Mohammed Adnène Trojette <[EMAIL PROTECTED]> (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 à [EMAIL PROTECTED] (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.
signature.asc
Description: Digital signature