freeX: Kammerjäger im Einsatz

Die ausschließlichen Vertriebsrechte an diesem Artikel liegen beim Computer- & Literaturverlag (C&L). Der Artikel darf nicht kopiert oder gar erneut in einer Zeitschrift oder einem Buch veröffentlicht werden ohne vorherige Erlaubnis von C&L. Der Verlag gestattet freundlicherweise die Veröffentlichung auf diesen Seiten. Wer öfter auf diesen Hinweis trifft, sollte sich überlegen, die Zeitschrift freeX zu abonnieren.

Das Bug Tracking System von Debian

Kaum eine Software ist fehlerfrei. Je größer und komplexer Software wird, desto größer ist die Chance, daß sich mehr oder weniger schwerwiegende Fehler eingeschlichen haben und desto komplizierte gestaltet sich die Fehlersuche. Die meisten Fehler sind jedoch harmlos und werden von den Entwicklern ohne Aufsehen in der nächsten Version behoben.

1. Was ist ein Bug?
2. Bug Tracking Systeme
3. Bugreports schreiben
4. Severities
5. Bugreports kommentieren

Je komplexer sich ein Projekt gestaltet, desto schwieriger lassen sich manche Fehler nachvollziehen. Daher sind detailierte Berichte über Fehler Fehlverhalten, oder sogar komplette Lösungen umso wichtiger. Viele komplizierte Fehler lassen sich nur dann finden, wenn sie nachvollzogen oder gar reproduziert werden können.

Was ist ein Bug?

Ein Fehler kann auf verschiedene Arten in Erscheinung treten. Am augenscheinlichsten ist allerdings Fehlverhalten der Software. Hier sind ein paar Beispiele.

Fehlverhalten des Programms
Inkonsistente Dokumentation
Rechtschreibungs- und Grammatikfehler
Fehlende Dokumentation
Falsche Klassifizierung (z.B. »main« anstatt »non-free«)
Installationsfehler
Ignorieren von Systemkomponenten
Fehlende oder unvollständige Integration ins Debian-System
Falsche oder ungültige URLs
Sicherheitsprobleme
Verstöße gegen die Debian-Policy

Wenn ein Paket einen derartigen Fehler aufweist, sollte er entsprechend berichtet werden, damit er behoben werden kann. Es ist leicht einzusehen, daß nur die Fehler korrigiert werden können, die den Autoren oder Betreuern auch bekannt sind. Der Betreuer findet oft zwar selbst einiges heraus, während er sich intensiv mit dem Paket beschäftigt, meistens erwischt er jedoch nicht alle Fehler.

Daher ist es wichtig, daß die Autoren und Betreuer mit Feedback (hier: Fehlerberichten) unterstützt werden. Wenn der Paket-Betreuer einen Fehler korrigiert, der im Original-Paket ebenfalls vorhanden ist, wird er mit Korrektur an die Original-Autoren weitergegeben. Dieses ist ein Teil des Beitrags an die Gemeinschaft für Freie Software, den Debian leistet.

Bug Tracking Systeme

Diese Systeme speichern Berichte über Fehlverhalten von Komponenten (sogenannte Bugreports) und stellen sie den Entwicklern zur Verfügung. Teilweise sind es öffentliche Systeme, so daß die Berichte von jeder Person im Netz gelesen werden können.

Für Debian GNU/Linux wurde ein solches System entwickelt. Es unterscheidet zwischen Fehlerberichten für verschiedene Komponenten (Pakete) sowie verschiedene Prioritäten. Dieses Bug Tracking System ist öffentlich und die einzelnen Berichte können im Web eingesehen werden:

http://bugs.debian.org/
Hauptseite des Bug Tracking Systems
http://bugs.debian.org/paket
Index-Seite der Bugreports zum Paket »paket«, falls Fehler in diesem Paket berichtet wurden.
http://bugs.debian.org/nummer
Zeigt die Details zu dem als »nummer« angegebenen Bugreport. Auf der Seite werden alle zu diesem Fehler eingegangenen Mails aufgelistet.

Gesteuert wird dieses System via E-Mail. Um einen neuen Bericht hinzuzufügen, muß lediglich eine entsprechende Mail geschrieben werden. Das System leitet die Mail anschließend an entsprechenden Paket-Betreuer weiter und erstellt die Webseiten entsprechend. Kommentare werden an eine spezielle neu generierte Mail-Adresse geschickt, wenn sie zum Bericht hinzugefügt werden sollen.

Ein Bugreport kann als geschlossen oder weitergeleitet markiert werden. Beides wird dem System jeweils per Mail mitgeteilt. Wird er geschlossen, dann bekommt die Person, die ihn geöffnet hat, eine Benachrichtigung zugeschickt, daß das Problem behoben ist. Parallel zu den persönlichen Mails werden verschiedene auch an spezielle Mailing-Listen geschickt, so daß sich interessierte Leute sogar über Fehler auf dem Laufen den halten können.

Das von Debian entwickelte Bug Tracking System wird nicht nur von Debian selbst, sondern auch vom Gnome-Projekt (http://bugs.gnome.org/) und vom KDE-Projekt (http://bugs.kde.org/) eingesetzt. Das System bedienen zu können hilft nicht nur im Debian-Projekt.Es ist zudem in der »unstable«-Distribution als Paket »debbugs« zusammengepackt und kann für eigene Zwecke eingesetzt werden.

Bugreports schreiben

Wie bereits erwähnt, kann jeder einen Bugreport verfassen. Benötigt wird lediglich die Möglichkeit, eine Mail zu verschicken. Der erste Teil eines Bugreports ist ein spezieller Kontroll-Header, aus dem das Bug Tracking System einen Teil seiner Informationen bezieht. Zwischen diesem Header und dem eigentlichen Bugreport muß eine Leerzeile stehen.

Der Header ist wie ein Mail-Header (nach RFC 822) aufgebaut. Feldname und Wert sind durch einen Doppelpunkt voneinander getrennt. Der einzige Header, der im Bugreport enthalten sein muß, ist der Name des Paketes, für das der Fehler berichtet wird. Ein solcher Header sieht wie folgt aus:

  Package: cgilib
  Version: 0.4-3
  Severity: normal

Die Angabe der Version des fehlerhaften Pakets ist besonders wichtig, denn oftmals ist ein Fehler bereits anderweitig aufgetreten und in der aktuellen Version des Pakets längst behoben.

Debian GNU/Linux existiert meistens als »stable« und »unstable« (in der Entwicklung befindliche) Version auf den Servern. An der Entwickler-Version arbeiten die Paket-Betreuer und erneuern das System. Es ist häufig der Fall, daß Fehler in neueren Versionen bereits behoben wurden. Der Paket-Betreuer wird den Bugreport in einem solchen Fall mit einem entsprechenden Kommentar schließen und die Person informieren, die den Bugreport geöffnet hat.

Die dritte Zeile (»Severity«) ist ebenfalls optional. »Severity: normal« ist die Voreinstellung. Mit diesem header wird die Wichtigkeit eines Fehlers angegeben. Folgende Angaben sind möglich, in umgekehrter Reihenfolge der Wichtigkeit. Ist zu einem Paket ein Bugreport offen, der wichtiger als »normal« ist, dann wird das Paket nur dann in eine neue Version der Distribution aufgenommen, wenn dieser Fehler behoben ist. Das macht den Bug zu einem sogenannten "Release Critical Bug" (abgekürzt: RCB).

Severities

fixed
Der Fehler ist behoben, jedoch nicht vom Paket-Betreuer selbst, sondern von einem anderen, der in die Bresche gesprungen ist. Im Text dieses Bugreports ist der Patch angegeben, der den Fehler behebt.
wishlist
Es ist kein richtiger Fehlerbericht, sondern ein sogenanntes Feature-Request. Es wird darum gebeten, das eine oder andere in das Paket aufzunehmen, z.B. weitere Dokumentation, eine zusätzliche Funktion oder die angehängte Manpage.
normal
Normale Priorität, Voreinstellung für Bugreports, wenn kein »Severity:«-Header angegeben wurde.
important
Ein Bugreport, der das betroffene Paket für das nächste Release disqualifiziert, z.B. wenn falsche Pfade referenziert werden und gewisse Teile nicht mehr funktionieren.
grave
Das betroffene Paket ist unbrauchbar. Das nächste Release von Debian wird dieses Paket nur dann enthalten sein, wenn dieser Fehler behoben ist. Das kann ein Sicherheitsloch sein oder einfach ein kaputtes Paket.
critical
Der Fehler ist so gravierend, daß er selbst weitere Pakete mitreißt oder eventuell sogar das gesamte System unbrauchbar macht, für Datenverlust sorgt oder ein gravierendes Sicherheitsloch in sich birgt.

Im Anschluß an diesen Header folgt der eigentliche Bugreport. Er wird auf Englisch geschrieben, da die Entwickler auf der gesamten Welt verstreut sind und nur selten Deutsch sprechen. Der Text sollte den Fehler so genau beschreiben, daß der Paket-Betreuer in der Lage ist, das Problem zu verstehen und den Fehler zu reproduzieren. Falls es möglich ist, sollte ein entsprechender Patch mitgeliefert werden, den der Betreuer nur einspielen muß.

Es ist nicht wichtig, daß der Bericht in sauberstem Englisch geschrieben wird. Wichtig ist nur, daß der Fehler nachvollzogen werden kann und behoben wird. Gebrochenes Englisch ist dafür meistens ausreichend. Wenn das Paket von weiteren Paketen (z.B. von Bibliotheken) abhängt und die Möglichkeit besteht, daß der Fehler evtl. dort zu suchen ist, sollten diese Pakete samt Versionsnummern ebenfalls angegeben werden.

Die Mail mit dem Bugreport wird an »submit@bugs.debian.org« geschickt und anschließend vom System verarbeitet. Nachdem der Bugreport aufgenommen wurde, wird eine Bestätigungsmail verschickt, meist innerhalb der nächsten halben Stunde. In der Mail steht die Nummer des Fehlers und wie man weitere Informationen hinzufügen kann. Es wird eine spezielle E-Mail-Adresse der art »nnnn@bugs.debian.org« generiert, wobei »nnnn« die Nummer des Fehlers ist.

Wem das zu kompliziert ist, der installiert sich das Paket »bug« und schreibt damit die Bugreports. Sie werden mit »bug paket« geschrieben. Das Programm hängt Abhängigkeiten automatisch an, genauso relevante Konfigurationsdateien.

Bugreports kommentieren

Wenn man Kommentare oder weiterführende Informationen zu einem Fehler hat, sollte man sie direkt an »nnnn@bugs.debian.org« schicken. Sie werden dann an den Paket-Betreuer weitergeleitet, an die Mailing-Liste »debian-bugs-dist« geschickt und im Web archiviert.

Stellt man im Nachhinein fest, daß die Wichtigkeit falsch gewählt wurde, z.B. daß es kein normaler, sondern nur ein Whishlist-Bug ist, oder daß das betroffene Paket trotz Fehler doch noch benutzbar ist, dann wird die Wichtigkeit angepaßt. Dazu wird eine Mail an »control@bugs.debian.org« geschickt. In die Mail wird folgendes geschrieben:

  severity nnnn wishlist
  thanks

Alles, was nach der Zeile »thanks« folgt, wird vom Bug Tracking System ignoriert. Sollte ein Bugreport geschlossen werden, ohne daß der darin beschriebene Fehler tatsächlich behoben wurde, dann besteht die Möglichkeit, den Bugreport wieder zu öffnen. Dazu wird folgendes in die Mail geschrieben:

  reopen nnnn
  thanks

Möchte man nachträglich den Titel des Bugreports ändern, ist das genauso leicht möglich. Dafür schreibt man:

  retitle nnnn Neue Überschrift
  thanks

Eine genaue Übersicht, wie das Bug Tracking System bedient wird, befindet sich auf http://www.debian.de/Bugs/.

Martin Schulze