33.3. Bugreports anzeigen

33.3.1. Hintergrundwissen

Allgemein gesprochen, ist ein Bugreport ein Fehlerbericht zu einem aufgetretenen bzw. von Ihnen bemerkten Fehler einer Soft- oder Hardware. Bei Debian ist der Bericht und dessen Einreichung vom Ablauf und der Form her standardisiert, damit dieser entdeckte Fehler möglichst automatisiert über das 'Debian Bug Tracking System (Debian BTS) [Debian-Bug-Tracking-System] verarbeitet und von allen Benutzern nachverfolgt werden kann. Somit ordnen Sie einen Fehlerbericht leichter einem bestimmten Paket oder einer spezifischen Systemkonstellation zu.

Generelles Ziel ist dabei, die bereits bestehenden Softwarepakete zu verbessern und auch noch nicht als stabil gekennzeichnete Pakete auf Fehler hin zu überprüfen und zu bereinigen. Dazu zählen auch Verstöße gegen (Debian)Richtlinien und Qualitätsvorgaben. Vor der Bereitstellung (Veröffentlichung) eines Pakets wird dann automatisch geprüft, ob das Paket den Anforderungen (Richtlinien) entspricht.

Weiterhin zählt dazu auch eine Prüfung auf kritische Fehler vor der Installation eines Pakets. apt-get wertet dazu das Ergebnis von apt-listbugs (siehe Abschnitt 33.3.2, „Bugreports mit apt-listbugs lesen“) aus und warnt Sie, falls für das Paket kritische Fehler im Debian BTS hinterlegt sind. Die Entscheidung liegt dann bei Ihnen, ob Sie das Paket wirklich installieren möchten oder lieber nicht.

An der Recherche nach Fehlern darf sich jeder Debian-Benutzer beteiligen. Dafür benutzen Sie das Debian BTS, um darin einerseits nach bestehenden Softwarefehlern und deren Lösungen zu recherchieren und andererseits weitere Fehler zu berichten, die Ihnen aufgefallen sind. Für ersteres muss das ganze reproduzierbar sein und es darf sich nicht um einen Bedienfehler handeln.

Wie bereits oben benannt, finden Sie bereits bekannte und eingetragene Fehler in der Fehlerdatenbank des Debian BTS. Über das webbasierte System suchen Sie anhand des Paketnamens, der Veröffentlichung, des Schweregrads, der Betreffzeile des Fehlerberichts, der Fehlernummer, dem Namen des Einreichenden, dem Status der Bearbeitung des Fehlers oder dem Bearbeiter — also demjenigen, der sich um die Bereinigung des Fehlers kümmert. Auf der Kommandozeile stehen Ihnen die Werkzeuge lintian (siehe Abschnitt 33.1, „Nicht installierte Pakete mit lintian prüfen“), apt-listbugs (siehe Abschnitt 33.3.2, „Bugreports mit apt-listbugs lesen“) und popbugs (siehe Abschnitt 33.3.4, „Release-kritische Fehler mit popbugs finden“) zur Verfügung.

Finden Sie einen Fehler bezüglich eines Debianpakets, schreiben Sie am besten einen Fehlerbericht (bug report). Eine ausführliche Beschreibung dessen, auf welche Punkte Sie bei dem Fehlerbericht wertlegen sollten, finden Sie auf der Webseite des Debian BTS. Bei der Zusammenstellung des Fehlerberichts hilft Ihnen das Werkzeug reportbug aus dem gleichnamigen Debianpaket [Debian-Paket-reportbug].

33.3.2. Bugreports mit apt-listbugs lesen

Die generelle Idee zu dem Werkzeug apt-listbugs aus dem gleichnamigen Debianpaket [Debian-Paket-apt-listbugs] ist, Fehlerberichte aus dem Debian BTS abzurufen. Wie wir bereits zuvor in Abschnitt 33.3.1, „Hintergrundwissen“ angerissen haben, ist das Werkzeug in den Ablauf zur Aktualisierung und Installation eines Pakets mit APT integriert. Es prüft in diesem Zusammenhang automatisch mit, ob im Debian BTS Fehler für das betreffende Paket vorliegen und diese bereits repariert wurden.

Darüberhinaus können Sie das Werkzeug auch direkt über die Kommandozeile aufrufen und sich eine Liste der registrierten Fehler ausgeben lassen. apt-listbugs akzeptiert dafür die folgenden Schalter (Auswahl):

-s Schweregrad (Langform --severity)
Fehler je nach Schweregrad eingrenzen. Möglich sind die Werte critical (kritisch), grave (sehr schwerwiegend), serious (schwerwiegend), important (wichtig), normal (normal), minor (weniger relevant), wishlist (Wunschliste) und all (alle Schweregrade). Mehrere Werte trennen Sie mittels Komma voneinander. Der Standardwert ist die Kombination der drei erstgenannten Werte critical,grave,serious.

-T Schlüsselworte (Langform --tags)
Filtere die Fehlermeldungen anhand des gegebenen Schlüsselworts. Mehrere Werte trennen Sie mittels Komma voneinander.

-S Status (Langform --stats)
Filtere und sortiere die Fehlerberichte anhand des aktuellen Status. Mögliche Statuswerte sind pending (offener Fehler), forwarded (der Fehlerbericht ist als weitergeleitet markiert), pending-fixed (der Fehlerbericht ist als gelöst markiert, aber noch ohne Bestätigung), fixed (der Fehlerbericht ist markiert als gelöst), absent (in der angefragten Veröffentlichung bzw. Architektur existiert der Fehler nicht) und done (für die angefragte Veröffentlichung bzw. Architektur ist der Fehler gelöst).

-B Fehlernummer (Langform --bugs)
Filtere die Fehlerberichte anhand der gegebenen Nummer des Fehlerberichts und zeige nur die betreffenden an. Mehrere Werte trennen Sie mittels Komma voneinander.

-D (Langform --show-downgrade)
Zeige nur die Fehlerberichte für Pakete an, für die ein Downgrade erfolgt ist (siehe auch Abschnitt 8.40, „Pakete downgraden“).

-P Priorität (Langform --pin-priority)
Benutze die Pin-Priorität als Filterkriterium (siehe Kapitel 20, Veröffentlichungen mischen für weitere Informationen zur Pin-Priorität).

Als weiteren Wert zum Aufruf benötigt apt-listbugs noch ein Kommando. Zur Auswahl stehen apt, list und rss. Bei ersterem liest apt-listbugs von stdin, bei list erwartet es die Paketnamen als Argumente zum Aufruf und bei letzterem im RSS-Format. Den Abschluss des Aufrufs bildet der Paketname, an den Sie zudem eine spezifische Paketversion anfügen können. Als Trennzeichen fungiert hier der Schrägstrich, sodass bspw. die Spezifikation für das Paket apt-listbugs in der Version 0.1.5 apt-listbugs/0.1.5 lautet.

Berichtete Fehler zum Paket coreutils auflisten. 

$ apt-listbugs -s critical,grave,serious list coreutils
Laden der Fehlerberichte ... Erledigt
»Found/Fixed«-Informationen werden ausgewertet ... Erledigt
grave Fehler von coreutils (-> ) <ungelöst>
 #743955 - coreutils: corrupted files on heavily fragmented ext3 and ext4 partitions
Zusammenfassung:
 coreutils(1 Fehler)
$

33.3.3. Ergänzende Bugreports mit apt-listchanges herausfiltern

Während Ihnen apt-listbugs alle Bugreports anzeigt, vergleicht apt-listchanges aus dem gleichnamigen Paket [Debian-Paket-apt-listchanges] die Änderungen zwischen dem lokal installierten Paket und der neuen, verfügbaren Version auf dem Spiegelserver. Dazu wertet es die beiden Dateien NEWS.Debian und changelog.gz bzw. changelog.Debian.gz aus.

Die Ausgabe von apt-listchanges steuern Sie dabei über mehrere Schalter (Auswahl):

-a (Langform --all)
Ausgabe aller Änderungen des Pakets.

-f Ausgabegerät (Langform --frontend)
Legt fest, an welches Ausgabegerät bzw. welche Ausgabeform apt-listchanges benutzt. Möglich sind derzeit pager, browser, xterm-pager, xterm-browser (für die Darstellung in einem Textbrowser in ihrem Terminal), text, mail (Versand als Email), gtk (graphische Darstellung) und none (keine Ausgabe).

--reverse
Ausgabe der Änderungen in zeitlich umgekehrter Reihenfolge.

--since=version
Ausgabe aller Änderungen ab der angegebenen Version des Pakets.

-v (Langform --verbose)
Ausgabe in ausführlicher Form.

--which=(news|changelogs|both):: Wählt aus, welche Änderungen angezeigt werden. news schränkt auf NEWS.Debian ein, changelogs hingegen auf changelog.Debian. both wählt beide Informationsquellen aus.

Im nachfolgenden Beispiel sehen Sie den Aufruf für das Paket ruby-json, wobei die Ausgabe als einfacher Text im Terminal erfolgt.

Aufrufbeispiel für apt-listchanges

# apt-listchanges -f text --which=both /var/cache/apt/archives/ruby-json_1.7.3-3_i386.deb
Lese Changelogs...
ruby-json (1.7.3-3) unstable; urgency=high

  * set urgency to high, as a security bug is fixed.
  * Add 10-fix-CVE-2013-0269.patch, adapted from upstream to fix denial of
    service and unsafe object creation vulnerability.
    [CVE-2013-0269] (Closes: #700436).

 -- Cédric Boutillier <cedric.boutillier@gmail.com>  Tue, 12 Feb 2013 23:14:48 +0100
...
#

33.3.4. Release-kritische Fehler mit popbugs finden

Mit dem Werkzeug popbugs aus dem Paket debian-goodies [Debian-Paket-debian-goodies] finden Sie release-kritische Fehler („release critical bugs“, abgekürzt mit RC bugs) in Paketen, die Sie hauptsächlich einsetzen. Dazu bezieht popbugs zunächst die Liste der RC bugs vom Debian BTS von der URL https://bugs.debian.org/release-critical/other/all.html und gleicht danach die gefundenen Fehler mit den Paketen ab, die auf ihrem System installiert sind. Beachten Sie daher, dass das Programm darauf aufbaut und für brauchbare Ergebnisse eine Internetverbindung benötigt. Die Grundlage des nachfolgenden, lokalen Vergleichs ist der allgemeine Installationsgrad der Debianpakete und die gesammelten Daten des popularity contest.

Abbildung 33.2, „Auflistung der bekannten, kritischen Fehler nach der Analyse von popbugs zeigt das Ergebnis der Recherche nach dem Aufruf von popbugs auf einem Debian 7 Wheezy in einem Browserfenster an (ohne Angabe von zusätzlichen Parametern etc.). Rufen Sie das Programm stattdessen über den Schalter -o gefolgt von einem Dateinamen zur Ausgabe auf, speichert popbugs die Auflistung als Datei unter dem angegebenen Pfad. Die Alternativschreibweise ist --output=Ausgabedatei.

Aufruf von popbugs und Ausgabe in die lokale Datei fehlerliste.html

$ popbugs -ofehlerliste.html
$

Sie erhalten jeweils eine direkte Verbindung zur Debian BTS mit einer paketweisen Auflistung. Weitere Informationen bekommen Sie, indem Sie in der Ausgabe auf einen mit einem Link hinterlegten Paketnamen klicken.

Abbildung 33.2. Auflistung der bekannten, kritischen Fehler nach der Analyse von popbugs

praxis/qualitaetskontrolle/bugreports-anzeigen/popbugs.png

33.3.5. Release-kritische Fehler mit rc-alert finden

Das Werkzeug rc-alert aus dem Paket devscripts [Debian-Paket-devscripts] leitet seinen Namen aus den beiden Anfangsbuchstaben von release critical (dt. veröffentlichungskritisch) und dem Begriff alert (dt. Alarm, Warnung oder Meldung) ab. Inhaltlich folgt es dabei dem gleichen Ziel wie popbugs (siehe Abschnitt 33.3.4, „Release-kritische Fehler mit popbugs finden“) und sucht dabei ebenfalls nach RC bugs vom Debian BTS über die URL https://bugs.debian.org/release-critical/other/all.html. Für brauchbare Ergebnisse benötigt es ebenso eine Internetverbindung.

rc-alert hebt sich von popbugs mit einigen Besonderheiten ab. Dazu gehört u.a. eine distributionsspezifische Suche und die Filterung der Paketliste anhand von Debtags (siehe Kapitel 13, Erweiterte Paketklassifikation mit Debtags).

Nachfolgend sehen Sie die Arbeitsweise von rc-alert anhand des Pakets apt. Das Ergebnis umfasst neben der Nummer des Bugreports (Bug) dessen Titel (Title), die hinterlegten Flags (Flags) und die Veröffentlichung, für die der Fehler relevant ist (Dists). Der erste Bug gilt nur für Debian stable, während der zweite Bug für zukünftige Veröffentlichungen auf der Basis von Debian testing und unstable wichtig ist. Als Kennzeichnung für eine Veröffentlichung sind für Debian oldstable (O), stable (S), testing (T) und unstable (U) in Verwendung.

Einfache Suche nach RC bugs für das Paket apt mit Hilfe von rc-alert (Ausschnitt). 

$ rc-alert apt
Package: apt
Bug:     558784
Title:   apt: re-adds removed keys
Flags:   [       I] (lenny-ignore or squeeze-ignore)
Dists:   [S] (stable)

...

Package: apt
Bug:     776910
Title:   apt: upgrade from wheezy to jessie breaks in the middle
Flags:   [        ] (none)
Dists:   [TU] (testing, unstable)

$

Möchten Sie die Recherche auf eine bestimmte Veröffentlichung einschränken, helfen Ihnen dabei die beiden Schalter -d (Langform --include-dists) und -o (Langform --include-dist-op). Mit ersterem spezifizieren Sie über die o.g. Kennzeichnung die von Ihnen gewünschten Veröffentlichungen, so bspw. --include-dists TUE für Debian testing unstable und experimental. Damit erhalten Sie zunächst alle Fehler, die entweder in den Veröffentlchungen Debian testing, unstable oder experimental auftreten.

Suche über die Angabe der Veröffentlichung (Variante 1). 

# rc-alert --include-dists TUE apt
Package: apt
Bug:     771428
Title:   apt tries to configure dbus before libdbus-1-3, fails to upgrade
Flags:   [        ] (none)
Dists:   [TUE] (testing, unstable, experimental)

Package: apt
Bug:     774924
Title:   apt: Jessie version cannot find upgrade path (but Wheezy version can)
Flags:   [ +      ] (patch)
Dists:   [E] (experimental)

Package: apt
Bug:     776910
Title:   apt: upgrade from wheezy to jessie breaks in the middle
Flags:   [        ] (none)
Dists:   [TU] (testing, unstable)
#

Mit dem zweiten Schalter legen Sie mittels --include-dist-op and fest, dass die Angabe der Veröffentlichung von rc-bugs als logisches und zu interpretieren ist. Damit begrenzen Sie die Ausgabe nur auf die angegebenen Veröffentlichungen.

Suche über die Angabe der Veröffentlichung (Variante 2). 

# rc-alert --include-dists TUE --include-dist-op and apt
Package: apt
Bug:     771428
Title:   apt tries to configure dbus before libdbus-1-3, fails to upgrade
Flags:   [        ] (none)
Dists:   [TUE] (testing, unstable, experimental)
#

Wie eingangs angesprochen, gestattet Ihnen rc-alert auch eine Suche anhand von Debtags. Dazu bietet es den Schalter --debtags an. Für die Recherche nach allen Paketen, die Programmcode in der Programmiersprache Perl enthalten und als Plugin gekennzeichnet sind, gelingt Ihnen der folgende Aufruf:

Recherche zu Bugreports anhand der Debtags. 

# rc-alert --debtags implemented-in::perl,role::plugin
Package: dictionaries-common
Bug:     751367
Title:   unupgradeable: "shared/packages-wordlist doesn't exist"
Flags:   [        ] (none)
Dists:   [S] (stable)
Debtags: implemented-in::lisp, implemented-in::perl, role::plugin, role::program, scope::utility, works-with::dictionary
#

Für eine weitere Recherche mit ausführlicher Anleitung zu rc-alert empfehlen wir Ihnen den Beitrag von Gambaru [gambaru-rc-alert].

33.3.6. Welche der von mir genutzten Pakete benötigen Hilfe?

Das Programm how-can-i-help aus dem gleichnamigen Paket [Debian-Paket-how-can-i-help] geht genau dieser Frage nach und listet Ihnen auf, welche konkrete Art der Unterstützung ein Paket benötigt. Es ergänzt den Eintrag von how-can-i-help im Debian Wiki [Debian-Wiki-how-can-i-help] um die dazu passende Funktionalität auf der Kommandozeile. Obwohl es erst offiziell ab Debian 8 Jessie verfügbar ist, gibt es ebenso ein Paket aus Debian Backports für Debian 7 Wheezy (für Debian Backports siehe Kapitel 19, Backports).

Als Datenquelle für seine Aussagen nutzt es die Ultimate Debian Database (UDD) [Ultimate-Debian-Database]. Dabei handelt es sich um eine PostgreSQL-Datenbank, die how-can-i-help über eine webbasierte Schnittstelle abfragt. Beachten Sie daher, dass das Programm für brauchbare Ergebnisse eine Internetverbindung voraussetzt.

how-can-i-help integriert sich zudem über einen APT-Hook in APT und wird somit nach jeder Paketinstallation erneut ausgeführt. In Folge sehen Sie damit stets nur neu hinzugekommene Pakete, Fehler und den Bedarf an Hilfe. Ebenso können Sie das Programm über die Kommandozeile mit etlichen Schaltern aufrufen (Auswahl).

-a (Langform --all)
Möglichkeiten für alle Pakete anzeigen, nicht nur für die installierten Pakete.

-o (Langform --old)
Zeige nicht nur die neu hinzugekommenen Möglichkeiten oder die Möglichkeiten zu den zuletzt installierten Paketen, sondern auch die Möglichkeiten, welche bereits in der Vergangenheit aufgelistet wurden.

-q (Langform --quiet)
Eine kompaktere Darstellung ohne Kopf- und Fußzeilen.

In Benutzung sind zudem eine Reihe von Abkürzungen für die konkrete Hilfe, die sich auf den Zustand eines Pakets beziehen. Diese Abkürzungen haben wir der Übersicht der Work-Needing and Prospective Packages (WNPP) entnommen [Debian-Wiki-WNPP]:

Orphaned (O)
Kennzeichnung für ein verwaistes Paket, d.h. derzeit ohne Paketmaintainer.
Request For Adopter (RFA)
Der derzeitige Paketmaintainer möchte die Verantwortung für das Paket abgeben und sucht einen Nachfolger.
Request For Help (RFH)
Der derzeitige Paketmaintainer braucht generell Hilfe bei der Pflege des Pakets, z.B. in Form eines Co-Maintainers oder auch nur jemand, der Bugreports vorsortiert. Welche Hilfe sich der Paketbetreuer genau wünscht, finden Sie im angegebenen Bugreport.
Intent To Adopt (ITA)
Jemand hat vor, das Paket zu übernehmen (Paketadoption). Diese Übernahme ist aber noch nicht geschehen.

Über die bereits bisher genannten Möglichkeiten zur Unterstützung haben sich die folgenden Wege bewährt, zur Weiterentwicklung und Verbesserung von Paketen beizutragen:

Request For Sponsorship (RFS)
Jemand, der kein Debian-Entwickler ist, hat eine neue Version dieses Pakets vorbereitet und sucht einen Debian-Entwickler, der das Paket begutachtet und dann das Hochladen (den Upload) sponsort.
newcomer
Pakete mit Bugreports, die mit der Markierung newcomer versehen sind. Eingeführt und früher bekannt unter der Markierung gift (engl. für Geschenk). Bugreports mit dieser Markierung gelten als „leichte Beute“ für Einsteiger in die Paketierung oder Entwicklung von Debian-eigenen Paketen. Diese Aufgaben sind i.d.R. ohne besondere Kenntnisse in der Paketierung lösbar, aber den Aufwand sollten Sie trotzdem nicht unterschätzen.
testing-autorm
Kennzeichnung für Pakete, die in Kürze aus dem Zweig Debian testing entfernt werden. Hintergrund sind zumeist bisher nicht behobene, veröffentlichungskritische Fehler (RC bugs) des Pakets oder eines ihrer Abhängigkeiten.
no-testing
Kennzeichnung für Pakete, die vor kurzem aus dem Zweig Debian testing entfernt wurden. Dies kann aufgrund bislang nicht behobener, veröffentlichungskritischer Fehler (RC bugs) passiert sein, aber auch weil der Paketbetreuer oder jemand anderes explizit die Entfernung des Pakets beantragt hat. Letzteres passiert häufiger, als Sie sich vorstellen können, z.B. wenn bei einer Bibliothek wegen einer SONAME-Änderung auch der Paketname korrigiert werden muss, bspw. von libfoo7 zu libfoo8.

Über die letzten beiden Markierungen hat how-can-i-help eine Art Glaskugel-Funktion bzgl. zukünftiger Debian-Veröffentlichungen. Daraus ersehen Sie Tendenzen dahingehend, welche Pakete im Bestand bleiben. Das hat direkte Auswirkungen, welche Software zukünftig als Debian-Paket verfügbar bleibt und gepflegt wird. Haben Sie gerade ein Paket aus Debian stable installiert und how-can-i-help zeigt Ihnen im Anschluss zu ihrer Installation an, dass das Paket aus Debian testing herausgeflogen ist, klären Sie für sich, ob Sie längerfristig auf dieses Paket setzen wollen. Bei einer solchen Meldung ist die Chance groß, dass dieses Paket in der nächsten Veröffentlichung von Debian stable nicht mehr enthalten ist.

Was gibt es zu tun? (Ausschnitt). 

$ how-can-i-help
New packages where help is needed, including orphaned ones (from WNPP):
 - apt-rdepends - https://bugs.debian.org/487125 - O (Orphaned)
 - ara - https://bugs.debian.org/450876 - O (Orphaned)
 - dctrl-tools - https://bugs.debian.org/768834 - O (Orphaned)
...

New packages removed from Debian 'testing' (the maintainer might need help):
 - apt-dpkg-ref - https://tracker.debian.org/pkg/apt-dpkg-ref
 - cpp-4.4 - https://tracker.debian.org/pkg/gcc-4.4
 - gcc-4.4 - https://tracker.debian.org/pkg/gcc-4.4
...
$