Bemerkung: Das Original ist neuer als diese Übersetzung.

Informationen über das Fehlerverwaltungssystem für Paketbetreuer und Leute, die mit dem Sichten von Fehlern beschäftigt sind

Eingangs wird ein Fehlerbericht als normale E-Mail-Nachricht an [email protected] eingeschickt. Diese muss zwingend eine Package:-Zeile enthalten (Näheres unter Debian BTS – Fehler berichten). Der Fehler bekommt dann eine Nummer, der Einsender erhält eine Empfangsbestätigung und die Nachricht wird an debian-bugs-dist weitergeleitet. Wenn die Package-Zeile den Namen eines Pakets mit bekanntem Betreuer enthält, dann erhält auch der Betreuer eine Kopie des Fehlerberichts.

Zu der Subject-Zeile wird noch Bug# nnn: hinzugefügt und das Reply-To wird so geändert, dass es beide, den Absender des Fehlerberichts und nnn@bugs.debian.org, enthält.

Fehlerberichte schließen

Fehlerberichte von Debian sollten geschlossen werden, wenn das Problem behoben ist. Probleme in Paketen können nur als behoben erachtet werden, wenn das Paket, das die Fehlerbehebung enthält, das Debian-Archiv erreicht.

Üblicherweise sind die einzigen Personen, die einen Fehlerbericht schließen sollten, der Einreicher des Fehlerberichts und der/die Betreuer des Paketes, gegen das der Fehler berichtet wurde. Es gibt Ausnahmen von dieser Regel, zum Beispiel, wenn der Fehler gegen unbekannte Pakete oder gewisse generelle Pseudo-Pakete berichtet wurde. Ein Fehlerbericht kann ebenso von jedermann geschlossen werden, wenn er ein verwaistes Paket betrifft oder der Paketbetreuer vergessen hat, ihn zu schließen. In letzterem Fall ist es jedoch sehr wichitg, dass dabei die Version genannt wird, in der der Fehler behoben wurde. Falls Sie Zweifel haben, schließen Sie den Fehler nicht, sondern fragen Sie zuerst auf der Mailingliste debian-devel um Rat.

Fehlerberichte sollten geschlossen werden, indem man eine E-Mail an nnn[email protected] schickt. Der Inhalt der E-Mail muss die Erklärung enthalten, wie der Fehler behoben wurde.

Alles, was Sie zum Schließen des Berichts tun müssen, ist eine Antwort auf die E-Mail zu schreiben, die Sie von der Fehlerdatenbank erhalten haben, und das To-Feld auf nnn[email protected] ändern (statt nnn-done kann man auch nnn-close verwenden).

Wo anwendbar, geben Sie eine Version-Zeile in den Pseudo-Kopfzeilen Ihrer Nachricht an, wenn Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher Veröffentlichung des Paketes die Korrektur enthalten ist.

Die Person, die den Fehler schließt, die Person, die den Fehlerbericht verfasst hat und die debian-bugs-closed-Mailingliste bekommen alle eine Hinweis-E-Mail über die Änderungen im Status des Berichts. Der Einsender und die Mailingliste erhalten ebenfalls den Inhalt der Nachricht, die an nnn-done geschickt wurde.

Folge-Nachrichten

Die Fehlerdatenbank wird die Adresse des Einreichers und die Fehleradresse (nnn@bugs.debian.org) in die Reply-To-Kopfzeile aufnehmen, nachdem der Fehlerbericht weitergeleitet wurde. Bitte beachten Sie, dass dies zwei unterschiedliche Adressen sind.

Jeder Entwickler, der auf einen Fehlerbericht antworten möchte, sollte einfach unter Respektierung der Reply-To-Kopfzeile auf die Nachricht antworten. Das wird den Fehlerbericht nicht schließen.

Benutzen Sie auf keinen Fall die Allen antworten- oder die followup-Funktion Ihres E-Mail-Programms, es sei denn, Sie möchten die Liste der Empfänger anschließend selbst überarbeiten. Achten Sie insbesondere darauf, dass Sie keine Folge-Nachrichten an [email protected] verschicken.

Nachrichten können an die folgenden Adressen geschickt werden, um in der Fehlerdatenbank abgelegt zu werden:

Hinsichtlich weiterer Informationen über Kopfzeilen, mittels denen ACK-Benachrichtigungen unterdrückt werden können, und darüber, wie mit Hilfe des Fehlerverwaltungssystems Kopien verschickt werden können, schauen Sie in die Anleitung zum Einreichen von Fehlerberichten.

Schweregrad

Die Fehlerdatenbank speichert zusätzlich zu jedem Fehler einen Schweregrad. Dieser wird standardmäßig auf normal gesetzt, was jedoch entweder durch das Hinzufügen einer Severity-Zeile im Pseudo-Header beim Verfassen des Fehlerberichts (siehe Anweisungen für Fehlerberichte) oder durch das Benutzen des severity-Kommandos über den Control Request Server geändert werden kann.

Die Schweregrade:

critical
Beschädigt Software im System, die in keinem Bezug zum fehlerhaften Paket steht (oder sogar das ganze System), oder verursacht einen ernsthaften Datenverlust oder öffnet eine neue Sicherheitslücke auf dem System, auf dem Sie das Paket installieren.
grave
Macht das betreffende Paket (fast) unbrauchbar oder verursacht einen Datenverlust oder öffnet eine Sicherheitslücke, die es erlaubt, auf die Benutzerkonten derjenigen Benutzer zuzugreifen, die das Paket verwenden.
serious
Ist eine ernsthafte Verletzung der Debian Policy (bedeutet ungefähr, dass es eine muss- oder erfordert-Klausel verletzt) oder macht das Paket nach Meinung des Betreuers oder der Veröffentlichungsverwalter ungeeignet für eine Veröffentlichung.
important
Ein Fehler, der wesentliche Auswirkungen auf die Benutzbarkeit des Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen.
normal
Standardwert, anwendbar auf die meisten Fehler.
minor
Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das vermutlich sehr leicht zu beheben ist.
wishlist
Für beliebige Feature-Requests, aber auch für beliebige Fehler, die aufgrund wesentlicher konzeptioneller Erwägungen sehr schwer zu beheben sind.

Bestimmte Schweregrade werden als veröffentlichungskritisch erachtet, was bedeutet, dass der Fehler einen Einfluss auf die Veröffentlichung des Paketes mit dem stabilen Release von Debian hat. Im Augenblick sind das critical, grave und serious. Die vollständigen und kanonischen Regeln, welche Probleme diese Schweregrade rechtfertigen, finden Sie in der Liste der veröffentlichungskritischen Probleme für die stabile Veröffentlichung.

Markierungen für Fehlerberichte

Jeder Fehler kann eine oder mehrere Markierungen (engl. Tags) aus einer gegebenen Menge haben. Diese Markierungen werden in der Liste der Fehler angezeigt, wenn Sie auf der Paket-Seite oder im vollständigen Fehlerprotokoll nachschauen.

Die Markierungen können durch das Einfügen einer Tags-Zeile in den Pseudo-Kopfzeilen beim Abschicken des Fehlerberichts (siehe Anweisungen für Fehlerberichte), oder durch das Benutzen des tags-Kommandos über den Control Request Server gesetzt werden. Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides trennen.

Die zurzeit verfügbaren Fehler-Markierungen sind: 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 . Hier sind ein paar zusätzliche Informationen über die Markierungen:

patch
Ein Patch oder eine andere leichte Prozedur, die den Fehler behebt, ist im Fehlerprotokoll enthalten. Wenn es einen Patch gibt, der jedoch den Fehler nicht hinreichend behebt, oder irgendwelche andere Probleme verursacht, dann sollte diese Markierung nicht verwendet werden.
wontfix
Dieser Fehler wird nicht behoben. Möglicherweise weil hier eine Wahl getroffen wurde zwischen zwei beliebigen Wegen, um bestimmte Dinge zu erledigen und dabei stimmen der Paketbetreuer und der Absender des Fehlerberichts in ihrer Meinung, wie diese Dinge erledigt werden sollten, nicht überein, möglicherweise auch, weil die Änderung des Verhaltens andere, schlimmere Probleme nach sich ziehen würde oder aber auch aus anderen Gründen.
moreinfo
Dieser Fehler kann nicht bearbeitet werden, bevor der Absender des Fehlerberichts mehr Informationen zur Verfügung stellt. Der Fehler wird für geschlossen erklärt, falls der Absender keine weiteren Informationen innerhalb eines angemessenen Zeitraumes (ein paar Monate) liefert. Das ist für Fehler der Art: Das geht nicht. Was geht nicht?
unreproducible
Dieser Fehler kann nicht auf dem System des Paketbetreuers reproduziert werden. In diesem Fall wird die Hilfe einer Drittpartei bei der Diagnose der Ursachen des Problems benötigt.
help
Der Paketbetreuer ersucht um Hilfe beim Beheben des Fehlers. Entweder hat der Betreuer nicht das nötige Wissen, um diesen Fehler zu beheben und wünscht die Mitarbeit durch andere, oder er ist überlastet und möchte diese Aufgabe deshalb an andere abgeben. Dieser Fehler könnte für Anfänger unpassend sein, außer er ist zusätzlich auch mit newcomer markiert.
newcomer
Für diesen Fehler existiert eine bekannte Lösung, aber der Paketbetreuer ersucht darum, dass jemand anderes diese implementiert. Dies ist eine ideale Aufgabe für Anfänger, die sich in Debian einbringen oder die ihre Fähigkeiten verbessern wollen.
pending
Eine Lösung für dieses Problem wurde gefunden und ein repariertes Paket wird bald hochgeladen.
fixed
Dieser Fehler wurde behoben oder es existiert ein Workaround (der von einem Nicht-Betreuer eingereicht wurde). Es gibt jedoch immer noch ein Randproblem, das beseitigt werden soll. Diese Markierung ersetzt den alten Schweregrad fixed.
security
Dieser Fehler beschreibt ein Sicherheitsproblem in einem Paket (z.B. falsch gesetzte Rechte, die Zugriff auf Daten erlauben, auf die nicht zugegriffen werden sollte; Pufferüberlauf, der es den Leuten erlaubt, das System so zu kontrollieren, wie sie es eigentlich nicht dürften; Diensteverweigerungs-Angriffe, die behoben werden sollten, usw.). Die meisten sicherheitsrelevanten Fehler sollten außerdem auch auf den Schweregrad critical oder grave gesetzt werden.
upstream
Dieser Fehler bezieht sich auf Programm-Code des ursprünglichen Autors.
confirmed
Der Paketbetreuer hat den Fehlerbericht gelesen, verstanden und sieht ihn als korrekt an, hat den Fehler aber noch nicht behoben. (Die Benutzung dieser Markierung ist optional; sie ist hauptsächlich für Betreuer gedacht, die eine große Anzahl offener Fehler verwalten müssen.)
fixed-upstream
Der Fehler wurde vom Upstream-Betreuer behoben, ist aber noch nicht im Paket enthalten (aus welchem Grund auch immer: möglicherweise ist es zu kompliziert, die Änderungen zurückzuportieren, oder der Fehler ist zu gering, um sich darüber den Kopf zu zerbrechen).
fixed-in-experimental
Der Fehler wurde in dem Paket behoben, das in der Experimental-Distribution enthalten ist, aber noch nicht in der Unstable-Distribution.
d-i
Dieser Fehler ist für die Entwicklung des debian-installers relevant. Diese Markierung sollte verwendet werden, wenn der Fehler die Entwicklung des Debian-Installers beeinflusst, das Paket, das davon betroffen ist, aber kein direkter Teil des Installers selbst ist.
ipv6
Dieser Fehler beeinträchtigt die Unterstützung für das Internet-Protokoll Version 6.
lfs
Dieser Fehler beeinträchtigt die Unterstützung großer Dateien (über 2 Gigabyte).
l10n
Dieser Fehler ist für die Lokalisierung des Pakets relevant.
a11y
Dieser Fehler ist bezüglich der Barrierefreiheit des Pakets relevant.
ftbfs
Der Bau des Pakets aus dem Quellcode schlägt fehl. Wenn der Fehler einem Quellpaket zugewiesen ist, schlägt der Bau dieses Pakets fehl. Falls der Fehler einem Binärpaket zugewiesen ist, schlägt der Bau des dazugehörigen Quellpakets fehl. Diese Markierung kann auch für nicht-standardkonforme Build-Umgebungen angewandt werden (z.B. durch Verwendung von Build-Depends aus Experimental), allerdings sollte der Schweregrad in diesem Fall niedriger als serious sein (also: der Fehler ist nicht release-kritisch).
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
Dies sind Release-abhängige Markierungen, die zwei verschiedene Auswirkungen haben: Wenn sie für einen Fehler gesetzt werden, ist dieser Fehler nur noch für die entsprechende Veröffentlichung relevant (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, wenn deren Markierungen gesetzt sind), aber ansonsten gelten die normalen fehlerhaft/behoben/nicht-zutreffend-Regeln. Auch sollte dieser Fehler nicht archiviert werden, bis er in der entsprechenden Veröffentlichung behoben ist.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
Veröffentlichungskritische Fehler mit dieser Markierung sollen zum Zwecke der Veröffentlichung des entsprechenden Releases ignoriert werden. Diese Markierung sollte nur von Veröffentlichungsleitern verwendet werden; setzen Sie sie nicht selbst ohne deren ausdrückliche Berechtigung.

Ein Wort über die Bedeutung von Distributions-spezifischen Markierungen: die ignore-Markierungen ignorieren Fehler zum Zweck des Übergangs nach Testing. Die Veröffentlichungs-Markierungen zeigen an, dass der betreffende Fehler noch nicht archiviert werden soll, bis er in den durch die Markierungen bezeichneten Veröffentlichungen behoben wurde. Außerdem zeigen die Veröffentlichungs-Markierungen an, dass ein Fehler nur in den entsprechenden Veröffentlichungen als Fehler betrachtet wird. [Mit anderen Worten ist der Fehler in jeder Veröffentlichung nicht vorhanden, deren korrespondierende Markierung nicht gesetzt ist, wenn überhaupt Veröffentlichungs-Markierungen gesetzt sind. Ansonsten gelten die normalen found- und fixed-Regeln.]

Veröffentlichungs-Markierungen sollten nicht verwendet werden, wenn durch die korrekte Versionierung des Fehlers der gewünschte Effekt erreicht wird, weil sie manuell hinzugefügt und wieder gelöscht werden müssen. Wenn Sie unsicher sind, ob eine Veröffentlichungs-Markierung notwendig ist, wenden Sie sich an die Administratoren des Debian-Fehlerverwaltungssystems ([email protected]) oder an das Release-Team.

Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet haben

Wenn ein Entwickler einen Fehlerbericht an den Entwickler des Upstream-Quellpakets, von dem das Debian-Paket abstammt, weiterleitet, dann sollte er das in der Fehlerdatenbank wie folgt vermerken:

Stellen Sie sicher, dass das To-Feld Ihrer Nachricht an den Autor nur die Adresse(n) des Autors/der Autoren enthält; fügen Sie die Person, die den Fehler gemeldet hat, nnn[email protected] und nnn@bugs.debian.org in das CC-Feld ein.

Bitten Sie den Autor, das CC an nnn[email protected] beim Antworten stehen zu lassen, so dass die Fehlerdatenbank die Antwort des Autors mit dem Originalfehlerbericht zusammen protokollieren kann. Diese Nachrichten werden nur abgelegt und nicht weitergeleitet; um eine Nachricht normal zu senden, schicken Sie sie auch an nnn@bugs.debian.org.

Wenn die Fehlerdatenbank eine Nachricht an nnn-forwarded erhält, dann wird der relevante Fehler als weitergeleitet markiert, die Weiterleitungsadresse ist dann die Adresse aus dem To-Feld der Originalnachricht, die die Datenbank bekommt, falls der Fehler nicht bereits als weitergeleitet markiert ist.

Sie können auch die forwarded to-Information manipulieren, indem Sie eine Nachricht an [email protected] schicken.

Besitzer eines Fehlers ändern

Wenn die Person, die für die Fehlerbehebung verantwortlich ist, nicht der zugewiesene Betreuer des Pakets ist (zum Beispiel, wenn das Paket von einer Gruppe betreut wird), kann es nützlich sein, diese Tatsache im Fehlerverwaltungssystem festzuhalten. Um dabei zu helfen, kann jeder Fehler wahlweise einen Besitzer haben.

Der Besitzer kann beim Senden eines Fehlerberichts durch eine Owner-Zeile in den Pseudo-Kopfzeilen festgelegt werden (siehe die Anweisungen über das Berichten von Fehlern) oder durch die Verwendung der Befehle owner und noowner im Zusammenhang mit dem Control Request Server.

Falsch angezeigte Paketbetreuer

Wenn ein Paketbetreuer falsch angezeigt wird, dann liegt es meistens daran, dass sich der Paketbetreuer vor kurzem geändert hat und der neue Betreuer es versäumt hat, eine neue Version des Pakets mit einem abgeänderten Maintainer-Feld in der Kontrolldatei hochzuladen. Das wird behoben, sobald das Paket hochgeladen wird; als Alternative können die Archivbetreuer den Betreuereintrag per Hand ändern, zum Beispiel wenn ein neues Build oder ein erneutes Hochladen des Pakets in nächster Zukunft nicht zu erwarten ist. Setzen Sie sich mit [email protected] in Verbindung, um Änderungen an der override-Datei zu veranlassen.

Wiedereröffnung, Neuzuweisung und Manipulation von Fehlerberichten

Es ist möglich, Fehlerberichte anderen Paketen zuzuweisen, fälschlicherweise für geschlossen erklärte Fehler neu zu eröffnen, die Information über das Ziel der Weiterleitung (falls eine existiert) eines Fehlerberichts zu modifizieren, Schweregrade und Titel der Berichte zu ändern, den Besitzer eines Fehlers festzulegen, Fehlerberichte zu verschmelzen bzw. wieder auseinander zu ziehen und die Versionen des Paketes, in der der Fehler gefunden und in der er behoben wurde, festzuhalten. Das können Sie machen, indem Sie eine Nachricht an [email protected] senden.

Das Format dieser Nachrichten ist in einem anderen Dokument, das entweder im WWW oder in der Datei bug-maint-mailcontrol.txt verfügbar ist, beschrieben. Eine Volltextversion können Sie auch durch das Senden des Wortes help an den oben genannten Server erhalten.

Fehler abonnieren

Die Fehlerdatenbank erlaubt denen, die Fehler berichten sowie Entwicklern und anderen interessierten dritten Parteien, individuelle Fehler zu abonnieren. Diese Fähigkeit kann von Leuten verwendet werden, die ein Auge auf einen Fehler halten wollen, ohne das gesamte Paket über den Debian Package Tracker zu abonnieren. Alle Nachrichten, die bei nnn@bugs.debian.org empfangen werden, werden an die Abonnenten geschickt.

Ein Fehler kann durch Versand einer E-Mail an nnn[email protected] abonniert werden. Der Betreff und der Textkörper der E-Mail werden vom BTS ignoriert. Sobald diese Nachricht verarbeitet wurde, wird den Benutzern eine Bestätigung-E-Mail zugestellt, auf die sie antworten müssen, bevor ihnen die Nachrichten, die den Fehler betreffen, zugeschickt werden.

Es ist auch möglich, das Abonnement eines Fehlers zu beenden. Dies kann über eine E-Mail an nnn[email protected] erfolgen. Der Betreff und der Textkörper der E-Mail werden wieder vom BTS ignoriert. Den Benutzern wird eine Bestätigungsnachricht übersandt, die sie beantworten müssen, um das Abonnement des Fehlers zu beenden.

Standardmäßig wird die Adresse abonniert, die in der From-Kopfzeile gefunden wird. Falls Sie für eine andere Adresse den Fehler abonnieren wollen, müssen Sie die Adresse, auf die der Fehler abonniert werden soll, in die Abonnier-Nachricht kodieren. Dies erfolgt in der Form: nnn-subscribe-Lokalteil=beispiel.com@bugs.debian.org. Dieses Beispiel würde [email protected] eine Abonniermeldung für Fehler nnn schicken. Das @-Zeichen muss durch Änderung in ein =-Zeichen kodiert werden. Ähnlich nimmt die Beendigung des Abonnements die Form nnn-unsubscribe-Lokalteil=beispiel.com@bugs.debian.org an. In beiden Fällen werden der Betreff und der Textkörper der E-Mail an die E-Mail-Adresse, die in der Anforderung einkodiert ist, im Rahmen der Bestätigungsanfrage weitergeleitet.

Das mehr oder weniger veraltete subject-scanning-Feature

Nachrichten, die bei submit oder bei bugs ankommen und deren Betreffzeile mit Bug#nnn anfängt, werden so behandelt, als wären sie an nnn@bugs.debian.org geschickt worden. Das passiert, um Abwärtskompatibilität zu den Nachrichten, die von alten Adressen weitergeleitet wurden, zu erhalten, sowie dazu, Nachrichten abzufangen, die irrtümlich an submit geschickt wurden (z.B. durch das Benutzen der Allen antworten-Funktion des jeweiligen E-Mailprogramms).

Ein ähnliches Schema gilt auch für maintonly, done, quiet und forwarded, die ankommende E-Mails mit einer Betreff-Markierung so behandeln, als wären sie zu der entsprechenden nnn-wasauchimmer@bugs.debian.org-Adresse geschickt worden.

Nachrichten, die nur mit forwarded und done – das heißt ohne die Nummer des Fehlerberichts in der Adresse und ohne Fehlernummer in der Betreffzeile – verschickt werden, werden unter junk einsortiert und für ein paar Wochen gespeichert, ansonsten jedoch ignoriert.

Das veraltete X-Debian-PR: quiet-Feature

Früher war es möglich, die Fehlerdatenbank davon abzuhalten, die Nachrichten, die es an die debian-bugs Adresse bekam, irgendwohin weiterzuleiten, indem man die Zeile X-Debian-PR: quiet in die eigentlichen E-Mail-Kopfzeilen einfügte.

Diese Kopfzeile wird nun ignoriert. Stattdessen können Sie Ihre Nachricht an quiet oder nnn-quiet (oder maintonly bzw. nnn-maintonly) schicken.

Weitere Seiten der Fehlerdatenbank:

Debian BTS administrators <[email protected]>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.