Bonjour,
Voici une mise à jour de la page :
https://www.debian.org/devel/buildd/wanna-build-states
Les fichiers sont aussi ici :
https://salsa.debian.org/webmaster-team/webwml/raw/master/french/devel/buildd/wanna-build-states.wml
https://salsa.debian.org/webmaster-team/webwml/raw/master/english/devel/buildd/wanna-build-states.wml
Merci d’avance pour vos relectures et commentaires.
Amicalement.
--
Jean-Paul
--- wanna-build-states.wml.orig 2023-10-05 20:13:42.073716944 +0200
+++ wanna-build-states.wml 2023-10-05 22:37:10.761539212 +0200
@@ -1,5 +1,5 @@
#use wml::debian::template title="Les états de wanna-build : une explication" BARETITLE="true"
-#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28" maintainer="David Prévot"
+#use wml::debian::translation-check translation="e94a8736fb66463fe305fff8fd1d7c61341d298d" maintainer="David Prévot"
# Translators:
# Mohammed Adnène Trojette, 2005-2007.
@@ -12,19 +12,23 @@
architecture spécifique. Une explication des différents résultats
de journalisation est aussi fournie.</p>
- <p>Finalement, un diagramme des états de <tt>wanna-build</tt> est
+ <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 supportée par Debian, une base de données
+<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>
+<em>not-for-us</em> et <em>installed</em>.</p>
<p>Voici leurs significations :</p>
<dl>
@@ -35,7 +39,7 @@
<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 alors que
+ 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
@@ -70,14 +74,17 @@
à 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
+ d'empaquetage automatique ; dans ce cas, les porteurs
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
+ 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
+ théoriquement demander explicitement un ordre de sections
différent, mais ce n'est pas fait d'habitude.<br />
- </dd>
+ 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
@@ -104,7 +111,7 @@
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 d'entrée, ou <q>incoming</q>.<br /> Un serveur
+ 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
@@ -124,35 +131,36 @@
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><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 par rapport à un paquet qui est marqué <em>not-for-us</em>, ou
+ 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>. Le responsable du
- paquet <tt>baz</tt> devant omettre l'ajout de <tt>bar</tt>
- aux dépendances d'empaquetage (<em>Build-Depends</em>), et
- l'ajouter quand il est précisé que <tt>baz</tt> attend
+ 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>, l'état <em>dep-wait</em> devra alors être modifié
+ <tt>m68k</tt>, alors l'état <em>dep-wait</em> devra alors ê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
- si les dépendances de construction des paquets peuvent être
- installées, avant de modifier leur état en <em>needs-build</em>.
- À ce moment, wanna-build a déjà la possibilité de vérifier la
+ la possibilité d’installation des dépendances de construction des
+ paquets qui autrement iraient 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
@@ -180,10 +188,10 @@
<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 reproduit, le paquet est
- marqué <em>failed</em> Un paquet ne quittera jamais cet état tant
+ marqué <em>failed</em>. 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é <em>failed</em> sera
+ nouvelle version d'un paquet anciennement marqué <em>failed</em> devient
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
@@ -196,13 +204,13 @@
humaine.
</dd>
<dt><a name="not-for-us">not-for-us</a></dt> <dd>Certains paquets
- spécifiques ne sont pas dédiées à toutes les architectures ;
+ 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 déchargement d'un paquet spécifique à une ou
+ 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
@@ -210,10 +218,10 @@
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
+ 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 déprécié ;
+ 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
@@ -222,8 +230,8 @@
<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'elle inclut aujourd'hui plus d'architectures, il
- doit être rempilé sur la queue <strong>à la main</strong>.<br />
+ 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
@@ -255,20 +263,20 @@
<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 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
+ n'apparaît pas dans le fichier Packages n'est qu’un problème temporaire
+ 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 <em>-removed</em>, 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 <em>failed-removed</em>
+ 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 traitement ultérieur.</p>
+ <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 une hôte restreint, et seuls les
+ 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
@@ -280,7 +288,7 @@
</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
+ statistiques du service d'empaquetage</a>, sauf s'il est dans
l'état <em>installed</em> (enfin, pas si vous ne répugnez pas à
fouiller à travers les fichiers <arch>-all.txt
gros de plusieurs mégaoctets).</p>
@@ -311,9 +319,8 @@
<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> embarqué, le signera et le renverra au serveur
- d'empaquetage automatique, ce qui provoquera le déchargement le
- paquet.
+ <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>
@@ -329,20 +336,20 @@
<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
+ 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 quand celui-ci sera prêt.
+ différent quand un sera prêt.
</dd>
<dt><a name="skipped">skipped</a></dt>
- <dd>Entre le temps où le paquet a été par le/un serveur
+ <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 où l'empaquetage a été
- tenté, une nouvelle version pour ce paquet a été déchargée, ou
+ 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. Quand cela est fait, un mail
- est envoyé au serveur d'empaquetage, qui marquera le paquet
+ pour une raison ou pour une autre. Quand cela est fait, un courriel
+ 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
@@ -353,6 +360,6 @@
<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'il ne contient pas tout ce qui
+Veuillez bien noter une nouvelle fois qu'elle ne contient pas tout ce qui
est mentionné dans ce document.
</p>
#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 porteurs
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 alors ê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 iraient 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 reproduit, le paquet est
marqué <em>failed</em>. 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é <em>failed</em> devient
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, 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
$a...@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 paquet qui
n'apparaît pas dans le fichier Packages n'est qu’un problème temporaire
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 <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> (enfin, pas si vous ne répugnez 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 à
l...@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 quand un 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. Quand cela est fait, un courriel
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).
</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>
commit e94a8736fb66463fe305fff8fd1d7c61341d298d
Author: Thomas Lange <la...@debian.org>
Date: Thu Oct 5 11:32:45 2023 +0200
add link to description of wanna-build actions, Closes #555967
diff --git a/english/devel/buildd/wanna-build-states.wml b/english/devel/buildd/wanna-build-states.wml
index ccdf6399fc1..490501d3a37 100644
--- a/english/devel/buildd/wanna-build-states.wml
+++ b/english/devel/buildd/wanna-build-states.wml
@@ -6,7 +6,9 @@
understand why their package has, or has not, been built for a
specific architecture. Also, an explanation of the different log
results is given.</p>
-
+ <p>
+ If you need a rebuild of your package, you can ask for <a href="https://release.debian.org/wanna-build.html";>wanna-build actions</a>
+ </p>
<p>Finally, a flowchart version of the wanna-build states is
<a href="#graphlink">available</a>, but do note that it doesn't talk
about everything mentioned in this document.</p>
