Build Service/Tipps und Tricks

aus openSUSE, der freien Wissensdatenbank

Auf dieser Seite finden Sie unsortiert kleine Tipps und Tricks zur Arbeit mit dem Build Service. Die meisten dieser Tipps sollten irgendwann in andere Seiten übernommen und von hier entfernt werden. Zweck dieser Seite ist es, eine erste Anlaufstelle zu schaffen, auf der Informationen eingereicht werden können, welche weiter dokumentiert oder so schnell wie möglich behoben werden sollten.

Die meisten der Informationen sind der buildservice-Mailing-Liste entnommen.

Bau von Pakten deaktivieren

Wir haben vor kurzem eine Möglichkeit eingeführt, einzelne Pakete vom Bau auszuschließen. Ein Weg, Pakete vom Bau auszuschließen ist, den Kommandozeilenklient 'osc' zu nutzen.

	erde@sonne:~> osc meta pkg -e <Projekt> <Paket>

Im Editor müssen Sie dann die <disable>-Markierung zu den Paket-Metadaten hinzufügen Sie können entweder

<disable arch="<build-arch>"/>
 

oder

<disable repository="<name-of-build-repository>"/>

oder beides

<disable repository="SLES_9" arch="x86_64"/>

verwenden. Der andere Weg geht über den Web-Client , wo Sie in der Ansicht des entsprechenden Pakets den passenden Knopf anklicken.

Laufende Bauvorgänge abbrechen

	erde@sonne:~> osc abortbuild <Projekt> <Paket> <Depot> <Architektur>

Expansion-Fehler

Wenn Sie für ein Paket eine Nachricht wie

expansion error have choice for inet-daemon needed by imap: inetd xinetd

erhalten, dann haben Sie zwei Möglichkeiten:

• Die schnelle Lösung ist, eines der obigen Pakete (inetd oder xinetd) zu ihren BuildRequires hinzuzufügen.
• Die dauerhafte Lösung ist, eine E-Mail an die opensuse-buildservice-Mailing-Liste zu senden, in welcher Sie darum bitten, eine der Dateien in die .dsc-Datei des Depots aufzunehmen, so dass andere Pakete mit dem selben Problem automatisch repariert werden.

Bauvorgänge im Build Service gesondert handhaben

Wenn Sie ihre spec-Datei auch noch woanders als im Build Service verwenden und das aus irgendeinem Grund hervorheben müssen, können Sie das Makro %opensuse_bs verwenden.

%if 0%{?opensuse_bs}
# Build Service spezifischer Teil hier
%endif

Bauen von 32Bit-RPMs nur als lokaler Bau

Wenn Sie ein 32Bit-Paket lokal auf einer x86_64-Maschine bauen wollen, versuchen Sie folgendes:

	erde@sonne:~> linux32 build foo.spec

Beachten Sie, dass osc build das für Sie erledigt.

Zugriff-verweigert-Fehler

Wenn ihr Paket lokal ohne Probleme gebaut wird, Sie aber Fehlermeldungen wie

 /usr/bin/install: cannot create regular file `/usr/lib/libfoo.so.0.0`: Permission denied

erhalten, sobald Sie versuchen, dass gleiche Paket im Build Service zu bauen, denken Sie daran, dass der Build Service zur Zeit das Bauen nur in der chroot-Umgebung unterstützt (und ihr Paket scheint im Moment DESTDIR respektive RPM_BUILD_ROOT nicht zu nutzen).

Fügen Sie einfach die Zeile

# norootforbuild

in ihre spec-Datei ein und Sie werden die selben (hässlichen) Fehler in ihrer lokalen Bauumgebung sehen: beheben Sie diese Fehler zuerst, bevor Sie das Paket an den Build Service übermitteln...

_link und _aggregate

Der Unterschied zwischen _link und _aggregate

Um Neubauten von Paketen zu verhindern, die gerade von der Bauumgebung für den Bau anderer Pakete benötigt werden oder gerade gebraucht werden, weil das Projekt einen kompletten Paketsatz an die Endnutzer verteilen will, existiert im Build Service die Fähigkeit _aggregate.

Ein Paket, welches in ein neues Projekt via aggregate "verknüpft" wird, benötigt in diesem neuen Projekt keinen Neubau. Es reicht, dem neuen Projekt die Binärdateien aus dem Originalprojekt zur Verfügung zu stellen.

Hier sind einige Argumente für und wider _link oder _aggregate:

Beispiel eines _link

Erstellen Sie in ihrem Projekt ein neues Paket (der Name kann der selbe wie der des Originalpakets sein - was aber kein Muss ist) und fügen Sie eine Datei wie diese hinzu:

<link project='openSUSE:Factory' package='tse3'/>

Patches gegen verlinkte Pakete

> Heute habe ich versucht, ein Paket aus einem anderen Projekt zu meinem Projekt zu verknüpfen, was
> kein Problem war. Dann habe ich das neue Paket mit osc ausgechecked, ich fand aber nur
> eine "_link"-Datei im Paketverzeichnis. Wie kann ich nun also bspw. einen Patch hinzufügen
> oder wie kann ich die spec-Datei verändern?

Dateien können zusätzlich auch im verknüpften Projekt sein. Dateien mit gleichem Namen überschreiben Dateien mit gleichem Namen im Originalprojekt. Dies bezieht auch die spec-Datei mit ein. Eine Patch-Datei kann verwendet werden, um Dateien im Originalprojekt zu verändern, ohne Sie zu überschreiben. Der Patch muss dann in der _link-Datei angegeben werden.

<link project='openSUSE:Factory' package='tse3'>
  <patches>
    <apply name="patch" />
  </patches>
</link>

Patches in verlinkte Pakete einfügen

Um einen Patch an eine spec-Datei anzuhängen, müssen Sie entweder einen Patch für die spec-Datei erstellen, der der spec-Datei den Patch hinzufügt, oder Sie nutzen das Kommando <add>:

<link project='openSUSE:Factory' package='tse3'>
  <patches>
    <add name="patch" />
  </patches>
</link>

Dies bindet den Patch oberhalb aller anderen Patches in die .spec-Datei ein und baut Sie mit dem angewendeten Patch.

Beispiel für ein _aggregate

Erstellen Sie in ihrem Projekt ein neues Paket (der Name kann der selbe wie der des Originalpakets sein - was aber kein Muss ist) und fügen Sie eine Datei mit dem unten aufgeführten Inhalt hinzu. Beachten Sie bitte, dass _aggregates in der Regel als schlechter Stil angesehen werden, da das Projekt so doppelten Platz braucht, der Build Service ihren Paketbau aufschieben kann und das Risiko eines inkompatiblen Bruchs ziemlich hoch ist. Normalerweise ist es besser, gegen weitere Paketdepots zu bauen, wie es weiter untern beschrieben wird, um Zugriff auf Pakete von anderen Depots zu erhalten...:

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
  </aggregate>
</aggregatelist>

Wenn die Depotnamen nicht übereinstimmen, können Sie mit dem <repository>-Element eine Zuordnung durchführen:

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
    <repository target="openSUSE_10.2" source="SUSE_10.2" />
  </aggregate>
</aggregatelist>

Mehrere Paketdepots zu einem Projekt hinzufügen

Es ist sehr praktisch, einem Projekt mehrere Paketdepots zuzuweisen, wenn ein Paket von mehr als einem Build Service-Paketdepot abhängt (Requires oder BuildRequires).

	erde@sonne:~> osc meta -e prj <Projektname>

Dies öffnet die Projektmetadaten in einem Editor; fügen Sie einfach den Bauzielen mit <path "projectname"/> weitere Paketdepots hinzu. Beachten Sie bitte, dass es nicht nötig ist, abhängige Paketdepots hinzuzufügen. Das folgende Beispiel fügt nur das Paketdepot des Projekts openSUSE:Tools hinzu. Da dieses aber gegen das Depot openSUSE:10.3/standard baut, werden auch alle Pakete aus diesem Depot mit einbezogen.

 <repository name="openSUSE_10.3">
   <path project="openSUSE:Tools" repository="openSUSE_10.3"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
 </repository>

Ein anderes Beispiel: Fügen Sie das NonFree- und das Update-Depot einem openSUSE:10.2-Projekt hinzu. Das Baisesdepot openSUSE:10.2/standard wird hier nicht benötigt, da beide andere Depots bereits gegen dieses gebaut werden. Beachten Sie bitte, dass das Hinzufügen des :Update-Projekt in der Regel zu der Situation führen kann, dass Nutzer alle Aktualisierungen installiert haben müssen, um keine Probleme zu bekommen, während ein Bau gegen die Basisdistribution für Nutzer mit und ohne Aktualisierungen funktionieren sollte. Die einzige Ausnahme, bei der das :Update-Depot benötigt wird, ist der Bau von Kernel-Modulen (da der Linux-Kernel recht oft inkompatibel wird, während es allen anderen Pakete auf Grund der Richtlinien nicht erlaubt ist, inkompatibel zu werden):

 <repository name="openSUSE_10.2">
   <path project="openSUSE:10.2:Update" repository="standard"/>
   <path project="openSUSE:10.2:NonFree" repository="standard"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
 </repository>

Wie ist eine Bauumgebung definiert?

Sie ist in der Datei /usr/lib/build/configs/$distro.conf im build-Paket definiert. Hier eine Beschreibung der Felder in dieser Datei:

Preinstall: <Pakete>

Die Pakete, welche für das Aufsetzen der Bauumgebung entpackt werden müssen. Dies ist grundsätzlich alles, was zum Betrieb von rpm/dpkg notwendig ist, bspw. die glibc und ähnliches.

Runscripts: <Pakete>

Eine Untermenge der Preinstall-Pakete. Es beschreibt, bei welchen Paketen die Postinstall-Skripte ausgeführt werden müssen.

Required: <Pakete>

Dies sind die Pakete, die die "normale" Bauumgebung ausmachen, also Dinge wie gcc, autoconf, automake und ähnliches.

Support: <Pakete>

Komfortpakete wie "vim" oder "strace". Der Unterschied zu "Required" besteht darin, dass die automatische Neubauerkennung sich Support-Pakete nicht ansieht, so erhalten Sie bspw. keinen automatischen Neubau wenn "strace" geändert wird.

Diese Liste enthält auch einige "-devel"-Pakete und andere Unterpakete von Paketen aus dem "Required"-Feld, um die "Required"-Liste klein zu halten. (Bspw. benötigen wird nicht sowohl "zlib" als auch "zlib-devel" im Required-Feld, da beide aus der gleichen Quelle gebaut werden.)

Dies ist alles wichtige, was es zur Einrichtung der Bauumgebung zu wissen gibt. Ach ja, wir erledigen hier auch die Erweiterung der Abhängigkeiten, so dass Paket die auf Grund von Abhängigkeiten benötigt werden, automatisch zur "Required"-Liste hinzugefügt werden.

So setzt sich die Standardliste wie folgt zusammen

Preinstall + Required + Support + Pakete aus der Erweiterung der Abhängigkeiten

Noch einige Worte zu den anderen Feldern:

Keep: <Pakete>

Wir brauchen solche Pakete. Normalerweise werden Unterpakete des Pakets, welches wir bauen wollen, nicht installiert. Wenn wir aber das "patch"-Paket bauen wollen benötigen wir ein funktionierendes Patch-Programm um Patches aus der spec-Datei anzuwenden. Deshalb haben wir "Keep: patch". Die Paket im Feld "Preinstall" finden sich automatisch in dieser Liste.

Prefer: <Positivpaket>

Prefer: -<Negativpaket>

Diese Informationen werden benötigt, um Zweideutigkeiten zu umgehen.

Ignore: <Paket>:<Paket>

Dies umgeht Abhängigkeiten beim Paketerweiterungsschritt.

Ignore: portmap:syslogd

meint, dass wir keinen installierten syslogd benötigen, wenn wir das portmap-Paket installieren müssen.

Bauen eines Pakets, welches während der Installation einen X-Server benötigt

> Das Paket XXXXXX benötigt zum Bauen einen X-Server (oder
> zumindest ein DISPLAY) (ohne die Konfigurationsdateien
> zu verändern).
>
> Kann ich im Build Service auf einen X-Server zugreifen?
> Welche Änderungen benötige ich in meiner spec-Datei?

Sie können einen Xvfb (starten Sie ihn in ihrer spec-Datei) laufen lassen, um dieses Problem zu umgehen.

Verschiedene spec-Dateien für verschiedene Plattformen verwenden

In einer perfekten Welt würden Sie eine einzige spec-Datei haben, welche auf allen RPM-basierten Plattformen funktioniert, gestern, heute und morgen auch noch. In der Realität ist eine einzelne spec-Datei entweder nicht möglich oder sie brauchen so viel %if-Zweige, dass ihre spec-Datei unlesbar würde.

Erfreulicherweise verfügt der Build Service über einen Weg, auf welchem Sie mehrere spec-Dateien für individuelle Plattformen nutzen können.

Stellen Sie sich vor, Sie hätten ein Paket namens "foo", welches eine spec-Datei namens "foo.spec" enthält. Lassen Sie uns annehmen, dass diese spec-Datei wunderbar für alle SUSE-basierten Distributionen wie openSUSE, SLES und SLED funktioniert, auf Grund von Unterschieden in der Paketausstattung benötigen Sie aber eine separate spec-Datei um das Paket für eine komplett andere Distribution wie Fedora zu bauen. Wenn das Paketdepot im Build Service den Namen "Fedora_Extras_6" trägt, dann können Sie eine spec-Datei namens "foo-Fedora_Extras_6.spec" erstellen, welche nur zum Bau für diese Plattform verwendet wird, an Stelle von "foo.spec".

Der einzige echte Negativpunkt hierbei ist, dass es nur auf einer individuellen Paketdepotbasis funktioniert. Es gibt keinen Weg, eine einzelne spec-Datei für mehrere Depots zu verwenden. Auf das oben genannte Beispiel bezogen heißt das, dass wenn Sie "foo" für Fedora Extras 4, 5 und 6 bauen wollen, Sie drei spec-Dateien erstellen müssen: "foo-Fedora_Extras_4.spec", "foo-Fedora_Extras_5.spec" und "foo-Fedora_Extras_6.spec" auch wenn jede spec-Datei exakt die selbe ist.

Ein gutes Beispielpaket, welches zur Zeit diese Methode verwendet ist das "net-snmp-main-snapshot"-Paket im net-snmp-Projekt.

Deaktivierte aber schon gebaute Pakete aus einem Depot entfernen

Die Web-Schnittstelle unterstützt dies zur Zeit noch nicht. In osc brauchen Sie einfach nur folgendes eingeben:

	erde@sonne:~> osc wipebinaries <Projektname>

Sie können auch direkt mit der buildservice-API "reden", um dieses Problem zu lösen. Wenn Sie alle schon gebauten, aber als deaktiviert markierten RPMs im ganzen Depot entfernenen wollen (in diesem Beispiel: home:foo), versuchen Sie folgendes:

• Erstellen Sie eine ~/.netrc-Datei, die ihre Anmeldeinformationen für build.opensuse.org enthält oder nuten Sie die Option "-u Benutzername:Passwort"

	erde@sonne:~> curl -n -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'

	erde@sonne:~> curl -u Benutzername:Passwort -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'

Weitere "Kommandos" finden Sie in der API-Dokumentation .

In einer Distribution verfügbare Pakete anzeigen lassen

Wenn Sie den exakten Namen eines Pakets, welches Sie für ihren Bau benötigen, nicht kennen, dann können Sie entweder die Web-Suche oder osc ls -b verwenden.

Beispiel: Welches Paket enthält unter Ubuntu die MySQL-Entwicklungsdateien?

Syntax: osc ls -b -r <Paketdepot> -a <Architektur> <Projekt>

	erde@sonne:~> osc ls -b -r standard -a i586 Ubuntu:7.10 | grep 'mysql.*dev' libmysqlclient15-dev_5.0.45-1ubuntu3_i386.deb erde@sonne:~>

Das gesuchte Paket heißt also "libmysqlclient15-dev".

rpmlint-Prüfungen in Build Service-Paketdepots aktivieren

Schauen Sie sich bitte die RpmLint-Seite und dort diesen Abschnitt an.

xxbit-Pakete für andere Architekturen bauen

Der Build Service unterstützt nun die Erstellung von xxbit-Paketen (<Paketname>-32bit, <Paketname>-64bit, <Paketname>-x86) sowie eine paketbasierte Konfiguration über eine Datei namens baselibs.conf. Das folgende ist ein Beispiel für eine solche Datei in ihrem Paketverzeichnis:

tcl
 +/usr/lib(64)?/tcl/.*
 requires -tcl-<Zieltyp>

1. Der Name des Pakets (Sie können auch Unterpakete hinzufügen, falls Sie baselibs für diese benötigen) muss am Anfang einer Zeile stehen. Die würde xxbit-Pakete für dieses Paket herstellen. Alle folgenden Zeilen sollten mit einem Leerzeichen beginnen, um Sie als Zusatz für dieses Paket zu kennzeichnen.
   1. Regex: fügt alle Dateien, die auf den regulären Ausdruck zutreffen, dem xxbit-Paket hinzu
   2. Path -> path(extension): fügt den Dateipfad als path(64) resp. path(32) zum xxbit-Paket hinzu
   3. prereq foo: fügt dem xxbit-Paket "foo" als PreReq hinzu (analog: requires, provides)
   4. targetarch x86_64 block!: kein 32bit-Paket für x86_64 erstellen
   5. targettype x86 package foo: erstelle nur foo-x86 (und nicht foo-32bit) (analog: targettype x86 requires foo, provides, ....)

Unterstützte Makros:

• <extension>
• <name>
• <version>
• <targettype>
• <prefix> ("" oder "/emul/ia32-linux")

Ein anderes Beispiel:

readline-devel
  requires -readline-<targettype>
  requires "libreadline5-<targettype> = <version>"