aboutsummaryrefslogtreecommitdiffstats
path: root/danish/Bugs/server-control.wml
blob: 81bdf75d2a643351cc22c9e4fb99a3dcb5dab4cd (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
#use wml::debian::template title="Debians fejlrapporteringssystem — kontrolserveren" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="d11193e66dd678156a1f8aa4c02b5ec7ae7eb116"

<h1>Introduktion til e-mailserveren til fejlrapportskontrol og -behandling</h1>

<p>På samme måde som <code>request@bugs.debian.org</code> gør det muligt at
<a href="server-request">hente fejldata og dokumentation gennem e-mail</a>, 
gør <code>control@bugs.debian.org</code> det muligt at behandle fejlrapporter på 
forskellige måder.</p>

<p>Kontrolserveren fungerer præcis som forespørgselsserveren og har desuden 
nogle ekstra kommandoer.  Hvis sandheden skal frem, så er det faktisk det 
samme program.  De to adresser er bare blevet adskilt for at forhindre
afsenderen i at begå fejl og forårsage problemer, når alt hvad vedkommende 
ønskede var at hente oplysninger.</p>

<p>Da kommandoerne der er specifikke for kontrolserveren faktik ændrer fejlens
status, vil der blive sendt en besked om behandlingen af kommandoerne til
vedligeholderen af den eller de pakker, som fejlen vedrører.  Desuden bliver
mailen til serveren og den ændringer den medfører logget i fejlrapporten og 
bliver dermed tilgængelige på websiderne.</p>

<p>Se <a href="server-request#introduction">introduktion til 
forespørgselsserveren</a> som findes på nettet, i filen 
<code>bug-log-mailserver.txt</code>, og ved at sende <code>help</code> til
en af e-mailserverne for grundlæggende oplysninger om hvordan man anvender
e-mailserverne, og for en liste over de tilgængelige kommandoer uanset 
hvilken adresse man anvender.</p>

<p>Et <a href="server-refcard">referencekort</a> til e-mailserveren er 
tilgængeligt via nettet, i <code>bug-mailserver-refcard.txt</code> eller via 
e-mail med kommandoen <code>refcard</code>.</p>


<h1>Kommandoer der findes på kontrolserveren</h1>

  <table style="margin-left:auto;margin-right:auto">
    <tr>
    <td align="center">Generelt</td>
    <td align="center">Versionering</td>
    <td align="center">Duplikater</td>
    <td align="center">Forskelligt</td>
    </tr>
    <tr>
      <!-- General -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#reassign">reassign</a></li>
	  <li><a href="#severity">severity</a></li>
	  <li><a href="#tag">tags</a></li>
	  <li><a href="#retitle">retitle</a></li>
	  <li><a href="#submitter">submitter</a></li>
	  <li><a href="#affects">affects</a></li>
	  <li><a href="#summary">summary</a></li>
	  <li><a href="#outlook">outlook</a></li>
	</ul>
      </td>
      <!-- Versioning -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#found">found</a> | <a href="#notfound">notfound</a></li>
	  <li><a href="#fixed">fixed</a> | <a href="#notfixed">notfixed</a></li>
	  <li><a href="#reopen">reopen</a></li>
	  <!-- <dt>(close)</dt> Deprecated -->
	</ul>
      </td>
      <!-- Duplicates -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li>
	  <li><a href="#forcemerge">forcemerge</a></li>
	  <li><a href="#clone">clone</a></li>
	</ul>
      </td>
      <!-- Misc. -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#thanks">thanks</a></li>
	  <li><a href="#comment">#</a></li>
	  <li><a href="#forwarded">forwarded</a> |  <a href="#notforwarded">notforwarded</a></li>
	  <li><a href="#owner">owner</a> | <a href="#noowner">noowner</a></li>
	  <li><a href="#block">block</a> | <a href="#unblock">unblock</a></li>
	  <li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li>
          <li><a href="server-request#user">user</a> |
            <a href="server-request#usertag">usertag</a> |
            <a href="server-request#usercategory">usercategory</a></li>
	</ul>
      </td>
    </tr>
  </table>


<dl>
  <dt><a name="reassign">
      <code>reassign</code> <var>fejlnummer</var> <var>pakke</var>
      [ <var>version</var> ]</a></dt>
  <dd><p>Angiver at fejlen med nummeret <var>fejlnummer</var> er en fejl i pakken
      <var>pakke</var>.  Dette kan anvendes til at sætte pakkenavnet hvis
      afsenderen glemte pseudo-brevhovedet, eller til at ændre en tidligere
      tildeling.  Der sendes ikke besked til nogen (bortset fra normale 
      oplysninger om kommandofortolkningen).</p>

      <p>Hvis du tilføjer en <var>version</var> vil fejlsporingssystemet
      bemærke, at fejlen påvirker den version af den nyligt tildelte pakke.</p> 

      <p>Du kan på samme tid tildele en fejl til to pakker, ved at adskille
      pakkenavnene med et komma.  <em>Dog</em> bør du kun gøre dette, hvis 
      fejlen kan rettes med en ændring til <em>af en</em> pakkerne.  Er det ikke
      tilfældet, bør du <a href="#clone">klone</a> fejlen og gentildele klonen 
      til den anden pakke.</p>
  </dd>

  <dt><a name="reopen">
      <code>reopen</code> <var>fejlnummer</var>
      [ <var>oprindelsesadresse</var> | <code>=</code> | <code>!</code> ]</a></dt>
  <dd><p>Åbner fejlrapporten med nummeret <var>fejlnummer</var> igen og tømmer 
      alle rettede versioner, hvis den er lukket.</p>
      <p>Som standard, eller hvis man angiver <code>=</code>, vil stadig kun 
      den oprindelige afsender være angivet som den der har rapporteret fejlen,
      så vedkommende vil blive informeret når rapporten lukkes igen.</p>
      <p>Hvis man medsender en ny <var>oprindelsesadresse</var> vil den blive
      anvendt i stedet for.  Hvis man selv være stå opført som afsenderen af 
      den nyåbnede fejlrapport, kan man anvende forkortelsen <code>!</code>, 
      eller angive sin egen e-mailadresse.</p>
      <p>Det er normalt en god idé at underrette personen der kommer til at stå
      som afsender af fejlrapporten, om at man genåbner rapporten, så 
      vedkommende er forberedt på at blive informeret når rapporten lukkes 
      igen.</p>
      <p>Hvis fejlrapporten ikke er lukket, vil reopen-kommandoen ikke gøre 
      noget, ikke engang ændre oprindelsesadressen.  For at ændre 
      oprindelsesadressen på en åben fejlrapport anvendes kommandoen 
      <code>submitter</code>; bemærk at dette ikke vil oplyse den oprindelige
      indsender om ændringen.

      <p>Hvis fejlen er blevet registreret som lukket i en bestemt version af
      en pakke, men dukker op igen i en senere version, det er bedre at 
      anvende kommandoen <code>found</code> i stedet.</p>
  </dd>

  <dt><a name="found">
      <code>found</code> <var>fejlnummer</var> [ <var>version</var> ]</a></dt>
  <dd><p>Registrerer at #<var>fejlnummer</var> er opdaget i den angivne 
      <var>version</var> af pakken som den er knyttet til.
      <var>version</var> kan være en komplet versionsangivelse på formen 
      <var>kildekodepakkenavn/version</var>.</p>

      <p>Fejlsporingssystemet anvender denne oplysning, sammen med rettede
      versionerner, der registreres når fejl lukkes, for at vise en liste over
      åbne fejl i forskellige udgaver af hver pakke.  Systemet anser en fejl
      for at være åben når der ikke er en rettet version eller når den er 
      fundet senere end den er rettet.</p>

      <p>Hvis ingen <var>version</var> er angivet, tømmes fejlens liste over 
      rettede versioner.  Dette svarer til hvordan <code>reopen</code> 
      fungerer.  <var>version</var> kan være en komplet versionsangivelse på 
      formen <var>kildekodepakkenavn/version</var>.</p>

      <p>Denne kommando sørger kun for at markere en fejl som ikke-løst hvis
      ingen version blev angivet, eller hvis den <var>version</var>, der
      markeres svarer til eller er større end den højeste <var>version</var>, 
      der sidst blev markeret som rettet.  (Hvis du er sikker på, at du ønsker 
      fejlen markeret som ikke-løst, anvend da <code>reopen</code> sammen med 
      <code>found</code>.)</p>

      <p>Denne kommando blev indført til fordel for <code>reopen</code>, fordi
      det var svært at tilføje en <var>version</var> til den kommandos 
      syntaks uden at lide af flertydighed.</p>
  </dd>

  <dt><a name="notfound">
      <code>notfound</code> <var>fejlnummer</var> <var>version</var></a></dt>
  <dd><p>Fjern registreringen af at #<var>fejlnummer</var> blev fundet i den
      angivne <var>version</var> af pakken som det er tilknyttet.
      <var>version</var> kan være en komplet versionsangivelse på formen 
      <var>kildekodepakkenavn/version</var>.</p>

      <p>Dette er anderledes end at lukke fejlen for den version, da fejlen
      heller ikke anføres som rettet i den version; ingen oplysninger om 
      versionen vil være kendte.  Formålet er at rette fejltagelser i 
      registreringen af hvornår en fejl blev fundet.</p>
  </dd>

  <dt><a name="fixed">
      <code>fixed</code> <var>fejlnummer</var> <var>version</var></a></dt>
  <dd><p>Angiv af fejl nummer <var>fejlnummer</var> blev rettet i en given
      <var>version</var> af den pakke, som den vedrører.
      <var>version</var> kan være en komplet versionsangivelse på formen 
      <var>kildekodepakkenavn/version</var>.</p>

      <p>Dette medfører <em>ikke</em> at fejlen markeres om lukket, det tilføjer
      blot en anden version, hvori fejlen er rettet.  Anvend adressen 
      bugnumber-done for at lukke fejlen og markere den som rettet i en bestemt
      version.</p>
  </dd>

  <dt><a name="notfixed">
      <code>notfixed</code> <var>fejlnummer</var> <var>version</var></a></dt>
  <dd><p>Fjern registreringen af at fejl nummer <var>fejlnummer</var> blev 
      rettet i den givne <var>version</var>.
      <var>version</var> kan være en komplet versionsangivelse på formen 
      <var>kildekodepakkenavn/version</var>.</p>

      <p>Denne kommando svarer til <code>found</code> efterfulgt af 
      <code>notfound</code> ('found' fjerner 'fixed' i en given version, og
      'notfound' fjerner 'found') med den undtagelse, at fejlen ikke genåbnes 
      hvis den fundne ('found') version er større end nogen eksisterende rettet 
      version.  Formålet er at rette fejltagelser i registreringen af hvornår en 
      fejl blev rettet; i de fleste tilfælde vil du i virkeligheden skulle 
      anvende <code>found</code>, og ikke <code>notfixed</code>.</p>
  </dd>

  <dt><a name="submitter">
      <code>submitter</code> <var>fejlnummer</var>
      <var>oprindelsesadresse</var> | <code>!</code></a></dt>
  <dd><p>Ændrer oprindelsesadressen i #<var>fejlnummer</var> til 
      <var>oprindelsesadresse</var>.</p>

      <p>Ønsker du blive ny oprinder af en rapport, kan du bruge kortformen 
      <code>!</code> eller angive din egen e-mail-adresse.</p>

      <p>Mens kommandoen <code>reopen</code> ændrer oprindelsen på andre
      fejlrapporter kombineret med den der genåbnes, påvirker 
      <code>submitter</code> ikke kombinerede fejlrapporter.</p>
  </dd>

  <dt><a name="forwarded">
      <code>forwarded</code> <var>fejlnummer</var> <var>adresse</var></a></dt>
  <dd><p>Noterer at fejlrapporten med nummeret <var>fejlnummer</var> er blevet
      videresendt til en opstrømsudvikler på adressen <var>adresse</var>.  Dette
      videresender faktisk ikke rapporten, men kan anvendes til at ændre en
      eksisterende, forkert vidersendelsesadresse, eller til at registrere en 
      ny adresse til en fejl som ikke tidligere var registeret som videresendt.
      <var>addresse</var> bør generelt være en URI eller muligvis en 
      e-mail-adresse.  Ved, hvor muligt, at angive en URI, er der mulighed for 
      at værktøjer kan forespørge et fjerntliggende fejlsporingssystem (så som 
      bugzilla) om en fejls status.</p>
      <p>Eksempel på brug:</p>
      <pre>
        forwarded 12345 http://bugz.illa.foo/cgi/54321
      </pre>
  </dd>

  <dt><a name="notforwarded">
      <code>notforwarded</code> <var>fejlnummer</var></a></dt>
  <dd><p>Glemmer alt om at fejlrapporten med nummeret <var>fejlnummer</var> er
      blevet videresendt til en opstrømsudvikler.  Hvis fejlen ikke er 
      registeret som videresendt, gør denne kommando ikke noget.</p>
  </dd>

  <dt><a name="retitle">
      <code>retitle</code> <var>fejlnummer</var> <var>ny-titel</var></a></dt>
  <dd><p>Ændrer titlen på en fejlrapport til den angivne (standard er den
      oprindelige rapports titel i <code>emne</code>-linjen).  Ændrer også 
      titlen på alle fejlrapporter, som denne fejl er slået sammen med.</p>
  </dd>

  <dt><a name="severity">
      <code>severity</code> <var>fejlnummer</var> <var>alvorsgrad</var></a></dt>
  <dd><p>Sætter alvorsgraden på fejlrapporten med nummeret <var>fejlnummer</var> 
      til alvorsgraden <var>grad</var>.  Den oprindelige afsender af rapporten
      underrettes ikke.</p>
      <p>Tilgængelige alvorsgrader er <bts_severities>.</p>
      <p>For en beskrivelse af hvad de <a href="Developer#severities">\
      betyder</a>, se udviklernes gennerelle dokumentation vedrørende
      fejlrapporteringssystemet.</p>
  </dd>

  <dt><a name="affects"><code>affects</code> <var>fejlnummer</var>
      [ <code>+</code> | <code>-</code> | <code>=</code>
      ] <var>pakke</var> [ <var>pakke</var> ... ]</a></dt>
  <dd>
    <p>
      Indikerer at en fejl påvirker en anden pakke.  I tilfældet hvor
      <var>fejlnummer</var> forårsager problemer i <var>pakke</var>, selv om 
      fejlen i virkeligheden findes i den pakke, som den er tildelt, forårsager
      dette at fejlen som standard vises i fejllisten hørende til 
      <var>pakke</var>.  Det bør generelt anvendes, hvor en fejl er alvorlig nok
      til at forårsage flere rapporter fra brugerne bliver tildelt den forkerte 
      pakke.  <code>=</code> opsætter det påvirkede til den oplyste liste over 
      pakker, og er standardhandlingen hvis ingen pakker er oplyst; 
      <code>-</code> fjerner de oplyste pakker fra listen over påvirkede; 
      <code>+</code> tilføjer de oplyste pakker til listen over påvirkede, og er
      standard hvis der er oplyst pakker.
    </p>
  </dd>

  <dt><a name="summary"><code>summary</code> <var>fejlnummer</var>
      [<var>meddelelsesnummer</var> | <var>opsumeringstekst</var>]</a></dt>
  <dd>
    <p>
      Vælger en meddelelse, der anvendes som fejlens opsummering.  Det første 
      ikke-pseudoheader-/ikke-control-afsnit hørende til den meddelelse, 
      fortolkes og opsættes som opsummering vedrørende fejlen og vises øverst på 
      fejlrapportsiden.  Det er nyttigt i situationer, hvor den oprindelige 
      rapport ikke på korrekt vis beskriver problemet eller hvis fejlen har 
      mange meddelelser, der gør det vanskeligt at identificere det egentlige 
      problem.
    </p>
    <p>
      Hvis <var>meddelelsesnummer</var> ikke er angivet, fjernes opsummeringen.
      <var>meddelelse nummer</var> er meddelelsesnummeret, der vises i outputtet 
      fra bugreport-cgi-skriptet; hvis et <var>meddelelsesnummer</var>0 
      angives, anvendes den aktuelle meddelelse (dvs. den meddelelse, som blev 
      sendt til control@bugs.debian.org som indeholder resumet af 
      control-kommandoen).
    </p>
    <p>
      Hvis <var>meddelelsesnummer</var> ikke er numerisk og ikke en tom streng,
      formodes det at være den tekst, som opresumeringen skal sættes til.
    </p>
  </dd>

  <dt><a name="outlook"><code>outlook</code> <var>fejlnummer</var>
      [<var>meddelelsesnummer</var> | <var>outlook-tekst</var>]</a></dt>
  <dd>
    <p>
      Vælger en meddelelse, som skal anvendes som outlook'et til rettelse af en
      fejl (eller den aktuelle status på fejlrettelsen).  Det første afsnit som 
      ikke er en pseudoheader/kontrol i den pågældende meddelelse fortolkes og 
      anvendes som fejlens outlook, der vises øverst på fejlrapportsiden. 
      Det er nyttigt til koordinering med andre, som arbejder på at rette den 
      samme fejl (eksempelvis under en fejlrettelsesfest).
    </p>
    <p>
      Hvis <var>meddelelsesnummer</var> ikke er angivet, tømmes outlook'et.
      <var>meddelelsesnummer</var> er det meddelesesnummer, som er uddata fra 
      bugreport-cgi-skriptet; hvis der angives et <var>meddelelsesnnummer</var>0, benyttes den aktuelle meddelelse (det vil sige, meddelelsen, som 
      blev senddt til control@bugs.debian.org, der indeholder kontrolkommandoen 
      summary).
    </p>
    <p>
      Hvis <var>meddelelsesnummer</var> ikke er numerisk og ikke en tom streng,
      formodes det at være den tekst, som opresumeringen skal sættes til.
    </p>
  </dd>

  <dt><a name="clone">
      <code>clone</code> <var>fejlnummer</var> <var>ny id</var> [ <var>nye id'er</var> ... ]</a></dt>
  <dd><p>Kloningskommandoen giver mulighed for at kopiere en fejlrapport.  Det er
      nyttigt hvor en enkelt fejlrapport faktisk angiver at flere forskellige
      fejl er opstået. <q><var>Nye id'er</var></q> er negative tal, adskilt af 
      mellemrumstegn, som kan benyttes i efterfølgende kontrolkommandoer til 
      at referere til de nyligt kopierede fejlrapporter.  Den oprettes en ny
      rapport for hver ny id.</p>
      <p>Eksemel på anvendelse:</p>
      <pre>
        clone 12345 -1 -2
        reassign -1 foo
        retitle -1 foo: foo sucks
        reassign -2 bar
        retitle -2 bar: bar sucks when used with foo
        severity -2 wishlist
        clone 123456 -3
        reassign -3 foo
        retitle -3 foo: foo sucks
        merge -1 -3
      </pre>
  </dd>

  <dt><a name="merge">
      <code>merge</code> <var>fejlnummer</var> <var>fejlnummer</var> ...</a></dt>
  <dd><p>Slår to eller flere fejlrapporter sammen.  Når rapporter er slået sammen
      vil åbning, lukning, markering af videresendelse eller fjernelse af 
      samme, samt omtildeling til en anden pakke af en af pakkerne have samme 
      effekt på alle de rapporter som er slået sammen.</p>
      <p>Inden fejlrapporter kan slås sammen skal de have præcis den samme 
      tilstand, enten skal de alle være åbne eller lukkede, med en samme 
      videresend-opstrømsadresse eller ikke alle markeret som videresendte,
      alle tildelt de(n) samme pakke(r) (en nøjagtig strengsammenligning 
      anvendes på de pakker som fejlrapporterne er tildelt). og alle skal have
      samme alvorsgrad. Hvis de fra begyndelsen ikke har samme tilstand skal 
      man anvende <code>reassign</code>, <code>reopen</code>, og så videre så
      de har samme tilstand inden man anvender kommanoden 
      <code>merge</code>.  Det er ikke nødvendigt at titler er ens og de vil
      ikke blive påvirket af kommandoen.  Tags behøver heller ikke at være ens,
      de vil blive samlet.</p>
      <p>Hvis nogle af fejlrapporterne anført i en <code>merge</code>-kommando
      allerede er slået sammen med andre rapporter, vil også de allerede 
      sammenslåede rapporter blevet slået sammen med de angivne fejlrapporter.
      Sammenslåning er som ækvivalent: den er refleksiv, transitiv og 
      symmetrisk.</p>
      <p>Når fejlrapporter slås sammen, bliver dette noteret i hver enkelt
      rapports log, og på websiderne oprettes links til de andre fejl.</p>
      <p>Sammenslåede fejlrapporter udløber samtidig, og kun når alle 
      rapporterne hver for sig opfylder kriterierne for at udløbe.</p>
  </dd>

  <dt><a name="forcemerge">
      <code>forcemerge</code> <var>fejlnummer</var> <var>fejlnummer</var> ...</a></dt>
  <dd><p>Gennemtvinger forbindelse af to eller flere fejlrapporter.  Den første 
      fejls indstillinger, som skal svare til en normal merge-kommando, tildeles 
      de efterfølgende angivne fejl.  For at undgå, at tastefejl fejlagtigt slår 
      fejl sammen, skal fejlene være i den samme pakke.  Se teksten oven for, 
      for en beskrivelse af hvad det vil sige at slå fejlrapporter sammen.</p>
      <p>Bemærk at dette gør det muligt at lukke fejl ved at slå dem sammen, du er
      ansvarlig for at give indsenderne besked med en passende lukningsmeddelse,
      hvis du vælger at gøre dette.</p>
  </dd>

  <dt><a name="unmerge">
      <code>unmerge</code> <var>fejlnummer</var></a></dt>
  <dd><p>Fjerner forbindelsen mellem en fejlrapport og de rapporter den er slået
      sammen med.  Hvis rapporten er slået sammen med flere andre, vil de andre
      fortsat være slået sammen, kun forbindelsen til den specifikt angivne 
      fejlrapport fjernes.</p>
      <p>Hvis mange fejlrapporter er slået sammen og du ønsker at opdele dem
      i to separate grupper af sammenslåede rapporter, skal de først fjerne
      forbindelserne for hver enkelt rapport i den ene nye gruppe, og dernæst
      slå dem sammen til den nye gruppe.</p>
      <p>Du kan kun fjerne forbindelsen for en rapport ad gangen med 
      <code>unmerge</code>-kommandoen.  Hvis du vil fjerne forbindelsen til
      flere fejlrapporter, skal du blot angive flere 
      <code>unmerge</code>-kommandoer i din meddelelse.</p>
  </dd>

  <dt><a name="tags"><!-- match tags too --></a><a name="tag">
      <code>tags</code> <var>fejlnummer</var> [ <code>+</code> | <code>-</code> 
      | <code>=</code> ] <var>mærke</var> [ <var>mærke</var> ... ]
      [ <code>+</code> | <code>-</code> | <code>=</code> <var>mærke</var> ... ] ]</a></dt>
  <dd><p>Sætter mærker for fejlrapporten med nummeret <var>fejlnummer</var>.
      Brugeren som rapporterede fejlen bliver ikke underrettet.  Sættes 
      handlingen til <code>+</code>, betyder det at alle de efterfølgende
      <var>mærker</var> tilføjes; <code>-</code> betyder at alle de efterfølgende
      <var>mærker</var> fjernes; og <code>=</code> betyder at de efterfølgende
      mærker opsættes jævnfør den leverede liste.  Anvendelse af mærkerne 
      <code>+</code>, <code>-</code> eller <code>=</code> ændrer handlingen på 
      de efterfølgende mærker.  Standardhandlingen er tilføjelse.</p>

      <p>Eksempler:</p>

      <pre>
	\# det samme som 'tags 123456 + patch'
	tags 123456 patch

	\# det samme som 'tags 123456 + help security'
	tags 123456 help security

	\# tilføjer mærkerne 'fixed' og 'pending'
	tags 123456 + fixed pending

	\# fjerner mærket 'unreproducible'
	tags 123456 - unreproducible

	\# sætter mærkerne til kun 'moreinfo' og 'unreproducible'
	tags 123456 = moreinfo unreproducible

	\# fjerner mærket moreinfo og tilføjer et patch-mærke
	tags 123456 - moreinfo + patch
      </pre>

      <p>Tilgængelige markeringer er pt. <bts_tags>.</p>
      <p>For en beskrivelse af hvad de <a href="Developer#tags">\
      betyder</a>, se udviklernes gennerelle dokumentation vedrørende
      fejlrapporteringssystemet.</p>
  </dd>

  <dt><a name="block">
      <code>block</code> <var>fejlnummer</var> <code>by</code> <var>fejl</var> ...</a></dt>
  <dd><p>Bemærk at rettelsen til den første fejl blokeres af de andre anførte fejl.</p>
  </dd>

  <dt><a name="unblock">
      <code>unblock</code> <var>fejlnumber</var> <code>by</code> <var>fejl</var> ...</a></dt>
  <dd><p>Bemærk at rettelsen til den første fejl ikke længere blokeres af de andre 
      anførte fejl.</p>
  </dd>

  <dt><a name="close">
      <code>close</code> <var>fejlnummer</var> (bør ikke længere anvendes)</a></dt>
  <dd><p>Lukker fejlrapporten med nummeret <var>fejlnummer</var>.</p>
      <p>Bruger, der oprindeligt indsendte fejlrapporten, får besked, men 
      indholdet i den e-mail, der lukker rapporten, medtages <em>ikke</em> (til 
      forskel fra at sende til 
      <var>fejlnummer</var><code>-done@bugs.debian.org</code>).  
      Vedligeholderen, der lukker rapporten, bør sørge for at brugeren, der 
      indsendte rapporten, får besked om hvorfor rapporten blev lukket, for 
      eksempel ved at sende en separat e-mail.  Anvendelse af denne kommando 
      frarådes derfor.  Se udvikleroplysningerne om 
      <a href="Developer#closing">hvordan man på rette vis lukker en 
      fejl</a>.</p>
  </dd>

  <dt><a name="package">
      <code>package</code> [ <var>pakkenavn</var> ... ]</a></dt>
  <dd><p>Begrænser de følgende kommandoer, så de kun virker på fejl indsendt mod de
      angivne pakker.  Du kan angive en eller flere pakker.  Hvis du ikke 
      angiver nogen pakker, vil de følgende kommandoer virke på alle fejl.
      Du opfordres til at anvende dette som en sikkerhedsfunktion, i fald du
      ved et uheld angiver de forkerte fejlnumre.</p>

      <p>Eksempel på brug:</p>

      <pre>
        package foo
        reassign 123456 bar

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist
      </pre>
  </dd>

  <dt><a name="owner">
      <code>owner</code> <var>fejlnummer</var> <var>adresse</var> | <code>!</code></a></dt>
  <dd><p>Sætter <var>adresse</var> til at være <q>owner</q> (ejer) af #<var>fejlnummer</var>.
      Ejeren af en fejl tager ansvareret for at rette den.  Dette er nyttigt 
      til arbejdsdeling i tilfælde hvor en pakke har et hold af vedligeholdere.</p>
      <p>Ønsker du selv at blive fejlens ejer, kan du bruge forkortelsen 
      <code>!</code> eller angive din egen e-mail-adresse.</p>
  </dd>

  <dt><a name="noowner">
      <code>noowner</code> <var>fejlnummer</var></a></dt>
  <dd><p>Glemmer alt om, at fejlen har en ejer, bortset fra den sædvanlige 
      vedligeholder.  Der er ikke er registeret en ejer af fejlen har denne
      kommando ingen effekt.</p>
  </dd>

  <dt><a name="archive">
      <code>archive</code> <var>fejlnummer</var></a></dt>
  <dd><p>Arkiverer en fejl, der tidligere var arkiveret men ikke er det i 
      øjeblikket, hvis fejlen opfylder arkiveringskravene, ignorerende 
      tidskrav.</p>
  </dd>

  <dt><a name="unarchive">
      <code>unarchive</code> <var>fejlnummer</var></a></dt>
  <dd><p>Ophæver arkiveringen af en fejl, der tidligere var arkiveret.  Ophævelse 
      af arkivering bør generelt kombineres med <q>reopen</q> (genåbn) og 
      <q>found</q>/<q>fixed</q> (fundet/rettet) hvor det er relevant.  Fejl, 
      hvis arkivering er blevet ophævet, kan arkiveres med <q>archive</q>,
      forudsat at de ikke-tidsmæssige arkiveringskrav er opfyldt.  Man bør ikke 
      anvende ophævelse af arkiving for at foretage trivielle ændringer på 
      arkiverede fej, så som at andre indsenderen; det primære formål er at gøre
      det muligt at genåbne fejl, der er blevet arkiveret, uden 
      BTS-administratorernes mellemkomst.</p>
  </dd>

  <dt><a name="comment">
      <code>#</code>...</a></dt>
  <dd><p>En-linje-kommentar.  <code>#</code> skal være på begyndelsen af linjen.
      Kommentartekster vil blive medtaget i bekræftelsen som sendes til 
      afsenderen og berørte vedligeholdere, hvorfor du kan anvende dette til at
      dokumentere årsagerne til dine kommandoer.</p>
  </dd>

  <dt><a name="thanks"><code>quit</code></a></dt>
  <dt><code>stop</code></dt>
  <dt><code>thank</code></dt>
  <dt><code>thanks</code></dt>
  <dt><code>thankyou</code></dt>
  <dt><code>thank you</code></dt>
  <dt><code>--</code></dt>
  <!-- #366093, I blame you! -->
  <!-- <dt><code>kthxbye</code> -->
  <!-- See... I documented it! -->
  <dd><p>På en linje for sig selv, efterfulgt af whitespace, fortæller 
      kontrolserveren at den skal stoppe behandlingen af meddelelsen;
      resten af meddelelsen kan indeholde forklaringer, underskrifter eller
      hvad som helst, intet af det vil blive bemærket af kontrolserveren.</p>
  </dd>
</dl>

<hr>

#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"

© 2014-2024 Faster IT GmbH | imprint | privacy policy