openSUSE:OSC
Das openSUSE Build Service Kommandozeilenwerkzeug heißt OSC
Inhaltsverzeichnis
OSC, der Python Kommandozeilen-Client
OSC ist in Python geschrieben. Zusätzlich zur Kommandozeilenschnittstelle liefert es auch ein Python-Modul zur Nutzung anderer Pythonprogramme.
Pakete für verschiedene Distributionen (openSUSE, SLES, Fedora, Mandriva, Debian, etc.) können unter http://download.opensuse.org/repositories/openSUSE:/Tools/ gefunden werden. Wenn Sie den neuesten Quellcode ausprobieren wollen, können Sie das mit Git machen:
git clone git://github.com/openSUSE/osc.git
Damit OSC funktioniert, wird python-xml benötigt:
zypper install python-xml
OSC dient im Build Service als Client für den Repository-Teil des Quellcodes. Er wird verwendet, um Metadaten oder Anfragen über Bauergebnisse zu bearbeiten.
Einführungsbeispiele werden unten gezeigt. Beachten Sie die Build Service Anleitung. Sie liefert eine systematische Einführung.
OSC ist erweiterbar. Sie können das Verhalten modifizieren oder Ihre eigenen Kommandos schreiben.
OSC wird Sie nach Ihrer Legitimation fragen, wenn Sie ihn das erste Mal benutzen und sie unter ~/.oscrc speichern. Das Passwort wird als klarer Text gespeichert. Schützen Sie Ihre Datei ~/.oscrc und Ihr Dateisystem angemessen.
Hier einige brauchbare Kommandos
Die Informationen zu einem Kommando zeigen:
osc help osc help <cmd>
Den vorhandenen Inhalts auf einem Server auflisten:
osc ls # listet Projekte osc ls Apache # listet Pakete in einem Projekt osc ls Apache subversion # listet Dateien von eiem Pakete in einem Projekt
Den Inhalt überprüfen:
osc co Apache # das komplette Projekt osc co Apache subversion # ein Paket osc co Apache subversion foo # eine einzelne Datei
Das Arbeitsverzeichnis aktualisieren:
osc up
osc up <directory>
osc up * # innerhalb eines Projetverzeichnisses,
Aktualisierung aller Pakete
osc up # innerhalb eines Projetverzeichnisses,
Aktualisierung aller Pakete
UND Überprüfung aller neu hinzugefügten Pakete
Geänderte Inhalte hoch laden
osc ci # aktuelles Verzeichnis osc ci <file1> <file2> # nur spezielle Dateien osc ci <dir1> <dir2> ... # mehrere Pakete osc ci -m "updated foobar" # spezifizieren einer Übergabenachricht
Zeige den Übergabe-Log
osc log
Zeige den Status (welche Dateien wurden lokal geändert)
osc st osc st <Verzeichnis>
Wenn eine Aktualisierung nicht automatisch zusammengeführt werden kann, dann ist eine Datei im Zustand 'C' (conflict/Konflikt). Konflikte werden mit spezielle Zeilen <<<<<< und >>>>> gekennzeichnet. Nach dem manuellen Lösen des Problems verwenden Sie
osc resolved <Datei>
Sorgen Sie dafür, dass Dateien beim nächsten 'Einchecken' hinzugefügt oder gelöscht werden:
osc add foo osc rm foo
Fügt alle neuen Dateien lakal hinzu, kopiert und löscht alle verschwundenen Dateien:
osc addremove
Erzeugt eine Differenz, um die Änderungen zu zeigen:
osc diff [Datei]
Zeigt das Bauergebnis des Paketes
osc results osc results <Plattform>
Zeigt die Log-Dateien eines Paketes (Sie müssen innerhalb eines Paketverzeichnisses sein):
osc buildlog <Plattform> <Architektur>
Zeigt die URLs von .repo Dateien, die Paketquellen für Yum/YaST/smart sind:
osc repourls [dir]
Löst einen Paketneubau aus für alle Repositorys/Architekturen eines Paketes:
osc rebuildpac [dir]
Baut ein Paket auf Ihrer lokalen Plattform:
osc build <Plattform> <Architektur> <Spezifikationsdatei> [--clean|--noinit|...]
Zeigt die konfigurierten Plattformen/Bau-Ziele:
osc platforms [project]
Zeigt das mögliche Bauziel für Ihr Projekt:
osc repos
Zeigt Meta-Information
osc meta prj <Projekt> osc meta pkg <Projekt> <Paket> osc meta user <Benutzername> osc meta prjconf <Projekt>
Bearbeitet die Meta-Information. Erzeugt ein neues Paket/Projekt, wenn es nicht vorhanden ist. Es wird einen Editor mit den Raw XML Metadaten geöffnet. Wenn Sie mit XML unsicher sind, können Sie stattdessen den Web-Client verwenden.
osc meta prj -e <Projekt> osc meta pkg -e <Projekt> <Paket> osc meta prjconf -e <Projekt>
(Die Projekt-Konfiguration (prjconf) könnte gut leer sein. Sie wird nur in speziellen Fällen benötigt.)
Aktualisiert Paket-Meta-Daten mit Metataten, die aus der Spezifikationsdatei genommen werden:
osc updatepacmetafromspec <dir>
Paketverfolgung
Mit osc ist es benso möglich, auf SVN ähnliche Weise zu managen. Diese Funktion wird Paketverfolgung (package tracking) genannt und muss im Abschnitt ~/.oscrc's [general] aktiviert werden:
# managen Sie Ihre Pakete auf svn ähnliche Weise do_package_tracking = 1
Fügt ein neues Paket zum Projekt hinzu:
osc mkpac <package>
Fügt ein bereits vorhandenes Verzeichnis und seine Dateien zu einem Projekt:
osc add <directory>
Entfernt ein Paket seine Dateien von einem Projekt:
osc deletepac <package>
Alle diese obigen Kommandos ändern nur Ihre lokale Arbeitskopie. Um Ihre Änderungen zum Build Service einzureichen, müssen Sie sie übergeben (osc ci -m <message>).
Das Status-Kommando zeigt ebenso den Zustand der Pakete:
osc st
Dokumentation
Zusätzlich ist für OSC ein Schwindelblatt als Anleitung verfügbar.
Wie sind bei einem nicht-Factory-Paket Fehler zu beheben?
Überprüfen Sie das Paket Ihrer Wahl:
osc -A https://api.suse.de bco SUSE:SLE-11-SP2:GA <Paketbezeichnung>
Behebe die Fehler. Und nachdem Sie den Paketbau überprüft haben, reichen Sie es ein:
osc commit <Paketbezeichnung>
Konfigurationsumzug
Die Version 0.114 erhielt einige Bereinigungen für die Konfigurationsdatei. Darum werden einige Optionen nun abgelehnt, so
- apisrv
- scheme
Eine neue Option wurde hinzugefügt:
- apiurl = <protocol>://<somehost> # verwenden Sie diese als Standard apiurl. Wenn diese Option nicht spezifiziert ist, wird der Standard (https://api.opensuse.org) verwendet.
Bis jetzt hat OSC noch einige Rückwärtskompatibilitäten für diese Optionen. Aber sie könnten in der Zukunft beseitigt werden. Das ist, weil sie eine Misbilligungswarnung für den Fall ausgibt, das eine dieser Optionen noch in Gebrauch ist. Das neue Konfigurationsschema sieht wie folgt aus:
# Eintrag für apiurl [<protocol>://<apiurl>] user = <Benutzername> password = <Passwort> ...
Bevor Sie den Umzug starten, sichern Sie bitte Ihre Dateir ~/.oscrc!
Wenn der Umzug aus irgend einem Grund nicht funktioniert, können Sie gern eine E-Mail an die opensuse-buildservice Mailingliste senden oder im IRC-Kanal #opensuse-buildservice fragen.
Unzugsfall I (nur apisrv)
Die Option apisrv wird zur Spezifizierung des Apihost verwendet. Wenn apisrv überhaupt nicht spezifiziert ist, wird der Standard ("api.opensuse.org") verwendet. Der gegenwärtige (grundsätzliche) Abschnitt sieht wie folgender aus:
[general] ... apisrv = <somehost> # or apisrv = <protocol>://<somehost>
apisrv wird durch die neue apiurl-Option ersetzt und sieht wie folgt aus:
[general] ... apiurl = <protocol>://<somehost>
Wenn apisrv kein "<protocol>" hat , wird https verwendet. Stellen Sie sicher, dass alle apiurl Abschnitte das neue Format haben, wie oben beschrieben. Hinterher kann apisrv gelöscht werden.
Umzugsfall II (nur scheme)
Der gegenwertige [general] Abschnitt sieht wie folgt aus:
[general] ... scheme = <protocol>
Das bedeutet, jeder apiurl Abschnitt, der nicht das neue Format, das oben beschrieben wurde hat zum Beispiel
[<somehost>] user = <username> password = <password> ...
muss umgewandelt werden zu
[<protocol>://<somehost>] user = <username> password = <password> ...
Danach kann die scheme-Option aus der [general] Sektion gelöscht werden (es kann sein, dass einige Abschnitte bereits das richtige Format haben).
Umzugsfall III (apisrv und scheme)
Der momentane [general] Abschnitt sieht wie folgt aus:
[general] ... apisrv = <somehost> scheme = <protocol>
Beide Optionen können gelöscht werden, wenn alle apiurl das neue Format besitzen, was oben beschrieben wurde. So Both options can be removed if all apiurl sections have the new format which is described above. Passen Sie hauptsächlich alle apiurl-Abschnitte an (es könnte sein, dass einige Abschnitte bereits das neue Format haben).
OSC Bau mit Xen
Sie müssen Xen-Pakete und den Xen-Kernel installiert und hochgefahren haben, um fortzufahren. Um lokale Bauten mit Xen zu aktivieren, müssen Sie diese Zeilen zum Abschnitt [general] ihrer Datei ~/.oscrc hinzufügen:
build-type=xen build-device=/tmp/FILE.root build-swap=/tmp/FILE.swap build-memory=512
Dann erzeugen Sie 2 Dateien:
dd if=/dev/zero of=/tmp/FILE.root bs=1M count=4096 # 4GB Partition für / . Bei großen Projekten sollten 8GB verwendet werden. mkfs.ext3 /tmp/FILE.root # Tippe (y), wenn es sich über die Datei beklagt, kein Geräteknoten zu sein. dd if=/dev/zero of=/tmp/FILE.swap bs=1M count=512 # verwenden Sie andere Größen, wenn benötigt mkswap /tmp/FILE.swap
Wenn Sie eine Funktion zur Kreuz-Kompilierung verwenden wollen, müssen Sie zu Ihrem /etc/sysconfig/kernel hinzufügen:
- binfmt_misc to INITRD_MODULES
- binfmt_misc to DOMU_INITRD_MODULES
- binfmt_misc to MODULES_LOADED_ON_BOOT
Erzeugen Sie die initrd's mit mkinitrd neu.
Starten Sie osc-Bau.
.oscrc Schwindelblatt
Der [general] Abschnitt
Speicher:
# Heruntergeladen Pakete werden hier gecached. Muss von Ihnen geschrieben werden. # Standard: packagecachedir = /var/tmp/osbuild-packagecache
# rootdir um die chroot Umgebung einzurichten # kann enthalten %(repo)s und/oder %(arch)s zum Ersetzen # /<path>/%(repo)s-%(arch)s-%(project)s-%(package)s # Standar: build-root = /var/tmp/build-root/
API Kommunikation:
# verwenden Sie diesen API Server (hostname[:port]) # (er benötigt einen Abschnitt [api.opensuse.org] mit den Referenzen) # Standar: apisrv = api.opensuse.org
# verwenden Sie dieses Protokoll, um auf den API-Server zu zu greifen (http oder https) # Standar: scheme = https
API Host:
# API Hosts können mit Aliase versehen werden, z.B. 'osc -A alias ...' # Listen Sie Aliase für API Hosts unter dem API Host-Abschnitt. # https://api.opensuse.org # user=jdoe # aliases=
Lokaler Bau:
# Wrapper, um den Bau als Root aufzurufen (sudo, su -, ...) # Standard: su-wrapper = su -c # kein Passwort gefordert mit: # su-wrapper = sudo # mit Eitrag in sudoers Datei: # <username> ALL = NOPASSWD: /usr/bin/build
# Für die Bequemlichket/Fehlerbeseitigung, osc fügt intern vim gdb strace zu # den Paketen hinzu, die im gebauten chroot installiert sind, wenn extra-pkgs nicht bestimmt ist zu: #extra-pkgs=
# build type - mögliche Werte: # * empty -> chroot # * xen -> xen VM # * kvm -> kvm VM (Test benötigt) # Standard: nicht festgelegt/chroot #build-type=xen
# build-device - Root Dateisystem, zu verwenden für VM # default: nicht festgelegt #build-device=/tmp/FILE.root
# build-swap - swap Dateisystem, zu verwenden für VM # Standard: nicht festgelegt #build-swap=/tmp/FILE.swap
# build-memory - Beitrag der memory für VM # Standard: nicht festgelegt #build-memory=512