Ubuntu logo

Packaging Guide

3. Einen Bug in Ubuntu beheben

3.1. Einleitung

Wenn Sie die Anweisungen in sich für Ubuntu-Entwicklung einrichten befolgt haben, sollten Sie bereit sein loszulegen.

./_images/fixing-a-bug.png

Wie man in der obigen Abbildung sehen kann, gibt es wenig Überraschungen im Prozess der Fehlerbehebung: man findet ein Problem, lädt den Quellcode herunter, arbeitet an einer Lösung, lädt die notwendigen Änderungen nach Launchpad und bittet um einen Merge. In diesem Handbuch werden wir alle nötigen Schritte nacheinander behandeln.

3.2. Das Problem finden

Es gibt viele verschiedene Wege Dinge zu finden an denen man arbeiten kann. Es kann ein Fehlerbericht sein, der einen selbst betrifft (was das Testen vereinfacht), oder ein Problem, das man woanders beobachtet hat, vielleicht auch in einem Fehlerbericht.

Schauen Sie die the bitesize bugs in Launchpad an, was Ihnen eine Vorstellung davon gibt woran man arbeiten kann. Es interessiert Sie vielleicht auch, sich die Bugs anzuschauen, die vom Ubuntu Hundred Papercuts Team triaged wurden.

3.3. Herausfinden, was repariert werden muss

Wenn Sie das Quellpaket, das den Fehler beinhaltet nicht kennen, aber der Pfad zu dem betroffenen Programm auf Ihrem System bekannt ist, dann können Sie das Quellpaket selbst ermitteln, an dem Sie arbeiten müssen.

Nehmen wir an, dass Sie einen Bug in Bumprace, einem Rennspiel, gefunden haben. Die Bumprace Anwendung kann durch Aufruf von /usr/bin/bumprace auf der Kommandozeile gestartet werden. Um das Binärpaket zu finden, welches diese Anwendung enthält, verwenden Sie diesen Befehl:

$ apt-file find /usr/bin/bumprace

Dies gibt aus:

bumprace: /usr/bin/bumprace

Beachten Sie dass der Teil vor der Spalte das Binärpaketname ist. Oft ist es so, dass das Quellpaket und das Binärpaket unterschiedliche Namen haben werden. Dies passiert am häufigsten wenn ein einzelnes Quellpaket verwendet wird um verschiedene unterschiedliche Binärpakete bauen soll. Um das Quellpaket für ein bestimmtes Binärpaket zu finden, geben Sie folgendes ein:

$ apt-cache showsrc bumprace | grep ^Package:
Package: bumprace
$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy

apt-cache ist Teil der Standardinstallation von Ubuntu.

3.4. Das Problem bestätigen

Sobald Sie herausgefunden haben, in welchem Paket sich das Problem befindet, wird es Zeit zu bestätigen, dass das Problem existiert.

Sagen wir das Paket bumprace nennt keine Homepage in seiner Paketbeschreibung. In einem ersten Schritt würde man prüfen, ob das Problem nicht vielleicht bereits behoben ist. Das ist leicht herauszufinden, entweder man schaut in Software Center oder führt folgendes aus:

apt-cache show bumprace

Die Ausgabe sollte etwa so aussehen:

Package: bumprace
Priority: optional
Section: universe/games
Installed-Size: 136
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XNBC-Original-Maintainer: Christian T. Steigies <cts@debian.org>
Architecture: amd64
Version: 1.5.4-1
Depends: bumprace-data, libc6 (>= 2.4), libsdl-image1.2 (>= 1.2.10),
         libsdl-mixer1.2, libsdl1.2debian (>= 1.2.10-1)
Filename: pool/universe/b/bumprace/bumprace_1.5.4-1_amd64.deb
Size: 38122
MD5sum: 48c943863b4207930d4a2228cedc4a5b
SHA1: 73bad0892be471bbc471c7a99d0b72f0d0a4babc
SHA256: 64ef9a45b75651f57dc76aff5b05dd7069db0c942b479c8ab09494e762ae69fc
Description-en: 1 or 2 players race through a multi-level maze
 In BumpRacer, 1 player or 2 players (team or competitive) choose among 4
 vehicles and race through a multi-level maze. The players must acquire
 bonuses and avoid traps and enemy fire in a race against the clock.
 For more info, see the homepage at http://www.linux-games.com/bumprace/
Description-md5: 3225199d614fba85ba2bc66d5578ff15
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Ein Gegenbeispiel wäre gedit, welches eine Homepage gesetzt hat:

$ apt-cache show gedit | grep ^Homepage
Homepage: http://www.gnome.org/projects/gedit/

Manchmal stellt sich heraus, dass jemand das Problem, das Sie lösen wollten, schon bearbeitet hat. Um doppelte und nutzlose Arbeit zu verhindern, macht es Sinn zuerst ein wenig Detektivarbeit zu leisten.

3.5. Die Fehlersituation ansehen

Zuerst sollte man überprüfen ob bereits ein Bericht über das Problem in Ubuntu zu finden ist. Vielleicht arbeitet bereits jemand an einer Fehlerbehebung oder wir können zu der Lösung beitragen. Für Ubuntu werfen wir einen kurzen Blick auf https://bugs.launchpad.net/ubuntu/+source/bumprace und es gibt dort keinen offenen Problembericht.

Bemerkung

Für Ubuntu wird die URL https://bugs.launchpad.net/ubuntu/+source/<package> einen immer auf die Bug-Seite des jeweiligen Pakets führen.

Für Debian, welches die Hauptquelle für Ubuntu’s Pakete ist, schauen wir auf http://bugs.debian.org/src:bumprace und finden auch keinen bestehenden Fehlerbericht für unser Problem.

Bemerkung

Für Debian wird die URL http://bugs.debian.org/src:<package> einen immer auf die Bug-Seite des jeweiligen Pakets führen.

Wir arbeiten an einem besonderen Problem, da es nur die für das Paketieren relevanten Teile des bumprace betrifft. Wenn es ein Problem im Quellcode wäre, würde es hilfreich sein auch den Upstream-Bugtracker zu überprüfen. Das ist leider von Paket zu Paket unterschiedlich; aber wenn Sie im Web danach suchen, sollte es in den meisten Fällen einfach zu finden sein.

3.6. Hilfe anbieten

Wenn Sie einen offenen Fehler gefunden haben, dieser noch nicht zugewiesen ist und Sie die Möglichkeit haben ihn zu beheben, sollten Sie einen Kommentar mit Ihrem Lösungsvorschlag abgeben. Geben Sie so viele Informationen wie möglich an: Unter welchen Umständen tritt der Fehler auf? Wie haben Sie den Fehler behoben? Haben Sie die Lösung getestet?

Wenn noch kein Fehlerbericht eingesandt wurde, können Sie das tun. Was Sie im Kopf behalten solltn ist: ist das Problem klein genug, dass man vielleicht einfach jemand direkt darum bittet einen Patch hoch zu laden? Haben Sie es vielleicht geschafft einen Teil des Problems zu beheben und wollen dies mitteilen?

Es ist toll wenn Sie Hilfe anbieten können und man wird dafür sehr dankbar sein.

3.7. Den Quellcode herunterladen

Sobald das Quellpaket bekannt ist auf dem gearbeitet werden soll, möchten Sie wahrscheinlich eine Kopie des Codes haben damit Sie diesen verbessern können. Das ubuntu-dev-tools Paket beinhaltet ein Werkzeug namens pull-lp-source welches ein Entwickler nutzen kann um den Quelltext jedes Pakets zu bekommen. Beispiel: Um den Sourcecode für das das Paket tomboy zu in xenial zu bekommen, können Sie dies eingeben:

$ pull-lp-source bumprace xenial

Wird keine Veröffentlichung wie xenial angeben, wird automatisch das Paket der Entwicklungsversion geholt.

Sobald man eine lokale Kopie des Quellpakets hat, kann man den Bug untersuchen, eine Behebung erstellen, ein debdiff erstellen und sein debdiff an einen Bug-Report zur Überprüfung durch andere Entwickler anhängen. Wir werden die Besonderheiten in den nächsten Abschnitten beschreiben.

3.8. Arbeiten an einer Fehlerbehebung

Es wurden ganze Bücher darüber verfasst, wie man Fehler findet, sie behebt, testet, usw. Wenn Sie ein Anfänger im Programmieren sind, versuchen Sie zuerst einfache Fehler wie beispielsweise in der Rechtschreibung zu beheben. Versuchen Sie die Änderungen so minimal wie möglich zu halten und dokumentieren Sie Ihre Änderungen und Annahmen übersichtlich.

Bevor Sie sich daran machen, einen Fehler selbst zu beheben, sollten Sie sicherstellen, dass nicht schon ein anderer diesen Fehler behoben hat oder gerade daran arbeitet. Anlaufstellen dafür sind:

  • Upstream (und Debian) Fehlererfassung (offene and geschlossene Fehler),

  • Die Upstream-Revisionseinträge (oder eine neue Veröffentlichung) haben möglicherweise das Problem behoben,

  • Fehler oder Paket-Uploads von Debian oder einer anderen Distribution

Sie möchten vielleicht einen Patch erstellen, der die Behebung enthält. Der Befehl edit-patch ist eine einfache Art einen Patch einem Paket hinzuzufügen. Starten Sie:

$ edit-patch 99-new-patch

Das wird die Paketierung in temporäres Verzeichnis kopieren. Sie können nun die Dateien mit einem Texteditor bearbeiten oder die Patches vom Upstream anwenden, zum Beispiel:

$ patch -p1 < ../bugfix.patch

Nachdem Sie die Datei bearbeitet haben, schreiben Sie exit oder drücken Strg+D um die zeitweilige Umgebung zu verlassen. Der neue Patch wird dann unter debian/patches eingefügt.

Sie müssen dann einen Header zu Ihrem Patch inklusive Metainformationen hinzufügen, so dass andere Entwickler den Zweck des Patches kennen und woher dieser stammt. Um den Vorlagen-Header zum Editieren zu bekommen, um zu zeigen was der Patch macht, geben Sie folgendes ein:

$ quilt header --dep3 -e

Dies wird die Vorlage in einem Texteditor öffnen. Folgen Sie der Vorlage und vergewisseren sich, dass Sie ausführlich sind, so dass alle nötigen Details, die den Patch beschreiben, vorhanden sind.

Wenn Sie nur``debian/control`` in diesem spezifischen Fall bearbeiten möchten brauchen Sie keinen Patch. Tragen Sie Homepage: http://www.linux-games.com/bumprace/ am Ende der ersten Sektion ein und der Bug sollte behoben sein.

3.8.1. Die Lösung dokumentieren

Es ist sehr wichtig Ihre Änderung ausreichend zu dokumentieren, so dass Entwickler, die sich den Code zukünftig ansehen, nicht raten müssen, was Ihre Gründe und Annahmen gewesen sind. Jedes Debian- und Ubuntu-Quellpaket beinhaltet die Datei debian/changelog, wo die Änderungen jedes hochgeladenen Paketes dokumentiert werden.

Die einfachste Möglichkeit um zu updaten ist den Befehl auszuführen:

$ dch -i

Dies wird eine Vorlage für einen Changelog-Eintrag für Sie erstellen, wo Sie die Lücken ausfüllen können. Ein Beispiel dafür wäre etwa:

specialpackage (1.2-3ubuntu4) trusty; urgency=low

  * debian/control: updated description to include frobnicator (LP: #123456)

 -- Emma Adams <emma.adams@isp.com>  Sat, 17 Jul 2010 02:53:39 +0200

dch sollte die erste und letzte Zeile von solch einem Änderungsprotokolleintrag bereits für Sie ausgefüllt haben. Zeile 1 enthält den Quellpaketnamen, die Versionsnummer, die Ubuntu-Zielversion und die Dringlichkeit (welche meistens »low« ist). Die letzte Zeile enthält immer den Namen des Autors, E-Mail-Adresse und Zeitstempel (im Format RFC 5322) der Änderung.

Wenn dieses Hindernis beseitigt ist, können wir uns auf den eigentlichen Eintrag des Änderungsprotokolls selbst konzentrieren: Es ist sehr wichtig festzuhalten:

  1. Wo die Änderung gemacht wurde.

  2. Was geändert wurde.

  3. Wo die Diskussion um die Änderung statt fand.

In unserem (sehr dürftigen) Beispiel ist der letzte Punkt mit (LP: #123456) abgedeckt, was sich auf den Launchpad-Fehler 123456 bezieht. Fehlerberichte, Beiträge zu Mailing-Listen oder Spezifikationen sind allgemein gute Informationen, die als Rationale für eine Änderung angegeben werden können. Zusätzlich wird im Falle der Verwendung von LP: #<Nummer> der angegebene Fehler automatisch geschlossen, wenn das Paket zu Ubuntu hochgeladen wird.

Um Unterstützung im nächsten Abschnitt zu bekommen ist es nötig, einen Bugreport in Lauchpad zu erstellen (falls noch keiner vorhanden ist, falls doch – verwenden Sie diesen) und zu erklären warum Ihre Behebung in Ubuntu enthalten sein sollte. Beispielsweise bei tomboy würde man einen Bug hier angeben (bearbeiten Sie die URL für das Paket für das Sie eine Behebung haben). Sobald ein Bug aufgegeben wurde, der Ihre Änderungen erklärt, geben Sie diese Bugnummer im Changelog ein.

3.9. Die Lösung testen

Um ein Testpaket mit Ihren Änderungen zu bauen, durchlaufen Sie diese Kommandos:

$ debuild -S -d -us -uc
$ pbuilder-dist <release> build ../<package>_<version>.dsc

Dies wird ein Quellpaket von den Zweiginhalten (-us -uc wird nur den Schritt der Unterzeichnung des Quellpakets überspringen und``-d`` wird den Schritt der Prüfung nach Build-Abhängigkeiten auslassen, pbuilder wird sich darum kümmern) und pbuilder-dist wird das Paket aus den Quellen für jegliches gewählte release bauen.

Bemerkung

Wenn debuild folgende Fehlermeldung ausgibt “Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address” starten Sie den update-maintainer Befehl (aus ubuntu-dev-tools) und es wird dies automatisch für Sie beheben. Dies passiert weil in Ubuntu alle Ubuntu Entwickler für alle Ubuntu-Pakete verantwortlich sind. In Debian hingegen haben die Pakete Maintainer.

Im Falle von bumprace, starten Sie folgendes um die Paketinformationen zu sehen:

$ dpkg -I ~/pbuilder/*_result/bumprace_*.deb

Wie erwartet sollte nun ein Homepage: Feld dort sein.

Bemerkung

In vielen Fällen werden Sie das Paket auch installieren müssen, um zu prüfen, dass alles funktioniert. In unserem Fall ist das viel einfacher. Wenn der Build erfolgreich war, werden Sie die Binärpakete in ~/pbuilder/<release>_result finden. Installieren Sie sie einfach per sudo dpkg -i <package>.deb oder indem Sie auf sie im Dateimanager doppelt-klicken.

3.10. Einreichen der Behebung und es einbringen

Sobald der changelog Eintrag geschrieben und gespeichert ist, starten Sie debuild noch einmal:

$ debuild -S -d

und dieses Mal wird es unterschrieben werden und Sie sind nun bereit, Ihr diff einzuschicken und Unterstützung zu bekommen.

In vielen Fällen möchte Debian eventuell den Patch ebenfalls haben (dies zu tun ist vorbildlich um sicherzustellen dass ein weiterer Kreis die Behebung bekommt). Somit sollten Sie den Patch an Debian schicken und Sie können dies wie folgt tun:

$ submittodebian

Dies wird Sie durch eine Reihe von Schritten führen, um sicherzustellen, dass der Bug an der richtigen Stelle landet. Überprüfen Sie das Diff noch einmal, um sicherzustellen, dass es keine unerwünschten Änderungen enthält, die Sie vorher gemacht haben.

Kommunikation ist wichtig, also sollten Sie mehr Beschreibung mitliefern, wenn Sie darum bitten die Änderung einzupflegen. Seien Sie freundlich, erklären Sie es ausreichend.

Wenn alles geklappt hat, sollten Sie eine Mail von Debian’s Bug-Tracker mit weiteren Informationen bekommen. Dies kann manchmal einige Minuten dauern.

Es mag vorteilhaft sein, es einfach in Debian einzubringen und es zu Ubuntu fließen zu lassen. In diesem Falle folgt man nicht dem untenstehenden Prozess. Aber manchmal im Falle von Security-Updates und Updates für stabile Veröffentlichungen ist die Behebung bereits in Debian enthalten (oder wird aus einem bestimmten Grund ignoriert) und Sie möchten dem untenstehenden Prozess folgen. Wenn Sie solche Updates machen, lesen Sie bitte unseren Artikel Security and stable release updates. Andere Fälle wo es möglich ist zu warten Patches an Debian zu schicken, sind reine Ubuntu Pakete, die nicht korrekt bauen oder Ubuntu-spezifische allgemeine Probleme.

Aber wenn Sie vorhaben Ihre Behebung an Ubuntu zu schicken wird es nun Zeit, ein “debdiff” zu erstellen. Dieses soll den Unterschied zwischen zwei Debian Paketen zeigen. Der Name des Befehls um eins zu erstellen ist ebenfalls debdiff. Es ist Teil des devscripts Pakets. Siehen Sie man debdiff für alle Details. Um zwei Quellpakete zu vergleichen, geben Sie die zwei dsc-Dateien als Argumente an:

$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc

In diesem Fall wenden Sie ein debdiff auf das heruntergeladene dsc mit pull-lp-source an sowie auf die neue dsc-Datei die Sie erstellt haben. Dies wird einen Patch erstellen, die Ihr Sponst lokal anwenden kann (durch patch -p1 < /path/to/debdiff). In diesem Fall wenden Sie eine Pipe auf die Ausgabe des debdiff Befehls auf eine Datei an, die man dann dem Bugreport anhängen kann:

$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc > 1-1.0-1ubuntu1.debdiff

Das Format, welches in 1-1.0-1ubuntu1.debdiff gezeigt wird, zeigt:

  1. 1- informiert den Betreuer, dass dies die erste Revision Ihres Patches ist. Niemand ist perfekt und machmal müssen Nachfolge-Patches angeboten werden. Dies stellt sicher, dass falls Ihr Patch mehr Arbeit benötigt, man ein konsistentes Namensschema verwenden kann.

  2. 1.0-1ubuntu1 zeigt die neue Version, die verwendet wird. Dies macht es einfach festzustellen, welche die neue Version ist.

  3. .debdiff ist eine Erweiterung, die illustriert, dass es ein debdiff ist.

Während dieses Format optional ist, funktioniert es gut und Sie können dies verwenden.

Gehen Sie anschließend zu dem Fehlerbericht, vergewisseren Sie sich, dass Sie auf Launchpad eingeloggt sind und klicken auf “Add attachment or patch” wo Sie einen neuen Kommentar hinzufügen. Hängen Sie das debdiff an und hinterlassen einen Kommentar, der Ihrem Betreuer sagt, wie dieser Patch angewendet werden kann und welche Tests erfolgt sind. Ein Beispielkommentar kann wie folgt aussehen:

This is a debdiff for Artful applicable to 1.0-1. I built this in pbuilder
and it builds successfully, and I installed it, the patch works as intended.

Vergewissern Sie sich, dass Sie es als einen Patch markieren (das Ubuntu Sponsors Team wird automatisch abonniert) und dass Sie den Fehlerbericht abonniert haben. Sie werden dann eine Durchsicht irgendwo zwischen mehreren Stunden seit dem Einreichen des Patches zu mehreren Wochen bekommen. Wenn dies länger dauern sollte, treten Sie bitte #ubuntu-motu auf freenode bei und erwähnen es dort. Bleiben Sie so lange da, bist Sie eine Antwort von jemand bekommen und diese Leute Sie anweisen, was als nächstes zu tun ist.

Sobald Sie einen Review erhalten haben, wurde Ihr Patch entweder hochgeladen, Ihr Patch braucht noch Arbeit oder wurde aus anderen Gründen abgelehnt (eventuell passt die Behebung nicht für Ubuntu und sollte stattdessen zu Debian gehen). Wenn den Patch noch etwas Arbeit benötigt, folgen Sie den gleichen Schritten und senden einen Folge-Patch im Bugreport. In anderen Fällen senden Sie diesen an Debian wie oben gezeigt.

Bedenken Sie: Gute Orte um Ihre Fragen zu stellen sind ubuntu-motu@lists.ubuntu.com und #ubuntu-motu auf freenode. Sie werden leicht viele neue Freunde finden sowie Leute mit der gleichen Leidenschaft, wie Sie sie haben: Die Welt einen besseren Ort durch die Herstellung besserer Open Source Software machen.

3.11. Weitere Überlegungen

Wenn Sie ein Paket finden und es sich herausstellt, dass Sie mehrere triviale Dinge darin beheben können, machen Sie es ruhig in einer Änderung. Das wird die Code-Review und das Einpflegen beschleunigen.

Sollte es mehrere große Dinge geben, die Sie beheben wollen, mag es Sinn ergeben stattdessen mehrere Patches oder Merge Proposals einzuschicken. Sollte es bereits individuelle Bugs dafür geben, macht das die Sache sogar noch einfacher.