Les états de wanna-build : une explication

Cette page tente d'expliquer ce que chaque état wanna-build signifie et ce qui arrivera à un paquet quand il sera dans cet état. Son audience cible est constituée des responsables de paquets Debian qui essaient de comprendre pourquoi leur paquet a, ou n'a pas, été empaqueté pour une architecture spécifique. Une explication des différents résultats de journalisation est aussi fournie.

En cas de besoin de reconstruction de paquet, il est possible de demander des actions wanna-build

Finalement, un diagramme des états de wanna-build est disponible, mais veuillez noter qu'il ne parle pas de tout ce qui est mentionné dans ce document.

Les états de `wanna-build`

Pour chaque architecture prise en charge par Debian, une base de données wanna-build est installée sur buildd.debian.org, avec tous les paquets et leur état actuel de compilation. Il y a huit états : needs-build, building, uploaded, dep-wait, BD-Uninstallable, failed, not-for-us et installed.

Voici leurs significations :

needs-build

Un paquet marqué needs-build a vu un envoi de sa nouvelle version par son responsable, mais pour une architecture différente de celle de la base de données wanna-build ; dans ce cas, un réempaquetage est nécessaire. Si l'état est needs-build, aucun serveur d'empaquetage automatique ne l'a récupéré, mais il le sera (une fois qu'un serveur sera disponible lorsque le paquet sera proche du haut de la liste). Les gens ont l'habitude de dire qu'un paquet fait la queue pour un réempaquetage quand ils parlent d'un paquet dans l'état needs-build.
Il peut être intéressant de noter que la file d'attente needs-build n'est pas une liste FIFO (premier entré premier servi) ; en fait, l'ordre utilisé se base sur les critères suivants :

les états des précédentes compilations des paquets ; les paquets qui ont été précédemment empaquetés obtiennent une priorité plus grande que les nouveaux paquets ;
les priorités (les paquets avec priorité required sont empaquetés avant les paquets avec priorité extra) ;
la section dans laquelle se trouve le paquet. Cet ordre est basé sur l'importance donnée aux paquets ; par exemple, la section games est empaquetée après la section base, et la section libs avant devel ;
l'ordre croissant de code ASCII des lettres du nom du paquet.

De plus, dans certaines conditions, il peut arriver qu'un serveur d'empaquetage ne prenne pas les paquets du haut de la file d'attente ; par exemple, quand un serveur d'empaquetage ne peut pas trouver les sources d'un paquet donné, il le rétrogradera dans la file (où il reprendra son ancien rang, à savoir le haut de la file), mais il ignorera le paquet pendant quelques heures. Un autre exemple où cela peut arriver est au moment où une architecture possède plusieurs serveurs d'empaquetage automatique ; dans ce cas, les responsables du portage de cette architecture peuvent choisir d'empaqueter les gros paquets sur leurs serveurs d'empaquetage automatique les plus rapides et laisser les paquets plus petits aux machines les plus lentes du parc. Un serveur d'empaquetage peut aussi théoriquement demander explicitement un ordre de sections différent, mais ce n'est pas fait d'habitude.
Il peut exister d’autres situations où l’ordre de la file d’attente semble être ignoré, mais remarquez que ce sont toutes des exceptions.

building

Un paquet est marqué building à partir du moment où un serveur d'empaquetage automatique le récupère du haut de la file d'attente de wanna-build jusqu'au moment où un administrateur du serveur d'empaquetage automatique répond au journal. Comme les paquets ne sont pas récupérés un par un, cela signifie qu'un paquet peut (et c'est habituellement le cas) être marqué building avant que l'empaquetage ait effectivement démarré ; cependant, comme le service d'empaquetage empaquette dans ses files d'attente locales sur la base d'une liste FIFO, cela ne devrait plus mettre très longtemps. Veuillez aussi noter que l'état d'un paquet n'est pas modifié une fois l'empaquetage terminé ; cela ne se fera que lorsque l'administrateur du serveur d'empaquetage automatique aura répondu au journal.

uploaded

Quand une tentative d'empaquetage réussit, un journal d'empaquetage est envoyé à l'administrateur du serveur d'empaquetage automatique et à buildd.debian.org. Le responsable du serveur d'empaquetage automatique signera alors le fichier .changes qui se trouve dans le journal d'empaquetage, et l'enverra au serveur d'empaquetage automatique. Par conséquent, le serveur d'empaquetage automatique enverra le paquet et le mettra dans l'état uploaded. Dans ce cas, un paquet dans cet état peut se trouver (quelque part) dans la file en attente.
Un serveur d'empaquetage automatique ne touchera plus un paquet une fois que son état est uploaded, tout du moins pas avant l'envoi suivant, ou avant qu'un porteur ne modifie lui-même l'état du paquet.

dep-wait

Quand un empaquetage échoue à cause de dépendances manquantes au moment de la construction, le responsable du serveur d'empaquetage automatique enverra un courriel au serveur d'empaquetage automatique, lui donnant comme instruction de supprimer les sources du paquet et de marquer le paquet comme dep-wait sur les dépendances manquantes. Un paquet dans un tel état sera automatiquement, sans intervention humaine, marqué needs-build une fois que les dépendances seront disponibles.
Originellement, un paquet devait subir une tentative d'empaquetage avant que le responsable ne le mette lui-même dans l'état dep-wait. Cependant, en août 2005, du code permettant de déplacer directement, si cela est approprié, un paquet de l'état installed à l'état dep-wait a été ajouté à wanna-build.
Il se peut, dans deux cas spécifiques, qu'un paquet soit définitivement marqué comme dep-wait ; cela se produit quand on fait une faute de frappe en spécifiant les dépendances dep-wait (si bien que le paquet est marqué dep-wait par rapport à un paquet qui n'existe pas et n'existera jamais) et quand une dépendance est déclarée au moment de la construction pour un paquet qui est marqué not-for-us ou qui est dans la liste packages-arch-specific.
Dans ce dernier cas, par exemple, considérons trois paquets : un paquet foo, qui n'existe que sur i386 ; un paquet bar, qui n'existe que pour m68k (et qui fait à peu près la même chose) ; et un paquet baz qui peut être empaqueté avec soit foo soit bar. Si le responsable du paquet baz oublie l'ajout de bar aux dépendances d'empaquetage (Build-Depends), et s’il l'ajoute quand il est précisé que baz attend (dep-wait) un paquet foo inexistant pour m68k, alors l'état dep-wait devra être modifié par les responsables du portage m68k eux-mêmes.

BD-Uninstallable

Pendant la conférence des développeurs Debian 2009, Joachim Breitner a émis l'idée d'utiliser edos-debcheck pour vérifier la possibilité d’installation des dépendances de construction des paquets qui autrement se mettraient dans l’état needs-build. À ce moment, wanna-build a déjà la possibilité de vérifier la disponibilité immédiate des dépendances de construction ; mais si un paquet ne peut pas être installé parce qu'il possède une dépendance de construction sur a qui dépend de b qui dépend de c (>=1.2.3) et que c est toujours en version 1.2.2, ce ne sera pas détecté, et la construction échouera dès le début à cause des dépendances de construction non disponibles. Se rendre compte de ce genre de cas était un processus non automatique à la charge de l'administrateur du serveur d'empaquetage, et en général, plutôt interminable. Avec le correctif BD-Uninstallable, ce n'est plus un problème. Quand un paquet est en BD-Uninstallable, cela signifie que ses dépendances de construction ne peuvent pas être installées (soit directement, soit parce qu'une partie de son arborescence de dépendances n'est pas disponible). Malheureusement, le correctif BD-Uninstallable, ne fournit pas de renseignements sur le paquet exact qui pose problème ; veuillez utiliser edos-debcheck pour le déterminer. Ce problème, cependant, se réglera de lui-même dès que les dépendances manquantes seront vraiment disponibles, et à ce moment, le paquet sera de nouveau déplacé en needs-build.

failed

Si une tentative d'empaquetage échoue et que le responsable du serveur d'empaquetage automatique décide que cela constitue réellement un échec qui ne doit pas être retenté, le paquet est marqué failed. Un paquet ne quittera jamais cet état avant qu'un responsable de portage décide qu'il devrait le faire, ou avant qu'une nouvelle version ne soit disponible. Cependant, quand une nouvelle version d'un paquet anciennement marqué failed sera disponible, le serveur d'empaquetage automatique demandera à son administrateur si l'empaquetage doit être retenté ; c'est de cette manière que les empaquetages qui échoueront inévitablement ne vont pas faire perdre du temps au serveur d'empaquetage. Même si le fait de mettre un paquet dans l'état failed avant même d'essayer l'empaquetage n'est pas forcément la bonne chose à faire, cette option reste disponible à l'administrateur du serveur d'empaquetage automatique.
Veuillez noter qu'un paquet ne sera jamais marqué failed sans intervention humaine.

not-for-us

Certains paquets spécifiques ne sont pas dédiés à toutes les architectures ; par exemple, lilo, un gestionnaire d'amorçage pour i386, ne doit pas être empaqueté pour alpha, m68k, ou s390. Cependant, wanna-build ne regarde pas dans le fichier de contrôle (debian/control) d'un paquet en créant sa base de données ; seuls les nom, section, état précédent et priorité sont examinés. Ainsi, avec le premier envoi d'un paquet spécifique à une ou des architectures qui ne doit pas être empaqueté sur d'autres architectures, une tentative d'empaquetage est néanmoins lancée (mais échoue avant même que les dépendances d'empaquetage ne soient téléchargées et/ou installées).
Comme les serveurs d'empaquetage automatique ne devraient pas perdre de temps à essayer d'empaqueter des paquets qui ne sont pas requis par leur architecture, il faut trouver un moyen de lister les paquets pour lesquels même une tentative d'empaquetage n’est pas nécessaire. La première solution à ce problème était not-for-us ; cependant, comme il est difficile à entretenir, not-for-us est désormais obsolète ; les responsables des serveurs d'empaquetage automatique doivent plutôt utiliser packages-arch-specific, qui est une liste des paquets spécifiques à une ou plusieurs architectures plutôt qu'un état wanna-build.
Un paquet dans l'état not-for-us ou dans l'état packages-arch-specific ne quittera pas cet état automatiquement ; si votre paquet a précédemment exclu une architecture donnée dans son fichier de contrôle, alors qu'il inclut aujourd'hui plus d'architectures, il doit être réintégré dans la file d’attente à la main.
S'il se trouve que vous deviez demander vous-même que cela se produise, vous pouvez le faire en contactant les responsables du serveur de construction adéquat. Ils peuvent être joints à l'adresse $arch@buildd.debian.org

installed

Comme le nom le suggère, un paquet marqué installé est compilé pour l'architecture à laquelle est dédiée la base de données wanna-build. Avant la publication de Woody, l'état d'un paquet passait d'uploaded à installed après l'exécution quotidienne de katie. Avec l'implémentation de Accepted-autobuild, toutefois, cela n'est plus vrai ; aujourd'hui, un paquet passe de l'état uploaded à l'état installed quand il a été accepté dans l'archive. Cela veut dire qu'un paquet est habituellement marqué installed au bout de quinze minutes, en moyenne.

En plus de ces huit états, wanna-build connaît aussi deux états de suppression (-removed), qui sont vraiment des cas marginaux. Ces deux états sont dep-wait-removed et failed-removed. Ils correspondent à leurs alter ego respectifs sans -removed comme suit : quand un paquet dans l'état failed ou dep-wait n'apparaît pas dans un nouveau fichier Packages qui est alimenté par wanna-build – quand il se trouve qu'il a été supprimé – l'information au sujet de ce paquet n'est pas supprimée, parce qu'il se pourrait que le fait que le paquet n'apparaisse pas dans le fichier Packages ne soit qu’un problème temporaire ou que le paquet ait été temporairement supprimé pour une raison ou pour une autre (mais qu'il réapparaisse dans l'archive, au bout d'un certain temps). Au lieu de cela, dans un tel cas, un paquet passe à un état -removed, afin que l'information concernant les raisons de son échec ou ce qu'il attend puissent être conservés. Si le paquet vient à réapparaître dans un fichier Packages fourni à wanna-build, il repassera alors de failed-removed à failed, ou de dep-wait-removed à dep-wait avant un traitement ultérieur.

Il n'est pas possible d'accéder à la base de données wanna-build directement ; cette base de données est installée sur ftp-master.debian.org, qui est un hôte restreint, et seuls les serveurs d'empaquetage automatiques ont une clé SSH qui leur permet d'accéder à la base de données wanna-build correspondant à leur architecture. C'était le cas bien avant que ftp-master ne soit restreint ; comme wanna-build pose un verrou au niveau de la base de données pendant un accès, ne serait-ce qu'en lecture, aux données, vous deviez être dans le bon groupe (wb-<arch>) pour pouvoir accéder directement à la base de données wanna-build.

Cela étant dit, vous pouvez voir l'état d'un paquet en allant sur la page de statistiques du service d'empaquetage, sauf s'il est dans l'état installed (à moins que vous ne répugniez pas à fouiller à travers les fichiers <arch>-all.txt gros de plusieurs mégaoctets).

Le résultat des journaux d'empaquetage

Quand un paquet est empaqueté par sbuild (le composant du service d'empaquetage qui effectue l'empaquetage proprement dit), un journal avec le résultat de l'empaquetage est envoyé par mail à l'administrateur du serveur d'empaquetage automatique et à logs@buildd.debian.org (afin qu'il puisse atterrir sur https://buildd.debian.org). Le résultat du journal d'empaquetage peut être successful, attempted (auparavant appelé failed), given-back ou skipped. Veuillez noter que, sur la page résumant le journal du service d'empaquetage, le préfixe maybe- est ajouté, entre autres à cause du fait qu'un empaquetage peut y être marqué failed pour des raisons qui ne sont pas vraiment un échec, et que cela a provoqué de la confusion par le passé (ou, dans le cas contraire, parfois, un paquet qui a apparemment été empaqueté avec succès est vraiment cassé et doit être réempaqueté).

La signification des résultats de journal est la suivante :

successful: L'empaquetage a réussi. Quand le responsable du serveur d'empaquetage recevra le journal, il extraira le fichier .change incorporé, le signera et le renverra au serveur d'empaquetage automatique, ce qui provoquera l’envoi du paquet.
attempted (auparavant : failed): L'empaquetage s'est terminé avec un code de retour non nul, indiquant qu'il a probablement échoué. Comme il peut y avoir un grand nombre de raisons pour qu'un empaquetage échoue, les énumérer toutes serait ennuyeux, alors ce ne sera pas fait ici. Si l'un de vos paquets est marqué (maybe-)failed, vous devez lire ce qui précède et vérifier son état wanna-build actuel.
given-back: L'empaquetage a échoué à cause d'un problème temporaire avec le serveur d'empaquetage automatique ; ce sont par exemple des problèmes de réseau, l'inaccessibilité du source des paquets avec le source.list actuel, un espace disque faible, etc.
Un paquet qui est given-back est à nouveau marqué comme needs-build ; en tant que tel, il sera automatiquement pris par un serveur d'empaquetage automatique différent dès que l'un d'eux sera prêt.
skipped: Entre le moment où le paquet a été sélectionné par le/un serveur d'empaquetage automatique et marqué building et le moment où l'empaquetage a été tenté, une nouvelle version pour ce paquet a été envoyée, ou un responsable de portage a lui-même modifié l'état wanna-build pour une raison ou pour une autre. Cela fait, un courriel est envoyé au serveur d'empaquetage qui marquera le paquet comme ne devant pas être empaqueté ; sbuild prend en compte l'information, et sautera l'étape d'empaquetage (même si un journal d'empaquetage contenant ce résultat est envoyé, pour décrire le fait que cela s'est produit).

Version graphique

Afin d'illustrer ce qui précède, nous fournissons une version graphique de cette procédure. Veuillez bien noter une nouvelle fois qu'elle ne contient pas tout ce qui est mentionné dans ce document.