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:
  1. Vorheriger Kompilierungsstatus des Paketes: Pakete, die zuvor schon einmal erzeugt wurden, erhalten eine höhere Priorität als neue.
  2. Paketprioritäten: Pakete mit der Priorität required (erforderlich) werden vor Paketen mit der Priorität extra erzeugt.
  3. 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.
  4. Nach Paketnamen: Hierzu werden die ASCII-Zeichen herangezogen.
Unter bestimmten Bedingungen kann es außerdem passieren, dass ein buildd ein Paket auswählt, welches nicht an der Spitze der Warteschlange ist. Dies passiert unter anderem dann, wenn ein buildd die Quelldateien eines bestimmten Paketes nicht finden kann. In diesem Fall wird das betreffende Paket wieder zurück in die Warteschlange eingereiht (an der vorherigen Position, d.h. den Anfang). Das Paket wird dann für einige Stunden vom buildd ignoriert. Ein anderes Beispiel wäre, wenn für eine Architektur mehrere Autobuilder vorhanden sind. In diesem Fall können die Portierenden entscheiden, dass die schnelleren Autobuilder die größeren Pakete und die langsameren Maschinen die kleineren Pakete bearbeiten sollen. Ein buildd kann theoretisch auch eine andere Bereichssortierung anfordern, dies ist üblicherweise aber nicht der Fall.
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 Status Needs-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 http://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.