[continued from previous message]

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&nbsp;: 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>&nbsp;&ndash;&nbsp;quand il se trouve qu'il a
été supprimé&nbsp;&ndash;&nbsp;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&nbsp;; 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&nbsp;; 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-&lt;arch&gt;) 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 &lt;arch&gt;-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 à
[email protected] (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&nbsp;:
</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&nbsp;; 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>&nbsp;; 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é&nbsp;; 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.


commit e94a8736fb66463fe305fff8fd1d7c61341d298d
Author: Thomas Lange <[email protected]>
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>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)