Bemerkung: Das Original ist neuer als diese Übersetzung.
Wanna-build-Zustände: Eine Erklärung
Diese Seite versucht zu erklären, welche wanna-build-Zustände es gibt und was es für ein Paket bedeutet, wenn es in einem dieser Zustände ist. Diese Seite ist für die Debian-Paketbetreuer gedacht, die herausfinden möchten, warum ihr Paket für eine bestimmte Architektur erzeugt bzw. noch nicht erzeugt wurde. Zusätzlich wird eine Erklärung für die unterschiedlichen Meldungen des Ergebnisprotokolls gegeben.
Zusätzlich existiert ein Ablaufdiagramm. In diesem wird aber nicht alles dargestellt, das dieses Dokument beschreibt.
Die wanna-build-Zustände
Für jede von Debian unterstützte Architektur ist auf buildd.debian.org eine Datenbank installiert. Sie enthält alle Pakete und deren jeweiligen Kompilierungsstatus. Es gibt acht Zustände: needs-build, building, uploaded, dep-wait, BD-Uninstallable, failed, not-for-us und installed.
Die Bedeutung derselben ist wie folgt:
- needs-build
- Ein Paket mit dem Status needs-build wurde von seinem Betreuer
in einer neuen Version hochgeladen, allerdings für eine andere Architektur
als die dieser wanna-build-Datenbank. Deshalb muss das Paket neu erzeugt werden.
Der Zustand needs-build zeigt hierbei an, dass das Paket noch von keinem
Autobuilder bearbeitet wurde. Dies geschieht, sobald das Paket in der Warteschlange
in die Nähe der Spitze gekommen ist und ein Autobuilder verfügbar ist. Meistens wird von
einem Paket als
auf eine Neuerzeugung wartend
bezeichnet, wenn dessen Status needs-build ist.
Es kann interessant sein, anzumerken, dass die Warteschlange nicht chronologisch (FIFO), sondern nach den folgenden Kriterien geordnet wird:- Vorheriger Kompilierungsstatus des Paketes: Pakete, die zuvor schon einmal erzeugt wurden, erhalten eine höhere Priorität als neue.
- Paketprioritäten: Pakete mit der Priorität required (erforderlich) werden vor Paketen mit der Priorität extra erzeugt.
- Der Bereich, in dem sich das Paket befindet: Diese Sortierung basiert auf der Einschätzung, welche der Pakete als wichtiger erachtet werden als andere. Beispielsweise wird ein Paket im Bereich games nach Paketen im Bereich base und Pakete des Bereichs libs vor solchen in devel erzeugt.
- Nach Paketnamen: Hierzu werden die ASCII-Zeichen herangezogen.
Es könnte weitere Situationen geben, in denen die Sortierung scheinbar ignoriert wird, aber dies sind immer Ausnahmen. - building
- Ein Paket wird als building markiert, sobald der Autobuilder das Paket von der Spitze der Warteschlange geholt hat. Der Status wird beibehalten bis der Administrator des Autobuilders auf die E-Mail mit dem Protokoll geantwortet hat. Da Pakete nicht eines nach dem anderen aus der Warteschlange genommen werden, bedeutet dies, dass Pakete meist schon als building markiert sind bevor der der Prozess eigentlich begonnen hat. Da aber die lokale Warteschlange des buildds nach dem FIFO-Prinzip funktioniert, sollte es nicht mehr allzu lange dauern. Außerdem ändert sich der Status nicht automatisch nach Abschluss des Erzeugens, sondern erst, nachdem der Administrator des Autobuilders auf die E-Mail mit dem Protokoll geantwortet hat.
- uploaded
- Wenn der Versuch, das Paket zu erzeugen, erfolgreich war,
wird das Protokoll an den Betreuer des Autobuilders sowie an
buildd.debian.org gesandt. Der Betreuer signiert dann die
.changes-Datei, die im Protokoll enthalten ist, und sendet diese
an den Autobuilder. Daraufhin lädt der Autobuilder
das Paket hoch und ändert den Status in der buildd-Datenbank auf
uploaded. Dies bedeutet, dass ein solches Paket irgendwo
in der Incoming-Warteschlange zu finden ist.
Kein Autobuilder ändert mehr etwas an einem Paket, sobald dessen Status uploaded ist – sofern keine neue Version hochgeladen wird oder ein Portierer etwas manuell am Status des Paketes ändert. - dep-wait
- Im Falle, dass ein Paket nicht erzeugt werden konnte, weil eine
oder mehrere Abhängigkeiten zum Erzeugen des Paketes nicht erfüllt
werden konnten, sendet der Betreuer des Autobuilders eine E-Mail an den
Autobuilder, in der der Autobuilder angewiesen wird, das Paket inklusive
seiner Quellen zu entfernen und das Paket selbst als dep-wait
zu markieren, bis die erforderlichen Abhängigkeiten erfüllt sind.
Sobald die Abhängigkeiten erfüllbar sind, wird der Status ohne menschliches
Eingreifen automatisch als needs-build
markiert.
Ursprünglich war ein Versuch, das Paket zu erzeugen, notwendig, bevor der Betreuer manuell dessen Status auf dep-wait setzte. Seit August 2005 ist dies nicht mehr notwendig, da wanna-build dahingehend erweitert wurde, fehlende Abhängigkeiten selbst zu erkennen und den Zustand eines Paketes, falls zutreffend, direkt von installed auf dep-wait zu ändern.
Es gibt zwei Fälle, in denen der Zustand eines Paketes dauerhaft dep-wait sein kann. Erstens, wenn eine Abhängigkeit falsch geschrieben wurde (das wartende Paket hängt dann von einem Paket ab, welches weder vorhanden ist, noch jemals sein wird) und zweitens, wenn ein Paket eine Abhängigkeit auf ein als not-for-us (nicht für uns) markiertes oder auf der packages-arch-specific-Liste stehendes Paket besitzt.
Ein Beispiel für den letzten Fall: Man stelle sich drei Pakete vor. Das Paket foo, welches nur für i386 vorhanden ist, das Paket bar, welches nur für m68k vorhanden ist (und ungefähr die gleiche Funktion wie ersteres bereitstellt) und ein Paket namens baz, welches entweder mit foo oder bar erzeugt werden kann. Sollte nun der Paketbetreuer von baz vergessen bar als Abhängigkeit für die Erzeugung zu definieren und er es hinzufügen, sobald er bemerkt, dass baz auf das auf der Architektur m68k nicht verfügbare Paket foo wartet, dann muss der Zustand dep-wait manuell für die Architektur m68k von dessen Portierern aufgehoben werden. - BD-Uninstallable
- Während debconf9 hatte
Joachim Breitner die Idee, edos-debcheck für die Überprüfung
der Installationsfähigkeit der zum Erzeugen des Pakets notwendigen
Abhängigkeiten zu verwenden. Bislang wurden diese Pakete in den
Status
Needs-Build
gesetzt. Zu dem damaligen Zeitpunkt hatte wanna-build bereits die Fähigkeit, die unmittelbare Verfügbarkeit der zum Erzeugen des Pakets notwendigen Abhängigkeiten zu überprüfen. Allerdings schlug das Bauen des Pakets früh fehl, wenn eine Abhängigkeit nicht installiert werden konnte, weil das Paket von a abhängt, das wiederum von b abhängt, welches seinerseits wiederum von c (>=1.2.3) abhängt und c erst in der Version 1.2.2 vorliegt. Dies konnte nicht erkannt werden. Solche Fehler herauszufinden, war also eine manuelle Aufgabe für den buildd-Administrator und üblicherweise langwierig. Mit dem BD-Uninstallable-Patch ist dies nicht länger ein Problem. Wenn Ihr Paket im Status BD-Uninstallable ist, bedeutet dies, dass eine der zum Erzeugen des Pakets notwendigen Abhängigkeiten nicht installiert werden kann (entweder unmittelbar oder weil ein Teil der weiteren Unterabhängigkeiten nicht verfügbar ist). Leider stellt der BD-Uninstallable-Patch keine Informationen darüber zur Verfügung, welches Paket genau fehlt. Um das herauszufinden, verwenden Sie bitte edos-debcheck. Dieses Problem wird sich aber lösen, sobald die fehlenden Abhängigkeiten zur Verfügung stehen. Zu diesem Zeitpunkt wird Ihr Paket automatisch wieder in den StatusNeeds-Build
verschoben. - failed
- Sollte das Erzeugen eines Paketes fehlschlagen und der Betreuer des
Autobuilders entscheiden, dass kein erneuter Versuch gestartet
werden soll, dann markiert er dieses Paket als failed.
Ein Paket bleibt in diesem Zustand, bis entweder ein Portierer dies
ändert oder eine neue Version des Paketes verfügbar ist. Im zweiten
Fall wird allerdings der Administrator des Autobuilders von diesem
um Erlaubnis gebeten, das Paket erzeugen zu dürfen, um einen offensichtlichen
erneuten Fehlschlag zu vermeiden und keine Rechenzeit auf dem
Autobuilder zu verschwenden. Auch wenn
dieses Vorgehen im Allgemeinen nicht der richtige Weg ist, steht es
dem Administrator des Autobuilders offen.
Ein Paket wird niemals automatisch ohne den Eingriff eines Menschen als failed markiert. - not-for-us
- Einige ausgewählte Pakete sind nur für bestimmte Architekturen
gedacht, wie zum Beispiel lilo, ein Boot-Loader für i386.
Dieser sollte nicht für alpha, m68k oder s390 erzeugt werden.
Allerdings beachtet wanna-build die Steuerdatei nicht,
während die eigene Datenbank erzeugt wird (nur der Name, der Bereich,
der vorhergehende Status und die Priorität eines Paketes werden in Betracht gezogen).
Deshalb wird nach dem ersten Hochladen eines architekturspezifischen
Paketes ein Versuch unternommen, es dennoch zu erzeugen. Dieser
Versuch schlägt fehl, bevor die zum Erzeugen notwendigen Abhängigkeiten
heruntergeladen/installiert wurden.
Da die Autobuilder ihre Zeit nicht mit Paketen verschwenden sollen, die für diese Architektur nicht gedacht sind, ist es notwendig, solche Pakete in irgendeiner Form aufzulisten. Die erste Lösung für dieses Problem war not-for-us. Da dies aber schwer zu verwalten ist, gilt der Zustand heute als veraltet und die Betreuer eines Autobuilders sollten packages-arch-specific stattdessen verwenden. Dies ist kein Zustand von wanna-build, sondern eine Liste für eine oder mehrere Architekturen, die Pakete aufführt, die nur für bestimmte Architekturen gedacht sind.
Ein Paket, welches entweder als not-for-us markiert wurde oder auf der packages-arch-specific-Liste steht, wird auch dann nicht automatisch daraus entfernt, wenn das Paket in einer neueren Version zusätzliche Architekturen unterstützt. Das Paket muss manuell erneut in die Warteschlange eingereiht werden.
Im Falle, dass dies für ein von Ihnen betreutes Paket zutrifft, müssen Sie den Administrator des entsprechenden buildds (auf Englisch) fragen. Dieser kann via $arch@buildd.debian.org kontaktiert werden. - installed
- Wie der Name bereits nahelegt, ist ein Paket, welches im Zustand installed ist, für die von der entsprechenden wanna-build-Datenbank abgedeckte Architektur kompiliert worden. Vor der Veröffentlichung von Woody änderte sich der Status von uploaded zu installed nach dem täglichen Durchlauf von katie. Seit der Implementierung von Accepted-autobuild stimmt dies so nicht mehr. Momentan ändert sich der Status eines Paketes von uploaded zu installed sobald es im Archiv akzeptiert wurde. Dies passiert im Durchschnitt nach ungefähr 15 Minuten.
Außer diesen acht Zuständen kennt wanna-build noch
zwei -removed-Zustände, die aber Sonderfälle sind. Es handelt
sich hierbei um dep-wait-removed und failed-removed.
Sie hängen direkt mit ihren respektiven einfachen
Zuständen wie
folgt zusammen: Sollte ein Paket, welches zuvor als dep-wait
oder failed markiert war, in einer neuen, an wanna-build
übergebenen Paketliste nicht mehr aufgeführt sein, so wird es mit dem
entsprechenden -removed-Zustand markiert, da es so scheint, als ob das
Paket entfernt wurde. Die Informationen zum Paket werden allerdings
nicht entfernt, da es sich nur um einen zeitweiligen Fehler handeln
könnte. Oder das Paket mit Absicht zeitweise entfernt wurde, um zu
einem späteren Zeitpunkt wieder ins Archiv aufgenommen zu werden. Stattdessen
wird ein solches Paket in einen -removed Zustand versetzt, so dass
der Grund des Fehlschlages oder worauf es wartet erhalten bleibt.
Sollte ein solches Paket auf eine späteren Paketliste für
wanna-build wieder aufgeführt sein, so wird dessen Status wieder auf
failed bzw. dep-wait vor seiner weiteren
Bearbeitung zurückgesetzt.
Es ist nicht möglich, direkt auf die auf ftp-master.debian.org installierte wanna-build-Datenbank zuzugreifen. Nur die Autobuilder haben einen SSH-Schlüssel, mit dem sie die Datenbank für ihre Architektur zugreifen können. Dies war bereits der Fall, als ftp-master noch nicht in seiner Benutzung für die Allgemeinheit eingeschränkt war, da wanna-build die Datenbank für andere Zugriffe sperrt, sobald es selbst (auch nur lesend) darauf zugreift. Für einen direkten Zugriff auf eine wanna-build-Datenbank muss der Zugreifende in der richtigen Benutzergruppe (wb-<arch>) sein.
Für die Allgemeinheit ist der Status eines Paketes auf der buildd-Statusseite
einsehbar. Eine Ausnahme hiervon stellt der Zustand installed
dar, dieser ist nur in den mehreren Megabyte großen <arch>-all.txt
-Dateien
nachzulesen.
Das Ergebnisprotokoll des Erzeugens
Wenn sbuild (die Komponente des buildd, die das Paket erzeugt) ein Paket erzeugt hat, sendet sie eine E-Mail an den Administrator des Autobuilders und an logs@buildd.debian.org (um schlussendlich unter https://buildd.debian.org/ verfügbar zu sein), welches das Protokoll des Erzeugens enthält. Das Ergebnis kann eines der folgenden sein: successful, attempted (früher bekannt als failed), given-back oder skipped. Auf der buildd-Protokollübersichtsseite wird immer das Präfix maybe- hinzugefügt, da es Fälle gibt, in denen das Erzeugen als failed eingestuft wird, es aber keinen wirklichen Fehlschlag gab. Auch der umgekehrte Fall, dass ein Paket als erfolgreich erzeugt markiert ist, es aber in Wirklichkeit fehlerhaft ist und erneut erzeugt werden muss, kann vorkommen. Dies hatte in der Vergangenheit zu einiger Verwirrung geführt und um diese fürderhin zu vermeiden, wurde oben genannter Präfix eingeführt.
Die Bedeutung der Ergebnisse ist wie folgt:
- successful
- Das Erzeugen war erfolgreich. Wenn der Administrator eines Autobuilders
ein solches Protokoll erhält, extrahiert er die enthaltene
.changes-Datei, signiert diese und sendet sie an den Autobuilder zurück, der dann das Paket hochlädt. - attempted (früher: failed)
- Das Erzeugen wurde mit einem Rückgabewert verschieden von Null beendet, was möglicherweise bedeutet, dass es fehlgeschlagen ist. Da es etliche Gründe gibt, warum das Erzeugen eines Paketes fehlgeschlagen sein kann, wird hier darauf verzichtet, sie alle zu nennen. Sollte eines Ihrer Pakete als (maybe-)failed markiert worden sein, sollten Sie den gesamten Artikel lesen und den aktuellen wanna-build-Zustand überprüfen.
- given-back
- Das Erzeugen schlug auf Grund eines temporären Fehlers des
Autobuilders fehl. Beispiele hierfür können Netzwerkprobleme,
nicht verfügbare Pakete (nicht in den in der aktuellen sources.list
enthalten Quellen verfügbar), kein ausreichender Speicherplatz usw. sein.
Ein solches Paket wird erneut als needs-build markiert. So wird dafür Sorge getragen, dass ein anderer Autobuilder, sobald einer verfügbar ist, erneut versucht, das Paket zu erzeugen. - skipped
- Sollte in der Zeit nachdem der/ein Autobuilder ein Paket als building markiert hat und dem eigentlichen Versuch, es zu erzeugen, eine neue Version des Paketes hochgeladen werden oder ein Portierer den wanna-build-Status manuell geändert haben, so wird dies von sbuild registriert und der Vorgang übersprungen. Ein Protokoll mit dieser Information wird versandt.
Die graphische Version
Um die oben dargestellten Punkte zu illustrieren, ist ein vereinfachtes Ablaufdiagramm dieser Prozedur verfügbar.
