Information om felbehandlingssystemet för paketutvecklare och felsorterare

Det första som händer är att en användare skickar in en felrapport per e-post till [email protected], som måste innehålla en Package-rad (se instruktioner för felrapportering för mer information). Felrapporten tilldelas ett nummer, som sänds tillbaka till användaren som kvittens, och vidaresänds sedan till debian-bugs-dist. Om Package-raden innehåller ett paket med en känd ansvarig, så skickas även en kopia till denne.

Ärenderaden kommer att få texten Bug#nnn: tillagd, och Reply-To sätts så att den inkluderar både felrapportens avsändare och nnn@bugs.debian.org.

Stänga en felrapport

Felrapporter i Debian bör stängas när problemet är rättat. Problem i paket kan endast anses rättade när ett paket som innehåller felrättelsen kommer på plats i Debianarkivet.

Vanligtvis är det bara personen som sände in felrapporten och den ansvarige för paketet mot vilket felet är insänt som bör stänga en felrapport. Det finns undantag från denna regel, till exempel för rapporter som sänts in mot okända paket eller vissa generella pseudopaket. En felrapport kan även stängas av vilken bidragslämnare som helst om felet är för ett övergivet (Eng: orphaned) paket eller om den paketansvarige har glömt att stänga det. Det är väldigt viktigt att nämna i vilket version som felrapporten stängdes. Om du är osäker, stäng inte felrapporter, utan be först om råd på sändlistan debian-devel.

Felrapporter stängs genom att sända e-post till nnn[email protected]. Meddelandekroppen måste innehålla en förklaring om hur felet rättades.

Med de brev som kommer från felrapporteringssystemet är allt du behöver att göra för att stänga felet att skriva ett svar i ditt e-postläsarprogram och redigera mottagarfältet så att det står nnn[email protected] istället för nnn@bugs.debian.org (nnn-close finns även som alias för nnn-done).

När det är möjligt ber vi dig ange en rad Version i pseudohuvudet i ditt brev när du stänger en felrapport, så att felrapporteringssystemet vet vilka utgåvor av paketet som innehåller rättelsen.

Personen som stänger felrapporten, personen som ursprungligen rapporterade den, såväl som sändlistan debian-bugs-closed kommer alla att få en bekräftelse på ändringen av status för rapporten. Felrapportens avsändare och sändlistan kommer även få en kopia på innehållet i meddelandet som sänds till nnn-done.

Uppföljningsmeddelanden

Felrapporteringssystemet kommer att inkludera avsändarens adress samt adressen till felrapporten (nnn@bugs.debian.org) i Reply-To-fältet när rapporten vidaresänds. Observera att detta är två olika adresser.

Om en utvecklare vill svara på en felrapport räcker det att svara på brevet och följa vad Reply-To föreskriver. Detta kommer inte markera rapporten som avhjälpt.

Använd inte svara till alla mottagare eller följ upp i ditt e-postprogram såvida du inte manuellt vill redigera mottagarlistan ordentligt. Du bör definitivt se till att inte skicka uppföljningsmeddelanden till [email protected].

Meddelanden kan skickas till följande adresser för att lagras i felrapporteringssystemet.

För vidare information om brevhuvuden för att förhindra svarsmeddelanden samt hur man sänder kopior genom felrapporteringssystemet, se instruktionerna för att rapportera fel.

Allvarlighetsgrader

Systemet lagrar en allvarlighetsgrad tillsammans med varje felrapport. Denna sätts som standard till normal, men kan ändras, antingen genom att skicka med en rad i ett pseudo-brevhuvud Severity när felet rapporteras (se instruktioner för att rapportera fel), eller genom att använda styrserverns severity-kommando. Avdela multipla märken med komman, blanksteg eller bådadera.

Allvarlighetsgraderna är:

critical (kritiskt)
anger att orelaterad programvara i systemet (eller hela systemet) inte fungerar, kan orsaka kritiskt databortfall, eller att ett säkerhetshål introduceras på system där paketet installeras.
grave (gravt)
felet gör paketet i fråga helt oanvändbart för de flesta eller alla användare, orsakar databortfall, eller introducerar ett säkerhetshål som ger åtkomst till konton hos dem som använder paketet.
serious (allvarligt)
en svår överträdelse av Debians policy (i stort sett så bryter den mot ett måste- eller krav-direktiv), eller, enligt paket- eller utgivningsansvariga, gör paketet olämpligt att släppas.
important (viktigt)
ett fel som på ett omfattande sätt inverkar på paketets användbarhet, utan att göra det helt oanvändbart för alla.
normal (normalt)
standardvärdet, för de flesta fel.
minor (mindre)
ett problem som inte påverkar paketets användbarhet, och som troligen är lätt att rätta.
wishlist (önskelista)
förfrågningar om nya funktioner, och även för fel som är väldigt svåra att fixa på grund av större formgivningsöverväganden.

Vissa allvarlighetsgrader anses vara kritiska nog att stoppa utgivning (release-critical), vilket betyder att felet kommer att påverka om paketet kan ges ut med den stabila utgåvan av Debian eller inte. För närvarande är dessa critical (kritiskt), grave (gravt) samt serious (allvarligt). För fullständiga och kanoniska regler som beskriver vilka problem som uppfyller kraven för dessa allvarlighetsgrader, se förteckningen över utgivningskritiska fel för nästa utgåva.

Markeringar på felrapporter

Varje felrapport kan vara märkt med noll eller flera av en given uppsättning markeringar. Dessa markeringar visas i listan över felrapporter när du tittar på ett pakets sida, och när du tittar på den kompletta felrapportsloggen.

Markeringar kan sättas genom att sända med en Tags-rad i pseudohuvudet när felrapporten sänds in (se instruktioner för felrapporteringar), eller genom att använda kommandot tags via styrservern.

Tillgängliga felrapportsmarkeringar är: 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 . Här följer detaljerad infomation om markeringarna:

patch
En patch, eller någon annan enkel procedur för att rätta felet, är inkluderat i felrapportsloggen. Om det finns en patch, men den inte rättar felrapporten helt och hållet, eller ger andra problem, bör denna markering inte användas.
wontfix (rättar ej)
Detta fel kommer inte att rättas. Detta kan bero på att det är ett val mellan två skilda sätt att göra det på, och paketansvarige eller användaren föredrar ett annat sätt att göra det på, kanske på grund av att en ändring av hur programmet arbetar kommer att ge andra, värre, problem för andra, eller av andra orsaker.
moreinfo (ytterligare info)
Detta fel kan inte hanteras förrän ytterligare information fås från avsändaren. Felrapporten kommer att stängas om avsändaren inte ger ytterligare information inom en försvarlig tid (några månader). Detta är avsett för felrapporter på formen Det fungerar inte – vad är det som inte fungerar?
unreproducible (ej reproducerbart)
Detta fel kan inte reproduceras på ansvariges system. Assistans från tredjepart behövs för att diagnostisera källan till problemet.
help (hjälp)
Den ansvarige ber om hjälp med att rätta detta fel. Antingen har inte den ansvarige kunskapen som behövs för att rätta detta fel och behöver samarbete, eller så har han eller hon för mycket att göra och vill delegera uppgiften till någon annan. Felet kanske inte är lämpat för nya bidragslämnare om det inte också är markerat med newcomer-taggen.
newcomer (nykomling)
Detta fel har en känd lösning men den paketansvarige önskar att någon annan implementerar den. Detta är en idealisk uppgift för nya bidragslämnare som vill bli mer involverade i Debian, eller som vill förbättra sina kunskaper.
pending (på gång)
En lösning på detta fel har hittats och en rättad version kommer sändas in inom kort.
fixed (rättat)
Felet är rättat eller har gåtts runt (till exempel genom en version insänd av någon annan än den som är ansvarig för paketet), men det är fortfarande ett problem som måste lösas. Denna märkning ersätter allvarlighetsgraden fixed.
security (säkerhet)
Felet beskriver ett säkerhetsproblem i ett paket (t.ex felaktig behörighet ger tillgång till data som inte skulle vara tillgänglig; buffertspill som gör det möjligt att kontrollera systemet på sätt som inte borde finnas; överbelastningsattacker som bör rättas, osv.). De flesta säkerhetsfel bör också få allvarlighetsgraden satt till critical eller grave.
upstream (uppströms)
Detta fel berör uppströmsdelen av paketet.
confirmed (bekräftad)
Paketansvarige har tittat på, förstår och håller i grunden med felrapporten, men har ännu inte rättat den. (Det är valfritt att använda detta märke; det är huvudsakligen avsett för paketansvariga som måste hantera stora mängder öppna fel.)
fixed-upstream
Felet har rättats av uppströmsutvecklaren, men ännu inte i paketet (av någon orsak: kanske är det för komplicerat att bakåtanpassa ändringen eller felet är för litet för att vara värt besväret).
fixed-in-experimental
Felet har rättats i paketet i den experimentella utgåvan, men ännu inte i den instabila utgåvan.
d-i
Detta fel är relevant för utvecklingen av debian-installer. Detta märke är avsett att användas när felet rör utvecklingen av installationsprogrammet men inte är insänt mot ett paket som direkt utgör en del av själva installationsprogrammet.
ipv6
Detta fel rör stödet för version 6 av Internetprotokollet.
lfs
Detta fel rör stödet för stora filer (över 2 gigabyte).
l10n
Felet berör lokalanpassningen av paketet.
ally
Detta fel påverkar tillgänglighet för användare med funktionsnedsättning. Det påverkar speciellt användbarheten för personer som är beroende av hjälpmedel (eller annan adaptiv teknik) för att använda systemet / paketet.
ftbfs
Paketet kan inte bygga från källkod (Fails To Build From Source). Om felet är tilldelat ett binärpaket så misslyckas de påverkade källkodspaketen att bygga. Taggen är tillämplig för icke-standard byggmiljöer (t.ex. när man använder byggberoenden från experimentella utgåvan), men allvarlighetsgraden skulle vara under "allvarlig" (utgåvekritisk) i sådana fall.
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
Dessa är utgåvemärkningar som har två effekter. När de sätts på ett fel, kan felet endast påverka specifik utgåva (Den kan dock påverka andra utgåvor om andra utgåvemärkningar är satta) men andra normala regler rörande fel/rättat/frånvarande gäller. Felet skall heller inte arkiveras förrän det är rättat i utgåvan.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
Detta utgivningskritiska fel skall ignoreras för utgivningen av ändamålet att ge ut en speciell utgåva. Detta märke får enbart användas av ansvarige för utgåvan; sätt inte det själv utan explicit dennes tillåtelse.

Lite information om distributions-specifika markeringar; Ignorera (-ignore) betyder att felet skall ignoreras för övergången till uttestningsutgåvan. Utgåvemarkeringarna anger att felet i fråga inte ska arkiveras tills det rättats i den specificerade mängden utgåvor. Utgåvemarkeringarna indikerar också att ett fel och den mängd av utgåvor för vilken ett fel kan anses finnas eller ha rättats. bara ska anses finnas i den angivna mängden utgåvor. [Med andra ord är felet frånvarande i samtliga utgåvor vars utgåveetikett inte är satt om någon utgåveetikett är satt; annars gäller de vanliga hittad/rättad-reglerna.]

Utgåvemarkeringar ska inte användas om korrekta versionsbenämningar på felet skulle åstadkomma den önskade effekten, eftersom de kräver tillägg eller borttagning för hand. Om du är osäker kring om en utgåvebemarkering krävs, kontakta administratörerna för Debians felrapporteringssystem ([email protected]) eller utgåvegruppen för råd.

Ange att du har skickat vidare en felrapport

När en utvecklare skickar vidare en felrapport till den som uppströms tillverkar den källkod som Debianpaketet härstammar från bör detta noteras i felrapporteringssystemet så här:

Se till att mottagarfältet i ditt brev till författaren bara anger författarens/-rnas adress/-er och ange den som rapporterade felet, nnn[email protected] och nnn@bugs.debian.org i Cc-fältet.

Be författaren att behålla Cc till nnn[email protected] när han/hon svarar, så att felrapporteringssystemet arkiverar svaret tillsammans med den ursprungliga rapporten. Dessa brev kommer enbart att arkiveras och inte vidaresändas; för att sända ett vanligt meddelande sänder du även till nnn@bugs.debian.org.

När felrapporteringssystemet får ett meddelande till nnn-forwarded markerar det den angivna felrapporten som vidaresänd till adresserna i mottagarfältet på det brev det tar emot om inte felet redan markerats som vidaresänt.

Du kan även manipulera forwarded to-informationen genom att skicka meddelanden till [email protected].

Byta ägare till ett fel

I de fall då personen som är ansvarig för att rätta felet inte är den som är satt som ansvarig för det paket det gäller (till exempel då paketet hanteras av en grupp), kan det vara lämpligt att anteckna denna information i felrapporteringssystemet. För att göra detta kan varje felrapport, om man så vill, ha en ägare.

Ägaren kan anges genom att sända med ett Owner-huvud i pseudohuvudet när felrapporten sänds in (se instruktionerna för att sända felrapporter), eller genom att använda kommandona owner och noowner mot styrservern.

Felaktigt angivna paketansvariga

Om fel person anges som ansvarig för ett paket är det vanligtvis för att den ansvarige nyligen har ändrats, och att den som tagit över ännu inte har skickat upp en ny version av paketet med ett ändrat Maintainer-kontrollfält. Detta rättas när paketet skickas upp, alternativt kan arkivansvariga ändra i listan över ansvariga manuellt, till exempel om en ny version av paketet inte förväntas skickas upp på ett tag. Kontakta [email protected] för ändringar.

Nyöppna, flytta över och manipulera felrapporter

Det är möjligt att flytta över felrapporter till andra paket, att nyöppna dem som felaktigt har stängts, att modifiera informationen som säger var (om någonstans) rapporten har vidaresänts, för att ändra allvarlighetsgraden eller rapporttiteln, sätta ägarskap på felrapporter, för att slå ihop eller dela på felrapporter och för att lägga till information om vilken version av paketen felen hittats i och i vilka de rättats. Detta görs genom att skicka e-post till [email protected].

Formatet på dessa styrmeddelanden beskrivs i ett annat dokument på webben samt i filen bug-maint-mailcontrol.txt. En version i ren text kan fås genom att skicka ordet help till servern på adressen ovan.

Prenumerera på felrapporter

Felrapporteringssystemet gör det möjligt för de som sänder in fel, utvecklare och andra intresserade tredjeparter att prenumerera på individuella felrapporter. Denna funktion kan användas av de som vill hålla reda på en felrapport utan att behöva prenumerera på ett paket genom Debians paketspårare (Package Tracking System - PTS). Alla brev som tas emot på nnn@bugs.debian.org sänds till prenumeranter.

Du prenumererar på en felrapport genom att sända ett e-brev till nnn[email protected]. Ärenderaden och innehållet i brevet ignoreras av felrapporteringssystemet. När brevet behandlats får du ett bekräftelsebrev du måste svara på innan du kan ta emot brev som gäller rapporten.

Det är även möjligt att avbeställa en felrapportsprenumeration. Du kan avbeställa genom att sända ett e-brev till nnn[email protected]. Ärenderaden och innehållet i brevet ignoreras åter av felrapporteringssystemet. Du får ett bekräftelsebrev du måste svara på innan din prenumeration på felrapporten avslutas.

Normalt används adressen som finns i From-huvudet som prenumerationsadress. Om du vill prenumerera på felrapporten på en annan adress måste du koda in adressen du vill prenumerera på i prenumerationsbeställningen. Du gör det på formen: nnn-subscribe-lokal_del=example.com@bugs.debian.org. I detta exempel sänds bekräftelsebrevet för fel nnn till [email protected]. Tecknet @ måste kodas genom att byta det till tecknet =. På samma sätt avbeställer du genom att använda en adress på formen nnn-unsubscribe-lokal_del=example.com@bugs.debian.org. I bägge fallen sänds ärenderaden och textkroppen i e-brevet vidare i bekräftelsebrevet till den e-postadress som beställningen gäller.

Mer eller mindre obsolet ärenderadavsökning

Meddelanden som kommer till submit eller bugs vars ärenderader börjar med Bug#nnn räknas som om de hade sänts till nnn@bugs.debian.org. Detta används både för bakåtkompatibilitet med post som vidaresänts från de gamla adresserna, och för att fånga uppföljningar som skickas till submit av misstag (till exempel genom att svara till alla mottagare).

En liknande funktion finns för maintonly, done, quiet och forwarded, vilka räknar e-post med en ärenderad enligt ovan som om de sänts till nnn-vaddetnuvar@bugs.debian.org.

Meddelanden som kommer till forwarded och done utan något felrapportsnummer, och dessutom utan ett nummer i ärenderaden, arkiveras under skräp och behålls i några veckor, men ignoreras i övrigt.

Föråldrad X-Debian-PR: quiet-funktion

Tidigare var det möjligt att undvika att felrapporteringssystemet vidaresänder meddelanden det tog emot till debian-bugs genom att lägga in raden X-Debian-PR: quiet i brevhuvudet.

Denna rad ignoreras numera. Använd istället adresserna quiet och nnn-quiet (eller maintonly eller nnn-maintonly).

Andra sidor i felrapporteringssystemet:

Debian BTS administrators <[email protected]>

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