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.

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 supportée 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 alors que 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 :
  1. 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 ;
  2. les priorités (les paquets avec priorité required sont empaquetés avant les paquets avec priorité extra) ;
  3. 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 ;
  4. 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 portages 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 section différent, mais ce n'est pas fait d'habitude.
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 d'entrée, ou incoming.
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 par rapport à 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. Le responsable du paquet baz devant omettre l'ajout de bar aux dépendances d'empaquetage (Build-Depends), et l'ajouter quand il est précisé que baz attend (dep-wait) un paquet foo inexistant pour m68k, l'état dep-wait devra alors ê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 si les dépendances de construction des paquets peuvent être installées, avant de modifier leur état en needs-build. À ce moment, wanna-build a déjà la possibilité de vérifier la 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 reproduit, le paquet est marqué failed Un paquet ne quittera jamais cet état tant 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ées à 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 déchargement 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, un moyen de lister les paquets pour lesquels une tentative d'empaquetage ne sert à rien est 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 déprécié ; 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'elle inclut aujourd'hui plus d'architectures, il doit être rempilé sur la queue à 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 paquet qui n'apparaît pas dans le fichier Packages n'est que temporairement sauté, ou que le paquet est temporairement supprimé pour une raison ou pour une autre (mais qu'il réapparaîtra 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 puisse être récupérée. Si le paquet vient à réapparaître dans un fichier Packages lié à wanna-build suivant, il repassera alors de failed-removed à failed, ou de dep-wait-removed à dep-wait avant 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 une 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 (enfin, pas si vous ne répugnez 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 embarqué, le signera et le renverra au serveur d'empaquetage automatique, ce qui provoquera le déchargement le 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 quand celui-ci sera prêt.
skipped
Entre le temps où le paquet a été par le/un serveur d'empaquetage automatique et marqué building, et où l'empaquetage a été tenté, une nouvelle version pour ce paquet a été déchargée, ou un responsable de portage a lui-même modifié l'état wanna-build pour une raison ou pour une autre. Quand cela est fait, un mail est envoyé au serveur d'empaquetage, qui marquera le paquet comme ne devant pas être empaqueté ; sbuild voit cela, 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'il ne contient pas tout ce qui est mentionné dans ce document.