Developer.wml 22.7 KB
Newer Older
1
#use wml::debian::template title="Debians feilrapportsystem — utviklerinfo" NOHEADER=yes NOCOPYRIGHT=true
2
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
3
#use wml::debian::translation-check translation="1.99" maintainer="Hans F. Nordhaug"
4 5
# Oversatt til norsk av Tollef Fog Heen (tfheen@debian.org)
# Oppdatert 2001-12-29 av Tor Slettnes (tor@slett.net)
6
# Oppdatert 2010-08-23 av Cato Auestad <bleakgadfly@fsfe.org>
7
# Oppdateres av Hans F. Nordhaug <hansfn@gmail.com>
8 9 10 11

  <h1>Utviklerinformasjon om feilrapportsystemet</h1>

  <p>
12
    Feilrapporter blir først sendt som en vanlig e-post til
13 14 15
    <code>submit@bugs.debian.org</code> som må inkludere en
    <code>Package</code>-linje (se  <a href="Reporting">Instruksjoner for
    feilrapportering</a> for mer informasjon). Rapporten får deretter et
16
    nummer, en kvittering blir sendt til innsenderen og rapporten blir
17 18 19
    videresendt til <code>debian-bugs-dist</code>. Hvis
    <code>Package</code>-linja inneholder en pakke som har en kjent 
    utvikler, så sendes det en kopi til utvikleren også.</p>
20 21

  <p>
22
    <code>Subject</code>-feltet vil få lagt til
23
    <code>Bug#</code><var>nnn</var><code>:</code> og
24
    <code>Reply-To</code> settes slik at den inkluderer både
25 26
    innsenderen og <var>nnn</var><code>@bugs.debian.org</code>.</p>

27
  <ul class="toc">
28
    <li><a href="#closing">Lukke feilrapporter</a></li>
29
    <li><a href="#followup">Oppfølgingsmeldinger</a></li>
30 31 32 33
    <li><a href="#severities">Alvorlighetsgrader</a></li>
    <li><a href="#tags">Merkelapper for feilrapporter</a></li>
    <li><a href="#forward">Informere om at du har videresendt en
	feilrapport</a></li>
34
    <li><a href="#owner">Endre eierskap på feilrapporter</a></li>
35
    <li><a href="#maintincorrect">Feilangitte pakkeutviklere</a></li>
36
    <li><a href="#requestserv">Gjenåpne, tildele og endre på
37
	feilrapporter</a></li> 
38
    <li><a href="#subscribe">Abonner på feilrapporter</a></li>
39
    <li><a href="#subjectscan">Mer eller mindre avlegs
40
	tittelfeltsøk</a></li> 
41 42 43 44 45 46 47
    <li><a href="#x-debian-pr">Avlegs <code>X-Debian-PR:
	  quiet</code>-egenskap</a></li> 
  </ul>

  <h2><a name="closing">Lukke feilrapporter</a></h2>

  <p>
48
    Debians feilrapporter skal lukkes når feilen er rettet. Problemer
49
    i pakkene kan kun anses som rettet etter at en pakke som innholder
50
    rettelsen på feilen er lastet inn i Debian-arkivet.</p>
51 52 53 54 55 56 57

  <p>
    Vanligvis er de eneste personene som kan lukke en feilrapport
    innsenderen av rapporten og vedlikeholderen(e) av pakken
    rapporten var sendt inn mot. Det finnes unntak til denne regelen,
    eksempelvis for feilrapporter som er sendt inn mot ukjente pakker eller
    visse generelle pseudo-pakker. Hvis du er i tvil, ikke lukk
58
    feilrapporter uten å spørre om råd i e-postlisten debian-devel.</p>
59 60

  <p>
61
    Feilrapporter lukkes ved å sende en e-post til
62
    <var>nnn</var><code>-done@bugs.debian.org</code>. Kroppen av
63
    meldingen må inneholde en forklaring av hvordan feilen ble fikset.
64 65 66 67
  </p>

  <p>
    Med en e-postene du har mottatt fra feilrapportsystemet er alt du
68
    trenger å gjøre for å lukke en feilrapport å svare på meldingen i
69 70 71 72 73 74 75 76 77
    e-postleseren din, og endre <code>To</code>- eller
    <code>Til</code>-feltet til 
    <var>nnn</var><code>-done@bugs.debian.org</code> i stedet for
    <var>nnn</var><code>@bugs</code>
    (<var>nnn</var><code>-close</code> er et alias for
    <var>nnn</var><code>-done</code>).</p>

  <p>Der det er anvendelig vennligst angi en <code>Version</code>-linje i 
    <a href="#Reporting#pseudoheader">pseudo-headeren</a> av din melding
78
    når du lukker en feilrapport. Slik vet feilrapportsystemet hvilken 
79 80 81 82
    utgivelse av pakken som inneholder en rettelse av feilen.</p>

  <p>
    Personen som lukker feilrapporten, den som sendte den inn, og
83
    e-postlisten <code>debian-bugs-closed</code> vil hver få en melding om
84
    endring av status i feilrapporten. Innsenderen og e-postlisten
85
    vil også motta innholdet av meldingen som ble sendt til
86 87 88
    <var>nnn</var><code>-done</code>.</p>


89
  <h2><a name="followup">Oppfølgingsmeldinger</a></h2>
90 91 92

  <p>
    Feilrapportsystemet vil inkludere innsenderen's adresse og
93
    feilrapportsadressen (<var>nnn</var><code>@bugs.debian.org</code>) i
94
    <code>Reply-To</code>-feltet når feilrapporten videresendes til
95 96 97
    pakkeutvikleren. Merk at disse er to adskilte adresser.</p>

  <p>
98
    Enhver utvikler som ønsker å svare på en feilmelding kan rett og
99
    slett svare på e-posten i samsvar med <code>Reply-To</code>-feltet.
100 101 102 103
    Dette vil <strong>ikke</strong> markere feilrapporten som lukket.</p>

  <p>
    <em>Ikke</em> bruk <q>svar til alle</q> eller <q>followup</q> dersom du ikke
104 105
    har til hensikt å vesentlig redigere på mottakerlisten. Pass spesielt på at
    du ikke sender oppfølgingsmeldinger til
106 107
    <code>submit@bugs.debian.org</code>.</p>

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
  <p>
    Meldinger kan sendes til følgende adresser for å bli lagret i feilrapportsystemet:
  </p>

  <ul>
    <li>
      <var>nnn</var><code>@bugs.debian.org</code> &mdash; slike meldinger sendes
      også til pakkeutvikleren og blir videresendt til <code>debian-bugs-dist</code>,
      men <strong>ikke</strong> til innsenderen;
    </li>
    <li>
      <var>nnn</var><code>-submitter@bugs.debian.org</code> &mdash; disse sendes 
      også til innsenderen og blir videresendt til <code>debian-bugs-dist</code>,
      men <strong>ikke</strong> til pakkeutvikleren;
    </li>
    <li>
      <var>nnn</var><code>-maintonly@bugs.debian.org</code> &mdash; disse sendes kun
      til pakkeutvikleren, <strong>ikke</strong> til innsenderen
      eller <code>debian-bugs-dist</code>;
    </li>
    <li>
      <var>nnn</var><code>-quiet@bugs.debian.org</code> &mdash; disse blir kun
      lagret i feilrapportsystemet (som alle over), 
      <strong>ikke</strong> sendt til noen andre.
    </li>
  </ul>
134 135

  <p>
136
    For mer informasjon om linjer til å dempe ACK-meldinger og hvordan sende
137 138 139 140 141 142 143 144
    kopier ved bruk av feilrapportsystemet, se 
    <a href="Reporting">Instruksjoner for feilrapportering</a>.</p>

  <h2><a name="severities">Alvorlighetsgrader</a></h2>

  <p>
    Feilrapportsystemet lagrer en alvorlighetsgrad sammen med hver
    feilrapport. Denne settes til <code>normal</code> til vanlig, men
145 146
    kan overstyres, enten ved å ha en <code>Severity</code>-linje i
    pseudo-hodet på eposten når den sendes inn (se
147
    <a href="Reporting#pseudoheader">instruksjonene for
148
    feilrapportering</a>), eller ved å bruke
149 150 151 152 153 154 155 156 157
    <code>severity</code>-kommandoen med <a
    href="#requestserv">kontrolltjeneren</a>.</p>

  <p>
    Alvorlighetsgradene er:

    <dl>
      <dt><code>critical</code> (kritisk)</dt>
      <dd>
158 159 160
	en feil som får annen ubeslektet programvare på systemet
	(eller hele systemet) til å slutte å fungere, eller forårsaker
	alvorlig datatap, eller lager et sikkerhetshull på systemer
161 162 163 164 165
	der pakken installeres.</dd>
      

      <dt><code>grave</code> (graverende)</dt>
      <dd>
166 167
	gjør pakken det er snakk om helt eller for det meste
	ubrukelig, forårsaker datatap eller lager et sikkerhetshull
168 169 170 171
	som gir tilgang til kontoene til brukerne som bruker pakken.</dd>

      <dt><code>serious</code> (alvorlig)</dt>
      <dd>
172 173 174
	et alvorlig brudd på Debians retningslinjer (det vil si, pakken bryter
	mot et <q>må</q> eller <q>påkrevd</q>-krav) eller, i følge
	pakkeutvikleren, gjør pakken uegnet for utgivelse.</dd>
175 176 177 178


      <dt><code>important</code> (viktig)</dt>
      <dd>
179 180
	en feil som har gjør at pakken ikke virker skikkelig, uten å
	gjøre den fullstendig ubrukelig.</dd>
181 182 183 184 185 186 187 188

      <dt><code>normal</code> (vanlig)</dt>
      <dd>
	standardverdien og den mest vanlige</dd>


      <dt><code>minor</code> (liten)</dt>
      <dd>
189 190
	et problem som ikke påvirker pakkens nytteverdi, og som
	sannsynligvis er trivielt å rette.</dd>
191

192
      <dt><code>wishlist</code> (ønske)</dt>
193
      <dd>
194 195
	for spørsmål om nye funksjoner og feil som er vanskelige å
	rette på grunn av designvalg.</dd>
196 197 198 199
    </dl>

  <p>
    Visse alvorlighetsgrader anses som
200
    <em><a href="https://bugs.debian.org/release-critical/">utgivelseskritisk</a></em>,
201 202 203
    noe som betyr at feilen vil bestemme om pakken blir utgitt sammen
    med den stabile utgaven av Debian. For tiden er disse gradene
    <strong>critical</strong>, <strong>grave</strong>, og
204
    <strong>serious</strong>. For fullstendige regler om disse alvorlighetsgradene, 
205
    se listen med <a href="https://release.debian.org/testing/rc_policy.txt">
206 207
    utgivelseskritiske feil for neste utgaven</a>.
  </p>
208 209 210 211 212 213


  <h2><a name="tags">Merkelapper for feilrapporter</a></h2>

  <p>
    Hver rapport kan ha null eller flere merkelapper angitt. Disse
214 215
    blir vist både i listen over feilrapporter på pakkens egen side, 
    og på den fullstendige feilrapportloggen.</p>
216 217

  <p>
218 219
    Merkelapper kan settes ved å bruk en <code>Tags</code>-linje i
    pseudo-linjen når feilen meldes inn (se <a
220
    href="Reporting#pseudoheader">instruksjoner for
221
    feilrapportering</a>), eller ved å bruke
222 223 224 225 226
    <code>tags</code>-kommandoen til <a
    href="#requestserv">kontrolltjeneren</a>.
    Separer flere merkelapper med komma, mellomrom eller begge.
  </p>

227 228 229
  <p>Gjeldende merkelapper er: <bts_tags>.</p>

  <p>Nedenfor finner du litt detaljert informasjon om hver merkelapp.</p>
230 231 232 233

    <dl>
      <dt><code>patch</code> (lapp)</dt>
      <dd>
234
	En lapp eller en annen enkel prosedyre for å rette feilen er
235
	inkludert i feilrapporten. Hvis det er en lapp tilgjengelig,
236
	men den ikke retter feilen ordentlig eller forårsaker et annet
237 238
	problem skal ikke denne merkelappen brukes.</dd>

239
      <dt><code>wontfix</code> (kommer ikke til å rettes)</dt>
240
      <dd>
241 242 243 244
	Denne feilen kommer ikke til å bli rettet.  Dette kan skyldes
	at man har valgt en av to likeverdige måter å gjøre noe på og
	utvikleren og innsenderen foretrekker to forskjellige måter,
	fordi endring av oppførselen vil forårsake andre, verre
245 246 247 248
	problemer for andre, eller av andre grunner.</dd>

      <dt><code>moreinfo</code> (mer informasjon trengs)</dt>
      <dd>
249 250 251
	Denne feilen kan ikke rettes før mer informasjon blir gjort
	tilgjengelig. Feilrapporten kommer til å bli lukket dersom ny
	informasjon ikke kommer i løpet av noe tid (et par måneder).
252 253 254 255 256
	Denne merkelappen er for feilrapporter av typen <q>Dette virker
	ikke!</q>. Hva virker ikke?</dd>

      <dt><code>unreproducible</code> (ikke reproduserbar)</dt>
      <dd>
257 258
	Denne feilen kan ikke reproduseres på utviklerens system.
	Assistanse fra tredjepart er nødvendig for å diagnostisere
259 260 261
	problemet.</dd>

      <dt><code>help</code> (hjelp)</dt>
262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277
      <dd>
        Utvikleren trenger hjelp for å fikse denne feilen.
        Enten har ikke utvikleren de nødvendige ferdighetene for å 
        rettet feilen og ønsker samarbeid, eller så er utvikleren
        overarbeidet og ønsker å delegere oppgaven. Feilen er kanskje
        ikke passende for nye bidragsytere med mindre den også er merket
        med <code>newcomer</code>-merkelapper.
      </dd>

      <dt><code>newcomer</code> (nybegynnere)</dt>
      <dd>
        Denne feilen har en kjent løsning, men utvikleren ber om at noen
        andre implementerer løsningen. Dette er en ideell oppgave for nye
        bidragsytere som ønsker å bli involvert i Debian eller som ønsker
        forbedre sine ferdigheter.
      </dd>
278

279 280
      <dt><code>pending</code> (i kø)</dt>
        <dd>En løsning på denne feilen har blitt funnet og en opplasting
281 282 283 284 285 286
	    vil bli gjort snarlig.</dd>

      <dt><code>fixed</code> (rettet)</dt>
      <dd>
	Denne feilen er rettet eller jobbet seg rundt (ved en
	opplasting av pakken av en annen utvikler enn den som er
287
	ansvarlig for den, f.eks), men problemet må fremdeles løses av
288 289 290 291 292 293 294
	utvikleren.  Denne merkelappen erstatter den gamle <q>fixed</q>
	alvorlighetsgraden.</dd>

      <dt><code>security</code> (sikkerhet)</dt>
      <dd>
	Denne rapporten beskriver et sikkerhetsproblem i en pakke
	(f.eks feil rettigheter som gir tilgang til data som ikke skal
295
	være tilgjengelig; bufferoverflyt som kan gi uautorisert
296
	tilgang til systemet, etc). De fleste sikkerhetsrelaterte
297
	feil bør også ha alvorlighetsgrad critical eller grave.</dd>
298

299
      <dt><code>upstream</code> (oppstrøms)</dt>
300
      <dd>
301
	Denne rapporten gjelder oppstrømsdelen av pakken.</dd>
302 303 304

      <dt><code>confirmed</code> (bekreftet)</dt>
      <dd>
305
	Utvikleren har sett, forstått og generelt sett er enig med
306 307
	at det er en feil, men har ikke fikset det. (Bruk av denne
	merkelappen er valgfri; den er til hovedsaklig for utviklere
308
	som behandler store mengder av åpne feilrapporter.)</dd>
309

310
      <dt><code>fixed-upstream</code> (fikset oppstrøms)</dt>
311
      <dd>
312
	Feilen har blitt fikset hos en utvikler oppstrøms, men er
313
	fortsatt ikke inkludert i pakken (for hva enn grunn: kanskje
314 315
	det er altfor komplisert å anvende i en eldre versjon eller
	altfor liten til å være verdt bryet).</dd>
316 317 318 319 320 321 322 323

      <dt><code>fixed-in-experimental</code> (fikset i eksperimentell)</dt>
      <dd>
	Feilen har blitt fikset i en pakke hos den eksperimentelle 
	utgaven, men ikke i den ustabile.</dd>

      <dt><code>d-i</code></dt>
      <dd>
324
        Denne feilen er relevant for utviklingen av debian-installer. Det
325 326 327
	er forventet at denne vil bli brukt når feilen påvirker utvikling 
	av installasjonsprogrammet, men ikke når feilen er innsendt mot en
	pakke som påvirker installasjonsprogrammet direkte.</dd>
328 329 330

      <dt><code>ipv6</code></dt>
      <dd>
331
	Denne feilen påvirker Internet Protocol version 6.</dd>
332 333 334

      <dt><code>lfs</code></dt>
      <dd>
335
	Denne feilen påvirker støtte for store filer (over 2 GB).</dd>
336 337 338

      <dt><code>l10n</code></dt>
      <dd>
339 340 341 342 343
	Denne feilen er relevant for lokalisering av pakken.</dd>
    
      <dt><code>a11y</code></dt>
      <dd>
        Denne feilen er relevant for pakkens tilgjengelighet.</dd>
344

345
      <dt><bts_release_tags></dt>
346
      <dd>
347 348 349 350 351 352
        Dette er utgave-merkelapper som har to innvirkninger. Når denne blir 
        satt på en feilrapport kan feilen kun påvirke den aktuelle utgaven 
        (men det kan påvirke andre utgaver hvis merkelapper for andre utgaver er satt)
        men ellers normale buggy/fixed/absent-regler gjelder. 
        Feilen burde ikke bli arkivert før den har blitt fikset i denne utgaven.
      </dd>
353

354
      <dt><bts_release_ignore_tags></dt>
355
      <dd>
356 357 358 359 360
        Denne utgavelseskritiske feilrapporten skal bli ignorert med målet om
        å få gi ut den aktuelle utgaven. <strong>Denne merkelappen skal kun bli 
        brukt av utgavelsesansvarlig(e); ikke sett denne selv uten eksplisitt 
        autorisasjon fra dem.</strong>
      </dd>
361 362 363 364

    </dl>

  <p>
365 366 367
    Noe informasjon om distribusjonsspesifikke merkelapper:
    <q>-ignore</q>-merkelappene ignorerer feilen for videre testing. 
    Merkelappene for utgivelse indikerer
368
    at aktuelle feilrapporter ikke skal bli arkivert før det har blitt
369
    ordnet i settet av utgivelser angitt. Merkelappen for utgivelse
370 371
    skal også indikere at feilrapporten er kun betenkt en feil i det
    settet med utgivelser angitt (med andre ord så er feilen 
372 373 374 375 376 377 378
    <strong>ikke tilstede</strong> i utgivelser hvor merkelappen for
    utgivelsen ikke er satt i feilrapporten).
  </p>

  <p>
    Merkelappene for utgivelser burde <strong>ikke</strong> bli brukt
    hvis rett angivelse av versjonen til feilrapporten ville utgjort
379 380
    nødvendig effekt, siden de krever manuelle tillegg og fjerning. 
    Hvis du er usikker på om en merkelapp for utgivelser er nødvendig,
381
    kontakt Debian sine administratorer for feilrapportsystemet (BTS)
382
    (<email "owner@bugs.debian.org">) eller utgivelseslaget for råd.
383 384 385 386 387 388 389
  </p>

  <h2>
    <a name="forward">Informere om at du har videresendt en
      feilrapport</a></h2> 

  <p>
390
    Når en Debian-utvikler videresender en feilrapport til utvikleren
391
    av den orginale kildekoden som gav opphav til Debian-pakken, skal
392
    dette lagres i feilrapportsystemet som følger:</p>
393 394

  <p>
395 396
    Pass på at <code>Til</code>-feltet på meldingen kun har
    adressen(e) til forfatteren(e). Legg både personen som
397 398 399 400 401 402
    rapporterte feilen, 
    <var>nnn</var><code>-forwarded@bugs.debian.org</code>,
    og <var>nnn</var><code>@bugs.debian.org</code> i
    <code>Cc</code>-feltet.</p>

  <p>
403 404
    Be forfatteren om å bevare <code>Cc</code>-feltet til
    <var>nnn</var><code>-forwarded@bugs</code> når de svarer slik at
405 406
    feilrapportsystemet lagrer svaret deres sammen med den
    opprinnelige rapporten. Disse meldingen er kun lagret, ikke sendt
407 408
    videre; for å sende en melding som normalt, send den til
    <var>nnn</var><code>@bugs.debian.org</code> også.
409 410 411
</p>

  <p>
412 413
    Når feilrapportsystemet får en melding på adressen
    <var>nnn</var><code>-forwarded</code> så vil den merke den
414
    aktuelle feilrapporten med at den har blitt videresendt til
415
    adresse(ne) i<code>Til</code>-feltet på meldingen den får,
416 417 418 419
    med mindre den allerede er merket som videresendt.
  </p>

  <p>
420
    Do kan også endre på <q>forwarded to</q>-informasjonen ved å sende
421 422 423 424
    meldinger til
    <a href="server-control"><code>control@bugs.debian.org</code></a>.
  </p>

425
  <h2><a name="owner">Endre eierskap på feilrapport</a></h2>
426 427
  
  <p>
428
    I tilfeller der personen som er ansvarlig for å fikse en feil 
429
    ikke er en tilegnet utvikler for en assosierte pakken (for 
430 431
    eksempel hvis pakken er utviklet av et lag), så kan det være
    nyttig å rapportere dette i feilrapportsystemet. For å hjelpe
432 433 434
    med dette kan hver feilrapport valgfritt ha en eier.</p>

  <p>
435 436
    Eieren kan bli sett ved å angi en <code>Owner</code>-linje i
    pseudo-hodet når en feilrapport en innsendt (se
437
    <a href="Reporting#pseudoheader">instruksjoner for feilrapportering</a>),
438
    eller ved å bruke <code>owner</code> og <code>noowner</code>-kommandoene
439 440 441 442 443 444 445 446 447
    med <a href="#requestserv">kontrolltjeneren</a>.
  </p>

  <h2><a name="maintincorrect">Feilangitte pakkeutviklere</a></h2>

  <p>
    Hvis den ansvarlige for en pakke er oppgitt feil, er dette
    vanligvis fordi pakkeansvarlig har skiftet nylig, og den nye
    ansvarlige har ikke lastet opp en ny versjon av pakken med endret
448 449 450 451
    <code>Maintainer</code>-felt i kontrollfilen. Dette blir rettet på
    når pakken lastes opp; alternativt kan de arkivansvarlige
    overstyre angitt pakkeansvarlig for en pakke manuelt, særlig gjelder 
    dette dersom det ikke forventes at pakken kommer til å bli lastet 
452 453 454 455 456
    opp snarlig. Kontakt <code>override-change@debian.org</code> for 
    endringer.
  </p>


457
  <h2><a name="requestserv">Gjenåpne, tilegne og endre på feilrapporter</a></h2>
458 459

  <p>
460 461 462 463
    Det er mulig å tilegne feilrapporter til andre pakker, gjenåpne
    rapporter som ikke skulle vært lukket, endre på informasjonen om
    hvor (hvis) feilrapporten er videresendt, endre på alvorlighetsgrad 
    og titler på feilrapporter, sette eierskap, slå sammen og ta 
464
    fra hverandre feilrapporter og angi versjoner av pakker der feilen ble
465
    funnet og i hvilken det er fikset. Dette gjøres ved å sende epost til
466 467 468 469
    <code>control@bugs.debian.org</code>.
  </p>

  <p>
470 471
    <a href="server-control">Formatet på disse meldingene</a> er
    beskrevet i et annet dokument tilgjengelig på WWW, eller i filen
472
    <code>bug-maint-mailcontrol.txt</code>. En ren tekstutgave kan
473
    anskaffes ved å sende <code>help</code> til adressen over.
474 475
  </p>

476
  <h2><a name="subscribe">Abonnere på feilrapporter</a></h2>
477 478
  
  <p>
479 480 481 482
    Feilrapportsystemet tillater også innsendere, utviklere og andre
    interesserte tredjeparter å abonnere på individuelle feilrapporter.
    Denne funksjonen kan bli brukt av de som ønsker å holde et øye med en
    feilrapport, uten å måtte abonnere på en pakke gjennom 
483
    <a href="https://packages.qa.debian.org">PTS</a>.
484 485 486 487 488
    Alle meldinger som er mottatt gjennom <var>nnn</var><code>@bugs.debian.org</code>,
    er sendt til abonnenter.
  </p>

  <p>
489
    Abonnere på en feilrapport kan bli gjort ved å sende en e-post til
490
    <var>nnn</var><code>-subscribe@bugs.debian.org</code>. Tittelen og
491 492 493
    kroppen til e-posten blir ignorert av feilrapportsystemet. Når en melding
    har blitt behandlet vil brukeren få en bekreftelsesmelding som de er
    nødt til å svare på før de får tilsendt meldinger som er relatert til
494 495 496 497
    feilrapporten.
  </p>
  
  <p>
498 499
    Det er også mulig å avslutte et abonnent på en feilrapport.
    For å avslutte abonnentet må man send en e-post til
500
    <var>nnn</var><code>-unsubscribe@bugs.debian.org</code>. Tittelen
501 502 503
    og kroppen på e-posten er igjen ignorert av BTS. Brukerene vil få
    tilsendt en bekreftelse som de må svare på hvis de ønsker å 
    avslutte abonnentet på feilrapporten.
504 505 506 507
  </p>

  <p>
    Som standard vil adressen som blir funnet i <code>Fra</code>-feltet
508 509
    blir abonnenten. Hvis du ønsker å abonnere en annen adresse til en
    feilrapport så må du endre på måten du abonnerer på. Dette tar følgende
510 511 512 513 514
    form:
    <var>nnn</var><code>-subscribe-</code>\
    <var>localpart</var><code>=</code>\
    <var>example.com</var><code>@bugs.debian.org</code>.
    Det eksempelet ville sendt <code>localpart@example.com</code> som en
515 516 517
    abonneringsmelding til feilrapport <var>nnn</var>. Alfakrøll blir endret
    til å være et erlik-tegn (<code>=</code>). På samme måte tar en avslutning
    på abonnentet form <var>nnn</var><code>-unsubscribe-</code><var>localpart</var>\
518 519 520 521 522
    <code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
    I begge tilfeller vil tittelen og kroppen av e-posten bli videresendt til e-postadressen
    angitt for bekreftelse.
  </p>

523
  <h2><a name="subjectscan">Mer eller mindre avlegs tittelfelt-søk</a></h2>
524 525 526 527 528

  <p>
    Meldinger som kommer til <code>submit</code> eller
    <code>bugs</code> og hvis tittelfelt starter med
    <code>Bug#</code><var>nnn</var> blir behandlet som om de hadde
529 530 531
    blitt sendt til <var>nnn</var><code>@bugs</code>. Dette er både
    av hensyn til bakoverkompatibilitet og for å hindre at
    oppfølginger på feilrapporter havner som nye feilrapporter ved en
532 533 534 535
    feil (f.eks at noen har brukt svar til alle).</p>
  
  <p>
    Meldinger sendt til <code>maintonly</code>, <code>done</code>,
536 537
    <code>quiet</code> og <code>forwarded</code> behandles på en
    tilsvarende måte.</p>
538 539 540 541

  <p>
    Meldinger som kommer til <code>forwarded</code> og
    <code>done</code> &mdash; uten feilrapportnummer i adressen &mdash;
542
    eller tittelfeltet blir lagret under <q>junk</q> (søppel) og bevart i noen
543 544 545 546 547 548
    uker, men ellers ignorert.</p>


  <h2><a name="x-debian-pr">Avlegs <code>X-Debian-PR: quiet</code>-egenskap</A></h2>

  <p>
549 550 551
    Tidligere kunne man unngå at feilrapportsystemet videresendte
    innkommende meldinger til <code>debian-bugs</code> ved å legge til
    en <code>X-Debian-PR: quiet</code>-linje i hodet på eposten.</p>
552 553

  <p>
554
    Denne linjen blir nå ignorert. Send i stedet meldingen til
555 556 557 558 559 560 561 562 563 564 565 566 567 568 569
    <code>quiet</code> eller <var>nnn</var><code>-quiet</code> (eller
    <code>maintonly</code> eller
    <var>nnn</var><code>-maintonly</code>).</p>

  <hr />
  
#use "otherpages.inc"

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

# Local variables:
# mode: sgml
# sgml-indent-data:t
# sgml-doctype:"../.doctype"
# End: