openSUSE:Build Service Tipps und Tricks

Wechseln zu: Navigation, Suche
Build Service
Paketbau
Hier werden einige unsortierte Tipps und Tricks zur Arbeit mit dem Build Service aufgelistet. Die meisten dieser Tipps sollten in andere Seiten aufgenommen und könnten dann hier gelöscht werden. Die Absicht für die Erstellung dieser Seite besteht darin, einen ersten Ort zu haben, um Informationen zu sammeln, die später genauer dokumentiert werden sollten. Die meisten Informationen werden aus der Build Service Mailingliste gesammelt (Archiv).

Inhaltsverzeichnis

Deaktivierung des Baus von Paketen

Es gibt verschiedene Wege den Bau von einzelnen Paketen zu deaktivieren. Ein Weg ist das Kommandozeilenwerkzeug OSC zu verwenden. Verwenden Sie 

osc api -X POST "/source/PROJECT/PACKAGE?cmd=set_flag&flag=build&status=disable" # und später
osc api -X POST "/source/PROJECT/PACKAGE?cmd=set_flag&flag=build&status=enable" # oder besser
osc api -X POST "/source/PROJECT/PACKAGE?cmd=remove_flag&flag=build"

oder bearbeiten der XML mit 

osc meta pkg -e <project> <package>

und füge das <disable>-Tag innerhalb <build> zu den Metadaten des Paketes hinzu. Sie können auch verwenden: 

<!-- [...] -->
<build>
  <disable arch="<build-arch>"/>
</build>
<!-- [...] -->

oder 

<!-- [...] -->
<build>
  <disable repository="<name-of-build-repository>"/>
</build>
<!-- [...] -->

oder beide, wie: 

<!-- [...] -->
<build>
  <disable repository="SLES_9" arch="x86_64"/>
</build>
<!-- [...] -->

Ein anderer Weg besteht in der Verwendung des Webclient und klicken Sie den geeigneten Knopf bei der Anzeige des entsprechenden Paketes.

Beachte: Jobs, die bereits gestartet wurden, können nicht gestoppt werden. Um diese dauerhaft zu beseitigen, müssen Sie diese im Verzeichnis /srv/obs/jobs/ löschen oder auf Ihrem örtlichen OBS.

Abbruch des laufenden Paketbaus

osc abortbuild <project> <package> <repo> <arch>

Erweiterungsfehler

Wenn Sie so etwas erhalten, wie: 

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

für ein Paket, dann haben Sie zwei Möglichkeiten:

  • Die schnelle Lösung ist, eins der obigen Pakete (inetd oder xinetd) zu Ihrem BuildRequires hinzu zu fügen.
  • Ein anderer Weg zur Fehlerbeseitigung besteht darin, eine Präferenz in Ihrer Projekt config mit 
osc meta -e prjconf <Project>

zu setzen und fügen die Zeile 

Prefer: xinetd

hinzu.

  • Die Langzeitlösung ist es, eine Mail an die openSUSE Build Service Mailingliste zu senden und zu bitten, eine der Dateien zu der .dsc-Datei des Repositorys hinzu zu fügen. So können andere Pakete mit dem gleichen Problem automatisch berichtigt werden.

Pakete in einem Projekt finden

Manchmal würden Sie gerne herausfinden, wie ein Paket bezeichnet ist, speziell in einem Basisprojekt, um es in der Zeile BuildRequires zu verwenden. Es gibt einen schwierigen OSC-Aufruf, um es heraus zu finden.

Dieses Kommando: 

 osc ls -b -r standard -a i586 Fedora:9

listet alle Binärpakete in Fedora 9 auf. Nehmen Sie den Paketnamen aus der Ausgabe.

Lesen Sie 

 osc ls --help

um detailliertere Informationen zu erhalten.

Handhabung des Baus speziell innerhalb des Build Service

Wenn Sie Ihre Spezifikationsdatei an anderen Orten als im Build Service verwenden müssen Sie es gutem Grund kennzeichnen. Sie können dafür das Makro %opensuse_bs verwenden, wie folgt 

%if 0%{?opensuse_bs}
# bs-specific part here
%endif

Bauwerke von 32bit RPMs nur mit örtlichem Bau

Wenn Sie ein 32bit Paket lokal auf einer x84_64 Maschine bauen wollen, versuchen Sie 

linux32 build foo.spec

Beachte, dass osc build das für Sie tut.

Fehler: Erlaubnis verweigert

Wenn Ihr Paket lokal ohne Probleme gebaut wird, aber Sie erhalten eine Fehlermeldung wie: 

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

wenn Sie versuchen, das gleiche Paket im Build Service zu bauen, erinnern Sie sich bitte daran, dass der Build Service momentan nur Bauten in der Chroot-Umgebung unterstützt (und Ihr Paket scheint momentan nicht DESTDIR resp. RPM_BUILD_ROOT zu verwenden).

Fügen Sie nur folgende Zeile in Ihre Spezifikationsdatei: 

# norootforbuild

und Sie werden die gleichen Fehler in Ihrer örtlichen Bau-Umgebung sehen: Beheben Sie diese Fehler zuerst, bevor Sie es beim Build Service einreichen...

_link und _aggregate

Der Unterschied zwischen _link und _aggregate

Um den Neubau von Paketen, die gerade als Baubedarf, für andere Pakete oder weil das Projekt einen kompletten Satz von Paketen für End-Nutzer herausgeben will, benötigt werden, zu vermeiden, gibt es die Funktion _aggregate im Build Service.

Ein Paket, das in einem neuen Projekt via aggregate "verlinkt" ist, wird im neuen Projekt nicht neu gebaut. Die Binärdateien vom Original-Projekt werden im neuen Projekt aktualisiert, wenn immer sie sich ändern.

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

Grund _link _aggregate Kommentar
Keine Quellenänderung wird benötigt.   X Aggregate ist möglich, aber verlangsamt Ihren Bau und benötigt doppelten Speicherplatz. Besser bau direkt gegen das andere Repository.
Ich muss für mein Projekt in den Quellen einige Änderungen vornehmen. X    
Das Original-Paket baut nicht auf allen benötigten Distributionen oder Architekturen. X X Der beste Weg könnte sein, zwei verschiedene Pseudo-Pakete zu haben: eins, das die _aggregate Funktion verwendet, um immer die Binärpakete vom Original-Projekt zu erhalten, und eins, das die -link Funktion verwendet, um die Pakete für den Rest zu bauen. (Aber der einfachste Weg ist, den den Original-Paketbetreuer um die fehlenden Distributionen/Architekturen in seinem Projekt zu bitten.)

Beispiele für Links

Beispiel für einen einfachen _link

Erstellen Sie ein neues Paket in Ihrem Projekt (der Name kann der gleiche wie der des Originalpakets sein - aber das ist nicht wesentlich) und fügen Sie eine Datei ein, die mit _link bezeichnet ist und den Inhalt wie den folgenden besitzt: 

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

Verlinkung gegen eine andere OBS Instanz

Wenn Sie eine lokale OBS-Instanz laufen haben und wollen nur einige Pakete vom offiziellen Build Service oder irgend einer anderen OBS-Instanz mit einem verfügbaren API-Server verlinken, fügen Sie eine _link-Datei wie diese hinzu: 

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

Das wird das Paket tse3 vom Projekt openSUSE:Factory der Build Service Instanz openSUSE.org in Ihr Projekt verlinken.

Für dieses Beispiel hat Ihr Build Service Admin ein leeres Projekt mit der Bezeichnung openSUSE.org in Ihrer lokale Instanz erzeugt, die die Zeile: 
<remoteurl>https://api.opensuse.org/public</remoteurl>
in der Projektdefinition enthält. Keine weitere Administrationsarbeit ist notwendig.

Patche im Vergleich zu verlinkten Paketen

> Heute versuchte ich ein Paket eines anderen Projektes mit 
> meinem Projekt zu verlinken, was kein Problem darstellte. 
> Dann überprüfte ich das neue Paket mit OCS, aber ich fand 
> nur eine _link-Datei im Paketverzeichnis. 
> So, wie kann ich zum Beispiel eine Patch hinzufügen 
> oder die Spezifikationsdatei modifizieren?

Dateien können allein zum verlinkten Projekt hinzugefügt werden. Dateien im verlinkten Projekt ersetzen diese mit dem gleichen Namen im Originalprojekt. Das schließt ebenso die Spezifikationsdatei ein. Eine Patch-Datei kann für Patch-Dateien im Original-Projekt verwendet werden, ohne diese zu überschreiben. Der Patch muss dann in der _link-Datei spezifiziert werden. 

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

Hinzufügen von Patch-Dateien in verlinkten Paketen

Um eine neue Patch-Datei auf eine Quelle anwenden zu können (zusätzlich zu den bereits in der Spezifikationsdatei gelisteten), könnten Sie einen Patch für die Spezifikationsdatei erstellen, die den Patch zur Spezifikationsdatei hinzufügt indem Sie <apply> verwenden. Aber es gibt einen leichteren Weg, indem Sie das <add>-Kommando verwenden: 

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

Das wird 'mybugfix.patch' zur Patch-Liste der Spezifikationsdatei hinzufügen, um es anzuwenden (das funktioniert durch den Build Service, indem die entsprechenden Zeilen für Sie in die Spezifikationsdatei eingefügt werden). Der neue Patch wird angewendet, nachdem alle vorhandenen Patche bereits in der Spezifikationsdatei definiert sind. Natürlich muss 'mybugfix.patch' in Ihrem verlinkten Projekt existieren.

Das Kommando <add> unterstützt die Attribute 'popt="NUMBER"', um ein -pNUMBER Argument zu  %patch hinzu zu fügen, 'dir="some/dir"', um do some/dir zu ändern, vor der Anwendung des Patches und 'after="NUMBER"', um  %patch nach der Zeile mit der Nummer NUMBER hinzu zu fügen.

Eine Zeile zum Kopf der Spezifikationsdatei hinzufügen

Um eine Zeile am Kopf der Spezifikationsdatei hinzu zu fügen (zum Beispiel %define) müssen Sie nicht die Spezifikationsdatei patchen. Stattdessen können Sie <topadd> verwenden: 

<link project="myproject" package="theotherpackage">
  <patches>
    <topadd>%define small_build 1</topadd>
  </patches>
</link>

Um diese Datei zu erhalten, prüfen Sie das Paket mit dem Argument --unexpand-link, wie hier:

osc checkout --unexpand-link someProject somePackage

Danach suchen Sie die Datei, die mit _link bezeichnet ist, bearbeiten die Datei und fügen den oben gezeigten Schnipsel zu der Datei hinzu.

Um zu überprüfen, dass alles erfolgreich funktioniert, überprüfen Sie das Paket an einem anderen Ort und untersuchen den Kopf der Spezifikationsdatei. Sie sollte die Zeile zwischen den Marken <topadd> haben.

Quelle und Deteils: hier

Beispiele für aggregates

Beispiel für ein _aggregate

Erstellen Sie ein neues Paket in Ihrem Projekt (die Bezeichnung kann die gleiche sein wie das Originalpaket - aber das ist nicht wichtig) und fügen eine Datei, die mit _aggregate benannt ist und dem Inhalt wie diesem, hinzu. Bitte beachten Sie, dass _aggregates gewöhnlich als schlechter Stil betrachtet wird, weil das Projekt den doppelten Platz benötigt. Der Build Service könnte Ihren Paketbau verschieben und das Risiko für inkompatible Bruchstellen sind hoch. Gewöhnlich ist es besser gegen weitere Repositorys, wie unter erklärt, zu bauen, um Zugriff auf Paketen von anderen Repositorys zu erhalten..: 

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

Wenn die Repository-Bezeichnungen nicht passen, können Sie ein Mapping mit dem Element <repository> spezifizieren (Quelle ist die Repository-Bezeichnung des Originalpaketes): 

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
    <repository target="openSUSE_11.4" source="SUSE_11.4" />
    <repository target="openSUSE_11.3" source="SUSE_11.3" />
  </aggregate>
</aggregatelist>

Wahl von i686 Paketen auf i586

Wenn Sie ein Paket einer anderen Architektur anstelle von Ihrer Standard-Architektur wollen (glibc i686 auf i586 zum Beispiel), brauchen Sie:

osc meta prjconf <yourproject> -e


und fügen: 

ExportFilter: \.i686\.rpm$ .

zu Ihrer Projekt-config hinzu.

Danach verwenden Sie so etwas wie 

<aggregatelist>
  <aggregate project="openSUSE:Factory">
    <package>glibc.i686</package>
  </aggregate>
</aggregatelist>

um das i686 Paket auf i586 zu bekommen.

Hinzufügen mehrerer Repositorys zu einem Projekt

Mehrere Repositorys zu einem Projekt hinzu zu fügen, ist sehr praktisch, wenn ein Paket von mehr als einem Build Service Repository abhängt (Requires oder BuildRequires). 

 osc meta -e prj <project name>

Das wird den Projekt-Meta-Editor öffnen und mehr Repositorys zu einem Ziel, unter Verwendung von <path "projectname"/> hinzu fügen. Bitte beachten Sie, dass es nicht nötig ist, abhängige Repositorys hinzu zu fügen. Das folgende Beispiel fügt nur ein Repository aus dem Projekt openSUSE:Tools hinzu. Aber dieses Eine baut gegen das openSUSE:12.1/Standard Repository. So dass alle diese Pakete ebenso verwendbar sind. 

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

Anderes Beispiel: Fügen Sie die Repositorys Non-Oss und Update zu einem openSUSE:12.1 Projekt hinzu. Das Basis-Repo openSUSE:12.1/repo/oss wird nicht benötigt, da alle beide ebenso gegen dieses bauen. Bitte beachten Sie, dass das Hinzufügen des :Update-Projekts gewöhnlich zu der Situation führen kann, dass die Benutzer alle Aktualisierungen haben müssen oder sie laufen in Schwierigkeiten hinein. Wenn Sie statt dessen gegen die Basis-Distribution bauen, sollte es für die Benutzer mit und ohne Aktualisierung funktionieren. Die einzige Ausnahme, bei der das Update-Repo benötigt wird, sind Kernelmodule (weil der Linux-Kernel sehr oft inkompatibel wird (während es für alle anderen Pakete, gemäß der Richtlinie, nicht zulässig ist inkompatibel zu werden): 

<repository name="openSUSE_12.1">
   <path project="openSUSE:12.1:Update" repository="standard"/>
   <path project="openSUSE:12.1:Non-Oss" repository="standard"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

Bitte beachten Sie folgendes:

  • Die Reihenfolge der einbezogenen Repositorys ist wichtig: Der Build Servis wird versuchen, ein Paket aus dem ersten Repository zu verwenden, das das Paket enthält, auch wenn die Version nicht passt.
  • Abhängigkeiten werden rekursiv einbezogen
  • Die Benutzer müssen alle Repositorys in ihrem System konfiguriert haben, so das Zypper die Benötigten ( Requires) während der Installationszeit lösen kann. Wenn Sie ungewöhnliche Projekte verwenden, ist es schwer sie richtig zu erraten.

Beispiel:
Projekt A hat 

 <repository name="openSUSE_Factory">
   <path repository="snapshot" project="openSUSE:Factory"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

Sie möchten gegen die Pakete vom Projekt A in Projekt B bauenB:
Entwerder verwenden Sie: 

 <repository name="openSUSE_Factory">
   <path repository="openSUSE_Factory" project="A"/>
   <path repository="snapshot" project="openSUSE:Factory"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

oder (openSUSE:Factory/snapshot ist bereits vom Projekt A einbezogen): 

 <repository name="openSUSE_Factory">
   <path repository="openSUSE_Factory" project="A"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

Wie ist eine Bauumgebung definiert?

Sie ist im Paket build unter /usr/lib/build/configs/$distro.conf definiert. Hier gibt es eine Beschreibung.

Das ist alles, was man über die Einrichtung Bauumgebung wissen muss. Wir machen hier auch Abhängigkeitserweiterungen, wenn Pakete gebraucht werden, so dass Paketabhängigkeiten automatisch zur Liste "Required" hinzu gefügt werden.

Bau eines Paketes, das einen X-Server während des Baus benötigt

> Das Paket XXXXXX benötigt einen X-server (oder
> mindestens ein DISPLAY) zum Bau 
> (ohne Änderung der Konfigurationsdateien).
>
> Kann ich auf einen X-Server im Build Service zugreifen?
> Was sind die geforderten Änderungen
> in meiner Spezifikationsdatei?

Sie können  Xvfb starten (starten Sie in Ihrer Spezifikationsdatei), um das Problem zu umgehen.

Zum Beispiel können Sie so etwas wie die Zeile unten in Ihrer Spezifikationsdatei verwenden: 

BuildRequires:  xorg-x11-Xvfb
%define         X_display         ":98"
...
%install
#############################################
### Starten eines virtuellen Framebuffer X Server ###
#############################################
export DISPLAY=%{X_display}
Xvfb %{X_display} >& Xvfb.log &
trap "kill $! || true" EXIT
sleep 10
...
# starten Sie Ihre Anwendung/Testeinrichtung hier

Verwendung verschiedener Spezifikationsdateien für verschiedene Plattformen

In einer idealen Welt würden Sie eine einzige Spezifikationsdatei haben, die auf allen RPM-basieten Plattformen läuft, Vergangenheit, Gegenwart und Zukunft. In der wirklichen Welt ist eine einzige Spezifikationsdatei nicht möglich, oder würde so viele %if-Zweige in Ihrer Spezifikationsdatei benötigen, so dass sie unlesbar würde.

Glücklicher Weise hat der Build Service einen Weg, auf dem Sie mehrere Spezifikationsdateien für individuelle Plattformen verwenden können.

Stellen Sie sich vor, Sie haben ein Paket namend "foo" und eine Spezifikationsdatei darin mit "foo.spec" bezeichnet. Lassen Sie uns annehmen, dass diese Spezifikationsdatei großartig auf allen SUSE-basierten Distributionen wie openSUSE, SLES und SLED läuft. Aber Unterschiede im Paket-Layout bedeuten, dass Sie wirklich eine Spezifikationsdatei für eine komplett andere Distribution wie Fedora brauchen. Wenn das Repository im Build Service mit "Fedora_Extras_6" bezeichnet ist, können Sie eine Spezifikationsdatei erstellen, die mit "foo-Fedora_Extras_6.spec" bezeichnet ist. Die wird nur für diese Plattform gebaut werden, im Gegensatz zur Verwendung von "foo.spec".

Die einzige wirkliche Kehrseite davon ist, dass sie nur auf einer individuellen Repositorybasis funktioniert. Es gibt keine Möglichkeit, eine einzige Spezifikationsdatei für mehrere Repositorys zu verwenden. Überdenken wir das Beispiel oben, wenn Sie "foo" für Fedora Extras 4, 5 und 6 bauen wollen, müssten Sie die drei Spezifikationsdateien: "foo-Fedora_Extras_4.spec", "foo-Fedora_Extras_5.spec", and "foo-Fedora_Extras_6.spec" erstellen, auch wenn die Spezifikationsdateien exakt die gleichen sind.

Ein gutes Beispielpaket, das das gerade verwendet ist das Paket "net-snmp-main-snapshot" im net-snmp Projekt.

Entfernung deaktivierter aber gebauter Pakete aus einem Repository

Das Webfrontend unterstützt das gegenwärtig nicht. In OSC geben Sie einfach ein: 

osc wipebinaries <projectname>

Sie können ebenso direkt mit dem Buildservis-API "sprechen", um das zu lösen. Wenn Sie alle gebauten RPMs, die als deaktiviert gekennzeichnet sind, für ein ganzes Repository entfernen wollen (in diesem Beispiel: home:foo), versuchen Sie den folgenden Weg:

  • Erstellen Sie eine ~/.netrc Datei, die Ihre Login-Informationen für build.opensuse.org enthält oder verwenden Sie die Option "-u username:password" 
  • curl -n -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'
    oder 
  • curl -u username:password -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'

Für mehr "Kommandos" schauen Sie in die API Dokumentation.

Auflistung verfügbarer Pakete in einer Distro

Wenn Sie nicht die exakte Bezeichnung eines Paketes kennen, das Sie für Ihren Bau benötigen, können Sie entweder Web-Suche verwenden oder osc ls -b.

Beispiel: Welches Paket enthält mysql Entwicklungs-Dateien für Ubuntu? 

#           <Repository> <Arch> <Projekt>
$ osc ls -b -r standard -a i586 Ubuntu:7.10 | grep 'mysql.*dev'
libmysqlclient15-dev_5.0.45-1ubuntu3_i386.deb
# -> das Paket heißt "libmysqlclient15-dev"

Freigabe von rpmlint Prüfungen in Build Service Repositorys

Bitte lesen Sie die Seite RpmLint und dieses Kapitel.

Bau von xxbit Paketen für andere Architekturen (baselibs)

Lesen Sie en:openSUSE:Build Service_baselibs.conf

Wie wird die Release-Nummer eines erhaltenen Paketes gesteuert

Normaler Weise handhabt der Build Service die Release-Markierung automatisch. Der Inhalt des Feldes Release: wird durch das Tupel CI_CNT.B_CNT ersetzt, worin CI_CNT eine Zahl von Commits und B_CNT eine Zahl von Umbauten sind (wenn der Neubau ausgelöst wird).

Dieses Verhalten ist ein Äquivalent von 

Release: <CI_CNT>.<B_CNT>

in prjconf (erreichbar via osc meta prjconf -e [PROJECT]).

Sie können das verbessern. Zum Beispiel für den Import von jpackage.org RPMs können Sie definieren: 

Release: %%{?release_prefix}.<CI_CNT>.<B_CNT>

worin das RPM Makro %{release_prefix} in einer Spezifikationsdatei definiert wird. Das erhaltene RPM wird eine Release-Nummer haben, die mit den beiden Projekten jpackage.org and openSUSE kompatibel ist. Das bedeutet, dass es Ihnen möglich ist, Ihre SUSE-Pakete auf die jpackage.org Pakete zu aktualisieren.

Wie behebt man "does not exist", wenn man versucht ein Projekt zu löschen

Wenn das Paket eine Auslaufzeit hat, können Sie in einen uneinheitlichen Zustand geraten zwischen der API-Datenbasis und dem Backend. Um so ein Projekt zu löschen, bearbeiten Sie seine Metadatei mit OSC: 

osc meta prj -e <projectname>

sichern sie und löschen sie hinterher: 

osc rdelete <projectname>

Bau einer SLES 11 SP1 LiveCD

Getestet mit kiwi-3.74-5.101.1 Installieren Sie clicfs-1.1.3-3.1.x86_64.rpm und liblzma0-4.999.9beta-11.1.x86_64.rpm auf dem Bausystem und kopieren Sie diese Dateien in dasRepository-Verzeichnis, das Sie unter /usr/share/kiwi/image/isoboot/suse-SLES11/config.xml konfiguriert haben.

Modifizieren Sie die Datei /usr/share/kiwi/image/isoboot/suse-SLES11/config.xml und fügen Sie die folgende Zeile <package name="clicfs"/> in den Abschnitt <packages type="bootstrap"> ein.

Es könnte ein Bug sein, wenn es nicht mit dieser Zeile funktioniert (CD bootet nicht)

<packages type="bootstrap" profiles="std">

aber mit type=image funktioniert die CD gut:

<packages type="image" profiles="std">


  1. kiwi --createhash /usr/share/kiwi/image/isoboot/suse-SLES11

Modifizieren Sie config.xml für Ihre Live CD (nicht die config.xml, die Sie gerade bearbeiteten) um clicfs zu verwenden: <type primary="true" boot="isoboot/suse-SLES11" flags="clic">iso</type>

Einrichtung eines SLES 10 SP2/SP3 KIWI Abbildes mit squashfs und aufs

Mein Bau-Host war auch ein SLES 10 SP2 x86_64.

Das ist nur eine schnelle Einführung. Schauen Sie in die anderen KIWI Dokumentationen.

Schritt 1: Installation von KIWI

Notiz: Sie könnten einige Pakete auf dem Repository von SLES 10 SDK finden. Der Autor installierte das kiwi-3.01-93.1 aus

http://download.opensuse.org/repositories/openSUSE:/Tools/SLE_10

Notiz: Für kiwi-desc-oemboot und kiwi-desc-vmxboot brauchen Sie Qemu. Der Autor hat sie nicht installiert.

Installieren des smarten Paketmanagers 

rpm -ivh /usr/share/kiwi/repo/suse-repo/suse-sle10-repo/smart-0.41-23.4.$(arch).rpm

Laden Sie squashfs für SLES 10 SP2/SP3 von http://download.opensuse.org/repositories/home:/mopp:/squashfs/ herunter.

Laden sie aufs für SLES 10 SP2/SP3 von http://download.opensuse.org/repositories/home:/mopp:/aufs herunter

Installieren Sie das Paket squashfs vom KIWI Server 

rpm -ivh /tmp/kiwi/squashfs-3.4-35.1.x86_64.rpm

Schritt 2: Erstellen der KIWI Boot Image Umgebung

Natürlich benötigen Sie die SLES 10 SP2/3 Quellen. Der Autor kopierte sie in ein örtliches Verzeichnis. Ändern Sie den Pfad zu den Verzeichnissen, die zu Ihrem System passen. 

cp -a aufs-kmp* squashfs-kmp* /usr/share/kiwi/repo/suse-repo/suse-sle10-repo/

Notiz: Die Module aufs und squashfs werden in /lib/modules/<kernel>/updates/ installiert. Stellen Sie sicher, dass das Kernel-Modul zu dem Kernel passt, dass Sie in Ihr KIWI-Abbild installieren.

Nun ist es Zeit, config.xml (boot/initrd image) zu modifizieren, um die Module aufs und squashfs zu finden. Vielleicht kopieren Sie das Verzeichnis, bevor Sie es bearbeiten. Da nach der Aktualisierung von KIWI config.xml wahrscheinlich überschrieben wird. 

cd /usr/share/kiwi/image/isoboot/suse-SLES10
vi config.xml

Es ist sehr wichtig, aufs und squashfs zum Abschnitt <drivers type="drivers"> und die Zeilen hinzu zu fügen. Ohne diese Module wird die LiveCD nicht gefunden. 

<file name="../updates/aufs.ko"/>
<file name="../updates/fs/squashfs/*"/>

Zum Abschnitt <packages type="bootstrap"> fügen Sie folgende Zeilen hinzu: 

<package name="squashfs-kmp-default"/>
<package name="squashfs-kmp-smp"/>
<package name="aufs-kmp-default"/>
<package name="aufs-kmp-smp"/>

Erzeugen Sie neue Hashes 

kiwi --createhash /usr/share/kiwi/image/isoboot/suse-SLES10

Schritt 3: Vorbereitung des Systemabbildes

Stellen Sie sicher, dass Sie nicht die Kernel des Boot-Abbildes und des System-Abbildes vertauscht haben (-default und -smp).

Bereiten Sie das Systemabbild vor (der Autor verwendete suse 11.0) 

cp -pr /usr/share/doc/packages/kiwi/examples/suse-11.0/suse-live-iso /usr/local/kiwi/suse-sle10sp2-live-iso

Bearbeiten Sie config.xml in /usr/local/kiwi/suse-sle10sp2-live-iso. Schließlich müssen Sie die Markierungen "boot" tag und "repository" ändern.

Änderung 

<type primary="true" boot="isoboot/suse-11.0" flags="unified">iso</type>

zu 

<type primary="true" boot="isoboot/suse-SLES10" flags="unified">iso</type>

Löschen Sie das Paket "bootsplash-branding-openSUSE", da es auf SLES 10 nicht verfügbar ist.

Sie müssen das Repository hinzufügen, um zusätzliche Pakete zu finden. 

       <repository type="rpm-dir">

 <source path="/usr/share/kiwi/repo/suse-repo/suse-sle10-repo/"/>

       </repository>

Sie fügen hinzu oder löschen die benötigten Pakete in config.xml und passen Sie Ihr System an.

Sie könnten das Paket dhcpcd hinzufügen, um DHCP zu aktivieren.

Die openSUSE Pattern scheinen mit SLES nicht zu funktionieren.

Schritt 4: Das ISO-Abbild erstellen

Stellen Sie sicher, dass Sie genug Speicherplatz zur Verfügung haben. 

kiwi --prepare /usr/local/kiwi/suse-sle10sp2-live-iso --root /tmp/myiso

Prüfen Sie die Log-Datei. Um das erstellte Zielsystem zu prüfen, können Sie folgendes eingeben: 

chroot /tmp/myiso

Wenn alles gut aussieht, ist es Zeit das ISO-Abbild zu erstellen 

kiwi --create /tmp/myiso -d /tmp/myiso-result

Prüfen Sie die Log-Datei.

Versuchen Sie das ISO-Abbild zu starten.

Ausführen eines nächtlichen Baus von einer VCS-Abmeldung

OBS hat nun die Unterstützung für das Downloaden vom VCS über eine Datei _service. Lesen Sie dazu diese Konzeptseite und die OBS (Entwurf) Dokumentation.

Sie brauchen dafür eine Maschine mit cron und osc.

Bereiten Sie ein Arbeitsverzeichnis mit einer VCS-Abmeldung von Ihrem Code vor und melden Sie sich von Ihrem Paket im Build Service ab. Bereiten Sie eine Spezifikationsdatei-Vorlage mit einem Platzhalter im Versionsfeld vor. Das könnte so aussehen: 

Name:         monitord
Version:      ##TIMESTAMP##
Requires:     alsa
...

Bereiten Sie ein Shellskript vor, das eine lokale Aktualisierung, die Vorbereitung das Tarpakets, die Modifizierung der Spezifikationsdatei und das Hochladen zum Build Service vornimmt.

Hier ist ein Beispiel für ein SVN Repository: 

#!/bin/bash

# der relative Pfad zure OBS Abmeldung
PACK_PATH=home:cwh:monitord-nightly/monitord

# der relative Pfad zur SVN Abmeldung
REPO_PATH=trunk

TIMESTAMP=`date +"%Y%m%d"`

# betreten des SVN Verzeichnisses
pushd $REPO_PATH

# Aktualisierung auf die gegenwärtige Revision
svn up

# Vorbereitung Tarball
make dist

# verschieben des Tarball zum Paketverzeichnis 
cp monitord-2.0svn.tar.gz ../$PACK_PATH

popd

# kopieren einer modifizierten Spezifikationsdatei in das Paketverzeichnis 
perl -p -e "s/##TIMESTAMP##/$TIMESTAMP/" monitord.spec > $PACK_PATH/monitord.spec

# betreten des Paket-Verzeichnisses
pushd $PACK_PATH

# hochladen der Änderungen (neuer Tarball und Spezifikationsdatei) zum OBS
osc commit -m "updated to current SVN snapshot $TIMESTAMP"

popd

echo "Done"

Dann rufen Sie das Skript über Cron auf.

Beispiel: 

0 5 * * *       cd /space/monitord-nightly && ./push_to-obs.sh
Abgerufen von „https://de.opensuse.org/index.php?title=openSUSE:Build_Service_Tipps_und_Tricks&oldid=30891“