Re: [RFR] wml://devel/buildd/wanna-build-states.wml
Le 05/10/2023 à 22:42, JP Guillonneau a écrit :
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.
Bonjour,
Détails et suggestions
Amicalement
Lucien
--- wanna-build-states.wml.orig 2023-10-06 11:38:53.838146030 +0200
+++ wanna-build-states.wml 2023-10-06 13:29:36.237834456 +0200
@@ -67,21 +67,21 @@
</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
+ 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>
@@ -144,29 +144,29 @@
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é
+ <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 iraient dans l’état <em>needs-build</em>.
+ 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.
@@ -180,25 +180,25 @@
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
+ 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> devient
+ 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.
@@ -210,21 +210,21 @@
<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
+ 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
@@ -255,24 +255,24 @@
<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
+ 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
@@ -282,21 +282,21 @@
à 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 à
+ l'état <em>installed</em> (à moins quq 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
@@ -333,31 +333,31 @@
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.
+ 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. Quand cela est fait, un courriel
+ 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 voit cela, et
+ 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
Reply to: