Salut, Quelques mises à jour triviales, que je soumets aux yeux avertis de la liste au cas où j'aurais introduit des erreurs (j'espère n'avoir pas introduit trop de fautes dans mon message ce coup ci). Amicalement David
Index: french/ports/hppa/index.wml
===================================================================
RCS file: /cvs/webwml/webwml/french/ports/hppa/index.wml,v
retrieving revision 1.19
diff -u -r1.19 index.wml
--- french/ports/hppa/index.wml 2 Mar 2011 17:42:52 -0000 1.19
+++ french/ports/hppa/index.wml 8 Jun 2011 02:48:04 -0000
@@ -1,14 +1,18 @@
#use wml::debian::template title="Portage pour PA-RISC" NOHEADER="yes"
#include "$(ENGLISHDIR)/ports/hppa/menu.inc"
-#use wml::debian::translation-check translation="1.29" maintainer="Thomas Marteau"
+#use wml::debian::translation-check translation="1.31" maintainer="Thomas Marteau"
<h1>Debian pour architecture PA-RISC</h1>
<h2>Ã?tat d'avancement</h2>
-<p>HPPA est une architecture officielle de Debian depuis <i>Woody</i>
-(Debian v 3.0). Vous pouvez vous reporter Ã
+<p>
+HPPA est devenue une architecture officielle de Debian avec
+<i>Woody</i> (Debian 3.0), et a été supprimée de stable Ã
+partir de la publication de <i>Squeeze</i> (Debian 6.0).
+
+Vous pouvez vous reporter Ã
<a href="http://parisc-linux.org/";>http://parisc-linux.org/</a>
pour plus d'informations.</p>
@@ -17,9 +21,10 @@
<h2>Contacts</h2>
-<p>La personne responsable des contacts entre Debian et l'équipe
-HP / Linuxcare (<em>ex</em> Puffin Group) est Bdale Garbee <\
-<a href="mailto:bdale@gag.com";>bdale@gag.com</a>>.
+<p>
+Bdale Garbee a été le principal instigateur de ce
+portage, mais il n'y participe plus activement.
+
La meilleure manière de poser vos questions est maintenant par la liste de
diffusion.</p>
Index: french/ports/ia64/index.wml
===================================================================
RCS file: /cvs/webwml/webwml/french/ports/ia64/index.wml,v
retrieving revision 1.20
diff -u -r1.20 index.wml
--- french/ports/ia64/index.wml 30 Jul 2009 18:12:57 -0000 1.20
+++ french/ports/ia64/index.wml 8 Jun 2011 03:04:01 -0000
@@ -1,6 +1,6 @@
#use wml::debian::template title="Portage pour IA-64" NOHEADER="yes"
#include "$(ENGLISHDIR)/ports/ia64/menu.inc"
-#use wml::debian::translation-check translation="1.36" maintainer="Thomas Marteau"
+#use wml::debian::translation-check translation="1.37" maintainer="Thomas Marteau"
<h1>Debian pour IA-64</h1>
@@ -14,19 +14,19 @@
<p>Si vous voulez aider, commencez par vous inscrire à la
<a href="#mailinglist">liste de diffusion debian-ia64</a>.
-<p>Les méthodes normales de Debian pour obtenir de quoi l'installer
-contiennent maintenant les images CD pour IA-64.
+<p>
+Les images de CD pour IA-64 font partie
+des méthodes normales de Debian pour obtenir de quoi l'installer
+avec la documentation.
</p>
-<p>Une autre possibilité est d'utiliser une version bêta de
-<a href="$(DEVEL)/debian-installer/">l'installateur Debian</a> pour ia64.
-Ceci est peut-être réservé pour les plus aventuriers mais tout problème
-rencontré et rapporté pourra aider Debian pour obtenir un installateur
-testé et prêt pour l'ia64 pour la prochaine version stable de Debian !
<h2>Versions des BIOS</h2>
-<p>Il est possible de trouver parmi les premiers systèmes IA-64 des machines
+<p>
+Tous les systèmes IA-64 modernes devraient fonctionner correctement.
+
+Il est possible de trouver, parmi les tous premiers systèmes IA-64, des machines
dont le BIOS a besoin d'une mise à jour pour faire fonctionner Linux.
Une combinaison particulière connue est d'utiliser des noyaux récents
sur des systèmes <i>Lion</i> avec de vieux BIOS. Pour faciliter, voici
Index: french/devel/testing.wml
===================================================================
RCS file: /cvs/webwml/webwml/french/devel/testing.wml,v
retrieving revision 1.28
diff -u -r1.28 testing.wml
--- french/devel/testing.wml 4 May 2011 23:09:09 -0000 1.28
+++ french/devel/testing.wml 8 Jun 2011 02:54:03 -0000
@@ -1,6 +1,6 @@
#use wml::debian::template title="La distribution de test de Debian" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
-#use wml::debian::translation-check translation="1.29" maintainer="Pierre Machard"
+#use wml::debian::translation-check translation="1.30" maintainer="Pierre Machard"
<p>
Pour les informations élémentaires destinées aux simples utilisateurs de la
@@ -43,10 +43,13 @@
<li>Il devra être compilé et à jour sur toutes les architectures sur
lesquelles il a été compilé par le passé dans la distribution
instable ;</li>
- <li>Il doit avoir moins (ou le même nombre) de rapport de bogue entrant dans
+ <li>
+ Il ne doit pas avoir de rapport de bogue entrant dans
la catégorie critique pour la parution dans la prochaine distribution <!--
oui, c est long mais ça me parait correct ; voir la discussion sur l10n !
- -->que la version actuellement dans la <q>distribution de test</q>
+ -->
+ qui ne concerne pas déjà la version actuellement
+ dans la <q>distribution de test</q>
(regardez ci-dessous pour <a href="#faq">plus
d'informations</a>) ;</li>
<li>Toutes ces dépendances doivent <em>soit</em> être satisfaites par les
#use wml::debian::template title="Portage pour PA-RISC" NOHEADER="yes" #include "$(ENGLISHDIR)/ports/hppa/menu.inc" #use wml::debian::translation-check translation="1.31" maintainer="Thomas Marteau" <h1>Debian pour architecture PA-RISC</h1> <h2>�tat d'avancement</h2> <p> HPPA est devenue une architecture officielle de Debian avec <i>Woody</i> (Debian 3.0), et a été supprimée de stable à partir de la publication de <i>Squeeze</i> (Debian 6.0). Vous pouvez vous reporter à <a href="http://parisc-linux.org/";>http://parisc-linux.org/</a> pour plus d'informations.</p> <p>Si vous avez des questions ou désirez aider, commencez par souscrire à la liste de diffusion debian-hppa décrite ci-dessous !</p> <h2>Contacts</h2> <p> Bdale Garbee a été le principal instigateur de ce portage, mais il n'y participe plus activement. La meilleure manière de poser vos questions est maintenant par la liste de diffusion.</p> <h2>Liste de diffusion</h2> <p>Pour souscrire à la liste de diffusion à propos du portage, envoyez un courriel avec le mot « subscribe » comme sujet à <a href="mailto:debian-hppa-request@lists.debian.org";> debian-hppa-request@lists.debian.org</a> ou utilisez la page <a href="$(HOME)/MailingLists/subscribe">d'inscription à la liste de diffusion</a>.</p> <p>L'archive de la liste se trouve dans <a href="http://lists.debian.org/debian-hppa/";>les archives des listes Debian</a>. <h2>Liens</h2> <ul> <li><a href="http://parisc-linux.org/";>Le site du projet PA-RISC Linux</a> ; <li><a href="http://www.pateam.org/parisc-linux-boot/doc.html";>Les manuels HOWTO de l'ESIEE</a> ; <li><a href="http://docs.hp.com/hpux/hw/";>Documentation sur les systèmes HP</a> ; <li><a href="http://h21007.www2.hp.com/dev/";>\ Documents de référence sur l'architecture HP PA-RISC</a> ; <li><a href="http://www.openpa.net/";>Le project OpenPA</a>. </ul>
#use wml::debian::template title="Portage pour IA-64" NOHEADER="yes" #include "$(ENGLISHDIR)/ports/ia64/menu.inc" #use wml::debian::translation-check translation="1.37" maintainer="Thomas Marteau" <h1>Debian pour IA-64</h1> <h2>�tat d'avancement</h2> <p> IA-64 est une architecture officielle depuis Debian 3.0 (<em>Woody</em>). </p> <p>Si vous voulez aider, commencez par vous inscrire à la <a href="#mailinglist">liste de diffusion debian-ia64</a>. <p> Les images de CD pour IA-64 font partie des méthodes normales de Debian pour obtenir de quoi l'installer avec la documentation. </p> <h2>Versions des BIOS</h2> <p> Tous les systèmes IA-64 modernes devraient fonctionner correctement. Il est possible de trouver, parmi les tous premiers systèmes IA-64, des machines dont le BIOS a besoin d'une mise à jour pour faire fonctionner Linux. Une combinaison particulière connue est d'utiliser des noyaux récents sur des systèmes <i>Lion</i> avec de vieux BIOS. Pour faciliter, voici ce que nous savons à propos des versions de BIOS qui sont compatibles avec Debian sur de plus anciens systèmes : <ul> <li> Lion connu aussi comme HP rx4610, version 99b fonctionne ; <li> BigSur connu aussi comme HP i2000, version 130 fonctionne. </ul> <p>Les téléchargements de microcode pour les systèmes <a href="http://www.hp.com";>HP</a> sont disponibles <a href="http://welcome.hp.com/country/us/eng/software_drivers.htm";>ICI</a>. <p>Si quelqu'un a des informations à propos d'une version de BIOS pour d'autres systèmes IA-64 opérationnelle avec Debian, faites-le savoir sur la liste de debian-ia64 ! <h2>Contacts</h2> <p>Les initiateurs du portage sur IA-64 sont Bdale Garbee et Randolph Chung. La meilleure façon de poser vos questions est de le faire <em>via</em> la liste de diffusion. <h2><a name="mailinglist">Liste de diffusion</a></h2> <p>Pour souscrire à la liste de diffusion à propos du portage, envoyez un courriel avec le mot « subscribe » comme sujet à <email "debian-ia64-request@lists.debian.org"> pour vous inscrire ou utilisez la <a href="http://lists.debian.org/debian-ia64/";>page d'inscription à la liste de diffusion</a>. Vous pouvez aussi consulter et rechercher dans les <a href="http://lists.debian.org/debian-ia64/";>archives de la liste</a>. </p>
#use wml::debian::template title="La distribution de test de Debian" BARETITLE=true
#include "$(ENGLISHDIR)/releases/info"
#use wml::debian::translation-check translation="1.30" maintainer="Pierre Machard"
<p>
Pour les informations élémentaires destinées aux simples utilisateurs de la
distribution de test, veuillez vous référer à <a
href="$(DOC)/FAQ/ch-ftparchives#s-testing">la FAQ Debian</a>.
</p>
<p>
Les simples utilisateurs et les développeurs de la distribution de test doivent
savoir que les mises à jour de sécurité pour la distribution de test <strong>ne
sont pas gérées par l'équipe chargée de la sécurité</strong>. Pour de plus
amples informations, référez-vous à la <a href="../security/faq#testing">FAQ de
l'équipe chargée de la sécurité</a>.
</p>
<p>
Cette page traite principalement de l'importance que revêt la distribution de
test pour les développeurs Debian.
</p>
<h2>Comment fonctionne la distribution de test ?</h2>
<p>
La distribution de test est une distribution générée automatiquement. Elle est
générée à partir de la distribution instable par un ensemble de scripts qui
tentent d'intégrer les paquets qui selon toute vraisemblance ne contiennent pas
de bogues critiques pour la publication. Ils s'assurent que les dépendances des
autres paquets de la distribution de test soient toujours préservées.
</p>
<p>
Un paquet (ou une version particulière) sera déplacé dans la distribution de
test lorsqu'il satisfera les critères suivants :
</p>
<ol>
<li>Il doit avoir été dans la distribution instable pendant 10, 5 ou
2 jours, en fonction de l'urgence de la mise en ligne ;</li>
<li>Il devra être compilé et à jour sur toutes les architectures sur
lesquelles il a été compilé par le passé dans la distribution
instable ;</li>
<li>
Il ne doit pas avoir de rapport de bogue entrant dans
la catégorie critique pour la parution dans la prochaine distribution <!--
oui, c est long mais ça me parait correct ; voir la discussion sur l10n !
-->
qui ne concerne pas déjà la version actuellement
dans la <q>distribution de test</q>
(regardez ci-dessous pour <a href="#faq">plus
d'informations</a>) ;</li>
<li>Toutes ces dépendances doivent <em>soit</em> être satisfaites par les
paquets d'ores et déjà présents dans la distribution de test, <em>ou
bien</em> être satisfaites par un ensemble de paquets qui sont installés au
même instant ;</li>
<li>L'opération d'installation des paquets dans la distribution de test ne
doit pas casser un seul paquet actuellement dans cette distribution
(regardez ci-dessous pour <a href="#faq">plus
d'informations</a>) ;</li>
</ol>
<p>
Un paquet qui satisfait aux trois premiers critères ci-dessus est un
<q>Candidat Valide</q>.
</p>
<p>
Le script de mise à jour indique quand un paquet peut-être déplacé de la
distribution instable vers la distribution de test. La sortie a deux
formes :
</p>
<ul>
<li>la <a href="http://ftp-master.debian.org/testing/update_excuses.html";>\
mise à jour des excuses</a> [<a
href="http://ftp-master.debian.org/testing/update_excuses.html.gz";>\
gzippée</a>] : liste l'ensemble des versions des paquets candidats et
l'état de base de leur propagation dans la distribution de test. Elle est
beaucoup plus digeste que :
</li>
<li>la <a href="http://ftp-master.debian.org/testing/update_output.txt";>\
sortie de la mise à jour</a> [<a
href="http://ftp-master.debian.org/testing/update_output.txt.gz";>\
gzippée</a>] : La sortie complète, plutôt indigeste des scripts de la
distribution de test compte tenu de la récursivité des candidats.
</li>
</ul>
<h2><a name="faq">Foire aux questions</a></h2>
<h3><q>Que sont les bogues de type critique pour l'intégration dans la
distribution <!-- nouvelle formulation ! -->(<i>release-critical bugs</i>), et
comment sont-ils comptabilisés ?</q></h3>
<p>
Tous les bogues des niveaux supérieurs de gravité appartiennent par défaut Ã
cette catégorie (<em><a href="http://bugs.debian.org/release-critical/";>\
release-critical</a></em>) ; actuellement, ce sont les niveaux
<strong>critical</strong>, <strong>grave</strong> et <strong>serious</strong>.
</p>
<p>
De tels bogues sont présumés avoir une incidence sur l'intégration du paquet
dans la distribution stable de Debian : en règle générale, si un paquet a
un rapport de bogue appartenant à cette catégorie, il n'ira pas dans la
distribution de test, et par conséquent ne sera pas publié dans la
distribution stable.
</p>
<p>
Le décompte des bogues de <q>testing</q> est effectué avec tous
les bogues critiques pour la publication marqués pour s'appliquer
à une combinaison de <tt>paquet/version</tt> disponible dans
<q>testing</q> pour une architecture concernée par la publication.
</p>
<h3><q>Comment l'installation d'un paquet provenant de la distribution de test
peut-elle casser d'autres paquets ?</q></h3>
<p>
La structure des archives de la distribution est telle qu'une distribution ne
peut contenir qu'une seule version d'un paquet ; un paquet est défini par
son nom. Aussi lorsque le paquet source <tt>acmefoo</tt> est installé dans la
distribution de test, ainsi que ses paquets binaires <tt>acme-foo-bin</tt>,
<tt>acme-bar-bin</tt>, <tt>libacme-foo1</tt> et <tt>libacme-foo-dev</tt>, la
version précédente est enlevée.
</p>
<p>
Néanmoins, il se peut que l'ancienne version ait fourni un paquet binaire avec
un ancien nom-so d'une bibliothèque<!-- voir la charte et le chapitre sur les
bibliothèques -->, comme <tt>libacme-foo0</tt>. Enlever l'ancien
<tt>acmefoo</tt> enlèvera également <tt>libacme-foo0</tt>, ce qui cassera tout
les paquets qui en dépendent.
</p>
<p>
Ã?videmment, cela affecte principalement les paquets qui fournissent des
ensembles de paquets binaires dans différentes versions (et principalement les
bibliothèques). Néanmoins, cela concerne aussi les paquets pour lesquels des
dépendances pour des versions précises ont été déclarées avec ==, <= ou
<<.
</p>
<p>
Lorsque l'ensemble des paquets binaires issu d'un paquet source est modifié,
tous les paquets qui dépendent des anciens paquets binaires doivent être mis Ã
jour pour dépendre maintenant des nouveaux paquets binaires. �tant donné que
l'installation d'un tel paquet source dans la distribution de test cassera
tous les paquets de cette distribution qui en dépendent, il est nécessaire de
prendre quelques dispositions : tous les paquets en dépendant doivent être
mis à jour et être prêts à être installés pour éviter la casse, une fois que
tout est prêt, une intervention manuelle du responsable de la publication ou
d'un assistant est nécessaire.
</p>
<p>
Si vous êtes confronté à des problèmes complexes sur des groupes de paquets
tels qu'évoqués ci-dessus, veuillez prendre contact avec <q>debian-devel</q> ou
<q>debian-release</q> pour demander de l'aide.
</p>
<h3><q>Je ne comprends toujours pas ! Les scripts de la distribution de
test disent que ce paquet est un candidat valide, mais il n'est toujours pas
dans cette distribution.</q></h3>
<p>
Cela peut se produire lorsque, directement ou indirectement l'installation du
paquet empêche un autre paquet de fonctionner.
</p>
<p>
N'oubliez pas de prendre en compte les dépendances de votre paquet. Considérez
que votre paquet dépend de libtool, ou libtdl<var>X</var>. Votre paquet n'ira
pas dans la distribution de test tant que la bonne version de libtool n'est pas
prête à y aller aussi.
</p>
<p>
De même, elle n'y entrera pas tant que l'installation de libtool provoquera de la casse
sur les paquets qui se trouvent déjà dans la distribution de test. En d'autres
termes, tant que tous les paquets dépendants de libltdl<var>Y</var> (où
<var>Y</var> est une version précédente) n'auront pas été recompilés, et que
tous les bogues de type critique pour l'intégration dans la distribution
n'auront pas été corrigés, etc., aucun de ces paquets n'entrera dans la
distribution de test.
</p>
<p>
Dans ce genre de situation, la <a
href="http://ftp-master.debian.org/testing/update_output.txt";>sortie
textuelle</a> [<a
href="http://ftp-master.debian.org/testing/update_output.txt.gz";>gzippée</a>]
est utile : elle fournit bon nombre d'informations (qu'il faut néanmoins
décoder) sur les paquets cassés lorsqu'un candidat valide est ajouté dans la
distribution de test (consultez la <a
href="$(DOC)/developers-reference/pkgs.html#details">\
référence du développeur pour plus de précisions</a>).
</p>
<h3><q>Pourquoi est-il parfois difficile de mettre un paquet
<i><kbd>Architecture: all</kbd></i> dans la distribution de
test ?</q></h3>
<p>
Si un paquet valable pour toutes les architectures doit être installé, il doit
pouvoir satisfaire l'ensemble de ses dépendances sur <strong>toutes</strong>
les architectures. S'il dépend d'un paquet qui ne compile que sur un nombre
limité d'architectures de Debian, il ne pourra pas être inclus.
</p>
<p>
Néanmoins, pour l'instant, la distribution de test ne vérifiera pas si le
paquet peut être installé sur les architectures non-i386 (<q>C'est un <i>
bidouillage grossier</i>, je ne suis pas très fier de l'avoir fait, mais c'est comme ça</q>
--aj).
</p>
<h3><q>Mon paquet est bloqué car il est dépassé sur certaines architectures.
Que dois-je faire ?</q></h3>
<p>
Vérifiez l'état de votre paquet dans la <a
href="http://buildd.debian.org/build.php";>base de données de journaux de
construction</a>. Si le paquet ne se construit pas, il sera marqué comme
<em>failed</em> ; analysez les comptes rendu de construction et corrigez
chacun des problèmes dont l'origine se trouve votre paquet source.
</p>
<p>
Si vous constatez que certaines architectures ont construit la nouvelle version
de votre paquet, mais que cela n'apparaît pas dans la sortie des scripts de la
distribution de test, alors vous devrez vous armer de patience et attendre que
le responsable du buildd correspondant mette en ligne le fichier dans l'archive
Debian.
</p>
<p>
Si vous constatez que certaines architectures n'ont pas du tout construit la
nouvelle version de votre paquet, malgré le fait que vous ayez mis en ligne une
rustine pour réparer l'échec précédent, la raison est selon toute vraisemblance
que votre paquet est marqué comme attendant des dépendances (<i>Dep-Wait</i>).
Vous pouvez également regarder la liste de ce que l'on appelle <a
href="http://buildd.debian.org/stats/";>en attente de construction</a> pour vous
en assurer.
</p>
<p>
Ces problèmes sont en définitive généralement corrigés, mais si vous attendez
déjà depuis un bon moment (disons deux semaines et plus), notifiez le
responsable des buildd concerné si une telle adresse est fournie sur <a
href="$(HOME)/ports/">la page des portages</a>, ou sur la liste de diffusion du
portage.
</p>
<p>
Si vous avez explicitement supprimé l'architecture de la liste Architecture
danns le fichier control et que le paquet avait déjà été construit pour cette
architecture, vous devez demander la suppression de l'archive des anciens
paquets binaires de cette architecture avant que votre paquet ne puisse
effectuer sa transition vers la distribution de test. Vous devez remplir un
rapport de bogue contre <q>ftp.debian.org</q> demandant la suppression de
l'archive instable des paquets de l'architecture abandonnée. En général, la
liste de diffusion du portage correspondant doit en être informée par
courtoisie.
</p>
<h3><q>Y a-t-il des exceptions ? Je suis persuadé que <tt>acmefoo</tt> a
été intégré dans la distribution de test malgré le fait qu'il ne réponde pas Ã
tous les critères.</q></h3>
<p>
Le responsable de la publication peut transgresser les règles dans deux cas de
figure :
</p>
<ul>
<li>Il peut décider que la rupture engendrée par l'installation d'une
nouvelle bibliothèque sera un bienfait, et il l'installera avec sa
flottille de dépendances ;</li>
<li>Il peut également enlever de façon manuelle des paquets de la
distribution de test, qui autrement seraient cassés, pour pouvoir installer
de nouveaux éléments.</li>
</ul>
<h3><q>Pouvez-vous fournir un exemple réel qui ne soit pas
trivial ?</q></h3>
<p>
En voici un : lorsque le paquet source <tt>apache</tt> est installé dans
la distribution de test, ainsi que ses paquets binaires <tt>apache</tt>,
<tt>apache-common</tt>, <tt>apache-dev</tt> et <tt>apache-doc</tt>, l'ancienne
version est enlevée.
</p>
<p>
Néanmoins, tous les modules d'Apache dépendent de <code>apache-common
(>=<var>quelque chose</var>), apache-common (<< <var>quelque
chose</var>)</code>, aussi ce changement cassera toutes ces dépendances. Par
conséquent, tous les modules d'Apache devront être recompilés avec la dernière
version d'Apache pour que la distribution de test soit mise à jour.
</p>
<p>
Continuons notre analyse plus avant : une fois que tous les modules ont
été mis à jour dans la distribution instable afin de fonctionner avec un nouvel
Apache, les scripts de la distribution de test testent <tt>apache-common</tt>
et se rendent compte que tous les modules d'Apache sont cassés parce qu'ils
possèdent <code>Depends: apache-common (<< <var>la version
actuelle</var></code> ; ensuite, ils essayent
<tt>libapache-<var>foo</var></tt> et trouvent qu'il ne s'installe pas parce
qu'il possède <code>Depends: apache-common (>= <var>la nouvelle
version</var>)</code>.
</p>
<p>
Néanmoins, par la suite, les scripts appliqueront une logique différente
(quelque fois provoquée par une intervention manuelle) : ils ignoreront le
fait que <tt>apache-common</tt> provoque de la casse, et continueront avec les
choses qui fonctionnent ; si cela ne fonctionne toujours pas, après toutes
ces tentatives, tant pis ! mais peut-être que <strong>ça va
fonctionner</strong>. Par la suite, ils testeront au hasard tous les paquets
<tt>libapache-<var>foo</var></tt> et constateront qu'ils fonctionnent.
</p>
<p>
Après que tout a été essayé, ils contrôlent le nombre de paquets qui ont été
cassés, cherchent si c'est plutôt un bien ou un mal par rapport à la situation
d'origine et soit ils acceptent tout, soit ils rejettent tout. Vous verrez
cela dans le fichier <tt>update_output.txt</tt> sur les lignes
<q><code>recur:</code></q>.
</p>
<p>
Par exemple :
</p>
<pre>
recur: [<var>foo</var> <var>bar</var>] <var>baz</var>
</pre>
<p>
dit grosso modo : <q>j'ai trouvé que <var>foo</var> et <var>bar</var>
amélioraient la situation, je vais maintenant essayer <var>baz</var>, même s'il
casse quelque chose pour voir ce qui se passe</q>. Les lignes du fichier
<tt>update_output.txt</tt> qui commencent par <q><code>accepted</code></q>
indiquent les éléments qui apparaissent comme étant bénéfiques, et les lignes
<q><code>skipped</code></q> les éléments qui empirent la situation.
</p>
<h3><q>Le fichier <tt>update_output.txt</tt> est complètement
illisible !</q></h3>
<p>
Ce n'est pas une question. ;-)
</p>
<p>
Prenons un exemple :
</p>
<pre>
skipped: cln (0) (150+4)
got: 167+0: a-40:a-33:h-49:i-45
* i386: ginac-cint, libginac-dev
</pre>
<p>
Cela signifie que si <tt>cln</tt> est ajouté dans la distribution de test,
<tt>ginac-cint</tt> et <tt>libginac-dev</tt> ne pourront plus être y installés
sur l'architecture i386. Notez que les architectures sont contrôlées dans
l'ordre alphabétique et seuls les problèmes survenants sur la première
architecture en défaut sont rapportés — c'est pourquoi on voit
souvent l'architecture alpha.
</p>
<p>
La ligne <q>got</q> inclut le nombre de problèmes dans la distribution de test
sur différentes architectures (jusqu'à la première architecture où l'on trouve
un problème — voir ci-dessus). L'item <q>i-45</q> signifie que si
<tt>cln</tt> est ajouté dans la distribution de test, il y aura 45 paquets
qui ne pourront plus être installés sur l'architecture i386. Quelques entrées
au-dessus et en dessous de <tt>cln</tt> montrent qu'il y avait 43 paquets
qui ne pouvaient pas être installés dans la distribution de test pour
l'architecture i386 à ce moment-là .
</p>
<p>
La ligne <q>skipped: cln (0) (150+4)</q> signifie qu'il y a toujours
150 paquets à vérifier après ce paquet pour que le contrôle de tous les
paquets soit achevé, et que 4 paquets ont d'ores et déjà été identifiés et
ne seront pas mis à jour car ils casseraient des dépendances. Le <q>(0)</q>
n'est pas significatif, vous pouvez l'ignorer.
</p>
<p>
Notez qu'il y plusieurs contrôles de tous les paquets lors de l'exécution d'un
script de la distribution de test.
</p>
<p>
<em>Jules Bean est à l'origine de la foire aux questions et de ses réponses.</em>
</p>
# Created: Sat Dec 8 12:44:29 GMT 2001
<h2>Informations complémentaires</h2>
<p>Les pages suivantes donnent des informations sur l'état de la distribution de
test et sur la migration des paquets de unstable vers testing :</p>
<ul>
<li>Les statistiques des paquets binaires ne sont pas à jour pour les
distributions :
<a href="http://ftp-master.debian.org/testing/testing_outdate.txt";>de test</a>et
<a href="http://ftp-master.debian.org/testing/stable_outdate.txt";>stable</a>,
<li>les problèmes de dépendance des distributions
<a href="http://qa.debian.org/debcheck.php?list=INDEX&dist=testing";>de test</a>
et
<a href="http://qa.debian.org/debcheck.php?list=INDEX&dist=stable";>stable</a>.
</ul>
<p>
Une <a href="http://release.debian.org/migration/";>\
interface</a> pour vous aider à découvrir pourquoi les paquets sont retenus en
dehors de la distribution de test.
</p>
<p>
Vous serez peut être intéressé par la lecture d'un ancien <a
href="http://lists.debian.org/debian-devel-0008/msg00906.html";>courrier d'
explication</a>. Son seul défaut est de ne pas prendre en considération
l'organisation en pool des paquets ; mais il a été écrit avant que cette
organisation ne soit mise en place par James Troup.
</p>
<p>
Le code de testing est disponible sur la machine <a
href="http://ftp-master.debian.org/testing/update_out_code/";>ftp-master</a>.
</p>
<p>
<em>Anthony Towns est l'auteur de l'implémentation de testing.</em>
</p>
Attachment:
signature.asc
Description: OpenPGP digital signature