Gentoo Bug Reporting Leitfaden

1.  Einführung

Vorwort

Einer der Faktoren, der die Lösung eines Bugs herauszögert, ist die Art und Weise wie er berichtet wird. Durch das Erstellen dieses Leitfadens hoffen wir, die Kommunikation zwischen den Entwicklern und den Benutzern in punkto Fehlerbereinigung zu verbessern. Fehler zu beseitigen ist ein wichtiger, wenn nicht gar entscheidender Teil der Qualitätssicherung eines jeden Projektes und wir hoffen, dass dieser Leitfaden dazu beitragen wird, dies zu einem Erfolg zu machen.

Bugs!!!!

Sie emergen ein Paket oder arbeiten mit einem Programm und plötzlich passiert das Schlimmste -- Sie finden einen Bug. Fehler kommen in vielen Formen vor, zum Beispiel als Fehler beim emergen oder als Speicherzugriffsfehler. Was auch immer die Ursache ist, Tatsache ist, dass so ein Fehler gelöst werden muss. Hier sind ein paar Beispiele für solche Fehler.

$ ./bad_code `perl -e 'print "A"x100'`
Segmentation fault

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Diese Fehler können ziemlich lästig sein. Aber wenn Sie einen finden, was sollten Sie tun? Die folgenden Abschnitte zeigen Ihnen zwei wichtige Werkzeuge um mit Laufzeitfehlern umzugehen. Danach werden wir einen Blick auf Fehler beim Kompilieren werfen und wie man mit diesen umgeht. Lassen Sie uns also mit dem ersten Werkzeug zur Fehlerbehandlung von Laufzeitfehlern anfangen -- gdb.

2.  Fehlersuche mit GDB

Einführung

GDB, oder der (G)NU (D)e(B)ugger, ist ein Programm um Laufzeitfehler zu finden, die normalerweise Memory Corruption nach sich ziehen. Schauen wir uns als erstes an, was Debuggen beinhaltet. Eines der wichtigsten Dinge, die Sie tun müssen, um ein Programm zu debuggen, ist, es mit FEATURES="nostrip" zu emergen. Das verhindert, dass die Debug-Symbole entfernt werden. Warum werden diese bei Programmen normalerweise entfernt? Der Grund ist derselbe, aus dem man gezippte Manpages verwendet -- um Platz zu sparen. Hier ist ein Vergleich wie sich die Größe eines Programms mit und ohne entfernte Debug-Symbole verändert.

(Debug-Symbole entfernt)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(Debug-Symbole enthalten)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code

Nur zur Verdeutlichung, bad_code ist das Programm, dass wir mit dem gdb gleich debuggen werden. Wie Sie sehen können, ist das Programm ohne Debug-Symbole 3140 Bytes groß, während mit ihnen das Programm 6374 Bytes groß ist. Das ist fast das Doppelte! Zwei weitere Sachen können Sie zum Debuggen machen. Das erste ist, ggdb zu Ihren CFLAGS und CXXFLAGS hinzuzufügen. Dieses Flag fügt weitere Debug-Symbole hinzu. Wir werden später sehen, was das bedeutet. Dies ist ein Beispiel wie /etc/make.conf mit den neu hinzugefügten Flags aussehen könnte.

CFLAGS="-O1 -pipe -ggdb"
CXXFLAGS="${CFLAGS}"

Als letztes können Sie noch debug zu den USE-Flags des Paketes hinzufügen. Dies können Sie mit Hilfe der Datei package.use wie folgt erledigen.

# echo "category/package debug" >> /etc/portage/package.use

Danach emergen wir das Paket, mit den bereits vorgenommenen Änderungen, erneut.

# FEATURES="nostrip" emerge package

Nun, da die Debug-Symbole eingerichtet sind, können wir mit dem Debuggen des Programms fortfahren.

Das Programm mit dem GDB ausführen

Nehmen wir an, wir haben ein Programm "bad_code". Jemand behauptet, dass das Programm abstürzt und gibt ein Beispiel. Sie nehmen sich der Sache an und probieren es aus:

$ ./bad_code `perl -e 'print "A"x100'`
Segmentation fault

Es sieht so aus, als hätte derjenige Recht. Da das Programm offensichtlich defekt ist, haben wir einen Bug vor uns. Jetzt ist es an der Zeit gdb zu benutzen, um das Problem zu lösen. Als erstes starten wir gdb mit --args und dem vollständigen Programmaufruf inklusive Argumenten, wie hier gezeigt:

$ gdb --args ./bad_code `perl -e 'print "A"x100'`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Sie sollten eine Eingabeaufforderung der Form "(gdb)" sehen, die auf eine Eingabe wartet. Als erstes müssen wir das Programm ausführen. Wir geben run ein und erhalten eine Nachricht ähnlich wie:

(gdb) run
Starting program: /home/chris/bad_code

Program received signal SIGSEGV, Segmentation fault.
0xb7ec6dc0 in strcpy () from /lib/libc.so.6

Hier sehen wir, wie das Programm startet, sowie eine Benachrichtigung über SIGSEV beziehungsweise Speicherzugriffsfehler. Das ist der GDB, der uns mitteilt, dass unser Programm abgestürzt ist. Er nennt uns außerdem die letzte ausgeführte Funktion, die er aufspüren konnte, als das Programm abgestürzt ist. Dies ist allerdings nicht wirklich hilfreich, da es mehrere strcpy in dem Programm geben könnte, so dass es den Entwicklern schwer fiele, zu erkennen, welches davon das Problem verursacht. Um ihnen dabei zu helfen, werden wir einen sogenannten Backtrace durchführen. Ein Backtrace läuft rückwärts durch alle Funktionen, die während der Programmausführung aufgerufen wurden, bis hin zu der fehlerhaften Funktion. Funktionen die (ohne einen Absturz zu verursachen) enden, werden im Backtrace nicht angezeigt. Um das Backtrace zu erhalten geben Sie am (gdb)-Prompt bt ein. Sie erhalten dann eine Ausgabe ähnlich wie:

(gdb) bt
#0  0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it ()
#2  0x080483ba in main ()

Sie können den Ablauf deutlich erkennen. main() wird als erstes aufgerufen, gefolgt von run_it() und irgendwo in run_it() liegt die fehlerhafte Funktion strcpy(). Solche Angaben helfen den Entwicklern das Problem einzugrenzen. Es gibt einige Ausnahmen zu dieser Ausgabe. Als erstes, wenn man vergisst die Debug-Symbole mit FEATURES="nostrip" zu aktivieren. Mit entfernten Debug-Symbolen sieht die Ausgabe folgendermaßen aus:

(gdb) bt
#0  0xb7e2cdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in ?? ()
#2  0xbfd19510 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000000 in ?? ()
#5  0xb7eef148 in libgcc_s_personality () from /lib/libc.so.6
#6  0x080482ed in ?? ()
#7  0x080495b0 in ?? ()
#8  0xbfd19528 in ?? ()
#9  0xb7dd73b8 in __guard_setup () from /lib/libc.so.6
#10 0xb7dd742d in __guard_setup () from /lib/libc.so.6
#11 0x00000006 in ?? ()
#12 0xbfd19548 in ?? ()
#13 0x080483ba in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0xb7deebcc in __new_exitfn () from /lib/libc.so.6
#17 0x00000000 in ?? ()
#18 0xbfd19560 in ?? ()
#19 0xb7ef017c in nullserv () from /lib/libc.so.6
#20 0xb7dd6f37 in __libc_start_main () from /lib/libc.so.6
#21 0x00000001 in ?? ()
#22 0xbfd195d4 in ?? ()
#23 0xbfd195dc in ?? ()
#24 0x08048201 in ?? ()

Dieser Backtrace enthält eine Vielzahl von Zeilen mit ??. Das kommt daher, da ohne Debug-Symbole gdb nicht weiß, wie das Programm ausgeführt wurde. Daher ist es unheimlich wichtig, dass die Debug-Symbole nicht entfernt werden. Jetzt erinnern Sie sich daran, dass wir vor einiger Zeit das -ggdb Flag erwähnt haben. Lassen Sie uns mal ausprobieren, wie die Ausgabe mit diesem Flag aussieht:

(gdb) bt
#0  0xb7e4bdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it (input=0x0) at bad_code.c:7
#2  0x080483ba in main (argc=1, argv=0xbfd3a434) at bad_code.c:12

Hier sehen wir, dass deutlich mehr Informationen für die Entwickler verfügbar sind. Es werden nicht nur die Informationen zu den aufgerufenen Funktionen angezeigt, sondern auch die genauen Zeilennummern aus den Quelldateien. Dieses wird bevorzugt, wenn Sie zusätzlichen Speicherplatz übrig haben. Hier sehen Sie, wie sehr sich die Dateigröße zwischen Programmen mit debug, strip und -ggdb unterscheidet.

(Debug-Symbole entfernt)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(Debug-Symbole aktiviert)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
(-ggdb Flag aktiviert)
-rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code

Wie Sie sehen können, fügt -ggdb etwa 13178 weitere Bytes zu der Größe der Datei mit Debug-Symbolen hinzu. Allerdings kann, wie oben gezeigt, der zusätzliche Speicherplatzbedarf sinnvoll sein, wenn man die Debuginformationen den Entwicklern präsentiert. Der Backtrace kann durch Kopieren und Einfügen in eine Datei gespeichert werden (wenn es ein nicht-X-basierendes Terminal ist, können Sie gpm verwenden. Um diese Anleitung kurz zu halten, empfehle ich Ihnen, die Dokumentation zu gpm zu lesen, um zu erfahren, wie Sie damit Kopieren und Einfügen können). Jetzt, wo wir mit gdb fertig sind, können wir ihn beenden.

(gdb) quit
The program is running. Exit anyway? (y or n) y
$

Damit endet die Einführung zu gdb. Wir hoffen, dass Sie mit Hilfe von gdb bessere Bugreports erstellen können. Allerdings gibt es auch andere Arten von Fehlern, die dazu führen können, dass ein Programm zur Laufzeit abbricht. Eine der anderen Möglichkeiten ist ein unzulässiger Dateizugriff. Dieses können wir mit einem raffinierten kleinen Tool namens strace herausfinden.

3.  Herausfinden von Dateizugriffsfehlern mit Hilfe von strace

Einführung

Programme benutzen oftmals Dateien, um Konfigurationsinformationen zu holen, auf Hardware zuzugreifen oder Logfiles zu schreiben. Manchmal versucht ein Programm auf solche Dateien fehlerhaft zuzugreifen. Ein Werkzeug namens strace wurde erstellt, um damit umgehen zu können. strace spürt Systemaufrufe auf (daher der Name), unter anderem Aufrufe, die den Arbeitsspeicher oder Dateien benutzen. Für unser Beispiel nehmen wir das Programm foobar2. Dieses ist eine neuere Version von foobar. Während des Wechsels zu foobar2 bemerken Sie allerdings, dass alle Ihre Konfigurationsdateien fehlen! In foobar Version 1 hatten Sie es auf "foo" eingestellt, jetzt benutzt es aber den Standard "bar".

$ ./foobar2
Configuration says: bar

Unsere vorherige Konfiguration hatte es ausdrücklich auf foo gesetzt, daher benutzen wir jetzt strace, um herauszufinden, was passiert ist.

Benutzen von strace um den Fehler zu finden

Wir lassen strace die Ergebnisse der Systemaufrufe loggen. Um dies zu erreichen, starten wir strace mit dem Argument -o[file]. Lassen Sie es uns wie folgt auf foobar2 anwenden.

# strace -ostrace.log ./foobar2

Damit erstellen wir im aktuellen Verzeichnis eine Datei namens strace.log. Wir prüfen nun die Datei. Hier sehen Sie einen Auszug der relevanten Teile dieser Datei.

open(".foobar2/config", O_RDONLY)       = 3
read(3, "bar", 3)                       = 3

Aha! Da ist also das Problem. Jemand hat das Konfigurationsverzeichnis auf .foobar2 anstelle von .foobar geändert. Wir können auch sehen, dass das Programm wie erwartet "bar" einliest. In diesem Fall können wir dem Ebuild-Maintainer empfehlen einen Warnhinweis einzubauen. Für den Moment können wir die Konfigurationsdateien von .foobar herüberkopieren und verändern, um das gewünschte Ergebnis zu erreichen.

Fazit

Bis jetzt haben wir uns darum gekümmert, Fehler zur Laufzeit zu finden. Diese Fehler sind problematisch, wenn Sie versuchen, Ihr Programm auszuführen. Allerdings sind Laufzeitfehler das geringste Problem, wenn sich das Programm erst gar nicht kompilieren lässt. Lassen Sie uns daher einen Blick darauf werfen, wie man Kompilationsfehlern beim emergen begegnet.

4.  Umgang mit emerge-Fehlern

Einführung

emerge-Fehler, wie der am Anfang gezeigte, können eine Hauptursache für Frustration bei den Benutzern sein. Das Melden solcher Fehler wird daher als entscheidend für die Bewahrung von Gentoos Gesundheit erachtet. Lassen Sie uns als Beispiel einen Blick auf das Ebuild foobar2, das einige Buildfehler enthält, werfen.

Untersuchen von emerge-Fehlern

Lassen Sie uns einen Blick auf diesen sehr einfachen emerge-Fehler werfen:

gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2.o foobar2.c
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1


!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

Das Programm kompiliert problemlos, bis es plötzlich stoppt und eine Fehlermeldung anzeigt. Dieser spezielle Fehler kann in drei verschiedene Teile aufgeteilt werden, die Kompilierungsnachrichten, den Buildfehler und die emerge-Fehlermeldung, wie nachfolgend gezeigt:

(Kompilierungsnachrichten)
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
 -c -o foobar2.o foobar2.c

(Buildfehler)
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1

(emerge-Fehler)
!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

Die Kompilierungsnachrichten weisen auf den Fehler hin. Meistens ist es eine gute Idee, mindestens die letzten 10 Zeilen beizufügen, so dass die Entwickler wissen, an welcher Stelle die Kompilierung war, als der Fehler auftrat.

Bitte stellen Sie sicher, dass Sie Fehlermeldungen immer auf Englisch einbinden, auch wenn Ihre Systemsprache auf eine andere gesetzt ist. Sie können temporär auf eine englische Locale umstellen, indem Sie LC_ALL=C der emerge Befehlszeile voranstellen.

# LC_ALL=C emerge sys-apps/foobar2

Make-Fehler sind die tatsächlichen Fehler und die Informationen, die der Entwickler benötigt. Wenn Sie Zeilen der Art "make: ***" sehen, ist dies oft die Stelle, an der der Fehler auftrat. Normalerweise können Sie 10 Zeilen davor und danach beifügen und der Entwickler kann den Fehler adressieren. Allerdings mag das nicht immer funktionieren, daher werden wir uns gleich eine Alternative ansehen.

Der emerge-Fehler ist das, was emerge als einen Fehler auswirft. Manchmal kann auch das wichtige Informationen beinhalten. Oftmals machen Leute den Fehler, ausschließlich den emerge-Fehler zu berichten. Das ist für sich alleine genommen nutzlos, aber mit dem make-Fehler und den Kompilierungsinformationen zusammen kann ein Entwickler sehen, welches Programm und welche Version des Pakets fehlschlägt. Als Randbemerkung, make ist als Buildprozess für Programme weit verbreitet (aber nicht immer). Wenn Sie keinen Fehler der Art "make: ***" finden können, kopieren Sie einfach die 20 Zeilen vor dem emerge-Fehler. Das sollte die meisten Fehlermeldungen des Buildsystems beinhalten. Nehmen wir einmal an, die Fehler scheinen recht umfangreich zu sein. 10 Zeilen werden dann nicht reichen, um alles einzufangen. An dieser Stelle kommt PORT_LOGDIR ins Spiel.

emerge und PORT_LOGDIR

PORT_LOGDIR ist eine Portage-Variable, die ein Logverzeichnis für einzelne emerge-Logs aufsetzt. Lassen Sie uns einen Blick darauf werfen, was das zur Folge hat. Starten Sie zuerst emerge mit PORT_LOGDIR auf Ihr gewähltes Logverzeichnis gesetzt. Nehmen wir an, Sie haben ein Verzeichnis /var/log/portage. Wir werden das als unser Logverzeichnis benutzen:

# PORT_LOGDIR=/var/log/portage emerge cate-gory/foobar2

Nun wird emerge wieder fehlschlagen. Allerdings haben wir dieses Mal ein Logfile, mit dem wir arbeiten und das wir dem Bugreport nachher anhängen können. Lassen Sie uns einen kurzen Blick in unser Logverzeichnis werfen.

# ls -la /var/log/portage
total 16
drwxrws---   2 root root 4096 Jun 30 10:08 .
drwxr-xr-x  15 root root 4096 Jun 30 10:08 ..
-rw-r--r--   1 root root 7390 Jun 30 10:09 cate-gory:foobar2-1.0:20090110-213217.log

Die Logfiles haben das Format [Kategorie]:[Paketname]-[Version]:[Datum].log. Ein kurzer Blick über das Logfile zeigt Ihnen den kompletten emerge-Prozess. Dieses kann dann angehängt werden, wie wir nachher im Kapitel Bugs melden sehen werden. Jetzt, da wir die Informationen, die wir zum Melden des Bugs benötigen, gewonnen haben, können wir das auch endlich machen. Bevor wir damit allerdings anfangen, müssen wir erst einmal sicherstellen, dass noch niemand den Fehler bereits gemeldet hat. Lassen Sie uns also einen Blick auf das Suchen von Bugs werfen.

5.  Suchen mit Bugzilla

Einführung

Wir bei Gentoo benutzen Bugzilla, um Bugs zu verwalten. Gentoos Bugzilla ist per HTTPS und HTTP erreichbar. HTTPS ist für diejenigen verfügbar, die sich in unsicheren Netzwerken befinden oder einfach paranoid sind :). Wegen der Konsistenz werden wir in den folgenden Beispielen die HTTPS-Version benutzen. Gehen Sie auf Gentoo Bugs, um sich einen ersten Eindruck zu verschaffen.

Eines der frustrierensten Dinge für Entwickler und Bug-Wrangler ist es, doppelte Bug Reports zu finden. Diese kosten sie eine Menge wertvoller Zeit, die sie ansonsten für wichtigere Bugs nutzen könnten. Oft kann dieses durch einige einfache Suchmethoden verhindert werden. Daher werden wir uns ansehen, wie man nach Bugs sucht, und herausfinden kann, ob man einen ähnlichen Bug gefunden hat. Für dieses Beispiel werden wir den xclass Emerge-Fehler benutzen, den wir weiter oben schon verwendet haben.

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Um unsere Suche zu beginnen, gehen wir zu der Bugzilla Homepage.

Abbildung 5.1: Bugzilla Homepage

Wir klicken auf "Query Existing bug reports". Der Grund, warum wir diese Suche der "basic bug search" vorziehen, ist, dass die basic bug search dazu tendiert, einem nur vage Ergebnisse zu liefern und Benutzer oft daran hindert, die Ergebnisse durchzusehen und doppelte Bugs zu finden. Nachdem wir auf den Query Screen geklickt haben, erreichen wir die nächste Seite:

Abbildung 5.2: Bugzilla Suchseite

Fahren Sie durch Klicken des "Advanced Search"-Link fort um die Advanced Search Seite hervorzubringen.

Abbildung 5.3: Seite Advanced Search

So sieht die Advanced Search Seite aus. Es mag auf den ersten Blick überwältigend aussehen, aber wir werden ein paar einfache Felder betrachten, mit deren Hilfe wir die eher vagen Suchergebnisse eingrenzen können.

Abbildung 5.4: Inhalt

Das erste Feld ist die Zusammenfassung des Fehlers. Hier tragen wir einfach den Namen des Pakets ein, das abstürzt. Wenn Bugzie keine Ergebnisse liefert, versuchen Sie den Paketnamen zu entfernen, für den Fall, dass jemand den Namen nicht in das Feld der Zusammenfassung geschrieben hat (eher unwahrscheinlich, aber wir haben schon eine Menge merkwürdiger Bug Reports gesehen).

Product, Component und Version sollten alle auf der Standardeinstellung gelassen werden. Das verhindert, dass wir zu genau suchen und die richtigen Bugs ausschließen.

Comment ist der wichtigste Teil. Benutzen Sie das Kommentarfeld, um die Besonderheit dieses Fehlers einzutragen. Grundsätzlich sollten Sie nicht so etwas wie den Anfang des Buildfehlers nehmen. Suchen Sie stattdessen eine Zeile die vorher auftritt und einen tatsächlichen Fehler zeigt. Sie sollten zusätzlich die Zeichensetzung entfernen, um Bugzilla davon abzuhalten, das Ergebnis falsch zu interpretieren. Ein Beispiel aus dem xclass emerge-Fehler:

menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
(Entfernen Sie die Anführungszeichen ' ')
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu

Diese Meldung ist spefizisch genug, um den gesuchten Bug zu finden, ohne sich durch Unmengen anderer xclass-Kompilierungsfehler wühlen zu müssen.

URI, Whiteboard und Keywords können so gelassen werden. Was wir bis hierhin eingetragen haben sollte ausreichen, um unseren Bug zu finden. Werfen wir nun einen Blick darauf, was wir eingetragen haben.

Abbildung 5.5: Ausgefüllte Suchmaske

Wenn wir auf den Search-Button klicken kommt unser Ergebnis...

Abbildung 5.6: Suchergebnisse

Nur 2 Bugs! Damit können wir viel einfacher umgehen. Wir klicken den ersten an und tatsächlich, es ist der gesuchte Bug.

Abbildung 5.7: Bug gefunden

Es ist aber nicht nur der Bug den wir gesucht haben, er ist auch schon gelöst. Wenn wir uns den letzten Kommentar ansehen, finden wir die Lösung und wissen, wie wir vorgehen müssen, um den Fehler zu bereinigen. Jetzt sehen wir uns mal an, was passiert wäre, wenn Sie nicht die Advanced Search genutzt hätten.

Abbildung 5.8: Einfache Suchergebnisse

4 zusätzliche Bugs mit denen wir uns beschäftigen müssten! Mit größeren Paketen wird es sogar noch schlimmer. Mit diesen einfachen Werkzeugen sind wir jedoch in der Lage die Anzahl der Suchergebnisse deutlich einzuschränken, um zu versuchen, einen spezifischen Bug zu finden.

Fazit

Nehmen wir mal an, Sie haben gesucht und gesucht, aber finden einfach keinen Bug. Sie haben also selbst einen bisher unbekannten Bug gefunden. Werfen wir also einen Blick auf den Prozess, wie man neue Bugs meldet.

6.  Das Melden von Bugs

Einführung

In diesem Kapitel werden wir herausfinden, wie wir Bugzilla benutzen können, um einen neuen Bug zu melden. Gehen Sie nun auf Gentoo Bugs und ...

Abbildung 6.1: Bugzilla Homepage

Klicken auf "Report a Bug - Using the guided format".

Abbildung 6.2: Produktauswahl

Wie Sie sehen können, größter Nachdruck wurde darauf gelegt, dass Sie den Bug an der richtigen Stelle eröffnen. Der Großteil der Bugs geht zu Gentoo Linux.

Trotzdem ordnen manche Leute ebuild-Bugs in Portage-Development (in der Annahme, dass das Portage-Team sich um den Portagebaum kümmert) oder Infra (in der Annahme, dass Infra Zugriff auf die Spiegelserver und rsync hat und den Fehler direkt beheben kann) ein. Das ist aber nicht die Art und Weise wie es funktioniert.

Ein anderes Missverständnis tritt häufig mit unseren Documentation-Bugs auf. Zum Beispiel, ein Benutzer findet einen Fehler in der Catalyst Dokumentation. Die allgemeine Tendenz ist, den Fehler unter Docs-user einzuordnen, so dass er dem GDP zugeteilt wird, obwohl er eigentlich zu einem Mitglied des Release Engineering-Team gehen sollte. Als Faustregel gilt: Nur Dokumentation unter http://www.gentoo.org/doc/* gehört zum GDP. Alles unter http://www.gentoo.org/proj/* gehört zu den jeweiligen Teams.

Unser Bug gehört nach Gentoo Linux, da er ein Ebuild-Fehler ist. Wir fahren dementsprechend fort und bekommen den mehrstufigen Bug-Reporting-Prozess zu sehen. Lassen Sie uns jetzt mit Schritt 1 beginnen...

Abbildung 6.3: Guided Format Schritt 1

Der erste Schritt hierbei ist wirklich wichtig (wie Sie an dem roten Text sehen können). Das ist der Punkt, an dem Sie durch eine Suche nachsehen, dass noch niemand den Bug gemeldet hat. Wenn Sie diesen Schritt weglassen und einen schon existierenden Bug melden, wird er als DUPLICATE markiert werden und damit eine Menge Arbeitsaufwand der Qualitätssicherung verschwendet. Um Ihnen einen Eindruck zu vermitteln: Die durchgestrichenen Bugnummern sind duplizierte Bugs. Jetzt folgt Schritt 2, in dem wir die benötigten Informationen eingeben.

Benötigte Informationen

Abbildung 6.4: Basisinformationen

Lassen Sie uns einen näheren Blick darauf werfen, was was ist.

• Als erstes gibt es das Produkt. Das Produkt schränkt den Bug auf einen bestimmten Bereich von Gentoo, wie zum Beispiel Bugzilla (für Bugs im Zusammenhang mit bugs.gentoo.org), Doc-user (für Benutzerdokumentation) oder Gentoo Linux (für Ebuilds und ähnliches) ein.
• Component gibt an, wo der Bug genau aufgetreten ist, insbesonders in welchen Bereich des gewählten Produktes er gehört. Das macht die Einteilung einfacher.
• Hardware-Plattform gibt Ihre verwendete Architektur an. Wenn Sie SPARC benutzen, setzen Sie es auf SPARC.
• Operating System gibt das Betriebssystem an, das Sie benutzen. Da Gentoo eine "Meta-Distribution" ist, kann es auf anderen Betriebssystemen als Linux laufen.

So, für unser Beispiel haben wir:

• Product - Gentoo Linux (Da es sich um einen Ebuild-Fehler handelt)
• Component - Application (Es ist ein fehlerhaftes Programm, foobar2)
• Hardware Platform - All (Dieser Fehler könnte auf allen Architekturen auftreten)
• Operation System - All (Er könnte auf allen Arten von Betriebssystemen auftreten)

Abbildung 6.5: Vervollständigte Basisinformation

• Build Identifier ist im Wesentlichen der User-Agent des Browsers, der benutzt wird um den Bug zu melden (zur Protokollierung). Sie können das Feld wie vorgefunden belassen.
• URL ist optional und wird benutzt, um auf weitere wichtige Informationen auf einer anderen Webseite zu verweisen (Upstream Bugzilla, Releasenotes auf der Pakethomepage usw.). Sie sollten niemals URL benutzen, um auf ein Pastebin für Fehlermeldungen, Logfiles, Ausgabe von emerge --info, Screenshots oder ähnliche Informationen zu verweisen. Stattdessen sollten diese Informationen immer an den Bug angehängt werden.
• In Summary sollten Sie die Paketkategorie, den Paketnamen und die Versionsnummer angeben.

Die Kategorie nicht in der Zusammenfassung anzugeben ist nicht so schlimm, wird aber empfohlen. Wenn Sie aber den Paketnamen nicht angeben, wissen wir nicht worauf sich der Bug bezieht und wir müssen nachfragen. Die Versionsnummer ist wichtig für die Leute, die nach Bugs suchen. Wenn 20 Personen Bugs erstellen und niemand eine Versionsnummer angibt, wie soll dann jemand, der nach einem ähnlichen Bug sucht, herausfinden, ob es seiner ist? Er müsste sich jeden einzelnen ansehen, was nicht so schwierig wäre. Aber stellen Sie sich vor, es wären 200 Bugs, das wäre schon aufwändiger. Nach all den Paketinformationen sollten Sie eine kurze Beschreibung des Vorfalls einfügen. Hier ist ein Beispiel:

Abbildung 6.6: Zusammenfassung

Diese einfachen Regeln machen das Umgehen mit Bugs deutlicher einfacher. Als nächstes kommen wir zu den Details. Hier geben wir die Informationen bezüglich des Bugs an. Wir erklären es Ihnen anhand eines Beispiels:

Abbildung 6.7: Details

Jetzt wissen die Entwickler, warum wir den Bugreport erstellen. Sie können nun versuchen, den Fehler zu reproduzieren. Reproduzierbarkeit gibt an, wie oft wir in der Lage waren, das Problem nachzustellen. In diesem Beispiel können wir den Fehler jederzeit reproduzieren, indem wir foobar2 ausführen. Tragen wir also diesen Hinweis ein.

Abbildung 6.8: Reproduzierbarkeit

Wir haben angegeben, wie wir den Fehler gefunden haben. Der nächste Schritt ist nun anzugeben, welches Ergebnis wir erhalten haben und was wir glauben, wie es hätte aussehen sollen.

Abbildung 6.9: Ergebnis

Dann können wir zusätzliche Informationen angeben. Das können zum Beispiel Sachen wie Stack-Traces, Abschnitte (da das komplette Logfile meistens zu groß und nicht sonderlich sinnvoll ist) des strace-Logs oder das Wichtigste, Ihre Ausgabe von emerge --info sein. Hier ist ein Beispiel:

Abbildung 6.10: Zusätzliche Informationen

Schlussendlich wählen wir die Dringlichkeit des Bugs. Schauen Sie sich das noch einmal ganz genau an. In den meisten Fällen ist es in Ordnung, es so zu lassen wie es ist, und jemand wird den Wert für Sie erhöhen/verringern. Wenn Sie allerdings die Dringlichkeit des Bugs erhöhen, lesen Sie alles noch einmal durch und vergewissern Sie sich, dass Sie keinen Fehler gemacht haben. Eine Übersicht über die verschiedenen Stufen folgt.

• Blocker - Das Programm lässt sich schlichtweg nicht emergen oder ist eine wesentliche Behinderung des Systems. Zum Beispiel ein baselayout-Problem, welches das System vom Booten abhält, wäre ein sicherer Kandidat für die Kategorie Blocker.
• Critical - Das Programm verursacht Datenverlust oder schwerwiegende Speicherlecks während der Laufzeit. Wiederum, wenn ein wichtiges Programm, wie zum Beispiel net-tools, nicht kompiliert, könnte es als critical gekennzeichnet werden. Zwar wird das System dadurch nicht am Starten gehindert, aber es ist ziemlich wichtig für den alltäglichen Gebrauch.
• Major - Das Programm stürzt ab, aber es ist nichts, was dazu führt, dass das System schweren Schaden nimmt oder Daten verloren gehen.
• Minor - Ihr Programm stürzt sporadisch ab und es gibt offensichtliche Notlösungen.
• Normal - Der Standard. Wenn Sie sich nicht sicher sind, lassen Sie es dabei, außer es handelt sich um einen neuen Build oder kosmetische Änderungen. In dem Fall lesen Sie bitter weiter unten für weitere Informationen.
• Trivial - Sachen wie ein falsch geschriebenes Wort oder die Korrektur von Leerzeichen.
• Enhancement - Eine Anfrage bezüglich neuer Features in einem Programm oder genauer gesagt ein neues Ebuild.

Abbildung 6.11: Gewichtung

In unserem Fall setzten wir den Wert auf Normal.

Jetzt können wir den neuen Bug Report abschicken, indem wir auf das Feld Submit Bug Report klicken. Sie sehen dann Ihren neuen Bug erscheinen. Sehen Sie sich Bug 97561 an, um zu sehen, wie das Ergebnis aussieht. Wir haben damit unseren Bug gemeldet! Schauen wir uns jetzt an, wie damit weiter umgegangen wird.

Zero-Day Bump Request

Bisher haben wir gezeigt, was man machen muss, um einen Bug zu erstellen. Jetzt sehen wir uns an, was man nicht machen sollte.

Nehmen wir an, Sie haben ungeduldig den Terminplan eines Upstreamprojektes verfolgt und wenn Sie auf die Homepage gehen, sehen Sie was? Genau, es wurde gerade vor ein paar Minuten eine neue Version veröffentlicht! Die meisten Benutzer würden sofort zu Gentoos Bugzilla rennen und melden, dass eine neue Version verfügbar ist - "Bitte fügt die neue Version Portage hinzu", usw. Allerdings ist dies genau das, was Sie nicht tun sollten. Diese Art von Anfragen werden Zero-Day (oder 0-Day) Bump Requests genannt, da sie am selben Tag getätigt werden, an dem eine neue Version erscheint.

Warum Sie warten sollten? Als erstes ist es ziemlich unhöflich zu erwarten, dass Gentoo Entwickler alles liegenlassen, woran sie gerade arbeiten, um eine neue Version, die vor 15 Minuten veröffentlicht wurde, hinzuzufügen. Ihr Zero-Day Bump Request könnte daher als INVALID oder LATER markiert werden, da Entwickler eine Menge dringender Aufgaben haben, die sie beschäftigen. Zweitens sind Entwickler normalerweise weit vor den Benutzern über neue Versionen informiert, da sie Upstream relativ eng verfolgen müssen. Sie wissen bereits, dass eine neue Version auf dem Weg ist. In vielen Fällen werden sie bereits einen Bug erstellt oder sogar die Version in Portage als maskiertes Paket hinzugefügt haben.

Seien Sie clever, wenn Sie neue Versionen von Paketen testen und vorschlagen. Suchen Sie in Bugzilla, bevor Sie Ihren Bump Request erstellen. Ist bereits ein Bug offen? Haben Sie kürzlich synchronisiert? Ist es bereits in Portage? Wurde es wirklich schon von Upstream veröffentlicht? Gesunder Menschenverstand wird Sie weit bringen und Sie bei den vielbeschäftigten Entwicklern beliebt machen. Wenn mehrere Tage seit der Veröffentlichung vergangen sind und Sie sich sicher sind, dass keine offene Anfrage dazu vorliegt (und dass es nicht bereits in Portage vorhanden ist), dann können Sie einen neuen Bug erstellen. Denken Sie daran, zu erwähnen, dass sich das Paket auf Ihrer Architektur kompilieren lässt und gut läuft. Jede weitere hilfreiche Information, die Sie beitragen, ist gerne gesehen.

Sie wollen die neueste Version Ihres Lieblingspakets in Portage sehen? Erstellen Sie kluge Bugs.

7.  Arbeiten mit Ihrem Bug

Wenn wir uns den Bug ansehen, sehen wir die Informationen, die wir vorhin eingegeben haben. Sie werden feststellen, dass der Bug bug-wranglers@gentoo.org zugeordnet wurde. Das ist die Standardzuordnung für Application Component Bugs.

Abbildung 7.1: Neue Basisinformationen eines Bug

Die Details, die wir zu dem Bug eingegeben haben, sind ebenfalls einsehbar.

Abbildung 7.2: Neue Bugdetails

Allerdings werden Bug-Wrangler (normalerweise) unseren Bug nicht reparieren, daher werden wir ihn jemandem zuordnen, der das kann (Sie können die Zuordnung auch die Bug-Wrangler erledigen lassen). Dafür benutzen wir die metadata.xml des Paketes. Sie finden sie normalerweise unter /usr/portage/category/package/metadata.xml. Hier ist die für foobar2 erstellte.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<herd>chriswhite</herd>
<maintainer>
<email>chriswhite@gentoo.org</email>
<name>Chris White</name>
</maintainer>
<longdescription lang="en">
Foobar2 is a package that uses a configuration file to display a word.
</longdescription>
</pkgmetadata>

Beachten Sie den Abschnitt maintainer. Dieser zählt die Maintainer des Paketes auf, in unserem Fall mich selber, Chris White. Die eingetragene Email ist chriswhite@gentoo.org. Wir werden diese Informationen nutzen, um den Bug der richtigen Person zuzuordnen. Um das zu machen, klicken Sie auf die Markierung neben Reassign bug to und geben dann die Email-Adresse ein.

Abbildung 7.3: Neuzuordnung eines Bug

Drücken Sie danach den Button Commit, um die Änderungen zu übernehmen. Der Bug wird mir dann zugeordnet. Kurz danach bemerken Sie (normalerweise per Email), dass ich auf Ihren Bug geantwortet habe. Ich habe Sie um ein strace-Log gebeten, um herauszufinden wie das Programm versucht auf die Konfigurationsdatei zuzugreifen. Sie folgen den anfänglichen Anweisungen bezüglich der Nutzung von strace und erhalten ein strace-Log. Nun müssen Sie es dem Bug hinzufügen. Um das zu erreichen, klicken Sie auf "Create A New Attachment".

Abbildung 7.4: Neuer Anhang

Jetzt müssen wir das Logfile hinzufügen. Lassen Sie uns das schrittweise durchgehen.

• File - Das ist der Ort der Datei auf ihrem Rechner. In diesem Beispiel der Ort von strace.log. Sie können den "Browse..." Knopf benutzen, um die Datei auszuwählen oder den Pfad direkt in das Textfeld eintragen.
• Description - Ein kurzer Einzeiler oder einige wenige Worte, die den Anhang beschreiben. Wir werden hier nur strace.log eintragen, da das ziemlich selbsterklärend ist.
• Content Type - Das ist der Dateityp der Datei, die wir an den Bug anhängen.
• Obsoletes - Falls schon Anhänge zu diesem Bug hinzugefügt wurden, haben Sie die Möglichkeit sie durch Ihren Anhang als hinfällig zu erklären. Da es keine existierenden Anhänge zu diesem Bug gibt, brauchen wir uns darum nicht zu kümmern.
• Comment - Fügen Sie Kommentare hinzu, die mit dem Anhang sichtbar werden. Sie können hier, falls nötig, näher auf den Anhang eingehen.

Im Bezug auf den Content Type, gibt es noch einige weitere Details. Sie können die "patch"-Checkbox auswählen, wenn Sie einen Patch anhängen. Ansonsten können Sie Bugzilla bitten, den Dateityp automatisch ("auto-detect") zu ermitteln (nicht empfehlenswert). Die andere Möglichkeit ist, den Dateityp aus einer Liste auszuwählen ("select from list"), was oftmals verwendet wird. Benutzen Sie Klartext (text/plain) für die meisten Anhänge, außer Binärdateien wie Bilder (je nach Typ image/gif, image/jpeg oder image/png benutzen) oder komprimierte Dateien wie .tar.bz2, welche vom Dateityp application/octet-stream sind.

Abbildung 7.5: Neuer Anhang hinzugefügt

Wir übermitteln strace.log und es wird im Bugreport wie folgt dargestellt.

Abbildung 7.6: Angehängtes Stracelog

Wir hatten schon erwähnt, dass es manchmal Ebuilds gibt, die Ihnen in der Emerge-Fehlermeldung mitteilen, eine bestimmte Datei anzuhängen. Ein Beispiel sehen Sie hier.

configure: error: PNG support requires ZLIB. Use --with-zlib-dir=<DIR>

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/config.log

!!! ERROR: dev-php/php-5.0.3-r1 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.

Bitte fügen Sie sämtliche so erwähnte Dateien Ihrem Bugreport hinzu.

Manchmal kann es passieren, dass Sie ein Entwickler bittet, ein diff oder einen Patch für eine Datei hinzuzufügen. Standard diff-Dateien können so erzeugt werden:

$ cp file file.old
$ nano file
$ diff -u file.old file

Für C/C++ Quelldateien wird das Flag -p hinzugefügt, um die Funktionsaufrufe mit anzuzeigen, auf die das Diff sich bezieht:

$ cp file.c file.c.old
$ nano file.c
$ diff -up file.c.old file.c

Das Dokumentationsteam benötigt die Flag-Kombination -Nt sowie -u. Das hat hauptsächlich mit Tabexpansion zu tun. Sie können so einen Diff folgendermaßen erstellen:

$ cp file.xml file.xml.old
$ nano file.xml
$ diff -Nut file.xml.old file.xml

Damit ist Ihr Diff erstellt. Stellen Sie sich vor, während wir all das erledigen, findet jemand anderes Ihren Bug über die Suchfunktion von Bugzilla und möchte den Bug weiter verfolgen. Er kann das tun, indem er seine Email in das Add CC Feld des Bugs einträgt, wie unten gezeigt. Sie können mit dieser Methode auch andere Bugs verfolgen.

Abbildung 7.7: Hinzufügen einer Email zu CC:

Während all dieser Arbeit kann der Bug verschiedene Statuskennzeichnungen durchlaufen. Das wird normalerweise durch die Gentoo Entwickler erledigt, aber manchmal auch durch den Ersteller. Die folgenden sind die verschiedenen möglichen Stati, die ein Bug während seiner Existenz durchlaufen kann.

• UNCONFIRMED - Sie werden diesen Fall nicht so oft erleben. Das bedeutet, dass der Ersteller des Bugs ihn mit Hilfe der fortgeschrittenen Methode erstellt hat und sich nicht sicher ist, ob sein Bug tatsächlich auch einer ist.
• NEW - Bugs werden, wenn sie erstellt werden, zuallererst als neu gelistet.
• ASSIGNED - Wenn die Person, der Sie den Bug zugeteilt haben, ihn validiert, wird er oftmals den Status ASSIGNED bekommen, während versucht wird, den Bug zu lösen. Das lässt Sie wissen, dass Ihr Bug als tatsächlicher Bug angenommen wurde.
• REOPENED - Jemand hat den Bug gelöst und Sie glauben die Lösung ist nicht praktikabel oder das Problem existiert weiterhin. Dann können Sie den Bug neu öffnen. Bitte missbrauchen Sie das nicht. Wenn ein Entwickler einen Bug das zweite oder dritte Mal schließt, ist es wahrscheinlich, dass Ihr Bug wirklich erledigt ist.
• RESOLVED - Eine bedeutende Entscheidung bezüglich des Bugs wurde getroffen. Normalerweise geht sie mit FIXED einher, um anzuzeigen, dass der Bug gelöst und der Fall geschlossen ist, auch wenn verschiedene andere Lösungen möglich sind. Wir werden uns damit etwas später noch beschäftigen.
• VERIFIED - Die Maßnahmen um den Bug zu reproduzieren sind korrekt. Betrifft normalerweise die QS (QA).
• CLOSED - Bedeutet im Grunde genommen für den Bug "Ruhe in Frieden" und er wird unter der nicht endenden Flut neuer Bugs begraben.

Kurz darauf finden wir den Fehler im strace-Log, lösen den Bug, markieren ihn als RESOLVED FIXED und vermerken, dass es eine Änderung in dem Ort der Konfigurationsdateien gab und dass ich das Ebuild mit einer Warnung diesbezüglich updaten werde. Der Bug ist nun gelöst und Sie bekommen folgendes zu sehen:

Abbildung 7.8: Gelöste Bugs

Weiter unten sehen Sie dies:

Abbildung 7.9: Bug Optionen

Das gibt Ihnen die Möglichkeit, wenn Sie wollen, den Bug neu zu öffnen (z.B. weil die Entwickler glauben, er wäre gelöst, aber die Lösung eigentlich nicht Ihren Erwartungen entspricht). Unser Bug ist jetzt gelöst! Es können jedoch verschiedene Arten von Lösungen auftreten. Hier ist eine kleine Liste:

• FIXED - Der Bug ist gelöst, folgen Sie den Anweisungen, um Ihre Probleme zu lösen.
• INVALID - Sie haben etwas ausdrücklich Dokumentiertes nicht gemacht und dadurch den Bug ausgelöst.
• DUPLICATE - Sie haben sich nicht an diese Anleitung gehalten und einen schon vorhandenen Bug noch einmal erstellt.
• WORKSFORME - Entwickler oder zugeordnete Personen können den Fehler nicht reproduzieren.
• CANTFIX - Der Bug kann aus bestimmten Umständen nicht gelöst werden. Diese Umstände werden von der Person, die sich um den Bug kümmert, notiert.
• WONTFIX - Dies wird normalerweise bei Anfragen nach neuen Ebuilds oder Feature-Requests gesetzt. Im Wesentlichen will der Entwickler ein bestimmtes Feature nicht hinzufügen, weil es entweder nicht gebraucht wird, eine bessere Alternative existiert oder einfach nur kaputt ist. Manchmal wird Ihnen eine Lösung mitgeteilt, wie Sie mit der Sache umgehen können.
• UPSTREAM - Der Bug kann nicht vom Gentoo Entwickler-Team gelöst werden und Sie werden gebeten, das Problem Upstream (die Leute die eigentlich das Programm erstellt haben) anzusprechen. Upstream hat verschiedene Wege mit Bugs umzugehen. Diese enthalten Mailinglisten, IRC-Channels und manchmal auch Bugreporting-Systeme. Wenn Sie sich nicht sicher sind, wie Sie Upstream erreichen können, fragen Sie im Bugreport nach und jemand wird Sie in die richtige Richtung stoßen.

Manchmal wird ein Entwickler Sie bitten, ein aktualisiertes Ebuild zu testen, bevor der Bug als gelöst markiert werden kann. Im nächsten Kapitel werden wir einen Blick darauf werfen, wie man Ebuilds testet.

8.  Ebuilds testen

Holen der Dateien

Nehmen wir an, Sie haben einen Bug für den foobar2 Compile-Fix von vorhin gemeldet. Jetzt könnten Entwickler herausfinden, wo das Problem liegt und brauchen möglicherweise Ihre Hilfe, um zu sicherzustellen, dass das Ebuild auch für Sie funktioniert:

Abbildung 8.1: Ebuild Testanfrage

Einige eher verwirrende Vokabeln werden hier benutzt. Als erstes sehen wir uns an, was ein Overlay ist. Ein Overlay ist ein besonderes Verzeichnis, wie /usr/portage, mit dem Unterschied, dass wenn Sie emerge sync benutzen, Dateien darin nicht gelöscht werden. Glücklicherweise wird dazu ein spezielles Verzeichnis /usr/local/portage erstellt. Lassen Sie uns fortfahren und unser Portage Overlay in /etc/make.conf eintragen. Öffnen Sie make.conf in Ihrem Lieblingseditor und fügen Sie gegen Ende folgendes ein.

PORTDIR_OVERLAY="/usr/local/portage"

Jetzt wollen wir die entsprechenden Verzeichnisse erstellen und die Dateien unseres Test-Ebuilds hinzufügen. In diesem Fall müssen wir die Dateien in das Verzeichnis sys-apps/foobar2 packen. Sie werden feststellen, dass der zweite Kommentar nach einem Verzeichnis files für den Patch fragt. Dieses Verzeichnis enthält andere benötigte Dateien, die nicht im Standardquellarchiv enthalten sind (Patches, init.d-Skripte, usw). Das ist ein Unterverzeichnis im Paketverzeichnis mit dem Namen files. Fahren Sie fort und erstellen Sie dieses Verzeichnis:

# mkdir -p /usr/local/portage/sys-apps/foobar2/files

Ok, jetzt können wir fortfahren und die Dateien herunterladen. Als erstes laden Sie das Ebuild nach /usr/local/portage/sys-apps/foobar2 herunter, und danach den Patch nach /usr/local/portage/sys-apps/foobar2/files. Jetzt, da wir alle benötigten Dateien haben, können wir mit dem Testen des Ebuilds anfangen.

Testen des Ebuilds

Der Prozess um ein Ebuild zu erstellen, das durch emerge genutzt werden kann, ist ziemlich einfach. Sie müssen eine Manifest-Datei für das Ebuild erstellen. Das kann mit dem ebuild-Befehl gemacht werden. Starten Sie ihn wie hier gezeigt:

# ebuild foobar2-1.0.ebuild manifest
>>> Creating Manifest for /usr/local/portage/sys-apps/foobar2

Jetzt testen wir, ob es wie erwartet funktioniert.

# emerge -pv foobar2

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] sys-apps/foobar2-1.0  0 kB [1]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage

Es sieht aus, als hätte es funktioniert! Sie werden die [1] neben der [ebuild]-Zeile bemerkt haben. Diese zeigt auf /usr/local/portage, was das vorhin erstellte Overlay ist. Jetzt fahren Sie fort und emergen das Paket.

# emerge foobar2
 Calculating dependencies ...done!
(compile info ausgeschnitten)
>>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
 * Applying foobar2-1.0-Makefile.patch ...                                    [ ok ]
(compile info ausgeschnitten)
>>> Merging sys-apps/foobar2-1.0 to /
>>> chris +sandbox(preinst)
--- /usr/
--- /usr/bin/
>>> /usr/bin/foobar2

Im ersten Abschnitt sehen wir, dass der Emergevorgang wie gewünscht startet. Der zweite Abschnitt zeigt, durch die Statusmeldung "[ ok ]" am rechten Rand, dass unser Patch erfolgreich angewandt wurde. Der letzte Abschnitt sagt uns, dass das Programm fehlerfrei kompiliert wurde. Unser Patch funktioniert! Jetzt können wir dem Entwickler mitteilen, dass sein Patch funktioniert und er den Fix in Portage einspielen kann.

Fazit

Das schließt dieses Howto bezüglich der Arbeit mit Bugzilla ab. Ich hoffe, Sie fanden es hilfreich. Wenn Sie Fragen, Kommentare oder Anregungen zu diesem Dokument haben, senden Sie diese (auf Englisch) bitte an mich unter Chris White. Besonderer Dank geht an moreon für seine Anmerkungen bezüglich des -g Flags und Kompilierfehler, die Leute in #gentoo-bugs für Ihre Hilfe mit dem Bug-Wrangling, Griffon26 für seine Anmerkungen bezüglich maintainer-needed, robbat2 für allgemeine Vorschläge und fox2mike für die Korrektur des Dokuments und das Hinzufügen von Inhalten.

Die Inhalte dieses Dokuments sind, sofern nicht explizit anders genannt, unter der Creative Commons - Namensnennung / Weitergabe Lizenz lizenziert. Die Gentoo Name and Logo Usage Guidelines treffen zu.