NB: Originalen er nyere enn denne oversettelsen.

Utviklerinformasjon om feilrapportsystemet

Feilrapporter blir først sendt som en vanlig e-post til [email protected] som må inkludere en Package-linje (se Instruksjoner for feilrapportering for mer informasjon). Rapporten får deretter et nummer, en kvittering blir sendt til innsenderen og rapporten blir videresendt til debian-bugs-dist. Hvis Package-linja inneholder en pakke som har en kjent utvikler, så sendes det en kopi til utvikleren også.

Subject-feltet vil få lagt til Bug#nnn: og Reply-To settes slik at den inkluderer både innsenderen og nnn@bugs.debian.org.

Lukke feilrapporter

Debians feilrapporter skal lukkes når feilen er rettet. Problemer i pakkene kan kun anses som rettet etter at en pakke som innholder rettelsen på feilen er lastet inn i Debian-arkivet.

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. En feil kan også lukkes av hvem som helst. hvis feilen er for en orphaned pakke, en pakke uten vedlikeholder, eller hvis vedlikeholderen av en pakke har glemt å lukke den. Det er veldig viktig å nevne i hvilken versjon feilen ble rettet. Hvis du er i tvil, ikke lukk feilrapporter uten å spørre om råd i e-postlisten debian-devel.

Feilrapporter lukkes ved å sende en e-post til nnn[email protected]. Kroppen av meldingen må inneholde en forklaring av hvordan feilen ble fikset.

Med en e-postene du har mottatt fra feilrapportsystemet er alt du trenger å gjøre for å lukke en feilrapport å svare på meldingen i e-postleseren din, og endre To- eller Til-feltet til nnn[email protected] i stedet for nnn@bugs (nnn-close er et alias for nnn-done).

Der det er anvendelig vennligst angi en Version-linje i pseudo-headeren av din melding når du lukker en feilrapport. Slik vet feilrapportsystemet hvilken utgivelse av pakken som inneholder en rettelse av feilen.

Personen som lukker feilrapporten, den som sendte den inn, og e-postlisten debian-bugs-closed vil hver få en melding om endring av status i feilrapporten. Innsenderen og e-postlisten vil også motta innholdet av meldingen som ble sendt til nnn-done.

Oppfølgingsmeldinger

Feilrapportsystemet vil inkludere innsenderen's adresse og feilrapportsadressen (nnn@bugs.debian.org) i Reply-To-feltet når feilrapporten videresendes til pakkeutvikleren. Merk at disse er to adskilte adresser.

Enhver utvikler som ønsker å svare på en feilmelding kan rett og slett svare på e-posten i samsvar med Reply-To-feltet. Dette vil ikke markere feilrapporten som lukket.

Ikke bruk svar til alle eller followup dersom du ikke har til hensikt å vesentlig redigere på mottakerlisten. Pass spesielt på at du ikke sender oppfølgingsmeldinger til [email protected].

Meldinger kan sendes til følgende adresser for å bli lagret i feilrapportsystemet:

For mer informasjon om linjer til å dempe ACK-meldinger og hvordan sende kopier ved bruk av feilrapportsystemet, se Instruksjoner for feilrapportering.

Alvorlighetsgrader

Feilrapportsystemet lagrer en alvorlighetsgrad sammen med hver feilrapport. Denne settes til normal til vanlig, men kan overstyres, enten ved å ha en Severity-linje i pseudo-hodet på eposten når den sendes inn (se instruksjonene for feilrapportering), eller ved å bruke severity-kommandoen med kontrolltjeneren.

Alvorlighetsgradene er:

critical (kritisk)
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 der pakken installeres.
grave (graverende)
gjør pakken det er snakk om helt eller for det meste ubrukelig, forårsaker datatap eller lager et sikkerhetshull som gir tilgang til kontoene til brukerne som bruker pakken.
serious (alvorlig)
et alvorlig brudd på Debians retningslinjer (det vil si, pakken bryter mot et må eller påkrevd-krav) eller, i følge pakkeutvikleren, gjør pakken uegnet for utgivelse.
important (viktig)
en feil som har gjør at pakken ikke virker skikkelig, uten å gjøre den fullstendig ubrukelig.
normal (vanlig)
standardverdien og den mest vanlige
minor (liten)
et problem som ikke påvirker pakkens nytteverdi, og som sannsynligvis er trivielt å rette.
wishlist (ønske)
for spørsmål om nye funksjoner og feil som er vanskelige å rette på grunn av designvalg.

Visse alvorlighetsgrader anses som utgivelseskritisk, noe som betyr at feilen vil bestemme om pakken blir utgitt sammen med den stabile utgaven av Debian. For tiden er disse gradene critical, grave, og serious. For fullstendige regler om disse alvorlighetsgradene, se listen med utgivelseskritiske feil for neste utgaven.

Merkelapper for feilrapporter

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

Merkelapper kan settes ved å bruk en Tags-linje i pseudo-linjen når feilen meldes inn (se instruksjoner for feilrapportering), eller ved å bruke tags-kommandoen til kontrolltjeneren. Separer flere merkelapper med komma, mellomrom eller begge.

Gjeldende merkelapper 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 .

Nedenfor finner du litt detaljert informasjon om hver merkelapp.

patch (lapp)
En lapp eller en annen enkel prosedyre for å rette feilen er inkludert i feilrapporten. Hvis det er en lapp tilgjengelig, men den ikke retter feilen ordentlig eller forårsaker et annet problem skal ikke denne merkelappen brukes.
wontfix (kommer ikke til å rettes)
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 problemer for andre, eller av andre grunner.
moreinfo (mer informasjon trengs)
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). Denne merkelappen er for feilrapporter av typen Dette virker ikke!. Hva virker ikke?
unreproducible (ikke reproduserbar)
Denne feilen kan ikke reproduseres på utviklerens system. Assistanse fra tredjepart er nødvendig for å diagnostisere problemet.
help (hjelp)
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 newcomer-merkelapper.
newcomer (nybegynnere)
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.
pending (i kø)
En løsning på denne feilen har blitt funnet og en opplasting vil bli gjort snarlig.
fixed (rettet)
Denne feilen er rettet eller jobbet seg rundt (ved en opplasting av pakken av en annen utvikler enn den som er ansvarlig for den, f.eks), men problemet må fremdeles løses av utvikleren. Denne merkelappen erstatter den gamle fixed alvorlighetsgraden.
security (sikkerhet)
Denne rapporten beskriver et sikkerhetsproblem i en pakke (f.eks feil rettigheter som gir tilgang til data som ikke skal være tilgjengelig; bufferoverflyt som kan gi uautorisert tilgang til systemet, etc). De fleste sikkerhetsrelaterte feil bør også ha alvorlighetsgrad critical eller grave.
upstream (oppstrøms)
Denne rapporten gjelder oppstrømsdelen av pakken.
confirmed (bekreftet)
Utvikleren har sett, forstått og generelt sett er enig med at det er en feil, men har ikke fikset det. (Bruk av denne merkelappen er valgfri; den er til hovedsaklig for utviklere som behandler store mengder av åpne feilrapporter.)
fixed-upstream (fikset oppstrøms)
Feilen har blitt fikset hos en utvikler oppstrøms, men er fortsatt ikke inkludert i pakken (for hva enn grunn: kanskje det er altfor komplisert å anvende i en eldre versjon eller altfor liten til å være verdt bryet).
fixed-in-experimental (fikset i eksperimentell)
Feilen har blitt fikset i en pakke hos den eksperimentelle utgaven, men ikke i den ustabile.
d-i
Denne feilen er relevant for utviklingen av debian-installer. Det 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.
ipv6
Denne feilen påvirker Internet Protocol version 6.
lfs
Denne feilen påvirker støtte for store filer (over 2 GB).
l10n
Denne feilen er relevant for lokalisering av pakken.
a11y
Denne feilen er relevant for pakkens tilgjengelighet.
ftbfs
Pakken bygger ikke fra kilde. Hvis feilen er tilordnet en kildepakke, så er det den pakken som ikke bygger. Hvis feilen er tilordnet en binærpakke, så er det den tilhørende kildepakken som ikke bygger. Merkelappen kan brukes for ikke-standard byggemiljø, men da skal alvorlighetsgrad være lavere enn serious.
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
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.
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 utgavelseskritiske feilrapporten skal bli ignorert med målet om å få gi ut den aktuelle utgaven. Denne merkelappen skal kun bli brukt av utgavelsesansvarlig(e); ikke sett denne selv uten eksplisitt autorisasjon fra dem.

Noe informasjon om distribusjonsspesifikke merkelapper: -ignore-merkelappene ignorerer feilen for videre testing. Merkelappene for utgivelse indikerer at aktuelle feilrapporter ikke skal bli arkivert før det har blitt ordnet i settet av utgivelser angitt. Merkelappen for utgivelse skal også indikere at feilrapporten er kun betenkt en feil i det settet med utgivelser angitt (med andre ord så er feilen ikke tilstede i utgivelser hvor merkelappen for utgivelsen ikke er satt i feilrapporten).

Merkelappene for utgivelser burde ikke bli brukt hvis rett angivelse av versjonen til feilrapporten ville utgjort nødvendig effekt, siden de krever manuelle tillegg og fjerning. Hvis du er usikker på om en merkelapp for utgivelser er nødvendig, kontakt Debian sine administratorer for feilrapportsystemet (BTS) ([email protected]) eller utgivelseslaget for råd.

Informere om at du har videresendt en feilrapport

Når en Debian-utvikler videresender en feilrapport til utvikleren av den orginale kildekoden som gav opphav til Debian-pakken, skal dette lagres i feilrapportsystemet som følger:

Pass på at Til-feltet på meldingen kun har adressen(e) til forfatteren(e). Legg både personen som rapporterte feilen, nnn[email protected], og nnn@bugs.debian.org i Cc-feltet.

Be forfatteren om å bevare Cc-feltet til nnn-forwarded@bugs når de svarer slik at feilrapportsystemet lagrer svaret deres sammen med den opprinnelige rapporten. Disse meldingen er kun lagret, ikke sendt videre; for å sende en melding som normalt, send den til nnn@bugs.debian.org også.

Når feilrapportsystemet får en melding på adressen nnn-forwarded så vil den merke den aktuelle feilrapporten med at den har blitt videresendt til adresse(ne) iTil-feltet på meldingen den får, med mindre den allerede er merket som videresendt.

Do kan også endre på forwarded to-informasjonen ved å sende meldinger til [email protected].

Endre eierskap på feilrapport

I tilfeller der personen som er ansvarlig for å fikse en feil ikke er en tilegnet utvikler for en assosierte pakken (for eksempel hvis pakken er utviklet av et lag), så kan det være nyttig å rapportere dette i feilrapportsystemet. For å hjelpe med dette kan hver feilrapport valgfritt ha en eier.

Eieren kan bli sett ved å angi en Owner-linje i pseudo-hodet når en feilrapport en innsendt (se instruksjoner for feilrapportering), eller ved å bruke owner og noowner-kommandoene med kontrolltjeneren.

Feilangitte pakkeutviklere

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 Maintainer-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 opp snarlig. Kontakt [email protected] for endringer.

Gjenåpne, tilegne og endre på feilrapporter

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 fra hverandre feilrapporter og angi versjoner av pakker der feilen ble funnet og i hvilken det er fikset. Dette gjøres ved å sende epost til [email protected].

Formatet på disse meldingene er beskrevet i et annet dokument tilgjengelig på WWW, eller i filen bug-maint-mailcontrol.txt. En ren tekstutgave kan anskaffes ved å sende help til adressen over.

Abonnere på feilrapporter

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 Debian Package Tracker. Alle meldinger som er mottatt gjennom nnn@bugs.debian.org, er sendt til abonnenter.

Abonnere på en feilrapport kan bli gjort ved å sende en e-post til nnn[email protected]. Tittelen og 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 feilrapporten.

Det er også mulig å avslutte et abonnent på en feilrapport. For å avslutte abonnentet må man send en e-post til nnn[email protected]. Tittelen 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.

Som standard vil adressen som blir funnet i Fra-feltet 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 form: nnn-subscribe-localpart=example.com@bugs.debian.org. Det eksempelet ville sendt [email protected] som en abonneringsmelding til feilrapport nnn. Alfakrøll blir endret til å være et erlik-tegn (=). På samme måte tar en avslutning på abonnentet form nnn-unsubscribe-localpart=example.com@bugs.debian.org. I begge tilfeller vil tittelen og kroppen av e-posten bli videresendt til e-postadressen angitt for bekreftelse.

Mer eller mindre avlegs tittelfelt-søk

Meldinger som kommer til submit eller bugs og hvis tittelfelt starter med Bug#nnn blir behandlet som om de hadde blitt sendt til nnn@bugs. Dette er både av hensyn til bakoverkompatibilitet og for å hindre at oppfølginger på feilrapporter havner som nye feilrapporter ved en feil (f.eks at noen har brukt svar til alle).

Meldinger sendt til maintonly, done, quiet og forwarded behandles på en tilsvarende måte.

Meldinger som kommer til forwarded og done — uten feilrapportnummer i adressen — eller tittelfeltet blir lagret under junk (søppel) og bevart i noen uker, men ellers ignorert.

Avlegs X-Debian-PR: quiet-egenskap

Tidligere kunne man unngå at feilrapportsystemet videresendte innkommende meldinger til debian-bugs ved å legge til en X-Debian-PR: quiet-linje i hodet på eposten.

Denne linjen blir nå ignorert. Send i stedet meldingen til quiet eller nnn-quiet (eller maintonly eller nnn-maintonly).

Andre sider i feilrapporteringssystemet

Debian BTS administrators <[email protected]>

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