# 5. 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.

## 5.1. 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.

Sobald du einen Eintrag unter `debian/changelog` eingefügt hast, sollte eine Fehlerkennzeichen vorhanden sein, das deutlich macht welchen Fehler von Launchpad du gerade behebst. Das Format für das Kennzeichen ist stark eingeschränkt: `LP: #12345`. Das Leerzeichen zwischen `:` und dem `#` ist notwendig und natürlich sollte die tatsächliche Fehlernummer verwendet werden. Dein Eintrag unter `debian/changelog` sollte in etwa so aussehen:

    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.

## 5.2. 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.