Team-Maintainence documentation; #410159

[developers-reference.git] / developers-reference.fr.sgml

<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
  <!-- include version information so we don't have to hard code it
       within the document -->
  <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
  <!-- common, language independent entities -->
  <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
  <!ENTITY % dynamicdata  SYSTEM "dynamic.ent" > %dynamicdata;

  <!-- CVS revision of this document -->
  <!ENTITY cvs-rev "$Revision: 1.64 $">

  <!-- if you are translating this document, please notate the CVS
       revision of the original developer's reference in cvs-en-rev -->
  <!-- <!ENTITY cvs-en-rev "1.315"> -->

  <!-- how to mark a section that needs more work -->
  <!ENTITY FIXME "<em>FIXME:</em>&nbsp;">

]>
<debiandoc>
 <book>
  <titlepag>
   <title>
     Référence du développeur Debian
   </title>
   <author>
     <name>L'équipe de la Référence du développeur</name>&email-devel-ref;
   </author>
   <author>
     <name>Andreas Barth </name>
   </author>
   <author>
     <name>Adam Di Carlo </name>
   </author>
   <author>
     <name>Rapha&euml;l Hertzog </name>
   </author>
   <author>
     <name>Christian Schwarz </name>
   </author>
   <author>
     <name>Ian Jackson </name>
   </author>
<translator>
  version française par Frédéric Bothamy (traducteur actuel)
</translator>
<translator>et Antoine Hulin (ancien traducteur)</translator>
<translator>
  et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
</translator>
   <version>
     Version &version;, &date-fr; (version française 20061130).
   </version>
   <copyright>
    <copyrightsummary>
      Copyright &copy; 2004&mdash;2006 Andreas Barth
    </copyrightsummary>
    <copyrightsummary>
      Copyright &copy; 1998&mdash;2003 Adam Di Carlo
    </copyrightsummary>
    <copyrightsummary>
      Copyright &copy; 2002&mdash;2003 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>
    <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>
    <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="http://www.gnu.org/copyleft/gpl.html" 
      name="la licence publique générale du projet GNU">. Vous pouvez 
      également l'obtenir en écrivant à la &fsf-addr;. <![ %htmltext [
    </p>
    <p>
      Si vous désirez imprimer cette référence, vous devriez utiliser la 
      <url id="developers-reference.pdf" name="version PDF">. Cette page est 
      également disponible en <url id="index.en.html" name="anglais">. ]]>
    </p>
   </copyright>
  </titlepag>
  <toc detail="sect1">
 
 <chapt id="scope">
  <heading>
    Portée de ce document
  </heading>
  <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.
  </p>
  <p>
    Les procédures décrites ci-après expliquent comment devenir responsable 
    Debian (<ref id="new-maintainer">), comment créer de nouveaux paquets 
    (<ref id="newpackage">) et comment les installer dans l'archive (<ref 
    id="upload">), comment gérer les rapports de bogues (<ref 
    id="bug-handling">), comment déplacer, effacer ou abandonner un paquet 
    (<ref id="archive-manip">), comment faire le portage d'un paquet (<ref 
    id="porting">), quand et comment faire la mise à jour du paquet d'un 
    autre responsable (<ref id="nmu">).
  </p>
  <p>
    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>
  <p>
    Ce manuel de référence ne présente pas les aspects techniques liés aux 
    paquets 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>
  <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. Ce n'est donc pas une sorte 
    de guide de normes.
  </p>
        <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, etc.

<p>
En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
aux développeurs (à l'exception de la liste
<email>debian-devel-french@&lists-host;</email>) 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.


<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
        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>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>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
        id="submit-bug">).

        <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 n'étant que des êtres
        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 censée être plus stable
        qu'<em>unstable</em> (<ref id="sec-dists">).

        <item><em>Stable</em>&nbsp;: nom de la distribution stable. Cette
        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;&nbsp;au sens large&nbsp;&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 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 responsable 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
        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>
 <chapt id="new-maintainer">
  <heading>
    Devenir responsable Debian
  </heading>
  <sect id="getting-started">
   <heading>
     Pour commencer
   </heading>
   <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 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>
   <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</p></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>
   <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>
   <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> pourra aussi être utile&nbsp;; voir <ref 
     id="irc-channels">.
   </p>
   <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"> et <url 
     id="&url-mentors;"> 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.
   </p>
   <p>
     Un écueil à éviter est d'avoir la partie locale de votre adresse
     électronique trop générique&nbsp;: des termes comme mail, admin, root ou
     master devraient être évitées. Veuillez consulter <url
     id="http://www.debian.org/MailingLists/"> pour plus de détails.
   </p>
  </sect>
  <sect id="mentors">
   <heading>
     Mentors et parrains Debian
   </heading>
   <p>
     La liste de diffusion &email-debian-mentors; a été mise en place pour 
     les responsables débutants recherchant de l'aide avec l'empaquetage 
     initial et d'autres problèmes de développeur. Chaque nouveau 
     développeur est invité à s'abonner à cette liste (voir <ref 
     id="mailing-lists"> pour les détails).
   </p>
   <p>
     Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple, 
     par courriels privés) devraient également envoyer des messages à cette 
     liste et un développeur expérimenté se proposera de les aider.
   </p>
   <p>
     De plus, si vous avez des paquets prêts à être inclus dans Debian, mais 
     que vous attendez que votre demande pour devenir responsable soit 
     acceptée, vous pouvez trouver un parrain pour envoyer vos paquets pour 
     vous. Les parrains sont des développeurs Debian officiels qui sont 
     volontaires pour critiquer et envoyer vos paquets pour vous. Veuillez 
     lire en premier la FAQ non officielle de debian-mentors à <url 
     id="&url-mentors;">.
   </p>
   <p>
     Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver 
     plus d'informations à <ref id="newmaint">.
   </p>
  </sect>
  <sect id="registering">
   <heading>
     S'enregistrer comme responsable Debian
   </heading>
   <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 en détail 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>
   <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 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>
   <p>
     Pour devenir responsable, il faudra montrer que vous pouvez faire du 
     bon travail et que vous serez un bon contributeur. Pour cela, vous 
     pourrez proposer des correctifs par le système de suivi des bogues 
     (BTS) et maintenir un paquet parrainé par un responsable Debian 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>
   <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é 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. (S'il n'y a pas de responsable près de chez vous, il peut y avoir 
     des moyens alternatifs pour valider votre identité en tant qu'exception 
     absolue étudiée au cas par cas. Veuillez vous reporter à la <url 
     id="&url-newmaint-id;" name="page d'identification"> pour en savoir 
     plus).
   </p>
   <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>
   <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">.
   </p>
   <p>
     Vous avez besoin d'une clé en version&nbsp;4 à utiliser pour le 
     développement Debian. La longueur de votre clé doit être d'au moins 
     1024&nbsp;;bits&nbsp;; il n'y a pas de raison d'utiliser une clé plus 
     petite et faire cela serait bien moins sûr. <footnote><p>Les clés en 
     version&nbsp;4 sont des clés conformes au standard OpenPGP défini dans 
     la RFC&nbsp;2440. La version&nbsp;4 est le type de clé qui a toujours 
     été créé avec GnuPG. Les versions de PGP depuis la version&nbsp;5 
     peuvent également créer des clés version&nbsp;4, l'autre choix ayant 
     été des clés compatibles pgp&nbsp;2.6.x (également appelées 
     «&nbsp;legacy RSA&nbsp;» par PGP).</p><p>Les clés (primaires) en 
     version&nbsp;4 peuvent soit utiliser l'algorithme RSA, soit 
     l'algorithme DSA, cela n'a donc rien à voir avec la question de GnuPG à 
     propos de «&nbsp;quel type de clé voulez-vous&nbsp;: (1) DSA et 
     Elgamal, (2) DSA (signature seule), (5) RSA (signature seule). Si vous 
     n'avez pas des besoins spécifiques, choisissez simplement la valeur par 
     défaut&nbsp;».</p><p>Le moyen le plus simple de dire si une clé 
     existante est une clé v4 ou une clé v3 (ou v2) est de regarder son 
     empreinte&nbsp;: les empreintes des clés en version&nbsp;4 sont des 
     hachés SHA-1 d'une partie de la clé, il s'agit donc d'une suite de 
     40&nbsp;chiffres hexadécimaux, habituellement groupés par blocs de 
     4. Les empreintes des anciennes versions de clé utilisaient MD5 et sont 
     généralement affichées par blocs de 2&nbsp;chiffres hexadécimaux. Par 
     exemple, si votre empreinte ressemble à ceci&nbsp: 
     <tt>5B00&nbsp;C96D&nbsp;5D54&nbsp;AEE1&nbsp;206B&nbsp;&nbsp;AF84&nbsp;DE7A&nbsp;AF6E&nbsp;94C0&nbsp;9C7F</tt>, 
     alors il s'agit d'une clé v4.</p><p>Une autre possibilité est d'envoyer 
     la clé dans <prgn>pgpdump</prgn>, qui dira quelque chose comme 
     «&nbsp;Public Key Packet - Ver 4&nbsp;».</p><p>Notez également que 
     votre clé doit être auto-signée (c.-à-d. elle doit signer tous ses 
     propres identifiants d'utilisateur&nbsp;; cela empêche la falsification 
     d'identité). Tous les logiciels OpenPGP modernes font cela 
     automatiquement, mais si vous avez une ancienne clé, il se peut que 
     vous deviez ajouter manuellement ces signatures.</p></footnote>
   </p>
   <p>
     Si votre clé publique n'est pas sur un serveur public tel que 
     &pgp-keyserv;, reportez-vous à la documentation disponible à
     <url id="&url-newmaint-id;" name="Étape 2 : Vérification d'identité">.
     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>
   <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. 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>
   <p>
     Pour faire acte de candidature, il vous faut un responsable Debian qui 
     soutiendra 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>
   <p>
     Quand vous avez trouvé 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</p></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>
   <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 de 
     vous porter candidat. Vous gagnerez beaucoup de temps si vous êtes bien 
     préparé.
   </p>
  </sect>
 </chapt>
 <chapt id="developer-duties">
  <heading>
    Les charges du responsable Debian
  </heading>
  <sect id="user-maint">
   <heading>
     Mise à jour de vos références Debian
   </heading>
   <p>
     Il existe une base de données LDAP contenant des informations 
     concernant les développeurs Debian à <url id="&url-debian-db;">. Vous 
     devriez y entrer vos informations et les mettre à jour quand elles 
     changent. Le plus important est de vous assurer que l'adresse vers 
     laquelle est redirigée votre adresse debian.org est toujours à jour, de 
     même que l'adresse à laquelle vous recevez votre abonnement à 
     debian-private si vous choisissez d'être abonné à cette liste.
   </p>
   <p>
     Pour plus d'informations à propos de cette base de données, veuillez 
     consulter <ref id="devel-db">.
   </p>
  </sect>
  <sect id="key-maint">
   <heading>
     Gérer votre clé publique
   </heading>
   <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 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>
   <p>
     Vous devez vous assurer que non seulement votre clé est à l'abri des 
     vols, mais également à l'abri d'une perte. Générez et faites une copie 
     (et également sur papier) de votre certificat de révocation&nbsp;; il 
     est nécessaire si votre clé est perdue.
   </p>
   <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>.
   </p>
   <p>
     Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé, 
     vous devez faire signer la nouvelle clé par un autre développeur. Si 
     l'ancienne clé est compromise ou invalide, vous devez également ajouter 
     la certification de révocation. S'il n'y pas de vraie raison pour une 
     nouvelle clé, les responsables du trousseau de clés peuvent rejeter la 
     nouvelle clé. Vous pouvez trouver plus de détails à <url 
     id="http://keyring.debian.org/replacing_keys.html">.
   </p>
   <p>
     Les mêmes routines d'extraction de clé décrites dans <ref 
     id="registering"> s'appliquent.
   </p>
   <p>
     Vous pouvez trouver une présentation approfondie de la gestion de clé 
     Debian dans la documentation du paquet 
     <package>debian-keyring</package>.
   </p>
  </sect>
  <sect id="voting">
   <heading>
     Voter
   </heading>
   <p>
     Bien que Debian ne soit pas vraiment une démocratie, nous disposons 
     d'un processus démocratique pour élire nos chefs et pour approuver les 
     résolutions générales. Ces procédures sont définies par la <url 
     id="&url-constitution;" name="charte Debian">.
   </p>
   <p>
     En dehors de l'élection annuelle du chef, les votes ne se tiennent pas 
     régulièrement et ils ne sont pas entrepris à la légère. Chaque 
     proposition est tout d'abord discutée sur la liste de diffusion 
     &email-debian-vote; et elle a besoin de plusieurs approbations avant 
     que le secrétaire du projet n'entame la procédure de vote.
   </p>
   <p>
     Vous n'avez pas besoin de suivre les discussions précédant le vote car 
     le secrétaire enverra plusieurs appels au vote sur la liste 
     &email-debian-devel-announce; (et tous les développeurs devraient être 
     inscrits à cette liste). La démocratie ne fonctionne pas si les 
     personnes ne prennent pas part au vote, c'est pourquoi nous 
     encourageons tous les développeurs à voter. Le vote est conduit par 
     messages signés ou chiffrés par GPG.
   </p>
   <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">, ainsi que des informations complémentaires sur la 
     procédure à suivre pour effectuer une proposition, la soutenir et voter 
     pour elle.
   </p>
  </sect>
  <sect id="inform-vacation">
   <heading>
     Prendre des vacances courtoisement
   </heading>
   <p>
     Il est courant pour les développeurs de s'absenter, que ce soit pour 
     des vacances prévues ou parce qu'ils sont submergés de travail. La 
     chose importante à noter est que les autres développeurs ont besoin de 
     savoir que vous êtes en vacances pour qu'ils puissent agir en 
     conséquence si un problème se produit pendant vos vacances.
   </p>
   <p>
     Habituellement, cela veut dire que les autres développeurs peuvent 
     faire des NMU (voir <ref id="nmu">) sur votre paquet si un gros 
     problème (bogue empêchant l'intégration dans la distribution, mise à 
     jour de sécurité, etc.) se produit pendant que vous êtes en 
     vacances. Parfois, ce n'est pas très important, mais il est de toute 
     façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
   </p>
   <p>
     Il y a deux choses à faire pour informer les autres 
     développeurs. Premièrement, envoyez un courrier électronique à 
     &email-debian-private; en commençant le sujet de votre message par 
     «&nbsp;[VAC]&nbsp;»<footnote><p>Ainsi, le message peut être facilement 
     filtré par les personnes qui ne veulent pas lire ces annonces de 
     vacances.</p></footnote> et donnez la période de vos vacances. Vous 
     pouvez également donner quelques instructions pour indiquer comment 
     agir si un problème survenait.
   </p>
   <p>
     L'autre chose à faire est de vous signaler comme «&nbsp;en 
     vacances&nbsp;»<footnote><p><em>on vacation</em> en 
     anglais</p></footnote> dans la <qref id="devel-db">base de données 
     Debian LDAP</qref> (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;!
   </p>
   <p>
     Idéalement, vous devriez vous connecter sur le <url 
     id="http://nm.debian.org/gpg.php" name="site de coordination GPG"> 
     quand vous réservez pour des vacances et vérifier si quelqu'un 
     recherche un échange de signatures. Cela est particulièrement important 
     quand des personnes vont à des endroits exotiques où nous n'avons pas 
     encore de développeurs, mais où il y a des personnes intéressées pour 
     poser leur candidature.
   </p>
  </sect>
  <sect id="upstream-coordination">
   <heading>
     Coordination avec les développeurs amont
   </heading>
   <p>
     Une grande part de votre travail de responsable Debian sera de rester 
     en contact avec les développeurs amont. 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 
     amont pour qu'ils soient corrigés dans les prochaines versions.
   </p>
   <p>
     Bien qu'il ne soit pas de votre responsabilité de corriger les bogues 
     non spécifiques à Debian, vous pouvez le faire si vous en êtes 
     capable. Quand vous faites de telles corrections, assurez-vous de les 
     envoyer également au développeur amont. Les utilisateurs et 
     responsables Debian proposent souvent des correctifs pour corriger des 
     bogues amont, il vous faudra alors évaluer ce correctif puis le 
     transmettre aux développeurs amont.
   </p>
   <p>
     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 amont pour qu'il soit inclus 
     dans leur version. Ainsi, vous n'aurez plus besoin de modifier les 
     sources lors des mises à jour amont suivantes. Quels que soient les 
     changements dont vous avez besoin, il faut toujours essayer de rester 
     dans la lignée des sources amont.
   </p>
  </sect>
  <sect id="rc-bugs">
   <heading>
     Comment gérer les bogues empêchant l'intégration du paquet dans la 
     distribution&nbsp;?
   </heading>
   <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><p>Traduction de l'anglais <em>Release-critical 
     bug (RC Bugs)</em></p></footnote>. Tous les rapports de bogue de 
     gravité <em>critique</em>, <em>grave</em> et 
     <em>sérieuse</em><footnote><p>Respectivement <em>critical</em>, 
     <em>grave</em> et <em>serious</em> en anglais</p></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 
     publication d'une distribution Debian ou peuvent justifier la suppression 
     d'un paquet d'une distribution gelée. C'est pourquoi ces bogues doivent 
     être corrigés au plus vite.
   </p>
   <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).
   </p>
  </sect>
  <sect>
   <heading>
     Démissionner
   </heading>
   <p>
     Si vous choisissez de quitter le projet Debian, procédez comme 
     suit&nbsp;:
    <enumlist numeration="arabic">
     <item>
      <p>
        abandonnez tous vos paquets comme décrit dans <ref 
        id="orphaning">&nbsp;;
      </p>
     </item>
     <item>
      <p>
        envoyez un courrier électronique signé par GnuPG à 
        &email-debian-private; indiquant pourquoi vous quittez le 
        projet&nbsp;;
      </p>
     </item>
     <item>
      <p>
        signalez aux responsables du porte-clés Debian que vous quittez le 
        projet en écrivant à &email-debian-keyring;.
      </p>
     </item>
    </enumlist>
   </p>
  </sect>
 </chapt>
 <chapt id="resources">
  <heading>
    Ressources pour le responsable Debian
  </heading>
  <p>
    Dans ce chapitre, vous trouverez une brève description des listes de 
    diffusion, 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.
  </p>
  <sect id="mailing-lists">
   <heading>
     Les listes de diffusion
   </heading>
   <p>
     Une grande partie des discussions entre les développeurs Debian (et les 
     utilisateurs) est gérée par un vaste éventail de listes de diffusion 
     que nous hébergeons à <tt><url id="http://&lists-host;/" 
     name="&lists-host;"></tt>. Pour en savoir plus sur comment s'abonner ou 
     se désabonner, comment envoyer un message et comment ne pas en envoyer, 
     comment retrouver d'anciens messages et comment les rechercher, comment 
     contacter les responsables des listes et pour savoir d'autres 
     informations sur les listes de diffusion, veuillez lire <url 
     id="&url-debian-lists;">. Cette section ne couvrira que les aspects des 
     listes de diffusion qui ont un intérêt particulier pour les 
     développeurs.
   </p>
   <sect1 id="mailing-lists-rules">
    <heading>
      Règles de base d'utilisation
    </heading>
    <p>
      Lorsque vous répondez sur une liste de diffusion, veuillez ne pas 
      envoyer de copie (<tt>CC</tt>) à l'auteur d'origine sauf s'il le 
      demande explicitement. Toute personne envoyant un message à une liste 
      de diffusion devrait la suivre pour voir les réponses.
    </p>
    <p>
      Le multi-postage (cross-posting) (envoyer le même message à plusieurs 
      listes) est découragé. Comme toujours sur le net, veuillez réduire la 
      citation des articles auxquels vous répondez. En général, veuillez 
      adhérez aux conventions usuelles d'envoi de messages.
    </p>
    <p>
      Veuillez lire le <url id="&url-debian-lists;#codeofconduct" name="code 
      de conduite"> pour plus d'informations.
    </p>
   </sect1>
   <sect1 id="core-devel-mailing-lists">
    <heading>
      Principales listes pour les responsables
    </heading>
    <p>
      Les principales listes de diffusion de Debian que les développeurs 
      devraient suivre sont&nbsp;:
     <list>
      <item>
       <p>
         &email-debian-devel-announce;, utilisée pour les annonces 
         importantes faites aux responsables. Tous les responsables Debian 
         sont censés être inscrits à cette liste,
       </p>
      </item>
      <item>
       <p>
         &email-debian-devel;, utilisée pour discuter de diverses questions 
         techniques relatives au développement,
       </p>
      </item>
      <item>
       <p>
         &email-debian-policy; où l'on discute et vote les modifications de 
         la charte Debian,
       </p>
      </item>
      <item>
       <p>
         &email-debian-project;, utilisée pour discuter de questions non 
         techniques.
       </p>
      </item>
     </list>
    </p>
    <p>
      Il existe d'autres listes de diffusion spécialisées dans différents 
      thèmes. Reportez-vous à la page <url id="http://&lists-host;/"> pour 
      en obtenir la liste complète.
    </p>
   </sect1>
   <sect1 id="mailing-lists-special">
    <heading>
      Listes spéciales
    </heading>
    <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é, 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>
    <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 amont à 
      propos de licences, de bogues ou encore des discussions sur le projet 
      avec d'autres personnes.
    </p>
   </sect1>
   <sect1 id="mailing-lists-new">
    <heading>
      Demander une nouvelle liste relative au développement
    </heading>
    <p>
      Avant de demander une liste de diffusion liée au développement d'un 
      paquet (ou d'un petit groupe de paquets liés), veuillez considérer si 
      l'utilisation d'un alias (via un fichier .forward-aliasname sur 
      master.debian.org, ce qui se traduit en une adresse raisonnablement 
      agréable <var>you-aliasname@debian.org</var>) ou une liste de 
      diffusion auto-gérée sur <qref id="alioth">Alioth</qref> serait plus 
      appropriée.
    </p>
    <p>
      Si vous décidez qu'une liste de diffusion standard sur 
      lists.debian.org est vraiment ce que vous voulez, lancez-vous et 
      faites une demande en suivant <url id="&url-debian-lists-new;" 
      name="le guide">.
    </p>
   </sect1>
  </sect>
  <sect id="irc-channels">
   <heading>
     Canaux IRC
   </heading>
   <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-oftc;" 
     name="Open and free technology community (OFTC)">. L'entrée DNS
     <tt>irc.debian.org</tt> est simplement un alias vers
     <tt>irc.oftc.net</tt>.
   </p>
   <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>
   <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>
   <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>
   <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 l'installateur Debian. <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>
   <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.
   </p>
   <p>
     Il existe également des canaux dédiés pour Debian sur d'autres réseaux 
     IRC, notamment sur le réseau IRC <url id="&url-openprojects;" 
     name="Freenode">, sur lequel pointait l'alias <tt>irc.debian.org</tt>
     jusqu'au 4&nbsp;juin&nbsp;2006.
   </p>
   <p>
     Pour obtenir un uniforme («&nbsp;cloak&nbsp;») sur freenode, vous devez 
     envoyer un courriel signé à J&ouml;rg Jaspert &lt;joerg@debian.org&gt; 
     dans lequel vous indiquez quel est votre pseudonyme 
     («&nbsp;nick&nbsp;»). Mettez «&nbsp;cloak&nbsp;» quelque part dans le 
     sujet. Votre pseudonyme devra être enregistré&nbsp;: <url 
     id="http://freenode.net/faq.shtml#nicksetup" name="Page de 
     configuration des pseudonymes">. Le courriel doit être signé par une 
     clé du porte-clés Debian. Veuillez consulter la <url 
     id="http://freenode.net/faq.shtml#projectcloak" name="documentation de 
     Freenode"> pour plus d'informations sur les uniformes.
   </p>
  </sect>
  <sect id="doc-rsrcs">
   <heading>
     Documentation
   </heading>
   <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 le <url 
     id="&url-devel-docs;" name="coin du développeur Debian">. Prenez le 
     temps de parcourir tous les liens, vous apprendrez encore beaucoup de 
     choses.
   </p>
  </sect>
  <sect id="server-machines">
   <heading>
     Les serveurs Debian
   </heading>
   <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>
   <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>
   <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>
   <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>
   <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>
   <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>
   <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, 
     l'équipe des administrateurs système peut être jointe à 
     <email>debian-admin@lists.debian.org</email>.
   </p>
   <p>
     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.
   </p>
   <p>
     Certains des serveurs de base sont à accès restreint, mais les 
     informations de ceux-ci sont fournies par d'autres serveurs miroirs.
   </p>
   <sect1 id="servers-bugs">
    <heading>
      Le serveur pour les rapports de bogues
    </heading>
    <p>
      <tt>&bugs-host;</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</p></footnote>).
    </p>
    <p>
      Ce serveur est à accès restreint&nbsp;; un miroir est disponible sur 
      <tt>merkel</tt>.
    </p>
    <p>
      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>
   </sect1>
   <sect1 id="servers-ftp-master">
    <heading>
      Le serveur ftp-master
    </heading>
    <p>
      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>
    <p>
      Ce serveur est à accès restreint&nbsp;; un miroir est disponible sur 
      <tt>merkel</tt>.
    </p>
    <p>
      Les problèmes avec l'archive Debian FTP doivent généralement être 
      rapportés comme bogues 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.
    </p>
   </sect1>
   <sect1 id="servers-non-us">
    <heading>
      Le serveur non-US
    </heading>
    <p>
      Le serveur non-US <tt>non-us.debian.org</tt> a été interrompu avec la 
      publication de <em>Sarge</em>. Le pseudo-paquet 
      <package>nonus.debian.org</package> existe encore pour le moment.
    </p>
   </sect1>
   <sect1 id="servers-www">
    <heading>
      Le serveur www-master
    </heading>
    <p>
      Le serveur web principal est <tt>www-master.debian.org</tt>. Il 
      héberge les pages web officielles, la façade de Debian pour la plupart 
      des débutants.
    </p>
    <p>
      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-host;/www.debian.org" name="système de suivi des 
      bogues"> que personne ne l'a déjà rapporté avant vous.
    </p>
   </sect1>
   <sect1 id="servers-people">
    <heading>
      Le serveur web people
    </heading>
    <p>
      <tt>people.debian.org</tt> est le serveur utilisé par les développeurs 
      pour leurs pages concernant Debian.
    </p>
    <p>
      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>
    <p>
      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>
    <p>
      Habituellement, la seule raison pour utiliser un serveur différent est 
      que vous avez besoin de publier des informations soumises aux 
      restrictions d'exportation américaines, dans ce cas, vous pouvez 
      utiliser l'un des autres serveurs situés en dehors des États-Unis.
    </p>
    <p>
      Veuillez envoyer un courrier à &email-debian-devel; si vous avez une 
      question.
    </p>
   </sect1>
   <sect1 id="servers-cvs">
    <heading>
      Le serveur CVS
    </heading>
    <p>
      Notre serveur CVS est situé sur <tt>cvs.debian.org</tt>.
    </p>
    <p>
      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>
    <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;">.
    </p>
    <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.
    </p>
   </sect1>
   <sect1 id="dchroot">
    <heading>
      Chroots de différentes distributions
    </heading>
    <p>
      Sur certaines machines, des chroots de différentes distributions sont 
      disponibles. Vous pouvez les utiliser comme ceci&nbsp;:
     <example>
vore% dchroot unstable
Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable
</example>
      Dans tous les chroots, les répertoires normaux des utilisateurs sont 
      disponibles. Vous pouvez trouver quels chroots sont disponibles à 
      <tt>&url-devel-machines;</tt>.
    </p>
   </sect1>
  </sect>
  <sect id="devel-db">
   <heading>
     La base de données des développeurs
   </heading>
   <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. Une partie de ces informations est également 
     disponible à travers le service <prgn>finger</prgn> sur les serveurs 
     Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce 
     qu'il indique.
   </p>
   <p>
     Les développeurs peuvent <url id="&url-debian-db-login;" name="se 
     connecter à la base de données"> pour modifier différentes informations 
     les concernant, comme&nbsp;:
    <list>
     <item>
      <p>
        l'adresse de suivi pour leur adresse debian.org,
      </p>
     </item>
     <item>
      <p>
        l'abonnement à debian-private,
      </p>
     </item>
     <item>
      <p>
        l'état en vacances ou non,
      </p>
     </item>
     <item>
      <p>
        des informations personnelles comme les adresse, pays, latitude et 
        longitude de l'endroit où ils vivent pour utilisation dans la <url 
        id="http://www.debian.org/devel/developers.loc" name="carte mondiale 
        des développeurs Debian">, numéros de téléphone et de fax, surnom 
        IRC et page web,
      </p>
     </item>
     <item>
      <p>
        le mot de passe et le shell préféré sur les machines du projet 
        Debian.
      </p>
     </item>
    </list>
   </p>
   <p>
     La plupart des informations ne sont naturellement pas accessibles 
     publiquement. Pour plus d'informations, veuillez lire la documentation 
     en ligne que vous pouvez trouver à <url id="&url-debian-db-doc;">.
   </p>
   <p>
     Les développeurs peuvent également envoyer leurs clés SSH pour qu'elles 
     soient utilisées pour autorisation sur les machines Debian officielles 
     et même ajouter de nouvelles entrées DNS du type *.debian.net. Ces 
     fonctionnalités sont documentées à <url id="&url-debian-db-mail-gw;">.
   </p>
  </sect>
  <sect id="archive">
   <heading>
     L'archive Debian
   </heading>
   <p>
     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>
   <p>
     Voici un exemple d'arborescence pour une archive Debian complète&nbsp;:
   </p>
   <p>
     &sample-dist-dirtree;

   </p>
   <p>
     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>
   <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>
   <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>
   <p>
     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.).
   </p>
   <sect1 id="archive-sections">
    <heading>
      Les sections
    </heading>
    <p>
      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>
    <p>
      Chaque paquet de la section <em>main</em> doit être conforme aux <url 
      id="&url-dfsg;" name="directives Debian pour le logiciel 
      libre"><footnote><p>Debian Free Software Guidelines</p></footnote> et 
      à toutes les autres recommandations décrites dans <url 
      id="&url-debian-policy;" name="la charte Debian"><footnote><p>Debian 
      Policy Manual</p></footnote>. Les DFSG<footnote><p><em>Debian Free 
      Software Guidelines</em></p></footnote> constituent notre définition 
      de «&nbsp;logiciel libre&nbsp;». Reportez-vous à la <em>charte 
      Debian</em> pour en savoir plus.
    </p>
    <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>
    <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.
    </p>
    <p>
      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>
    <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.
    </p>
    <p>
      D'un autre côté, un distributeur de cédérom pourra facilement vérifier 
      la licence de chacun des paquets de la section <em>non-free</em> et 
      inclure tous les paquets qu'il lui sera autorisé (dans la mesure où 
      cela varie énormément d'un distributeur à l'autre, ce travail ne peut 
      être fait par les développeurs Debian).
    </p>
    <p>
      Notez que le terme «&nbsp;section&nbsp;» est également utilisé pour 
      faire référence aux catégories qui simplifient l'organisation des 
      paquets disponibles et leur recherche, e.g. <em>admin</em>, 
      <em>net</em>, <em>utils</em> etc. Il fut un temps où ces sections 
      (sous-sections, plutôt) existaient sous la forme de sous-répertoires 
      dans l'archive Debian. Actuellement, elles n'existent plus que dans le 
      champ en-tête «&nbsp;Section&nbsp;» des paquets.
    </p>
   </sect1>
   <sect1>
    <heading>
      Les architectures
    </heading>
    <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>
    <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, le projet 
      Debian a décidé qu'il 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 non-Linux. À côté 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>
    <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 a 
      ajouté cinq nouvelles architectures&nbsp;: <em>ia64</em>, 
      <em>hppa</em>, <em>s390</em>, <em>mips</em> et <em>mipsel</em>.
    </p>
    <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">.
    </p>
   </sect1>
   <sect1>
    <heading>
      Les paquets
    </heading>
    <p>
      Il existe deux types de paquets Debian&nbsp;: les paquets sources et 
      les paquets binaires.
    </p>
    <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>
    <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>responsable 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>
    <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.).
    </p>
   </sect1>
   <sect1>
    <heading>
      Les distributions
    </heading>
    <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 <file>pool</file> à la 
      racine de l'archive Debian.
    </p>
    <p>
      Pour résumer, 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>
    <p>
      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 méta-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).
    </p>
    <sect2 id="sec-dists">
     <heading>
       <em>Stable</em>, <em>testing</em> et <em>unstable</em>
     </heading>
     <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>
     <p>
       Les développements se font sur la distribution 
       <em>unstable</em><footnote><p><em>unstable</em> signifie 
       «&nbsp;instable&nbsp;»</p></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>
     <p>
       La distribution <qref id="testing">«&nbsp;testing&nbsp;»</qref> est 
       générée automatiquement en prenant les paquets d'<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. Voir <ref id="testing">.
     </p>
     <p>
       Après une période de développement, quand le responsable de 
       distribution<footnote><p><em>Release manager</em></p></footnote> le 
       juge opportun, la distribution <em>testing</em> est gelée, ce qui 
       signifie que les conditions à remplir pour qu'un paquet passe 
       d'<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 <em>testing</em> est gelée encore 
       plus. Les détails de la gestion de la distribution <em>testing</em> 
       sont publiées par l'équipe de publication sur la liste 
       debian-devel-announce. Après la résolution des problèmes restants à 
       la satisfaction de l'équipe de publication, la distribution est 
       publiée. La publication veut dire que <em>testing</em> est renommée 
       en <em>stable</em>, une nouvelle copie est créée pour la nouvelle 
       <em>testing</em> et l'ancienne <em>stable</em> est renommée en 
       <em>oldstable</em> et y reste jusqu'à ce qu'elle soit finalement 
       archivée. Lors de l'archivage, son contenu est déplacé sur 
       <tt>&archive-host;</tt>.
     </p>
     <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.2r4&nbsp;» devient «&nbsp;2.2r5&nbsp;» 
       et ainsi de suite). Veuillez vous référer aux <qref 
       id="upload-stable">envois dans la distribution <em>stable</em></qref> 
       pour plus de détails.
     </p>
     <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.
     </p>
    </sect2>
    <sect2>
     <heading>
       Informations complémentaires sur la distribution 
       «&nbsp;testing&nbsp;»
     </heading>
     <p>
       Les paquets sont habituellement installés dans la distribution 
       <em>testing</em> après avoir atteint un certain degré de test dans 
       <em>unstable</em>.
     </p>
     <p>
       Pour plus de détails, veuillez consulter les <qref 
       id="testing">informations à propos de la distribution 
       <em>testing</em></qref>.
     </p>
    </sect2>
    <sect2 id="experimental">
     <heading>
       Experimental
     </heading>
     <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>
     <p>
       Voici les lignes de <manref section="5" name="sources.list"> pour 
       <em>experimental</em>&nbsp;:
      <example>
deb http://ftp.<var>xy</var>.debian.org/debian/ experimental main
deb-src http://ftp.<var>xy</var>.debian.org/debian/ experimental main
</example>
     </p>
     <p>
       Si un logiciel peut causer des dégâts importants, il sera sûrement 
       préférable de le mettre dans la distribution 
       <em>experimental</em>. Un système de fichiers compacté expérimental, 
       par exemple, devrait probablement aller dans <em>experimental</em>.
     </p>
     <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>
     <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 d'<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>
     <p>
       Un nouveau logiciel qui ne risque pas d'endommager le système ira 
       directement dans <em>unstable</em>.
     </p>
     <p>
       Une solution de rechange à <em>experimental</em> consiste à utiliser 
       vos pages personnelles sur le serveur <tt>people.debian.org</tt>.
     </p>
     <p>
       Veuillez considérer l'utilisation de l'option <tt>-v</tt> de 
       <prgn>dpkg-buildpackage</prgn> si l'envoi d'un paquet dans 
       <em>unstable</em> ferme finalement des bogues qui ont d'abord été 
       corrigés dans <em>experimental</em>. Lors de l'envoi vers 
       <em>unstable</em> d'un paquet contenant des bogues corrigés dans 
       <em>experimental</em>, veuillez considérer l'utilisation de l'option 
       <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> pour qu'ils soient 
       finalement fermés.
     </p>
    </sect2>
   </sect1>
   <sect1 id="codenames">
    <heading>
      Les noms de distribution
    </heading>
    <p>
      Chaque distribution Debian diffusée a un <em>nom de code</em>&nbsp;: 
      Debian&nbsp;1.1 s'appelle «&nbsp;Buzz&nbsp;»&nbsp;; Debian&nbsp;1.2, 
      «&nbsp;Rex&nbsp;»&nbsp;; Debian&nbsp;1.3, «&nbsp;Bo&nbsp;»&nbsp;; 
      Debian&nbsp;2.0, «&nbsp;Hamm&nbsp;»&nbsp;; Debian&nbsp;2.1, 
      «&nbsp;Slink&nbsp;»; Debian&nbsp;2.2, «&nbsp;Potato&nbsp;»&nbsp;; 
      Debian&nbsp;3.0, «&nbsp;Woody&nbsp;»&nbsp;; Debian&nbsp;3.1, 
      «&nbsp;Sarge&nbsp;»&nbsp;; Debian&nbsp;4.0,
      «&nbsp;Etch&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 d'<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 prises en 
      charge ou pour lesquelles la distribution n'a pas encore été 
      publiée. Ces architectures seront intégrées ultérieurement à la 
      distribution principale.
    </p>
    <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. 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 publication, ce qui aurait forcé les miroirs FTP à télécharger à 
      nouveau la distribution complète (qui est plutôt volumineuse).
    </p>
    <p>
      D'un autre côté, 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>
    <p>
      En conséquence, les noms de répertoire des distributions dans 
      l'archive sont déterminés par leur nom 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.
    </p>
   </sect1>
  </sect>
  <sect id="mirrors">
   <heading>
     Les miroirs Debian
   </heading>
   <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&nbsp;&mdash; 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 évite 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>
   <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>
   <p>
     Les miroirs sont en général mis en &oelig;uvre 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.
   </p>
  </sect>
  <sect id="incoming-system">
   <heading>
     Le système Incoming
   </heading>
   <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 sur 
     <tt>&ftp-master-host;</tt>.
   </p>
   <p>
     Les paquets sont envoyés par tous les responsables Debian dans un 
     répertoire nommé <file>UploadQueue</file>. Ce répertoire est parcouru 
     toutes les quelques minutes par un démon appelé <prgn>queued</prgn>, 
     les fichiers <file>*.command</file> sont exécutés et les fichiers 
     <file>*.changes</file> restants et correctement signés sont déplacés 
     avec leurs fichiers correspondants dans le répertoire 
     <file>unchecked</file>. Ce répertoire n'est pas visible de la plupart 
     des développeurs car ftp-master est à accès restreint&nbsp;; il est 
     parcouru toutes les 15 minutes par le script <prgn>katie</prgn> qui 
     vérifie l'intégrité des paquets envoyés et leurs 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 (ou s'il a de nouveaux paquets binaire), 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>
   <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;"> jusqu'à ce qu'il soit vraiment installé dans 
     l'archive Debian. Cela se produit seulement une fois par jour (et c'est 
     également appelé une «&nbsp;exécution dinstall&nbsp;» pour des raisons 
     historiques)&nbsp;; 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 (fabrication 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>
   <p>
     Le logiciel de maintenance de l'archive enverra également le fichier 
     <file>.changes</file> signé avec OpenPGP/GnuPG que vous avez envoyé, à 
     la liste de diffusion appropriée. Si un paquet est diffusé avec le 
     champ <tt>Distribution:</tt> positionné à «&nbsp;stable&nbsp;», 
     l'annonce sera envoyée à &email-debian-changes;. Si un paquet est 
     diffusé avec le champ <tt>Distribution:</tt> positionné à 
     «&nbsp;unstable&nbsp;» ou «&nbsp;experimental&nbsp;», l'annonce sera à 
     la place envoyée à &email-debian-devel-changes;.
   </p>
   <p>
     Bien que ftp-master soit à accès restreint, une copie de l'installation 
     est disponible à tous les développeurs sur 
     <tt>&ftp-master-mirror;</tt>.
   </p>
  </sect>
  <sect id="pkg-info">
   <heading>
     Informations sur un paquet
   </heading>
   <p>
   </p>
   <sect1 id="pkg-info-web">
    <heading>
      Sur le web
    </heading>
    <p>
      Chaque paquet a plusieurs pages web 
      dédiées. <tt>http://&packages-host;/<var>nom-paquet</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 télécharger 
      le paquet.
    </p>
    <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>nom-paquet</var></tt>.
    </p>
   </sect1>
   <sect1 id="madison">
    <heading>
      L'outil <prgn>madison</prgn>
    </heading>
    <p>
      <prgn>madison</prgn> est un outil en ligne de commande qui est 
      disponible sur <tt>&ftp-master-host;</tt> et sur le miroir 
      <tt>&ftp-master-mirror;</tt>. Il utilise un seul paramètre 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>
    <p>
     <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>
    <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 version du 
      paquet a été recompilée sur la plupart des architectures.
    </p>
   </sect1>
  </sect>
  <sect id="pkg-tracking-system">
   <heading>
     Système de suivi des paquets
   </heading>
   <p>
     Le système de suivi des paquets (PTS)<footnote><p>«&nbsp;Package 
     Tracking System&nbsp;»</p></footnote> est un outil pour suivre par 
     courrier l'activité concernant un paquet source. Cela veut vraiment 
     dire que vous pourrez recevoir les mêmes courriers que le responsable, 
     simplement en vous inscrivant au paquet dans le PTS.
   </p>
   <p>
     Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés 
     listés ci-dessous. Ceci vous permettra de sélectionner les courriers 
     que vous voulez recevoir.
   </p>
   <p>
     Par défaut, vous recevrez&nbsp;:
    <taglist>
     <tag>
       <tt>bts</tt>
     </tag>
     <item>
      <p>
        Tous les rapports de bogue et les discussions qui suivent.
      </p>
     </item>
     <tag>
       <tt>bts-control</tt>
     </tag>
     <item>
      <p>
        Les courriers de notification de 
        <email>control@bugs.debian.org</email> sur les changement d'état de 
        l'un des rapports de bogue.
      </p>
     </item>
     <tag>
       <tt>upload-source</tt>
     </tag>
     <item>
      <p>
        Le courrier de notification de <prgn>katie</prgn> quand un paquet 
        source envoyé a été accepté.
      </p>
     </item>
     <tag>
       <tt>katie-other</tt>
     </tag>
     <item>
      <p>
        Les autres courriers d'avertissement et d'erreur de 
        <prgn>katie</prgn> (comme une incohérence de passage en force pour 
        les champs section ou priorité).
      </p>
     </item>
     <tag>
       <tt>default</tt>
     </tag>
     <item>
      <p>
        Tout courrier non automatique envoyé au PTS par les personnes qui 
        veulent contacter les inscrits au paquet. Ceci peut être fait en 
        envoyant un courrier à 
        <tt><var>paquet-source</var>@&pts-host;</tt>. Pour prévenir l'envoi 
        de pourriels, tous les courriers envoyés à ces adresses doivent 
        contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
      </p>
     </item>
     <tag>
       <tt>summary</tt>
     </tag>
     <item>
      <p>
        Des courriers de résumé réguliers sur l'état du paquet. Actuellement,
        seule la progression du paquet dans <em>testing</em> est envoyée.
      </p>
     </item>
    </taglist>
   </p>
   <p>
     Vous pouvez également décider de recevoir des informations 
     supplémentaires&nbsp;:
    <taglist>
     <tag>
       <tt>upload-binary</tt>
     </tag>
     <item>
      <p>
        Le courrier d'information de <prgn>katie</prgn> quand un paquet 
        binaire envoyé est accepté. En d'autres termes, à chaque fois qu'un 
        démon de compilation ou un porteur envoie votre paquet pour une 
        autre architecture, vous recevez un courrier pour suivre comment 
        votre paquet est recompilé pour toutes les architectures.
      </p>
     </item>
     <tag>
       <tt>cvs</tt>
     </tag>
     <item>
      <p>
        Les notifications de modifications CVS<footnote><p><em>CVS 
        commits</em></p></footnote> si le responsable a mis en place un 
        système pour faire suivre les notifications de modifications vers le 
        PTS.
      </p>
     </item>
     <tag>
       <tt>ddtp</tt>
     </tag>
     <item>
      <p>
        Les traductions des descriptions ou des questionnaires debconf 
        soumis au Projet de traduction des descriptions de paquets 
        Debian<footnote><p><em>Debian Description Translation Project, 
        DDTP</em></p></footnote>.
      </p>
     </item>
     <tag>
       <tt>derivatives</tt>
     </tag>
     <item>
      <p>
        Des informations sur les changements effectués sur le paquet dans les
        distributions dérivées (par exemple, Ubuntu).
      </p>
     </item>
    </taglist>
   </p>
   <sect1 id="pts-commands">
    <heading>
      L'interface de courrier du PTS
    </heading>
    <p>
      Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant 
      différentes commandes à <email>pts@qa.debian.org</email>.
     <taglist>
      <tag>
        <tt>subscribe &lt;paquet source&gt; [&lt;adresse&gt;]</tt>
      </tag>
      <item>
       <p>
         Inscrit <var>adresse</var> aux communications liées au paquet 
         source <var>paquet source</var>. L'adresse de l'expéditeur est 
         utilisée si le second paramètre n'est pas présent. Si <var>paquet 
         source</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.
       </p>
      </item>
      <tag>
        <tt>unsubscribe &lt;paquet source&gt; [&lt;adresse&gt;]</tt>
      </tag>
      <item>
       <p>
         Supprime une inscription précédente au paquet source <var>paquet 
         source</var> en utilisant l'adresse spécifiée ou l'adresse de 
         l'expéditeur si le second paramètre n'est pas rempli.
       </p>
      </item>
      <tag>
        <tt>unsubscribeall [&lt;adresse&gt;]</tt>
      </tag>
      <item>
       <p>
         Supprime toutes les inscriptions précédentes de l'adresse spécifiée
         ou de l'adresse de l'expéditeur si le second paramètre n'est pas
         rempli.
       </p>
      </item>
      <tag>
        <tt>which [&lt;adresse&gt;]</tt>
      </tag>
      <item>
       <p>
         Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée 
         si elle est spécifiée.
       </p>
      </item>
      <tag>
        <tt>keyword [&lt;adresse&gt;]</tt>
      </tag>
      <item>
       <p>
         Donne les mots-clés que vous acceptez. Pour une explication des ces 
         mots-clés, <qref id="pkg-tracking-system">voir 
         ci-dessus</qref>. Voici un rapide résumé&nbsp;:
        <list>
         <item>
          <p>
            <tt>bts</tt>&nbsp;: courriers venant du système de gestion de 
            bogues (BTS) Debian
          </p>
         </item>
         <item>
          <p>
            <tt>bts-control</tt>&nbsp;: réponses aux courriers envoyés à 
            &bugs-host;&email-bts-control;
          </p>
         </item>
         <item>
          <p>
            <tt>summary</tt>&nbsp;: courriers de résumé automatique sur 
            l'état d'un paquet
          </p>
         </item>
         <item>
          <p>
            <tt>cvs</tt>&nbsp;: notifications de modifications CVS
          </p>
         </item>
         <item>
          <p>
            <tt>ddtp</tt>&nbsp;: traductions des descriptions et 
            questionnaires debconf
          </p>
         </item>
         <item>
          <p>
            <tt>derivatives</tt>&nbsp;: changements effectués sur le paquet
            dans des distributions dérivées
          </p>
         </item>
         <item>
          <p>
            <tt>upload-source</tt>&nbsp;: annonce d'un nouvel envoi de 
            paquet source qui a été accepté
          </p>
         </item>
         <item>
          <p>
            <tt>upload-binary</tt>&nbsp;: annonce d'un nouvel envoi de 
            binaire seulement (portage)
          </p>
         </item>
         <item>
          <p>
            <tt>katie-other</tt>&nbsp;: autres courriers des ftpmasters 
            (incohérence de passage en force, etc.)
          </p>
         </item>
         <item>
          <p>
            <tt>default</tt>&nbsp;: tous les autres courriers (ceux qui ne 
            sont pas automatiques)
          </p>
         </item>
        </list>
       </p>
      </item>
      <tag>
        <tt>keyword &lt;paquet source&gt; [&lt;adresse&gt;]</tt>
      </tag>
      <item>
       <p>
         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.
       </p>
      </item>
      <tag>
        <tt>keyword [&lt;adresse&gt;] {+|-|=} &lt;liste de 
        mots-clés&gt;</tt>
      </tag>
      <item>
       <p>
         Accepte (+) ou refuse (-) les courriers classés sous le(s) 
         mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
         change l'ensemble par défaut des mots-clés acceptés par un
         utilisateur.
       </p>
      </item>
      <tag>
        <tt>keywordall [&lt;adresse&gt;] {+|-|=} &lt;liste de
        mots-clés&gt;</tt>
      </tag>
      <item>
       <p>
         Accepte (+) ou refuse (-) les courriers classés sous le(s)
         mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
         change les mots-clés de toutes les inscriptions actuellement en cours
         d'un utilisateur.
       </p>
      </item>
      <tag>
        <tt>keyword &lt;paquet source&gt; [&lt;adresse&gt;] {+|-|=} 
        &lt;liste de mots-clés&gt;</tt>
      </tag>
      <item>
       <p>
         Identique à l'élément précédent, mais remplace la liste des 
         mots-clés pour le paquet source indiqué.
       </p>
      </item>
      <tag>
        <tt>quit | thanks | --</tt>
      </tag>
      <item>
       <p>
         Arrête le traitement des commandes. Toutes les lignes suivantes 
         sont ignorées par le robot.
       </p>
      </item>
     </taglist>
    </p>
    <p>
      L'utilitaire en ligne de commande <prgn>pts-subscribe</prgn> (du paquet
      <package>devscripts</package>) peut être pratique pour s'inscrire
      temporairement à certains paquets, par exemple après avoir fait une mise
      à jour indépendante (NMU).
    </p>

   </sect1>
   <sect1 id="pts-mail-filtering">
    <heading>
      Filtrer les courriers du PTS
    </heading>
    <p>
      Une fois que vous vous êtes inscrit à un paquet, vous recevrez les 
      courriers envoyés à <tt><var>paquet 
      source</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 (par exemple, 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>
    <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>
    </p>
   </sect1>
   <sect1 id="pts-cvs-commit">
    <heading>
      Faire suivre les modifications de CVS vers le PTS
    </heading>
    <p>
      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 
      (ainsi que des possibles co-responsables) puissent suivre de près 
      l'évolution du paquet.
    </p>
    <p>
      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>paquet 
      source</var>_cvs@&pts-host;</tt>. Seules les personnes qui ont accepté 
      le mot-clé <em>cvs</em> recevront les notifications.
    </p>
   </sect1>
   <sect1 id="pts-web">
    <heading>
      L'interface web du PTS
    </heading>
    <p>
      Le PTS possède une interface web à <url id="http://&pts-host;/"> qui 
      réunit beaucoup d'informations au même endroit à propos de chaque 
      paquet source. Il propose plusieurs liens utiles (BTS, statistiques 
      QA, informations de contact, état de traduction DDTP, journaux de 
      compilation automatique) et il regroupe beaucoup d'autres informations 
      provenant de différents endroits (les 30 dernières entrées de 
      changelog, l'état dans <em>testing</em>, etc.). Il s'agit d'un outil 
      très pratique si vous désirez connaître ce qu'il en est d'un paquet 
      source spécifique. De plus, il y a un formulaire qui permet de 
      facilement s'inscrire au PTS par courrier.
    </p>
    <p>
      Vous pouvez aller directement à la page web concernant un paquet 
      source avec une URL comme <tt>http://&pts-host;/<var>paquet 
      source</var></tt>.
    </p>
    <p>
      Cette interface a été conçue comme un portail pour le développements 
      des paquets&nbsp;: vous pouvez ajouter du contenu personnalisé aux 
      pages de vos paquets. Vous pouvez ajouter des «&nbsp;informations 
      statiques&nbsp;»<footnote><p><em>Static 
      information</em></p></footnote> (des annonces qui sont destinées à 
      rester disponibles indéfiniment) et des nouvelles dans la section 
      «&nbsp;dernières nouvelles&nbsp;»<footnote><p><em>Latest 
      news</em></p></footnote>.
    </p>
    <p>
      Les annonces statiques peuvent être utilisées pour indiquer&nbsp;:
     <list>
      <item>
       <p>
         la disponibilité d'un projet hébergé sur <qref 
         id="alioth">Alioth</qref> pour la co-maintenance du paquet,
       </p>
      </item>
      <item>
       <p>
         un lien vers le site web amont,
       </p>
      </item>
      <item>
       <p>
         un lien vers le suivi de bogues amont,
       </p>
      </item>
      <item>
       <p>
         l'existence d'un canal IRC dédié au logiciel,
       </p>
      </item>
      <item>
       <p>
         toute autre ressource disponible qui peut être utile à la 
         maintenance du paquet.
       </p>
      </item>
     </list>
      Les nouvelles usuelles peuvent être utilisées pour annoncer que&nbsp;:
     <list>
      <item>
       <p>
         des paquets bêta sont disponibles pour test,
       </p>
      </item>
      <item>
       <p>
         des paquets finaux sont attendus pour la semaine prochaine,
       </p>
      </item>
      <item>
       <p>
         l'empaquetage est sur le point d'être intégralement refait,
       </p>
      </item>
      <item>
       <p>
         des rétroportages sont disponibles,
       </p>
      </item>
      <item>
       <p>
         le responsable est en vacance (s'il désire publier cette 
         information),
       </p>
      </item>
      <item>
       <p>
         une mise à jour indépendante (NMU) est en cours de réalisation,
       </p>
      </item>
      <item>
       <p>
         quelque chose d'important va affecter le paquet.
       </p>
      </item>
     </list>
    </p>
    <p>
      Les deux types d'informations sont fabriqués de façon similaire&nbsp;: 
      il vous suffit d'envoyer un courrier soit à 
      <email>pts-static-news@qa.debian.org</email> (pour les annonces 
      statiques), soit à <email>pts-news@qa.debian.org</email> (pour les 
      nouvelles usuelles). Le courrier devrait indiquer quel paquet est 
      concerné par la nouvelle en donnant le nom du paquet source dans un 
      en-tête de courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête 
      <tt>Package</tt> (comme pour les rapports de bogue du BTS). Si une URL 
      est disponible dans l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans 
      un pseudo-en-tête <tt>Url</tt>, le résultat est un lien vers cette URL 
      au lieu d'une nouvelle complète.
    </p>
    <p>
      Voici quelques exemples de courriers valides utilisés pour générer des 
      nouvelles dans le PTS. Le premier ajoute un lien vers l'interface 
      cvsweb de debian-cd dans la section «&nbsp;Informations 
      statiques&nbsp;»&nbsp;:
     <example>
From: Raphael Hertzog &lt;hertzog@debian.org&gt;
To: pts-static-news@qa.debian.org
Subject: Browse debian-cd CVS repository with cvsweb
 
Package: debian-cd
Url: http://cvs.debian.org/debian-cd/
</example>
    </p>
    <p>
      Le second est une annonce envoyée à une liste de diffusion et 
      également envoyée au PTS pour qu'elle soit publiée sur la page web du 
      PTS du paquet. Notez l'utilisation du champ BCC pour éviter que des 
      réponses ne soient envoyées par erreur au PTS.
     <example>
From: Raphael Hertzog &lt;hertzog@debian.org&gt;
To: debian-gtk-gnome@lists.debian.org
Bcc: pts-news@qa.debian.org
Subject: Galeon 2.0 backported for woody
X-PTS-Package: galeon

Hello gnomers!

I'm glad to announce that galeon has been backported for woody. You'll find
everything here:
...
</example>
    </p>
    <p>
      Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car 
      vous ne pourrez pas l'enlever par la suite et vous ne pourrez pas non 
      plus l'éditer. La seule chose que vous puissiez faire est d'envoyer 
      une deuxième nouvelle qui va déprécier l'information contenue dans la 
      précédente.
    </p>
   </sect1>
  </sect>
  <sect id="ddpo">
   <heading>
     Vue d'ensemble des paquets d'un développeur
   </heading>
   <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>
   <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é.
   </p>
  </sect>
  <sect id="alioth">
   <heading>
     Debian *Forge&nbsp;: Alioth
   </heading>
   <p>
     Alioth est un service de Debian plutôt récent, basé sur une version 
     légèrement modifiée du logiciel GForge (qui a évolué à partir de 
     SourceForge). Ce logiciel offre aux développeurs l'accès à des outils 
     faciles d'utilisation comme un gestionnaire de suivi de bogues, un 
     gestionnaire de correctifs, un gestionnaire de tâches et de projets, un 
     service d'hébergement de fichiers, des listes de diffusion, des dépôts 
     CVS, etc. Tous ces outils sont gérés par une interface web.
   </p>
   <p>
     Alioth est destiné à fournir des facilités pour des projets de 
     logiciels soutenus ou dirigés par Debian, à faciliter les contributions 
     de développeurs externes aux projets initiés par Debian et à aider des 
     projets dont les buts sont de promouvoir Debian ou ses dérivés.
   </p>
   <p>
     Tous les développeurs Debian ont automatiquement un compte sur 
     Alioth. Ils peuvent l'activer en utilisant la fonctionnalité de 
     récupération des mots de passe. Les développeurs externes peuvent 
     demander un compte invité sur Alioth.
   </p>
   <p>
     Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
   </p>
  </sect>
  <sect id="developer-misc">
   <heading>
     «&nbsp;Goodies&nbsp;» pour les développeurs
   </heading>
   <p>
   </p>
   <sect1 id="lwn">
    <heading>
      Abonnements LWN
    </heading>
    <p>
      Depuis octobre&nbsp;2002, HP parraine l'abonnement à LWN pour tous les 
      développeurs Debian intéressés. Les détails sur les moyens d'accéder à 
      cet avantage sont expliqués dans <url 
      id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
    </p>
   </sect1>
  </sect>
 </chapt>
 <chapt id="pkgs">
  <heading>
    Gestion des paquets
  </heading>
  <p>
    Ce chapitre contient des informations relatives à la création, l'envoi, 
    la maintenance et le portage des paquets.
  </p>
  <sect id="newpackage">
   <heading>
     Nouveaux paquets
   </heading>
   <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>
   <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 <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>
   <p>
     Le sujet de votre rapport de bogue devra être 
     &lt;ITP<footnote><p><em>Intent To Package</em>&nbsp;: intention 
     d'empaquetage</p></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>
   <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>
   <p>
     Lors de la fermeture de bogues de sécurité, incluez les numéros CVS ainsi
     que «&nbsp;Closes: #nnnnn&nbsp;». Ceci est utile  l'équipe de sécurité
     pour suivre les failles de sécurité. Si un envoi est effectué pour
     corriger le bogue avant que l'identifiant de l'alerte soit connu, il est
     conseillé de modifier l'entrée de changelog historique lors du prochain
     envoi. Même dans ce cas, veuillez inclure tous les pointeurs disponibles
     vers les informations de contexte dans l'entrée de changelog d'origine.
   </p>
   <p>
     Plusieurs raisons nous poussent à demander aux responsables d'annoncer 
     leur intention&nbsp;:
    <list compact="compact">
     <item>
      <p>
        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.
      </p>
     </item>
     <item>
      <p>
        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é.
      </p>
     </item>
     <item>
      <p>
        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>.
      </p>
     </item>
     <item>
      <p>
        C'est une information utile pour les gens qui utilisent la 
        distribution <em>unstable</em> et qui sont nos premiers 
        testeurs. Nous devons leur faciliter la tâche.
      </p>
     </item>
     <item>
      <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 des nouveautés du projet.
      </p>
     </item>
    </list>
   </p>
   <p>
     Veuillez consulter <url
     id="http://ftp-master.debian.org/REJECT-FAQ.html"> pour les raisons
     courantes de rejet des nouveaux paquets.
   </p>
  </sect>
  <sect id="changelog-entries">
   <heading>
     Enregistrer les modifications dans le paquet
   </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 les raisons de 
     ceux-ci (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>
   <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="distribution">. 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>
   <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>
   <p>
     Par convention, l'entrée changelog d'un paquet contenant une nouvelle 
     version amont ressemble à&nbsp;:
    <example>
  * new upstream version
</example>
   </p>
   <p>
     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">.
   </p>
   <p>
     Voir aussi <ref id="bpp-debian-changelog">.
   </p>
  </sect>
  <sect id="sanitycheck">
   <heading>
     Tester le paquet
   </heading>
   <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>
      <p>
        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.
      </p>
     </item>
     <item>
      <p>
        Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter 
        <prgn>lintian</prgn> comme suit&nbsp;: <tt>lintian -v 
        <var>version-paquet</var>.changes</tt>. Ce programme fera une 
        vérification sur les paquets source et binaire. Si vous ne comprenez 
        pas les messages retourné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>
      <p>
        En principe, un paquet pour lequel <prgn>lintian</prgn> renvoie des 
        erreurs (elles commencent par <tt>E</tt>) <em>ne doit pas</em> être 
        installé dans l'archive.
      </p>
      <p>
        Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la 
        section <ref id="lintian">.
      </p>
     </item>
     <item>
      <p>
        Vous pouvez facultativement exécuter <ref id="debdiff"> pour 
        analyser les modifications depuis une ancienne version si celle-ci 
        existe.
      </p>
     </item>
     <item>
      <p>
        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>.
      </p>
     </item>
     <item>
      <p>
        Désinstallez le paquet et réinstallez-le.
      </p>
     </item>
     <item>
      <p>
        Copiez le paquet source dans une répertoire différent et tentez de 
        le décompacter et de le reconstruire. Ceci teste si le paquet repose 
        sur des fichiers existants en dehors de ceux du paquet ou s'il 
        repose sur des permissions préservées des fichiers livrés dans le 
        fichier .diff.gz.
      </p>
     </item>
    </list>
   </p>
  </sect>
  <sect id="sourcelayout">
   <heading>
     Disposition du paquet source
   </heading>
   <p>
     Il existe deux types de paquets source Debian&nbsp;:
    <list>
     <item>
      <p>
        les paquets appelés <em>natifs</em> pour lesquels il n'y a pas de 
        distinction entre les sources d'origine et les correctifs appliqués 
        pour Debian
      </p>
     </item>
     <item>
      <p>
        les paquets (plus courants) où il y a un fichier archive source 
        d'origine accompagné par un autre fichier contenant les correctifs 
        pour Debian.
      </p>
     </item>
    </list>
   </p>
   <p>
     Pour les paquets natifs, le paquet source inclut un fichier de contrôle 
     source Debian (<tt>.dsc</tt>) et l'archive source 
     (<tt>.tar.gz</tt>). Un paquet source d'un paquet non natif inclut un 
     fichier de contrôle source Debian, l'archive source d'origine 
     (<tt>.orig.tar.gz</tt>) et les correctifs Debian (<tt>.diff.gz</tt>).
   </p>
   <p>
     Le caractère natif d'un paquet est déterminé lorsqu'il est construit 
     par <manref section="1" name="dpkg-buildpackage">. Le reste de cette 
     section ne se rapporte qu'aux paquets non natifs.
   </p>
   <p>
     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>
   <p>
     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>
   <p>
     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>
   <p>
     Veuillez noter que, dans des paquets non natifs, les permissions sur 
     des fichiers qui ne sont pas présents dans l'archive .orig.tar.gz ne 
     seront pas préservées car diff ne stocke pas les permissions de fichier 
     dans le correctif.
   </p>
  </sect>
  <sect id="distribution">
   <heading>
     Choisir une distribution
   </heading>
   <p>
     Chaque envoi doit spécifier à quelle distribution le paquet est 
     destiné. Le processus de construction de paquet extrait cette 
     information à partir de la première ligne du fichier 
     <file>debian/changelog</file> et la place dans le champ 
     <tt>Distribution</tt> du fichier <tt>.changes</tt>.
   </p>
   <p>
     Il existe plusieurs valeurs possibles pour ce champ&nbsp;: 
     «&nbsp;stable&nbsp;», «&nbsp;unstable&nbsp;», 
     «&nbsp;testing-proposed-updates&nbsp;» et «&nbsp;experimental&nbsp;».
   </p>
   <p>
     En fait, il y a deux autres possibilités&nbsp;: 
     «&nbsp;stable-security&nbsp;» et «&nbsp;testing-security&nbsp;», mais 
     veuillez lire <ref id="bug-security"> pour plus d'informations sur 
     celles-ci.
   </p>
   <p>
     Il n'est pas possible d'envoyer un paquet dans plusieurs distributions 
     en même temps.
   </p>
   <sect1 id="upload-stable">
    <heading>
      Cas spécial&nbsp;: mise à jour d'un paquet de la distribution 
      <em>stable</em>
    </heading>
    <p>
      Livrer un paquet pour la distribution <em>stable</em> signifie que le 
      paquet 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>
    <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>
       <p>
         un problème fonctionnel vraiment critique,
       </p>
      </item>
      <item>
       <p>
         un paquet devenu non installable,
       </p>
      </item>
      <item>
       <p>
         un paquet indisponible pour une architecture.
       </p>
      </item>
     </list>
    </p>
    <p>
      Par le passé, des envois vers <em>stable</em> étaient également 
      utilisés pour corriger les problèmes de sécurité. Cependant, cette 
      pratique est dépréciée car les envois utilisés pour les avis de 
      sécurité Debian<footnote><p>Debian security advisory</p></footnote> 
      sont automatiquement copiés dans l'archive 
      <file>proposed-updates</file> appropriée quand l'avis est 
      publié. Reportez-vous à <ref id="bug-security"> pour des informations 
      plus détaillées sur la gestion des problèmes de sécurité.
    </p>
    <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.
    </p>
    <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 non installables, est 
      fortement déconseillé.
    </p>
    <p>
      L'équipe responsable de la distribution<footnote><p><em>the Release 
      team</em></p></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.
    </p>
    <p>
      Il est fortement conseillé de discuter avec le responsable de la 
      version stable <em>avant</em> de réaliser un envoi dans 
      <em>stable</em>/<em>stable-proposed-updates</em>, pour que le paquet 
      envoyé corresponde aux besoins de la prochaine révision de 
      <em>stable</em>.
    </p>
   </sect1>
   <sect1 id="upload-t-p-u">
    <heading>
      Cas spécial&nbsp;: mise à jour d'un paquet de la distribution 
      <em>testing</em>/<em>testing-proposed-updates</em>
    </heading>
    <p>
      Veuillez consulter les informations dans la <qref id="t-p-u">section 
      sur <em>testing</em></qref> pour des détails.
    </p>
   </sect1>
  </sect>
  <sect id="upload">
   <heading>
     Mettre à jour un paquet
   </heading>
   <sect1 id="upload-ftp-master">
    <heading>
      Installer un paquet sur <tt>ftp-master</tt>
    </heading>
    <p>
      Pour installer un paquet, vous devez envoyer les fichiers (y compris 
      les fichiers changes et dsc signés) par ftp anonyme sur 
      <ftpsite>&ftp-master-host;</ftpsite> dans le répertoire 
      &upload-queue;. Pour que les fichiers y soient traités, ils doivent 
      être signés avec une clé du porte-clés (<em>keyring</em>) Debian.
    </p>
    <p>
      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.
    </p>
    <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 paquets vers 
      Debian
    </p>
    <p>
      Pour supprimer des paquets, veuillez lire le fichier README dans ce 
      répertoire FTP et le paquet Debian <ref id="dcut">.
    </p>
   </sect1>
   <sect1 id="upload-non-us">
    <heading>
      Installer un paquet sur <tt>non-US</tt>
    </heading>
    <p>
      <em>Note&nbsp;:</em> non-us a été interrompu avec la publication de 
      <em>Sarge</em>.
    </p>
   </sect1>
   <sect1 id="delayed-incoming">
    <heading>
      Envois différés
    </heading>
    <p>
      Les envois différés sont pour le moment réalisés <em>via</em> la file 
      différée sur gluck. Le répertoire d'envoi est 
      <ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>. 0-day est 
      envoyé approximativement plusieurs fois par jour vers ftp-master.
    </p>
    <p>
      Avec une version assez récente de dput, cette section
     <example>
[tfheen_delayed]
method = scp
fqdn = gluck.debian.org
incoming = ~tfheen
</example>
      dans votre fichier ~/.dput.cf devrait fonctionner correctement pour 
      réaliser des envois dans la file DELAYED.
    </p>
    <p>
      <em>Note&nbsp;:</em> Comme la file d'envoi va sur <tt>ftp-master</tt>, 
      la prescription que l'on trouve dans <ref id="upload-ftp-master"> 
      s'applique également ici.
    </p>
   </sect1>
   <sect1>
    <heading>
      Envois de sécurité
    </heading>
    <p>
      N'envoyez <strong>PAS</strong> un paquet vers la file d'envoi de sécurité 
      (<em>oldstable-security</em>, <em>stable-security</em>, etc.) sans 
      avoir obtenu au préalable l'autorisation de l'équipe de sécurité. Si 
      le paquet ne correspond pas tout à fait aux besoins de cette équipe, 
      il entraînera beaucoup de problèmes et de délais dans la gestion de 
      cet envoi non désiré. Pour plus de détails, consultez la section <ref 
      id="bug-security">.
    </p>
   </sect1>
   <sect1>
    <heading>
      Les autres files d'envoi
    </heading>
    <p>
      Les files scp sur ftp-master et security sont pratiquement 
      inutilisables à cause des restrictions de connexion sur ces hôtes.
    </p>
    <p>
      Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont 
      actuellement arrêtées. Un travail est en cours pour les restaurer.
    </p>
    <p>
      Les files sur master.debian.org, samosa.debian.org, 
      master.debian.or.jp et ftp.chiark.greenend.org.uk sont arrêtées de 
      façon permanente et ne seront pas restaurées. La file du Japon sera 
      remplacée par une nouvelle file sur hp.debian.or.jp un jour.
    </p>
    <p>
      À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le 
      précédent ftp-master) fonctionne, mais elle est déconseillée et sera 
      supprimée à un moment donné.
    </p>
   </sect1>
   <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>
    <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>
    <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).
    </p>
    <p>
      Notez que si vous envoyez <em>via</em> les files, le logiciel de démon 
      de file vous enverra également une notification par courriel.
    </p>
   </sect1>
  </sect>
  <sect id="override-file">
   <heading>
     Spécifier la section, la sous-section et la priorité d'un paquet
   </heading>
   <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>
   <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 pourrez vouloir modifier le fichier <em>override</em>.
   </p>
   <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>
   <p>
     Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à 
     <manref section="1" name="dpkg-scanpackages"> et <url 
     id="&url-bts-devel;#maintincorrect">.
   </p>
   <p>
     Notez que le champ <tt>Section</tt> décrit à la fois la section et la 
     sous-section, comme décrit dans <ref id="archive-sections">. Si la 
     section est «&nbsp;main&nbsp;», elle devrait être omise. La liste des 
     sous-sections autorisées peut être trouvée dans <url 
     id="&url-debian-policy;ch-archive.html#s-subsections">.
   </p>
  </sect>
  <sect id="bug-handling">
   <heading>
     Gérer les bogues
   </heading>
   <p>
     Chaque développeur doit être capable de travailler avec le <url 
     id="&url-bts;" name="système de suivi des bogues"> Debian. Il faut 
     savoir comment remplir des rapports de bogue correctement (voir <ref 
     id="submit-bug">), comment les mettre à jour et les réordonner et 
     comment les traiter et les fermer.
   </p>
   <p>
     Les fonctionnalités du système de suivi des bogues sont décrites dans 
     la <url id="&url-bts-devel;" name="documentation du BTS pour les 
     développeurs">. Ceci inclut la fermeture des bogues, l'envoi des 
     messages de suivi, l'assignation des niveaux de gravité et des marques, 
     l'indication que les bogues ont été envoyés au développeur amont et 
     autres problèmes.
   </p>
   <p>
     Des opérations comme réassigner des bogues à d'autres paquets, réunir 
     des rapports de bogues séparés traitant du même problème ou rouvrir des 
     bogues quand ils ont été prématurément fermés, sont gérées en utilisant 
     le serveur de courrier de contrôle. Toutes les commandes disponibles 
     pour ce serveur sont décrites dans la <url id="&url-bts-control;" 
     name="documentation du serveur de contrôle du BTS">.
   </p>
   <sect1 id="bug-monitoring">
    <heading>
      Superviser les rapports de bogue
    </heading>
    <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>votre_compte</var>@debian.org</tt>.
    </p>
    <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>
    <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;:
     <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.
    </p>
   </sect1>
   <sect1 id="bug-answering">
    <heading>
      Répondre à des rapports de bogue
    </heading>
    <p>
      Lorsque vous répondez à des rapports de bogue, 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-host;</email> par 
      exemple). Si vous rédigez un nouveau courrier et si vous ne vous 
      souvenez plus de l'adresse du rapporteur de bogue, vous pouvez 
      utiliser l'adresse <email>123-submitter@&bugs-host;</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-host;</email>).
    </p>
    <p>
      Si vous recevez un bogue mentionnant «&nbsp;FTBFS&nbsp;», cela veut 
      dire «&nbsp;Fails To Build From Source&nbsp;» (Erreur de construction 
      à partir du source). Les porteurs emploient fréquemment cet acronyme.
    </p>
    <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-host;</email>. Si vous corrigez un bogue en 
      changeant et en envoyant une nouvelle version du paquet, vous pouvez 
      fermer le bogue automatiquement comme décrit dans <ref 
      id="upload-bugfix">.
    </p>
    <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.
    </p>
   </sect1>
   <sect1 id="bug-housekeeping">
    <heading>
      Gestion générale des bogues
    </heading>
    <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 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 serveur de contrôle 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>
    <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>
    <p>
      Voici une liste des étapes que vous pouvez suivre pour gérer un 
      rapport de bogue&nbsp;:
     <enumlist numeration="arabic">
      <item>
       <p>
         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 discuté 
         avec l'auteur amont.
       </p>
       <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">.
       </p>
      </item>
      <item>
       <p>
         Si le 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 <qref id="irc-channels">IRC</qref> ou sur 
         &email-debian-devel;. Veuillez vous assurer que le (ou les) 
         responsable(s) du paquet sur lequel est réattribué le paquet sait 
         pourquoi vous l'avez ainsi réattribué.
       </p>
       <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.
       </p>
      </item>
      <item>
       <p>
         Si le bogue est réel, mais que le problème a déjà été rapporté par 
         quelqu'un d'autre, les deux rapports de bogues pertinents devraient 
         être fusionnés en un seul en utilisant la commande <tt>merge</tt> 
         (fusion) du BTS. Ainsi, quand le bogue sera corrigé, tous les 
         créateurs de rapport de bogue en seront informés (notez, cependant, 
         que les courriels envoyés à l'un des créateurs de rapport de bogue 
         ne seront pas automatiquement envoyés aux autres créateurs de 
         rapport de bogue). Pour plus de détails sur les technicités de la 
         commande de fusion et sa voisine, la commande <tt>unmerge</tt> 
         (séparation), veuillez consulter la documentation du serveur de 
         contrôle du BTS.
       </p>
      </item>
      <item>
       <p>
         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'information) 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é.
       </p>
      </item>
      <item>
       <p>
         Si le bogue est lié à l'empaquetage, 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).
       </p>
      </item>
      <item>
       <p>
         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.
       </p>
      </item>
      <item>
       <p>
         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">.
       </p>
      </item>
     </enumlist>
    </p>
   </sect1>
   <sect1 id="upload-bugfix">
    <heading>
      Quand les rapports de bogue sont-ils fermés par une mise à jour&nbsp;?
    </heading>
    <p>
      Au fur et à mesure que les bogues et problèmes sont corrigés dans vos 
      paquets, il est de votre responsabilité en tant que responsable du 
      paquet de fermer les rapports de bogue associés. Cependant, vous ne 
      devez pas les fermer avant que le paquet n'ait été accepté dans 
      l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore les 
      rapports 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. Le bogue devrait être fermé avec la bonne version.
    </p>
    <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 man page. Closes: #98725.
</example>
      Techniquement parlant, l'expression rationnelle Perl suivante décrit 
      comment les lignes de <em>changelogs</em> de fermeture de bogues sont 
      identifiées&nbsp;:
     <example>
  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
</example>
      Nous préférons la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est 
      l'entrée la plus concise et la plus facile à intégrer dans le texte du 
      fichier <file>changelog</file>.
    </p>
    <p>
      À moins que cela soit spécifié différemment par l'option <var>-v</var> de
      <prgn>dpkg-buildpackage</prgn>, seuls les bogues fermés dans l'entrée de
      changelog la plus récente sont fermés (fondamentalement, seuls les
      bogues mentionnés dans la partie de changelog du fichier
      <file>.changes</file> sont fermés).
    </p>
    <p>
    <!-- les bogues des envois ... ? -->
      Historiquement, les envois identifiés comme <qref id="nmu">Mise à jour
      indépendante</qref> («&nbsp;Non-maintainer upload&nbsp;» ou NMU) étaient
      marqués comme <tt>fixed</tt> au lieu d'être fermés, mais cette pratique
      a cassé avec l'ajout du suivi des versions. Le même raisonnement
      s'applique à l'étiquette <tt>fixed-in-experimental</tt>.
    </p>
    <p>
      Si vous entrez un numéro de bogue incorrect ou si vous oubliez un 
      bogue dans les entrées du fichier <file>changelog</file>, n'hésitez 
      pas à annuler tout dommage que l'erreur a entraîné. Pour rouvrir un 
      bogue fermé par erreur, envoyez une commande <tt>reopen 
      <var>XXX</var></tt> à l'adresse de contrôle du système de suivi des 
      bogues, &email-bts-control;. Pour fermer tous les bogues restants qui 
      ont été corrigés par votre envoi, envoyez le fichier 
      <file>.changes</file> à <email>XXX-done@&bugs-host;</email> où 
      <var>XXX</var> est le numéro du bogue et placez «&nbsp;Version:
      YYY&nbsp;» et une ligne vide dans les deux premières lignes du corps du
      courrier où <var>YYY</var> est la première version dans laquelle le
      bogue a été corrigé.
    </p>
    <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. 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-host;</email>. Vous <strong>ne devez 
      pas</strong> pas fermer des bogues dans une entrée de changelog d'une 
      version si les changements dans cette version n'ont rien à voir avec 
      le bogue.
    </p>
    <p>
      Pour une information plus générale sur ce qu'il faut mettre dans les 
      entrées de changelog, veuillez vous reporter aux <ref 
      id="bpp-debian-changelog">.
    </p>
   </sect1>
   <sect1 id="bug-security">
    <heading>
      Gérer les bogues de sécurité
    </heading>
    <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.
    </p>
    <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; dès que 
      possible. <strong>N'ENVOYEZ PAS</strong> de paquet pour 
      <em>stable</em>&nbsp;; l'équipe de sécurité le fera. Les informations 
      utiles incluent, par exemple&nbsp;:
     <list compact="compact">
      <item>
       <p>
         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>,
       </p>
      </item>
      <item>
       <p>
         la nature d'une solution si elle est disponible (les correctifs 
         sont particulièrement utiles),
       </p>
      </item>
      <item>
       <p>
         tout paquet corrigé que vous avez vous-même préparé (envoyez 
         seulement les fichiers <file>.diff.gz</file> et <file>.dsc</file> 
         et lisez d'abord <ref id="bug-security-building">),
       </p>
      </item>
      <item>
       <p>
         toute assistance que vous pouvez fournir pour aider les tests 
         (exploits, tests de régression, etc.),
       </p>
      </item>
      <item>
       <p>
         toute information nécessaire pour l'annonce de sécurité (voir <ref 
         id="bug-security-advisories">).
       </p>
      </item>
     </list>
    </p>
    <sect2 id="bug-security-confidentiality">
     <heading>
       Confidentialité
     </heading>
     <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. Ceci permet aux distributeurs 
       de logiciels de coordonner leur dévoilement afin de minimiser 
       l'exposition de leurs utilisateurs. 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>
     <p>
       Il existe plusieurs façons pour un développeur de prendre 
       connaissance d'un problème de sécurité&nbsp;:
      <list compact="compact">
       <item>
        <p>
          il le remarque sur un forum public (liste de diffusion, site web, 
          etc.),
        </p>
       </item>
       <item>
        <p>
          quelqu'un remplit un rapport de bogue,
        </p>
       </item>
       <item>
        <p>
          quelqu'un l'informe par courrier privé.
        </p>
       </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>
        <p>
          si l'exposition de sécurité est mineure, il n'y a parfois pas 
          besoin de garder le secret sur le problème et une correction 
          devrait être effectuée et diffusée,
        </p>
       </item>
       <item>
        <p>
          si le problème est grave, il est préférable de partager cette 
          information avec d'autres vendeurs et de coordonner une 
          publication. L'équipe de sécurité reste en contact avec les 
          différentes organisations et individus et peut prendre soin des 
          actions à mener.
        </p>
       </item>
      </list>
     </p>
     <p>
       Dans tous les cas, si la personne qui indique le problème demande à 
       ce que l'information ne soit pas diffusée, cela devrait être respecté 
       avec l'évidente exception d'informer l'équipe de sécurité pour qu'une 
       correction puisse être effectuée pour la version stable de 
       Debian. Quand vous envoyez des informations confidentielles à 
       l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
     </p>
     <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>
     <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.
     </p>
    </sect2>
    <sect2 id="bug-security-advisories">
     <heading>
       Annonces de sécurité
     </heading>
     <p>
       Les annonces de sécurité ne sont émises que pour la distribution 
       actuelle diffusée <em>stable</em>, <em>PAS</em> 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 
       les membres de 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="compact">
       <item>
        <p>
          une description du problème et de sa portée, y compris&nbsp;:
         <list>
          <item>
           <p>
             le type du problème (usurpation de privilège, déni de service, 
             etc.),
           </p>
          </item>
          <item>
           <p>
             quels sont les privilèges obtenus et par quels utilisateurs (si 
             c'est le cas)
           </p>
          </item>
          <item>
           <p>
             comment il peut être exploité,
           </p>
          </item>
          <item>
           <p>
             si le problème peut être exploité à distance ou localement,
           </p>
          </item>
          <item>
           <p>
             comment le problème a été corrigé,
           </p>
          </item>
         </list>
          Ces informations permettent aux utilisateurs d'estimer la menace 
          pesant sur leurs systèmes.
        </p>
       </item>
       <item>
        <p>
          les numéros de version des paquets affectés,
        </p>
       </item>
       <item>
        <p>
          les numéros de version des paquets corrigés,
        </p>
       </item>
       <item>
        <p>
          une information sur la façon de récupérer les paquets mis à jour 
          (habituellement l'archive de sécurité Debian),
        </p>
       </item>
       <item>
        <p>
          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é.
        </p>
       </item>
      </list>
     </p>
    </sect2>
    <sect2 id="bug-security-building">
     <heading>
       Préparer les paquets pour corriger des problèmes de sécurité
     </heading>
     <p>
       Une façon d'aider l'équipe de sécurité dans ses travaux est de lui 
       fournir des paquets corrigés convenables pour une annonce de sécurité 
       pour la version <em>stable</em> de Debian
     </p>
     <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 
       diffusé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, aussi minimal que soit le changement.
     </p>
     <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étroporté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>
     <p>
       Dans certains cas, il n'est pas possible de rétroporter 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, ceci 
       n'est fait que dans des situations extrêmes et vous devez toujours 
       coordonner cela avec l'équipe de sécurité au préalable.
     </p>
     <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-la 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>
     <p>
       N'incluez <strong>PAS</strong> de changements dans votre paquet qui 
       ne soient pas liés directement à la correction de la 
       vulnérabilité. Ceux-ci devraient être ensuite enlevés et cela perd du 
       temps. S'il y a d'autres bogues dans votre paquet que vous aimeriez 
       corriger, faites un envoi vers proposed-updates de la façon 
       habituelle, après l'envoi de l'alerte de sécurité. Le mécanisme de 
       mise à jour de sécurité n'est pas un moyen d'introduire des 
       changements dans votre paquet qui seraient sinon rejetés de la 
       distribution stable, n'essayez donc pas de faire cela, s'il vous 
       plaît.
     </p>
     <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> du paquet <package>patchutils</package> et 
       <prgn>debdiff</prgn> du paquet <package>devscripts</package> sont des 
       outils utiles pour cela, voir <ref id="debdiff">).
     </p>
     <p>
       Assurez-vous de conserver les points suivants à l'esprit&nbsp;:
      <list>
       <item>
        <p>
          Ciblez 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 ni 
          <var>distribution</var>-proposed-updates, ni 
          <tt>stable</tt>&nbsp;!
        </p>
       </item>
       <item>
        <p>
          L'envoi devra avoir «&nbsp;urgency=high&nbsp;».
        </p>
       </item>
       <item>
        <p>
          Fournissez des entrées de changelog descriptives et 
          complètes. D'autres personnes se baseront dessus pour déterminer 
          si un bogue particulier a été corrigé. Incluez toujours une 
          référence externe, de préférence un identifiant CVE, pour qu'elle 
          puisse être recoupée. Incluez la même information dans le 
          changelog pour <em>unstable</em> pour qu'il soit clair que le même 
          bogue a été corrigé car cela est très utile pour vérifier que le 
          bogue a été corrigé pour la prochaine version stable. Si aucun 
          identifiant CVE n'a encore été assigné, l'équipe de sécurité en 
          demandera un pour qu'il puisse être inclus dans le paquet et dans 
          le changelog.
        </p>
       </item>
       <item>
        <p>
          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>. Soyez attentif à 
          ne pas ré-utiliser un numéro de version que vous auriez déjà 
          utilisé pour un précédent envoi. 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.
        </p>
       </item>
       <item>
        <p>
          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.
        </p>
       </item>
       <item>
        <p>
          Sauf 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 avec la source amont complète 
          (<tt>dpkg-buildpackage -sa</tt>). S'il y a déjà eu un précédent 
          envoi à security.debian.org, vous pouvez faire un envoi sans le 
          paquet source (<tt>dpkg-buildpackage -sd</tt>).
        </p>
       </item>
       <item>
        <p>
          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.
        </p>
       </item>
       <item>
        <p>
          Compilez le paquet 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">).
        </p>
       </item>
      </list>
     </p>
    </sect2>
    <sect2 id="bug-security-upload">
     <heading>
       Mettre à jour le paquet corrigé
     </heading>
     <p>
       Vous <em>NE</em> devez <em>PAS</em> envoyer un paquet dans la file 
       d'attente des envois de sécurité (oldstable-security, 
       stable-security, etc.) sans l'accord préalable de l'équipe de 
       sécurité. Si le paquet ne remplit pas exactement les exigences de 
       l'équipe, il causera beaucoup de problèmes, ainsi que des délais dans 
       la gestion de l'envoi indésirable.
     </p>
     <p>
       Vous <em>NE</em> devez <em>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>
     <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-master.debian.org/pub/SecurityUploadQueue/</tt>.
     </p>
     <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>
     <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é qui ne 
       peuvent pas encore être diffusés.
     </p>
     <p>
       Si une personne de l'équipe de sécurité accepte un paquet, il sera 
       installé sur security.debian.org et proposé pour le répertoire 
       <var>distribution</var>-proposed-updates qui convient sur ftp-master.
     </p>
    </sect2>
   </sect1>
  </sect>
  <sect id="archive-manip">
   <heading>
     Déplacer, effacer, changer le nom, adopter et abandonner des paquets
   </heading>
   <p>
     Certaines manipulations de l'archive ne sont pas possibles 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.
   </p>
   <sect1 id="moving-pkgs">
    <heading>
      Déplacer des paquets
    </heading>
    <p>
      Il se peut qu'un paquet puisse 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é.</p></footnote>.
    </p>
    <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 à la <url id="&url-debian-policy;" 
      name="charte Debian"> pour en savoir plus. Vous devez vous assurer
      d'inclure le fichier <file>.orig.tar.gz</file> dans votre envoi (même si
      vous n'envoyez pas de nouvelle version amon) ou il n'apparaîtra pas dans
      la nouvelle section avec le reste du paquet. Si votre nouvelle section 
      est valide, il sera déplacé automatiquement. Si ce n'est pas le cas, 
      contactez les responsables ftp pour comprendre ce qui s'est passé.
    </p>
    <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">.
    </p>
   </sect1>
   <sect1 id="removing-pkgs">
    <heading>
      Supprimer des paquets
    </heading>
    <p>
      Si, pour une raison ou une autre, vous avez besoin de supprimer 
      complètement 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&nbsp;; comme pour tous les bogues, ce bogue devrait être 
      de gravité normale. N'oubliez pas de préciser de quelle distribution 
      le paquet doit être supprimé. Normalement, vous ne devriez avoir à 
      supprimer que des paquets d'<em>unstable</em> ou 
      d'<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é d'<em>unstable</em> et si aucun paquet de 
      <em>testing</em> n'en dépend.
    </p>
    <p>
      Il existe une exception pour laquelle il n'est pas nécessaire de faire
      une demande explicite de suppression&nbsp;: si un paquet (source ou
      binaire) est orphelin, il sera supprimé de façon semi-automatique. Pour
      un paquet binaire, cela veut dire s'il n'y a plus de paquet source
      produisant le paquet binaire&nbsp;; si le paquet binaire n'est
      simplement plus produit pour certaines architectures, une demande de
      suppression est toujours nécessaire. Pour un paquet source, cela veut
      dire que tous les paquets binaires auxquels il se réfère ont été
      récupérés par un autre paquet source.
    </p>
    <p>
      Vous devez détailler dans votre demande de suppressions 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>
    <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 responsable.
    </p>
    <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>paquet</var> </tt> vous indiquera, entre autres, les paquets qui 
      dépendent de <var>paquet</var>.
      Parmi d'autres programmes utiles, citons <tt>apt-cache rdepends</tt>,
      <prgn>apt-rdepends</prgn> et <prgn>grep-dctrl</prgn>.
      Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
    </p>
    <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.
    </p>
    <sect2>
     <heading>
       Supprimer des paquets dans <tt>Incoming</tt>
     </heading>
     <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 plus élevé que 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.
     </p>
    </sect2>
   </sect1>
   <sect1>
    <heading>
      Remplacer un paquet ou changer son nom
    </heading>
    <p>
      Si vous vous trompez en nommant un paquet, vous devrez intervenir en 
      deux étapes pour changer son nom. 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 demandez la suppression du paquet mal 
      nommé. N'oubliez pas de réattribuer correctement les bogues du paquet 
      en même temps.
    </p>
    <p>
      D'autres fois, vous pouvez commettre une erreur en construisant le 
      paquet et vous 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 aide à garantir la 
      consistance dans le réseau des miroirs.
    </p>
   </sect1>
   <sect1 id="orphaning">
    <heading>
      Abandonner un paquet
    </heading>
    <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é.</p></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>&nbsp;; si le 
      paquet a une priorité standard ou supérieure, elle devrait être 
      <em>importante</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>
    <p>
      Si vous avez simplement l'intention de donner le paquet, mais que vous 
      pouvez conserver sa maintenance pour le moment, vous devriez à la 
      place soumettre un rapport de bogue sur <package>wnpp</package> et 
      l'intituler <tt>RFA: <var>paquet</var> -- <var>description 
      courte</var></tt>. <tt>RFA</tt> veut dire <em>Request For 
      Adoption</em> (demande d'adoption).
    </p>
    <p>
      Vous pouvez trouver plus d'informations sur les <url id="&url-wnpp;" 
      name="pages web WNPP"><footnote><p><em>Work-needing and prospective 
      packages</em>&nbsp;: paquets en souffrance et paquets 
      souhaités.</p></footnote>.
    </p>
   </sect1>
   <sect1 id="adopting">
    <heading>
      Adopter un paquet
    </heading>
    <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>
    <p>
      Prendre un paquet parce qu'il vous semble que celui-ci est négligé 
      n'est pas correct &mdash;&nbsp;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. Si vous avez le 
      sentiment qu'un responsable est parti sans prévenir depuis un moment, 
      veuillez vous reporter à <ref id="mia-qa">).
    </p>
    <p>
      Généralement, vous ne pouvez pas adopter un paquet sans l'accord du 
      responsable actuel. Même s'il vous ignore, ce n'est pas une raison 
      pour le faire. Les plaintes à propos des responsables devraient être 
      portées sur la liste de diffusion des développeurs. Si la discussion 
      ne se termine pas par une conclusion positive et que le problème est 
      de nature technique, envisagez de porter le cas à l'attention du 
      comité technique (voir la <url id="&url-tech-ctte;" name="page web du 
      comité technique"> pour plus d'information).
    </p>
    <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 le <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.
    </p>
   </sect1>
  </sect>
  <sect id="porting">
   <heading>
     Le portage
   </heading>
   <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>
   <p>
     Porter un paquet consiste à faire un paquet binaire pour des 
     architectures différentes 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.
   </p>
   <sect1 id="kind-to-porters">
    <heading>
      Être courtois avec les porteurs
    </heading>
    <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>
    <p>
      Ici, la première et la plus importante chose 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>
    <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 numeration="arabic">
      <item>
       <p>
         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> (voir <ref 
         id="debootstrap">). 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 (voir <ref 
         id="pbuilder">).
       </p>
       <p>
         Si vous n'arrivez pas à installer un environnement 
         <em>chrooté</em>, <prgn>dpkg-depcheck</prgn> pourra peut-être vous 
         aider (voir <ref id="dpkg-depcheck">).
       </p>
       <p>
         Consultez la <url id="&url-debian-policy;" name="charte Debian"> 
         pour en savoir plus sur les dépendances de fabrication.
       </p>
      </item>
      <item>
       <p>
         Ne choisissez pas d'autres valeurs 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.
       </p>
      </item>
      <item>
       <p>
         Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x 
         <var>paquet</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>.
       </p>
      </item>
      <item>
       <p>
         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>.
       </p>
      </item>
      <item>
       <p>
         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.
       </p>
      </item>
      <item>
       <p>
         Ne vous appuyez pas sur une installation préexistante de votre 
         paquet (un sous-cas de la remarque précédente).
       </p>
      </item>
      <item>
       <p>
         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.
       </p>
      </item>
      <item>
       <p>
         Vérifiez que votre fichier <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>.
       </p>
      </item>
     </enumlist>
    </p>
   </sect1>
   <sect1 id="porter-guidelines">
    <heading>
      Instructions pour les mises à jour des porteurs
    </heading>
    <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>
    <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>
    <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>.
    </p>
    <p>
      Si vous travaillez sur une machine Debian pour vos efforts de portage 
      et que vous devez signer votre envoi localement pour son acceptation 
      dans l'archive, vous pouvez exécuter <prgn>debsign</prgn> sur votre 
      fichier <file>.changes</file> pour qu'il soit signé de manière commode 
      ou utilisez le mode de signature à distance de <prgn>dpkg-sig</prgn>.
    </p>
    <sect2 id="binary-only-nmu">
     <heading>
       Mises à jour indépendantes binaires ou recompilations
     </heading>
     <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).
     </p>
     <p>
       Vous devez vous assurer que votre mise à jour indépendante binaire ne 
       rend pas le paquet non installable. Cela peut arriver si un paquet 
       source génère des paquets dépendants et indépendants de 
       l'architecture qui dépendent les uns des autres <em>via</em> 
       $(Source-Version).
     </p>
     <p>
       Malgré les modifications nécessaires du changelog, ce type de mise à 
       jour reste une mise à jour indépendante binaire &mdash;&nbsp;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>
     <p>
       Ces recompilations nécessitent des numéros de version 
       «&nbsp;magiques&nbsp;» pour que le système de maintenance de 
       l'archive comprenne 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>
     <p>
       La «&nbsp;magie&nbsp;» d'une mise à jour indépendante par 
       recompilation uniquement est déclenchée par l'utilisation d'un 
       suffixe ajouté au numéro de version du paquet de la forme 
       b&lt;numéro&gt;. Par exemple, si la dernière version que vous avez 
       recompilée était la version 2.9.3, votre mise à jour indépendante 
       aura le numéro de version 2.9-3+b1. Si la dernière version était 
       3.4+b1 (i.e. un paquet natif avec une précédente mise à jour 
       indépendante par recompilation), votre mise à jour indépendant aura 
       le numéro de version 3.4+b2. <footnote><p>Par le passé, de telles 
       mises à jour indépendantes utilisaient le numéro de troisième niveau 
       de la partie Debian de la révision pour dénoter l'état de 
       recompilation uniquement&nbsp;; cependant, cette syntaxe était 
       ambigüe pour les paquets natifs et ne permettait pas un ordre correct 
       des mises à jour indépendantes par recompilation uniquement, des 
       mises à jour indépendantes de source et des mises à jour 
       indépendantes de sécurité sur le même paquet et elle a donc été 
       abandonnée en faveur de cette nouvelle syntaxe.</p></footnote>
     </p>
     <p>
       De manière similaire aux envois du porteur initial, la façon correcte 
       d'invoquer <prgn>dpkg-buildpackage</prgn> est <tt>dpkg-buildpackage 
       -B</tt> pour ne construire que les parties dépendant de 
       l'architecture du paquet.
     </p>
    </sect2>
    <sect2 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. Elle varie 
       également selon que l'architecture est candidate pour inclusion dans 
       la prochaine version stable&nbsp;; les responsables de publication 
       décident et annoncent quelles architectures sont candidates.
     </p>
     <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;&nbsp;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>&nbsp;&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). Pour les envois de 
       <em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous 
       coordonner avec l'équipe de publication appropriée.
     </p>
     <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>
     <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>
     <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.
     </p>
    </sect2>
   </sect1>
   <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>
     <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ées 
       dans les <ref id="tools-porting">.
     </p>
    </sect2>
    <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>
     <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>
     <p>
       Une partie des informations produites par <package>buildd</package> 
       &mdash;&nbsp;utiles pour les porteurs&nbsp;&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>
     <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;&nbsp;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.
     </p>
     <p>
       Les administrateurs des buildds pour chaque architecture peuvent être 
       contactés à l'adresse électronique $arch@buildd.debian.org.
     </p>
    </sect2>
   </sect1>
   <sect1 id="packages-arch-specific">
    <heading>
      Quand votre paquet <em>n'est pas</em> portable
    </heading>
    <p>
      Certains paquets ont encore des problèmes pour être construits et/ou 
      pour fonctionner sur certaines des architectures prises en charge par 
      Debian et ne peuvent pas du tout être portés, ou pas dans un laps de 
      temps raisonnable. Un exemple est un paquet qui est spécifique SGVA 
      (i386 seulement) ou qui utilise des fonctionnalités spécifiques au 
      matériel qui ne sont pas gérées sur toutes les architectures.
    </p>
    <p>
      Pour éviter que des paquets cassés soient envoyés dans l'archive et 
      qu'ils fassent perdre du temps des buildd, vous devez faire plusieurs 
      choses&nbsp;:
    </p>
    <p>
     <list>
      <item>
       <p>
         Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la 
         compilation sur les architectures qu'il ne gère pas. Il y a 
         plusieurs moyens de faire cela. Le moyen préféré est d'avoir une 
         petite suite de tests pendant la construction qui testera la 
         fonctionnalité et qui échouera si cela ne fonctionne pas. C'est de 
         toute façon une bonne idée et empêchera des (certains) envois 
         cassés pour toutes les architectures, et cela permettra également 
         au paquet d'être construit dès que la fonctionnalité nécessaire est 
         disponible.
       </p>
       <p>
         De plus, si vous croyez que la liste des architectures gérées est 
         plutôt constante, vous devriez changer «&nbsp;any&nbsp;» en une 
         liste des architectures gérées dans le fichier 
         <file>debian/control</file>. Ainsi, la construction échouera 
         également et l'indiquera à un lecteur humain sans vraiment essayer.
       </p>
      </item>
      <item>
       <p>
         Pour empêcher les compilateurs automatiques de tenter sans raison 
         de construire votre paquet, il doit être inclus dans 
         <file>packages-arch-specific</file>, une liste utilisée par le 
         script <prgn>wanna-build</prgn>. La version actuelle est disponible 
         à <url 
         id="http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak">&nbsp;; 
         veuillez consulter le début du fichier pour savoir qui contacter 
         pour le modifier.
       </p>
      </item>
     </list>
    </p>
    <p>
      Veuillez noter qu'il est insuffisant de simplement ajouter votre 
      paquet à Packages-arch-specific sans le faire également échouer lors 
      de compilation sur les architectures non gérées&nbsp;: un porteur ou 
      toute autre personne essayant de construire votre paquet peut 
      accidentellement l'envoyer sans remarquer qu'il ne fonctionne pas. Si 
      dans le passé, certains paquets binaires ont été envoyés pour des 
      architectures non gérées, demandez leur suppression en remplissant un 
      bogue sur <package>ftp.debian.org</package>.
    </p>
   </sect1>
  </sect>
  <sect id="nmu">
   <heading>
     Mise à jour indépendante
   </heading>
   <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>
   <p>
     Cette section ne traite que des mises à jour indépendantes de source, 
     c.-à-d., les mises à jour qui envoient une nouvelle version d'un 
     paquet. Pour les mises à jour indépendantes par des porteurs ou des 
     membres de la QA, veuillez consulter <ref id="binary-only-nmu">. Si un 
     buildd construit et envoie un paquet, cela est également à strictement 
     parler une NMU binaire. Veuillez consulter <ref id="buildd"> pour plus 
     d'informations.
   </p>
   <p>
     La raison principale pour laquelle une mise à jour indépendante est 
     réalisée est quand un développeur a besoin de corriger le paquet d'un 
     autre développeur pour résoudre des problèmes sérieux ou des bogues 
     paralysants ou quand le responsable d'un paquet ne peut pas fournir une 
     correction dans un délai raisonnable.
   </p>
   <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.
   </p>
   <p>
     Et souvenez-vous du Serment d'Hippocrate&nbsp; «&nbsp;Par dessus tout, 
     ne pas faire de mal&nbsp;». Il est préférable de laisser un paquet avec 
     un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel 
     ou un correctif qui cache le bogue sans le résoudre.
   </p>
   <sect1 id="nmu-guidelines">
    <heading>
      Comment faire une mise à jour indépendante&nbsp;?
    </heading>
    <p>
      Les mises à jour indépendantes qui corrigent des bogues de gravité 
      importante, sérieuse et plus élevée sont encouragées et 
      acceptées. Vous devriez vous efforcer de contacter le responsable 
      actuel du paquet&nbsp;: il est peut-être sur le point d'envoyer un 
      correctif pour le problème ou il a peut-être une meilleure solution.
    </p>
    <p>
      Les mises à jour indépendantes doivent être réalisées pour assister un 
      responsable de paquet à résoudre des bogues. Les responsables 
      devraient être reconnaissants pour cette aide et les personnes faisant 
      la mise à jour indépendante devraient respecter les décisions du 
      responsable et tenter d'aider personnellement le responsable dans son 
      travail.
    </p>
    <p>
      Une mise à jour indépendante devrait suivre toutes les conventions 
      décrites dans cette section. Pour un envoi vers <em>testing</em> ou 
      <em>unstable</em>, l'ordre suivant des étapes est recommandé&nbsp;:
    </p>
    <p>
     <list>
      <item>
       <p>
         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.
       </p>
      </item>
      <item>
       <p>
         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;».
       </p>
      </item>
      <item>
       <p>
         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 cette section et testez-la soigneusement sur 
         votre machine (cf. <ref id="sanitycheck">). 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.
       </p>
      </item>
      <item>
       <p>
         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.
       </p>
      </item>
      <item>
       <p>
         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.
       </p>
      </item>
     </list>
    </p>
    <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. Veuillez vous 
      reporter à <ref id="qa-bsp"> pour des détails.
    </p>
    <p>
      Pour la distribution <em>testing</em>, les règles peuvent être 
      changées par les responsables de publication. Veuillez porter une 
      attention spéciale au fait que le moyen habituel pour un paquet 
      d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
    </p>
    <p>
      Pour la distribution <em>stable</em>, veuillez y apporter une 
      attention supplémentaire. Bien sûr, les responsables de publication 
      peuvent également modifier les règles ici. Veuillez vérifier avant 
      votre envoi que tous vos changements sont acceptables pour inclusion 
      dans la prochaine version stable par le responsable de publication.
    </p>
    <p>
      Quand un bogue de sécurité est détecté, l'équipe de sécurité peut 
      effectuer une mise à jour indépendante en utilisant ses propres 
      règles. Veuillez vous référer à <ref id="bug-security"> pour plus 
      d'informations.
    </p>
    <p>
      Pour les différences concernant les mises à jour indépendantes par les 
      porteurs, veuillez voir <ref id="source-nmu-when-porter">.
    </p>
    <p>
      Bien sûr, il est toujours possible de s'accorder avec un responsable 
      pour des règles spéciales (comme quand le responsable demande 
      «&nbsp;merci d'envoyer le correctif directement pour moi et pas de 
      diff nécessaire&nbsp;»).
    </p>
   </sect1>
   <sect1 id="nmu-version">
    <heading>
      Numéro de version pour les mises à jour indépendantes
    </heading>
    <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>
    <p>
      Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez 
      ajouter un numéro de version mineur à la partie 
      <var>révision-debian</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&nbsp;; le nouveau fichier de contrôle du paquet source serait 
      alors <file>foo_1.1-3.1.dsc</file>.
    </p>
    <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>
    <p>
      S'il n'y a pas de partie <var>révision-debian</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 responsable du paquet doit, lui, 
      démarrer sa numérotation à «&nbsp;1&nbsp;».
    </p>
    <p>
      Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, 
      vous devrez parfois créer une branche («&nbsp;fork&nbsp;») dans 
      l'arbre de numéro des version. Pour cela, vous pouvez utiliser des 
      numéros de version comme 1.1-3sarge0.1.
    </p>
   </sect1>
   <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 l'envoi ainsi que la version livrée.
    </p>
    <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&nbsp;:
     <example>
  * Non-maintainer upload
</example>
    </p>
   </sect1>
   <sect1 id="nmu-patch">
    <heading>
      Mise à jour indépendante source et système de suivi des bogues
    </heading>
    <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>
    <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>
    <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 ferment les rapports. 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>
    <p>
      Après avoir fait une mise à jour indépendante, il vous faudra aussi 
      envoyer l'information aux bogues existants que vous avez corrigés 
      par votre NMU en incluant le diff unifié. Historiquement, c'était une
      habitude de créer un 
      nouveau rapport de bogue et inclure un correctif comprenant toutes les 
      modifications que vous avez réalisées. 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>
    <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> &mdash; et bien sûr, également conserver les 
      modifications. Si vous annulez certaines des modifications, veuillez 
      réouvrir les rapports de bogue correspondants.
    </p>
   </sect1>
   <sect1 id="nmu-build">
    <heading>
      Fabriquer une mise à jour indépendante source
    </heading>
    <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="distribution"> 
      en suivant toutes les instructions de la section <ref id="upload">.
    </p>
    <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>.
    </p>
   </sect1>
   <sect1 id="ack-nmu">
    <heading>
      Valider une mise à jour indépendante
    </heading>
    <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. Le moyen le plus simple est 
      d'utiliser l'option <tt>-v</tt> de <prgn>dpkg-buildpackage</prgn> car 
      cela vous permet d'inclure tous les changements depuis votre dernier 
      envoi de responsable. Sinon, 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>
    <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">).
    </p>
   </sect1>
   <sect1 id="nmu-vs-qa">
    <heading>
      Mise à jour indépendante ou envoi de QA&nbsp;?
    </heading>
    <p>
      Sauf si vous savez que le responsable est toujours actif, il est sage 
      de vérifier le paquet pour voir s'il n'a pas été abandonné. La liste 
      actuelle des paquets orphelins pour lesquels le champ responsable n'a 
      pas été positionné correctement est disponible à <url 
      id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour 
      indépendante sur un paquet incorrectement orphelin, veuillez 
      positionner le responsable à «&nbsp;Debian QA Group 
      &lt;packages@qa.debian.org&gt;&nbsp;».
    </p>
   </sect1>
   <sect1 id="nmu-who">
    <heading>
      Qui peut faire une mise à jour indépendante&nbsp;?
    </heading>
    <p>
      Seuls les responsables Debian officiels peuvent faire des mises à jour 
      indépendantes binaire ou source. Un responsable officiel est une 
      personne dont la clé est dans le porte-clés Debian. Tout autre 
      personne est toutefois 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.
    </p>
   </sect1>
   <sect1 id="nmu-terms">
    <heading>
      Terminologie
    </heading>
    <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 deux expressions ont une 
      signification technique précise dans ce document. 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><p>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">).</p></footnote>.
    </p>
    <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>
    <p>
      Une mise à jour indépendante binaire est constituée 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>
    <p>
      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</p></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&nbsp;: utilisez toujours 
      «&nbsp;mise à jour indépendante binaire&nbsp;» ou «NMU binaire&nbsp;» 
      pour les mises à jour indépendantes de binaires seuls.
    </p>
   </sect1>
  </sect>
  <sect id="collaborative-maint">
   <heading>
     Maintenance collective
   </heading>
   <p>
     «&nbsp;Maintenance collective&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>
   <p>
     Habituellement, il y a un responsable principal et un ou plusieurs 
     co-responsables. Le responsable principal est la personne 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>
   <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>.
      </p>
     </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>
Uploaders: John Buzz &lt;jbuzz@debian.org&gt;, Adam Rex &lt;arex@debian.org&gt;
</example>
      </p>
     </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.
      </p>
     </item>
    </list>
   </p>
   <p>
     La maintenance collective peut souvent être facilitée par l'utilisation 
     d'outils sur Alioth (voir <ref id="alioth">).
   </p>
  </sect>
  <sect id="testing">
   <heading>
     La distribution <em>testing</em>
   </heading>
   <p>
   </p>
   <sect1 id="testing-basics">
    <heading>
      Bases
    </heading>
    <p>
      Les paquets sont habituellement installés dans la distribution 
      <em>testing</em> après avoir atteint un certain degré de test dans 
      <em>unstable</em>.
    </p>
    <p>
      Ils doivent être en synchronisation pour toutes les architectures et 
      ne doivent pas avoir de dépendances qui les rendraient non 
      installables&nbsp;; ils doivent également n'avoir aucun bogue bloquant 
      l'inclusion du paquet dans une version stable 
      («&nbsp;release-critical&nbsp;») au moment où ils sont installés dans 
      <em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête 
      pour être une version candidate stable. Veuillez voir ci-dessous pour 
      les détails.
    </p>
   </sect1>
   <sect1 id="testing-unstable">
    <heading>
      Mises à jour depuis <em>unstable</em>
    </heading>
    <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&nbsp;; ces scripts sont appelés <em>britney</em>. Ils fabriquent 
      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 
      bogue.
    </p>
    <p>
      L'inclusion d'un paquet d'<em>unstable</em> est soumise aux conditions 
      suivantes&nbsp;:
     <list>
      <item>
       <p>
         Le paquet doit avoir été disponible dans <em>unstable</em> depuis 
         2, 5 ou 10&nbsp;jours selon le champ d'urgence de l'envoi (élevée, 
         moyenne ou basse). Veuillez noter que cette urgence est 
         «&nbsp;collante&nbsp;» («&nbsp;sticky&nbsp;»), ce qui veut dire que 
         l'envoi avec l'urgence la plus élevée depuis la précédente 
         transition dans <em>testing</em> est prise en compte. Ces délais 
         peuvent être doublés lors d'un gel de distribution, ou les 
         transitions dans <em>testing</em> peuvent être complètement 
         désactivées&nbsp;;
       </p>
      </item>
      <item>
       <p>
         Il doit avoir autant ou moins de bogues empêchant l'intégration 
         dans la distribution que la version actuellement disponible dans 
         <em>testing</em>&nbsp;;
       </p>
      </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;;
       </p>
      </item>
      <item>
       <p>
         Il ne doit pas casser les dépendances d'un paquet qui est déjà 
         disponible dans <em>testing</em>&nbsp;;
       </p>
      </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 remplir tous les critères nécessaires).
       </p>
      </item>
     </list>
    </p>
    <p>
      Pour savoir si un paquet a progressé ou non dans <em>testing</em>, 
      veuillez voir la sortie du script de <em>testing</em> sur la <url 
      id="&url-testing-maint;" name="page web de la distribution testing"> 
      ou utilisez le programme <prgn>grep-excuses</prgn> inclus dans le 
      paquet <package>devscripts</package>. Si vous voulez rester informé de 
      la progression de vos paquets dans <em>testing</em>, vous pouvez 
      facilement le mettre dans la <manref section="5" name="crontab">.
    </p>
    <p>
      Le fichier <file>update_excuses</file> ne donne pas toujours la raison 
      précise pour laquelle un paquet est refusé&nbsp;; 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="page web de la 
      distribution testing"> donne plus d'informations à propos des 
      problèmes courants qui peuvent occasionner cela.
    </p>
    <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. Voir ci-dessous pour des détails.
    </p>
    <p>
      Des analyses de dépendances plus avancées sont présentées sur <url 
      id="http://bjorn.haxx.se/debian/"> &mdash; mais, attention, cette page 
      affiche également les dépendances de construction qui ne sont pas 
      considérées par britney.
    </p>
    <sect2 id="outdated">
     <heading>
       Désynchronisation
     </heading>
     <p>
       Pour le script de migration dans <em>testing</em>, 
       «&nbsp;désynchronisé&nbsp;» (<em>outdated</em> veut dire ceci&nbsp;: 
       il y a différentes versions dans <em>unstable</em> pour les 
       architectures de version (à l'exception des architectures dans 
       fuckedarches&nbsp;; fuckedarches est une liste des architectures qui 
       ne suivent pas le rythme (dans update_out.py), mais actuellement 
       cette liste est vide). «&nbsp;Désynchronisé&nbsp;» n'a rien à voir 
       avec les architectures que le paquet fournit pour <em>testing</em>.
     </p>
     <p>
       Considérons cet exemple&nbsp;:
     </p>
     <p>
      <example>
foo      | alpha | arm 
---------+-------+----
testing  |   1   |  -
unstable |   1   |  2
</example>
     </p>
     <p>
       Le paquet est désynchronisé pour alpha dans <em>unstable</em> et 
       n'entrera pas dans <em>testing</em>. Supprimer foo de 
       <em>testing</em> n'aiderait en rien, le paquet serait toujours 
       désynchronisé pour alpha et ne se propagerait pas dans 
       <em>testing</em>.
     </p>
     <p>
       Cependant, si ftp-master supprime un paquet d'<em>unstable</em> (ici 
       pour arm)&nbsp;:
     </p>
     <p>
      <example>
foo      | alpha | arm | hurd-i386
---------+-------+-----+----------
testing  |   1   |  1  |    -
unstable |   2   |  -  |    1
        </example>
     </p>
     <p>
       Dans ce cas, le paquet est synchronisé pour toutes les architectures 
       de version dans <em>unstable</em> (et l'architecture supplémentaire 
       hurd-i386 ne compte pas car ce n'est pas une architecture de 
       version).
     </p>
     <p>
       Quelquefois, la question est soulevée pour savoir s'il est possible 
       de permettre à des paquets de passer dans <em>testing</em> qui ne 
       sont pas encore construits pour toutes les architectures&nbsp;: 
       non. Simplement non. (Excepté si vous êtes responsable de glibc ou 
       équivalent).
     </p>
    </sect2>
    <sect2 id="removals">
     <heading>
       Suppressions de <em>testing</em>
     </heading>
     <p>
       Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre 
       paquet&nbsp;: ceci ne se produit que pour permettre à un 
       <em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous 
       les autres critères. Considérons, par exemple, qu'un paquet 
       <em>a</em> ne peut pas être installé avec la nouvelle version de 
       <em>b</em>&nbsp; alors <em>a</em> peut être supprimé pour permettre 
       l'entrée de <em>b</em>.
     </p>
     <p>
       Bien sûr, il existe une autre raison pour supprimer un paquet de 
       <em>testing</em>&nbsp;: le paquet est trop bogué (et avoir un seul 
       bogue RC est suffisant pour être dans cet état).
     </p>
     <p>
       De plus, si un paquet a été supprimé d'<em>unstable</em> et qu'aucun
       paquet de <em>testing</em> n'en dépend plus, il sera alors
       automatiquement supprimé.
     </p>

    </sect2>
    <sect2 id="circular">
     <heading>
       Dépendances circulaires
     </heading>
     <p>
       Une situation qui n'est pas très bien gérée par britney est si un 
       paquet <em>a</em> dépend de la nouvelle version d'un paquet 
       <em>b</em> et vice versa.
     </p>
     <p>
       Voici un exemple&nbsp;:
     </p>
     <p>
      <example>
  | testing         |  unstable
--+-----------------+------------
a | 1; dépend: b=1 |  2; dépend: b=2
b | 1; dépend: a=1 |  2; dépend: a=2
        </example>
     </p>
     <p>
       Aucun des paquets <em>a</em> et <em>b</em> ne sera considéré pour 
       mise à jour.
     </p>
     <p>
       Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de 
       publication. Veuillez les contacter en envoyant un courrier 
       électronique à debian-release@lists.debian.org si cela se produit 
       pour l'un de vos paquets.
     </p>
    </sect2>
    <sect2>
     <heading>
       Influence d'un paquet dans <em>testing</em>
     </heading>
     <p>
       Généralement, l'état d'un paquet dans <em>testing</em> ne change rien 
       pour la transition de la prochaine version d'<em>unstable</em> vers 
       <em>testing</em>, avec deux exceptions&nbsp;: si le nombre de bogues 
       RC du paquet est réduit, le paquet peut migrer même s'il a encore des 
       bogues RC. La seconde exception est que si la version du paquet dans 
       <em>testing</em> est désynchronisée entre les différentes 
       architectures, alors toute architecture peut être mise à jour vers la 
       version du paquet source&nbsp;; cependant, cela ne peut se produire 
       que si le paquet a été précédemment forcé, si l'architecture est dans 
       fuckedarches ou s'il n'y avait pas du tout de paquet binaire de cette 
       architecture présent dans <em>unstable</em> lors de la migration dans 
       <em>testing</em>.
     </p>
     <p>
       En résumé, cela veut dire&nbsp;: la seule influence qu'un paquet de 
       <em>testing</em> a sur la nouvelle version du même paquet est que la 
       nouvelle version peut rentrer plus facilement.
     </p>
    </sect2>
    <sect2 id="details">
     <heading>
       Détails
     </heading>
     <p>
       Si vous êtes intéressé par les détails, voici comment fonctionne 
       britney&nbsp;:
     </p>
     <p>
       Les paquets sont examinés pour savoir si ce sont des candidats 
       valides. Cela donne le fichier «&nbsp;update excuses&nbsp;». Les 
       raisons les plus communes pour lesquelles un paquet n'est pas 
       considéré sont la jeunesse du paquet, le nombre de bogues RC et la 
       désynchronisation pour certaines architectures. Pour cette partie de britney, 
       les responsables de version ont des marteaux de toute taille pour 
       forcer britney à considérer un paquet. (Le gel de la base est 
       également codé dans cette partie de britney.) (Il y a une chose 
       semblable pour les mises à jour binaires pures, mais cela n'est pas 
       décrit ici. Si vous êtes intéressé par cela, veuillez étudier 
       attentivement le code.)
     </p>
     <p>
       Maintenant, la partie la plus complexe se produit&nbsp;: britney 
       tente de mettre à jour <em>testing</em> avec des candidats 
       valides&nbsp;; en premier, chaque paquet individuellement, puis des 
       groupes de plus en plus larges de paquets ensemble. Chaque tentative 
       est acceptée si <em>testing</em> n'est pas moins non installable 
       après la mise à jour qu'avant celle-ci. (Avant et après cette partie, 
       certains coups de pouce («&nbsp;hints&nbsp;») sont traités&nbsp;; 
       mais, comme seuls les responsables de version peuvent positionner des 
       coups de pouce, cela n'est probablement pas très important pour 
       vous.)
     </p>
     <p>
       Si vous voulez voir plus de détails, vous pouvez le voir dans 
       merkel:/org/ftp.debian.org/testing/update_out/ (ou dans 
       ~aba/testing/update_out pour voir une configuration avec un fichier 
       de paquets plus petit). Par le web, c'est à <url 
       id="http://ftp-master.debian.org/testing/update_out_code/">.
     </p>
     <p>
       Les coups de pouce sont visibles sur <url 
       id="http://ftp-master.debian.org/testing/hints/">.
     </p>
    </sect2>
   </sect1>
   <sect1 id="t-p-u">
    <heading>
      Mises à jour directes dans <em>testing</em>
    </heading>
    <p>
      La distribution <em>testing</em> est peuplée avec des paquets en 
      provenance d'<em>unstable</em> selon des règles expliquées 
      ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer 
      des paquets construits seulement pour <em>testing</em>. Pour cela, 
      vous pouvez envoyer vos paquets vers 
      <em>testing-proposed-updates</em>.
    </p>
    <p>
      Souvenez-vous que les paquets envoyés là ne sont pas traités 
      automatiquement, ils doivent passer entre les mains du responsable de 
      distribution. Vous devez donc avoir une bonne raison pour les y 
      envoyer. Pour savoir ce que représente une bonne raison aux yeux des 
      responsables de distribution, vous devriez lire les instructions 
      données qu'ils envoient régulièrement sur 
      &email-debian-devel-announce;.
    </p>
    <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 de développement dans 
      <em>unstable</em>), vous pouvez utiliser cette facilité, mais il est 
      recommandé de demander l'autorisation du responsable de distribution 
      auparavant. Même si un paquet est gelé, des mises à jour par 
      <em>unstable</em> sont possibles si l'envoi dans <em>unstable</em> ne 
      tire pas de nouvelles dépendances.
    </p>
    <p>
      Les numéros de version sont habituellement choisis en ajoutant le nom 
      de code de la distribution <em>testing</em> et un numéro incrémenté, 
      comme 1.2sarge1 pour le premier envoi dans 
      <em>testing-proposed-updates</em> du paquet en version&nbsp;1.2.
    </p>
    <p>
      Veuillez vous assurer que vous n'oubliez aucun des éléments suivants 
      lors de votre envoi&nbsp;:
     <list>
      <item>
       <p>
         vérifiez que votre paquet doit vraiment aller dans 
         <em>testing-proposed-updates</em> et ne peut pas passer par 
         <em>unstable</em>&nbsp;;
       </p>
      </item>
      <item>
       <p>
         vérifiez que vous n'incluez que le minimum de changements&nbsp;;
       </p>
      </item>
      <item>
       <p>
         vérifiez que vous incluez une explication appropriée dans le 
         changelog&nbsp;;
       </p>
      </item>
      <item>
       <p>
         vérifiez que vous avez bien indiqué <em>testing</em> ou 
         <em>testing-proposed-updates</em> comme votre distribution 
         cible&nbsp;;
       </p>
      </item>
      <item>
       <p>
         vérifiez que vous avez construit et testé votre paquet dans 
         <em>testing</em> et non dans <em>unstable</em>&nbsp;;
       </p>
      </item>
      <item>
       <p>
         vérifiez que votre numéro de version est plus élevé que les 
         versions de <em>testing</em> et de 
         <em>testing-proposed-updates</em> et moins élevé que celle de 
         <em>unstable</em>&nbsp;;
       </p>
      </item>
      <item>
       <p>
         après l'envoi et la construction réussie sur toutes les 
         plates-formes, contactez l'équipe de publication à 
         &email-debian-release; et demandez-leur d'approuver votre envoi.
       </p>
      </item>
     </list>
    </p>
   </sect1>
   <sect1 id="faq">
    <heading>
      Questions fréquemment posées
    </heading>
    <p>
    </p>
    <sect2 id="rc">
     <heading>
       Quels sont les bogues bloquant l'intégration dans la version stable 
       et comment sont-ils comptés&nbsp;?
     </heading>
     <p>
       Tous les bogues de gravité assez élevée sont par défaut considérés 
       comme bloquant l'intégration du paquet dans la version stable&nbsp;; 
       actuellement, ce sont les bogues critiques, graves et sérieux.
     </p>
     <p>
       Certains bogues sont supposés avoir un impact sur les chances que le 
       paquet a d'être diffusé dans la version stable de Debian&nbsp;: en 
       général, si un paquet a des bogues bloquants, il n'ira pas dans 
       <em>testing</em> et par conséquent, ne pourra pas être diffusé dans 
       <em>stable</em>.
     </p>
     <p>
       Le compte des bogues d'<em>unstable</em> est effectué avec tous les 
       bogues bloquants sans étiquette de version (comme <em>potato</em>, 
       <em>woody</em>) ou avec une étiquette <em>sid</em> et également s'ils 
       ne sont ni corrigés ou marqués avec <em>sarge-ignore</em>. Le compte 
       des bogues de <em>testing</em> pour un paquet est considéré comme à 
       peu près le nombre de bogues d'<em>unstable</em> lors du dernier 
       pointage quand la version <em>testing</em> a été égale à la version 
       <em>unstable</em>.
     </p>
     <p>
       Cela changera après la sortie de <em>Sarge</em> dès que nous aurons 
       des versions dans le système de suivi des bogues.
     </p>
    </sect2>
    <sect2>
     <heading>
       Comment est-ce que l'installation d'un paquet dans <em>testing</em> 
       peut casser d'autres paquets&nbsp;?
     </heading>
     <p>
       La structure des archives de la distribution est faite de telle façon 
       qu'elles ne peuvent contenir qu'une version d'un paquet&nbsp;; un 
       paquet est défini par son nom. Donc, quand le paquet source acmefoo 
       est installé dans <em>testing</em> avec ses paquets binaires 
       acme-foo-bin, acme-bar-bin, libacme-foo1 et libacme-foo-dev, 
       l'ancienne version est supprimée.
     </p>
     <p>
       Cependant, l'ancienne version pouvait fournir à un paquet binaire un 
       vieux soname d'une bibliothèque, comme libacme-foo0. Supprimer 
       l'ancien acmefoo va supprimer libacme-foo0, ce qui va casser tout 
       paquet qui en dépend.
     </p>
     <p>
       Évidemment, cela touche principalement des paquets qui fournissent 
       des jeux changeant de paquets binaires dans différentes versions (par 
       suite, principalement des bibliothèques). Cependant, cela va aussi 
       toucher des paquets sur lesquels une dépendance versionnée a été 
       déclarée du type ==, <= ou <<.
     </p>
     <p>
       Quand le jeu de paquets binaires fournis par un paquet source change 
       de cette façon, tous les paquets qui dépendent des anciens binaires 
       doivent être mis à jour pour dépendre de la nouvelle version à la 
       place. Comme l'installation d'un tel paquet source dans 
       <em>testing</em> casse tous les paquets qui en dépendent dans 
       <em>testing</em>, une certaine attention doit y être portée&nbsp;: 
       tous les paquets en dépendant doivent être mis à jour et prêts à être 
       installés eux-même pour qu'ils ne cassent pas et, une fois que tout 
       est prêt, une intervention manuelle du responsable de version ou d'un 
       de ses assistants est normalement requise.
     </p>
     <p>
       Si vous avez des problèmes avec des groupes compliqués de paquets 
       comme ceci, contactez debian-devel ou debian-release en demandant de 
       l'aide.
     </p>
    </sect2>
   </sect1>
  </sect>
 </chapt>
 <chapt id="best-pkging-practices">
  <heading>
    Les meilleurs pratiques pour la construction des paquets
  </heading>
  <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>
  <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.
  </p>
  <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.
   </p>
   <sect1 id="helper-scripts">
    <heading>
      Scripts d'aide
    </heading>
    <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, la question de l'installation des 
      entrées de menu&nbsp;: vous avez besoin de placer un fichier dans 
      <file>/usr/share/menu</file> (ou <file>/usr/lib/menu</file> pour des 
      fichiers de menu binaires exécutables, si nécessaire) 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>
    <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&nbsp;; les 
      paquets ont alors simplement besoin d'être reconstruits avec la 
      nouvelle version du script et sans aucun changement supplémentaire.
    </p>
    <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 compacte 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>
    <p>
      Vous pouvez débuter avec <package>debhelper</package> en lisant 
      <manref section="1" name="debhelper"> 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>
    <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;">.
    </p>
   </sect1>
   <sect1 id="multiple-patches">
    <heading>
      Séparer vos correctifs en plusieurs fichiers
    </heading>
    <p>
      Les gros paquets peuvent avoir plusieurs bogues que vous devez 
      gérer. 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 parce que les bogues ont été corrigés en amont.
    </p>
    <p>
      Malheureusement, le système de création des paquets tel qu'il est 
      actuellement ne fournit pas de moyen de séparer les correctifs en 
      plusieurs fichiers. Cependant, il existe des moyens de séparer les 
      correctifs&nbsp;: les fichiers correctifs sont livrés dans le fichier 
      correctif Debian (<file>.diff.gz</file>), habituellement dans le 
      répertoire <file>debian/</file>. La seule différence est qu'ils ne 
      sont pas appliqués immédiatement par dpkg-source, mais par la règle 
      <tt>build</tt> du fichier <file>debian/rules</file>. Inversement, ils 
      sont annulés par la règle <tt>clean</tt>.
    </p>
    <p>
      <prgn>dbs</prgn> est l'une des approches les plus populaires pour 
      cela. Il fait ce qui est décrit ci-dessus et fournit la possibilité de 
      créer de nouveaux correctifs et de mettre à jour d'anciens 
      correctifs. Veuillez vous reporter au paquet <package>dbs</package> 
      pour plus d'informations et au paquet <package>hello-dbs</package> 
      pour un exemple.
    </p>
    <p>
      <prgn>Dpatch</prgn> fournit également ces fonctions, mais il est prévu 
      pour être encore plus facile d'utilisation. Veuillez voir le paquet 
      <package>dpatch</package> pour la documentation et des exemples (dans 
      <file>/usr/share/doc/dpatch</file>).
    </p>
   </sect1>
   <sect1 id="multiple-binary">
    <heading>
      Paquets binaires multiples
    </heading>
    <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, le paquet source 
      <package>vim</package>) ou pour créer plusieurs petits paquets au lieu 
      d'un seul gros (afin, par exemple, que l'utilisateur puisse n'installer
      que la partie nécessaire et ainsi économiser de l'espace disque).
    </p>
    <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> ou <prgn>dh_install</prgn> du paquet 
      <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>
    <p>
      Le premier cas est un peu plus difficile car il implique de multiples 
      recompilations du même logiciel, mais avec différentes options de 
      configuration. Le paquet source <package>vim</package> est un exemple 
      de la façon de gérer cela avec un fichier <file>rules</file> écrit à 
      la main.
    </p>
   </sect1>
  </sect>
  <sect id="bpp-debian-control">
   <heading>
     Les meilleures pratiques pour le fichier <file>debian/control</file>
   </heading>
   <p>
     Les pratiques suivantes sont relatives au fichier 
     <file>debian/control</file>. Elles viennent en complément des <url 
     id="&url-debian-policy;ch-binary.html#s-descriptions" name="règles pour 
     les descriptions des paquets">.
   </p>
   <p>
     La description du paquet, telle qu'elle est définie par le champ 
     correspondant dans le fichier <file>control</file>, contient à la fois 
     le résumé du paquet et la description longue pour le paquet. <ref 
     id="bpp-desc-basics"> décrit des lignes générales pour les deux parties 
     de la description. Ensuite, <ref id="bpp-pkg-synopsis"> fournit des 
     principes spécifiques pour le résumé et <ref id="bpp-pkg-desc"> 
     contient des principes spécifiques pour la description longue.
   </p>
   <sect1 id="bpp-desc-basics">
    <heading>
      Les règles générales pour les descriptions des paquets
    </heading>
    <p>
      La description du paquet devrait être écrite pour l'utilisateur moyen, 
      l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, 
      les paquets de développement sont pour les développeurs et leur 
      description peut utiliser un langage technique. Pour les applications 
      à but plus général comme un éditeur, la description devrait être 
      écrite pour un non-spécialiste.
    </p>
    <p>
      Notre critique des descriptions des paquets nous amène à conclure que 
      la plupart des descriptions des paquets sont techniques, c'est-à-dire, 
      qu'elles ne sont pas écrites pour être comprises par les 
      non-spécialistes. À moins que votre paquet ne soit que pour les 
      techniciens, c'est un problème.
    </p>
    <p>
      Comment écrire pour les non-spécialistes&nbsp;? Évitez le 
      jargon. Évitez de vous référer à d'autres applications et cadres de 
      travail avec lesquels l'utilisateur n'est pas forcément familier 
      &mdash;&nbsp;«&nbsp;GNOME&nbsp;» ou «&nbsp;KDE&nbsp;» sont corrects 
      car les utilisateurs sont probablement familiers avec ces termes, mais 
      «&nbsp;GTK+&nbsp;» ne l'est probablement pas. Ne supposez aucune 
      connaissance. Si vous devez utiliser des termes techniques, 
      introduisez-les.
    </p>
    <p>
      Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour 
      promouvoir votre paquet, quel que soit l'amour que vous lui 
      portez. Rappelez-vous que le lecteur n'a pas forcément les mêmes 
      priorités que vous.
    </p>
    <p>
      Des références aux noms de tout autre paquet de logiciels, noms de 
      protocoles, standards ou spécifications devraient utiliser leurs 
      formes canoniques si elles existent. Par exemple, utilisez «&nbsp;X 
      Window System&nbsp;», «&nbsp;X11&nbsp;» ou «&nbsp;X&nbsp;» et non 
      «&nbsp;X Windows&nbsp;», «&nbsp;X-Windows&nbsp;» ou «&nbsp;X 
      Window&nbsp;». Utilisez «&nbsp;GTK+&nbsp;» et non «&nbsp;GTK&nbsp;» ou 
      «&nbsp;gtk&nbsp;». Utilisez «&nbsp;GNOME&nbsp;» et non 
      «&nbsp;Gnome&nbsp;». Utilisez «&nbsp;PostScript&nbsp;» et non 
      «&nbsp;Postscript&nbsp;» ou «&nbsp;postscript&nbsp;».
    </p>
    <p>
      Si vous avez des problèmes pour écrire votre description, vous pouvez 
      l'envoyer à &email-debian-l10n-english; et demander un retour 
      d'informations.
    </p>
   </sect1>
   <sect1 id="bpp-pkg-synopsis">
    <heading>
      Le résumé du paquet ou description courte
    </heading>
    <p>
      La ligne de résumé (la description courte) devrait être concise. Elle 
      ne doit pas répéter le nom du paquet (c'est une règle).
    </p>
    <p>
      C'est une bonne idée de penser au résumé comme à une clause apposée et 
      non une phrase complète. Une clause apposée est définie dans WordNet 
      comme une relation grammaticale entre un mot et une phrase pronominale 
      qui la suit, par exemple «&nbsp;Rudolph, le renne au nez 
      rouge&nbsp;». La clause apposée ici est «&nbsp;le renne au nez 
      rouge&nbsp;». Comme le résumé est une clause et non une phrase 
      complète, nous recommandons de ne pas la commencer par une majuscule 
      et de ne pas la finir par un point. Il ne doit pas non plus commencer 
      avec un article, défini («&nbsp;le&nbsp;») ou indéfini 
      («&nbsp;un&nbsp;»).
    </p>
    <p>
      Cela peut vous aider d'imaginer le résumé combiné avec le nom du 
      paquet de la façon suivante&nbsp;:
     <example><var>nom-paquet</var> est un <var>résumé</var>.</example>
      Sinon, il peut être plus compréhensible de le voir comme
     <example><var>nom-paquet</var> est <var>résumé</var>.</example>
      ou, si le nom du paquet est lui-même un pluriel (comme 
      «&nbsp;developer-tools&nbsp;»)
     <example><var>nom-paquet</var> sont <var>résumé</var>.</example>
      Cette façon de former une phrase à partir du nom du paquet et du 
      résumé devrait être considérée comme une heuristique et non comme une 
      règle stricte. Il y a certains cas où cela n'a aucun sens de former 
      une phrase.
    </p>
   </sect1>
   <sect1 id="bpp-pkg-desc">
    <heading>
      La description longue
    </heading>
    <p>
      La description longue du paquet est 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. Vous pouvez supposer que l'utilisateur a 
      déjà lu le résumé du paquet.
    </p>
    <p>
      La description longue devrait toujours être constituée de phrases 
      complètes.
    </p>
    <p>
      Le premier paragraphe de la description longue devrait répondre aux 
      questions suivantes&nbsp;: qu'est-ce que fait le paquet&nbsp;? Quelle 
      tâche aide-t-il l'utilisateur à accomplir&nbsp;? Il est important de 
      décrire ceci d'une manière non technique, à moins que le paquet ne 
      s'adresse qu'à un auditoire de techniciens.
    </p>
    <p>
      Les paragraphes suivants devraient répondre aux questions 
      suivantes&nbsp;: Pourquoi, en tant qu'utilisateur, ai-je besoin de ce 
      paquet&nbsp;? Quelles sont les autres fonctionnalités dont dispose le 
      paquet&nbsp;? Quelles sont les fonctionnalités marquantes et les 
      déficiences de ce paquet comparé à d'autres paquets (par exemple, 
      «&nbsp;si vous avez besoin de X, utilisez Y à la place&nbsp;»)&nbsp;? 
      Est-ce que le paquet est lié à d'autres paquets d'une certaine façon 
      qui n'est pas gérée par le gestionnaire de paquet (par exemple, 
      «&nbsp;il s'agit d'un client pour le serveur foo&nbsp;»)&nbsp;?
    </p>
    <p>
      Soyez attentif à éviter les fautes d'orthographe et de 
      grammaire. N'oubliez pas votre vérificateur orthographique. Les deux 
      programmes <prgn>ispell</prgn> et <prgn>aspell</prgn> possèdent des 
      modes spéciaux pour vérifier les fichiers 
      <file>debian/control</file>&nbsp;:
     <example>ispell -d american -g debian/control</example>
     <example>aspell -d en -D -c debian/control</example>
    </p>
    <p>
      Les utilisateurs s'attendent habituellement à ce que les réponses aux 
      questions suivantes soient présentes dans la description du 
      paquet&nbsp;:
     <list>
      <item>
       <p>
         Qu'est-ce que fait le paquet&nbsp;? Si c'est un ajout d'un autre 
         paquet, la description courte du paquet dont c'est un ajout devrait 
         le spécifier.
       </p>
      </item>
      <item>
       <p>
         Pourquoi est-ce qu'il voudrait installer ce paquet&nbsp;? Ceci est 
         lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client 
         de messagerie&nbsp;; il est cool, rapide, s'interface avec PGP, 
         LDAP et IMAP, a les fonctionnalités X, Y et Z).
       </p>
      </item>
      <item>
       <p>
         Si ce paquet ne devrait pas être installé directement, mais être 
         tiré par un autre paquet, cela devrait être mentionné.
       </p>
      </item>
      <item>
       <p>
         Si le paquet est expérimental, ou s'il y a d'autres raisons pour 
         lesquelles il ne devrait pas être utilisé, si un autre paquet 
         devrait être utilisé à la place, cela devrait également être 
         présent.
       </p>
      </item>
      <item>
       <p>
         En quoi le paquet est différent des paquets concurrents&nbsp;? 
         Est-ce que c'est une meilleure implémentation&nbsp;? A-t-il plus de 
         fonctionnalités, des fonctionnalités différentes&nbsp;? Pourquoi 
         devrait-il choisir ce paquet&nbsp;?
       </p>
      </item>
     </list>
    </p>
   </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>
    <p>
      Ne mettez rien s'il n'existe pas de page pour le logiciel.
    </p>
    <p>
      Veuillez noter que nous espérons que ce champ sera remplacé par un 
      vrai champ de <file>debian/control</file> qui serait compris par 
      <prgn>dpkg</prgn> et <tt>&packages-host;</tt>. Si vous ne voulez pas 
      vous embêter à déplacer la page d'accueil depuis la description vers 
      ce nouveau champ, vous devriez probablement attendre qu'il soit 
      disponible. Veuillez vous assurer que cette ligne correspond à 
      l'expression rationnelle <tt>/^ Homepage: [^ ]*$/</tt> car cela permet 
      à <file>packages.debian.org</file> de l'analyser correctement.
    </p>
   </sect1>
  </sect>
  <sect id="bpp-debian-changelog">
   <heading>
     Les meilleures pratiques pour le fichier <file>debian/changelog</file>
   </heading>
   <p>
     Les pratiques suivantes viennent en complément de la <url 
     id="&url-debian-policy;ch-docs.html#s-changelogs" name="directive sur 
     les fichiers changelog">.
   </p>
   <sect1 id="bpp-changelog-do">
    <heading>
      Écrire des entrées de changelog utiles
    </heading>
    <p>
      L'entrée de changelog pour une révision de paquet documente les 
      changements dans cette révision et seulement ceux-ci. Concentrez-vous 
      sur la description des changements significatifs et visibles de 
      l'utilisateur qui ont été effectués depuis la dernière version.
    </p>
    <p>
      Ciblez <em>ce</em> qui a été changé &mdash;&nbsp;qui, comment et quand 
      cela a été fait est généralement de moindre importance. Ceci dit, 
      rappelez-vous de nommer poliment les personnes qui ont fourni une aide 
      notable pour réaliser le paquet (par exemple, ceux qui ont envoyé des 
      correctifs).
    </p>
    <p>
      Vous n'avez pas besoin de détailler les changements triviaux et 
      évidents. Vous pouvez également regrouper plusieurs de ces changements 
      dans une seule entrée. D'un autre côté, ne soyez pas trop concis si 
      vous avez entrepris un changement majeur. Soyez tout spécialement 
      clair s'il y a des changements qui modifient le comportement du 
      programme. Pour plus d'explications, utilisez le fichier 
      <file>README.Debian</file>.
    </p>
    <p>
      Utilisez un langage anglais commun pour que la majorité des lecteur 
      puissent le comprendre. Évitez les abréviations, le parler technique 
      et le jargon quand vous expliquez des changements fermant un bogue, 
      spécialement pour les rapports de bogue créés par des utilisateurs qui 
      ne vous paraissent pas particulièrement à l'aise techniquement. Vous 
      devez être poli et ne pas jurer.
    </p>
    <p>
      Il est parfois désirable de préfixer les entrées de changelog avec le 
      nom des fichiers qui ont été modifiés. Cependant, il n'est pas besoin 
      de lister explicitement tous les fichiers modifiés, particulièrement 
      si la modification est petite ou répétitive. Vous pouvez utiliser les 
      caractères génériques.
    </p>
    <p>
      Quand vous faites référence aux bogues, ne supposez rien a 
      priori. Dites ce qu'était le problème, comment il a été résolu et 
      ajoutez la chaîne de caractères «&nbsp;closes: #nnnnn&nbsp;». Veuillez 
      voir <ref id="upload-bugfix"> pour plus d'informations.
    </p>
   </sect1>
   <sect1 id="bpp-changelog-misconceptions">
    <heading>
      idées fausses communes sur les entrées de changelog
    </heading>
    <p>
      Les entrées de changelog <strong>ne devraient pas</strong> documenter 
      des problèmes génériques d'empaquetage («&nbsp;Hé, si vous cherchez 
      foo.conf, il est dans /etc/blah/.&nbsp;») car les administrateurs et 
      utilisateurs sont supposés être au moins vaguement rompus à la façon 
      dont les choses sont arrangées sur un système Debian. Mentionnez 
      cependant tout changement d'emplacement d'un fichier de configuration.
    </p>
    <p>
      Les seuls bogues fermés par une entrée de changelog devraient être 
      ceux qui sont vraiment corrigés dans la même révision du 
      paquet. Fermer des bogues non liés par le fichier changelog est 
      considéré comme une très mauvaise pratique. Veuillez voir <ref 
      id="upload-bugfix">.
    </p>
    <p>
      Les entrées de changelog <strong>ne devraient pas</strong> être le 
      lieu de discussions avec les émetteurs de bogues («&nbsp;Je ne vois 
      pas de segfaults lors du lancement de foo avec l'option bar&nbsp;; 
      envoyez-moi plus d'informations.&nbsp;»), ni celui de phrases 
      génériques sur la vie, l'univers et tout le reste («&nbsp;Désolé, cet 
      envoi m'a pris du temps, mais j'avais attrapé la grippe&nbsp;») ou 
      celui de demandes d'aide («&nbsp;La liste des bogues sur ce paquet est 
      énorme, donnez-moi un coup de main&nbsp;»). Ceci ne sera généralement 
      pas remarqué par les personnes ciblées, mais peut ennuyer les 
      personnes qui désirent lire des informations sur les changements réels 
      du paquet. Veuillez vous reporter à <ref id="bug-answering"> pour plus 
      d'informations sur la façon d'utiliser le système de suivi des bogues.
    </p>
    <p>
      C'est une vieille tradition de valider les bogues fixés par une mise à 
      jour indépendante dans la première entrée du changelog de l'envoi du 
      vrai responsable. Comme nous avons maintenant le suivi des versions, il
      est suffisant de garder les entrées de changelog des mises à jour
      indépendantes et de simplement mentionner ce fait dans votre propre
      entrée de changelog.
    </p>
   </sect1>
   <sect1 id="bpp-changelog-errors">
    <heading>
      Erreurs communes dans les entrées de changelogs
    </heading>
    <p>
      Les exemples suivants montrent des erreurs communes ou des exemples de 
      mauvais style dans les entrées de changelog<footnote><p>NdT&nbsp;: Les 
      entrées de changelog sont ici affichées en français pour faciliter la 
      compréhension, mais vos entrées devront naturellement être rédigées en 
      anglais.</p></footnote>.
    </p>
    <p>
     <example>
  * Corrige tous les bogues restants.
</example>
      Ceci n'indique visiblement rien d'utile au lecteur.
    </p>
    <p>
     <example>
  * Correctif de Jane Random appliqué.
</example>
      Sur quoi portait le correctif&nbsp;?
    </p>
    <p>
     <example>
  * Révision de cible d'installation la nuit dernière.
</example>
      Qu'a accompli la révision&nbsp;? Est-ce que la mention de la nuit 
      dernière est supposée nous rappeler que nous ne devons pas faire 
      confiance à ce code&nbsp;?
    </p>
    <p>
     <example>
  * Corrige MRD vsync av. anciens CRTs.
</example>
      Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment 
      cette... euh... merde (oups, un mot interdit&nbsp;!) ou comment cela a 
      été corrigé.
    </p>
    <p>
     <example>
  * Ceci n'est pas un bogue. Closes: #nnnnnn.
</example>
      Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour 
      communiquer cette information&nbsp;; à la place, utilisez le système 
      de suivi des bogues. Deuxièmement, il n'y a aucune explication 
      concernant la raison pour laquelle le rapport n'était pas un bogue.
    </p>
    <p>
     <example>
  * A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
</example>
      Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue 
      dans une précédente entrée de changelog, ceci n'est pas un problème, 
      fermez simplement le bogue normalement dans le BTS. Il n'y a pas 
      besoin de modifier le fichier changelog, en supposant que la 
      description de la correction est déjà intégrée (ceci s'applique aux 
      correctifs par les auteurs/responsables amont également, vous n'avez 
      pas à suivre les bogues qui ont été corrigés il y a longtemps dans 
      votre changelog).
    </p>
    <p>
     <example>
  * Closes: #12345, #12346, #15432.
</example>
      Où est la description&nbsp;?! Si vous n'arrivez pas à trouver un 
      message descriptif, commencez par insérer le titre de chacun des 
      différents bogues.
    </p>
   </sect1>
   <sect1 id="bpp-news-debian">
    <heading>
      Compléter les changelogs avec les fichiers NEWS.Debian
    </heading>
    <p>
      Les nouvelles importantes à propos des changements dans un paquet 
      peuvent également être placées dans les fichiers NEWS.Debian. Ces 
      nouvelles seront affichées par des outils comme apt-listchanges, avant 
      le reste des changelogs. Ceci est le moyen préféré pour informer les 
      utilisateurs des changements significatifs dans un paquet. Il est 
      préférable d'utiliser ce fichier plutôt que d'utiliser des notes 
      debconf car c'est moins ennuyeux et l'utilisateur peut y revenir et se 
      référer au fichier NEWS.Debian après l'installation. Et c'est mieux 
      que de lister les changements principaux dans README.Debian car 
      l'utilisateur peut facilement rater de telles notes.
    </p>
    <p>
      Le format du fichier est le même que pour un fichier de changelog 
      Debian, mais il n'utilise pas d'astérisques et décrit chaque élément 
      de nouvelle dans un paragraphe complet si nécessaire plutôt que les 
      résumés concis qui iraient dans un changelog. C'est une bonne idée de 
      passer votre fichier par dpkg-parsechangelog pour vérifier son 
      formatage car il n'est pas vérifié automatiquement pendant la 
      construction comme le changelog. Voici un exemple d'un vrai fichier 
      NEWS.Debian&nbsp;:
     <example>
cron (3.0pl1-74) unstable; urgency=low

    The checksecurity script is no longer included with the cron package:
    it now has its own package, "checksecurity". If you liked the
    functionality provided with that script, please install the new
    package.

 -- Steve Greenland &lt;stevegr@debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
</example>
    </p>
    <p>
      Le fichier NEWS.Debian est installé comme 
      /usr/share/doc/&lt;package&gt;/NEWS.Debian.gz. Il est compressé et a 
      toujours ce nom même dans les paquets natifs Debian. Si vous utilisez 
      debhelper, dh_installchangelogs installera les fichiers debian/NEWS 
      pour vous.
    </p>
    <p>
      À la différence des fichiers changelog, vous n'avez pas besoin de 
      mettre à jour les fichiers NEWS.Debian à chaque nouvelle version. Ne 
      les mettez à jour que si vous avez quelque chose de particulièrement 
      important que l'utilisateur a besoin de savoir. Si vous n'avez pas de 
      nouvelles du tout, il n'est pas nécessaire de fournir de fichier 
      NEWS.Debian dans votre paquet. Pas de nouvelles, bonne nouvelle&nbsp;!
    </p>
   </sect1>
  </sect>
  <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 en charge 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>
   <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>
   <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>
   <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>
   <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 préciser bash 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>
   <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>
   <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 d'une 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 paramètre. Il renvoie vrai (zéro) si la commande a été trouvée 
     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.
   </p>
   <p>
     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. Autrement dit, il est placé dans <file>/usr/bin</file> au lieu 
     de <file>/bin</file>, il n'est donc pas possible de l'utiliser dans les 
     scripts qui sont exécutés avant que la partition <file>/usr</file> soit 
     montée. Cependant, la plupart des scripts n'auront pas ce problème.
   </p>
  </sect>
  <sect id="bpp-config-mgmt">
   <heading>
     Gestion de la configuration avec <package>debconf</package>
   </heading>
   <p>
     <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.
   </p>
   <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="7" name="debconf-devel">. Vous devriez vraiment lire cette 
     page si vous décidez d'utiliser debconf. Nous documentons également 
     plusieurs des meilleures pratiques ici.
   </p>
   <p>
     Ces lignes directives incluent plusieurs recommandations de style 
     d'écriture et de typographie, des considérations générales à propos de 
     l'utilisation de debconf ainsi que des recommandations plus spécifiques 
     pour certaines parties de la distribution (par exemple, le système 
     d'installation).
   </p>
   <sect1>
    <heading>
      N'abusez pas de debconf
    </heading>
    <p>
      Depuis que debconf est apparu dans Debian, il a été largement abusé et 
      plusieurs critiques reçues par la distribution Debian proviennent 
      d'utilisation abusive de debconf avec la nécessité de répondre à un 
      grand nombre de questions avant d'avoir n'importe quel petit logiciel 
      d'installé.
    </p>
    <p>
      Garder les notes d'utilisation à leur place&nbsp;: le fichier 
      NEWS.Debian ou le fichier README.Debian. N'utilisez des notes que pour 
      des notes importantes qui peuvent directement concerner l'utilisation 
      du paquet. Rappelez-vous que les notes bloqueront toujours 
      l'installation avant leur confirmation ou qu'elles embêtent 
      l'utilisateur par un courriel.
    </p>
    <p>
      Choisissez avec soin les priorités des questions dans les scripts de 
      responsable. Reportez-vous à <manref section="7" name="debconf-devel"> 
      pour plus de détails sur les priorités. La plupart des questions 
      devraient utiliser un priorité moyenne ou basse.
    </p>
   </sect1>
   <sect1>
    <heading>
      Recommandations générales pour les auteurs et traducteurs
    </heading>
    <p>
    </p>
    <sect2>
     <heading>
       Écrivez un anglais correct
     </heading>
     <p>
       La plupart des responsables de paquets Debian n'ont pas l'anglais 
       comme langue maternelle. Écrire des modèles correctement rédigés peut 
       donc ne pas être facile pour eux.
     </p>
     <p>
       Veuillez utiliser (et abuser de) la liste de discussions 
       &email-debian-l10n-english;. Faites relire vos questionnaires.
     </p>
     <p>
       Des questionnaires écrits incorrectement donnent une pauvre image de 
       votre paquet, de votre travail... ou même de Debian elle-même.
     </p>
     <p>
       Évitez le jargon technique autant que possible. Si certains termes 
       vous semblent courants, ils peuvent être impossibles à expliquer à 
       d'autres personnes. Si vous ne pouvez pas les éviter, essayez de les 
       expliquer (en utilisant la description étendue). Quand vous faites 
       cela, essayez d'équilibrer la verbosité et la simplicité.
     </p>
    </sect2>
    <sect2>
     <heading>
       Être courtois avec les traducteurs
     </heading>
     <p>
       Les questionnaires debconf peuvent être traduits. Debconf, avec son 
       paquet-frêre <package>po-debconf</package>, offre un cadre de travail 
       simple pour obtenir des questionnaires traduits par les équipes de 
       traduction ou même par des individus isolés.
     </p>
     <p>
       Veuillez utiliser les questionnaires basés sur gettext. Installez 
       <package>po-debconf</package> sur votre système de développement et 
       lisez sa documentation («&nbsp;man po-debconf&nbsp;» est un bon 
       début).
     </p>
     <p>
       Évitez de changer vos questionnaires trop souvent. Modifier le texte 
       des questionnaires entraîne plus de travail pour les traducteurs dont 
       les traductions seront rendues «&nbsp;floues&nbsp;» 
       («&nbsp;fuzzy&nbsp;»). Si vous prévoyez des modifications dans vos 
       questionnaires d'origine, veuillez contacter les traducteurs. La 
       plupart des traducteurs actifs sont très réactifs et obtenir leur 
       travail inclus avec vos questionnaires modifiés vous économisera des 
       envois supplémentaires. Si vous utilisez des modèles basés sur 
       gettext, le nom et l'adresse électronique du traducteur sont 
       mentionnés dans les en-têtes des fichiers PO.
     </p>
     <p>
       L'utilisation de <prgn>podebconf-report-po</prgn> du paquet 
       <package>po-debconf</package> est hautement recommandée pour avertir 
       les traducteurs qui ont des traductions incomplètes et pour leur 
       demander des mises à jour.
     </p>
     <p>
       En cas de doutes, vous pouvez également contacter l'équipe de 
       traduction pour une langue donnée 
       (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions 
       &email-debian-i18n;.
     </p>
     <p>
       Les appels à traductions postés sur &email-debian-i18n; avec le 
       fichier <file>debian/po/templates.pot</file> attaché ou référencé 
       dans une URL sont encouragés. Assurez-vous de mentionner dans ces 
       appels pour de nouvelles traductions quelles sont les langues pour 
       lesquelles vous avez déjà des traductions existantes, pour éviter 
       toute duplication de travail.
     </p>
    </sect2>
    <sect2>
     <heading>
       «&nbsp;Dé-fuzzy-fiez&nbsp;» les traductions complètes lors des 
       corrections de typos et d'orthographe
     </heading>
     <p>
       Quand le texte d'un questionnaire debconf est corrigé et que vous 
       êtes <strong>certain</strong> que les changements <strong>n'ont 
       aucun</strong> effet sur les traductions, soyez courtois avec les 
       traducteurs et dé-fuzzy-fiez leurs traductions.
     </p>
     <p>
       Si vous ne le faites pas, le questionnaire entier ne sera pas traduit 
       jusqu'à ce qu'un traducteur vous envoie une mise à jour.
     </p>
     <p>
       Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez 
       procéder ainsi&nbsp;:
      <enumlist numeration="arabic">
       <item>
        <p>
          enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si 
          les fichiers sont complets en utilisant (il faut que le paquet 
          <package>gettext</package> soit installé)&nbsp;:
         <example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
--statistics $i; done</example>
        </p>
       </item>
       <item>
        <p>
          déplacez tous les fichiers ayant des chaînes floues 
          («&nbsp;fuzzy&nbsp;») dans un emplacement temporaire. Les fichiers 
          n'ayant aucune chaîne floue (seulement des chaînes traduites et 
          non traduites) seront conservées où ils sont placés,
        </p>
       </item>
       <item>
        <p>
          maintenant <strong>et seulement maintenant</strong>, corrigez les 
          typos dans le questionnaire et vérifiez que les traductions ne 
          sont pas impactées (les typos, les fautes d'orthographe et parfois 
          les corrections de typographie sont généralement acceptables),
        </p>
       </item>
       <item>
        <p>
          exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes 
          les chaînes que vous avez modifiées dans les traductions. Vous 
          pouvez constater cela en exécutant à nouveau la commande 
          ci-dessus,
        </p>
       </item>
       <item>
        <p>
          utilisez la commande suivante&nbsp;:
         <example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
        </p>
       </item>
       <item>
        <p>
          déplacez dans debian/po les fichiers qui avaient des chaînes 
          floues dans la première étape,
        </p>
       </item>
       <item>
        <p>
          exécutez à nouveau <prgn>debconf-updatepo</prgn>.
        </p>
       </item>
      </enumlist>
     </p>
    </sect2>
    <sect2>
     <heading>
       Ne faites pas de suppositions à propos des interfaces
     </heading>
     <p>
       Le texte des modèles ne doit pas faire référence aux composants 
       appartenant à l'une des interfaces debconf. Des phrases comme 
       «&nbsp;If you answer Yes...&nbsp;» n'a aucun sens pour les 
       utilisateurs d'interfaces graphiques qui utilisent des cases à cocher 
       pour les questions booléennes.
     </p>
     <p>
       Les modèles de chaînes de caractères devraient éviter de mentionner 
       les valeurs par défaut dans leur description. Tout d'abord, parce que 
       cela est redondant avec les valeurs lues par les 
       utilisateurs. Ensuite, parce ces valeurs par défaut peuvent être 
       différentes selon les choix du responsable (par exemple, quand la 
       base de données debconf a été préremplie).
     </p>
     <p>
       Plus généralement, essayez d'éviter de vous référer à toute action de 
       l'utilisation. Donnez simplement des faits.
     </p>
    </sect2>
    <sect2>
     <heading>
       N'utilisez pas la première personne
     </heading>
     <p>
       Vous devriez éviter d'utiliser la première personne («&nbsp;I will do 
       this...&nbsp;» ou «&nbsp;We recommend...&nbsp;»). L'ordinateur n'est 
       pas une personne et les questionnaires debconf ne parlent pas pour 
       les développeurs Debian. Vous devriez utiliser une construction 
       neutre et souvent une forme passive. Pour ceux d'entre vous qui 
       écrivent déjà des publications scientifiques, écrivez simplement vos 
       questionnaires comme vous écririez un papier scientifique.
     </p>
    </sect2>
    <sect2>
     <heading>
       Soyez neutre dans le genre
     </heading>
     <p>
       Le monde est fait d'hommes et de femmes. Veuillez utiliser des 
       constructions neutres dans le genre dans votre texte. Ce n'est pas du 
       politiquement correct, c'est simplement montrer du respect pour toute 
       l'humanité.
     </p>
    </sect2>
   </sect1>
   <sect1>
    <heading>
      Définition des champs de questionnaires
    </heading>
    <p>
      Cette partie donne plusieurs informations qui sont principalement 
      extraites de la page de manuel <manref section="7" 
      name="debconf-devel">.
    </p>
    <sect2>
     <heading>
       Type
     </heading>
     <p>
     </p>
     <sect3>
      <heading>
        string: (chaîne de caractères)
      </heading>
      <p>
        Résulte en un champ d'entrée libre dans lequel l'utilisateur peut 
        écrire toute chaîne.
      </p>
     </sect3>
     <sect3>
      <heading>
        password: (mot de passe)
      </heading>
      <p>
        Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ 
        avec précaution&nbsp;; soyez conscient que le mot de passe que 
        l'utilisateur entre sera écrit dans la base de données debconf. Vous 
        devriez probablement enlever cette valeur de la base de données dès 
        que possible.
      </p>
     </sect3>
     <sect3>
      <heading>
        boolean: (booléen)
      </heading>
      <p>
        Un choix vrai/faux. Rappelez-vous&nbsp;: vrai/faux, <strong>pas oui/non</strong>...
      </p>
     </sect3>
     <sect3>
      <heading>
        select: (sélection)
      </heading>
      <p>
        Un choix parmi un certain nombre de valeurs. Les choix doivent être 
        spécifiés dans un champ nommé «&nbsp;Choices&nbsp;». Séparez les 
        valeurs possibles par des virgules et des espaces ainsi&nbsp;: 
        Choices: yes, no, maybe
      </p>
     </sect3>
     <sect3>
      <heading>
        multiselect: (sélection multiple)
      </heading>
      <p>
        Comme le type de données select, excepté que l'utilisateur peut 
        choisir un nombre quelconque d'éléments dans la liste de choix (ou 
        aucun d'entre eux).
      </p>
     </sect3>
     <sect3>
      <heading>
        note: (note)
      </heading>
      <p>
        Plutôt que d'être une question en tant que telle, ce type de donnée 
        indiqué une note qui peut être affichée à l'utilisateur. Il ne 
        devrait être utilisé que pour des données importantes que 
        l'utilisateur doit réellement voir, car debconf fera tout ce qu'il 
        peut pour s'assurer que l'utilisateur le voit&nbsp;; il stoppera 
        l'installation en attendant que l'utilisateur appuie sur une touche 
        ou il leur enverra même la note par courrier dans certains cas.
      </p>
     </sect3>
     <sect3>
      <heading>
        text: (texte)
      </heading>
      <p>
        Ce type est maintenant considéré comme obsolète&nbsp;: ne l'utilisez 
        pas.
      </p>
     </sect3>
     <sect3>
      <heading>
        error: (erreur)
      </heading>
      <p>
        <strong>CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR 
        DEBCONF.</strong>
      </p>
      <p>
        Il a été ajouté à cdebconf, la version C de debconf, utilisé en 
        premier dans l'installateur Debian.
      </p>
      <p>
        Veuillez ne pas l'utiliser à moins que debconf ne le prenne en 
        charge.
      </p>
      <p>
        Ce type est conçu pour gérer des messages d'erreur. Il est presque 
        semblable au type «&nbsp;note&nbsp;». Des interfaces peuvent le 
        présenter différemment (par exemple, l'interface dialog de cdebconf 
        affiche un écran rouge au lieu de l'écran bleu habituel).
      </p>
     </sect3>
    </sect2>
    <sect2>
     <heading>
       Description: description courte et étendue
     </heading>
     <p>
       Les descriptions des modèles sont composées de deux parties&nbsp;: 
       une courte et une étendue. La description courte est dans la ligne 
       «&nbsp;Description:&nbsp;» du questionnaire.
     </p>
     <p>
       La description courte devrait être gardée courte (50&nbsp;caractères 
       ou moins) pour qu'elle puisse être ajustée par la plupart des 
       interfaces debconf. La garder courte aide également les traducteurs, 
       car les traductions ont tendance à être plus longues que l'original.
     </p>
     <p>
       La description courte devrait se suffire à elle-même. Certaines 
       interfaces n'affichent pas la description longue par défaut ou 
       seulement si l'utilisateur la demande explicitement ou même ne 
       l'affichent pas du tout. Évitez des choses comme «&nbsp;What do you 
       want to do&nbsp;?&nbsp;».
     </p>
     <p>
       Il n'est pas nécessaire que la description courte soit une phrase 
       complète. Cela fait partie de la recommandation «&nbsp;gardez-la 
       courte et efficace&nbsp;».
     </p>
     <p>
       La description étendue ne devrait pas répéter la description courte 
       mot pour mot. Si vous ne trouvez pas de description longue, commencez 
       par à y réfléchir plus. Envoyez un message sur debian-devel. Demandez 
       de l'aide. Suivez un cours d'écriture&nbsp;! La description étendue 
       est importante. Si, après tout cela, vous ne trouvez toujours rien, 
       laissez-la vide.
     </p>
     <p>
       La description étendue devrait utiliser des phrases complètes. Des 
       paragraphes devraient être gardés court pour améliorer la 
       lisibilité. Ne mélangez pas deux idées dans le même paragraphe, mais 
       utilisez plutôt un autre paragraphe.
     </p>
     <p>
       Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les
       écrans trop longs. Par expérience, 20&nbsp;lignes est la limite à
       éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue
       classique, les utilisateurs devront faire défiler le texte et un grand
       nombre de personnes ne le font simplement pas.
     </p>
     <p>
       Pour des règles spécifiques selon le type de questionnaire (chaîne de 
       caractères, booléen, etc.), veuillez lire ci-dessous.
     </p>
    </sect2>
    <sect2>
     <heading>
       Choices (choix)
     </heading>
     <p>
       Ce champ devrait utilisé pour des types Select et Multiselect. Il 
       contient les choix possibles qui seront présentés aux 
       utilisateurs. Ces choix devraient être séparés par des virgules.
     </p>
    </sect2>
    <sect2>
     <heading>
       Default (valeur par défaut)
     </heading>
     <p>
       Ce champ est facultatif. Il contient la réponse par défaut pour les 
       modèles chaîne de caractères, sélection et multi-sélection. Pour des 
       questionnaires multi-sélection, il peut contenir une liste de choix 
       séparés par des virgules.
     </p>
    </sect2>
   </sect1>
   <sect1>
    <heading>
      Guide de style spécifique par champ de questionnaires
    </heading>
    <p>
    </p>
    <sect2>
     <heading>
       Champ Type
     </heading>
     <p>
       Aucune indication spécifique excepté&nbsp;: utilisez le type 
       approprié en vous référant à la section précédente.
     </p>
    </sect2>
    <sect2>
     <heading>
       Champ Description
     </heading>
     <p>
       Voici ci-dessous des instructions spécifiques pour écrire 
       correctement la description (courte et étendue) selon le type de 
       questionnaire.
     </p>
     <sect3>
      <heading>
        questionnaire chaîne de caractères/mot de passe
      </heading>
      <p>
       <list>
        <item>
         <p>
           La description courte est une invite et <strong>non</strong> un
           titre. Évitez des invites de style question («&nbsp;IP
           Address?&nbsp;») en faveur d'invites «&nbsp;ouvertes&nbsp;»à
           («&nbsp;IP address:&nbsp;»). L'utilisation des deux-points est
           recommandée.
         </p>
        </item>
        <item>
         <p>
           La description étendue est un complément à la description 
           courte. Dans la partie étendue, expliquez ce qui est demandé, 
           plutôt que de poser la même question à nouveau en utilisant des 
           mots plus longs. Utilisez des phrases complètes. Un style 
           d'écriture trop concis est fortement découragé.
         </p>
        </item>
       </list>
      </p>
     </sect3>
     <sect3>
      <heading>
        modèles booléens
      </heading>
      <p>
       <list>
        <item>
         <p>
           La description courte devrait être rédigée sous la forme d'une 
           question qui devrait être gardée courte et devrait généralement 
           se terminer par un point d'interrogation. Un style d'écriture 
           concis est permis et même encouragé si la question est plutôt 
           longue (rappelez-vous que les traductions sont souvent plus 
           longue que les versions d'origine)
         </p>
        </item>
        <item>
         <p>
           La description étendue ne devrait <strong>pas</strong> inclure de
           question.
         </p>
        </item>
        <item>
         <p>
           À nouveau, veuillez éviter de vous référer à des composants 
           d'interface spécifiques. Une erreur courante pour de telles 
           questionnaires est les constructions du type «&nbsp;if you answer 
           Yes&nbsp;».
         </p>
        </item>
       </list>
      </p>
     </sect3>
     <sect3>
      <heading>
        sélection/multi-sélection
      </heading>
      <p>
       <list>
        <item>
         <p>
           La description courte est une invite et <strong>non</strong> un
           titre. N'utilisez <strong>pas</strong> des constructions inutiles
           du type «&nbsp;Please choose...&nbsp;». Les utilisateurs sont assez
           intelligents pour réaliser qu'ils doivent choisir quelque chose...:)
         </p>
        </item>
        <item>
         <p>
           La description étendue devra compléter la description 
           courte. Elle peut se référer aux choix disponibles. Elle peut 
           également mentionner que l'utilisateur peut choisir plus d'un des 
           choix disponibles si le questionnaire est du type sélection 
           multiple (bien que l'interface rende souvent cela clair).
         </p>
        </item>
       </list>
      </p>
     </sect3>
     <sect3>
      <heading>
        Notes
      </heading>
      <p>
       <list>
        <item>
         <p>
           La description courte devrait être considéré comme un *titre*.
         </p>
        </item>
        <item>
         <p>
           La description étendue est ce qui sera affiché comme une 
           description plus détaillée de la note. Faites des phrases, 
           n'utilisez pas un style d'écriture trop concis.
         </p>
        </item>
        <item>
         <p>
           <strong>N'abusez pas de debconf.</strong> Les notes sont le moyen le plus courant 
           d'abus de debconf. Comme il est écrit dans la page de manuel de 
           debconf-devel&nbsp;: il est préférable de ne les utiliser que 
           pour des avertissements à propos de problèmes très sérieux. Les 
           fichiers NEWS.Debian ou README.Debian sont les endroits 
           appropriés pour un grand nombre de notes. Si, en lisant ceci, 
           vous envisagez de convertir vos modèles de type note en entrées 
           dans NEWS/Debian ou README.Debian, veuillez considérer de 
           conserver les traductions existantes pour une utilisation future.
         </p>
        </item>
       </list>
      </p>
     </sect3>
    </sect2>
    <sect2>
     <heading>
       Champ de choix
     </heading>
     <p>
       S'il est probable que les choix changent souvent, veuillez considérer 
       l'utilisation de l'astuce «&nbsp;__Choices&nbsp;». Cela séparera 
       chaque choix individuel en une chaîne de caractères seule, ce qui 
       aidera considérablement les traducteurs à faire leur travail.
     </p>
    </sect2>
    <sect2>
     <heading>
       Champ par défaut
     </heading>
     <p>
       S'il est probable que la valeur par défaut d'un modèle 
       «&nbsp;select&nbsp;» change selon la langue de l'utilisateur (par 
       exemple, s'il s'agit d'un choix de langue), veuillez utiliser 
       l'astuce «&nbsp;_DefaultChoice&nbsp;».
     </p>
     <p>
       Ce champ spécial permet aux traducteurs de positionner le choix le 
       plus approprié selon leur propre langue. Cela deviendra le choix par 
       défaut quand leur langue sera sélectionnée alors votre choix par 
       défaut sera utilisé pour l'anglais.
     </p>
     <p>
       Un exemple tiré des modèles du paquet geneweb&nbsp;:
      <example>
Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH FORM of your language
# For instance, the french translator will need to put "French (fr)" here.
_DefaultChoice: English (en)[ translators, please see comment in PO files]
_Description: Geneweb default language:
</example>
     </p>
     <p>
       Notez l'utilisation de crochets qui permettent des commentaires 
       internes dans les champs debconf. Notez également l'utilisation de 
       commentaires qui apparaîtront dans les fichiers sur lesquels 
       travailleront les traducteurs.
     </p>
     <p>
       Les commentaires sont nécessaires car l'astuce DefaultChoice est un 
       peu déroutante&nbsp;: les traducteurs peuvent y placer leur propre 
       choix.
     </p>
    </sect2>
    <sect2>
     <heading>
       Champ par défaut
     </heading>
     <p>
       N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas 
       utiliser de valeurs par défaut, n'utilisez simplement pas du tout 
       Default.
     </p>
     <p>
       Si vous utilisez po-debconf (et vous <strong>devriez</strong> le faire, voir 2.2), 
       veuillez considérer de rendre ce champ traduisible, si vous pensez 
       qu'il peut être traduit.
     </p>
     <p>
       Si la valeur par défaut peut varier selon la langue ou le pays (par 
       exemple, la valeur par défaut pour un choix de langue), veuillez 
       considérer l'utilisation du type spécial «&nbsp;_DefaultChoice&nbsp;» 
       documenté dans <manref section="7" name="po-debconf">).
     </p>
    </sect2>
   </sect1>
  </sect>
  <sect id="bpp-i18n">
   <heading>
     Internationalisation
   </heading>
   <sect1 id="bpp-i18n-debconf">
    <heading>
      Gestion des traductions de debconf
    </heading>
    <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>
    <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 
      pour le responsable et pour les traducteurs&nbsp;; des scripts de 
      transition sont fournis.
    </p>
    <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 section="7" name="po-debconf"> pour les 
      détails.
    </p>
   </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>
    <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>
    <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.
    </p>
   </sect1>
  </sect>
  <sect id="bpp-common-situations">
   <heading>
     Pratiques communes d'empaquetage
   </heading>
   <sect1 id="bpp-autotools">
    <heading>
      Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
    </heading>
    <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.
    </p>
   </sect1>
   <sect1 id="bpp-libraries">
    <heading>
      Bibliothèques
    </heading>
    <p>
      Pour diverses raisons, il a toujours été difficile d'empaqueter les 
      bibliothèques. 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>
    <p>
      Les bonnes pratiques d'empaquetage des bibliothèques ont été 
      regroupées dans <url id="&url-libpkg-guide;" name="le guide 
      d'empaquetage des bibliothèques">.
    </p>
   </sect1>
   <sect1 id="bpp-docs">
    <heading>
      Documentation
    </heading>
    <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é raisonnable 
      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>
   </sect1>
   <sect1 id="bpp-other">
    <heading>
      Types spécifiques de paquets
    </heading>
    <p>
      Plusieurs types spécifiques de paquets ont des sous-chartes spéciales 
      et des règles et pratiques d'empaquetage correspondantes&nbsp;:
     <list>
      <item>
       <p>
         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).
       </p>
      </item>
      <item>
       <p>
         Les paquets liés à Python ont leur charte Python&nbsp;; voir 
         &file-python-policy; dans le paquet <package>python</package>.
       </p>
      </item>
      <item>
       <p>
         Les paquets liés à Emacs ont leur <url id="&url-emacs-policy;" 
         name="charte Emacs">.
       </p>
      </item>
      <item>
       <p>
         Les paquets liés à Java ont leur <url id="&url-java-policy;" 
         name="charte Java">.
       </p>
      </item>
      <item>
       <p>
         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>.
       </p>
      </item>
      <item>
       <p>
         Les paquets fournissant des DTD XML ou SGML devraient se conformer 
         aux recommandations que l'on peut trouver dans le paquet 
         <package>sgml-base-doc</package>
       </p>
      </item>
      <item>
       <p>
         Les paquets Lisp devraient s'enregistrer avec le paquet 
         <package>common-lisp-controller</package> pour lequel vous pouvez 
         vous reporter au fichier &file-lisp-controller;.
       </p>
      </item>
     </list>
    </p>
   </sect1>
   <sect1 id="bpp-archindepdata">
    <heading>
      Données indépendantes de l'architecture
    </heading>
    <p>
      Il n'est pas rare d'avoir une grande quantité de données indépendantes 
      de l'architecture fournie avec un programme. Par exemple, des fichiers 
      audio, une collection d'icônes, des motifs de papiers peints ou autres 
      fichiers graphiques. Si la taille des données est négligeable par 
      rapport à la taille du reste du paquet, il est probablement mieux de 
      tout garder dans le même paquet.
    </p>
    <p>
      Cependant, si la taille des données est considérable, vous devez 
      envisager de les partager dans un paquet séparé et indépendant de 
      l'architecture («&nbsp;_all.deb&nbsp;»). Ainsi, en faisant cela, vous 
      évitez une duplication inutile des mêmes données dans onze fichiers 
      .debs pour chaque architecture. Bien que ceci ajoute une surcharge 
      supplémentaire aux fichiers <file>Packages</file>, ceci sauve beaucoup 
      d'espace disque sur les miroirs Debian. Séparer les données 
      indépendantes de l'architecture réduit également le temps de 
      traitement de <prgn>lintian</prgn> ou de <prgn>linda</prgn> (voir <ref 
      id="tools-lint">) quand ils sont exécutés sur l'ensemble de l'archive 
      Debian.
    </p>
   </sect1>
   <sect1 id="bpp-locale">
    <heading>
      Avoir besoin d'une certaine locale pendant la construction
    </heading>
    <p>
      Si vous avez besoin d'une certaine locale pendant la construction, 
      vous pouvez créer un fichier temporaire par cette astuce&nbsp;:
    </p>
    <p>
      Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et 
      LC_ALL au nom de la locale que vous générez, vous devriez obtenir ce 
      que vous voulez sans être root. Quelque chose comme ceci&nbsp;:
     <example>
LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8

mkdir -p $LOCALE_PATH
localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"

# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
</example>
    </p>
   </sect1>
   <sect1 id="bpp-transition">
    <heading>
      Rendre les paquets de transition conformes avec deborphan
    </heading>
    <p>
      Deborphan est un programme pour aider les utilisateurs à détecter 
      quels paquets peuvent être enlevés sans problème du système, i.e. ceux 
      dont aucun paquet ne dépend. L'opération par défaut est de chercher 
      seulement parmi les sections libs et oldlibs pour débusquer les 
      bibliothèques inutilisées. Mais si l'on passe le bon paramètre, il 
      tente d'attraper d'autres paquets inutiles.
    </p>
    <p>
      Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de 
      transition qui étaient nécessaires pour une mise à jour, mais qui 
      peuvent sans problème être supprimés. Pour cela, il recherche la 
      chaîne de caractères «&nbsp;dummy&nbsp;» ou «&nbsp;transitional&nbsp;» 
      dans la description courte.
    </p>
    <p>
      Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte 
      dans la description courte. Si vous cherchez des exemples, exécutez 
      simplement&nbsp;:
     <example>apt-cache search .|grep dummy</example>
      or
     <example>apt-cache search .|grep transitional</example>
      .
    </p>
   </sect1>
   <sect1 id="bpp-origtargz">
    <heading>
      Les meilleures pratiques pour les fichiers <file>orig.tar.gz</file>
    </heading>
    <p>
      Il existe deux types d'archives tar («&nbsp;tarball&nbsp;») source 
      d'origine&nbsp;: les sources vierges et les sources amont 
      réempaquetées.
    </p>
    <sect2 id="pristinesource">
     <heading>
       Sources vierges
     </heading>
     <p>
       La caractéristique définissant une archive source vierge est que le 
       fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar 
       officielle distribuée par l'auteur amont. <footnote><p>Nous ne 
       pouvons pas empêcher les auteurs amont de changer l'archive tar 
       qu'ils distribuent sans également incrémenter le numéro de version, 
       il ne peut donc pas y avoir de garantie qu'une archive vierge est 
       identique à ce que l'auteur amont distribue <em>actuellement</em> à 
       tout moment. La seule chose à laquelle on peut s'attendre est que 
       c'est identique à quelque chose que l'amont <em>a</em> un jour 
       distribuée. Si une différence se produit plus tard (par exemple, si 
       l'amont remarque qu'il n'a pas utilisé la compression maximale pour 
       sa distribution d'origine et qu'il la recompresse), c'est vraiment 
       trop dommage. Comme il n'y a pas de bonne façon d'envoyer un nouveau 
       .orig.tar.gz pour la même version, il n'y a même pas de raison de 
       traiter cette situation comme un bogue.</p></footnote> Cela rend 
       possible d'utiliser des vérifications de somme pour vérifier 
       facilement que tous les changements entre la version Debian et celle 
       de l'amont sont contenus dans le fichier diff Debian. Également, si 
       le source amont est énorme, les auteurs amont et d'autres qui ont 
       déjà l'archive tar amont peuvent économiser du temps de 
       téléchargement s'ils veulent inspecter votre empaquetage en détail.
     </p>
     <p>
       Il n'y a pas de règles universellement acceptées suivies par les 
       auteurs amont concernant la structure des répertoires dans leur 
       archive tar, mais <prgn>dpkg-source</prgn> est cependant capable de 
       traiter la plupart des archives tar comme source vierge. Sa stratégie 
       est équivalente à la suivante&nbsp;:
     </p>
     <p>
      <enumlist numeration="arabic">
       <item>
        <p>
          Il décompacte l'archive tar dans un répertoire temporaire vide par
         <example>
zcat chemin/vers/&lt;nom-du-paquet&gt;_&lt;version-amont&gt;.orig.tar.gz | tar xf -
         </example>
        </p>
       </item>
       <item>
        <p>
          Si, après cela, le répertoire temporaire ne contient qu'un 
          répertoire et pas d'autres fichiers, <prgn>dpkg-source</prgn> 
          renomme ce répertoire en 
          <tt>&lt;packagename&gt;-&lt;version-amont&gt;(.orig)</tt>. Le nom 
          du répertoire de premier niveau dans l'archive tar n'a pas 
          d'importance et est oublié.
        </p>
       </item>
       <item>
        <p>
          Sinon, l'archive tar a dû être empaqueté sans répertoire de 
          premier niveau commun (honte à l'auteur amont&nbsp;!). Dans ce 
          cas, <prgn>dpkg-source</prgn> renomme le répertoire temporaire 
          <em>lui-même</em> en 
          <tt>&lt;packagename&gt;-&lt;version-amont&gt;(.orig)</tt>.
        </p>
       </item>
      </enumlist>
     </p>
    </sect2>
    <sect2 id="repackagedorigtargz">
     <heading>
       Réempaquetage des sources amont
     </heading>
     <p>
       Vous <strong>devriez</strong> envoyer des paquets sources avec une 
       archive tar vierge si possible, mais il peut y avoir diverses raisons 
       pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne 
       distribue pas le source comme un tar gzipé du tout ou si l'archive 
       tar amont contient du matériel non libre au sens des DFSG que vous 
       devez supprimer avant l'envoi.
     </p>
     <p>
       Dans tous ces cas, le développeur doit construire un fichier 
       .orig.tar.gz convenable lui-même. Nous nous référerons à une telle 
       archive tar comme un «&nbsp;source amont réempaqueté&nbsp;». Notez 
       qu'un «&nbsp;source amont réempaqueté&nbsp;» est différent d'un 
       paquet natif Debian. Un source réempaqueté est toujours fourni avec 
       des changements spécifiques Debian dans un fichier <tt>.diff.gz</tt> 
       séparé et il a toujours un numéro de version composé de 
       <tt>&lt;source-amont&gt;</tt> et de <tt>&lt;debian-revision&gt;</tt>.
     </p>
     <p>
       Il peut y avoir des cas où il est souhaitable de réempaqueter le 
       source même si l'amont distribue un fichier <tt>.tar.gz</tt> qui 
       pourrait en principe être utilisé dans sa forme vierge. Le plus 
       évident est si des économies d'espaces <em>significatives</em> 
       peuvent être réalisées en recompressant l'archive tar ou en 
       supprimant des parties fondamentalement inutiles de l'archive 
       source. Agissez à votre guise à cet endroit, mais soyez prêt à 
       défendre votre décision si vous réempaquetez un source qui aurait pu 
       être vierge.
     </p>
     <p>
       Un .orig.tar.gz réempaqueté&nbsp;:
     </p>
     <p>
      <enumlist numeration="arabic">
       <item>
        <p>
          <strong>doit</strong> contenir des informations détaillées sur la 
          façon dont a été obtenu le source réempaqueté et comment cela peut 
          être reproduit dans le fichier <file>README.Debian-source</file> 
          ou un fichier similaire. Ce fichier devrait être dans la partie 
          <file>diff.gz</file> du paquet source Debian, habituellement dans 
          le répertoire <file>debian</file>, <em>pas</em> dans le 
          <file>orig.tar.gz</file> réempaqueté. C'est également une bonne 
          idée de fournir une cible <tt>get-orig-source</tt> dans votre 
          fichier <file>debian/rules</file> qui répète le processus, comme 
          décrit dans la Charte, <url 
          id="&url-debian-policy;ch-source.html#s-debianrules" 
          name="debian/rules, le principal script de construction">.
        </p>
       </item>
       <item>
        <p>
          <strong>ne devrait pas</strong> contenir de fichiers qui ne 
          viennent pas de l'auteur amont ou dont vous avez changé le 
          contenu. <footnote><p>Comme exception spéciale, si l'omission d'un 
          fichier non libre devait entraîner l'échec de la compilation du 
          source sans assistance du diff Debian, il peut être approprié au 
          lieu de cela d'éditer les fichiers, en omettant seulement les 
          parties non libres de ceux-ci et/ou d'expliquer la situation dans 
          un fichier README.Debian-source à la racine de l'arborescence du 
          source. Mais dans ce cas, veuillez également demander instamment à 
          l'auteur amont de faciliter la séparation des composants non 
          libres du reste du source.</p></footnote>
        </p>
       </item>
       <item>
        <p>
          <strong>devrait</strong>, sauf cas impossible pour des raisons 
          légales, préserver l'infrastructure de construction entière et de 
          portabilité fournie par l'auteur amont. Par exemple, ce n'est pas 
          une raison suffisante pour omettre un fichier qui n'est utilisé 
          que pour la construction sur MS-DOS. De manière similaire, un 
          Makefile fourni par l'amont ne devrait pas être réécrit en 
          exécutant un script configure.
        </p>
        <p>
          (<em>Explication&nbsp;:</em> il est courant que les utilisateurs 
          Debian qui ont besoin de reconstruire un logiciel pour des 
          plates-formes non-Debian récupèrent le source d'un miroir Debian 
          plutôt que de chercher à localiser un point de distribution 
          amont).
        </p>
       </item>
       <item>
        <p>
          <strong>devrait</strong> utiliser 
          <tt>&lt;nom-du-paquet&gt;-&lt;version-amont&gt;.orig</tt> comme 
          nom du répertoire de premier niveau dans son archive tar. Cela 
          rend possible la distinction entre des archives tar vierges 
          d'archives réempaquetées.
        </p>
       </item>
       <item>
        <p>
          <strong>devrait</strong> être gzipé avec une compression maximale.
        </p>
       </item>
      </enumlist>
     </p>
     <p>
       La façon canonique de réaliser les deux derniers points est de 
       laisser <tt>dpkg-source -b</tt> construire l'archive tar réempaquetée 
       à partir du répertoire décompacté.
     </p>
    </sect2>
    <sect2 id="changed-binfiles">
     <heading>
       Changer des fichiers binaires dans le <tt>diff.gz</tt>
     </heading>
     <p>
       Il est parfois nécessaire de changer des fichiers binaires contenus 
       dans l'archive tar d'origine ou d'ajouter des fichiers binaires qui 
       ne sont pas dans celle-ci. Si cela est fait en copiant simplement les 
       fichiers dans l'arborescence de l'archive debianisée, 
       <prgn>dpkg-source</prgn> ne pourra pas gérer cela. D'un autre côté, 
       selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un 
       tel fichier binaire modifié dans un fichier <file>orig.tar.gz</file> 
       réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire 
       <file>debian</file> dans un format <prgn>uuencode</prgn> (ou 
       semblable) <footnote><p>Le fichier devrait avoir un nom qui indique 
       clairement quel fichier binaire il encode. Habituellement, un 
       postfixe indiquant le codage devrait être ajouté au nom du fichier 
       d'origine. Notez que vous n'avez pas besoin de dépendre de
       <package>sharutils</package> pour avoir le programme
       <prgn>uudecode</prgn> si vous utilisez la fonction <tt>pack</tt> de
       <prgn>perl</prgn>. Le code pourrait ressembler à ceci&nbsp;:
       <example>
uuencode-file:
    perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded

uudecode-file:
    perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
       </example>
      </p></footnote>. Le fichier sera ensuite décodé et copié à 
       son emplacement pendant l'étape de construction. Le changement sera 
       donc visible assez facilement.
     </p>
     <p>
       Certains paquets utilisent <prgn>dbs</prgn> pour gérer les correctifs 
       à leur source amont et créent toujours un nouveau fichier 
       <tt>orig.tar.gz</tt> contenant le vrai <tt>orig.tar.gz</tt> dans son 
       répertoire de premier niveau. Cela est discutable concernant la 
       préférence pour un source vierge. D'un autre côté, il est facile de 
       modifier ou d'ajouter des fichiers binaires dans ce cas&nbsp;: placez 
       les simplement dans le fichier <tt>orig.tar.gz</tt> nouvellement créé 
       à côté du vrai et copiez les au bon endroit pendant l'étape de 
       construction.
     </p>
    </sect2>
   </sect1>
  </sect>
 </chapt>
 <chapt id="beyond-pkging">
  <heading>
    Au-delà de l'empaquetage
  </heading>
  <p>
    Debian, c'est beaucoup plus que de l'empaquetage 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>
  <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.
  </p>
  <sect id="submit-bug">
   <heading>
     Rapporter des bogues
   </heading>
   <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>
   <p>
     Lisez les <url id="&url-bts-report;" name="instructions pour créer un 
     rapport de bogue"> dans le <url id="&url-bts;" name="système de suivi 
     des bogues"> Debian.
   </p>
   <p>
     Essayez de soumettre le bogue à partir d'un compte utilisateur normal 
     sur lequel vous pouvez recevoir des courriers, pour que les personnes 
     puissent vous joindre s'ils ont besoin de plus d'informations à propos 
     du bogue. Ne soumettez pas de bogues en tant que root.
   </p>
   <p>
     Vous pouvez utiliser un outil comme <manref section="1" 
     name="reportbug"> pour soumettre des bogues. Il peut automatiser et 
     dans l'ensemble faciliter le processus.
   </p>
   <p>
     Assurez-vous que le bogue n'a pas déjà été rapporté. Chaque paquet 
     dispose d'une liste de bogues facilement accessible à 
     <tt>http://&bugs-host;/<var>nom_paquet</var></tt>. Des outils comme 
     <manref section="1" name="querybts"> peuvent également vous fournir ces 
     informations (et <prgn>reportbug</prgn> invoquera également 
     habituellement <prgn>querybts</prgn> avant l'envoi).
   </p>
   <p>
     Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple, 
     votre bogue concerne un paquet qui réécrit des fichiers d'un autre 
     paquet, vérifiez les listes des bogues pour les <em>deux</em> paquets 
     pour éviter de créer des rapports de bogues dupliqués.
   </p>
   <p>
     Vous pouvez également parcourir les bogues d'autres paquets, en les 
     regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec 
     «&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 obtenu la permission du responsable).
   </p>
   <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:<var>&lt;votre-adresse-de-courrier&gt;</var></tt>.
   </p>
   <sect1 id="submit-many-bugs">
    <heading>
      Ouvrir un grand nombre de rapports en une seule fois («&nbsp;mass bug 
      filing&nbsp;»)
    </heading>
    <p>
      Ouvrir un grand nombre de rapports pour le même problème sur un grand 
      nombre de paquets &mdash;&nbsp;plus de dix&nbsp;&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>
    <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; et de mentionner le fait dans le sujet de votre 
      message. 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>
    <p>
      Veuillez utiliser les programmes <prgn>dd-list</prgn> et si nécessaire,
      <prgn>whodepends</prgn> (du paquet <package>devscripts</package>) pour
      générer une liste de tous les paquets concernés et incluez la sortie
      dans votre courrier à &email-debian-devel;.
    </p>
    <p>
      Quand vous envoyez un grand nombre de rapports sur le même sujet, vous 
      devriez les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils 
      ne soient pas redirigés vers les listes de diffusion.
    </p>
   </sect1>
  </sect>
  <sect id="qa-effort">
   <heading>
     Effort d'assurance qualité
   </heading>
   <sect1 id="qa-daily-work">
    <heading>
      Travail journalier
    </heading>
    <p>
      Bien qu'il y ait un groupe de personnes dédié à 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">).
    </p>
   </sect1>
   <sect1 id="qa-bsp">
    <heading>
      Les chasses aux bogues
    </heading>
    <p>
      De temps en temps, le groupe d'assurance qualité organise des chasses 
      aux bogues<footnote><p><em>Bug Squashing Party</em></p></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>
    <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 voulez gérer vous-même le bogue, veuillez 
      l'expliquer dans le BTS.
    </p>
    <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 d'habitude&nbsp;; 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 tout souhait du 
      responsable s'il en a exprimé.
    </p>
    <p>
      Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante, 
      envoyez simplement un correctif au BTS. C'est de loin meilleur qu'une 
      mise à jour défectueuse.
    </p>
   </sect1>
  </sect>
  <sect id="contacting-maintainers">
   <heading>
     Contacter d'autres responsables
   </heading>
   <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>
   <p>
     Chercher l'adresse d'un responsable d'un paquet peut être 
     fastidieux. Heureusement, il existe un alias de courrier simple, 
     <tt>&lt;paquet&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;paquet&gt;</tt> par le nom du paquet 
     source ou binaire.
   </p>
   <p>
     Vous pouvez également vouloir contacter les personnes qui sont 
     inscrites à un paquet de source donné par le <ref 
     id="pkg-tracking-system">. Vous pouvez le faire en utilisant l'adresse 
     <tt>&lt;paquet&gt;@&pts-host;</tt>.
   </p>
  </sect>
  <sect id="mia-qa">
   <heading>
     Gérer les responsables non joignables
   </heading>
   <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. Il est possible qu'il ne soit plus actif, 
     mais qu'il ne se soit pas désenregistré du système. D'un autre côté, il 
     est possible qu'il ait simplement besoin d'un rappel.
   </p>
   <p>
     Il y a un système simple (la base de données MIA) dans laquelle les 
     informations sur les responsables supposés Absents En Exercice 
     («&nbsp;Missing In Action) sont enregistrées. Quand un membre du groupe 
     QA contacte un responsable inactif ou trouve plus d'informations sur 
     celui-ci, c'est enregistré dans la base de données MIA. Ce système est 
     disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut 
     être interrogé avec un outil de nom <prgn>mia-query</prgn>.
     Utilisez <example>mia-query --help</example> pour voir comment interroger
     la base de données. Si vous déterminez qu'aucune 
     information n'a encore été enregistrée pour un responsable inactif ou 
     si vous voulez ajouter plus d'informations, vous deviez utiliser la 
     procédure suivante.
   </p>
   <p>
     La première étape est de contacter poliment le responsable et 
     d'attendre une réponse pendant un temps raisonnable. Il est assez 
     difficile de définir le «&nbsp;temps raisonnable&nbsp;», mais il est 
     important de prendre en compte que la vraie vie est parfois assez 
     mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel 
     après deux semaines.
   </p>
   <p>
     Si le responsable ne répond pas après quatre semaines (un mois), on 
     peut supposer qu'il n'y aura probablement pas de réponse. Si ceci se 
     produit, vous devriez poursuivre vos investigations et essayer de 
     réunir toutes les informations utiles sur ce responsable. Ceci 
     inclut&nbsp;:
   </p>
   <p>
    <list>
     <item>
      <p>
        Les informations «&nbsp;echelon&nbsp;» disponibles dans la <url 
        id="&url-debian-db;" name="base de données LDAP des développeurs">, 
        qui indiquent quand le développeur a envoyé un message pour la 
        dernière fois sur une liste de diffusion Debian (cela inclut les 
        envois via les listes debian-*-changes). Rappelez-vous également de 
        vérifier si le responsable est indiqué comme en vacances dans la 
        base de données.
      </p>
     </item>
     <item>
      <p>
        Le nombre de paquets de ce responsable et les conditions de ces 
        paquets. En particulier, reste-t-il des bogues empêchant 
        l'intégration du paquet dans la distribution qui sont ouverts depuis 
        des lustres&nbsp;? De plus, combien de bogues y a-t-il en 
        général&nbsp;? Un autre point d'information important est si les 
        paquets ont subi des mises à jour indépendantes et si oui, par qui.
      </p>
     </item>
     <item>
      <p>
        Est-ce que le responsable est actif en dehors de Debian&nbsp;? Par 
        exemple, il peut avoir envoyé des messages récemment à des listes de 
        diffusion non-Debian ou des groupes de discussion.
      </p>
     </item>
    </list>
   </p>
   <p>
     Un problème particulier est représenté par les paquets parrainés 
     &mdash;&nbsp;le responsable n'est pas un développeur Debian 
     officiel. Les informations «&nbsp;echelon&nbsp;» ne sont pas 
     disponibles pour les personnes parrainées, par exemple, vous devez donc 
     trouver et contacter le responsable Debian qui a réellement envoyé le 
     paquet. Étant donné qu'il a signé le paquet, il est responsable de 
     l'envoi de toute façon et il est probable qu'il sait ce qui s'est passé
     avec la personne qu'il parraine.
   </p>
   <p>
     Il est également permis d'envoyer une demande à &email-debian-devel; 
     demandant si quelqu'un est au courant d'information sur le responsable 
     manquant. Veuillez mettre en CC: la personne en question.
   </p>
   <p>
     Une fois que vous avez réuni toutes ces informations, vous pouvez 
     contacter &email-mia;. Les personnes de cet alias utiliseront les 
     informations que vous aurez fournies pour décider comment procéder. Par 
     exemple, ils peuvent abandonner un ou tous les paquets du 
     responsable. Si un paquet a subi une mise à jour indépendante, ils 
     peuvent préférer contacter le responsable ayant fait cette mise à jour 
     &mdash; il est peut-être intéressé par le paquet.
   </p>
   <p>
     Un dernier mot&nbsp;: veuillez vous souvenir d'être poli. Nous sommes 
     tous des volontaires et nous ne pouvons dédier l'intégralité de notre 
     temps à Debian. Vous n'êtes pas non plus au courant des circonstances 
     de la personne impliquée. Elle est peut-être sérieusement malade ou 
     pourrait même nous avoir quitté &mdash;&nbsp;vous ne savez pas qui 
     recevra vos courriers. Imaginez comme un proche se sentira s'il lit un 
     courrier pour la personne décédée et trouve un message très impoli, en 
     colère et accusateur&nbsp;!
   </p>
   <p>
     D'un autre côté, bien que nous soyons tous volontaires, nous avons une 
     responsabilité. Vous pouvez donc insister sur l'importance du plus 
     grand intérêt &mdash;&nbsp;si un responsable n'a plus le temps ou 
     l'envie, il devrait «&nbsp;laisser filer&nbsp;» et donner le paquet à 
     quelqu'un ayant plus de temps.
   </p>
   <p>
     Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez
     étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org
     où les détails techniques et les procédures MIA sont documentées et
     contactez &email-mia;.
   </p>
  </sect>
  <sect id="newmaint">
   <heading>
     Interagir avec de futurs développeurs Debian
   </heading>
   <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.
   </p>
   <sect1 id="sponsoring">
    <heading>
      Parrainer des paquets
    </heading>
    <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>
    <p>
      Les nouveaux responsables ont habituellement certaines difficultés à 
      créer des paquets Debian &mdash;&nbsp;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>
    <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, il est toujours possible de 
      savoir que c'est vous qui avez fait l'envoi.
    </p>
    <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><p>Tasks and Skills</p></footnote> de sa 
      candidature.
    </p>
   </sect1>
   <sect1>
    <heading>
      Gérer les paquets parrainés
    </heading>
    <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>
    <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>
    <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>
    <p>
      Une fois que le paquet a atteint les standards Debian, construisez et 
      signez le paquet avec
     <example>dpkg-buildpackage -k<var>KEY-ID</var></example>
      avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez 
      également utiliser toute partie de votre <var>KEY-ID</var>, tant 
      qu'elle est unique dans votre porte-clés secret.
    </p>
    <p>
      Le champ Maintainer du fichier <file>control</file> et le fichier 
      <file>changelog</file> devraient afficher la personne qui a fait 
      l'empaquetage, 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>
    <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>
    <p>
      Vous êtes encouragé à garder un &oelig;il sur le suivi des paquets que 
      vous parrainez en utilisant le <ref id="pkg-tracking-system">.
    </p>
   </sect1>
   <sect1>
    <heading>
      Recommander un nouveau développeur
    </heading>
    <p>
      Reportez-vous à la page sur les <url id="&url-newmaint-advocate;" 
      name="recommandations pour un développeur prospectif"> sur le site web 
      Debian.
    </p>
   </sect1>
   <sect1>
    <heading>
      Gérer les candidatures des nouveaux candidats
    </heading>
    <p>
      Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" 
      name="liste à vérifier pour les responsables de candidatures"> sur le 
      site web Debian.
    </p>
   </sect1>
  </sect>
 </chapt>
 <chapt id="l10n">
  <heading>
    Internationalisation, traduction, être internationalisé et être traduit
  </heading>
  <p>
    Debian prend en charge un nombre toujours croissant de langues 
    naturelles. Même si l'anglais est votre langue maternelle et que vous ne 
    parlez pas d'autre langue, il est de votre devoir de responsable d'être 
    conscient des problèmes d'internationalisation (abrégé en i18n à cause 
    des 18&nbsp;lettres entre le i et le n dans internationalisation). C'est 
    pourquoi, même si des programmes seulement en anglais vous suffisent, 
    vous devriez lire la plupart de ce chapitre.
  </p>
  <p>
    Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/" 
    name="introduction à l'i18n"> de Tomohiro KUBOTA, «&nbsp;I18N 
    (internationalisation) veut dire la modification d'un logiciel ou de 
    technologies liées pour qu'un logiciel puisse potentiellement gérer des 
    langues multiples, des conventions multiples et ainsi de suite dans le 
    monde entier&nbsp;» alors que «&nbsp;L10N (localisation) veut dire 
    l'implémentation dans une langue spécifique pour un logiciel déjà 
    internationalisé&nbsp;».
  </p>
  <p>
    La l10n et l'i18n sont interconnectées, mais les difficultés liées à 
    chacune sont très différentes. Il n'est pas vraiment difficile de 
    permettre à un programme de changer la langue dans laquelle sont 
    affichés les textes selon les paramètres de l'utilisateur, mais il est 
    très coûteux en temps de traduire réellement ces messages. D'un autre 
    côté, définir le codage des caractères est trivial, mais adapter le code 
    pour utiliser des codages de caractères différents est un problème 
    vraiment difficile.
  </p>
  <p>
    En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas 
    de règle générale, il n'y a pas actuellement d'infrastructure 
    centralisée pour la l10n dans Debian qui puisse être comparée au 
    mécanisme dbuild pour le portage. Le plus gros du travail doit donc être 
    réalisé manuellement.
  </p>
  <sect id="l10n-handling">
   <heading>
     Comment sont gérées les traductions au sein de Debian
   </heading>
   <p>
     La gestion des traductions des textes contenus dans un paquet est 
     encore une tâche manuelle et le processus dépend du type de texte que 
     vous désirez voir traduit.
   </p>
   <p>
     Pour les messages des programmes, l'infrastructure gettext est utilisée 
     pour la plupart d'entre eux. La plupart du temps, la traduction est 
     gérée en amont dans des projets comme le <url 
     id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de 
     traduction libre">, le <url 
     id="http://developer.gnome.org/projects/gtp/" name="projet de 
     traduction de Gnome"> ou <url id="http://i18n.kde.org/" name="celui de 
     KDE">. La seule ressource centralisée dans Debian est les <url 
     id="http://www.debian.org/intl/l10n/" name="statistiques de traduction 
     Debian centralisées"> où vous pouvez trouver des statistiques sur les 
     fichiers de traduction trouvés dans les paquets, mais il n'y a aucune 
     infrastructure pour faciliter le processus de traduction.
   </p>
   <p>
     Un effort pour traduire les descriptions de paquet a démarré il y a 
     longtemps, même si les outils fournissent très peu de prise en charge 
     pour les utiliser vraiment (i.e., seul APT peut les utiliser quand il 
     est configuré convenablement). Les responsables n'ont rien à faire de 
     particulier pour gérer les traductions des descriptions de 
     paquets&nbsp;; les traducteurs devraient utiliser le <url 
     id="http://ddtp.debian.org/" name="DDTP">.
   </p>
   <p>
     Pour les questionnaires debconf, les responsable devraient utiliser le 
     paquet po-debconf pour faciliter le travail des traducteurs, qui 
     peuvent utiliser le DDTP pour faire leur travail (mais les équipes 
     française et brésilienne ne le font pas). On peut trouver certaines 
     statistiques à la fois sur le site du DDTP (à propos de ce qui est 
     vraiment traduit) et sur le site des <url 
     id="http://www.debian.org/intl/l10n/" name="statistiques de traduction 
     Debian centralisées"> (à propos de ce qui est intégré dans les 
     paquets).
   </p>
   <p>
     Pour les pages web, chaque équipe l10n a accès au CVS correspondant et 
     les statistiques sont disponibles sur le site des statistiques de 
     traduction Debian centralisées.
   </p>
   <p>
     Pour la documentation générale à propos de Debian, le processus est 
     plus ou moins le même que pour les pages web (les traducteurs ont accès 
     au CVS), mais il n'y a pas de page de statistiques.
   </p>
   <p>
     Pour la documentation spécifique aux paquets (pages de manuel, 
     documents info, autres formats), presque tout est encore à faire.
   </p>
   <p>
     Le plus notablement, le projet KDE gère la traduction de ses 
     documentations de la même façon que ses messages de programme.
   </p>
   <p>
     Il existe un effort pour gérer les pages de manuel spécifiques Debian 
     au sein d'un <url 
     id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt CVS 
     spécifique">.
   </p>
  </sect>
  <sect id="l10n-faqm">
   <heading>
     FAQ I18N &amp; L10N pour les responsables
   </heading>
   <p>
     Voici une liste des problèmes que les responsables peuvent rencontrer 
     concernant l'i18n et la l10n. Lorsque vous lirez cela, gardez à 
     l'esprit qu'il n'y a pas de consensus sur ces points au sein de Debian 
     et que ce ne sont que des conseils. Si vous avez une meilleure idée 
     pour un problème donné ou si vous êtes en désaccord avec certains 
     points, vous êtes libre de fournir vos impressions pour que ce document 
     puisse être amélioré.
   </p>
   <sect1 id="l10n-faqm-tr">
    <heading>
      Comment faire en sorte qu'un texte soit traduit
    </heading>
    <p>
      Pour traduire des descriptions de paquet ou des questionnaires 
      debconf, vous n'avez rien à faire, l'infrastructure du DDTP répartira 
      le matériel à traduire aux volontaires sans besoin d'interaction de 
      votre part.
    </p>
    <p>
      Pour tous les autres matériels (fichiers gettext, pages de manuel ou 
      autre documentation), la meilleure solution est de placer votre texte 
      quelque part sur l'Internet et de demander sur debian-i18n la 
      traduction dans différentes langues. Certains membres des équipes de 
      traduction sont abonnés à cette liste et ils prendront soin de la 
      traduction et du processus de relecture. Une fois qu'ils ont fini, 
      vous recevrez de leur part votre document traduit dans votre boîte aux 
      lettres.
    </p>
   </sect1>
   <sect1 id="l10n-faqm-rev">
    <heading>
      Comment faire en sorte qu'une traduction donnée soit relue
    </heading>
    <p>
      De temps en temps, des personnes indépendantes traduiront certains 
      textes inclus dans votre paquet et vous demanderont d'inclure la 
      traduction dans le paquet. Cela peut devenir problématique si vous 
      n'êtes pas familier avec la langue donnée. C'est une bonne idée 
      d'envoyer le document à la liste de diffusion l10n correspondante en 
      demandant une relecture. Une fois celle-ci faite, vous devriez avoir 
      plus confiance dans la qualité de la traduction et l'inclure sans 
      crainte dans votre paquet.
    </p>
   </sect1>
   <sect1 id="l10n-faqm-update">
    <heading>
      Comment faire en sorte qu'une traduction donnée soit mise à jour
    </heading>
    <p>
      Si vous avez certaines traductions d'un texte donné qui traînent, 
      chaque fois que vous mettez à jour l'original, vous devriez demander 
      au précédent traducteur de mettre à jour sa traduction avec vos 
      nouveaux changements. Gardez à l'esprit que cette tâche demande du 
      temps&nbsp;; au moins une semaine pour obtenir une mise à jour relue.
    </p>
    <p>
      Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur 
      la liste de diffusion correspondante. Si tout échoue, n'oubliez pas de 
      mettre un avertissement dans le document traduit, indiquant que la 
      traduction est un peu obsolète et que le lecteur devrait se référer au 
      document d'origine si possible.
    </p>
    <p>
      Évitez de supprimer complètement une traduction à cause de son 
      obsolescence. Un vieux document est souvent mieux que pas de 
      documentation du tout pour les personnes non anglophones.
    </p>
   </sect1>
   <sect1 id="l10n-faqm-bug">
    <heading>
      Comment gérer un rapport de bogue concernant une traduction
    </heading>
    <p>
      La meilleure solution peut être de marquer le bogue comme «&nbsp;suivi 
      au développeur amont&nbsp;» (<em>forwarded to upstream</em>) et de 
      faire suivre le bogue à la fois au précédent traducteur et à son 
      équipe (en utilisant la liste de diffusion debian-l10n-XXX 
      correspondante).
    </p>
   </sect1>
  </sect>
  <sect id="l10n-faqtr">
   <heading>
     FAQ I18N &amp; L10N pour les traducteurs
   </heading>
   <p>
     Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de procédure 
     générale dans Debian concernant ces points et que, dans tous les cas, 
     vous devriez collaborer avec votre équipe et les responsables des 
     paquets.
   </p>
   <sect1 id="l10n-faqtr-help">
    <heading>
      Comment aider l'effort de traduction
    </heading>
    <p>
      Choisissez ce que vous désirez traduire, assurez-vous que personne ne 
      travaille déjà dessus (en utilisant votre liste de diffusion 
      debian-l10n-XXX), traduisez-le, faites-le relire par d'autres 
      personnes dont c'est également la langue maternelle sur votre liste de 
      diffusion l10n et fournissez-le au responsable du paquet (voir le 
      point suivant).
    </p>
   </sect1>
   <sect1 id="l10n-faqtr-inc">
    <heading>
      Comment fournir une traduction pour inclusion dans un paquet
    </heading>
    <p>
      Assurez-vous que votre traduction est correcte (en demandant une 
      relecture sur votre liste de discussion l10n) avant de la fournir pour 
      inclusion. Cela gagnera du temps à tout le monde et évitera le chaos 
      qui résulterait d'avoir plusieurs versions du même document dans les 
      rapports de bogue.
    </p>
    <p>
      La meilleure solution est de créer un rapport de bogue standard 
      contenant la traduction sur le paquet. Assurez-vous d'utiliser 
      l'étiquette «&nbsp;patch&nbsp;» et n'utilisez pas une gravité 
      supérieure à «&nbsp;wishlist&nbsp;» car l'absence de traduction n'a 
      jamais empêché un programme de fonctionner.
    </p>
   </sect1>
  </sect>
  <sect id="l10n-best">
   <heading>
     Meilleures pratiques actuelles concernant la l10n
   </heading>
   <p>
    <list>
     <item>
      <p>
        En tant que responsable, ne modifiez jamais les traductions en 
        aucune façon (même pour reformater l'affichage) sans demander à la 
        liste de diffusion l10n correspondante. Vous risquez, par exemple, 
        de casser le codage du fichier en agissant ainsi. De plus, ce que 
        vous considérez comme une erreur peut être correct (ou même 
        nécessaire) pour une langue donnée.
      </p>
     </item>
     <item>
      <p>
        En tant que traducteur, si vous trouvez une erreur dans le texte 
        d'origine, assurez-vous de l'indiquer. Les traducteurs sont souvent 
        les lecteurs les plus attentifs d'un texte donné et s'ils ne rendent 
        pas compte des erreurs qu'ils trouvent, personne ne le fera.
      </p>
     </item>
     <item>
      <p>
        Dans tous les cas, rappelez-vous que le problème principal avec la 
        l10n est qu'elle demande la coopération de plusieurs personnes et 
        qu'il est très facile de démarrer une guerre incendiaire à propos de 
        petits problèmes dûs à des incompréhensions. Donc, si vous avez des 
        problèmes avec votre interlocuteur, demandez de l'aide sur la liste 
        de diffusion l10n correspondante, sur debian-i18n ou même sur 
        debian-devel (attention, cependant, les discussions sur la l10n 
        tournent très souvent à l'incendie sur cette liste :)
      </p>
     </item>
     <item>
      <p>
        Dans tous les cas, la coopération ne peut être atteinte qu'avec un 
        <strong>respect mutuel</strong>.
      </p>
     </item>
    </list>
   </p>
  </sect>
 </chapt>
 <appendix id="tools">
  <heading>
    Aperçu des outils du responsable Debian
  </heading>
  <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.
  </p>
  <p>
    Les outils du responsable Debian sont destinés à aider les responsables 
    et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry 
    Wall, il y a plus d'une manière de le faire.
  </p>
  <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 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>
  <p>
    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;nom_paquet&gt;</tt>.
  </p>
  <sect id="tools-core">
   <heading>
     Outils de base
   </heading>
   <p>
     Les outils suivants sont pratiquement nécessaires à tout responsable.
   </p>
   <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 essentiels à tout 
      responsable Debian.
    </p>
   </sect1>
   <sect1 id="debconf">
    <heading>
      <package>debconf</package>
    </heading>
    <p>
      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 dialogue. D'autres types d'interface 
      peuvent être ajoutés sous forme de modules.
    </p>
    <p>
      Vous trouverez la documentation de ce paquet dans le paquet 
      <package>debconf-doc</package>.
    </p>
    <p>
      Beaucoup pensent que ce système devrait être utilisé pour tout paquet 
      nécessitant une configuration interactive&nbsp;; reportez-vous à la 
      <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.
    </p>
   </sect1>
   <sect1 id="fakeroot">
    <heading>
      <package>fakeroot</package>
    </heading>
    <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>.
    </p>
   </sect1>
  </sect>
  <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>
    <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 signification de chaque erreur, la 
      partie concernée dans la charte et le moyen habituel de régler le 
      problème.
    </p>
    <p>
      Veuillez vous reporter à <ref id="sanitycheck"> pour plus 
      d'informations sur comment et quand utiliser Lintian.
    </p>
    <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> 
      pour l'ensemble de la distribution de développement 
      (<em>unstable</em>).
    </p>
   </sect1>
   <sect1 id="linda">
    <heading>
      <package>linda</package>
    </heading>
    <p>
      <package>linda</package> est un autre vérificateur de paquet. Il est 
      semblable à <package>lintian</package>, mais il a un ensemble de tests 
      différents. Il est écrit en Python plutôt qu'en Perl.
    </p>
   </sect1>
   <sect1 id="debdiff">
    <heading>
      <package>debdiff</package>
    </heading>
    <p>
      <prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref 
      id="devscripts">) compare des listes de fichiers et des fichiers de 
      contrôle de deux paquets. C'est un simple test de régression qui peut 
      vous aider à remarquer si le nombre de paquets binaires a changé 
      depuis le dernier envoi ou si autre chose a changé dans le fichier de 
      contrôle. Bien sûr, certains des changements qu'il indique sont 
      normaux, mais il peut aider à empêcher différents accidents.
    </p>
    <p>
      Vous pouvez l'exécuter sur un couple de paquets binaires&nbsp;:
     <example>
debdiff package_1-1_arch.deb package_2-1_arch.deb
</example>
    </p>
    <p>
      Ou même sur un couple de fichiers de changements&nbsp;:
     <example>
debdiff package_1-1_arch.changes package_2-1_arch.changes
</example>
    </p>
    <p>
      Pour plus d'informations, veuillez voir <manref section="1" 
      name="debdiff">.
    </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.
   </p>
   <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. <package>debhelper</package> inclut des 
      programmes pour installer différents fichiers, les compresser, ajuster 
      leurs droits et intégrer votre paquet dans le système de menu Debian.
    </p>
    <p>
      À la différence d'autres approches, <package>debhelper</package> est 
      divisé en plusieurs petits utilitaires simples qui agissent de manière 
      cohérente. Ce découpage permet un contrôle des opérations plus fin que 
      certains des autres «&nbsp;<em>outils debian/rules</em>&nbsp;».
    </p>
    <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>.
    </p>
   </sect1>
   <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>.
    </p>
    <p>
      Le consensus actuel est que l'utilisation de 
      <package>debmake</package> est déconseillée au profit de 
      <package>debhelper</package>. C'est un bogue d'utiliser 
      <package>debmake</package> pour les nouveaux paquets. Les nouveaux 
      paquets utilisant <package>debmake</package> seront rejetés de 
      l'archive.
    </p>
   </sect1>
   <sect1 id="dh-make">
    <heading>
      <package>dh-make</package>
    </heading>
    <p>
      Le paquet <package>dh-make</package> contient <prgn>dh_make</prgn>, 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</prgn> est une 
      réécriture de <package>debmake</package> et ses fichiers modèles 
      utilisent les programmes dh_* de <package>debhelper</package>.
    </p>
    <p>
      Quoique les fichiers de règles fabriqués par <prgn>dh_make</prgn> 
      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.
    </p>
   </sect1>
   <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>. Le fichier <file>debian/packages</file> contient 
      des instructions pour construire les paquets et il n'y a pas besoin de 
      créer de fichiers <file>Makefile</file>. Il existe la possibilité 
      d'utiliser un moteur de macros semblable à celui utilisé dans les 
      fichiers SPECS des paquets source RPM.
    </p>
    <p>
      Pour plus d'informations, voir le <tt><url 
      id="http://yada.alioth.debian.org/" name="site de YADA"></tt>.
    </p>
   </sect1>
   <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.
    </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 la 
     gestion du support de tâches.
   </p>
   <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 amont dans le 
      référentiel.
    </p>
    <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.
    </p>
   </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 
      fichiers. Par «&nbsp;système de base&nbsp;», nous entendons le strict 
      minimum nécessaire pour fonctionner et installer le reste du système.
    </p>
    <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 
      construction. Vous pouvez aussi l'utiliser pour voir comment se 
      comporte votre paquet quand il est installé dans un environnement 
      minimum.
    </p>
   </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.
    </p>
    <p>
      Un paquet lié est <package>pbuilder-uml</package>, qui va même plus 
      loin en réalisant la construction au sein d'un environnement 
      «&nbsp;User Mode Linux&nbsp;».
    </p>
   </sect1>
   <sect1 id="sbuild">
    <heading>
      <package>sbuild</package>
    </heading>
    <p>
      <package>sbuild</package> est un autre compilateur automatique. Il 
      peut aussi être 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 les 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.
    </p>
   </sect1>
   <sect1 id="dput">
    <heading>
      <package>dput</package>
    </heading>
    <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 <prgn>dinstall</prgn> en 
      mode simulation (<em>dry-run</em>) après le téléchargement.
    </p>
   </sect1>
   <sect1 id="dcut">
    <heading>
      <package>dcut</package>
    </heading>
    <p>
      Le script <package>dcut</package> (faisant partie du paquet <ref 
      id="dput">) aide à la suppression de fichiers du répertoire d'envoi 
      ftp.
    </p>
   </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 et par 
     l'utilisation du fichier officiel <file>config.sub</file> le plus 
     récent.
   </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 amont 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.
    </p>
   </sect1>
   <sect1 id="autotools-dev">
    <heading>
      <package>autotools-dev</package>
    </heading>
    <p>
      <package>autotools-dev</package> 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écompacté (par exemple, des fichiers dans 
      <file>/etc</file> ont été modifié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 sauvegarder 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. Par exemple, il y a des fonctions 
      pratiques pour lister les bogues actuels d'un paquet et pour finaliser 
      la dernière entrée d'un fichier <file>debian/changelog</file> file.
    </p>
   </sect1>
   <sect1 id="dpkg-depcheck">
    <heading>
      <package>dpkg-depcheck</package>
    </heading>
    <p>
      <prgn>dpkg-depcheck</prgn> (du paquet <package>devscripts</package>, 
      <ref id="devscripts">) exécute une commande sous <prgn>strace</prgn> 
      pour déterminer tous les paquets utilisés par la commande.
    </p>
    <p>
      Pour les paquets Debian, c'est utile quand vous devez créer une ligne 
      <tt>Build-Depends</tt> pour votre nouveau paquet&nbsp;: exécuter le 
      processus de compilation avec <prgn>dpkg-depcheck</prgn> vous fournira 
      une bonne première approximation des dépendances de compilation. Par 
      exemple&nbsp;:
     <example>
dpkg-depcheck -b debian/rules build
</example>
    </p>
    <p>
      <prgn>dpkg-depcheck</prgn> peut aussi être utilisé pour vérifier les 
      dépendances d'exécution, particulièrement si votre paquet utilise 
      exec(2) pour exécuter d'autres programmes.
    </p>
    <p>
      Pour plus d'informations, veuillez voir <manref section="1" 
      name="dpkg-depcheck">.
    </p>
   </sect1>
  </sect>
  <sect id="tools-porting">
   <heading>
     Outils de portage
   </heading>
   <p>
     Les outils suivants facilitent le travail des porteurs et la 
     compilation croisée.
   </p>
   <sect1 id="quinn-diff">
    <heading>
      <package>quinn-diff</package>
    </heading>
    <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>.
    </p>
   </sect1>
   <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></p></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.
    </p>
   </sect1>
  </sect>
  <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
   </p>
   <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. Il vous permet d'examiner un paquet sans le 
      décompresser.
    </p>
   </sect1>
  </sect>
 </appendix>
</book>
</debiandoc>