Ubuntu logo

Packaging Guide

Ubuntu Packaging Handbuch

Willkommen zum Leitfaden für Ubuntu-Paketierung und -Entwicklung! Es ist der offizielle Anlaufpunkt um alles über das Thema Ubuntu-Entwicklung und -Paketierung zu lernen. Nachdem du diesen Leitfaden abgehandelt hast, wirst du:

  • von den wichtigsten Spielern, Prozessen und Werkzeugen in der Ubuntu-Entwicklung gehört,
  • deine Entwicklungsumgebung erfolgreich eingerichtet,
  • eine bessere Vorstellung von der Gemeinschaft und ihrem Zugang,
  • einen tatsächlichen Fehler in Ubuntu als Teil der Anleitungen behoben haben.

Ubuntu ist nicht nur eine freies Open Source Betriebssystem, seine Platform ist auch offen und wird in einer transparenten Art entwickelt. Der Quellcode für jede einzelnen Komponente kann einfach besorgt werden und jede einzelne Änderung an der Ubuntu Plattform kann angeschaut werden.

Das heißt, Du kannst selbst aktiv werden und die Dinge verbessern. Die Gemeinschaft der Ubuntu Plattform Entwickler ist immer an neuen Kollegen, die gerade anfangen, interessiert.

Ubuntu ist außerdem eine Gemeinschaft von tollen Leuten, die an freie Software glauben und dass jeder Zugang dazu haben sollte. Die Mitglieder sind einladend und freuen sich, wenn Du mit machen willst. Wir freuen uns über Fragen und wenn Du anfängst, Ubuntu zusammen mit uns besser zu machen.

Solltest Du Probleme haben: keine Panik! Schau Dir den Artikel über Kommunikation an und Du wirst sehen, wie Du am leichtesten in Kontakt mit anderen Entwicklern kommst.

Die Anleitung teilt sich in zwei Bereiche auf:

  • Eine Liste von Artikel, die spezifische Aufgaben betreffen.
  • Eine Sammlung von Knowledge-Base Artikel, die in’s Detail gehen und Werkzeuge und Workflows erklären.

Dieser Leitfaden konzentriert sich auf die verteilte Ubuntu Entwicklungs-Methode. Das ist ein neuer Paketierungsweg, der verteilte Zweige zur Versionsverwaltung verwendet. Er hat momentan einige Beschränkungen, die dazu führen, dass viele Teams in Ubuntu traditionelle Paketierungsmethoden verwenden. Siehe die Seite UDD Einleitung für eine Einführung in die Unterschiede.

Artikel

Einführung in die Ubuntu-Entwicklung

Ubuntu besteht aus tausenden verschiedenen Komponenten, geschrieben in vielen verschiedenen Programmiersprachen. Jede Komponente - sei es eine Softwarebibliothek, ein Werkzeug oder eine grafische Anwendung - ist als Quellpaket erhältlich. Quellpakete bestehen in den meisten Fällen aus zwei Teilen: dem eigentlichen Quellcode und den Metadaten. Metadaten enthalten die Abhängigkeiten des Pakets, Informationen zum Urheberrecht und zur Lizenz, und Einweisungen wie das Paket erstellt werden soll. Ist das Quellpaket einmal kompiliert, werden durch den Erstellungsprozess Binärpakete zur Verfügung gestellt, welche der Benutzer in Form von .deb Dateien installieren kann.

Immer, wenn eine neue Version einer Anwendung veröffentlicht wird oder jemand eine Änderung am Quelltext von Ubuntu durchführt, muss der Quelltext in Launchpad hochgeladen werden, um dort in Binärdateien übersetzt zu werden. Die entstandenen Binärdateien werden auf alle Spiegelserver in verschiedenen Ländern verteilt. Die Adressen in der Datei /etc/apt/sources.list verweisen auf das Hauptarchiv oder Spiegelserver. Jeden Tag werden diverse Abbilddateien von Ubuntu erzeugt, die für die verschiedenen Einsatzbereiche optimiert sind. Es gibt beispielsweise Abbilddateien, die Sie auf einem USB-Stick ablegen oder auf eine DVD brennen können, andere sind für das Starten über ein Netzwerk optimiert und wieder andere können auf Mobiltelefonen oder Tablet-PCs installiert werden. Ubuntu Desktop, Ubuntu Server, Kubuntu und weitere Versionen benötigen unterschiedliche Pakete für ihre jeweilige Abbilddatei. Die so entstandene Abbilddateien werden zum Testen der Installation eingesetzt und ermöglichen Rückschlüsse auf die weitere Entwicklungsplanung.

Die Entwicklung von Ubuntu ist sehr stark abhängig vom aktuelle Veröffentlichungszyklus. Alle 6 Monate wird eine neue Version von Ubuntu veröffentlicht. Dies ist aber nur möglich, weil es fest definierte Enddaten für den Eingang neuer Paketversionen gibt. Ab diesem Datum sind Entwickler dazu angehalten, nur noch kleinere Veränderungen vorzunehmen. Nach der Hälfte des Entwicklungszeitraumes ist das sogenannte »Feature Freeze« erreicht, bis zu dem alle neuen Funktionalitäten implementiert sein müssen. In der restlichen Zeit wird hauptsächlich an der Fehlerbehebung gearbeitet. Zu diesem Zeitpunkt werden die Benutzeroberfläche, die Dokumentation, der Kernel usw. gesperrt, die »Beta-Phase« ist erreicht, in der sehr viele Tests durchgeführt werden. Von nun an werden nur noch kritische Fehler behoben und eine Vorveröffentlichung wird erstellt. Sobald keine größeren Probleme mehr auftreten, wird daraus die letztendliche neue Versionsveröffentlichung.

./_images/cycle-items.png

Tausende Quellpakete, Millionen von Codezeilen und hunderte beteiligte Personen benötigen eine gute Kommunikation und Planung, um einen hohen Qualitätsstandard zu halten. Am Anfang sowie in der Mitte eines Veröffentlichungszyklus findet eine Veranstaltung Namens »Ubuntu Developer Summit« statt, bei dem Entwickler und sonstige beteiligte Personen zusammentreffen und zukünftige Funktionalitäten der nächsten Version planen. Die zuständigen Projektgruppen diskutieren dort über diese Funktionalitäten und stellen eine Spezifikation auf, in der alle detaillierten Informationen, Erwartungen, Implementierungen, nötigen Veränderungen an anderen Stellen und Testbedingungen enthalten sind. Der komplette Prozess ist dabei transparent und für jeden einsehbar, sodass Sie auch teilnehmen können, ohne direkt anwesend zu sein. Dazu gibt es Videoübertragungen, Chats mit Teilnehmern oder auch das Abonnement der Änderungen an Spezifikationen. Sie sind also immer auf dem neusten Stand.

Aber nicht jede einzelne Änderung kann bei einem solchen Treffen diskutiert werden, besonders, weil Ubuntu auch von Änderungen in vielen anderen Projekten abhängt. Deshalb stehen alle an Ubuntu beteiligten Menschen dauerhaft in Kontakt. Die meisten Projekte benutzen eigene externe Mailinglisten, um nicht den Überblick in der Hauptarbeit zu verlieren. Für eilige Änderungen benutzen Entwickler und alle Beitragenden außerdem noch den Internet Relay Chat (IRC). Jegliche Diskussionen sind offen und öffentlich einsehbar.

Ein weiteres wichtiges Werkzeug, welches die Kommunikation betrifft ist, sind Fehlerberichte. Wann immer ein Defekt in einem Paket oder einem Teil der Infrastruktur gefunden wird, wird ein Fehlerbericht auf Launchpad eingereicht. Jede Information ist diesem Bericht vereinigt und seine Wichtigkeit, Status und Bearbeiter werden bei Bedarf angepasst. Das macht es zu einem effektiven Werkzeug den Fehlern in einem Paket oder Projekt Herr zu bleiben und den Arbeitsaufwand zu organisieren.

Die meiste in Ubuntu erhältliche Software ist nicht von den Ubuntu-Entwicklern selbst geschrieben, sondern von Entwicklern anderer Open-Source-Projekte und die dann in Ubuntu eingefügt wird. Diese Projekte werden “Upstreams” genannt, weil ihr Quellcode in Ubuntu einfließt, wo wir ihn “nur” integrieren. Die Beziehung zu den Upstreams is von kritischer Wichtigkeit für Ubuntu. Es ist nicht nur der Code den wir von ihnen bekommen, sondern sie bekommen von uns auch Benutzer, Fehlerberichte und Fehlerbehebungen von Ubuntu (und anderen Distributionen).

Der wichtigste Upstream für Ubuntu ist Debian. Debian ist die Distribution auf der Ubuntu aufbaut und viele der Entscheidungen über das Designs der Paket-Infrastruktur werden dort getroffen. Traditionell hatte Debian schon immer eigene Betreuer oder ganze Entwicklerteams für jedes einzelne Paket. In Ubuntu gibt es auch Teams die ein Interesse an einer Einheit von Paketen zeigen und natürlicherweise hat jeder Entwickler ein Spezialgebiet. Jedoch sind Teilnahme (und Rechte zum Hochladen) generell offen für jeden der Fähigkeiten und Willen zeigt.

Selber zu Ubuntu beizutragen ist nicht so schwierig wie es scheint und kann durchaus eine lohnenswerte Erfahrung sein. Dabei geht es nicht nur darum, etwas neues und spannendes zu lernen, sondern auch um das Lösen von Problemen und so das Helfen von millionen von Menschen.

Quelloffene Entwicklung geschieht in einer dezentralen Art mit unterschiedlichen Zielen. Beispielsweise kommt es vor, dass ein Entwickler gerne eine neue großartige Funktion implementieren möchte, während Ubuntu, gebunden an den Veröffentlichungszyklus, ein Hauptaugenmerk auf ein stabiles System mit guter Fehlerbehebung legt. Darum wird hier das Prinzip der “aufgeteilten Arbeit” angewendet, wo in vielen Zweigen gleichzeitig entwickelt wird, die am Ende alle zusammengeführt werden.

./_images/cycle-branching.png

In dem oben gezeigtem Beispiel würde es Sinn machen, Ubuntu mit der bestehenden Version des Projektes ausliefern, die Fehlerbehebung hinzufügen, diese für die nächste Veröffentlichung Upstream hinzuzufügen und es mit der (wenn geeignet) nächsten Ubuntu-Veröffentlichung auszuliefern. Dieses ist der bestmögliche Kompromiss und es würde jeder Gewinnen.

Um einen Fehler in Ubuntu zu reparieren, musst Du dir zuerst den Quelltext des Paketes besorgen. Dann den Fehler beheben und so dokumentieren, dass es einfach für andere Entwickler und Benutzer zu verstehen ist und schließlich das Paket bauen um es zu testen. Nachdem du das Paket getestet hast, kannst du deine Änderung einfach zur Aufnahme in den aktuellen Ubuntu Entwicklungszweig vorschlagen. Ein Entwickler mit dem Recht zum hochladen wird deine Änderung für dich bewerten und anschließend es für dich in Ubuntu integrieren.

./_images/cycle-process.png

Wenn Du eine Lösung suchst ist es eine gute Idee zu prüfen, ob Upstream das Problem bekannt ist. Wenn es noch keine Lösung gibt, macht es Sinn, daran gemeinsam zu arbeiten.

Zusätzliche Schritte könnten beinhalten, die Änderung auf einen älteren, immer noch unterstützten Release zurückzuportieren oder die Änderungen an Upstream weiterzuleiten.

Die wichtigsten Anforderungen für den Erfolg in der Ubuntu-Entwicklung sind: Der Drang »Dinge wieder zum Laufen zu bringen«, keine Angst davor zu haben Dokumentationen zu lesen und Fragen zu stellen, Teamgeist zu zeigen und ein wenig Detektivarbeit genießen zu können.

Gute Plätze um Fragen zu stellen, sind ubuntu-motu@lists.ubuntu.com und #ubuntu-motu auf irc.freenode.net. Du wirst sehr einfach neue Freunde finden und Leute, die dieselbe Leidenschaft haben wie Du: die Welt zu einem bessern Platz zu machen durch Open Source Software.

Die Programme einrichten

Es gibt einiges zu tun, bevor Du mit der Ubuntu-Entwicklung loslegen kannst. Dieser Artikel wird Dir helfen, dein System so einzurichten, dass Du mit Paketen arbeiten und Deine Pakete auf Ubuntu’s Hosting-Platform, Launchpad, hochladen kannst. Hierüber werden wir reden:

  • Paketierungs-Software installieren. Dies beinhaltet:
    • Ubuntu-spezifische Paketierungs-Werkzeuge
    • Verschlüsselungssoftware so dass Deine Arbeit als Deine eigene verifiziert werden kann
    • Weitere Verschlüsselungssoftware so dass Du sichere Dateitransfers machen kannst
  • Deinen Account auf Lauchpad erstellen und einrichten
  • Deine Entwicklungsumgebung aufsetzen, so dass Du lokale Builds von Paketen machen, mit anderen Entwicklern interagieren und Deine Änderungswünsche in Launchpad unterbreiten kannst.

Bemerkung

Es macht Sinn, Paketierungaufgaben direkt in der Entwicklungsversion von Ubuntu zu machen. Dies wird es Dir erlauben Deine Änderungen in derselben Umgebung zu testen, wo diese später eingepflegt und verwendet werden.

Mach dir deswegen aber keine Sorgen, du kannst Testdrive or chroots verwenden um sicher eine Entwicklerversion zu benutzen.

Grundlegende Paketierungs-Software installieren

Es gibt eine Anzahl von Werkzeugen die dir das Leben als Ubuntu-Entwickler um einiges einfacher machen. Du wirst diesen zu einem späteren Zeitpunkt in diesem Handbuch begegnen. Um die meisten davon zu installieren, kannst du folgenden Befehl ausführen:

$ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file

Merke: Seit Ubuntu 11.10 “Oneiric Ocelot” (oder falls du Zurückportierungen für eine derzeit unterstütze Version aktiviert hast) wird der folgenden Befehl das obige und weitere Werkzeuge installieren, welche für die Ubuntu-Entwicklung sehr gebräuchlich sind.

$ sudo apt-get install packaging-dev

Dieser Befehl wird folgende Software installieren

  • gnupgGNU Privacy Guard enthält Werkzeuge, die du für die Erstellung eines kryptographischen Schlüssels benötigst. Mit dem Schlüssel kannst du die Dateien unterschreiben welche du zu Launchpad hochladen willst.
  • pbuilder – ein Werkzeug um reproduzierbare Builds eines Pakets in einer sauberen und isolierten Umgebung zu machen.
  • ubuntu-dev-tools (und devscripts, eine direkte Abhängkigkeit) – eine Sammlung von Werkzeugen, die viele Paketierungsaufgaben einfacher machen.
  • bzr-builddeb (und bzr, eine direkt anhängiges Paket) – verteilte Versionskontrolle mit Bazaar, einem neuen Weg mit Paketen in Ubuntu zu arbeiten der es einfach macht mit vielen Entwicklern am selben Quellcode zusammenzuarbeiten während es einfach bleibt Änderungen einfließen zu lassen.
  • apt-file ist eine einfache Möglichkeit das Binärpaket zu finden welches eine gegebene Datei enthält.
Deinen GPG-Schlüssel erstellen

GPG bedeutet GNU Privacy Guard und implementiert den OpenPGP-Standard, mit dem Sie Nachrichten und Dateien unterschreiben und verschlüsseln können. Dies bringt eine Reihe von Vorteilen mit sich. In unserem Fall ist diese Funktion wichtig, damit Sie Dateien signieren können und so kenntlich machen, dass Sie daran gearbeitet haben. Wenn Sie ein Paket in Launchpad hochladen möchten funktioniert dies nur, wenn mit absoluter Sicherheit festgestellt werden kann, wer die Datei hochgeladen hat.

Um Deinen GPG-Schlüssel zu erstellen, starte:

$ gpg --gen-key

GPG fragt zuerst, welche Art von Schlüssel Sie generieren möchten. Die Standardauswahl (RSA und DSA) ist eine gute Wahl. Als nächstes werden Sie nach der Schlüsselgröße gefragt. Die Standardauswahl (zur Zeit 2048) ist zwar eine gute Wahl, aber 4096 bietet deutlich mehr Sicherheit. Danach müssen Sie angeben, ob der Schlüssel zu einem bestimmten Zeitpunkt ungültig werden soll. Auch hier ist die Stadardauswahl »0« ein guter Wert, der bedeutet, dass der Schlüssel unbegrenzt gültig ist. Zum Schluss werden noch Ihr Name sowie Ihre E-Mail Adresse abgefragt. Geben Sie hier die E-Mail Adresse an, mit der Sie bei der Entwicklung bei Ubuntu tätig sein möchten. Bei Bedarf können später weitere hinzugefügt werden. Die letzte Angabe ist eine Passphrase (eine Passphrase ist ein Passwort, in dem auch Leerzeichen enthalten sein dürfen). Sie sollte sehr sicher sein.

Jetzt wird GPG einen Schlüssel für dich generieren, was ein bisschen dauern kann. Es braucht zufällige Bytes, also ist eine gute Idee das System ein wenig auszulasten. Beweg den Mauszeiger hin und her, schreib ein paar Zeilen und lade ein paar Webseiten.

Wenn das getan ist, wirst Du in etwa solch eine Meldung erhalten:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

In diesem Fall ist 43CDE61D die key ID.

Als nächstes muss du den öffentlichen Teil deines Schlüssels auf einen Keyserver hochladen, sodass man Nachrichten und Dateien dir zuordnen kann. Um das zu tun, führe folgenden Befehl aus:

$ gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>

Dies wird deinen Schlüssel auf den Ubuntu-Schlüsselserver laden, aber ein Netzwerk aus Schlüsselservern wird den Schlüssel untereinander weiterreichen. Ist der Vorgang erst einmal abgeschlossen, ist dein unterschriebener öffentlicher Schlüssel bereit alle deine Beiträge auf der ganzen Welt zu verifizieren.

Deinen SSH-Schlüssel erstellen

SSH steht für Secure Shell und ist ein Protokoll, welches es Ihnen erlaubt, Daten sicher über ein Netzwerk auszutauschen. Es ist üblich per SSH Zugang zur Kommandozeile eines andern Rechners zu erhalten und es zur sicheren Dateiübertragung zu verwenden. Für unsere Zwecke nutzen wir SSH hauptsächlich zum sicheren Hochladen von Paketen zu Launchpad.

Um Deinen SSH-Schlüssel zu erstellen, starte:

$ ssh-keygen -t rsa

Der Standardname ergibt normalerweise Sinn, deshalb kann er auch einfach so bleiben. Aus Sicherheitsgründen ist es ratsam eine Passphrase zu verwenden.

pbuilder einrichten

pbuilder ermöglicht es Ihnen, Pakete lokal auf Ihrem Rechner zu erstellen. Das dient mehreren Zwecken:

  • Die Erstellung wird in einer minimalen und sauberen Umgebung vorgenommen. Das hilft sicherzustellen, dass der Vorgang in einer wiederholbaren Weise abläuft ohne Ihr System zu modifizieren.
  • Du brauchst nicht alle nötigen Build-Abhängigkeiten lokal installieren.
  • Du kannst mehrere Instanzen für diverse Ubuntu- und Debian-Versionen einrichten

pbuilder einzurichten ist sehr einfach, starte:

$ pbuilder-dist <release> create

where <release> is for example raring, saucy, trusty or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though.

Alles einrichten um mit Launchpad arbeiten zu können

Mit einer grundlegenden lokalen Konfiguration vor Ort ist dein nächster Schritt dein System auf die Arbeit mit Launchpad einzurichten. Dieses Kapitel legt den Schwerpunkt auf folgende Themen:

  • Was Launchpad ist und einen Launchpad Account erstellen
  • Deinen GPG- und SSH-Schlüssel auf Launchpad hochladen
  • Bazaar einrichten um mit Launchpad arbeiten zu können
  • Bash einrichten um mit Launchpad arbeiten zu können
Über Launchpad

Launchpad ist das Kernstück der Infrastruktur in Ubuntu. Es speichert nicht nur unsere Pakete und unseren Code, sondern auch Dinge wie Übersetzungen, Fehlerberichte, Informationen über Personen die an Ubuntu arbeiten sowie deren Mitgliedschaften in Entwicklerteams. Du wirst Launchpad ebenso dazu benutzen um deine Lösungen zu veröffentlichen und andere Ubuntu-Entwickler dazu zu bringen sie zu überprüfen und zu finanzieren.

Du wirst dich mit Launchpad anmelden und ein Minumum an Informationen preisgeben müssen. Das gibt dir die Möglichkeit Code runter- und hochzuladen, Fehlerberichte auszustellen und vieles mehr.

Neben Ubuntu kann Launchpad jedes beliebige Projekt mit freier Software beherbergen. Für weitere Informationen siehe im Launchpad Hilfe Wiki.

Einen Launchpad Account erstellen

Falls du noch keinen Launchpad-Account hast, kannst du einfach einen einrichten. Falls du schon einen Account besitzt, aber dich nicht mehr an deine Launchpad-ID erinnern kannst, findest du sie auf https://launchpad.net/~ nach dem Zeichen ~ in der URL.

Der Registrierungsprozess von Launchpad wird nach einem Anzeigenamen verlangen. Es ist empfehlenswert hier seinen echten Namen zu verwenden, damit die anderen Ubuntu-Entwickler eine Möglichkeit haben dich besser kennenzulernen.

Sobald du einen neuen Account registrierst, wird dir Launchpad eine E-Mail mit einem Weblink senden, der deine E-Mail-Adresse bestätigt. Falls du keine E-Mail erhältst, solltest du deinen Spam-Ordner überprüfen.

Die neue Hilfe-Seite auf Launchpad gibt mehr Information über den Ablauf und zusätzliche Einstellungen, die du ändern kannst.

Deinen GPG-Schlüssel auf Launchpad hochladen

First, you will need to get your fingerprint and key ID.

Um Deinen GPG-Fingerabdruck zu finden, starte:

$ gpg --fingerprint email@address.com

und es wird Dir etwa sowas ausgegeben:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

Then run this command to submit your key to Ubuntu keyserver:

$ gpg --keyserver keyserver.ubuntu.com --send-keys 43CDE61D

where 43CDE61D should be replaced by your key ID (which is in the first line of output of the previous command). Now you can import your key to Launchpad.

Gehe auf https://launchpad.net/~/+editpgpkeys und kopiere den “Key fingerprint” in das Textfeld. Im oben genannten Beispiel wäre das 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D. Klicke jetzt auf “Import Key”.

Launchpad benutzt den Fingerabdruck, um Ihren Schlüssel am Ubuntu-Schlüsselserver abzufragen. Bei Erfolg erhalten Sie eine verschlüsselte E-Mail mit der Bitte, den Schlüsselimport zu bestätigen. Durchsuchen Sie dazu Ihr E-Mail Postfach nach dieser E-Mail. Unterstützt Ihr E-Mail Anbieter OpenPGP-Verschlüsselung, werden Sie nach dem Passwort gefragt, dass Sie bei der Erstellung des Schlüssels verwendet haben. Geben Sie dieses ein und klicken Sie auf den Link, um zu bestätigen, dass dies Ihr Schlüssel ist.

Launchpad verschlüsselt diese E-Mail unter Verwendung Ihres öffentlichen Schlüssels, um Sie als den Besitzer des Schlüssels zu bestätigen. Wenn Sie das unter Ubuntu standardmäßig installierte Thunderbird als Ihr E-Mail Programm benutzen, können Sie die Nachricht einfach entschlüsseln, indem Sie die Enigmail-Erweiterung installieren. Unterstützt Ihre eingesetzte E-Mail-Software keine OpenPGP-Verschlüsselung, können Sie den Inhalt auch manuell entschlüsseln. Geben Sie dazu in der Eingabeaufforderung den Befehl gpg ein und kopieren Sie den verschlüsselten Inhalt der E-Mail in das Fenster.

Zurück auf der Launchpad-Webseite, drück die Schaltfläche zur Bestätigung und Launchpad wird den Import deines OpenPGP-Schlüssels abschließen.

Weitere Informationen findest Du auf https://help.launchpad.net/YourAccount/ImportingYourPGPKey

Deinen SSH-Schlüssel auf Launchpad hochladen

Öffne https://launchpad.net/~/+editsshkeys in einem Webbrowser, und öffne auch ~/.ssh/id_rsa.pub in einem Texteditor. Dies ist der öffentliche Teil Deines SSH-Schlüssels, also ist es sicher ihn auf Launchpad zu veröffentlichen. Kopiere den Inhalt der Datei und füge sie in die Textbox ein die mit “Add an SSH key” überschrieben ist. Klicke jetzt “Import Public Key”.

Für weitere Informationen über diesen Prozess, besuchen Sie die Seite Erstellung eines SSH-Schlüsselpaares auf Launchpad.

Bazaar einrichten

Bazaar ist das Werkzeug, das wir verwenden, um Quellcode-Änderungen in logischer Art und Weise zu speichern, um vorgeschlagene Änderungen auszutauschen und einzupflegen, und auch um gleichzeitig entwickeln zu können. Es wird für die Ubuntu Distributed Development Methode verwendet um an Ubuntu-Paketen zu arbeiten.

Um Bazaar zu sagen, wer Du bist, starte einfach:

$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius

whoami teilt Bazaar mit welchen Namen und welche Email-Adresse benutzt werden soll für Commit-Nachrichten. Mit launchpad-login setzt man seine Launchpad ID. Dadurch wird Quellcode, den Du in Launchpad veröffentlichst, mit Dir verbunden.

Merke: Falls du dich nicht mehr an deine ID erinnern kannst, geh auf https://launchpad.net/~ und achte darauf, wohin es dich umleitet. Der Teil nach dem “~” in der URL ist deine Launchpad ID.)

Deine Shell einrichten

Genau wie mit Bazaar, müssen die Debian/Ubuntu Paketierungs-Werkzeuge auch mehr über Dich erfahren. Öffne einfach ~/.bashrc in einem Texteditor und füge etwas wie das hier a Ende hinzu:

export DEBFULLNAME="Bob Dobbs"
export DEBEMAIL="subgenius@example.com"

Speichere die Datei jetzt und starte entweder Dein Terminal neu oder starte:

$ source ~/.bashrc

(Falls du nicht die Standardanwendung bash benutzt, passe bitte die Konfigurationsdatei für diese Anwendung dementsprechend an.)

Verteilte Ubuntu Entwicklung — Einleitung

Diese Anleitung bezieht sich auf die Paketierung mit der Verteilte Ubuntu Entwicklung (UDD) Methode.

Ubuntu Distributed Development (UDD) is a new technique for developing Ubuntu packages that uses tools, processes, and workflows similar to generic distributed version control system (DVCS) based software development. The DVCS used for UDD is Bazaar.

Traditionelle Paketbeschränkungen

Traditionally Ubuntu packages have been kept in tar archive files. A traditional source package is made up of the upstream source tar, a “debian” tar (or compressed diff file for older packages) containing the packaging and a .dsc meta-data file. To see a traditional package run:

$ apt-get source kdetoys

This will download the upstream source kdetoys_4.6.5.orig.tar.bz2, the packaging kdetoys_4.6.5-0ubuntu1.debian.tar.gz and the meta-data kdetoys_4.6.5-0ubuntu1~ppa1.dsc. Assuming you have dpkg-dev installed it will extract these and give you the source package.

Traditional packaging would edit these files and upload. However this gives limited opportunity to collaborate with other developers, changes have to be passed around as diff files with no central way to track them and two developers can not make changes at the same time. So most teams have moved to putting their packaging in a revision control system. This makes it easier for several developers to work on a package together. However there is no direct connection between the revision control system and the archive packages so the two must be manually kept in sync. Since each team works in its own revision control system a prospective developer must first work out where that is and how to get the packaging before they can work on the package.

Verteilte Ubuntu Entwicklung

With Ubuntu Distributed Development all packages in the Ubuntu (and Debian) archive are automatically imported into Bazaar branches on our code hosting site Launchpad. Changes can be made directly to these branches in incremental steps and by anyone with commit access. Changes can also be made in forked branches and merged back in with Merge Proposals when they are large enough to need review or if they are by someone without direct commit access.

UDD branches are all in a standard location, so doing a checkout is easy:

$ bzr branch ubuntu:kdetoys

The merge history includes two separate branches, one for the upstream source and one which adds the debian/ packaging directory:

$ cd kdetoys
$ bzr qlog

(This command uses qbzr for a GUI, run log instead of qlog for console output.)

./_images/kdetoys-udd-branch.png

This UDD branch of kdetoys shows the full packaging for each version uploaded to Ubuntu with grey circles and the upstream source versions with green circles. Versions are tagged with either the version in Ubuntu such as 4:4.2.29-0ubuntu1 or for the upstream branch with the upstream version upstream-4.2.96.

Many Ubuntu packages are based on the packages in Debian, UDD also imports the Debian package into our branches. In the kdetoys branch above the Debian versions from unstable are from the merge with blue circles while those from Debian experimental are from the merge with yellow circles. Debian releases are tagged with their version number, e.g., 4:4.2.2-1.

So from a UDD branch you can see the complete history of changes to the package and compare any two versions. For example, to see the changes between version 4.2.2 in Debian and the 4.2.2 in Ubuntu use:

$ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1

(Dieser befehl nutzt qbzr um eine grafische Benuterschnittstelle zu erhalten, starte diff alstelle von qdiff um eine Konsolenausgabe zu erhalten.)

./_images/kdetoys-udd-diff.png

From this we can clearly see what has changed in Ubuntu compared to Debian, very handy.

Bazaar

UDD branches use Bazaar, a distributed revision control system intended to be easy to use for those familiar with popular systems such as Subversion while offering the power of Git.

To do packaging with UDD you will need to know the basics of how to use Bazaar to manage files. For an introduction to Bazaar see the Bazaar Five Minute Tutorial and the Bazaar Users Guide.

Beschränkungen der Verteilten Ubuntu Entwicklung

Verteilte Ubuntu Entwicklung is eine neue Methode um mit Ubuntu-Paketen zu arbeiten. Sie hat derzeit die folgenden Beschränkungen:

  • Doing a full branch with history can take a lot of time and network resources. You may find it quicker to do a lightweight checkout bzr checkout --lightweight ubuntu:kdetoys but this will need a network access for any further bzr operations.
  • Working with patches is fiddly. Patches can be seen as a branched revision control system, so we end up with RCS on top of RCS.
  • There is no way to build directly from branches. You need to create a source package and upload that.
  • Some packages have not been successfully imported into UDD branches. Recent versions of Bazaar will automatically notify you when this is the case. You can also check the status of the package importer manually before working on a branch.

All of the above are being worked on and UDD is expected to become the main way to work on Ubuntu packages soon. However currently most teams within Ubuntu do not yet work with UDD branches for their development. However because UDD branches are the same as the packages in the archive any team should be able to accept merges against them.

Einen Bug in Ubuntu beheben

Einleitung

Wenn Du die Anweisungen in Sich für Ubuntu-Entwicklung einrichten befolgt hast, solltest Du 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.

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.

In Harvest <http://harvest.ubuntu.com/>`_ haben wir eine Übersicht über vielfältige “TODO-Listen” die mit Ubuntu-Entwicklung zusammenhängen. Harvest listet Fehler, die in Debian oder Upstream-Projekten behoben wurden, es listet kleine Bugs (wir nennen sie ‘bitesize’) und so weiter. Schau es Dir an und finde Deinen ersten Fehler an dem Du arbeitest.

Herausfinden, was repariert werden muss

Wenn Du das Quellpaket, das den Fehler beinhaltet nicht kennst, aber Dir der Pfad zu dem betroffenen Programm auf Deinem System bekannt ist, dann kannst Du das Quellpaket selbst ermitteln, an dem Du arbeiten musst.

Sagen wird, du hast einen Fehler in Tomboy gefunden, einer Merkzettel-Anwendung für den Desktop. Tomboy kann mit dem Befehl /usr/bin/tomboy aus der Kommandozeile gestartet werden. Um das Binärpaket zu finden, welches die Anwendung enthält, verwende folgenden Befehl:

$ apt-file find /usr/bin/tomboy

Dies gibt aus:

tomboy: /usr/bin/tomboy

Beachte dass der Teil vor dem Doppelpunkt der Binärpaketname ist. Es ist häufig der Fall, dass das Quellpaket und Binärpaket unterschiedliche Bezeichnungen besietzen. Das tritt am häufigsten auf, wenn ein einzelnes Quellpaket dazu verwendet wird mehrere verschiedene Binärpakete zu erstellen. Um das Quellpaket eines bestimmten Binärpaketes zu finden, tippe:

$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy
$ apt-cache showsrc python-vigra | grep ^Package:
Package: libvigraimpex

apt-cache ist Teil der Standardinstallation von Ubuntu.

Den Quellcode herunterladen

Wenn Du einmal das Quellpaket kennst mit dem Du arbeitest, wirst Du eine Kopie des Codes auf deinem System brauchen, um es von Fehlern zu befreien. In der Ubuntu Entwicklungsverteilung wird dazu das Quellpaket abgezweigt. Launchpad verwaltet alle Zweige der Quellpakete in Ubuntu.

Wenn du erst einmal eine lokale Kopie des Quellpakets hast, kannst du den Fehler untersuchen, ihn beheben und die Lösung wieder zu Launchpad in Form eines Bazaar-Zweiges hochladen. Wenn du mit deiner Lösung zufrieden bist, kannst du einen Vereinigungsvorschlag einreichen, der andere Ubuntu-Entwicker auffordert deine Änderung zu überprüfen und anzunehmen. Wenn sie mit deinen Änderungen einverstanden sind, wird ein Ubuntu-Entwickler die neue Version des Pakets zu Ubuntu hochladen, sodass jeder von deiner exzellenten Lösung profitieren kann - und du ein bisschen Ansehen einheimst. Du bist jetzt schon auf dem Weg ein Ubuntu-Entwicker zu werden!

Wir werden in den folgenden Abschnitten genauer beschreiben, wie der Code abgezweigt werden kann, deine Fehlerbehebung vorangebracht wird und eine Anfrage für eine Durchsicht gestellt wird.

Arbeiten an einer Fehlerbehebung

Es wurden ganze Bücher darüber verfasst wie man Fehler findet, sie behebt, testet, usw. Wenn du ein Anfänger im Programmieren bist, versuche zuerst einfache Fehler wie beispielsweise in der Rechtschreibung zu beheben. Versuche die Änderungen so minimal wie möglich zu halten und dokumentiere deine Änderungen und Annahmen übersichtlich.

Bevor du dich daran machst, einen Fehler selbst du behen, solltest du 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

Du willst nun einen Patch entwickeln, der die Fehlerbehebung enthält. Der Befehl edit-patch ist eine einfache Möglichkeit um einen Patch zu einem Paket hinzuzufügen. Führe aus:

$ edit-patch 99-new-patch

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

$ patch -p1 < ../bugfix.patch

Nachdem du die Datei bearbeitet hast, schreibe exit oder drücke Strg+D um die zeitweilige Umgebung zu verlassen. Der neue Patch wird dann unter debian/patches eingefügt.

Die Lösung testen

Um ein Testpaket mit Deinen Änderungen zu bauen, durchlaufe diese Kommandos:

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

Dies wird ein Quellpaket aus dem Inhalt des Zweiges (-us -uc bewirkt, dass die Signierung des Pakets übersprungen wird) und pbuilder-dist wird die Pakete aus dem Quellcode bauen, für den release, den Du ausgewählt hast..

Ist die Erstellung einmal gelungen, installieren Sie das Paket von ~/pbuilder/<Veröffentlichung>_result/ (mithilfe von sudo dpkg -i <Paket>_<Version>.deb). Dann führen Sie einen Test durch, ob der Fehler behoben wurde.

Die Lösung dokumentieren

Es ist sehr wichtig Deine Änderung ausreichend zu dokumentieren, so dass Entwickler, die sich den Code zukünftig ansehen, nicht raten müssen, was Deine 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 Dich erstellen, wo Du die Lücken ausfüllen kannst. 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 dich 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 Änderungsprotokolles selbst konzentrieren: Es ist sehr wichtig festzuhalten:

  1. wo die Änderungen durchgeführt wurden
  2. was geändert wurde
  3. wo die Diskussion zu dieser Änderung zu finden ist

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.

Den Fix hochladen

Wenn der Eintrag im changelog geschrieben und gespeichert ist, kannst Du einfach folgendes starten:

debcommit

und die Änderung wird mit deinem Changelog-Eintrag als Commit-Nachricht lokal committet.

Um das ganze als Zweignamen zu Launchpad hoch zu laden (push), musst Du Dich an die folgende Struktur halten.

lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>

Dies könnte zum Beispiel sein:

lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456

Also wenn Du einfach folgendes startest:

bzr push lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
bzr lp-propose

sollte alles erledigt sein. Der Befehl push befördert es auf Launchpad und das nächste Kommando öffnet die Launchpad-Webseite mit dem Remotezweig in deinem Browser. Nach dem Klick auf den Link “(+) Propose for merging” wird die Änderung überprüft und in Ubuntu eingefügt.

Unser Artikel ueber seeking sponsorship geht mehr ins Detail darüber, wie man Feedback zu den eingestellten Änderungen erhält.

Wenn deine Arbeit an einem Entwicklungszweig Fehler in einer stabilen Version oder eine Sicherheitslücke behebt, ist es wert einen Blick auf den Artikel doc:Sicherheits- und Stabilitäts-Updates<./security-and-stable-release-updates> zu werfen.

Tutorial: Einen Bug in Ubuntu beheben

Obwohl die Mechanismen, um einen Fehler zu beheben für jeden Fehler gleich sind, ist das auftretende Problem sehr wahrscheinlich jedes Mal unterschiedlich. Ein Beispiel für ein konkretes Problem hilft Anhaltspunkte dafür zu finden, auf was alles geachtet werden muss.

Bemerkung

Als dieser Artikel geschrieben wurde, war dies noch nicht behoben. Wenn Du diesen Artikel liest, ist es eventuell schon behoben. Nimm dies als Beispiel und versuche es für die spezifischen Probleme, die du behebst anzuwenden.

Das Problem bestaetigen

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>
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 waere 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 Du lösen wolltest, schon bearbeitet hat. Um doppelte und nutzlose Arbeit zu verhindern macht es Sinn zuerst ein wenig Detektivarbeit zu leisten.

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 du im Web danach suchst, sollte es in den meisten Fällen einfach zu finden sein.

Hilfe anbieten

Wenn du einen offenen Fehler gefunden hast, dieser noch nicht zugewiesen ist und du die Möglichkeit hast ihn zu beheben, solltest du einen Kommetar mit deinem Lösungsvorschlag abgeben. Gib so viele Informationen wie möglich an: Unter welchen Umständen tritt der Fehler auf? Wie hast du den Fehler behoben? Hast du die Lösung getestet?

Wenn noch kein Fehlerbericht eingesandt wurde, kannst Du das tun. Was Du im Kopf behalten solltest ist: ist das Problem klein genug, dass man vielleicht einfach jemand direkt darum bittet einen Patch hoch zu laden? Hast Du es vielleicht geschafft einen Teil des Problems zu beheben und willst dies mitteilen?

Es ist toll wenn Du Hilfe anbieten kannst und man wird dafür sehr dankbar sein.

Das Problem beheben

Für dieses spezifische Beispiel reicht es aus, das Netz nach bumprace zu durchsuchen, um die Homepage zu finden. Stell sicher, dass die Seite auch aktiv ist und nicht nur ein Software-Katalog. http://www.linux-games.com/bumprace/ sieht nach der richtigen Seite aus.

Um dieses Problem im Quellpaket zu beheben, müssen wir uns erst den Quelltext besorgen. Das ist einfach:

bzr branch ubuntu:bumprace

Wenn Du the Debian Directory Overview vorher gelesen hast, wirst Du Dich vielleicht daran erinnwen, dass die Homepage für ein Paket im ersten Teil von debian/control, spezifiziert wird. Dieser Abschnitt startet mit Source:.

Als nächstes führt man folgendes aus:

cd bumprace

und bearbeite debian/control um Homepage: http://www.linux-games.com/bumprace/ hinzuzufügen. Das Ende des ersten Abschnitts sollte ein guter Platz dafür sein. Wenn Du das erledigt hast, speichere die Datei ab.

Wenn Du jetzt folgendes ausführst:

bzr diff

dann solltest Du in etwa so etwas sehen:

=== modified file 'debian/control'
--- debian/control      2012-05-14 23:38:14 +0000
+++ debian/control      2012-09-03 15:45:30 +0000
@@ -12,6 +12,7 @@
                libtool,
                zlib1g-dev
 Standards-Version: 3.9.3
+Homepage: http://www.linux-games.com/bumprace/

 Package: bumprace
 Architecture: any

Der Diff ist relativ leicht zu verstehen. Die + zeigen eine Zeile an, die hinzugefügt wurde. In unserem Fall wurde sie vor dem zweiten Abschnitt hinzugefügt, der mit Package beginnt, wobei es sich um ein Binärpaket handelt.

Die Lösung dokumentieren

Es ist wichtig den anderen Entwicklern zu erklären, was genau Du getan hast. Wenn Du folgendes ausführst:

dch -i

dies wird einen Editor starten, der eine Standard-Meldung enthält, die man nur noch ausfüllen muss. In unserem Fall wird ein Eintrag wie debian/control: Added project's homepage. ausreichen. Dann speichere die Datei ab. Um sicherzustellen, dass alles geklappt hat, führe folgendes aus:

bzr diff debian/changelog

und Du wirst in etwa so etwas sehen:

=== modified file 'debian/changelog'
--- debian/changelog    2012-05-14 23:38:14 +0000
+++ debian/changelog    2012-09-03 15:53:52 +0000
@@ -1,3 +1,9 @@
+bumprace (1.5.4-1ubuntu1) UNRELEASED; urgency=low
+
+  * debian/control: Added project's homepage.
+
+ -- Peggy Sue <peggy.sue@example.com>  Mon, 03 Sep 2012 17:53:12 +0200
+
 bumprace (1.5.4-1) unstable; urgency=low

   * new upstream version, sound and music have been removed (closes: #613344)

Ein paar weitere Überlegungen:

  • Falls man eine Referenz auf einen Bugreport in Launchpad hat, der mit der Änderung behoben wird, hängt man an die Changelog-Meldung (LP: #<bug number>) an, also z.B.: (LP: #123456).
  • Solltest Du Deine Änderung in Debian haben wollen, ist die Syntax um einen Debian-Bugreport zu schließen: (Closes: #<bug number>), z.B.: (Closes: #123456).
  • Wenn es eine Referenz zu einem Upstream- oder Debian-Bug ist, oder zu einer Mailinglisten-Unterhaltung, erwähne dies bitte auch.
  • Versuche Deine Zeilen nach 80 Zeichen umzubrechen.
  • Versuche präzise zu sein. Es muss kein Aufsatz sein, aber genau genug, damit jemand, der sich das Problem nicht in’s kleinste Detail anschaut, auch versteht, was geändert wurde.
  • Erwähne, wie Du den Fehler behoben hast und wo.

Die Lösung testen

Um die Lösung zu testen, musst Du deine Entwicklungsumgebung aufgesetzt haben, dann das Paket bauen, es installieren und dann prüfen dass das Problem tatsächlich behoben ist. In unserem Fall wäre das:

bzr bd -- -S
pbuilder-dist <current Ubuntu release> build ../bumprace_*.dsc
dpkg -I ~/pbuilder/*_result/bumprace_*.deb

In Schritt 1 bauen wir das Quellpaket aus dem Quellzweig heraus, dann bauen wir es mit pbuilder, dann prüfen wir das resultierende Paket um zu sehen, ob die Homepage hinzugefügt wurde.

Bemerkung

In vielen Fällen wirst Du 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, wirst Du die Binärpakete in ~/pbuilder/<release>_result finden. Installiere sie einfach per sudo dpkg -i <package>.deb oder indem Du auf sie im Dateimanager doppelt-klickst.

Wie wird festgestellt haben, ist das Problem nun behoben, also ist der nächste Schritt, die Lösung mit dem Rest der Welt zu teilen.

Die Lösung in das Projekt einbringen

Es ist sinnvoll einen Fix so nah an die Quelle des Codes (Upstream) wie möglich zu bringen. Hierdurch können wir sicherstellen, dass jeder die Änderung wie sie ist übernehmen kann und keine zusätzlichen lokalen Änderungen benötigen.

In unserem Fall haben wir herausgefunden, dass es sich um ein Problem in der Paketierung handelte, in Ubuntu, wie in Debian. Weil Ubuntu auf Debian basiert, werden wir die Fehlerlösung nach Debian schicken. Sobald sie dort eingepflegt wurde, wird sie ihren Weg nach Ubuntu finden. Der Fehler den wir hier behandelt haben ist ganz klar unkritisch, also macht diese Vorgehensweise Sinn. Wenn es wichtig ist das Problem so schnell wie möglich zu beheben, wirst Du Deine Fehlerlösung an mehrere Bugtracker schicken wollen - wenn das Problem mehrere Stellen betreffen sollte.

Um den Patch zu Debian zu senden, starte einfach:

submittodebian

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

Kommunikation ist wichtig, also solltest Du mehr Beschreibung mitliefern, wenn Du darum bittest die Änderung einzupflegen. Sei freundlich, erkläre es ausreichend.

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

Bemerkung

Sollte das Problem nur in Ubuntu bestehen, solltest Du Dir vielleicht Seeking Review and Sponsorship anschauen, um die Änderung direkt eingepflegt zu bekommen.

Weitere Überlegungen

Wenn Du ein Paket findest und es sich herausstellt, dass Du mehrere triviale Dings darin beheben kannst, mach es ruhig in einer Änderung. Das wird die Code-Review und das Einpflegen beschleunigen.

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

Neue Software paketieren

Auch wenn bereits tausende Pakete in den Ubuntu-Archiven vorhanden sind, gibt es noch immer sehr viele Programme, die nicht dort zu finden sind. Wenn es ein neues interessantes Programm gibt, das eine größere Verbreitung haben sollte, möchten Sie vielleicht versuchen ein Paket für Ubuntu zu erzeugen oder ein PPA einzurichten. Dieser Leitfaden hilft Ihnen Schritt für Schritt dabei die neuen Softwarepakete zu erstellen.

Sie sollten als erstes den :doc:`Vorbereitung<./getting-set-up>`s-Artikle lesen, um Ihre Entwicklungsumgebung vorzubereiten.

Das Programm überprüfen

Der erste Schritt in der Paketerstellung ist das Besorgen des veröffentlichen Quelltextes von Upstream (die Autoren von Software werden als “Upstream” bezeichnet) und das Überprüfen auf Kompilier- und Ausführbarkeit.

Dieser Leitfaden führt Sie anhand einer einfachen Anwendung namens GNU Hello, die von GNU.org veröffentlicht wurde, duch den Prozess des Paketbaus.

Falls du die nötigen Werkzeuge zur Erstellung noch nicht hast, lass uns sicherstellen, dass sie bereitgestellt werden. Ebenso wird mit fehlenden Abhängigkeiten verfahren.

Build-Werkzeuge installieren

$ sudo apt-get install build-essential

Das Hauptpaket herunterladen

$ wget -O hello-2.7.tar.gz "http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"

Jetzt entpacke das Hauptpaket

$ tar xf hello-2.7.tar.gz
$ cd hello-2.7

Diese Anwendung nutzt das autoconf-Build-System, also wollen wir ./configure ausführen, um uns für das Kompilieren vorzubereiten.

Dies wird die benötigten Erstellungsabhängigkeiten überprüfen. Um hello als einfaches Beispiel zu nehmen, build-essential sollte alles bereitstellen was wir brauchen. An komplexeren Programmen wird dieser Befehl scheitern, wenn du nicht die benötigten Bibliotheken und Entwicklungsdateien besitzt. Installiere die benötigten Pakete und Entwicklungsdateien bis der Befehl erfolgreich ausgeführt wird.:

$ ./configure

Jetzt kannst Du den Quelltext kompilieren:

$ make

Wenn das Kompilieren erfolgreich war, können Sie folgende Anwendung installieren und starten:

$ sudo make install
$ hello

Ein Paket starten

bzr-builddeb includes a plugin to create a new package from a template. The plugin is a wrapper around the dh_make command. You should already have these if you installed packaging-dev. Run the command providing the package name, version number, and path to the upstream tarball:

$ sudo apt-get install dh-make
$ cd ..
$ bzr dh-make hello 2.7 hello-2.7.tar.gz

Wenn Sie nach dem Pakettyp gefragt werden, wählen Sie mit der Eingabe von s den Typ einzelne Binärdatei. Der Quelltext wird in einen Zweig importiert und das debian/ Paketverzeichnis wird hinzugefügt. Sehen Sie sich einmal den Inhalt an. Die meisten Dateien werden nur für spezielle Pakete (beispielsweise Emacs Module) benötigt, sodass Sie mit dem Entfernen der nicht benötigten Dateien anfangen können:

$ cd hello/debian
$ rm *ex *EX

Du solltest nun jede der Dateien anpassen.

In debian/changelog change the version number to an Ubuntu version: 2.7-0ubuntu1 (upstream version 2.7, Debian version 0, Ubuntu version 1). Also change unstable to the current development Ubuntu release such as trusty.

Much of the package building work is done by a series of scripts called debhelper. The exact behaviour of debhelper changes with new major versions, the compat file instructs debhelper which version to act as. You will generally want to set this to the most recent version which is 9.

Unter control sind alle Metadaten eines Paketes enthalten. Der erste Abschnitt beschreibt das Quellpaket. Der zweite Abschnitt beschreibt die Binärpakete, die erstellt werden. Unter Build-Depends: müssen alle Pakete eingetragen werden, von denen die Kompilierung abhängt. Für hello werden mindestens die folgenden benötigt:

Build-Depends: debhelper (>= 9)

Sie müssen außerdem eine Beschreibung der Anwendung das Feld Description: eintragen.

copyright muss ausgefüllt werden um der Lizenz des Upstreams gerecht zu werden. Der Datei hello/COPYING nach ist das die GNU GPL 3 oder neuer.

docs enthält alle Dokumentationsdateien des Upstreams, die deiner Meinung nach in dem entgültigen Paket enthalten sein sollten.

README.source und README.Debian werden nur benötigt, wenn dein Paket nicht nur Standardfunktionen hat. Das trifft hier nicht zu, also können sie gelöscht werden.

source/format kann beibehalten werden, es beschreibt das Versionsformat des Quellpakets und sollte 3.0 (quilt) sein.

Die Umfangreichste Datei ist rules. Hierbei handelt es sich um eine Make-Datei, die den Quelltext kompiliert und in ein Binärpaket verwandelt. Erfreulicherweise wird dabei heutzutage die meiste Arbeit von debhelper 7 erledigt, sodass das universale % Make-Dateiziel nur das dh Script ausführt, das alles Benötigte durchführt.

Alle Dateien sind in größerer Ausführlichkeit in der Übersicht im Artikel über das Debian Verzeichnis beschrieben.

Schlussendlich kommitte den Code zu deinem Paketier-Zweig:

$ bzr commit -m "Initial commit of Debian packaging."

Das Paket bauen

Jetzt wird überprüft, ob das Programm kompiliert und das -deb Binärpaket erfolgreich gebaut werden kann:

$ bzr builddeb -- -us -uc
$ cd ../../

Mit dem Befehl bzr builddeb wird das Paket im aktuellen Verzeichnis gebaut. Die Option -us -uc ist die Anweisung, dass das Paket nicht GPG signiert werden muss. Das Ergebnis wird in .. ausgegeben.

Du kannst Dir den Inhalt eines Paketes mit folgendem Befehl ansehen:

$ lesspipe hello_2.7-0ubuntu1_amd64.deb

Install the package and check it works (later you will be able to uninstall it using sudo apt-get remove hello if you want):

$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb

You can also install all packages at once using:

$ sudo debi

Nächste Schritte

Auch wenn das .deb Binärpaket erfolgreich gebaut wird, ist im Bauprozess möglicherweise ein Fehler passiert. Viele Fehler können automatisch mit dem Werkzeug lintian gefunden werden, das auf die .dsc Metadaten Datei als auch auf das .deb Binärpaket angewendet werden kann:

$ lintian hello_2.7-0ubuntu1.dsc
$ lintian hello_2.7-0ubuntu1_amd64.deb

Ein Beschreibung von jedem ausgegebenen Problem kann auf der lintian website gefunden werden.

Nachdem der Fehler im Bauprozess behoben wurde, können Sie mit der Option -nc “no clean” das Paket erneut bauen, ohne mit der Kompilierung des Quelltextes starten zu müssen:

$ bzr builddeb -- -nc -us -uc

Nachdem sichergestellt ist, dass das Paket auf dem eigenen Rechner erfolgreich gebaut werden kann, sollten Sie überprüfen, ob dies auch auf einem frisch installierten System funktioniert. Zu diesem Zweck kann pbuilder eingesetzt werden. Da das gebaute Paket in ein PPA (Personal Package Archive) hochgeladen werden soll, ist es erforderlich, das Paket zu signieren. So kann Launchpad überprüfen, dass dieses Paket wirklich von Ihnen stammt (die hochzuladende Datei muss signiert werden, da die -us und -uc Markierungen nicht wie zuvor an bzr builddeb übergeben wurden). Für das Signieren benötigen Sie eine funktionierende Version von GPG. Sollten Sie pbuilder-dist oder GPG noch nicht installiert haben, so machen Sie dies jetzt:

$ bzr builddeb -S
$ cd ../build-area
$ pbuilder-dist trusty build hello_2.7-0ubuntu1.dsc

Wenn Sie mit Ihrem Paket zufrieden sind, wird es vermutlich Ihre Absicht sein, dass andere Benutzer Ihr Paket überprüfen. Dazu können Sie den Zweig in Launchpad hochladen:

$ bzr push lp:~<lp-username>/+junk/hello-package

Das Hochladen in ein PPA hat mehrere Vorteile: Sie können einfach den Paketbauvorgang auf Fehlerfreiheit überprüfen und andere können die Binärpakete testen. Hierfür benötigen Sie ein PPA in Launchpad, in das Sie ihre Dateien mittels dput hochladen:

$ dput ppa:<lp-username>/<ppa-name> hello_2.7-0ubuntu1.changes

Sehen Sie auch Hochladen für mehr Informationen.

Rückmeldungen können Sie über den #ubuntu-motu IRC Kanal erfragen sowie über die MOTU Mailing Liste.`MOTU mailing list`_. Möglicherweise können Sie bei besonderen Fragen auch ein spezielles Team um Rat bitten, beispielsweise das GNU Team.

Zur Einbindung einsenden

Es gibt eine Vielzahl von Wegen, auf denen ein Paket in Ubuntu einziehen kann. In den meisten Fällen ist der Weg über Debian der beste Weg. Auf diesem Weg wird versichert, dass das Paket die größte Anzahl an Nutzern hat da es nicht nur in Debian und Ubuntu vorhanden sein wird, sondern auch in ihren Derivaten. Hier sind einige nützliche Links für das Hinzufügen neuer Pakete im Debianprojekt:

  • Debian Mentors FAQ - Das debian-mentors Team kümmert sich um neue und zukünftige Debian-Entwickler. Hier kannst du Sponsoren finden, die deine Pakete in das Archiv hoch laden,
  • Work-Needing and Prospective Packages - Information darüber, wie man “Intent to Package” und “Request for Package” Bug-Reports schreibt und aktuelle Listen von offenen ITPs und RFPs.
  • Debian Developer’s Reference, 5.1. New packages - Das gesamte Dokument ist wichtig für Ubuntu- und Debian-Entwickler. Dieser Abschnitt beschäftigt sich mit den Prozessen für das Hochladen von neuen Paketen.

In some cases, it might make sense to go directly into Ubuntu first. For instance, Debian might be in a freeze making it unlikely that your package will make it into Ubuntu in time for the next release. This process is documented on the “New Packages” section of the Ubuntu wiki.

Bildschirmfotos

Hast du einmal ein Paket zu Debian hochgeladen, solltest du Bildschirmfotos bereitstellen um zukünftigen Benutzern einen Einblick in das Programm zu geben. Diese sollen auf http://screenshots.debian.net/upload hochgeladen werden.

Security und Stable Release Updates

Einen sicherheitstechnischen Fehler in Ubuntu beheben

Einleitung

Fixing security bugs in Ubuntu is not really any different than fixing a regular bug in Ubuntu, and it is assumed that you are familiar with patching normal bugs. To demonstrate where things are different, we will be updating the dbus package in Ubuntu 12.04 LTS (Precise Pangolin) for a security update.

Den Quelltext bekommen

In this example, we already know we want to fix the dbus package in Ubuntu 12.04 LTS (Precise Pangolin). So first you need to determine the version of the package you want to download. We can use the rmadison to help with this:

$ rmadison dbus | grep precise
dbus | 1.4.18-1ubuntu1   | precise          | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-security | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-updates  | source, amd64, armel, armhf, i386, powerpc

Typically you will want to choose the highest version for the release you want to patch that is not in -proposed or -backports. Since we are updating Precise’s dbus, you’ll download 1.4.18-1ubuntu1.4 from precise-updates:

$ bzr branch ubuntu:precise-updates/dbus
Den Quelltext patchen

Now that we have the source package, we need to patch it to fix the vulnerability. You may use whatever patch method that is appropriate for the package, including UDD techniques, but this example will use edit-patch (from the ubuntu-dev-tools package). edit-patch is the easiest way to patch packages and it is basically a wrapper around every other patch system you can imagine.

Um einen Patch mit edit-patch anzulegen:

$ cd dbus
$ edit-patch 99-fix-a-vulnerability

This will apply the existing patches and put the packaging in a temporary directory. Now edit the files needed to fix the vulnerability. Often upstream will have provided a patch so you can apply that patch:

$ patch -p1 < /home/user/dbus-vulnerability.diff

After making the necessary changes, you just hit Ctrl-D or type exit to leave the temporary shell.

Das Changelog und die Patches formatieren

After applying your patches you will want to update the changelog. The dch command is used to edit the debian/changelog file and edit-patch will launch dch automatically after un-applying all the patches. If you are not using edit-patch, you can launch dch -i manually. Unlike with regular patches, you should use the following format (note the distribution name uses precise-security since this is a security update for Precise) for security updates:

dbus (1.4.18-2ubuntu1.5) precise-security; urgency=low

  * SECURITY UPDATE: [DESCRIBE VULNERABILITY HERE]
    - debian/patches/99-fix-a-vulnerability.patch: [DESCRIBE CHANGES HERE]
    - [CVE IDENTIFIER]
    - [LINK TO UPSTREAM BUG OR SECURITY NOTICE]
    - LP: #[BUG NUMBER]
...

Update your patch to use the appropriate patch tags. Your patch should have at a minimum the Origin, Description and Bug-Ubuntu tags. For example, edit debian/patches/99-fix-a-vulnerability.patch to have something like:

## Description: [DESCRIBE VULNERABILITY HERE]
## Origin/Author: [COMMIT ID, URL OR EMAIL ADDRESS OF AUTHOR]
## Bug: [UPSTREAM BUG URL]
## Bug-Ubuntu: https://launchpad.net/bugs/[BUG NUMBER]
Index: dbus-1.4.18/dbus/dbus-marshal-validate.c
...

Multiple vulnerabilities can be fixed in the same security upload; just be sure to use different patches for different vulnerabilities.

Deine Arbeit testen und einsenden

At this point the process is the same as for fixing a regular bug in Ubuntu. Specifically, you will want to:

  1. Build your package and verify that it compiles without error and without any added compiler warnings
  2. Upgrade to the new version of the package from the previous version
  3. Test that the new package fixes the vulnerability and does not introduce any regressions
  4. Submit your work via a Launchpad merge proposal and file a Launchpad bug being sure to mark the bug as a security bug and to subscribe ubuntu-security-sponsors

If the security vulnerability is not yet public then do not file a merge proposal and ensure you mark the bug as private.

The filed bug should include a Test Case, i.e. a comment which clearly shows how to recreate the bug by running the old version then how to ensure the bug no longer exists in the new version.

The bug report should also confirm that the issue is fixed in Ubuntu versions newer than the one with the proposed fix (in the above example newer than Precise). If the issue is not fixed in newer Ubuntu versions you should prepare updates for those versions too.

Updates fuer stabile Releases

We also allow updates to releases where a package has a high impact bug such as a severe regression from a previous release or a bug which could cause data loss. Due to the potential for such updates to themselves introduce bugs we only allow this where the change can be easily understood and verified.

The process for Stable Release Updates is just the same as the process for security bugs except you should subscribe ubuntu-sru to the bug.

The update will go into the proposed archive (for example precise-proposed) where it will need to be checked that it fixes the problem and does not introduce new problems. After a week without reported problems it can be moved to updates.

Für weitere Informationen besuche die ‘Stable Release Updates wiki’ Seite.

Patches für Pakete

Sometimes, Ubuntu package maintainers have to change the upstream source code in order to make it work properly on Ubuntu. Examples include, patches to upstream that haven’t yet made it into a released version, or changes to the upstream’s build system needed only for building it on Ubuntu. We could change the upstream source code directly, but doing this makes it more difficult to remove the patches later when upstream has incorporated them, or extract the change to submit to the upstream project. Instead, we keep these changes as separate patches, in the form of diff files.

Man kann Patches in Debian-Paketen auf unterschiedliche Arten handhaben, glücklicherweise stellt sich Quilt als Standard heraus, weil es von den meisten Paketen verwendet wird.

Let’s look at an example package, kamoso in Trusty:

$ bzr branch ubuntu:trusty/kamoso

The patches are kept in debian/patches. This package has one patch kubuntu_01_fix_qmax_on_armel.diff to fix a compile failure on ARM. The patch has been given a name to describe what it does, a number to keep the patches in order (two patches can overlap if they change the same file) and in this case the Kubuntu team adds their own prefix to show the patch comes from them rather than from Debian.

Die Reihenfolge in der Patches angewandt werden ist in debian/patches/series definiert.

Patches mit Quilt

Bevor Du mit Quilt arbeitest, musst Du spezifizieren, wo die Patches liegen. Füge dies in Deine ~/.bashrc hinzu:

export QUILT_PATCHES=debian/patches

Und verwende source, um die neuen Exports anzuwenden:

$ . ~/.bashrc

Standardmäßig werden alle Patches angewandt, wenn Du UDD Checkouts or heruntergeladene Quellpakete benutzt. Du kannst dies folgendermaßen überprüfen:

$ quilt applied
kubuntu_01_fix_qmax_on_armel.diff

Wenn Du den Patch entfernen wolltest, würdest du pop ausführen:

$ quilt pop
Removing patch kubuntu_01_fix_qmax_on_armel.diff
Restoring src/kamoso.cpp

No patches applied

Und um einen Patch anzuwenden, verwendst du push:

$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp

Now at patch kubuntu_01_fix_qmax_on_armel.diff

Einen neuen Patch hinzufügen

Um einen neuen Patch hinzuzufügen muss Quilt angewiesen werden, einen neuen Patch zu erstellen, sagen Sie ihm welche Dateien dieser Patch ändern soll, bearbeiten Sie die Dateien und aktualisieren Sie den Patch:

$ quilt new kubuntu_02_program_description.diff
Patch kubuntu_02_program_description.diff is now on top
$ quilt add src/main.cpp
File src/main.cpp added to patch kubuntu_02_program_description.diff
$ sed -i "s,Webcam picture retriever,Webcam snapshot program,"
src/main.cpp
$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff

Der quilt add ist sehr wichtig, wenn du ihn vergisst, werden die Dateien nicht im Patch auftauchen.

Die Änderung wird jetzt in debian/patches/kubuntu_02_program_description.diff sein und die series Datei wird den Patch auflisten. Du solltest die neue Datei zur Paketierung hinzufügen:

$ bzr add debian/patches/kubuntu_02_program_description.diff
$ bzr add .pc/*
$ dch -i "Add patch kubuntu_02_program_description.diff to improve the program description"
$ bzr commit

Quilt behält seine Metadaten im .pc/ Verzeichnis, sodass dieses momentan ebenfalls für das Paketieren hinzugefügt werden muss. In der Zukunft sollte das verbessert werden.

Im Allgemeinen sollten Sie vorsichtig sein, Patches zu Programmen hinzuzufügen sofern diese nicht von Upstream kommen, es gibt häufig einen guten Grund warum die Änderung noch nicht vorgenommen wurde. Das oben genannte Beispiel ändert einen Benutzerschnittstellen-String beispielswese und würde somit mit den gesamten Übersetzungen brechen. Wenn Zweifel bestehen, fragen Sie den Upstreamautor bevor ein Patch hinzugefügt wird.

Patch Headers

Wir empfehlen, dass du jeden Patch mit den DEP-3 Kopfzeilen versiehst. Hier sind einige Einträge, die du verwenden kannst:

Description:Description of what the patch does. It is formatted like Description field in debian/control: first line is short description, starting with lowercase letter, the next lines are long description, indented with a space.
Author:Autor des Patches (i.e. “Jane Doe <packager@example.com>”).
Origin:Wo der Patch herkommt (z.B. “upstream”), wenn Author nicht verwendet wird.
Bug-Ubuntu:Ein Link zu einem Launchpad-Bug, eine Kurzform wird vorgezogen (wie z.B. https://bugs.launchpad.net/bugs/XXXXXXX). Wenn es auch Bugs in Upstream-Bugtracker oder in Debian gibt, füge auch Bug oder Bug-Debian Einträge hinzu.
Forwarded:Ob der Patch an Upstream weitergeleitet wurde. Entweder “yes”, “no” oder “not-needed”.
Last-Update:Datum der letzten Revision (in der Form “YYYY-MM-DD”).

Auf neue Upstream Versionen aktualisieren

Um zur neuen Version zu upgraden, kannst du das bzr merge-upstream Kommando verwenden:

$ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.2.orig.tar.bz2

Wenn Sie diesen Befehl starten, werden alle Patches nicht angewandt, da sie nicht mehr zu alt werden können. Sie müssen eventuell aktualisiert werden um der neuen Upstreamquelle zu entsprechen oder sie müssen eventuell in ihrer Gesamtheit entfernt werden. Um nach Problemen zu forschen, wenden Sie die Patches nacheinander an:

$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp
Hunk #1 FAILED at 398.
1 out of 1 hunk FAILED -- rejects in file src/kamoso.cpp
Patch kubuntu_01_fix_qmax_on_armel.diff can be reverse-applied

Wenn er umgekehrt angewendet werden kann, bedeutet das, dass der Patch bereits von Upstream angewendet wurde, damit kann er gelöscht werden:

$ quilt delete kubuntu_01_fix_qmax_on_armel
Removed patch kubuntu_01_fix_qmax_on_armel.diff

Dann fahre fort:

$ quilt push
Applied kubuntu_02_program_description.diff

Es ist sinnvoll Refresh zu starten, dies wird den Patch entsprechend der veränderten Upstreamquelle aktualisieren:

$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff

Dann committe wie ueblich:

$ bzr commit -m "new upstream version"

Quilt im Paket verwenden

Moderne Pakete nutzen standardmäßig Quilt, welches in das Paketierungsformat eingebaut ist. Prüfen Sie debian/source/format um sich zu vergewissern, dass dort 3.0 (quilt) steht.

Ältere Pakete, die das Quellformat 1.0 verwenden, werden explizit Quilt verwenden müssen, normalerweise in dem ein Makefile in debian/rules eingebunden wird.

Quilt konfigurieren

Die ~/.quiltrc Datei kann verwendet werden um quilt zu konfigurieren. Hier sind einige Optionen, die nützlich sein können, für die Verwendung von quilt mit debian/packages:

# Set the patches directory
QUILT_PATCHES="debian/patches"
# Remove all useless formatting from the patches
QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
# The same for quilt diff command, and use colored output
QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"

Andere Patch-Systeme

Other patch systems used by packages include dpatch and cdbs simple-patchsys, these work similarly to Quilt by keeping patches in debian/patches but have different commands to apply, un-apply or create patches. You can find out which patch system is used by a package by using the what-patch command (from the ubuntu-dev-tools package). You can use edit-patch, shown in previous chapters, as a reliable way to work with all systems.

In even older packages changes will be included directly to sources and kept in the diff.gz source file. This makes it hard to upgrade to new upstream versions or differentiate between patches and is best avoided.

Ändere nicht das Patch-System eines Pakets ohne das mit dem Debian-Maintainer oder dem zuständigen Ubuntu-Team zu besprechen. Wenn derzeit keines existiert, ist es dir freigestellt Quilt hinzuzufügen.

FTBFS-Pakete reparieren

Bevor ein Paket in Ubuntu verwendet werden kann, muss es aus den Quellen erstellt werden können. Falls dies nicht gelingt wird es in -proposed warten und ist daher nicht in den Ubuntu-Archiven verfügbar. Eine vollständige Liste solcher Pakete finden Sie unter http://qa.ubuntuwire.org/ftbfs/. Auf der Seite werden 5 Kategorien angezeigt:

  • Paket konnte nicht erstellt werden (F): Beim Erstellen trat ein Fehler auf.
  • Erstellung abgebrochen (X): Die Erstellung wurde aus einem Grund abgebrochen. Davon sollten folgende von Anfang vermieden werden.
  • Paket wartet auf ein anderes Paket (M): Dieses Paket wartet bis ein anderes anderes Paket erstellt oder aktualisiert wird oder (wenn das Paket in main ist) eine seiner Abhängigkeiten ist im falschen Archiv-Teil.
  • Fehler im chroot (C): Ein Teil des chroot is fehlgeschlagen, das kann meist durch eine Neuerstellung des Pakets behoben werden. Bitte einen Entwickler eine Neuerstellung vorzunehmen.
  • Fehler beim Hochladen (U): Das Paket konnte nicht hochgeladen werden. Das ist normalerweise ein Fall um eine Neuerstellung zu bitten, aber überprüfe zuerst das Erstellungsprotokoll.

Erste Schritte

Als erstes solltest du versuchen das FTBFS selbst zu reproduzieren. Hol dir den Code entweder per bzr branch lp:ubuntu/PACKAGE und dann den Tarball oder per dget PACKAGE_DSC auf der ”.dsc”-Datei von der Launchpad-Seite. Ist das einmal erledigt, erstelle es in einer schroot.

Du solltest in der Lage sein das FTBFS zu reproduzieren. Wenn nicht, überprüfe ob gerade eine fehlende Abhängigkeit heruntergeladen wird, was bedeutet das du sie zu einer Erstellungsabhängigkeit in debain/control machen musst. Ein Paket lokal zu erstellen hilft auch ein Problem ausfindig zu machen, was durch eine eine fehlende, nicht aufgeführte Abhängigkeit verursacht wird (funktioniert lokal aber nicht in einer schroot).

Debian überprüfen

Kannst du das Problem reproduzieren, ist es an der Zeit eine Lösung zu finden. Falls das Paket auch in Debian enthalten ist, kannst du überprüfen ob es dort erstellt werden kann, indem du auf http://packages.qa.debian.org/PACKAGE gehst. Falls Debian eine aktuelle Version einsetzt, solltest du sie mergen. Falls nicht, überprüfe die Erstellungs- und Fehlerberichte, die auf der Seite verlinkt sind, für zusätzliche Infos über FTBFS oder Patches. Debian betreut auch eine Liste von Befehl-FTBFS und wie sie behoben werden können; sie ist unter https://wiki.debian.org/qa.debian.org/FTBFS zu finden, du wirst sie sicher auch bei der Lösungssuche einbeziehen wollen.

ARM64

Ubuntu has added arm64 as a architecture recently, but many packages fail to build on it. A full list of the packages not building are at qa.ubuntuwire.org/ftbfs/arm64.html. Many of these are caused by packages using outdated autotools helper files. Any package with the lintian warning ancient-autotools-helper-file or outdated-autotools-helper-file will have this issue. Adding autotools-dev or dh-autoreconf to the build proccess will usually fix this.

Andere Gründe warum die Paketerstellung fehlsschlägt

Wenn ein Paket in main enthalten ist, aber eine dessen Abhängigkeiten ist nicht in main vorhanden, sollte ein MIR-Fehlerbericht eingereicht werden. https://wiki.ubuntu.com/MainInclusionProcess erklärt den Ablauf.

Das Problem beheben

Hast du erst einmal eine Lösung für das Problem gefunden, folge demselben Prozess wie bei jedem anderen Fehler. Erstelle einen Patch, hänge ihn an einen bzr-Zweig oder -Fehler an, informiere ubuntu-sponsors, und versuche dann das der Patch von Upstream und/oder Debian aufgenommen wird.

Gemeinsame Bibliotheken

Gemeinsame Bibliotheken sind kompilierter Code, der von vielen verschiedenen Programmen gemeinsam genutzt wird. Sie werden als .so-Dateien unter /usr/lib/ zur Verfügung gestellt.

Eine Bibliothek exportiert Symbole, welche die kompilierten Versionen von Funktion, Klassen und Variablen sind. Eine Bibliothek wird als SONAME bezeichnet und beinhaltet eine Versionsnummer. Dieser SONAME entspricht nicht zwingend der öffentlichen Versionsbezeichnung. Ein Programm wird gegen eine gegebene SONAME-Version der Bibliothek kompiliert. Wenn eines der Symbole entfernt oder geändert wird, muss die Versionsnummer angepasst werden, was dazu führt, dass jedes Paket welches die Bibliothek benutzt, wieder gegen die neue Version kompiliert werden musss. Versionsnummern werden normalerweise vom Upstream festgelegt und wir folgen ihnen mit unseren Binärpaketnamen, auch ABI-Nummer genannt. Aber manchmal benutzt der Upstream keine vernünftigen Versionsnummern und die Paketierer müssen einer getrennten Nummerierung folgen.

Libraries are usually distributed by upstream as standalone releases. Sometimes they are distributed as part of a program. In this case they can be included in the binary package along with the program (this is called bundling) if you do not expect any other programs to use the library, more often they should be split out into separate binary packages.

Die Bibliotheken selbst werden in einem Binärpaket mit dem Namen libfoo1 abgelegt, wobei foo der Name der Bibliothek und 1 die SONAME-Version ist. Entwicklungsdateien aus dem Paket, beispielsweise Kopfdateien, die benötigt werden, um Programme gegen die Bibliothek zu übersetzen, werden in einem Paket mit dem Namen libfoo-dev abgelegt.

Ein Beispiel

Wir werden libnova als Beispiel verwenden:

$ bzr branch ubuntu:trusty/libnova
$ sudo apt-get install libnova-dev

Um den SONAME der Bibliothek herauszufinden, starte:

$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME

The SONAME is libnova-0.12.so.2, which matches the file name (usually the case but not always). Here upstream has put the upstream version number as part of the SONAME and given it an ABI version of 2. Library package names should follow the SONAME of the library they contain. The library binary package is called libnova-0.12-2 where libnova-0.12 is the name of the library and 2 is our ABI number.

Wenn im Upstream inkompatible Änderungen an den Bibliotheken durchgeführt werden, müssen sie eine neue Revision des SONAME erstellen und wir werden unsere Bibliothek umbenennen müssen. Jedes andere Paket welches unsere Bibliothek verwendet, muss dann wieder gegen die neue Version kompiliert werden; das nennt man Transition und kann einigen Aufwand verursachen. Im besten Fall bleibt unsere ABI-Nummer passend zu SONAME des Upstreams, aber manchmal führen sie Inkompatibilitäten ein ohne ihre Versionsnummer zu ändern und so müssen wir unsere anpassen.

Wenn wir uns debian/libnova-0.12-2.install ansehen, stellen wir fest, dass dort zwei Dateien eingebunden werden:

usr/lib/libnova-0.12.so.2
usr/lib/libnova-0.12.so.2.0.0

Das letzte is die eigentliche Bibliothek, komplett mit Unter- und Punkversionsnummer. Das erste ist ein Symlink welcher auf die eigentliche Bibliothek verweist. Der Symlink ist das, nach dem die Programme welche Bibliothek benutzen suchen, sie kümmern sich nicht um die Unterversionsnummern.

libnova-dev.install beinhaltet alle benötigten Dateien um das Programm mit dieser Bibliothek zu kompilieren. Kopfdateien, eine Konfigurationsbinärdatei, die libtool Datei .la und libnova.so, welche als weiterer Symlink zu der Bibliothek führt; Programme die gegen die Bibliothek kompiliert werden kümmern sich nicht um die Hauptversionsnummer (jedoch wird das die Binärdatei in die sie kompilieren berücksichtigen).

.la libtool Dateien werden für manche nicht-Linux Systeme mit beschränkter Bibliotheksunterstützung benötigt. Sie bringen aber im Normalfall auf Debian basierenden Systemen mehr Probleme mit, als sie lösen. Es ist daher eines der derzeit wichtigsten Ziele alle .la Dateien auf Debian-Systemen zu entfernen und daran sollte jeder mitarbeiten.

Statische Bibliotheken

Das -dev Paket stellt außerdem usr/lib/libnova.a bereit. Dies ist eine statische Bibliothek, eine Alternative zu gemeinsamen Bibliotheken. Jedes gegen diese statische Bibliothek kompilierte Programm beinhaltet diesen Quelltext. Damit entfällt das Problem, die Bibliothek könnte als Binärdatei inkompatibel sein. Allerdings bedeutet dies auch, dass alle Fehler, die Sicherheitsprobleme inbegriffen, nicht behoben werden, solange das Programm nicht erneut kompiliert wird. Aus diesem Grund sind Programme, die statische Bibliotheken verwenden, zu vermeiden.

Symbol-Dateien

When a package builds against a library the shlibs mechanism will add a package dependency on that library. This is why most programs will have Depends: ${shlibs:Depends} in debian/control. That gets replaced with the library dependencies at build time. However shlibs can only make it depend on the major ABI version number, 2 in our libnova example, so if new symbols get added in libnova 2.1 a program using these symbols could still be installed against libnova ABI 2.0 which would then crash.

Um die Bibliotheksabhängigkeiten präzise zu halten, verwenden wir .symbols-Dateien, die alle Symbole in einer Bibliothek auflisten und in welcher Version sie zuerst auftauchten.

libnova hat keine Symboldatei, also können wir eine erstellen. Beginne damit das Paket zu kompilieren:

$ bzr builddeb -- -nc

Die Option -nc sorgt dafür, dass nach dem Kompilieren die Dateien des Programms, die währenddessen erzeugten wurden, nicht entfernt werden. Wechseln Sie in das Verzeichnis des Kompilierungsprozesses und führen Sie dpkg-gensymbols für das Bibliothekspaket aus:

$ cd ../build-area/libnova-0.12.2/
$ dpkg-gensymbols -plibnova-0.12-2 > symbols.diff

Dies erstellt eine Diff-Datei welche du selbst anwenden kannst:

$ patch -p0 < symbols.diff

Which will create a file named similar to dpkg-gensymbolsnY_WWI that lists all the symbols. It also lists the current package version. We can remove the packaging version from that listed in the symbols file because new symbols are not generally added by new packaging versions, but by the upstream developers:

$ sed -i s,-0ubuntu2,, dpkg-gensymbolsnY_WWI

Nun verschiebe die Datei an ihren Ort, comitte und mache eine Testlauf:

$ mv dpkg-gensymbolsnY_WWI ../../libnova/debian/libnova-0.12-2.symbols
$ cd ../../libnova
$ bzr add debian/libnova-0.12-2.symbols
$ bzr commit -m "add symbols file"
$ bzr builddeb

Wenn es erfolgreich kompiliert ist die Symboldatei in Ordnung. Mit der nächsten Upstream-Version von libnova würdest du erneut dpkg-gensymbols ausführen und es liefert eine Auflistung der Unterschiede um die Symboldatei zu aktualisieren.

C++-Bibliothek-Symboldateien

C++ hat noch genauere Standards für das Kompilieren als Binärdatei als C. Das Debian Qt/KDE Projekt betreut einige Scripte um dies zu vereinfachen. Lesen Sie die Seite »Arbeiten mit Symboldateien«_ um zu erfahren, wie diese zu benutzen sind.

Weiterführende Literatur

Junichi Uekawa’s Debian Library Packaging Guide erklärt das Thema detaillierter.

Zurückportieren von Software-Aktualisierungen

In manchen Fällen möchtest Du vielleicht gerne eine neue Funktion in einer stabilen Version verfügbar machen, die nicht mit einer kritischen Fehlerbehebung zusammenhängt. Für diese Fälle gibt es zwei Möglichkeiten: Entweder du lädst das Paket in ein PPA hoch oder bereitest einen Backport vor.

Persönliches Paketarchiv (PPA)

Ein PPA bringt viele Vorteile. Es ist leicht zu benutzen und du benötigst keinerlei Genehmigung oder Überprüfung anderer. Aber andererseits werden die Benutzer sie manuell einrichten müssen, da sie keine Standard-Paketquelle ist.

Die PPA Dokumentation auf Launchpad ist sehr verständlich und sollte dich schnell voran bringen.

Offizielle Ubuntu-Backports

Das Zurückportieren ist ein Mittel um den Nutzern neue Funktionen bereitzustellen. Wegen der Gefahr von Kompabilitätsproblemen erhalten Nutzer keine zurückportierten Pakete ohne ausdrückliche Maßnahmen ihrerseits. Das macht Zurückportieren grundsätzlich zu einer schlechten Wahl für Fehlerbehebungen. Wenn ein Paket in einer Ubuntu-Veröffentlichung einen Fehler aufweist, sollte er entweder durch ein Sicherheitsupdate oder den “Stable-Release”-Updateprozess angemessen behoben werden.

Wenn Du Dich dazu entschlossen hast, ein Paket durch eine Backport in einen stabilen Release zu portieren, wirst Du zumindest einen Test-Build ausführen müssen und das Paket in demjenigen Release zu testen. pbuilder-dist (im ubuntu-dev-tools Paket) ist ein tolles Werkzeug um das problemlos zu tun.

Um eine Anfrage auf Zurückportierung zu stellen und sie vom Team bearbeitet zu bekommen, kannst du das Werkzeug requestbackport verwenden (auch in dem Paket ubuntu-dev-tools enthalten). Es wird feststellen welche dazwischenliegende Veröffentlichungen das Paket benötigt um zurückportiert werden zu können, listet alle zurückliegenden Abhängigkeiten auf und stellt eine offizielle Anfrage. Es wird außerdem dem Fehlerbericht eine Prüfliste für Tests anhängen.

Wissensdatenbank

Kommunikation in der Ubuntu-Entwicklung

In einem Projekt, bei dem tausende Zeilen Quelltext geändert werden, viele Entscheidungen getroffen werden und hunderte Leute täglich zusammenspielen, ist es wichtig effizient zu kommunizieren.

Mailinglisten

Mailinglisten sind ein sehr bedeutendes Werkzeug um Ideen an ein größeres Team zu kommunizieren und sicherzustellen, dass man jeden erreicht, auch über Zeitzonen hinweg.

Bezüglich der Entwicklung, sind dies die Wichtigsten:

IRC-Kanäle

Für Echtzeit-Diskussionen schaue auf dem IRC Server irc.freenode.net in einem oder mehreren der folgenden Kanäle vorbei:

  • #ubuntu-devel (für allgemeine Diskussion zur Entwicklung)
  • #ubuntu-motu (für MOTU Team Diskussionen und genereller Hilfe)

Allgemeine Übersicht über das debian/ Verzeichnis

Dieser Artikel gibt eine kurze Übersicht über die verschiedenen Dateien im debian/ Verzeichnis, welche für das Paketieren von Ubuntu Paketen wichtig sind. Die wichtigsten Dateien sind changelog, control, copyright und rules. Diese Dateien werden für alle Pakete benötigt. Anhand weiterer Dateien im debian/ Verzeichnis kann das Verhalten der Pakete angepasst und konfiguriert werden. Während einige dieser Dateien in diesem Artikel beschrieben werden, ist er nicht als vollständige Übersicht gedacht.

Das Änderungsprotokoll

Die Datei ist, wie sich schon am Namen erkennen lässt, eine Liste von Änderungen die in jeder Version gemacht wurden. Sie hat ein spezielles Format aus dem man Paketname, Version, Distribution, Änderungen, Autor und Zeitpunkt herauslesen kann. Falls du einen GPG-Schlüssel besitzt (siehe: Erste Schritte), stelle sicher dass du den selben Alias und E-Mail Adresse im changelog verwendest wie in deinem Schlüssel. Das folgende ist eine changelog Vorlage:

package (version) distribution; urgency=urgency

 * change details
  - more change details
 * even more change details

-- maintainer name <email address>[two spaces]  date

Das Format (besonders das Datumsformat) ist wichtig. Das Datum sollte im RFC 5322 Format sein, sodass es dann durch Eingabe von date -R abgerufen werden kann. Zur Erleichterung kann der Befehl ``dch``genutzt werden, um den Changelog zu editieren. Er wird das Datum automatisch aktualisieren.

Unterpunkte werden durch einen Strich “-” dargestellt, während Hauptpunkte durch einen Stern “*” gekennzeichnet werden.

Falls Du ein neues Paket ohne Vorlage erstellst, kannst Du mit dch --create (dch befindet sich im devscripts Paket) standard Daten für debian/changelog anlegen.

Dies ist ein Beispiel für eine changelog Datei des hello Pakets:

hello (2.8-0ubuntu1) trusty; urgency=low

  * New upstream release with lots of bug fixes and feature improvements.

-- Jane Doe <packager@example.com>  Thu, 21 Oct 2013 11:12:00 -0400

Erwähnenswert ist, dass die Version ein -0ubuntu1 Suffix angehängt hat, das die Distributions-Änderung wiederspiegelt. Sie wird benutzt damit das Packetieren in der gleichen Quellversion aktualisiert werden kann (z.B. für Fehlerbehebungen).

Ubuntu und Debian haben leicht unterschiedliche Versionsbezeichnungen um Konflikte mit demselben Quellpaket zu vermeiden. Wenn ein Debian-Paket unter Ubuntu geändert wurde, wird ein ubuntuX (wobei X für die Ubuntu-Revision steht) an das Ende der Debianversion angehängt. Also wenn das Debian-Paket hello 2.6-1 unter Ubuntu geändert wurde, würde die Versionsbezeichnung 2.6-1ubuntu1 sein. Falls ein Paket dieser Anwendung nicht für Debian existiert, dann ist die Debian-Revision 0 (z.B. 2.6-0ubuntu1).

Für weitere Informationen, schau Dir die changelog section (Section 4.4) des Debian Policy Manual an.

Die control Datei

Die control Datei enthält Informationen, die der Paketmanager (also z.B. apt-get, synaptic und adept) verwendet, build-spezifische Abhängigkeiten, Betreuerinformationen und vieles andere.

Für das Ubuntupaket hello, sieht die Datei control folgendermaßen aus:

Source: hello
Section: devel
Priority: optional
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Jane Doe <packager@example.com>
Standards-Version: 3.9.5
Build-Depends: debhelper (>= 7)
Vcs-Bzr: lp:ubuntu/hello
Homepage: http://www.gnu.org/software/hello/

Package: hello
Architecture: any
Depends: ${shlibs:Depends}
Description: The classic greeting, and a good example
 The GNU hello program produces a familiar, friendly greeting. It
 allows non-programmers to use a classic computer science tool which
 would otherwise be unavailable to them. Seriously, though: this is
 an example of how to do a Debian package. It is the Debian version of
 the GNU Project's `hello world' program (which is itself an example
 for the GNU Project).

Der erste Absatz beschreibt in dem Feld Build-Depends das Quellpaket inklusive aller benötigten Paketabhängigkeiten, die nötig sind um das Paket aus dem Quellcode zu bauen. Es enthält außerdem einige Metadaten wie den Namen des Verantwortlichen, die Version der Debian-Richtlinien, der Ort der Paketversionkontrolle und die Upstream-Homepage.

Beachten sie, dass in Ubuntu das Maintainer Feld eine allgemeine Adresse enthält, weil jeder jedes Paket bearbeiten kann (dies unterscheidet sich von Debian, wo das Bearbeiten einer Person oder einem Team vorbehalten ist). Pakete von Ubuntu sollten allgemein im Maintainer Feld die Angabe Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> haben. Wird dieses Feld verändert, sollte diese Angabe im Feld XSBC-Original-Maintainer gespeichert werden. Für diesen Zweck gibt es das update-maintainer Script aus dem ubuntu-dev-tools Paket. Weitere Informationen können Sie unter Debian Maintainer Feld Spezifikation im Ubuntu Wiki nachlesen.

Jeder weitere Abschnitte beschreibt ein Binärpaket, welches gebaut wird.

Für weitere Information, schau Dir control file section (Chapter 5) des Debian Policy Manual an.

Die rules Datei

Die letzte Datei, die wir uns anschauen ist rules. Hier geschieht alle Arbeit, um das Paket zu erzeugen. Es ist ein Makefile mit Targets, um die Anwendung zu kompilieren und zu installieren, dann die .deb Datei von den installierten Dateien zu erzeugen. Es enthält auch ein Target um “aufzuräumen”, so dass das Quellpaket wieder auf dem ursprünglichen Stand ist.

Hier ist eine vereinfachte Version der rules Datei, die von dh_make erzeugt wurde (erhältlich im dh-make Paket):

#!/usr/bin/make -f
# -*- makefile -*-

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

%:
       dh  $@

Lass uns durch diese Datei ein bisschen genauer durchgehen. Sie sorgt dafür, dass jedes Target, welches von debian/rules aufgerufen wird, als Argument an /usr/bin/dh weitergegeben wird, welches selbst wiederum alle nötigen dh_*-Befehle aufrufen wird.

dh durchläuft eine Sequenz von debhelper Kommandos. Die unterstützen Sequenzen korrespondieren mit den Targets einer debian/rules-Datei: “build”, “clean”, “install”, “binary-arch”, “binary-indep” und “binary”. Um zu sehen, welche Kommandos als Teil welchen Targets durchlaufen werden, benutze:

$ dh binary-arch --no-act

Befehlen in der Sequenz binary-indep wird die Option “-i” mitgegeben um sicherzustellen, dass sie nur mit binär-unabhängigen Paketen funktionieren und Befehlen in der Sequenz binary-arch wird die Option “-a” mitgegeben um sicherzustellen, dass sie nur mit Architektur-unabhängigen Paketen funktionieren.

Jeder debhelper Befehl wird aufgenommen wenn er erfolgreich in debian/package.debhelper.log ausgeführt wird. (Welcher dh_clean löscht.) So kann dh mitteilen welche Befehle bereits für welches Paket ausgeführt wurden und überspringt diejenigen, die nochmals ausgeführt werden sollen.

Jedes Mal wenn dh ausgeführt wird, untersucht es die Logdatei und findet den zuletzt verwendeten Befehl welcher in der gegebenen Sequenz enthalten ist. Es springt danach zum nächsten Befehl in der Sequenz. Die Optionen --until, --before, --after und --remaining können dieses Verhalten beeinflussen.

Falls debian/rules ein Target mit einem Namen wie override_dh_command enthält, dann wird dh, sobald es an dem Befehl in der Sequenz angekommen ist, das Target von dieser Anweisungsdatei verwenden statt den eigentlichen Befehl auszuführen. Das neue Target kann dann den Befehl mit mit anderen Optionen ausführen oder komplett andere Befehle stattdessen ausführen. (Zu beachten ist, dass du für die Erstellung debhelper 7.0.50 oder höher verwenden solltest.)

Wirf einen Blick in /usr/share/doc/debhelper/examples/ und man dh für weitere Beispiele. Außerdem ist der Regelkatalog (Abschnitt 4.9) der Debian-Grundsatzanweisung hilfreich.

Zusätzliche Dateien

Die Datei install

Die Datei install wir dvon dh_install verwendet um Dateien in das Binärpacket zu installieren. Es hat zwei gängige Einsatzmöglichkeiten:

  • Um Dateien in dein Paket zu installieren, die nicht vom Upstream-Build-System installiert werden.
  • Aufteilen eines einzelnen großen Quellpaketes in mehrere Binärpakete.

Im ersten Fall sollte die Datei install eine Zeile für jede installierte Datei enthalten, die sowohl das Datei- als auch Installationsverzeichnis festlegt. Zum Beispiel, die folgende install-Datei würde das das Skript foo in das Stammverzeichnis des Quellpakets nach usr/bin und eine Desktop-Datei in das debian-Verzeichnis nach usr/share/applications installieren:

foo usr/bin
debian/bar.desktop usr/share/applications

Wenn ein Quellpaket mehrere Binärpakete produziert, wird dh die Dateien in debian/tmp statt direkt in in debian/<package> installieren. Dateien aus debian/tmp können dann in getrennte Binärpakete mithilfe mehrerer $package_name.install-Dateien verschoben werden. Dies wird oft dazu benutzt um große Mengen architekturunabhängiger Daten aus architekturabhängigen Paketen herauszulösen und sie in Architecture: all-Pakete zu integrieren. In diesem Fall werden nur der Name der zu installierenden Dateien (oder Ordner) benötigt und nicht das Installationsverzeichnis. Zum Beispiel könnte foo.install mit ausschließlich architekturabhängigen Dateien so ausschauen:

usr/bin/
usr/lib/foo/*.so

Während foo-common.install mit der architekturunabhängigen Datei so ausschauen könnte:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

Dies würde zwei Binärpakete erzeugen, foo und foo-common. Beide würden ihren eigenen Abschnitt in debian/control benötigen.

Siehe man dh_install und den Abschnitt zur Installationsdatei (Abschnitt 5.11) der Debian-Anleitung für neue Maintainers für zusätzliche Informationen.

Die Datei ‘watch’

Die Datei debian/watch erlaubt uns automatisch mithilfe des Werkzeuges uscan in dem Paket devscripts zu überprüfen, ob neue Upstream-Versionen vorhanden sind. Die erste Zeile der “watch”-Datei muss die Format-Version bezeichnen (3, zum Zeipunkt dieser Textfassung), während die folgenden Zeilen die zu parsenden URLs enthalten. Zum Beispiel:

version=3

http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz

Der Befehl uscan im Wurzelverzeichnis des Quellcodes wird jetzt die Upstream-Versionsnummer in debian/changelog mit der neusten verfügbaren Upstream-Version vergleichen. Wenn eine neue Upstream-Version gefunden wurde, wird sie automatisch heruntergeladen. Zum Beispiel:

$ uscan
hello: Newer version (2.7) available on remote site:
  http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz
  (local version is 2.6)
hello: Successfully downloaded updated package hello-2.7.tar.gz
    and symlinked hello_2.7.orig.tar.gz to it

Sollten Deine Tarballs in Launchpad sein, so wird debian/watch etwas komplizierter (siehe Question 21146 und Bug 231797 für mehr Informationen). In diesem Fall benutze etwas wie:

version=3
https://launchpad.net/flufl.enum/+download http://launchpad.net/flufl.enum/.*/flufl.enum-(.+).tar.gz

Für weitere Informationen, schaue Dir man uscan und die watch file section (Section 4.11) im Debian Policy Manual an.

Um eine Liste der Pakete zu sehen, deren watch Datei eine neuere Version Upstream berichtet, schau Dir Ubuntu External Health Status an.

Die Datei source/format

Diese Datei spezifiziert das Format des Quellpakets. Es sollt eine einzige Zeile enthalten, die das gewünschte Format beschreibt.

  • 3.0 (native) für native Debian-Pakete (keine Upstreamversion)
  • 3.0 (quilt) für Pakete mit einem separaten Upstream-Tarball
  • 1.0 für Pakete, die explizit das Standard-Format wünschen

Momentan wird das Paket-Quellformat standardmäßig auf 1.0 gesetzt, sollte die Datei nicht existieren. Das kann man jedoch auch explizit in der source/format Datei angeben. Solltest Du Dich dagegen entscheiden, wird lintian eine Warnung wegen der fehlenden Datei ausgeben. Diese Warnung hat lediglich Informationscharakter und kann sicher ignoriert werden.

Entwickler werden ermutigt, das neuere 3.0 Quellformat zu verwenden, es stellt eine Reihe von Features bereit:

  • Unterstützung für zusätzliche Komprimierungsformate: bzip2, lzma, xz
  • Ünterstützung für mehrere Upstream-Tarballs
  • Nicht nötig den Upsteam-Tarball neu zu packen um das Debian-Verzeichnis zu löschen
  • Debian-spezifische Änderung sind nicht länger in einem einzelnen .diff.gz sondern stattdessen in mehreren Patches kompatibel mit quilt unter debian/patches/

http://wiki.debian.org/Projects/DebSrc3.0 umfasst zusätzliche Informationen bezüglich dem Umstieg zu dem 3.0 Quellcode-Format.

man dpkg-source und source/format section (Section 5.21) aus dem Debian New Maintainers’ Guide haben weitere Details.

Weiterführende Quellen

Ergänzend zu den Debian Grundlagen in jedem obigen Abschnitt sind detailliertere Informationen zu den einzelnen Dateien im Leitfaden für neue Debian-Betreuer zusammengefasst. Kapitel 4, “Benötigte Dateien im Verzeichnis debian” geht auch vertiefend auf die Dateien control, changelog, copyright und rules ein. Kapitel 5, “Andere Dateien im Verzeichnis debian” behandelt alle anderen möglicherweise benötigten Dateien.

autopkgtest: Automatische Tests für Pakete

Die DEP 8-Spezifikation legt fest, wie automatische Tests sehr einfach in Pakete eingebunden werden können. Um einen Test in ein Paket einzubinden, müssen Sie nur folgendes machen:

  • fügen Sie folgendes zum Abschnitt “Source” in debian/control hinzu:

    XS-Testsuite: autopkgtest
  • erstellen Sie eine Datei namens debian/tests/control, die die Anforderungen für die Testumgebung festlegt,

  • fügen Sie die Tests in debian/tests/ ein.

Anforderungen für die Testumgebung

In debian/tests/control legen Sie fest, welche Anforderungen die Testumgebung erfüllen muss. Sie können zum Beispiel alle Pakete auflisten, die für die Tests benötigt werden, oder angeben, ob die Testumgebung beim Erstellen des Pakets beschädigt wird oder ob root-Rechte benötigt werden. Die DEP 8 specification listet alle verfügbaren Optionen auf.

Im Folgenden schauen uns das Quellpaket glib2.0 an. Im einfachsten Fall sieht die Datei so aus:

Tests: build
Depends: libglib2.0-dev, build-essential

Das stellt für den Test debian/tests/build sicher, dass die Pakete libglib2.0-dev und build-essential installiert sind.

Bemerkung

Sie können in der Depends-Zeile @ benutzen, um festzulegen, dass Sie alle Pakete installiert haben wollen, die aus dem jeweiligen Quellpaket erzeugt werden.

Die eigentlichen Tests

Der passende Test für das obige Beispiel könnte folgender sein:

#!/bin/sh
# autopkgtest check: Build and run a program against glib, to verify that the
# headers and pkg-config file are installed correctly
# (C) 2012 Canonical Ltd.
# Author: Martin Pitt <martin.pitt@ubuntu.com>

set -e

WORKDIR=$(mktemp -d)
trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
cd $WORKDIR
cat <<EOF > glibtest.c
#include <glib.h>

int main()
{
    g_assert_cmpint (g_strcmp0 (NULL, "hello"), ==, -1);
    g_assert_cmpstr (g_find_program_in_path ("bash"), ==, "/bin/bash");
    return 0;
}
EOF

gcc -o glibtest glibtest.c `pkg-config --cflags --libs glib-2.0`
echo "build: OK"
[ -x glibtest ]
./glibtest
echo "run: OK"

An dieser Stelle wird ein sehr einfaches Stück C-Code in ein temporäres Verzeichnis geschrieben. Dies wird mit den Systembibliotheken übersetzt (wobei die Flags und Bibliothekpfade benutzt werden, wie sie uns von pkg-config geliefert werden). Dann wird der resultierende Binär-Code ausgeführt, der grundlegende Funtionen in glib testet.

Obwohl es sich um einen kleinen und simplen Test handelt, werden eine größere Anzahl von Systemkomponenten getestet. Dies hilft kritische Fehler früher zu entdecken.

Den Test ausführen

Das Test-Skript kann selbst ausgeführt werden, aber um sicherzustellen, dass der Test auch in der Testumgebung zufriedenstellend abläuft, bietet es sich an “adt-run” (im Paket “autopkgtest”) zu verwenden, um diesen Test auszuführen. Der einfachste Weg dazu ist diesen Befehl im Quellpfad auszuführen.

sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null

Der Nachteil dieser Herangehensweise ist, dass du es zwar lokal testen kannst, aber nicht sicherstellen kannst, dass es in einer minimalen Umgebung funktioniert. Zum Beispiel ist es schwierig festzustellen, ob alle benötigten Pakete für die Versuche installiert sind. Mit ‘lp:auto-package-testing’ haben wir ein umfangreiches Hilfsmittel, welches auf Basis einer unveränderten virtuellen Machine die Tests durchführt. Um es einzurichten, musst du zuerst die benötigten Abhängigkeiten installieren:

sudo apt-get install qemu-utils kvm eatmydata

Dann besorge dir den Quellcode von Launchpad:

bzr branch lp:auto-package-testing
cd auto-package-testing

And provision a Trusty AMD64 system:

./bin/prepare-testbed -r trusty amd64

This command will create a pristine Trusty AMD64 VM from a cloud image. To run the tests, simply run:

./bin/run-adt-test -r trusty -a amd64 \
    -S file:///tmp/glib2.0-2.35.7/ glib2.0

Das würde das Quellpaket /tmp/glib2.0-2.35.7/ auswählen und die Tests gegen das Paket glib2.0 aus dem Archiv laufen lassen. Die Option -S unterstützt auch Quellen von bzr, git und apt. Wenn du nur eine Quelle mit -S festlegst, aber den Paketnamen nicht genauer bestimmst, wird diese Funktion stattdessen den Zweig aufbauen und die Binaries von dieser Version installieren; das ist nützlich wenn du Tests für ein neueres Paket durchführen willst als das welches in Ubuntu enthalten ist oder das Paket überhaupt nicht in Ubuntu existiert. Wenn du die Option -k setzt kannst du in die virtuelle Maschine wechseln nachdem die Tests durchgeführt wurden. Das macht es sehr einfach Fehler zu erkennen.

Die ‘auto-package-testing documentation’ hat viele andere wichtige Informationen für andere Testoptionen.

Weitere Beispiele

Diese Liste ist nicht vollständig, aber wird dir sicher einen guten Einblick geben wie automatisierte Testdurchläufe in Ubuntu implementiert und benutzt werden.

  • Die libxml2 tests sind sehr ähnlich. Sie enthalten auch eine Test-Kompilierung eines Stücks C-Code und führen es aus.
  • Der Test ‘gtk+3.0 tests’ erwirkt außerdem einen Kompilierungs-, Link- und Durchlaufstest im ‘’build’’ Test. Es gibt einen zusätzlichen “python3-gi”-Test, welcher sicherstellt, dass die GTK-Bibliothek auch durch “Introspection” benutzt werden kann.
  • In den ubiquity tests wird die Test-Suite von Upstream (den Software-Autoren) ausgeführt.
  • Die gvfs tests haben ausführliche Funktionalitätstests und sind sehr interessant, weil sie die Benutzung von CDs, Samba, DAV und anderen Dingen simulieren.

Ubuntu Infrastruktur

Pakete, welche autopkgtest aktiviert haben, werden jedes mal, wenn Sie hochgeladen werden oder eine Ihrer Abhängigkeiten sich ändert, einem Testlauf unterzogen. Die Ausgabe der automatisch laufenden autopkgtest-Tests können im Internet angesehen werden und werden regelmäßig aktualisiert.

Debian hat bisher noch keine Infrastruktur für Automatisches Testen, aber Tests sollten trotzdem nach Debian weitergeleitet werden, denn DEP-8 ist eine Debian-Spezifikation und Debian-Entwickler und -Nutzer können Tests immerhin manuell ausführen.

Pakete in Debian mit dem Testsuite-Header werden außerdem automatisch hinzugefügt, wenn sie nach Ubuntu gesynced werden.

Die Tests in Ubuntu bekommen

Der Prozess, um einen autopkgtest in Ubuntu einzubringen ist größtenteils identisch mit fixing a bug in Ubuntu. Im Prinzip muss man einfach:

  • Führe bzr branch ubuntu:<Paketname> aus,
  • bearbeiten Sie debian/control um die Tests zu aktivitieren,
  • fügen Sie ein debian/tests-Verzeichnis hinzu,
  • schreiben Sie die debian/tests/control-Datei, basierend auf der DEP 8 Specification,
  • fügen Sie Ihre(n) Test(s) zu debian/tests hinzu,
  • die Änderungen committen, sie nach Launchpad hochladen, und einen Merge vorschlagen, sie dann überprüfen lassen, genau wie jede andere Änderung an einem Quellpaket auch.

Was du machen kannst

Das Ubuntu Engineering Team hat eine Liste von list of required test-cases zusammengestellt, wo Pakete die Tests brauchen in verschiedene Kategorien aufgeteilt wurden. Hier kannst du eine Liste von Beispielen von Tests finden und das Schreiben der Tests Dir zuweisen.

Falls irgendwelche Probleme auftreten, kannst du dem #ubuntu-quality IRC channel beitreten, um in Kontakt mit den Entwicklern zu treten.

Den Quelltext bekommen

Quellpaket-URLs

Bazaar bietet einige nette Abkürzungen, um Zugang zu Launchpads Quellverzeichnispaketen zu bekommen, sowohl in Ubuntu als auch in Debian.

Um Dich auf Quellzweige zu beziehen benutze:

ubuntu:package

wobei Paket sich auf den Paketnamen bezieht, an dem du interessiert bist. Diese URL gehört zu dem Paket der aktuellen Entwicklerversion von Ubuntu. Um auf das Tomboy-Verzeichnis der Entwicklerversion zuzugreifen, würdest du benutzen:

ubuntu:tomboy

To refer to the version of a source package in an older release of Ubuntu, just prefix the package name with the release’s code name. E.g. to refer to Tomboy’s source package in Saucy use:

ubuntu:saucy/tomboy

Weil sie eindeutig sind, kannst Du die Distro-Serien-Namen auch abkürzen:

ubuntu:s/tomboy

You can use a similar scheme to access the source branches in Debian, although there are no shortcuts for the Debian distro-series names. To access the Tomboy branch in the current development series for Debian use:

debianlp:tomboy

and to access Tomboy in Debian Wheezy use:

debianlp:wheezy/tomboy

Den Quelltext herunterladen

Every source package in Ubuntu has an associated source branch on Launchpad. These source branches are updated automatically by Launchpad, although the process is not currently foolproof.

There are a couple of things that we do first in order to make the workflow more efficient later. Once you are used to the process you will learn when it makes sense to skip these steps.

Einen verteilten Aufbewahrungsort (Repository) erstellen

Sagen wir du willst an dem Paket Tomboy arbeiten, und du hast überprüft, dass das Quellpaket tomboy benannt ist. Bevor der Code von Tomboy bezogen wird, erstelle eine gemeinsam genutzte Ablage für die Zweige des Pakets. Die gemeinsame Ablage macht zukünftige Arbeiten um einiges effizienter.

Verwende dazu den Befehl bzr init-repo, gib als Argument einfach den Verzeichnisnamen an, den Du verwenden möchtest:

$ bzr init-repo tomboy

You will see that a tomboy directory is created in your current working area. Change to this new directory for the rest of your work:

$ cd tomboy
Den trunk-Zweig bekommen

We use the bzr branch command to create a local branch of the package. We’ll name the target directory tomboy.dev just to keep things easy to remember:

$ bzr branch ubuntu:tomboy tomboy.dev

The tomboy.dev directory represents the version of Tomboy in the development version of Ubuntu, and you can always cd into this directory and do a bzr pull to get any future updates.

Sicherstellen, dass die Version aktuell ist

When you do your bzr branch you will get a message telling you if the packaging branch is up to date. For example:

$ bzr branch ubuntu:tomboy
Most recent Ubuntu version: 1.8.0-1ubuntu1.2
Packaging branch status: CURRENT
Branched 86 revisions.

Occasionally the importer fails and packaging branches do not match what is in the archive. A message saying:

Packaging branch status: OUT-OF-DATE

means the importer has failed. You can find out why on http://package-import.ubuntu.com/status/ and file a bug on the UDD project to get the issue resolved.

Upstream-Tar-Datei

Du kannst die Upstream-Tar-Datei bekommen in dem Du folgenden Befehl ausführst:

bzr get-orig-source

This will try a number of methods to get the upstream tar, firstly by recreating it from the upstream-x.y tag in the bzr archive, then by downloading from the Ubuntu archive, lastly by running debian/rules get-orig-source. The upstream tar will also be recreated when using bzr to build the package:

bzr builddeb

The builddeb plugin has several configuration options.

Einen Zweig fuer ein bestimmtes Release bekommen

When you want to do something like a stable release update (SRU), or you just want to examine the code in an old release, you’ll want to grab the branch corresponding to a particular Ubuntu release. For example, to get the Tomboy package for Quantal do:

$ bzr branch ubuntu:m/tomboy quantal
Ein Debian Quellpaket importieren

If the package you want to work on is available in Debian but not Ubuntu, it’s still easy to import the code to a local bzr branch for development. Let’s say you want to import the newpackage source package. We’ll start by creating a shared repository as normal, but we also have to create a working tree to which the source package will be imported (remember to cd out of the tomboy directory created above):

$ bzr init-repo newpackage
$ cd newpackage
$ bzr init debian
$ cd debian
$ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc

As you can see, we just need to provide the remote location of the dsc file, and Bazaar will do the rest. You’ve now got a Bazaar source branch.

An einem Paket arbeiten

Once you have the source package branch in a shared repository, you’ll want to create additional branches for the fixes or other work you plan to do. You’ll want to base your branch off the package source branch for the distro release that you plan to upload to. Usually this is the current development release, but it may be older releases if you’re backporting to an SRU for example.

Einen Zweig fuer eine Änderung erstellen

Das erste, was Du sicherstellen solltest, ist, ob das Quellpaket aktuell ist. Das wird so sein, wenn Du es gerade ausgecheckt hast, ansonsten:

$ cd tomboy.dev
$ bzr pull

Alle Aktualisierungen die das Paket vor Deinem Checkout erhalten hat, werden jetzt heruntergeladen. Es ist am Besten an diesem Branch keine Änderungen vorzunehmen. Stattdessen lohnt es sich einen neuen Branch anzulegen, der nur die Änderungen enthalten wird, die Du vornehmen möchtest. Zum Beispiel könntest Du Bug 12345 des Tomboy-Projekts beheben wollen. Wenn Du im Shared Repository bist, das Du vorher angelegt hast, kannst Du einen Bugfix-Branch folgendermaßen anlegen:

$ bzr branch tomboy.dev bug-12345
$ cd bug-12345

Jetzt kannst Du alle Arbeit im Verzeichnis bug-12345 erledigen. Du kannst dort alle nötigen Änderungen vornehmen und währenddessen committen. Es ist nicht anders als jede andere Software-Entwicklung mit Bazaar. Man kann committen so oft man möchte und wenn die Änderungen fertig sind, benutzt man einfach dch (aus dem Paket devscripts):

$ dch -i

Dies wird einen Editor öffnen um einen Eintrag in debian/changelog hinzuzufügen.

tomboy (1.12.0-1ubuntu3) trusty; urgency=low

  * Don't fubar the frobnicator. (LP: #12345)

 -- Bob Dobbs <subgenius@example.com>  Mon, 10 Sep 2013 16:10:01 -0500

Einreichen mit normal:

bzr commit

Ein Hook in bzr-builddeb wird den Eintrag aus debian/changelog in der Commit-Nachricht verwenden und ein Tag setzen, um Bug #12345 als behoben zu markieren.

Das funktioniert nur mit ‘bzr-builddeb 2.7.5’ und ‘bzr 2.4’, verwende debcommit für ältere Versionen.

Das Paket bauen

Währenddessen wirst deinen eigenen Zweig erstellen wollen, sodass du auch sicher gehen kannst, dass der Fehler auch behoben wurde.

Um das Paket zu bauen kann man das Kommando bzr builddeb (aus dem Paket bzr-builddeb) verwenden. Du kannst das Quellpaket folgendermaßen bauen:

$ bzr builddeb -S

(bd ist ein Alias für builddeb.) Du kannst das Paket unsigniert lassen, in dem Du -- -us -uc an das Kommando anhängst.

Es ist außerdem möglich, Deine normalen Werkzeuge zu verwenden, so lange sie nur das .bzr Verzeichnis aus dem resultierenden Paket entfernen können.

$ debuild -i -I

Falls jemals eine Fehlermeldung bezüglich dem Erstellen eines nativen Paketes ohne einen Tarball auftritt, überprüfe ob eine Datei mit dem Namen .bzr-builddeb/default.conf das Paket irrtümlich als nativ einstuft. Wenn die Version im Änderungsprotokoll einen Bindestrich enthält, dann ist es kein natives Paket und du kannst die Konfigurationsdatei entfernen. Merke dass obwohl bzr builddeb eine Option --native besitzt, ist keine Option --no-native vorhanden.

Wenn Du das Quellpaket heruntergeladen hast, kannst Du es ganz normal mit pbuilder-dist (oder pbuilder oder sbuilt) bauen.

Sponsoring und Nachprüfung finden

One of the biggest advantages to using the UDD workflow is to improve quality by seeking review of changes by your peers. This is true whether or not you have upload rights yourself. Of course, if you don’t have upload rights, you will need to seek sponsorship.

Once you are happy with your fix, and have a branch ready to go, the following steps can be used to publish your branch on Launchpad, link it to the bug issue, and create a merge proposal for others to review, and sponsors to upload.

Zu Launchpad hochladen

We previously showed you how to associate your branch to the bug using dch and bzr commit. However, the branch and bug don’t actually get linked until you push the branch to Launchpad.

It is not critical to have a link to a bug for every change you make, but if you are fixing reported bugs then linking to them will be useful.

Die allgemeine Form der URL, zu der Du Deinen Branch hochlädst ist:

lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>

For example, to push your fix for bug 12345 in the Tomboy package for Trusty, you’d use:

$ bzr push lp:~subgenius/ubuntu/trusty/tomboy/bug-12345

Die letzte Komponente des Pfades ist frei wählbar, am besten entscheidest Du Dich für etwas dass Deine Änderung am treffendsten beschreibt.

However, this usually isn’t enough to get Ubuntu developers to review and sponsor your change. You should next submit a merge proposal.

Um dies zu tun, öffne den Bug-Report in Deinem Browser, z.B.:

$ bzr lp-open

Sollte dies fehlschlagen, dann benutze:

$ xdg-open https://code.launchpad.net/~subgenius/ubuntu/trusty/tomboy/bug-12345

where most of the URL matches what you used for bzr push. On this page, you’ll see a link that says Propose for merging into another branch. Type in an explanation of your change in the Initial Comment box. Lastly, click Propose Merge to complete the process.

Merge proposals to package source branches will automatically subscribe the ~ubuntu-branches team, which should be enough to reach an Ubuntu developer who can review and sponsor your package change.

Ein Debdiff erzeugen

As noted above, some sponsors still prefer reviewing a debdiff attached to bug reports instead of a merge proposal. If you’re requested to include a debdiff, you can generate one like this (from inside your bug-12345 branch):

$ bzr diff -rbranch:../tomboy.dev

Ein weiterer Weg dies zu tun ist den Merge-Vorschlag im Browser zu öffnen und das Diff herunterzuladen.

You should ensure that diff has the changes you expect, no more and no less. Name the diff appropriately, e.g. foobar-12345.debdiff and attach it to the bug report.

Umgang mit Feedback der Sponsoren

If a sponsor reviews your branch and asks you to change something, you can do this fairly easily. Simply go to the branch that you were working in before, make the changes requested, and then commit:

$ bzr commit

Wenn Du Deinen Branch nach Launchpad hochlädst, wird sich Bazaar merken wohin und der Branch in Launchpad wird aktualisiert mit Deinen letzten Commits. Alles was Du tun musst, ist:

$ bzr push

You can then reply to the merge proposal review email explaining what you changed, and asking for re-review, or you can reply on the merge proposal page in Launchpad.

Note that if you are sponsored via a debdiff attached to a bug report you need to manually update by generating a new diff and attaching that to the bug report.

Erwartungen

The Ubuntu developers have set up a schedule of “patch pilots”, who regularly review the sponsoring queue and give feedback on branches and patches. Even though this measure has been put in place it might still take several days until you hear back. This depends on how busy everybody is, if the development release is currently frozen, or other factors.

Wenn Du eine Weile nichts mehr gehört hast, schaue einfach in #ubuntu-devel auf irc.freenode.net ob Dir jemand dort helfen kann.

Weitere Informationen über den allgemeinen Prozess für Sponsoring, sind auf https://wiki.ubuntu.com/SponsorshipProcess verfügbar.

Ein Paket hochladen

Ist der Vorschlag zum Merge erst einmal gesichtet und bestätigt, kann das Paket in das Archiv (falls du die benötigten Berechtigungen besitzt) oder in eigenes Personal Package Archive (PPA) hochgeladen werden. Sponsoren laden gerne auch selbst die Pakete hoch, deren Änderungen sie finanziert haben.

Eine eigene Änderung hochladen

Wenn du einen Branch mit einer Änderung hast, die Du hochladen möchtest, musst Du die Änderung in den Haupt-Branch integrieren, ein Quellpaket bauen und es hochladen.

Zuerst musst Du prüfen, ob Du die neueste Version des Pakets in Deinem Checkout des Entwicklungszweiges hast.

$ cd tomboy/tomboy.dev
$ bzr pull

This pulls in any changes that may have been committed while you were working on your fix. From here, you have several options. If the changes on the trunk are large and you feel should be tested along with your change you can merge them into your bug fix branch and test there. If not, then you can carry on merging your bug fix branch into the development trunk branch. As of bzr 2.5 and bzr-builddeb 2.8.1, this works with just the standard merge command:

$ bzr merge ../bug-12345

Für ältere Versionen von bzr kannst Du das merge-package Kommando verwenden.

$ bzr merge-package ../bug-12345

Dies wird zwei Zweige mergen, dabei können Merge-Konflikte auftreten, die man manuell auflösen muss.

Als nächstes solltest Du sicherstellen, dass debian/changelog wie gewünscht aussieht, mit der richtigen Distribution, Versionsnummer und so weiter.

Ist das einmal gemacht, solltest du die zu commitende Änderung mit bzr diff überprüfen. Das sollte dieselben Unterschiede anzeigen wie debdiff bevor ein Quellpaket hochgeladen wird.

Im nächsten Schritt baut und testet man das modifizierte Paket, genau wie sonst auch:

$ bzr builddeb -S

When you’re finally happy with your branch, make sure you’ve committed all your changes, then tag the branch with the changelog’s version number. The bzr tag command will do this for you automatically when given no arguments:

$ bzr tag

Dieser Tag signalisiert dem Paketimporter, dass der Bazaar-Zweig denselben Inhalt hat wie das Archiv.

Jetzt kann man die Änderungen zurück nach Launchpad hochladen:

$ bzr push ubuntu:tomboy

(Ändere die Zieldistribution, falls Du einen SRU oder ähnliches hochlädst.)

You need one last step to get your changes uploaded into Ubuntu or your PPA; you need to dput the source package to the appropriate location. For example, if you want to upload your changes to your PPA, you’d do:

$ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes

oder, wenn Du die Uploadrechte für das Primärachiv hast:

$ dput tomboy_1.5.2-1ubuntu5_source.changes

Jetzt kannst Du den Feature-Branch löschen. Er ist bereits gemerged, kann also von Launchpad heruntergeladen werden, wenn nötig.

Eine Änderung sponsorn

Sponsoring someone else’s change is just like the above procedure, but instead of merging from a branch you created, you merge from the branch in the merge proposal:

$ bzr merge lp:~subgenius/ubuntu/trusty/tomboy/bug-12345

Sollte es Merge-Konflikte geben, wirst Du den Autoren der Änderung wahrscheinlich bitten, diese zu lösen. Im nächsten Abschnitt wird beschrieben, wie man einen bevorstehenden Merge abbricht.

But if the changes look good, commit and then follow the rest of the uploading process:

$ bzr commit --author "Bob Dobbs <subgenius@example.com>"

Einen Upload abbrechen

At any time before you dput the source package you can decide to cancel an upload and revert the changes:

$ bzr revert

You can do this if you notice something needs more work, or if you would like to ask the contributor to fix up conflicts when sponsoring something.

Etwas sponsoren und eigene Änderungen beifügen

If you are going to sponsor someone’s work, but you would like to roll it up with some changes of your own then you can merge their work in to a separate branch first.

If you already have a branch where you are working on the package and you would like to include their changes, then simply run the bzr merge from that branch, instead of the checkout of the development package. You can then make the changes and commit, and then carry on with your changes to the package.

If you don’t have an existing branch, but you know you would like to make changes based on what the contributor provides then you should start by grabbing their branch:

$ bzr branch lp:~subgenius/ubuntu/trusty/tomboy/bug-12345

then work in this new branch, and then merge it in to the main one and upload as if it was your own work. The contributor will still be mentioned in the changelog, and Bazaar will correctly attribute the changes they made to them.

Auf dem Laufenden bleiben

Falls bereits jemand anderes Änderungen an einem Paket vorgenommen hat, wirst du sie in deine eigenen Kopien des Pakets einbinden wollen.

Hauptzweig aktualisieren

Das Aktualisieren deiner Kopie des Zweiges, welcher zu dem Paket in der jeweiligen Veröffentlichung gehört, ist sehr einfach. Verwende lediglich bzr pull aus dem entsprechendem Verzeichnis heraus:

$ cd tomboy/tomboy.dev
$ bzr pull

This works wherever you have a checkout of a branch, so it will work for things like branches of saucy, trusty-proposed, etc.

Arbeitszweige aktualisieren

Once you have updated your copy of a distroseries branch, then you may want to merge this in to your working branches as well, so that they are based on the latest code.

You don’t have to do this all the time though. You can work on slightly older code with no problems. The disadvantage would come if you were working on some code that someone else changed. If you are not working on the latest version then your changes may not be correct, and may even produce conflicts.

The merge does have to be done at some point though. The longer it is left, the harder may be, so doing it regularly should keep each merge simple. Even if there are many merges the total effort would hopefully be less.

To merge the changes you just need to use bzr merge, but you must have committed your current work first:

$ cd tomboy/bug-12345
$ bzr merge ../tomboy.dev

Any conflicts will be reported, and you can fix them up. To review the changes that you just merged use bzr diff. To undo the merge use bzr revert. Once you are happy with the changes then use bzr commit.

Sich auf Versionen eines Paketes beziehen

You will often think in terms of versions of a package, rather than the underlying Bazaar revision numbers. bzr-builddeb provides a revision specifier that makes this convenient. Any command that takes a -r argument to specify a revision or revision range will work with this specifier, e.g. bzr log, bzr diff, and so on. To view the versions of a package, use the package: specifier:

$ bzr diff -r package:0.1-1..package:0.1-2

Das zeigt den Unterschied zwischen den Paketversionen 0.1-1 und 0.1-2.

Merging — Von Debian und dem Upstream aktualisieren

Merging is one of the strengths of Bazaar, and something we do often in Ubuntu development. Updates can be merged from Debian, from a new upstream release, and from other Ubuntu developers. Doing it in Bazaar is pretty simple, and all based around the bzr merge command [1].

While you are in any branch’s working directory, you can merge in a branch from a different location. First check that you have no uncommitted changes:

$ bzr status

Wenn ein Bericht auftritt, musst du entweder die Änderungen comitten, rückgängig machen oder zurückstellen um später darauf zurückzukommen.

Von Debian mergen

Next run bzr merge passing the URL of the branch to merge from. For example, to merge from the version of the package in Debian Unstable run [2]:

$ bzr merge lp:debian/tomboy

This will merge the changes since the last merge point and leave you with changes to review. This may cause some conflicts. You can see everything that the merge command did by running:

$ bzr status
$ bzr diff

If conflicts are reported then you need to edit those files to make them look how they should, removing the conflict markers. Once you have done this, run:

$ bzr resolve
$ bzr conflicts

This will resolve any conflicted files that you fixed, and then tell you what else you have to deal with.

Once any conflicts are resolved, and you have made any other changes that you need, you will add a new changelog entry, and commit:

$ dch -i
$ bzr commit

wie zuvor beschrieben.

However, before you commit, it is always a good thing to check all the Ubuntu changes by running:

$ bzr diff -r tag:0.6.10-5

which will show the differences between the Debian (0.6.10-5) and Ubuntu versions (0.6.10-5ubuntu1). In similar way you can compare to any other versions. To see all available versions run:

$ bzr tags

After testing and committing the merge, you will need to seek sponsorship or upload to the archive in the normal way.

If you are going to build the source package from this merged branch, you would use the -S option to the bd command. One other thing you’ll want to consider is also using the --package-merge option. This will add the appropriate -v and -sa options to the source package so that all the changelog entries since the last Ubuntu change will be included in your _source.changes file. For example:

$ bzr builddeb -S --package-merge

Merging a new upstream version

When upstream releases a new version (or you want to package a snapshot), you have to merge a tarball into your branch.

This is done using the bzr merge-upstream command. If your package has a valid debian/watch file, from inside the branch that you want to merge to, just type this:

$ bzr merge-upstream

This will download the tarball and merge it into your branch, automatically adding a debian/changelog entry for you. bzr-builddeb looks at the debian/watch file for the upstream tarball location.

If you do not have a debian/watch file, you’ll need to specify the location of the upstream tarball, and the version manually:

$ bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz

The --version option is used to specify the upstream version that is being merged in, as the command isn’t able to infer that (yet).

The last parameter is the location of the tarball that you are upgrading to; this can either be a local filesystem path, or a http, ftp, sftp, etc. URI as shown. The command will automatically download the tarball for you. The tarball will be renamed appropriately and, if required, converted to .gz.

The merge-upstream command will either tell you that it completed successfully, or that there were conflicts. Either way you will be able to review the changes before committing as normal.

If you are merging an upstream release into an existing Bazaar branch that has not previously used the UDD layout, bzr merge-upstream will fail with an error that the tag for the previous upstream version is not available; the merge can’t be completed without knowing what base version to merge against. To work around this, create a tag in your existing repository for the last upstream version present there; e.g., if the last Ubuntu release was 1.1-0ubuntu3, create the tag upstream-1.1 pointing to the bzr revision you want to use as the tip of the upstream branch.

[1]You will need newer versions of bzr and the bzr-builddeb for the merge command to work. Use the versions from Ubuntu 12.04 (Precise) or the development versions from the bzr PPA. Specifically, you need bzr version 2.5 beta 5 or newer, and bzr-builddeb version 2.8.1 or newer. For older versions, use the bzr merge-package command instead.
[2]To check other available branches of a package in Debian, see package code page. E.g. https://code.launchpad.net/debian/+source/tomboy

Chroots benutzen

Wenn Du eine Version von Ubuntu benutzt, aber an Paketen für andere Versionen arbeitest, kannst Du eine Umgebung dieser Version mit einer Chroot erzeugen.

Eine Chroot erlaubt dir ein Dateisystem einer anderen Distribution zu haben in dem man nahezu normal arbeiten kann. Dadurch vermeidet man den Overhead des Laufens einer vollen virtuellen Maschine.

Eine Chroot-Umgebung anlegen

Benutze das Kommando debootstrap um eine neue Chroot zu erzeugen:

$ sudo debootstrap trusty trusty/

This will create a directory trusty and install a minimal trusty system into it.

If your version of debootstrap does not know about Trusty you can try upgrading to the version in backports.

Du kannst dann in der Chroot arbeiten:

$ sudo chroot trusty

Wo Du alle Pakete installieren oder löschen kannst ohne Dein Hauptsystem zu berühren.

Vielleicht möchtest Du auch deine GPG/ssh-Schlüssel und Bazaarkonfiguration in das Chroot kopieren, um so einfacher auf Pakete zugreifen zu und sie signieren zu können:

$ sudo mkdir trusty/home/<username>
$ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar trusty/home/<username>

Damit apt und andere Programme sich nicht mehr über fehlende Locales beschweren, kann man die relevanten Language Packs installieren:

$ apt-get install language-pack-en

Um X-Window Programme in der Chroot Umgebung nutzen zu können, muss das /tmp Verzeichnis in die Umgebung gebunden werden. Dies geht außerhalb des Chroot mit folgendem Kommando:

$ sudo mount -t none -o bind /tmp trusty/tmp
$ xhost +

Für einige Programme kann es nötig sein die Verzeichnisse /dev und /proc in das Chroot zu binden.

Für weitere Informationen über Chroots siehe unsere Debootstrap Chroot wiki page.

Alternativen

SBuild ist ähnlich wie PBuilder ein System zurErstellung von Umgebungen, in denen die Paketerzeugung getestet werden kann. Es ist näher an der von Lauchpad verwendeten Umgebung zur Paketerzeugung, erfordert aber im Vergleich zu PBuilder etwas mehr Konfigurationsaufwand. Für eine detaillierte Erklärung siehe the Security Team Build Environment wiki page.

Für das Paketieren und Testen von Programmen können vollständige virtuelle Maschinen nützlich sein. TestDrive ist ein Programm, mit dem die Synchronisation und das Ausführen von täglich erzeugten ISO Abbildern automatisiert werden kann, für weitere Informationen siehe the TestDrive wiki page.

Du kannst pbuilder auch so konfigurieren, dass er anhält, wenn er ein Problem findet. Kopiere C10shell von /usr/share/doc/pbuilder/examples in ein Verzeichnis und benutze das --hookdir= Argument um darauf zu verweisen.

Mit Amazon’s EC2 cloud computers kann man einen Rechner für einige cent pro Stunde mieten. Hier kannst Du Ubuntu Maschinen mit jeglicher unterstützen Version installieren und darauf Pakete erstellen. Gemietete Rechenleistung kann besonders nützlich sein um Bandbreitenprobleme zu umgehen wenn Du viele Pakete parallel übersetzen möchtest.

Traditional Packaging

Der Großteil dieses Leitfadens beschäftigt sich mit verteilter Ubuntu Entwicklung (UDD), die das verteilte Versionsverwaltungssystem (DVCS) Bazaar verwendet, um Paketquellen abzurufen und Fehlerbehebungen mit Zusammenführungsvorschlägen einzureichen. Dieser Artikel diskutiert, was wir aus Mangel eines besseren Wortes traditionelle Paketierung nennen. Vor der Einführung von Bazaar für die Ubuntu Entwicklung waren das typische Methoden, um zu Ubuntu beizutragen.

In einigen Fällen wird es nötig sein, diese Hilfsmittel an Stelle von UDD zu benutzen. Daher solltest du dich vorher mit ihnen vertraut machen. Bevor du beginnst, solltest du den Artikel :doc:’Getting Set Up. <./getting-set-up>’ bereits gelesen haben.

Den Quelltext bekommen

Um das Quellpaket zu bekommen, kannst du folgendes benutzen:

$ apt-get source <package_name>

Diese Methode hat allerdings einige Nachteile. Sie lädt die Version von der auf deinem System verfügbaren Quelle. Voraussichtlich läuft bei dir die letzte stabile Veröffentlichung, aber du möchtest deine Änderungen, unabhängig der Entwicklerveröffentlichung, berücksichtigt haben. Für diesen Fall bietet das “ubuntu-dev-tools” Paket ein Helferskript:

$ pull-lp-source <package_name>

Grundsätzlich wird die letzte Entwicklerversion heruntergeladen. Du kannst ebenso eine spezifische Ubuntu Veröffentlichung wählen:

$ pull-lp-source <package_name> trusty

to pull the source from the trusty release, or:

$ pull-lp-source <package_name> 1.0-1ubuntu1

um die Version “1.0-1 ubuntu1” des Pakets herunterzuladen. Für weitere Informationen zu den Befehlen schau unter “man pull-lp-source” nach.

Nehmen wir beispielsweise an, wir hätten einen Fehlerbericht, der meldet, dass die Schreibweise von “colour” in der “xicc”-Beschreibung “color” lauten sollte.

$ pull-lp-source xicc 0.2-3

Einen Debdiff erstellen

Ein “debdiff” zeigt die Unterschiede zwischen zwei Debian-Paketen. Der dafür notwendige Befehl heißt ebenfalls “debdiff”. Er ist Teil des “devscripts”-Paketes. Für alle Details schau unter “man debdiff” nach. Um zwei Quellpakete zu vergleichen, gib ihre “dsc”-Datein als Bedingungen an:

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

Um mit unserem Beispiel fortzufahren, lasst uns die”debian/control” bearbeiten und unseren ‘Fehler beheben’:

$ cd xicc-0.2
$ sed -i 's/colour/color/g' debian/control

Wir müssen uns also an die ‘Debian Maintainer Spec <https://wiki.ubuntu.com/DebianMaintainerField>’ halten und zum Ersetzen die “debian/control” verändern:

Maintainer: Ross Burton <ross@debian.org>

mit:

Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Ross Burton <ross@debian.org>

Du kannst dafür das “update-maintainer”-Werkzeug aus dem “ubuntu-dev-tools”-Paket benutzen.

Denk daran, deine Änderungen in “debian/changelog” mit Hilfe von “dch -i” zu dokumentieren. Dann können wir ein neues Quellpaket erstellen:

$ debuild -S

Nun können wir unsere Änderungen mit “debdiff” untersuchen:

$ cd ..
$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc | less

Um eine Patch-Datei zu erstellen, die du an andere verschicken, oder zur Unterstützung an einen Fehlerbericht anhängen kannst, benutze:

$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc > xicc_0.2-3ubuntu1.debdiff

Einen Debdiff anwenden

Um den “debdiff”-Befehl anzuwenden, stelle zuerst sicher, dass du den Quellcode der Version hast, gegen deren Fehler du die Änderung erstellt hast:

$ pull-lp-source xicc 0.2-3

Wechsele in einer Konsole zu dem Verzeichnis, in dem die Quelldatei unkomprimiert liegt:

$ cd xicc-0.2

Ein “debdiff” ist wie eine normale Patch-Datei. Wende sie wie gewohnt an mit:

$ patch -p1 < ../xicc_0.2.2ubuntu1.debdiff

Pakete für Python-Module und -Anwendungen erstellen

Our packaging follows Debian’s Python policy. We will use the python-markdown package as an example, which can be downloaded from PyPI. You can look at its packaging at its Subversion repository.

Es gibt zwei Arten von Python Paketen — Module und Anwendungen

At the time of writing, Ubuntu has two incompatible versions of Python — 2.x and 3.x. /usr/bin/python is a symbolic link to a default Python 2.x version, and /usr/bin/python3 — to a default Python 3.x version. Python modules should be built against all supported Python versions.

If you are going to package a new Python module, you might find the py2dsc tool useful (available in python-stdeb package).

debian/control

Python 2.x and 3.x versions of the package should be in separate binary packages. Names should have python{,3}-modulename format (like: python3-dbus.mainloop.qt). Here, we will use python-markdown and python3-markdown for module packages and python-markdown-doc for the documentation package.

Einträge in debian/control die sich ausschließlich auf Python-Pakete beziehen:

  • Der “section”-Eintrag der Modul-Pakete sollte python und doc für das Dokumentationspaket sein. Für eine Anwendung ist ein Paket mit nur einem Binärpaket ausreichend.

  • Wir sollten Build-Abhängigkeiten auf python-all (>= 2.6.6-3~) und python3-all (>= 3.1.2-7~) hinzufügen, um sicherzustellen, dass die Python-Hilfswerkzeuge verfügbar sind (der nächste Abschnitt hat hierzu mehr Informationen).

  • Es wird empfohlen X-Python-Version und X-Python3-Version Einträge hinzuzufügen — siehe Abschnitt “Specifying Supported Versions” der Policy für weitere Details. Zum Beispiel:

    X-Python-Version: >= 2.6
    X-Python3-Version: >= 3.1

    Sollte Dein Paket nur mit Python 2.x oder 3.x funktionieren, die Build-Abhängigkeit auf nur eines der -all Pakete wird ausreichen, ebenso reicht einer der -Version-Einträge.

  • Modulpakete sollten die Substitutionsvariablen {python:Depends} und respektive {python3:Depends} in ihren Abhängigkeitslisten haben.

debian/rules

Die empfohlenen Hilfsprogramme für Pythonmodule sind dh_python2 und dh_python3. Unglücklicherweise baut debhelper noch keine Python 3.x Pakete automatisch (siehe bug 597105 im Debian BTS), also werden wir manuell in den “override” Abschnitten tun müssen (überspringe dies, wenn Dein Paket nicht Python 3.x unterstützt).

Hier ist unsere debian/rules Datei (mit Anmerkungen):

# These commands build the list of supported Python 3 versions
# The last version should be just “python3” so that the scripts
# get a correct shebang.
# Use just “PYTHON3 := $(shell py3versions -r)” if your package
# doesn’t contain scripts
PY3REQUESTED := $(shell py3versions -r)
PY3DEFAULT := $(shell py3versions -d)
PYTHON3 := $(filter-out $(PY3DEFAULT),$(PY3REQUESTED)) python3

%:
    # Adding the required helpers
    dh $@ --with python2,python3

override_dh_auto_clean:
    dh_auto_clean
    rm -rf build/

override_dh_auto_build:
    # Build for each Python 3 version
    set -ex; for python in $(PYTHON3); do \
        $$python setup.py build; \
    done
    dh_auto_build

override_dh_auto_install:
    # The same for install; note the --install-layout=deb option
    set -ex; for python in $(PYTHON3); do \
        $$python setup.py install --install-layout=deb --root=debian/tmp; \
    done
    dh_auto_install

It is also a good practice to run tests during the build, if they are shipped by upstream. Usually tests can be invoked using setup.py test or setup.py check.

debian/*.install

Python 2.x modules are installed into /usr/share/pyshared/ directory, and symbolic links are created in /usr/lib/python2.x/dist-packages/ for every interpreter version, while Python 3.x ones are all installed into /usr/lib/python3/dist-packages/.

If your package is an application and has private Python modules, they should be installed in /usr/share/module, or /usr/lib/module if the modules are architecture-dependent (e.g. extensions) (see “Programs Shipping Private Modules” section of the Policy).

So, our python-markdown.install file will look like this (we’ll also want to install a markdown_py executable):

usr/lib/python2.*/
usr/bin/

und python3-markdown.install wird nur eine Zeile haben:

usr/lib/python3/

Das -doc Paket

The tool most commonly used for building Python docs is Sphinx. To add Sphinx documentation to your package (using dh_sphinxdoc helper), you should:

  • Füge eine Build-Abhängigkeit auf python-sphinx oder python3-sphinx hinzu (je nachdem, welche Python-Version Du verwendest);
  • Hänge sphinxdoc an die Zeile mit dh --with an;
  • Lass setup.py build_sphinx in override_dh_auto_build laufen (wird manchmal jedoch nicht benötigt);
  • Trag {sphinxdoc:Depends} in die Liste der Abhängigkeiten des -doc Pakets ein;
  • Add the path of the built docs directory (usually build/sphinx/html) to your .docs file.

In our case, the docs are automatically built in build/docs/ directory when we run setup.py build, so we can simply put this in the python-markdown-doc.docs file:

build/docs/

Because docs also contain source .txt files, we’ll also tell dh_compress to not compress them — by adding this to debian/rules:

override_dh_compress:
    dh_compress -X.txt

Auf Paketierungsfehler prüfen

Along with lintian, there is a special tool for checking Python packages — lintian4py. It is available in the lintian4python package. For example, these two commands invoke both versions of lintian and check source and binary packages:

lintian -EI --pedantic *.dsc *.deb
lintian4py -EI --pedantic *.dsc *.deb

Here, -EI option is used to enable experimental and informational tags.

Siehe auch

KDE Paketierung

Das Paketieren von KDE-Programmen in Ubuntu wird von den Kubuntu- und MOTU-Teams übernommen. Du kannst das Kubuntu-Team über die Kubuntu-Mailingliste und den IRC-Kanal #kubuntu-devel auf Freenode kontaktieren. Weitere Information über die Kubuntu-Entwicklung findest du auf der Kubuntu-Wiki-Seite.

Unsere Paketierung folgt den Richtlinien des Debian Qt/KDE Team`_ und Debian KDE Extras Team. Die meisten unserer Pakete sind von denen dieser Debian-Teams abgeleitet.

Richtlinien für Fehlerkorrekturen

Kubuntu führt keine Fehlerkorrekturen an KDE-Programmen durch solange sie nicht von Upstream-Autoren oder dortigen Einreichungen stammen, mit der Absicht sie bald in das Programm einfließen zu lassen, oder das Problem mit den Upstream-Autoren abgesprochen wurde.

Kubuntu ändert keine Paketbezeichnungen mit Ausnahme dort, wo Upstream dies erwartet (wie das Logo des Kickoff-Menüs links oben) oder es der Vereinfachung dient (wie der Entfernung des Begrüßungsbildschirms).

debian/rules

Debian-Pakete verwenden Zusätze zur herkömmlichen Debhelper-Verwendung. Diese sind im Paket pkg-kde-tools` enthalten.

Pakete, welche Debhelper 7 verwenden, sollten die Option --with=kde anhängen. Dies stellt sicher, dass die richtigen Flags zum Bauen benutzt werden und Optionen zum Umgang mit kdeinit-Stubs and Übersetzungen hinzugefügt werden:

%:
    dh $@ --with=kde

Einige neuere KDE-Packete verwenden das dhmk-System, eine alternative zu dh, welches von dem Debian Qt/KDE-Team entwickelt wurde. Sie können sich darüber in /usr/share/pkg-kde-tools/qt-kde-team/2/README informieren. Pakete die dieses benutzen, werden /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk enthalten anstelle des Ausführens von dh.

Übersetzungen

Übersetzungen von Paketen in main werden in Launchpad importiert und werden von Launchpad in Ubuntu’s Language-Packs exportiert.

Daher muss jedes KDE-Paket Übersetzungsvorlagen generieren, Upstream-Übersetzungen verwenden oder bereitstellen und Übersetzungen für .desktop-Dateien interpretieren können.

Um Übersetzungsvorlagen zu generieren, muss das Packet eine Message.sh Datei einbinden. Wenn dem nicht so ist, beschwere dich upstream. Ob es funktioniert kannst Du überprüfen, in dem Du extract-messages.sh ausführst, welches eine oder mehrere Dateien namens .pot in po/ erstellen sollte. Dies wird während des Bauens automatisch getan, wenn Du dh``mit der Option ``--width=kde benutzt.

Upstream wird üblicherweise ebenfalls die Übersetzungs- .po-Dateien in das po/ Verzeichnis tun. Wenn sie dies nicht tun, prüft ob sie in separaten Upstream-Sprachpaketen wie beispielsweise der KDE SC Sprachpakete sind. Wenn sie in einzelnen Sprachpaketen sind, muss Launchpad diese gemeinsam manuell assoziieren, bitte kontaktiert dpm_ um dies zu tun.

Wenn ein Paket von universe zu main verschoben wird, muss es erneut hochgeladen werden bevor die Übersetzung in Launchpad importiert wird.

.desktop``Dateien benötigen ebenfalls Übersetzungen. Wir patchen KDELibs, dass die Übersetzungen aus ``.po Dateien geholt werden, auf die durch eine Zeile X-Ubuntu-Gettext-Domain= gezeigt wird und den .desktop``Dateien zur Buildzeit hinzugefügt werden. Eine .pot-Datei für jedes Paket wird während des Builds erzeugt und die .po-Dateien müssen von Upstream heruntergeladen und in das Paket bzw. unsere Sprachpakete gebracht werden. Die Liste von .po-Dateien, die aus KDEs Repositories heruntergeladen werden soll ist in ``/usr/lib/kubuntu-desktop-i18n/desktop-template-list.

Bibliothekssymbole

Librarysymbole werden in .symbole verfolgt um zu versichern, dass keine bei neuen Veröffentlichung fehlen. KDE benutzt C++ Bibliothen, die etwas anders im Vergleich zu C-Bibliotheken agieren. Debians Qt/KDE Team hat Skripts um dieses Problem zu lösen. Beachten Sie Working with symbols files_ wie man diese Dateien erstellt und aktuell hält.

Weiterführende Literatur

Man kann dieses Handbuch auch offline in verschiedenen Formaten lesen, wenn man eins der Binärpakete installiert.

Wenn Du mehr über das Bauen von Debian-Paketen lernen willst, sind hier einige Debian-Resourcen, die Du hilfreich finden könntest.

Wir sind stets darauf bedacht diese Anleitung zu verbessern. Wenn du Probleme haben solltest oder Vorschläge hast, erstelle bitte einen Bericht auf Launchpad. Für den Fall dass du an der Anleitung mitarbeiten willst, hol dir den Code ebenfalls von dort.