Utvecklarinformation om hur systemet används

Det första som händer är att en användare skickar in en felrapport per e-post till submit@bugs.debian.org. Felrapporten tilldelas ett nummer, vilket sänds tillbaka till användaren som kvittens, och vidaresänds sedan till debian-bugs-dist. Om avsändaren inkluderade en Package-rad som angav 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. 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-done@bugs.debian.org. Meddelandekroppen måste innehålla en förklaring om hur felet rättades.

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.

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-done@bugs.debian.org istället för nnn@bugs.debian.org (nnn-close finns även som alias för nnn-done).

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.

Felrapporteringssystemet kommer att ta emot svaret på nnn@bugs.debian.org, vidaresända det till den ansvarige för paketet, arkivera svaret tillsammans med övriga loggar för felrapporten och vidaresända det till debian-bugs-dist.

Om du sänder e-post till nnn-submitter@bugs.debian.org kommer det explicit sändas till den som rapporterade felet och en kopia kommer sparas i felrapporteringssystemet. Brevet kommer inte sändas till paketansvariga.

Om du vill sända ett uppföljningsmeddelande som inte är lämpligt för debian-bugs-dist kan du göra det genom att skicka till nnn-quiet@bugs.debian.org eller nnn-maintonly@bugs.debian.org. E-post till nnn-quiet@bugs.debian.org arkiveras i felrapporteringssystemet, men vidaresänds inte till andra individer eller sändlistor. E-post till nnn-maintonly@bugs.debian.org arkiveras i felrapporteringssystemet och vidaresänds enbart till den som har hand om paketet i fråga.

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 submit@bugs.debian.org.

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 eller till stor del oanvändbart, 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 Lenny.

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
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.
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.
potato
Felet gäller specifikt potato-utgåvan av Debian.
woody
Felet gäller specifikt woody-utgåvan av Debian.
sarge
Detta fel skall inte arkiveras förrän det rättats i Sarge.
sarge-ignore
Detta utgivningskritiska fel skall ignoreras för utgivningen av Sarge. Detta märke får enbart användas av ansvarige för utgivningarna; sätt inte det själv utan explicit dennes tillåtelse.
etch
Detta fel skall inte arkiveras förrän det rättats i Etch.
etch-ignore
Detta utgivningskritiska fel skall ignoreras för utgivningen av Etch. Detta märke får enbart användas av ansvarige för utgivningarna; sätt inte det själv utan explicit dennes tillåtelse.
lenny
Detta fel skall inte arkiveras förrän det rättats i Lenny.
lenny-ignore
Detta utgivningskritiska fel skall ignoreras för utgivningen av Lenny. Detta märke får enbart användas av ansvarige för utgivningarna; sätt inte det själv utan explicit dennes tillåtelse.
sid
Detta fel skall inte arkiveras förrän det rättats i Sid.
experimental
Detta fel skall inte arkiveras förrän det rättats i den experimentella utgåvan.

Betydelsen av de åttda sista markeringarna har ändrats nyligen. Ignorera betyder att felet skall ignoreras för övergången till uttestningsutgåvan. Utgåvemarkeringarna, vilka tidigare angav vilka fel som gällde för en specifik utgåva, anger nu när ett fel kan arkiveras och ignoreras i övrigt av systemet. De kan dock användas av andra verktyg, till exempel skripten som flyttar paket till uttestningsutgåvan.

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-forwarded@bugs.debian.org och nnn@bugs.debian.org i Cc-fältet.

Be författaren att behålla Cc till nnn-forwarded@bugs.debian.org 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 control@bugs.debian.org.

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 override-change@debian.org 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 control@bugs.debian.org.

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 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-subscribe@bugs.debian.org. Ä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-unsubscribe@bugs.debian.org. Ä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 lokal_del@example.com. 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 <owner@bugs.debian.org>

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