Bemerkung: Das Original ist neuer als diese Übersetzung.

Einführung in den E-Mail-Server für Kontrolle und Manipulation

Genau wie [email protected] es erlaubt, Fehlerdaten und -dokumentation über E-Mail abzurufen, erlaubt es [email protected], Fehlerberichte auf verschiedene Arten und Wege zu bearbeiten.

Der Kontroll-Server arbeitet genauso wie der Request-Server, mit der Ausnahme, dass er einige zusätzliche Befehle unterstützt. In der Tat ist er sogar das gleiche Programm. Die beiden Adressen werden nur unterschieden, um zu verhindern, dass Anwender Fehler machen und Probleme verursachen, während sie lediglich versuchen, Informationen zu erhalten.

Da die für den Kontroll-Server spezifischen Befehle den Status eines Fehlers ändern, wird eine Benachrichtigung über die Bearbeitung der Befehle an den Betreuer des Pakets, dem die geänderten Fehler zugewiesen sind, gesendet. Zusätzlich werden die E-Mail an den Server und die daraus entstandenen Änderungen im Fehlerbericht festgehalten und sind daher auf den Webseiten abrufbar.

Bitte lesen Sie die Einführung zum Request-Server, die im World Wide Web bereitsteht, in der Datei bug-log-mailserver.txt, oder durch Senden des Wortes help an einen der E-Mail-Server, um Details der Arbeit der E-Mail-Server zu erhalten sowie der gesamten Befehle.

Die Referenzkarte für den E-Mail-Server ist im WWW verfügbar, in bug-mailserver-refcard.txt oder per E-Mail durch Senden des Befehls refcard.

Befehle, die beim Kontroll-E-Mail-Server zur Verfügung stehen

Allgemeine	Versionierung	Duplikate	Verschiedenes
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 Fehlernummer Paket [ Version ]

Nimmt auf, dass der Fehler #Fehlernummer ein Fehler in Paket ist. Dies kann verwendet werden, um nachträglich einen Fehler einem Paket zuzuordnen, wenn der Benutzer vergessen hat, die Pseudo-Kopfzeile anzugeben, oder um eine frühere Zuweisung zu ändern. Es werden keine Benachrichtigungen an irgendjemanden geschickt (anders als die üblichen Informationen bei der Verarbeitung).

Falls Sie eine Version angeben, wird die Fehlerdatenbank bemerken, dass der Fehler diese Version des frisch-zugewiesenen Pakets betrifft.

Sie können einen Fehler zwei Paketen auf einmal zuweisen, indem Sie die Paketnamen durch Komma trennen. Sie sollten dies allerdings nur tun, falls der Fehler durch eine Änderung in einem der beiden Pakete behoben werden kann. Falls dies nicht zutrifft, sollten Sie den Fehler klonen und den Klon dem anderen Paket zuweisen.

reopen Fehlernummer [ Urheber-Adresse | = | ! ]

Öffnet #Fehlernummer erneut (wenn er geschlossen ist) und löscht die Liste der Versionsnummern, für die der Fehler behoben wurde.

Wenn Sie = als Urheber angeben, wird der gleiche Urheber verwendet, der den Fehler ursprünglich berichtet hat, so dass er erneut eine Bestätigung erhält, wenn der Fehlerbericht erneut geschlossen wird.

Wenn Sie eine Urheber-Adresse angeben, wird der Urheber auf die angegebene Adresse gesetzt. Wenn Sie wünschen, als neuer Urheber des wieder-geöffneten Fehlerberichts eingetragen zu werden, verwenden Sie das Kürzel ! oder geben Sie Ihre eigene E-Mail-Adresse an.

Es ist normalerweise eine gute Idee, der Person, die als Urheber eingetragen wird, mitzuteilen, dass Sie den Bericht erneut öffnen, damit diese Bescheid weiß, dass sie eine Bestätigung zu erwarten hat, wenn der Bericht erneut geschlossen wird.

Wenn der Fehler nicht geschlossen wurde, wird reopen nichts tun, nicht einmal den Urheber ändern. Um den Urheber eines offenen Fehlerberichts zu ändern, verwenden Sie den submitter Befehl; beachten Sie, dass dies den ursprünglichen Urheber über die Änderung informiert.

Falls der Fehler als in einer bestimmten Version eines Paketes geschlossen notiert wurde, aber in einer späteren Version wieder aufgetaucht ist, ist es besser, stattdessen den found-Befehl zu verwenden.

found Fehlernummer [ Version ]

Notiere, dass #Fehlernummer in der gegebenen Version des Pakets, der sie zugewiesen wurde, angetroffen wurde. Version kann eine vollständig qualifizierte Version in der Form Quelltextpaketname/Version sein.

Die Fehlerdatenbank verwendet diese Information in Verbindung mit korrigierten Versionen, die beim Schließen notiert werden, um Listen von offenen Fehlern in verschiedenen Versionen jedes Pakets anzuzeigen. Sie betrachtet einen Fehler als offen, wenn sie keine korrigierte Version hat, oder wenn er gefunden wurde, nachdem er korrigiert wurde.

Falls keine Version angegeben wurde, wird die Liste der korrigierten Versionen für diesen Fehler bereinigt. Dies ist identisch zu dem Verhalten von reopen. Version kann eine vollständig qualifizierte Version in der Form Quelltextpaketname/Version sein.

Mit diesem Befehl wird ein Fehler lediglich als nicht-erledigt markiert, falls keine Version angegeben ist, oder falls die Version, in der der Fehler gefunden wurde, größer oder gleich der höchsten Version ist, die als korrigiert markiert wurde. (Falls Sie sich sicher sind, dass Sie den Fehler als nicht-erledigt markieren wollen, verwenden Sie reopen zusammen mit found).

Dieser Befehl wurde als Präferenz für reopen eingeführt, da es schwierig war, eine Version zu der Syntax dieses Befehls hinzuzufügen, ohne unter Mehrdeutigkeiten zu leiden.

notfound Fehlernummer Version

Entferne die Aufzeichnung, dass #Fehlernummer in der angegebenen Version des Pakets, dem er zugewiesen wurde, angetroffen wurde. Version kann eine vollständig qualifizierte Version in der Form Quelltextpaketname/Version sein.

Dies unterscheidet sich vom Schließen eines Fehlers in dieser Version darin, dass der Fehler nicht als in dieser Version korrigiert aufgeführt ist; keine Information über diese Version wird bekannt sein. Es ist dazu gedacht, Irrtümer, wann der Fehler gefunden wurde, in den Aufzeichnungen zu korrigieren.

fixed Fehlernummer Version

Kennzeichne, dass der Fehler #Fehlernummer in der angegebenen Version des zugewiesenen Pakets korrigiert wurde. Version kann eine vollständig qualifizierte Version in der Form Quelltextpaketname/Version sein.

Dies führt nicht dazu, dass der Fehler als geschlossen markiert wird, es ergänzt lediglich eine weitere Version, in der der Fehler korrigiert wurde. Verwenden Sie die Fehlernummer-done-Adresse, um einen Fehler zu schließen und ihn als in einer bestimmen Version korrigiert zu markieren.

notfixed Fehlernummer Version

Entferne die Aufzeichnung, dass der Fehler Fehlernummer in der angegebenen Version korrigiert wurde. Version kann eine vollständig qualifizierte Version in der Form Quelltextpaketname/Version sein.

Dieser Befehl ist äquivalent zu found gefolgt von notfound (found entfernt das fixed in einer bestimmten Version, und notfound entfernt den found) mit der Ausnahme, dass der Fehler nicht wieder geöffnet wird, wenn die Version, in der der Fehler gefunden wurde, größer als jede Version ist, in der der Fehler als korrigiert markiert wurde. Es ist dazu gedacht, Irrtümer in der Aufzeichnung zu korrigieren, wann ein Fehler behoben wurde. In den meisten Fällen benötigen Sie eigentlich found, nicht notfixed.

submitter Fehlernummer Urheber-Adresse | !

Ändert den Urheber von #Fehlernummer auf Urheber-Adresse.

Falls Sie der neue Urheber des Berichts werden wollen, können Sie die Kurzform ! verwenden, um Ihre eigene E-Mail Adresse anzugeben.

Während der reopen-Befehl den Urheber von anderen mit dem zu öffnenden zusammengeführten Fehlern ändert, beeinflusst submitter zusammengeführte Fehler nicht.

forwarded Fehlernummer Adresse

Vermerkt, dass Fehlernummer an den ursprünglichen Betreuer unter Adresse weitergeleitet wurde. Dieses leitet den Bericht nicht tatsächlich weiter. Es kann dafür benutzt werden, um eine fehlerhafte forwarded-to-Adresse zu ändern oder um eine neue für einen Fehler zu vermerken, der bisher nicht als weitergeleitet markiert wurde. Adresse sollte im Allgemeinen eine URI sein, oder möglicherweise eine E-Mail-Adresse. Die Verwendung einer URI wo möglich erlaubt es Werkzeugen, den Status in anderen Fehlerdatenbanken (wie Bugzilla) für den Fehlerstatus abzufragen.

Verwendungsbeispiel:

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

notforwarded Fehlernummer

Vergisst jegliche Idee, dass Fehlernummer an einen ursprünglichen Betreuer weitergeleitet wurde. Wenn der Fehler nicht als forwarded markiert war, wird dieses nichts tun.

retitle Fehlernummer Neuer-Titel

Ändert den Titel des Fehlerberichts zu dem angegebenen (normalerweise wird das Subject aus der E-Mail-Kopfzeile des ursprünglichen Berichts genommen). Auch werden hiermit die Titel aller mit diesem Fehlerbericht zusammengefassten Fehlerberichte geändert.

severity Fehlernummer Schwere

Setzt den Schweregrad für den Fehlerbericht #Fehlernummer auf Schwere. Es wird keine Benachrichtigung an den Benutzer verschickt, der den Fehler berichtet hat.

Schweregrade sind critical, grave, serious, important, normal, minor, wishlist.

Die Bedeutung der Schweregrade finden Sie in den allgemeinen Informationen zum Fehler-System für Entwickler.

affects Fehlernummer [ + | - | = ] Paket [ Paket ... ]

Zeigt an, dass ein Fehler ein anderes Paket betrifft. Falls Fehlernummer das Paket unbenutzbar macht, obwohl der Fehler tatsächlich in dem Paket vorhanden ist, dem er zugewiesen wurde, wird der Fehler in der Voreinstellung auf der Fehlerseite des anderen Pakets aufgelistet. Dies sollte immer dann benutzt werden, wenn der Fehler so schwerwiegend ist, dass verschiedene Benutzer Fehlerberichte gegen das falsche Paket einsenden könnten. = setzt die Liste der betroffenen Pakete auf die hierauf folgend angegebenen Pakete, dies ist der Standard, wenn noch keine Pakete angegeben wurden; - entfernt das angegebene Paket von der Liste betroffener Pakete; + fügt das angegebene Paket zur Liste der betroffenen Pakete hinzu, und ist der Standard, wenn bereits Pakete angegeben wurden.

summary Fehlernummer [Nachrichtennummer] | Zusammenfassungstext]

Wählt eine Nachricht aus, die als Zusammenfassung des Fehlers verwendet wird. Der erste Absatz der Nachricht, der keine Pseudo-Kopfzeilen oder Kontrollbefehle enthält, wird ausgewertet und als Zusammenfassung verwendet. Diese wird oben auf der Seite des Fehlerberichts dargestellt. Das ist sinnvoll in Fällen, wo der ursprüngliche Bericht das Problem nicht richtig beschreibt oder es so viele Nachrichten gibt, dass das tatsächliche Problem schwierig zu erkennen ist.

Falls die Nachrichtennummer nicht angegeben ist, wird die Zusammenfassung gelöscht. Nachrichtennummer ist die Nummer der Nachricht, wie sie in der Ausgabe des Fehlerbericht-CGI-Skripts angezeigt wird; falls eine Nachrichtennummer gleich 0 angegeben ist, wird die aktuelle Nachricht verwendet (das heißt, die Nachricht, die an [email protected] geschickt wurde und welche den summary-Kontrollbefehl enthält).

Wenn die Nachrichtennummer nicht numerisch und auch nicht leer ist, wird dies als der Text angenommen, auf den der Zusammenfassungstext gesetzt werden soll.

outlook Fehlernummer [Nachrichtennummer | Vorausschautext]

Wählt eine Nachricht, die als Vorausschau für die Behebung des Fehlers (oder den derzeitigen Status zur Behebung des Fehlers) verwendet wird. Der erste Abschnitt der Nachricht, der weder Pseudo-Header noch Kontrollbefehl ist, wird verarbeitet und als Vorausschau für den Fehler gesetzt, um oben auf der Seite des Fehlerberichts angezeigt zu werden. Dies ist nützlich, um die Arbeit mit anderen zu koordinieren, die mit der Behebung dieses Fehlers beschäftigt sind (zum Beispiel auf einer Fehlerbehebungsparty (Bug Squashing Party)).

Falls die Nachrichtennummer nicht angegeben ist, wird der Vorausschautext gelöscht. Nachrichtennummer ist die Nummer der Nachricht gemäß der Ausgabe des Fehlerbericht-CGI-Skripts; wenn die Nachrichtennummer gleich 0 ist, wird die aktuelle Nachricht verwendet (das heißt, die Nachricht, die an [email protected] gesendet wurde und den outlook-Kontrollbefehl enthält).

Wenn die Nachrichtennummer nicht numerisch und auch nicht leer ist, wird dies als der Text angenommen, auf den der Vorausschautext gesetzt werden soll.

clone Fehlernummer NeueID [ NeueIDs ... ]

Der clone-Kontrollbefehl erlaubt es, einen Fehlerbericht zu duplizieren. Es ist nützlich, wenn ein einziger Bericht tatsächlich mehrere unterschiedliche Fehler anspricht. NeueID/NeueIDs sind negative Nummern, von Leerzeichen getrennt, die in nachfolgenden Kontrollbefehlen verwendet werden können, um auf die neuen duplizierten Fehlerberichte zu verweisen. Ein neuer Bericht wird für jede neue ID generiert.

Beispielsverwendung:

        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 Fehlernummer Fehlernummer ...

Fasst zwei oder mehrere Fehlerberichte zusammen. Wenn Berichte zusammengefasst sind, wirken sich das Öffnen, Schließen, Markieren als Weitergeleitet bzw. dessen Aufhebung und die Zuweisung an ein Paket jeweils auf alle Berichte dieser Menge aus und nicht nur auf einen einzigen.

Bevor Fehler zusammengefasst werden können, müssen sie sich in exakt dem gleichen Zustand befinden: entweder sind alle geöffnet oder geschlossen, mit den gleichen ursprünglichen Autoren als forwarded-to markiert oder alle nicht als weitergeleitet markiert, alle dem gleichen Paket (oder den gleichen Paketen, ein exakter String-Vergleich wird auf die Pakete durchgeführt) zugewiesen und alle müssen die gleiche Schwere haben. Wenn sie sich nicht im gleichen Zustand befinden, sollten Sie reassign, reopen und so weiter verwenden, um sicherzustellen, dass sie sich im gleichen Zustand befinden, bevor Sie merge benutzen. Die Titel müssen nicht übereinstimmen und werden von der Zusammenfassung nicht beeinflusst. Auch die Markierungen müssen nicht übereinstimmen, sie werden kombiniert.

Wenn einer der Fehler, der in einem merge-Befehl aufgelistet ist, bereits mit einem anderen Fehler zusammengefasst ist, werden alle diese Berichte mit den neuen aufgelisteten zusammengefasst. Zusammenfassen ist wie eine Gleichheits-Relation: Es ist reflexiv, transitiv und symmetrisch.

Das Zusammenfassen von Berichten bewirkt, dass eine Bemerkung im Log jedes Berichts erscheint; auf den WWW-Seiten fügt dies Links zu den anderen Fehlern ein.

Zusammengefasste Berichte verfallen gleichzeitig, und nur dann, wenn alle der Berichte gleichzeitig die Kriterien für den Verfall erfüllen.

forcemerge Fehlernummer Fehlernummer ...

Erzwingt das Zusammenfassen zweier oder mehrerer Fehlerberichte. Während bei einem normalen merge die Fehlerberichte exakt den gleichen Zustand aufweisen müssen, wird hier der Zustand des ersten angegebenen Fehlerberichts allen nachfolgend aufgeführten Fehlerberichten zugewiesen. Um zu vermeiden, dass Tippfehler fälschlicherweise Fehler zusammenfassen, müssen die Fehler im gleichen Paket sein. Lesen Sie den obigen Text für eine Beschreibung, was Zusammenfassen bedeutet.

Beachten Sie, dass dies das Schließen von Fehlern durch Zusammenfassen ermöglicht; Sie sind dafür verantwortlich, die Einreicher mit einer angemessenen Abschlussnachricht zu benachrichtigen, falls Sie dies durchführen.

unmerge Fehlernummer

Zieht einen Fehlerbericht aus einer zusammengefassten Fehler-Menge heraus. Wenn der angegebene Bericht mit mehreren anderen zusammengefasst ist, bleiben die anderen Fehlerberichte weiterhin zusammengefasst; lediglich die Assoziation mit dem explizit angegebenen Bericht wird gelöst.

Wenn viele Fehlerberichte zusammengefasst sind und Sie wünschen, diese in zwei separate Gruppen aufzuteilen, müssen Sie jeden einzelnen Bericht einer dieser Gruppen aus der großen Gruppe herausziehen und anschließend in der neuen Gruppe zusammenfassen.

Sie können mit dem Befehl unmerge nur einen Bericht aus einer Menge herausziehen; wenn Sie mehr als einen Bericht aus einer Gruppe herausziehen möchten, schreiben Sie einfach mehrere unmerge-Befehle in Ihre E-Mail.

tags Fehlernummer [ + | - | = ] Markierung [ Markierung ... ] [ + | - | = Markierung ... ] ]

Setzt Markierungen für den Fehlerbericht #Fehlernummer. Es wird keine Benachrichtigung an den Anwender geschickt, der den Fehler berichtet hat. Die Aktion + bedeutet, dass jede folgend übergebene Markierung hinzugefügt wird, - bedeutet, dass jede folgend übergebene Markierung entfernt wird und = bedeutet, dass die in der Liste folgenden Markierungen gesetzt werden sollen. Zwischen den Markierungen vorhandene Anweisungen +, - oder = ändern die Aktion für die nachfolgenden Markierungen. Voreingestellt ist, dass neue Markierungen hinzugefügt werden.

Beispiel für die Benutzung:

        # Dasselbe wie tags 123456 + patch
        tags 123456 patch

        # Dasselbe wie tags 123456 + help security
        tags 123456 help security

        # Hinzufügen der fixed und pending-Markierungen
        tags 123456 + fixed pending

        # Entfernen der unreproducible-Markierung
        tags 123456 - unreproducible

        # Setze Markierungen exakt auf moreinfo und unreproducible
        tags 123456 = moreinfo unreproducible

        # Entfernen der moreinfo-Markierung und Hinzufügen der
        # patch-Markierung
        tags 123456 - moreinfo + patch

Markierungen können zurzeit folgende Werte annehmen: 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 .

Die Bedeutung der Markierungen für Fehlerberichte finden Sie in den allgemeinen Informationen zum Fehler-System für Entwickler.

block Fehlernummer by Fehlernummer ...

Fügt die Anmerkung hinzu, dass die Fehlerbehebung des ersten Fehlers durch die anderen aufgeführten Fehler blockiert wird.

unblock Fehlernummer by Fehlernummer ...

Entfernt die Anmerkung, dass die Fehlerbehebung des ersten Fehlers durch die anderen aufgeführten Fehler blockiert wird.

close Fehlernummer [ korrigierte-Version ] (veraltet)

Schließt den Fehlerbericht #Fehlernummer.

Eine Benachrichtigung wird an den Benutzer geschickt, der den Fehler berichtet hat, jedoch ist (im Gegensatz zu E-Mails an Fehlernummer[email protected]) der Text der E-Mail, die das Schließen verursacht hat, nicht in dieser Benachrichtigung enthalten. Der Betreuer, der den Bericht geschlossen hat, sollte sicherstellen, womöglich durch Versenden einer separaten Nachricht, dass der Benutzer, der den Fehler berichtet hat, weiß, wieso er geschlossen wurde. Die Verwendung dieses Befehls wird daher nicht empfohlen. Siehe auch die Informationen für Entwickler über das korrekte Schließen eines Fehlerberichts.

Falls Sie eine korrigierte-Version angeben, wird die Fehlerdatenbank vermerken, dass der Fehler in dieser Version des Pakets korrigiert wurde.

package [ Paketname ... ]

Beschränkt die folgenden Kommandos derart, dass sie nur auf Fehler angewendet werden, die hier aufgeführt sind. Sie können ein oder mehrere Pakete angeben. Falls Sie kein einziges Paket angeben, werden die folgenden Kommandos auf alle Fehler angewandt. Es wird empfohlen, dies als Sicherheitsvorkehrung zu verwenden, falls Sie irrtümlicherweise die falschen Fehlernummern erwischen.

Beispielsanwendung:

        package foo
        reassign 123456 bar 1.0-1

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist

owner Fehlernummer Adresse | !

Setzt Adresse als Besitzer von #Fehlernummer. Der Besitzer eines Fehlers beansprucht die Verantwortung für das Beheben des Fehlers für sich. Dies ist nützlich, um die Arbeit in Fällen zu verteilen, bei denen ein Paket ein Team von Betreuern besitzt.

Falls Sie selbst der Besitzer des Fehlers werden wollen, können Sie die Abkürzung ! verwenden oder Ihre eigene E-Mail Adresse angeben.

noowner Fehlernummer

Vergisst jegliche Information darüber, dass der Fehler einen anderen Besitzer als den üblichen Betreuer hat. Falls der Fehler keinen Besitzer eingetragen hat, tut dies nichts.

archive Fehlernummer

Archiviert einen Fehler, der zu einem Zeitpunkt in der Vergangenheit archiviert worden wäre, aber nicht archiviert worden ist, falls der Fehler die Voraussetzungen für die Archivierung erfüllt. Die Zeit wird ignoriert.

unarchive Fehlernummer

Macht die Archivierung eines Fehlers rückgängig. Dies sollte in der Regel mit reopen und found/fixed gekoppelt werden. Fehler, deren Archivierung rückgängig gemacht wurde, können mit archive wieder archiviert werden, falls die nicht zeitbezogenen Archivierungsrichtlinien erfüllt sind. Sie sollten die Archivierung nicht rückgängig machen, um triviale Änderungen an archivierten Fehlern vorzunehmen, z.B. den Einreicher zu ändern. Primär dient dieser Befehl dazu, Fehler erneut zu öffnen, die ohne den Eingriff der BTS-Administratoren archiviert wurden.

#...

Einzeiliger Kommentar. Das #-Zeichen muss am Anfang der Zeile stehen. Die Kommentartexte sind in der Bestätigung enthalten, die dem Einsender und den betroffenen Betreuern zugeschickt wird, so dass Sie hiermit die Gründe für Ihre Befehle dokumentieren können.

quit

stop

thank

thanks

thankyou

thank you

--

Wenn dies allein in einer Zeile steht, eventuell gefolgt von Leerzeichen, so teilt dies dem Kontroll-Server mit, die Bearbeitung der Nachricht zu beenden; der Rest der Nachricht kann Erklärungen, Signaturen und alles andere enthalten, nichts davon wird von dem Kontroll-Server entdeckt.

Weitere Seiten der Fehlerdatenbank:

Debian BTS administrators <[email protected]>