chiark / gitweb /
updated PUBLISHDIR
[developers-reference.git] / developers-reference.fr.sgml
index 41268c6..5082228 100644 (file)
-<!doctype debiandoc system>
-
+<!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 independant entities -->
+  <!entity % commondata  SYSTEM "common.ent" > %commondata;
+  <!-- CVS revision of this document -->
+  <!entity cvs-rev "$Revision: 1.32 $">
+
+  <!-- if you are translating this document, please notate the RCS
+       revision of the developers reference here -->
+  <!--
+    <!entity cvs-en-rev "1.91">
+    -->
+]>
+<debiandoc>
 <!--
- Guide de Référence du Développeur Debian GNU/Linux.
- Copyright (C)1997 Christian Schwarz;
- Publié sous les termes de la licence GNU
- General Public License, version 2 ou supérieure
+ TODO:
+  - bugs in upstream versions should be reported upstream!
+  - add information on how to get accounts on different architectures
+  - talk about CVS access, other ways to submit problems
+  - add information on how you can contribute w/o being an official
+    developer
+  - "official port maintainer" ? (cf. glibc-pre2.1)
  -->
+
+
 <book>
+<title>Référence du développeur Debian
+
+<author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email>
+<author>Christian Schwarz <email>schwarz@debian.org</email>
+<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
+<author>&nbsp;
+<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
+<author>et les membres de la liste
+<email>debian-l10n-french@lists.debian.org</email>
+<version>Version &version;, &date-fr; (version française 20020506).
+
+<copyright>
+
+<copyrightsummary>
+ Copyright &copy;1998 &ndash; 2002 Adam Di Carlo</copyrightsummary>
+<copyrightsummary>
+Copyright &copy;1997, 1998 Christian Schwarz.</copyrightsummary>
+
+<p>
+Ce manuel est un logiciel libre&nbsp;; il peut être redistribué et/ou modifié selon
+les termes de la licence publique générale du projet GNU (GNU GPL), telle que
+publiée par la «&nbsp;Free Software Foundation&nbsp;» (version 2 ou toute
+version postérieure).
+
+<p>
+Il est distribué dans l'espoir qu'il sera utile, mais <em>sans aucune
+garantie</em>, sans même la garantie implicite d'une possible valeur marchande
+ou d'une adéquation à un besoin particulier. Consultez la licence publique générale
+du projet GNU pour plus de détails.
+
+<p>
+Une copie de la licence publique générale du projet GNU est disponible dans le
+fichier &file-GPL; de la distribution &debian-formal; ou sur la toile&nbsp;: <url
+id="&url-gpl" name="la licence publique générale du projet GNU">. Vous pouvez
+également l'obtenir en écrivant à la &fsf-addr;.
+
+
+
+
+       <toc detail="sect2">
+
+
+
+
+       <chapt id="scope">Introduction
+       
+       <sect>Portée de ce document
+
+<p>
+Le but de ce document est de donner une vue d'ensemble des procédures à
+suivre et des ressources mises à la disposition des développeurs Debian.
+
+<p>
+Les procédures décrites ci-après expliquent entre autre comment devenir
+responsable Debian (<ref id="new-maintainer">), comment installer des nouveaux
+paquets dans l'archive (<ref id="upload">), quand et comment faire un portage
+ou une mise à jour du paquet d'un autre responsable (<ref id="nmu">), comment
+déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">) et
+comment gérer les bogues (<ref id="bug-handling">).
+
+<p>
+Les ressources présentées dans ce manuel incluent les listes de diffusion et
+les serveurs (<ref id="servers">), une présentation de la structure de
+l'archive Debian (<ref id="archive">), des explications sur les serveurs qui
+acceptent les mises à jour de paquets (<ref id="upload-ftp-master">) et une
+présentation des outils qui peuvent aider un responsable à améliorer la
+qualité de ses paquets (<ref id="tools">).
+
+<p>
+Ce manuel de référence ne présente pas les aspects techniques liés aux paquets
+Debian. Il ne décrit pas non plus comment les créer. Il ne décrit pas 
+non plus les règles que doivent respecter les paquets Debian. Cette
+information est disponible dans le <url id="&url-debian-policy;" name="Debian
+Policy Manual">.
+
+<p>
+De plus ce document <em>n'est pas l'expression d'une politique
+officielle</em>. Il contient de la documentation sur le système Debian et des
+conseils pratiques largement suivis. C'est une sorte de guide pratique.
+
+
+
+
+
+       <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...
+
+<p>
+En conséquence la langue utilisée dans toutes les listes de diffusion
+destinées aux développeurs est l'anglais et les rapports de bogue doivent être
+rédigés en anglais. En fait, sauf exception rare, tout dialogue avec les
+autres responsables Debian se fera en anglais quelque soit le média.
+
+
+       <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>NMU source</em>&nbsp;: mise à jour indépendante source. Il
+       s'agit d'une mise à jour indépendante pour un paquet source (<ref
+       id="nmu-terms">).
+
+       <item><em>NMU binaire</em>&nbsp;: mise à jour indépendante binaire.
+       Mise à jour indépendante pour un paquet binaire(<ref id="nmu-terms">).
+
+       <item><em>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 remettant en cause la
+       distribution. Bogues de gravité <em>critique</em>, <em>grave</em>
+       et <em>sérieuse</em>. Ces bogues ne doivent pas apparaître dans une
+       distribution <em>stable</em>. Ils doivent être corrigés ou bien les
+       paquets en cause doivent être supprimés (<ref id="rc-bugs">). 
+
+       <item><em>Unstable</em>&nbsp;: Nom de la distribution en cours de
+       développement. Cette distribution contient les paquets envoyés par
+       les développeurs. Ceux-ci étant humains, elle est parfois cassée (<ref
+       id="sec-dists">).
+
+       <item><em>Testing</em>&nbsp;: Nom de la distribution en test. Cette
+       distribution reçoit les paquets des développeurs qui ont passé une
+       période de deux semaines dans <em>unstable</em> et pour lesquels aucun
+       bogue remettant en cause la distribution (cf. <em>Release critical bug</em>)
+       n'a été découvert. Cette distribution n'a pas été testée
+       en profondeur. Elle est cependant sensée être plus stable que
+       <em>unstable</em> (<ref id="sec-dists">).
+
+       <item><em>Stable</em>&nbsp;: Nom de la distribution dite stable. Cette
+       distribution a été testée, validée et diffusée (<ref
+       id="sec-dists">).
+
+       <item><em>Debian maintainer</em>&nbsp;: responsable Debian, développeur
+       Debian (parfois mainteneur). Personne qui fait officiellement
+       partie du projet Debian. Elle a accès aux serveurs Debian et participe
+       au développement &mdash; au sens large &mdash; de la distribution (<ref
+       id="developer-duties">). La plupart des responsables font de la mise
+       en paquet mais il existe d'autres activités telles que documentation,
+       site web, création des cédéroms, administration des serveurs...
+
+       <item><em>Upstream version</em>&nbsp;: version amont. Il s'agit du
+       logiciel tel qu'il est fournit par le responsable amont &mdash; par
+       opposition à la version fournie par la distribution Debian. (Voir
+       <ref id="upstream-coordination">.)
+
+       <item><em>Upstream maintainer</em>&nbsp;: responsable amont ou développeur
+       amont. Personne(s) responsable(s) du développement ou de la
+       maintenance d'un logiciel. En général le responsable amont n'a rien à
+       voir avec le projet Debian (<ref id="upstream-coordination">).
+
+       <item><em>Debian keyring</em>&nbsp;: porte-clés Debian. Le porte-clés
+       Debian contient les clés publiques de tous les responsables Debian (<ref
+       id="key-maint">).
+
+       <item><em>Work-needing and prospective packages (WNPP)</em>&nbsp;: paquets en
+       souffrance et paquets souhaités. La liste des paquets en
+       souffrance indique les paquets qui n'ont plus de responsable. La liste
+       des paquets souhaités indique les logiciels que des utilisateurs
+       aimeraient bien voir dans la distribution (<ref id="upload">).
+
+       </list>
+
+
+       <chapt id="new-maintainer">Devenir responsable Debian
+
 
-<title>Guide de Référence du Développeur Debian
-<author>Christian Schwarz <email/schwarz@debian.org/
-<author>basé sur des documents précédemment écrits par Ian Jackson 
-<email/ijackson@gnu.ai.mit.edu/
-<author>version française par Hervé Floch
-<email/Herve.Floch@Linux.EU.Org/
-<version>version 0.1, <date>
+       <sect id="getting-started">Pour commencer
 
-<copyright>Copyright &copy;1997 Christian Schwarz.
 <p>
+Vous avez lu toute la documentation, vous avez examiné le <url
+id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
+l'intérêt de tout ce qui
+se trouve dans le paquet exemple <package>hello</package> et vous vous
+apprêtez à mettre en paquet votre logiciel préféré. Comment devenir
+responsable Debian et intégrer votre travail au projet&nbsp;?
+
+<p>
+Si vous ne l'avez pas encore fait vous pouvez commencer par vous inscrire à la
+liste &email-debian-devel;.
+
+<p>
+Pour cela, envoyez un courrier à l'adresse
+&email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
+<em>Objet</em><footnote><em>Subject</em> en anglais</footnote> de votre
+message. En cas de problème, contactez l'administrateur de la liste
+&email-listmaster;. Vous trouverez plus d'information dans la section <ref
+id="mailing-lists">.
+
+<p>
+Vous suivrez les discussions de cette liste (sans poster) pendant quelques
+temps avant de coder quoi que ce soit et vous informerez la liste de votre
+intention de travailler sur quelque chose pour éviter de dupliquer le travail
+d'un autre.
+
+<p>
+Une autre liste intéressante est &email-debian-mentors;. Voir la section <ref
+id="mentors"> pour les détails. Le canal IRC <tt>#debian</tt> sur le réseau
+<em>Linux People IRC</em> (c.-à-d. <tt>irc.debian.org</tt>) pourra aussi être
+utile.
+
+<p>
+Quand vous avez choisi la manière dont vous contriburez au projet
+&debian-formal;, prenez contact avec les responsables Debian qui travaillent
+sur des tâches similaires. Ainsi vous pouvez apprendre auprès de personnes
+expérimentées.  Si, par exemple, vous voulez mettre en paquet des logiciels
+existants, trouvez-vous un parrain. Un parrain est une personne qui
+travaillera sur vos paquets avec vous et les téléchargera dans l'archive
+Debian une fois qu'il sera satisfait de votre mise en paquet. Pour trouver
+un parrain, envoyez une demande de parrainage à la liste
+&email-debian-mentors; en vous présentant et en décrivant votre paquet (voir
+<ref id="sponsoring"> pour en savoir plus sur le sujet). Si vous préférez
+porter Debian sur une architecture ou un noyau alternatif, abonnez vous aux
+listes dédiées au portage et demandez-y comment démarrer. Finalement, si vous
+êtes intéressé par la documentation ou l'assurance qualité (QA) vous pouvez
+contacter les responsables qui travaillent déjà sur ces tâches et proposer des
+rustines et des améliorations.
+
+
+       <sect id="registering">Devenir responsable Debian
+
+<p>
+Avant de décider de devenir responsable Debian, il vous faudra lire toute la
+documentation disponible dans le <url id="&url-newmaint;" name="coin du
+nouveau responsable">. Elle décrit toutes les étapes préparatoires qu'il vous
+faudra franchir avant de déposer votre candidature.
+
+Par exemple, avant d'être candidat, il vous faudra lire le
+<url id="&url-social-contract;" name="contrat social Debian">. Devenir responsable
+Debian implique que vous adhériez à ce contrat social
+et que vous vous engagiez à le soutenir&nbsp;; il est très important que les
+responsables soient en accord avec les principes fondamentaux qui animent le
+projet &debian-formal;. Lire le <url id="&url-gnu-manifesto;" name="Manifeste
+GNU"> est aussi une bonne idée.
+
+<p>
+Le processus d'enregistrement a pour but de vérifier votre identité, vos
+intentions et vos compétences. Le nombre de personnes travaillant pour
+&debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
+dans plusieurs endroits très importants&nbsp;: nous devons rester
+attentifs pour éviter un acte malveillant. C'est pourquoi nous contrôlons les
+nouveaux responsables avant de leur donner un compte sur nos serveurs et les
+autoriser à ajouter des paquets dans l'archive.
 
-Ce manuel relève du logiciel libre ; vous pouvez le redistribuer et/ou le 
-modifier conformément à la GNU GPL (General Public License) publiée par la FSF 
-(Free Software Foundation) dans la version 2 (ou supérieure si vous le 
-préférez).
 <p>
+Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
+et être un bon contributeur. Pour cela, vous pourrez proposer des
+rustines par le système de suivi des bogues (BTS) ou maintenir un paquet
+parrainé pendant un temps. Nous attendons aussi des contributeurs qu'ils
+soient intéressés par le projet dans son ensemble et pas uniquement par leurs
+propes paquets. Si vous pouvez aider d'autres responsables en fournissant des
+informations sur un bogue ou même avec une rustine, faite-le&nbsp;!
 
-Il est distribué dans l'espoir qu'il sera utile, <em>sans aucune garantie</em> ; 
-sans même une garantie implicite de qualité marchande ou d'adéquation à un 
-quelconque usage. Voyez la GNU GPL pour plus de détails.
 <p>
+Pour votre candidature, vous devrez être familiarisé avec la philosophie du
+projet Debian et avec sa documentation technique. Il vous faudra aussi une
+clé GPG signée par un responsable Debian. Si votre clé GPG n'est pas encore
+signée, vous devriez essayer de recontrer un responsable Debian pour le faire.
+La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
+GPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
+(Si vous ne trouvez pas de responsable près de chez vous, il existe un second
+moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
+signée avec votre clé GPG. Privilégiez tout de même la clé GPG signée pour 
+valider une identité. Reportez-vous à la <url id="&url-newmaint-id;"
+name="page d'identification"> pour en savoir plus sur ces deux options.)
 
-Une copie de la licence GNU GPL est disponible dans le fichier 
-<tt>/usr/doc/copyright/GPL</tt> de la distribution Debian GNU/Linux ou sur le 
-World Wide Web à l'URL <tt>http://www.gnu.org/copyleft/gpl.html</tt>. Vous 
-pouvez aussi l'obtenir en écrivant à la Free Software Foundation, Inc., 675 Mass 
-Ave, Cambridge, MA 02139, USA.
 <p>
+Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une
+clé OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez
+la documentation du logiciel de cryptographie que vous utiliserez car elle
+contient des informations indispensables pour la sécurité de votre clé. Les 
+défaillances de sécurité sont bien plus souvent dues à des erreurs humaines 
+qu'à des problèmes logiciels ou à des techniques d'espionnage avancées. Voir
+<ref id="key-maint"> pour plus d'information sur la gestion de votre clé
+publique.
 
-<toc sect>
+<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">.
 
-<chapt>Devenir un mainteneur
 <p>
+L'algorithme à clé publique recommandé pour les développements Debian est DSA
+(parfois appelé «&nbsp;DSS&nbsp;» ou «&nbsp;DH\ElGamal&nbsp;»). Vous pouvez
+aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
+minimum de 1024 bits&nbsp;; il n'y a pas de raison d'utiliser une clé plus courte et le
+faire serait beaucoup moins sûr. Votre clé doit être signée avec votre propre
+identifiant&nbsp;; cela évite les falsifications. <prgn>GNU Privacy Guard</prgn> le
+fait automatiquement.
 
-<sect>Avant de travailler sur un paquet
 <p>
+Si votre clé publique n'est pas sur un serveur public tel que &pgp-keyserv;,
+reportez-vous à la documentation disponible localement dans &file-keyservs;.
+Cette documentation explique comment mettre votre clé publique sur un serveur.
+L'équipe <em>New maintainer</em> mettra votre clé publique sur les serveurs de
+clés si elle n'y est pas déjà.
 
-Vous avez lu toute la documentation, vous avez compris l'utilité de chaque
-élément du paquet d'exemple <prgn/hello/ et vous voulez « debianiser » votre
-paquet favori. Alors, comment devient-on un développeur Debian dont le travail 
-peut être incorporé dans le projet ?
 <p>
+Certains pays limitent l'usage des logiciels de cryptographie.  Cela ne
+devrait cependant pas avoir d'impact sur l'activité d'un responsable de paquet
+car il peut être tout à fait légal d'utiliser des logiciels de cryptographie
+pour l'authentification plutôt que pour le cryptage (comme c'est le cas en
+France). &debian-formal; ne nécessite en aucune manière de cryptographie en
+tant que cryptage. Si vous vivez dans un pays où l'usage de la cryptographie
+pour authentification est interdit, contactez-nous pour que nous prenions des
+dispositions particulières.
 
-Tout d'abord, abonnez-vous à <prgn/debian-devel/ si vous ne l'avez pas déjà
-fait. Envoyez juste le mot <tt/subscribe/ dans le champ <em/Subject/ d'un
-courrier électronique à <email/debian-devel-REQUEST@lists.debian.org/. En cas de 
-problème, contactez l'administrateur de la liste de diffusion à l'adresse 
-<email/listmaster@lists.debian.org/.
 <p>
+Pour faire acte de candidature, il vous faut un responsable Debian qui
+vérifiera votre candidature (un <em>avocat</em>). Après avoir contribué au
+projet Debian pendant un temps, quand vous choisissez de devenir un
+responsable Debian officiel, un responsable déjà enregistré avec qui vous
+aurez travaillé dans les derniers mois devra exprimer que, d'après lui, vous
+pouvez contribuer avec succès au projet Debian.
 
-Vous devriez vous abonner et observer un peu avant d'écrire le moindre code, 
-vous devriez aussi poster un message annonçant vos intentions avant d'attaquer 
-un travail, afin d'épargner des efforts dupliqués.
 <p>
+Quand vous avez trouvez un <em>avocat</em>, quand votre clé GPG est signée et
+quand vous avez contribuez pendant un temps au projet vous êtes près pour
+faire acte de candidature. Il vous suffit pour cela de vous enregistrer sur
+notre <url id="&url-newmaint-apply;"  name="page de candidature">. Ensuite,
+votre avocat devra confirmer votre candidature. Quand il aura accompli cette
+tâche, un responsable de candidature<footnote>Application manager</footnote>
+sera désigné pour vous accompagner dans le processus d'enregistrement. Vous
+pouvez toujours consulter le <url id="&url-newmaint-db;" name="tableau de bord
+des candidatures"> pour connaître l'état de votre candidature.
+
 
-Si vous n'avez pas déjà de clef PGP, générez-en une. Vous devriez probablement 
-lire le manuel de PGP. En effet, il contient de nombreuses informations 
-importantes qui sont primordiales pour sa sécurité. Bien plus de failles de 
-sécurité sont dues à des erreurs humaines qu'à des bogues logiciels ou des 
-techniques d'espionnage perfectionnées.
 <p>
+Pour en savoir plus, consultez le <url id="&url-newmaint;" name="coin des
+nouveaux responsables"> sur le site Debian. Assurez-vous de bien connaître
+les étapes nécessaires au processus d'enregistrement avant vous porter
+candidat. Vous gagnerez beaucoup de temps si vous êtes bien préparé.
+
 
-En raison des restrictions à l'exportation décidées par le gouvernement des 
-États Unis, quelques paquets Debian dont PGP ont été déplacés vers un serveur 
-FTP en dehors des U.S.A. . Vous pouvez obtenir les localisations de ces paquets 
-à <ftpsite/ftp.debian.org/ dans le fichier 
-<ftppath>/pub/debian/README.non-US</>.
+       <sect id="mentors">Mentors et parrains Debian
 <p>
+La liste de diffusion &email-debian-mentors; a été créée pour les
+responsables débutants qui cherchent de l'aide pour leur première
+création de paquet ainsi que pour des problèmes spécifiques aux 
+développeurs. Tout responsable débutant est invité à s'y inscrire 
+(voir <ref id="mailing-lists"> pour plus de détails).
 
-Si vous vivez dans un pays où l'usage de la cryptographie est interdit, même 
-pour l'authentification, veuillez nous contacter pour que nous trouvions des 
-arrangements particuliers. Ceci ne s'applique pas pour la France où je pense 
-que seul le chiffrement est interdit et pas l'authentification.
 <p>
+Ceux qui préfèrent une aide personnalisée (via une correspondance
+privée) doivent aussi poster dans cette liste, un développeur 
+expérimenté se portera volontaire pour les aider.
 
-<sect>S'enregistrer comme un développeur Debian
 <p>
+De plus, si vous avez des paquets prêts à être intégrés mais attendez le
+résultat de votre candidature, vous pouvez chercher un parrain qui
+téléchargera les paquets pour vous. Les parrains sont des responsables Debian
+officiels volontaires pour examiner vos paquets et les télécharger pour vous.
+Vous pouvez demander un parrainage à l'adresse <url id="&url-sponsors;">.
 
-Quand votre nouveau paquet sera prêt à être envoyé, vous devrez poster un 
-message à <email/new-maintainer@debian.org/ pour vous enregistrer comme un
-développeur Debian « officiel » afin d'être autorisé à envoyer des paquets. 
 <p>
+Si vous désirez être mentor ou parrain, reportez vous à <ref id="newmaint">.
+
+
+       <chapt id="developer-duties">Les charges du responsable Debian
+
+
+       <sect id="user-maint">Mise à jour de vos références Debian
 
-Le message devra annoncer ce que vous avez fait et qui vous êtes. Aussi, vous 
-devriez demander à avoir un compte sur le serveur principal et à être inscrit 
-sur la liste debian-private (la liste de diffusion réservée aux développeurs). 
-Il devra contenir votre clé publique PGP ou RSA (extraite avec la commande 
-<tt>pgp -kxa</tt>, dans le cas de PGP) pour la base de données des clés fournie 
-avec dpkg. Vérifiez que vous avez signé votre message avec la clé PGP ou RSA que 
-vous avez choisie.
 <p>
+Une base de données LDAP contient de nombreuses informations concernant
+les développeurs, vous pouvez y accéder à l'adresse <url
+id="&url-debian-db;">.  Vous pouvez modifier votre mot de passe (ce mot de
+passe est diffusé sur la plupart des machines auxquelles vous avez accès),
+votre adresse, votre pays, la latitude et la longitude de l'endroit où vous
+résidez, vos numéros de téléphone et de fax, votre interpréteur de commande
+préféré, votre surnom IRC, votre page web, votre adresse de courrier
+électronique ainsi que l'alias que vous utilisez pour votre courrier
+électronique chez debian.org. La plupart de ces informations ne sont pas
+accessibles au public. Pour plus de détails au sujet de cette base de données
+reportez-vous à sa documentation en ligne disponible à l'adresse <url
+id="&url-debian-db-doc;">.
 
-Incluez votre nom d'usager préféré pour le serveur principal (sept caractères ou
-moins), ainsi que l'adresse électronique à laquelle vous souhaitez recevoir les
-messages de debian-private (typiquement, ce sera ou votre adresse principale ou 
-votre nouvelle adresse debian.org).
 <p>
+Vous y tiendrez à jour les informations vous concernant.
 
-Vous devrez aussi indiquer un moyen par lequel nous pourrons vérifier votre 
-identité réelle. Par exemple, un des moyens suivants conviendrait :
 
-<list compact>
-<item>Une clé PGP ou RSA signée par une signature bien connue, comme :
-<list compact>
-<item>un des développeurs Debian
-<item>un service de certification (comme Verisign, Thawte, etc.)
-</list>
-<item>une copie numérisée ou physiquement postée de documents officiels 
-certifiant de votre identité (comme un extrait de naissance, une carte nationale 
-d'identité, un permis de conduire, etc.). Incluez votre empreinte PGP or RSA sur 
-l'image numérisée et signez l'image avec votre clé PGP ou RSA.
-</list>
 
-Les mécanismes suivants sont déconseillés, mais acceptables si aucun des moyens 
-précédents n'est utilisable :
-<list compact>
-<item>Une liste de numéros de téléphone auxquels vous pouvez être joint (à nos 
-frais). Cette liste doit pouvoir être vérifiée indépendamment, par des moyens 
-tel qu'un annuaire national ou toute autre source faisant autorité.
-</list>
 
-Nous sommes désolés pour les contraintes découlant de cette vérification 
-d'identité, mais pour le moment, de telles mesures sont indispensables pour 
-assurer la sécurité et la fiabilité de notre distribution.
+       <sect id="key-maint">Gérer votre clé publique
+
 <p>
+Soyez très vigilant en utilisant votre clé privée.  Ne la placez pas sur un
+serveur public ou sur des machines multi-utilisateurs telles que
+<tt>master.debian.org</tt>.  Sauvegardez vos clés et gardez-en une copie hors
+connexion. Lisez la documentation fournie avec votre logiciel et la <url
+id="&url-pgp-faq;" name="FAQ PGP">.
 
-Une fois que cette information est reçue et traitée, vous devriez recevoir les 
-informations concernant votre nouveau compte de mainteneur Debian. Si vous ne 
-recevez rien sous 7-10 jours, veuillez renvoyer votre message original car les 
-bénévoles gérant les nouveaux volontaires sont généralement débordés et des 
-erreurs surviennent parfois.
 <p>
+Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous
+pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
+<tt>&keyserver-host;</tt>. Si vous voulez ajouter ou supprimer une clé, envoyez
+un courrier à &email-debian-keyring;. Les procédures d'extraction de clé
+décrites dans <ref id="registering"> s'appliquent ici.
 
-<chapt>Les Serveurs Internet
 <p>
+Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
+dans la documentation du paquet <package>debian-keyring</package>.
+
+
+
+
+       <sect id="inform-vacation">Prendre des vacances courtoisement
 
-<sect>Les listes de diffusion
 <p>
+La plupart des développeurs prennent des vacances&nbsp;; généralement, cela signifie
+qu'ils ne peuvent ni travailler pour Debian ni être joints par
+courrier électronique si un problème se présentait. Les autres développeurs
+ont besoin de savoir que vous êtes en vacances&nbsp;; ainsi ils sauront comment
+réagir en cas de problème. En général, cela signifie que les autres
+développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
+cas de gros problème (bogues bloquants pour la distribution, mise à jour de
+sécurité...) durant vos vacances.
 
-Le serveur des listes de diffusion est hébergé sur <tt/lists.debian.org/.
-Envoyez un courrier électronique à 
-<tt/debian-<var/foo/-REQUEST@lists.debian.org/, <tt/debian-<var/foo// étant le
-nom de la liste, avec le mot <tt/subscribe/ dans le sujet pour vous abonner ou
-<tt/unsubscribe/ pour vous désabonner.
 <p>
+Il y a deux choses à faire pour informer les autres développeurs.
+Premièrement, envoyer un courrier électronique indiquant vos dates de vacances
+à &email-debian-private;, vous pouvez aussi donner quelques instructions pour
+indiquer comment agir si un problème survenait. Notez bien que certaines 
+personnes ne sont pas intéressées par les annonces de vacances et ne
+veulent pas les lire&nbsp;; ajoutez '[VAC] ' à l'objet de votre courrier
+pour qu'il soit facilement filtré.
 
-Quand vous répondez à un message sur la liste, n'envoyez pas de copie en <tt/CC/
-à l'auteur. Toute personne écrivant à une liste de diffusion devrait la lire 
-pour prendre connaissance des réponses.
 <p>
+Deuxièmement, il faut mettre
+à jour la base de données Debian LDAP et vous signaler «&nbsp;en
+vacances&nbsp;» (l'accès à cette information est réservé aux développeurs).
+N'oubliez pas de retirer votre indicateur «&nbsp;en vacances&nbsp;» lorsque
+celles-ci sont terminées&nbsp;!
+
+
+
+
+       <sect id="upstream-coordination">Coordination avec les développeurs
+       amonts
 
-Comme toujours dans vos courriers, essayez de réduire les citations des articles 
-auxquels vous répondez. Appliquez vous aussi à respecter la Nétiquette lorsque 
-vous postez.
 <p>
+Une grosse part de votre travail de responsable Debian sera de rester en
+contact avec les développeurs amonts. Parfois, les utilisateurs établissent
+des rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez
+transmettre ces rapports de bogue aux développeurs amonts pour qu'ils soient
+corrigés dans les prochaines versions.  Il n'est pas de votre responsabilité
+de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
+si vous êtes capable de le faire, nous vous encourageons à contribuer au
+développement amont en proposant une rustine qui corrige ce bogue.
+Les utilisateurs et responsables Debian proposent souvent des rustines
+pour corriger des bogues amonts, il vous faudra alors évaluer cette
+rustine puis la transmettre aux développeurs amonts.
 
-<sect>Le serveur principal
 <p>
+Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
+paquet conforme à la charte Debian, alors vous devriez proposer une 
+rustine aux développeurs amonts pour qu'elle soit incluse dans leur
+version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
+mises à jour amonts suivantes.  Quels que soient les changements dont vous
+avez besoin, il faut toujours essayer de rester dans la lignée des sources
+amonts. 
+
+
+
+
+
+       <sect id="rc-bugs">Gestion des bogues bloquants pour la distribution
 
-<sect>Le serveur Ftp et ses miroirs
 <p>
+Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais
+<em>Release-critical bug (RCB)</em></footnote> sont les bogues de gravité
+<em>critique</em>, <em>grave</em> et <em>sérieuse</em><footnote>Respectivement
+<em>critical</em>, <em>grave</em> et <em>serious</em> en anglais</footnote>.
+Ces bogues peuvent retarder la diffusion d'une distribution Debian et/ou
+peuvent justifier la suppression d'un paquet d'une distribution gelée. C'est
+pourquoi ces bogues ont besoin d'être corrigés au plus vite.  Vous devez être
+conscient que certains développeurs faisant partie de l'équipe d'<url
+id="&url-debian-qa;" name ="assurance qualité Debian"> surveillent ces bogues
+et essaient de vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas
+corriger un bogue de ce type dans les deux semaines, vous devriez soit
+demander de l'aide en envoyant un courrier à l'équipe d'assurance qualité
+(<em>QA group</em> &email-debian-qa;), soit expliquer vos difficultés et
+présenter un plan pour corriger le problème en répondant au rapport de bogue
+concerné. Si rien n'est fait, des personnes de l'équipe d'assurance qualité
+pourraient chercher à corriger votre paquet (voir <ref id="nmu">) après avoir
+tenté de vous contacter. Ils pourraient attendre moins longtemps que
+d'habitude pour faire leur mise à jour s'il n'y a pas trace d'activité récente
+de votre part dans le système de suivi des bogues.
+
+
+
+       <sect id="qa-effort">L'effort d'assurance qualité
 
-<sect>Les serveurs WWW
 <p>
+Même s'il y a un groupe de personnes dédié à l'assurance qualité, cette
+activité ne leur est pas réservée. Vous pouvez participer à cet effort en
+éliminant, autant que faire se peut, tout bogue de vos paquets et en observant
+les remarques émises par <prgn>lintian</prgn> (voir <ref id="lintian-reports">).  Si cela
+ne vous semble pas possible, il faudrait songer à abandonner certains
+de vos paquets (voir <ref id="orphaning">). Vous pouvez aussi
+demander l'aide d'autres personnes pour rattraper votre retard dans la liste
+des bogues (vous pouvez demander de l'aide sur les listes  &email-debian-qa;
+et &email-debian-devel;).  
+
 
-<chapt>Le travail quotidien du développeur de paquet
+       <sect id="mia-qa">Responsables injoignables
 <p>
+Si vous remarqué qu'un paquet manque d'attention, assurez-vous que le
+responsable est toujours actif et continuera à travailler sur son paquet.
+Essayez de le contacter.
 
-<sect>Annoncer les nouveaux paquets
 <p>
+Si vous n'obtenez pas de réponse après quelques semaines, rassemblez toutes
+les informations utiles sur ce responsable. Commencez par consulter la <url
+id="http://db.debian.org" name="base de données des développeurs"> pour
+déterminer si le responsable est en vacances et quand il a été vu pour la
+dernère fois. Listez les paquets importants gérés par ce responsable et les
+bogues bloquants pour la distribution qui concernent ces paquets.
 
-<sect>Envoyer les nouveaux paquets
+<p> Envoyez toutes ces informations à &email-debian-qa; pour que l'équipe
+d'assurance qualité prenne les mesures nécessaires.
+
+       <sect>Démissionner
 <p>
+Si vous choisissez de quitter le projet Debian, procédez comme suit&nbsp;: 
+
+       <enumlist>
+       <item>
+       Abandonnez tous vos paquets comme décrit dans <ref id="orphaning">.
+       
+       <item>
+       Envoyez un courrier électronique à &email-debian-private; indiquant
+       comment vous quittez le projet.
+
+       <item>
+       Signalez aux responsables du porte-clés Debian que vous quittez le
+       projet en écrivant à &email-debian-keyring;.
+
+       </enumlist>
+
+
+       <chapt><heading>Au dela de la mise en paquet</heading>
 
-Quand vous avez un compte personnel sur le serveur principal, vous pouvez vous 
-connecter par ftp et transférer les fichiers dans 
-<tt>/home/Debian/ftp/private/project/Incoming</tt>. Vous ne pouvez pas 
-envoyer dans « Incoming » sur le serveur principal par FTP anonyme, vous devez 
-utiliser votre nom et votre mot de passe.
 <p>
+Le projet Debian nécessite bien plus que la mise en paquet des logiciels et la
+maintenance de ces paquets. Ce chapitre décrit d'autres types de contributions
+&mdash; contributions souvent d'importance critique pour le projet Debian
+&mdash; au dela de la création et de la maintenance de paquet.
 
-Vous pouvez aussi envoyer vos fichiers dans « Incoming » avec une queue de 
-chargement gérée par un cron en Europe sur ftp.chiark.greenend.org.uk. Pour plus 
-de détails, connectez vous sur chiark via FTP anonyme et lisez 
-<tt>/pub/debian/private/project/README.how-to-upload</tt>.
 <p>
+En tant qu'organisation basée sur le volontariat, Debian compte sur
+l'appréciation de ces membres qui choisiront sur quoi ils veulent travailler
+et sur quoi il est le plus important de passer son temps.
+
+       <sect id="newmaint"><heading>Interaction avec les nouveaux
+       responsables</heading>
 
-Vous pouvez aussi trouver le paquet Debian <tt>dupload</tt> utile pour envoyer 
-les nouveaux paquets au serveur principal. Regardez la documentation de 
-<tt>dupload</tt> pour plus d'informations.
 <p>
+Le succès de Debian dépend de sa capacité à attirer et retenir des volontaires
+de talent. Si vous êtes un responsable expérimenté, nous vous recommandons de
+vous impliquer dans le recrutement de nouveaux responsables.  Cette section
+décrit comment aider les nouveaux responsables.
+
+       <sect1 id="sponsoring">Parrainer un paquet
 
-<sect>Mises à jour par Intérim
 <p>
+Parrainer un paquet signifie télécharger un paquet pour un responsable qui
+n'a pas la possibilité de le faire lui même&nbsp;: un nouveau responsable.
+Parrainer un paquet signifie aussi en accepter la responsabilité.
 
-Dans certaines circonstances, il est nécessaire que quelqu'un d'autre que le 
-mainteneur courant réalise une nouvelle version d'un paquet. Par exemple, un
-porteur vers une autre architecture peut avoir à faire quelques petits 
-changements au paquet source et ne pas vouloir attendre que le mainteneur 
-principal ait incorporé la pièce (patch) pour envoyer sa version, ou un problème 
-de sécurité peut être apparu, nécessitant des changements immédiats.
 <p>
+Si vous êtes prêt à parrainer un paquet, vous pouvez vous inscrire à <url
+id="&url-sponsors;">.
 
-Les mainteneurs autres que les mainteneurs courants devraient faire le moins de 
-changements possible sur le paquet, et ils devraient toujours envoyer un 
-« unified context diff » (<tt/diff -u/) détaillant leurs changements au système 
-de suivi de bogues pour que le mainteneur soit tenu au courant de la situation.
 <p>
+Les nouveaux responsables ont souvent quelques difficultés pour créer des
+paquets Debian &mdash; ce qui est bien compréhensible. C'est là que le parrain
+intervient. Il vérifie que le paquet est suffisamment bon pour intégrer
+la distribution. Notez que si le paquet est nouveau les administrateurs de
+l'archive l'inspecteront aussi avant de le laisser entrer.
 
-Quand quelqu'un d'autre que le mainteneur courant sort un nouveau paquet, il 
-devrait ajouter un nouveau morceau à la partie <var/debian-revision/ du numéro
-de version -- c'est à dire la partie après le dernier trait d'union. Ce morceau
-supplémentaire commencera à <tt/1/ afin d'éviter de priver un des mainteneurs
-actuels d'un de ses numéros de version, ce qui pourrait le gêner. Si il n'y a
-pas de partie <var/debian-revision/ dans le numéro de version, alors, il devrait
-en être créée une dans le numéro de version, en commençant à <tt/1/.
 <p>
+Parrainer un paquet en se contentant de signer la livraison ou de recompiler
+le paquet n'est <strong>franchement pas recommandé</strong>. Vous devez
+construire le paquet source comme vous le feriez avec vos propres paquets.
+N'oubliez pas qu'il sera possible de voir que vous avez téléchargé un paquet
+même si vous avez laissé le nom du futur responsable dans les fichiers
+<em>control</em> et <em>changelog</em>.
 
-S'il est absolument nécessaire pour quelqu'un d'autre que le mainteneur courant 
-de faire une nouvelle version basée sur une nouvelle souche, alors la personne 
-faisant cette version devrait commencer avec le numéro <var/debian-revision/
-<tt/0.1/. Le mainteneur courant aurait commencé avec le numéro de 
-<var/debian-revision/ à <tt/1/.
 <p>
+Si vous êtes responsable de candidature pour un nouveau responsable, vous
+pouvez aussi être son parrain. Ainsi vous pouvez aussi vérifier comment le
+candidat traite la partie «&nbsp;Tâches et compétences<footnote>'Tasks and
+Skills'</footnote>&nbsp;» de leur candidature.
+
+       <sect1>Aider un nouveau responsable
 
-<sect>Changement de mainteneur
 <p>
+Consultez la page <url id="&url-newmaint-advocate;" name="Aider un futur
+responsable"> sur le site du projet Debian.
+
+
+
+       <sect1>Suivre la candidature d'un nouveau responsable
 
-Régulièrement, une liste des paquets nécessitant un nouveau mainteneur est 
-postée vers la liste <tt>debian-devel</tt>. Cette liste peut aussi être 
-consultée sur <ftpsite>ftp.debian.org</> dans le fichier 
-<ftppath>/debian/doc/package-developers/prospective-packages.txt</>.
-Si vous voulez reprendre la maintenance d'un de ces paquets, ou si vous ne 
-pouvez plus maintenir les paquets que vous avez, ou si vous voulez simplement 
-savoir si quelqu'un est en train de travailler sur un nouveau paquet, envoyez un 
-message à <email/override-change@debian.org/.
 <p>
+Consultez la page <url id="&url-newmaint-amchecklist;" name="Aide mémoire du
+responsable de candidature"> sur le site du projet Debian.
+
+
+
+
+
+
+       <chapt id="servers">Listes de diffusion, serveurs et autres machines
 
-Si vous reprenez un ancien paquet, vous voudrez probablement être désigné comme 
-le mainteneur officiel du paquet dans le système de suivi de bogues. Ceci sera 
-fait automatiquement une fois que vous aurez envoyé une nouvelle version avec un 
-champ <tt/Maintainer:/ mis à jour. Si vous ne comptez pas envoyer de nouvelle
-version avant un certain temps, envoyez un courrier électronique à
-<email/override-change@debian.org/ pour que les rapports de bogue vous soient
-envoyés.
 <p>
+Dans ce chapitre vous trouverez une très brève description des listes de 
+diffusion Debian, des principaux serveurs Debian et des autres machines 
+auxquelles vous aurez accès en tant que développeur.
+
+
+
+       <sect id="mailing-lists">Les listes de diffusion
 
-<chapt>Le système de suivi de bogues
 <p>
-Ce chapitre explique le système de traitement des bogues de Debian aux 
-mainteneurs Debian. Si vous voulez savoir comment signaler un bogue ou comment 
-accéder aux informations sur les bogues signalés lisez plutôt Le Manuel de 
-l'utilisateur Debian.
+Le serveur de liste de diffusion est <tt>&lists-host;</tt>.  Envoyez un
+courrier électronique à <tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>,
+où <tt>debian-<var>foo</var></tt> est le nom de la liste, avec le mot
+<tt>subscribe</tt> dans le champ <em>Objet</em><footnote><em>Subject</em> en
+anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt> pour
+vous désabonner.  Vous trouverez des instructions plus détaillées pour vous
+abonner et vous désabonner aux adresses <url
+id="&url-debian-lists-subscribe;">, <url id="&url-debian-lists-txt;"> ou
+localement dans le fichier &file-mail-lists; si vous avez installé le paquet
+<package>doc-debian</package>.
+
 <p>
-   Initialement, un rapport de bogue est soumis par un utilisateur par un simple 
-   courrier électronique à <tt>submit@bugs.debian.org</tt>. Il lui sera alors 
-   attribué un numéro, un accusé de réception sera envoyé à l'utilisateur et le 
-   message sera envoyé vers la liste de diffusion <tt>debian-devel</tt>. Si
-   l'utilisateur a inclus une ligne « Package » indiquant un paquet avec un 
-   mainteneur connu, ce mainteneur recevra une copie lui aussi.
+Lorsque vous répondez aux messages d'une liste de diffusion,
+n'envoyez pas de copie (<tt>CC</tt>) à l'auteur du courrier à moins
+qu'il ne l'ait demandé explicitement. Quelqu'un qui envoie un message à une
+liste de diffusion se doit d'y lire les réponses.
+
 <p>
+Les principales listes de diffusion Debian sont&nbsp;:
+       <list compact>
+       <item> &email-debian-devel;&nbsp;;
+       <item> &email-debian-policy;&nbsp;;
+       <item> &email-debian-user;&nbsp;;
+       <item> &email-debian-private;&nbsp;;
+       <item> &email-debian-announce; et
+       <item> &email-debian-devel-announce;.
+       </list>
+
+Un développeur devrait, au minimum, être inscrit à la liste
+&email-debian-devel-announce;.
 
-   <tt>Bug#nnn:</tt> sera ajouté à la ligne « Subject », et le champ 
-   « Reply-To » inclura l'auteur du rapport de bogue, et 
-   <tt>nnn@bugs.debian.org</tt>.
 <p>
+Il existe d'autres listes de diffusion spécialisées dans différents thèmes.
+Reportez-vous à la page <url id="&url-debian-lists-subscribe;"> pour en
+obtenir la liste complète.  Nous déconseillons l'usage des correspondances
+croisées (envoyer le même message à plusieurs listes).
 
-<sect>Manipuler les rapports de bogues
 <p>
+&email-debian-private; est une liste de diffusion destinée aux discussions
+privées entre développeurs Debian. Elle doit être utilisée pour tout message
+qui ne doit pas être publié, quelqu'en soit la raison.  C'est une liste à
+faible trafic et les utilisateurs sont priés de ne l'utiliser qu'en cas de
+réelle nécessité. De plus, il ne faut <em>jamais</em> faire suivre un courrier
+de cette liste à qui que ce soit. Pour des raisons évidentes, les archives de
+cette liste ne sont pas disponible sur la toile. Vous pouvez les consulter en
+visitant le répertoire <file>~debian/archive/debian-private</file> avec votre 
+compte sur <tt>master.debian.org</tt>.
 
-<sect1>Clore un rapport de bogue
 <p>
+&email-debian-email; est une liste de diffusion fourre-tout. Elle est utilisée
+pour les correspondances relatives à Debian qu'il serait utile d'archiver, telles
+que des échanges avec les auteurs amonts à propos de licences, de bogues ou encore
+des discussions sur le projet avec d'autres personnes.
 
-   Un développeur qui voit un bogue sur <tt>debian-devel</tt> et qui en prend la 
-   responsabilité devrait envoyer une réponse, en utilisant la fonction 
-   « Répondre » de son logiciel favori et en éditant le champ « À » pour envoyer 
-   à <tt>nnn-done@bugs.debian.org</tt> au lieu de <tt>nnn@bugs</tt> 
-   (<tt>nnn-close</tt> est un alias pour <tt>nnn-done</tt>).
 <p>
+Comme toujours sur internet, éliminez les lignes inutiles quand vous citez
+le message auquel vous répondez. Plus généralement, respectez
+les conventions habituelles lorsque vous envoyez des messages.
 
-   L'adresse de l'auteur originel du rapport de bogue sera incluse dans le champ 
-   « To » parce que le système de gestion des bogues l'avait inclus dans le champ 
-   « Reply-To ».
 <p>
-   Les messages « Done » ne sont pas automatiquement envoyés dans la liste de 
-   diffusion, il pourrait donc parfois valoir la peine d'inclure la liste de 
-   diffusion <tt>debian-devel</tt> si les autres développeurs peuvent être 
-   intéressés.
+Les archives des listes de diffusion sont disponibles en ligne à l'adresse
+<url id="&url-lists-archives;">.
+
+
+
+
+       <sect id="server-machines">Les serveurs Debian
+
 <p>
-   La personne qui clôt le rapport de bogue et la personne qui l'a soumis 
-   recevront chacune une notification du changement de statut du rapport.
+Les serveurs Debian sont bien connus et hébergent les fonctions
+critiques du projet Debian.  Tout développeur se doit de savoir ce qu'ils sont
+et à quoi ils servent.
+
 <p>
+Si vous avez un problème en utilisant un serveur Debian et si vous estimez que
+les administrateurs système devraient en être avertis, vous trouverez
+l'adresse d'un responsable pour cette machine à la page <url
+id="&url-devel-machines;">.  Si votre problème n'est pas lié au système
+(paquet à supprimer ou suggestion pour le site web par exemple), il vous
+faudra en général ouvrir un rapport de bogue sur un
+«&nbsp;pseudo-paquet&nbsp;». Reportez-vous à la section <ref id="submit-bug">
+pour connaître la procédure à suivre.
 
 
-<sect1>Messages suivis
+
+
+       <sect1 id="servers-master">Le serveur maître
+
 <p>
+<tt>master.debian.org</tt> est le serveur maître du système de suivi des
+bogues (BTS<footnote>Système de suivi des bogues se dit <em>Bug Tracking
+System</em> en anglais</footnote>). Si vous envisagez de manipuler les
+rapports de bogue ou d'en faire une analyse statistique ce sera le bon endroit
+pour le faire.  Informez la liste &email-debian-devel; de votre intention
+avant d'implémenter quoi que ce soit afin d'éviter un travail en double
+ou le gaspillage de temps machine.
 
-   Si un développeur veut répondre à un rapport de bogue sans marquer le bogue 
-   comme résolu, il peut simplement répondre au message. Sa réponse ira (par
-   défaut) à <tt>nnn@bugs</tt> et à l'auteur du rapport de bogue. Le système de 
-   suivi de bogues archivera la réponse avec le reste des traces pour ce rapport 
-   de bogue et le fera suivre à <tt>debian-devel</tt>. Le bogue ne sera pas 
-   marqué comme résolu.
 <p>
-   Si vous voulez envoyer une réponse à un message qui n'est pas appropriée pour 
-   <tt>debian-devel</tt>, vous pouvez le faire en envoyant votre réponse à 
-   <tt>nnn-quiet@bugs</tt> ou <tt>nnn-maintonly@bugs</tt>, qui l'archivera 
-   simplement (sans le faire suivre aucunement) et l'enverra seulement au 
-   mainteneur du paquet en question.
+Tous les développeurs Debian ont un compte sur <tt>master.debian.org</tt>.
+Prenez grand soin de votre mot de passe. Évitez les méthodes de connexion et
+de téléchargement qui envoient votre mot de passe en clair sur internet.
+
+<p>
+Si vous rencontrez un problème avec <tt>master.debian.org</tt> tel qu'un
+disque plein, une activité suspecte ou autre, envoyez un courrier
+électronique à &email-debian-admin;.
+
+
+
+
+       <sect1 id="servers-ftp-master">Le serveur ftp-master
+
+<p>
+Le serveur ftp-master (<tt>ftp-master.debian.org</tt> ou <tt>
+auric.debian.org</tt>) est le serveur maître de l'archive Debian 
+(exception faite des paquets non-US). En général, les mises à jour de
+paquets se font sur ce serveur. Reportez-vous à la section <ref id="upload">
+pour en savoir plus.
+
+<p>
+Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
+comme bogue contre le pseudo-paquet <package>ftp.debian.org</package> ou par
+courrier électronique à &email-ftpmaster;&nbsp;; reportez-vous à la section <ref
+id="archive-manip"> pour connaître la procédure à suivre.
+
+
+
+
+       <sect1 id="servers-www">Le serveur WWW
+
+<p>
+Le serveur web principal, <tt>www.debian.org</tt>, est aussi connu sous le nom
+<tt>klecker.debian.org</tt>. Tous les développeurs ont un compte sur cette
+machine.
+
+<p>
+Si vous désirez publier quelques informations spécifiques à Debian sur la
+toile,
+vous pouvez le faire en les déposant dans le sous-répertoire
+<file>public_html</file> de votre répertoire personnel sur
+<tt>klecker.debian.org</tt>. Toute information déposée à cet endroit est
+accessible à l'adresse <tt>http://people.debian.org/~<var>user-id</var>/</tt>.
+Vous devriez préférer ce serveur aux autres car les répertoires
+<file>public_html</file> du serveur <tt>klecker.debian.org</tt> sont
+sauvegardés. Ce n'est pas le cas sur les autres serveurs. N'utilisez pas ces
+serveurs pour publier des informations sans rapport avec le projet Debian
+avant d'en avoir obtenu la permission. Pour toute question supplémentaire,
+adressez-vous à la liste &email-debian-devel;.  
+
+<p>
+Si vous rencontrez un problème avec un serveur web Debian, vous devez
+généralement envoyer un rapport de bogue contre le pseudo-paquet
+<package>www.debian.org</package>.  Vérifiez d'abord sur le <url
+id="http://bugs.debian.org/www.debian.org" name="système de suivi des bogues">
+que personne ne l'a déjà rapporté avant vous.
+
+
+
+
+       <sect1 id="servers-cvs">Le serveur CVS
+       
+<p>
+Le serveur <tt>cvs.debian.org</tt> est aussi connu sous le nom
+<tt>klecker.debian.org</tt> (déjà présenté plus haut). Si vous avez besoin
+d'un serveur CVS accessible par tous pour, par exemple, coordonner le travail
+de plusieurs développeurs sur un paquet, vous pouvez demander un espace sur ce
+serveur.
+
+<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>
+Pour obtenir un espace CVS, envoyez une demande à l'adresse
+&email-debian-admin; en précisant le nom de l'espace, le propriétaire du
+répertoire racine et pourquoi vous en avez besoin.
+
+
+
+
+       <sect1 id="servers-mirrors">Les miroirs des serveurs Debian
+
+<p>
+Les serveurs web et FTP Debian sont dupliqués sur d'autres serveurs. Évitez de
+charger les serveurs originaux. Idéalement, les serveurs originaux se
+contentent de copier leur contenu sur les miroirs de premier niveau et
+tous les utilisateurs consultent les miroirs. Ainsi le projet Debian étale
+ces besoins en bande passante sur plusieurs serveurs et plusieurs réseaux.
+Notez que la duplication des données sur les miroirs est déclenchée par le
+serveur maître. Ceci nous garantit que les miroirs sont aussi à jour que
+possible.
+
+<p>
+La liste des miroirs FTP (et en général HTTP) se trouve à l'adresse <url
+id="&url-debian-mirrors;">. Vous trouverez plus d'information sur les miroirs
+Debian à l'adresse <url id="&url-debian-mirroring;">. Cette page contient des
+informations et des outils qui pourront vous aider si vous avez l'intention de
+mettre en place votre propre miroir, que ce soit pour un usage interne ou
+pour un accès public.
+
+<p>
+Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider
+Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
+machines.
+
+
+
+
+       <sect id="other-machines">Les autres machines Debian
+
+<p>
+Vous aurez peut-être accès à d'autres machines Debian. Vous pouvez utiliser
+ces machines pour des tâches en rapport avec le projet Debian. Soyez gentils
+avec les administrateurs et ne consommez pas des montagnes d'espace disque, de
+bande passante ou de temps machine sans en avoir d'abord reçu l'autorisation.
+En général, ces machines sont gérés par des volontaires et sont utilisées pour
+des activités de portage.
+
+<p>
+Vous trouverez une liste des autres machines mises à la disposition des
+développeurs Debian à l'adresse <url id="&url-devel-machines;">.
+
+
+
+
+
+       <chapt id="archive">L'archive Debian
+
+       <sect>Aperçu
+
+<p>
+La distribution &debian-formal; est composée d'un grand nombre de paquets Debian
+(fichiers <tt>.deb</tt>&nbsp;: à peu près &number-of-pkgs;) et de quelques
+autres fichiers (documentation, images des disquettes d'installation,
+etc.).
+
+<p>
+Voici un exemple d'arborescence pour une archive Debian complète&nbsp;:
+
+<p>
+&sample-dist-dirtree;
+
+<p>
+Comme vous pouvez le voir, le répertoire racine contient deux répertoires,
+<tt>dists/</tt> et <tt>pool/</tt>. Le second est un ensemble de répertoires où
+sont stockés les paquets. Ceux-ci sont manipulés grâce à la base de données de
+l'archive et aux logiciels qui l'accompagnent. Le premier répertoire contient
+les distributions <em>stable</em>, <em>testing</em> et <em>unstable</em>. Le
+découpage en sous-répertoires est identique d'un répertoire de distribution à
+l'autre&nbsp;; nous nous contenterons donc d'exposer ce découpage pour la
+distribution <em>stable</em>. Les fichiers <tt>Packages</tt> et
+<tt>Sources</tt> qui se trouvent dans les répertoires de distribution peuvent
+faire référence à des fichiers du répertoire <tt>pool/</tt>.
+
+
+<p>
+Le répertoire <tt>dists/stable</tt> contient trois répertoires nommés
+<tt>main</tt>, <tt>contrib</tt> et <tt>non-free</tt>.
+
+<p>
+Dans chacune de ces sections se trouve un répertoire contenant les paquets
+sources (<tt>source/</tt>), un répertoire pour chaque architecture supportée
+(<tt>binary-i386/</tt>, <tt>binary-m68k/</tt>, etc) et un répertoire pour les
+paquets indépendants de l'architecture (<tt>binary-all/</tt>).
+
+<p>
+La section <em>main</em> contient d'autres répertoires destinés aux images de
+disquettes et à quelques documentations essentielles pour installer la
+distribution Debian sur une architecture particulière (<tt>disk-i386/</tt>,
+<tt>disk-m68k/</tt>, etc).
+
+<p>
+Les répertoires  <tt>binary-*/</tt> et <tt>source/</tt> sont à nouveau
+divisés en <em>sous-sections</em>.
+
+
+
+       <sect>Les sections
+
+<p>
+La section <em>main</em> constitue la <strong>distribution &debian-formal;
+officielle</strong>.  Elle est officielle parce qu'elle est conforme à toutes
+nos recommandations. Les deux autres sections divergent de ces recommandations
+à différents degrés, elles ne font donc pas officiellement partie de
+&debian-formal;.
+
+<p>
+Chaque paquet de la section <em>main</em> doit être conforme aux <url
+id="&url-dfsg;" name="Debian Free Software Guidelines"> et à toutes les autres
+recommandations décrites dans <url id="&url-debian-policy;" name="le Debian
+Policy Manual">. Les DFSG<footnote><em>Debian Free Software
+Guidelines</em></footnote> constituent notre définition de <em>logiciel
+libre</em>. Reportez-vous au <em>Debian Policy Manual</em> pour en savoir
+plus.
+
+<p>
+Les paquets de la section <em>contrib</em> doivent être conformes aux DFSG
+mais ne respectent pas d'autres contraintes. Ils peuvent par exemple dépendre
+de paquets de la section <em>non-free</em>.
+
 <p>
+Les 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.
 
-   <em>N'utilisez pas</em> les fonctionnalités « reply to all recipients » ou
-   « follow-up » de votre outil de courrier, à moins d'avoir l'intention de 
-   modifier ensuite les destinataires. En particulier, n'envoyez pas un message 
-   de « follow-up » à <tt>nnn@bugs.debian.org</tt> et à 
-   <tt>submit@bugs.debian.org</tt> simultanément parce que le système de suivi 
-   de bogues recevrait alors deux copies de chaque et chacune serait renvoyée à
-   <tt>debian-devel</tt> séparément.
-<p> 
+<p>
+Le <em>Debian Policy Manual</em> donne des définitions plus précises pour ces trois sections.
+Les paragraphes précédants ne constituent qu'une introduction.
+
+<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.
 
-<sect1>Enregistrer que vous avez fait suivre un rapport de bogue
 <p>
+D'un autre coté, un distributeur de cédérom pourra facilement vérifier
+individuellement les licences des paquets de la section <em>non-free</em> et
+ajouter autant de paquets qu'il est autorisé à le faire sur ses cédéroms (dans
+la mesure où cela varie énormément d'un distributeur à l'autre ce travail ne
+peut être fait par les développeurs Debian).
+
+
+
+       <sect>Les architectures
 
-   Quand un développeur fait suivre un rapport de bogue au développeur d'un 
-   paquet plus général dont est dérivé le paquet Debian, il doit le noter dans 
-   le système de suivi de bogue comme suit :
 <p>
+À ses débuts, le noyau Linux existait uniquement pour les architectures Intel
+x86&nbsp;; il en était de même pour Debian. Linux devenant de plus
+en plus populaire, il a été porté vers d'autres architectures.  <p> Le noyau
+2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC, Motorola, 680x0
+(Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2 supporte encore
+plus d'architectures dont ARM et UltraSPARC.  Puisque Linux supporte ces
+architectures, Debian a décidé qu'il devait les supporter aussi. C'est
+pourquoi plusieurs portages sont en cours&nbsp;; en fait il y a aussi des portages
+vers d'autres noyaux. À coté d'<em>i386</em> (notre nom pour Intel x86), nous
+avons, au moment où j'écris <em>m68k</em>, <em>alpha</em>, <em>powerpc</em>,
+<em>sparc</em>, <em>hurd-i386</em>, et <em>arm</em>.
 
-   Vérifiez que le champ « To » de votre message à l'auteur contient uniquement 
-   l'adresse de l'auteur ; mettez ensuite la personne qui a signalé le bogue et
-   <tt>nnn-forwarded@bugs.debian.org</tt> dans le champ « CC ».
 <p>
+&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>.  Debian 2.0
+supporte les architectures <em>i386</em> et <em>m68k</em>.  Debian 2.1
+supporte les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
+<em>sparc</em>. Debian 2.2 ajoute le support de l'architecture
+<em>powerpc</em>.
 
-   Demandez à l'auteur de respecter le « CC » à <tt>nnn-forwarded@bugs</tt> 
-   quand il répond, pour que le système de suivi de bogue archive sa réponse 
-   avec le rapport original.
 <p>
+Vous trouverez des informations destinées aux développeurs à propos d'un
+portage particulier sur la page <url id="&url-debian-ports;" name="Portage
+Debian">.
+
+
+
+
+       <sect>Les sous-sections
 
-   Quand le système de suivi de bogues reçoit un message à 
-   <tt>nnn-forwarded</tt>, il marque le bogue correspondant comme ayant été 
-   transmis à (aux) adresse(s) figurant dans le champ « To » du message qu'il 
-   reçoit.
 <p>
-   
-   Vous pouvez aussi manipuler l'information « forwarded to » en envoyant des 
-   messages à <tt>control@bugs</tt>.
+Les sections <em>main</em>, <em>contrib</em> et <em>non-free</em> sont
+divisées en sous-sections  pour simplifier le processus d'installation et la
+maintenance de l'archive Debian. Ces sous-sections ne sont pas définies
+formellement, à l'exception peut-être de la sous-section <em>base</em>.
+Elles existent pour simplifier l'organisation des paquets et la navigation
+dans la liste des paquets disponibles. Reportez-vous à la distribution
+courante pour connaître la liste des sous-sections disponibles.
+
 <p>
-   
-<sect1>Messages de résumé à « debian-devel »
+Notez qu'avec l'introduction de la nouvelle organisation de l'archive (voir le
+répertoire racine <em>pool/</em>), les sous-sections matérialisées par des
+répertoires pourraient disparaître à l'avenir. Elles seront cependant
+conservées dans le champ <tt>Section</tt> de l'en-tête des paquets.
+
+
+
+
+       <sect>Les paquets
+
 <p>
+Il existe deux types de paquets Debian&nbsp;: les paquets sources et les 
+paquets binaires.
 
-   Chaque vendredi, une liste des bogues non résolus est postée sur 
-   <tt>debian-devel</tt>, triée suivant l'âge du rapport ; chaque mardi, une 
-   liste des rapports de bogue non résolus depuis trop longtemps est postée,
-   triée suivant le mainteneur du paquet.
 <p>
+Les paquets sources sont constitués de deux ou trois fichiers&nbsp;: 
 
-   Si le mainteneur d'un paquet est listé incorrectement, c'est généralement 
-   parce qu'il y a eu un changement de mainteneur récemment, et le nouveau 
-   mainteneur n'a pas encore envoyé de nouvelle version du paquet avec un champ 
-   de contrôle « Maintainer » modifié. Ceci sera réglé quand le paquet sera 
-   envoyé. Une autre solution, il y a un fichier que les mainteneurs de la 
-   distribution peuvent éditer pour enregistrer les changements de mainteneur. 
-   Par exemple, si un nouveau paquet n'est pas prévu pour une période 
-   suffisamment longue, vous pouvez contacter 
-   <tt>iwj-mastercron@master.debian.org</tt> pour que le changement soit forcé.
+       <list compact>
+       <item>
+       un fichier <tt>.dsc</tt> et un fichier <tt>.tar.gz</tt> ou,
+
+       <item>
+       un fichier <tt>.dsc</tt>, un fichier <tt>.orig.tar.gz</tt> et un
+       fichier <tt>.diff.gz</tt>.
+
+       </list>
+       
 <p>
+Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
+distribué en dehors de Debian, il n'y a qu'un fichier <tt>.tar.gz</tt> qui
+contient les sources du programme. Si un paquet est distribué ailleurs, le
+fichier <tt>.orig.tar.gz</tt> contient ce que l'on appelle <em>code source
+amont</em>, c'est-à-dire le code source distribué par le <em>mainteneur
+amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le
+fichier <tt>.diff.gz</tt> contient les modifications faites par le responsable
+Debian.
 
-<sect1>Rouvrir, réassigner et manipuler des bogues
 <p>
+Le fichier <tt>.dsc</tt> liste tous les fichiers sources avec leurs sommes de
+contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
+concernant le paquet (responsable, version, etc).
+
+
+
+
+       <sect>Les répertoires des distributions
 
-   Il est possible de réassigner des rapports de bogue à d'autres paquets, d'en 
-   rouvrir certains clos par erreur, de modifier l'information disant où 
-   l'information a été transmise (forwarded), si elle l'a été, de changer les 
-   titres des rapports, de fusionner et séparer des rapports de bogue. Ceci est 
-   fait en envoyant des courriers électroniques à 
-   <tt>control@bugs.debian.org</tt>.
 <p>
+L'organisation des répertoires présentée précédemment est elle-même englobée
+par les <em>répertoires des distributions</em>.  Chaque distribution est
+incluse dans le répertoire <tt>pool</tt> à la racine de l'archive Debian.
 
-   Le format de ces messages est décrit dans les sections
-   suivantes.
 <p>
+En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par
+exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
+Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
+courant. Un autre emplacement courant est <tt>/pub/debian</tt>.
 
-<sect1>Fonctionnalités plus ou moins obsolètes
-(étude des sujets)
 <p>
+Une distribution est composée de paquets Debian sources et binaires et des
+fichiers <tt>Sources</tt> et <tt>Packages</tt> correspondants. Ces derniers
+contiennent la description de tous les paquets. Les premiers sont
+conservés dans le répertoire <tt>pool/</tt> tandis que les seconds sont
+conservés dans le répertoire <tt>dists/</tt> de l'archive (pour des questions
+de compatibilité descendante)
+
+
+
+
+       <sect1 id="sec-dists"><em>Stable</em>, <em>testing</em> et
+                             <em>unstable</em>
 
-   Les messages qui arrivent pour soumission ou les bogues dont le sujet 
-   commence par <tt>Bug#nnn</tt> sont traités comme ayant déjà été envoyés à
-   <tt>nnn@bugs</tt>. Ceci pour des raisons de compatibilité ascendante avec les 
-   courriers envoyés depuis les anciennes adresses et pour éviter les messages 
-   de suivi (followup) envoyés par erreur à <tt>submit@bugs.debian.org</tt> pour 
-   soumission (par exemple, en utilisant « reply to all recipients »).
 <p>
+Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
+<tt>dists/stable</tt>), une distribution appelée <em>testing</em> (dans le
+répertoire <tt>dists/testing</tt>) et une distribution appelée
+<em>unstable</em> (dans le répertoire <tt>dists/unstable</tt>). Ceci reflète
+le processus de développement du projet Debian.
+       
+<p>
+Les développements se font sur la distribution <em>unstable</em><footnote>
+<em>unstable</em> signifie «&nbsp;instable&nbsp;»</footnote> (c'est pourquoi
+elle est aussi appelée <em>distribution de développement</em>). Chaque
+développeur Debian peut modifier ses paquets à tout moment dans cette
+distribution. Ainsi son contenu change tous les jours. Comme aucun effort
+particulier n'est fait pour s'assurer que tout fonctionne correctement dans
+cette distribution, elle est parfois <em>instable</em>. 
 
-   Un schéma similaire est utilisé pour « maintonly », « done », « quiet » et 
-   « forwarded », qui traitent les courriers arrivant avec un champ « Subject »
-   modifié comme ayant été envoyés à l'adresse <tt>nnn-whatever@bugs</tt> 
-   correspondante.
-<p>   
+<p>
+Les paquets sont copiés de <em>unstable</em> vers <em>testing</em> s'ils
+satisfont certains critères. Pour entrer dans la distribution <em>testing</em>
+un paquet doit faire partie de l'archive depuis deux semaines et ne doit pas
+avoir de bogue bloquant pour la distribution (<em>RC bug</em>). Passé cette
+période, le paquet sera installé dans <em>testing</em> dès que les paquets
+dont il dépend y seront. Ce processus est automatique. Vous pouvez consulter
+quelques notes sur ce système ainsi que les <tt>update_excuses</tt> (qui
+indiquent quels paquets sont candidats, lesquels ne le sont pas et pourquoi) à
+l'adresse <url id="&url-testing-maint;">.
 
-   Les messages arrivant sans numéro de rapport de bogue dans leur adresse, ni 
-   dans leur champ Subject seront archivés comme « junk » et gardés pendant 
-   quelques semaines, mais autrement ignorés.
 <p>
+Après une période de développement, quand le responsable de
+distribution<footnote><em>Release manager</em></footnote> le juge opportun, la
+distribution <em>testing</em> est gelée, ce qui signifie que les conditions à
+remplir pour qu'un paquet passe de <em>unstable</em> à <em>testing</em> sont
+durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
+autorisées concernent les corrections de bogues. Après quelques temps,
+selon l'avancement, la distribution entre dans une phase de
+«&nbsp;gel complet&nbsp;» où les seules modifications acceptées concernent la
+procédure d'installation. Cette phase s'appelle un «&nbsp;cycle de test&nbsp;»
+et cela peut durer jusqu'à deux semaines.  Il peut y avoir plusieurs cycles de
+tests avant que le responsable de distribution ne la déclare prête pour la
+diffusion. À la fin du dernier cycle de test, la distribution <em>frozen</em>
+est renommée <em>stable</em>, remplaçant l'ancienne distribution <em>stable</em> qui
+est enlevée à cette occasion (elle peut être retrouvée à l'adresse
+<tt>&archive-host;</tt>).
 
-<sect1>Projets futurs
 <p>
+Ce cycle de développement est basé sur l'idée que la distribution
+<em>instable</em> devient <em>stable</em> après une période de test
+(<em>testing</em>). Une distribution contient inévitablement des
+bogues, même si elle est classée stable. C'est pourquoi les distributions
+stables sont mises à jour de temps en temps. Les corrections introduites sont
+testées avec une grande attention et ajoutées individuellement à l'archive
+pour diminuer les risques d'introduire de nouveaux bogues. Vous pouvez trouver
+des paquets proposés pour les mises à jour de <em>stable</em> dans le
+répertoire <tt>proposed-updates</tt>. De temps en temps, les paquets de ce
+répertoire qui ne présentent pas de problème sont installés dans la
+distribution <em>stable</em> et le numéro de révision de cette distribution
+est incrémenté («&nbsp;1.3&nbsp;» devient «&nbsp;1.3r1&nbsp;»,
+«&nbsp;2.0r2&nbsp;» devient «&nbsp;2.0r3&nbsp;» et ainsi de suite).
 
-   Le champ « Package: » de l'en-tête devrait devenir obligatoire ; 
-   actuellement, en cas d'oubli, seul un avertissement est généré.
 <p>
+Notez que pendant la période de gel les développements continuent sur la
+distribution instable car cette distribution reste en place. 
+
+
+       <sect1><em>Experimental</em>
 
-<sect1>Fonctionnalité obsolète « X-Debian-PR: quiet »
 <p>
+La distribution <em>experimental</em> est une distribution particulière. Ce
+n'est pas une distribution à part entière comme le sont <em>stable</em> et
+<em>unstable</em>. Elle est prévue pour servir de plate-forme de développement
+pour les projets expérimentaux qui ont de grandes chances de détruire le
+système ou bien pour des logiciels qui sont vraiment trop instables pour être
+inclus dans la distribution <em>unstable</em> (mais pour qui une mise en 
+paquet est justifiée). Les utilisateurs qui téléchargent et
+installent des paquets depuis 
+<em>experimental</em> sont prévenus&nbsp;: on ne peut pas faire confiance à la
+distribution <em>experimental</em>.
 
-   Ceci est utilisé pour empêcher le système de suivi de bogues de transmettre 
-   n'importe où des messages qu'il reçoit à <tt>debian-bugs</tt>, en rajoutant 
-   une ligne <tt>X-Debian-PR: quiet</tt> dans l'en-tête du courrier.
-<p>   
+<p>
+Si un logiciel risque de causer des dégats importants, il sera
+sûrement préférable de le mettre dans la distribution <em>experimental</em>.
+Un système de fichier compressé, par exemple, devrait probablement aller dans
+<em>experimental</em>.
 
-   Cette en-tête est maintenant ignorée. A la place, envoyez vos messages à 
-   <tt>quiet</tt> ou <tt>nnn-quiet</tt> (ou <tt>maintonly</tt> ou 
-   <tt>nnn-maintonly</tt>).
 <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.
 
-<sect>L'interface de contrôle par courrier
 <p>
+Quelques logiciels expérimentaux peuvent aller dans <em>unstable</em>, avec un
+avertissement dans la description mais ce n'est pas recommandé car les paquets
+de <em>unstable</em> se propagent dans <em>testing</em> et aboutissent dans
+<em>stable</em>.
 
-   En plus du serveur de courrier sur <tt>request@bugs.debian.org</tt> qui 
-   permet la recherche de données sur les bogues et de documentation par 
-   courrier électronique, il y a un autre serveur à 
-   <tt>control@bugs.debian.org</tt> qui permet de manipuler les rapports de 
-   bogues de plusieurs façons.
 <p>
+Un nouveau logiciel qui ne risque pas d'endommager le système ira
+directement dans <em>unstable</em>. 
 
-   Le serveur de contrôle fonctionne de la même façon que le serveur de 
-   requêtes, excepté qu'il a quelques commandes supplémentaires ; en fait, c'est 
-   le même programme. Les deux adresses sont seulement séparées pour éviter que 
-   les utilisateurs ne fassent des erreurs et causent des problèmes en essayant 
-   juste d'obtenir des informations.
 <p>
+Une alternative à <em>experimental</em> consiste à utiliser vos pages
+personnelles sur le serveur <tt>people.debian.org</tt>
+(<tt>klecker.debian.org</tt>).
+
+       <sect id="codenames">Les noms de distribution
 
-   Regardez « introduction au serveur de requêtes » disponible sur le World Wide 
-   Web, dans le fichier bug-maint-mailcontrol.txt ou en demandant de l'aide à 
-   chaque serveur de courrier pour les bases d'utilisation des serveurs et les 
-   différentes commandes disponibles quand on écrit à une adresse.
 <p>
+Chaque distribution Debian diffusée a un nom&nbsp;: Debian 1.1 s'appelle
+«&nbsp;buz&nbsp;»&nbsp;; Debian 1.2, «&nbsp;rex&nbsp;»&nbsp;; Debian 1.3 «&nbsp;bo&nbsp;»&nbsp;;
+Debian 2.0, «&nbsp;hamm&nbsp;»&nbsp;; Debian 2.1, «&nbsp;slink&nbsp;»; Debian 2.2
+«&nbsp;potato&nbsp;» et Debian 3.0 «&nbsp;woody&nbsp;». Il y a aussi une pseudo-distribution nommée
+«&nbsp;sid&nbsp;», il s'agit de la distribution <em>unstable</em>&nbsp;; comme les
+paquets vont de <em>unstable</em> à <em>testing</em> quand ils approchent de
+la stabilité, la distribution «&nbsp;sid&nbsp;» n'est jamais diffusée.  En plus
+du contenu habituel d'une distribution Debian, «&nbsp;sid&nbsp;» contient des
+paquets pour des architectures qui ne sont pas encore officiellement
+supportées ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
+architectures doivent rejoindre les architectures supportées à une date
+future.
 
-   La carte de référence pour les serveurs de courrier est disponible via le 
-   WWW, dans le fichier bug-mailserver-refcard.txt ou par courrier électronique 
-   en utilisant la commande « refcard ».
 <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.
 
-Voici la liste des commandes disponibles :
-<taglist> 
-<tag><tt>   close bugnumber</tt>
-<item>
-          Ferme le rapport de bogue « #bugnumber ».
 <p>
+Si nous avions nommé le répertoire qui contient la prochaine version àc
+diffuser «&nbsp;testing&nbsp;», il aurait fallu le renommer
+«&nbsp;stable&nbsp;» au moment de la diffusion, ce qui aurait forcé les
+miroirs FTP à re-télécharger la distribution complète (qui est plutôt
+volumineuse).
 
-          Une notification est envoyée à l'utilisateur qui a soumis le bogue, 
-          mais (contrairement au courrier envoyé à <tt>bugnumber-done@bugs</tt>) 
-          le texte du courrier qui a clos le bogue <em>n'est pas</em> inclus 
-          dans cette notification. Le mainteneur qui a fermé un rapport devrait 
-          s'assurer, probablement en envoyant un message séparé, que 
-          l'utilisateur qui a soumis le bogue sait pourquoi il a été clos.
 <p>
+D'un autre coté, si une distribution s'appelle <em>Debian-x.y</em> dès le
+départ, des personnes pourraient s'imaginer que la distribution Debian
+<em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
+avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
+pré-1.0. C'est pour cette raison que la première version officielle était la
+version 1.1 et non la 1.0.)
 
-<tag><tt>   reassign bugnumber package</tt>
-<item>
-          Enregistre que le rapport de bogue « #bugnumber » est un bogue dans un 
-          paquet. Ce peut être utilisé pour fixer le paquet si l'utilisateur a 
-          oublié la pseudo en-tête, ou pour modifier une assignation précédente. 
-          Aucune notification n'est envoyée à qui que ce soit (en dehors des
-          informations usuelles transcrites lors des traitements).
 <p>
+En conséquence, les noms de répertoire des distributions dans l'archive sont
+déterminés par leurs noms de code et non par leur statut (exemple&nbsp;: slink). Ces
+noms sont identiques pendant la période de développement et une fois la
+distribution diffusée&nbsp;; des liens symboliques, qui peuvent être modifiés
+facilement, indiquent la distribution stable actuelle. 
 
-<tag><tt>   reopen bugnumber [originator-address|=]</tt>
-<item>
-          Rouvre « #bugnumber » si il a été fermé.
 <p>
+Tout ceci explique pourquoi les répertoires des distributions sont nommés à
+partir des noms de code des distributions alors que <em>stable</em>,
+<em>testing</em> et <em>unstable</em> sont des liens
+symboliques qui pointent vers les répertoires appropriés.
+
+
+
+
+
+       <chapt id="upload">La mise à jour d'un paquet
+
+
+       <sect>Nouveaux paquets
 
-          Par défaut, vous êtes enregistré comme étant à l'origine du rapport, 
-          donc vous recevrez l'accusé de réception quand il sera fermé une 
-         nouvelle fois. Ceci pour éviter d'inonder un innocent utilisateur avec 
-         plusieurs notifications sur un même rapport de bogue.
 <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.
 
-          Si vous rajoutez une adresse d'origine, l'auteur du rapport de bogue 
-          sera enregistré à l'adresse que vous avez rajouté. Vous pouvez 
-          utiliser <tt>=</tt> pour conserver l'auteur original des traitements
-          précédents. C'est habituellement une bonne idée d'annoncer à la 
-          personne qui est enregistrée comme auteur du rapport de bogue que vous
-          rouvrez le rapport, pour qu'elle s'attende à recevoir l'accusé de 
-          clôture du bogue.
 <p>
+Supposons que personne ne travaille sur le paquet que vous visez, vous devez
+alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
+pseudo-paquet <tt>wnpp</tt>. Ce
+courrier devra décrire le paquet que vous projetez de créer, la licence de ce
+paquet et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
+pas limitative.
 
-          Si le bogue n'est pas fermé, alors le rouvrir ne fera rien, même pas 
-          de changer l'auteur original. Il n'y a aucune manière de changer 
-          l'auteur original d'un rapport de bogue ouvert (ceci est délibéré pour 
-          qu'il ne puisse pas y avoir de rapport de bogue fermé et détruit 28
-          jours plus tard sans que personne ne soit au courant.
 <p>
+Le sujet de votre rapport de bogue devra être &lt;ITP<footnote><em>Intent To
+Package</em>&nbsp;: intention de mise en paquet</footnote>&nbsp;:
+<var>NomDuPaquet</var> &mdash; <var> courte description </var>&gt;, en remplaçant
+<var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
+<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
+&email-debian-devel; en mettant cette adresse dans le champ
+<tt>X-Debbugs-CC:</tt> de l'en-tête du message. N'utilisez pas le champ
+<tt>CC:</tt> car de cette manière le sujet du message ne contiendrait pas le
+numéro du bogue.
 
-<tag><tt>   forwarded bugnumber address</tt>
-<item>
-          Enregistre que le rapport de bogue a été passé à un mainteneur à 
-          l'adresse <tt>address</tt>. Ceci n'envoie pas le message à la personne
-          concernée. Ceci peut être utilisé pour modifier une adresse de 
-          « forwarded-to » erronée, ou pour en enregistrer un nouveau pour un 
-         bogue n'ayant pas été noté comme ayant précédemment été transmis.
 <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">).
 
-<tag><tt>   notforwarded bugnumber</tt>
-<item>
-          Efface toute trace que le rapport de bogue a été transmis à un 
-          quelconque mainteneur. Si le bogue n'a pas été enregistré comme ayant
-          été transmis, alors ceci ne fera rien.
 <p>
+Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer
+leurs intentions&nbsp;:
+
+       <list compact>
+       <item>
+       Les responsables ont ainsi la possibilité de puiser dans l'expérience
+       des autres responsables et cela leur permet de savoir si une autre personne
+       travaille déjà dessus.
+
+       <item>
+       D'autres personnes qui envisagent de travailler sur le même paquet
+       apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
+       être partagé.
+
+       <item>
+       Cela permet aux autres responsables d'en savoir plus sur le nouveau
+       paquet que ne le permettent la description d'une ligne et l'habituelle
+       entrée «&nbsp;<em>Initial release</em>&nbsp;» que l'on trouve dans les
+       fichiers <em>changelog</em> qui sont postés sur
+       <tt>debian-devel-changes</tt>.
+
+       <p>
+       C'est une information utile pour les gens qui utilisent la
+       distribution <em>unstable</em> et qui sont nos premiers testeurs. Nous
+       devons faciliter la tâche de ces gens.
+
+       <p>
+       Avec ces annonces, les développeurs Debian et toutes les autres personnes
+       intéressées peuvent se faire une meilleure idée des évolutions et nouveautés du
+       projet.
+
+       </list>
+
+
+       <sect id="changelog-entries">
+       <heading>Ajouter une entrée à debian/changelog</heading>
 
-<tag><tt>   retitle bugnumber new-title</tt>
-<item>
-          Change le titre d'un rapport de bogue pour celui spécifié (par défaut, 
-          il s'agit du champ Subject de l'en-tête du courrier du rapport 
-          original).
 <p>
+Les modifications que vous apportez au paquet doivent être tracées dans le
+fichier <file>debian/changelog</file>. Ces traces doivent donner une
+description concise des changements, expliquer pourquoi (si ce n'est pas
+clair) et indiquer si des rapports de bogues sont clos. Il faut aussi indiquer
+quand le paquet a été terminé. Ce fichier sera installé dans
+<file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
+<file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
+natif.
 
-          Contrairement à beaucoup des commandes de manipulation de bogue 
-          utilisées sur un rapport parmi quelques-uns fusionnés, celle-ci 
-          changera uniquement le titre du bogue concerné et pas ceux des 
-          rapports avec lesquels il est fusionné.
 <p>
+Le fichier <file>debian/changelog</file> a une structure précise comportant
+différents champs. Le champ <em>distribution</em> est décrit dans <ref
+id="upload-dist">. Vous trouverez plus d'information sur la structure de ce
+fichier dans le <em>Debian Policy Manual</em> section
+«&nbsp;<file>debian/changelog</file>&nbsp;».
 
-<tag><tt>   merge bugnumber bugnumber ...</tt>
-<item>
-          Fusionne deux ou plusieurs rapports de bogue. Quand des rapports sont 
-          fusionnés, l'action d'ouvrir, fermer, marquer comme transmis ou 
-         supprimer cette marque et réassigner un des bogues à un nouveau 
-         paquet, aura un effet identique sur tous les autres rapports 
-         fusionnés.
 <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">.
 
-          Avant que les bogues puissent être fusionnés, ils doivent être 
-          exactement dans le même état : soit tous ouverts, soit tous fermés, 
-          avec la même adresse de mainteneur « forwarded-to », s'ils ont été 
-          transmis ou aucun marqué comme transmis, et tous assignés au(x) 
-          même(s) paquet(s) (une comparaison exacte des chaînes de caractères 
-          est faite sur le paquet auquel le bogue est assigné). Si ils ne sont 
-          pas dans le même état au départ, vous devrez utiliser réassigne 
-          (reassign), rouvrir (reopen) et les autres pour vous assurer qu'ils se 
-          trouvent dans le même état avant de les fusionner.
 <p>
+Par convention, l'entrée changelog d'un paquet qui contient une nouvelle
+version amont ressemble à&nbsp;:
+<example>
+  * new upstream version
+</example>
 
-          Si un des bogues listés dans la commande de fusion est déjà fusionné 
-          avec un autre bogue, alors tous les rapports fusionnés avec un de ceux
-          listés seront fusionnés également. La fusion est comme l'égalité : 
-          c'est réflexif, transitif et symétrique.
 <p>
+Quelques outils peuvent vous aider à créer des entrées et finaliser
+<file>changelog</file> pour une livraison &mdash; voir les sections <ref
+id="devscripts"> et <ref id="dpkg-dev-el">.
+
+       <sect id="upload-checking">Vérifier le paquet avant la mise à jour
 
-          Fusionner des rapports de bogue provoque l'apparition d'une note dans 
-          les traces de chacun des rapports ; sur les pages WWW, des liens sur 
-          les autres bogues sont rajoutés
-<p>
-
-          L'expiration des rapports fusionnés se produit pour tous 
-          simultanément, et uniquement quand chacun des paquets pris séparément 
-          répond aux critères d'expiration.
-<p>
-
-<tag><tt>   unmerge bugnumber</tt>
-<item>
-          Sépare un rapport de bogue d'autres rapports de bogue avec lesquels il 
-          a été fusionné. Si le rapport listé est fusionné avec plusieurs 
-          autres, alors ils sont tous laissés fusionnés ensemble, et seules leur 
-          association avec le bogue explicitement cité sont supprimées.
 <p>
+Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
+devrez au moins faire les tests suivants (il vous faut une ancienne version
+du paquet)&nbsp;:
+       <list compact>
+       <item>
+       Installez le paquet et vérifiez que le logiciel fonctionne. Si le
+       paquet existait déjà dans une version plus ancienne, faites une mise à
+       jour.
+
+       <item>
+       Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
+       <prgn>lintian</prgn> comme suit&nbsp;: <tt>lintian -v
+       <var>package-version</var>.changes</tt>. Ce programme fera une
+       vérification sur les paquets source et binaire. Si vous ne comprenez
+       pas les messages générés par <prgn>lintian</prgn> essayez l'option
+       <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
+       bavard dans sa description du problème.
+       <p>
+       En principe, un paquet pour lequel
+       <prgn>lintian</prgn> génère des erreurs (elles commencent par
+       <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
+       <p>
+       Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
+       section lintian <ref id="lintian">.
+       
+       <item>
+       Faites régresser le paquet
+       vers sa version précédente si elle existe &mdash; cela permet de tester les
+       scripts <tt>postrm</tt> et <tt>prerm</tt>.
+
+       <item>
+       Désinstallez le paquet et réinstallez-le.
+
+       </list>
+
+
+
+       <sect>Générer le fichier « changes »
+<p>
+Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
+être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
+l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
+général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
+fabrication du paquet.
+
+<p>
+Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
+suivants&nbsp;:
+
+<p>
+&control-file-fields;
+
+<p>
+Tous ces champs sont obligatoires pour une installation sur les serveurs
+Debian.  Vous pouvez consulter la liste des champs de contrôle dans le
+<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
+les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
+automatiquement avec le champ <tt>Description</tt> (voir <ref
+id="upload-bugfix">).
+
+
+       <sect1>L'archive des sources amonts
+<p>
+La première fois qu'un paquet est installé dans l'archive pour une version
+amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
+téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
+fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
+<tt>.dsc</tt> et il ne sera pas nécessaire de le télécharger à nouveau.
+
+<p>
+Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
+incluront le fichier <tt>tar</tt> amont si et seulement si le numéro de
+révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
+amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
+l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
+
+<p>
+Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
+originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
+fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier
+<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
+raison ou pour une autre il y a une différence, la nouvelle version de ce
+fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
+<tt>-sa</tt> par exemple).
+
+
+
+
+       <sect1 id="upload-dist">Choisir une distribution
+
+<p>
+Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
+<file>debian/changelog</file>, indique à quelle distribution le paquet est
+destiné.
+
+<p>
+Il y a trois valeurs possibles pour ce champ&nbsp;: <em>stable</em>,
+<em>unstable</em> et <em>experimental</em>&nbsp;. En temps
+normal, les paquets sont téléchargés dans <em>unstable</em>.
+
+<p>
+Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause
+des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et
+pour les paquets fabriqués par le démon de compilation pour les autres
+architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et
+comment faire une mise à jour de <em>stable</em>.
+
+<p>
+Notez bien que combiner <em>experimental</em> avec quelque distribution
+que ce soit n'a pas de sens.
+
+
+       <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>
+
+<p>
+Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
+sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
+pour y être testé avant d'être effectivement inclus dans <em>stable</em>.
+
+<p>
+Une livraison pour la distribution <em>stable</em> requière des soins
+supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
+que dans les cas suivants&nbsp;:
+
+       <list>
+       <item>un problème de sécurité (un avis de sécurité
+       Debian<footnote>Debian security advisory.</footnote>),
+       <item>un probleme fonctionnel vraiment critique,
+       <item>un paquet devenu ininstallable,
+       <item>un paquet indisponible pour une architecture.
+       </list>
+
+<p>
+Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
+important car même une modification triviale peut causer un bogue plus 
+tard. Livrer une nouvelle version amont d'un logiciel pour corriger un 
+problème de sécurité est désapprouvé&nbsp;; dans la plupart des cas la
+bonne solution consiste à prendre la rustine correspondante de la
+nouvelle version amont et à l'appliquer à l'ancienne (faire un
+portage (<em>backport</em>) de la rustine.
+
+<p>
+Les paquets livrés pour <em>stable</em> doivent être compilés avec la
+distribution <em>stable</em> pour que leurs dépendances se limitent aux
+bibliothèques (et autres paquets) disponibles dans <em>stable</em>&nbsp;;
+un paquet livré pour la distribution <em>stable</em> qui dépend d'une
+bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
+Modifier les dépendances d'autres paquets (en manipulant le champ
+<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
+ininstallables, est fortement déconseillé.
+
+<p>
+L'équipe responsable de la distribution<footnote><em>the Release
+team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera
+régulièrement le contenu de <em>proposed-updates</em> et décidera si votre
+paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis
+(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog,
+vos changements pour une livraison vers <em>stable</em> sinon le paquet ne
+sera pas considéré.
+
+
+
+       <sect id="uploading">Mettre à jour un paquet
+
+
+       <sect1 id="upload-ftp-master">Installer un paquet sur
+       <tt>ftp-master</tt> 
+
+<p>
+Pour installer un paquet vous avez besoin d'un compte sur
+<ftpsite>ftp-master</ftpsite>, ce que vous devez avoir en tant que
+développeur Debian. Si vous utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn>
+pour télécharger vos paquets, placez-les dans
+<tt>&us-upload-dir;</tt>.  Si vous utilisez un FTP anonyme,
+placez-les dans <ftppath>/pub/UploadQueue/</ftppath>. Attention, il est
+préférable de transférer le fichier <tt>changes</tt> en dernier. Dans le cas
+constraire, votre livraison pourrait être rejetée car l'outil de maintenance
+de l'archive pourrait lire le fichier <tt>changes</tt> et constater que les
+fichiers ne sont pas tous présents. Si vous ne voulez pas vous embêter avec
+l'ordre de transfert des fichiers, vous pouvez tout simplement copier vos
+fichiers dans un répertoire temporaire de <tt>ftp-master</tt> et les déplacer
+ensuite vers <tt>&us-upload-dir;</tt>.
+
+<p>
+<em>Note&nbsp;:</em> ne téléchargez pas de paquet contenant un logiciel
+protégé par des brevets américains sur <tt>ftp-master</tt>, de même n'y
+téléchargez pas de paquet cryptographique qui appartiendrait a
+<em>contrib</em> ou <em>non-free</em>. Quand vous ne pouvez télécharger sur
+<tt>ftp-master</tt>, vous ne pouvez pas non plus télécharger sur
+<tt>chiark</tt> ou <tt>erlangen</tt>. Les livraisons de ces logiciels doivent
+aller sur <tt>non-us</tt> (voir <ref id="upload-non-us">). Si vous ne savez
+pas si votre paquet est protégé par un brevet ou s'il est soumis aux lois de
+contrôle des exportations américaines posez la question sur la liste
+&email-debian-devel;.
+
+<p>
+Les paquets <package>dupload</package> ou <package>dput</package> pourront
+vous faciliter le travail lors du téléchargement. Ces programmes, bien
+pratique, sont configurés par défaut pour
+se connecter par FTP sur les serveurs <tt>ftp-master</tt>,
+<tt>chiark</tt> et <tt>erlangen</tt>. Ils peuvent aussi être configurés pour
+utiliser <prgn>ssh</prgn> ou <prgn>rsync</prgn>. Se reporter à <manref
+name="dupload" section="1">, <manref name="dupload" section="5"> et <manref
+name="dput" section="1"> pour en savoir plus.
+
+<p>
+Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en fera le 
+logiciel de maintenance de l'archive en exécutant <prgn>dinstall</prgn>
+sur votre fichier <file>.changes</file>&nbsp;:
+
+<example>dinstall -n foo.changes</example>
+
+
+
+
+
+       <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
+       (pandora) 
+
+<p>
+Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
+exportations américain ne doivent pas être installés sur <tt>ftp-master</tt>.
+Installez le paquet sur <ftpsite>non-us.debian.org</ftpsite> dans le
+répertoire <tt>&non-us-upload-dir;</tt> (<ref id="dupload"> et <ref
+id="dput">, avec les options adéquates, peuvent tous deux être utilisés pour
+cela). Par défaut, vous pouvez utiliser le même <em>login/mot de passe</em>
+que pour <tt>ftp-master</tt>. Si vous utilisez
+une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
+répertoire <ftppath>/pub/UploadQueue/</ftppath>.
+
+<p>
+Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
+avec&nbsp;:
+
+<example>dinstall -n foo.changes</example>
+
+
+<p>
+Attention, les personnes résidant aux États-Unis et les citoyens américains
+sont soumis à des restrictions sur l'exportation des logiciels de
+cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter
+quelques logiciels de cryptographie soumis à une obligation de déclaration
+auprès du département du commerce américain. Toutefois, cette restriction a
+été abandonnée pour des logiciels qui sont déjà disponible en dehors des
+États-Unis. En conséquence, tout logiciel de cryptographie de la section
+<em>main</em> de l'archive Debian qui ne dépend d'aucun paquet d'une
+autre section &mdash; il ne doit pas dépendre de <em>non-US/main</em> &mdash;
+peut être téléchargé sur ftp-master ou l'une de ses files d'attente décrites
+plus haut.
+
+
+<p>
+Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens
+américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être
+vigilants en le faisant.  Nous recommandons aux responsables concernés de
+prendre toutes les précautions nécessaires, <em>y compris la consultation d'un
+juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en
+livrant un paquet sur <tt>non-US</tt>.
+
+<p>
+Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>
+les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
+name="procédure décrite par le gouvernement américain">. Les responsables de
+paquets <em>non-US/non-free</em> devront en plus consulter les <url
+id="&url-notification-of-export;" name="règles de déclaration d'exportation
+pour les logiciels commerciaux">.
+
+<p>
+Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
+juridique. Une fois encore, nous recommandons aux résidents et citoyens
+américains de consulter un juriste avant de livrer un paquet sur
+<tt>non-US</tt>.
+
+
+       <sect1>Installer un paquet via <tt>chiark</tt>
+
+<p>
+Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
+possibilités. L'une d'elles consiste à télécharger vos fichiers dans
+<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Pour
+les détails consultez <url id="&url-chiark-readme;">.
+
+<p>
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
+lois de contrôle des exportations américaines sur <tt>chiark</tt>.
+Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
+les indications de la section <ref id="upload-ftp-master"> sont applicables ici
+aussi.
+
+<p>
+Le programme <prgn>dupload</prgn> est capable de télécharger sur
+<tt>chiark</tt>&nbsp;; consultez la documentation de ce programme pour en savoir
+plus.
+
+
+
+       <sect1>Installer un paquet via <tt>erlangen</tt>
+
+<p>
+Vous pouvez aussi accéder à un serveur situé en Allemagne&nbsp;: il vous suffit
+d'ouvrir une connexion anonyme sur&nbsp;:
+
+<p>
+       <url id="&url-upload-erlangen;">.
+
+<p>
+Le téléchargement fait sur ce serveur doit être aussi complet que s'il
+était fait dans le répertoire <tt>Incoming</tt> sur <tt>ftp-master</tt> :
+il doit comporter le fichier <file>.changes</file> et tous les fichiers 
+mentionnés dans ce dernier. Le serveur vérifie que le fichier 
+<tt>.changes</tt> est bien signé avec la clé PGP d'un développeur Debian pour 
+éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez bien 
+que le champ <tt>Maintainer</tt> du fichier <tt>.changes</tt> contient 
+<em>votre</em> adresse électronique. De même que sur <tt>ftp-master</tt>, 
+cette adresse est ensuite utilisée pour toutes les réponses.
+
+<p>
+Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire
+après le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous
+devriez ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de
+votre paquet. Normalement, il devrait avoir été déplacé vers
+<tt>ftp-master</tt>&nbsp;;
+vous serez informé par le même biais si une erreur s'est produite au cours du
+processus.
+
+<p>
+Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
+lois de contrôle des exportations américaines sur <tt>erlangen</tt>.
+Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
+les indications de la section <ref id="upload-ftp-master"> sont applicables ici
+aussi.
+
+<p>
+Le programme <prgn>dupload</prgn> est capable de télécharger sur 
+<tt>erlangen</tt>&nbsp;; consultez la documentation de ce programme pour en savoir
+plus.
+
+
+
+
+
+       <sect1>Les autres serveurs
+
+<p>
+Un autre serveur est disponible aux États-Unis&nbsp;; c'est un bon point
+de repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
+paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
+<tt>erlangen</tt>.
+<p>
+Il existe aussi un serveur au Japon&nbsp;: téléchargez vos paquet par FTP
+anonyme sur <url id="&url-upload-jp;">.
+
+
+
+
+       <sect id="upload-announce">Annoncer une mise à jour
+
+<p>
+Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
+listes «&nbsp;debian-changes&nbsp;». Ceci est maintenant géré automatiquement
+par le logiciel de gestion de l'archive quand il est exécuté (en principe une
+fois par jour). Vous devez juste utiliser une version récente de
+<package>dpkg-dev</package> (&gt;= 1.4.1.2). Le courrier généré par le
+logiciel de maintenance de l'archive contiendra le fichier <tt>.changes</tt>
+signé que vous avez livré avec votre paquet. Précédemment, cette charge
+revenait à <prgn>dupload</prgn>&nbsp;; vérifiez que vous avez bien configuré
+<prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
+<tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).
+
+<p>
+Si un paquet est mis à jour avec un champ <tt>Distribution:</tt> à
+<em>stable</em>, l'annonce est envoyée sur la liste&nbsp;:
+
+<p>
+<tt>   &email-debian-changes;.</tt>
+
+<p>
+S'il est mis à jour avec un champ <tt>Distribution:</tt> à <em>unstable</em>
+ou <em>experimental</em>, l'annonce est envoyée sur la liste
+&email-debian-devel-changes;.
+
+<p>
+Le programme <prgn>dupload</prgn> est suffisamment intelligent pour déterminer
+où devra aller l'annonce et pour envoyer le courrier sur la bonne liste. Voir <ref
+id="dupload">.
+
+
+
+
+       <sect id="upload-notification">
+       <heading>Notification de l'installation d'un nouveau paquet</heading>
+
+<p>
+Les administrateurs de l'archive Debian sont responsables de l'installation
+des mises à jour. La plupart des mises à jour sont gérées
+quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>.
+Les mises à jour
+de paquets sur la distribution <em>unstable</em>, en particulier, sont
+installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau
+paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois
+entre le téléchargement d'un paquet vers un serveur et son installation
+effective. Soyez patients.
+
+<p>
+Dans tous les cas vous recevrez un accusé de réception par courrier
+électronique indiquant que votre paquet a été installé et quels rapports
+de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
+les rapports de bogues que vous vouliez clore sont bien dans cette liste. 
+
+<p>
+L'accusé de réception indique aussi la section dans laquelle le paquet a
+été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
+courrier qui vous informera de cette différence (voir plus loin).
+
+
+
+
+       <sect1 id="override-file">Le fichier <em>override</em>
+
+<p>
+Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
+<file>debian/control</file> n'indiquent ni où le paquet sera installé dans
+l'archive Debian ni sa priorité. Afin de conserver la
+cohérence de l'archive, ce sont les administrateurs qui contrôlent ces
+champs. Les valeurs du fichier <file>debian/control</file> sont juste des
+indications.
+
+<p>
+Les administrateurs de l'archive indiquent les sections et priorités des paquets
+dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
+fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
+informé par courrier électronique quand votre paquet sera installé dans
+l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
+avant votre prochain téléchargement ou alors vous aurez envie de modifier le
+fichier <em>override</em>.
+
+<p>
+Pour modifier la section dans laquelle un paquet est archivé, vous devez
+d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
+envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
+paquet <package>ftp.debian.org</package> demandant la modification de la
+section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
+amènent à demander ces changements.
+
+<p>
+Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
+name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.
+
+
+
+
+       <chapt id="nmu">Mise à jour indépendante
+
+<p>
+Dans certaines circonstances il est nécessaire qu'une personne autre que le
+responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à
+jour est désigné en anglais par l'expression <em>non-maintainer upload
+(NMU)</em>.  Dans le présent document, nous traduisons librement cette
+expression par «&nbsp;mise à jour indépendante&nbsp;».
+
+<p>
+Ces mises à jour indépendantes font partie du travail normal des porteurs qui
+compilent les paquets pour d'autres architectures (voir <ref id="porting">).
+Nous faisons aussi des mises à jour indépendantes quand un développeur Debian 
+corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
+ou un bogue paralysant. Cela se produit plus particulièrement en période de
+gel de la distribution de développement ou quand le responsable officiel du
+paquet ne peut pas fournir une correction dans un délai raisonnable.
+
+<p>
+Ce chapitre contient des informations qui vous expliqueront quand et comment
+faire des mises à jour indépendantes. Une distinction fondamentale doit être
+faite entre les mises à jour indépendantes sources et les mises à jour 
+indépendantes binaires. Elle est explicitée dans la section suivante.
+
+
+       <sect id="nmu-terms">Terminologie
+
+<p>
+Deux nouvelles expressions sont introduites dans cette section&nbsp;: 
+«&nbsp;mise à jour indépendante source&nbsp;» et «&nbsp;mise à 
+jour indépendante binaire&nbsp;». Ces expressions ont une définition
+précie dans le monde Debian. Elles correspondent toutes deux au même type
+d'activité&nbsp;; elles impliquent toutes deux qu'une personne fait une mise à
+jour d'un paquet alors qu'elle n'est pas officiellement responsable de ce
+paquet. C'est pourquoi nous qualifions ces mises à jours 
+d'<em>indépendantes</em><footnote>Contrairement à ce que pourrait laisser
+entendre cette traduction de <em>non-maintainer upload</em>, il n'est pas
+question d'agir sans prévenir le responsable au préalable (voir <ref 
+id="nmu-guidelines">).</footnote>.
+
+<p>
+Une mise à jour indépendante source est une livraison de paquet faite par
+une personne qui n'est pas le responsable officiel de ce paquet avec pour
+objectif de corriger un bogue dans le paquet. Une mise à jour indépendante
+source implique toujours une modification des sources du paquet, même s'il
+ne s'agit que d'un changement dans le fichier <file>debian/changelog</file>.
+Ce changement peut tout aussi bien concerner la partie amont du source que la
+partie spécifique à Debian. Une mise à jour indépendante source peut aussi
+inclure des paquets spécifiques à une architecture, un fichier <em>diff</em>
+modifié ou, plus rarement, des nouveaux sources amonts.
+
+<p>
+Une mise à jour indépendante binaire est la recompilation et l'archivage
+d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un
+effort de portage. Une mise à jour indépendante binaire est la livraison d'un
+paquet compilé (souvent pour une autre architecture) à condition que cette
+compilation n'ait pas nécessité de modifications des sources. Dans de 
+nombreux cas, les porteurs
+sont obligés de modifier les sources pour les rendre compilables sur leur
+architecture cible&nbsp;; il s'agira alors d'une mise à jour indépendante source et
+non d'une mise à jour indépendante binaire. Comme vous pouvez le remarquer,
+nous ne faisons pas de distinction entre les mises à jour indépendantes 
+faites par des porteurs et les autres mises à jour indépendantes.
+
+<p>
+Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
+par l'expression «&nbsp;mise à jour indépendante&nbsp;»
+(NMU<footnote>Non-maintainer upload</footnote>).  Pourtant cela conduit souvent
+à des confusions car beaucoup associent «&nbsp;mise à jour indépendante&nbsp;»
+et «&nbsp;mise à jour indépendante source&nbsp;». Il faut donc rester
+vigilant. Dans ce chapitre, si nous utilisons «&nbsp;mise à jour
+indépendante&nbsp;» seul, il s'agit des deux types de livraisons.
+
+
+
+
+
+       <sect id="nmu-who">Qui peut faire une mise à jour indépendante&nbsp;?
+
+<p>
+Seuls les responsables Debian officiels peuvent faire des mises à jour
+indépendantes. Un responsable officiel est une personne dont la clé est dans
+le porte-clés Debian. Toute personne est invitée à télécharger les paquets
+sources pour corriger des bogues&nbsp;; au lieu de faire des mises à jour
+indépendantes, ils pourront soumettre les rustines qui le méritent au
+système de suivi des bogues. Les responsables apprécient presque toujours les
+rustines et les rapports de bogue soignés.
+
+
+       <sect id="nmu-when">Quand faire une mise à jour indépendante source&nbsp;?
+
+<p>
+Les recommandations pour déterminer quand faire une mise à jour indépendante
+source dépendent de la distribution visée (i.e. stable, instable ou
+experimentale). Les porteurs, ayant une activité particulière, obéissent à des règles
+légèrement différentes (voir <ref id="source-nmu-when-porter">).
+
+<p>
+Quand une faille de sécurité est détectée, un
+paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de
+l'équipe de sécurité Debian<footnote>Debian Security officer</footnote>
+entrera en contact
+avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans
+un délai raisonnable (moins de 48&nbsp;heures). Si le mainteneur ne peut
+fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps,
+l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour
+indépendante source).
+
+<p>
+Pendant le cycle de mise au point (<em>release cycle</em>, voir <ref 
+id="sec-dists">), les livraisons qui
+corrigent les bogues de gravité <em>sérieuse</em> (i.e. <em>serious</em>) et
+supérieures sont encouragées et acceptées. Même pendant cette période, vous
+devrez tenter d'entrer en contact avec le responsable du paquet&nbsp;; il pourrait
+bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour
+n'importe quelle mise à jour indépendante source, les recommandations de la
+section <ref id="nmu-guidelines"> doivent être respectées.
+
+<p>
+Les mises à jour indépendantes sont aussi acceptable pour la distribution
+instable mais seulement en dernier ressort
+ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne
+pas il est probablement correct de faire une mise à jour indépendante 
+<em>(NMU)</em>&nbsp;:
+
+<p>
+       <list compact>
+       <item>
+       Vérifiez que le bogue est bien référencé dans le système de suivi des
+       bogues.  S'il n'y est pas, faites un rapport de bogue.
+
+       <item>
+       Envoyez un courrier au responsable du paquet et proposez votre aide
+       pour corriger le bogue. Donnez-lui quelques jours.
+
+       <item>
+       Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de
+       suivi des bogues. Construisez le paquet et testez-le comme décrit dans
+       la section <ref id="upload-checking">. Utilisez le paquet chez vous.
+
+       <item>
+       Attendez une réponse pendant quelques semaines.
+
+       <item>
+       Envoyez un courrier au responsable lui demandant son accord pour faire
+       une mise à jour indépendante <em>(NMU)</em>.
+
+       <item>
+       Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
+       bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
+       possible.
+
+       <item>
+       Attendez une réponse une semaine encore.
+
+       <item>
+       Faites votre mise à jour indépendante comme décrit dans la section
+       <ref id="nmu-guidelines">.  
+
+       </list>
+
+
+
+
+
+
+       <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
+       source&nbsp;?
+
+<p>
+Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
+rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
+paquet source, cette mise à jour est automatiquement une mise à jour
+indépendante source et est soumise aux règles qui suivent. Si un porteur
+construit un paquet binaire recompilé, les règles sont différentes (voir <ref
+id="porter-guidelines">.
+
+<p>
+Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu
+intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
+modules ou des fichiers, ne déplacez pas les répertoires&nbsp;; plus généralement ne
+corrigez pas ce qui n'est pas cassé.  Faites une rustine aussi petite que
+possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en
+au responsable du paquet, au responsable amont ou soumettez un rapport de
+bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em>
+être faits lors d'une mise à jour indépendante.
+
+
+
+
+
+       <sect1 id="nmu-version">Numéro de version pour les mises à jour
+       indépendantes sources
+
+<p>
+Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
+changer, même pour la plus triviale des modifications. Notre système de
+gestion de paquets s'appuie sur ces numéros de version.
+
+<p>
+Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
+un numéro de version mineur à la partie <var>debian-revision</var> du numéro
+de version (la partie qui suit le dernier trait d'union). Ce numéro
+supplémentaire débutera à «&nbsp;1&nbsp;». Prenons pour exemple le paquet
+«&nbsp;foo&nbsp;» qui porte le  numéro de version 1.1-3. Dans l'archive, le
+fichier de contrôle du paquet source serait <file>foo_1.1-3.dsc</file>. La
+version amont est «&nbsp;1.1&nbsp;» et la révision Debian est «&nbsp;3&nbsp;».
+La mise à jour indépendante suivante ajouterait le numéro de version mineur
+«&nbsp;.1&nbsp;» au numéro de révision Debian; le nouveau fichier de contrôle
+du paquet source serait alors <file>foo_1.1-3.1.dsc</file>.
+
+<p>
+Le numéro de révision mineur est nécessaire pour éviter de prendre un numéro
+de version au responsable officiel du paquet, ce qui pourrait perturber son
+travail. Cela a aussi l'avantage de montrer clairement que le paquet n'a pas
+été livré par le responsable officiel.
+
+<p>
+S'il n'y a pas de partie <var>debian-revision</var> dans le numéro de version
+du paquet, il faut en créer une en démarrant à «&nbsp;0.1&nbsp;». S'il est
+absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
+fasse une livraison basée sur une nouvelle version amont, cette personne
+doit choisir «&nbsp;0.1&nbsp;» comme numéro de révision Debian. Le mainteneur
+du paquet doit, lui, démarrer sa numérotation à «&nbsp;1&nbsp;». Notez que pour
+faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option
+<tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il
+reconnaît les numéros de révisions «&nbsp;0&nbsp;» ou «&nbsp;1&nbsp;» &mdash; il
+n'est pas suffisamment intelligent pour reconnaître «&nbsp;0.1&nbsp;»).
+
+<p>
+Attention, les porteurs qui ne font que recompiler les paquets pour d'autres
+architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne
+doivent utiliser de nouveaux numéros de version que s'ils modifient les
+paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour
+indépendante source et non une mise à jour indépendante binaire.
+
+
+
+
+
+       <sect1 id="nmu-changelog">
+         <heading>Les mises à jour indépendantes sources doivent être
+         mentionnées dans le fichier changelog</heading>
+
+<p>
+Une personne qui fait une mise à jour indépendante source doit ajouter une
+entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
+et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
+comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
+version livrée.
+
+<p>
+Par convention, dans le cas d'une mise à jour indépendante source
+<em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne
+
+<example>
+  * Non-maintainer upload
+</example>
+
+
+
+
+
+       <sect1 id="nmu-patch">Mise à jour indépendante source et système
+       de suivi des bogues 
+
+<p>
+Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
+modifications que possible et doit toujours envoyer ses modifications au
+système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
+
+<p>
+En cas de simple recompilation du paquet, le processus diffère
+suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise
+à jour indépendante qui ne nécessite rien de plus qu'une recompilation et
+n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée
+est disponible, un bogue a été corrigé dans <package>debhelper</package>),
+vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>;
+il y aura donc une modification. Si vous êtes porteur, vous êtes probablement
+en train de faire une mise à jour indépendante binaire. (Note&nbsp;: ce système ne
+tient pas compte des porteurs qui font des recompilations &mdash; tenez cela pour
+une faiblesse de notre système de gestion des paquets.)
+
+<p>
+Si la mise à jour indépendante source (<em>source NMU</em>) corrige des
+bogues, ceux-ci doivent être marqués <em>fixed</em> (corrigé) dans le système
+de suivi des bogues plutôt que clos. Par convention, seul le responsable du
+paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
+rapport.  Heureusement, le système d'archivage Debian reconnait les mises à
+jours indépendantes et positionne correctement le statut des bogues à
+<em>fixed</em> si la personne qui fait la mise à jour a listé tous les
+bogues dans le fichier changelog en utilisant la syntaxe <tt>Closes:
+bug#<var>nnnnn</var></tt> (voir <ref id="upload-bugfix"> pour en savoir plus
+sur la fermeture de bogue par le fichier changelog). Ce passage au statut
+<em>fixed</em> assure que chacun sait que le bogue est corrigé par une mise
+à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que
+le responsable du paquet incorpore les modifications de cette mise à jour dans
+la version officielle du paquet.
+
+<p>
+Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
+nouveau rapport de bogue qui inclura une rustine contenant toutes les
+modifications que vous avez faites.
+Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi
+employer une autre méthode pour régler le problème. Certains bogues sont
+corrigés dans la version amont, ce qui est une bonne raison pour annuler les
+modifications d'une mise à jour indépendante. Si le responsable choisit de
+mettre à jour le paquet plutôt que d'utiliser les rustines de la mise à jour
+indépendante, il devra s'assurer que cette nouvelle version corrige
+effectivement chacun des bogues corrigés dans la mise à jour indépendante.
+
+<p>
+De plus, le responsable officiel devrait <em>toujours</em> conserver les
+entrées documentant une mise à jour indépendante dans le fichier
+<file>changelog</file>.
+
+
+
+
+
+
+       <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
+
+<p>
+Les paquets faisant l'objet d'une mise à jour indépendante source sont 
+construits comme les
+autres. Sélectionnez une distribution en utilisant les règles décrites dans
+la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
+classique avec tout ce qui l'accompagne conformément à la description <ref
+id="uploading">.
+
+<p>
+En fait, toutes les prescriptions de la section <ref id="upload"> sont
+applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
+idoine.
+
+<p>
+Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt>
+dans le fichier <file>debian/control</file>. Votre nom, mentionné dans
+l'entrée du fichier <file>debian/changelog</file> concernant la mise à jour, 
+sera utilisé pour signer le fichier <tt>.changes</tt>.
+
+
+
+
+       <chapt id="porting">Le portage
+
+<p>
+Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
+un porteur et même si vous n'utilisez qu'une architecture, il est de votre
+responsabilité de développeur d'être attentif aux questions de portabilité.
+C'est pourquoi il est important que vous lisiez ce chapitre même si vous
+n'êtes pas un porteur.
+       
+<p>
+Porter un paquet consiste à faire un paquet binaire pour une architecture
+différente de celle du paquet binaire fait par le responsable du paquet. 
+C'est une
+activité remarquable et essentielle. En fait, les porteurs sont à l'origine
+de la plupart des compilations de paquet Debian. Pour un paquet binaire
+<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
+autre architecture, soit un total de &number-of-arches; recompilations.
+
+
+
+
+       <sect id="kind-to-porters">Être gentil avec les porteurs
+
+<p>
+Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un 
+grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
+modification. Malheureusement, c'est rarement le cas. Cette section contient
+une liste d'erreurs commises régulièrement par les responsables Debian &mdash;
+problèmes courants qui bloquent souvent les porteurs et compliquent
+inutilement leur travail.
+
+<p>
+Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
+remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
+étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine
+manière). Merci pour votre indulgence envers des rapports de bogues succincts ou
+peu clairs&nbsp;; faites de votre mieux pour éliminer le problème. 
+
+<p>
+Les problèmes les plus couramment rencontrés par les porteurs sont causés par
+des erreurs de mise en paquet dans le paquet source. Voici une
+<em>checklist</em> de choses auxquelles vous devez être attentif :
+
+       <enumlist>
+       <item>
+       Vérifiez que les champs <tt>Build-Depends</tt> et
+       <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
+       corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
+       paquet <package>debootstrap</package> pour créer un environnement
+       <em>unstable</em> <em>chrooté</em>. Dans cet environnement
+       <em>chrooté</em> il faudra installer le paquet
+       <package>build-essential</package> et tous les paquets mentionnés dans
+       les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
+       Ensuite, vous essayerez de fabriquer votre paquet dans cette
+       environnement.
+       <p>
+       Consultez le <url id="&url-debian-policy;" name="Debian Policy
+       Manual"> pour en savoir plus sur les dépendances de fabrication.
+       <item>
+       Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
+       le champ architecture sans avoir de bonnes raisons pour le faire. Trop
+       souvent, les développeurs ne respectent pas les instructions du
+       <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir
+       la valeur «&nbsp;i386&nbsp;» est la plupart du temps incorrect.
+
+       <item>
+       Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
+       <var>package</var>.dsc</tt> pour vous assurer que le paquet se
+       désarchive correctement. En utilisant le résultat de ce test,
+       construisez votre paquet binaire à l'aide de la commande
+       <tt>dpkg-buildpackage</tt>.
+
+       <item>
+       Vérifiez que les fichiers <file>debian/files</file> et
+       <file>debian/substvars</file> ne sont pas dans votre paquet source.
+       Ils doivent être effacés par la cible <em>clean</em> de
+       <file>debian/rules</file>.
+
+       <item>
+       Assurez-vous que vous ne vous appuyez pas sur des éléments de
+       configuration ou des logiciels installés ou modifiés localement. Par
+       exemple, vous ne devriez jamais appeler des programmes du répertoire
+       <file>/usr/local/bin</file> ou de répertoires équivalents.  Essayez de ne pas vous
+       appuyer sur des logiciels configurés de manière spéciale. Essayez de
+       construire votre paquet sur une autre machine, même s'il s'agit de la
+       même architecture.
+
+       <item>
+       Ne vous appuyez pas sur une installation préexistante de votre paquet
+       (un sous-cas de la remarque précédente).
+
+       <item>
+       Si possible, ne vous appuyez pas sur une particularité présente dans
+       un compilateur précis ou dans certaine version d'un compilateur. Si
+       vous ne pouvez pas faire autrement, assurez-vous que les dépendances
+       de fabrication reflètent bien cette restriction. Dans ce cas, vous
+       cherchez sûrement les problèmes car quelques architectures pourraient
+       choisir un compilateur différent.
+
+       <item>
+       Vérifiez que votre <file>debian/rules</file> distingue les cibles
+       <em>binary-arch</em> et <em>binary-indep</em> comme l'exige la
+       Charte Debian. Vérifiez que ces cibles sont
+       indépendantes l'une de l'autre, c'est à dire qu'il n'est pas
+       nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre.
+       Pour vérifier cela, essayez d'exécuter <tt>dpkg-buildpackage -b</tt>.
+
+       </enumlist>
+
+
+
+
+       <sect id="porter-guidelines">Instructions pour les mises à jour des
+       porteurs
+
+<p>
+Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
+de la chance et votre travail est facile. Cette section s'applique dans ce
+cas&nbsp;; elle décrit comment construire et installer correctement votre mise à
+jour indépendante binaire dans l'archive Debian. Si vous devez modifier le
+paquet pour le rendre compilable sur votre architecture cible vous devez faire
+une mise à jour des sources, consultez la section <ref id="nmu-guidelines">.
+
+<p>
+Pour une mise à jour indépendante binaire, ne faites pas de changement
+dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet
+source (cela inclut <file>debian/changelog</file>).
+
+<p>
+La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
+<tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr,
+remplacez <var>adresse-porteur</var> par votre adresse électronique. Cette
+commande construira les portions du paquet qui dépendent de l'architecture, en
+utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.
+
+
+       <sect1 id="recompile-nmu-versioning">
+       <heading>Numéro de version des mises à jour indépendantes
+       binaires</heading>
+
+<p>
+Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
+tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
+changer le numéro de version pour que le système de comparaison des numéros de
+version fonctionne correctement. Ce type de mise à jour reste une mise à jour
+indépendante binaire &mdash; il n'est pas nécessaire de reconsidérer le statut
+des paquets binaires des autres architectures pour les marquer périmés ou à
+recompiler.
+
+<p>
+Ces recompilations nécessitent des numéros de version « magiques » pour que le
+système de maintenance de l'archive comprennent que, bien qu'il y ait une
+nouvelle version, il n'y a pas eu de modification des sources. Si vous ne
+faites pas cela correctement, les administrateurs de l'archive rejetteront
+votre mise à jour (car il n'y aura pas de code source associé).
+
+<p>
+Cette magie associée à une mise à jour par recompilation est déclenchée en
+utilisant un troisième nombre dans la partie debian du numéro de version.  Si,
+par exemple, la dernière version du paquet que vous recompilez était
+«&nbsp;2.9-3&nbsp;», votre mise à jour portera le numéro
+«&nbsp;2.9-3.0.1&nbsp;». Si cette version était «&nbsp;3.4-2.1&nbsp;» votre
+mise à jour portera le numéro «&nbsp;3.4-2.1.1&nbsp;».
+
+
+
+       
+       <sect1 id="source-nmu-when-porter"> <heading>Quand faire une mise à
+       jour indépendante source pour un portage&nbsp;?</heading>
+
+<p>
+Les porteurs qui font des mises à jour indépendantes sources suivent
+généralement les instructions de la section <ref id="nmu"> tout comme les
+non-porteurs. Les délais d'attente sont cependant plus courts car les porteurs
+doivent manipuler un grand nombre de paquets.
+À nouveau, la situation diffère selon la distribution visée.
+
+<!--
+FIXME: commented out until I can work out how to upload to testing directly
+
+Une correction
+cruciale (i.e. rendre un paquet compilable sur une architecture supportée par
+la prochaine distribution) peut être installée <em>sans</em> délai pour la
+distribution gelée.
+-->
+
+<p>
+Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
+instructions précédentes sont applicables à deux différences près. Tout
+d'abord, le temps d'attente raisonnable &mdash; délai entre le moment où vous
+envoyez un rapport au système de suivi des bogues et le moment où vous pouvez
+faire une mise à jour indépendante <em>(NMU)</em> &mdash; est de sept jours. Ce
+délai peut être raccourci si le problème est crucial et met l'effort de
+portage en difficulté : c'est à la discrétion de l'équipe de portage.
+(Souvenez-vous, il ne s'agit pas d'un règlement mais de recommandations
+communément acceptées).
+
+<p>
+Deuxième différence, les porteurs qui font des mises à jour indépendantes
+sources doivent choisir une gravité <em>sérieuse</em> (i.e.
+<em>serious</em>) ou supérieure quand ils envoient leur rapport au système de
+suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un
+paquet binaire pour chaque architecture supportée au moment de la sortie de la
+distribution. Il est très important d'avoir un paquet source et un paquet
+binaire pour toutes les architectures pour être conforme à plusieurs licences.
+
+<p>
+Les porteurs doivent éviter d'implémenter des contournements pour 
+des bogues de l'environnement de compilation, du noyau ou de la libc. Quelques
+fois ces contournements sont inévitables. Si vous devez faire quelque chose de 
+ce genre, marquez proprement vos
+modifications avec des <tt>#ifdef</tt> et documentez votre contournement pour
+que l'on sache le retirer une fois que le problème aura disparu.
+
+<p>
+Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de
+leur travail pendant le délai d'attente. Ainsi d'autres personnes peuvent
+bénéficier du travail du porteur même pendant ce délai. Bien sûr ces adresses
+n'ont rien d'officiel alors soyez sur vos gardes si vous les utilisez.
+
+
+
+
+       <sect>Outils pour les porteurs
+
+<p>
+Il y a plusieurs outils pour le travail de portage. Cette section contient
+une courte description de ces outils&nbsp;; reportez-vous à la documentation de
+leurs paquets ou aux références citées ci-après pour une description complète.
+
+
+
+
+       <sect1 id="quinn-diff">
+       <heading><package>quinn-diff</package>
+
+<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>.
+
+
+
+
+
+       <sect1 id="buildd">
+       <heading><package>buildd</package>
+
+<p>
+Le système <package>buildd</package> est un système distribué pour la
+compilation d'une distribution. Il est habituellement utilisé en conjonction
+avec des automates de compilation&nbsp;; ce sont des machines «&nbsp;esclaves&nbsp;»
+qui récupèrent des paquets sources et tentent de les compiler. Il est aussi
+possible d'interagir par courrier électronique avec ce système. Cette
+interface est utilisée par les porteurs pour récupérer un paquet source (en
+général un paquet qui ne peut être compilé automatiquement) et travailler
+dessus.
+
+<p>
+<package>buildd</package> n'est pas disponible sous forme de paquet&nbsp;;
+pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont prévu
+de l'utiliser bientôt. Il regroupe un ensemble de composants très utiles,
+continuellement utilisés mais non encore mis en paquet, tels que
+<prgn>andrea</prgn>, <prgn>sbuild</prgn> et <prgn>wanna-build</prgn>.
+
+<p>
+Une partie des informations produites par <package>buildd</package> &mdash; utiles
+pour les porteurs &mdash; est disponible sur la toile à l'adresse <url
+id="&url-buildd;">. Ces informations incluent les résultats produits toutes
+les nuits par <prgn>andrea</prgn> (dépendances des sources) et
+<prgn>quinn-diff</prgn> (paquets à recompiler).  <p> Nous sommes très
+enthousiasmés par ce système car il a de nombreux usages potentiels. Des
+groupes de développeurs indépendants peuvent utiliser ce système pour créer
+différentes saveurs de la Debian &mdash; qui peuvent être ou ne pas être
+intéressantes pour tous (une version de Debian compilée avec des vérifications
+relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
+rapidement toute une distribution.
+
+
+
+
+       <sect1 id="dpkg-cross">
+       <heading><package>dpkg-cross</package>
+
+<p>
+<package>dpkg-cross</package> est un outil qui installe les bibliothèques et
+les entêtes nécessaires à une compilation croisée<footnote><em>cross-compilation</em>
+</footnote> d'une manière similaire à <package>dpkg</package>. De plus
+<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
+améliorés pour supporter les compilations croisées.  
+
+
+
+
+
+       <chapt id="archive-manip">
+       <heading>Déplacer, effacer, renommer, adopter et abandonner des
+       paquets</heading>
+
+<p>
+Certaines manipulations de l'archive ne sont pas accessibles avec le processus
+de mise à jour automatisé. Elles sont appliquées manuellement par les
+développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
+
+
+
+
+       <sect>Déplacer des paquets
+
+<p>
+Parfois un paquet pourra changer de section. Une nouvelle version d'un paquet
+de la section <tt>non-free</tt> pourrait par exemple être distribuée sous
+licence LGP GNU&nbsp;; dans ce cas le paquet doit être déplacé dans la section
+<tt>main</tt> ou <tt>contrib</tt><footnote> Reportez-vous  au <url
+id="&url-debian-policy;" name="Debian Policy Manual"> pour savoir dans quelle
+section un paquet doit être classé.</footnote>.
+
+<p>
+Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez
+les informations de contrôle du paquet pour le placer dans la section désirée
+et téléchargez à nouveau votre paquet dans l'archive. Reportez-vous au
+<url id="&url-debian-policy;" name="Debian Policy Manual"> pour en savoir
+plus.  Lisez attentivement le rapport d'installation qui vous sera envoyé lors
+de l'archivage de votre paquet. Si pour une raison ou une autre le paquet
+est toujours à son ancien emplacement, envoyez un rapport de bogue sur le
+pseudo-paquet <tt>ftp.debian.org</tt> demandant la suppression dudit paquet.
+Décrivez précisément vos manipulations car il pourrait s'agir d'un bogue dans
+le logiciel de gestion de l'archive.
+
+<p>
+Si vous avez besoin de modifier la sous-section de l'un de vos paquets
+(<tt>devel</tt> ou <tt>admin</tt> par exemple) la procédure est légèrement
+différente. Modifiez la sous-section dans le fichier de contrôle de votre
+paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
+fichier <em>override</em> comme décrit dans la section <ref
+id="override-file">.
+
+
+
+
+       <sect id="removing-pkgs">Supprimer des paquets
+
+<p>
+Si pour une raison ou une autre vous avez besoin de supprimer un paquet
+de l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile,
+que l'on conservait pour des raisons de compatibilité), il vous faudra 
+envoyer un rapport de bogue concernant le pseudo-paquet
+<tt>ftp.debian.org</tt> et demandant sa suppression. N'oubliez pas de
+préciser de quelle distribution le paquet doit être supprimé.
+
+<p>
+Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
+autres développeurs sur la liste &email-debian-devel;.  Le programme
+<prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
+utile. La commande <tt>apt-cache showpkg <var>package</var> </tt> vous
+indiquera, entre autres, les paquets qui dépendent de <var>package </var>.
+
+       <sect1>Supprimer des paquets dans <tt>Incoming</tt>
+<p>
+Par le passé, il était possible de supprimer un paquet de <tt>Incomming</tt>.
+Ce n'est plus possible depuis la mise en place du nouveau système
+de file d'attente. Il vous faudra télécharger une nouvelle version de votre
+paquet avec un numéro de version postérieur à celui que vous voulez remplacer.
+Les deux versions seront installées dans l'archive mais seule la plus récente
+sera accessible dans <em>unstable</em> car la précédente sera immédiatement
+replacée par la nouvelle. Toutefois, si vous testez correctement vos paquets,
+le besoin d'en remplacer un ne devrait pas être trop fréquent.
+
+
+
+       <sect>Remplacer ou renommer un paquet
+
+<p>
+Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de le
+renommer. Dans ce cas, vous devrez intervenir en deux étapes. D'abord,
+modifiez votre fichier <file>debian/control</file> pour que votre paquet
+renommé remplace et entre en conflit avec le nom de paquet que vous voulez
+remplacer. Reportez-vous au <url id="&url-debian-policy;" name="Debian Policy
+Manual"> pour les détails. Une fois que votre paquet est installé dans
+l'archive, faites un rapport de bogue concernant le pseudo-paquet
+<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
+l'archive, faites un rapport de bogue concernant le pseudo-paquet
+<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
+
+
+
+
+
+       <sect id="orphaning">Abandonner un paquet
+
+<p>
+Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres
+et faire le nécessaire pour qu'il soit marqué <em>abandonné</em>(i.e.
+<em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
+Group &orphan-address;</tt> dans le champ
+<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
+pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
+«&nbsp;<tt>O<footnote><em>Orphaned</em>&nbsp;: abandonné.</footnote>:
+<var>paquet</var> &mdash; <var>courte description</var></tt>&nbsp;» pour indiquer
+que le paquet est orphelin. La gravité du bogue sera <em>normale</em>.
+Si vous le jugez nécessaire, envoyez une copie à
+&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
+l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le
+sujet du message ne contiendra pas le numéro du bogue.
+
+<p>
+Si le paquet est particulièrement important pour la distribution il vous
+faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
+«&nbsp;<tt>RFA<footnote><em>Request For Adoption</em>&nbsp;: offre
+d'adoption.</footnote>: <var>paquet</var> &mdash; <var>courte
+description</var></tt>&nbsp;» et lui affecter la gravité <em>importante</em>.
+Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
+décrit précédemment.
+
+<p>
+Reportez-vous à la page WNPP<footnote><em>Work-needing and prospective
+packages</em>&nbsp;: paquets en souffrance et paquets souhaités.</footnote> <url
+id="&url-wnpp;"> pour en savoir plus.
+
+
+
+
+
+       <sect id="adopting">Adopter un paquet
+
+<p>
+Une liste des paquets en attente de nouveau responsable est disponible à la
+page <url id="&url-wnpp;" name="Work-Needing and Prospective Packages">. Si
+vous voulez prendre en charge un paquet de cette liste reportez-vous à la page
+susmentionnée pour connaître la procédure à suivre.
+
+<p>
+Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
+correct &mdash; ce serait une prise d'otage.  Vous pouvez prendre contact avec le
+responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.
+Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une
+raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable
+est parti sans prévenir depuis un moment, demandez-le sur la liste
+&email-debian-private;.
+
+<p>
+Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de
+suivi des bogues indique que vous êtes le responsable du paquet. Cela se
+produira automatiquement une fois que vous aurez installé une nouvelle version
+du paquet dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut
+prendre quelques heures après le téléchargement. Si vous pensez ne pas avoir
+de mise à jour à faire pour un moment, envoyez un courrier électronique à
+&email-override; pour pouvoir recevoir les rapports de bogue.
+
+
+
+
+
+       <chapt id="bug-handling">Gérer les bogues
+
+
+
+       <sect>Superviser les rapports de bogues
+
+<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.
+
+<p>
+Les responsables interagissent avec le système de suivi des bogues en
+utilisant l'adresse électronique <tt>bugs.debian.org</tt>. Vous trouverez une
+documentation sur les commandes disponibles à l'adresse <url id="&url-bts;">
+ou, si vous avez installé le paquet <package>doc-debian</package>, dans les
+fichiers locaux &file-bts-docs;.
+
+<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;:
+
+<p>
+<example>
+# Synthèse hebdomadaire des rapports de bogue qui me concernent
+&cron-bug-report;
+</example>
+
+<p>
+Remplacez <var>address</var> par votre adresse officielle de responsable
+Debian.
+
+
+
+
+       <sect id="submit-bug">Ouvrir un rapport de bogue
+
+<p>
+En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets
+En tant que responsable Debian, vous trouvez des bogues dans d'autres paquets,
+ou bien vous voulez réassigner à d'autres paquets des rapports de bogue 
+concernant vos paquets. La page d'aide du <url id="&url-bts-control;"
+name="système de suivi des bogues"> vous explique comment procéder.
+
+<p>
+Nous vous encourageons à ouvrir des rapports de bogue s'il y a des problèmes.
+Essayez de soumettre ces rapports depuis un compte utilisateur où vous pouvez
+recevoir du courrier. Ne les envoyez pas en tant que <em>root</em>.
+
+<p>
+Vérifiez que le bogue n'a pas encore été déclaré. Essayez de faire un travail
+propre en déclarant le bogue et en l'envoyant à la bonne adresse.
+
+<p>
+Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les
+bogues qui ont été rapportés plusieurs fois ou affecter la gravité
+<em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été
+corrigé.  Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le
+responsable du paquet vous ne devez pas clore le rapport (à moins que vous
+n'ayez l'autorisation du responsable).
+
+
+
+
+       <sect>Répondre à des rapports de bogues
+
+<p>
+Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au
+rapporteur du bogue et au bogue lui-même (<email>123@bugs.debian.org</email>
+par exemple).
+
+<p>
+Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la
+commande <em>close</em> à l'adresse&nbsp;:
+
+<p>
+<tt>   &email-bts-control;</tt>
+
+<p>
+Si vous le faites, le rapporteur n'aura aucun retour sur la clôture de son
+rapport.
+
+
+
+
+       <sect id="upload-bugfix">Quand les rapports sont fermés par une
+       mise à jour
+
+<p>
+Si vous corrigez un bogue dans vos paquets, il est de votre responsabilité de
+fermer le rapport de bogue associé. Pourtant vous ne devez pas le fermer avant
+que le paquet n'ait été accepté dans l'archive Debian.  C'est pourquoi, vous
+pouvez et vous devez clore le rapport dans le système de suivi des bogues une
+fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été
+installé dans l'archive.
+
+<p>
+Si vous utilisez une version récente de <package>dpkg-dev</package> et que
+vous remplissez convenablement le fichier <file>changelog</file>, le logiciel de
+maintenance de l'archive fermera les rapports de bogue automatiquement. Tout ce
+que vous avez à faire est de respecter la syntaxe suivante dans votre fichier
+<file>debian/changelog</file>&nbsp;:
+<example>
+acme-cannon (3.1415) unstable; urgency=low
+
+  * Frobbed with options (closes: Bug#98339)
+  * Added safety to prevent operator dismemberment, closes: bug#98765,
+    bug#98713, #98714.
+  * Added manpage. Closes: #98725.
+</example>
+
+Techniquement parlant, l'expression régulière suivante est utilisée :
+<example>
+  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
+</example>
+
+L'auteur préfère la syntaxe <tt>(closes: Bug#<var>XXX</var>)</tt>, car elle
+est facilement repérable dans le fichier <file>changelog</file>.
+
+<p>
+Si vous voulez fermer un rapport de bogue manuellement &mdash; à l'ancienne &mdash; il
+suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse
+<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
+bogue.
+
+
+
+
+       <sect id="lintian-reports">Les rapports Lintian
+
+<p>
+Vous devriez récupérer la dernière version de <package>lintian</package>
+depuis <em>unstable</em> régulièrement et vérifier tous vos paquets. Vous
+pouvez aussi chercher votre adresse électronique dans la page de <url
+id="&url-lintian;" name="rapport lintian">. Cette page, mise à jour
+automatiquement, contient les rapports lintian concernant la
+dernière version de la distribution (en général <em>unstable</em>) générés
+avec la dernière version de <package>lintian</package>.
+
+
+
+
+
+       <sect>Ouvrir un grand nombre de rapports d'un seul coup
+
+<p>
+Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
+paquet &mdash; plus de dix &mdash; est une pratique que nous déconseillons. Prenez
+toutes les mesures possibles pour éviter cette situation. Si le problème peut
+être détecté automatiquement par exemple, ajoutez un nouveau test dans le
+paquet <package>lintian</package> pour générer une erreur ou un avertissement.
+
+<p>
+Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
+d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
+d'autres développeurs la possibilité de vérifier que le problème existe
+vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
+les mêmes rapports de bogue simultanément.
+
+<p>
+Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
+les envoyer à <email>maintonly@bugs.debian.org</email> pour qu'ils ne soient
+pas redirigés vers les listes de diffusions.
+
+
+
+
+
+
+
+       <chapt id="tools">Aperçu des outils du responsable Debian
+
+<p>
+Cette section contient un aperçu rapide des outils dont dispose le
+responsable.  Cette liste n'est ni complète ni définitive, il s'agit juste
+d'un guide des outils les plus utilisés.
+
+<p>
+Les outils du responsable Debian sont destinés à améliorer le confort des
+responsables et libérer leur temps des tâches plus cruciales. Comme le dit
+Larry Wall, il y a plus d'une manière de le faire.
+
+<p>
+Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas.
+Debian n'a pas de position officielle sur la
+question&nbsp;; tout outil conviendra du moment qu'il fait le boulot. C'est pourquoi
+cette section n'a pas été conçue pour indiquer à chacun
+quel outil il devrait utiliser ou comment il devrait faire pour gérer sa
+charge de responsable Debian. Elle n'est pas non plus destinée à
+favoriser l'usage d'un outil aux dépens d'un autre.
+
+<p>
+La plupart des descriptions de ces outils proviennent des descriptions de
+leurs paquets. Vous trouverez plus d'information dans les
+documentations de ces paquets.
+Vous pouvez aussi obtenir plus d'information avec la commande <tt>apt-cache
+show <var>package_name</var></tt>.
+
+
+
+       <sect id="dpkg-dev">
+       <heading><package>dpkg-dev</package> 
+
+<p>
+Le paquet <package>dpkg-dev</package> contient les outils (y compris
+<prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des
+paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas
+niveau indispensables pour créer et manipuler les paquets&nbsp;; en tant que tels,
+ils sont indispensables à tout responsable Debian.
+
+
+
+
+       <sect id="lintian">
+       <heading><package>lintian</package> 
+
+<p>
+<package>lintian</package> dissèque les paquets pour y repérer des bogues et
+des manquements aux règles de développement. Il contient des tests automatisés pour
+vérifier de nombreuses règles et quelques erreurs courantes.  L'utilisation de
+<package>lintian</package> a déjà été discutée dans <ref id="upload-checking">
+et <ref id="lintian-reports">.
+
+       <sect id="debconf">
+       <heading><package>debconf</package></heading>
+
+<p>
+Le paquet <package>debconf</package> fournit une interface consistante pour
+configurer les paquets interactivement. Il est indépendant de l'interface et
+permet une configuration en mode texte, par une interface HTML ou par boîtes
+de dialogues. D'autres types d'interface peuvent être ajoutés sous forme
+de modules.
+
+<p>
+Vous trouverez la documentation de ce paquet dans le paquet
+<package>debconf-doc</package>.
+
+<p>
+Beaucoup pensent que ce système devrait être utilisé pour tout paquet
+nécessitant une configuration interactive. <package>debconf</package> n'est
+pas requis par le <em>Debian Policy Manual</em> pour le moment&nbsp;; cela
+pourra changer dans le futur.
+
+       
+       <sect id="debhelper">
+       <heading><package>debhelper</package> 
+
+<p>
+Le paquet <package>debhelper</package> regroupe un ensemble de programmes qui
+peuvent être utilisés dans <file>debian/rules</file> pour automatiser les
+tâches courantes relatives à la fabrication des paquets Debian binaires. Ce
+paquet contient des utilitaires pour installer différents fichiers, les
+compresser, ajuster leurs droits et intégrer votre paquet dans le
+système de menu Debian.
+
+<p>
+Au contraire d'autres approches, <package>debhelper</package> est
+divisé en plusieurs petits utilitaires qui agissent de manière cohérente.
+Ce découpage permet un contrôle des opérations plus fin que
+d'autres outils «&nbsp;<em>debian/rules</em>&nbsp;».
+
+<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>.
+
+
+
+       <sect id="debmake">
+       <heading><package>debmake</package> 
+
+<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>
+Le consensus actuel est que l'usage de <package>debmake</package> est
+déconseillé au profit de <package>debhelper</package> mais ce n'est pas une
+erreur d'utiliser <package>debmake</package>.
+
+
+
+       <sect id="yada">
+       <heading><package>yada</package> 
+
+<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>.
+
+<p>
+Remarque&nbsp;: <package>yada</package> est qualifié de «&nbsp;quasiment non
+maintenu&nbsp;» par son responsable, Charles Briscoe-Smith. Son usage est donc
+déconseillé.
+
+
+
+       <sect id="equivs">
+       <heading><package>equivs</package> 
+
+<p>
+<package>equivs</package> est un autre paquet pour faire des paquets. Il est
+souvent conseillé pour un usage local, si vous avez besoin de faire un paquet
+pour satisfaire des dépendances. Il est aussi parfois utilisé pour faire des
+«&nbsp;méta-paquets&nbsp;» qui sont des paquets dont l'unique objet est de
+dépendre d'autres paquets.
+
+
+
+       <sect id="cvs-buildpackage">
+       <heading><package>cvs-buildpackage</package> 
+
+<p>
+Le paquet <package>cvs-buildpackage</package> permet de mettre à jour ou
+récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
+un paquet Debian depuis le référentiel CVS et il assiste le développeur lors
+de l'intégration de modifications amont dans le référentiel.
+
+<p>
+Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS
+pour le responsable. Il permet de conserver des branches CVS distinctes
+pour les distributions <em>stable</em>, <em>unstable</em> et probablement
+<em>experimental</em>. 
+
+
+       <sect id="dupload">
+       <heading><package>dupload</package> 
+
+<p>
+Le paquet <package>dupload</package> contient un script du même nom pour
+mettre à jour des paquets dans l'archive Debian, tracer ces mises à jour et
+les annoncer par courrier électronique automatiquement. Vous pouvez le
+configurer pour faire des mises à jour à d'autres endroits et avec d'autres
+méthodes.
+
+
+       <sect id="dput">
+       <heading><package>dput</package>
+<p>
+Le script <package>dput</package> fait à peu près la même chose que
+<package>dupload</package> mais il le fait différemment. Il a aussi quelques
+fonctions supplémentaires telles que la possibilité de vérifier la signature
+GnuPG et les sommes de contrôles avant le téléchargement et la possibilité de
+démarrer <tt>dinstall</tt> en mode simulation (<em>dry-run</em>) après le
+téléchargement.
+
+       <sect id="fakeroot">
+       <heading><package>fakeroot</package> 
+
+<p>
+<package>fakeroot</package> simule les privilèges <em>root</em>. Cela permet
+de fabriquer un paquet sans être root (en général les paquets installent des
+fichiers appartenant à <em>root</em>). Si vous avez installé
+<package>fakeroot</package> vous pouvez construire un paquet en étant
+utilisateur&nbsp;: <tt>dpkg-buildpackage -rfakeroot</tt>.
+
+
+       <sect id="debootstrap">
+       <heading><package>debootstrap</package>
+
+<p>
+Le paquet <package>debootstrap</package> vous permet d'amorcer un système
+Debian de base à n'importe quel endroit dans votre système de fichier. Par
+«&nbsp;système de base&nbsp;» nous entendons le strict minimum nécéssaire pour
+fonctionner et installer le reste du système.
+
+<p>
+Avoir un système comme celui-ci peut vous servir de différentes manières. Vous
+pouvez par exemple déplacer votre racine dans ce système avec
+<prgn>chroot</prgn> pour tester vos dépendances de fabrication. Vous pouvez
+aussi l'utiliser pour voir comment se comporte votre paquet quand il est
+installé dans un environnement minimum.
+
+
+       <sect id="devscripts">
+       <heading><package>devscripts</package> 
+
+<p>
+Le paquet <package>devscripts</package> contient quelques scripts et outils
+que vous trouverez peut-être utiles pour maintenir vos paquets Debian. Parmi
+ces scripts, vous trouverez <prgn>debchange</prgn> et <prgn>dch</prgn> qui 
+manipulent votre fichier
+<file>debian/changelog</file> depuis la ligne de commande et
+<prgn>debuild</prgn> qui est construit au-dessus de
+<prgn>dpkg-buildpackage</prgn>.
+
+
+
+       <sect id="dpkg-dev-el">
+       <heading><package>dpkg-dev-el</package>
+
+<p>
+<package>dpkg-dev-el</package> fournit des macros Emacs lisp qui apportent une
+aide lors de l'édition des fichiers du répertoire <file>debian</file> de votre
+paquet. À l'édition de <file>debian/changelog</file>, par exemple, vous
+disposez de fonctions pour finaliser une version et consulter la liste des
+rapports de bogue ouverts.
+
+
+       <sect id="debget">
+       <heading><package>debget</package>
+
+<p>
+Le paquet <package>debget</package> contient un script qui peut être utile
+pour télécharger des paquets depuis l'archive Debian. Vous pouvez par exemple
+l'utiliser pour télécharger des paquets sources (bien que <tt>apt-get source
+<var>package</var></tt> fasse à peu près la même chose).
+
+
+
+<!-- FIXME: add the following
+  dpkg-awk
+  alien
+  dpkg-repack
+  grep-dctrl
+  pbuilder -->
+
+
+
 
-          Si plusieurs rapports de bogues sont fusionnés et que vous voulez les 
-          séparer en deux groupes séparés de rapports fusionnés, vous devez 
-          séparer chacun des rapports des nouveaux groupes séparément et alors 
-          seulement les fusionner dans les nouveaux groupes désirés.
-<p>
-
-          Vous ne pouvez séparer uniquement qu'un rapport de bogue des autres 
-          rapports de bogue fusionnés pour chaque commande « unmerge » ; si vous 
-          voulez séparer plus d'un rapport de bogue, ajoutez simplement quelques 
-          commandes « unmerge » à votre message.
-<p>
-</taglist>
-<p>
-
-<sect>Résumé des commandes disponibles
-<p>
-
-<sect1>Synopsis des commandes disponibles à « request@bugs.debian.org »
-<p>
-
-<list>
-<item><tt>send bugnumber</tt>
-<item><tt>send-detail bugnumber</tt>
-<item><tt>index [full]</tt>
-<item><tt>index-summary by-package</tt>
-<item><tt>index-summary by-number</tt>
-<item><tt>index-maint</tt>
-<item><tt>index maint maintainer-substring</tt>
-<item><tt>send-unmatched [this|0]</tt>
-<item><tt>send-unmatched last|-1</tt>
-<item><tt>send-unmatched old|-2</tt>
-<item><tt>getinfo filename</tt> (voir plus bas)
-<item><tt>help</tt>
-<item><tt>refcard</tt>
-<item><tt>quit|stop|thank...|--...</tt>
-<item><tt>#...</tt> _(comment)_
-<item><tt>debug level</tt>
-</list>
-<p>       
-<sect1>Liste des fichiers d'informations pour « getinfo »
-<p>
-<list
-<item><tt>maintainers</tt>
-<item><tt>override.stable</tt>
-<item><tt>override.development</tt>
-<item><tt>override.contrib</tt>
-<item><tt>override.non-free</tt>
-<item><tt>override.experimental</tt>
-<item><tt>override.codeword</tt>
-<item><tt>pseudo-packages.description</tt>
-<item><tt>pseudo-packages.maintainers</tt>
-</list>
-<p>       
-<sect1>Synopsis des commandes supplémentaires disponibles sur le serveur de 
-courriers de contrôle
-<p>
-<list>
-<item><tt>close bugnumber</tt> (vous devez expliquer séparément à l'auteur 
-pourquoi)
-<item><tt>reassign bugnumber package</tt>
-<item><tt>reopen bugnumber [originator-address|=]</tt>
-<item><tt>forwarded bugnumber address</tt>
-<item><tt>notforwarded bugnumber</tt>
-<item><tt>retitle bugnumber new-title</tt>
-<item><tt>merge bugnumber bugnumber ...</tt>
-<item><tt>unmerge bugnumber</tt>
-</list>
-<p>       
 
 
 </book>
+</debiandoc>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:2
+sgml-indent-data:nil
+sgml-parent-document:nil
+sgml-exposed-tags:nil
+sgml-declaration:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->
+<!-- vim:set tw=78:ts=8: -->