X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.fr.sgml;h=b93f9a34ba89b091782b7c57bb3a10a462a5763c;hb=895e9d9cfefd0f4b2ea37cf942cd4f9a0652a954;hp=b0da9ea3e0d7061f2255f167fb1185058c22a314;hpb=42d3180934c785c834aadb379f8ba28252af944c;p=developers-reference.git diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index b0da9ea..b93f9a3 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -5,12 +5,12 @@ %commondata; - + ]> @@ -26,15 +26,14 @@ -Manuel de référence du développeur Debian +<title>Référence du développeur Debian <author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email> <author>Christian Schwarz <email>schwarz@debian.org</email> <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email> <author>  -<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.fr</email> -<author>avec la participation de Alain Meessen -<author>et des membres de la liste +<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email> +<author>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email> <version>version &version;, &date-fr; @@ -46,7 +45,7 @@ Copyright ©1997, 1998 Christian Schwarz.</copyrightsummary> <p> -Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié selon +Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié selon les termes de la licence grand public du projet GNU (GNU GPL), telle que publiée par la « Free Software Foundation » (version 2 ou toute version supérieure). @@ -164,10 +163,10 @@ r id="submit-bug">). <item><em>Release critical bug</em> : bogue remettant en cause la - distribution. Bogues de sévérité <em>critique</em>, <em>grave</em> + distribution. Bogues de gravité <em>critique</em>, <em>grave</em> et <em>sérieuse</em>. Ces bogues ne doivent pas apparaître dans une distribution <em>stable</em>. Ils doivent être corrigés ou bien les - paquets en cause doivent être supprimés (<ref id="rc-bug">). + paquets en cause doivent être supprimés (<ref id="rc-bugs">). <item><em>Unstable</em> : Nom de la distribution en cours de développement. Cette distribution contient les paquets envoyés par @@ -177,7 +176,8 @@ r <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 sévère n'a été découvert. Cette distribution n'a pas été testée + bogue remettant en cause la distribution (cf. <em>Release critical bug</em>) + n'a été découvert. Cette distribution n'a pas été testée en profondeur. Elle est cependant sensée être plus stable que <em>unstable</em> (<ref id="life-cycle">). @@ -194,13 +194,13 @@ r <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 + au développement — au sens large — de la distribution (<ref id="developer-duties">). La plupart des responsables font de la mise en paquet mais il existe d'autres activités telles que documentation, site web, création des cédéroms, administration des serveurs... <item><em>Upstream version</em> : version amont. Il s'agit du - logiciel tel qu'il est fournit par le responsable amont -- par + logiciel tel qu'il est fournit par le responsable amont — par opposition à la version fournie par la distribution Debian. (Voir <ref id="upstream-coordination">.) @@ -439,7 +439,7 @@ exp <chapt id="developer-duties">Les charges du responsable Debian - <sect>Mise à jour de vos références Debian + <sect id="user-maint">Mise à jour de vos références Debian <p> Une base de données LDAP contient de nombreuses informations concernant @@ -487,10 +487,10 @@ dans la documentation du paquet <package>debian-keyring</package>. <sect id="inform-vacation">Prendre des vacances courtoisement <p> -La plupart des développeurs prennent des vacances ; généralement, cela signifie +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 +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 bloquants pour la distribution, mise à jour de @@ -500,11 +500,17 @@ s Il y a deux choses à faire pour informer les autres développeurs. Premièrement, envoyer un courrier électronique indiquant vos dates de vacances à &email-debian-private;, vous pouvez aussi donner quelques instructions pour -indiquer comment agir si un problème survenait. Deuxièmement, il faut mettre +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 ; ajoutez '[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 » (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. +celles-ci sont terminées ! @@ -520,15 +526,15 @@ transmettre ces rapports de bogue aux d corrigés dans les prochaines versions. Il n'est pas de votre responsabilité de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois, si vous êtes capable de le faire, nous vous encourageons à contribuer au -développements amonts en proposant un <em>patch</em> qui corrige ce bogue. -Les utilisateurs et responsables Debian proposent souvent des <em>patches</em> -pour corriger des bogues amonts, il vous faudra alors évaluer ce -<em>patch</em> puis le transmettre aux développeurs amonts. +développement amont en proposant une rustine qui corrige ce bogue. +Les utilisateurs et responsables Debian proposent souvent des rustines +pour corriger des bogues amonts, il vous faudra alors évaluer cette +rustine puis la transmettre aux développeurs amonts. <p> Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un -paquet conforme à la charte Debian, alors vous devriez proposer un -<em>patch</em> aux developpeurs amonts pour qu'il soit inclus dans leur +paquet conforme à la charte Debian, alors vous devriez proposer une +rustine aux développeurs amonts pour qu'elle soit incluse dans leur version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des mises à jour amonts suivantes. Quels que soient les changements dont vous avez besoin, il faut toujours essayer de rester dans la lignée des sources @@ -538,11 +544,11 @@ amonts. - <sect id="rc-bug">Gestion des bogues bloquants pour la distribution + <sect id="rc-bugs">Gestion des bogues bloquants pour la distribution <p> Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais -<em>Release critical bug (RCB)</em></footnote> sont les bogues de sévérité +<em>Release critical bug (RCB)</em></footnote> sont les bogues de gravité <em>critique</em>, <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>, <em>grave</em> et <em>serious</em> en anglais</footnote>. Ces bogues peuvent retarder la diffusion d'une distribution Debian et/ou @@ -553,8 +559,8 @@ id="&url-debian-qa;" name ="assurance qualit et essaient de vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de ce type dans les deux semaines, vous devriez soit demander de l'aide en envoyant un courrier à l'équipe d'assurance qualité -(<em>QA group</em> &email-debian-qa;), soit vous expliquer et présenter un -plan pour corriger le problème en répondant au rapport de bogue +(<em>QA group</em> &email-debian-qa;), soit expliquer vos difficultés et +présenter un plan pour corriger le problème en répondant au rapport de bogue concerné. Si rien n'est fait, des personnes de l'équipe d'assurance qualité pourraient chercher à corriger votre paquet (voir <ref id="nmu">) après avoir tenté de vous contacter. Ils pourraient attendre moins longtemps que @@ -570,9 +576,8 @@ M activité ne leur est pas réservée. Vous pouvez participer à cet effort en éliminant, autant que faire se peut, tout bogue de vos paquets et en observant les remarques émises par <prgn>lintian</prgn> (voir <ref id="lintian-reports">). Si cela -vous semble tout à fait impossible, il faudrait songer à abandonner certains -de vos paquets, vous pourrez ainsi faire du bon travail avec les paquets dont -vous restez responsable (voir <ref id="orphaning">). Vous pouvez aussi +ne vous semble pas possible, il faudrait songer à abandonner certains +de vos paquets (voir <ref id="orphaning">). Vous pouvez aussi demander l'aide d'autres personnes pour rattraper votre retard dans la liste des bogues (vous pouvez demander de l'aide sur les listes &email-debian-qa; et &email-debian-devel;). @@ -860,7 +865,7 @@ sont stock l'archive et aux logiciels qui l'accompagnent. Le premier répertoire contient les distributions <em>stable</em>, <em>testing</em> et <em>unstable</em>. Le découpage en sous-répertoires est identique d'un répertoire de distribution à -l'autre ; nous nous contenterons donc d'exposer ce découpage pour la +l'autre ; nous nous contenterons donc d'exposer ce découpage pour la distribution <em>stable</em>. Les fichiers <tt>Packages</tt> et <tt>Sources</tt> qui se trouvent dans les répertoires de distribution peuvent faire référence à des fichiers du répertoire <tt>pool/</tt>. @@ -1125,59 +1130,59 @@ distribution <em>frozen</em> appara - <sect1>Experimental - -<p> -<em>NOTE : <em>experimental</em> ne fonctionne plus depuis la mise en place du -<em>package pool</em>. Si la distribution <em>experimental</em> est remise en service -un jour, la présente section aura sûrement besoin d'une mise à jour.</em> + <sect1><em>Experimental</em> <p> La distribution <em>experimental</em> est une distribution particulière. Ce n'est pas une distribution à part entière comme le sont <em>stable</em> et <em>unstable</em>. Elle est prévue pour servir de plate-forme de développement pour les projets expérimentaux qui ont de grandes chances de détruire le -système. Les utilisateurs qui téléchargent et installent des paquets depuis +système ou bien pour des logiciels qui sont vraiment trop instables pour être +inclus dans la distribution <em>unstable</em> (mais qui ont néanmoins une +bonne raison pour être mis en paquet). Les utilisateurs qui téléchargent et +installent des paquets depuis <em>experimental</em> sont prévenus : on ne peut pas faire confiance à la distribution <em>experimental</em>. <p> -Les responsables doivent être très sélectifs quant à l'utilisation de la -distribution <em>experimental</em>. Même très instable, un paquet peut aller -dans <em>unstable</em> ; ajoutez juste quelques avertissements dans la -description. Par contre, s'il y a une chance que le logiciel endommage -sérieusement le système, il est préférable de le mettre dans +S'il y a des chances pour qu'un logiciel cause des dégats importants, il sera +sûrement préférable de le mettre dans la distribution <em>experimental</em>. +Un système de fichier compressé, par exemple, devrait probablement aller dans <em>experimental</em>. <p> -Un système de fichier crypté, par exemple, devrait probablement aller dans -<em>experimental</em>. Une nouvelle version non finalisée d'un logiciel qui -utilise une méthode de configuration complètement différente pourrait aller -dans <em>experimental</em> à la discrétion du responsable. Un nouveau logiciel -qui a peu de chance d'endommager le système ira dans <em>unstable</em>. Si -vous travaillez sur un cas de mise à jour complexe ou incompatible vous pouvez -aussi utiliser <em>experimental</em> comme plate-forme d'intégration et ainsi -fournir un accès aux testeurs. +Une nouvelle version amont qui ajoute des nouvelles fonctions et en supprime +beaucoup de plus anciennes ne devra pas être téléchargée dans l'archive +Debian, elle pourra cependant être téléchargée dans <em>experimental</em>. Une +nouvelle version non finalisée d'un logiciel qui utilise une méthode de +configuration complètement différente pourrait aller dans +<em>experimental</em> à la discrétion du responsable. Si vous travaillez sur +un cas de mise à jour complexe ou incompatible vous pouvez aussi utiliser +<em>experimental</em> comme plate-forme d'intégration et ainsi fournir un +accès aux testeurs. <p> -Par contre, utiliser <em>experimental</em> comme plate-forme n'est pas -toujours la meilleure idée. Vous ne pouvez pas remplacer ou mettre à jour des -paquets dans cet espace vous-même (c'est le logiciel de maintenance de -l'archive qui s'en charge). De plus, il vous faudra penser à demander la -suppression de vos paquets à l'équipe d'administration de l'archive une fois -qu'ils seront installés dans <em>unstable</em>. Utiliser vos pages web -personnelles sur le serveur <tt>klecker.debian.org</tt> est en général une -meilleure idée, cela permet de décharger l'équipe de maintenance de l'archive. +Quelques logiciels expérimentaux peuvent aller dans <em>unstable</em>, avec un +avertissement dans la description mais ce n'est pas recommandé car les paquets +de <em>unstable</em> se propagent dans <em>testing</em> et aboutissent dans +<em>stable</em>. +<p> +Un nouveau logiciel qui a peu de chance d'endommager le système ira +directement dans <em>unstable</em>. +<p> +Une alternative à <em>experimental</em> consiste à utiliser vos pages +personnelles sur le serveur <tt>people.debian.org</tt> +(<tt>klecker.debian.org</tt>). <sect id="codenames">Les noms de distribution <p> Chaque distribution Debian diffusée a un nom : Debian 1.1 s'appelle « buz » ; Debian 1.2, « rex » ; Debian 1.3 « bo » ; -Debian 2.0, « hamm » ; Debian 2.1, « slink » et Debian 2.2 -« potato ». Il y a aussi une pseudo-distribution nommée +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 de la stabilité, la distribution « sid » n'est jamais diffusée. En plus @@ -1248,12 +1253,12 @@ pas limitative. <p> Le sujet de votre rapport de bogue devra être <ITP<footnote><em>Intent To Package</em> : intention de mise en paquet</footnote> : -<var>NomDuPaquet</var> -- <var> courte description </var>>, en remplaçant -<var>NomDuPaquet</var> par le nom du paquet. La sévérité du bogue sera +<var>NomDuPaquet</var> — <var> courte description </var>>, en remplaçant +<var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera <em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à -&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de -l'entête du message. N'utilisez pas le champs CC: car de cette manière le -sujet du message ne contiendrait pas le numéro du bogue. +&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de +l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le +sujet du message ne contiendra pas le numéro du bogue. <p> Il faudra aussi ajouter une entrée @@ -1297,14 +1302,47 @@ leurs intentions : </list> + <sect id="upload-checking">Vérifier le paquet avant la mise à jour +<p> +Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous +devrez au moins faire les tests suivants (il vous faut une ancienne version +du paquet pour cela) : + <list compact> + <item> + Installez le paquet et vérifiez que le logiciel fonctionne. Si le + paquet existait déjà dans une version plus ancienne, faites une mise à + jour. + <item> + Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter + <prgn>lintian</prgn> comme suit : <tt>lintian -v + <var>package-version</var>.changes</tt>. Ce programme fera une + vérification sur les paquets source et binaire. Si vous ne comprenez + par les messages générés par <prgn>lintian</prgn> essayez l'option + <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus + bavard dans sa description du problème. + <p> + En principe, un paquet pour lequel + <prgn>lintian</prgn> génère des erreurs (elles commencent par + <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive. + <p> + Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la + section lintian <ref id="lintian">. + + <item> + Faites régresser le paquet + vers sa version précédente si elle existe — cela permet de tester les + scripts <tt>postrm</tt> et <tt>prerm</tt>. - <sect id="uploading">Mettre à jour un paquet + <item> + Désinstallez le paquet et réinstallez-le. + + </list> - <sect1>Générer le fichier « changes » + <sect>Générer le fichier « changes » <p> Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à @@ -1325,41 +1363,10 @@ Debian. Vous pouvez consulter la liste des champs de contr <url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue automatiquement avec le champ <tt>Description</tt> (voir <ref -id="upload-bugfix">). Nous ne verrons ici que le champ <tt>Distribution</tt> -car il est directement lié aux règles d'administration de l'archive. - +id="upload-bugfix">). - - <sect1 id="upload-dist">Choisir une distribution - -<p> -Le champ <tt>Distribution</tt>, qui provient du fichier -<file>debian/changelog</file>, indique à quelle distribution le paquet est -destiné. Il y a quatre valeurs possibles pour ce champ : <em>stable</em>, -<em>unstable</em>, <em>frozen</em> et <em>experimental</em> ; ces valeurs -peuvent aussi être combinées. Si, par exemple, Debian a été gelée et vous -voulez mettre à jour une correction de bogue sur <em>frozen</em>, il faudra -indiquer <em>frozen unstable</em> dans le champ distribution (se reporter à -<ref id="upload-frozen"> pour savoir quand vous pouvez faire une mise à jour -sur <em>frozen</em>). Notez bien qu'il n'y a pas de raison de combiner -<em>experimental</em> avec quelque distribution que ce soit. - -<p> -Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause -des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et -pour les paquets fabriqués par le démon de compilation pour les autres -architectures). Notez encore que choisir la valeur <em>stable</em> pour ce -champ signifie que le paquet sera dirigé vers le répertoire -<tt>proposed-update</tt> des archives Debian pour y être testé avant d'être -effectivement inclus dans <em>stable</em>. L'équipe responsable de la -distribution<footnote><em>the release team</em></footnote> (joignable à -l'adresse &email-debian-release;) prendra la décision d'inclure ou de ne pas -inclure votre paquet dans la distribution <em>stable</em>. C'est pourquoi vous -pourrez choisir de leur envoyer un courrier expliquant les motifs qui vous ont -incité à faire une mise à jour pour <em>stable</em>, si votre fichier -<file>changelog</file> n'est pas suffisamment clair sur ce point. - + <sect1>L'archive des sources amonts <p> La première fois qu'un paquet est installé dans l'archive pour une version amont donnée, le fichier <tt>tar</tt> de cette version amont doit être @@ -1386,9 +1393,38 @@ fichier doit + <sect1 id="upload-dist">Choisir une distribution + +<p> +Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier +<file>debian/changelog</file>, indique à quelle distribution le paquet est +destiné. + +<p> +Il y a quatre valeurs possibles pour ce champ : <em>stable</em>, +<em>unstable</em>, <em>frozen</em> et <em>experimental</em> . En temps +normal, les paquets sont téléchargés dans <em>unstable</em>. + +<p> +Ces valeurs peuvent être combinées mais seules quelques combinaisons ont +un sens. Si la distribution a été gelée et si vous voulez livrer une correction +de bogue sur <em>frozen</em>, il faudra indiquer <em>frozen unstable</em> dans +le champ distribution. Se reporter à <ref id="upload-frozen"> pour en savoir +plus sur les mises à jour de <em>frozen</em>). + +<p> +Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause +des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et +pour les paquets fabriqués par le démon de compilation pour les autres +architectures). Se reporter à <ref id="upload-stable"> pour savoir quand et +comment faire une mise à jour de <em>stable</em>. + +<p> +Notez bien que combiner <em>experimental</em> avec quelque distribution +que ce soit n'a pas de sens. - <sect2 id="upload-frozen">Mettre à jour la distribution <em>frozen</em> + <sect2 id="upload-frozen">Mettre à jour un paquet de la distribution <em>frozen</em> <p> Le gel de la distribution est un moment crucial pour Debian. C'est l'occasion @@ -1398,7 +1434,7 @@ pour <em>frozen</em>. <p> Il est tentant de toujours mettre en paquet la dernière version d'un logiciel -pour Debian ; mais il est bien plus important que le système soit stable et +pour Debian ; mais il est bien plus important que le système soit stable et qu'il fonctionne de la manière attendue. <p> @@ -1409,28 +1445,28 @@ conseils : <p> <list compact> <item> - Les corrections de bogues de sévérité <em>critique</em>, + Les corrections de bogues de gravité <em>critique</em>, <em>grave</em> ou <em>sérieuse</em><footnote>respectivement <em>critical</em>, <em>grave</em> ou <em>serious</em></footnote> sont toujours autorisées pour les paquets qui doivent exister dans la distribution. <item> - Les corrections pour les bogues de sévérité <em>critique</em>, + Les corrections pour les bogues de gravité <em>critique</em>, <em>grave</em> ou <em>sérieuse</em><footnote>respectivement <em>critical</em>, <em>grave</em> ou <em>serious</em></footnote> sont autorisées pour les paquets non indispensables uniquement si elles n'ajoutent pas de nouvelle fonctionnalité. <item> - Les corrections pour les bogues de sévérité <em>importante</em>, + Les corrections pour les bogues de gravité <em>importante</em>, <em>normale</em> et <em>mineure</em><footnote>respectivement <em>important</em>, <em>normal</em> et <em>minor</em></footnote> sont autorisées, bien que découragées, sur tous les paquets si et seulement s'elles n'ajoutent pas de nouvelle fonctionnalité. <item> - Les corrections de sévérité <em>wishlist</em> ne sont pas autorisées (ce + Les corrections de gravité <em>wishlist</em> ne sont pas autorisées (ce ne sont pas vraiment des bogues après tout). <item> @@ -1443,49 +1479,61 @@ conseils : L'expérience montre qu'il y a 15% de chance d'introduire un nouveau bogue en corrigeant un autre bogue. L'introduction et la découverte d'un nouveau bogue retarde la mise à disposition de la distribution ou affaiblit le produit -final. Il y a très peu de corrélation entre la sévérité du bogue corrigé et -la sévérité du bogue introduit par la correction. - +final. Il y a très peu de corrélation entre la gravité du bogue corrigé et +la gravité du bogue introduit par la correction. - - <sect1 id="upload-checking">Vérifier le paquet avant la mise à jour + <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em> <p> -Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous -devrez au moins faire les tests suivants (il vous faut une ancienne version -du paquet pour cela) : +Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet +sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian +pour y être testé avant d'être effectivement inclus dans <em>stable</em>. - <list compact> - <item> - Installez le paquet et vérifiez que le logiciel fonctionne. Si le - paquet existait déjà dans une version plus ancienne, faites une mise à - jour. +<p> +Une livraison pour la distribution <em>stable</em> requière des soins +supplémentaires. Un paquet de cette distribution ne devrait être mis à jour +que dans les cas suivants : - <item> - Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter - <prgn>lintian</prgn> comme suit : <tt>lintian -v - <var>package-version</var>.changes</tt>. Ce programme fera une - vérification sur les paquets source et binaire. Si vous ne comprenez - par les messages générés par <prgn>lintian</prgn> essayez l'option - <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus - bavard dans sa description du problème. <p> Un paquet pour lequel - <prgn>lintian</prgn> génère des erreurs (elles commencent par - <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive. + <list> + <item>un problème de sécurité (un avis de sécurité + Debian<footnote>Debian security advisory.</footnote>), + <item>un probleme fonctionnel vraiment critique, + <item>un paquet devenu ininstallable, + <item>un paquet indisponible pour une architecture. + </list> - <p> - Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la - section lintian <ref id="lintian">. <item> Faites régresser le paquet - vers sa version précédente si elle existe -- cela permet de tester les - scripts <tt>postrm</tt> et <tt>prerm</tt>. +<p> +Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas +important car même une modification triviale peut causer un bogue plus +tard. Livrer une nouvelle version amont d'un logiciel pour corriger un +problème de sécurité est désapprouvé ; dans la plupart des cas la +bonne solution consiste à prendre la rustine correspondante de la +nouvelle version amont et à l'appliquer à l'ancienne (faire un +portage (<em>backport</em>) de la rustine. - <item> - Désinstallez le paquet et réinstallez-le. +<p> +Les paquets livrés pour <em>stable</em> doivent être compilés avec la +distribution <em>stable</em> pour que leurs dépendances se limitent aux +bibliothèques (et autres paquets) disponibles dans <em>stable</em> ; +un paquet livré pour la distribution <em>stable</em> qui dépend d'une +librairie qui n'est disponible que dans <em>unstable</em> sera rejeté. +Modifier les dépendances d'autres paquets (en manipulant le champ +<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets +ininstallables, est fortement déconseillé. - </list> +<p> +L'équipe responsable de la distribution<footnote><em>the Release +team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera +régulièrement le contenu de <em>proposed-updates</em> et décidera si votre +paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis +(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog, +vos changements pour une livraison vers <em>stable</em> sinon le paquet ne +sera pas considéré. + <sect id="uploading">Mettre à jour un paquet <sect1 id="upload-ftp-master">Installer un paquet sur @@ -1541,7 +1589,7 @@ Utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn> pour copier votre paquet sur <ftpsite>non-us.debian.org</ftpsite>. Placer les fichiers dans le répertoire <tt>&non-us-upload-dir;</tt>. Par défaut, vous pouvez utiliser le même <em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez -une connexion FTP anonyme pour le téléchargement, placez vous fichiers dans le +une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le répertoire <ftppath>/pub/UploadQueue/</ftppath>. <p> @@ -1557,7 +1605,7 @@ avec : <p> -Attention, les personnes résidant aux États-unis et les citoyens américains +Attention, les personnes résidant aux États-Unis et les citoyens américains sont soumis à des restrictions sur l'exportation des logiciels de cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter quelques logiciels de cryptographie soumis à une obligation de déclaration @@ -1567,7 +1615,7 @@ aupr Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le faisant. Nous recommandons aux responsables concernés de -prendre toutes les précautions nécessaires, <em>y compris consulter un +prendre toutes les précautions nécessaires, <em>y compris la consultation d'un juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un paquet sur <tt>non-US</tt>. @@ -1591,8 +1639,13 @@ am <p> Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs possibilités. L'une d'elles consiste à télécharger vos fichiers dans -<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Comme -cette file d'attente des mises à jour est redirigée vers <tt>ftp-master</tt>, +<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Pour +les détails consultez <url id="&url-chiark-readme;">. + +<p> +Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux +lois de contrôle des exportations américaines sur <tt>chiark</tt>. +Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, les indications de la section <ref id="upload-ftp-master"> sont applicables ici aussi. @@ -1633,11 +1686,11 @@ vous serez inform processus. <p> -<em>Note :</em> ne téléchargez pas de paquets contenant des logiciels tombant -sous le coup de la loi de contrôle des exportations américaine sur -<tt>erlangen</tt>. Comme les paquets téléchargés ici vont vers -<tt>ftp-master</tt>, les règles décrites dans la section <ref -id="upload-ftp-master"> sont applicables ici aussi. +Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux +lois de contrôle des exportations américaines sur <tt>erlangen</tt>. +Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>, +les indications de la section <ref id="upload-ftp-master"> sont applicables ici +aussi. <p> Le programme <prgn>dupload</prgn> est capable de télécharger sur @@ -1688,13 +1741,6 @@ S'il est mis <em>experimental</em> ou <em>frozen</em>, l'annonce est envoyée sur la liste &email-debian-devel-changes;. -<p> -De temps en temps, il est nécessaire de mettre à jour simultanément les -distributions <em>stable</em> et <em>unstable</em> ; cela est possible en -indiquant les deux distributions sur la ligne <tt>Distribution:</tt>. Dans ce -dernier cas, l'annonce sera faite sur les deux listes de diffusion citées -précédemment. - <p> Le programme <prgn>dupload</prgn> est suffisamment intelligent pour déterminer où devra aller l'annonce et pour envoyer le courrier sur la bonne liste. Voir <ref @@ -1709,8 +1755,8 @@ id="dupload">. <p> Les administrateurs de l'archive Debian sont responsables de l'installation des mises à jour. La plupart des mises à jour sont gérées -quotidiennement par le logiciel de gestion de l'archive <prgn>dak</prgn> -(aussi appelé <prgn>katie</prgn> ou <prgn>dinstall</prgn>). Les mises à jour +quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>. +Les mises à jour de paquets sur la distribution <em>unstable</em>, en particulier, sont installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois @@ -1719,10 +1765,14 @@ effective. Soyez patients. <p> Dans tous les cas vous recevrez un accusé de réception par courrier -électronique indiquant que votre paquet a été installé. Lisez attentivement ce -courrier. Vous pourriez remarquer que votre paquet n'a pas été installé dans -la section que vous aviez désignée. La raison de ce changement sera dans le -courrier. +électronique indiquant que votre paquet a été installé et quels rapports +de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous +les rapports de bogues que vous vouliez clore sont bien dans cette liste. + +<p> +L'accusé de réception indique aussi la section dans laquelle le paquet a +été installé. S'il ne s'agit pas de votre choix, vous recevrez un second +courrier qui vous informera de cette différence (voir plus loin). @@ -1739,10 +1789,20 @@ indications. <p> Les administrateurs de l'archive indiquent les sections et priorités des paquets -dans le fichier <em>override</em>. De temps en temps, ce fichier doit être -corrigé. Modifier le fichier <file>control</file> du paquet n'aura aucun -effet. Il vous faudra écrire à &email-override; ou faire un rapport de bogue -sur le pseudo-paquet <package>ftp.debian.org</package>. +dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le +fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez +informé par courrier électronique quand votre paquet sera installé dans +l'archive. Vous pourrez corriger votre fichier <em>debian/control</em> +avant votre prochain téléchargement ou alors vous aurez envie de modifier le +fichier <em>override</em>. + +<p> +Pour modifier la section dans laquelle un paquet est archivé, vous devez +d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite, +envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo +paquet <package>ftp.debian.org</package> demandant la modification de la +section ou de la priorité de votre paquet. Exposez bien les raisons qui vous +amènent à demander ces changements. <p> Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref @@ -1797,12 +1857,14 @@ 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 version amont du source que la -partie du source spécifique à Debian. +Ce changement peut tout aussi bien concerner la partie amont du source que la +partie spécifique à Debian. Une mise à jour indépendante source peut aussi +inclure des paquets spécifiques à une architecture, un fichier <em>diff</em> +modifié ou, plus rarement, des nouveaux sources amonts. <p> -Une mise à jour indépendante binaire est une recompilation et un archivage -d'un paquet pour une nouvelle architecture. Il s'agit souvent du résultat d'un +Une mise à jour indépendante binaire est la recompilation et l'archivage +d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un effort de portage. Une mise à jour indépendante binaire est la livraison d'un paquet compilé (souvent pour une autre architecture) à condition que cette compilation n'ait pas nécessité de modifications des sources. Dans de @@ -1819,7 +1881,7 @@ par l'expression (NMU<footnote>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 j'utilise « mise à jour +vigilant. Dans ce chapitre, si nous utilisons « mise à jour indépendante » seul, il s'agit des deux types de livraisons. @@ -1833,9 +1895,9 @@ Seuls les responsables Debian officiels peuvent faire des mises 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 <em>patch</em> qui le méritent au +indépendantes, ils pourront soumettre les rustines qui le méritent au système de suivi des bogues. Les responsables apprécient presque toujours les -<em>patch</em> et les rapports de bogue soignés. +rustines et les rapports de bogue soignés. <sect id="nmu-when">Quand faire une mise à jour indépendante source ? @@ -1847,19 +1909,19 @@ gel légèrement différentes (voir <ref id="source-nmu-when-porter">). <p> -La distribution stable ne peut recevoir que des corrections critiques ou des -mises à jour de sécurité. Quand une faille de sécurité est détectée, un -paquet corrigé doit être livré le plus tôt possible. Dans ce cas, le responsable de -sécurité Debian<footnote>Debian Security Manager</footnote> entrera en contact +Quand une faille de sécurité est détectée, un +paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de +l'équipe de sécurité Debian<footnote>Debian Security officer</footnote> +entrera en contact avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans un délai raisonnable (moins de 48 heures). Si le mainteneur ne peut -fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps, le -responsable de sécurité pourra corriger le paquet (i.e. faire une mise à jour +fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps, +l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour indépendante source). <p> Pendant la phase de gel (voir <ref id="upload-frozen">), les livraisons qui -corrigent les bogues de sévérité <em>sérieuse</em> (i.e. <em>serious</em>) et +corrigent les bogues de gravité <em>sérieuse</em> (i.e. <em>serious</em>) et supérieures sont encouragées et acceptées. Même pendant cette période, vous devrez tenter d'entrer en contact avec le responsable du paquet ; il pourrait bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour @@ -1884,7 +1946,7 @@ pas il est probablement correct de faire une mise pour corriger le bogue. Donnez-lui quelques jours. <item> - Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de + Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de suivi des bogues. Construisez le paquet et testez-le comme décrit dans la section <ref id="upload-checking">. Utilisez le paquet chez vous. @@ -1929,7 +1991,7 @@ id="porter-guidelines">. 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 <em>patch</em> aussi petit que +corrigez pas ce qui n'est pas cassé. Faites une rustine aussi petite que possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en au responsable du paquet, au responsable amont ou soumettez un rapport de bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em> @@ -1974,7 +2036,7 @@ doit choisir du paquet doit, lui, démarrer sa numérotation à « 1 ». Notez que pour faire cela vous devrez utiliser <prgn>dpkg-buildpackage</prgn> avec l'option <tt>-sa</tt> pour le forcer à utiliser le nouveau paquet source (par défaut il -reconnaît les numéros de révisions « 0 » ou « 1 » -- il +reconnaît les numéros de révisions « 0 » ou « 1 » — il n'est pas suffisamment intelligent pour reconnaître « 0.1 »). <p> @@ -2028,7 +2090,7 @@ est disponible, un bogue a vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>; il y aura donc une modification. Si vous êtes porteur, vous êtes probablement en train de faire une mise à jour indépendante binaire. (Note : ce système ne -tient pas compte des porteurs qui font des recompilations -- tenez cela pour +tient pas compte des porteurs qui font des recompilations — tenez cela pour une faiblesse de notre système de gestion des paquets.) <p> @@ -2039,21 +2101,21 @@ et le rapporteur du bogue sont autoris Cependant, la personne qui fait une mise à jour indépendante doit envoyer une note à chaque bogue concerné expliquant qu'il est corrigé par cette mise à jour indépendante. Cette personne doit ensuite utiliser l'adresse -<email>control@bugs.debian.org</email> pour modifier la sévérité des bogues +<email>control@bugs.debian.org</email> pour modifier la gravité des bogues corrigés et leur donner la valeur <em>corrigé</em> (i.e. <em>fixed</em>). Cela permet de s'assurer 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 nécessaire, ouvrez des rapports de bogue -avec les <em>patch</em> correspondants ou assurez-vous que l'un des rapports de -bogue déjà ouverts comporte ces <em>patch</em>. +avec les rustines correspondantes ou assurez-vous que l'un des rapports de +bogue déjà ouverts comporte ces rustines. <p> -Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, il pourra aussi +Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi employer une autre méthode pour régler le problème. Certains bogues sont corrigés dans la version amont, ce qui est une bonne raison pour annuler les modifications d'une mise à jour indépendante. Si le responsable choisit de -mettre à jour le paquet sans utiliser les <em>patch</em> de la mise à jour +mettre à jour le paquet sans utiliser les rustines de la mise à jour indépendante, il devra s'assurer que cette nouvelle version corrige effectivement chacun des bogues corrigés dans la mise à jour indépendante. @@ -2075,7 +2137,7 @@ 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="upload">. +id="uploading">. <p> En fait, toutes les prescriptions de la section <ref id="upload"> sont @@ -2107,7 +2169,7 @@ C'est une activité remarquable et essentielle. En fait, les porteurs sont à l'origine de la plupart des compilations de paquet Debian. Pour un paquet binaire <em>i386</em>, par exemple, il faut compter une recompilation pour chaque -autre architecture, soit un total de cinq recompilations. +autre architecture, soit un total de &number-of-arches; recompilations. @@ -2118,7 +2180,7 @@ autre architecture, soit un total de cinq recompilations. 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 -- +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. @@ -2126,7 +2188,8 @@ inutilement leur travail. 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). +manière). Merci pour votre indulgence envers des rapports de bogues 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 @@ -2135,6 +2198,20 @@ des erreurs de mise en paquet dans le paquet source. Voici une <enumlist> <item> + Vérifiez que les champs <tt>Build-Depends</tt> et + <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont + corrects. Le meilleur moyen pour vérifier cela est d'utiliser le + paquet <package>debootstrap</package> pour créer un environnement + <em>unstable</em> <em>chrooté</em>. Dans cet environnement + <em>chrooté</em> il faudra installer le paquet + <package>build-essential</package> et tous les paquets mentionnés dans + les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>. + Ensuite, vous essayerez de fabriquer votre paquet dans cette + environnement. + <p> + Consultez le <url id="&url-debian-policy;" name="Debian Policy + Manual"> pour en savoir plus sur les dépendances de fabrication. + <item> Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour le champ architecture sans avoir de bonnes raisons pour le faire. Trop souvent, les développeurs ne respectent pas les instructions du @@ -2168,8 +2245,12 @@ des erreurs de mise en paquet dans le paquet source. Voici une (un sous-cas de la remarque précédente). <item> - Ne supposez pas qu'<prgn>egcc</prgn> est disponible, ni que vous - utilisez une version précise de <prgn>gcc</prgn>. + Si possible, ne vous appuyez pas sur une particularité présente dans + un compilateur précis ou dans certaine version d'un compilateur. Si + vous ne pouvez pas faire autrement, assurez-vous que les dépendances + de fabrication reflètent bien cette restriction. Dans ce cas, vous + cherchez sûrement les problèmes car quelques architectures pourraient + choisir un compilateur différent. <item> Vérifiez que votre <file>debian/rules</file> distingue les cibles @@ -2200,18 +2281,6 @@ Pour une mise dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet source (cela inclut <file>debian/changelog</file>). -<p> -Parfois il est nécessaire de recompiler des paquets quand d'autres paquets, -tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez -changer le numéro de version pour que le système de gestion des paquets -fonctionne correctement. Ce type de mise à jour reste une mise à jour -indépendante binaire -- il n'est pas nécessaire de faire une recompilation sur -toutes les architectures. Vous devez utiliser la même règle de numérotation -que pour une mise à jour indépendante mais en ajoutant « .0. » -devant le numéro de révision Debian. Par exemple une recompilation du paquet -source « foo_1.3-1 » portera le numéro de version -<tt>foo_1.3-1.0.1</tt>. - <p> La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante : <tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr, @@ -2220,6 +2289,33 @@ commande construira les portions du paquet qui d utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>. + <sect1 id="recompile-nmu-versioning"> + <heading>Numéro de version des mises à jour indépendantes + binaires</heading> + +<p> +Parfois il est nécessaire de recompiler des paquets quand d'autres paquets, +tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez +changer le numéro de version pour que le système de comparaison des numéros de +version fonctionne correctement. Ce type de mise à jour reste une mise à jour +indépendante binaire — 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 ». @@ -2242,9 +2338,9 @@ distribution gel <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 +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 +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 @@ -2252,7 +2348,7 @@ commun <p> Deuxième différence, les porteurs qui font des mises à jour indépendantes -sources doivent choisir une sévérité <em>sérieuse</em> (i.e. +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 @@ -2304,7 +2400,7 @@ l'architecture <var>X</var> doivent <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 » +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 @@ -2319,14 +2415,14 @@ continuellement utilis <prgn>andrea</prgn>, <prgn>sbuild</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 +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 enthousiasmés par ce système car il a de nombreux usages potentiels. Des groupes de développeurs indépendants peuvent utiliser ce système pour créer -différentes saveurs de la Debian -- qui peuvent être ou ne pas être +différentes saveurs de la Debian — qui peuvent être ou ne pas être intéressantes pour tous (une version de Debian compilée avec des vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler rapidement toute une distribution. @@ -2447,19 +2543,19 @@ Group &orphan-address;</tt> dans le champ <tt>maintainer</tt> du paquet et faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être « <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>: -<var>paquet</var> -- <var>courte description</var></tt> » pour indiquer -que le paquet est orphelin. La sévérité du bogue sera <em>normale</em>. +<var>paquet</var> — <var>courte description</var></tt> » pour indiquer +que le paquet est orphelin. La gravité du bogue sera <em>normale</em>. Si vous le jugez nécessaire, envoyez une copie à -&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de -l'entête du message. N'utilisez pas le champs CC: car de cette manière le -sujet du message ne contiendrait pas le numéro du bogue. +&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de +l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le +sujet du message ne contiendra pas le numéro du bogue. <p> Si le paquet est particulièrement important pour la distribution il vous faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer « <tt>RFA<footnote><em>Request For Adoption</em> : offre -d'adoption.</footnote>: <var>paquet</var> -- <var>courte -description</var></tt> » et lui affecter la sévérité <em>importante</em>. +d'adoption.</footnote>: <var>paquet</var> — <var>courte +description</var></tt> » et lui affecter la gravité <em>importante</em>. Envoyez une copie de votre rapport de bogue à la liste debian-devel comme décrit précédemment. @@ -2482,7 +2578,7 @@ susmentionn <p> Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas -correct -- ce serait une prise d'otage. Vous pouvez prendre contact avec le +correct — ce serait une prise d'otage. Vous pouvez prendre contact avec le responsable actuel et lui demander si vous pouvez prendre en charge ce paquet. Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable @@ -2559,7 +2655,7 @@ propre en d <p> Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les -bogues qui ont été rapportés plusieurs fois ou affecter la sévérité +bogues qui ont été rapportés plusieurs fois ou affecter la gravité <em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été corrigé. Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le responsable du paquet vous ne devez pas clore le rapport (à moins que vous @@ -2624,7 +2720,7 @@ L'auteur pr est facilement repérable dans le fichier <file>changelog</file>. <p> -Si vous voulez fermer un rapport de bogue manuellement -- à l'ancienne -- il +Si vous voulez fermer un rapport de bogue manuellement — à l'ancienne — il suffit d'envoyer le fichier <tt>.changes</tt> à l'adresse <email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du bogue. @@ -2651,7 +2747,7 @@ avec la derni <p> Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de -paquet -- plus de dix -- est une pratique que nous déconseillons. Prenez +paquet — plus de dix — est une pratique que nous déconseillons. Prenez toutes les mesures possibles pour éviter cette situation. Si le problème peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le paquet <package>lintian</package> pour générer une erreur ou un avertissement. @@ -2682,14 +2778,14 @@ Debian quand ils ont affaire <sect>Parrainer un paquet <p> Parrainer un paquet signifie télécharger un paquet dans l'archive Debian pour -un responsable qui n'est pas capable de le faire lui même : un futur -responsable. Parrainer un paquet signifie aussi assumer la résponsabilité de +un responsable qui n'est pas capable de le faire lui-même : un futur +responsable. Parrainer un paquet signifie aussi assumer la responsabilité de ce parrainage. <p> Les nouveaux responsables éprouvent souvent quelques difficultés pour créer -des paquets Debian -- ce qui est bien compréhensible. C'est là que le parrain -intervient. Il doit verifier que le paquet est suffisamment bon pour intégrer +des paquets Debian — ce qui est bien compréhensible. C'est là que le parrain +intervient. Il doit vérifier que le paquet est suffisamment bon pour intégrer la distribution. Notez que si le paquet est nouveau les administrateurs FTP devront eux aussi inspecter ce paquet avant de le laisser entrer. @@ -2703,17 +2799,17 @@ contr <p> Si vous êtes responsable de candidature<footnote>Application -manager</footnote> pour un developpeur, vous pouvez aussi être son parrain. De -cette manière, vous aurez la possibilité de vérifier vous même comment ce -candidat accomplit la partie `Tâches et compétences'<footnote>`Tasks and +manager</footnote> pour un développeur, vous pouvez aussi être son parrain. De +cette manière, vous aurez la possibilité de vérifier vous-même comment ce +candidat accomplit la partie « Tâches et compétences »<footnote>`Tasks and Skills'</footnote> de sa candidature. - <sect>Soutenir un nouveau responsable + <sect>Aider un nouveau responsable <p> -Consultez la page <url id="&url-newmaint-advocate;" name="Soutenir un futur +Consultez la page <url id="&url-newmaint-advocate;" name="Aider un futur responsable"> sur le site du projet Debian. @@ -2759,7 +2855,7 @@ documentations de ces paquets. Le paquet <package>dpkg-dev</package> contient les outils (y compris <prgn>dpkg-source</prgn>) nécessaires pour déballer, fabriquer et livrer des paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas -niveau indispensables pour créer et manipuler les paquets ; en tant que tels, +niveau indispensables pour créer et manipuler les paquets ; en tant que tels, ils sont indispensables à tout responsable Debian. @@ -2816,7 +2912,7 @@ Ce d <heading><package>debmake</package> <p> -<package>debmake</package> -- un précurseur de <package>debhelper</package> -- +<package>debmake</package> — un précurseur de <package>debhelper</package> — est un assistant moins modulaire pour manipuler le fichier <file>debian/rules</file>. Il inclut deux programmes principaux : <prgn>deb-make</prgn>, utile au développeur Debian pour convertir un paquet