Introduktion till e-postservern för felrapportsstyrning och -manipulering

Precis som request@bugs.debian.org gör det möjligt att hämta information om felrapporten via e-post, gör control@bugs.debian.org det möjligt att manipulera felrapporterna på olika sätt.

Styrservern fungerar precis som frågeservern, förutom att den har ett antal extrakommandon. Om sanningen ska fram så är det faktiskt samma program. De två adresserna är bara separerade för att undvika att användare gör misstag och orsakar problem när allt de ville göra var att hämta information.

Eftersom de kommandon som gäller för styrservern faktiskt ändrar felrapportens status sänds en kvittering på behandlingen av kommandona till den/de ansvariga för de paket vars status ändras. Dessutom loggas brevet som sänds till servern i felrapporten och blir därmed tillgängligt via webbsidorna.

Se introduktion till frågeservern som finns på webben, i filen bug-log-mailserver.txt, eller genom att skicka help till någon av e-postservarna för grundläggande information om hur du använder e-postservrarna, och för de kommandon som finns tillgängliga oavsett vilken adress du använder.

Ett referenskort för e-postservrarna finns tillgängligt via webben, i bug-mailserver-refcard.txt eller via e-post med refcard-kommandot.

Kommandon som finns på styrservern

Allmänt	Versionshantering	Duplikat	Blandat
reassign severity tag retitle submitter affects summary	found \| notfound fixed \| notfixed reopen	merge \| unmerge forcemerge clone	thanks # forwarded \| notforwarded owner \| noowner block \| unblock archive \| unarchive

reassign felnummer paket [ version ]

Anger att fel nummer felnummer är ett fel i paketet paket. Detta kan användas för att sätta paketnamnet om användaren glömde pseudo-brevhuvudet, eller för att ändra en tidigare tilldelning. Inga notifikationer sänds till någon (förutom den normala information om kommandotydningen).

Om du inkluderar en version kommer felrapporteringssystemet notera att felet gäller den versionen av det paket det nyss tilldelats.

Du kan tilldela ett fel till två paket på samma gång genom att separera paketnamnen med ett komma. Du bör dock endast göra detta om felet kan korrigeras genom en ändring i något av paketen. Om så inte är fallet bör du klona felet och tilldela klonen till det andra paketet.

reopen felnummer [ ursprungsadress | = | ! ]

Öppnar upp felrapport nummer felnummer igen om den har stängts.

Som standard, eller om du anger =, kommer fortfarande den ursprunglige avsändaren att stå som felrapportör, så de kommer att få information om när den stängs på nytt.

Om du skickar med en ny adress (ursprungsadress) kommer den att användas istället, och om du själv vill stå som avsändare av den nyöppnade felrapporten kan du använda förkortningen !, eller ange din egen e-postadress.

Det är vanligtvis en bra idé att tala om för personen som kommer att anges som avsändare att du öppnar upp rapporten igen, så att de vet att de ska förvänta sig den rapport de får när den stängs på nytt.

Om felrapporten inte är stängd kommer inte reopen att göra någonting, inte ens ändra avsändare. För att ändra avsändare för en öppen felrapport, använd kommandot submitter; observera att den ursprungliga avsändaren då kommer informeras om ändringen.

Om det noterats att felet stängts i en specifik version av ett paket men återkommit i en senare version är det bättre att istället använda kommandot found.

found felnummer [ version ]

Notera det faktum att felnummer har upptäckts i version av det paket det tilldelats. version kan vara en fullt kvalificerad version på formen källpaketnamn/version.

Felrapporteringssystemet använder denna information, tillsammans med rättade versioner som lagras när felrapporter stängs, till att visa en förteckning över fel som är öppna i olika versioner av varje paket. Det anser en fel att vara öppen när det inte finns någon rättad version, eller när den upptäckts i en nyare version än det rättats i.

Om ingen version anges rensas listan över rättade versioner. Detta är samma beteende som reopen. version kan vara en fullt kvalificerad version på formen källpaketnamn/version.

Detta kommando gör bara att ett fel markeras som orättat när ingen version anges, eller som versionen som markeras som funnen är lika med eller större än den version som markerats som rättad. (Om du är säker på att felet inte är rättat, använd reopen tillsammans med found.)

Kommandot har introducerats framför reopen eftersom det var svårt att lägga till en version till det kommandots syntax utan att det blev tvetydigt.

notfound felnummer version

Ta bort information om att felnummer påträffats i given version av paketet till vilken det tilldelats. version kan vara en fullt kvalificerad version på formen källpaketnamn/version.

Till skillnad mot att stänga felrapporten listas inte felet som rättat i den versionen heller, information om den versionen kommer finnas tillgänglig. Detta kommando är avsett för att rätta felaktigheter i rapporteringen om när ett fel påträffats.

fixed felnummer version

Ange att fel felnummer rättades i den givna versionen av paketet det är tilldelat till. version kan vara en fullt kvalificerad version på formen källpaketnamn/version.

Detta innebär inte att felrapporten stängs, den lägger bara till ytterligare en version i vilken felet har rättats. Använd felnummer-done-adressen för att stänga en felrapport och ange att den är rättad i en specifik version.

notfixed felnummer version

Ta bort markeringen om att fel felnummer rättades i den givna versionen. version kan vara en fullt kvalificerad version på formen källpaketnamn/version.

Kommandot motsvarar found följt av notfound (found tar bort fixed för en specifik version, och notfound tar bort found) med det undantaget att felet inte öppnas om den funna versionen är större än någon av de existerande rättade versionerna. Kommandot är menat för att rätta misstag i uppgifterna om när ett fel rättades; i de flesta fall vill du använda found, inte notfixed.

submitter felnummer avsändaradress | !

Ändra avsändaren av felrapport nummer felnummer till avsändaradress.

Om du vill bli ny avsändare av rapporten kan du använda kortformen ! eller ange din egen e-postadress.

Medan reopen-kommandot ändrar avsändaren för andra felrapporter som slagits samman med den som återöppnas påverkar submitter inte sammanslagna rapporter.

forwarded felnummer adress

Noterar att felrapport nummer felnummer har vidaresänts till en utvecklare uppströms på adressen adress, men skickar inte vidare själva rapporten. Detta kan användas för att ändra en existerande, felaktig, vidaresändningsadress, eller för att lägga in en ny till en felrapport som inte tidigare markerats som vidaresänd. adress ska oftast vara en URI, eller möjligen en e-postadress. Genom att använda en URI när det går möjliggör du för verktyg att ställa frågor till ett externt felhanteringssystem (såsom bugzilla) om ett fels status.

Exempel på användning:

      forwarded 12345 http://bugz.illa.foo/cgi/54321

notforwarded felnummer

Glömmer allting om att felrapport nummer felnummer har vidaresänts till någon utvecklare uppströms. Om felet inte hade någon vidaresändning registrerad gör detta kommando ingenting.

retitle felnummer ny-titel

Ändrar titeln på felrapporten till den som anges (förinställt värde är ärenderaden från det ursprungliga felrapporteringsbrevet).

Till skillnad från de flesta andra felmanipuleringskommandon så kommer detta kommando, när det används på en uppsättning av hopslagna felrapporter, bara att påverka den felrapport som efterfrågas, inte alla som slagits samman.

severity felnummer grad

Sätter allvarlighetsgraden för felrapport nummer felnummer till allvarlighetsgrad grad. Ingen notifikation sänds till den användare som rapporterade felet.

Tillgängliga allvarlighetsgrader är: critical, grave, serious, important, normal, minor och wishlist.

För betydelser, se den övergripande utvecklardokumentationen för felrapporteringssystemet.

affects felnummer [ + | - | = ] paket [ paket ... ]

Indikerar att ett fel påverkar ett annat paket. I det fall felnummer orsakar problem i paket trots att felet i själva verket finns i det paket det är kopplat till, gör detta kommando att felet listas som standard i pakets lista. Detta ska generellt användas när felet är allvarligt nog att föranleda användare att rapportera flera rapporter som kopplas till fel paket.

summary felnummer [meddelandenummer]

Väljer ett meddelande som används som sammanfattning av felet. Det första stycket i det meddelandet som inte är ett pseudohuvud tolkas och sätts som sammanfattning av felet. Sammanfattningen visas högst upp på felrapportsidan. Detta är användbart i fall originalrapporten inte beskriver problemet korrekt eller felet har flera meddelanden vilket gör det svårt att identifiera problemet.

Om meddelandenummer inte ges, töms sammanfattningen. meddelandenummer är meddelandenumret som det listas i utdatat från cgi-skriptet bugreport.

clone felnummer nytt-id [ nya-id ]

Klonkommandot låter dig duplicera en felrapport. Det är användbart när en enda felrapport faktiskt indikerar att flera olika fel har uppstått. Nya id är negativa värden, avdelade med blanksteg, vilka kan användas i följande styrkommandon för att nå de nyduplicerade felen. En ny rapport genereras för varje nytt id.

Exempel på användning:

       clone 12345 -1 -2
       reassign -1 foo
       retitle -1 foo: foo sucks
       reassign -2 bar
       retitle -2 bar: bar sucks when used with foo
       severity -2 wishlist
       clone 123456 -3
       reassign -3 foo
       retitle -3 foo: foo sucks
       merge -1 -3

merge felnummer felnummer ...

Slår ihop två eller flera felrapporter. När rapporter är hopslagna kommer öppnande, stängande, (av)markerande som vidaresänd och omtilldelning till ett nytt paket av någon av felrapporterna att få samma effekt på samtliga hopslagna rapporter.

Innan felrapporter kan slås samman måste de ha samma tillstånd: antingen alla öppna eller alla stängda, med samma "vidaresänd-uppströms"-adress (eller inte alls markerad som vidaresänd), alla tilldelade samma paket (en exakt strängjämförelse görs på de paket till vilka felrapporterna är tilldelade), och alla ha samma allvarlighetsgrad. Om de från början inte har samma tillstånd måste du använda reassign, reopen, och så vidare, för att se till att de är det innan du använder merge. Rubrikerna behöver inte vara lika och påverkas inte heller av sammanslagningen. Märken behöver inte heller vara identiska, de kommer att slås ihop.

Om någon av felrapporterna som listas i merge-kommandot redan är hopslagen med någon annan felrapport kommer alla redan hopslagna rapporter att slås samman med de angivna felrapporterna. Hopslagning är som ekvivalens: reflexiv, transitiv och symmetrisk.

När felrapporter slås ihop noteras detta i alla rapporters logg, och på webbsidorna inkluderas länkar till de andra felen.

Hopslagna felrapporter försvinner samtidigt, och bara när alla rapporterna separat uppfyller kriterierna för att raderas.

forcemerge felnummer felnummer ...

Tvingar fram en sammanslagning mellan två eller flera felrapporter. Det första felet som anges är huvudfelrapporten och dess egenskapeer (i en normal sammanslagning måste egenskaperna vara identiska) tilldelas de andra felrapporter som anges efteråt. För att undvika att felskrivningar av misstag slår samman felrapporter måste felen gälla samma paket. Se texten ovan för en beskrivning av vad sammanslagning innebär.

Observera att detta gör det möjligt att stänga felrapporter genom en sammanslaning; du ansvarar för att meddela avsändaren med ett lämpligt stängnindsmeddelande om du gör det.

unmerge felnummer

Plockar bort en felrapport från dem den slagits samman med. Om rapporten är sammanslagen med flera andra kommer de andra fortfarande att vara sammanslagna med varandra; bara deras association med felrapporten som anges här kommer att tas bort.

Om många felrapporter är hopslagna och du vill dela upp dem i två separata grupper måste du först plocka isär alla rapporter i den ena gruppen en och en, för att sedan slå ihop dessa till den nya gruppen.

Du kan bara plocka isär en rapport åt gången med unmerge-kommandot. Om du vill plocka isär fler än en kan du helt enkelt ange flera unmerge-kommandon i ditt meddelande.

tags felnummer [ + | - | = ] märke [ märke ... ] [ + | - | = märke ... ] ]

Sätter märken på felrapport nummer felnummer. Ingen notifiering sänds till den användare som rapporterade felet. Att välja funktionen + betyder att alla angivna märken läggs till, - betyder att alla angivna märken tas bort, och = betyder att märkena ställs om till den angivna listan. Om +, - eller = dyker upp mitt i listan ställer det om hur de efterföljande märkena behandlas. Förvald funktion är att lägga till.

Exempel på hur det används:

# samma som tags 123456 + patch
tags 123456 patch

# samma som tags 123456 + help security
tags 123456 help security

# lägg till märkena fixed och pending
tags 123456 + fixed pending

# ta bort märket unreproducible
tags 123456 - unreproducible

# Ställ in exakt märkena moreinfo och unreproducible
tags 123456 = moreinfo unreproducible
  
# ta bort märket moreinfo och lägg till märket patch
tags 123456 - moreinfo + patch

Tillgängliga markeringar är för närvarande patch, wontfix, moreinfo, unreproducible, help, pending, fixed, fixed-in-experimental, fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs, l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore, lenny, lenny-ignore, squeeze, squeeze-ignore, sid och experimental.

För betydelser, se den övergripande utvecklardokumentationen för felrapporteringssystemet.

block felnummer by fel ...

Markera att rättningen av det första felet blockeras av det andra listade felet.

unblock felnummer by fel ...

Markera att rättningen av det första felet inte längre blockeras av det andra listade felet.

close felnummer[ rättad-version ] (bör ej användas)

Stänger felrapport nummer felnummer.

Användaren som ursprungligen skickade in felrapporten meddelas, men innehållet i det brev som stängde felrapporten inkluderas inte (till skillnad från felnummer-done@bugs.debian.org). Den som stänger rapporten bör se till att användaren som skickade rapporten får reda på varför den stängts, till exempel genom att skicka ett separat brev. Därför avråds det från att använda detta kommando. Se utvecklarinformationen om hur man stänger en felrapport på rätt sätt.

Om du skickar med en rättad-version kommer felrapporteringsystemet notera att felet rättats i den versionen av paketet.

package [ paketnamn ... ]

Begränsar de kommandon som följer så att de endast kan appliceras på fel som sänts in mot de paket som anges. Du kan ange ett eller flera paket. Om du inte anger några paket gäller de kommandon som följer för samtliga paket. Vi ber dig använda detta som en säkerhetsåtgärd om du av misstag skulle använda felaktiga felnummer.

Exempel på hur det används:

        package foo
        reassign 123456 bar 1.0-1

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist

owner felnummer adress | !

Ställer in adress till ägare till felrapport nummer felnummer. En felrapports ägare tar ansvar för att rätta den. Detta kan användas när ett paket tas hand om av en grupp.

Om du själv vill bli ägare till felrapporten kan du använda snabbkommandot ! istället eller ange din egen e-postadress.

archive felnummer

Arkiverar en felrapport som vid något tidigare tillfälle varit arkiverad men som inte är det för närvarande, om felrapporten uppfyller kraven för arkivering, förutom tid.

unarchive felnummer

Avarkiverar en felrapport som arkiverats tidigare. Avarkivering bör normalt göras tillsammans med lämpliga reopen och found/fixed. Felrapporter som avarkiverats kan arkiveras på nytt med archive så länge alla krav för arkivering förutom tid uppfylls.

#...

Enradskommentar. #-tecknet måste stå först på raden. Kommentarstexten kommer tas med i bekräftelsen som sänds till avsändaren och de berörda paketansvariga, så du kan använda detta för att dokumentera varför du sänder kommandona.

quit

stop

thank

thanks

thankyou

thank you

--

På en ensam rad, oavsett skiftläge, möjligen efterföljd av mellanslag, säger åt styrservern att sluta behandla meddelandet; resten av meddelandet kan innehålla förklaringar, signaturer eller något annat, inget av det kommer att läsas av styrservern.

Andra sidor i felrapporteringssystemet:

Debian BTS administrators <owner@bugs.debian.org>