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 [email protected], 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:

Den exakten und vollständigen Text aller Fehlermeldungen, die ausgegeben oder protokolliert wurden. Das ist sehr wichtig!
Was Sie genau eingetippt oder gemacht haben, als der Fehler auftrat.
Eine Beschreibung des fehlerhaften Verhaltens der Software: Welches Verhalten haben Sie erwartet und was haben Sie tatsächlich beobachtet. Eine Kopie einer Beispielsitzung ist ein guter Weg, so etwas vorzuzeigen.
Korrekturvorschlag oder sogar einen Patch, falls Sie einen haben.
Details der Konfiguration des Programms, das das/die Problem(e) verursacht. Fügen Sie den kompletten Text der Konfigurationsdateien mit ein.
Die Version beliebiger Pakete, von denen das fehlerhafte Paket abhängt.
Welche Kernel-Version Sie benutzen (uname -a), Ihre Shared-C-Bibliothek (ls -l /lib/*/libc.so.6 oder apt show libc6 | grep ^Version) und, falls angebracht, beliebige andere Details über Ihr Debian-System. Falls Sie zum Beispiel ein Problem mit einem Perl-Skript hatten, dann sollten Sie die Version der perl-Binärdatei mit angeben (perl -v oder dpkg -s perl | grep ^Version:).
Relevante Einzelheiten über die Hardware in Ihrem System. Falls Sie ein Problem mit einem Gerätetreiber melden, dann listen Sie bitte alle Hardware-Komponenten Ihres Systems auf, da solche Probleme oft von IRQ- und E/A-Adresskonflikten herrühren.
Falls bei Ihnen reportbug installiert ist, hilft die Ausgabe von reportbug --template -T none -s none -S normal -b --list-cc none -q <Paket>, da es die Ausgabe der Skripte des Paketbetreuers sowie Versionsinformationen enthält.

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: [email protected]
  From: [email protected]
  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 [email protected] 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: [email protected]

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: [email protected]

markiert den frisch eingereichten Fehler als weitergeleitet an [email protected]. Lesen Sie für weitere Details Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet haben in der Entwickler-Dokumentation.

Verantwortlichkeit einfordern

Owner: [email protected]

zeigt an, dass [email protected] 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 [email protected] geschickt werden müssten, auch funktionieren, wenn sie an [email protected] oder [email protected] 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 [email protected] 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 [email protected] anstatt [email protected]. 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 [email protected] 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 [email protected] verwenden. Fehler, die an [email protected] 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[email protected] 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 [email protected] 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 [email protected] 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 [email protected]. 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 [email protected] oder nnn[email protected] 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 [email protected]-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 <[email protected]>
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 <[email protected]>