<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.34 $">
+ <!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.153">
+ <!entity cvs-en-rev "1.197">
-->
<!-- -->
]>
<debiandoc>
-<!--
- TODO:
- - bugs in upstream versions should be reported upstream!
- - add information on how to get accounts on different architectures
- - talk about CVS access, other ways to submit problems
- - add information on how you can contribute w/o being an official
- developer
- - "official port maintainer" ? (cf. glibc-pre2.1)
- -->
<book>
-
<title>Référence du développeur Debian
- <author>Adam Di Carlo, responsable actuel<email>aph@debian.org</email>
- <author>Raphaël Hertzog, co-responsable <email>hertzog@debian.org</email>
- <author>Christian Schwarz <email>schwarz@debian.org</email>
- <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
+
+ <author>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>
- <author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
- <author>et Frédéric Bothamy (traducteur actuel) <email>fbothamy@mail.dotcom.fr</email>
- <author>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
- <version>Version &version;, &date-fr; (version française 20021231).</version>
+ <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>
<copyright>
- <copyrightsummary>Copyright © 1998—2002 Adam Di Carlo</copyrightsummary>
+ <copyrightsummary>Copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>Copyright © 2002 Raphaël Hertzog</copyrightsummary>
<copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary>
<p>
<!-- FIXME: rewrites -->
<p>
-Les procédures décrites ci-après expliquent comment devenir
-responsable Debian (<ref id="new-maintainer">), comment installer des nouveaux
-paquets dans l'archive (<ref id="upload">), quand et comment faire un portage ou
-une mise à jour du paquet d'un autre responsable (<ref id="nmu">), comment
-déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">) et comment
-gérer les rapports de bogues (<ref id="bug-handling">).
+Les procédures décrites ci-après expliquent comment devenir responsable Debian
+(<ref id="new-maintainer">), comment créer de nouveaux paquets (<ref
+id="newpackage">) et comment les installer dans l'archive (<ref id="upload">),
+comment gérer les rapports de bogues (<ref id="bug-handling">), comment
+déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">), comment
+faire le portage d'un paquet (<ref id="porting">), quand et comment faire la
+mise à jour du paquet d'un autre responsable (<ref id="nmu">).
<p>
Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref
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...
+finlandais, français, espagnols, danois, etc.
<p>
En conséquence, la langue utilisée dans toutes les listes de diffusion destinées
-aux développeurs 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.
+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
les paquets sources des différentes distributions (<ref
id="pkg-tracking-system">).
- <item><em>Unstable</em> : Nom de la distribution en cours de
+ <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
+ <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 que
- <em>unstable</em> (<ref id="sec-dists">).
+ 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 dite stable. Cette
+ <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
+ 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
id="upstream-coordination">.)
<item><em>Upstream maintainer</em> : responsable amont ou
- développeur amont. Personne(s) responsable(s) du développement ou de la
+ 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">).
améliorations.
- <sect id="registering">Devenir responsable Debian
+ <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
cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite
- en aucun chiffrement. Si vous vivez dans un pays où l'utilisation de la
- cryptographie pour authentification est interdite, contactez-nous pour que nous
- prenions des dispositions particulières.
+ 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
<sect id="user-maint">Mise à jour de vos références Debian
<p>
-Il existe une base de données LDAP qui contient des informations concernant
-les développeurs ;
- vous pouvez y accéder à l'adresse <url id="&url-debian-db;">. Vous pouvez
- modifier votre mot de passe (ce mot de passe est diffusé sur la plupart des
- machines auxquelles vous avez accès), votre adresse, votre pays, la latitude et
- la longitude de l'endroit où vous résidez, vos numéros de téléphone et de fax,
- votre interpréteur de commande préféré, votre surnom IRC, votre page web, votre
- adresse de courrier électronique ainsi que l'alias que vous utilisez pour votre
- courrier électronique chez debian.org. La plupart de ces informations ne sont
- pas accessibles au public. Pour plus de détails au sujet de cette base de
- données, reportez-vous à sa documentation en ligne disponible à l'adresse <url
- id="&url-debian-db-doc;">.
-<p>
-Vous y tiendrez à jour les informations vous concernant.
+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 id="key-maint">Gérer votre clé publique
<p>
Vous pouvez trouver une présentation approfondie de la gestion de clé Debian
dans la documentation du paquet <package>debian-keyring</package>.
-
<sect id="voting">Voter
<p>
-Debian, sans être une vraie démocratie, dispose d'outils à
- caractère démocratique et utilise un procédé démocratique pour élire son chef
- ou pour approuver une résolution. Ces procédures sont décrites dans la <url
- id="&url-constitution;" name="Constitution Debian">.
+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>
-Un processus démocratique ne fonctionne bien que si tout le monde participe au
- vote, c'est pourquoi vous devez voter. Pour cela, vous devez vous inscrire à la
- liste &email-debian-devel-announce; car les annonces de votes sont publiées sur
- cette liste. Si vous voulez suivre les débats qui précèdent un vote,
- inscrivez-vous à liste &email-debian-vote;.
+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>
-La liste de toutes les propositions (passées et présentes) est disponible à la
- page <url id="&url-vote;" name="Informations sur les votes Debian">. Vous y
- trouverez aussi des informations complémentaires sur la procédure à suivre pour
- proposer un vote.
+Vous n'avez pas besoin de suivre les discussions précédant le vote car le
+secrétaire enverra plusieurs appels au vote sur la liste
+&email-debian-devel-announce; (et tous les développeurs devraient être inscrits
+à cette liste). La démocratie ne fonctionne pas si les personnes ne prennent pas
+part au vote, c'est pourquoi nous encourageons tous les développeurs à voter. Le
+vote est conduit par messages signés ou chiffrés par GPG.
+<p>
+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 id="inform-vacation">Prendre des vacances courtoisement
<p>
-La plupart des développeurs prennent des vacances ; généralement, cela
- signifie qu'ils ne peuvent ni travailler pour Debian, ni être joints par
- courrier électronique si un problème se présentait. Les autres développeurs ont
- besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment
- réagir en cas de problème. En général, cela signifie que les autres
- développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
- cas de gros problème (bogues empêchant l'intégration dans la distribution, mise à jour de
- sécurité, etc.) durant vos vacances.
-<p>
-Il y a deux choses à faire pour en informer les autres développeurs.
- Premièrement, envoyez un courrier électronique indiquant vos dates de vacances
- à &email-debian-private;, vous pouvez aussi donner quelques instructions pour
- indiquer comment agir si un problème survenait. Notez bien que certaines
- personnes ne sont pas intéressées par les annonces de vacances et ne veulent
- pas les lire ; veuillez ajouter '[VAC] ' à l'objet de votre courrier pour
- qu'il soit facilement filtré.
-<p>
-Deuxièmement, il faut mettre à jour la base de données Debian LDAP et vous
- signaler « en vacances »<footnote><p><em>on vacation</em> en
- anglais</footnote>(l'accès à cette information est réservé aux développeurs).
- N'oubliez pas de retirer votre indicateur « en vacances » lorsque
- celles-ci sont terminées !
+<!-- à 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 !
<sect id="upstream-coordination">Coordination avec les développeurs amonts
<p>
suivantes. Quels que soient les changements dont vous avez besoin, il faut
toujours essayer de rester dans la lignée des sources amonts.
- <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du paquet dans la distribution ?
+ <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
<em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
ayant un impact sur la présence du paquet dans la prochaine version stable de
Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
- et/ou peuvent justifier la suppression d'un paquet d'une distribution gelée.
- C'est pourquoi ces bogues ont besoin d'être corrigés au plus vite.
+ 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
<chapt id="resources">Ressources pour le responsable Debian
<p>
-Dans ce chapitre, vous trouverez une brève description des listes de diffusions,
+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.
Les archives des listes de diffusion sont consultables à <url
id="&url-lists-archives;">.
- <sect1 id="core-devel-mailing-lists">Principales listes pour les responsables
+ <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 :
<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>
+ charte Debian,</item>
<item>&email-debian-project;, utilisée pour discuter de questions non
techniques.</item>
</list>
<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 à
+Pour vous abonner ou vous désabonner de n'importe quelle liste, envoyez un
+ courrier électronique à
<tt>debian-<var>foo</var>-REQUEST@&lists-host;</tt>, où
- <tt>debian-<var>foo</var></tt> est le nom de la liste, avec le mot
- <tt>subscribe</tt> dans le champ <em>Objet</em><footnote><p><em>Subject</em>
- en anglais</footnote> pour vous abonner à la liste ou <tt>unsubscribe</tt>
- pour vous désabonner.
+ <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 à <url id="&url-debian-lists-txt;"> ou installer le paquet
+ 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;.
<p>
Lorsque vous répondez aux messages d'une liste de diffusion, n'envoyez pas de
copie (<tt>CC</tt>) à l'auteur du courrier à moins qu'il ne l'ait demandé
- explicitement. Quelqu'un qui envoie un message à une liste de diffusion se doit
+ 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é.
+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. Veuillez lire le <url id="&url-debian-lists;" name="code
- de conduite"> pour plus d'information.
+ d'envoi de messages.
+<p>
+Veuillez lire le <url id="&url-debian-lists;" name="code de conduite"> pour plus
+ d'informations.
<sect1 id="mailing-lists-special">Listes spéciales
<p>
telles que des échanges avec les auteurs amonts à propos de licences, de bogues
ou encore des discussions sur le projet avec d'autres personnes.
+
<sect id="irc-channels">Canaux IRC
<p>
Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
principalement hébergés sur le réseau <url id="&url-openprojects;"
name="freenode"> (anciennement connu sous le nom de Open Projects Network).
L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
- <tt>irc.openprojects.net</tt>.
+ <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
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é
+ 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>,
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/">.
<sect id="doc-rsrcs">Documentation
<p>
Ce document contient beaucoup d'informations très utiles aux développeurs
Debian, mais il ne peut pas tout contenir. La plupart des autres documents
- intéressants sont référencés dans <url id="&url-devel-docs;" name="le coin du
- développeur">. Prenez le temps de parcourir tous les liens, vous apprendrez
- encore beaucoup de choses.
+ 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.
<sect id="server-machines">Les serveurs Debian
<sect1 id="servers-bugs">Le serveur pour les rapports de bogues
<p>
-<tt>bugs.debian.org</tt> est le serveur maître du système de suivi des bogues
+<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
gaspillage de temps machine.
<p>
Tous les développeurs Debian ont un compte sur
- <tt>bugs.debian.org</tt>.
+ <tt>&bugs-host;</tt>.
<sect1 id="servers-ftp-master">Le serveur ftp-master
<p>
pour en savoir plus.
<p>
Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
- comme bogue sur le pseudo-paquet <package>ftp.debian.org</package> ou par
+ comme bogue
s 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.
<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 bogue sur le pseudo-paquet <package>nonus.debian.org</package>
- pseudo-package (remarquez l'absence de trait d'union entre "non" et "us" dans
- le nom du pseudo-paquet — c'est dû à la compatibilité descendante).
- Rappelez-vous de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de
- bogue concernant le problème sur le <url
- id="http://bugs.debian.org/nonus.debian.org" name="système de suivi des
- bogues">.
+ 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">.
<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 facade de Debian pour la plupart des débutants.
+ 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.debian.org/www.debian.org" name="système de suivi des bogues">
+ id="http://&bugs-host;/www.debian.org" name="système de suivi des bogues">
que personne ne l'a déjà rapporté avant vous.
<sect1 id="servers-people">Le serveur web people
<p>
-<tt>people.debian.org</tt> est le serveur utilisé pour les pages personnelles
- des développeurs concernant ce qui est lié à Debian.
+<tt>people.debian.org</tt> est le serveur utilisé par les développeurs pour
+leurs pages concernant Debian.
<p>
Si vous avez des informations spécifiques Debian que vous voulez rendre
disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
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'export
+ 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>
La base de données des développeurs à <url id="&url-debian-db;"> est un annuaire
LDAP de gestion des informations des développeurs Debian. Vous pouvez utiliser
- cette ressource pour rechercher la liste des développeurs Debian. Pour plus
- d'informations sur la façon de garder à jour vos informations dans la base des
- développeurs, reportez-vous à <ref id="user-maint">. Une partie de ces
- informations est également disponible à travers le service finger sur les
+ 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>
-La base de données vous permet d'enregistrer d'autres informations ; par
-exemple, des
- clés publiques SSH qui seront installées automatiquement sur les machines
- Debian officielles, ou des entrées DNS de type *debian.net. Ces fonctionnalités
- sont documentées à <url id="&url-debian-db-mail-gw;">.
-
-<!-- <sect id="servers-mirrors">Les miroirs des serveurs Debian
-<p>
-Les serveurs web et FTP Debian sont dupliqués sur d'autres serveurs.
- Évitez de charger les serveurs originaux. Idéalement, les serveurs originaux
- se contentent de copier leur contenu sur les miroirs de premier niveau et tous
- les utilisateurs consultent les miroirs. Ainsi le projet Debian étale ses
- besoins en bande passante sur plusieurs serveurs et plusieurs réseaux. Notez
- que la duplication des données sur les miroirs est déclenchée par le serveur
- maître. Ceci nous garantit que les miroirs sont aussi à jour que possible.
-<p>
-La liste des miroirs FTP/HTTP se trouve à l'adresse <url
- id="&url-debian-mirrors;">. Vous trouverez plus d'information sur les miroirs
- Debian à l'adresse <url id="&url-debian-mirroring;">. Cette page contient des
- informations et des outils qui pourront vous aider si vous avez l'intention de
- mettre en place votre propre miroir, que ce soit pour un usage interne ou pour
- un accès public.
-<p>
-Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider
- Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
- machines.
--->
+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;">.
+
+<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;">.
+
<sect id="archive">L'archive Debian
<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).
+ <file>disk-m68k/</file>, etc.).
<sect1>Les sections
<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
+ 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
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 coté, un distributeur de cédérom pourra facilement vérifier
+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
- ajouter tous les paquets qu'il pourra ajouter (dans
+ 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.
<sect1>Les architectures
<p>
Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
- reconnaît ces architectures, Debian a décidé qu'elle devait également les
+ 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. À coté d'<em>i386</em> (notre nom
- pour Intel x86), nous avons, au moment où j'écris <em>m68k</em>,
+ 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>
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).
-
+ concernant le paquet (responsable, version, etc.).
<sect1>Les répertoires des distributions
<p>
<p>
Une distribution est composée de paquets sources et binaires et des
fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
- contiennent toutes les meta-informations sur les paquets. Les premiers sont
+ 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).
-
<sect2 id="sec-dists"><em>Stable</em>, <em>testing</em> et
<em>unstable</em>
<p>
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 de
- <em>unstable</em> s'ils satisfont à certains critères. Ces critères
- garantissent que les paquets de <em>testing</em> sont de bonne qualité. La mise
- à jour de <em>testing</em> est lancée chaque jour après que les nouveaux
- paquets ont été installés.
+<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 de <em>unstable</em> à <em>testing</em> sont
+ à 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 »
Notez que, pendant la période de gel, les développements continuent sur la
distribution <em>unstable</em> car cette distribution reste en place.
- <sect2><em>Experimental</em>
+ <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
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
accès aux testeurs.
<p>
Quelques logiciels expérimentaux peuvent cependant aller dans <em>unstable</em>,
- avec un avertissement dans la description mais ce n'est pas recommandé car
- les paquets de <em>unstable</em> se propagent dans <em>testing</em> et
+ 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
Une alternative à <em>experimental</em> consiste à utiliser vos pages
personnelles sur le serveur <tt>people.debian.org</tt>.
-
<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
+ 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 de <em>unstable</em> à <em>testing</em> quand ils approchent
+ 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
« 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 coté, si une distribution s'appelait <em>Debian-x.y</em> dès le
+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.)
+ version 1.1 et non la 1.0).
<p>
En conséquence, les noms de répertoire des distributions dans l'archive sont
- déterminés par leurs noms de code et non par leur statut (exemple :
+ 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
<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
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
+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
FTP/HTTP. Cette page utile inclut également des informations et des outils pour
créer son propre miroir, soit en interne soit pour un accès public.
<p>
-Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider
+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.
+
<sect id="incoming-system">
<heading>Le système Incoming
<p>
<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
<sect1 id="delayed-incoming">Incoming différé
<p>
Le répertoire <file>unchecked</file> comprend un sous-répertoire spécial,
- <file>DELAYED</file>. Celui-ci est lui-même subdivisé en neuf répertoires
- nommés <file>1-day</file> à <file>9-day</file>. Les paquets qui sont envoyés
- dans l'un de ces répertoires seront déplacés dans le vrai répertoire
- <file>unchecked</file> après le nombre correspondant de jours. Ceci est fait
- par un script qui est exécuté chaque jour et qui déplace les paquets entre les
- répertoires. Ceux qui sont dans « 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 cette fonctionnalité de délai peut être simplifiée en
+ <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 :
utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi :
<example>DELAY=5 dupload --to delayed <changes-file></example>
+
<sect id="testing">
<heading>La distribution « testing »
<p>
chaque jour après l'installation des paquets mis à jour. Ils génèrent les
fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
le font d'une manière intelligente pour éviter toute incohérence et essayer de
- n'utiliser que des paquets sans bogues.
+ n'utiliser que des paquets sans bogue.
<p>
-L'inclusion d'un paquet de <em>unstable</em> est soumise aux
+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
critères).</item>
</list>
<p>
-Les scripts génèrent certains fichiers pour expliquer
- pourquoi certains paquets sont maintenus hors de <em>testing</em>. Ils sont
- disponibles à <url id="&url-testing-maint;">. Sinon, il est possible
- d'utiliser le programme <prgn>grep-excuses</prgn> inclus dans le paquet
- <package>devscripts</package>. Il peut facilement être mis dans la <manref
- section="5" name="crontab"> pour rester informé de la progression de ses
- paquets dans <em>testing</em>.
+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="vue d'ensemble de testing"> donne plus
+ 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.
+
<sect id="pkg-info">Informations sur un paquet
<p>
-
<sect1 id="pkg-info-web">Sur le web
<p>
Chaque paquet a plusieurs pages web dédiées.
l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart
des architectures.
- <sect id="pkg-tracking-system">Le système de suivi des paquets
+
+ <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>
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
- recevez les mêmes courriers que le responsable. Chaque courrier envoyé par le
+ 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>
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>.
+
</taglist>
<sect1 id="pts-commands">L'interface de courrier du PTS
<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é si le
+ <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
<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 à
- <email>control@bugs.debian.org</email>
+ &bugs-host;&email-bts-control;
<item><tt>summary</tt> : courriers de résumé automatique sur l'état
- d'un paquet
+ 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
<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")
+ pas automatiques)
</list>
<tag><tt>keyword <srcpackage> [<email>]</tt>
Seules les personnes qui ont accepté le mot-clé <em>cvs</em> recevront les
notifications.
+
<sect id="ddpo">Vue d'ensemble des paquets d'un développeur
<p>
Un portail web pour l'Assurance Qualité (QA) est disponible à <url
Ce chapitre contient des informations relatives à la création, l'envoi, la
maintenance et le portage des paquets.
- <sect id="upload">La mise à jour d'un paquet
- <sect1>Nouveaux paquets
+
+ <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
nouveautés du projet.
</list>
- <sect1 id="changelog-entries">
- <heading>Ajouter une entrée à <file>debian/changelog</file></heading>
+
+ <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 pourquoi (si ce n'est pas
- clair) et indiquer si des rapports de bogue ont été clos. Il faut aussi indiquer
- quand le paquet a été terminé. Ce fichier sera installé dans
+ 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="upload-dist">. Vous trouverez plus d'informations sur la structure de ce
+ 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>
utilisées pour fermer des rapports de bogue au moment où le paquet est
installé dans l'archive. Voir la section <ref id="upload-bugfix">.
<p>
-Par convention, l'entrée changelog d'un paquet qui contient une nouvelle version
+Par convention, l'entrée changelog d'un paquet contenant une nouvelle version
amont ressemble à :
<example>
* new upstream version
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">.
-
- <sect1 id="upload-checking">Vérifier le paquet avant de l'envoyer
+ <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
l'archive.
<p>
Pour en savoir plus sur <prgn>lintian</prgn>, reportez-vous à la section
- lintian <ref id="lintian">.
+ <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>.
</list>
- <sect1>Générer le fichier « changes »
+<sect id="sourcelayout">Disposition du paquet source
<p>
-Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
- être accompagnée d'un fichier <file>.changes</file>. Ce fichier explique à
- l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
- général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
- fabrication du paquet.
+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>
-Le fichier <file>changes</file> est un fichier de contrôle qui contient les
- champs suivants :
+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>
-&control-file-fields;
-<p>
-Tous ces champs sont obligatoires pour une installation sur les serveurs Debian.
- Vous pouvez consulter la liste des champs de contrôle dans la <url
- id="&url-debian-policy;" name="charte Debian"> pour connaître les valeurs que
- prennent ces champs. Vous pouvez fermer un rapport de bogue automatiquement
- avec le champ <tt>Description</tt> (voir <ref id="upload-bugfix">).
-
+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.
- <sect2>L'archive des sources amonts
<p>
La première fois qu'un paquet est installé dans l'archive pour une version amont
donnée, le fichier <file>tar</file> de cette version amont doit être
un fichier <tt>tar</tt> identique à l'octet près à celui déjà présent dans
l'archive.
-
- <sect2 id="upload-dist">Choisir une distribution
+ <sect1 id="distribution">Choisir une distribution
<p>
-Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
- <file>debian/changelog</file>, indique à quelle distribution le paquet est
- destiné.
+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 ». En fait, il y a deux autres possibilités :
- « stable-security » et « testing-security ». Cependant,
- ces dernières sont utilisées par l'équipe de sécurité ; n'envoyez pas
- de paquets dedans sans l'accord de celle-ci.
+ « 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
distributions. En particulier, il est absurde de combiner la distribution
<em>experimental</em> avec tout autre chose.
-
- <sect3 id="upload-stable">Mettre à jour un paquet de la distribution
+ <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
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étro-portage<footnote><em>backport</em></footnote> du correctif).
+ 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
décrivez, dans le fichier changelog, vos changements pour une livraison
vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
- <sect3 id="upload-t-p-u">Mettre à jour un paquet de la distribution
+ <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
fournir des paquets corrigés durant le gel.
<p>
Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement,
- ils doivent passer entre les mains du responsable de version. Vous devez
+ 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 version, vous
+ 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>
<em>unstable</em>), vous pouvez l'utiliser, mais il est recommandé de
demander l'autorisation du responsable de distribution auparavant.
- <sect1 id="uploading">Mettre à jour un paquet
- <sect2 id="upload-ftp-master">Installer un paquet sur
+ <sect id="upload">Mettre à jour un paquet
+
+ <sect1 id="upload-ftp-master">Installer un paquet sur
<tt>ftp-master</tt>
<p>
Pour installer un paquet, vous avez besoin d'un compte sur
<p>
Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
travail lors du téléchargement. Ces programmes, bien pratiques, aident à
- automatiser le processus d'envoi de paquet vers Debian
+ 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>.
+<example>dinstall -n foo.changes</example>
+<p>
Notez que <prgn>dput</prgn> peut le faire automatiquement pour vous.
- <sect2 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
+ <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
américains de consulter un juriste avant de livrer un paquet sur
<tt>non-US</tt>.
-
- <sect2>Installer un paquet via <tt>chiark</tt>
+ <sect1>Installer un paquet via <tt>chiark</tt>
<p>
Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
possibilités. L'une d'elles consiste à télécharger vos fichiers dans
<tt>chiark</tt> ; consultez la documentation de ce programme pour en
savoir plus.
-
- <sect2>Installer un paquet via <tt>erlangen</tt>
+ <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;">.
<tt>erlangen</tt> ; consultez la documentation de ce programme pour en
savoir plus.
-
- <sect2>Les autres serveurs
+ <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
Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
anonyme sur <url id="&url-upload-jp;">.
-
-
- <sect1 id="upload-announce">Annoncer une mise à jour
-<p>
-Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
- listes « debian-changes ». Ceci est maintenant géré automatiquement
- par le logiciel de gestion de l'archive quand il est exécuté (en principe, une
- fois par jour). Vous devez juste utiliser une version récente de
- <package>dpkg-dev</package> (>= 1.4.1.2). Le courrier généré par le logiciel
- de maintenance de l'archive contiendra le fichier <file>.changes</file> signé
- que vous avez livré avec votre paquet. Précédemment, cette charge revenait à
- <prgn>dupload</prgn> ; vérifiez que vous avez bien configuré
- <prgn>dupload</prgn> pour qu'il n'envoie pas ces annonces (cherchez
- <tt>dinstall_runs</tt> dans la documentation de <prgn>dupload</prgn>).
-<p>
-Si un paquet est mis à jour avec un champ <tt>Distribution:</tt> à
- <em>stable</em>, l'annonce est envoyée sur la liste &email-debian-changes;.
- S'il est mis à jour avec un champ <tt>Distribution:</tt> à <em>unstable</em> ou
- <em>experimental</em>, l'annonce est envoyée sur la liste
- &email-debian-devel-changes;.
-
<sect1 id="upload-notification">
<heading>Notification de l'installation d'un nouveau paquet</heading>
<p>
installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier
qui vous informera de cette différence (voir ci-dessous).
- <sect2 id="override-file">Le fichier <em>override</em>
+
+ <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
vous amènent à demander ces changements.
<p>
Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref
- section="8" name="dpkg-scanpackages"> et
- <url id="&url-bts-devel;#maintincorrect">.
+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">.
- <sect id="nmu">Mise à jour indépendante
+ <sect id="bug-handling">Gérer les bogues
<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 ».
+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>
-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.
+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>
-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.
+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">.
- <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é.
+ <sect1 id="bug-monitoring">Superviser les rapports de bogue
<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.
+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 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 ?
+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>
-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.
-
+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.
- <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">.
+ <sect1 id="bug-answering">Répondre à des rapports de bogue
<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 :
+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>
-<list>
-<item>Vérifiez que les bogues du paquet qui devraient être corrigés par la
- mise à jour indépendante sont bien référencés dans le système de suivi des
- bogues. S'ils n'y sont pas, faites des rapports de bogue
- immédiatement.
-<item>Attendez la réponse du responsable quelques jours. Si vous n'obtenez
- aucune réponse, vous pouvez l'aider en lui envoyant le correctif qui
- corrige le bogue. N'oubliez pas de marquer le bogue avec le mot-clé
- « 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="upload-checking">). Re-vérifiez que votre correctif
- n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est
- aussi minimaliste et non intrusif que possible.
-<item>Envoyez votre paquet à incoming dans <file>DELAYED/7-day</file> (cf.
- <ref id="delayed-incoming">), envoyez le correctif final au responsable
- par le BTS et expliquez-lui qu'il a 7 jours pour réagir s'il veut annuler
- la NMU.
-<item>Suivez ce qui se passe, vous êtes responsable pour tout bogue que vous
- auriez introduit avec votre NMU. Vous devriez probablement utiliser le
- <ref id="pkg-tracking-system"> (PTS) pour vous tenir informé de l'état du
- paquet après votre NMU.
-</list>
+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>
-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.
+Vous ne devez <em>jamais</em> fermer un rapport de bogue en envoyant la commande
+ <tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
+ n'aura aucune information sur la clôture de son rapport.
- <sect1 id="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">.
+ <sect1 id="bug-housekeeping">Gestion générale des bogues
<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
+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>
-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.
+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>
-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 ».
-
+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>
- <sect2 id="nmu-changelog">
- <heading>Les mises à jour indépendantes sources doivent être
- mentionnées dans le fichier changelog</heading>
+ <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
+ une mise à jour ?
<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.
+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>
-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
+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>
- * Non-maintainer upload
+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 :
- <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.
+<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 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.
+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>
-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.
+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>
-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>.
+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">.
-
- <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
-<p>
-Les paquets faisant l'objet d'une mise à jour indépendante source sont
- construits comme les autres. Sélectionnez une distribution en utilisant les
- règles décrites dans la section <ref id="upload-dist"> et construisez un
- fichier <tt>.changes</tt> classique avec tout ce qui l'accompagne
- conformément à la description <ref id="uploading">. En fait, toutes les
- prescriptions de la section <ref id="upload"> sont applicables ici.
+ <sect1 id="bug-security">Gérer les bogues de sécurité
<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>.
+À 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.
- <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.
+ <sect2 id="bug-security-you">Que faire si vous apprenez l'existence d'un
+ problème de sécurité ?
<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">).
+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>
- <sect id="porting">Le portage
+ <sect2 id="bug-security-confidentiality">Confidentialité
<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.
+À 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>
-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.
+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>
- <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>. Dans cet environnement
- <em>chrooté</em> il faudra installer le paquet
- <package>build-essential</package> et tous les paquets mentionnés dans
- les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
- Ensuite, vous essayerez de fabriquer votre paquet dans cet
- environnement. Ces étapes peuvent être automatisées en utilisant le
- programme <prgn>pbuilder</prgn> qui est fourni par le paquet de même
- nom.
- <p>
- Consultez la <url id="&url-debian-policy;" name="charte Debian"> pour en
- savoir plus sur les dépendances de fabrication.
- </item>
- <item>
- Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
- le champ architecture sans avoir de bonnes raisons pour le faire. Trop
- souvent, les développeurs ne respectent pas les instructions de la <url
- id="&url-debian-policy;" name="charte Debian">. Choisir la valeur
- « 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 <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 ».
+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>
- <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.
-
+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).
- <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>
+<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>.
- <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>
+<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>
- <heading>Outils pour les porteurs</heading>
+ <sect2 id="bug-security-advisories">Annonces de sécurité
<p>
-Les descriptions de plusieurs outils de portage peuvent être trouvés dans les
-<ref id="tools-porting">.</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="buildd">
- <heading><package>buildd</package></heading>
+ <sect2 id="bug-security-building">
+ <heading>Préparer les paquets pour corriger des problèmes de sécurité
<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.
+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>
-<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>.
+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>
-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).
+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>
-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="collaborative-maint">
- Maintenance collaborative
+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>
-« Maintenance collaborative » 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.
+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>
-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.
+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>
-Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
- simple :
+Lors de la construction de la correction, gardez les points suivants à
+l'esprit :
+
<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>
+ 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><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>
+ 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><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>
+ 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 de nom, adopter et abandonner des paquets
+ <heading>Déplacer, effacer, changer le nom, adopter et abandonner des paquets
<p>
-Certaines manipulations de l'archive ne sont pas accessibles avec le processus
+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.
téléchargez à nouveau votre paquet dans l'archive. Reportez-vous à la <url
id="&url-debian-policy;" name="charte Debian"> pour en savoir plus. Si votre
nouvelle section est valide, il sera déplacé automatiquement. Si ce n'est pas
- le cas, contactez les ftpmasters pour comprendre ce qui s'est passé.
+ 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
rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
demander sa suppression. N'oubliez pas de préciser de quelle distribution le
paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
- des paquets de <em>unstable</em> ou de <em>experimental</em>. Les paquets de
+ 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é de <em>unstable</em> et
+ 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
<sect1>Remplacer un paquet ou changer son nom
<p>
-Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de
- changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
+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
+ (reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
les détails). Une fois que votre paquet est installé dans l'archive, faites un
rapport de bogue concernant le pseudo-paquet <tt>ftp.debian.org</tt> et
- demandant la suppression du paquet mal nommé. N'oubliez pas de réattribuer
+ 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
- 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
+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 garantit la consistance dans le réseau des
- miroirs.
+ 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>
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. Vous ne pouvez le faire sans son accord. Qu'il vous ignore
- n'est pas une raison suffisante pour le faire. Si vous avez le sentiment qu'un
- responsable est parti sans prévenir depuis un moment, demandez-le sur la liste
- &email-debian-private;. Vous pouvez également informer le groupe QA (cf. <ref
- id="mia-qa">).
+ 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 <ref
- id="pkg-tracking-system"> pour recevoir les rapports de bogue. Cependant,
- assurez-vous que cela ne pose aucun problème à l'ancien responsable de
- continuer à recevoir les bogues durant ce temps.
-
-
- <sect id="bug-handling">Gérer les bogues
-<p>
-Vous trouverez souvent, en tant que responsable de paquet, des bogues dans
- d'autres paquets ou vous aurez des bogues rapportés sur vos paquets et qui
- doivent être réattribués. Les <url id="&url-bts-control;" name="instructions du
- BTS"> peuvent vous indiquer comment faire cela. Vous pouvez trouver plus
- d'informations sur la façon de faire des rapports de bogue dans <ref
- id="submit-bug">.
-
- <sect1>Superviser les rapports de bogue
-<p>
-Si vous voulez être un bon responsable, consultez régulièrement la page du <url
- id="&url-bts;" name="système de suivi des bogues">. Cette page contient tous
- les rapports de bogue qui concernent vos paquets. Vous pouvez les vérifier avec
- cette page : <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.
-
- <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.debian.org</email>
- par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
- plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
- <email>123-submitter@bugs.debian.org</email> pour contacter le rapporteur
- <em>et</em> enregistrer votre courrier dans le journal du bogue (ce qui veut
- dire que vous n'avez pas besoin d'envoyer une copie du courrier à
- <email>123@bugs.debian.org</email>).
+ 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>
-Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
- corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
- d'explication à <email>123-done@bugs.debian.org</email>. Si vous corrigez un
- bogue en changeant et en envoyant une nouvelle versions du paquet, vous pouvez
- fermer le bogue automatiquement comme décrit dans <ref id="upload-bugfix">.
+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>
-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.
+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="bug-housekeeping">Gestion générale des bogues
+
+ <sect1 id="kind-to-porters">Être gentil avec les porteurs
<p>
-En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
- d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
- bogues sur d'autres paquets. Les fonctions intéressantes du système de suivi
- des bogues pour les développeurs sont décrites dans la <url
- id="&url-bts-devel;" name="documentation du BTS pour les développeurs Debian">.
- Les <url id="&url-bts-control;" name="instructions du BTS"> documentent les
- opérations techniques du BTS, telles que comment remplir, réassigner, regrouper
- et marquer des bogues. Cette section contient des lignes directrices pour gérer
- vos propres bogues, définies à partir de l'expérience collective des
- développeurs Debian.
+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>
-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.
+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>
-Voici une liste des étapes que vous pouvez suivre pour gérer un rapport de
- bogue :
+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>
- 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.
+ 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 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">.
+ 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>
- Si le rapport de bogue est réel, mais est causé par un autre paquet,
- réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
- quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
- &email-debian-devel; ou vous pouvez le réattribuer à
- <package>debian-policy</package> pour les laisser décider dans quel
- paquet est située l'erreur.
- <p>
- Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
- corresponde à notre définition de gravité des bogues. C'est dû au
- fait que les gens tendent à augmenter la gravité des bogues pour
- s'assurer que leurs bogues seront corrigés rapidement. La gravité de
- certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
- quand le changement demandé est seulement d'ordre cosmétique.
+ 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>
- Le rapporteur de bogue peut avoir oublié de fournir certaines
- informations. Dans ce cas, vous devez lui demander les informations
- nécessaires. Vous pouvez utiliser la marque <tt>moreinfo</tt> (plus
- d'info) sur le bogue. De plus, si vous ne pouvez pas reproduire le
- bogue, vous pouvez le marquer comme <tt>unreproducible</tt> (non
- reproductible). Une personne qui arriverait à reproduire le bogue est
- alors invitée à fournir plus d'informations sur la façon de le
- reproduire. Après quelques mois, si cette information n'a été envoyée
- par personne, le bogue peut être fermé.
+ 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>
- Si le bogue est lié à l'empaquètement, vous devez simplement le
- corriger. Si vous ne pouvez pas le corriger vous-même, marquez alors le
- bogue avec <tt>help</tt> (aide). Vous pouvez également demander de
- l'aide sur &email-debian-devel; ou &email-debian-qa;. S'il s'agit d'un
- problème amont, vous devez faire suivre le rapport à l'auteur amont.
- Faire suivre un bogue n'est pas suffisant, vous devez vérifier à chaque
- version si le bogue a été corrigé ou non. S'il a été corrigé, vous le
- fermez simplement, sinon vous devez le rappeler à l'auteur. Si vous avez
- les compétences nécessaires, vous pouvez préparer un correctif pour
- corriger le bogue et l'envoyer en même temps à l'auteur. Assurez-vous
- d'envoyer le correctif au BTS et marquez le bogue avec <tt>patch</tt>
- (correctif).
+ 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>
- 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.
+ 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>
- 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">.
+ 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="bug-security">Gérer les bogues de sécurité
+
+ <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>
-À 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.
+Les descriptions de plusieurs outils de portage peuvent être trouvées dans les
+<ref id="tools-porting">.</p>
- <sect2 id="bug-security-you">Que faire si vous apprenez l'existence d'un
- problème de sécurité ?
+
+ <sect2 id="buildd">
+ <heading><package>buildd</package></heading>
<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 :
+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>
- <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>
+ <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.
- <sect2 id="bug-security-confidentiality">Confidentialité
+ <sect1 id="nmu-terms">Terminologie
<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.
+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>
-Il existe plusieurs façons pour un développeur de prendre connaissance d'un
-problème de sécurité :
+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.
-<list compact>
- <item>
- il le remarque sur un forum publique (liste de diffusion, site web, etc.),
- </item>
- <item>
- quelqu'un remplit un rapport de bogue,
- </item>
- <item>
- quelqu'un l'informe par courrier privé.
- </item>
-</list>
-Dans les deux premiers cas, l'information est publique et il est important
-d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce
-n'est peut-être pas une information publique. Dans ce cas, il existe quelques
-options possibles pour traiter le problème :
+ <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>
- 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>
+<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>
+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>
-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).
+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 ».
+
-<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>.
+ <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 :
-<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.
+<example>
+ * Non-maintainer upload
+</example>
- <sect2 id="bug-security-advisories">Annonces de sécurité
-<p>
-Les annonces de sécurité ne sont émises que pour la distribution actuelle
- diffusée <em>stable</em>, pas pour <em>testing</em> ou <em>unstable</em>.
- Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
- &email-debian-security-announce; et elle est postée sur <url
- id="&url-debian-security-advisories;" name="la page de sécurité">. Les
- annonces de sécurité sont écrites et postées par l'équipe de sécurité.
- Cependant, ils ne verront aucun inconvénient à ce qu'un responsable leur
- apporte des informations ou écrive une partie du texte. Les informations qui
- devraient être présentes dans une annonce incluent :
-<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'assister l'équipe de sécurité dans ses travaux est de fournir des
- paquets corrigés convenables pour une annonce de sécurité pour la version
- <em>stable</em> de Debian
+ <sect2 id="nmu-patch">Mise à jour indépendante source et système de
+ suivi des bogues
<p>
-Quand une mise à jour de la version <em>stable</em> est effectuée, un soin
- particulier doit être apporté pour éviter de modifier le comportement du
- système ou d'introduire de nouveaux bogues. Pour cela, faites le moins de
- changements possibles pour corriger le bogue. Les utilisateurs et les
- administrateurs s'attendent à un comportement identique dans une version
- lorsque celle-ci est effectuée, donc tout changement qui est fait est
- susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
- les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
- quelque minimal que soit le changement.
+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>
-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.
+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>
-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.
+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>
-Il existe une autre règle de conduite liée à cela : testez toujours vos
-changements. Si une exploitation du problème existe, essayez-là et
-vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
-corrigé. Testez aussi les autres actions normales car parfois un correctif de
-sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
-liées.
+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>
-Examinez et testez autant que possible vos changements. Vérifiez les différences
-avec la version précédente de manière répétée (<prgn>interdiff</prgn> et
-<prgn>debdiff</prgn> sont des outils utiles pour cela). Lors de la construction
-de la correction, gardez les points suivants à l'esprit :
+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>.
-<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é
+ <sect2 id="nmu-build">Fabriquer une mise à jour indépendante source
<p>
-Vous <em>NE DEVEZ PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
-sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
-exactement les impératifs de l'équipe, il causera beaucoup de problèmes, ainsi
-que des délais dans la gestion de l'envoi indésirable.
+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>
-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.
+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>
-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>.
+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">).
-<p>
-Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
-automatiquement recompilé pour toutes les architectures et stocké pour
-vérification par l'équipe de sécurité.
-<p>
-Les envois en attente d'acceptation ou de vérification ne sont accessibles que
-par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
-correctifs pour des problèmes de sécurités qui ne peuvent pas encore être
-diffusés.
+ <sect id="collaborative-maint">
+ <heading>Maintenance collective</heading>
<p>
-Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur
-security.debian.org ainsi que dans le répertoire
-<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
-l'archive non-US.
-
- <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
- une mise à jour ?
+« 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>
-Si vous corrigez un bogue 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.
+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>
-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 régulière suivante Perl est utilisée :
-
+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>
- /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
+Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
</example>
-
-L'auteur préfère la syntaxe <tt>closes: #<var>XXX</var></tt>, car c'est l'une
-des plus concises et des plus faciles à intégrer dans le texte du fichier
-<file>changelog</file>.
-<p>
-Si vous entrez un numéro de bogue incorrect ou si vous en oubliez un dans le
- fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage que
- l'erreur a entrainé. Pour réouvrir un bogue fermé par erreur, envoyez une
- commande <tt>reopen <var>XXX</var></tt> au robot de contrôle du système de
- suivi des bogues. Pour fermer tous les bogues restants qui ont été corrigés par
- votre envoi, envoyez le fichier <file>.changes</file> à
- <email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
- bogue.
-<p>
-Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant le
- <file>changelog</file> tel que décrit ci-dessus — si vous désirez
- simplement fermer les bogues qui n'ont rien à voir avec l'un de vos envois,
- faites-le simplement en envoyant une explication à
- <email>XXX-done@bugs.debian.org</email>.
+</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
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
+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,
d'aide quand ils sont utiles, en complément de commandes définies manuellement
dans le fichier <file>debian/rules</file>.
<p>
-Vous pouvez débuter avec <package>debhelper</package> par lire <manref
+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
+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.
qui vous convient. Plusieurs exemples de fichiers <file>debian/rules</file> sont
disponibles à <url id="&url-rules-files;">.
-<!-- Pour vous aider dans votre effort d'empaquètement, vous pouvez
- utiliser les scripts d'aide. Les meilleurs scripts disponibles sont fournis
- par <package>debhelper</package>. Avec <prgn>dh_make</prgn> (paquet
- <package>dh-make</package>), vous pouvez générer en quelques secondes un
- paquet qui est presque prêt. Cependant, cette apparente simplicité cache un
- grand nombre de choses faites par les scripts d'aide. Vous devez savoir ce
- qu'ils font, c'est pourquoi vous êtes fortement encouragé à lire les pages de
- manuel correspondantes, en commençant par <manref section="1" name="debhelper">. C'est
- nécessaire parce que vous devez comprendre ce qui se passe pour être capable
- de les utiliser sagement et pour pouvoir corriger des bogues de manière
- élégante.
-<p>
-debhelper est très utile car il vous permet de suivre la plus récente
- charte Debian sans faire beaucoup de modifications car les changements qui
- peuvent être automatisés sont presque toujours faits automatiquement par un
- script debhelper. De plus, il offre suffisamment de flexibilité pour que vous
- soyez capable de l'utiliser en conjonction avec des invocations de shell
- écrites à la main à l'intérieur du fichier <file>rules</file>.
-<p>
-Vous pouvez cependant décider de ne pas utiliser de script d'aide et
- tout de même écrire d'excellents fichiers <file>rules</file>. Plusieurs
- exemples sont disponibles à <url id="&url-rules-files;">.
-
- -->
<sect1 id="multiple-patches">
- <heading>Appliquer des correctifs sur les sources ou appliquer des
- correctifs lors de la construction ?</heading>
-<p>
-Les gros paquets peuvent avoir plusieurs bogues que vous devez corriger.
- Si vous corrigez sans faire attention les bogues dans les
-sources,
- vous ne pourrez pas différencier facilement les
- nombreux correctifs que vous aurez appliqués. Cela peut devenir trés
-compliqué de mettre à jour le paquet avec une nouvelle version amont qui
- intègre certains correctifs (mais pas tous). Vous ne pouvez pas prendre
- l'ensemble des correctifs (par exemple, dans les fichiers <file>.diff.gz</file>) et
- décider quels correctifs il vous faut enlever parceque les bogues ont été
- corrigés en amont.
-<p>
-Une bonne solution est de conserver des correctifs séparés sous le répertoire
- <file>debian</file> et de les appliquer lors de la compilation. Le paquet
- <package>dbs</package> fournit un moyen pratique pour appliquer ces correctifs
- lors de la compilation (et de les enlever lors du nettoyage). Le paquet
- <package>dbs</package> fournit également des facilités pour créer des
- correctifs et garder une trace de leur utilité. Comme toujours lorsque vous
- utilisez des outils des maintenance, vous devez lire la documentation
- associée. Le paquet <package>hello-dbs</package> est un exemple simple qui
- présente comment utiliser <package>dbs</package>.
+ <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, les différents paquets <package>vim-*</package>) ou pour
- créer plusieurs petits paquets au lieu d'un seul gros (par exemple, si
- l'utilisateur peut installer que la partie dont il a besoin et ainsi
+ 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> (approche
- vierge) ou <prgn>dh_install</prgn> (du <package>debhelper</package>).
+ 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 <package>vim</package> est un exemple de la façon de
- gérer cela avec un fichier rules écrit à la main.
+ 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 multile configure/make cycles
+<!-- &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>
<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
+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
Vous pouvez utiliser cette fonction pour rechercher le <tt>$PATH</tt> pour un
nom de commande passé en argument. Il renvoie vrai (zéro) si la commande a été
-trouvé et faux sinon. Il s'agit réellement de la façon la plus portable de faire
+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. 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 ; mais cela ne posera sans doute pas de
+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 id="bpp-debian-control">
- <heading>Les meilleures pratiques pour le fichier
- <file>debian/control</file></heading>
- <p>
-Les pratiques suivantes viennent en complément de la <url
- id="&url-debian-policy;ch-miscellaneous.html#s-descriptions"
- name="règles pour les descriptions de paquet">.</p>
-
- <sect1 id="bpp-pkg-desc">
- <heading>Écrire des descriptions utiles</heading>
-<p>
-La description du paquet (telle qu'elle est définie dans le champ correspondant
- du fichier <file>control</file>) est habituellement la première
- information dont dispose l'utilisateur avant d'installer un paquet. Aussi,
- elle devrait fournir toutes les informations nécessaires pour le laisser
- décider de l'installation du paquet.
-<p>
-Pour des raisons de cohérence et d'esthétique, vous devriez mettre en
- majuscule la première lettre du résumé de la description. Ne mettez pas
-de point à la fin. La description elle-même devrait n'être constituée
- que de phrases entières.
-<p>
-Enfin, comme la première impression de l'utilisateur est basée sur cette
- description, vous devriez éviter les fautes d'orthographe et de grammaire.
- N'oubliez pas votre vérificateur orthographique.
- <prgn>ispell</prgn> possède une option spéciale (<tt>-g</tt>) pour
- cela : <example>ispell -d american -g debian/control</example>. Si
- vous voulez qu'une personne relise la description que vous avez l'intention
- d'utiliser, vous pouvez le demander sur &email-debian-l10n-english;.
- </sect1>
-
- <sect1 id="bpp-upstream-info">
- <heading>Page d'accueil amont</heading>
- <p>
-Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
-description du paquet dans le fichier <file>debian/control</file>. Cette
-information devrait être ajoutée à la fin de la description en utilisant le
-format suivant :
-
-<example> .
- Homepage: http://some-project.some-place.org/</example>
-
-Veuillez noter les espaces au début de la ligne, ils servent à séparer les
-lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
-reporter à <url id="&url-eg-desc-upstream-info;">.
- <p>
-Ne mettez rien s'il n'existe pas de page pour le logiciel.
-
- <p>
-Veuillez noter que nous espérons que ce champ sera remplacé par un
-vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
-et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à mettre la
-page d'accueil de la description dans ce nouveau champ, vous devriez
-probablement attendre qu'il soit disponible.</p>
- </sect1>
</sect>
-<!-- <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
- <p>
- &FIXME; presentation of cvs-buildpackage, updating sources
- via CVS (debian/rules refresh).
--->
-
-
<sect id="bpp-config-mgmt">
<heading>Gestion de la configuration avec <package>debconf</package></heading>
</sect1>
</sect>
-<!-- , ils ne peuvent pas garder la trace de chaque changement dans les paquets
- pour être informé quand une chaîne de traduction n'est plus à jour.
- Heureusement, <package>debconf</package> peut automatiquement indiquer les
- traductions non à jour si les responsables de paquet suivent les quelques
- lignes de conduites de base décrites ci-dessous.
-<p>
-Les traducteurs peuvent utiliser <prgn>debconf-getlang</prgn>
- (paquet <package>debconf-utils</package>) pour écrire un fichier
- <file>templates.xx</file> contenant à la fois les champs en anglais et
- localisés (où <em>xx</em> est le code de langue, qui peut être suivi par un
- code de pays). Ce fichier peut être placé dans le sous-répertoire
- <file>debian</file> sans aucun changement.
-<p>
-Lors de la construction d'un paquet binaire, les fichiers
- <file>debian/templates.xx</file> sont regroupés avec
- <file>debian/templates</file> pour générer le fichier <file>templates</file>
- qui contient le paquet binaire. Ceci est fait automatiquement par
- <prgn>dh_installdebconf</prgn> (paquet <package>debhelper</package>). Si vous
- n'utilisez pas debhelper, vous pouvez faire la même chose avec
- <prgn>debconf-mergetemplate</prgn> (paquet
- <package>debconf-utils</package>).
-<p>
-Quand le responsable du paquet a besoin de faire une mise à jour du
- fichier de modèle, il n'a qu'à changer <file>debian/templates</file>. Quand
- les chaînes en anglais de ce fichier et de <file>debian/templates.xx</file>
- diffèrent, les traducteurs savent que leur traduction n'est plus à jour.
-<p>
-Veuillez vous reporter à la page sur les <url id="&url-debconf-l10n-help;"
- name="fichiers templates debconf de localisation"> du site web Debian, elle
- contient des instructions plus détaillées, y compris un exemple complet.
- -->
<sect id="bpp-common-situations">
- <heading>Pratiques d'empaquètement communes</heading>
+ <heading>Pratiques d'empaquetage communes</heading>
<!--
<sect1 id="bpp-kernel">Kernel modules/patches
<sect1 id="bpp-libraries">Bibliothèques
<p>
-Les bibliothèques ont toujours été difficiles à empaqueter pour diverses
- raisons. La charte impose plusieurs contraintes pour faciliter la maintenance
+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'empaquètement des bibliothèques ont été regroupées dans
- <url id="&url-libpkg-guide;" name="le guide d'empaquètement des
+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
<sect1 id="bpp-other">Types spécifiques de paquets
<p>
Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des
- règles et pratiques d'empaquètement correspondantes :
+ règles et pratiques d'empaquetage correspondantes :
<list>
<item>
Les paquets liés à Perl ont leur <url id="&url-perl-policy;" name="charte
l'architecture).
</item>
<item>
- Les paquets liés à Python ont leur charte python ; voir
+ Les paquets liés à Python ont leur charte Python ; voir
&file-python-policy; dans le paquet <package>python</package>.
</item>
<item>
<item>
Les paquets Lisp devraient s'enregistrer avec le paquet
<package>common-lisp-controller</package> pour lequel vous pouvez vous
- reporter à &file-lisp-controller;.
+ 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'empaquètement
+ <heading>Au-delà de l'empaquetage
<p>
-Debian, c'est beaucoup plus que de l'empaquètement de logiciels et de
+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.
les testeurs de première ligne. Trouver et rapporter les bogues dans les
paquets d'autres développeurs améliore la qualité de Debian.
<p>
-Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel vous
- pouvez recevoir des courriers. Ne soumettez pas de bogues en tant
- que root.
-<p>
-Assurez-vous que le bogue n'a pas déjà été rapporté. Essayez de
- faire du bon boulot quand vous rapportez le bogue et indiquez l'emplacement
- exact. Vous pouvez également parcourir les bogues d'autres paquets, en les
- regroupant s'ils sont indiqués plus d'une fois, ou en modifiant la gravité d'un
- bogue à « 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 la
- permission sécurisée du responsable).
+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:<your-email-addr></tt>.
+ <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
les mêmes rapports de bogue simultanément.
<p>
Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez
- les envoyer à <email>maintonly@bugs.debian.org</email> pour qu'ils ne soient
- pas redirigés vers les listes de diffusions.
+ les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils ne soient
+ pas redirigés vers les listes de diffusion.
<sect id="qa-effort">Effort d'assurance qualité
exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
- par un correctif ou si vous gérerez votre bogue vous-même, veuillez l'expliquer
+ 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 habituellement, ils devraient envoyer le correctif de la
+ 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.
devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
mise à jour défectueuse.
- <sect id="mia-qa">Gérer les responsables non joignables
-<p>
-Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
- que le responsable est toujours actif et qu'il continue à travailler sur
- ses paquets. Essayez de le contacter vous-même.
-<p>
-Si vous n'obtenez aucune réponse après quelques semaines, vous devriez réunir
- toutes les informations utiles sur ce responsable. Commencez par vous
- connecter sur la <url id="&url-debian-db;" name="base de données des
- développeurs Debian"> et faites une recherche complète pour vérifier si le
- responsable est en vacances et quand il a été vu la dernière fois.
- Réunissez les noms des paquets importants dont il est responsable et tous
- les bogues critiques pour la distribution rapportés sur ceux-ci.
-<p>
-Envoyez toutes ces informations à &email-debian-qa; pour laisser les personnes
- de la QA décider de ce qui est nécessaire.
-
<sect id="contacting-maintainers">Contacter d'autres responsables
<p>
Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
ou binaire.
<p>
Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
- paquet de source donné par <ref id="pkg-tracking-system">. Vous pouvez le
+ 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>
<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
+ 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>
construire le paquet source comme si vous vouliez construire l'un de vos
paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
candidat développeur dans le changelog et dans le fichier de
- contrôle, l'envoi peut toujours vous être attribué.
+ 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
avant de l'envoyer dans le répertoire Incoming.
<p>
Le champ Maintainer du fichier <file>control</file> et le fichier
- <file>changelog</file> devraient lister la personne qui a fait l'empaquètement,
+ <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>
vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
changelog.
<p>
-Vous êtes encouragé à garder un ½il sur le suivi des paquets que vous parrainer
- en utilisant <ref id="pkg-tracking-system">.
+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>
Le paquet <package>debconf</package> fournit une interface unifiée pour
configurer les paquets interactivement. Il est indépendant de l'interface et
permet une configuration en mode texte, par une interface HTML ou par boîtes de
- dialogues. D'autres types d'interface peuvent être ajoutés sous forme de
+ 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 à <ref
+ 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>
chaque erreur, la partie concernée dans la charte et le moyen habituel de
régler le problème.
<p>
-Veuillez vous reporter à <ref id="upload-checking"> pour plus d'informations sur
+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
<heading><package>linda</package></heading>
<p>
<package>linda</package> est un autre vérificateur de paquet. Il est sembable à
-<package>lintian</package>, mais il a un jeu de tests différents. Il est écrit
+<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">
compresser, ajuster leurs droits et intégrer votre paquet dans le système de
menu Debian.
<p>
-
Au contraire d'autres approches, <package>debhelper</package> est divisé en
+
À 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 volatiles pour être documentées. Vous en
+ <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>
<heading>Constructeurs de paquets</heading>
<p>
Les paquets suivants aident le processus de construction des paquets, en général
-en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que gérant le support de
+en contrôlant <prgn>dpkg-buildpackage</prgn> ainsi que la gestion du support de
tâches.
<sect1 id="cvs-buildpackage">
<sect1 id="sbuild">
<heading><package>sbuild</package></heading>
<p>
-<package>sbuild</package> est un autre compilateur automatique. Il peut être
- aussi utilisé dans un environnement « chrooté ». Il peut être utilisé
+<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.
<heading><package>dupload</package></heading>
<p>
Le paquet <package>dupload</package> contient un script du même nom pour mettre
- à jour des paquets dans l'archive Debian, tracer ces mises à jour et les
+ à 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>
+ <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 travaile des porteurs et la compilation
+Les outils suivants facilitent le travail des porteurs et la compilation
croisée.</p>
<sect1 id="quinn-diff">
<heading><package>debview</package></heading>
<p>
<package>debview</package> fournit un mode Emacs pour voir les paquets binaires
-Debian. Ceci vous permet d'examiner un paquer sans le décompresser.</p>
+Debian. Il vous permet d'examiner un paquet sans le décompresser.</p>
</sect1>
</sect>
-<!-- FIXME : tag heading suspect -->
-<!--
- <sect id="debget">
- <package>debget</package>
-<p>
-Le paquet <package>debget</package> contient un script qui peut être
- utile pour télécharger des paquets depuis l'archive Debian. Vous pouvez, par
- exemple, l'utiliser pour télécharger des paquets sources (bien que <tt>apt-get
- source <package></tt> fasse à peu près la même chose).
- -->
<!-- FIXME: add the following
questionable:
+ dbs (referred to above)
+ dpatch (referred to above)
+ debarchiver
ucf
dpkg-awk
grep-dctrl
apt-show-versions
pdbv
epm
+ apt-src
+ apt-build
rejected:
debaux: too new, unmaintained?
dh-make-perl: too new, unmaintained?
-->
-</appendix>
-
+ </appendix>
</book>
</debiandoc>
sgml-local-ecat-files:nil
End:
-->
+
~ianmdlvl / developers-reference.git / blobdiff