Förutom e-postservern på request@bugs.debian.org som gör det
möjligt att hämta information om felrapporten via e-post, finns det
ytterligare en server på control@bugs.debian.org som
dessutom gör 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.
reassign felnummer paket
[ version ]
Om du inkluderar en version kommer felrapporteringssystemet notera att felet gäller den versionen av det paket det nyss tilldelats.
reopen felnummer
[ ursprungsadress | = | ! ]
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 ]
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.
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 densamma
som versionen där felet sist markerades som rättats.
(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
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
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
Kommandot motsvarar found följt av notfound
(found tar bort fixed för en specifik version, och notfound tar bort found).
submitter felnummer
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
notforwarded felnummer
retitle felnummer ny-titel
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
Tillgängliga allvarlighetsgrader är:
critical, grave, serious,
important, normal, minor och
wishlist.
För betydelser, se den övergripande utvecklardokumentationen för felrapporteringssystemet.
clone felnummer nytt-id [ nya-id ]
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 ...
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
...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
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 ... ]
+ betyder att alla angivna märken läggs till,
- betyder att alla angivna märken tas bort, och
= betyder att alla aktuella märken ignoreras och de ställs om
från noll till den angivna listan.
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
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,
sid
och experimental.
För betydelser, se
den övergripande utvecklardokumentationen för felrapporteringssystemet.
block felnummer by fel ...
unblock felnummer by fel ...
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 ... ]
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 | !
ägaretill 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
unarchive felnummer
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.
#...
#-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
--
Andra sidor i felrapporteringssystemet:
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.