Bemærk: Originalen er nyere end denne oversættelse.

Oplysninger om fejlsporingssystemet til pakkevedligeholdere og fejlsøgere

Det første der sker er at en bruger indsender en fejlrapport per e-mail til [email protected], som skal indeholde en Package-linje (se Vejledning i fejlrapportering for flere oplysninger). Fejlrapporten tildeles dernæst et nummer, der sendes retur til brugeren som kvittering, og siden videresendes til debian-bugs-dist. Hvis Package-linjen indeholder en pakke, der har en kendt vedligeholder, bliver der også sendt en kopi til vedkommende.

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

Lukning af fejlrapport

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.

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 forældreløs 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.

Fejlrapporter lukkes ved at sende en e-mail til nnn[email protected]. Meddelelsens krop skal indeholde en forklaring på hvordan fejlen blev rettet.

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 nnn[email protected] i stedet for nnn@bugs.debian.org (nnn-close findes også som alias for nnn-done).

Hvor det er relevant, bedes man også også tilføje en Version-linje i pseudo-headeren i meddelelsen, når en fejl lukkes, så fejlsporingssystemet ved hvilken udgave af pakken, der indeholder fejlrettelsen.

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

Opfølgningsmeddelelser

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

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

Anvend ikke svar til alle modtagere eller opfølgning 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 [email protected].

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

For flere oplysninger om headerlinjer til undertrykkelse af ACK-meddelelser og hvordan man sender kopier ved hjælp af fejlsporingssystemet, se vejledningen om hvordan man rapporterer fejl.

Alvorsgrader

Systemet gemmer en alvorsgrad sammen med hver fejlrapport. Denne sættes som standard til normal, men kan ændres, enten ved at tilføje en Severity-linje i pseudo-brevhovedet når fejlen rapporteres (se vejledning i at rapportere fejl, eller ved at anvende kontrolserverens severity-kommando.

Alvorsgraderne er:

critical (kritisk)
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.
grave (graverende)
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.
serious (alvorlig)
er en alvorlig overtrædelse af Debians retningslinjer (generelt vil det sige at den bryder et skal- eller krav-direktiv), eller den gør efter den pakkeansvarliges eller udgivelsesansvarliges mening pakken uegnet til udgivelse.
important (vigtig)
en fejl der i større grad påvirker pakkens anvendelighed, uden at gøre den helt uanvendelig for alle.
normal (normal)
standardværdi, gælder de fleste fejl.
minor (mindre)
et problem der ikke påvirker pakkens anvendelighed, og som formentlig er nemt at rette.
wishlist (ønskeliste)
efterspørgsel af ny funktionalitet, og også fejl der er meget vanskellige at rette på grund af større udformningsovervejelser.

Visse alvorsgrader anses for at være kritiske nok til at stoppe en udgivelse (release-critical), hvilket betyder at sådanne fejl vil afgøre om pakken kan udgives eller ej med den stabile udgave af Debian. For tiden disse critical (kritisk), grave (graverende) samt serious (alvorlig). For fuldstændige og kanoniske regler om hvilket problemer der fortjener disse alvorsgrader, se listen over udgivelseskritiske problemer i den næste udgivelse.

Mærker på fejlrapporter

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.

Markeringer kan sættes ved at medsende en Tags-linje i pseudohovedet når fejlrapporten indsendes (se vejledning i fejlrapportering), eller ved at anvende kommandoen tags via kontrolserveren. Adskil flere mærker med komma, mellemrumstegn eller begge.

De aktuelle fejlrapporteringsmarkeringer er: patch, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore . Her følger detaljerede oplysninger om dem:

patch
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.
wontfix (retter ikke)
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.
moreinfo (flere oplysninger)
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 Det virker ikke. Hvad er det der ikke virker?
unreproducible (kan ikke genskabes)
Denne fejl kan ikke genskabes på vedligeholderens system. Bistand fra trediepart er nødvendig for at kunne give en diagnose på årsagen til problemet.
help (hjælp)
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 newcomer (nybegynder).
newcomer (nybegynder)
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.
pending (i gang)
Der er fundet en løsning på fejlen og den vil snart blive uploadet.
fixed (rettet)
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 fixed-alvorsgrad.
security (sikkerhed)
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 (denial of service) som bør rettes, osv.). De fleste sikkerhedsfejl bør også have alvorsgraden critical eller grave.
upstream (opstrøm)
Denne fejl vedrører opstrømsdelen af pakken.
confirmed
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.)
fixed-upstream
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).
fixed-in-experimental
Fejlen er rettet i pakken i den eksperimentelle distribution, men endnu ikke i den ustabile distribution.
d-i
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.
ipv6
Denne fejl påvirker understøttelse af Internet Protocol version 6.
lfs
Denne fejl påvirker understøttelse af store filer (over 2 gigabyte).
l10n
Denne fejl er relevant ved lokaltilpasning af pakken.
a11y
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.
ftbfs
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 serious (udgivelseskritisk) i sådanne situationer.
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
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.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
Denne udgivelseskritiske fejl skal ignoreres hvad angår udgivelse af den specifikke udgivelse. Disse mærker bør kun anvendes af releasemanager(s); opsæt den ikke selv uden at de eksplicit har godkendt det.

Nogle oplysninger om distributionsspecifikke mærker: -ignore-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 findes ikke i nogen udgivelse, hvis tilsvarende udgivelsesmærker ikke er opsat, såfremt et eller flere udgivelsesmærker er opsat; ellers gælder de almindelige fundet-/rettet-regler.]

Udgivelsesmærker bør ikke 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 protected]) eller udgivelsesholdet for at blive rådgivet.

Angive at du har videresendt en fejlrapport

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

Sørg for at Til-feltet i din e-mail forfatteren kun indeholder forfatter(nes) adresse(r), indsæt både adressen på vedkommende som rapporterede fejlen, og nnn[email protected] og nnn@bugs.debian.org i CC-feltet.

Bed forfatteren om at beholde CC til nnn[email protected] 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 nnn@bugs.debian.org.

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

Du kan også ændre på forwarded to-oplysningen ved at sende meddelelsen til [email protected].

Ændring af en fejls ejer

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.

Ejeren kan registreres ved at tilføje en Owner-linje (ejer) i pseudoheaderen når fejlen indsendes (se vejledning i rapportering af fejl) eller ved at kommandoerne owner (ejer) og noowner (ingen ejer) med kontrolforespørgselsserveren.

Fejlagtigt angiven pakkevedligeholder

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 Maintainer-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 [email protected] vedrørende ændringer til filen override.

Genåbne, omadressere og manipulere fejlrappoter

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 [email protected].

Formatet på disse kontrolmeddelelser er beskrevet i et andet webdokument og i filen bug-maint-mailcontrol.txt. En udgave i ren tekst kan leveres ved at sende en e-mail med ordet help til serveren på adressen overfor.

Abonnement på fejl

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 Debian Package Tracker. Alle meddelelser der modtages på nnn@bugs.debian.org, sendes til dem, der har tegnet abonnement.

Tegnelse af abonnement kan gøres ved at sende en e-mail til nnn[email protected]. 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.

Det er også muligt at ophæve abonnementet på en fejl. Abonnementsophævelse sker ved at sende en e-mail til nnn[email protected]. 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.

Som standard bliver der tegnet abonnement til den adresse, som findes i headerfeltet From. Ø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: nnn-subscribe-lokal-del=example.com@bugs.debian.org. I eksemplet vil der blive sendt en tegnelsesmeddelelse til [email protected] vedrørende fejlen nnn. @-tegnet skal indkapsles ved at ændre det til et =-tegn. På lignende måde ophæves et abonnement: nnn-unsubscribe-lokal-del=example.com@bugs.debian.org. I begge tilfælde vil e-mail'ens emne og krop blive videresendt til e-mail-adressen i forespørgslen til bekræftelse.

Mere eller mindre forældet søgning i emnelinjen

Meddelelser som ankommer til submit eller bugs hvis emne begynder med Bug#nnn vil blive behandlet som de er sendt til nnn@bugs.debian.org. 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 submit (for eksempel ved at svare til alle modtagere).

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

Meddelelser som ankommer til forwarded og done – det vil sige uden et fejlrapportnummer i adressen - og uden et fejlnummer i emnelinjen, vil blive arkiveret under affald (junk) i nogle uger, men vil ellers blive ignoreret.

Forældet X-Debian-PR: quiet-funktion

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

Denne linje bliver nu ignoreret. Send i stedet din meddelelse til quiet eller nnn-quiet (eller maintonly eller nnn-maintonly).

Andre sider i fejlrapporteringssystemet:

Debian BTS administrators <[email protected]>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.