Bemærk: Originalen er nyere end denne oversættelse.

Introduktion til e-mailserveren til fejlrapportskontrol og -behandling

På samme måde som [email protected] gør det muligt at hente fejldata og dokumentation gennem e-mail, gør [email protected] 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.

Kommandoer der findes på kontrolserveren

Generelt	Versionering	Duplikater	Forskelligt
reassign severity tags retitle submitter affects summary outlook	found \| notfound fixed \| notfixed reopen	merge \| unmerge forcemerge clone	thanks # forwarded \| notforwarded owner \| noowner block \| unblock archive \| unarchive user \| usertag \| usercategory

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 og tømmer alle rettede versioner, hvis den er 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 rapporten, 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 version

Fjern 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 version

Angiv 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 version

Fjern 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 adresse

Noterer 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 fejlnummer

Glemmer 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-titel

Ændrer titlen på en fejlrapport til den angivne (standard er den oprindelige rapports titel i emne-linjen). Ændrer også titlen på alle fejlrapporter, som denne fejl er slået sammen med.

severity fejlnummer alvorsgrad

Sæ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, 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 fejllisten 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. = opsætter det påvirkede til den oplyste liste over pakker, og er standardhandlingen hvis ingen pakker er oplyst; - fjerner de oplyste pakker fra listen over påvirkede; + tilføjer de oplyste pakker til listen over påvirkede, og er standard hvis der er oplyst pakker.

summary fejlnummer [meddelelsesnummer | opsumeringstekst]

Vælger en meddelelse, der anvendes som fejlens opsummering. Det første ikke-pseudoheader-/ikke-control-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 meddelelsesnummer ikke er angivet, fjernes opsummeringen. meddelelse nummer er meddelelsesnummeret, der vises i outputtet fra bugreport-cgi-skriptet; hvis et meddelelsesnummer på 0 angives, anvendes den aktuelle meddelelse (dvs. den meddelelse, som blev sendt til [email protected] som indeholder resumet af control-kommandoen).

Hvis meddelelsesnummer ikke er numerisk og ikke en tom streng, formodes det at være den tekst, som opresumeringen skal sættes til.

outlook fejlnummer [meddelelsesnummer | outlook-tekst]

Vælger en meddelelse, som skal anvendes som outlook'et til rettelse af en fejl (eller den aktuelle status på fejlrettelsen). Det første afsnit som ikke er en pseudoheader/kontrol i den pågældende meddelelse fortolkes og anvendes som fejlens outlook, der vises øverst på fejlrapportsiden. Det er nyttigt til koordinering med andre, som arbejder på at rette den samme fejl (eksempelvis under en fejlrettelsesfest).

Hvis meddelelsesnummer ikke er angivet, tømmes outlook'et. meddelelsesnummer er det meddelesesnummer, som er uddata fra bugreport-cgi-skriptet; hvis der angives et meddelelsesnnummer på 0, benyttes den aktuelle meddelelse (det vil sige, meddelelsen, som blev senddt til [email protected], der indeholder kontrolkommandoen summary).

Hvis meddelelsesnummer ikke er numerisk og ikke en tom streng, formodes det at være den tekst, som opresumeringen skal sættes til.

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 fejls indstillinger, som skal svare til en normal merge-kommando, tildeles de efterfølgende angivne fejl. For at undgå, at tastefejl 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 slå fejlrapporter sammen.

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 fejlnummer

Fjerner 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, 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 .

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, der oprindeligt indsendte fejlrapporten, får besked, men indholdet i den e-mail, der lukker rapporten, medtages ikke (til forskel fra at sende til fejlnummer[email protected]). Vedligeholderen, der lukker rapporten, bør sørge for at brugeren, der indsendte rapporten, får besked om hvorfor rapporten blev lukket, for eksempel ved at sende en separat e-mail. Anvendelse af denne kommando 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 fejlnummer

Glemmer 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 fejlnummer

Arkiverer en fejl, der tidligere var arkiveret men ikke er det i øjeblikket, hvis fejlen opfylder arkiveringskravene, ignorerende tidskrav.

unarchive fejlnummer

Ophæ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. Man bør ikke anvende ophævelse af arkiving for at foretage trivielle ændringer på arkiverede fej, så som at andre indsenderen; det primære formål er at gøre det muligt at genåbne fejl, der er blevet arkiveret, uden BTS-administratorernes mellemkomst.

#...

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.

quit

stop

thank

thanks

thankyou

thank 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 BTS administrators <[email protected]>