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