Schnellnavigation überspringen

• Über Debian
• Nachrichten
• Debian besorgen
• Unterstützung
• Entwickler-Ecke
• Sitemap
• Suche

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

Genau wie request@bugs.debian.org es erlaubt, Fehlerdaten und -dokumentation über E-Mail abzurufen, erlaubt es control@bugs.debian.org, 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 bekannten 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

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. Keine Benachrichtigungen werden an jemanden 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 zu 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.

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 mitzuteilen, dass sie neuer Urheber ist, wenn sie neuer Urheber wird, wenn Sie einen Bericht erneut öffnen, damit sie Bescheid weiß, dass sie eine Bestätigung zu erwarten haben, 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 von der Ä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 zu der sie zugewiesen wurde, angetroffen wurde.

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.

Mit diesem Befehl wird eine Fehler nur als nicht-erledigt markiert, falls keine Version angegeben ist, oder falls die Version, in der der Fehler gefunden wurde, mit der Version, in der der Fehler korrigiert wurde, übereinstimmt (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 den 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.

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.

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

Dieser Befehl ist äquivalent zu found gefolgt von notfound (found entfernt das fixed in einer bestimmten Version, und notfound entfernt den found).

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.

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

Anders als die meisten sonstigen Befehle zur Manipulation von Fehlern, wird dieser nur den Titel eines einzigen Fehlerberichts ändern und nicht alle, wenn er auf einen einzigen aus einer Menge von zusammengefassten Berichten angewendet wird.

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 und wishlist.

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

clone Fehlernummer NeueID [ neue IDs ... ]

Das clone Kontroll-Kommando erlaubt es, einen Fehlerbericht zu duplizieren. Es ist nützlich, wenn ein einziger Bericht tatsächlich mehrere unterschiedliche Fehler anspricht. neue IDs sind negative Nummern, von Leerzeichen getrennt, die in nachfolgenden Kontroll-Befehlen 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 beinhaltet dieses Links zu den anderen Fehlern.

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. Der erste aufgeführte Fehler ist der Leitfehler und seine Einstellungen (die Einstellungen, die beim normalen merge identisch sein müssen) werden den nachfolgend aufgeführten Fehlern 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 ... ]

Setzt Markierungen für den Fehlerbericht #Fehlernummer. Keine Benachrichtigung wird an den Anwender geschickt, der den Fehler berichtet hat. Die Aktion + bedeutet, dass jede übergebene Markierung hinzugefügt wird, - bedeutet, dass jede übergebene Markierung entfernt wird und = bedeutet, dass aktuelle Markierungen ignoriert und neu gesetzt werden sollen. 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
  

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

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-done@bugs.debian.org) 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 Fehler 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 war, 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 wurden, können mit archive wieder archiviert werden, falls die nicht zeitbezogenen Archivierungsrichtlinien erfüllt sind.

#...

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.