Mohammed Adnène Trojette <adn+deb@diwi.org> (23/05/2005): > J'ai mis le temps pour celui-là. > Merci d'avance aux relecteurs. De rien :-) -- Cyril Brulebois
--- wanna-build-states.wml.orig 2005-05-23 16:22:48.000000000 +0200
+++ wanna-build-states.wml 2005-05-23 16:50:18.231385016 +0200
@@ -11,7 +11,7 @@
<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>
+ parle pas de tout de ce qui est mentionné dans ce document.</p>
<h2>Les états de <tt>wanna-build</tt></h2>
@@ -48,7 +48,7 @@
<em>required</em> sont empaquetés avant les paquets avec
priorité <em>extra</em>) ;
</li>
- <li>la section dans laquelle se trouve le paquet. Cette ordre
+ <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
@@ -60,7 +60,7 @@
</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
+ 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
@@ -87,7 +87,7 @@
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
+ 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>
@@ -96,7 +96,7 @@
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'envoie au serveur d'empaquetage automatique. Par conséquent,
+ 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
@@ -115,7 +115,7 @@
<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> Alors, dans deux cas spécifiques; il
+ disponibles.<br> Alors, dans deux cas spécifiques, il
se peut 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>
@@ -132,7 +132,7 @@
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 quand il est précisé que <tt>baz</tt> attend
+ l'ajouter 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é
par les responsables du portage <tt>m68k</tt> eux-mêmes.
@@ -146,8 +146,8 @@
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 ainsi
- de telle manière que les empaquetages qui écoueront inévitablement
+ 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 à
@@ -157,12 +157,12 @@
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 noms, section, urgence et priorité sont examinés. Ainsi,
+ seuls les nom, section, urgence 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
@@ -177,7 +177,7 @@
entretenir, <em>not-for-us</em> est désormais déprécié ;
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 architecture
+ 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
@@ -218,8 +218,8 @@
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.
- Dut le paquet réapparaître dans un fichier Packages lié à
- wanna-build suivant, il repassera alors de <em>failed-removed</em>
+ Si le paquet venait à réapparaître dans un fichier Packages lié à
+ wanna-build suivant, il repasserait 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>
<p>
@@ -251,7 +251,7 @@
<p>
Quand un paquet est empaqueté par sbuild (le composant du
service d'empaquetage qui effectue l'empaquetage proprement dit),
- une journal avec le résultat de l'empaquetage est envoyé par mail
+ 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
http://buildd.debian.org). Le résultat du journal d'empaquetage
@@ -270,13 +270,13 @@
<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 renerra au serveur
+ <code>.change</code> embarqué, le signera et le renverra au serveur
d'empaquetage automatique, ce qui provoquera le déchargement le
paquet.
</dd>
<dt><a name="failed">failed</a></dt>
<dd>L'empaquetage a échoué. Comme il peut y avoir un grand nombre
- de raisons pour qu'un empaquetage échoue, les énumérer tous serait
+ 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 devrez lire ce qui précède et
vérifier son état wanna-build actuel.
Attachment:
signature.asc
Description: Digital signature