path: root/danish/Bugs/Developer.wml

#use wml::debian::template title="Debians fejlrapporteringssystem – oplysninger til udviklere" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="40a57e26c62893be7c80d82f1772999f68d51179"
<h1>Oplysninger om fejlsporingssystemet til pakkevedligeholdere og fejlsøgere</h1>

<p>Det første der sker er at en bruger indsender en fejlrapport per e-mail til
<code>submit@bugs.debian.org</code>, som skal indeholde en 
<code>Package</code>-linje (se <a href="Reporting">Vejledning i 
fejlrapportering</a> for flere oplysninger). Fejlrapporten tildeles dernæst et 
nummer, der sendes retur til brugeren som kvittering, og siden videresendes til 
<code>debian-bugs-dist</code>.  Hvis <code>Package</code>-linjen indeholder en 
pakke, der har en kendt vedligeholder, bliver der også sendt en kopi til 
vedkommende.</p>

<p><code>Emne</code>-linjen får tilføjet teksten 
<code>Bug#</code><var>nnn</var><code>:</code>, og <code>Reply-To</code> 
opsættes så den indeholder både fejlrapportens afsender og 
<var>nnn</var><code>@bugs.debian.org</code>.</p>

<ul class="toc">
    <li><a href="#closing">Lukning af fejlrapport</a></li>
    <li><a href="#followup">Opfølgende meddelelser</a></li>
    <li><a href="#severities">Alvorsgrader</a></li>
    <li><a href="#tags">Mærker i fejlrapporter</a></li>
    <li><a href="#forward">Angiv at du har videresendt en fejlrapport</a></li>
    <li><a href="#owner">Ændring af en fejls ejer</a></li>
    <li><a href="#maintincorrect">Fejlagtigt angiven pakkevedligeholder</a></li>
    <li><a href="#requestserv">Genåbne, omadressere og manipulere 
	fejlrapporter</a></li>
    <li><a href="#subscribe">Abonnement på fejl</a></li>
    <li><a href="#subjectscan">Mere eller mindre forældet søgning i 
	emnelinje</a></li>
    <li><a href="#x-debian-pr">Forældet 
	<code>X-Debian-PR: quiet</code>-funktion</a></li>
</ul>


<h2 id="closing">Lukning af fejlrapport</h2>

<p>Fejlrapporter i Debian bør lukkes når problemerne er løst.  Problemer i 
pakker kan kun anses for løste når en pakke indeholdende fejlrettelsen er
blevet optaget i Debians arkiv.</p>

<p>Normalt er de eneste personer der bør lukke en fejlrapport, den der indsendte 
fejlrapporten og den ansvarlige for pakken som fejlrapporten blev indsendt imod.  
Der findes undtagelser fra reglen, for eksempel fejl som indsendes mod ukendte 
pakker eller visse generelle pseudopakker.  En fejl kan også lukkes af enhver 
bidragyder, hvis fejlen gælder en <strong>forældreløs</strong> pakke eller hvis 
vedligeholderen af pakken ikke har fået lukket fejlen.  Det er meget vigtigt at 
nævne i hvilken version, fejlen blev rettet.  Hvis du er usikker, så luk ikke 
fejlrapporter uden først at have bedt om råd på postlisten debian-devel.</p>

<p>Fejlrapporter lukkes ved at sende en e-mail til 
<var>nnn</var><code>-done@bugs.debian.org</code>. Meddelelsens krop skal 
indeholde en forklaring på hvordan fejlen blev rettet.</p>

<p>Med de e-mails som kommer fra fejlrapporteringssystemet er alt hvad du 
behøver at gøre for at lukke fejlrapporten, at skrive et svar i dit postprogram
og redigere modtagerfeltet så der står 
<var>nnn</var><code>-done@bugs.debian.org</code> i stedet for
<var>nnn</var><code>@bugs.debian.org</code>
(<var>nnn</var><code>-close</code> findes også som alias for
<var>nnn</var><code>-done</code>).</p>

<p>Hvor det er relevant, bedes man også også tilføje en 
<code>Version</code>-linje i <a href="Reporting#pseudoheader">\
pseudo-headeren</a> i meddelelsen, når en fejl lukkes, så fejlsporingssystemet
ved hvilken udgave af pakken, der indeholder fejlrettelsen.</p>

<p>Personen som lukker fejlrapporten, personen der oprindeligt rapporterede 
den, såvel som postlisten <code>debian-bugs-closed</code> vil alle få en
bekræftelse på ændringen rapportens status.  Fejlrapportens afsender og
postlisten vil også modtage indholdet af meddelelser der sendes til 
<var>nnn</var><code>-done</code>.</p>


<h2 id="followup">Opfølgningsmeddelelser</h2>

<p>Fejlrapporteringssystemet indeholder afsenderens adresse og adressen på
fejlrapporten (<var>nnn</var><code>@bugs.debian.org</code>) i 
<code>Reply-To</code>-feltet når rapporten videresendes.  Bemærk at dette er to 
forskellige adresser.</p>

<p>Hvis en udvikler vil svare på en fejlrapport, er det nok at svare på 
meddelelsen og respektere <code>Reply-To</code>-feltets indhold.  Dette vil 
<strong>ikke</strong> lukke fejlrapporten.</p>

<p>Anvend <em>ikke</em> <q>svar til alle modtagere</q> eller <q>opfølgning</q> i 
dit mailprogram, med mindre du har i sinde at redigere modtagerlisten betydeligt.  
I særdeleshed skal du sørge for ikke at sende opfølgningsmeddelelser til 
<code>submit@bugs.debian.org</code>.</p>

<p>Meddelelser kan sendes til følgende adresser, for at blive registreret i 
fejlsporingssystemet:</p>

<ul>
    <li>
	<var>nnn</var><code>@bugs.debian.org</code> — sådanne meddelelser sendes
	også til pakkevedligeholderen og videresendes til 
	<code>debian-bugs-dist</code>, men <strong>ikke</strong> til 
	indsenderen;
    </li>
    <li>
	<var>nnn</var><code>-submitter@bugs.debian.org</code> — disse sendes 
	også til indsenderen og videresendes til <code>debian-bugs-dist</code>,
	men <strong>ikke</strong> til pakkevedligeholderen;
    </li>
    <li>
	<var>nnn</var><code>-maintonly@bugs.debian.org</code> — disse sendes kun
	til pakkevedligeholderen, <strong>ikke</strong> til indsenderen eller
	<code>debian-bugs-dist</code>;
    </li>
    <li>
	<var>nnn</var><code>-quiet@bugs.debian.org</code> — disse registreres 
	kun i fejlsporingssystemet (som det er tilfældet med alle ovennævnte),
	de sendes <strong>ikke</strong> til nogen anden adresse.
    </li>
</ul>

<p>For flere oplysninger om headerlinjer til undertrykkelse af ACK-meddelelser
og hvordan man sender kopier ved hjælp af fejlsporingssystemet, se 	
<a href="Reporting">vejledningen om hvordan man rapporterer fejl</a>.</p>


<h2 id="severities">Alvorsgrader</h2>

<p>Systemet gemmer en <q>alvorsgrad</q> sammen med hver fejlrapport.  Denne 
sættes som standard til <code>normal</code>, men kan ændres, enten ved at 
tilføje en <code>Severity</code>-linje i <q>pseudo-brevhovedet</q> når fejlen 
rapporteres (se <a href="Reporting#pseudoheader">vejledning i at rapportere 
fejl</a>, eller ved at anvende <a href="#requestserv">kontrolserverens</a> 
<code>severity</code>-kommando.</p>

<p>Alvorsgraderne er:</p>

<dl>
<dt><code>critical</code> (kritisk)</dt>
<dd>får uafhængige programmer i systemet (eller hele systemet) til ikke længere
at fungere, kan forsage kritisk datatab, eller der introduceres et 
sikkerhedshul i systemet ved at installere pakken.</dd>

<dt><code>grave</code> (graverende)</dt>
<dd>fejlen gør den pågældende pakke helt eller mestendels uanvendelig, forsager
datatab, eller introducerer et sikkerhedshul der giver adgang til kontoerne 
tilhørende dem der anvender pakken.</dd>

<dt><code>serious</code> (alvorlig)</dt>
<dd>er en <a href="$(DOC)/debian-policy/">alvorlig overtrædelse af Debians 
retningslinjer</a> (generelt vil det sige at den bryder et <q>skal</q>- eller 
<q>krav</q>-direktiv), eller den gør efter den pakkeansvarliges eller 
udgivelsesansvarliges mening pakken uegnet til udgivelse.</dd>

<dt><code>important</code> (vigtig)</dt>
<dd>en fejl der i større grad påvirker pakkens anvendelighed, uden at gøre den
helt uanvendelig for alle.</dd>

<dt><code>normal</code> (normal)</dt>
<dd>standardværdi, gælder de fleste fejl.</dd>

<dt><code>minor</code> (mindre)</dt>
<dd>et problem der ikke påvirker pakkens anvendelighed, og som formentlig er 
nemt at rette.</dd>

<dt><code>wishlist</code> (ønskeliste)</dt>
<dd>efterspørgsel af ny funktionalitet, og også fejl der er meget vanskellige
at rette på grund af større udformningsovervejelser.</dd>

</dl>

<p>Visse alvorsgrader anses for at være 
<em><a href="https://bugs.debian.org/release-critical/">kritiske nok til at 
stoppe en udgivelse</a></em> (<q>release-critical</q>), hvilket betyder at 
sådanne fejl vil afgøre om pakken kan udgives eller ej med den stabile udgave 
af Debian.  For tiden disse <strong lang=en>critical</strong> (kritisk),
<strong lang=en>grave</strong> (graverende) samt 
<strong lang=en>serious</strong> (alvorlig).
For fuldstændige og kanoniske regler om hvilket problemer der fortjener 
disse alvorsgrader, se listen over 
<a href="https://release.debian.org/testing/rc_policy.txt">udgivelseskritiske 
problemer i den næste udgivelse</a>.</p>


<h2 id="tags">Mærker på fejlrapporter</h2>

<p>Enhver fejlrapport kan have ingen eller flere givne markeringer.  Disse 
markeringer vises i listen over fejlrapporter når du kigger på en pakkes side, 
og når du kigger på den komplette fejlrapportlog.</p>

<p>Markeringer kan sættes ved at medsende en <code>Tags</code>-linje i 
pseudohovedet når fejlrapporten indsendes (se
<a href="Reporting#pseudoheader">vejledning i fejlrapportering</a>),
eller ved at anvende kommandoen <code>tags</code> via
<a href="#requestserv">kontrolserveren</a>. Adskil flere mærker med komma,
mellemrumstegn eller begge.</p>

<p>De aktuelle fejlrapporteringsmarkeringer er: <bts_tags>.  Her følger 
detaljerede oplysninger om dem:</p>

<dl>

<dt><code>patch</code></dt>
  <dd>En patch (rettelse) eller en anden simpel måde at rette fejlen på, er 
  indeholdt i fejlrapportloggen.  Hvis der er tale om en patch, men hvis den 
  ikke helt løser fejlen eller giver andre problemer, bør denne markering ikke
  anvendes.</dd>

<dt><code>wontfix</code> (retter ikke)</dt>
  <dd>Denne fejl vil ikke blive rettet.
  Dette kan skyldes at det er et valg mellem to forskellige måder at gøre det 
  på, og pakkens vedligeholder og brugeren foretrækker forskellige måder at 
  gøre tingene på, måske på grund af at en ændring af hvordan programmet
  fungerer, vil give andre, værre, problemer for andre brugere, eller måske af
  andre grunde.</dd>

<dt><code>moreinfo</code> (flere oplysninger)</dt>
  <dd>Denne fejl kan ikke behandles før der er modtaget flere oplysninger fra
  afsenderen.  Fejlrapporten vil blive lukket hvis afsenderen ikke giver flere
  oplysninger indenfor rimelig tid (nogle måneder).  Dette er til fejl af typen
  <q>Det virker ikke</q>. Hvad er det der ikke virker?</dd>

<dt><code>unreproducible</code> (kan ikke genskabes)</dt>
  <dd>Denne fejl kan ikke genskabes på vedligeholderens system.  Bistand fra
  trediepart er nødvendig for at kunne give en diagnose på årsagen til 
  problemet.</dd>

<dt><code>help</code> (hjælp)</dt>
  <dd>Vedligeholderen beder om hjælp til at rette fejlen.  Enten har 
  vedligehodleren ikke de nødvendige færdigheder til at rette fejlen og ønsker 
  at samarbejde derom, eller vedkommende har for meget at se til og ønsker at 
  uddelegere opgaven.  Fejlen er måske ikke egnet til nye bidragydere, med 
  mindre den også er markeret som <code>newcomer</code> (nybegynder).</dd>

<dt><code>newcomer</code> (nybegynder)</dt>
  <dd>Fejlen har en kendt løsning, men vedligeholden beder en anden om at 
  implementere det.  Det er en ideel opgave til nye bidragydere, der ønsker at 
  blive involveret i Debian, eller som ønsker at forbedre deres 
  færdigheder.</dd>

<dt><code>pending</code> (i gang)</dt>
  <dd>Der er fundet en løsning på fejlen og den vil snart blive uploadet.</dd>

<dt><code>fixed</code> (rettet)</dt>
  <dd>Fejlen er rettet eller der er fundet en måde at omgå problemet på (for
  eksempel via en udgave indsendt af en anden vedligeholderen), men der er 
  stadig et problem som skal løses.  Denne markering erstatter den gamle 
  <q>fixed</q>-alvorsgrad.</dd>

<dt><code>security</code> (sikkerhed)</dt>
  <dd>Fejlen beskriver et sikkerhedsproblem i en pakke (for eksempel forkert
  afhængig giver adgang til data som ikke skulle være tilgængelige; 
  bufferoverløb som giver folk mulighed for at kontrollere systemet på måder 
  der ikke burde være mulige; lammelsesangreb (<q>denial of service</q>) som
  bør rettes, osv.).  De fleste sikkerhedsfejl bør også have alvorsgraden
  <q>critical</q> eller <q>grave</q>.</dd>

<dt><code>upstream</code> (opstrøm)</dt>
  <dd>Denne fejl vedrører opstrømsdelen af pakken.</dd>

<dt><code>confirmed</code></dt>
  <dd>Vedligeholderen har kigget på, forstår og er generelt enig i, at det er
  en fejl, men har endnu ikke rettet den.  (Det er frivilligt at anvende denne
  markering; den er primært beregnet til vedligeholdere der er nødt til at 
  holde styr på et stort antal åbne fejl.)</dd>

<dt><code>fixed-upstream</code></dt>
  <dd>Fejlen er rettet af opstrømsvedligeholderen, men er endnu ikke i pakken
  (af en eller anden grund, måske er det for kompliceret at tilbageføre 
  ændringen eller for lille til, at det er besværet værd).</dd>

<dt><code>fixed-in-experimental</code></dt>
  <dd>Fejlen er rettet i pakken i den eksperimentelle distribution, men endnu
  ikke i den ustabile distribution.</dd>

<dt><code>d-i</code></dt>
  <dd>Denne fejl er relevant ved udviklingen af debian-installer.  Det forventes
  at markeringen vil blive anvendt, når fejlen påvirker udviklingen af 
  installeringsprogrammet, men ikke er indsendt mod en pakke, som direkte er en
  del af selve installeringsprogrammet.</dd>

<dt><code>ipv6</code></dt>
  <dd>Denne fejl påvirker understøttelse af Internet Protocol version 6.</dd>

<dt><code>lfs</code></dt>
  <dd>Denne fejl påvirker understøttelse af store filer (over 2 gigabyte).</dd>

<dt><code>l10n</code></dt>
  <dd>Denne fejl er relevant ved lokaltilpasning af pakken.</dd>

<dt><code>a11y</code></dt>
  <dd>Denne fejl påvirker tilgængelighed for brugere med handicap.  Den påvirker 
  især brugbarhed for personer, der er afhængige af hjælpemiddels- (eller 
  tilpasnings-)teknologi for at benytte systemet/pakken.</dd>

<dt><code>ftbfs</code></dt>
  <dd>Pakken kan ikke opbygges fra kildekoden.  Hvis fejlen er tildelt en 
  binær pakke, kan de påvirkede kildekodepakke ikke opbygges.  Markeringen 
  gælder ikke-standard-buildmiljøer (fx ved hjælp af Build-Depends fra 
  experimental), men alvorsgraden bør være under <q>serious</q> 
  (udgivelseskritisk) i sådanne situationer.</dd>

<dt><bts_release_tags></dt>
  <dd>Disse er udgivelsestags, der har to virkemåder.  Ved opsætning på en fejl,
  kun fejlen kun påvirke den specifikke udgivelse (selv om den også kan påvirke 
  andre udgivelser, hvis andre udgivelsestags er opsat), men ellers gælder de 
  almindelige regler for fejlbehæftet/rettet/ikke fundet.  Fejlen bør ikke 
  arkiveres før den er rettet i udgivelsen.</dd>

<dt><bts_release_ignore_tags></dt>
  <dd>Denne udgivelseskritiske fejl skal ignoreres hvad angår udgivelse af den 
  specifikke udgivelse.  <strong>Disse mærker bør kun anvendes af 
  releasemanager(s); opsæt den ikke selv uden at de eksplicit har godkendt 
  det.</strong></dd>

</dl>

<p>Nogle oplysninger om distributionsspecifikke mærker:  
<q>-ignore</q>-mærkerne ignorerer fejlen med det formål at teste udbredelse.  
Udgivelsesmærkerne indikerer at den pågældende fejl ikke skal arkiveres før den 
er rettet i de angivne udgivelser.  Udgivelsesmærkerne indikerer også, at fejlen 
kun anses for at gælde i de angivne udgivelser.  [Med andre ord, fejlen 
<strong>findes ikke</strong> i nogen udgivelse, hvis tilsvarende 
udgivelsesmærker <strong>ikke</strong> er opsat, såfremt et eller flere 
udgivelsesmærker er opsat; ellers gælder de almindelige 
fundet-/rettet-regler.]</p>

<p>Udgivelsesmærker bør <strong>ikke</strong> anvendes hvis den korrekte 
versionering af fejlen ellers vil give den ønskede virkning, da de kræver 
manuel tilføjelse og fjernelse.  Hvis du er usikker på, hvorvidt et 
udgivelsesmærke er krævet, så kontakt på engelsk Debian BTS Administrators 
(<email "owner@bugs.debian.org">) eller udgivelsesholdet for at blive 
rådgivet.</p>


<h2 id="forward">Angive at du har videresendt en fejlrapport</h2>

<p>Når en udvikler videresender en fejlrapport til udvikleren af 
<q>opstrøms</q>-kildekodepakken, som Debians pakker er baseret på, skal det 
noteres i fejlrapporteringssystemet som følger:</p>

<p>Sørg for at <code>Til</code>-feltet i din e-mail forfatteren kun indeholder
forfatter(nes) adresse(r), indsæt både adressen på vedkommende som rapporterede
fejlen, og <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>Bed forfatteren om at beholde <code>CC</code> til 
<var>nnn</var><code>-forwarded@bugs.debian.org</code> når vedkommende svarer, 
så fejlrapporteringssystemet arkiverer svaret sammen med den oprindelige 
rapport.  Disse meddelelser gemmes kun og videresendes ikke; for at sende en
meddelelse som normalt, skal de også sendes til 
<var>nnn</var><code>@bugs.debian.org</code>.</p>

<p>Når fejlrapporteringssystemet modtager en meddelelse til 
<var>nnn</var><code>-forwarded</code>, markerer det den relevante fejlrapport
som videresendt til adresse(rne) i e-mailens <code>Til</code>-felt, hvis
fejlen ikke allerede er markeret som videresendt.</p>

<p>Du kan også ændre på <q>forwarded to</q>-oplysningen ved at sende meddelelsen 
til <a href="server-control"><code>control@bugs.debian.org</code></a>.</p>


<h2><a name="owner">Ændring af en fejls ejer</a></h2>	

<p>I tilfælde hvor den ansvarlig for rettelsen af en fejl ikke er den angivne
vedligeholder for de tilknyttede pakker (for eksempel når pakken vedligeholdes
af et hold), det det være nyttigt at registrere denne oplysning i
fejlsporingssystemet.  Som en hjælp til dette, kan man ved alle fejl valgfrit
have en ejer.</p>

<p>Ejeren kan registreres ved at tilføje en <code>Owner</code>-linje (ejer) i
pseudoheaderen når fejlen indsendes (se <a href="Reporting#pseudoheader">\
vejledning i rapportering af fejl</a>) eller ved at kommandoerne 
<code>owner</code> (ejer) og <code>noowner</code> (ingen ejer) med
<a href="#requestserv">kontrolforespørgselsserveren</a>.</p>


<h2 id="maintincorrect">Fejlagtigt angiven pakkevedligeholder</h2>

<p>Hvis en forkert person er angivet som en pakkes vedligeholder, er det 
normalt fordi der nyligt er kommet en ny vedligeholder, og den nye 
vedligeholder har endnu ikke overført en ny version af pakken med et ændret
<code>Maintainer</code>-kontrolfelt.  Dette ændres når pakken overføres, 
alternativt kan vedligeholderen manuelt ændre i listen over vedligeholdere, for
eksempel hvis en ny version af pakken ikke forventes at være nødvendig indenfor
den nærmeste fremtid. Kontakt <code>override-change@debian.org</code> 
vedrørende ændringer til filen override.</p>


<h2 id="requestserv">Genåbne, omadressere og manipulere fejlrappoter</h2>

<p>Det er muligt at omadressere fejlrapporter til andre pakker, at genåbne 
fejlagtigt lukkede rapporter, at ændre oplysningerne om hvortil (om noget) 
rapporten er blevet videresendt, at ændre alvorsgrader og overskrifter på 
rapporter, samle og splitte fejlrapporter, og til at registrere pakkeversioner
hvor fejl blev fundet og hvor de blev rettet.  Dette gøres ved at sende en
e-mail til <code>control@bugs.debian.org</code>.</p>

<p><a href="server-control">Formatet på disse kontrolmeddelelser</a> er 
beskrevet i et andet webdokument og i filen 
<code>bug-maint-mailcontrol.txt</code>.  En udgave i ren tekst kan leveres ved
at sende en e-mail med ordet <code>help</code> til serveren på adressen 
overfor.</p>


<h2><a name="subscribe">Abonnement på fejl</a></h2>

<p>Fejlsporingssystemet gør det også muligt for indsendere af fejl, udviklere
og andre interesserede tredjeparter at tegne abonnement på individuelle fejl.
Denne funktion kan anvendes af dem, der ønsker at holde øje med en fejl, uden
at skulle tegne abonnement på pakken gennem 
<a href="https://tracker.debian.org/">Debian Package Tracker</a>.  Alle 
meddelelser der modtages på <var>nnn</var><code>@bugs.debian.org</code>, 
sendes til dem, der har tegnet abonnement.</p>

<p>Tegnelse af abonnement kan gøres ved at sende en e-mail til 
<var>nnn</var><code>-subscribe@bugs.debian.org</code>.  E-mail'ens emne og
krop ignoreres af BTS.  Når meddelelesen er blevet behandlet, sendes der en
bekræftelsesmeddelelse til brugeren, som vedkommende skal svare på før e-mail
vedrørende den pågældende fejl bliver sendt til brugeren.</p>

<p>Det er også muligt at ophæve abonnementet på en fejl.  Abonnementsophævelse
sker ved at sende en e-mail til 
<var>nnn</var><code>-unsubscribe@bugs.debian.org</code>.  E-mail'ens emne og 
krop ignoreres igen af BTS.  Der sendes bekræftelsesmeddelelse til brugeren, 
som vedkommende skal svare på for abonnementet kan blive ophævet.</p>

<p>Som standard bliver der tegnet abonnement til den adresse, som findes i 
headerfeltet <code>From</code>.  Ønsker du at en anden adresse skal have 
tegnet abonnement, er du nødt til at tilføje adresse i tegnelsesmeddelelsen.
Dette sker på følgende måde: 
<var>nnn</var><code>-subscribe-</code><var>lokal-del</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
I eksemplet vil der blive sendt en tegnelsesmeddelelse til 
<code>lokal-del@example.com</code> vedrørende fejlen <var>nnn</var>. 
<code>@</code>-tegnet skal indkapsles ved at ændre det til et 
<code>=</code>-tegn.  På lignende måde ophæves et abonnement:
<var>nnn</var><code>-unsubscribe-</code><var>lokal-del</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
I begge tilfælde vil e-mail'ens emne og krop blive videresendt til 
e-mail-adressen i forespørgslen til bekræftelse.</p>


<h2 id="subjectscan">Mere eller mindre forældet søgning i emnelinjen</h2>

<p>Meddelelser som ankommer til <code>submit</code> eller <code>bugs</code> 
hvis emne begynder med <code>Bug#</code><var>nnn</var> vil blive behandlet som
de er sendt til <var>nnn</var><code>@bugs.debian.org</code>.  Dette er både på 
grund af bagudkompabilitetshensyn med e-mails videresendt fra de gamle adresser, 
og for at opfange mails der fejlagtigt sendes til <code>submit</code> (for 
eksempel ved at svare til alle modtagere).</p>

<p>En lignende funktion findes til <code>maintonly</code>, <code>done</code>, 
<code>quiet</code> og <code>forwarded</code>, som behandler e-mails der 
ankommer med en emnelinje som svarer til at de er sendt til adressen
<var>nnn-hvaddetnuvar</var><code>@bugs.debian.org</code>.</p>

<p>Meddelelser som ankommer til <code>forwarded</code> og <code>done</code> 
&ndash; det vil sige uden et fejlrapportnummer i adressen - og uden et 
fejlnummer i emnelinjen, vil blive arkiveret under <q>affald</q> (<q>junk</q>) 
i nogle uger, men vil ellers blive ignoreret.</p>


<h2 id="x-debian-pr">Forældet <code>X-Debian-PR: quiet</code>-funktion</h2>

<p>Tidligere var det muligt at forhindre at fejlrapporteringssystemet i alle
former for videresendelser modtaget på <code>debian-bugs</code>, ved at tilføje
linjen <code>X-Debian-PR: quiet</code> i brevhovedet.</p>

<p>Denne linje bliver nu ignoreret.  Send i stedet din meddelelse til 
<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"