På samme måde som request@bugs.debian.org gør det muligt at
hente fejldata og dokumentation gennem e-mail,
gør control@bugs.debian.org det muligt at behandle fejlrapporter på
forskellige måder.
Kontrolserveren fungerer præcis som forespørgselsserveren og har desuden nogle ekstra kommandoer. Hvis sandheden skal frem, så er det faktisk det samme program. De to adresser er bare blevet adskilt for at forhindre afsenderen i at begå fejl og forårsage problemer, når alt hvad vedkommende ønskede var at hente oplysninger.
Da kommandoerne der er specifikke for kontrolserveren faktik ændrer fejlens status, vil der blive sendt en besked om behandlingen af kommandoerne til vedligeholderen af den eller de pakker, som fejlen vedrører. Desuden bliver mailen til serveren og den ændringer den medfører logget i fejlrapporten og bliver dermed tilgængelige på websiderne.
Se introduktion til
forespørgselsserveren som findes på nettet, i filen
bug-log-mailserver.txt, og ved at sende help til
en af e-mailserverne for grundlæggende oplysninger om hvordan man anvender
e-mailserverne, og for en liste over de tilgængelige kommandoer uanset
hvilken adresse man anvender.
Et referencekort til e-mailserveren er
tilgængeligt via nettet, i bug-mailserver-refcard.txt eller via
e-mail med kommandoen refcard.
| Generelt | Versionering | Duplikater | Forskelligt |
reassign fejlnummer pakke
[ version ]Angiver at fejlen med nummeret fejlnummer er en fejl i pakken pakke. Dette kan anvendes til at sætte pakkenavnet hvis afsenderen glemte pseudo-brevhovedet, eller til at ændre en tidligere tildeling. Der sendes ikke besked til nogen (bortset fra normale oplysninger om kommandofortolkningen).
Hvis du tilføjer en version vil fejlsporingssystemet bemærke, at fejlen påvirker den version af den nyligt tildelte pakke.
Du kan på samme tid tildele en fejl til to pakker, ved at adskille pakkenavnene med et komma. Dog bør du kun gøre dette, hvis fejlen kan rettes med en ændring til af en pakkerne. Er det ikke tilfældet, bør du klone fejlen og gentildele klonen til den anden pakke.
reopen fejlnummer
[ oprindelsesadresse | = | ! ]Åbner fejlrapporten med nummeret fejlnummer igen hvis den er blevet lukket.
Som standard, eller hvis man angiver =, vil stadig kun
den oprindelige afsender være angivet som den der har rapporteret fejlen,
så vedkommende vil blive informeret når rapporten lukkes igen.
Hvis man medsender en ny oprindelsesadresse vil den blive
anvendt i stedet for. Hvis man selv være stå opført som afsenderen af
den nyåbnede fejlrapport, kan man anvende forkortelsen !,
eller angive sin egen e-mailadresse.
Det er normalt en god idé at underrette personen der kommer til at stå som afsender af fejlrapporten, om at man genåbner rappoten, så vedkommende er forberedt på at blive informeret når rapporten lukkes igen.
Hvis fejlrapporten ikke er lukket, vil reopen-kommandoen ikke gøre
noget, ikke engang ændre oprindelsesadressen. For at ændre
oprindelsesadressen på en åben fejlrapport anvendes kommandoen
submitter; bemærk at dette ikke vil oplyse den oprindelige
indsender om ændringen.
Hvis fejlen er blevet registreret som lukket i en bestemt version af
en pakke, men dukker op igen i en senere version, det er bedre at
anvende kommandoen found i stedet.
found fejlnummer [ version ]Registrerer at #fejlnummer er opdaget i den angivne version af pakken som den er knyttet til. version kan være en komplet versionsangivelse på formen kildekodepakkenavn/version.
Fejlsporingssystemet anvender denne oplysning, sammen med rettede versionerner, der registreres når fejl lukkes, for at vise en liste over åbne fejl i forskellige udgaver af hver pakke. Systemet anser en fejl for at være åben når der ikke er en rettet version eller når den er fundet senere end den er rettet.
Hvis ingen version er angivet, tømmes fejlens liste over
rettede versioner. Dette svarer til hvordan reopen
fungerer. version kan være en komplet versionsangivelse på
formen kildekodepakkenavn/version.
Denne kommando sørger kun for at markere en fejl som ikke-løst hvis
ingen version blev angivet, eller hvis den version, der
markeres svarer til eller er større end den højeste version,
der sidst blev markeret som rettet. (Hvis du er sikker på, at du ønsker
fejlen markeret som ikke-løst, anvend da reopen sammen med
found.)
Denne kommando blev indført til fordel for reopen, fordi
det var svært at tilføje en version til den kommandos
syntaks uden at lide af flertydighed.
notfound fejlnummer versionFjern registreringen af at #fejlnummer blev fundet i den angivne version af pakken som det er tilknyttet. version kan være en komplet versionsangivelse på formen kildekodepakkenavn/version.
Dette er anderledes end at lukke fejlen for den version, da fejlen heller ikke anføres som rettet i den version; ingen oplysninger om versionen vil være kendte. Formålet er at rette fejltagelser i registreringen af hvornår en fejl blev fundet.
fixed fejlnummer versionAngiv af fejl nummer fejlnummer blev rettet i en given version af den pakke, som den vedrører. version kan være en komplet versionsangivelse på formen kildekodepakkenavn/version.
Dette medfører ikke at fejlen markeres om lukket, det tilføjer blot en anden version, hvori fejlen er rettet. Anvend adressen bugnumber-done for at lukke fejlen og markere den som rettet i en bestemt version.
notfixed fejlnummer versionFjern registreringen af at fejl nummer fejlnummer blev rettet i den givne version. version kan være en komplet versionsangivelse på formen kildekodepakkenavn/version.
Denne kommando svarer til found efterfulgt af
notfound ('found' fjerner 'fixed' i en given version, og
'notfound' fjerner 'found') med den undtagelse, at fejlen ikke genåbnes
hvis den fundne ('found') version er større end nogen eksisterende rettet
version. Formålet er at rette fejltagelser i registreringen af hvornår en
fejl blev rettet; i de fleste tilfælde vil du i virkeligheden skulle
anvende found, og ikke notfixed.
submitter fejlnummer
oprindelsesadresse | !Ændrer oprindelsesadressen i #fejlnummer til oprindelsesadresse.
Ønsker du blive ny oprinder af en rapport, kan du bruge kortformen
! eller angive din egen e-mail-adresse.
Mens kommandoen reopen ændrer oprindelsen på andre
fejlrapporter kombineret med den der genåbnes, påvirker
submitter ikke kombinerede fejlrapporter.
forwarded fejlnummer adresseNoterer at fejlrapporten med nummeret fejlnummer er blevet videresendt til en opstrømsudvikler på adressen adresse. Dette videresender faktisk ikke rapporten, men kan anvendes til at ændre en eksisterende, forkert vidersendelsesadresse, eller til at registrere en ny adresse til en fejl som ikke tidligere var registeret som videresendt. addresse bør generelt være en URI eller muligvis en e-mail-adresse. Ved, hvor muligt, at angive en URI, er der mulighed for at værktøjer kan forespørge et fjerntliggende fejlsporingssystem (så som bugzilla) om en fejls status.
Eksempel på brug:
forwarded 12345 http://bugz.illa.foo/cgi/54321
notforwarded fejlnummerGlemmer alt om at fejlrapporten med nummeret fejlnummer er blevet videresendt til en opstrømsudvikler. Hvis fejlen ikke er registeret som videresendt, gør denne kommando ikke noget.
retitle fejlnummer ny-overskriftÆndrer overskriften på en fejlrapport til den angivne (standard er den
oprindelige rapports tekst i emne-linjen).
Modsat de fleste andre fejlbehandlingskommandoer, påvirker denne kommando kun den angivne fejlrapport, og ikke alle andre rapporter som den er slået sammen med.
severity fejlnummer alvorsgradSætter alvorsgraden på fejlrapporten med nummeret fejlnummer til alvorsgraden grad. Den oprindelige afsender af rapporten underrettes ikke.
Tilgængelige alvorsgrader er critical,
grave, serious, important,
normal, minor og wishlist.
For en beskrivelse af hvad de betyder, se udviklernes gennerelle dokumentation vedrørende fejlrapporteringssystemet.
affects fejlnummer
[ + | - | =
] pakke [ pakke ... ]Indikerer at en fejl påvirker en anden pakke. I tilfældet hvor fejlnummer forårsager problemer i pakke, selv om fejlen i virkeligheden findes i den pakke, som den er tildelt, forårsager dette at fejlen som standard vises i pakkelisten hørende til pakke. Det bør generelt anvendes, hvor en fejl er alvorlig nok til at forårsage flere rapporter fra brugerne bliver tildelt den forkerte pakke.
summary fejlnummer
[meddelelse nummer]Vælger en meddelelse, der anvendes som fejlens opsummering. Det første ikke-pseudoheader-afsnit hørende til den meddelelse, fortolkes og opsættes som opsummering vedrørende fejlen og vises øverst på fejlrapportsiden. Det er nyttigt i situationer, hvor den oprindelige rapport ikke på korrekt vis beskriver problemet eller hvis fejlen har mange meddelelser, der gør det vanskeligt at identificere det egentlige problem.
Hvis meddelelse nummer ikke er angivet, fjernes opsummeringen. meddelelse nummer er meddelelsesnummeret, der vises i outputtet fra bugreport-cgi-skriptet.
clone fejlnummer ny id [ nye id'er ... ]Kloningskommandoen giver mulighed for at kopiere en fejlrapport. Det er
nyttigt hvor en enkelt fejlrapport faktisk angiver at flere forskellige
fejl er opstået. Nye id'er
er negative tal, adskilt af
mellemrumstegn, som kan benyttes i efterfølgende kontrolkommandoer til
at referere til de nyligt kopierede fejlrapporter. Den oprettes en ny
rapport for hver ny id.
Eksemel på anvendelse:
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 fejlnummer fejlnummer ...Slår to eller flere fejlrapporter sammen. Når rapporter er slået sammen vil åbning, lukning, markering af videresendelse eller fjernelse af samme, samt omtildeling til en anden pakke af en af pakkerne have samme effekt på alle de rapporter som er slået sammen.
Inden fejlrapporter kan slås sammen skal de have præcis den samme
tilstand, enten skal de alle være åbne eller lukkede, med en samme
videresend-opstrømsadresse eller ikke alle markeret som videresendte,
alle tildelt de(n) samme pakke(r) (en nøjagtig strengsammenligning
anvendes på de pakker som fejlrapporterne er tildelt). og alle skal have
samme alvorsgrad. Hvis de fra begyndelsen ikke har samme tilstand skal
man anvende reassign, reopen, og så videre så
de har samme tilstand inden man anvender kommanoden
merge. Det er ikke nødvendigt at titler er ens og de vil
ikke blive påvirket af kommandoen. Tags behøver heller ikke at være ens,
de vil blive samlet.
Hvis nogle af fejlrapporterne anført i en merge-kommando
allerede er slået sammen med andre rapporter, vil også de allerede
sammenslåede rapporter blevet slået sammen med de angivne fejlrapporter.
Sammenslåning er som ækvivalent: den er refleksiv, transitiv og
symmetrisk.
Når fejlrapporter slås sammen, bliver dette noteret i hver enkelt rapports log, og på websiderne oprettes links til de andre fejl.
Sammenslåede fejlrapporter udløber samtidig, og kun når alle rapporterne hver for sig opfylder kriterierne for at udløbe.
forcemerge fejlnummer fejlnummer ...Gennemtvinger forbindelse af to eller flere fejlrapporter. Den første angivne fejl er hovedfejlen og dens indstillinger (som skal svare til en normal merge-kommando) tildeles de efterfølgende angivne fejl. For at undgå at slåfejl fejlagtigt slår fejl sammen, skal fejlene være i den samme pakke. Se teksten oven for for en beskrivelse af hvad det vil sige at forbinde fejlrapporter.
Bemærk at dette gør det muligt at lukke fejl ved at slå dem sammen, du er ansvarlig for at give indsenderne besked med en passende lukningsmeddelse, hvis du vælger at gøre dette.
unmerge fejlnummerFjerner forbindelsen mellem en fejlrapport og de rapporter den er slået sammen med. Hvis rapporten er slået sammen med flere andre, vil de andre fortsat være slået sammen, kun forbindelsen til den specifikt angivne fejlrapport fjernes.
Hvis mange fejlrapporter er slået sammen og du ønsker at opdele dem i to separate grupper af sammenslåede rapporter, skal de først fjerne forbindelserne for hver enkelt rapport i den ene nye gruppe, og dernæst slå dem sammen til den nye gruppe.
Du kan kun fjerne forbindelsen for en rapport ad gangen med
unmerge-kommandoen. Hvis du vil fjerne forbindelsen til
flere fejlrapporter, skal du blot angive flere
unmerge-kommandoer i din meddelelse.
tags fejlnummer [ + | -
| = ] mærke [ mærke ... ]
[ + | - | = mærke ... ] ]Sætter mærker for fejlrapporten med nummeret fejlnummer.
Brugeren som rapporterede fejlen bliver ikke underrettet. Sættes
handlingen til +, betyder det at alle de efterfølgende
mærker tilføjes; - betyder at alle de efterfølgende
mærker fjernes; og = betyder at de efterfølgende
mærker opsættes jævnfør den leverede liste. Anvendelse af mærkerne
+, - eller = ændrer handlingen på
de efterfølgende mærker. Standardhandlingen er tilføjelse.
Eksempler:
# det samme som 'tags 123456 + patch'
tags 123456 patch
# det samme som 'tags 123456 + help security'
tags 123456 help security
# tilføjer mærkerne 'fixed' og 'pending'
tags 123456 + fixed pending
# fjerner mærket 'unreproducible'
tags 123456 - unreproducible
# sætter mærkerne til kun 'moreinfo' og 'unreproducible'
tags 123456 = moreinfo unreproducible
# fjerner mærket moreinfo og tilføjer et patch-mærke
tags 123456 - moreinfo + patch
Tilgængelige markeringer er pt. 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 og experimental.
For en beskrivelse af hvad de betyder, se udviklernes gennerelle dokumentation vedrørende fejlrapporteringssystemet.
block fejlnummer by fejl ...Bemærk at rettelsen til den første fejl blokeres af de andre anførte fejl.
unblock fejlnumber by fejl ...Bemærk at rettelsen til den første fejl ikke længere blokeres af de andre anførte fejl.
close fejlnummer (bør ikke længere anvendes)Lukker fejlrapporten med nummeret fejlnummer.
Bruger som oprindeligt indsendte fejlrapporten får besked, men
indholdet i den e-mail som lukker rapporten inkluderes
ikke (til forskel fra at sende til
fejlnummer-done@bugs.debian.org). Vedligeholder som lukker
rapporten bør sørge for at brugeren som indsendte rapporten får besked
om hvorfor rapporten blev lukket, for eksempel ved at sende en separat
e-mail. Anvendelse af denne kommandoen frarådes derfor. Se
udvikleroplysningerne om hvordan man på rette
vis lukker en fejl.
package [ pakkenavn ... ]Begrænser de følgende kommandoer, så de kun virker på fejl indsendt mod de angivne pakker. Du kan angive en eller flere pakker. Hvis du ikke angiver nogen pakker, vil de følgende kommandoer virke på alle fejl. Du opfordres til at anvende dette som en sikkerhedsfunktion, i fald du ved et uheld angiver de forkerte fejlnumre.
Eksempel på brug:
package foo
reassign 123456 bar
package bar
retitle 123456 bar: bar sucks
severity 123456 normal
package
severity 234567 wishlist
owner fejlnummer adresse | !Sætter adresse til at være owner
(ejer) af #fejlnummer.
Ejeren af en fejl tager ansvareret for at rette den. Dette er nyttigt
til arbejdsdeling i tilfælde hvor en pakke har et hold af vedligeholdere.
Ønsker du selv at blive fejlens ejer, kan du bruge forkortelsen
! eller angive din egen e-mail-adresse.
noowner fejlnummerGlemmer alt om, at fejlen har en ejer, bortset fra den sædvanlige vedligeholder. Der er ikke er registeret en ejer af fejlen har denne kommando ingen effekt.
archive fejlnummerArkiverer en fejl, der tidligere var arkiveret men ikke er det i øjeblikket, hvis fejlen opfylder arkiveringskravene, ignorerende tidskrav.
unarchive fejlnummerOphæver arkiveringen af en fejl, der tidligere var arkiveret. Ophævelse
af arkivering bør generelt kombineres med reopen
(genåbn) og
found
/fixed
(fundet/rettet) hvor det er relevant. Fejl,
hvis arkivering er blevet ophævet, kan arkiveres med archive
,
forudsat at de ikke-tidsmæssige arkiveringskrav er opfyldt.
#...En-linje-kommentar. # skal være på begyndelsen af linjen.
Kommentartekster vil blive medtaget i bekræftelsen som sendes til
afsenderen og berørte vedligeholdere, hvorfor du kan anvende dette til at
dokumentere årsagerne til dine kommandoer.
quitstopthankthanksthankyouthank you--På en linje for sig selv, efterfulgt af whitespace, fortæller kontrolserveren at den skal stoppe behandlingen af meddelelsen; resten af meddelelsen kan indeholde forklaringer, underskrifter eller hvad som helst, intet af det vil blive bemærket af kontrolserveren.
Andre sider i fejlrapporteringssystemet:
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.