[RFR2] wml://devel/buildd/wanna-build-states.wml
Bonjour,
Le 06/10/23 13:32 Lucien a écrit :
>Détails et suggestions
⇒patch
Voici la nouvelle version intégrant les propositions de Lucien.
Merci d’avance pour vos relectures et commentaires.
Amicalement
--
Jean-Paul
#use wml::debian::template title="Les états de wanna-build : une explication" BARETITLE="true"
#use wml::debian::translation-check translation="e94a8736fb66463fe305fff8fd1d7c61341d298d" maintainer="David Prévot"
# Translators:
# Mohammed Adnène Trojette, 2005-2007.
<p>Cette page tente d'expliquer ce que chaque état
<tt>wanna-build</tt> 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.</p>
<p>
En cas de besoin de reconstruction de paquet, il est possible de demander
des <a href="https://release.debian.org/wanna-build.html";>actions wanna-build</a>
</p>
<p>Finalement, un diagramme des états de <tt>wanna-build</tt> est
<a href="#graphlink">disponible</a>, mais veuillez noter qu'il ne
parle pas de tout ce qui est mentionné dans ce document.</p>
<h2>Les états de <tt>wanna-build</tt></h2>
<p>Pour chaque architecture prise en charge par Debian, une base de données
<tt>wanna-build</tt> est installée sur buildd.debian.org, avec tous les
paquets et leur état actuel de compilation. Il y a huit états :
<em>needs-build</em>, <em>building</em>, <em>uploaded</em>,
<em>dep-wait</em>, <em>BD-Uninstallable</em>, <em>failed</em>,
<em>not-for-us</em> et <em>installed</em>.</p>
<p>Voici leurs significations :</p>
<dl>
<dt><a name="needs-build">needs-build</a></dt>
<dd>Un paquet marqué <em>needs-build</em> 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
<tt>wanna-build</tt> ; dans ce cas, un réempaquetage
est nécessaire. Si l'état est <em>needs-build</em>, 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'<q>un paquet fait la queue pour un
réempaquetage</q> quand ils parlent d'un paquet dans l'état
<em>needs-build</em>.<br /> Il peut être intéressant de
noter que la file d'attente <em>needs-build</em> n'est pas une
liste FIFO (premier entré premier servi) ; en fait, l'ordre
utilisé se base sur les critères suivants :
<ol>
<li>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 ;
</li>
<li>les priorités (les paquets avec priorité
<em>required</em> sont empaquetés avant les paquets avec
priorité <em>extra</em>) ;
</li>
<li>la section dans laquelle se trouve le paquet. Cet ordre
est basé sur l'importance donnée aux paquets ; par
exemple, la section <em>games</em> est empaquetée après la
section <em>base</em>, et la section <em>libs</em> avant
<em>devel</em> ;
</li>
<li>l'ordre croissant de code ASCII des lettres du nom du
paquet.
</li>
</ol>
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.<br />
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.
</dd>
<dt><a name="building">building</a></dt>
<dd>Un paquet est marqué <em>building</em> à partir du moment où
un serveur d'empaquetage automatique le récupère du haut de la
file d'attente de <tt>wanna-build</tt> 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é <em>building</em> 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
<strong>n'</strong>est <strong>pas</strong> modifié une
fois l'empaquetage terminé ; cela ne se fera que lorsque
l'administrateur du serveur d'empaquetage automatique aura
répondu au journal.</dd>
<dt><a name="uploaded">uploaded</a></dt>
<dd>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 <em>uploaded</em>. Dans ce cas, un
paquet dans cet état peut se trouver (quelque part) dans la
file en attente.<br /> Un serveur
d'empaquetage automatique ne touchera plus un paquet une
fois que son état est <em>uploaded</em>, tout du moins pas
avant l'envoi suivant, ou avant qu'un porteur ne modifie
lui-même l'état du paquet.
</dd>
<dt><a name="dep-wait">dep-wait</a></dt>
<dd>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
<em>dep-wait</em> sur les dépendances manquantes. Un paquet dans
un tel état sera automatiquement, sans intervention humaine,
marqué <em>needs-build</em> une fois que les dépendances seront
disponibles.<br />
Originellement, un paquet devait subir une tentative d'empaquetage
avant que le responsable ne le mette lui-même dans l'état
<em>dep-wait</em>. Cependant, en août 2005, du code permettant
de déplacer directement, si cela est approprié, un paquet de l'état
<em><a href="#installed">installed</a></em> à l'état
<em>dep-wait</em> a été ajouté à wanna-build.<br />
Il se peut, dans deux cas spécifiques, qu'un paquet soit définitivement
marqué comme <em>dep-wait</em> ; cela se produit quand on fait une
faute de frappe en spécifiant les dépendances <em>dep-wait</em> (si
bien que le paquet est marqué <em>dep-wait</em> 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é
<em>not-for-us</em> ou
qui est dans la liste <em>packages-arch-specific</em>.<br />
Dans ce dernier cas, par exemple, considérons trois
paquets : un paquet <tt>foo</tt>, qui n'existe que sur
<tt>i386</tt> ; un paquet <tt>bar</tt>, qui n'existe
que pour <tt>m68k</tt> (et qui fait à peu près la même
chose) ; et un paquet <tt>baz</tt> qui peut être empaqueté
avec soit <tt>foo</tt> soit <tt>bar</tt>. Si le responsable du
paquet <tt>baz</tt> oublie l'ajout de <tt>bar</tt>
aux dépendances d'empaquetage (<em>Build-Depends</em>), et s’il
l'ajoute quand il est précisé que <tt>baz</tt> attend
(<em>dep-wait</em>) un paquet <tt>foo</tt> inexistant pour
<tt>m68k</tt>, alors l'état <em>dep-wait</em> devra être modifié
par les responsables du portage <tt>m68k</tt> eux-mêmes.
</dd>
<dt><a name="bd-uninstallable">BD-Uninstallable</a></dt>
<dd>Pendant la conférence des développeurs Debian 2009, <a
href='https://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Joachim
Breitner a émis l'idée</a> 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 <em>needs-build</em>.
À 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 <em>BD-Uninstallable</em>,
ce n'est plus un problème.
Quand un paquet est en <em>BD-Uninstallable</em>, 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 <em>BD-Uninstallable</em>,
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 <em>needs-build</em>.
</dd>
<dt><a name="wanna-build-state-failed">failed</a></dt>
<dd>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é <em>failed</em>. 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é <em>failed</em> 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 <em>failed</em> 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.<br /> Veuillez noter qu'un paquet ne sera
<strong>jamais</strong> marqué <em>failed</em> sans intervention
humaine.
</dd>
<dt><a name="not-for-us">not-for-us</a></dt> <dd>Certains paquets
spécifiques ne sont pas dédiés à toutes les architectures ;
par exemple, <tt>lilo</tt>, un gestionnaire d'amorçage pour i386,
ne doit pas être empaqueté pour alpha, m68k, ou s390. Cependant,
<em>wanna-build</em> 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).<br />
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
<em>not-for-us</em> ; cependant, comme il est difficile à
entretenir, <em>not-for-us</em> est désormais obsolète ;
les responsables des serveurs d'empaquetage automatique doivent
plutôt utiliser <em>packages-arch-specific</em>, qui est une
liste des paquets spécifiques à une ou plusieurs architectures
plutôt qu'un état wanna-build.<br />
Un paquet dans l'état <em>not-for-us</em> ou dans l'état
<em>packages-arch-specific</em> <strong>ne</strong> quittera
<strong>pas</strong> 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 <strong>à la main</strong>.<br />
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
</dd>
<dt><a name="installed">installed</a></dt>
<dd>Comme le nom le suggère, un paquet marqué <em>installé</em>
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'<em>uploaded</em> à <em>installed</em>
après l'exécution quotidienne de katie. Avec l'implémentation
de <a
href="https://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html";>Accepted-autobuild</a>,
toutefois, cela n'est plus vrai ; aujourd'hui, un paquet
passe de l'état <em>uploaded</em> à l'état <em>installed</em>
quand il a été accepté dans l'archive. Cela veut dire qu'un
paquet est habituellement marqué <em>installed</em> au bout de
quinze minutes, en moyenne.
</dd>
</dl>
<p>En plus de ces huit états, <em>wanna-build</em> connaît aussi
deux états de suppression (<q>-removed</q>), qui sont
vraiment des cas marginaux. Ces deux états sont
<em>dep-wait-removed</em> et <em>failed-removed</em>. Ils
correspondent à leurs alter ego respectifs sans
<q>-removed</q> comme suit : quand un paquet dans
l'état <em>failed</em> ou <em>dep-wait</em> n'apparaît pas dans un
nouveau fichier Packages qui est alimenté par
<em>wanna-build</em> – 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 <em>-removed</em>, 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 <em>failed-removed</em>
à <em>failed</em>, ou de <em>dep-wait-removed</em> à
<em>dep-wait</em> avant un traitement ultérieur.</p>
<p>
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.
</p>
<p>Cela étant dit, vous pouvez voir l'état d'un paquet en allant
sur <a href="https://buildd.debian.org/stats/";>la page de
statistiques du service d'empaquetage</a>, sauf s'il est dans
l'état <em>installed</em> (à moins que vous ne répugniez pas à
fouiller à travers les fichiers <arch>-all.txt
gros de plusieurs mégaoctets).</p>
<h2>Le résultat des journaux d'empaquetage</h2>
<p>
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 <em>successful</em>,
<em>attempted</em> (auparavant appelé <em>failed</em>),
<em>given-back</em> ou <em>skipped</em>. Veuillez noter que, sur
<a href="https://buildd.debian.org/";>la page résumant le journal
du service d'empaquetage</a>, le préfixe <em>maybe-</em> est
ajouté, entre autres à cause du fait qu'un empaquetage peut y être
marqué <em>failed</em> 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é).
</p>
<p>
La signification des résultats de journal est la suivante :
</p>
<dl>
<dt><a name="successful">successful</a></dt>
<dd>L'empaquetage a réussi. Quand le responsable du
serveur d'empaquetage recevra le journal, il extraira le fichier
<code>.change</code> incorporé, le signera et le renverra au serveur
d'empaquetage automatique, ce qui provoquera l’envoi du paquet.
</dd>
<dt><a name="failed">attempted</a> (auparavant : failed)</dt>
<dd>
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é <em>(maybe-)failed</em>, vous devez lire ce qui précède et
vérifier son état wanna-build actuel.
</dd>
<dt><a name="given-back">given-back</a></dt>
<dd>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.<br /> Un
paquet qui est <em>given-back</em> est à nouveau marqué comme <em><a
href="#needs-build">needs-build</a></em> ; 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.
</dd>
<dt><a name="skipped">skipped</a></dt>
<dd>Entre le moment où le paquet a été sélectionné par le/un serveur
d'empaquetage automatique et marqué <em><a
href="#building">building</a></em> 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).
</dd>
</dl>
<h2><a name="graphlink">Version graphique</a></h2>
<p>Afin d'illustrer ce qui précède, nous fournissons une <a
href="wanna-build.png">version graphique</a> de cette procédure.
Veuillez bien noter une nouvelle fois qu'elle ne contient pas tout ce qui
est mentionné dans ce document.
</p>
Reply to: