(fr) Proofreading Lucien Gentis

1 files changed, 15 insertions, 15 deletions

diff --git a/french/devel/buildd/wanna-build-states.wml b/french/devel/buildd/wanna-build-states.wml
index d176cd77bad..516c2f4ee82 100644
--- a/french/devel/buildd/wanna-build-states.wml
+++ b/french/devel/buildd/wanna-build-states.wml
@@ -74,7 +74,7 @@ paquets et leur état actuel de compilation. Il y a huit états :
         à 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
@@ -151,7 +151,7 @@ paquets et leur état actuel de compilation. Il y a huit états :
         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>
@@ -159,7 +159,7 @@ paquets et leur état actuel de compilation. Il y a huit états&nbsp;:
 	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
@@ -187,11 +187,11 @@ paquets et leur état actuel de compilation. Il y a huit états&nbsp;:
       <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é&nbsp;; c'est
         de cette manière que les empaquetages qui échoueront inévitablement
@@ -217,7 +217,7 @@ paquets et leur état actuel de compilation. Il y a huit états&nbsp;:
         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>&nbsp;; cependant, comme il est difficile à
@@ -262,10 +262,10 @@ paquets et leur état actuel de compilation. Il y a huit états&nbsp;:
     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
+    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.
@@ -289,7 +289,7 @@ paquets et leur état actuel de compilation. Il y a huit états&nbsp;:
     <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 que vous ne répugniez 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>
@@ -340,7 +340,7 @@ Comme il peut y avoir un grand nombre
         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.
+        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
@@ -348,9 +348,9 @@ Comme il peut y avoir un grand nombre
         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é&nbsp;; sbuild voit cela, et
+        comme ne devant pas être empaqueté&nbsp;; 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).