Wie werden Fehler in Debian mit Reportbug berichtet?

Wir empfehlen nachdrücklich, dass Sie zum Berichten von Fehlern in Debian das Programm reportbug verwenden.

reportbug wird auf den meisten Systemen standardmäßig installiert. Falls es bei Ihnen nicht installiert ist, kann mit dem Paketmanagement-Werkzeug auf Ihrem System installiert werden.

reportbug kann über den entsprechenden Menüeintrag im Bereich System gestartet werden bzw. auf der Kommandozeile über reportbug.

Es wird Sie Schritt-für-Schritt durch den Prozess zum Berichten eines Fehlers leiten.

Falls Sie Fragen haben, die während der interaktiven Eingabeaufforderungen von Reportbug nicht geklärt werden können, können Sie in den Rest dieser Dokumentation schauen oder auf der deutschen Debian User-Mailingliste fragen.

Wie werden Fehler in Debian mittels E-Mail berichtet (und fortgeschrittener Einsatz von Reportbug)

Wichtige Dinge, die vor dem Abschicken zu beachten sind

Welches Paket ist von Ihrem Fehlerbericht betroffen?

Sie müssen wissen, zu welchem Paket Sie einen Fehler einreichen wollen. Schauen Sie sich dieses Beispiel an, um zu bestimmen, wie Sie diese Information finden (Sie werden diese Information dazu verwenden, um herauszufinden, ob Ihr Fehler bereits berichtet wurde).

Falls Sie nicht in der Lage sind, zu bestimmen, welches Paket für das Problem verantwortlich ist, senden Sie bitte eine E-Mail an die Mailingliste Debian-User und bitten um Hilfe. Diese Liste ist allerdings englischsprachig – falls Sie deutschsprachige Hilfe suchen, schicken Sie die E-Mail hingegen an die deutschsprachige Mailingliste Debian-User-German.

Falls das Problem nicht einfach nur ein Paket betrifft, sondern allgemeine Debian-Dienste, gibt es einige Pseudo-Pakete oder sogar Mailinglisten, die Sie stattdessen verwenden können, um Ihre Nachrichten an uns weiterzuleiten.

Wurde Ihr Fehlerbericht bereits gemeldet?

Sie sollten vor dem Abschicken überprüfen, ob Ihr Fehler bereits von jemandem anderen berichtet wurde. Die für ein spezielles Paket eingereichten Fehler können Sie mit der Paket-Option des Fehler-Suchformulars einsehen. Falls es bereits einen existierenden Fehlerbericht #<Nummer> gibt, sollten Sie Ihre Kommentare per E-Mail an <Nummer>@bugs.debian.org senden, statt einen neuen Fehler zu berichten.

Schicken Sie mehrere Berichte für mehrere Fehler

Vermeiden Sie es bitte, mehrere, in keiner Beziehung zueinander stehende Fehler – besonders welche, die in verschiedenen Paketen vorkommen – in einer einzigen Nachricht zu verschicken.

Reichen Sie Fehler nicht bei den Originalautoren ein

Falls Sie einen Fehler in Debian melden, senden Sie bitte selber keine Kopie an die Originalautoren, da es möglich ist, dass der Fehler nur in Debian selbst existiert. Falls notwendig, wird der Betreuer des Pakets den Fehler an die Originalautoren weiterleiten.

Fehlerberichte per E-Mail melden

Sie können Fehler berichten, indem Sie eine E-Mail an submit@bugs.debian.org, schicken, verwenden Sie dafür das unten aufgeführte spezielle Format. reportbug (siehe oben) wird Ihre E-Mail für Sie korrekt formatieren; bitte verwenden Sie es! Bitte schreiben Sie die E-Mail auf Englisch, da die meisten Entwickler kein Deutsch verstehen (gebrochenes Englisch ist kein Problem). Debian ist eine internationale Distribution mit Mitarbeiten aus vielen Ländern, so dass die verwendete Sprache meistens Englisch ist.

Kopfzeilen (Header)

Wie in jeder anderen E-Mail auch sollten Sie eine klare, beschreibende Betreff-Zeile in Ihren E-Mail-Kopfzeilen haben. Diese Betreffzeile wird später in der Fehlerdatenbank als ursprünglicher Titel des von Ihnen übermittelten Programmfehlers fungieren, also versuchen Sie sie bitte so informativ wie nur möglich zu machen!

Falls Sie eine Kopie ihres Fehlerberichts an weitere Empfänger (wie zum Beispiel Mailinglisten) schicken wollen, sollten Sie nicht die üblichen E-Mail-Kopfzeilen verwenden, sondern eine andere Methode, die weiter unten beschrieben wird.

Pseudo-Kopfzeilen

Der erste Teil des Fehlerberichts sind die Pseudo-Kopfzeilen, die Informationen über das Paket enthalten sowie die Version, auf die sich Ihr Fehlerbericht bezieht. Die erste Zeile des Textkörpers muss eine Pseudo-Kopfzeile enthalten. Sie sollte wie folgt lauten:

Package: <Paketname>

Ersetzen Sie <Paketname> durch den Namen des von dem Fehler betroffenen Pakets.

Die zweite Zeile der Nachricht soll folgendermaßen aussehen:

Version: <Paket-Version>

Ersetzen Sie <Paket-Version> durch die betroffene Version des Paketes. Bitte fügen Sie hier außer der Version keinen weiteren Text hinzu, da die Fehlerdatenbank auf dieses Feld angewiesen ist, um herauszufinden, welche Veröffentlichungen von diesem Fehler betroffen sind.

Sie müssen eine korrekte Package-Zeile in den Pseudo-Kopfzeilen angeben, damit die Fehlerdatenbank die Nachricht an den Paketbetreuer zustellen kann. Lesen Sie dieses Beispiel für Hinweise, wie Sie diese Information finden können.

Weitere gültige Pseudo-Kopfzeilen finden Sie unter Weitere Pseudo-Kopfzeilen.

Der Inhalt des Berichts

Bitte fügen Sie in Ihren Bericht noch Folgendes ein:

Berichten Sie über alle Einzelheiten, die Ihnen wichtig erscheinen, Sie laufen kaum Gefahr, Ihren Fehlerbericht wegen zu vieler Informationen zu lang werden zu lassen. Falls die Dateien, mit denen Sie das Problem reproduzieren konnten, klein sind, dann fügen Sie deren Inhalt in den Bericht ein (falls die Dateien groß sind, könnten Sie sie auf einer öffentlich-zugänglichen Webseite zur Verfügung stellen).

Für weitere Hinweise, wie man den Entwicklern dabei helfen kann, die Probleme zu lösen, lesen Sie bitte Wie man Fehler effektiv meldet.

Beispiel eines Fehlerberichts

Ein Fehlerbericht mit Kopfzeilen und Pseudo-Kopfzeilen sieht ungefähr so aus:

  To: submit@bugs.debian.org
  From: diligent@testing.linux.org
  Subject: Hello says `goodbye'

  Package: hello
  Version: 1.3-16

  When I invoke `hello' without arguments from an ordinary shell
  prompt it prints `goodbye', rather than the expected `hello, world'.
  Here is a transcript:

  $ hello
  goodbye
  $ /usr/bin/hello
  goodbye
  $

  I suggest that the output string, in hello.c, be corrected.

  I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13
  and libc6 2.1.3-10.

Versenden von Kopien der Fehlerberichte an andere Adressen

Manchmal ist es nötig, eine Kopie des Fehlerberichts an eine andere Adresse außer debian-bugs-dist und der Adresse des Paketbetreuers zu verschicken (normalerweise sind das die zwei Adressen, an die ein Fehlerbericht geschickt wird).

Das können Sie tun, indem Sie Ihren Fehlerbericht als Kopie (CC) an die anderen Adressen verschicken. In diesem Fall würden die anderen Kopien jedoch in ihrem Reply-To-Feld und in der Betreff-Zeile keine Nummer des Fehlerberichts haben. Wenn die Empfänger auf den Fehlerbericht antworten, werden sie wahrscheinlich den Eintrag submit@bugs.debian.org in ihren Kopfzeilen lassen und somit die Nachricht zu einem neuen Fehlerbericht machen. Das führt zu vielen doppelt eingereichten Berichten.

Um es richtig zu machen, sollte die Pseudo-Kopfzeile X-Debbugs-CC verwendet werden. Fügen Sie eine Zeile wie diese zu den Pseudo-Kopfzeilen Ihrer Nachricht hinzu:

 X-Debbugs-CC: other-list@cosmic.edu

Das veranlasst die Fehlerdatenbank dazu, eine Kopie Ihres Fehlerberichts an die Adresse(n) in der X-Debbugs-CC-Zeile sowie an debian-bugs-dist zu senden.

Wenn Sie auf diese Art Kopien an mehr als eine Adresse schicken möchten, fügen Sie diese durch Kommas getrennt in eine einzige X-Debbugs-CC-Zeile ein.

Vermeiden Sie es, auf solche Art Kopien an Adressen anderer Fehlerberichte zu senden. Diese werden durch Prüfungen abgefangen, um E-Mail-Schleifen zu verhindern. Es gibt auch kaum einen Grund, X-Debbugs-CC für solche Kopien zu verwenden, da so die Fehlernummer, die durch diesen Mechanismus eingefügt wird, direkt durch eine andere ersetzt wird; benutzen Sie stattdessen normale CC-Kopfzeilen.

Diese Funktionalität kann oft sinnvoll mit quiet kombiniert werden – Einzelheiten dazu finden Sie weiter unten.

Weitere Pseudo-Kopfzeilen

Schweregrade

Ob es sich im Fehlerbericht um einen besonders schweren Fehler oder lediglich um einen Wunsch nach neuer Funktionalität handelt, können Sie beim Abschicken Ihres Berichts über den Schweregrad festlegen. Dies ist allerdings nicht zwingend notwendig, der Paketbetreuer wird den passenden Schweregrad festlegen, wenn Sie es nicht tun (oder den falschen Schweregrad wählen).

Um einen Schweregrad festzulegen, fügen Sie eine Zeile wie die folgende zu den Pseudo-Kopfzeilen hinzu:

Severity: <Schwere>

Ersetzen Sie <Schwere> durch einen der vorhandenen Schweregrade, wie sie in der weiterführenden Dokumentation beschrieben sind.

Markierungen zuweisen

Sie können einen Fehler mit Markierungen (Tags) versehen, wenn Sie ihn melden. Falls Sie zum Beispiel einen Patch mit Ihrem Fehlerbericht mitschicken, möchten Sie wohl die patch-Markierung setzen. Dies ist jedoch keine zwingende Notwendigkeit, die Entwickler werden ihren Bericht mit Markierungen versehen, wenn dies angebracht ist.

Um Markierungen zu setzen, fügen Sie eine Zeile wie die folgende zu den Pseudo-Kopfzeilen hinzu:

Tags: <Markierungen>

Ersetzen Sie <Markierungen> durch eine oder mehrere der verfügbaren Markierungen, wie sie in der Dokumentation für Entwickler beschrieben sind. Wenn Sie mehrere Markierungen angeben wollen, können Sie diese mit Kommata, Leerzeichen oder beidem trennen.

User: <Benutzername>
Usertags: <Benutzermarkierungen>

Ersetzen Sie <Benutzermarkierungen> durch einen oder mehrere Usertags. Trennen Sie mehrere Markierungen mit Kommata, Leerzeichen oder beidem. Falls Sie einen <Benutzernamen> angeben, werden die Markierungen für diesen Benutzer gesetzt. Andernfalls wird die E-Mail-Adresse des Absenders als Benutzername verwendet.

Sie können auch direkt beim Einreichen des Fehlerberichts mehrere Benutzermarkierungen für verschiedene Benutzer setzen, indem Sie mehrere User-Pseudo-Kopfzeilen einfügen; jede Usertags-Pseudo-Kopfzeile gilt dabei für die jeweils vorangehende User-Zeile. Dies kann insbesondere nützlich sein, um Benutzermarkierungen für ein Team mit mehreren Mitgliedern zu setzen, oder für mehrere Teams oder auch wenn Sie die Architektur-Usertags für Fehler setzen möchten, die mehrere Architekturen betreffen. 

User: <erster Benutzername>
Usertags: <Markierungen für ersten Benutzer>
User: <zweiter Benutzername>
Usertags: <Markierungen für zweiten Benutzer>

Auf Forwarded (weitergeleitet) setzen

Forwarded: foo@example.com

markiert den frisch eingereichten Fehler als weitergeleitet an foo@example.com. Lesen Sie für weitere Details Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet haben in der Entwickler-Dokumentation.

Verantwortlichkeit einfordern

Owner: foo@example.com

zeigt an, dass foo@example.com jetzt für die Korrektur dieses Fehlers verantwortlich ist. Lesen Sie für weitere Details Änderung des Eigentümers des Fehlers in der Entwickler-Dokumentation.

Quellpaket

Source: foopackage

das Äquivalent zu Package: für Fehler, die im Quellpaket des Paketes foopackage vorhanden sind; für die meisten Fehler in vielen Paketen brauchen Sie diese Option nicht zu verwenden.

Kontrollbefehle

Control: control commands

Erlaubt die Möglichkeit, dass Befehle, die eigentlich an control@bugs.debian.org geschickt werden müssten, auch funktionieren, wenn sie an submit@bugs.debian.org oder nnn@bugs.debian.org gesendet werden. Die Angabe -1 bezieht sich zunächst auf den aktuellen Fehler (das bedeutet auf den Fehler, der über eine Mail an submit@ erstellt wird oder an den per nnn@ die Nachricht geschickt wird). Lesen Sie bitte die Dokumentation zum E-Mail-Server für Kontrolle und Manipulation bezüglich weiterer Informationen, welche Kontrollbefehle zulässig sind.

Zum Beispiel würden folgende Pseudo-Kopfzeilen in einer Nachricht, die an 12345@bugs.debian.org gesendet wird

Control: retitle -1 this is the title
Control: severity -1 normal
Control: summary -1 0
Control: forwarded -1 https://bugs.debian.org/nnnnnn

dazu führen, dass 12345 umbenannt, sein Schweregrad geändert, seine Zusammenfassung gesetzt und der Fehler als Weitergeleitet markiert wird.

X-Debbugs-Kopfzeilen

Und schlußendlich: Sollte Ihr MUA das Bearbeiten von Kopfzeilen nicht erlauben, können Sie die verschiedenen X-Debbugs--Kopfzeilen auch als Pseudo-Kopfzeilen setzen.

Zusätzliche Informationen

Verschiedene Meldungsadressen (unbedeutende oder vielfache Fehlerberichte)

Falls ein Fehlerbericht eher unbedeutend ist (zum Beispiel ein Tippfehler in der Dokumentation oder ein unbedeutendes Build-Problem), passen Sie den Schweregrad entsprechend an und schicken Sie ihn an maintonly@bugs.debian.org anstatt submit@bugs.debian.org. maintonly leitet den Fehlerbericht nur an den Paketbetreuer weiter, er wird nicht an die Fehlerdatenbank-Mailingliste weitergeleitet.

Falls Sie mehrere Berichte auf einmal haben, sollten Sie auf jeden Fall maintonly@bugs.debian.org verwenden, um nicht zu viel redundanten E-Mail-Verkehr auf der Fehlerdatenbank-Mailingliste zu verursachen. Vor dem Abschicken vieler ähnlicher Fehler sollten Sie auch eine Zusammenfassung an debian-bug-dist schicken.

Falls Sie einen Fehler an die Fehlerdatenbank schicken wollen, der bereits an den Paketbetreuer geschickt wurde, können Sie quiet@bugs.debian.org verwenden. Fehler, die an quiet@bugs.debian.org geschickt werden, werden nirgendwohin weitergeleitet, sondern lediglich abgelegt.

Wenn Sie verschiedene E-Mail-Adressen für das Einreichen von Fehlern verwenden, wird von der Fehlerdatenbank das Reply-To jeder weitergeleiteten Nachricht so gesetzt, dass Antworten genauso bearbeitet werden wie der Originalbericht. Das bedeutet zum Beispiel, dass Antworten an maintonly an nnn-maintonly@bugs.debian.org statt an nnn@bugs.debian.org geschickt werden, außer jemand ändert dies manuell.

Empfangsbestätigungen

Üblicherweise schickt die Fehlerdatenbank Ihnen eine Empfangsbestätigung per E-Mail, wenn Sie einen neuen Fehler berichten oder zusätzliche Informationen zu einem vorhandenen Fehler einsenden. Falls Sie diese Bestätigung unterdrücken wollen, fügen Sie eine X-Debbugs-No-Ack-Kopfzeile oder Pseudokopfzeile in Ihre E-Mail ein (der Inhalt dieser Kopfzeile ist egal). Falls Sie einen neuen Bericht mit dieser Kopfzeile einsenden, müssen Sie selbst das Web-Interface bemühen, um später die Fehlernummer herauszufinden.

Beachten Sie, dass diese Kopfzeile keine Empfangsbestätigungen des control@bugs.debian.org Mailservers unterdrückt, da diese Bestätigungen Fehlermeldungen enthalten könnten, die gelesen und entsprechend behandelt werden sollten.

Spam-Bekämpfung und fehlende E-Mails

Die Fehlerdatenbank implementiert einen recht umfangreichen Satz an Regeln, um sicherzustellen, dass Spam es nicht ins BTS schafft. Obwohl wir die Anzahl fälschlich positiv-erkannter Mails zu reduzieren versuchen, passiert dies dennoch. Falls Sie annehmen, dass Ihre E-Mail fälschlicherweise als positiv erkannt wurde, nehmen Sie zwecks Hilfe bitte mit owner@bugs.debian.org Kontakt auf. Ein weiterer, häufiger Grund für E-Mails, die es nicht ins BTS schaffen, ist die Verwendung von Adressen, die auf FROM_DAEMON von Procmail passen. Hierzu gehören E-Mail von Adressen wie mail@foobar.com. Falls Sie vermuten, dass Ihre E-Mail auf FROM_DAEMON passt, lesen Sie zum Überprüfen procmailrc(5) und schicken Sie die E-Mail erneut von einer Adresse, die nicht auf FROM_DAEMON passt.

Fehlerberichte bei unbekannten Paketen

Falls die Fehlerdatenbank den Betreuer des angegebenen Pakets nicht kennt, dann wird sie den Bericht an debian-bugs-dist weiterleiten, auch wenn die maintonly-Markierung verwendet wurde.

Wenn Sie etwas an maintonly@bugs.debian.org oder nnn-maintonly@bugs.debian.org schicken, sollten Sie sicherstellen, dass der Bericht das richtige Paket erreicht, indem Sie beim Verschicken des Originalfehlerberichts das Feld Package korrekt angeben oder indem Sie den control@bugs.debian.org-Dienst nutzen, um den Bericht im Nachhinein passend zuzuordnen.

Benutzen von dpkg, um den Paketnamen und die Version herauszufinden

Wenn Sie reportbug verwenden, um einen Fehler in einem Befehl zu berichten, sagen wir in grep, wird folgender Befehl automatisch das richtige Paket auswählen und Ihnen ermöglichen, sofort mit dem Bericht loszuschreiben: reportbug --file $(which grep)

Sie können auch herausfinden, durch welches Paket es installiert wurde, indem Sie dpkg --search verwenden. Die Versionsnummer des installierten Paketes ermitteln Sie mit dpkg --list oder dpkg --status.

Zum Beispiel:

$ which apt-get
/usr/bin/apt-get
$ type apt-get
apt-get is /usr/bin/apt-get
$ dpkg --search /usr/bin/apt-get
apt: /usr/bin/apt-get
$ dpkg --list apt
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Säubern/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
|/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: GROSS=schlecht)
||/ Name           Version        Beschreibung
+++-==============-==============-============================================
ii  apt            0.3.19         Advanced front-end for dpkg
$ dpkg --status apt
Package: apt
Status: install ok installed
Priority: standard
Section: base
Installed-Size: 1391
Maintainer: APT Development Team <deity@lists.debian.org>
Version: 0.3.19
Replaces: deity, libapt-pkg-doc (<< 0.3.7), libapt-pkg-dev (<< 0.3.7)
Provides: libapt-pkg2.7
Depends: libapt-pkg2.7, libc6 (>= 2.1.2), libstdc++2.10
Suggests: dpkg-dev
Conflicts: deity
Description: Advanced front-end for dpkg
 This is Debian's next generation front-end for the dpkg package manager.
 It provides the apt-get utility and APT dselect method that provides a
 simpler, safer way to install and upgrade packages.
 .
 APT features complete installation ordering, multiple source capability
 and several other unique features, see the Users Guide in
 /usr/doc/apt/guide.text.gz

Weitere nützliche Befehle und Pakete

Das querybts-Werkzeug, das im selben Paket wie reportbug enthalten ist, bietet eine komfortable Text-basierte Schnittstelle zur Fehlerdatenbank.

Emacs-Benutzer können auch das debian-bug-Kommando benutzen, das vom debian-el-Paket zur Verfügung gestellt wird. Wenn es mit M-x debian-bug aufgerufen wird, fragt es alle nötigen Informationen ab, ähnlich wie reportbug.

Weitere Seiten der Fehlerdatenbank:

Debian BTS administrators <owner@bugs.debian.org>

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