chiark / gitweb /
Synchronize with 1.153 and proofread by P. Batailler.
authorfbothamy <fbothamy@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Wed, 1 Jan 2003 23:54:47 +0000 (23:54 +0000)
committerfbothamy <fbothamy@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Wed, 1 Jan 2003 23:54:47 +0000 (23:54 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2026 313b444b-1b9f-4f58-a734-7bb04f332e8d

developers-reference.fr.sgml

index 5082228..6d705f4 100644 (file)
@@ -4,14 +4,18 @@
   <!entity % versiondata SYSTEM "version.ent"> %versiondata;
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
-  <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.32 $">
 
-  <!-- if you are translating this document, please notate the RCS
+  <!-- CVS revision of this document -->
+  <!entity cvs-rev "$Revision: 1.33 $">
+  <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
-    <!entity cvs-en-rev "1.91">
+    <!entity cvs-en-rev "1.153">
     -->
+
+  <!--  -->
+  <!entity FIXME "<em>FIXME:</em>&nbsp;">
+
 ]>
 <debiandoc>
 <!--
   - "official port maintainer" ? (cf. glibc-pre2.1)
  -->
 
-
-<book>
-<title>Référence du développeur Debian
-
-<author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email>
-<author>Christian Schwarz <email>schwarz@debian.org</email>
-<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
-<author>&nbsp;
-<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
-<author>et les membres de la liste
-<email>debian-l10n-french@lists.debian.org</email>
-<version>Version &version;, &date-fr; (version française 20020506).
-
-<copyright>
-
-<copyrightsummary>
- Copyright &copy;1998 &ndash; 2002 Adam Di Carlo</copyrightsummary>
-<copyrightsummary>
-Copyright &copy;1997, 1998 Christian Schwarz.</copyrightsummary>
-
-<p>
-Ce manuel est un logiciel libre&nbsp;; il peut être redistribué et/ou modifié selon
-les termes de la licence publique générale du projet GNU (GNU GPL), telle que
-publiée par la «&nbsp;Free Software Foundation&nbsp;» (version 2 ou toute
+  <book>
+
+      <title>Référence du développeur Debian
+      <author>Adam Di Carlo, responsable actuel<email>aph@debian.org</email>
+      <author>Raphaël Hertzog, co-responsable <email>hertzog@debian.org</email>
+      <author>Christian Schwarz <email>schwarz@debian.org</email>
+      <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
+      <author>&nbsp;
+      <author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
+      <author>et Frédéric Bothamy (traducteur actuel) <email>fbothamy@mail.dotcom.fr</email>
+      <author>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
+      <version>Version &version;, &date-fr; (version française 20021231).</version>
+
+      <copyright>
+       <copyrightsummary>Copyright &copy; 1998&mdash;2002 Adam Di Carlo</copyrightsummary>
+       <copyrightsummary>Copyright &copy; 2002 Raphaël Hertzog</copyrightsummary>
+       <copyrightsummary>Copyright &copy; 1997, 1998 Christian Schwarz.</copyrightsummary>
+<p>
+Ce manuel est un logiciel libre&nbsp;; il peut être redistribué et/ou modifié
+selon les termes de la licence publique générale du projet GNU (GNU GPL), telle
+que publiée par la «&nbsp;Free Software Foundation&nbsp;» (version 2 ou toute
 version postérieure).
 
 <p>
 Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
 garantie</em>, sans même la garantie implicite d'une possible valeur marchande
-ou d'une adéquation à un besoin particulier. Consultez la licence publique générale
-du projet GNU pour plus de détails.
-
-<p>
-Une copie de la licence publique générale du projet GNU est disponible dans le
-fichier &file-GPL; de la distribution &debian-formal; ou sur la toile&nbsp;: <url
-id="&url-gpl" name="la licence publique générale du projet GNU">. Vous pouvez
-également l'obtenir en écrivant à la &fsf-addr;.
-
-
-
-
-       <toc detail="sect2">
+ou d'une adéquation à un besoin particulier. Consultez la licence publique
+générale du projet GNU pour plus de détails.
 
+<p>Une copie de la licence publique générale du projet GNU est disponible dans
+le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile&nbsp;:
+<url id="&url-gpl" name="la licence publique générale du projet GNU">. Vous
+pouvez également l'obtenir en écrivant à la &fsf-addr;.
 
+    <toc detail="sect1">
 
-
-       <chapt id="scope">Introduction
-       
-       <sect>Portée de ce document
+    <chapt id="scope">Portée de ce document
 
 <p>
-Le but de ce document est de donner une vue d'ensemble des procédures à
-suivre et des ressources mises à la disposition des développeurs Debian.
+Le but de ce document est de donner une vue d'ensemble des procédures à suivre
+et des ressources mises à la disposition des développeurs Debian.
 
+<!-- FIXME: rewrites -->
 <p>
-Les procédures décrites ci-après expliquent entre autre comment devenir
+Les procédures décrites ci-après expliquent comment devenir
 responsable Debian (<ref id="new-maintainer">), comment installer des nouveaux
-paquets dans l'archive (<ref id="upload">), quand et comment faire un portage
-ou une mise à jour du paquet d'un autre responsable (<ref id="nmu">), comment
-déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">) et
-comment gérer les bogues (<ref id="bug-handling">).
+paquets dans l'archive (<ref id="upload">), quand et comment faire un portage ou
+une mise à jour du paquet d'un autre responsable (<ref id="nmu">), comment
+déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">) et comment
+gérer les rapports de bogues (<ref id="bug-handling">).
 
 <p>
-Les ressources présentées dans ce manuel incluent les listes de diffusion et
-les serveurs (<ref id="servers">), une présentation de la structure de
-l'archive Debian (<ref id="archive">), des explications sur les serveurs qui
-acceptent les mises à jour de paquets (<ref id="upload-ftp-master">) et une
-présentation des outils qui peuvent aider un responsable à améliorer la
-qualité de ses paquets (<ref id="tools">).
+Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref
+id="mailing-lists">) et les serveurs (<ref id="server-machines">), une
+présentation de la structure de l'archive Debian (<ref id="archive">), des
+explications sur les serveurs qui acceptent les mises à jour de paquets (<ref
+id="upload-ftp-master">) et une présentation des outils qui peuvent aider un
+responsable à améliorer la qualité de ses paquets (<ref id="tools">).
 
 <p>
 Ce manuel de référence ne présente pas les aspects techniques liés aux paquets
-Debian. Il ne décrit pas non plus comment les créer. Il ne décrit pas 
-non plus les règles que doivent respecter les paquets Debian. Cette
-information est disponible dans le <url id="&url-debian-policy;" name="Debian
-Policy Manual">.
+Debian, ni comment les créer. Il ne décrit pas non plus les règles que doivent
+respecter les paquets Debian. Cette information est disponible dans la <url
+id="&url-debian-policy;" name="charte Debian">.
 
 <p>
-De plus ce document <em>n'est pas l'expression d'une politique
-officielle</em>. Il contient de la documentation sur le système Debian et des
-conseils pratiques largement suivis. C'est une sorte de guide pratique.
-
-
-
-
+De plus ce document <em>n'est pas l'expression d'une politique officielle</em>.
+Il contient de la documentation sur le système Debian et des conseils pratiques
+largement suivis. C'est une sorte de guide pratique.
 
        <sect>Introduction à la version française
 
        <sect1>Avertissement
 
 <p>
-Bien que ce document soit en français, l'activité de responsable Debian
-implique une maîtrise de la langue anglaise. Le projet Debian est un projet
-international auquel participent des japonais, néo-zélandais, américains,
-allemands, finlandais, français, espagnols, danois...
+Bien que ce document soit en français, l'activité de responsable Debian implique
+une maîtrise de la langue anglaise. Le projet Debian est un projet international
+auquel participent des japonais, néo-zélandais, américains, allemands,
+finlandais, français, espagnols, danois...
 
 <p>
-En conséquence la langue utilisée dans toutes les listes de diffusion
-destinées aux développeurs est l'anglais et les rapports de bogue doivent être
-rédigés en anglais. En fait, sauf exception rare, tout dialogue avec les
-autres responsables Debian se fera en anglais quelque soit le média.
+En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
+aux développeurs est l'anglais et les rapports de bogue doivent être rédigés en
+anglais. En fait, sauf exception rare, tout dialogue avec les autres
+responsables Debian se fera en anglais quel que soit le média.
 
 
        <sect1>Glossaire
 
 <p>
-Cette section liste les termes techniques qui ont un sens spécifique
-dans le projet Debian. Pour chacune de ces expressions vous trouverez la
-traduction française utilisée dans ce manuel, une définition et une
-référence à la section du manuel qui traite de ce sujet.
+Cette section liste les termes techniques qui ont un sens spécifique dans le
+projet Debian. Pour chacune de ces expressions, vous trouverez la traduction
+française utilisée dans ce manuel, une définition et une référence à la section
+du manuel qui traite de ce sujet.
 
 
-       <list>
+<list>
        <item><em>Upload</em>&nbsp;: mise à jour, téléchargement (parfois
-       livraison). Opération qui consiste à télécharger un nouveau paquet
-       ou une nouvelle version de paquet dans l'archive Debian (<ref
+       livraison). Opération qui consiste à télécharger un nouveau paquet ou
+       une nouvelle version de paquet dans l'archive Debian (<ref
        id="upload">).
 
-       <item><em>Non-maintainer upload (NMU)</em>&nbsp;: mise à jour indépendante.
-       Téléchargement d'une nouvelle version de paquet dans l'archive
-       Debian par une personne qui n'est pas officiellement responsable de ce
-       paquet(<ref id="nmu">).
+       <item><em>Non-maintainer upload (NMU)</em>&nbsp;: mise à jour
+       indépendante. Téléchargement d'une nouvelle version de paquet dans
+       l'archive Debian par une personne qui n'est pas officiellement
+       responsable de ce paquet (<ref id="nmu">).
 
-       <item><em>NMU source</em>&nbsp;: mise à jour indépendante source. Il
+       <item><em>Source NMU</em>&nbsp;: mise à jour indépendante source. Il
        s'agit d'une mise à jour indépendante pour un paquet source (<ref
        id="nmu-terms">).
 
-       <item><em>NMU binaire</em>&nbsp;: mise à jour indépendante binaire.
-       Mise à jour indépendante pour un paquet binaire(<ref id="nmu-terms">).
+       <item><em>Binary NMU</em>&nbsp;: mise à jour indépendante binaire. Mise
+       à jour indépendante pour un paquet binaire (<ref id="nmu-terms">).
 
        <item><em>Bug Tracking System (BTS)</em>&nbsp;: système de suivi des
        bogues. Il s'agit du système utilisé par le projet Debian pour suivre
        les bogues et leur correction (<ref id="bug-handling">).
 
        <item><em>Bug submitter</em>&nbsp;: rapporteur du bogue. Personne qui
-       envoie un rapport de bogue au système de suivi des bogues(<ref
+       envoie un rapport de bogue au système de suivi des bogues (<ref
        id="submit-bug">).
 
-       <item><em>Release critical bug</em>&nbsp;: bogue remettant en cause la
-       distribution. Bogues de gravité <em>critique</em>, <em>grave</em>
-       et <em>sérieuse</em>. Ces bogues ne doivent pas apparaître dans une
-       distribution <em>stable</em>. Ils doivent être corrigés ou bien les
-       paquets en cause doivent être supprimés (<ref id="rc-bugs">). 
+       <item><em>Release critical bug</em>&nbsp;: bogue empêchant l'intégration
+        du paquet dans la distribution. Bogues de gravité <em>critique</em>,
+        <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas
+        apparaître dans une distribution <em>stable</em>. Ils doivent être
+        corrigés ou bien les paquets en cause doivent être supprimés (<ref
+        id="rc-bugs">).
+
+       <item><em>Package Tracking System (PTS)</em>&nbsp;: système de suivi des
+       paquets. Il s'agit du système utilisé par le projet Debian pour suivre
+       les paquets sources des différentes distributions (<ref
+       id="pkg-tracking-system">).
 
        <item><em>Unstable</em>&nbsp;: Nom de la distribution en cours de
-       développement. Cette distribution contient les paquets envoyés par
-       les développeurs. Ceux-ci étant humains, elle est parfois cassée (<ref
+       développement. Cette distribution contient les paquets envoyés par les
+       développeurs. Ceux-ci étant humains, elle est parfois cassée (<ref
        id="sec-dists">).
 
        <item><em>Testing</em>&nbsp;: Nom de la distribution en test. Cette
        distribution reçoit les paquets des développeurs qui ont passé une
        période de deux semaines dans <em>unstable</em> et pour lesquels aucun
-       bogue remettant en cause la distribution (cf. <em>Release critical bug</em>)
-       n'a été découvert. Cette distribution n'a pas été testée
-       en profondeur. Elle est cependant sensée être plus stable que
+       bogue remettant en cause la distribution (cf. <em>Release critical
+       bug</em>) n'a été découvert. Cette distribution n'a pas été testée en
+       profondeur. Elle est cependant censée être plus stable que
        <em>unstable</em> (<ref id="sec-dists">).
 
        <item><em>Stable</em>&nbsp;: Nom de la distribution dite stable. Cette
-       distribution a été testée, validée et diffusée (<ref
-       id="sec-dists">).
+       distribution a été testée, validée et diffusée (<ref id="sec-dists">).
 
        <item><em>Debian maintainer</em>&nbsp;: responsable Debian, développeur
-       Debian (parfois mainteneur). Personne qui fait officiellement
-       partie du projet Debian. Elle a accès aux serveurs Debian et participe
-       au développement &mdash; au sens large &mdash; de la distribution (<ref
-       id="developer-duties">). La plupart des responsables font de la mise
-       en paquet mais il existe d'autres activités telles que documentation,
-       site web, création des cédéroms, administration des serveurs...
+       Debian (parfois mainteneur). Personne qui fait officiellement partie du
+       projet Debian. Elle a accès aux serveurs Debian et participe au
+       développement &mdash; au sens large &mdash; de la distribution (<ref
+       id="developer-duties">). La plupart des responsables font de la mise en
+       paquet, mais il existe d'autres activités telles que la documentation,
+       la gestion du site web, la création des cédéroms, l'administration des
+       serveurs, etc.
 
        <item><em>Upstream version</em>&nbsp;: version amont. Il s'agit du
-       logiciel tel qu'il est fournit par le responsable amont &mdash; par
-       opposition à la version fournie par la distribution Debian. (Voir
-       <ref id="upstream-coordination">.)
+       logiciel tel qu'il est fourni par le responsable amont &mdash; par
+       opposition à la version fournie par la distribution Debian. (Voir <ref
+       id="upstream-coordination">.)
 
-       <item><em>Upstream maintainer</em>&nbsp;: responsable amont ou développeur
-       amont. Personne(s) responsable(s) du développement ou de la
-       maintenance d'un logiciel. En général le responsable amont n'a rien à
+       <item><em>Upstream maintainer</em>&nbsp;: responsable amont ou
+       développeur amont. Personne(s) responsable(s) du développement ou de la
+       maintenance d'un logiciel. En général, le responsable amont n'a rien à
        voir avec le projet Debian (<ref id="upstream-coordination">).
 
        <item><em>Debian keyring</em>&nbsp;: porte-clés Debian. Le porte-clés
        Debian contient les clés publiques de tous les responsables Debian (<ref
        id="key-maint">).
 
-       <item><em>Work-needing and prospective packages (WNPP)</em>&nbsp;: paquets en
-       souffrance et paquets souhaités. La liste des paquets en
+       <item><em>Work-needing and prospective packages (WNPP)</em>&nbsp;:
+       paquets en souffrance et paquets souhaités. La liste des paquets en
        souffrance indique les paquets qui n'ont plus de responsable. La liste
        des paquets souhaités indique les logiciels que des utilisateurs
        aimeraient bien voir dans la distribution (<ref id="upload">).
        </list>
 
 
-       <chapt id="new-maintainer">Devenir responsable Debian
-
-
-       <sect id="getting-started">Pour commencer
-
+    <chapt id="new-maintainer">Devenir responsable Debian
+       
+      <sect id="getting-started">Pour commencer
 <p>
 Vous avez lu toute la documentation, vous avez examiné le <url
-id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
-l'intérêt de tout ce qui
-se trouve dans le paquet exemple <package>hello</package> et vous vous
-apprêtez à mettre en paquet votre logiciel préféré. Comment devenir
-responsable Debian et intégrer votre travail au projet&nbsp;?
-
-<p>
-Si vous ne l'avez pas encore fait vous pouvez commencer par vous inscrire à la
-liste &email-debian-devel;.
-
-<p>
-Pour cela, envoyez un courrier à l'adresse
-&email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
-<em>Objet</em><footnote><em>Subject</em> en anglais</footnote> de votre
-message. En cas de problème, contactez l'administrateur de la liste
-&email-listmaster;. Vous trouverez plus d'information dans la section <ref
-id="mailing-lists">.
-
-<p>
-Vous suivrez les discussions de cette liste (sans poster) pendant quelques
-temps avant de coder quoi que ce soit et vous informerez la liste de votre
-intention de travailler sur quelque chose pour éviter de dupliquer le travail
-d'un autre.
-
+ id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
+ l'intérêt de tout ce qui se trouve dans le paquet d'exemple
+ <package>hello</package> et vous vous apprêtez à mettre en paquet votre
+ logiciel préféré. Comment devenir responsable Debian et intégrer votre travail
+ au projet&nbsp;?
+<p>
+Si vous ne l'avez pas encore fait, commencez par vous inscrire à la
+ liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
+ &email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
+ <em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> de votre
+ message. En cas de problème, contactez l'administrateur de la liste
+ &email-listmaster;. Vous trouverez plus d'informations dans la section <ref
+ id="mailing-lists">. &email-debian-devel-announce; est une autre liste
+ incontournable pour qui veut suivre les développements de Debian.
+<p>
+Vous suivrez les discussions de cette liste (sans poster) pendant quelque temps
+ avant de coder quoi que ce soit et vous informerez la liste de votre intention
+ de travailler sur quelque chose pour éviter de dupliquer le travail d'un autre.
 <p>
 Une autre liste intéressante est &email-debian-mentors;. Voir la section <ref
-id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> sur le réseau
-<em>Linux People IRC</em> (c.-à-d. <tt>irc.debian.org</tt>) pourra aussi être
-utile.
-
-<p>
-Quand vous avez choisi la manière dont vous contriburez au projet
-&debian-formal;, prenez contact avec les responsables Debian qui travaillent
-sur des tâches similaires. Ainsi vous pouvez apprendre auprès de personnes
-expérimentées.  Si, par exemple, vous voulez mettre en paquet des logiciels
-existants, trouvez-vous un parrain. Un parrain est une personne qui
-travaillera sur vos paquets avec vous et les téléchargera dans l'archive
-Debian une fois qu'il sera satisfait de votre mise en paquet. Pour trouver
-un parrain, envoyez une demande de parrainage à la liste
-&email-debian-mentors; en vous présentant et en décrivant votre paquet (voir
-<ref id="sponsoring"> pour en savoir plus sur le sujet). Si vous préférez
-porter Debian sur une architecture ou un noyau alternatif, abonnez vous aux
-listes dédiées au portage et demandez-y comment démarrer. Finalement, si vous
-êtes intéressé par la documentation ou l'assurance qualité (QA) vous pouvez
-contacter les responsables qui travaillent déjà sur ces tâches et proposer des
-rustines et des améliorations.
-
-
-       <sect id="registering">Devenir responsable Debian
+ id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> pourra aussi être
+ utile.
+
+<p>
+Quand vous avez choisi la manière dont vous contribuerez au projet
+ &debian-formal;, prenez contact avec les responsables Debian qui travaillent
+ sur des tâches similaires. Ainsi vous pourrez apprendre auprès de personnes
+ expérimentées. Si, par exemple, vous voulez mettre en paquet des logiciels
+ existants, trouvez-vous un parrain. Un parrain est une personne qui travaillera
+ sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois
+ qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez
+ une demande de parrainage à la liste &email-debian-mentors; en vous présentant
+ et en décrivant votre paquet (voir <ref id="sponsoring"> pour en savoir plus
+ sur le sujet). Si vous préférez porter Debian sur une architecture ou un noyau
+ alternatif, abonnez-vous aux listes dédiées au portage et demandez-y comment
+ démarrer. Finalement, si vous êtes intéressé par la documentation ou
+ l'assurance qualité (QA), vous pouvez contacter les responsables qui
+ travaillent déjà sur ces tâches et proposer des correctifs et des
+ améliorations.
 
+      <sect id="registering">Devenir responsable Debian
 <p>
 Avant de décider de devenir responsable Debian, il vous faudra lire toute la
-documentation disponible dans le <url id="&url-newmaint;" name="coin du
-nouveau responsable">. Elle décrit toutes les étapes préparatoires qu'il vous
-faudra franchir avant de déposer votre candidature.
-
-Par exemple, avant d'être candidat, il vous faudra lire le
-<url id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
-Debian implique que vous adhériez à ce contrat social
-et que vous vous engagiez à le soutenir&nbsp;; il est très important que les
-responsables soient en accord avec les principes fondamentaux qui animent le
-projet &debian-formal;. Lire le <url id="&url-gnu-manifesto;" name="Manifeste
-GNU"> est aussi une bonne idée.
-
+ documentation disponible dans le <url id="&url-newmaint;" name="coin du nouveau
+ responsable">. Elle décrit toutes les étapes préparatoires qu'il vous faudra
+ franchir avant de déposer votre candidature.
+
+Par exemple, avant d'être candidat, il vous faudra lire le <url
+ id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
+ Debian implique que vous adhériez à ce contrat social et que vous vous engagiez
+ à le soutenir&nbsp;; il est très important que les responsables soient en
+ accord avec les principes fondamentaux qui animent le projet &debian-formal;.
+ Lire le <url id="&url-gnu-manifesto;" name="Manifeste GNU"> est aussi une bonne
+ idée.
 <p>
 Le processus d'enregistrement a pour but de vérifier votre identité, vos
-intentions et vos compétences. Le nombre de personnes travaillant pour
-&debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
-dans plusieurs endroits très importants&nbsp;: nous devons rester
-attentifs pour éviter un acte malveillant. C'est pourquoi nous contrôlons les
-nouveaux responsables avant de leur donner un compte sur nos serveurs et les
-autoriser à ajouter des paquets dans l'archive.
-
+ intentions et vos compétences. Le nombre de personnes travaillant pour
+ &debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
+ dans plusieurs endroits très importants&nbsp;: nous devons rester vigilants
+ pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux
+ responsables avant de leur donner un compte sur nos serveurs et de les autoriser à
+ ajouter des paquets dans l'archive.
 <p>
 Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
-et être un bon contributeur. Pour cela, vous pourrez proposer des
-rustines par le système de suivi des bogues (BTS) ou maintenir un paquet
-parrainé pendant un temps. Nous attendons aussi des contributeurs qu'ils
-soient intéressés par le projet dans son ensemble et pas uniquement par leurs
-propes paquets. Si vous pouvez aider d'autres responsables en fournissant des
-informations sur un bogue ou même avec une rustine, faite-le&nbsp;!
-
+ et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs
+ par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé
+ pendant un temps. Nous attendons aussi des contributeurs qu'ils soient
+ intéressés par le projet dans son ensemble et pas uniquement par leurs propres
+ paquets. Si vous pouvez aider d'autres responsables en fournissant des
+ informations sur un bogue ou même avec un correctif, faites-le&nbsp;!
 <p>
 Pour votre candidature, vous devrez être familiarisé avec la philosophie du
-projet Debian et avec sa documentation technique. Il vous faudra aussi une
-clé GPG signée par un responsable Debian. Si votre clé GPG n'est pas encore
-signée, vous devriez essayer de recontrer un responsable Debian pour le faire.
-La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
-GPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
-(Si vous ne trouvez pas de responsable près de chez vous, il existe un second
-moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
-signée avec votre clé GPG. Privilégiez tout de même la clé GPG signée pour 
-valider une identité. Reportez-vous à la <url id="&url-newmaint-id;"
-name="page d'identification"> pour en savoir plus sur ces deux options.)
-
-<p>
-Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une
-clé OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez
-la documentation du logiciel de cryptographie que vous utiliserez car elle
-contient des informations indispensables pour la sécurité de votre clé. Les 
-défaillances de sécurité sont bien plus souvent dues à des erreurs humaines 
-qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
-<ref id="key-maint"> pour plus d'information sur la gestion de votre clé
-publique.
-
+ projet Debian et avec sa documentation technique. Il vous faudra aussi une clé
+ GnuPG signée par un responsable Debian. Si votre clé GnuPG n'est pas encore
+ signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
+ La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
+ GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
+ (Si vous ne trouvez pas de responsable près de chez vous, il existe un second
+ moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
+ signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour
+ valider une identité. Reportez-vous à la <url id="&url-newmaint-id;" name="page
+ d'identification"> pour en savoir plus sur ces deux options.)
+
+<p>
+Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé
+ OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la
+ documentation du logiciel de cryptographie que vous utiliserez car elle
+ contient des informations indispensables pour la sécurité de votre clé. Les
+ défaillances de sécurité sont bien plus souvent dues à des erreurs humaines
+ qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
+ <ref id="key-maint"> pour plus d'informations sur la gestion de votre clé
+ publique.
 <p>
 Debian utilise <prgn>GNU Privacy Guard</prgn> (paquet <package>gnupg</package>
-version 1 ou supérieure comme standard de base). Vous pouvez aussi utiliser une
-autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la
-<url id="&url-rfc2440;" name="RFC 2440">.
-
+ version 1 ou supérieure) comme standard de base. Vous pouvez aussi utiliser une
+ autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la <url
+ id="&url-rfc2440;" name="RFC 2440">.
 <p>
 L'algorithme à clé publique recommandé pour les développements Debian est DSA
-(parfois appelé «&nbsp;DSS&nbsp;» ou «&nbsp;DH\ElGamal&nbsp;»). Vous pouvez
-aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
-minimum de 1024 bits&nbsp;; il n'y a pas de raison d'utiliser une clé plus courte et le
-faire serait beaucoup moins sûr. Votre clé doit être signée avec votre propre
-identifiant&nbsp;; cela évite les falsifications. <prgn>GNU Privacy Guard</prgn> le
-fait automatiquement.
-
+ (parfois appelé «&nbsp;DSS&nbsp;» ou «&nbsp;DH\ElGamal&nbsp;»). Vous pouvez
+ aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
+ minimum de 1024 bits&nbsp;; il n'y a pas de raison d'utiliser une clé plus
+ courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec
+ votre propre identifiant&nbsp;; cela évite les falsifications. <prgn>GNU
+ Privacy Guard</prgn> le fait automatiquement.
 <p>
 Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;,
-reportez-vous à la documentation disponible localement dans &file-keyservs;.
-Cette documentation explique comment mettre votre clé publique sur un serveur.
-L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
-clés si elle n'y est pas déjà.
-
-<p>
-Certains pays limitent l'usage des logiciels de cryptographie.  Cela ne
-devrait cependant pas avoir d'impact sur l'activité d'un responsable de paquet
-car il peut être tout à fait légal d'utiliser des logiciels de cryptographie
-pour l'authentification plutôt que pour le cryptage (comme c'est le cas en
-France). &debian-formal; ne nécessite en aucune manière de cryptographie en
-tant que cryptage. Si vous vivez dans un pays où l'usage de la cryptographie
-pour authentification est interdit, contactez-nous pour que nous prenions des
-dispositions particulières.
-
-<p>
-Pour faire acte de candidature, il vous faut un responsable Debian qui
-vérifiera votre candidature (un <em>avocat</em>). Après avoir contribué au
-projet Debian pendant un temps, quand vous choisissez de devenir un
-responsable Debian officiel, un responsable déjà enregistré avec qui vous
-aurez travaillé dans les derniers mois devra exprimer que, d'après lui, vous
-pouvez contribuer avec succès au projet Debian.
-
-<p>
-Quand vous avez trouvez un <em>avocat</em>, quand votre clé GPG est signée et
-quand vous avez contribuez pendant un temps au projet vous êtes près pour
-faire acte de candidature. Il vous suffit pour cela de vous enregistrer sur
-notre <url id="&url-newmaint-apply;"  name="page de candidature">. Ensuite,
-votre avocat devra confirmer votre candidature. Quand il aura accompli cette
-tâche, un responsable de candidature<footnote>Application manager</footnote>
-sera désigné pour vous accompagner dans le processus d'enregistrement. Vous
-pouvez toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord
-des candidatures"> pour connaître l'état de votre candidature.
-
-
+ reportez-vous à la documentation disponible localement dans &file-keyservs;.
+ Cette documentation explique comment mettre votre clé publique sur un serveur.
+ L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
+ clés si elle n'y est pas déjà.
+<p>
+Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait
+ cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
+ peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
+ l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite
+ en aucun chiffrement. Si vous vivez dans un pays où l'utilisation de la
+ cryptographie pour authentification est interdite, contactez-nous pour que nous
+ prenions des dispositions particulières.
+<p>
+Pour faire acte de candidature, il vous faut un responsable Debian qui vérifiera
+ votre candidature (un <em>avocat</em>). Après avoir contribué au projet Debian
+ pendant un temps, quand vous choisissez de devenir un responsable Debian
+ officiel, un responsable déjà enregistré avec qui vous aurez travaillé dans les
+ derniers mois devra exprimer que, d'après lui, vous pouvez contribuer avec
+ succès au projet Debian.
+<p>
+Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et
+ quand vous avez déjà contribué au projet, vous êtes prêt à faire
+ acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre
+ <url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre
+ avocat devra confirmer votre candidature. Quand il aura accompli cette tâche,
+ un responsable de candidature<footnote><p>Application manager</footnote> sera
+ désigné pour vous accompagner dans le processus d'enregistrement. Vous pouvez
+ toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord des
+ candidatures"> pour connaître l'état de votre candidature.
 <p>
 Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
-nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître
-les étapes nécessaires au processus d'enregistrement avant vous porter
-candidat. Vous gagnerez beaucoup de temps si vous êtes bien préparé.
+ nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître les
+ étapes nécessaires au processus d'enregistrement avant de vous porter candidat.
+ Vous gagnerez beaucoup de temps si vous êtes bien préparé.
 
 
-       <sect id="mentors">Mentors et parrains Debian
+      <sect id="mentors">Mentors et parrains Debian
 <p>
-La liste de diffusion &email-debian-mentors; a été créée pour les
-responsables débutants qui cherchent de l'aide pour leur première
-création de paquet ainsi que pour des problèmes spécifiques aux 
-développeurs. Tout responsable débutant est invité à s'y inscrire 
-(voir <ref id="mailing-lists"> pour plus de détails).
-
+La liste de diffusion &email-debian-mentors; a été créée pour les responsables
+ débutants qui cherchent de l'aide pour leur première création de paquet ainsi
+ que pour des problèmes spécifiques aux développeurs. Tout responsable débutant
+ est invité à s'y inscrire (voir <ref id="mailing-lists"> pour plus de détails).
 <p>
-Ceux qui préfèrent une aide personnalisée (via une correspondance
-privée) doivent aussi poster dans cette liste, un développeur 
-expérimenté se portera volontaire pour les aider.
-
+Ceux qui préfèrent une aide personnalisée (via une correspondance privée)
+ doivent aussi poster dans cette liste, un développeur expérimenté se portera
+ volontaire pour les aider.
 <p>
-De plus, si vous avez des paquets prêts à être intégrés mais attendez le
-résultat de votre candidature, vous pouvez chercher un parrain qui
-téléchargera les paquets pour vous. Les parrains sont des responsables Debian
-officiels volontaires pour examiner vos paquets et les télécharger pour vous.
-Vous pouvez demander un parrainage à l'adresse <url id="&url-sponsors;">.
-
+Si vos paquets sont prêts à être intégrés mais que vous attendiez le
+ résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera
+ les paquets à votre place. Les parrains sont des responsables Debian officiels
+ volontaires pour examiner et télécharger vos paquets. Vous pouvez
+ demander un parrainage à l'adresse <url id="&url-sponsors;">.
 <p>
-Si vous désirez être mentor ou parrain, reportez vous à <ref id="newmaint">.
-
-
-       <chapt id="developer-duties">Les charges du responsable Debian
+Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.
 
 
-       <sect id="user-maint">Mise à jour de vos références Debian
+    <chapt id="developer-duties">Les charges du responsable Debian
 
+      <sect id="user-maint">Mise à jour de vos références Debian
 <p>
-Une base de données LDAP contient de nombreuses informations concernant
-les développeurs, vous pouvez y accéder à l'adresse <url
-id="&url-debian-db;">.  Vous pouvez modifier votre mot de passe (ce mot de
-passe est diffusé sur la plupart des machines auxquelles vous avez accès),
-votre adresse, votre pays, la latitude et la longitude de l'endroit où vous
-résidez, vos numéros de téléphone et de fax, votre interpréteur de commande
-préféré, votre surnom IRC, votre page web, votre adresse de courrier
-électronique ainsi que l'alias que vous utilisez pour votre courrier
-électronique chez debian.org. La plupart de ces informations ne sont pas
-accessibles au public. Pour plus de détails au sujet de cette base de données
-reportez-vous à sa documentation en ligne disponible à l'adresse <url
-id="&url-debian-db-doc;">.
-
+Il existe une base de données LDAP qui contient des informations concernant 
+les développeurs&nbsp;;
+ vous pouvez y accéder à l'adresse <url id="&url-debian-db;">. Vous pouvez
+ modifier votre mot de passe (ce mot de passe est diffusé sur la plupart des
+ machines auxquelles vous avez accès), votre adresse, votre pays, la latitude et
+ la longitude de l'endroit où vous résidez, vos numéros de téléphone et de fax,
+ votre interpréteur de commande préféré, votre surnom IRC, votre page web, votre
+ adresse de courrier électronique ainsi que l'alias que vous utilisez pour votre
+ courrier électronique chez debian.org. La plupart de ces informations ne sont
+ pas accessibles au public. Pour plus de détails au sujet de cette base de
+ données, reportez-vous à sa documentation en ligne disponible à l'adresse <url
+ id="&url-debian-db-doc;">.
 <p>
 Vous y tiendrez à jour les informations vous concernant.
 
-
-
-
-       <sect id="key-maint">Gérer votre clé publique
-
+      <sect id="key-maint">Gérer votre clé publique
 <p>
-Soyez très vigilant en utilisant votre clé privée.  Ne la placez pas sur un
-serveur public ou sur des machines multi-utilisateurs telles que
-<tt>master.debian.org</tt>.  Sauvegardez vos clés et gardez-en une copie hors
-connexion. Lisez la documentation fournie avec votre logiciel et la <url
-id="&url-pgp-faq;" name="FAQ PGP">.
-
+Soyez très vigilant en utilisant votre clé privée. Ne la placez pas sur un
+ serveur public ou sur des machines multi-utilisateurs telles que les serveurs
+ Debian (voir <ref id="server-machines">). Sauvegardez vos clés et gardez-en une
+ copie hors connexion. Lisez la documentation fournie avec votre logiciel et la
+ <url id="&url-pgp-faq;" name="FAQ PGP">.
 <p>
 Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous
-pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
-<tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez
-un courrier à &email-debian-keyring;. Les procédures d'extraction de clé
-décrites dans <ref id="registering"> s'appliquent ici.
-
+ pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
+ <tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez
+ un courrier à &email-debian-keyring;. Les procédures d'extraction de clé
+ décrites dans <ref id="registering"> s'appliquent ici.
 <p>
 Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
-dans la documentation du paquet <package>debian-keyring</package>.
-
-
-
-
-       <sect id="inform-vacation">Prendre des vacances courtoisement
-
+ dans la documentation du paquet <package>debian-keyring</package>.
+
+
+       <sect id="voting">Voter
+<p>
+Debian, sans être une vraie démocratie, dispose d'outils à
+ caractère démocratique et utilise un procédé démocratique pour élire son chef
+ ou pour approuver une résolution. Ces procédures sont décrites dans la <url
+ id="&url-constitution;" name="Constitution Debian">.
+<p>
+Un processus démocratique ne fonctionne bien que si tout le monde participe au
+ vote, c'est pourquoi vous devez voter. Pour cela, vous devez vous inscrire à la
+ liste &email-debian-devel-announce; car les annonces de votes sont publiées sur
+ cette liste. Si vous voulez suivre les débats qui précèdent un vote,
+ inscrivez-vous à liste &email-debian-vote;.
+<p>
+La liste de toutes les propositions (passées et présentes) est disponible à la
+ page <url id="&url-vote;" name="Informations sur les votes Debian">. Vous y
+ trouverez aussi des informations complémentaires sur la procédure à suivre pour
+ proposer un vote.
+
+
+      <sect id="inform-vacation">Prendre des vacances courtoisement
+<p>
+La plupart des développeurs prennent des vacances&nbsp;; généralement, cela
+ signifie qu'ils ne peuvent ni travailler pour Debian, ni être joints par
+ courrier électronique si un problème se présentait. Les autres développeurs ont
+ besoin de savoir que vous êtes en vacances&nbsp;; ainsi ils sauront comment
+ réagir en cas de problème. En général, cela signifie que les autres
+ développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
+ cas de gros problème (bogues empêchant l'intégration dans la distribution, mise à jour de
+ sécurité, etc.) durant vos vacances.
+<p>
+Il y a deux choses à faire pour en informer les autres développeurs.
+ Premièrement, envoyez un courrier électronique indiquant vos dates de vacances
+ à &email-debian-private;, vous pouvez aussi donner quelques instructions pour
+ indiquer comment agir si un problème survenait. Notez bien que certaines
+ personnes ne sont pas intéressées par les annonces de vacances et ne veulent
+ pas les lire&nbsp;; veuillez ajouter '[VAC] ' à l'objet de votre courrier pour
+ qu'il soit facilement filtré.
+<p>
+Deuxièmement, il faut mettre à jour la base de données Debian LDAP et vous
+ signaler «&nbsp;en vacances&nbsp;»<footnote><p><em>on vacation</em> en
+ anglais</footnote>(l'accès à cette information est réservé aux développeurs).
+ N'oubliez pas de retirer votre indicateur «&nbsp;en vacances&nbsp;» lorsque
+ celles-ci sont terminées&nbsp;!
+
+      <sect id="upstream-coordination">Coordination avec les développeurs amonts
+<p>
+Une grande part de votre travail de responsable Debian sera de rester en contact
+ avec les développeurs amonts. Parfois, les utilisateurs établissent des
+ rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez transmettre
+ ces rapports de bogue aux développeurs amonts pour qu'ils soient corrigés dans
+ les prochaines versions. Il n'est pas de votre responsabilité de corriger les
+ bogues qui ne sont pas spécifiques à Debian. Toutefois, si vous êtes capable de
+ le faire, nous vous encourageons à contribuer au développement amont en
+ proposant un correctif qui corrige le bogue. Les utilisateurs et responsables
+ Debian proposent souvent des correctifs pour corriger des bogues amonts, il
+ vous faudra alors évaluer ce correctif puis le transmettre aux développeurs
+ amonts.
 <p>
-La plupart des développeurs prennent des vacances&nbsp;; généralement, cela signifie
-qu'ils ne peuvent ni travailler pour Debian ni être joints par
-courrier électronique si un problème se présentait. Les autres développeurs
-ont besoin de savoir que vous êtes en vacances&nbsp;; ainsi ils sauront comment
-réagir en cas de problème. En général, cela signifie que les autres
-développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
-cas de gros problème (bogues bloquants pour la distribution, mise à jour de
-sécurité...) durant vos vacances.
-
+Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
+ paquet conforme à la charte Debian, alors vous devriez proposer un correctif
+ aux développeurs amonts pour qu'il soit inclus dans leur version. Ainsi, vous
+ n'aurez plus besoin de modifier les sources lors des mises à jour amonts
+ suivantes. Quels que soient les changements dont vous avez besoin, il faut
+ toujours essayer de rester dans la lignée des sources amonts.
+
+      <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du paquet dans la distribution&nbsp;?
+<p>
+Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel
+ que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une
+ catégorie spéciale de bogues qui nécessite particulièrement votre
+ attention&nbsp;: les bogues empêchant l'intégration du paquet dans la
+ distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC
+ Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>,
+ <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>,
+ <em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
+ ayant un impact sur la présence du paquet dans la prochaine version stable de
+ Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
+ et/ou peuvent justifier la suppression d'un paquet d'une distribution gelée.
+ C'est pourquoi ces bogues ont besoin d'être corrigés au plus vite.
+<p>
+Les développeurs faisant partie de l'équipe d'<url id="&url-debian-qa;"
+ name="assurance qualité Debian"> surveillent ces bogues et essaient de vous
+ aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de
+ ce type dans les deux semaines, vous devriez soit demander de l'aide en
+ envoyant un courrier à l'équipe d'assurance qualité (<em>QA group</em>) à
+ &email-debian-qa;, soit expliquer vos difficultés et présenter un plan pour
+ corriger le problème en répondant au rapport de bogue concerné. Si rien n'est
+ fait, des personnes de l'équipe d'assurance qualité pourraient chercher à
+ corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter
+ (ils pourraient attendre moins longtemps que d'habitude pour faire leur mise à
+ jour s'il n'y a pas trace d'activité récente de votre part dans le système de
+ suivi des bogues).
+
+
+      <sect>Démissionner
+<p>
+Si vous choisissez de quitter le projet Debian, procédez comme suit&nbsp;:
+<enumlist compact="compact">
+  <item><p>abandonnez tous vos paquets comme décrit dans <ref
+       id="orphaning">&nbsp;;</item>
+  <item><p>envoyez un courrier électronique à &email-debian-private; indiquant
+       pourquoi vous quittez le projet&nbsp;;</item>
+  <item><p>signalez aux responsables du porte-clés Debian que vous quittez le
+       projet en écrivant à &email-debian-keyring;.</item>
+</enumlist>
+
+
+
+   <chapt id="resources">Ressources pour le responsable Debian
+<p>
+Dans ce chapitre, vous trouverez une brève description des listes de diffusions,
+ des machines Debian qui seront à votre disposition en tant que responsable
+ Debian ainsi que toutes les autres ressources à votre disposition pour vous
+ aider dans votre travail de responsable.
+
+      <sect id="mailing-lists">Les listes de diffusion
+<p>
+Le serveur de liste de diffusion est <tt>&lists-host;</tt>.
+<p>
+Les archives des listes de diffusion sont consultables à <url
+ id="&url-lists-archives;">.
+
+       <sect1 id="core-devel-mailing-lists">Principales listes pour les responsables
+<p>
+Les principales listes de diffusion de Debian que les développeurs
+ devraient suivre sont&nbsp;:
+<list>
+<item>&email-debian-devel-announce;, utilisée pour les annonces importantes
+      faites aux responsables. Tous les responsables Debian sont censés être
+      inscrits à cette liste,</item>
+<item>&email-debian-devel;, utilisée pour discuter de diverses questions
+      techniques relatives au développement,</item>
+<item>&email-debian-policy; où l'on discute et vote les modifications de la
+      Charte Debian,</item>
+<item>&email-debian-project;, utilisée pour discuter de questions non
+      techniques.</item>
+</list>
 <p>
-Il y a deux choses à faire pour informer les autres développeurs.
-Premièrement, envoyer un courrier électronique indiquant vos dates de vacances
-à &email-debian-private;, vous pouvez aussi donner quelques instructions pour
-indiquer comment agir si un problème survenait. Notez bien que certaines 
-personnes ne sont pas intéressées par les annonces de vacances et ne
-veulent pas les lire&nbsp;; ajoutez '[VAC] ' à l'objet de votre courrier
-pour qu'il soit facilement filtré.
+Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
+ Reportez-vous à la page <url id="&url-debian-lists-subscribe;"> pour en obtenir
+ la liste complète.
 
+       <sect1 id="mailing-lists-subunsub">S'abonner et se désabonner
 <p>
-Deuxièmement, il faut mettre
-à jour la base de données Debian LDAP et vous signaler «&nbsp;en
-vacances&nbsp;» (l'accès à cette information est réservé aux développeurs).
-N'oubliez pas de retirer votre indicateur «&nbsp;en vacances&nbsp;» lorsque
-celles-ci sont terminées&nbsp;!
-
-
-
-
-       <sect id="upstream-coordination">Coordination avec les développeurs
-       amonts
-
+Pour vous abonner ou vous désabonner de n'importe quelle liste,
+ envoyez un courrier électronique à
+ <tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>, où
+ <tt>debian-<var>foo</var></tt> est le nom de la liste, avec le mot
+ <tt>subscribe</tt> dans le champ <em>Objet</em><footnote><p><em>Subject</em>
+ en anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt>
+ pour vous désabonner.
 <p>
-Une grosse part de votre travail de responsable Debian sera de rester en
-contact avec les développeurs amonts. Parfois, les utilisateurs établissent
-des rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez
-transmettre ces rapports de bogue aux développeurs amonts pour qu'ils soient
-corrigés dans les prochaines versions.  Il n'est pas de votre responsabilité
-de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
-si vous êtes capable de le faire, nous vous encourageons à contribuer au
-développement amont en proposant une rustine qui corrige ce bogue.
-Les utilisateurs et responsables Debian proposent souvent des rustines
-pour corriger des bogues amonts, il vous faudra alors évaluer cette
-rustine puis la transmettre aux développeurs amonts.
-
+Si vous préférez utiliser une page web pour vous inscrire à plusieurs listes,
+ celle-ci se trouve à l'adresse <url id="&url-debian-lists-subscribe;">.
 <p>
-Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
-paquet conforme à la charte Debian, alors vous devriez proposer une 
-rustine aux développeurs amonts pour qu'elle soit incluse dans leur
-version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
-mises à jour amonts suivantes.  Quels que soient les changements dont vous
-avez besoin, il faut toujours essayer de rester dans la lignée des sources
-amonts. 
-
-
-
-
-
-       <sect id="rc-bugs">Gestion des bogues bloquants pour la distribution
+Vous pouvez télécharger la liste des listes de diffusion et quelques
+ instructions à <url id="&url-debian-lists-txt;"> ou installer le paquet
+ <package>doc-debian</package> et en disposer localement dans le fichier
+ &file-mail-lists;.
 
+       <sect1 id="mailing-lists-rules">Règles d'usage simple
 <p>
-Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais
-<em>Release-critical bug (RCB)</em></footnote> sont les bogues de gravité
-<em>critique</em>, <em>grave</em> et <em>sérieuse</em><footnote>Respectivement
-<em>critical</em>, <em>grave</em> et <em>serious</em> en anglais</footnote>.
-Ces bogues peuvent retarder la diffusion d'une distribution Debian et/ou
-peuvent justifier la suppression d'un paquet d'une distribution gelée. C'est
-pourquoi ces bogues ont besoin d'être corrigés au plus vite.  Vous devez être
-conscient que certains développeurs faisant partie de l'équipe d'<url
-id="&url-debian-qa;" name ="assurance qualité Debian"> surveillent ces bogues
-et essaient de vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas
-corriger un bogue de ce type dans les deux semaines, vous devriez soit
-demander de l'aide en envoyant un courrier à l'équipe d'assurance qualité
-(<em>QA group</em> &email-debian-qa;), soit expliquer vos difficultés et
-présenter un plan pour corriger le problème en répondant au rapport de bogue
-concerné. Si rien n'est fait, des personnes de l'équipe d'assurance qualité
-pourraient chercher à corriger votre paquet (voir <ref id="nmu">) après avoir
-tenté de vous contacter. Ils pourraient attendre moins longtemps que
-d'habitude pour faire leur mise à jour s'il n'y a pas trace d'activité récente
-de votre part dans le système de suivi des bogues.
-
-
-
-       <sect id="qa-effort">L'effort d'assurance qualité
-
+Lorsque vous répondez aux messages d'une liste de diffusion, n'envoyez pas de
+ copie (<tt>CC</tt>) à l'auteur du courrier à moins qu'il ne l'ait demandé
+ explicitement. Quelqu'un qui envoie un message à une liste de diffusion se doit
+ d'y lire les réponses.
 <p>
-Même s'il y a un groupe de personnes dédié à l'assurance qualité, cette
-activité ne leur est pas réservée. Vous pouvez participer à cet effort en
-éliminant, autant que faire se peut, tout bogue de vos paquets et en observant
-les remarques émises par <prgn>lintian</prgn> (voir <ref id="lintian-reports">).  Si cela
-ne vous semble pas possible, il faudrait songer à abandonner certains
-de vos paquets (voir <ref id="orphaning">). Vous pouvez aussi
-demander l'aide d'autres personnes pour rattraper votre retard dans la liste
-des bogues (vous pouvez demander de l'aide sur les listes  &email-debian-qa;
-et &email-debian-devel;).  
-
+La multi-diffusion (envoyer le même message à plusieurs listes) est déconseillé.
+ Comme toujours sur Internet, veuillez réduire le texte cité des messages
+ auxquels vous répondez. En général, veuillez adhérer aux conventions usuelles
+ d'envoi de messages. Veuillez lire le <url id="&url-debian-lists;" name="code
+ de conduite"> pour plus d'information.
 
-       <sect id="mia-qa">Responsables injoignables
+       <sect1 id="mailing-lists-special">Listes spéciales
 <p>
-Si vous remarqué qu'un paquet manque d'attention, assurez-vous que le
-responsable est toujours actif et continuera à travailler sur son paquet.
-Essayez de le contacter.
-
+&email-debian-private; est une liste de diffusion destinée aux discussions
+ privées entre développeurs Debian. Elle doit être utilisée pour tout message
+ qui ne doit pas être publié, quelle qu'en soit la raison. C'est une liste à
+ faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
+ réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
+ de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
+ cette liste ne sont pas disponibles sur la toile. Vous pouvez les consulter en
+ visitant le répertoire <file>~debian/archive/debian-private</file> avec votre
+ compte sur <tt>lists.debian.org</tt>.
 <p>
-Si vous n'obtenez pas de réponse après quelques semaines, rassemblez toutes
-les informations utiles sur ce responsable. Commencez par consulter la <url
-id="http://db.debian.org" name="base de données des développeurs"> pour
-déterminer si le responsable est en vacances et quand il a été vu pour la
-dernère fois. Listez les paquets importants gérés par ce responsable et les
-bogues bloquants pour la distribution qui concernent ces paquets.
-
-<p> Envoyez toutes ces informations à &email-debian-qa; pour que l'équipe
-d'assurance qualité prenne les mesures nécessaires.
-
-       <sect>Démissionner
+&email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
+ pour les correspondances relatives à Debian qu'il serait utile d'archiver,
+ telles que des échanges avec les auteurs amonts à propos de licences, de bogues
+ ou encore des discussions sur le projet avec d'autres personnes.
+
+      <sect id="irc-channels">Canaux IRC
+<p>
+Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
+ principalement hébergés sur le réseau <url id="&url-openprojects;"
+ name="freenode"> (anciennement connu sous le nom de Open Projects Network).
+ L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
+ <tt>irc.openprojects.net</tt>.
+<p>
+Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
+canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles
+ récentes dans le sujet et qui est administré par des robots. <em>#debian</em>
+ est destiné aux anglophones&nbsp;; il existe également <em>#debian.de</em>,
+ <em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms
+ semblables pour les personnes parlant d'autres langues.
+<p>
+Le canal principal pour le développement Debian est <em>#debian-devel</em>.
+ C'est un canal très actif avec habituellement plus de 150 personnes connectées
+ en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce
+ n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est
+ cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est
+ toujours rempli d'informations intéressantes.
+<p>
+Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler
+ de problèmes discutés sur &email-debian-private;. Il existe un canal protégé
+ par clé <em>#debian-private</em> dans ce but. La clé est disponible dans les
+ archives de debian-private à
+ <file>master.debian.org:&file-debian-private-archive;</file>, effectuez
+ simplement un <prgn>zgrep</prgn> avec <em>#debian-private</em> dans tous les
+ fichiers.
+<p>
+Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
+ est utilisé pour la coordination des <em>chasses aux bogues</em>.
+ <em>#debian-boot</em> est utilisé pour la coordination du travail sur les
+ disquettes de démarrage (i.e. l'installeur). <em>#debian-doc</em> est utilisé
+ occasionnellement pour travailler sur la documentation comme celle que vous
+ lisez actuellement. D'autres canaux sont dédiés à une architecture ou un
+ ensemble de paquets&nbsp;: <em>#debian-bsd</em>, <em>#debian-kde</em>,
+ <em>#debian-jr</em>, <em>#debian-edu</em>, <em>#debian-sf</em> (paquet
+ SourceForge), <em>#debian-oo</em> (paquet OpenOffice), etc.
+<p>
+Certains canaux pour développeurs non anglophones existent, par exemple,
+ <em>#debian-devel-fr</em> pour les francophones intéressés dans le
+ développement de Debian.
+
+
+      <sect id="doc-rsrcs">Documentation
+<p>
+Ce document contient beaucoup d'informations très utiles aux développeurs
+ Debian, mais il ne peut pas tout contenir. La plupart des autres documents
+ intéressants sont référencés dans <url id="&url-devel-docs;" name="le coin du
+ développeur">. Prenez le temps de parcourir tous les liens, vous apprendrez
+ encore beaucoup de choses.
+
+
+      <sect id="server-machines">Les serveurs Debian
+<p>
+Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent
+ les fonctions critiques du projet Debian. La plupart des machines sont
+ utilisées pour des activités de portage et elles ont toutes un accès permanent
+ à Internet.
+<p>
+La plupart des machines peuvent être utilisées par les développeurs
+ tant qu'ils respectent les règles définies dans la <url
+ id="&url-dmup;" name="charte d'utilisation des machines Debian">.
+<p>
+Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs
+ à Debian comme vous l'entendez. Veuillez cependant être gentil avec les
+ administrateurs système et ne pas utiliser de grandes quantités d'espace
+ disque, de ressource réseau ou CPU sans obtenir auparavant l'accord des
+ administrateurs. Habituellement, ces machines sont administrées par des
+ volontaires.
+<p>
+Veuillez prendre soin de votre mot de passe Debian ainsi que des clés SSH
+ installées sur les machines Debian. Évitez les méthodes de connexion ou d'envoi
+ de données qui envoient les mots de passe en clair par l'Internet comme telnet,
+ FTP, POP, etc.
+<p>
+Veuillez ne pas déposer de données non relatives à Debian sur les serveurs
+Debian à moins que vous n'ayez préalablement obtenu la permission de le faire.
+<p>
+La liste actuelle des machines Debian est disponible à <url
+ id="&url-devel-machines;">. Cette page web contient les noms des machines, les
+ informations de contact, les informations sur qui peut s'y connecter, les clés
+ SSH, etc.
 <p>
-Si vous choisissez de quitter le projet Debian, procédez comme suit&nbsp;: 
-
-       <enumlist>
-       <item>
-       Abandonnez tous vos paquets comme décrit dans <ref id="orphaning">.
-       
-       <item>
-       Envoyez un courrier électronique à &email-debian-private; indiquant
-       comment vous quittez le projet.
-
-       <item>
-       Signalez aux responsables du porte-clés Debian que vous quittez le
-       projet en écrivant à &email-debian-keyring;.
-
-       </enumlist>
-
-
-       <chapt><heading>Au dela de la mise en paquet</heading>
-
+Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
+ les administrateurs système devraient en être avertis, l'équipe des
+ administrateurs système peut être jointe à
+ <email>debian-admin@lists.debian.org</email>.
 <p>
-Le projet Debian nécessite bien plus que la mise en paquet des logiciels et la
-maintenance de ces paquets. Ce chapitre décrit d'autres types de contributions
-&mdash; contributions souvent d'importance critique pour le projet Debian
-&mdash; au dela de la création et de la maintenance de paquet.
+Si votre problème est lié à un certain service ou n'est pas lié au système
+ (paquet à supprimer de l'archive ou suggestion pour le site web par exemple),
+ il vous faudra en général ouvrir un rapport de bogue sur un
+ «&nbsp;pseudo-paquet&nbsp;». Reportez-vous à la section <ref id="submit-bug">
+ pour connaître la procédure à suivre.
 
+      <sect1 id="servers-bugs">Le serveur pour les rapports de bogues
 <p>
-En tant qu'organisation basée sur le volontariat, Debian compte sur
-l'appréciation de ces membres qui choisiront sur quoi ils veulent travailler
-et sur quoi il est le plus important de passer son temps.
-
-       <sect id="newmaint"><heading>Interaction avec les nouveaux
-       responsables</heading>
-
+<tt>bugs.debian.org</tt> est le serveur maître du système de suivi des bogues
+ (BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
+ System</em> en anglais</footnote>). Si vous envisagez de manipuler les rapports
+ de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
+ faire. Informez la liste &email-debian-devel; de votre intention avant
+ d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
+ gaspillage de temps machine.
 <p>
-Le succès de Debian dépend de sa capacité à attirer et retenir des volontaires
-de talent. Si vous êtes un responsable expérimenté, nous vous recommandons de
-vous impliquer dans le recrutement de nouveaux responsables.  Cette section
-décrit comment aider les nouveaux responsables.
-
-       <sect1 id="sponsoring">Parrainer un paquet
+Tous les développeurs Debian ont un compte sur
+ <tt>bugs.debian.org</tt>.
 
+      <sect1 id="servers-ftp-master">Le serveur ftp-master
 <p>
-Parrainer un paquet signifie télécharger un paquet pour un responsable qui
-n'a pas la possibilité de le faire lui même&nbsp;: un nouveau responsable.
-Parrainer un paquet signifie aussi en accepter la responsabilité.
-
+Le serveur <tt>ftp-master.debian.org</tt> est le serveur maître de l'archive
+ Debian (exception faite des paquets non-US). En général, les mises à jour de
+ paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
+ pour en savoir plus.
 <p>
-Si vous êtes prêt à parrainer un paquet, vous pouvez vous inscrire à <url
-id="&url-sponsors;">.
+Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
+ comme bogue sur le pseudo-paquet <package>ftp.debian.org</package> ou par
+ courrier électronique à &email-ftpmaster;&nbsp;; reportez-vous à la section
+ <ref id="archive-manip"> pour connaître la procédure à suivre.
 
+      <sect1 id="servers-non-us">Le serveur non-US
 <p>
-Les nouveaux responsables ont souvent quelques difficultés pour créer des
-paquets Debian &mdash; ce qui est bien compréhensible. C'est là que le parrain
-intervient. Il vérifie que le paquet est suffisamment bon pour intégrer
-la distribution. Notez que si le paquet est nouveau les administrateurs de
-l'archive l'inspecteront aussi avant de le laisser entrer.
-
+Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie
+ non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une
+ des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section
+ <ref id="upload-non-us"> pour en savoir plus.
 <p>
-Parrainer un paquet en se contentant de signer la livraison ou de recompiler
-le paquet n'est <strong>franchement pas recommandé</strong>. Vous devez
-construire le paquet source comme vous le feriez avec vos propres paquets.
-N'oubliez pas qu'il sera possible de voir que vous avez téléchargé un paquet
-même si vous avez laissé le nom du futur responsable dans les fichiers
-<em>control</em> et <em>changelog</em>.
+Les problèmes avec l'archive de paquets non-US doivent généralement être
+ rapportés comme bogue sur le pseudo-paquet <package>nonus.debian.org</package>
+ pseudo-package (remarquez l'absence de trait d'union entre "non" et "us" dans
+ le nom du pseudo-paquet &mdash; c'est dû à la compatibilité descendante).
+ Rappelez-vous de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de
+ bogue concernant le problème sur le <url
+ id="http://bugs.debian.org/nonus.debian.org" name="système de suivi des
+ bogues">.
 
+      <sect1 id="servers-www">Le serveur www-master
 <p>
-Si vous êtes responsable de candidature pour un nouveau responsable, vous
-pouvez aussi être son parrain. Ainsi vous pouvez aussi vérifier comment le
-candidat traite la partie «&nbsp;Tâches et compétences<footnote>'Tasks and
-Skills'</footnote>&nbsp;» de leur candidature.
-
-       <sect1>Aider un nouveau responsable
-
+Le serveur web principal est <tt>www-master.debian.org</tt>. Il héberge les
+ pages web officielles, la facade de Debian pour la plupart des débutants.
 <p>
-Consultez la page <url id="&url-newmaint-advocate;" name="Aider un futur
-responsable"> sur le site du projet Debian.
-
-
-
-       <sect1>Suivre la candidature d'un nouveau responsable
+Si vous rencontrez un problème avec un serveur web Debian, vous devez
+ généralement envoyer un rapport de bogue sur le pseudo-paquet
+ <package>www.debian.org</package>. Vérifiez d'abord sur le <url
+ id="http://bugs.debian.org/www.debian.org" name="système de suivi des bogues">
+ que personne ne l'a déjà rapporté avant vous.
 
+      <sect1 id="servers-people">Le serveur web people
 <p>
-Consultez la page <url id="&url-newmaint-amchecklist;" name="Aide mémoire du
-responsable de candidature"> sur le site du projet Debian.
-
-
-
-
-
-
-       <chapt id="servers">Listes de diffusion, serveurs et autres machines
-
+<tt>people.debian.org</tt> est le serveur utilisé pour les pages personnelles
+ des développeurs concernant ce qui est lié à Debian.
 <p>
-Dans ce chapitre vous trouverez une très brève description des listes de 
-diffusion Debian, des principaux serveurs Debian et des autres machines 
-auxquelles vous aurez accès en tant que développeur.
-
-
-
-       <sect id="mailing-lists">Les listes de diffusion
-
+Si vous avez des informations spécifiques Debian que vous voulez rendre
+ disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
+ <file>public_html</file> de votre répertoire personnel sur
+ <tt>people.debian.org</tt>. Elles seront accessibles à l'adresse
+ <tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
 <p>
-Le serveur de liste de diffusion est <tt>&lists-host;</tt>.  Envoyez un
-courrier électronique à <tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>,
-où <tt>debian-<var>foo</var></tt> est le nom de la liste, avec le mot
-<tt>subscribe</tt> dans le champ <em>Objet</em><footnote><em>Subject</em> en
-anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt> pour
-vous désabonner.  Vous trouverez des instructions plus détaillées pour vous
-abonner et vous désabonner aux adresses <url
-id="&url-debian-lists-subscribe;">, <url id="&url-debian-lists-txt;"> ou
-localement dans le fichier &file-mail-lists; si vous avez installé le paquet
-<package>doc-debian</package>.
-
+Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegardé
+ alors que sur les autres serveurs, ce ne sera pas le cas.
 <p>
-Lorsque vous répondez aux messages d'une liste de diffusion,
-n'envoyez pas de copie (<tt>CC</tt>) à l'auteur du courrier à moins
-qu'il ne l'ait demandé explicitement. Quelqu'un qui envoie un message à une
-liste de diffusion se doit d'y lire les réponses.
-
+Habituellement, la seule raison pour utiliser un serveur différent est que vous
+ avez besoin de publier des informations soumises aux restrictions d'export
+ américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
+ en dehors des États-Unis, comme le serveur mentionné ci-dessus
+ <tt>non-us.debian.org</tt>.
 <p>
-Les principales listes de diffusion Debian sont&nbsp;:
-       <list compact>
-       <item> &email-debian-devel;&nbsp;;
-       <item> &email-debian-policy;&nbsp;;
-       <item> &email-debian-user;&nbsp;;
-       <item> &email-debian-private;&nbsp;;
-       <item> &email-debian-announce; et
-       <item> &email-debian-devel-announce;.
-       </list>
-
-Un développeur devrait, au minimum, être inscrit à la liste
-&email-debian-devel-announce;.
+Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.
 
+      <sect1 id="servers-cvs">Le serveur CVS
 <p>
-Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
-Reportez-vous à la page <url id="&url-debian-lists-subscribe;"> pour en
-obtenir la liste complète.  Nous déconseillons l'usage des correspondances
-croisées (envoyer le même message à plusieurs listes).
-
+Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
 <p>
-&email-debian-private; est une liste de diffusion destinée aux discussions
-privées entre développeurs Debian. Elle doit être utilisée pour tout message
-qui ne doit pas être publié, quelqu'en soit la raison.  C'est une liste à
-faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
-réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
-de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
-cette liste ne sont pas disponible sur la toile. Vous pouvez les consulter en
-visitant le répertoire <file>~debian/archive/debian-private</file> avec votre 
-compte sur <tt>master.debian.org</tt>.
-
+Si vous avez besoin d'un serveur CVS accessible par tous pour, par exemple,
+ coordonner le travail de plusieurs développeurs sur un paquet, vous pouvez
+ demander un espace CVS sur ce serveur.
 <p>
-&email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
-pour les correspondances relatives à Debian qu'il serait utile d'archiver, telles
-que des échanges avec les auteurs amonts à propos de licences, de bogues ou encore
-des discussions sur le projet avec d'autres personnes.
-
+Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en
+ lecture seule pour les connexions client-serveur anonymes et les accès
+ client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut
+ aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">.
+<p>
+Pour obtenir un espace CVS, envoyez une demande à l'adresse &email-debian-admin;
+ en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
+ racine et pourquoi vous en avez besoin.
+
+
+    <sect id="devel-db">La base de données des développeurs
+<p>
+La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire
+ LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser
+ cette ressource pour rechercher la liste des développeurs Debian. Pour plus
+ d'informations sur la façon de garder à jour vos informations dans la base des
+ développeurs, reportez-vous à <ref id="user-maint">. Une partie de ces
+ informations est également disponible à travers le service finger sur les
+ serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
+ qu'il indique.
+<p>
+La base de données vous permet d'enregistrer d'autres informations&nbsp;; par
+exemple, des
+ clés publiques SSH qui seront installées automatiquement sur les machines
+ Debian officielles, ou des entrées DNS  de type *debian.net. Ces fonctionnalités
+ sont documentées à <url id="&url-debian-db-mail-gw;">.
+
+<!--     <sect id="servers-mirrors">Les miroirs des serveurs Debian
+<p>
+Les serveurs web et FTP Debian sont dupliqués sur d'autres serveurs.
+ Évitez de charger les serveurs originaux. Idéalement, les serveurs originaux
+ se contentent de copier leur contenu sur les miroirs de premier niveau et tous
+ les utilisateurs consultent les miroirs. Ainsi le projet Debian étale ses
+ besoins en bande passante sur plusieurs serveurs et plusieurs réseaux. Notez
+ que la duplication des données sur les miroirs est déclenchée par le serveur
+ maître. Ceci nous garantit que les miroirs sont aussi à jour que possible.
+<p>
+La liste des miroirs FTP/HTTP se trouve à l'adresse <url
+ id="&url-debian-mirrors;">. Vous trouverez plus d'information sur les miroirs
+ Debian à l'adresse <url id="&url-debian-mirroring;">. Cette page contient des
+ informations et des outils qui pourront vous aider si vous avez l'intention de
+ mettre en place votre propre miroir, que ce soit pour un usage interne ou pour
+ un accès public.
 <p>
-Comme toujours sur internet, éliminez les lignes inutiles quand vous citez
-le message auquel vous répondez. Plus généralement, respectez
-les conventions habituelles lorsque vous envoyez des messages.
+Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider
+ Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
+ machines.
+-->
 
+    <sect id="archive">L'archive Debian
 <p>
-Les archives des listes de diffusion sont disponibles en ligne à l'adresse
-<url id="&url-lists-archives;">.
-
-
-
-
-       <sect id="server-machines">Les serveurs Debian
-
+La distribution &debian-formal; est composée d'un grand nombre de paquets
+ (fichiers <tt>.deb</tt>&nbsp;: actuellement, à peu près &number-of-pkgs;) et de
+ quelques autres fichiers (comme la documentation et des images des disquettes
+ d'installation).
 <p>
-Les serveurs Debian sont bien connus et hébergent les fonctions
-critiques du projet Debian.  Tout développeur se doit de savoir ce qu'ils sont
-et à quoi ils servent.
-
+Voici un exemple d'arborescence pour une archive Debian complète&nbsp;:
 <p>
-Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
-les administrateurs système devraient en être avertis, vous trouverez
-l'adresse d'un responsable pour cette machine à la page <url
-id="&url-devel-machines;">.  Si votre problème n'est pas lié au système
-(paquet à supprimer ou suggestion pour le site web par exemple), il vous
-faudra en général ouvrir un rapport de bogue sur un
-«&nbsp;pseudo-paquet&nbsp;». Reportez-vous à la section <ref id="submit-bug">
-pour connaître la procédure à suivre.
-
-
-
-
-       <sect1 id="servers-master">Le serveur maître
-
+&sample-dist-dirtree;
 <p>
-<tt>master.debian.org</tt> est le serveur maître du système de suivi des
-bogues (BTS<footnote>Système de suivi des bogues se dit <em>Bug Tracking
-System</em> en anglais</footnote>). Si vous envisagez de manipuler les
-rapports de bogue ou d'en faire une analyse statistique ce sera le bon endroit
-pour le faire.  Informez la liste &email-debian-devel; de votre intention
-avant d'implémenter quoi que ce soit afin d'éviter un travail en double
-ou le gaspillage de temps machine.
-
+Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
+ <file>dists/</file> et <file>pool/</file>. Le second est un ensemble de
+ répertoires où sont stockés les paquets. Ceux-ci sont manipulés grâce à la base
+ de données de l'archive et aux logiciels qui l'accompagnent. Le premier
+ répertoire contient les distributions <em>stable</em>, <em>testing</em> et
+ <em>unstable</em>. Les fichiers <file>Packages</file> et <file>Sources</file>
+ qui se trouvent dans les répertoires de distribution peuvent faire référence à
+ des fichiers du répertoire <file>pool/</file>. Le découpage en sous-répertoires
+ est identique d'un répertoire de distribution à l'autre&nbsp;. Ce que nous
+ exposerons ci-dessous pour la distribution <em>stable</em> est également
+ applicable aux distributions <em>unstable</em> et <em>testing</em>.
+<p>
+Le répertoire <file>dists/stable</file> contient trois répertoires nommés
+  <file>main</file>, <file>contrib</file> et <file>non-free</file>.
+<p>
+Dans chacune de ces sections, se trouve un répertoire contenant les paquets
+  sources (<file>source/</file>) et un répertoire pour chaque architecture
+  acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
 <p>
-Tous les développeurs Debian ont un compte sur <tt>master.debian.org</tt>.
-Prenez grand soin de votre mot de passe. Évitez les méthodes de connexion et
-de téléchargement qui envoient votre mot de passe en clair sur internet.
+La section <em>main</em> contient d'autres répertoires destinés aux images de
+ disquettes et à plusieurs documents essentiels pour installer la distribution
+ Debian sur une architecture particulière (<file>disk-i386/</file>,
+ <file>disk-m68k/</file>, etc).
 
+      <sect1>Les sections
 <p>
-Si vous rencontrez un problème avec <tt>master.debian.org</tt> tel qu'un
-disque plein, une activité suspecte ou autre, envoyez un courrier
-électronique à &email-debian-admin;.
-
-
-
-
-       <sect1 id="servers-ftp-master">Le serveur ftp-master
-
+La section <em>main</em> constitue la <strong>distribution &debian-formal;
+ officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
+ à toutes nos recommandations. Les deux autres sections divergent de ces
+ recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong>
+ officiellement partie de &debian-formal;.
 <p>
-Le serveur ftp-master (<tt>ftp-master.debian.org</tt> ou <tt>
-auric.debian.org</tt>) est le serveur maître de l'archive Debian 
-(exception faite des paquets non-US). En général, les mises à jour de
-paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
-pour en savoir plus.
-
+Chaque paquet de la section <em>main</em> doit être conforme aux <url
+ id="&url-dfsg;" name="directives Debian pour le logiciel
+ libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les
+ autres recommandations décrites dans <url id="&url-debian-policy;" name="la
+ charte Debian"><footnote>Debian Policy Manual</footnote>. Les
+ DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent
+ notre définition de «&nbsp;logiciel libre&nbsp;». Reportez-vous à la <em>charte
+ Debian</em> pour en savoir plus.
+<p>
+Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG, mais
+ ne respectent pas d'autres contraintes. Ils peuvent, par exemple, dépendre de
+ paquets de la section <em>non-free</em>.
 <p>
-Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
-comme bogue contre le pseudo-paquet <package>ftp.debian.org</package> ou par
-courrier électronique à &email-ftpmaster;&nbsp;; reportez-vous à la section <ref
-id="archive-manip"> pour connaître la procédure à suivre.
-
-
-
-
-       <sect1 id="servers-www">Le serveur WWW
-
+Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section
+ <em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils
+ bénéficient de nos infrastructures (système de suivi des bogues, listes de
+ diffusion, etc), ces paquets <em>non-free</em> ne font pas partie de la
+ distribution Debian.
 <p>
-Le serveur web principal, <tt>www.debian.org</tt>, est aussi connu sous le nom
-<tt>klecker.debian.org</tt>. Tous les développeurs ont un compte sur cette
-machine.
-
+La <em>charte Debian</em> donne des définitions plus précises pour ces trois
+ sections. Les paragraphes précédents ne constituent qu'une introduction.
 <p>
-Si vous désirez publier quelques informations spécifiques à Debian sur la
-toile,
-vous pouvez le faire en les déposant dans le sous-répertoire
-<file>public_html</file> de votre répertoire personnel sur
-<tt>klecker.debian.org</tt>. Toute information déposée à cet endroit est
-accessible à l'adresse <tt>http://people.debian.org/~<var>user-id</var>/</tt>.
-Vous devriez préférer ce serveur aux autres car les répertoires
-<file>public_html</file> du serveur <tt>klecker.debian.org</tt> sont
-sauvegardés. Ce n'est pas le cas sur les autres serveurs. N'utilisez pas ces
-serveurs pour publier des informations sans rapport avec le projet Debian
-avant d'en avoir obtenu la permission. Pour toute question supplémentaire,
-adressez-vous à la liste &email-debian-devel;.  
-
+La séparation de l'archive en trois sections est importante pour toute personne
+ qui désire distribuer Debian, que ce soit par serveur FTP ou sur cédérom. Il
+ suffit de distribuer les sections <em>main</em> et <em>contrib</em> pour éviter
+ tout problème légal. Certains paquets de la section <em>non-free</em>
+ interdisent leur distribution à titre commercial par exemple.
 <p>
-Si vous rencontrez un problème avec un serveur web Debian, vous devez
-généralement envoyer un rapport de bogue contre le pseudo-paquet
-<package>www.debian.org</package>.  Vérifiez d'abord sur le <url
-id="http://bugs.debian.org/www.debian.org" name="système de suivi des bogues">
-que personne ne l'a déjà rapporté avant vous.
+D'un autre coté, un distributeur de cédérom pourra facilement vérifier
+ la licence de chacun des paquets de la section <em>non-free</em> et
+ ajouter tous les paquets qu'il pourra ajouter (dans
+ la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne
+ peut être fait par les développeurs Debian).
 
 
+      <sect1>Les architectures
+<p>
+À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
+ x86&nbsp;; il en était de même pour Debian. Linux devenant de plus en plus
+ populaire, il a été porté vers d'autres architectures.
+<p>
+Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
+ Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
+ reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
+ reconnaît ces architectures, Debian a décidé qu'elle devait également les
+ accepter. C'est pourquoi plusieurs portages sont en cours&nbsp;; en fait, il y
+ a aussi des portages vers d'autres noyaux. À coté d'<em>i386</em> (notre nom
+ pour Intel x86), nous avons, au moment où j'écris <em>m68k</em>,
+ <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
+ <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
+ <em>mipsel</em> et <em>sh</em>.
+<p>
+&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
+ reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît
+ les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
+ <em>sparc</em>. Debian 2.2 accepte en plus les architectures
+ <em>powerpc</em> et <em>arm</em>. Debian 3.0 accepte cinq
+ nouvelles architectures&nbsp;: <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
+ <em>mips</em> et <em>mipsel</em>.
+<p>
+Pour chaque portage, vous trouverez des informations destinées aux développeurs
+ et utilisateurs sur la page <url id="&url-debian-ports;" name="Portage
+ Debian">.
+
+      <sect1>Les paquets
+<p>
+Il existe deux types de paquets Debian&nbsp;: les paquets sources et les paquets
+ binaires.
+<p>
+Les paquets sources sont constitués de deux ou trois fichiers&nbsp;: un fichier
+ <file>.dsc</file> et soit un fichier <file>.tar.gz</file>, soit un fichier
+ <file>.orig.tar.gz</file> et un fichier <file>.diff.gz</file>.
+<p>
+Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
+ distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
+ contient les sources du programme. Si un paquet est distribué ailleurs, le
+ fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
+ amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
+ amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
+ <file>.diff.gz</file> contient les modifications faites par le responsable
+ Debian.
+<p>
+Le fichier <file>.dsc</file> liste tous les fichiers sources avec leurs sommes
+ de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
+ concernant le paquet (responsable, version, etc).
 
 
-       <sect1 id="servers-cvs">Le serveur CVS
-       
+      <sect1>Les répertoires des distributions
 <p>
-Le serveur <tt>cvs.debian.org</tt> est aussi connu sous le nom
-<tt>klecker.debian.org</tt> (déjà présenté plus haut). Si vous avez besoin
-d'un serveur CVS accessible par tous pour, par exemple, coordonner le travail
-de plusieurs développeurs sur un paquet, vous pouvez demander un espace sur ce
-serveur.
-
+L'organisation des répertoires présentée précédemment est elle-même englobée par
+ les <em>répertoires des distributions</em>. Chaque distribution est incluse
+ dans le répertoire <file>pool</file> à la racine de l'archive Debian.
 <p>
-Le serveur <tt>cvs.debian.org</tt> autorise les accès CVS locaux, les accès en
-lecture seule pour les connexions client-serveur anonymes et les accès
-client-serveur complets pour les connexions <prgn>ssh</prgn>. L'espace CVS peut
-aussi être consulté par la toile à l'adresse <url id="&url-cvsweb;">.
-
+En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par
+ exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
+ Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
+ courant. Un autre emplacement courant est <file>/pub/debian</file>.
 <p>
-Pour obtenir un espace CVS, envoyez une demande à l'adresse
-&email-debian-admin; en précisant le nom de l'espace, le propriétaire du
-répertoire racine et pourquoi vous en avez besoin.
-
+Une distribution est composée de paquets sources et binaires et des
+ fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
+ contiennent toutes les meta-informations sur les paquets. Les premiers sont
+ conservés dans le répertoire <file>pool/</file> tandis que les seconds sont
+ conservés dans le répertoire <file>dists/</file> de l'archive (pour
+ compatibilité descendante).
 
 
+       <sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et
+       <em>unstable</em>
+<p>
+Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
+ <file>dists/stable</file>), une distribution appelée <em>testing</em> (dans le
+ répertoire <file>dists/testing</file>) et une distribution appelée
+ <em>unstable</em> (dans le répertoire <file>dists/unstable</file>). Ceci
+ reflète le processus de développement du projet Debian.
+<p>
+Les développements se font sur la distribution
+ <em>unstable</em><footnote><p><em>unstable</em> signifie
+ «&nbsp;instable&nbsp;»</footnote> (c'est pourquoi elle est aussi appelée
+ <em>distribution de développement</em>). Chaque développeur Debian peut
+ modifier ses paquets à tout moment dans cette distribution. Ainsi son contenu
+ change tous les jours. Comme aucun effort particulier n'est fait pour s'assurer
+ que tout fonctionne correctement dans cette distribution, elle est parfois
+ littéralement «&nbsp;instable&nbsp;».
+<p>
+<ref id="testing"> est générée automatiquement en prenant les paquets de
+ <em>unstable</em> s'ils satisfont à certains critères. Ces critères
+ garantissent que les paquets de <em>testing</em> sont de bonne qualité. La mise
+ à jour de <em>testing</em> est lancée chaque jour après que les nouveaux
+ paquets ont été installés.
+<p>
+Après une période de développement, quand le responsable de
+ distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
+ la distribution <em>testing</em> est gelée, ce qui signifie que les conditions
+ à remplir pour qu'un paquet passe de <em>unstable</em> à <em>testing</em> sont
+ durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
+ autorisées concernent les corrections de bogues. Après quelque temps, selon
+ l'avancement, la distribution entre dans une phase de «&nbsp;gel complet&nbsp;»
+ où les seules modifications acceptées concernent la procédure d'installation.
+ Cette phase s'appelle un «&nbsp;cycle de test&nbsp;» et cela peut durer jusqu'à
+ deux semaines. Il peut y avoir plusieurs cycles de tests avant que le
+ responsable de distribution ne la déclare prête pour la diffusion. À la fin du
+ dernier cycle de test, la distribution <em>frozen</em> devient <em>stable</em>,
+ remplaçant l'ancienne distribution <em>stable</em> qui est enlevée à cette
+ occasion (elle peut être retrouvée à l'adresse <tt>&archive-host;</tt>).
+<p>
+Ce cycle de développement est basé sur l'idée que la distribution
+ <em>unstable</em> devient <em>stable</em> après une période de test
+ (<em>testing</em>). Une distribution contient inévitablement des bogues, même
+ si elle est classée stable. C'est pourquoi les distributions stables sont mises
+ à jour de temps en temps. Les corrections introduites sont testées avec une
+ grande attention et sont ajoutées une à une à l'archive pour diminuer les
+ risques d'introduire de nouveaux bogues. Vous pouvez trouver des paquets
+ proposés pour les mises à jour de <em>stable</em> dans le répertoire
+ <file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
+ qui ne présentent pas de problème sont installés dans la distribution
+ <em>stable</em> et le numéro de révision de cette distribution est incrémenté
+ («&nbsp;3.0&nbsp;» devient «&nbsp;3.0r1&nbsp;», «&nbsp;2.0r4&nbsp;» devient
+ «&nbsp;2.0r5&nbsp;» et ainsi de suite).
+<p>
+Notez que, pendant la période de gel, les développements continuent sur la
+ distribution <em>unstable</em> car cette distribution reste en place.
+
+       <sect2><em>Experimental</em>
+<p>
+La distribution <em>experimental</em> est une distribution particulière. Ce n'est
+   pas une distribution à part entière comme le sont <em>stable</em> et
+   <em>unstable</em>. Elle est prévue pour servir de plate-forme de
+   développement pour les projets expérimentaux qui risquent vraiment de
+   détruire le système ou bien pour des logiciels qui sont vraiment trop
+   instables pour être inclus dans la distribution <em>unstable</em> (mais pour
+   lesquels une mise en paquet est justifiée). Les utilisateurs qui téléchargent
+   et installent des paquets depuis <em>experimental</em> sont prévenus&nbsp;:
+   on ne peut pas faire confiance à la distribution <em>experimental</em>.
+<p>
+Si un logiciel peut causer des dégats importants, il sera sûrement
+   préférable de le mettre dans la distribution <em>experimental</em>. Un
+   système expérimental de fichier compressé, par exemple, devrait probablement
+   aller dans <em>experimental</em>.
+<p>
+Une nouvelle version amont qui ajoute de nouvelles fonctions tout en supprimant
+   de nombreuses autres ne devra pas être téléchargée dans l'archive Debian,
+   elle pourra cependant être téléchargée dans <em>experimental</em>. Une
+   nouvelle version non finalisée d'un logiciel qui utilise une méthode de
+   configuration complètement différente pourrait aller dans
+   <em>experimental</em> au gré du responsable. Si vous travaillez sur un cas de
+   mise à jour complexe ou incompatible, vous pouvez aussi utiliser
+   <em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
+   accès aux testeurs.
+<p>
+Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>,
+   avec un avertissement dans la description mais ce n'est pas recommandé car
+   les paquets de <em>unstable</em> se propagent dans <em>testing</em> et
+   aboutissent dans <em>stable</em>. Vous ne devriez pas avoir peur d'utiliser
+   <em>experimental</em> car ceci ne cause aucun souci aux ftpmasters, les
+   paquets expérimentaux sont automatiquement enlevés quand vous envoyez le
+   paquet dans <em>unstable</em> avec un numéro de version supérieur.
+<p>
+Un nouveau logiciel qui ne risque pas d'endommager le système ira directement
+   dans <em>unstable</em>.
+<p>
+Une alternative à <em>experimental</em> consiste à utiliser vos pages
+   personnelles sur le serveur <tt>people.debian.org</tt>.
 
-       <sect1 id="servers-mirrors">Les miroirs des serveurs Debian
 
+      <sect1 id="codenames">Les noms de distribution
 <p>
-Les serveurs web et FTP Debian sont dupliqués sur d'autres serveurs. Évitez de
-charger les serveurs originaux. Idéalement, les serveurs originaux se
-contentent de copier leur contenu sur les miroirs de premier niveau et
-tous les utilisateurs consultent les miroirs. Ainsi le projet Debian étale
-ces besoins en bande passante sur plusieurs serveurs et plusieurs réseaux.
-Notez que la duplication des données sur les miroirs est déclenchée par le
-serveur maître. Ceci nous garantit que les miroirs sont aussi à jour que
-possible.
-
+Chaque distribution Debian diffusée a un <em>nom de code</em>&nbsp;: Debian 1.1
+ s'appelle «&nbsp;buzz&nbsp;»&nbsp;; Debian 1.2, «&nbsp;rex&nbsp;»&nbsp;; Debian
+ 1.3 «&nbsp;bo&nbsp;»&nbsp;; Debian 2.0, «&nbsp;hamm&nbsp;»&nbsp;; Debian 2.1,
+ «&nbsp;slink&nbsp;»; Debian 2.2 «&nbsp;potato&nbsp;» et Debian 3.0
+ «&nbsp;woody&nbsp;». Il y a aussi une pseudo-distribution nommée
+ «&nbsp;sid&nbsp;», il s'agit de la distribution <em>unstable</em>&nbsp;; comme
+ les paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent
+ de la stabilité, la distribution «&nbsp;sid&nbsp;» n'est jamais diffusée. En
+ plus du contenu habituel d'une distribution Debian, «&nbsp;sid&nbsp;» contient
+ des paquets pour des architectures qui ne sont pas encore officiellement
+ reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
+ architectures seront intégrées ulterieurement à la distribution principale.
 <p>
-La liste des miroirs FTP (et en général HTTP) se trouve à l'adresse <url
-id="&url-debian-mirrors;">. Vous trouverez plus d'information sur les miroirs
-Debian à l'adresse <url id="&url-debian-mirroring;">. Cette page contient des
-informations et des outils qui pourront vous aider si vous avez l'intention de
-mettre en place votre propre miroir, que ce soit pour un usage interne ou
-pour un accès public.
-
+Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
+ participer et suivre les développements), même les distributions
+ <em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP et
+ FTP de Debian. Si nous avions nommé le répertoire qui contient la prochaine
+ distribution à diffuser «&nbsp;testing&nbsp;», il aurait fallu changer son nom en
+ «&nbsp;stable&nbsp;» au moment de la diffusion, ce qui aurait forcé les miroirs
+ FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse).
+<p>
+D'un autre coté, si une distribution s'appelait <em>Debian-x.y</em> dès le
+ départ, des personnes pourraient s'imaginer que la distribution Debian
+ <em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
+ avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
+ pré-1.0. C'est pour cette raison que la première version officielle était la
+ version 1.1 et non la 1.0.)
 <p>
+En conséquence, les noms de répertoire des distributions dans l'archive sont
+ déterminés par leurs noms de code et non par leur statut (exemple&nbsp;:
+ slink). Ces noms sont identiques pendant la période de développement et une
+ fois la distribution diffusée&nbsp;; des liens symboliques, qui peuvent être
+ modifiés facilement, indiquent la distribution stable actuelle. Tout ceci
+ explique pourquoi les répertoires des distributions sont nommés à partir des
+ noms de code des distributions alors que <em>stable</em>, <em>testing</em> et
+ <em>unstable</em> sont des liens symboliques qui pointent vers les répertoires
+ appropriés.
+
+    <sect id="mirrors">Les miroirs Debian
+       <p>
+Les différentes archives de téléchargement et le site web disposent de plusieurs
+miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
+certains de ces serveurs ne sont pas publics et la charge est
+répartie sur une première série de serveurs. De cette façon, les
+utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
+Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
+plusieurs réseaux différents et évitent aux utilisateurs de surcharger
+l'emplacement primaire. Notez que dans cette première série, les serveurs sont aussi à jour
+que possible car la mise à jour est déclenchée par les sites maîtres internes.
+       <p>
+Toutes les informations sur les miroirs Debian peuvent être trouvées à <url
+id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles
+FTP/HTTP. Cette page utile inclut également des informations et des outils pour
+créer son propre miroir, soit en interne soit pour un accès public.
+       <p>
 Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider
-Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
-machines.
-
-
-
-
-       <sect id="other-machines">Les autres machines Debian
-
+ Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
+ machines.
+
+    <sect id="incoming-system">
+       <heading>Le système Incoming
+<p>
+Le système Incoming est responsable de la collecte des paquets mis à jour et de
+ leur installation dans l'archive Debian. Il est constitué d'un ensemble de
+ répertoires et de scripts qui sont installés à la fois sur
+ <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>.
+<p>
+Les paquets sont envoyés par tous les responsables Debian dans un répertoire
+ nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes
+ par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
+ les signatures de chiffrage. Si le paquet est considéré comme prêt à être
+ installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
+ du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file>
+ où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
+ devant être installés <em>à la main</em>, il est déplacé dans le répertoire
+ <file>byhand</file> où il attend une installation manuelle par les ftpmasters.
+ Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé
+ dans le répertoire <file>reject</file>.
+<p>
+Une fois que le paquet est accepté, le système envoie une confirmation par
+ courrier au responsable et ferme les bogues corrigés par l'envoi, puis
+ les compilateurs automatiques peuvent commencer la recompilation. Le paquet est
+ maintenant accessible publiquement à <url id="&url-incoming;"> (une telle
+ adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il
+ soit vraiment installé dans l'archive Debian. Ceci se produit seulement une
+ fois par jour, le paquet est alors supprimé de <file>Incoming</file> et
+ installé dans le pool avec les autres paquets. Une fois que toutes les autres
+ mises à jour (générant des nouveaux fichiers d'index <file>Packages</file> et
+ <file>Sources</file> par exemple) ont été effectuées, un script spécial est
+ appelé pour demander aux miroirs primaires de se mettre à jour.
+<p>
+Tous les développeurs Debian ont un droit d'écriture dans le répertoire
+ <file>unchecked</file> pour pouvoir y envoyer leurs paquets, ils ont également
+ accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou
+ déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais 
+ seuls les ftpmasters ont droit d'écriture dans les autres répertoires.
+ C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
+ accepté.
+
+      <sect1 id="delayed-incoming">Incoming différé
+<p>
+Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
+ <file>DELAYED</file>. Celui-ci est lui-même subdivisé en neuf répertoires
+ nommés <file>1-day</file> à <file>9-day</file>. Les paquets qui sont envoyés
+ dans l'un de ces répertoires seront déplacés dans le vrai répertoire
+ <file>unchecked</file> après le nombre correspondant de jours. Ceci est fait
+ par un script qui est exécuté chaque jour et qui déplace les paquets entre les
+ répertoires. Ceux qui sont dans «&nbsp;1-day&nbsp;» sont installés dans
+ <file>unchecked</file> alors que les autres sont déplacés dans le répertoire
+ adjacent (par exemple, un paquet dans <file>5-day</file> sera déplacé dans
+ <file>4-day</file>). Cette fonctionnalité est particulièrement utile pour les
+ personnes qui effectuent des mises à jour indépendantes (NMU,
+ «&nbsp;non-maintainer uploads&nbsp;»). Au lieu d'attendre avant d'envoyer la
+ NMU, elle est envoyée dès qu'elle est prête dans l'un de ces répertoires
+ <file>DELAYED/<var>x</var>-day</file>. Ceci laisse le nombre correspondant de
+ jours au responsable pour réagir et envoyer lui-même une autre correction s'il
+ n'est pas complètement satisfait par la NMU. Il peut également enlever
+ complètement la NMU.
+<p>
+L'utilisation de cette fonctionnalité de délai peut être simplifiée en
+ l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez
+ <prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette
+ partie à votre fichier de configuration&nbsp;:
+<example>
+$delay = ($ENV{DELAY} || 7);
+$cfg{'delayed'} = {
+         fqdn => "&ftp-master-host;",
+         login => "yourdebianlogin",
+         incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
+         dinstall_runs => 1,
+         method => "scpb"
+};</example>
+Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être
+utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi&nbsp;:
+<example>DELAY=5 dupload --to delayed &lt;changes-file&gt;</example>
+
+    <sect id="testing">
+       <heading>La distribution «&nbsp;testing&nbsp;»
+<p>
+Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
+ chaque jour après l'installation des paquets mis à jour. Ils génèrent les
+ fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
+ le font d'une manière intelligente pour éviter toute incohérence et essayer de
+ n'utiliser que des paquets sans bogues.
+<p>
+L'inclusion d'un paquet de <em>unstable</em> est soumise aux
+ conditions suivantes&nbsp;:
+<list compact="compact">
+<item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis
+      plusieurs jours&nbsp;; le nombre précis dépend du champ d'urgence de
+      l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une
+      urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent
+      être doublés lors d'un gel de distribution&nbsp;;</item>
+<item><p>Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
+      version disponible dans <em>testing</em>&nbsp;;</item>
+<item><p>Il doit être disponible pour toutes les architectures pour lesquelles
+      il a été auparavant construit. <ref id="madison"> peut être
+      intéressant pour vérifier cette information&nbsp;;</item>
+<item><p>Il ne doit pas casser les dépendances d'un paquet qui est déjà
+      disponible dans <em>testing</em>&nbsp;;</item>
+<item><p>Les paquets dont il dépend doivent soit être déjà disponibles dans
+      <em>testing</em> soit être acceptés dans <em>testing</em> au
+      même moment (et ils doivent eux-mêmes respecter tous ces
+      critères).</item>
+</list>
+<p>
+Les scripts génèrent certains fichiers pour expliquer
+ pourquoi certains paquets sont maintenus hors de <em>testing</em>. Ils sont
+ disponibles à <url id="&url-testing-maint;">. Sinon, il est possible
+ d'utiliser le programme <prgn>grep-excuses</prgn> inclus dans le paquet
+ <package>devscripts</package>. Il peut facilement être mis dans la <manref
+ section="5" name="crontab"> pour rester informé de la progression de ses
+ paquets dans <em>testing</em>.
+<p>
+Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
+ pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
+ regardant ce qui serait cassé avec l'inclusion du paquet. La <url
+ id="&url-testing-maint;" name="vue d'ensemble de testing"> donne plus
+ d'informations à propos des problèmes courants qui peuvent occasionner cela.
+<p>
+Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
+ jeu des inter-relations est trop compliqué et ne peut être résolu par le
+ script. Dans ce cas, le responsable de version doit être contacté et il forcera
+ l'inclusion du paquet.
+
+    <sect id="pkg-info">Informations sur un paquet
+<p>
+
+
+      <sect1 id="pkg-info-web">Sur le web
+<p>
+Chaque paquet a plusieurs pages web dédiées.
+ <tt>http://&packages-host;/<var>package-name</var></tt> affiche chaque version
+ du paquet disponible dans les différentes distributions. Les informations
+ détaillées par version incluent la description du paquet, les dépendances et
+ des liens pour récupérer le paquet.
+<p>
+Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder
+ les bogues de chaque paquet à
+ <tt>http://&bugs-host;/<var>package-name</var></tt>.
+
+      <sect1 id="madison">L'outil <prgn>madison</prgn>
+<p>
+<prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur
+ <tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>. Il utilise un seul
+ argument qui correspond au nom du paquet. Il affiche comme résultat quelle
+ version du paquet est disponible pour chaque combinaison d'architecture et de
+ distribution. Un exemple l'expliquera mieux.
 <p>
-Vous aurez peut-être accès à d'autres machines Debian. Vous pouvez utiliser
-ces machines pour des tâches en rapport avec le projet Debian. Soyez gentils
-avec les administrateurs et ne consommez pas des montagnes d'espace disque, de
-bande passante ou de temps machine sans en avoir d'abord reçu l'autorisation.
-En général, ces machines sont gérés par des volontaires et sont utilisées pour
-des activités de portage.
+<example>
+$ madison libdbd-mysql-perl
+libdbd-mysql-perl |   1.2202-4 |        stable | source, alpha, arm, i386, m68k, powerpc, sparc
+libdbd-mysql-perl |   1.2216-2 |       testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+libdbd-mysql-perl | 1.2216-2.0.1 |       testing | alpha
+libdbd-mysql-perl |   1.2219-1 |      unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc</example>
+<p>
+Dans cet exemple, vous pouvez voir que la version dans <em>unstable</em> diffère
+ de celle de <em>testing</em> et qu'il y a eu une NMU binaire seulement pour
+ l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart
+ des architectures.
+
+    <sect id="pkg-tracking-system">Le système de suivi des paquets
+<p>
+Le système de suivi des paquets (PTS)<footnote>«&nbsp;Package Tracking
+ System&nbsp;»</footnote> est un outil pour suivre par courrier l'activité
+ concernant un paquet source. Il suffit simplement de s'inscrire à un
+ paquet source pour recevoir les courriers liés à celui-ci. Vous
+ recevez les mêmes courriers que le responsable. Chaque courrier envoyé par le
+ PTS est classé et associé à l'un des mots-clés listés ci-dessous. Ceci vous
+ permettra de sélectionner les courriers que vous voulez recevoir.
+<p>
+Par défaut, vous recevrez&nbsp;:
+<taglist>
+  <tag><tt>bts</tt>
+  <item>Tous les rapports de bogue et les discussions qui
+       suivent.
+
+  <tag><tt>bts-control</tt>
+  <item>Les courriers de contrôle notifiant le changement d'état de l'un des
+       bogues.
+
+  <tag><tt>upload-source</tt>
+  <item>Le courrier de confirmation de <prgn>katie</prgn> quand un paquet
+       source envoyé a été accepté.
+
+  <tag><tt>katie-other</tt>
+  <item>Les autres courriers d'avertissement et d'erreur de
+       <prgn>katie</prgn> (comme une incohérence de forçage pour les champs
+       section ou priorité).
+
+  <tag><tt>default</tt>
+  <item>Tout courrier non automatique envoyé au PTS par les personnes qui
+       veulent contacter les inscrits au paquet.
+
+  <tag><tt>summary</tt>
+  <item>À l'avenir, vous pourriez recevoir des courriers de résumé pour vous
+       tenir informé de l'état du paquet (statistiques sur les bogues, vue
+       générale du portage, progression dans <em>testing</em>,
+       etc.).
+</taglist>
+
+<p>
+Vous pouvez également décider de recevoir plus d'informations&nbsp;: 
+<taglist>
+  <tag><tt>upload-binary</tt>
+   <item>Le courrier d'information de <prgn>katie</prgn> quand un paquet
+       binaire envoyé est accepté (pour vérifier que votre paquet est
+       recompilé pour toutes les architectures).
+
+  <tag><tt>cvs</tt>
+  <item>Les modifications CVS<footnote><p><em>CVS commits</em></footnote> si le
+       responsable a mis en place un système pour faire suivre les
+       notifications de modifications vers le PTS.
+
+</taglist>
+
+       <sect1 id="pts-commands">L'interface de courrier du PTS
+<p>
+Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant différents
+ commandes à <email>pts@qa.debian.org</email>.
+
+<taglist>
+  <tag><tt>subscribe &lt;srcpackage&gt; [&lt;email&gt;]</tt>
+  <item>Inscrit <var>email</var> aux communications liées au paquet source
+       <var>srcpackage</var>. L'adresse de l'expéditeur est utilisé si le
+       second argument n'est pas présent. Si <var>srcpackage</var> n'est pas
+       un paquet source valide, vous obtiendrez un avertissement. Cependant,
+       s'il s'agit d'un paquet binaire valide, le PTS vous inscrira pour le
+       paquet source correspondant.
+
+  <tag><tt>unsubscribe &lt;srcpackage&gt; [&lt;email&gt;]</tt>
+  <item>Supprime une inscription précédente au paquet source
+       <var>srcpackage</var> en utilisant l'adresse spécifiée ou l'adresse de
+       l'expéditeur si le second argument n'est pas rempli.
+
+  <tag><tt>which [&lt;email&gt;]</tt>
+  <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
+       si elle est spécifiée.
+
+  <tag><tt>keyword [&lt;email&gt;]</tt>
+  <item>Donne les mots-clés que vous acceptez. Chaque courrier envoyé par le
+       PTS est associé à un mot-clé et vous ne recevez que les courriers associés
+       aux mots-clés que vous avez acceptés. Voici la liste des mots-clés
+       disponibles&nbsp;:
+        <list>
+       <item><tt>bts</tt>&nbsp;: courriers venant du système de gestion de bogues (BTS) Debian
+        <item><tt>bts-control</tt>&nbsp;: réponses aux courriers envoyés à
+             <email>control@bugs.debian.org</email>
+        <item><tt>summary</tt>&nbsp;: courriers de résumé automatique sur l'état
+              d'un paquet
+        <item><tt>cvs</tt>&nbsp;: notifications de modifications CVS
+        <item><tt>upload-source</tt>&nbsp;: annonce d'un nouvel envoi de paquet
+             source qui a été accepté
+        <item><tt>upload-binary</tt>&nbsp;: annonce d'un nouvel envoi de binaire
+             seulement (portage)
+        <item><tt>katie-other</tt>&nbsp;: autres courriers des ftpmasters
+             (incohérence de forçage, etc.)
+        <item><tt>default</tt>&nbsp;: tous les autres courriers (ceux qui ne sont
+             pas "automatiques")
+        </list>
+
+  <tag><tt>keyword &lt;srcpackage&gt; [&lt;email&gt;]</tt>
+  <item>Identique à l'élément précédent, mais pour un paquet source donné
+       car vous pouvez sélectionner un ensemble de mots-clés différent pour
+       chaque paquet source.
+
+  <tag><tt>keyword [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</tt>
+  <item>Accepte (+) ou refuse (-) les courriers associés au(x) mot(s)-clé(s).
+       Définit la liste (=) des mots-clés acceptés.
+
+  <tag><tt>keyword &lt;srcpackage&gt; [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</tt>
+  <item>Identique à l'élément précédent, mais remplace la liste des mots-clés
+       pour le paquet source indiqué.
+
+  <tag><tt>quit | thanks | --</tt>
+  <item>Arrête le traitement des commandes. Toutes les lignes suivantes sont
+       ignorées par le robot.
+</taglist>
+
+       <sect1 id="pts-mail-filtering">Filtrer les courriers du PTS
+<p>
+Une fois que vous vous êtes inscrit à un paquet, vous recevrez les courriers
+ envoyés à <tt><var>srcpackage</var>@packages.qa.debian.org</tt>. Ces courriers
+ ont des en-têtes spéciaux ajoutés pour vous permettre de les filtrer dans des
+ boîtes aux lettres avec <prgn>procmail</prgn>. Les en-têtes ajoutés sont
+ <tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> et
+ <tt>X-Unsubscribe</tt>.
+<p>
+Voici un exemple d'en-têtes ajoutés pour une notification d'envoi de
+source sur le paquet <package>dpkg</package>&nbsp;:
+<example>
+X-Loop: dpkg@&pts-host;
+X-PTS-Package: dpkg
+X-PTS-Keyword: upload-source
+X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
+</example>
 
+       <sect1 id="pts-cvs-commit">Faire suivre les modifications de CVS vers le PTS
 <p>
-Vous trouverez une liste des autres machines mises à la disposition des
-développeurs Debian à l'adresse <url id="&url-devel-machines;">.
-
-
-
-
+Si vous utilisez un référentiel CVS accessible publiquement pour maintenir votre
+ paquet Debian, vous pouvez vouloir faire suivre les notifications de
+ modifications vers le PTS pour que les inscrits (par exemple, des
+ co-responsables) puissent suivre de près l'évolution du paquet.
+<p>
+C'est très facile à mettre en place. Une fois que votre référentiel génère des
+ notifications de modifications, vous devez simplement vous assurer qu'il envoie une
+ copie de tous ces courriers à <tt><var>srcpackage</var>_cvs@&pts-host;</tt>.
+ Seules les personnes qui ont accepté le mot-clé <em>cvs</em> recevront les
+ notifications.
 
-       <chapt id="archive">L'archive Debian
+    <sect id="ddpo">Vue d'ensemble des paquets d'un développeur
+<p>
+Un portail web pour l'Assurance Qualité (QA) est disponible à <url
+ id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
+ développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne
+ un bon résumé sur les paquets d'un développeur&nbsp;: nombre de bogues par
+ gravité, liste des versions disponibles, état des tests et des liens vers
+ d'autres informations utiles.
+<p>
+C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier
+ de bogues ouverts et pour ne pas oublier quels paquets sont sous votre
+ responsabilité.
 
-       <sect>Aperçu
 
+   <chapt id="pkgs">Gestion des paquets
 <p>
-La distribution &debian-formal; est composée d'un grand nombre de paquets Debian
-(fichiers <tt>.deb</tt>&nbsp;: à peu près &number-of-pkgs;) et de quelques
-autres fichiers (documentation, images des disquettes d'installation,
-etc.).
+Ce chapitre contient des informations relatives à la création, l'envoi, la
+ maintenance et le portage des paquets.
 
+    <sect id="upload">La mise à jour d'un paquet
+      <sect1>Nouveaux paquets
 <p>
-Voici un exemple d'arborescence pour une archive Debian complète&nbsp;:
-
+Si vous voulez créer un nouveau paquet pour la distribution Debian, vous devriez
+ commencer par consulter la liste des <url id="&url-wnpp;" name="paquets en
+ souffrance et paquets souhaités">. Vous pourrez ainsi vérifier que personne ne
+ travaille déjà sur ce paquet et éviter un double travail. Consultez aussi cette
+ page si vous voulez en savoir plus.
 <p>
-&sample-dist-dirtree;
-
+Supposons que personne ne travaille sur le paquet que vous visez, vous devez
+ alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
+ pseudo-paquet <package>wnpp</package>. Ce courrier devra décrire le paquet que
+ vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source
+ peut être téléchargé. Cette liste n'est pas limitative.
+<p>
+Le sujet de votre rapport de bogue devra être &lt;ITP<footnote><p><em>Intent To
+ Package</em>&nbsp;: intention de mise en paquet</footnote>&nbsp;:
+ <var>NomDuPaquet</var> &mdash; <var>courte description</var>&gt;, en remplaçant
+ <var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
+ <em>wishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
+ &email-debian-devel; en mettant cette adresse dans le champ
+ <tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
+ <tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
+ numéro du bogue.
+<p>
+Il faudra aussi ajouter une entrée <tt>Closes: bug#<var>nnnnn</var></tt> dans le
+ fichier <file>changelog</file> du nouveau paquet. Cette indication fermera
+ automatiquement le rapport de bogue à l'installation du nouveau paquet sur les
+ serveurs d'archivage (voir <ref id="upload-bugfix">).
+<p>
+Plusieurs raisons nous poussent à demander aux responsables
+ d'annoncer leur intention&nbsp;:
+<list compact>
+<item>Les responsables ont ainsi la possibilité de puiser dans l'expérience
+      des autres responsables et cela leur permet de savoir si une autre
+      personne travaille déjà dessus.
+<item>D'autres personnes qui envisagent de travailler sur le même paquet
+      apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
+      être partagé.</item>
+<item>Cela permet aux autres responsables de connaître le nouveau
+      paquet mieux que ne le permettent la description d'une ligne et l'habituelle
+      entrée de type changelog <em>Initial release</em> postée sur
+      <tt>debian-devel-changes</tt>.
+<item>C'est une information utile pour
+      les gens qui utilisent la distribution <em>unstable</em> et qui sont nos
+      premiers testeurs. Nous devons faciliter la tâche de ces gens.
+<item>Avec ces annonces, les développeurs Debian et toutes les autres personnes
+      intéressées peuvent se faire une meilleure idée des évolutions et des
+      nouveautés du projet.
+</list>
+
+      <sect1 id="changelog-entries">
+         <heading>Ajouter une entrée à <file>debian/changelog</file></heading>
+<p>
+Les modifications que vous apportez au paquet doivent être notifiées dans le
+   fichier <file>debian/changelog</file>. Ces notes doivent donner une
+   description concise des changements, expliquer pourquoi (si ce n'est pas
+   clair) et indiquer si des rapports de bogue ont été clos. Il faut aussi indiquer
+   quand le paquet a été terminé. Ce fichier sera installé dans
+   <file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
+   <file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
+   natif.
 <p>
-Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
-<tt>dists/</tt> et <tt>pool/</tt>. Le second est un ensemble de répertoires où
-sont stockés les paquets. Ceux-ci sont manipulés grâce à la base de données de
-l'archive et aux logiciels qui l'accompagnent. Le premier répertoire contient
-les distributions <em>stable</em>, <em>testing</em> et <em>unstable</em>. Le
-découpage en sous-répertoires est identique d'un répertoire de distribution à
-l'autre&nbsp;; nous nous contenterons donc d'exposer ce découpage pour la
-distribution <em>stable</em>. Les fichiers <tt>Packages</tt> et
-<tt>Sources</tt> qui se trouvent dans les répertoires de distribution peuvent
-faire référence à des fichiers du répertoire <tt>pool/</tt>.
-
-
+Le fichier <file>debian/changelog</file> a une structure précise comportant
+   différents champs. Le champ <em>distribution</em> est décrit dans <ref
+   id="upload-dist">. Vous trouverez plus d'informations sur la structure de ce
+   fichier dans la section «&nbsp;<file>debian/changelog</file>&nbsp;» de la
+   <em>charte Debian</em>.
 <p>
-Le répertoire <tt>dists/stable</tt> contient trois répertoires nommés
-<tt>main</tt>, <tt>contrib</tt> et <tt>non-free</tt>.
-
+Les entrées du fichier <file>changelog</file> peuvent être
+   utilisées pour fermer des rapports de bogue au moment où le paquet est
+   installé dans l'archive. Voir la section <ref id="upload-bugfix">.
 <p>
-Dans chacune de ces sections se trouve un répertoire contenant les paquets
-sources (<tt>source/</tt>), un répertoire pour chaque architecture supportée
-(<tt>binary-i386/</tt>, <tt>binary-m68k/</tt>, etc) et un répertoire pour les
-paquets indépendants de l'architecture (<tt>binary-all/</tt>).
-
+Par convention, l'entrée changelog d'un paquet qui contient une nouvelle version
+   amont ressemble à&nbsp;:
+<example>
+  * new upstream version
+</example>
 <p>
-La section <em>main</em> contient d'autres répertoires destinés aux images de
-disquettes et à quelques documentations essentielles pour installer la
-distribution Debian sur une architecture particulière (<tt>disk-i386/</tt>,
-<tt>disk-m68k/</tt>, etc).
-
+Quelques outils peuvent vous aider à créer des entrées et à finaliser le fichier
+   <file>changelog</file> pour une livraison &mdash; voir les sections <ref
+   id="devscripts"> et <ref id="dpkg-dev-el">.
+
+
+
+      <sect1 id="upload-checking">Vérifier le paquet avant de l'envoyer
+<p>
+Avant d'envoyer votre paquet, vous devriez faire quelques tests de base. Vous
+   devriez au moins faire les tests suivants (il vous faut une ancienne version
+   du paquet)&nbsp;:
+<list>
+<item>Installez le paquet et vérifiez que le logiciel fonctionne. Si le
+      paquet existait déjà dans une version plus ancienne, faites une mise à
+      jour.
+<item>Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
+      <prgn>lintian</prgn> comme suit&nbsp;: <tt>lintian -v
+      <var>package-version</var>.changes</tt>. Ce programme fera une
+      vérification sur les paquets source et binaire. Si vous ne comprenez pas
+      les messages générés par <prgn>lintian</prgn>, essayez l'option
+      <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
+      bavard dans sa description du problème.
+      <p>
+      En principe, un paquet pour lequel <prgn>lintian</prgn> génère des erreurs
+      (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être installé dans
+      l'archive.
+      <p>
+      Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la section
+      lintian <ref id="lintian">.
+<item>Faites régresser le paquet vers sa version précédente si elle existe
+      &mdash; cela permet de tester les scripts <file>postrm</file> et
+      <file>prerm</file>.
+<item>Désinstallez le paquet et réinstallez-le.
+</list>
+
+
+      <sect1>Générer le fichier «&nbsp;changes&nbsp;»
 <p>
-Les répertoires  <tt>binary-*/</tt> et <tt>source/</tt> sont à nouveau
-divisés en <em>sous-sections</em>.
-
-
+Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
+   être accompagnée d'un fichier <file>.changes</file>. Ce fichier explique à
+   l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
+   général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
+   fabrication du paquet.
+<p>
+Le fichier <file>changes</file> est un fichier de contrôle qui contient les
+   champs suivants&nbsp;:
+<p>
+&control-file-fields;
+<p>
+Tous ces champs sont obligatoires pour une installation sur les serveurs Debian.
+   Vous pouvez consulter la liste des champs de contrôle dans la <url
+   id="&url-debian-policy;" name="charte Debian"> pour connaître les valeurs que
+   prennent ces champs. Vous pouvez fermer un rapport de bogue automatiquement
+   avec le champ <tt>Description</tt> (voir <ref id="upload-bugfix">).
 
-       <sect>Les sections
 
+       <sect2>L'archive des sources amonts
 <p>
-La section <em>main</em> constitue la <strong>distribution &debian-formal;
-officielle</strong>.  Elle est officielle parce qu'elle est conforme à toutes
-nos recommandations. Les deux autres sections divergent de ces recommandations
-à différents degrés, elles ne font donc pas officiellement partie de
-&debian-formal;.
-
+La première fois qu'un paquet est installé dans l'archive pour une version amont
+   donnée, le fichier <file>tar</file> de cette version amont doit être
+   téléchargé et mentionné dans le fichier <file>.changes</file>. Par la suite,
+   ce fichier <file>tar</file> sera utilisé pour générer les fichiers
+   <file>diff</file> et <file>.dsc</file> et il ne sera pas nécessaire de le
+   télécharger à nouveau.
 <p>
-Chaque paquet de la section <em>main</em> doit être conforme aux <url
-id="&url-dfsg;" name="Debian Free Software Guidelines"> et à toutes les autres
-recommandations décrites dans <url id="&url-debian-policy;" name="le Debian
-Policy Manual">. Les DFSG<footnote><em>Debian Free Software
-Guidelines</em></footnote> constituent notre définition de <em>logiciel
-libre</em>. Reportez-vous au <em>Debian Policy Manual</em> pour en savoir
-plus.
-
+Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
+   incluront le fichier <file>tar</file> amont si et seulement si le numéro de
+   révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
+   amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
+   l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
 <p>
-Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG
-mais ne respectent pas d'autres contraintes. Ils peuvent par exemple dépendre
-de paquets de la section <em>non-free</em>.
+Si la mise à jour ne contient pas le fichier <file>tar</file> des sources
+   originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
+   fichiers <file>.dsc</file> et <file>diff</file> de la mise à jour, utiliser
+   un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans
+   l'archive.
 
-<p>
-Les paquets qui ne sont pas conformes aux DFSG sont rangés dans la section
-<em>non-free</em>. Bien que nous supportions l'usage de ces paquets et qu'ils
-bénéficient de nos infrastructures (système de suivi des bogues, listes de
-diffusion, etc), ces paquets <em>non-free</em> ne font pas partie de la
-distribution Debian.
 
+       <sect2 id="upload-dist">Choisir une distribution
 <p>
-Le <em>Debian Policy Manual</em> donne des définitions plus précises pour ces trois sections.
-Les paragraphes précédants ne constituent qu'une introduction.
-
+Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
+   <file>debian/changelog</file>, indique à quelle distribution le paquet est
+   destiné.
 <p>
-La séparation de l'archive en trois sections est
-importante pour toute personne qui désire distribuer Debian, que ce soit par
-serveur FTP ou sur cédérom. Il suffit de distribuer les sections <em>main</em>
-et <em>contrib</em> pour éviter tout problème légal. Certains paquets de la
-section <em>non-free</em> interdisent leur distribution à titre commercial par
-exemple.
-
+Il existe plusieurs valeurs possibles pour ce champ&nbsp;: «&nbsp;stable&nbsp;»,
+    «&nbsp;unstable&nbsp;», «&nbsp;testing-proposed-updates&nbsp;» et
+    «&nbsp;experimental&nbsp;». En fait, il y a deux autres possibilités&nbsp;:
+    «&nbsp;stable-security&nbsp;» et «&nbsp;testing-security&nbsp;». Cependant,
+    ces dernières sont utilisées par l'équipe de sécurité&nbsp;; n'envoyez pas
+    de paquets dedans sans l'accord de celle-ci.
 <p>
-D'un autre coté, un distributeur de cédérom pourra facilement vérifier
-individuellement les licences des paquets de la section <em>non-free</em> et
-ajouter autant de paquets qu'il est autorisé à le faire sur ses cédéroms (dans
-la mesure où cela varie énormément d'un distributeur à l'autre ce travail ne
-peut être fait par les développeurs Debian).
+Il est techniquement possible d'envoyer un paquet dans plusieurs distributions
+   en même temps, mais ceci n'a habituellement aucun sens d'utiliser cette
+   fonctionnalité car les dépendances d'un paquet peuvent varier selon les
+   distributions. En particulier, il est absurde de combiner la distribution
+   <em>experimental</em> avec tout autre chose.
 
 
-
-       <sect>Les architectures
-
-<p>
-À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
-x86&nbsp;; il en était de même pour Debian. Linux devenant de plus
-en plus populaire, il a été porté vers d'autres architectures.  <p> Le noyau
-2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC, Motorola, 680x0
-(Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2 supporte encore
-plus d'architectures dont ARM et UltraSPARC.  Puisque Linux supporte ces
-architectures, Debian a décidé qu'il devait les supporter aussi. C'est
-pourquoi plusieurs portages sont en cours&nbsp;; en fait il y a aussi des portages
-vers d'autres noyaux. À coté d'<em>i386</em> (notre nom pour Intel x86), nous
-avons, au moment où j'écris <em>m68k</em>, <em>alpha</em>, <em>powerpc</em>,
-<em>sparc</em>, <em>hurd-i386</em>, et <em>arm</em>.
-
-<p>
-&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>.  Debian 2.0
-supporte les architectures <em>i386</em> et <em>m68k</em>.  Debian 2.1
-supporte les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
-<em>sparc</em>. Debian 2.2 ajoute le support de l'architecture
-<em>powerpc</em>.
-
-<p>
-Vous trouverez des informations destinées aux développeurs à propos d'un
-portage particulier sur la page <url id="&url-debian-ports;" name="Portage
-Debian">.
-
-
-
-
-       <sect>Les sous-sections
-
-<p>
-Les sections <em>main</em>, <em>contrib</em> et <em>non-free</em> sont
-divisées en sous-sections  pour simplifier le processus d'installation et la
-maintenance de l'archive Debian. Ces sous-sections ne sont pas définies
-formellement, à l'exception peut-être de la sous-section <em>base</em>.
-Elles existent pour simplifier l'organisation des paquets et la navigation
-dans la liste des paquets disponibles. Reportez-vous à la distribution
-courante pour connaître la liste des sous-sections disponibles.
-
-<p>
-Notez qu'avec l'introduction de la nouvelle organisation de l'archive (voir le
-répertoire racine <em>pool/</em>), les sous-sections matérialisées par des
-répertoires pourraient disparaître à l'avenir. Elles seront cependant
-conservées dans le champ <tt>Section</tt> de l'en-tête des paquets.
-
-
-
-
-       <sect>Les paquets
-
-<p>
-Il existe deux types de paquets Debian&nbsp;: les paquets sources et les 
-paquets binaires.
-
-<p>
-Les paquets sources sont constitués de deux ou trois fichiers&nbsp;: 
-
-       <list compact>
-       <item>
-       un fichier <tt>.dsc</tt> et un fichier <tt>.tar.gz</tt> ou,
-
-       <item>
-       un fichier <tt>.dsc</tt>, un fichier <tt>.orig.tar.gz</tt> et un
-       fichier <tt>.diff.gz</tt>.
-
-       </list>
-       
-<p>
-Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
-distribué en dehors de Debian, il n'y a qu'un fichier <tt>.tar.gz</tt> qui
-contient les sources du programme. Si un paquet est distribué ailleurs, le
-fichier <tt>.orig.tar.gz</tt> contient ce que l'on appelle <em>code source
-amont</em>, c'est-à-dire le code source distribué par le <em>mainteneur
-amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le
-fichier <tt>.diff.gz</tt> contient les modifications faites par le responsable
-Debian.
-
-<p>
-Le fichier <tt>.dsc</tt> liste tous les fichiers sources avec leurs sommes de
-contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
-concernant le paquet (responsable, version, etc).
-
-
-
-
-       <sect>Les répertoires des distributions
-
-<p>
-L'organisation des répertoires présentée précédemment est elle-même englobée
-par les <em>répertoires des distributions</em>.  Chaque distribution est
-incluse dans le répertoire <tt>pool</tt> à la racine de l'archive Debian.
-
-<p>
-En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par
-exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
-Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
-courant. Un autre emplacement courant est <tt>/pub/debian</tt>.
-
-<p>
-Une distribution est composée de paquets Debian sources et binaires et des
-fichiers <tt>Sources</tt> et <tt>Packages</tt> correspondants. Ces derniers
-contiennent la description de tous les paquets. Les premiers sont
-conservés dans le répertoire <tt>pool/</tt> tandis que les seconds sont
-conservés dans le répertoire <tt>dists/</tt> de l'archive (pour des questions
-de compatibilité descendante)
-
-
-
-
-       <sect1 id="sec-dists"><em>Stable</em>, <em>testing</em> et
-                             <em>unstable</em>
-
-<p>
-Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
-<tt>dists/stable</tt>), une distribution appelée <em>testing</em> (dans le
-répertoire <tt>dists/testing</tt>) et une distribution appelée
-<em>unstable</em> (dans le répertoire <tt>dists/unstable</tt>). Ceci reflète
-le processus de développement du projet Debian.
-       
-<p>
-Les développements se font sur la distribution <em>unstable</em><footnote>
-<em>unstable</em> signifie «&nbsp;instable&nbsp;»</footnote> (c'est pourquoi
-elle est aussi appelée <em>distribution de développement</em>). Chaque
-développeur Debian peut modifier ses paquets à tout moment dans cette
-distribution. Ainsi son contenu change tous les jours. Comme aucun effort
-particulier n'est fait pour s'assurer que tout fonctionne correctement dans
-cette distribution, elle est parfois <em>instable</em>. 
-
-<p>
-Les paquets sont copiés de <em>unstable</em> vers <em>testing</em> s'ils
-satisfont certains critères. Pour entrer dans la distribution <em>testing</em>
-un paquet doit faire partie de l'archive depuis deux semaines et ne doit pas
-avoir de bogue bloquant pour la distribution (<em>RC bug</em>). Passé cette
-période, le paquet sera installé dans <em>testing</em> dès que les paquets
-dont il dépend y seront. Ce processus est automatique. Vous pouvez consulter
-quelques notes sur ce système ainsi que les <tt>update_excuses</tt> (qui
-indiquent quels paquets sont candidats, lesquels ne le sont pas et pourquoi) à
-l'adresse <url id="&url-testing-maint;">.
-
-<p>
-Après une période de développement, quand le responsable de
-distribution<footnote><em>Release manager</em></footnote> le juge opportun, la
-distribution <em>testing</em> est gelée, ce qui signifie que les conditions à
-remplir pour qu'un paquet passe de <em>unstable</em> à <em>testing</em> sont
-durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
-autorisées concernent les corrections de bogues. Après quelques temps,
-selon l'avancement, la distribution entre dans une phase de
-«&nbsp;gel complet&nbsp;» où les seules modifications acceptées concernent la
-procédure d'installation. Cette phase s'appelle un «&nbsp;cycle de test&nbsp;»
-et cela peut durer jusqu'à deux semaines.  Il peut y avoir plusieurs cycles de
-tests avant que le responsable de distribution ne la déclare prête pour la
-diffusion. À la fin du dernier cycle de test, la distribution <em>frozen</em>
-est renommée <em>stable</em>, remplaçant l'ancienne distribution <em>stable</em> qui
-est enlevée à cette occasion (elle peut être retrouvée à l'adresse
-<tt>&archive-host;</tt>).
-
-<p>
-Ce cycle de développement est basé sur l'idée que la distribution
-<em>instable</em> devient <em>stable</em> après une période de test
-(<em>testing</em>). Une distribution contient inévitablement des
-bogues, même si elle est classée stable. C'est pourquoi les distributions
-stables sont mises à jour de temps en temps. Les corrections introduites sont
-testées avec une grande attention et ajoutées individuellement à l'archive
-pour diminuer les risques d'introduire de nouveaux bogues. Vous pouvez trouver
-des paquets proposés pour les mises à jour de <em>stable</em> dans le
-répertoire <tt>proposed-updates</tt>. De temps en temps, les paquets de ce
-répertoire qui ne présentent pas de problème sont installés dans la
-distribution <em>stable</em> et le numéro de révision de cette distribution
-est incrémenté («&nbsp;1.3&nbsp;» devient «&nbsp;1.3r1&nbsp;»,
-«&nbsp;2.0r2&nbsp;» devient «&nbsp;2.0r3&nbsp;» et ainsi de suite).
-
-<p>
-Notez que pendant la période de gel les développements continuent sur la
-distribution instable car cette distribution reste en place. 
-
-
-       <sect1><em>Experimental</em>
-
-<p>
-La distribution <em>experimental</em> est une distribution particulière. Ce
-n'est pas une distribution à part entière comme le sont <em>stable</em> et
-<em>unstable</em>. Elle est prévue pour servir de plate-forme de développement
-pour les projets expérimentaux qui ont de grandes chances de détruire le
-système ou bien pour des logiciels qui sont vraiment trop instables pour être
-inclus dans la distribution <em>unstable</em> (mais pour qui une mise en 
-paquet est justifiée). Les utilisateurs qui téléchargent et
-installent des paquets depuis 
-<em>experimental</em> sont prévenus&nbsp;: on ne peut pas faire confiance à la
-distribution <em>experimental</em>.
-
-<p>
-Si un logiciel risque de causer des dégats importants, il sera
-sûrement préférable de le mettre dans la distribution <em>experimental</em>.
-Un système de fichier compressé, par exemple, devrait probablement aller dans
-<em>experimental</em>.
-
-<p>
-Une nouvelle version amont qui ajoute de nouvelles fonctions tout en 
-supprimant de nombreuses autres ne devra pas être téléchargée dans l'archive
-Debian, elle pourra cependant être téléchargée dans <em>experimental</em>. Une
-nouvelle version non finalisée d'un logiciel qui utilise une méthode de
-configuration complètement différente pourrait aller dans
-<em>experimental</em> au gré du responsable. Si vous travaillez sur
-un cas de mise à jour complexe ou incompatible vous pouvez aussi utiliser
-<em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
-accès aux testeurs.
-
-<p>
-Quelques logiciels expérimentaux peuvent aller dans <em>unstable</em>, avec un
-avertissement dans la description mais ce n'est pas recommandé car les paquets
-de <em>unstable</em> se propagent dans <em>testing</em> et aboutissent dans
-<em>stable</em>.
-
-<p>
-Un nouveau logiciel qui ne risque pas d'endommager le système ira
-directement dans <em>unstable</em>. 
-
-<p>
-Une alternative à <em>experimental</em> consiste à utiliser vos pages
-personnelles sur le serveur <tt>people.debian.org</tt>
-(<tt>klecker.debian.org</tt>).
-
-       <sect id="codenames">Les noms de distribution
-
-<p>
-Chaque distribution Debian diffusée a un nom&nbsp;: Debian 1.1 s'appelle
-«&nbsp;buz&nbsp;»&nbsp;; Debian 1.2, «&nbsp;rex&nbsp;»&nbsp;; Debian 1.3 «&nbsp;bo&nbsp;»&nbsp;;
-Debian 2.0, «&nbsp;hamm&nbsp;»&nbsp;; Debian 2.1, «&nbsp;slink&nbsp;»; Debian 2.2
-«&nbsp;potato&nbsp;» et Debian 3.0 «&nbsp;woody&nbsp;». Il y a aussi une pseudo-distribution nommée
-«&nbsp;sid&nbsp;», il s'agit de la distribution <em>unstable</em>&nbsp;; comme les
-paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent de
-la stabilité, la distribution «&nbsp;sid&nbsp;» n'est jamais diffusée.  En plus
-du contenu habituel d'une distribution Debian, «&nbsp;sid&nbsp;» contient des
-paquets pour des architectures qui ne sont pas encore officiellement
-supportées ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
-architectures doivent rejoindre les architectures supportées à une date
-future.
-
-<p>
-Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
-participer et suivre les développements) même les distributions
-<em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP
-et FTP de Debian.
-
-<p>
-Si nous avions nommé le répertoire qui contient la prochaine version àc
-diffuser «&nbsp;testing&nbsp;», il aurait fallu le renommer
-«&nbsp;stable&nbsp;» au moment de la diffusion, ce qui aurait forcé les
-miroirs FTP à re-télécharger la distribution complète (qui est plutôt
-volumineuse).
-
-<p>
-D'un autre coté, si une distribution s'appelle <em>Debian-x.y</em> dès le
-départ, des personnes pourraient s'imaginer que la distribution Debian
-<em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
-avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
-pré-1.0. C'est pour cette raison que la première version officielle était la
-version 1.1 et non la 1.0.)
-
-<p>
-En conséquence, les noms de répertoire des distributions dans l'archive sont
-déterminés par leurs noms de code et non par leur statut (exemple&nbsp;: slink). Ces
-noms sont identiques pendant la période de développement et une fois la
-distribution diffusée&nbsp;; des liens symboliques, qui peuvent être modifiés
-facilement, indiquent la distribution stable actuelle. 
-
-<p>
-Tout ceci explique pourquoi les répertoires des distributions sont nommés à
-partir des noms de code des distributions alors que <em>stable</em>,
-<em>testing</em> et <em>unstable</em> sont des liens
-symboliques qui pointent vers les répertoires appropriés.
-
-
-
-
-
-       <chapt id="upload">La mise à jour d'un paquet
-
-
-       <sect>Nouveaux paquets
-
-<p>
-Si vous voulez créer un nouveau paquet pour la distribution Debian vous
-devriez commencer par consulter la liste des <url id="&url-wnpp;"
-name="paquets en souffrance et paquets souhaités">. Vous pourrez ainsi
-vérifier que personne ne travaille déjà sur ce paquet et éviter un double
-travail. Consultez aussi cette page si vous voulez en savoir plus.
-
-<p>
-Supposons que personne ne travaille sur le paquet que vous visez, vous devez
-alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
-pseudo-paquet <tt>wnpp</tt>. Ce
-courrier devra décrire le paquet que vous projetez de créer, la licence de ce
-paquet et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
-pas limitative.
-
-<p>
-Le sujet de votre rapport de bogue devra être &lt;ITP<footnote><em>Intent To
-Package</em>&nbsp;: intention de mise en paquet</footnote>&nbsp;:
-<var>NomDuPaquet</var> &mdash; <var> courte description </var>&gt;, en remplaçant
-<var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
-<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champ
-<tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
-<tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
-numéro du bogue.
-
-<p>
-Il faudra aussi ajouter une entrée
-<tt>Closes: bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file>
-du nouveau paquet. Cette indication fermera automatiquement le rapport de
-bogue à l'installation du nouveau paquet sur les serveurs d'archivage (voir
-<ref id="upload-bugfix">).
-
-<p>
-Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer
-leurs intentions&nbsp;:
-
-       <list compact>
-       <item>
-       Les responsables ont ainsi la possibilité de puiser dans l'expérience
-       des autres responsables et cela leur permet de savoir si une autre personne
-       travaille déjà dessus.
-
-       <item>
-       D'autres personnes qui envisagent de travailler sur le même paquet
-       apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
-       être partagé.
-
-       <item>
-       Cela permet aux autres responsables d'en savoir plus sur le nouveau
-       paquet que ne le permettent la description d'une ligne et l'habituelle
-       entrée «&nbsp;<em>Initial release</em>&nbsp;» que l'on trouve dans les
-       fichiers <em>changelog</em> qui sont postés sur
-       <tt>debian-devel-changes</tt>.
-
-       <p>
-       C'est une information utile pour les gens qui utilisent la
-       distribution <em>unstable</em> et qui sont nos premiers testeurs. Nous
-       devons faciliter la tâche de ces gens.
-
-       <p>
-       Avec ces annonces, les développeurs Debian et toutes les autres personnes
-       intéressées peuvent se faire une meilleure idée des évolutions et nouveautés du
-       projet.
-
-       </list>
-
-
-       <sect id="changelog-entries">
-       <heading>Ajouter une entrée à debian/changelog</heading>
-
-<p>
-Les modifications que vous apportez au paquet doivent être tracées dans le
-fichier <file>debian/changelog</file>. Ces traces doivent donner une
-description concise des changements, expliquer pourquoi (si ce n'est pas
-clair) et indiquer si des rapports de bogues sont clos. Il faut aussi indiquer
-quand le paquet a été terminé. Ce fichier sera installé dans
-<file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
-<file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
-natif.
-
-<p>
-Le fichier <file>debian/changelog</file> a une structure précise comportant
-différents champs. Le champ <em>distribution</em> est décrit dans <ref
-id="upload-dist">. Vous trouverez plus d'information sur la structure de ce
-fichier dans le <em>Debian Policy Manual</em> section
-«&nbsp;<file>debian/changelog</file>&nbsp;».
-
-<p>
-Les entrées du fichier <file>changelog</file> peuvent être utilisées pour
-fermer des rapports de bogue au moment où le paquet est installé dans
-l'archive. Voir la section <ref id="upload-bugfix">.
-
-<p>
-Par convention, l'entrée changelog d'un paquet qui contient une nouvelle
-version amont ressemble à&nbsp;:
-<example>
-  * new upstream version
-</example>
-
-<p>
-Quelques outils peuvent vous aider à créer des entrées et finaliser
-<file>changelog</file> pour une livraison &mdash; voir les sections <ref
-id="devscripts"> et <ref id="dpkg-dev-el">.
-
-       <sect id="upload-checking">Vérifier le paquet avant la mise à jour
-
-<p>
-Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
-devrez au moins faire les tests suivants (il vous faut une ancienne version
-du paquet)&nbsp;:
-       <list compact>
-       <item>
-       Installez le paquet et vérifiez que le logiciel fonctionne. Si le
-       paquet existait déjà dans une version plus ancienne, faites une mise à
-       jour.
-
-       <item>
-       Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
-       <prgn>lintian</prgn> comme suit&nbsp;: <tt>lintian -v
-       <var>package-version</var>.changes</tt>. Ce programme fera une
-       vérification sur les paquets source et binaire. Si vous ne comprenez
-       pas les messages générés par <prgn>lintian</prgn> essayez l'option
-       <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
-       bavard dans sa description du problème.
-       <p>
-       En principe, un paquet pour lequel
-       <prgn>lintian</prgn> génère des erreurs (elles commencent par
-       <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
-       <p>
-       Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
-       section lintian <ref id="lintian">.
-       
-       <item>
-       Faites régresser le paquet
-       vers sa version précédente si elle existe &mdash; cela permet de tester les
-       scripts <tt>postrm</tt> et <tt>prerm</tt>.
-
-       <item>
-       Désinstallez le paquet et réinstallez-le.
-
-       </list>
-
-
-
-       <sect>Générer le fichier « changes »
-<p>
-Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
-être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
-l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
-général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
-fabrication du paquet.
-
-<p>
-Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
-suivants&nbsp;:
-
-<p>
-&control-file-fields;
-
-<p>
-Tous ces champs sont obligatoires pour une installation sur les serveurs
-Debian.  Vous pouvez consulter la liste des champs de contrôle dans le
-<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
-les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
-automatiquement avec le champ <tt>Description</tt> (voir <ref
-id="upload-bugfix">).
-
-
-       <sect1>L'archive des sources amonts
-<p>
-La première fois qu'un paquet est installé dans l'archive pour une version
-amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
-téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
-fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
-<tt>.dsc</tt> et il ne sera pas nécessaire de le télécharger à nouveau.
-
-<p>
-Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
-incluront le fichier <tt>tar</tt> amont si et seulement si le numéro de
-révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
-amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
-l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
-
-<p>
-Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
-originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
-fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier
-<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
-raison ou pour une autre il y a une différence, la nouvelle version de ce
-fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
-<tt>-sa</tt> par exemple).
-
-
-
-
-       <sect1 id="upload-dist">Choisir une distribution
-
-<p>
-Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
-<file>debian/changelog</file>, indique à quelle distribution le paquet est
-destiné.
-
-<p>
-Il y a trois valeurs possibles pour ce champ&nbsp;: <em>stable</em>,
-<em>unstable</em> et <em>experimental</em>&nbsp;. En temps
-normal, les paquets sont téléchargés dans <em>unstable</em>.
-
-<p>
-Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause
-des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et
-pour les paquets fabriqués par le démon de compilation pour les autres
-architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et
-comment faire une mise à jour de <em>stable</em>.
-
-<p>
-Notez bien que combiner <em>experimental</em> avec quelque distribution
-que ce soit n'a pas de sens.
-
-
-       <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>
-
+         <sect3 id="upload-stable">Mettre à jour un paquet de la distribution
+         <em>stable</em>
 <p>
 Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
-sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
-pour y être testé avant d'être effectivement inclus dans <em>stable</em>.
-
-<p>
-Une livraison pour la distribution <em>stable</em> requière des soins
-supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
-que dans les cas suivants&nbsp;:
-
-       <list>
-       <item>un problème de sécurité (un avis de sécurité
-       Debian<footnote>Debian security advisory.</footnote>),
-       <item>un probleme fonctionnel vraiment critique,
-       <item>un paquet devenu ininstallable,
-       <item>un paquet indisponible pour une architecture.
-       </list>
-
-<p>
-Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
-important car même une modification triviale peut causer un bogue plus 
-tard. Livrer une nouvelle version amont d'un logiciel pour corriger un 
-problème de sécurité est désapprouvé&nbsp;; dans la plupart des cas la
-bonne solution consiste à prendre la rustine correspondante de la
-nouvelle version amont et à l'appliquer à l'ancienne (faire un
-portage (<em>backport</em>) de la rustine.
-
+     sera dirigé vers le répertoire <file>stable-proposed-updates</file> des
+     archives Debian pour y être testé avant d'être effectivement inclus dans
+     <em>stable</em>.
+<p>
+Une livraison pour la distribution <em>stable</em> requiert des soins
+     supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
+     que dans les cas suivants&nbsp;:
+<list>
+<item>un problème de sécurité (un avis de sécurité Debian<footnote>Debian
+      security advisory</footnote>),
+<item>un problème fonctionnel vraiment critique,
+<item>un paquet devenu ininstallable,
+<item>un paquet indisponible pour une architecture.
+</list>
+<p>
+Il est fortement déconseillé de changer quoi que ce soit si ce
+     n'est pas important car même une modification triviale peut provoquer un
+     bogue. Livrer une nouvelle version amont d'un logiciel pour
+     corriger un problème de sécurité est désapprouvé&nbsp;; dans la plupart
+     des cas, la bonne solution consiste à prendre le correctif correspondant de
+     la nouvelle version amont et à l'appliquer à l'ancienne (faire un
+     rétro-portage<footnote><em>backport</em></footnote> du correctif).
 <p>
 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
-distribution <em>stable</em> pour que leurs dépendances se limitent aux
-bibliothèques (et autres paquets) disponibles dans <em>stable</em>&nbsp;;
-un paquet livré pour la distribution <em>stable</em> qui dépend d'une
-bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
-Modifier les dépendances d'autres paquets (en manipulant le champ
-<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
-ininstallables, est fortement déconseillé.
-
+     distribution <em>stable</em> pour que leurs dépendances se limitent aux
+     bibliothèques (et autres paquets) disponibles dans <em>stable</em>&nbsp;;
+     un paquet livré pour la distribution <em>stable</em> qui dépend d'une
+     bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
+     Modifier les dépendances d'autres paquets (en manipulant le champ
+     <tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
+     ininstallables, est fortement déconseillé.
 <p>
 L'équipe responsable de la distribution<footnote><em>the Release
-team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera
-régulièrement le contenu de <em>proposed-updates</em> et décidera si votre
-paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis
-(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog,
-vos changements pour une livraison vers <em>stable</em> sinon le paquet ne
-sera pas considéré.
-
-
-
-       <sect id="uploading">Mettre à jour un paquet
-
-
-       <sect1 id="upload-ftp-master">Installer un paquet sur
-       <tt>ftp-master</tt> 
-
-<p>
-Pour installer un paquet vous avez besoin d'un compte sur
-<ftpsite>ftp-master</ftpsite>, ce que vous devez avoir en tant que
-développeur Debian. Si vous utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn>
-pour télécharger vos paquets, placez-les dans
-<tt>&us-upload-dir;</tt>.  Si vous utilisez un FTP anonyme,
-placez-les dans <ftppath>/pub/UploadQueue/</ftppath>. Attention, il est
-préférable de transférer le fichier <tt>changes</tt> en dernier. Dans le cas
-constraire, votre livraison pourrait être rejetée car l'outil de maintenance
-de l'archive pourrait lire le fichier <tt>changes</tt> et constater que les
-fichiers ne sont pas tous présents. Si vous ne voulez pas vous embêter avec
-l'ordre de transfert des fichiers, vous pouvez tout simplement copier vos
-fichiers dans un répertoire temporaire de <tt>ftp-master</tt> et les déplacer
-ensuite vers <tt>&us-upload-dir;</tt>.
-
-<p>
-<em>Note&nbsp;:</em> ne téléchargez pas de paquet contenant un logiciel
-protégé par des brevets américains sur <tt>ftp-master</tt>, de même n'y
-téléchargez pas de paquet cryptographique qui appartiendrait a
-<em>contrib</em> ou <em>non-free</em>. Quand vous ne pouvez télécharger sur
-<tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
-<tt>chiark</tt> ou <tt>erlangen</tt>. Les livraisons de ces logiciels doivent
-aller sur <tt>non-us</tt> (voir <ref id="upload-non-us">). Si vous ne savez
-pas si votre paquet est protégé par un brevet ou s'il est soumis aux lois de
-contrôle des exportations américaines posez la question sur la liste
-&email-debian-devel;.
-
-<p>
-Les paquets <package>dupload</package> ou <package>dput</package> pourront
-vous faciliter le travail lors du téléchargement. Ces programmes, bien
-pratique, sont configurés par défaut pour
-se connecter par FTP sur les serveurs <tt>ftp-master</tt>,
-<tt>chiark</tt> et <tt>erlangen</tt>. Ils peuvent aussi être configurés pour
-utiliser <prgn>ssh</prgn> ou <prgn>rsync</prgn>. Se reporter à <manref
-name="dupload" section="1">, <manref name="dupload" section="5"> et <manref
-name="dput" section="1"> pour en savoir plus.
-
-<p>
-Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en fera le 
-logiciel de maintenance de l'archive en exécutant <prgn>dinstall</prgn>
-sur votre fichier <file>.changes</file>&nbsp;:
-
-<example>dinstall -n foo.changes</example>
-
-
-
-
-
-       <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
-       (pandora) 
-
+     team</em></footnote> (joignable à l'adresse &email-debian-release;)
+     évaluera régulièrement le contenu de <em>stable-proposed-updates</em> et
+     décidera si votre paquet peut être inclus dans la distribution
+     <em>stable</em>. Soyez précis (et, si nécessaire, prolixe) quand vous
+     décrivez, dans le fichier changelog, vos changements pour une livraison
+     vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
+
+    <sect3 id="upload-t-p-u">Mettre à jour un paquet de la distribution
+    <em>testing-proposed-updates</em>
+<p>
+La distribution <em>testing</em> est peuplée avec des paquets en provenance
+     d'<em>unstable</em> selon des règles expliquées dans <ref id="testing">.
+     Cependant, le responsable de distribution peut stopper les scripts de
+     <em>testing</em> quand il veut geler la distribution. Dans ce cas, vous
+     pouvez envoyer vos paquets vers <em>testing-proposed-updates</em> pour
+     fournir des paquets corrigés durant le gel.
+<p>
+Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
+     ils doivent passer entre les mains du responsable de version. Vous devez
+     donc avoir une bonne raison pour les y envoyer. Pour savoir ce que
+     représente une bonne raison aux yeux du responsable de version, vous
+     devriez lire les instructions données qu'il envoie régulièrement sur
+     &email-debian-devel-announce;.
+<p>
+Vous ne devriez pas envoyer un paquet à <em>testing-proposed-updates</em> quand
+     vous pouvez le mettre à jour par <em>unstable</em>. Si vous ne pouvez faire
+     autrement (par exemple, parce que vous avez une nouvelle version dans
+     <em>unstable</em>), vous pouvez l'utiliser, mais il est recommandé de
+     demander l'autorisation du responsable de distribution auparavant.
+
+      <sect1 id="uploading">Mettre à jour un paquet
+
+       <sect2 id="upload-ftp-master">Installer un paquet sur
+       <tt>ftp-master</tt>
+<p>
+Pour installer un paquet, vous avez besoin d'un compte sur
+   <ftpsite>&ftp-master-host;</ftpsite>, ce que vous devriez déjà avoir en tant
+   que développeur Debian. Si vous utilisez <prgn>scp</prgn> ou
+   <prgn>rsync</prgn> pour télécharger vos paquets, placez-les dans
+   &us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans
+   &upload-queue;. Attention, il est préférable de transférer le fichier
+   <tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait
+   être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier
+   <tt>changes</tt> et constater que les fichiers ne sont pas tous présents. Si
+   vous ne voulez pas vous embêter avec l'ordre de transfert des fichiers, vous
+   pouvez tout simplement copier vos fichiers dans un répertoire temporaire de
+   <tt>ftp-master</tt> et les déplacer ensuite vers &us-upload-dir;.
+<p>
+<em>Note&nbsp;:</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquet
+   concernant la cryptographie qui appartiendrait à <em>contrib</em> ou <em>non-free</em>.
+   Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
+   id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par
+   des brevets américains ne peuvent pas être envoyés sur
+   <tt>ftp-master</tt>&nbsp;; selon le cas, ils peuvent peut-être pourtant être
+   envoyés vers <file>non-US/non-free</file> (le paquet est dans
+   <em>non-free</em> à cause de problèmes de distribution et non pas à cause de
+   la licence du logiciel). Quand vous ne pouvez télécharger sur
+   <tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
+   <tt>chiark</tt> ou <tt>erlangen</tt>. Si vous ne savez pas si votre paquet
+   est protégé par un brevet ou s'il est soumis aux lois de contrôle des
+   exportations américaines, posez la question sur la liste
+   &email-debian-devel;.
+<p>
+Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
+   travail lors du téléchargement. Ces programmes, bien pratiques, aident à
+   automatiser le processus d'envoi de paquet vers Debian
+<p>
+Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en
+   fera le logiciel de maintenance de l'archive en exécutant
+   <prgn>dinstall</prgn> sur votre fichier <file>.changes</file>&nbsp;: 
+<example>dinstall -n foo.changes</example>.
+Notez que <prgn>dput</prgn> peut le faire automatiquement pour vous.
+
+       <sect2 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
 <p>
 Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
-exportations américain ne doivent pas être installés sur <tt>ftp-master</tt>.
-Installez le paquet sur <ftpsite>non-us.debian.org</ftpsite> dans le
-répertoire <tt>&non-us-upload-dir;</tt> (<ref id="dupload"> et <ref
-id="dput">, avec les options adéquates, peuvent tous deux être utilisés pour
-cela). Par défaut, vous pouvez utiliser le même <em>login/mot de passe</em>
-que pour <tt>ftp-master</tt>. Si vous utilisez
-une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
-répertoire <ftppath>/pub/UploadQueue/</ftppath>.
-
-<p>
-Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
-avec&nbsp;:
-
-<example>dinstall -n foo.changes</example>
-
-
-<p>
-Attention, les personnes résidant aux États-Unis et les citoyens américains
-sont soumis à des restrictions sur l'exportation des logiciels de
-cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter
-quelques logiciels de cryptographie soumis à une obligation de déclaration
-auprès du département du commerce américain. Toutefois, cette restriction a
-été abandonnée pour des logiciels qui sont déjà disponible en dehors des
-États-Unis. En conséquence, tout logiciel de cryptographie de la section
-<em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une
-autre section &mdash; il ne doit pas dépendre de <em>non-US/main</em> &mdash;
-peut être téléchargé sur ftp-master ou l'une de ses files d'attente décrites
-plus haut.
-
-
-<p>
-Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens
-américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être
-vigilants en le faisant.  Nous recommandons aux responsables concernés de
-prendre toutes les précautions nécessaires, <em>y compris la consultation d'un
-juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en
-livrant un paquet sur <tt>non-US</tt>.
-
-<p>
-Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>
-les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
-name="procédure décrite par le gouvernement américain">. Les responsables de
-paquets <em>non-US/non-free</em> devront en plus consulter les <url
-id="&url-notification-of-export;" name="règles de déclaration d'exportation
-pour les logiciels commerciaux">.
-
-<p>
-Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
-juridique. Une fois encore, nous recommandons aux résidents et citoyens
-américains de consulter un juriste avant de livrer un paquet sur
-<tt>non-US</tt>.
-
-
-       <sect1>Installer un paquet via <tt>chiark</tt>
-
-<p>
-Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
-possibilités. L'une d'elles consiste à télécharger vos fichiers dans
-<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Pour
-les détails consultez <url id="&url-chiark-readme;">.
-
+   exportations américaines ne doivent pas être installés sur
+   <tt>ftp-master</tt>. Installez le paquet sur
+   <ftpsite>non-us.debian.org</ftpsite> dans le répertoire &non-us-upload-dir;
+   (<ref id="dupload"> et <ref id="dput"> avec les options adéquates peuvent
+   tous deux être utilisés pour cela). Par défaut, vous pouvez utiliser le même
+   <em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez
+   une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
+   répertoire &upload-queue;.
 <p>
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
-lois de contrôle des exportations américaines sur <tt>chiark</tt>.
-Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
-les indications de la section <ref id="upload-ftp-master"> sont applicables ici
-aussi.
-
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur
-<tt>chiark</tt>&nbsp;; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
-       <sect1>Installer un paquet via <tt>erlangen</tt>
-
-<p>
-Vous pouvez aussi accéder à un serveur situé en Allemagne&nbsp;: il vous suffit
-d'ouvrir une connexion anonyme sur&nbsp;:
-
-<p>
-       <url id="&url-upload-erlangen;">.
-
-<p>
-Le téléchargement fait sur ce serveur doit être aussi complet que s'il
-était fait dans le répertoire <tt>Incoming</tt> sur <tt>ftp-master</tt> :
-il doit comporter le fichier <file>.changes</file> et tous les fichiers 
-mentionnés dans ce dernier. Le serveur vérifie que le fichier 
-<tt>.changes</tt> est bien signé avec la clé PGP d'un développeur Debian pour 
-éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez bien 
-que le champ <tt>Maintainer</tt> du fichier <tt>.changes</tt> contient 
-<em>votre</em> adresse électronique. De même que sur <tt>ftp-master</tt>, 
-cette adresse est ensuite utilisée pour toutes les réponses.
-
-<p>
-Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire
-après le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous
-devriez ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de
-votre paquet. Normalement, il devrait avoir été déplacé vers
-<tt>ftp-master</tt>&nbsp;;
-vous serez informé par le même biais si une erreur s'est produite au cours du
-processus.
-
-<p>
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
-lois de contrôle des exportations américaines sur <tt>erlangen</tt>.
-Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
-les indications de la section <ref id="upload-ftp-master"> sont applicables ici
-aussi.
-
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur 
-<tt>erlangen</tt>&nbsp;; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
-
-
-       <sect1>Les autres serveurs
-
-<p>
-Un autre serveur est disponible aux États-Unis&nbsp;; c'est un bon point
-de repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
-paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
-<tt>erlangen</tt>.
-<p>
-Il existe aussi un serveur au Japon&nbsp;: téléchargez vos paquet par FTP
-anonyme sur <url id="&url-upload-jp;">.
-
-
-
-
-       <sect id="upload-announce">Annoncer une mise à jour
-
-<p>
-Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
-listes «&nbsp;debian-changes&nbsp;». Ceci est maintenant géré automatiquement
-par le logiciel de gestion de l'archive quand il est exécuté (en principe une
-fois par jour). Vous devez juste utiliser une version récente de
-<package>dpkg-dev</package> (&gt;= 1.4.1.2). Le courrier généré par le
-logiciel de maintenance de l'archive contiendra le fichier <tt>.changes</tt>
-signé que vous avez livré avec votre paquet. Précédemment, cette charge
-revenait à <prgn>dupload</prgn>&nbsp;; vérifiez que vous avez bien configuré
-<prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
-<tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).
-
-<p>
-Si un paquet est mis à jour avec un champ <tt>Distribution:</tt> à
-<em>stable</em>, l'annonce est envoyée sur la liste&nbsp;:
-
-<p>
-<tt>   &email-debian-changes;.</tt>
-
-<p>
-S'il est mis à jour avec un champ <tt>Distribution:</tt> à <em>unstable</em>
-ou <em>experimental</em>, l'annonce est envoyée sur la liste
-&email-debian-devel-changes;.
-
-<p>
-Le programme <prgn>dupload</prgn> est suffisamment intelligent pour déterminer
-où devra aller l'annonce et pour envoyer le courrier sur la bonne liste. Voir <ref
-id="dupload">.
-
-
-
-
-       <sect id="upload-notification">
-       <heading>Notification de l'installation d'un nouveau paquet</heading>
-
-<p>
-Les administrateurs de l'archive Debian sont responsables de l'installation
-des mises à jour. La plupart des mises à jour sont gérées
-quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>.
-Les mises à jour
-de paquets sur la distribution <em>unstable</em>, en particulier, sont
-installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau
-paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois
-entre le téléchargement d'un paquet vers un serveur et son installation
-effective. Soyez patients.
-
-<p>
-Dans tous les cas vous recevrez un accusé de réception par courrier
-électronique indiquant que votre paquet a été installé et quels rapports
-de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
-les rapports de bogues que vous vouliez clore sont bien dans cette liste. 
-
-<p>
-L'accusé de réception indique aussi la section dans laquelle le paquet a
-été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
-courrier qui vous informera de cette différence (voir plus loin).
-
-
-
-
-       <sect1 id="override-file">Le fichier <em>override</em>
-
-<p>
-Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
-<file>debian/control</file> n'indiquent ni où le paquet sera installé dans
-l'archive Debian ni sa priorité. Afin de conserver la
-cohérence de l'archive, ce sont les administrateurs qui contrôlent ces
-champs. Les valeurs du fichier <file>debian/control</file> sont juste des
-indications.
-
-<p>
-Les administrateurs de l'archive indiquent les sections et priorités des paquets
-dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
-fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
-informé par courrier électronique quand votre paquet sera installé dans
-l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
-avant votre prochain téléchargement ou alors vous aurez envie de modifier le
-fichier <em>override</em>.
-
-<p>
-Pour modifier la section dans laquelle un paquet est archivé, vous devez
-d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
-envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
-paquet <package>ftp.debian.org</package> demandant la modification de la
-section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
-amènent à demander ces changements.
-
-<p>
-Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
-name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.
-
-
-
-
-       <chapt id="nmu">Mise à jour indépendante
-
-<p>
-Dans certaines circonstances il est nécessaire qu'une personne autre que le
-responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à
-jour est désigné en anglais par l'expression <em>non-maintainer upload
-(NMU)</em>.  Dans le présent document, nous traduisons librement cette
-expression par «&nbsp;mise à jour indépendante&nbsp;».
-
-<p>
-Ces mises à jour indépendantes font partie du travail normal des porteurs qui
-compilent les paquets pour d'autres architectures (voir <ref id="porting">).
-Nous faisons aussi des mises à jour indépendantes quand un développeur Debian 
-corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
-ou un bogue paralysant. Cela se produit plus particulièrement en période de
-gel de la distribution de développement ou quand le responsable officiel du
-paquet ne peut pas fournir une correction dans un délai raisonnable.
-
-<p>
-Ce chapitre contient des informations qui vous expliqueront quand et comment
-faire des mises à jour indépendantes. Une distinction fondamentale doit être
-faite entre les mises à jour indépendantes sources et les mises à jour 
-indépendantes binaires. Elle est explicitée dans la section suivante.
-
-
-       <sect id="nmu-terms">Terminologie
-
-<p>
-Deux nouvelles expressions sont introduites dans cette section&nbsp;: 
-«&nbsp;mise à jour indépendante source&nbsp;» et «&nbsp;mise à 
-jour indépendante binaire&nbsp;». Ces expressions ont une définition
-précie dans le monde Debian. Elles correspondent toutes deux au même type
-d'activité&nbsp;; elles impliquent toutes deux qu'une personne fait une mise à
-jour d'un paquet alors qu'elle n'est pas officiellement responsable de ce
-paquet. C'est pourquoi nous qualifions ces mises à jours 
-d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
-entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
-question d'agir sans prévenir le responsable au préalable (voir <ref 
-id="nmu-guidelines">).</footnote>.
-
-<p>
-Une mise à jour indépendante source est une livraison de paquet faite par
-une personne qui n'est pas le responsable officiel de ce paquet avec pour
-objectif de corriger un bogue dans le paquet. Une mise à jour indépendante
-source implique toujours une modification des sources du paquet, même s'il
-ne s'agit que d'un changement dans le fichier <file>debian/changelog</file>.
-Ce changement peut tout aussi bien concerner la partie amont du source que la
-partie spécifique à Debian. Une mise à jour indépendante source peut aussi
-inclure des paquets spécifiques à une architecture, un fichier <em>diff</em>
-modifié ou, plus rarement, des nouveaux sources amonts.
-
-<p>
-Une mise à jour indépendante binaire est la recompilation et l'archivage
-d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un
-effort de portage. Une mise à jour indépendante binaire est la livraison d'un
-paquet compilé (souvent pour une autre architecture) à condition que cette
-compilation n'ait pas nécessité de modifications des sources. Dans de 
-nombreux cas, les porteurs
-sont obligés de modifier les sources pour les rendre compilables sur leur
-architecture cible&nbsp;; il s'agira alors d'une mise à jour indépendante source et
-non d'une mise à jour indépendante binaire. Comme vous pouvez le remarquer,
-nous ne faisons pas de distinction entre les mises à jour indépendantes 
-faites par des porteurs et les autres mises à jour indépendantes.
-
-<p>
-Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
-par l'expression «&nbsp;mise à jour indépendante&nbsp;»
-(NMU<footnote>Non-maintainer upload</footnote>).  Pourtant cela conduit souvent
-à des confusions car beaucoup associent «&nbsp;mise à jour indépendante&nbsp;»
-et «&nbsp;mise à jour indépendante source&nbsp;». Il faut donc rester
-vigilant. Dans ce chapitre, si nous utilisons «&nbsp;mise à jour
-indépendante&nbsp;» seul, il s'agit des deux types de livraisons.
-
-
-
-
-
-       <sect id="nmu-who">Qui peut faire une mise à jour indépendante&nbsp;?
-
-<p>
-Seuls les responsables Debian officiels peuvent faire des mises à jour
-indépendantes. Un responsable officiel est une personne dont la clé est dans
-le porte-clés Debian. Toute personne est invitée à télécharger les paquets
-sources pour corriger des bogues&nbsp;; au lieu de faire des mises à jour
-indépendantes, ils pourront soumettre les rustines qui le méritent au
-système de suivi des bogues. Les responsables apprécient presque toujours les
-rustines et les rapports de bogue soignés.
-
-
-       <sect id="nmu-when">Quand faire une mise à jour indépendante source&nbsp;?
-
-<p>
-Les recommandations pour déterminer quand faire une mise à jour indépendante
-source dépendent de la distribution visée (i.e. stable, instable ou
-experimentale). Les porteurs, ayant une activité particulière, obéissent à des règles
-légèrement différentes (voir <ref id="source-nmu-when-porter">).
-
-<p>
-Quand une faille de sécurité est détectée, un
-paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de
-l'équipe de sécurité Debian<footnote>Debian Security officer</footnote>
-entrera en contact
-avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans
-un délai raisonnable (moins de 48&nbsp;heures). Si le mainteneur ne peut
-fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps,
-l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour
-indépendante source).
-
-<p>
-Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref 
-id="sec-dists">), les livraisons qui
-corrigent les bogues de gravité <em>sérieuse</em> (i.e. <em>serious</em>) et
-supérieures sont encouragées et acceptées. Même pendant cette période, vous
-devrez tenter d'entrer en contact avec le responsable du paquet&nbsp;; il pourrait
-bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour
-n'importe quelle mise à jour indépendante source, les recommandations de la
-section <ref id="nmu-guidelines"> doivent être respectées.
-
-<p>
-Les mises à jour indépendantes sont aussi acceptable pour la distribution
-instable mais seulement en dernier ressort
-ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne
-pas il est probablement correct de faire une mise à jour indépendante 
-<em>(NMU)</em>&nbsp;:
-
-<p>
-       <list compact>
-       <item>
-       Vérifiez que le bogue est bien référencé dans le système de suivi des
-       bogues.  S'il n'y est pas, faites un rapport de bogue.
-
-       <item>
-       Envoyez un courrier au responsable du paquet et proposez votre aide
-       pour corriger le bogue. Donnez-lui quelques jours.
-
-       <item>
-       Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de
-       suivi des bogues. Construisez le paquet et testez-le comme décrit dans
-       la section <ref id="upload-checking">. Utilisez le paquet chez vous.
-
-       <item>
-       Attendez une réponse pendant quelques semaines.
-
-       <item>
-       Envoyez un courrier au responsable lui demandant son accord pour faire
-       une mise à jour indépendante <em>(NMU)</em>.
-
-       <item>
-       Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
-       bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
-       possible.
-
-       <item>
-       Attendez une réponse une semaine encore.
-
-       <item>
-       Faites votre mise à jour indépendante comme décrit dans la section
-       <ref id="nmu-guidelines">.  
-
-       </list>
-
-
-
-
-
-
-       <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
-       source&nbsp;?
-
-<p>
-Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
-rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
-paquet source, cette mise à jour est automatiquement une mise à jour
-indépendante source et est soumise aux règles qui suivent. Si un porteur
-construit un paquet binaire recompilé, les règles sont différentes (voir <ref
-id="porter-guidelines">.
-
-<p>
-Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu
-intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
-modules ou des fichiers, ne déplacez pas les répertoires&nbsp;; plus généralement ne
-corrigez pas ce qui n'est pas cassé.  Faites une rustine aussi petite que
-possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en
-au responsable du paquet, au responsable amont ou soumettez un rapport de
-bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em>
-être faits lors d'une mise à jour indépendante.
-
-
-
-
-
-       <sect1 id="nmu-version">Numéro de version pour les mises à jour
-       indépendantes sources
-
-<p>
-Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
-changer, même pour la plus triviale des modifications. Notre système de
-gestion de paquets s'appuie sur ces numéros de version.
-
-<p>
-Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
-un numéro de version mineur à la partie <var>debian-revision</var> du numéro
-de version (la partie qui suit le dernier trait d'union). Ce numéro
-supplémentaire débutera à «&nbsp;1&nbsp;». Prenons pour exemple le paquet
-«&nbsp;foo&nbsp;» qui porte le  numéro de version 1.1-3. Dans l'archive, le
-fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
-version amont est «&nbsp;1.1&nbsp;» et la révision Debian est «&nbsp;3&nbsp;».
-La mise à jour indépendante suivante ajouterait le numéro de version mineur
-«&nbsp;.1&nbsp;» au numéro de révision Debian; le nouveau fichier de contrôle
-du paquet source serait alors <file>foo_1.1-3.1.dsc</file>.
-
-<p>
-Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro
-de version au responsable officiel du paquet, ce qui pourrait perturber son
-travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
-été livré par le responsable officiel.
-
-<p>
-S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version
-du paquet, il faut en créer une en démarrant à «&nbsp;0.1&nbsp;». S'il est
-absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
-fasse une livraison basée sur une nouvelle version amont, cette personne
-doit choisir «&nbsp;0.1&nbsp;» comme numéro de révision Debian. Le mainteneur
-du paquet doit, lui, démarrer sa numérotation à «&nbsp;1&nbsp;». Notez que pour
-faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option
-<tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il
-reconnaît les numéros de révisions «&nbsp;0&nbsp;» ou «&nbsp;1&nbsp;» &mdash; il
-n'est pas suffisamment intelligent pour reconnaître «&nbsp;0.1&nbsp;»).
-
-<p>
-Attention, les porteurs qui ne font que recompiler les paquets pour d'autres
-architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne
-doivent utiliser de nouveaux numéros de version que s'ils modifient les
-paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour
-indépendante source et non une mise à jour indépendante binaire.
-
-
-
-
-
-       <sect1 id="nmu-changelog">
-         <heading>Les mises à jour indépendantes sources doivent être
-         mentionnées dans le fichier changelog</heading>
-
-<p>
-Une personne qui fait une mise à jour indépendante source doit ajouter une
-entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
-et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
-comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
-version livrée.
-
-<p>
-Par convention, dans le cas d'une mise à jour indépendante source
-<em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne
-
-<example>
-  * Non-maintainer upload
-</example>
-
-
-
-
-
-       <sect1 id="nmu-patch">Mise à jour indépendante source et système
-       de suivi des bogues 
-
-<p>
-Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
-modifications que possible et doit toujours envoyer ses modifications au
-système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
-
-<p>
-En cas de simple recompilation du paquet, le processus diffère
-suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise
-à jour indépendante qui ne nécessite rien de plus qu'une recompilation et
-n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée
-est disponible, un bogue a été corrigé dans <package>debhelper</package>),
-vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>;
-il y aura donc une modification. Si vous êtes porteur, vous êtes probablement
-en train de faire une mise à jour indépendante binaire. (Note&nbsp;: ce système ne
-tient pas compte des porteurs qui font des recompilations &mdash; tenez cela pour
-une faiblesse de notre système de gestion des paquets.)
-
-<p>
-Si la mise à jour indépendante source (<em>source NMU</em>) corrige des
-bogues, ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système
-de suivi des bogues plutôt que clos. Par convention, seul le responsable du
-paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
-rapport.  Heureusement, le système d'archivage Debian reconnait les mises à
-jours indépendantes et positionne correctement le statut des bogues à
-<em>fixed</em> si la personne qui fait la mise à jour a listé tous les
-bogues dans le fichier changelog en utilisant la syntaxe <tt>Closes:
-bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
-sur la fermeture de bogue par le fichier changelog). Ce passage au statut
-<em>fixed</em> assure que chacun sait que le bogue est corrigé par une mise
-à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que
-le responsable du paquet incorpore les modifications de cette mise à jour dans
-la version officielle du paquet.
-
-<p>
-Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
-nouveau rapport de bogue qui inclura une rustine contenant toutes les
-modifications que vous avez faites.
-Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi
-employer une autre méthode pour régler le problème. Certains bogues sont
-corrigés dans la version amont, ce qui est une bonne raison pour annuler les
-modifications d'une mise à jour indépendante. Si le responsable choisit de
-mettre à jour le paquet plutôt que d'utiliser les rustines de la mise à jour
-indépendante, il devra s'assurer que cette nouvelle version corrige
-effectivement chacun des bogues corrigés dans la mise à jour indépendante.
-
-<p>
-De plus, le responsable officiel devrait <em>toujours</em> conserver les
-entrées documentant une mise à jour indépendante dans le fichier
-<file>changelog</file>.
-
-
-
-
-
-
-       <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
-
-<p>
-Les paquets faisant l'objet d'une mise à jour indépendante source sont 
-construits comme les
-autres. Sélectionnez une distribution en utilisant les règles décrites dans
-la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
-classique avec tout ce qui l'accompagne conformément à la description <ref
-id="uploading">.
-
-<p>
-En fait, toutes les prescriptions de la section <ref id="upload"> sont
-applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
-idoine.
-
-<p>
-Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt>
-dans le fichier <file>debian/control</file>. Votre nom, mentionné dans
-l'entrée du fichier <file>debian/changelog</file> concernant la mise à jour, 
-sera utilisé pour signer le fichier <tt>.changes</tt>.
-
-
-
-
-       <chapt id="porting">Le portage
-
-<p>
-Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
-un porteur et même si vous n'utilisez qu'une architecture, il est de votre
-responsabilité de développeur d'être attentif aux questions de portabilité.
-C'est pourquoi il est important que vous lisiez ce chapitre même si vous
-n'êtes pas un porteur.
-       
-<p>
-Porter un paquet consiste à faire un paquet binaire pour une architecture
-différente de celle du paquet binaire fait par le responsable du paquet. 
-C'est une
-activité remarquable et essentielle. En fait, les porteurs sont à l'origine
-de la plupart des compilations de paquet Debian. Pour un paquet binaire
-<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
-autre architecture, soit un total de &number-of-arches; recompilations.
-
-
-
-
-       <sect id="kind-to-porters">Être gentil avec les porteurs
-
-<p>
-Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un 
-grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
-modification. Malheureusement, c'est rarement le cas. Cette section contient
-une liste d'erreurs commises régulièrement par les responsables Debian &mdash;
-problèmes courants qui bloquent souvent les porteurs et compliquent
-inutilement leur travail.
-
-<p>
-Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
-remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
-étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine
-manière). Merci pour votre indulgence envers des rapports de bogues succincts ou
-peu clairs&nbsp;; faites de votre mieux pour éliminer le problème. 
-
-<p>
-Les problèmes les plus couramment rencontrés par les porteurs sont causés par
-des erreurs de mise en paquet dans le paquet source. Voici une
-<em>checklist</em> de choses auxquelles vous devez être attentif :
-
-       <enumlist>
-       <item>
-       Vérifiez que les champs <tt>Build-Depends</tt> et
-       <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
-       corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
-       paquet <package>debootstrap</package> pour créer un environnement
-       <em>unstable</em> <em>chrooté</em>. Dans cet environnement
-       <em>chrooté</em> il faudra installer le paquet
-       <package>build-essential</package> et tous les paquets mentionnés dans
-       les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
-       Ensuite, vous essayerez de fabriquer votre paquet dans cette
-       environnement.
-       <p>
-       Consultez le <url id="&url-debian-policy;" name="Debian Policy
-       Manual"> pour en savoir plus sur les dépendances de fabrication.
-       <item>
-       Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
-       le champ architecture sans avoir de bonnes raisons pour le faire. Trop
-       souvent, les développeurs ne respectent pas les instructions du
-       <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir
-       la valeur «&nbsp;i386&nbsp;» est la plupart du temps incorrect.
-
-       <item>
-       Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
-       <var>package</var>.dsc</tt> pour vous assurer que le paquet se
-       désarchive correctement. En utilisant le résultat de ce test,
-       construisez votre paquet binaire à l'aide de la commande
-       <tt>dpkg-buildpackage</tt>.
-
-       <item>
-       Vérifiez que les fichiers <file>debian/files</file> et
-       <file>debian/substvars</file> ne sont pas dans votre paquet source.
-       Ils doivent être effacés par la cible <em>clean</em> de
-       <file>debian/rules</file>.
-
-       <item>
-       Assurez-vous que vous ne vous appuyez pas sur des éléments de
-       configuration ou des logiciels installés ou modifiés localement. Par
-       exemple, vous ne devriez jamais appeler des programmes du répertoire
-       <file>/usr/local/bin</file> ou de répertoires équivalents.  Essayez de ne pas vous
-       appuyer sur des logiciels configurés de manière spéciale. Essayez de
-       construire votre paquet sur une autre machine, même s'il s'agit de la
-       même architecture.
-
-       <item>
-       Ne vous appuyez pas sur une installation préexistante de votre paquet
-       (un sous-cas de la remarque précédente).
-
-       <item>
-       Si possible, ne vous appuyez pas sur une particularité présente dans
-       un compilateur précis ou dans certaine version d'un compilateur. Si
-       vous ne pouvez pas faire autrement, assurez-vous que les dépendances
-       de fabrication reflètent bien cette restriction. Dans ce cas, vous
-       cherchez sûrement les problèmes car quelques architectures pourraient
-       choisir un compilateur différent.
-
-       <item>
-       Vérifiez que votre <file>debian/rules</file> distingue les cibles
-       <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
-       Charte Debian. Vérifiez que ces cibles sont
-       indépendantes l'une de l'autre, c'est à dire qu'il n'est pas
-       nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre.
-       Pour vérifier cela, essayez d'exécuter <tt>dpkg-buildpackage -b</tt>.
-
-       </enumlist>
-
-
-
-
-       <sect id="porter-guidelines">Instructions pour les mises à jour des
-       porteurs
-
-<p>
-Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
-de la chance et votre travail est facile. Cette section s'applique dans ce
-cas&nbsp;; elle décrit comment construire et installer correctement votre mise à
-jour indépendante binaire dans l'archive Debian. Si vous devez modifier le
-paquet pour le rendre compilable sur votre architecture cible vous devez faire
-une mise à jour des sources, consultez la section <ref id="nmu-guidelines">.
-
-<p>
-Pour une mise à jour indépendante binaire, ne faites pas de changement
-dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet
-source (cela inclut <file>debian/changelog</file>).
-
-<p>
-La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
-<tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr,
-remplacez <var>adresse-porteur</var> par votre adresse électronique. Cette
-commande construira les portions du paquet qui dépendent de l'architecture, en
-utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.
-
-
-       <sect1 id="recompile-nmu-versioning">
-       <heading>Numéro de version des mises à jour indépendantes
-       binaires</heading>
-
-<p>
-Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
-tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
-changer le numéro de version pour que le système de comparaison des numéros de
-version fonctionne correctement. Ce type de mise à jour reste une mise à jour
-indépendante binaire &mdash; il n'est pas nécessaire de reconsidérer le statut
-des paquets binaires des autres architectures pour les marquer périmés ou à
-recompiler.
-
-<p>
-Ces recompilations nécessitent des numéros de version « magiques » pour que le
-système de maintenance de l'archive comprennent que, bien qu'il y ait une
-nouvelle version, il n'y a pas eu de modification des sources. Si vous ne
-faites pas cela correctement, les administrateurs de l'archive rejetteront
-votre mise à jour (car il n'y aura pas de code source associé).
-
-<p>
-Cette magie associée à une mise à jour par recompilation est déclenchée en
-utilisant un troisième nombre dans la partie debian du numéro de version.  Si,
-par exemple, la dernière version du paquet que vous recompilez était
-«&nbsp;2.9-3&nbsp;», votre mise à jour portera le numéro
-«&nbsp;2.9-3.0.1&nbsp;». Si cette version était «&nbsp;3.4-2.1&nbsp;» votre
-mise à jour portera le numéro «&nbsp;3.4-2.1.1&nbsp;».
-
-
-
-       
-       <sect1 id="source-nmu-when-porter"> <heading>Quand faire une mise à
-       jour indépendante source pour un portage&nbsp;?</heading>
-
-<p>
-Les porteurs qui font des mises à jour indépendantes sources suivent
-généralement les instructions de la section <ref id="nmu"> tout comme les
-non-porteurs. Les délais d'attente sont cependant plus courts car les porteurs
-doivent manipuler un grand nombre de paquets.
-À nouveau, la situation diffère selon la distribution visée.
-
-<!--
-FIXME: commented out until I can work out how to upload to testing directly
-
-Une correction
-cruciale (i.e. rendre un paquet compilable sur une architecture supportée par
-la prochaine distribution) peut être installée <em>sans</em> délai pour la
-distribution gelée.
--->
-
-<p>
-Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
-instructions précédentes sont applicables à deux différences près. Tout
-d'abord, le temps d'attente raisonnable &mdash; délai entre le moment où vous
-envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
-faire une mise à jour indépendante <em>(NMU)</em> &mdash; est de sept jours. Ce
-délai peut être raccourci si le problème est crucial et met l'effort de
-portage en difficulté : c'est à la discrétion de l'équipe de portage.
-(Souvenez-vous, il ne s'agit pas d'un règlement mais de recommandations
-communément acceptées).
-
-<p>
-Deuxième différence, les porteurs qui font des mises à jour indépendantes
-sources doivent choisir une gravité <em>sérieuse</em> (i.e.
-<em>serious</em>) ou supérieure quand ils envoient leur rapport au système de
-suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un
-paquet binaire pour chaque architecture supportée au moment de la sortie de la
-distribution. Il est très important d'avoir un paquet source et un paquet
-binaire pour toutes les architectures pour être conforme à plusieurs licences.
-
-<p>
-Les porteurs doivent éviter d'implémenter des contournements pour 
-des bogues de l'environnement de compilation, du noyau ou de la libc. Quelques
-fois ces contournements sont inévitables. Si vous devez faire quelque chose de 
-ce genre, marquez proprement vos
-modifications avec des <tt>#ifdef</tt> et documentez votre contournement pour
-que l'on sache le retirer une fois que le problème aura disparu.
-
-<p>
-Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de
-leur travail pendant le délai d'attente. Ainsi d'autres personnes peuvent
-bénéficier du travail du porteur même pendant ce délai. Bien sûr ces adresses
-n'ont rien d'officiel alors soyez sur vos gardes si vous les utilisez.
-
-
-
-
-       <sect>Outils pour les porteurs
-
-<p>
-Il y a plusieurs outils pour le travail de portage. Cette section contient
-une courte description de ces outils&nbsp;; reportez-vous à la documentation de
-leurs paquets ou aux références citées ci-après pour une description complète.
-
-
-
-
-       <sect1 id="quinn-diff">
-       <heading><package>quinn-diff</package>
-
+Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
+   avec&nbsp;: <example>dinstall -n foo.changes</example>
+<p>
+Attention, les personnes résidant aux États-Unis et les citoyens américains sont
+   soumis à des restrictions sur l'exportation des logiciels de cryptographie.
+   Au moment où j'écris, les citoyens américains peuvent exporter quelques
+   logiciels de cryptographie soumis à une obligation de déclaration auprès du
+   département du commerce américain. Toutefois, cette restriction a été
+   abandonnée pour des logiciels qui sont déjà disponibles en dehors des
+   États-Unis. En conséquence, tout logiciel de cryptographie de la section
+   <em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une autre
+   section &mdash; il ne doit pas dépendre de <em>non-US/main</em> &mdash; peut
+   être téléchargé sur <tt>ftp-master</tt> ou l'une de ses files d'attente
+   décrites plus haut.
+<p>
+La <em>charte Debian</em> n'empêche pas les résidents et citoyens américains de
+   livrer des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le
+   faisant. Nous recommandons aux responsables concernés de prendre toutes les
+   précautions nécessaires, <em>y compris la consultation d'un juriste</em>,
+   pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un
+   paquet sur <tt>non-US</tt>.
+<p>
+Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>,
+   les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
+   name="procédure décrite par le gouvernement américain">. Les responsables de
+   paquets <em>non-US/non-free</em> devront en plus consulter les <url
+   id="&url-notification-of-export;" name="règles de déclaration d'exportation
+   pour les logiciels commerciaux">.
 <p>
-<package>quinn-diff</package> est utilisé pour localiser les différences d'une
-architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
-l'architecture <var>X</var> doivent être portés sur l'architecture <var>Y</var>.
-
-
-
-
+Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
+   juridique. Une fois encore, nous recommandons aux résidents et citoyens
+   américains de consulter un juriste avant de livrer un paquet sur
+   <tt>non-US</tt>.
 
-       <sect1 id="buildd">
-       <heading><package>buildd</package>
 
+       <sect2>Installer un paquet via <tt>chiark</tt>
 <p>
-Le système <package>buildd</package> est un système distribué pour la
-compilation d'une distribution. Il est habituellement utilisé en conjonction
-avec des automates de compilation&nbsp;; ce sont des machines «&nbsp;esclaves&nbsp;»
-qui récupèrent des paquets sources et tentent de les compiler. Il est aussi
-possible d'interagir par courrier électronique avec ce système. Cette
-interface est utilisée par les porteurs pour récupérer un paquet source (en
-général un paquet qui ne peut être compilé automatiquement) et travailler
-dessus.
-
+Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
+   possibilités. L'une d'elles consiste à télécharger vos fichiers dans
+   <file>Incoming</file> en passant par le serveur <tt>chiark</tt> en Europe.
+   Pour les détails, consultez <url id="&url-chiark-readme;">.
 <p>
-<package>buildd</package> n'est pas disponible sous forme de paquet&nbsp;;
-pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont prévu
-de l'utiliser bientôt. Il regroupe un ensemble de composants très utiles,
-continuellement utilisés mais non encore mis en paquet, tels que
-<prgn>andrea</prgn>, <prgn>sbuild</prgn> et <prgn>wanna-build</prgn>.
-
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
+   contrôle des exportations américaines sur <tt>chiark</tt>. Les paquets
+   téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les
+   indications de la section <ref id="upload-ftp-master"> sont applicables ici
+   aussi.
 <p>
-Une partie des informations produites par <package>buildd</package> &mdash; utiles
-pour les porteurs &mdash; est disponible sur la toile à l'adresse <url
-id="&url-buildd;">. Ces informations incluent les résultats produits toutes
-les nuits par <prgn>andrea</prgn> (dépendances des sources) et
-<prgn>quinn-diff</prgn> (paquets à recompiler).  <p> Nous sommes très
-enthousiasmés par ce système car il a de nombreux usages potentiels. Des
-groupes de développeurs indépendants peuvent utiliser ce système pour créer
-différentes saveurs de la Debian &mdash; qui peuvent être ou ne pas être
-intéressantes pour tous (une version de Debian compilée avec des vérifications
-relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
-rapidement toute une distribution.
-
-
-
+Le programme <prgn>dupload</prgn> est capable de télécharger sur
+   <tt>chiark</tt>&nbsp;; consultez la documentation de ce programme pour en
+   savoir plus.
 
-       <sect1 id="dpkg-cross">
-       <heading><package>dpkg-cross</package>
 
+       <sect2>Installer un paquet via <tt>erlangen</tt>
 <p>
-<package>dpkg-cross</package> est un outil qui installe les bibliothèques et
-les entêtes nécessaires à une compilation croisée<footnote><em>cross-compilation</em>
-</footnote> d'une manière similaire à <package>dpkg</package>. De plus
-<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
-améliorés pour supporter les compilations croisées.  
-
-
-
-
-
-       <chapt id="archive-manip">
-       <heading>Déplacer, effacer, renommer, adopter et abandonner des
-       paquets</heading>
-
+Vous pouvez aussi accéder à un serveur situé en Allemagne&nbsp;: il vous suffit
+   d'ouvrir une connexion anonyme sur <url id="&url-upload-erlangen;">.
+<p>
+Le téléchargement fait sur ce serveur doit être aussi complet que s'il était
+   fait dans le répertoire <file>Incoming</file> sur <tt>ftp-master</tt> : il
+   doit comporter le fichier <file>.changes</file> et tous les fichiers
+   mentionnés dans ce dernier. Le serveur vérifie que le fichier
+   <file>.changes</file> est bien signé avec la clé PGP d'un développeur Debian
+   pour éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez
+   bien que le champ <tt>Maintainer</tt> du fichier <file>.changes</file>
+   contient <em>votre</em> adresse électronique. De même que sur
+   <tt>ftp-master</tt>, cette adresse est ensuite utilisée pour toutes les
+   réponses.
+<p>
+Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire après
+   le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous devriez
+   ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de votre
+   paquet. Normalement, il devrait avoir été déplacé vers
+   <tt>ftp-master</tt>&nbsp;; vous serez informé par le même biais si une erreur
+   s'est produite au cours du processus.
+<p>
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
+   contrôle des exportations américaines sur <tt>erlangen</tt>. Les paquets
+   téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les
+   indications de la section <ref id="upload-ftp-master"> sont applicables ici
+   aussi.
 <p>
-Certaines manipulations de l'archive ne sont pas accessibles avec le processus
-de mise à jour automatisé. Elles sont appliquées manuellement par les
-développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
+Le programme <prgn>dupload</prgn> est capable de télécharger sur
+   <tt>erlangen</tt>&nbsp;; consultez la documentation de ce programme pour en
+   savoir plus.
 
 
+       <sect2>Les autres serveurs
+<p>
+Un autre serveur est disponible aux États-Unis&nbsp;; c'est un bon point de
+   repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
+   paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
+   <tt>erlangen</tt>.
+<p>
+Il existe aussi un serveur au Japon&nbsp;: téléchargez vos paquet par FTP
+   anonyme sur <url id="&url-upload-jp;">.
 
 
-       <sect>Déplacer des paquets
 
+      <sect1 id="upload-announce">Annoncer une mise à jour
 <p>
-Parfois un paquet pourra changer de section. Une nouvelle version d'un paquet
-de la section <tt>non-free</tt> pourrait par exemple être distribuée sous
-licence LGP GNU&nbsp;; dans ce cas le paquet doit être déplacé dans la section
-<tt>main</tt> ou <tt>contrib</tt><footnote> Reportez-vous  au <url
-id="&url-debian-policy;" name="Debian Policy Manual"> pour savoir dans quelle
-section un paquet doit être classé.</footnote>.
-
+Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
+ listes «&nbsp;debian-changes&nbsp;». Ceci est maintenant géré automatiquement
+ par le logiciel de gestion de l'archive quand il est exécuté (en principe, une
+ fois par jour). Vous devez juste utiliser une version récente de
+ <package>dpkg-dev</package> (&gt;= 1.4.1.2). Le courrier généré par le logiciel
+ de maintenance de l'archive contiendra le fichier <file>.changes</file> signé
+ que vous avez livré avec votre paquet. Précédemment, cette charge revenait à
+ <prgn>dupload</prgn>&nbsp;; vérifiez que vous avez bien configuré
+ <prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
+ <tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).
 <p>
-Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez
-les informations de contrôle du paquet pour le placer dans la section désirée
-et téléchargez à nouveau votre paquet dans l'archive. Reportez-vous au
-<url id="&url-debian-policy;" name="Debian Policy Manual"> pour en savoir
-plus.  Lisez attentivement le rapport d'installation qui vous sera envoyé lors
-de l'archivage de votre paquet. Si pour une raison ou une autre le paquet
-est toujours à son ancien emplacement, envoyez un rapport de bogue sur le
-pseudo-paquet <tt>ftp.debian.org</tt> demandant la suppression dudit paquet.
-Décrivez précisément vos manipulations car il pourrait s'agir d'un bogue dans
-le logiciel de gestion de l'archive.
-
+Si un paquet est mis à jour avec un champ <tt>Distribution:</tt> à
+ <em>stable</em>, l'annonce est envoyée sur la liste &email-debian-changes;.
+ S'il est mis à jour avec un champ <tt>Distribution:</tt> à <em>unstable</em> ou
+ <em>experimental</em>, l'annonce est envoyée sur la liste
+ &email-debian-devel-changes;.
+
+      <sect1 id="upload-notification">
+         <heading>Notification de l'installation d'un nouveau paquet</heading>
+<p>
+Les administrateurs de l'archive Debian sont responsables de l'installation des
+ mises à jour. La plupart des mises à jour sont gérées quotidiennement par le
+ logiciel de gestion de l'archive <prgn>katie</prgn>. Les mises à jour de
+ paquets sur la distribution <em>unstable</em> sont installées
+ ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet,
+ celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois entre le
+ téléchargement d'un paquet vers un serveur et son installation effective. Soyez
+ patient.
+<p>
+Dans tous les cas, vous recevrez un accusé de réception par courrier
+ électronique indiquant que votre paquet a été installé et quels rapports de
+ bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous les
+ rapports de bogue que vous vouliez clore sont bien dans cette liste.
+<p>
+L'accusé de réception indique aussi la section dans laquelle le paquet a été
+ installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier
+ qui vous informera de cette différence (voir ci-dessous).
+
+       <sect2 id="override-file">Le fichier <em>override</em>
 <p>
-Si vous avez besoin de modifier la sous-section de l'un de vos paquets
-(<tt>devel</tt> ou <tt>admin</tt> par exemple) la procédure est légèrement
-différente. Modifiez la sous-section dans le fichier de contrôle de votre
-paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
-fichier <em>override</em> comme décrit dans la section <ref
-id="override-file">.
-
-
-
-
-       <sect id="removing-pkgs">Supprimer des paquets
-
+Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
+   <file>debian/control</file> n'indiquent ni où le paquet sera installé dans
+   l'archive Debian, ni sa priorité. Afin de conserver la cohérence de
+   l'archive, ce sont les administrateurs qui contrôlent ces champs. Les valeurs
+   du fichier <file>debian/control</file> sont juste des indications.
 <p>
-Si pour une raison ou une autre vous avez besoin de supprimer un paquet
-de l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile,
-que l'on conservait pour des raisons de compatibilité), il vous faudra 
-envoyer un rapport de bogue concernant le pseudo-paquet
-<tt>ftp.debian.org</tt> et demandant sa suppression. N'oubliez pas de
-préciser de quelle distribution le paquet doit être supprimé.
-
+Les administrateurs de l'archive indiquent les sections et priorités des paquets
+   dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
+   fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
+   informé par courrier électronique quand votre paquet sera installé dans
+   l'archive. Vous pourrez corriger votre fichier <em>debian/control</em> avant
+   votre prochain téléchargement ou alors vous pourrez vouloir modifier le
+   fichier <em>override</em>.
+<p>
+Pour modifier la section dans laquelle un paquet est archivé, vous devez d'abord
+   vérifier que fichier <file>debian/control</file> est correct. Ensuite,
+   envoyez un courrier à &email-override; ou un rapport de bogue sur le
+   pseudo-paquet <package>ftp.debian.org</package> demandant la modification de
+   la section ou de la priorité de votre paquet. Exposez bien les raisons qui
+   vous amènent à demander ces changements.
+<p>
+Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref
+   section="8" name="dpkg-scanpackages">, &file-bts-mailing; et &file-bts-info;.
+
+
+    <sect id="nmu">Mise à jour indépendante
+<p>
+Dans certaines circonstances, il est nécessaire qu'une personne autre que le
+      responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de
+      mise à jour est désigné en anglais par l'expression <em>non-maintainer
+      upload (NMU)</em>. Dans le présent document, nous traduisons librement
+      cette expression par «&nbsp;mise à jour indépendante&nbsp;».
+<p>
+Ces mises à jour indépendantes de binaires font de temps en temps partie du
+       travail normal des porteurs qui compilent les paquets pour d'autres
+       architectures (voir <ref id="porting">). Un développeur peut aussi faire
+       des mises à jour indépendantes quand il corrige le paquet d'un autre
+       développeur pour éliminer un problème de sécurité ou un bogue bloquant. Cela
+       se produit plus particulièrement en période de gel de la distribution de
+       développement ou quand le responsable officiel du paquet ne peut pas
+       fournir une correction dans un délai raisonnable.
 <p>
-Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
-autres développeurs sur la liste &email-debian-devel;.  Le programme
-<prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
-utile. La commande <tt>apt-cache showpkg <var>package</var> </tt> vous
-indiquera, entre autres, les paquets qui dépendent de <var>package </var>.
-
-       <sect1>Supprimer des paquets dans <tt>Incoming</tt>
+Ce chapitre contient des informations qui vous expliqueront quand et comment
+      faire des mises à jour indépendantes. Une distinction fondamentale doit
+      être faite entre les mises à jour indépendantes sources et les mises à
+      jour indépendantes binaires. Elle est explicitée dans la section suivante.
+
+      <sect1 id="nmu-terms">Terminologie
+<p>
+Deux nouvelles expressions sont introduites dans cette section&nbsp;:
+ «&nbsp;mise à jour indépendante source&nbsp;» et «&nbsp;mise à jour
+ indépendante binaire&nbsp;». Ces expressions ont une définition précise dans le
+ monde Debian. Elles correspondent toutes deux au même type d'activité&nbsp;;
+ elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
+ alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
+ nous qualifions ces mises à jours
+ d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
+ entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
+ question d'agir sans prévenir le responsable au préalable (voir <ref
+ id="nmu-guidelines">).</footnote>.
+<p>
+Une mise à jour indépendante source est une livraison de paquet faite par une
+ personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
+ de corriger un bogue dans le paquet. Une mise à jour indépendante source
+ implique toujours une modification des sources du paquet, même s'il ne s'agit
+ que d'un changement dans le fichier <file>debian/changelog</file>. Ce
+ changement peut tout aussi bien concerner la partie amont du source que la
+ partie spécifique à Debian. Une mise à jour indépendante source peut aussi
+ inclure des paquets spécifiques à une architecture tout comme un fichier
+ <em>diff</em> modifié.
+<p>
+Une mise à jour indépendante binaire est constitué par la recompilation et
+ l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
+ résultat d'un effort de portage. Une mise à jour indépendante binaire est la
+ livraison d'un paquet compilé (souvent pour une autre architecture) à condition
+ que cette compilation n'ait pas nécessité de modifications des sources. Dans de
+ nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
+ compilables sur leur architecture cible&nbsp;; il s'agira alors d'une mise à
+ jour indépendante source et non d'une mise à jour indépendante binaire. Comme
+ vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
+ jour indépendantes faites par des porteurs et les autres mises à jour
+ indépendantes.
 <p>
-Par le passé, il était possible de supprimer un paquet de <tt>Incomming</tt>.
-Ce n'est plus possible depuis la mise en place du nouveau système
-de file d'attente. Il vous faudra télécharger une nouvelle version de votre
-paquet avec un numéro de version postérieur à celui que vous voulez remplacer.
-Les deux versions seront installées dans l'archive mais seule la plus récente
-sera accessible dans <em>unstable</em> car la précédente sera immédiatement
-replacée par la nouvelle. Toutefois, si vous testez correctement vos paquets,
-le besoin d'en remplacer un ne devrait pas être trop fréquent.
-
-
+Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
+ par l'expression «&nbsp;mise à jour indépendante&nbsp;»
+ (NMU<footnote><p>Non-maintainer upload</footnote>). Pourtant, cela conduit
+ souvent à des confusions car beaucoup associent «&nbsp;mise à jour
+ indépendante&nbsp;» et «&nbsp;mise à jour indépendante source&nbsp;». Il faut
+ donc rester vigilant. Dans ce chapitre, si nous utilisons l'expression
+ «&nbsp;mise à jour indépendante&nbsp;» seule, il s'agit des deux types de
+ livraisons.
 
-       <sect>Remplacer ou renommer un paquet
 
+      <sect1 id="nmu-who">Qui peut faire une mise à jour indépendante&nbsp;?
 <p>
-Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de le
-renommer. Dans ce cas, vous devrez intervenir en deux étapes. D'abord,
-modifiez votre fichier <file>debian/control</file> pour que votre paquet
-renommé remplace et entre en conflit avec le nom de paquet que vous voulez
-remplacer. Reportez-vous au <url id="&url-debian-policy;" name="Debian Policy
-Manual"> pour les détails. Une fois que votre paquet est installé dans
-l'archive, faites un rapport de bogue concernant le pseudo-paquet
-<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
-l'archive, faites un rapport de bogue concernant le pseudo-paquet
-<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
-
-
-
-
+Seuls les responsables Debian officiels peuvent faire des mises à jour
+ indépendantes. Un responsable officiel est une personne dont la clé est dans le
+ porte-clés Debian. Toute personne est invitée à télécharger les paquets sources
+ pour corriger des bogues&nbsp;; au lieu de faire des mises à jour
+ indépendantes, ils pourront soumettre les correctifs qui le méritent au système
+ de suivi des bogues. Les responsables apprécient presque toujours les
+ correctifs et les rapports de bogue soignés.
 
-       <sect id="orphaning">Abandonner un paquet
 
+      <sect1 id="nmu-when">Quand faire une mise à jour indépendante
+      source&nbsp;?
 <p>
-Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres
-et faire le nécessaire pour qu'il soit marqué <em>abandonné</em>(i.e.
-<em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
-Group &orphan-address;</tt> dans le champ
-<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
-pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
-«&nbsp;<tt>O<footnote><em>Orphaned</em>&nbsp;: abandonné.</footnote>:
-<var>paquet</var> &mdash; <var>courte description</var></tt>&nbsp;» pour indiquer
-que le paquet est orphelin. La gravité du bogue sera <em>normale</em>.
-Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
-l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le
-sujet du message ne contiendra pas le numéro du bogue.
-
+Les recommandations pour déterminer quand faire une mise à jour indépendante
+ source dépendent de la distribution visée (i.e. <em>stable</em>,
+ <em>unstable</em> ou <em>experimental</em>). Les porteurs, ayant une activité
+ particulière, obéissent à des règles légèrement différentes (voir <ref
+ id="source-nmu-when-porter">).
+<p>
+Quand une bogue de sécurité est détecté, l'équipe de sécurité peut faire une
+ mise à jour indépendante. Veuillez vous reporter à <ref id="bug-security"> pour
+ plus d'informations.
+<p>
+Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref
+ id="sec-dists">), les livraisons qui corrigent les bogues de gravité
+ <em>sérieuse</em> (i.e. <em>serious</em>) et supérieures sont encouragées et
+ acceptées. Même pendant cette période, vous devriez tenter d'entrer en contact
+ avec le responsable du paquet&nbsp;; il pourrait bien être sur le point de
+ livrer un paquet corrigé lui aussi. Comme pour n'importe quelle mise à jour
+ indépendante source, les recommandations de la section <ref
+ id="nmu-guidelines"> doivent être respectées. Des exceptions spéciales sont
+ effectuées pour <ref id="qa-bsp">.
+<p>
+Envoyer des corrections de bogues vers <em>unstable</em> par une autre personne
+ que le responsable ne devrait être fait qu'en suivant ce protocole&nbsp;:
+<p>
+<list>
+<item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
+      mise à jour indépendante sont bien référencés dans le système de suivi des
+      bogues. S'ils n'y sont pas, faites des rapports de bogue
+      immédiatement.
+<item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
+      aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
+      corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
+      «&nbsp;patch&nbsp;».
+<item>Patientez quelques jours. Si vous n'avez toujours aucune réponse du
+      responsable, envoyez-lui un courrier annonçant votre intention
+      d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme
+      décrit dans <ref id="nmu-guidelines">, testez-la soigneusement sur votre
+      machine (cf. <ref id="upload-checking">). Re-vérifiez que votre correctif
+      n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
+      aussi minimaliste et non intrusif que possible.
+<item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
+      <ref id="delayed-incoming">), envoyez le correctif final au responsable
+      par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
+      la NMU.
+<item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
+      auriez introduit avec votre NMU. Vous devriez probablement utiliser le
+      <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
+      paquet après votre NMU.
+</list>
+<p>
+Parfois, le responsable de version ou un groupe organisé de
+ développeurs peut annoncer une certaine période de temps au cours de laquelle
+ les règles de mise à jour indépendante seront plus souples. Ceci implique
+ habituellement une période plus courte d'attente avant d'envoyer des
+ correctifs et une période de délai plus courte. Il est important de noter que
+ même au cours de ces «&nbsp;chasses aux bogues&nbsp;», la personne
+ désirant faire la mise à jour indépendante doit remplir des bogues et
+ contacter en premier le développeur, et ensuite seulement passer à
+ l'action.
+
+      <sect1 id="nmu-guidelines">Comment faire une mise à jour indépendante
+      source&nbsp;?
 <p>
-Si le paquet est particulièrement important pour la distribution il vous
-faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
-«&nbsp;<tt>RFA<footnote><em>Request For Adoption</em>&nbsp;: offre
-d'adoption.</footnote>: <var>paquet</var> &mdash; <var>courte
-description</var></tt>&nbsp;» et lui affecter la gravité <em>importante</em>.
-Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
-décrit précédemment.
-
+Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
+ rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
+ paquet source, cette mise à jour est automatiquement une mise à jour
+ indépendante source et est soumise aux règles qui suivent. Si un porteur
+ construit un paquet binaire recompilé, les règles sont différentes (voir <ref
+ id="porter-guidelines">.
+<p>
+Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
+ intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
+ modules ou des fichiers, ne déplacez pas les répertoires&nbsp;; plus
+ généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
+ petit que possible. Si certaines choses froissent votre sens de l'esthétique,
+ parlez-en au responsable du paquet, au responsable amont ou soumettez un
+ rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent
+ pas</em> être effectués lors d'une mise à jour indépendante.
+
+
+       <sect2 id="nmu-version">Numéro de version pour les mises à jour
+       indépendantes sources
 <p>
-Reportez-vous à la page WNPP<footnote><em>Work-needing and prospective
-packages</em>&nbsp;: paquets en souffrance et paquets souhaités.</footnote> <url
-id="&url-wnpp;"> pour en savoir plus.
-
-
-
-
-
-       <sect id="adopting">Adopter un paquet
-
+Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
+   changer, même pour la plus triviale des modifications. Notre système de
+   gestion de paquets s'appuie sur ces numéros de version.
 <p>
-Une liste des paquets en attente de nouveau responsable est disponible à la
-page <url id="&url-wnpp;" name="Work-Needing and Prospective Packages">. Si
-vous voulez prendre en charge un paquet de cette liste reportez-vous à la page
-susmentionnée pour connaître la procédure à suivre.
+Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
+   un numéro de version mineur à la partie <var>debian-revision</var> du numéro
+   de version (la partie qui suit le dernier trait d'union). Ce numéro
+   supplémentaire débutera à «&nbsp;1&nbsp;». Prenons pour exemple le paquet
+   «&nbsp;foo&nbsp;» qui porte le numéro de version 1.1-3. Dans l'archive, le
+   fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
+   version amont est «&nbsp;1.1&nbsp;» et la révision Debian est
+   «&nbsp;3&nbsp;». La mise à jour indépendante suivante ajouterait le numéro de
+   version mineur «&nbsp;.1&nbsp;» au numéro de révision Debian; le nouveau
+   fichier de contrôle du paquet source serait alors
+   <file>foo_1.1-3.1.dsc</file>.
+<p>
+Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro de
+   version au responsable officiel du paquet, ce qui pourrait perturber son
+   travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
+   été livré par le responsable officiel.
+<p>
+S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version du
+   paquet, il faut en créer une en démarrant à «&nbsp;0.1&nbsp;». S'il est
+   absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
+   fasse une livraison basée sur une nouvelle version amont, cette personne doit
+   choisir «&nbsp;0.1&nbsp;» comme numéro de révision Debian. Le mainteneur du
+   paquet doit, lui, démarrer sa numérotation à «&nbsp;1&nbsp;».
 
+       <sect2 id="nmu-changelog">
+           <heading>Les mises à jour indépendantes sources doivent être
+           mentionnées dans le fichier changelog</heading>
 <p>
-Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
-correct &mdash; ce serait une prise d'otage.  Vous pouvez prendre contact avec le
-responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.
-Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une
-raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable
-est parti sans prévenir depuis un moment, demandez-le sur la liste
-&email-debian-private;.
-
+Une personne qui fait une mise à jour indépendante source doit ajouter une
+   entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
+   et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
+   comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
+   version livrée.
 <p>
-Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de
-suivi des bogues indique que vous êtes le responsable du paquet. Cela se
-produira automatiquement une fois que vous aurez installé une nouvelle version
-du paquet dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut
-prendre quelques heures après le téléchargement. Si vous pensez ne pas avoir
-de mise à jour à faire pour un moment, envoyez un courrier électronique à
-&email-override; pour pouvoir recevoir les rapports de bogue.
+Par convention, dans le cas d'une mise à jour indépendante source
+   <em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne
 
+<example>
+  * Non-maintainer upload
+</example>
 
 
+       <sect2 id="nmu-patch">Mise à jour indépendante source et système de
+       suivi des bogues
+<p>
+Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
+   modifications que possible et doit toujours envoyer ses modifications au
+   système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
+<p>
+Et si vous recompilez simplement le paquet&nbsp;? Si vous avez simplement besoin
+   de recompiler le paquet pour une seule architecture, vous pouvez faire une
+   NMU binaire seulement comme décrit dans <ref id="binary-only-nmu"> qui ne
+   nécessite pas qu'un correctif soit envoyé. Si vous désirez que le paquet soit
+   recompilé pour toutes les architectures, vous devez alors faire une NMU
+   source et vous devrez envoyer un correctif.
+<p>
+Si la mise à jour indépendante source (<em>source NMU</em>) corrige des bogues,
+   ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système de
+   suivi des bogues plutôt que clos. Par convention, seul le responsable du
+   paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
+   rapport. Heureusement, le système d'archivage Debian reconnaît les mises à
+   jours indépendantes et positionne correctement le statut des bogues à
+   <em>fixed</em> si la personne qui fait la mise à jour a listé tous les bogues
+   dans le fichier changelog en utilisant la syntaxe <tt>Closes:
+   bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
+   sur la fermeture de bogue par le fichier <file>changelog</file>). Ce passage
+   au statut <em>fixed</em> assure que chacun sait que le bogue est corrigé par
+   une mise à jour indépendante tout en laissant le rapport de bogue ouvert
+   jusqu'à ce que le responsable du paquet incorpore les modifications de cette
+   mise à jour dans la version officielle du paquet.
+<p>
+Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
+   nouveau rapport de bogue qui inclura un correctif contenant toutes les
+   modifications que vous avez faites. Sinon, vous pouvez envoyer cette
+   information aux bogues qui sont fixés par votre NMU. Le responsable officiel
+   pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
+   méthode pour régler le problème. Certains bogues sont corrigés dans la
+   version amont, ce qui est une bonne raison pour annuler les modifications
+   d'une mise à jour indépendante. Si le responsable choisit de mettre à jour le
+   paquet plutôt que d'utiliser les correctifs de la mise à jour indépendante,
+   il devra s'assurer que cette nouvelle version corrige effectivement chacun
+   des bogues corrigés dans la mise à jour indépendante.
+<p>
+De plus, le responsable officiel devrait <em>toujours</em> conserver les entrées
+   documentant une mise à jour indépendante dans le fichier
+   <file>changelog</file>.
+
+
+       <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
+<p>
+Les paquets faisant l'objet d'une mise à jour indépendante source sont
+   construits comme les autres. Sélectionnez une distribution en utilisant les
+   règles décrites dans la section <ref id="upload-dist"> et construisez un
+   fichier <tt>.changes</tt> classique avec tout ce qui l'accompagne
+   conformément à la description <ref id="uploading">. En fait, toutes les
+   prescriptions de la section <ref id="upload"> sont applicables ici.
+<p>
+Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt> dans
+   le fichier <file>debian/control</file>. Votre nom, mentionné dans l'entrée du
+   fichier <file>debian/changelog</file> concernant la mise à jour, sera utilisé
+   pour signer le fichier <file>.changes</file>.
+
+      <sect1 id="ack-nmu">Valider une mise à jour indépendante
+<p>
+Si l'un de vos paquets a subi une mise à jour indépendante, vous devez récupérer
+ les changements dans votre copie des sources. Ceci est aisé, vous avez
+ simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
+ vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
+ jour. Vous pouvez soit les fermer manuellement en envoyant les courriers
+ nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
+ l'entrée du changelog de votre prochain envoi.
+<p>
+Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
+ pas une attaque personnelle contre le responsable. C'est une preuve que le
+ paquet est important pour quelqu'un et qu'il est désireux de vous aider dans
+ votre travail, vous devriez donc lui être reconnaissant. Vous pouvez également
+ lui demander s'il serait intéressé pour vous aider sur une base plus régulière
+ comme co-responsable ou responsable de secours (cf. <ref
+ id="collaborative-maint">).
+
+
+    <sect id="porting">Le portage
+<p>
+Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
+      porteur et même si vous n'utilisez qu'une architecture, il est de votre
+      responsabilité de développeur d'être attentif aux questions de
+      portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
+      même si vous n'êtes pas un porteur.
+<p>
+Porter un paquet consiste à faire un paquet binaire pour une architecture
+      différente de celle du paquet binaire fait par le responsable du paquet.
+      C'est une activité remarquable et essentielle. En fait, les porteurs sont
+      à l'origine de la plupart des compilations de paquets Debian. Pour un
+      paquet binaire <em>i386</em>, par exemple, il faut compter une
+      recompilation pour chaque autre architecture, soit un total de
+      &number-of-arches; recompilations.
 
 
-       <chapt id="bug-handling">Gérer les bogues
+      <sect1 id="kind-to-porters">Être gentil avec les porteurs
+<p>
+Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
+ grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
+ modification. Malheureusement, c'est rarement le cas. Cette section contient
+ une liste d'erreurs commises régulièrement par les responsables Debian &mdash;
+ problèmes courants qui bloquent souvent les porteurs et compliquent inutilement
+ leur travail.
+<p>
+Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
+ remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
+ étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
+ Merci pour votre indulgence envers des rapports de bogue succincts ou peu
+ clairs&nbsp;; faites de votre mieux pour éliminer le problème.
+<p>
+Les problèmes les plus couramment rencontrés par les porteurs sont causés par
+ des erreurs de mise en paquet dans le paquet source. Voici un
+ pense-bête pour les choses auxquelles vous devez être attentif&nbsp;:
+<enumlist>
+  <item>
+       Vérifiez que les champs <tt>Build-Depends</tt> et
+       <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
+       corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
+       <package>debootstrap</package> pour créer un environnement
+       <em>unstable</em> <em>chrooté</em>. Dans cet environnement
+       <em>chrooté</em> il faudra installer le paquet
+       <package>build-essential</package> et tous les paquets mentionnés dans
+       les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
+       Ensuite, vous essayerez de fabriquer votre paquet dans cet
+       environnement. Ces étapes peuvent être automatisées en utilisant le
+       programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
+       nom.
+        <p>
+        Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
+       savoir plus sur les dépendances de fabrication.
+  </item>
+  <item>
+       Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
+       le champ architecture sans avoir de bonnes raisons pour le faire. Trop
+       souvent, les développeurs ne respectent pas les instructions de la <url
+       id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
+       «&nbsp;i386&nbsp;» est la plupart du temps incorrect.
+  </item>
+  <item>
+       Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
+       <var>package</var>.dsc</tt> pour vous assurer que le paquet se
+       décompresse correctement. En utilisant le résultat de ce test,
+       construisez votre paquet binaire à l'aide de la commande
+       <prgn>dpkg-buildpackage</prgn>.
+  </item>
+  <item>
+       Vérifiez que les fichiers <file>debian/files</file> et
+       <file>debian/substvars</file> ne sont pas dans votre paquet source. Ils
+       doivent être effacés par la cible <em>clean</em> de
+       <file>debian/rules</file>.
+  </item>
+  <item>
+       Assurez-vous que vous ne vous appuyez pas sur des éléments de
+       configuration ou des logiciels installés ou modifiés localement. Par
+       exemple, vous ne devriez jamais appeler des programmes du répertoire
+       <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne
+       pas vous appuyer sur des logiciels configurés de manière spéciale.
+       Essayez de construire votre paquet sur une autre machine, même s'il
+       s'agit de la même architecture.
+  </item>
+  <item>
+       Ne vous appuyez pas sur une installation préexistante de votre paquet
+       (un sous-cas de la remarque précédente).
+  </item>
+  <item>
+       Si possible, ne vous appuyez pas sur une particularité présente dans un
+       compilateur précis ou dans une certaine version d'un compilateur. Si
+       vous ne pouvez pas faire autrement, assurez-vous que les dépendances de
+       fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez
+       sûrement les problèmes car quelques architectures pourraient choisir un
+       compilateur différent.
+  </item>
+  <item>
+       Vérifiez que votre <file>debian/rules</file> distingue les cibles
+       <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la charte
+       Debian. Vérifiez que ces cibles sont indépendantes l'une de l'autre,
+       c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de ces cibles
+       avant d'invoquer l'autre. Pour vérifier cela, essayez d'exécuter
+       <tt>dpkg-buildpackage -b</tt>.
+  </item>
+</enumlist>
 
 
+      <sect1 id="porter-guidelines">Instructions pour les mises à jour des
+      porteurs
+<p>
+Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
+ de la chance et votre travail est facile. Cette section s'applique dans ce
+ cas&nbsp;; elle décrit comment construire et installer correctement votre
+ paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le
+ rendre compilable sur votre architecture cible vous devez faire une mise à jour
+ des sources, consultez la section <ref id="nmu-guidelines">.
+<p>
+Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
+ n'avez pas besoin de modifier les fichiers du paquet source (cela inclut le
+ fichier <file>debian/changelog</file>).
+<p>
+La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante&nbsp;:
+ <tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
+ <var>adresse-porteur</var> par votre adresse électronique. Cette commande
+ construira les parties du paquet qui dépendent de l'architecture, en utilisant
+ la cible <em>binary-arch</em> de <file>debian/rules</file>.
+
+       <sect2 id="binary-only-nmu">
+          Mises à jour indépendantes binaires ou recompilations
+<p>
+Parfois l'envoi du portage initial pose problème car l'environnement dans lequel
+ le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
+ obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
+ dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
+ le numéro de version pour que les mauvais anciens paquets soient remplacés dans
+ l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
+ s'ils n'ont pas un numéro de version supérieur à celui actuellement
+ disponible). Malgré les modifications nécessaires du changelog, ce type de mise
+ à jour reste une mise à jour indépendante binaire &mdash; il n'est pas
+ nécessaire de reconsidérer le statut des paquets binaires des autres
+ architectures pour les marquer périmés ou à recompiler.
+<p>
+Ces recompilations nécessitent des numéros de version «&nbsp;magiques&nbsp;»
+ pour que le système de maintenance de l'archive comprennent que, bien qu'il y
+ ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
+ ne faites pas cela correctement, les administrateurs de l'archive rejetteront
+ votre mise à jour (car il n'y aura pas de code source associé).
+<p>
+Cette magie associée à une mise à jour par recompilation est déclenchée en
+ utilisant un troisième nombre dans la partie debian du numéro de version. Si,
+ par exemple, la dernière version du paquet que vous recompilez était
+ «&nbsp;2.9-3&nbsp;», votre mise à jour portera le numéro
+ «&nbsp;2.9-3.0.1&nbsp;». Si cette version était «&nbsp;3.4-2.1&nbsp;» votre
+ mise à jour portera le numéro «&nbsp;3.4-2.1.1&nbsp;».
 
-       <sect>Superviser les rapports de bogues
 
+       <sect2 id="source-nmu-when-porter">
+         Quand faire une mise à jour indépendante source pour un portage&nbsp;?
 <p>
-Si vous voulez être un bon responsable, consultez régulièrement la
-page du <url id="&url-bts;" name="système de suivi des bogues">. Cette page
-contient tous les rapports de bogue qui concernent vos paquets.
-
+Les porteurs qui font des mises à jour indépendantes sources suivent
+   généralement les instructions de la section <ref id="nmu"> tout comme les
+   non-porteurs. Les délais d'attente sont cependant plus courts car les
+   porteurs doivent manipuler un grand nombre de paquets. À nouveau, la
+   situation diffère selon la distribution visée.
 <p>
-Les responsables interagissent avec le système de suivi des bogues en
-utilisant l'adresse électronique <tt>bugs.debian.org</tt>. Vous trouverez une
-documentation sur les commandes disponibles à l'adresse <url id="&url-bts;">
-ou, si vous avez installé le paquet <package>doc-debian</package>, dans les
-fichiers locaux &file-bts-docs;.
-
+Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
+   instructions précédentes sont applicables à deux différences près. Tout
+   d'abord, le temps d'attente raisonnable &mdash; délai entre le moment où vous
+   envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
+   faire une mise à jour indépendante <em>(NMU)</em> &mdash; est de sept jours.
+   Ce délai peut être raccourci si le problème est crucial et met l'effort de
+   portage en difficulté : c'est à la discrétion de l'équipe de portage.
+   (Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations
+   communément acceptées)
 <p>
-Certains trouvent utile de recevoir régulièrement une synthèse des rapports de
-bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant
-tous les rapports de bogue ouverts pour vos paquets, vous pouvez configurer
-<prgn>cron</prgn> comme suit&nbsp;:
-
+Deuxième différence, les porteurs qui font des mises à jour indépendantes
+   sources doivent choisir une gravité <em>sérieuse</em> (i.e. <em>serious</em>)
+   ou supérieure quand ils envoient leur rapport au système de suivi des bogues.
+   Ceci assure qu'un paquet source unique permet de produire un paquet binaire
+   pour chaque architecture supportée au moment de la sortie de la distribution.
+   Il est très important d'avoir un paquet source et un paquet binaire pour
+   toutes les architectures pour être conforme à plusieurs licences.
+<p>
+Les porteurs doivent éviter d'implémenter des contournements pour des bogues de
+   l'environnement de compilation, du noyau ou de la libc. Quelques fois, ces
+   contournements sont inévitables. Si vous devez faire quelque chose de ce
+   genre, marquez proprement vos modifications avec des <tt>#ifdef</tt> et
+   documentez votre contournement pour que l'on sache le retirer une fois que le
+   problème aura disparu.
+<p>
+Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur
+   travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent
+   bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces
+   adresses n'ont rien d'officiel, alors soyez sur vos gardes si vous les
+   utilisez.
+
+
+      <sect1 id="porter-automation">
+          <heading>Infrastructure de portage et automatisation</heading>
+          <p>
+Il existe une infrastructure et plusieurs outils pour faciliter l'automatisation
+du portage des paquets. Cette section contient un bref aperçu de cette
+automatisation et du portage de ces outils&nbsp;; veuillez vous reporter à la
+documentation des paquets ou les références pour une information complète.</p>
+
+          <sect2>
+            <heading>Listes de diffusion et pages web</heading>
+            <p>
+Les pages web contenant l'état de chaque portage peuvent être trouvées à <url
+id="&url-debian-ports;">.
+            <p>
+Chaque portage de Debian possède sa propre liste de diffusion. La liste des
+listes de diffusion de portage peut être trouvée à <url
+id="&url-debian-port-lists;">. Ces listes sont utilisées pour coordonner les
+porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les
+porteurs.</p>
+          </sect2>
+
+      <sect2>
+           <heading>Outils pour les porteurs</heading>
+<p>
+Les descriptions de plusieurs outils de portage peuvent être trouvés dans les
+<ref id="tools-porting">.</p>
+
+
+       <sect2 id="buildd">
+           <heading><package>buildd</package></heading>
+<p>
+Le système <package>buildd</package> est un système distribué pour la
+   compilation d'une distribution. Il est habituellement utilisé en conjonction
+   avec des automates de compilation&nbsp;; ce sont des machines
+   «&nbsp;esclaves&nbsp;» qui récupèrent des paquets sources et tentent de les
+   compiler. Il est aussi possible d'interagir par courrier électronique avec ce
+   système. Cette interface est utilisée par les porteurs pour récupérer un
+   paquet source (en général, un paquet qui ne peut être compilé
+   automatiquement) et travailler dessus.
 <p>
+<package>buildd</package> n'est pas disponible sous forme de paquet&nbsp;;
+   pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont
+   prévu de l'utiliser bientôt. L'outil de construction automatisé réel est dans
+   le paquet <package>sbuild</package>, voir la description dans <ref
+   id="sbuild">. Le système <package>buildd</package> regroupe également un
+   ensemble de composants très utiles, continuellement utilisés, mais non encore
+   mis en paquet, tels que <prgn>andrea</prgn> et <prgn>wanna-build</prgn>.
+<p>
+Une partie des informations produites par <package>buildd</package> &mdash;
+   utiles pour les porteurs &mdash; est disponible sur la toile à l'adresse <url
+   id="&url-buildd;">. Ces informations incluent les résultats produits toutes
+   les nuits par <prgn>andrea</prgn> (dépendances des sources) et
+   <prgn>quinn-diff</prgn> (paquets à recompiler).
+<p>
+Nous sommes très fiers de ce système car il a de nombreux usages potentiels. Des
+   groupes de développeurs indépendants peuvent utiliser ce système pour créer
+   différentes saveurs de Debian &mdash; qui peuvent être ou ne pas être
+   intéressantes pour tous (par exemple, une version de Debian compilée avec des
+   vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
+   de recompiler rapidement toute une distribution.
+</sect2>
+
+
+    <sect id="collaborative-maint">
+        Maintenance collaborative
+<p>
+«&nbsp;Maintenance collaborative&nbsp;» est un terme décrivant le partage des
+ devoirs de la maintenance d'un paquet Debian par plusieurs personnes. Cette
+ collaboration est presque toujours une bonne idée car il en résulte
+ généralement une meilleure qualité et un temps de correction de bogues plus
+ petit. Il est fortement recommandé que les paquets de priorité
+ <tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
+<p>
+Habituellement, il y a un responsable principal et un ou plusieurs
+ co-responsables. Le responsable principal est celui dont le nom est indiqué
+ dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
+ co-responsables sont tous les autres responsables.
+<p>
+Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
+ simple&nbsp;:
+<list>
+<item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
+      construisez le paquet. Habituellement, cela implique que vous utilisiez un
+      système de contrôle de version comme <prgn>CVS</prgn> ou
+      <prgn>Subversion</prgn>.
+</item>
+<item><p> Ajouter les nom et adresse correctes du co-responsable au champ
+      <tt>Uploaders</tt> dans la partie globale du fichier
+      <file>debian/control</file>.
 <example>
-# Synthèse hebdomadaire des rapports de bogue qui me concernent
-&cron-bug-report;
+Uploaders: John Buzz &lt;jbuzz@debian.org&gt;, Adam Rex &lt;arex@debian.org&gt;
 </example>
-
-<p>
-Remplacez <var>address</var> par votre adresse officielle de responsable
-Debian.
+</item>
+<item><p>
+      En utilisant le PTS (<ref id="pkg-tracking-system">), les
+      co-responsables devraient s'inscrire eux-mêmes aux paquets sources
+      appropriés.
+</item>
+</list>
 
 
-
-
-       <sect id="submit-bug">Ouvrir un rapport de bogue
-
+    <sect id="archive-manip">
+      <heading>Déplacer, effacer, changer de nom, adopter et abandonner des paquets
 <p>
-En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets
-En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets,
-ou bien vous voulez réassigner à d'autres paquets des rapports de bogue 
-concernant vos paquets. La page d'aide du <url id="&url-bts-control;"
-name="système de suivi des bogues"> vous explique comment procéder.
+Certaines manipulations de l'archive ne sont pas accessibles avec le processus
+      de mise à jour automatisé. Elles sont appliquées manuellement par les
+      développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
 
+      <sect1 id="moving-pkgs">Déplacer des paquets
 <p>
-Nous vous encourageons à ouvrir des rapports de bogue s'il y a des problèmes.
-Essayez de soumettre ces rapports depuis un compte utilisateur où vous pouvez
-recevoir du courrier. Ne les envoyez pas en tant que <em>root</em>.
-
+Parfois, un paquet pourra changer de section. Une nouvelle version d'un paquet
+ de la section <tt>non-free</tt> pourrait, par exemple, être distribuée sous
+ licence GNU GPL&nbsp;; dans ce cas, le paquet doit être déplacé dans la section
+ <tt>main</tt> ou <tt>contrib</tt><footnote><p>Reportez-vous à la <url
+ id="&url-debian-policy;" name="charte Debian"> pour savoir dans quelle section
+ un paquet doit être classé.</footnote>.
 <p>
-Vérifiez que le bogue n'a pas encore été déclaré. Essayez de faire un travail
-propre en déclarant le bogue et en l'envoyant à la bonne adresse.
-
+Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez les
+ informations de contrôle du paquet pour le placer dans la section désirée et
+ téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
+ id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
+ nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
+ le cas, contactez les ftpmasters pour comprendre ce qui s'est passé.
 <p>
-Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les
-bogues qui ont été rapportés plusieurs fois ou affecter la gravité
-<em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été
-corrigé.  Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le
-responsable du paquet vous ne devez pas clore le rapport (à moins que vous
-n'ayez l'autorisation du responsable).
-
-
-
-
-       <sect>Répondre à des rapports de bogues
-
+Si vous avez besoin de modifier la sous-section de l'un de vos paquets
+ (<tt>devel</tt> ou <tt>admin</tt> par exemple), la procédure est légèrement
+ différente. Modifiez la sous-section dans le fichier de contrôle de votre
+ paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
+ fichier <em>override</em> comme décrit dans la section <ref
+ id="override-file">.
+
+
+      <sect1 id="removing-pkgs">Supprimer des paquets
+<p>
+Si, pour une raison ou une autre, vous avez besoin de supprimer un paquet de
+ l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile, que
+ l'on conservait pour des raisons de compatibilité), il vous faudra envoyer un
+ rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
+ demander sa suppression. N'oubliez pas de préciser de quelle distribution le
+ paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
+ des paquets de <em>unstable</em> ou de <em>experimental</em>. Les paquets de
+ <em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
+ automatiquement après que le paquet a été supprimé de <em>unstable</em> et
+ si aucun paquet de <em>testing</em> n'en dépend.
+<p>
+Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
+ but d'éviter les suppressions non désirées et de garder une trace de la raison
+ pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
+ du paquet qui remplace celui à supprimer.
+<p>
+Vous ne pouvez demander la suppression d'un paquet que si vous en
+ êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
+ obtenir l'accord de son dernier responsable.
 <p>
-Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au
-rapporteur du bogue et au bogue lui-même (<email>123@bugs.debian.org</email>
-par exemple).
-
+Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
+ autres développeurs sur la liste &email-debian-devel;. Le programme
+ <prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
+ utile. La commande <tt>apt-cache showpkg <var>paquet</var> </tt> vous
+ indiquera, entre autres, les paquets qui dépendent de <var>paquet</var>.
+<p>
+Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
+ Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
+ évolué en un autre paquet (par exemple, <tt>libfoo12</tt> a été supprimé parce
+ que <tt>libfoo13</tt> le remplace) ou ils sont fermés si le logiciel ne fait
+ simplement plus partie de Debian.
+
+       <sect2>Supprimer des paquets dans <tt>Incoming</tt>
+<p>
+Par le passé, il était possible de supprimer un paquet de <file>Incoming</file>.
+   Cependant, ce n'est plus possible depuis la mise en place du nouveau système
+   de file d'attente. Il vous faudra télécharger une nouvelle version de votre
+   paquet avec un numéro de version postérieur à celui que vous voulez
+   remplacer. Les deux versions seront installées dans l'archive mais seule la
+   plus récente sera accessible dans <em>unstable</em> car la précédente sera
+   immédiatement remplacée par la nouvelle. Toutefois, si vous testez
+   correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
+   trop fréquent.
+
+      <sect1>Remplacer un paquet ou changer son nom
+<p>
+Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de 
+ changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
+ votre fichier <file>debian/control</file> pour que votre nouveau paquet
+ remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
+ (Reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
+ les détails). Une fois que votre paquet est installé dans l'archive, faites un
+ rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
+ demandant la suppression du paquet mal nommé. N'oubliez pas de réattribuer
+ correctement les bogues du paquet en même temps.
+<p>
+D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
+ désirez le remplacer. La seule façon de faire est d'incrémenter le numéro
+ de version et d'envoyer une nouvelle version. L'ancienne version expirera de la
+ façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
+ compris les sources&nbsp;: si vous désirez remplacer l'archive source amont de
+ votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
+ possibilité simple est de remplacer <file>foo_1.00.orig.tar.gz</file> par
+ <file>foo_1.00+0.orig.tar.gz</file>. Cette restriction donne à chaque fichier
+ du site ftp un nom unique ce qui garantit la consistance dans le réseau des
+ miroirs.
+
+      <sect1 id="orphaning">Abandonner un paquet
+<p>
+Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres et
+ faire le nécessaire pour qu'il soit marqué <em>abandonné</em> (i.e.
+ <em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
+ Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et
+ faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>. Le
+ titre de votre rapport de bogue devrait être
+ «&nbsp;<tt>O<footnote><p><em>Orphaned</em>&nbsp;: abandonné.</footnote>:
+ <var>paquet</var> &mdash; <var>courte description</var></tt>&nbsp;» pour
+ indiquer que le paquet est abandonné. La gravité du bogue sera
+ <em>normale</em>. Si vous le jugez nécessaire, envoyez une copie à
+ &email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
+ l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le sujet
+ du message ne contiendra pas le numéro du bogue.
+<p>
+Si le paquet est particulièrement important pour la distribution, il vous faudra
+ faire un rapport de bogue sur le pseudo-paquet <package>wnpp</package>,
+ l'intituler «&nbsp;<tt>RFA<footnote><p><em>Request For Adoption</em>&nbsp;:
+ offre d'adoption.</footnote>: <var>paquet</var> &mdash; <var>courte
+ description</var></tt>&nbsp;» et lui affecter la gravité <em>importante</em>.
+ Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
+ décrit ci-dessus.
+<p>
+Reportez-vous à la page WNPP<footnote><p><em>Work-needing and prospective
+ packages</em>&nbsp;: paquets en souffrance et paquets souhaités.</footnote>
+ <url id="&url-wnpp;"> pour en savoir plus.
+
+      <sect1 id="adopting">Adopter un paquet
+<p>
+Une liste des paquets en attente de nouveau responsable est disponible à la page
+ <url id="&url-wnpp;" name="paquets en souffrance et paquets souhaités">. Si
+ vous voulez prendre en charge un paquet de cette liste, reportez-vous à la page
+ mentionnée ci-dessus pour connaître la procédure à suivre.
 <p>
-Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la
-commande <em>close</em> à l'adresse&nbsp;:
-
+Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
+ correct &mdash; ce serait un détournement de paquet. Vous pouvez prendre
+ contact avec le responsable actuel et lui demander si vous pouvez prendre en
+ charge ce paquet. Vous ne pouvez le faire sans son accord. Qu'il vous ignore
+ n'est pas une raison suffisante pour le faire. Si vous avez le sentiment qu'un
+ responsable est parti sans prévenir depuis un moment, demandez-le sur la liste
+ &email-debian-private;. Vous pouvez également informer le groupe QA (cf. <ref
+ id="mia-qa">).
+<p>
+Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de suivi
+ des bogues indique que vous êtes le responsable du paquet. Cela se produira
+ automatiquement une fois que vous aurez installé une nouvelle version du paquet
+ dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut prendre
+ quelques heures après le téléchargement. Si vous pensez ne pas avoir de mise à
+ jour à faire pour un moment, vous pouvez utiliser <ref
+ id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
+ assurez-vous que cela ne pose aucun problème à l'ancien responsable de
+ continuer à recevoir les bogues durant ce temps.
+
+
+    <sect id="bug-handling">Gérer les bogues
+<p>
+Vous trouverez souvent, en tant que responsable de paquet, des bogues dans
+ d'autres paquets ou vous aurez des bogues rapportés sur vos paquets et qui
+ doivent être réattribués. Les <url id="&url-bts-control;" name="instructions du
+ BTS"> peuvent vous indiquer comment faire cela. Vous pouvez trouver plus
+ d'informations sur la façon de faire des rapports de bogue dans <ref
+ id="submit-bug">.
+
+      <sect1>Superviser les rapports de bogue
+<p>
+Si vous voulez être un bon responsable, consultez régulièrement la page du <url
+ id="&url-bts;" name="système de suivi des bogues">. Cette page contient tous
+ les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier avec
+ cette page&nbsp;: <tt>http://&bugs-host;/<var>yourlogin</var>@debian.org</tt>.
+<p>
+Les responsables interagissent avec le système de suivi des bogues en utilisant
+ l'adresse électronique <tt>&bugs-host;</tt>. Vous trouverez une documentation
+ sur les commandes disponibles à l'adresse <url id="&url-bts;"> ou, si vous avez
+ installé le paquet <package>doc-debian</package>, dans les fichiers locaux
+ &file-bts-docs;.
 <p>
-<tt>   &email-bts-control;</tt>
+Certains trouvent utile de recevoir régulièrement une synthèse des rapports de
+ bogues ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous
+ les rapports de bogue ouverts pour vos paquets, vous pouvez configurer
+ <prgn>cron</prgn> comme suit&nbsp;:
+<example>
+# Synthèse hebdomadaire des rapports de bogue qui me concernent &cron-bug-report;
+</example>
+Remplacez <var>address</var> par votre adresse officielle de responsable Debian.
 
+      <sect1 id="bug-answering">Répondre à des rapports de bogue
 <p>
-Si vous le faites, le rapporteur n'aura aucun retour sur la clôture de son
-rapport.
-
-
-
-
-       <sect id="upload-bugfix">Quand les rapports sont fermés par une
-       mise à jour
-
+Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au
+ rapporteur du bogue et au bogue lui-même (<email>123@bugs.debian.org</email>
+ par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
+ plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
+ <email>123-submitter@bugs.debian.org</email> pour contacter le rapporteur
+ <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut
+ dire que vous n'avez pas besoin d'envoyer une copie du courrier à
+ <email>123@bugs.debian.org</email>).
+<p>
+Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
+ corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
+ d'explication à <email>123-done@bugs.debian.org</email>. Si vous corrigez un
+ bogue en changeant et en envoyant une nouvelle versions du paquet, vous pouvez
+ fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">.
+<p>
+Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande
+ <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
+ n'aura aucune information sur la clôture de son rapport.
+
+      <sect1 id="bug-housekeeping">Gestion générale des bogues
+<p>
+En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
+ d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
+ bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi
+ des bogues pour les développeurs sont décrites dans la <url
+ id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">.
+ Les <url id="&url-bts-control;" name="instructions du BTS"> documentent les
+ opérations techniques du BTS, telles que comment remplir, réassigner, regrouper
+ et marquer des bogues. Cette section contient des lignes directrices pour gérer
+ vos propres bogues, définies à partir de l'expérience collective des
+ développeurs Debian.
+<p>
+Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres
+ paquet est l'une des «&nbsp;obligations civiques&nbsp;» du responsable,
+ reportez-vous à <ref id="submit-bug"> pour les détails. Cependant, gérer les
+ bogues de vos propres paquets est encore plus important.
+<p>
+Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de
+ bogue&nbsp;:
+<enumlist>
+  <item>
+        Décider si le rapport correspond à un bogue réel ou non. Parfois, les
+       utilisateurs exécutent simplement un programme de la mauvaise façon car
+       ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez
+       simplement le bogue avec assez d'informations pour laisser l'utilisateur
+       corriger son problème (donnez des indications vers la bonne
+       documentation et ainsi de suite). Si le rapport de bogue revient
+       régulièrement, vous devriez vous demander si la documentation est assez
+       bonne ou si le programme ne devrait pas détecter une mauvaise
+       utilisation pour donner un message d'erreur informatif. Il s'agit d'un
+       problème qui peut être présenté à l'auteur amont.
+        <p>
+        Si le rapporteur de bogue n'est pas d'accord avec votre décision de
+       fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un
+       accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez
+       marquer le bogue avec <tt>wontfix</tt> pour indiquer aux personnes que
+       le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas
+       acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision
+       par le comité technique en réattribuant le bogue à
+       <package>tech-ctte</package> (vous pouvez utiliser la commande
+       <tt>clone</tt> du BTS si vous désirez garder le bogue comme rapporté sur
+       votre paquet). Avant de faire cela, veuillez lire la <url
+       id="&url-tech-ctte;" name="procédure recommandée">.
+  </item>
+  <item>
+        Si le rapport de bogue est réel, mais est causé par un autre paquet,
+       réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
+       quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
+       &email-debian-devel; ou vous pouvez le réattribuer à
+       <package>debian-policy</package> pour les laisser décider dans quel
+       paquet est située l'erreur.
+        <p>
+        Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
+       corresponde à notre définition de gravité des bogues. C'est dû au
+       fait que les gens tendent à augmenter la gravité des bogues pour
+       s'assurer que leurs bogues seront corrigés rapidement. La gravité de
+        certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
+       quand le changement demandé est seulement d'ordre cosmétique.
+  </item>
+  <item>
+        Le rapporteur de bogue peut avoir oublié de fournir certaines
+       informations. Dans ce cas, vous devez lui demander les informations
+       nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
+       d'info) sur le bogue. De plus, si vous ne pouvez pas reproduire le
+       bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non
+       reproductible). Une personne qui arriverait à reproduire le bogue est
+       alors invitée à fournir plus d'informations sur la façon de le
+       reproduire. Après quelques mois, si cette information n'a été envoyée
+       par personne, le bogue peut être fermé.
+  </item>
+  <item>
+        Si le bogue est lié à l'empaquètement, vous devez simplement le
+       corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le
+       bogue avec <tt>help</tt> (aide). Vous pouvez également demander de
+       l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un
+       problème amont, vous devez faire suivre le rapport à l'auteur amont.
+       Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque
+       version si le bogue a été corrigé ou non. S'il a été corrigé, vous le
+       fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
+       les compétences nécessaires, vous pouvez préparer un correctif pour
+       corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous
+       d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt>
+       (correctif).
+  </item>
+  <item>
+        Si vous avez corrigé un bogue sur votre copie locale ou si un correctif
+       a été inclus dans le référentiel CVS, vous pouvez marquer le bogue avec
+       <tt>pending</tt> (en attente) pour informer que le bogue est corrigé et
+       qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt>
+       dans le <file>changelog</file>). C'est particulièrement utile si
+       plusieurs développeurs travaillent sur le même paquet.
+  </item>
+  <item>
+        Une fois que le paquet corrigé est disponible dans la distribution
+       <em>unstable</em>, vous pouvez fermer le bogue. Ceci peut être fait
+       automatiquement, pour cela, reportez-vous à <ref id="upload-bugfix">.
+  </item>
+</enumlist>
+
+      <sect1 id="bug-security">Gérer les bogues de sécurité
+<p>
+À cause de leur nature sensible, les bogues liés à la sécurité doivent être
+ soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
+ cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
+ aider les responsables ayant des problèmes de sécurité ou pour les corriger
+ elle-même, pour envoyer les annonces de sécurité et pour maintenir le site
+ security.debian.org.
+
+        <sect2 id="bug-security-you">Que faire si vous apprenez l'existence d'un
+        problème de sécurité&nbsp;?
+<p>
+Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
+   paquet Debian, que vous soyez ou non le responsable, regroupez les
+   informations pertinentes sur le problème et contactez rapidement l'équipe de
+   sécurité à &email-security-team;. Les informations utiles incluent, par
+   exemple&nbsp;:
+
+ <list compact>
+      <item>
+      les versions du paquet connues pour être affectées par le bogue. Vérifiez
+      chaque version présente dans les distributions maintenues par Debian ainsi
+      que dans <em>testing</em> et dans <em>unstable</em>,
+      </item>
+      <item>
+      la nature d'une solution si elle est disponible (Les correctifs sont
+      particulièrement utiles),
+      </item>
+      <item>
+      tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les
+      fichiers <file>.diff.gz</file> et <file>.dsc</file>),
+      </item>
+      <item>
+      toute information nécessaire pour l'annonce de sécurité (voir <ref
+      id="bug-security-advisories">).
+      </item>
+  </list>
+
+        <sect2 id="bug-security-confidentiality">Confidentialité
+<p>
+À la différence de la plupart des autres activités au sein de Debian, les
+   informations sur les problèmes de sécurité doivent parfois être gardées en
+   privé pour un certain temps. Cette décision dépend de la nature du problème
+   et de l'existence d'une solution correspondante et également s'il s'agit d'un
+   fait connu publiquement.
+<p>
+Il existe plusieurs façons pour un développeur de prendre connaissance d'un
+problème de sécurité&nbsp;:
+
+<list compact>
+      <item>
+      il le remarque sur un forum publique (liste de diffusion, site web, etc.),
+      </item>
+      <item>
+      quelqu'un remplit un rapport de bogue,
+      </item>
+      <item>
+      quelqu'un l'informe par courrier privé.
+      </item>
+</list>
+
+Dans les deux premiers cas, l'information est publique et il est important
+d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
+n'est peut-être pas une information publique. Dans ce cas, il existe quelques
+options possibles pour traiter le problème&nbsp;:
+
+<list>
+<item>
+      si le problème est trivial (comme des fichiers temporaires non sécurisés),
+      il n'y a pas besoin de garder le secret sur le problème et une correction
+      devrait être effectuée et diffusée,
+</item>
+<item>
+      si le problème est grave (exploitable à distance, possibilité d'accéder
+      aux privilèges d'administratation), il est préférable de partager cette
+      information avec d'autres vendeurs et de coordonner une diffusion.
+      L'équipe de sécurité garde des contacts avec les différentes organisations
+      et individus et peut prendre soin des actions à mener.
+</item>
+</list>
+
+<p>
+Dans tous les cas, si la personne qui indique le problème demande à ne pas
+diffuser l'information, cela devrait être respecté avec l'évidente exception
+d'informer l'équipe de sécurité (assurez-vous d'informer l'équipe de sécurité
+que l'information ne doit pas être révélée).
+
+<p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
+un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
+changelog et de diff sont publiques pour <em>unstable</em>.
+
+<p>Il existe deux raisons pour diffuser l'information même si le secret est
+demandé&nbsp;: le problème est connu depuis un certain temps ou le problème ou
+son exploitation est devenu public.
+
+        <sect2 id="bug-security-advisories">Annonces de sécurité
+<p>
+Les annonces de sécurité ne sont émises que pour la distribution actuelle
+   diffusée <em>stable</em>, pas pour <em>testing</em> ou <em>unstable</em>.
+   Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
+   &email-debian-security-announce; et elle est postée sur <url
+   id="&url-debian-security-advisories;" name="la page de sécurité">. Les
+   annonces de sécurité sont écrites et postées par l'équipe de sécurité.
+   Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
+   apporte des informations ou écrive une partie du texte. Les informations qui
+   devraient être présentes dans une annonce incluent&nbsp;:
+<list compact>
+<item>
+       une description du problème et de sa portée, y compris&nbsp;:
+        <list>
+       <item>
+               le type du problème (escalade de privilège, déni de service,
+                etc.),
+        </item>
+       <item>
+               comment il peut être exploité,
+        </item>
+       <item>
+               si le problème peut être exploité à distance ou localement,
+        </item>
+       <item>
+               comment le problème a été corrigé,
+        </item>
+       </list>
+</item>
+<item>
+       les numéros de version des paquets affectés,
+</item>
+<item>
+       les numéros de version des paquets corrigés,
+</item>
+<item>
+       une information sur la façon de récupérer les paquets mis à jour,
+</item>
+<item>
+       des références à des annonces amont, des identifiants <url
+        id="http://cve.mitre.org" name="CVE"> et toute autre information utile
+        pour recouper les références de la vulnérabilité.
+</item>
+</list>
+
+         <sect2 id="bug-security-building">
+            <heading>Préparer les paquets pour corriger des problèmes de sécurité
+<p>
+Une façon d'assister l'équipe de sécurité dans ses travaux est de fournir des
+  paquets corrigés convenables pour une annonce de sécurité pour la version
+  <em>stable</em> de Debian
+<p>
+Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
+  particulier doit être apporté pour éviter de modifier le comportement du
+  système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
+  changements possibles pour corriger le bogue. Les utilisateurs et les
+  administrateurs s'attendent à un comportement identique dans une version
+  lorsque celle-ci est effectuée, donc tout changement qui est fait est
+  susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
+  les bibliothèques&nbsp;: assurez-vous ne de jamais changer l'API ou l'ABI,
+  quelque minimal que soit le changement.
+<p>
+Cela veut dire que passer à une version amont supérieure n'est pas une bonne
+solution. À la place, les changements pertinents devraient être rétro-portés
+vers la version présente dans la distribution <em>stable</em> de Debian.
+Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de
+sécurité Debian peut le faire.
+<p>
+Dans certains cas, il n'est pas possible de rétro-porter un correctif de
+sécurité, par exemple, quand de grandes quantités de code source doivent être
+modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à
+une nouvelle version amont. Cependant, vous devez toujours coordonner cela avec
+l'équipe de sécurité au préalable.
+<p>
+Il existe une autre règle de conduite liée à cela&nbsp;: testez toujours vos
+changements. Si une exploitation du problème existe, essayez-là et
+vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
+corrigé. Testez aussi les autres actions normales car parfois un correctif de
+sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
+liées.
+<p>
+Examinez et testez autant que possible vos changements. Vérifiez les différences
+avec la version précédente de manière répétée (<prgn>interdiff</prgn> et
+<prgn>debdiff</prgn> sont des outils utiles pour cela). Lors de la construction
+de la correction, gardez les points suivants à l'esprit&nbsp;:
+
+<list>
+<item>
+      Assurez-vous que vous avez pour cible la bonne distribution dans votre
+      fichier <file>debian/changelog</file>. Pour <em>stable</em>, il s'agit de
+      <tt>stable-security</tt> et pour <em>testing</em>, c'est
+      <tt>testing-security</tt> et pour l'ancienne distribution stable, c'est
+      <tt>oldstable-security</tt>. Ne ciblez pas
+      <var>distribution</var>-proposed-updates&nbsp;!
+</item>
+<item>
+      Assurez-vous que le numéro de version est correct. Il doit être plus élevé
+      que celui du paquet actuel, mais moins que ceux des paquets des versions
+      des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
+      --compare-versions</tt>. Pour <em>testing</em>, il doit y avoir un numéro
+      de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
+      exemple, si <em>testing</em> et <em>unstable</em> ont la même version),
+      vous devez envoyer une nouvelle version vers <em>unstable</em> en premier.
+</item>
+<item>
+      Ne faites pas d'envoi de source seul si votre paquet possède un ou
+      plusieurs paquets binary-all (n'utilisez pas l'option <tt>-S</tt> de
+      <prgn>dpkg-buildpackage</prgn>). L'infrastructure <prgn>buildd</prgn> ne
+      construira pas ceux-ci. Ce point s'applique aux envois de paquets normaux
+      également.
+</item>
+<item>
+      Si la source amont a été envoyée auparavant à security.debian.org (par une
+      précédente mise à jour de sécurité), construisez le paquet sans la source
+      amont (<tt>dpkg-buildpackage -sd</tt>). Sinon, construisez-le avec le
+      source complet (<tt>dpkg-buildpackage -sa</tt>).
+</item>
+<item>
+      Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
+      que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
+      déplacer plus tard le correctif de sécurité dans l'archive principale.
+</item>
+<item>
+      Assurez-vous, lors de la compilation du paquet, de compiler sur un système
+      propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
+      construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
+      utiliser l'une des machines de debian.org (voir <ref
+      id="server-machines">) ou mettez en place un chroot (voir <ref id=
+      "pbuilder"> et <ref id="debootstrap">).
+</item>
+</list>
+
+      <sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
+<p>
+Vous <em>NE DEVEZ PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
+sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
+exactement les impératifs de l'équipe, il causera beaucoup de problèmes, ainsi
+que des délais dans la gestion de l'envoi indésirable.
+<p>
+Vous <em>NE DEVEZ PAS</em> envoyer votre correction dans
+<em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
+paquets seront copiés de security.debian.org dans le répertoire
+<file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
+de version ou un numéro plus grand est déjà installé dans l'archive, la mise à
+jour de sécurité sera rejetée par le système d'archive. Ainsi, la distribution
+<em>stable</em> se retrouvera à la place sans la mise à jour de sécurité de ce
+paquet.
+<p>
+Une fois que vous avez créé et testé le nouveau paquet et qu'il a été approuvé
+par l'équipe de sécurité, il doit être envoyé pour être installé dans les
+archives. Pour les envois de sécurité, l'adresse d'envoi est
+<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
+
+<p>
+Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
+automatiquement recompilé pour toutes les architectures et stocké pour
+vérification par l'équipe de sécurité.
+
+<p>
+Les envois en attente d'acceptation ou de vérification ne sont accessibles que
+par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
+correctifs pour des problèmes de sécurités qui ne peuvent pas encore être
+diffusés.
+
+<p>
+Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
+security.debian.org ainsi que dans le répertoire
+<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
+l'archive non-US.
+
+      <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
+      une mise à jour&nbsp;?
 <p>
 Si vous corrigez un bogue dans vos paquets, il est de votre responsabilité de
-fermer le rapport de bogue associé. Pourtant vous ne devez pas le fermer avant
-que le paquet n'ait été accepté dans l'archive Debian.  C'est pourquoi, vous
-pouvez et vous devez clore le rapport dans le système de suivi des bogues une
-fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été
-installé dans l'archive.
-
-<p>
-Si vous utilisez une version récente de <package>dpkg-dev</package> et que
-vous remplissez convenablement le fichier <file>changelog</file>, le logiciel de
-maintenance de l'archive fermera les rapports de bogue automatiquement. Tout ce
-que vous avez à faire est de respecter la syntaxe suivante dans votre fichier
-<file>debian/changelog</file>&nbsp;:
+ fermer le rapport de bogue associé. Cependant, vous ne devez pas le fermer
+ avant que le paquet n'ait été accepté dans l'archive Debian. C'est pourquoi,
+ vous pouvez et vous devez clore le rapport dans le système de suivi des bogues
+ une fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été
+ installé dans l'archive.
+<p>
+Cependant, il est possible d'éviter d'avoir à fermer manuellement les bogues
+ après l'envoi &mdash; indiquez simplement les bogues corrigés dans le fichier
+ <file>changelog</file> en suivant une syntaxe précise. Par exemple&nbsp;:
+
 <example>
 acme-cannon (3.1415) unstable; urgency=low
 
   * Frobbed with options (closes: Bug#98339)
   * Added safety to prevent operator dismemberment, closes: bug#98765,
     bug#98713, #98714.
-  * Added manpage. Closes: #98725.
+  * Added man page. Closes: #98725.
 </example>
 
-Techniquement parlant, l'expression régulière suivante est utilisée :
+Techniquement parlant, l'expression régulière suivante Perl est utilisée :
+
 <example>
   /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
 </example>
 
-L'auteur préfère la syntaxe <tt>(closes: Bug#<var>XXX</var>)</tt>, car elle
-est facilement repérable dans le fichier <file>changelog</file>.
-
+L'auteur préfère la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'une
+des plus concises et des plus faciles à intégrer dans le texte du fichier
+<file>changelog</file>.
 <p>
-Si vous voulez fermer un rapport de bogue manuellement &mdash; à l'ancienne &mdash; il
-suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse
-<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
-bogue.
-
-
+Si vous entrez un numéro de bogue incorrect ou si vous en oubliez un dans le
+ fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage que
+ l'erreur a entrainé. Pour réouvrir un bogue fermé par erreur, envoyez une
+ commande <tt>reopen <var>XXX</var></tt> au robot de contrôle du système de
+ suivi des bogues. Pour fermer tous les bogues restants qui ont été corrigés par
+ votre envoi, envoyez le fichier <file>.changes</file> à
+ <email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
+ bogue.
+<p>
+Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le
+ <file>changelog</file> tel que décrit ci-dessus &mdash; si vous désirez
+ simplement fermer les bogues qui n'ont rien à voir avec l'un de vos envois,
+ faites-le simplement en envoyant une explication à
+ <email>XXX-done@bugs.debian.org</email>.
+
+  <chapt id="best-pkging-practices">
+    <heading>Les meilleurs pratiques pour la construction des paquets
+<p>
+La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
+name="charte Debian"> qui définit explicitement les obligations que tous les
+paquets doivent suivre. Mais c'est également grâce à une histoire partagée
+d'expériences qui va au-delà de la charte Debian, une accumulation d'années
+d'expérience pour la construction des paquets&nbsp;; des développeurs de grand
+talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
+créer et maintenir d'excellents paquets.
+
+<p>
+Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne
+sont que des recommandations, non pas des obligations ou des règles. Ce sont
+seulement des astuces et conseils subjectifs et des liens collectés pour les
+développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
+
+    <sect id="bpp-debian-rules">
+        <heading>Les meilleures pratiques pour le fichier <file>debian/rules</file></heading>
+        <p>
+Les recommandations suivantes s'appliquent au fichier <file>debian/rules</file>.
+Comme ce fichier contrôle le processus de compilation et qu'il sélectionne les
+fichiers inclus dans le paquet (directement ou indirectement), il s'agit
+habituellement du fichier sur lequel les responsables passent le plus de temps.
+
+
+       <sect1 id="helper-scripts">Scripts d'aide
+<p>
+La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
+<file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
+partager une logique commune pour un grand nombre de paquets. Prenez, par
+exemple, l'installation des entrées de menu&nbsp;: vous avez besoin de
+placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
+scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
+Comme il s'agit d'une chose très commune, pourquoi chaque
+responsable devrait-il écrire sa propre version, parfois avec des bogues&nbsp;?
+Supposons également que le répertoire de menu soit modifié, chaque paquet
+devrait être modifié.
+<p>
+Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous
+conformiez aux conventions attendues par le script d'aide, celui-ci prend soin
+de tous les détails. Les changements dans la charte peuvent alors être faits
+dans le script d'aide, les paquets ont alors simplement besoin d'être
+reconstruits avec la nouvelle version du script et sans aucun changement
+supplémentaire.
+<p>
+L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
+courant et le meilleur (à notre avis) système est <package>debhelper</package>.
+Les précédents systèmes d'aide comme <package>debmake</package> étaient
+«&nbsp;monolithiques&nbsp;»&nbsp;: vous ne pouviez pas choisir quelles parties
+intéressantes vous pouviez utiliser, mais vous êtiez obligé de choisir le
+système pour tout faire. <package>debhelper</package>, à l'inverse, consiste en
+un certain nombre de petits programmes <prgn>dh_*</prgn>. Par exemple,
+<prgn>dh_installman</prgn> installe et compresse les pages de manuel,
+<prgn>dh_installmenu</prgn> installe les fichiers de menu et ainsi de suite.
+Ainsi, il offre une flexibilité suffisante pour pouvoir utiliser les scripts
+d'aide quand ils sont utiles, en complément de commandes définies manuellement
+dans le fichier <file>debian/rules</file>.
+<p>
+Vous pouvez débuter avec <package>debhelper</package> par lire <manref
+name="debhelper" section="1"> et en regardant les exemples fournis avec le
+paquet. <prgn>dh_make</prgn> du paquet <package>dh-make</package> (voir <ref
+id="dh-make">) peut être utilisé pour convertir un paquet source
+«&nbsp;vierge&nbsp;» en une version utilisant <package>debhelper</package>. Ce
+raccourci ne devrait cependant pas vous faire croire que vous n'avez pas besoin
+de comprendre les scripts individuels <prgn>dh_*</prgn>). Si vous comptez
+utiliser un système d'aide, vous devez prendre le temps d'apprendre à utiliser
+ce système pour savoir ce que vous pouvez en attendre ainsi que son
+comportement.
+<p>
+Plusieurs personnes pensent que des fichiers <file>debian/rules</file> vierges
+sont préférables car vous n'avez pas à apprendre les détails internes d'un
+quelconque système d'aide. La décision vous appartient complètement. Utilisez ce
+qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
+disponibles à <url id="&url-rules-files;">.
+
+<!-- Pour vous aider dans votre effort d'empaquètement, vous pouvez
+ utiliser les scripts d'aide. Les meilleurs scripts disponibles sont fournis
+ par <package>debhelper</package>. Avec <prgn>dh_make</prgn> (paquet
+ <package>dh-make</package>), vous pouvez générer en quelques secondes un
+ paquet qui est presque prêt. Cependant, cette apparente simplicité cache un
+ grand nombre de choses faites par les scripts d'aide. Vous devez savoir ce
+ qu'ils font, c'est pourquoi vous êtes fortement encouragé à lire les pages de
+ manuel correspondantes, en commençant par <manref section="1" name="debhelper">. C'est
+ nécessaire parce que vous devez comprendre ce qui se passe pour être capable
+ de les utiliser sagement et pour pouvoir corriger des bogues de manière
+ élégante.
+<p>
+debhelper est très utile car il vous permet de suivre la plus récente
+ charte Debian sans faire beaucoup de modifications car les changements qui
+ peuvent être automatisés sont presque toujours faits automatiquement par un
+ script debhelper. De plus, il offre suffisamment de flexibilité pour que vous
+ soyez capable de l'utiliser en conjonction avec des invocations de shell
+ écrites à la main à l'intérieur du fichier <file>rules</file>.
+<p>
+Vous pouvez cependant décider de ne pas utiliser de script d'aide et
+ tout de même écrire d'excellents fichiers <file>rules</file>. Plusieurs
+ exemples sont disponibles à <url id="&url-rules-files;">.
 
+ -->
+       <sect1 id="multiple-patches">
+         <heading>Appliquer des correctifs sur les sources ou appliquer des
+         correctifs lors de la construction&nbsp;?</heading>
+<p>
+Les gros paquets peuvent avoir plusieurs bogues que vous devez corriger.
+ Si vous corrigez sans faire attention les bogues dans les 
+sources, 
+ vous ne pourrez pas différencier facilement les
+ nombreux correctifs que vous aurez appliqués. Cela peut devenir trés 
+compliqué de mettre à jour le paquet avec une nouvelle version amont qui
+ intègre certains correctifs (mais pas tous). Vous ne pouvez pas prendre
+ l'ensemble des correctifs (par exemple, dans les fichiers <file>.diff.gz</file>) et
+ décider quels correctifs il vous faut enlever parceque les bogues ont été
+ corrigés en amont.
+<p>
+Une bonne solution est de conserver des correctifs séparés sous le répertoire
+ <file>debian</file> et de les appliquer lors de la compilation. Le paquet
+ <package>dbs</package> fournit un moyen pratique pour appliquer ces correctifs
+ lors de la compilation (et de les enlever lors du nettoyage). Le paquet
+ <package>dbs</package> fournit également des facilités pour créer des
+ correctifs et garder une trace de leur utilité. Comme toujours lorsque vous
+ utilisez des outils des maintenance, vous devez lire la documentation
+ associée. Le paquet <package>hello-dbs</package> est un exemple simple qui
+ présente comment utiliser <package>dbs</package>.
+<p>
+
+       <sect1 id="multiple-binary">Paquets binaires multiples
+<p>
+Un simple paquet source va souvent permettre de construire plusieurs paquets
+ binaires différents, que ce soit pour fournir plusieurs saveurs du même
+ paquet (par exemple, les différents paquets <package>vim-*</package>) ou pour
+ créer plusieurs petits paquets au lieu d'un seul gros (par exemple, si
+ l'utilisateur peut installer que la partie dont il a besoin et ainsi
+ économiser de l'espace disque).
+<p>
+Le second cas peut facilement être géré dans le fichier
+ <file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
+ appropriés du répertoire de construction dans les arborescence temporaires du
+ paquet. Vous pouvez le faire en utilisant <prgn>install</prgn> (approche
+ vierge) ou <prgn>dh_install</prgn> (du <package>debhelper</package>).
+ Assurez-vous de vérifier les différentes permutations de paquets, en
+ garantissant que vous avez bien défini les dépendances entre les paquets dans
+ le fichier <file>debian/control</file>.
+<p>
+Le premier cas est un peu plus diffile car il implique de multiples
+ recompilations du même logiciel, mais avec différentes options de
+ configuration. Le paquet <package>vim</package> est un exemple de la façon de
+ gérer cela avec un fichier rules écrit à la main.
+
+<!-- &FIXME; Find a good debhelper example with multile configure/make cycles
+     -->
+</sect1>
+
+    <sect id="bpp-debian-maint-scripts">
+        <heading>Les meilleures pratiques pour les scripts de
+        maintenance</heading>
+        <p>
+Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
+<file>debian/preinst</file>, <file>debian/prerm</file> et
+<file>debian/postrm</file>. Ces scripts prennent soin de la configuration
+d'installation ou de désinstallation des paquets, ce qui n'est pas simplement créer ou 
++supprimer des fichiers et des répertoires. Les instructions suivantes
+complètent la <url id="&url-debian-policy;" name="charte Debian">.
+        <p>
+Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
+devez vous assurer que rien de grave ne se produit si un script est appelé deux
+fois là où il ne devrait habituellement être appelé qu'une fois.
+        <p>
+Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
+tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
+d'activité, donc vous ne devez pas supposer que ce sont des tty.
+        <p>
+Tous les affichages et les configurations interactives devraient être
+minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
+<package>debconf</package> pour l'interface. Rappelez-vous que, dans tous les
+cas, l'affichage ne doit se faire que dans l'étape de configuration,
+<tt>configure</tt> du script de post-installation, <file>postinst</file>.
+        <p>
+Gardez les scripts de maintenance aussi simples que possible. Nous vous
+suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
+avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
+l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
+Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
+parties aux scripts.
+        <p>
+Si vous modifiez les scripts de maintenance, assurez-vous de tester la
+suppression du paquet, la double installation et la purge complète. Assurez-vous
+qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
+tout fichier créé, directement ou indirectement, par les scripts de
+maintenance.
+        <p>
+Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
+utiliser quelque chose comme&nbsp;:
+<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
+
+Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
+maintenance, la fonction de shell suivante conforme à POSIX peut vous
+aider&nbsp;:
+
+&example-pathfind;
+
+Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
+nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
+trouvé et faux sinon. Il s'agit réellement de la façon la plus portable de faire
+car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
+POSIX. Bien que <prgn>which</prgn> soit une alternative acceptable car il est
+présent dans le paquet classé <em>required</em><package>debianutils</package>, il n'est pas
+présent dans la partition racine&nbsp;; mais cela ne posera sans doute pas de
+problème.
+
+
+    <sect id="bpp-debian-control">
+       <heading>Les meilleures pratiques pour le fichier
+       <file>debian/control</file></heading>
+        <p>
+Les pratiques suivantes viennent en complément de la <url
+            id="&url-debian-policy;ch-miscellaneous.html#s-descriptions"
+            name="règles pour les descriptions de paquet">.</p>
+
+       <sect1 id="bpp-pkg-desc">
+           <heading>Écrire des descriptions utiles</heading>
+<p>
+La description du paquet (telle qu'elle est définie dans le champ correspondant
+     du fichier <file>control</file>) est habituellement la première
+     information dont dispose l'utilisateur avant d'installer un paquet. Aussi,
+     elle devrait fournir toutes les informations nécessaires pour le laisser
+     décider de l'installation du paquet.
+<p>
+Pour des raisons de cohérence et d'esthétique, vous devriez mettre en
+     majuscule la première lettre du résumé de la description. Ne mettez pas 
+de point à la fin. La description elle-même devrait n'être constituée
+     que de phrases entières.
+<p>
+Enfin, comme la première impression de l'utilisateur est basée sur cette
+     description, vous devriez éviter les fautes d'orthographe et de grammaire.
+     N'oubliez pas votre vérificateur orthographique.
+     <prgn>ispell</prgn> possède une option spéciale (<tt>-g</tt>) pour
+     cela&nbsp;: <example>ispell -d american -g debian/control</example>. Si
+     vous voulez qu'une personne relise la description que vous avez l'intention
+     d'utiliser, vous pouvez le demander sur &email-debian-l10n-english;.
+        </sect1>
+
+        <sect1 id="bpp-upstream-info">
+          <heading>Page d'accueil amont</heading>
+          <p>
+Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
+description du paquet dans le fichier <file>debian/control</file>. Cette
+information devrait être ajoutée à la fin de la description en utilisant le
+format suivant&nbsp;:
+
+<example> .
+  Homepage: http://some-project.some-place.org/</example>
+
+Veuillez noter les espaces au début de la ligne, ils servent à séparer les
+lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
+reporter à <url id="&url-eg-desc-upstream-info;">.
+          <p>
+Ne mettez rien s'il n'existe pas de page pour le logiciel.
+
+          <p>
+Veuillez noter que nous espérons que ce champ sera remplacé par un
+vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
+et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à mettre la
+page d'accueil de la description dans ce nouveau champ, vous devriez
+probablement attendre qu'il soit disponible.</p>
+        </sect1>
+      </sect>
+
+<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
+       <p>
+       &FIXME; presentation of cvs-buildpackage, updating sources
+       via CVS (debian/rules refresh).
+-->
 
-       <sect id="lintian-reports">Les rapports Lintian
 
+      <sect id="bpp-config-mgmt">
+       <heading>Gestion de la configuration avec <package>debconf</package></heading>
+       
+       <p>
 <p>
-Vous devriez récupérer la dernière version de <package>lintian</package>
-depuis <em>unstable</em> régulièrement et vérifier tous vos paquets. Vous
-pouvez aussi chercher votre adresse électronique dans la page de <url
-id="&url-lintian;" name="rapport lintian">. Cette page, mise à jour
-automatiquement, contient les rapports lintian concernant la
-dernière version de la distribution (en général <em>unstable</em>) générés
-avec la dernière version de <package>lintian</package>.
+<package>Debconf</package> est un système de gestion de configuration qui
+ peut être utilisé par les divers scripts de maintenance (principalement
+ en post-installation dans le fichier <file>postinst</file>) pour demander à
+l'utilisateur des informations concernant la configuration du paquet. Il 
+faut maintenant éviter les interactions directes avec l'utilisateur et 
+préférer les interactions utilisant <package>debconf</package>. Ceci permettra
+ à l'avenir des installations non interactives. <!-- pas de trait d'union
+entre non et adjectif -->
+       <p>
+Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
+ communes sont référencées dans la page de manuel <manref section="8"
+ name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
+ d'utiliser debconf.
+      </sect>
+
+
+      <sect id="bpp-i18n">
+        <heading>Internationalisation</heading>
+
+
+
+       <sect1 id="bpp-i18n-debconf">Gestion des traductions de
+       debconf
+<p>
+Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur
+ un grand nombre de paquets et doivent donc collaborer avec plusieurs
+ responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur
+ langue maternelle, il se peut que vous deviez être particulièrement patient
+ avec eux.
+<p>
+Le but de <package>debconf</package> était de faciliter la configuration des
+paquets aux responsables et aux utilisateurs. À l'origine, les
+traductions des questionnaires debconf étaient gérées avec
+<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
+déconseillée&nbsp;; la meilleure façon pour l'internationalisation de
+<package>debconf</package> est d'utiliser le paquet
+<package>po-debconf</package>. Cette méthode est plus facile et pour le
+responsable et pour les traducteurs&nbsp;; des scripts de transition sont
+fournis.
+<p>
+Lors de l'utilisation de <package>po-debconf</package>, la traduction est
+stockée dans des fichiers <file>po</file> (à l'instar des techniques de
+traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
+messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
+modifiez l'état d'un champ traduisible en appelant
+<prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
+l'attention des traducteurs. Puis, lors de la construction du paquet, le
+programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
+nécessaire à l'ajout du modèle avec les traductions à jour dans les paquets
+binaires. Veuillez vous reporter à la page de manuel <manref name="po-debconf"
+section="7"> pour les détails.
+        </sect1>
+
+        <sect1 id="bpp-i18n-docs">
+          <heading>Documentation traduite</heading>
+          <p>
+La traduction de la documentation est cruciale pour les utilisateurs, mais elle
+représente un important travail. Il n'existe aucun moyen d'éliminer ce travail,
+mais vous pouvez faciliter les choses pour les traducteurs.
+          <p>
+Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
+plus facile pour les traducteurs d'avoir accès à un système de contrôle de
+source. Ceci permet aux traducteurs de voir les différences entre deux versions
+de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
+d'être retraduit. Il est recommandé que le document traduit inclue une note à
+propos de la révision de contrôle du source sur laquelle la traduction est
+basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
+name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
+aperçu de l'état de la traduction pour une langue donnée, en utilisant les
+commentaires structurés pour une révision donnée du fichier à traduire et, pour
+un fichier traduit, la révision du fichier d'origine sur laquelle la traduction
+est basée. Vous pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
+          <p>
+Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
+d'isoler les informations indépendantes de la langue et de les définir
+comme des entités dans un fichier séparé qui sera inclus par les différentes
+traductions. Ceci aide, par exemple, à garder à jour les adresses pour
+plusieurs fichiers.
+        </sect1>
+      </sect>
+
+<!-- , ils ne peuvent pas garder la trace de chaque changement dans les paquets
+ pour être informé quand une chaîne de traduction n'est plus à jour.
+ Heureusement, <package>debconf</package> peut automatiquement indiquer les
+ traductions non à jour si les responsables de paquet suivent les quelques
+ lignes de conduites de base décrites ci-dessous.
+<p>
+Les traducteurs peuvent utiliser <prgn>debconf-getlang</prgn>
+ (paquet <package>debconf-utils</package>) pour écrire un fichier
+ <file>templates.xx</file> contenant à la fois les champs en anglais et
+ localisés (où <em>xx</em> est le code de langue, qui peut être suivi par un
+ code de pays). Ce fichier peut être placé dans le sous-répertoire
+ <file>debian</file> sans aucun changement.
+<p>
+Lors de la construction d'un paquet binaire, les fichiers
+ <file>debian/templates.xx</file> sont regroupés avec
+ <file>debian/templates</file> pour générer le fichier <file>templates</file>
+ qui contient le paquet binaire. Ceci est fait automatiquement par
+ <prgn>dh_installdebconf</prgn> (paquet <package>debhelper</package>). Si vous
+ n'utilisez pas debhelper, vous pouvez faire la même chose avec
+ <prgn>debconf-mergetemplate</prgn> (paquet
+ <package>debconf-utils</package>).
+<p>
+Quand le responsable du paquet a besoin de faire une mise à jour du
+  fichier de modèle, il n'a qu'à changer <file>debian/templates</file>. Quand
+  les chaînes en anglais de ce fichier et de <file>debian/templates.xx</file>
+  diffèrent, les traducteurs savent que leur traduction n'est plus à jour.
+<p>
+Veuillez vous reporter à la page sur les <url id="&url-debconf-l10n-help;"
+ name="fichiers templates debconf de localisation"> du site web Debian, elle
+ contient des instructions plus détaillées, y compris un exemple complet.
+ -->
 
+    <sect id="bpp-common-situations">
+       <heading>Pratiques d'empaquètement communes</heading>
 
+<!--
+       <sect1 id="bpp-kernel">Kernel modules/patches
+<p>
 
+       &FIXME; Heavy use of kernel-package. provide files in
+       /etc/modutils/ for module configuration.
+-->
 
+       <sect1 id="bpp-autotools">
+          <heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
+<p>
+Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file>
+et <file>config.guess</file>, est critique pour les porteurs, spécialement pour
+les architectures plus changeantes. De très bonnes pratiques d'empaquetage
+utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été regroupées
+dans &file-bpp-autotools; du paquet <package>autotools-dev</package>. Vous êtes
+vivement encouragé à lire ce fichier et à suivre les recommandations indiquées.
+
+
+       <sect1 id="bpp-libraries">Bibliothèques
+<p>
+Les bibliothèques ont toujours été difficiles à empaqueter pour diverses
+ raisons. La charte impose plusieurs contraintes pour faciliter la maintenance
+ et pour garantir que les mises à jour sont aussi simples que possible quand une
+ nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
+ rendre défectueux une douzaine de paquets qui en dépendent.
+<p>
+Les bonnes pratiques d'empaquètement des bibliothèques ont été regroupées dans
+ <url id="&url-libpkg-guide;" name="le guide d'empaquètement des
+ bibliothèques">.
+
+       <sect1 id="bpp-docs">Documentation
+          <p>
+Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html"
+name="règles sur la documentation">.</p>
+          <p>
+Si votre paquet contient de la documentation construite à partir de XML ou SGML,
+nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
+paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
+documentation, ils peuvent récupérer le paquet source.</p>
+          <p>
+La charte spécifie que la documentation doit être fournie au format HTML.
+Nous vous recommandons également de la fournir au format PDF et texte simple si
+c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
+généralement pas approprié de fournir des versions en texte simple pour la
+documentation dont le format source est du HTML.</p>
+          <p>
+Les principaux manuels fournis devraient être enregistrés par le paquet
+<package>doc-base</package> à l'installation. Reportez-vous à la documentation
+du paquet <package>doc-base</package> pour plus d'information.</p>
 
-       <sect>Ouvrir un grand nombre de rapports d'un seul coup
 
+       
+       <sect1 id="bpp-other">Types spécifiques de paquets
+<p>
+Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
+ règles et pratiques d'empaquètement correspondantes&nbsp;:
+<list>
+<item>
+      Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
+      Perl">, quelques exemples de paquets qui suivent cette charte sont
+      <package>libdbd-pg-perl</package> (module perl binaire) ou
+      <package>libmldbm-perl</package> (module perl indépendant de
+      l'architecture).
+</item>
+<item>
+      Les paquets liés à Python ont leur charte python&nbsp;; voir
+      &file-python-policy; dans le paquet <package>python</package>.
+</item>
+<item>
+      Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;"
+      name="charte Emacs">.
+</item>
+<item>
+      Les paquets liés à Java ont leur <url id="&url-java-policy;" name="charte
+      Java">.
+</item>
+<item>
+      Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
+      &file-ocaml-policy; du paquet <package>ocaml</package>. Un bon exemple est
+      le paquet source <package>camlzip</package>.
+</item>
+<item>
+      Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
+      recommandations que l'on peut trouver dans le paquet
+      <package>sgml-base-doc</package>
+<item>
+      Les paquets Lisp devraient s'enregistrer avec le paquet
+      <package>common-lisp-controller</package> pour lequel vous pouvez vous
+      reporter à &file-lisp-controller;.
+</list>
+
+  </sect1>
+</sect>
+
+  <chapt id="beyond-pkging">
+    <heading>Au-delà de l'empaquètement
+<p>
+Debian, c'est beaucoup plus que de l'empaquètement de logiciels et de
+    la maintenance de paquets. Ce chapitre contient des informations sur les
+    façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
+    simple création et maintenance de paquets.
+<p>
+En tant qu'organisation de volontaires, Debian repose sur la liberté de 
+    choisir ce sur quoi l'on désire travailler et de choisir la
+    partie la plus importante à laquelle on veut consacrer son temps.
+
+    <sect id="submit-bug">
+        <heading>Rapporter des bogues
+<p>
+Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
+ bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
+ les testeurs de première ligne. Trouver et rapporter les bogues dans les
+ paquets d'autres développeurs améliore la qualité de Debian.
+<p>
+Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel vous
+ pouvez recevoir des courriers. Ne soumettez pas de bogues en tant
+ que root.
+<p>
+Assurez-vous que le bogue n'a pas déjà été rapporté. Essayez de
+ faire du bon boulot quand vous rapportez le bogue et indiquez l'emplacement
+ exact. Vous pouvez également parcourir les bogues d'autres paquets, en les
+ regroupant s'ils sont indiqués plus d'une fois, ou en modifiant la gravité d'un
+ bogue à «&nbsp;fixed&nbsp;» quand ils ont déjà été corrigés. Notez cependant
+ que si vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous
+ ne devriez pas fermer réellement le bogue (à moins que vous n'ayez la
+ permission sécurisée du responsable).
+<p>
+De temps en temps, vous pourrez vouloir vérifier ce qui s'est passé à propos des
+ bogues que vous avez rapportés. Saisissez cette occasion pour fermer les bogues
+ que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez
+ rapportés, vous avez simplement besoin d'aller à
+ <tt>http://&bugs-host;/from:&lt;your-email-addr&gt;</tt>.
+
+      <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul
+      coup
 <p>
 Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
-paquet &mdash; plus de dix &mdash; est une pratique que nous déconseillons. Prenez
-toutes les mesures possibles pour éviter cette situation. Si le problème peut
-être détecté automatiquement par exemple, ajoutez un nouveau test dans le
-paquet <package>lintian</package> pour générer une erreur ou un avertissement.
-
+ paquets &mdash; plus de dix &mdash; est une pratique que nous déconseillons.
+ Prenez toutes les mesures possibles pour éviter cette situation. Si le problème
+ peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le
+ paquet <package>lintian</package> pour générer une erreur ou un avertissement.
 <p>
 Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
-d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
-d'autres développeurs la possibilité de vérifier que le problème existe
-vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
-les mêmes rapports de bogue simultanément.
-
+ d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
+ d'autres développeurs la possibilité de vérifier que le problème existe
+ vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
+ les mêmes rapports de bogue simultanément.
 <p>
 Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
-les envoyer à <email>maintonly@bugs.debian.org</email> pour qu'ils ne soient
-pas redirigés vers les listes de diffusions.
-
+ les envoyer à <email>maintonly@bugs.debian.org</email> pour qu'ils ne soient
+ pas redirigés vers les listes de diffusions.
 
 
+      <sect id="qa-effort">Effort d'assurance qualité
+       
+       <sect1 id="qa-daily-work">Travail journalier
+<p>
+Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
+ devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
+ cet effort en conservant vos paquets aussi exempts de bogues que possible et
+ aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
+ id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
+ d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
+ Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
+ puissent rattraper votre retard dans la correction des bogues (vous pouvez
+ demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
+ temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
+ id="collaborative-maint">).
+       
+       <sect1 id="qa-bsp">Les chasses aux bogues
+<p>
+De temps en temps, le groupe d'assurance qualité organise des chasses aux
+ bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
+ supprimer le plus de problèmes possible. Elles sont annoncées sur
+ &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
+ pendant la chasse&nbsp;: habituellement, il s'agit des bogues empêchant
+ l'intégration du paquet dans la distribution («&nbsp;Release Critical&nbsp;»),
+ mais il peut arriver qu'ils décident d'aider à finir une transition majeure
+ (comme une nouvelle version de Perl qui demande la recompilation de tous les
+ modules binaires).
+<p>
+Les règles pour les mises à jour indépendantes sont différentes au cours de la
+ chasse parce que l'annonce de la chasse est considérée comme une annonce
+ préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
+ peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
+ exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
+ pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
+ ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
+ par un correctif ou si vous gérerez votre bogue vous-même, veuillez l'expliquer
+ dans le BTS.
+<p>
+Les personnes qui participent à la chasse ont des règles spécifiques pour les
+ mises à jour indépendantes, ils peuvent en faire une sans avertissement
+ préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
+ DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
+ s'appliquent comme habituellement, ils devraient envoyer le correctif de la
+ mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
+ jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
+ respecter les souhaits du responsable s'il en a exprimés.
+<p>
+Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle
+ devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
+ mise à jour défectueuse.
+
+    <sect id="mia-qa">Gérer les responsables non joignables
+<p>
+Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
+      que le responsable est toujours actif et qu'il continue à travailler sur
+      ses paquets. Essayez de le contacter vous-même.
+<p>
+Si vous n'obtenez aucune réponse après quelques semaines, vous devriez réunir
+      toutes les informations utiles sur ce responsable. Commencez par vous
+      connecter sur la <url id="&url-debian-db;" name="base de données des
+      développeurs Debian"> et faites une recherche complète pour vérifier si le
+      responsable est en vacances et quand il a été vu la dernière fois.
+      Réunissez les noms des paquets importants dont il est responsable et tous
+      les bogues critiques pour la distribution rapportés sur ceux-ci.
+<p>
+Envoyez toutes ces informations à &email-debian-qa; pour laisser les personnes
+      de la QA décider de ce qui est nécessaire.
+
+    <sect id="contacting-maintainers">Contacter d'autres responsables
+<p>
+Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
+      pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
+      façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
+      simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
+      que vous en avez besoin.
+<p>
+Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
+      Heureusement, il existe un alias de courrier simple,
+      <tt>&lt;package&gt;@&packages-host;</tt>, qui fournit un moyen d'envoyer
+      un courrier à un responsable, quelle que soit son adresse (ou ses
+      adresses). Remplacez <tt>&lt;package&gt;</tt> par le nom du paquet source
+      ou binaire.
+<p>
+Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
+      paquet de source donné par <ref id="pkg-tracking-system">. Vous pouvez le
+      faire en utilisant l'adresse <tt>&lt;package-name&gt;@&pts-host;</tt>.
+
+
+    <sect id="newmaint">
+      <heading>Interagir avec de futurs développeurs Debian
+<p>
+Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
+      talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
+      recommandons de vous impliquer dans le processus d'apport des nouveaux
+      responsables. Cette section décrit comment aider les futurs développeurs.
+
+
+      <sect1 id="sponsoring">Parrainer des paquets
+<p>
+Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
+ pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
+ Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
+<p>
+Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
+ <url id="&url-sponsors;">.
+<p>
+Les nouveaux responsables ont habituellement certaines difficultés à créer des
+ paquets Debian &mdash; ceci est bien compréhensible. C'est pourquoi le parrain
+ est là, pour vérifier que le paquet parrainé est assez bon pour être inclus
+ dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
+ devront également l'inspecter avant de l'intégrer)
+<p>
+Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
+ paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
+ construire le paquet source comme si vous vouliez construire l'un de vos
+ paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
+ candidat développeur dans le changelog et dans le fichier de
+ contrôle, l'envoi peut toujours vous être attribué.
+<p>
+Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
+ pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
+ candidat gère la partie «&nbsp;Tâches et Capacités&nbsp;»<footnote>Tasks and
+ Skills</footnote> de sa candidature.
+
+      <sect1>Gérer les paquets parrainés
+<p>
+En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
+ atteint les standards minimum de Debian. Ceci implique que vous devez
+ construire et tester le paquet sur votre propre système avant l'envoi.
+<p>
+Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
+ filleul. En théorie, vous devriez seulement demander le fichier diff et
+ l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
+ le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
+ utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
+ vérifier qu'il n'a pas modifié les fichiers sources du fichier
+ <file>.orig.tar.gz</file> qu'il fournit.
+<p>
+N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
+ doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
+ paquet ne soit dans un état acceptable. Être un parrain veut dire être un
+ mentor.
+<p>
+Une fois que le paquet a atteint les standards Debian, construisez le paquet
+ avec
+<example>
+ dpkg-buildpackage -us -uc
+</example>
+ et signez-le avec
+<example>
+ debsign -m <var>"Nom complet</var> <var>votre-adresse-courrier</var> <var>changes-file</var>
+</example>
+ avant de l'envoyer dans le répertoire Incoming.
+<p>
+Le champ Maintainer du fichier <file>control</file> et le fichier
+ <file>changelog</file> devraient lister la personne qui a fait l'empaquètement,
+ c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
+ de suivi des bogues (BTS) à propos de son paquet.
+<p>
+Si vous préférez laisser une trace plus visible de votre travail de parrainage,
+  vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
+  changelog.
+<p>
+Vous êtes encouragé à garder un ½il sur le suivi des paquets que vous parrainer
+       en utilisant <ref id="pkg-tracking-system">.
 
+      <sect1>Recommander un nouveau développeur
+<p>
+Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
+ name="recommandations pour un développeur prospectif"> sur le site web Debian.
 
+      <sect1>Gérer les candidatures des nouveaux candidats
+<p>
+Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
+ vérifier pour les responsables de candidatures"> sur le site web Debian.
 
 
-       <chapt id="tools">Aperçu des outils du responsable Debian
 
+    <appendix id="tools">Aperçu des outils du responsable Debian
 <p>
-Cette section contient un aperçu rapide des outils dont dispose le
-responsable.  Cette liste n'est ni complète ni définitive, il s'agit juste
-d'un guide des outils les plus utilisés.
-
+Cette section contient un aperçu rapide des outils dont dispose le responsable.
+      Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
+      des outils les plus utilisés.
 <p>
 Les outils du responsable Debian sont destinés à améliorer le confort des
-responsables et libérer leur temps des tâches plus cruciales. Comme le dit
-Larry Wall, il y a plus d'une manière de le faire.
-
+      responsables et libérer leur temps des tâches plus cruciales. Comme le dit
+      Larry Wall, il y a plus d'une manière de le faire.
 <p>
 Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
-Debian n'a pas de position officielle sur la
-question&nbsp;; tout outil conviendra du moment qu'il fait le boulot. C'est pourquoi
-cette section n'a pas été conçue pour indiquer à chacun
-quel outil il devrait utiliser ou comment il devrait faire pour gérer sa
-charge de responsable Debian. Elle n'est pas non plus destinée à
-favoriser l'usage d'un outil aux dépens d'un autre.
-
+      Debian n'a pas de position officielle sur la question&nbsp;; tout outil
+      conviendra du moment qu'il fait le boulot. C'est pourquoi cette section
+      n'a pas été conçue pour indiquer à chacun quel outil il doit utiliser ou
+      comment il devrait faire pour gérer sa charge de responsable Debian. Elle
+      n'est pas non plus destinée à favoriser l'utilisation d'un outil aux
+      dépens d'un autre.
 <p>
-La plupart des descriptions de ces outils proviennent des descriptions de
-leurs paquets. Vous trouverez plus d'information dans les
-documentations de ces paquets.
-Vous pouvez aussi obtenir plus d'information avec la commande <tt>apt-cache
-show <var>package_name</var></tt>.
+La plupart des descriptions de ces outils proviennent des descriptions de leurs
+      paquets. Vous trouverez plus d'informations dans les documentations de ces
+      paquets. Vous pouvez aussi obtenir plus d'informations avec la commande
+      <tt>apt-cache show &lt;package_name&gt;</tt>.</p>
 
 
+      <sect id="tools-core">
+        <heading>Outils de base</heading>
+        <p>
+Les outils suivants sont pratiquement nécessaires à tout responsable.</p>
 
-       <sect id="dpkg-dev">
-       <heading><package>dpkg-dev</package> 
 
+      <sect1 id="dpkg-dev">
+         <heading><package>dpkg-dev</package></heading>
 <p>
 Le paquet <package>dpkg-dev</package> contient les outils (y compris
-<prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
-paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
-niveau indispensables pour créer et manipuler les paquets&nbsp;; en tant que tels,
-ils sont indispensables à tout responsable Debian.
-
-
-
-
-       <sect id="lintian">
-       <heading><package>lintian</package> 
-
-<p>
-<package>lintian</package> dissèque les paquets pour y repérer des bogues et
-des manquements aux règles de développement. Il contient des tests automatisés pour
-vérifier de nombreuses règles et quelques erreurs courantes.  L'utilisation de
-<package>lintian</package> a déjà été discutée dans <ref id="upload-checking">
-et <ref id="lintian-reports">.
-
-       <sect id="debconf">
-       <heading><package>debconf</package></heading>
+ <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
+ paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
+ niveau indispensables pour créer et manipuler les paquets&nbsp;; en tant que
+ tels, ils sont indispensables à tout responsable Debian.
 
+      <sect1 id="debconf">
+         <heading><package>debconf</package></heading>
 <p>
-Le paquet <package>debconf</package> fournit une interface consistante pour
-configurer les paquets interactivement. Il est indépendant de l'interface et
-permet une configuration en mode texte, par une interface HTML ou par boîtes
-de dialogues. D'autres types d'interface peuvent être ajoutés sous forme
-de modules.
-
+Le paquet <package>debconf</package> fournit une interface unifiée pour
+ configurer les paquets interactivement. Il est indépendant de l'interface et
+ permet une configuration en mode texte, par une interface HTML ou par boîtes de
+ dialogues. D'autres types d'interface peuvent être ajoutés sous forme de
+ modules.
 <p>
 Vous trouverez la documentation de ce paquet dans le paquet
-<package>debconf-doc</package>.
-
+ <package>debconf-doc</package>.
 <p>
 Beaucoup pensent que ce système devrait être utilisé pour tout paquet
-nécessitant une configuration interactive. <package>debconf</package> n'est
-pas requis par le <em>Debian Policy Manual</em> pour le moment&nbsp;; cela
-pourra changer dans le futur.
-
-       
-       <sect id="debhelper">
-       <heading><package>debhelper</package> 
+ nécessitant une configuration interactive&nbsp;; reportez-vous à <ref
+ id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
+ <em>charte Debian</em> pour le moment&nbsp;; cependant, cela pourra changer.
+</sect1>
+
+      <sect1 id="fakeroot">
+       <package>fakeroot</package>
+<p>
+<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet de
+ fabriquer un paquet sans être root (en général, les paquets installent des
+ fichiers appartenant à <em>root</em>). Si vous avez installé
+ <package>fakeroot</package>, vous pouvez construire un paquet en tant que
+ simple utilisateur avec&nbsp;: <tt>dpkg-buildpackage -rfakeroot</tt>.
+
+
+      <sect id="tools-lint">
+        <heading>Outils du paquet lint</heading>
+        <p>
+Selon le «&nbsp;Free On-line Dictionary of Computing&nbsp;» (FOLDOC),
+«&nbsp;lint&nbsp;» est «&nbsp;un outil de traitement de langage C qui contient
+beaucoup plus de tests complets sur le code que n'en font habituellement les
+compilateurs C.&nbsp;». Les outils du paquet lint aide les responsables de
+paquet à trouver automatiquement des problèmes habituels et des violations de
+charte dans leurs paquets</p>
+
+      <sect1 id="lintian">
+         <heading><package>lintian</package></heading>
+<p>
+<package>lintian</package> dissèque les paquets pour y repérer des bogues et des
+ manquements aux règles de développement. Il contient des tests automatisés pour
+ vérifier de nombreuses règles et quelques erreurs courantes.
+<p>
+Vous devriez récupérer la dernière version de <package>lintian</package> depuis
+ <em>unstable</em> régulièrement et vérifier tous vos paquets. Notez que
+ l'option <tt>-i</tt> donne des explications détaillées sur la signication de
+ chaque erreur, la partie concernée dans la charte et le moyen habituel de
+ régler le problème.
+<p>
+Veuillez vous reporter à <ref id="upload-checking"> pour plus d'informations sur
+comment et quand utiliser Lintian.
+<p>
+ Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian
+ sur vos paquets à <url id="&url-lintian;">. Ces rapports contiennent la sortie
+ de la dernière version de <prgn>lintian</prgn> sur l'ensemble de la
+ distribution de développement (<em>unstable</em>).
+</sect1>
+
+        <sect1 id="linda">
+          <heading><package>linda</package></heading>
+          <p>
+<package>linda</package> est un autre vérificateur de paquet. Il est sembable à
+<package>lintian</package>, mais il a un jeu de tests différents. Il est écrit
+en Python plutôt qu'en Perl.</p>
+        </sect1>
+      </sect>
+
+      <sect id="tools-helpers">
+        <heading>Aides pour le fichier <file>debian/rules</file></heading>
+       <p>
+Des outils de construction de paquets rendent le processus d'écriture du fichier
+<file>debian/rules</file> plus facile. Veuillez voir les <ref
+id="helper-scripts"> pour plus d'informations sur les raisons pour lesquelles
+ils peuvent être désirables ou non.
 
+      <sect1 id="debhelper">
+       <heading><package>debhelper</package></heading>
 <p>
 Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
-peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
-tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
-paquet contient des utilitaires pour installer différents fichiers, les
-compresser, ajuster leurs droits et intégrer votre paquet dans le
-système de menu Debian.
-
+ peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
+ tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
+ paquet contient des utilitaires pour installer différents fichiers, les
+ compresser, ajuster leurs droits et intégrer votre paquet dans le système de
+ menu Debian.
 <p>
-Au contraire d'autres approches, <package>debhelper</package> est
-divisé en plusieurs petits utilitaires qui agissent de manière cohérente.
-Ce découpage permet un contrôle des opérations plus fin que
-d'autres outils «&nbsp;<em>debian/rules</em>&nbsp;».
-
+Au contraire d'autres approches, <package>debhelper</package> est divisé en
+ plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage
+ permet un contrôle des opérations plus fin que d'autres «&nbsp;<em>outils
+ debian/rules</em>&nbsp;».
 <p>
 Il existe aussi un certain nombre de petites extensions
-<package>debhelper</package> trop éphémères pour être documentées. Vous en
-listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
+ <package>debhelper</package> trop volatiles pour être documentées. Vous en
+ listerez la plupart en faisant <tt>apt-cache search ^dh-</tt>.
+</sect1>
 
 
-
-       <sect id="debmake">
-       <heading><package>debmake</package> 
-
+      <sect1 id="debmake">
+         <heading><package>debmake</package></heading>
 <p>
-<package>debmake</package> &mdash; un précurseur de <package>debhelper</package> &mdash;
-est un assistant moins modulaire pour manipuler le fichier
-<file>debian/rules</file>.  Il inclut deux programmes principaux&nbsp;:
-<prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
-source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
-regroupe le type de fonction que l'on trouve dans
-<package>debhelper</package>.
-
+<package>debmake</package> &mdash; un précurseur de <package>debhelper</package>
+ &mdash; est un assistant moins modulaire pour manipuler le fichier
+ <file>debian/rules</file>. Il inclut deux programmes principaux&nbsp;:
+ <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet
+ source normal (non-Debian) en paquet source Debian, et <prgn>debstd</prgn> qui
+ regroupe le type de fonction que l'on trouve dans <package>debhelper</package>.
 <p>
 Le consensus actuel est que l'usage de <package>debmake</package> est
-déconseillé au profit de <package>debhelper</package> mais ce n'est pas une
-erreur d'utiliser <package>debmake</package>.
-
+ déconseillé au profit de <package>debhelper</package>, mais ce n'est pas une
+ erreur d'utiliser <package>debmake</package>.
+</sect1>
 
+       <sect1 id="dh-make">
+          <heading><package>dh-make</package>
+       <p>
+Le paquet <package/dh-make/ contient <prgn/dh_make/, un programme qui crée un
+squelette de fichiers nécessaires à la construction d'un paquet Debian à partir
+d'une arborescence source. Comme le nom le suggère, <prgn/dh_make/ est une
+ré-écriture de <package/debmake/ et ses fichiers modèles utilisent les
+programmes dh_* de <package/debhelper/.
+       <p>
+Quoique les fichiers de règles générés par <prgn/dh_make/ constituent en général
+une base suffisante pour un paquet fonctionnel, ce ne sont que les
+fondations&nbsp;: la charge incombe toujours au responsable d'affiner 
+les fichiers générés et de rendre le paquet complètement fonctionnel et
+en conformité avec la charte.
+        </sect1>
 
-       <sect id="yada">
-       <heading><package>yada</package> 
-
+      <sect1 id="yada">
+         <heading><package>yada</package></heading>
 <p>
 Le paquet <package>yada</package> est un autre assistant pour la création de
-paquets. Il utilise un fichier <file>debian/packages</file> pour générer
-<file>debian/rules</file> et d'autres fichiers nécessaires dans
-le sous-répertoire <file>debian/</file>.
-
+ paquets. Il utilise un fichier <file>debian/packages</file> pour générer
+ <file>debian/rules</file> et d'autres fichiers nécessaires dans le
+ sous-répertoire <file>debian/</file>.
 <p>
 Remarque&nbsp;: <package>yada</package> est qualifié de «&nbsp;quasiment non
-maintenu&nbsp;» par son responsable, Charles Briscoe-Smith. Son usage est donc
-déconseillé.
+ maintenu&nbsp;» par son responsable, Charles Briscoe-Smith. Son usage est donc
+ déconseillé.
+</sect1>
 
 
-
-       <sect id="equivs">
-       <heading><package>equivs</package> 
-
+      <sect1 id="equivs">
+         <heading><package>equivs</package></heading>
 <p>
 <package>equivs</package> est un autre paquet pour faire des paquets. Il est
-souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
-pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
-«&nbsp;méta-paquets&nbsp;» qui sont des paquets dont l'unique objet est de
-dépendre d'autres paquets.
-
-
-
-       <sect id="cvs-buildpackage">
-       <heading><package>cvs-buildpackage</package> 
-
-<p>
-Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou
-récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
-un paquet Debian depuis le référentiel CVS et il assiste le développeur lors
-de l'intégration de modifications amont dans le référentiel.
-
-<p>
-Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
-pour le responsable. Il permet de conserver des branches CVS distinctes
-pour les distributions <em>stable</em>, <em>unstable</em> et probablement
-<em>experimental</em>. 
-
-
-       <sect id="dupload">
-       <heading><package>dupload</package> 
-
-<p>
-Le paquet <package>dupload</package> contient un script du même nom pour
-mettre à jour des paquets dans l'archive Debian, tracer ces mises à jour et
-les annoncer par courrier électronique automatiquement. Vous pouvez le
-configurer pour faire des mises à jour à d'autres endroits et avec d'autres
-méthodes.
-
-
-       <sect id="dput">
-       <heading><package>dput</package>
-<p>
-Le script <package>dput</package> fait à peu près la même chose que
-<package>dupload</package> mais il le fait différemment. Il a aussi quelques
-fonctions supplémentaires telles que la possibilité de vérifier la signature
-GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
-démarrer <tt>dinstall</tt> en mode simulation (<em>dry-run</em>) après le
-téléchargement.
-
-       <sect id="fakeroot">
-       <heading><package>fakeroot</package> 
-
-<p>
-<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet
-de fabriquer un paquet sans être root (en général les paquets installent des
-fichiers appartenant à <em>root</em>). Si vous avez installé
-<package>fakeroot</package> vous pouvez construire un paquet en étant
-utilisateur&nbsp;: <tt>dpkg-buildpackage -rfakeroot</tt>.
-
-
-       <sect id="debootstrap">
-       <heading><package>debootstrap</package>
-
-<p>
-Le paquet <package>debootstrap</package> vous permet d'amorcer un système
-Debian de base à n'importe quel endroit dans votre système de fichier. Par
-«&nbsp;système de base&nbsp;» nous entendons le strict minimum nécéssaire pour
-fonctionner et installer le reste du système.
-
+ souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
+ pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
+ «&nbsp;méta-paquets&nbsp;» qui sont des paquets dont l'unique objet est de
+ dépendre d'autres paquets.</p>
+ </sect1>
+</sect>
+
+
+      <sect id="tools-builders">
+        <heading>Constructeurs de paquets</heading>
+        <p>
+Les paquets suivants aident le processus de construction des paquets, en général
+en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que gérant le support de
+tâches.
+
+      <sect1 id="cvs-buildpackage">
+         <heading><package>cvs-buildpackage</package></heading>
+<p>
+Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou de
+ récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
+ un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
+ l'intégration de modifications amonts dans le référentiel.
+<p>
+Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
+ responsable Debian. Il permet de conserver des branches CVS distinctes pour les
+ distributions <em>stable</em>, <em>unstable</em> et probablement
+ <em>experimental</em> et de bénéficier des avantages d'un système de contrôle
+ de version.
+ </sect1>
+
+      <sect1 id="debootstrap">
+         <heading><package>debootstrap</package></heading>
+<p>
+Le paquet <package>debootstrap</package> vous permet d'amorcer un système Debian
+ de base à n'importe quel endroit dans votre système de fichier. Par
+ «&nbsp;système de base&nbsp;», nous entendons le strict minimum nécessaire pour
+ fonctionner et installer le reste du système.
 <p>
 Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
-pouvez par exemple déplacer votre racine dans ce système avec
-<prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
-aussi l'utiliser pour voir comment se comporte votre paquet quand il est
-installé dans un environnement minimum.
-
-
-       <sect id="devscripts">
-       <heading><package>devscripts</package> 
-
+ pouvez, par exemple, déplacer votre racine dans ce système avec
+ <prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
+ aussi l'utiliser pour voir comment se comporte votre paquet quand il est
+ installé dans un environnement minimum.
+        </sect1>
+
+      <sect1 id="pbuilder">
+         <heading><package>pbuilder</package></heading>
+<p>
+<package>pbuilder</package> construit un système «&nbsp;chrooté&nbsp;» et
+ compile des paquets dans ce système. Ceci est très utile pour vérifier que les
+ dépendances de compilation de votre paquet sont correctes et pour vous assurer
+ qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le
+ paquet résultant. </sect1>
+
+      <sect1 id="sbuild">
+         <heading><package>sbuild</package></heading>
+<p>
+<package>sbuild</package> est un autre compilateur automatique. Il peut être
+ aussi utilisé dans un environnement «&nbsp;chrooté&nbsp;». Il peut être utilisé
+ seul ou comme partie d'un environnement de compilation distribué en réseau.
+ Comme le précédent, c'est une partie du système utilisé par les porteurs pour
+ construire des paquets binaires pour toutes les architectures disponibles.
+ Veuillez vous reporter à <ref id="buildd"> pour plus d'informations et à <url
+ id="&url-buildd;"> pour voir le système en fonctionnement.</p>
+        </sect1>
+      </sect>
+
+      <sect id="uploaders">
+        <heading>Téléchargeurs de paquets</heading>
+        <p>
+Les paquets suivants aident à automatiser ou à simplifier le processus d'envoi
+de paquets dans l'archive officielle.</p>
+
+      <sect1 id="dupload">
+         <heading><package>dupload</package></heading>
+<p>
+Le paquet <package>dupload</package> contient un script du même nom pour mettre
+ à jour des paquets dans l'archive Debian, tracer ces mises à jour et les
+ annoncer par courrier électronique automatiquement. Vous pouvez le configurer
+ pour faire des mises à jour à d'autres endroits et avec d'autres méthodes.
+       </sect1>
+
+      <sect1 id="dput">
+         <heading><package>dput</package></heading>
 <p>
-Le paquet <package>devscripts</package> contient quelques scripts et outils
-que vous trouverez peut-être utiles pour maintenir vos paquets Debian. Parmi
-ces scripts, vous trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui 
-manipulent votre fichier
-<file>debian/changelog</file> depuis la ligne de commande et
-<prgn>debuild</prgn> qui est construit au-dessus de
-<prgn>dpkg-buildpackage</prgn>.
-
-
-
-       <sect id="dpkg-dev-el">
-       <heading><package>dpkg-dev-el</package>
+Le script <package>dput</package> fait à peu près la même chose que
+ <package>dupload</package>, mais il le fait différemment. Il a aussi quelques
+ fonctions supplémentaires telles que la possibilité de vérifier la signature
+ GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
+ démarrer <prgn>dinstall</prgn> en mode simulation (<em>dry-run</em>) après le
+ téléchargement.
+       </sect1>
+      </sect>
+
+
+      <sect id="tools-maint-automate">
+        <heading>Automatisation de la maintenance</heading>
+        <p>
+Les outils suivants aident à automatiser les différentes tâches de maintenance
+par l'ajout des entrées de changelog ou de lignes de signatures, par la
+recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier
+officiel <file>config.sub</file>.</p>
+
+
+        <sect1 id="devscripts">
+         <heading><package>devscripts</package></heading>
+<p>
+Le paquet <package>devscripts</package> contient des scripts et outils qui sont
+ très utiles pour maintenir vos paquets Debian. Parmi ces scripts, vous
+ trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui manipulent votre
+ fichier <file>debian/changelog</file> depuis la ligne de commande et
+ <prgn>debuild</prgn> qui est construit au-dessus de
+ <prgn>dpkg-buildpackage</prgn>. L'outil <prgn>bts</prgn> est également très
+ utile pour mettre à jour l'état des rapports de bogue depuis la ligne de
+ commande. Le programme <prgn>uscan</prgn> peut être utilisé pour suivre les
+ nouvelles versions amonts de vos paquets. Le programme <prgn>debrsign</prgn>
+ peut être utilisé pour signer à distance un paquet avant de l'envoyer, ce qui
+ est agréable quand la machine sur laquelle vous construisez le paquet est
+ différente de celle où résident vos clés GPG.</p>
+<p>
+Vérifiez la page de manuel <manref section="1" name="devscripts"> pour une liste
+ complète des scripts disponibles.
+
+        <sect1 id="autotools-dev">
+          <heading><package>autotools-dev</package></heading>
+          <p>
+Contient les meilleurs pratiques pour des personnes assurant la maintenance de
+paquets qui utilisent <prgn>autoconf</prgn> et/ou <prgn>automake</prgn>.
+Contient également des fichiers canoniques <file>config.sub</file> et
+<file>config.guess</file> qui sont connus pour fonctionner avec tous les
+portages Debian.</p>
+        </sect1>
+
+        <sect1 id="dpkg-repack">
+          <heading><package>dpkg-repack</package></heading>
+          <p>
+<prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
+a déjà été installé. Si des changements ont été effectués sur le paquet quand il
+a été décompressé (par exemple, des fichiers dans <file>/etc</file> ont été
+modifés), le nouveau paquet héritera de ces changements.</p>
+          <p>
+Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre
+ou la re-création de paquets installés sur un système, mais qui ne sont plus
+disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le
+mettre à jour.</p>
+        </sect1>
+
+        <sect1 id="alien">
+          <heading><package>alien</package></heading>
+          <p>
+<prgn>alien</prgn> convertit des paquets binaires entre différents formats de
+paquets, y compris des paquets Debian, RPM (RedHat), LSB (Linux Standard Base),
+Solaris et Slackware.</p>
+        </sect1>
+
+        <sect1 id="debsums">
+          <heading><package>debsums</package></heading>
+          <p>
+<prgn>debsums</prgn> vérifie des paquets installés par rapport à leur somme de
+hachage MD5. Veuillez noter que tous les paquets n'ont pas de sommes MD5 car
+elles ne sont pas requises par la charte.</p>
+        </sect1>
+
+      <sect1 id="dpkg-dev-el">
+         <heading><package>dpkg-dev-el</package></heading>
+<p>
+<package>dpkg-dev-el</package> fournit des macros Emacs Lisp qui apportent une
+ aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
+ paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
+ disposez de fonctions pour finaliser une version et consulter la liste des
+ rapports de bogue ouverts.</p>
+</sect1>
+
+
+      <sect id="tools-porting">
+        <heading>Outils de portage</heading>
+        <p>
+Les outils suivants facilitent le travaile des porteurs et la compilation
+croisée.</p>
 
+       <sect1 id="quinn-diff">
+         <heading><package>quinn-diff</package></heading>
 <p>
-<package>dpkg-dev-el</package> fournit des macros Emacs lisp qui apportent une
-aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
-paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
-disposez de fonctions pour finaliser une version et consulter la liste des
-rapports de bogue ouverts.
-
-
-       <sect id="debget">
-       <heading><package>debget</package>
+<package>quinn-diff</package> est utilisé pour localiser les différences d'une
+   architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
+   l'architecture <var>X</var> doivent être portés sur l'architecture
+   <var>Y</var>.
 
+       <sect1 id="dpkg-cross">
+           <heading><package>dpkg-cross</package></heading>
+<p>
+<package>dpkg-cross</package> est un outil qui installe les bibliothèques et les
+   en-têtes nécessaires à une compilation
+   croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
+   similaire à <package>dpkg</package>. De plus, les paquets
+   <prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
+   améliorés pour accepter les compilations croisées.
+
+      <sect id="tools-doc">
+        <heading>Documentation et information</heading>
+        <p>
+Les paquets suivants fournissent des informations pour les responsables ou de
+l'aide pour construire de la documentation
+
+        <sect1 id="debiandoc-sgml">
+          <heading><package>debiandoc-sgml</package></heading>
+          <p>
+<package>debiandoc-sgml</package> fournit la DTD DebianDoc SGML qui est
+habituellement utilisée pour la documentation Debian. Ce manuel, par exemple,
+est écrit en DebianDoc. Il fournit également des scripts pour construire et
+décliner le source en de multiples formats de sortie.</p>
+          <p>
+La documentation sur la DTD peut être trouvée dans le paquet
+<package>debiandoc-sgml-doc</package>.</p>
+        </sect1>
+
+        <sect1 id="debian-keyring">
+          <heading><package>debian-keyring</package></heading>
+          <p>
+Contient les clés publiques GPG et PGP des développeurs Debian. Voir <ref
+id="key-maint"> et la documentation du paquet pour plus d'informations.</p>
+        </sect1>
+
+        <sect1 id="debview">
+          <heading><package>debview</package></heading>
+          <p>
+<package>debview</package> fournit un mode Emacs pour voir les paquets binaires
+Debian. Ceci vous permet d'examiner un paquer sans le décompresser.</p>
+        </sect1>
+      </sect>
+
+<!-- FIXME : tag heading suspect -->
+<!--
+      <sect id="debget">
+       <package>debget</package>
 <p>
-Le paquet <package>debget</package> contient un script qui peut être utile
-pour télécharger des paquets depuis l'archive Debian. Vous pouvez par exemple
-l'utiliser pour télécharger des paquets sources (bien que <tt>apt-get source
-<var>package</var></tt> fasse à peu près la même chose).
-
-
+Le paquet <package>debget</package> contient un script qui peut être
+ utile pour télécharger des paquets depuis l'archive Debian. Vous pouvez, par
+ exemple, l'utiliser pour télécharger des paquets sources (bien que <tt>apt-get
+ source &lt;package&gt;</tt> fasse à peu près la même chose).
+ -->
 
 <!-- FIXME: add the following
+
+questionable:
+  ucf
   dpkg-awk
-  alien
-  dpkg-repack
   grep-dctrl
-  pbuilder -->
-
-
-
-
+  d-shlibs
+  wajig
+  magpie
+  apt-dpkg-ref
+  apt-show-source
+  apt-show-versions
+  pdbv
+  epm
+
+rejected:
+  debaux: too new, unmaintained?
+  dh-make-perl: too new, unmaintained?
+-->
 
+</appendix>
 
-</book>
+  </book>
 </debiandoc>
 
 <!-- Keep this comment at the end of the file
@@ -3099,4 +4340,3 @@ sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:
 -->
-<!-- vim:set tw=78:ts=8: -->