Wie man veröffentlichungskritische Bugs in Debian beseitigt

Es hält sich hartnäckig das Gerücht, dass es so etwas wie einen Konkurrenzkampf zwischen Debian und Ubuntu gebe. Tatsächlich ermutigt Ubuntu jedoch neue Software über Debian einzubringen. Im Umkehrschluss heißt das auch, dass jeder Beitrag zu Debian auch ein Beitrag zu Ubuntu ist.
In diesem Artikel geht es darum, dass auch ein kleiner Beitrag der gesamten Distribution weiterhelfen kann und dass das Beseitigen von Bugs, Modifizieren von Quelltext und die Neuerstellung des Pakets kein Hexenwerk sein muss. Besonders hilfreich ist das Beseitigen von sogenannten veröffentlichungskritischen Bugs, kurz RC-Bugs genannt.

Der grobe Ablauf

  1. Finde einen RC-Bug, der dich interessiert.
  2. Erstelle einen Patch für das Problem.
  3. Schicke die Lösung an die Fehlerdatenbank von Debian.
  4. Finde jemanden, der das Paket hochladen kann.

Finde einen RC-Bug

Erster Anlaufpunkt um einen RC-Bug zu finden ist die Ultimative Debian Datenbank (UDD). Hier lässt sich mit Hilfe verschiedener Filteroptionen die Suche exakt einschränken. Für den angehenden Kammerjäger ist diese Ansicht die zur Zeit beste. Wichtig ist, dass man alle schon mit Patch markierten Bugs und alle die neuer als 7 Tage sind ignorieren kann, da es bei ersteren eine Lösung gibt und bei letzteren dem Paketverwalter zumindest eine Chance eingeräumt werden sollte, das Problem selbst zu lösen.
Ein hilfreiches Werkzeug ist das Programm rc-alert, welches sich im Paket devscripts befindet und anzeigt, welche Software auf dem eigenen Rechner kritische Fehler aufweist. Ein Bonus von rc-alert ist, dass es nach Debtags filtern kann.
Mit dem nachfolgenden Befehl werden nur Debian Testing und Unstable nach Bugs durchsucht und geflickte und kurz vor dem Upload stehende Pakete ausgelassen. Zusätzlich wird nur jene Software aufgelistet, die in Perl oder Python implementiert worden ist.
rc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python
Multi Disk Error

Erstelle einen Patch

In vielen Fällen benötigt man nicht einmal Kenntnisse in einer Programmiersprache, sondern es genügt mit einem Texteditor umgehen zu können. In Bug #675220, #685959 und #685958 geht es schlicht darum, dass die E-Mail-Adresse des Paketverwalters ungültig ist, was gegen die Paketrichtlinien von Debian verstößt. Genauso gut kann aber auch eine Abhängigkeit falsch sein, wodurch das Paket sich nicht mehr kompilieren lässt. Diese Art von Fehler haben zwar ernste Auswirkungen, lassen sich jedoch in der Regel leicht beheben.
Zum Arbeiten mit Quellpaketen solltet ihr euch das Paket build-essential oder, wenn ihr Gefallen an der Sache gefunden habt, packaging-dev installieren.
apt-get source textedit.app
Mit Hilfe von dpkg-dev wird automatisch das Quellpaket entpackt. Nachdem man in das entpackte Quellverzeichniss gewechselt ist, sollte man zuerst einen neuen Changelog-Eintrag anlegen und deutlich machen, dass man hier eine Änderung als Nicht-Paketverwalterin vornimmt.
dch --nmu
Hierdurch wird automatisch das Changelog mit dem richtigen Eintrag geöffnet. Da der Patch für Unstable gedacht ist (der Regelfall) sollte das UNRELEASED dementsprechend in unstable umgeändert werden. Noch eine kurze Beschreibung, was ihr geändert habt und ein wichtiger Schritt für einen Non-Maintainer-Upload (NMU) ist getan.

textedit.app (4.0+20061029-3.4) unstable; urgency=low
  * Non-maintainer upload.
  * Fix invalid maintainer email address. (Closes: #675220)

Der wichtigste Anlaufpunkt im Quellpaket ist das Debian-Verzeichnis. In debian/control lassen sich z.B. allgemeine Paketinformationen wie die E-Mail-Adresse des Maintainers, Abhängigkeiten oder auch die empfohlenen Pakete in einer einfachen Textdatei definieren. Der "Fix" für die vorher erwähnten Bugs war es, das Maintainer-Feld zu aktualisieren. Gäbe es noch weitere Änderungen zu machen, könnte man mit
dch -a
weitere Einträge zum Changelog hinzufügen und die entsprechende Textdateien innerhalb des Debian-Verzeichnisses ändern.

Einen Patch mit Quilt erstellen

Müsst ihr hingegen den Quellcode selbst patchen und entspricht das Paket dem neuen Format 3.0 (quilt), könnt ihr quilt zum Patchen benutzen. Ob ein Paket dies unterstützt findet ihr heraus, indem ihr einen Blick in die Datei debian/source/format werft. Raphaël Hertzog hat die Bedienung von quilt in einem sehr guten Artikel auf den Punkt gebracht.
Der grobe Ablauf ist, dass ihr innerhalb des Debian-Verzeichnisses einen Ordner patches erstellen müsst, falls er nicht vorhanden ist und dann nach diesem Schema Patches erzeugt.

  • Erstellt einen neuen Patch
    quilt new NamedesPatches
  • Verändert eine oder mehrere Dateien nach Belieben
    quilt edit Datei
  • Wendet den Patch auf die Originaldatei an
    quilt push
  • Erneuert den Patch, wenn er schon existiert.
    quilt refresh

Einen Patch importieren

quilt import -P NamedesPatches /Pfad-zum-Patch.patch
quilt push
Häufig kommt es auch vor, dass schon jemand einen Patch hinterlassen hat und man ihn selbst ausprobieren oder testen möchte.

Schicke den Patch an die Fehlerdatenbank

Ist man der Meinung alles erledigt zu haben, sollte man zuerst alle Patches wieder zurücksetzen und das Quellpaket neu bauen.
Innerhalb des Quellverzeichnisses:
quilt pop -a
Dann

cd ..
dpkg-source -b textedit.app-4.0+20061029

Wenn ihr alles richtig gemacht habt, müsste nun eine weitere .dsc-Datei entstanden sein. Mit Hilfe von debdiff, dass sich auch im Paket devscripts befindet, lassen sich nun alle gemachten Unterschiede als Diff in eine neue Datei ausgeben, der Patch.
Allgemein:

debdiff altesPaket.dsc neuesPaket.dsc > Paket.debdiff

Im Speziellen:

debdiff textedit.app_4.0+20061029-3.3.dsc textedit.app_4.0+20061029-3.4.dsc > textedit.app.debdiff

Diese Datei muss jetzt nur noch per Mail an den Fehlerbericht geschickt werden und dieser mit dem passenden Tag patch markiert werden. Die Anleitung zur Bedienung der Fehlerdatenbank verrät alle Details. Zum Markieren als Patch genügt eine Mail an control@bugs.debian.org mit folgendem Inhalt, wobei nnnnnn für die Fehlernummer steht

tags nnnnnn patch
thanks

Einen Sponsor finden

Im Regelfall sollte das Anhängen des Patches an den Fehlerbericht mehr als ausreichend sein. Es besteht jedoch auch die Möglichkeit das Paket direkt zu mentors.debian.net hochzuladen, wo ihr Hilfe von Debianentwicklern erhalten könnt. Vorher müsst ihr noch wissen, wie man Debianpakete aus den Quellen baut, was auch zum Testen des Patches nützlich ist.
Habt ihr einen Account bei den Mentoren erstellt und seid ihr den Regeln für einen Non-Maintainer-Upload gefolgt, sind die Aussichten gut dort jemanden zu finden, der das gepatchte Paket in das Archiv hochladen kann. Vorausgesetzt natürlich, es löst tatsächlich das Problem.

Lesenswerte und inspirierende Links

2 Replies to “Wie man veröffentlichungskritische Bugs in Debian beseitigt”

Schreibe einen Kommentar zu Anonymous Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.