État des compilations

Ditana entretient son propre dépôt pacman en complément d’Arch – 59 paquets, listés intégralement dans chaque exécution arrivée à son terme. Une exécution qui s’est arrêtée liste ceux qu’elle avait atteints. Chaque nuit, une machine de compilation récupère la recette de chaque paquet, détermine ce qui doit être recompilé et le compile dans un conteneur vierge. La règle qui régit la suite est la seule qui compte ici :

Si un seul paquet ne peut pas être compilé, ou si ses sources ne peuvent pas être vérifiées, rien n’est publié.

Pas « le reste est publié et celui-là sera réessayé demain ». Rien. Le dépôt à partir duquel vous installez est soit l’ensemble complet et cohérent issu d’une seule exécution, soit l’ensemble complet et cohérent de la veille. Un dépôt plus petit peut le promettre ; un grand dépôt, mis à jour paquet par paquet, ne le peut pas – c’est pourquoi Ditana garde le sien assez petit pour pouvoir s’en porter garant comme un seul ensemble.

Une telle affirmation vaut exactement ce que valent ses preuves, c’est pourquoi le registre ci-dessous est rédigé par la chaîne de compilation elle-même, y compris les exécutions où rien n’a été publié. Cette chaîne est ditana-build, et elle est publique : la barrière de revue est bin/pkgbuild-review-gate, et le test d’installation est bin/test-install-in-qemu.

Chargement du registre des compilations…

Jusqu’où une exécution est allée

Chaque exécution passe par les mêmes étapes, et son outcome indique laquelle elle a atteinte. Voici les quatre états, ainsi que les couleurs employées ci-dessus :

outcome	Ce que cela signifie pour vous
released	C’est ce que vous installez. Chaque paquet a été compilé, chaque signature vérifiée, et l’ensemble complet a remplacé le dépôt à partir duquel votre système se met à jour.
in-testing	Compilé et signé, l’ensemble se trouve dans un dépôt de test séparé le temps d’être vérifié. Votre système installe toujours la version précédente.
built	La machine de compilation a terminé, mais elle ne détient aucune clé de signature – la signature a lieu ensuite sur une autre machine. Rien n’a encore bougé.
held-back	Quelque chose a échoué, si bien que rien du tout n’a été publié. Le dépôt à partir duquel vous installez est intact et toujours cohérent.

Seul released signifie que les paquets vous sont parvenus. Les trois autres sont des étapes en chemin, ou un arrêt.

Ce qu’il est advenu de chaque paquet

Au sein d’une exécution, chaque paquet reçoit un seul status :

status	Signification
current	La recette n’a pas changé depuis la compilation du paquet existant et, pour un paquet -git, le commit amont n’a pas bougé non plus. Rien à faire.
rebuilt	Les sources ont été récupérées et vérifiées sur la machine de compilation, puis le paquet a été compilé dans un conteneur neuf.
review-stopped	La recette a changé d’une manière qu’une personne doit examiner. L’exécution s’arrête là.
build-failed	Le paquet n’a pas pu être compilé, ou n’a produit aucun artefact. L’exécution s’arrête là.

Ce sont les deux derniers qui font qu’une exécution se termine en held-back : un seul paquet suffit.

Pourquoi une exécution s’arrête

L’essentiel de ce que Ditana recompile, ce sont des recettes tierces de l’AUR, empaquetées dans un dépôt auquel ses utilisateurs font confiance par le biais de la configuration des signatures de pacman. L’AUR est une chaîne d’approvisionnement, et il a été attaqué comme telle : des paquets orphelins ont été adoptés puis ont reçu des commits malveillants, c’est pourquoi l’AUR a désactivé l’adoption et les envois en août 2026.

C’est pourquoi chaque git pull de la chaîne de compilation est classé avant que quoi que ce soit ne soit compilé. Les changements de numéro de version, les commentaires, les caractères d’espacement et les sommes de contrôle qui accompagnent un changement de version sont acceptés d’office. Une modification de source=, d’une url=, d’une révision VCS, de quoi que ce soit à l’intérieur d’une fonction, de install=, de provides=, conflicts=, replaces= ou validpgpkeys=, une somme de contrôle qui change sans que la version change, une nouvelle dépendance que pacman ne connaît pas, une ligne # Maintainer: modifiée ou vidée – chacun de ces cas arrête l’exécution. Pour cela, la recette n’est jamais chargée dans un shell : exécuter le fichier suspect est précisément ce qu’il faut éviter ; l’analyse est donc statique et, lorsqu’elle a un doute, elle bloque.

Sur les douze derniers mois de l’historique réel des paquets, cela arrête une exécution environ une fois tous les trois jours et demi. Ce n’est pas un défaut qu’il faudrait éliminer par des ajustements ; c’est le prix de la règle du tout ou rien, payé d’avance.

Certaines des recettes que Ditana recompile n’ont aucun mainteneur amont – leur ligne # Maintainer: est vide. C’est pourquoi une ligne de mainteneur vidée arrête une exécution au lieu d’être acceptée d’office : une recette orpheline est précisément celle que quelqu’un peut adopter.

Ce que cela ne vérifie pas

La revue porte sur les métadonnées d’empaquetage, pas sur le code source amont. Lorsqu’une recette compile à partir d’une révision git, le contenu de cette révision n’est examiné par aucun élément de cette chaîne. L’avantage de Ditana sur un service de recompilation sans revue est réel mais limité, et énoncer cette limite fait partie de l’affirmation.

Le test d’installation

Compiler et signer un dépôt n’est pas la même chose que pouvoir installer à partir de celui-ci. Entre le dépôt de test et la publication, il y a une étape de plus : la machine de compilation installe ce même dépôt dans sa propre machine virtuelle, sans surveillance, à l’aide d’un fichier de réponses situé sur un petit lecteur de configuration – le même mécanisme qu’un hébergeur utiliserait via PXE, ce qui explique qu’aucune frappe au clavier ne soit simulée.

Deux conditions doivent être remplies, et le registre indique laquelle d’entre elles a été atteinte.

Étape	Ce qui s’était passé
installing	Le support d’installation est en cours d’exécution. Rien n’a encore été installé.
installed	Le programme d’installation a atteint son redémarrage final.
booted	Le système installé a démarré de lui-même et a répondu sur le port 22. Le test est réussi.

La distinction est importante, car les deux échecs correspondent à des bogues différents. Une exécution qui s’arrête à installing a produit un dépôt à partir duquel personne ne peut installer. Une exécution qui s’arrête à installed a produit un système qui a été écrit correctement et qui ne démarre pas, et c’est le genre de défaut qu’aucune compilation, aussi poussée soit-elle, ne permet de détecter.

Atteindre booted signifie bien davantage que ce que l’expression laisse entendre. Le chargeur d’amorçage s’est exécuté, l’initramfs a trouvé et importé le pool ZFS, systemd a atteint le mode multi-utilisateur, le réseau est devenu actif et un service a démarré. Rien n’est injecté dans le système invité pour provoquer l’une ou l’autre de ces actions : install-openssh est activé par défaut, de sorte qu’une bannière sur le port 22 est l’œuvre du système installé lui-même.

Lorsque le test échoue, le registre contient une image de l’écran du système invité au moment où le banc de test a abandonné. Le support d’installation n’écrit rien sur une console série une fois que son chargeur d’amorçage a passé la main ; tout ce que le programme d’installation affiche se trouve donc sur cet écran et nulle part ailleurs – un programme d’installation qui attend devant une question y est visible, et n’apparaît dans aucun journal.

Un test échoué ne publie rien. Les paquets restent dans le dépôt de test, et le dépôt à partir duquel vous installez reste intact.

Où se trouve la clé de signature

La machine qui compile détient une sous-clé de signature, pas la clé principale.

Elle compile, signe avec cette sous-clé, envoie les paquets vers le dépôt de test, installe ce dépôt dans une machine virtuelle et ne publie en production que si l’installation a fonctionné. Tenir la clé à l’écart de la machine de compilation est une configuration que la chaîne prend toujours en charge, et c’est ainsi que Ditana fonctionnait jusqu’en août 2026 ; cette pratique a été abandonnée parce qu’une publication conditionnée par une installation de test doit avoir lieu sur la machine qui vient de compiler, et la séparation intercalait une deuxième machine et une étape manuelle. Ce que la sous-clé apporte en contrepartie : elle peut être révoquée et remplacée isolément, elle ne peut pas certifier d’autres clés, et l’empreinte avec laquelle les utilisateurs effectuent leur vérification ne change jamais.

Ce que cela protège, c’est la clé, pas les paquets : la machine de signature signe ce que la machine de compilation a produit, sans l’examiner. Ce que cela empêche, c’est que la machine qui exécute des scripts de compilation étrangers puisse faire signer des données arbitraires à tout moment.

Vérifier par vous-même

Le registre est du simple JSON et n’est pas généré par ce site web :

• /build-history/index.json – l’index glissant des exécutions les plus récentes.
• /build-history/<timestamp>.json – un fichier par exécution : outcome, message, counts, un objet test-install lorsqu’une exécution a été testée, et un tableau packages dont les entrées contiennent name, status, seconds, un éventuel detail et les chemins des journaux de ce paquet.
• L’objet test-install contient result, le stage atteint par le système invité, l’iso et l’answer-file avec lesquels il a été piloté et, si l’installation a échoué, un chemin screenshot sous /build-history/logs/<timestamp>/test-install/ contenant l’écran du système invité au moment où le banc de test a abandonné.
• /build-history/logs/<timestamp>/<package>/ – ce que makepkg a consigné dans le journal pendant la compilation de ce paquet, réparti par étape (prepare, build, check, package). Chaque paquet recompilé lors d’une exécution est accessible par un lien depuis sa ligne ci-dessus, et un paquet dont la compilation a échoué a lui aussi son journal – c’est celui qui mérite d’être lu.

Les noms de serveurs, les adresses, les chemins et le nom de connexion du compte de compilation sont retirés des registres et des journaux avant leur écriture. Rien d’autre n’est filtré ; le texte d’erreur que vous voyez est celui que la chaîne de compilation a vu.

Sous quelles licences

Chaque paquet présenté ici est compilé à partir d’une recette accessible au public qui indique sa source amont. La page Licences indique où trouver l’une et l’autre, et traite le seul cas où la licence elle-même est contestée : les paquets ZFS, dont Ditana distribue les sources et les outils de l’espace utilisateur, mais jamais un module du noyau compilé.