Build-Status

Ditana betreibt zusätzlich zu Arch eine eigene pacman-Paketquelle – 59 Pakete, die in jedem abgeschlossenen Durchlauf vollständig aufgelistet sind. Ein angehaltener Durchlauf listet auf, was er bis dahin erreicht hatte. Jede Nacht holt ein Build-Host das Rezept jedes Pakets, entscheidet, was neu gebaut werden muss, und baut es in einem sauberen Container. Die Regel, die bestimmt, was danach geschieht, ist hier die einzige, die zählt:

Wenn auch nur ein einziges Paket nicht gebaut werden kann oder seine Quellen nicht überprüft werden können, wird nichts veröffentlicht.

Nicht «der Rest wird ausgeliefert und das eine Paket morgen erneut versucht». Nichts. Die Paketquelle, aus der Sie installieren, ist entweder der vollständige, untereinander konsistente Satz aus einem Durchlauf oder der vollständige, untereinander konsistente Satz von gestern. Eine kleinere Paketquelle kann das versprechen; eine grosse, die Paket für Paket aktualisiert wird, kann es nicht – deshalb hält Ditana die eigene klein genug, um als Ganzes für sie einstehen zu können.

Eine solche Behauptung ist genau so viel wert wie ihre Belege; deshalb wird die Aufzeichnung unten von der Pipeline selbst geschrieben, einschliesslich der Durchläufe, in denen nichts ausgeliefert wurde. Diese Pipeline ist ditana-build, und sie ist öffentlich: Die Prüfstufe ist bin/pkgbuild-review-gate, und der Installationstest ist bin/test-install-in-qemu.

Build-Aufzeichnung wird geladen …

Wie weit ein Durchlauf gekommen ist

Jeder Durchlauf durchläuft dieselben Stufen, und sein outcome gibt an, welche er erreicht hat. Das sind die vier Zustände und die Farben oben:

outcome	Was es für Sie bedeutet
released	Das installieren Sie. Jedes Paket gebaut, jede Signatur überprüft, und der ganze Satz hat die Paketquelle ersetzt, aus der Ihr System aktualisiert wird.
in-testing	Gebaut und signiert; der Satz liegt in einer separaten Test-Paketquelle, während er geprüft wird. Ihr System installiert weiterhin die vorherige Veröffentlichung.
built	Der Build-Host ist fertig, hat aber keinen Signaturschlüssel – signiert wird danach auf einem anderen Rechner. Bisher wurde nichts verschoben.
held-back	Etwas hat die Prüfung nicht bestanden, deshalb wurde gar nichts ausgeliefert. Die Paketquelle, aus der Sie installieren, ist unberührt und weiterhin konsistent.

Nur released bedeutet, dass die Pakete bei Ihnen angekommen sind. Die anderen drei sind Stufen auf dem Weg dorthin oder ein Halt.

Was mit jedem Paket geschah

Innerhalb eines Durchlaufs erhält jedes Paket einen status:

status	Bedeutung
current	Das Rezept hat sich seit dem Bau des vorhandenen Pakets nicht geändert, und bei einem Paket mit der Endung -git hat sich auch der Upstream-Commit nicht bewegt. Nichts zu tun.
rebuilt	Die Quellen wurden auf dem Host geholt und überprüft, dann wurde das Paket in einem frischen Container gebaut.
review-stopped	Das Rezept hat sich so geändert, dass ein Mensch es sich ansehen muss. Der Durchlauf endet hier.
build-failed	Das Paket liess sich nicht kompilieren oder hat kein Artefakt erzeugt. Der Durchlauf endet hier.

Die letzten beiden sind der Grund, warum ein Durchlauf als held-back endet: Ein einziges Paket genügt.

Warum ein Durchlauf anhält

Das meiste, was Ditana neu baut, sind AUR-Rezepte von Dritten, verpackt in eine Paketquelle, der ihre Benutzerinnen und Benutzer über die Signatur-Konfiguration von pacman vertrauen. Das AUR ist eine Lieferkette und wurde auch als solche angegriffen: Verwaiste Pakete wurden übernommen und mit bösartigen Commits versehen, weshalb das AUR im August 2026 Übernahmen und Pushes deaktiviert hat.

Deshalb wird jedes git pull in der Pipeline eingestuft, bevor irgendetwas gebaut wird. Versionserhöhungen, Kommentare, Leerraum und Prüfsummen, die mit einer Versionsänderung einhergehen, werden durchgewunken. Eine Änderung an source=, an einer url=, an einer VCS-Revision, an irgendetwas innerhalb einer Funktion, an install=, an provides=, conflicts=, replaces= oder validpgpkeys=, eine Prüfsumme, die sich ändert, ohne dass sich die Version ändert, eine neue Abhängigkeit, die pacman nicht kennt, eine geänderte oder geleerte Zeile # Maintainer: – jede davon hält den Durchlauf an. Das Rezept wird dafür nie in einer Shell eingelesen: Die verdächtige Datei auszuführen, ist genau das, was vermieden werden muss; die Analyse ist daher statisch, und im Zweifel blockiert sie.

Gemessen an den letzten zwölf Monaten echter Paketgeschichte hält das einen Durchlauf ungefähr einmal alle dreieinhalb Tage an. Das ist kein Mangel, der durch Feinabstimmung beseitigt werden sollte; es ist der Preis der Alles-oder-nichts-Regel, im Voraus bezahlt.

Einige der Rezepte, die Ditana neu baut, werden im Upstream von niemandem betreut – ihre Zeile # Maintainer: ist leer. Deshalb hält eine geleerte Maintainer-Zeile einen Durchlauf an, statt durchgewunken zu werden: Ein verwaistes Rezept ist genau das, das jemand übernehmen kann.

Was hier nicht geprüft wird

Die Prüfung umfasst die Metadaten der Paketierung, nicht den Quellcode des Upstream-Projekts. Wenn ein Rezept aus einer Git-Revision baut, wird der Inhalt dieser Revision von nichts in dieser Pipeline geprüft. Ditanas Vorteil gegenüber einem ungeprüften Neubau-Dienst ist real, aber begrenzt, und die Grenze zu benennen, gehört zur Behauptung dazu.

Der Installationstest

Eine Paketquelle zu bauen und zu signieren, ist nicht dasselbe, wie aus ihr installieren zu können. Zwischen der Test-Paketquelle und der Veröffentlichung liegt ein weiterer Schritt: Der Build-Host installiert genau diese Paketquelle unbeaufsichtigt in eine eigene virtuelle Maschine, gesteuert von einer Antwortdatei auf einem kleinen Konfigurationslaufwerk – derselbe Mechanismus, den ein Hosting-Anbieter über PXE verwenden würde; deshalb werden keine Tastatureingaben simuliert.

Zwei Dinge müssen zutreffen, und die Aufzeichnung gibt an, welches davon erreicht wurde.

Stufe	Was geschehen war
installing	Das Medium läuft. Es wurde noch nichts installiert.
installed	Das Installationsprogramm hat seinen letzten Neustart erreicht.
booted	Das installierte System ist von selbst hochgefahren und hat auf Port 22 geantwortet. Das gilt als bestanden.

Die Unterscheidung ist wichtig, weil die beiden Fehlschläge verschiedene Fehler sind. Ein Durchlauf, der bei installing anhält, hat eine Paketquelle erzeugt, aus der niemand installieren kann. Einer, der bei installed anhält, hat ein System erzeugt, das korrekt geschrieben wurde und nicht hochfährt, und das ist die Art von Mangel, die kein noch so gründliches Bauen findet.

booted zu erreichen, bedeutet weit mehr, als der Ausdruck vermuten lässt. Der Bootloader lief, das initramfs fand und importierte den ZFS-Pool, systemd erreichte den Mehrbenutzermodus, das Netzwerk wurde aktiv, und ein Dienst startete. Nichts wird in den Gast eingeschleust, um irgendeinen dieser Schritte herbeizuführen: install-openssh ist standardmässig aktiviert, sodass ein Banner auf Port 22 das eigene Werk des installierten Systems ist.

Wenn der Test fehlschlägt, enthält die Aufzeichnung ein Bild des Gastbildschirms in dem Moment, in dem die Testumgebung aufgegeben hat. Das Installationsmedium schreibt nichts mehr auf eine serielle Konsole, sobald sein Bootloader übergeben hat; alles, was das Installationsprogramm darstellt, ist also auf diesem Bildschirm und nirgends sonst – ein Installationsprogramm, das bei einer Frage wartet, ist dort zu sehen und in keinem Protokoll.

Ein fehlgeschlagener Test veröffentlicht nichts. Die Pakete bleiben in der Test-Paketquelle, und die Paketquelle, aus der Sie installieren, bleibt unberührt.

Wo der Signaturschlüssel liegt

Der Rechner, der baut, besitzt einen Signatur-Unterschlüssel, nicht den Hauptschlüssel.

Er baut, signiert mit diesem Unterschlüssel, lädt in die Test-Paketquelle hoch, installiert diese Paketquelle in eine virtuelle Maschine und veröffentlicht nur dann in die Produktion, wenn die Installation funktioniert hat. Den Schlüssel vom Build-Host fernzuhalten, unterstützt die Pipeline weiterhin, und so arbeitete Ditana bis August 2026; das wurde aufgegeben, weil eine Veröffentlichung, die an eine Testinstallation geknüpft ist, auf dem Rechner stattfinden muss, der gerade gebaut hat, und durch die Trennung ein zweiter Rechner und ein manueller Schritt dazwischen lagen. Was der Unterschlüssel stattdessen bringt: Er kann für sich allein widerrufen und ersetzt werden, er kann keine weiteren Schlüssel zertifizieren, und der Fingerabdruck, anhand dessen Benutzerinnen und Benutzer überprüfen, ändert sich nie.

Was dies schützt, ist der Schlüssel, nicht die Pakete: Der signierende Rechner signiert, was der Build-Host erzeugt hat, ohne es zu prüfen. Was es verhindert, ist, dass der Rechner, der fremde Build-Skripte ausführt, jederzeit beliebige Daten signieren lassen kann.

Selbst überprüfen

Die Aufzeichnung ist reines JSON und wird nicht von dieser Website erzeugt:

• /build-history/index.json – der fortlaufende Index der jüngsten Durchläufe.
• /build-history/<timestamp>.json – eine Datei pro Durchlauf: outcome, message, counts, ein Objekt test-install, wenn ein Durchlauf getestet wurde, und ein Array packages, dessen Einträge name, status, seconds, gegebenenfalls detail und die Pfade der Protokolle dieses Pakets enthalten.
• Das Objekt test-install enthält result, die stage, die der Gast erreicht hat, das iso und die answer-file, mit denen er gesteuert wurde, und, falls die Installation fehlgeschlagen ist, einen Pfad screenshot unter /build-history/logs/<timestamp>/test-install/ mit dem Bildschirm des Gastes in dem Moment, in dem die Testumgebung aufgegeben hat.
• /build-history/logs/<timestamp>/<package>/ – was makepkg beim Bauen dieses Pakets protokolliert hat, nach Stufe aufgeteilt (prepare, build, check, package). Jedes neu gebaute Paket eines Durchlaufs ist von seiner Zeile oben verlinkt, und auch ein Paket, dessen Build fehlgeschlagen ist, wird protokolliert – das ist dasjenige, das sich zu lesen lohnt.

Servernamen, Adressen, Pfade und der Anmeldename des Build-Kontos werden aus den Aufzeichnungen und aus den Protokollen entfernt, bevor sie geschrieben werden. Sonst wird nichts gefiltert; der Fehlertext, den Sie sehen, ist der Fehlertext, den die Pipeline gesehen hat.

Unter welchen Lizenzen

Jedes Paket hier wird aus einem öffentlich verfügbaren Rezept gebaut, das seine Upstream-Quelle nennt. Lizenzen gibt an, wo beides zu finden ist, und behandelt den einen Fall, in dem die Lizenz selbst umstritten ist: die ZFS-Pakete, von denen Ditana die Quellen und die Userspace-Werkzeuge verteilt, aber nie ein kompiliertes Kernelmodul.