-
-<p>
-Vous pouvez aussi accéder à un serveur situé en Allemagne : il vous suffit
-d'ouvrir une connexion anonyme sur :
-
-<p>
- <url id="&url-upload-erlangen;">.
-
-<p>
-Le téléchargement fait sur ce serveur doit être aussi complet que s'il
-était fait dans le répertoire <tt>Incoming</tt> sur <tt>ftp-master</tt> :
-il doit comporter le fichier <file>.changes</file> et tous les fichiers
-mentionnés dans ce dernier. Le serveur vérifie que le fichier
-<tt>.changes</tt> est bien signé avec la clé PGP d'un développeur Debian pour
-éviter que des faux paquets n'atteignent <tt>ftp-master</tt>. Vérifiez bien
-que le champ <tt>Maintainer</tt> du fichier <tt>.changes</tt> contient
-<em>votre</em> adresse électronique. De même que sur <tt>ftp-master</tt>,
-cette adresse est ensuite utilisée pour toutes les réponses.
-
-<p>
-Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire
-après le téléchargement, contrairement au serveur <tt>chiark</tt>. Vous
-devriez ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de
-votre paquet. Normalement, il devrait avoir été déplacé vers
-<tt>ftp-master</tt> ;
-vous serez informé par le même biais si une erreur s'est produite au cours du
-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.
-
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur
-<tt>erlangen</tt> ; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
-
-
- <sect1>Les autres serveurs
-
-<p>
-Un autre serveur est disponible aux États-Unis ; c'est un bon point
-de repli quand il est difficile de joindre <tt>ftp-master</tt>. Livrez vos
-paquets à l'adresse <url id="&url-upload-samosa;"> comme vous le feriez sur
-<tt>erlangen</tt>.
-<p>
-Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
-anonyme sur <url id="&url-upload-jp;">.
-
-
-
-
- <sect id="upload-announce">Annoncer une mise à jour
-
-<p>
-Quand un paquet est mis à jour, une annonce doit être envoyée sur l'une des
-listes « 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 <tt>.changes</tt>
-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 pour la distribution <em>stable</em>, l'annonce
-est envoyée sur la liste :
-
-<p>
-<tt> &email-debian-changes;.</tt>
-
-<p>
-S'il est mis à jour pour les distributions <em>unstable</em>,
-<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
-id="dupload">.
-
-
-
-
- <sect id="upload-notification">
- <heading>Notification de l'installation d'un nouveau paquet</heading>
-
-<p>
-Les administrateurs de l'archive Debian sont responsables de l'installation
-des mises à jour. La plupart des mises à jour sont gérées
-quotidiennement par le logiciel de gestion de l'archive <prgn>katie</prgn>.
-Les mises à jour
-de paquets sur la distribution <em>unstable</em>, en particulier, sont
-installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau
-paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois
-entre le téléchargement d'un paquet vers un serveur et son installation
-effective. Soyez patients.
-
-<p>
-Dans tous les cas vous recevrez un accusé de réception par courrier
-électronique indiquant que votre paquet a été installé et quels rapports
-de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
-les rapports de bogues que vous vouliez clore sont bien dans cette liste.
-
-<p>
-L'accusé de réception indique aussi la section dans laquelle le paquet a
-été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
-courrier qui vous informera de cette différence (voir plus loin).
-
-
-
-
- <sect1 id="override-file">Le fichier <em>override</em>
-
-<p>
-Les champs <tt>Section</tt> et <tt>Priority</tt> du fichier
-<file>debian/control</file> n'indiquent ni où le paquet sera installé dans
-l'archive Debian ni sa priorité. Afin de conserver la
-cohérence de l'archive, ce sont les administrateurs qui contrôlent ces
-champs. Les valeurs du fichier <file>debian/control</file> sont juste des
-indications.
-
-<p>
-Les administrateurs de l'archive indiquent les sections et priorités des paquets
-dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
-fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
-informé par courrier électronique quand votre paquet sera installé dans
-l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
-avant votre prochain téléchargement ou alors vous aurez envie de modifier le
-fichier <em>override</em>.
-
-<p>
-Pour modifier la section dans laquelle un paquet est archivé, vous devez
-d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
-envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
-paquet <package>ftp.debian.org</package> demandant la modification de la
-section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
-amènent à demander ces changements.
-
-<p>
-Pour en savoir plus sur le fichier <em>override</em>, reportez-vous à <manref
-name="dpkg-scanpackages" section="8">, &file-bts-mailing; et &file-bts-info;.
-
-
-
-
- <chapt id="nmu">Mise à jour indépendante
-
-<p>
-Dans certaines circonstances il est nécessaire qu'une personne autre que le
-responsable d'un paquet fasse une mise à jour de ce paquet. Ce type de mise à
-jour est désigné en anglais par l'expression <em>non-maintainer upload
-(NMU)</em>. Dans le présent document, nous traduisons librement cette
-expression par « mise à jour indépendante ».
-
-<p>
-Ces mises à jour indépendantes font partie du travail normal des porteurs qui
-compilent les paquets pour d'autres architectures (voir <ref id="porting">).
-Nous faisons aussi des mises à jour indépendantes quand un développeur Debian
-corrige le paquet d'un autre développeur pour éliminer un trou de sécurité
-ou un bogue paralysant. Cela se produit plus particulièrement en période de
-gel de la distribution de développement ou quand le responsable officiel du
-paquet ne peut pas fournir une correction dans un délai raisonnable.
-
-<p>
-Ce chapitre contient des informations qui vous expliqueront quand et comment
-faire des mises à jour indépendantes. Une distinction fondamentale doit être
-faite entre les mises à jour indépendantes sources et les mises à jour
-indépendantes binaires. Elle est explicitée dans la section suivante.
-
-
- <sect id="nmu-terms">Terminologie
-
-<p>
-Deux nouvelles expressions sont introduites dans cette section :
-« mise à jour indépendante source » et « mise à
-jour indépendante binaire ». Ces expressions ont une définition
-précie 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, un fichier <em>diff</em>
-modifié ou, plus rarement, des nouveaux sources amonts.
-
-<p>
-Une mise à jour indépendante binaire est la recompilation et l'archivage
-d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un
-effort de portage. Une mise à jour indépendante binaire est la livraison d'un
-paquet compilé (souvent pour une autre architecture) à condition que cette
-compilation n'ait pas nécessité de modifications des sources. Dans de
-nombreux cas, les porteurs
-sont obligés de modifier les sources pour les rendre compilables sur leur
-architecture cible ; 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>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 « mise à jour
-indépendante » seul, il s'agit des deux types de livraisons.
-
-
-
-
-
- <sect 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 <em>patch</em> 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.
-
-
- <sect 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. stable, instable ou
-gelée). 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>
-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
-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
-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
-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
-n'importe quelle mise à jour indépendante source, les recommandations de la
-section <ref id="nmu-guidelines"> doivent être respectées.
-
-<p>
-Les mises à jour indépendantes sont aussi acceptable pour la distribution
-instable mais seulement en dernier ressort
-ou avec une autorisation. Essayez d'abord ce qui suit et si cela ne fonctionne
-pas il est probablement correct de faire une mise à jour indépendante
-<em>(NMU)</em> :
-
-<p>
- <list compact>
- <item>
- Vérifiez que le bogue est bien référencé dans le système de suivi des
- bogues. S'il n'y est pas, faites un rapport de bogue.
-
- <item>
- Envoyez un courrier au responsable du paquet et proposez votre aide
- pour corriger le bogue. Donnez-lui quelques jours.
-
- <item>
- Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de
- suivi des bogues. Construisez le paquet et testez-le comme décrit dans
- la section <ref id="upload-checking">. Utilisez le paquet chez vous.
-
- <item>
- Attendez une réponse pendant quelques semaines.
-
- <item>
- Envoyez un courrier au responsable lui demandant son accord pour faire
- une mise à jour indépendante <em>(NMU)</em>.
-
- <item>
- Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
- bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
- possible.
-
- <item>
- Attendez une réponse une semaine encore.
-
- <item>
- Faites votre mise à jour indépendante comme décrit dans la section
- <ref id="nmu-guidelines">.
-
- </list>
-
-
-
-
-
-
- <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
- source ?
-
-<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 <em>patch</em> 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 faits lors d'une mise à jour indépendante.
-
-
-
-
-
- <sect1 id="nmu-version">Numéro de version pour les mises à jour
- indépendantes sources
-
-<p>
-Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
-changer, même pour la plus triviale des modifications. Notre système de
-gestion de paquets s'appuie sur ces numéros de version.
-
-<p>
-Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
-un numéro de version mineur à la partie <var>debian-revision</var> du numéro
-de version (la partie qui suit le dernier trait d'union). Ce numéro
-supplémentaire débutera à « 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 ». 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
-n'est pas suffisamment intelligent pour reconnaître « 0.1 »).
-
-<p>
-Attention, les porteurs qui ne font que recompiler les paquets pour d'autres
-architectures n'ont pas besoin de renuméroter les paquets. Les porteurs ne
-doivent utiliser de nouveaux numéros de version que s'ils modifient les
-paquets sources qu'ils recompilent, c'est-à-dire s'ils font une mise à jour
-indépendante source et non une mise à jour indépendante binaire.
-
-
-
-
-
- <sect1 id="nmu-changelog">
- <heading>Les mises à jour indépendantes sources doivent être
- mentionnées dans le fichier changelog</heading>
-
-<p>
-Une personne qui fait une mise à jour indépendante source doit ajouter une
-entrée dans le fichier <file>changelog</file> qui indique les bogues corrigés
-et qui précise pourquoi cette mise à jour était nécessaire. Cette entrée
-comportera l'adresse de la personne ayant fait la mise à jour ainsi que la
-version livrée.
-
-<p>
-Par convention, dans le cas d'une mise à jour indépendante source
-<em>(NMU)</em>, l'entrée du fichier changelog débute par la ligne
-
-<example>
- * Non-maintainer upload
-</example>
-
-
-
-
-
- <sect1 id="nmu-patch">Mise à jour indépendante source et système
- de suivi des bogues
-
-<p>
-Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
-modifications que possible et doit toujours envoyer ses modifications au
-système de suivi des bogues au format diff unifié (<tt>diff -u</tt>).
-
-<p>
-En cas de simple recompilation du paquet, le processus diffère
-suivant que vous agissez en tant que porteur ou pas. Si vous faites une mise
-à jour indépendante qui ne nécessite rien de plus qu'une recompilation et
-n'agissez pas en temps que porteur (i.e. une nouvelle bibliothèque partagée
-est disponible, un bogue a été corrigé dans <package>debhelper</package>),
-vous devez tout de même ajouter une entrée dans le fichier <em>changelog</em>;
-il y aura donc une modification. Si vous êtes porteur, vous êtes probablement
-en train de faire une mise à jour indépendante binaire. (Note : ce système ne
-tient pas compte des porteurs qui font des recompilations — tenez cela pour
-une faiblesse de notre système de gestion des paquets.)
-
-<p>
-Si la mise à jour indépendante source corrige des bogues, vous devez le
-<em>notifier</em> au système de suivi des bogues mais vous ne devez pas
-<em>clore</em> les rapports de bogue. Seul le responsable officiel d'un paquet
-et le rapporteur du bogue sont autorisés à fermer un rapport de bogue.
-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
-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>.
-
-<p>
-Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, 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
-indépendante, il devra s'assurer que cette nouvelle version corrige
-effectivement chacun des bogues corrigés dans la mise à jour indépendante.
-
-<p>
-De plus, le responsable officiel devrait <em>toujours</em> conserver les
-entrées documentant une mise à jour indépendante dans le fichier
-<file>changelog</file>.
-
-
-
-
-
-
- <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
-
-<p>
-Les paquets faisant l'objet d'une mise à jour indépendante source sont
-construits comme les
-autres. Sélectionnez une distribution en utilisant les règles décrites dans
-la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
-classique avec tout ce qui l'accompagne conformément à la description <ref
-id="upload">.
-
-<p>
-En fait, toutes les prescriptions de la section <ref id="upload"> sont
-applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
-idoine.
-
-<p>
-Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt>
-dans le fichier <file>debian/control</file>. Votre nom, mentionné dans
-l'entrée du fichier <file>debian/changelog</file> concernant la mise à jour,
-sera utilisé pour signer le fichier <tt>.changes</tt>.
-
-
-
-
- <chapt id="porting">Le portage
-
-<p>
-Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
-un porteur et même si vous n'utilisez qu'une architecture, il est de votre
-responsabilité de développeur d'être attentif aux questions de portabilité.
-C'est pourquoi il est important que vous lisiez ce chapitre même si vous
-n'êtes pas un porteur.
-
-<p>
-Porter un paquet consiste à faire un paquet binaire pour une architecture
-différente de celle du paquet binaire fait par le responsable du paquet.
-C'est une
-activité remarquable et essentielle. En fait, les porteurs sont à l'origine
-de la plupart des compilations de paquet Debian. Pour un paquet binaire
-<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
-autre architecture, soit un total de &number-of-arches; recompilations.
-
-
-
-
- <sect id="kind-to-porters">Être gentil avec les porteurs
-
-<p>
-Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
-grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
-modification. Malheureusement, c'est rarement le cas. Cette section contient
-une liste d'erreurs commises régulièrement par les responsables Debian —
-problèmes courants qui bloquent souvent les porteurs et compliquent
-inutilement leur travail.
-
-<p>
-Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
-remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
-étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine
-manière). Merci pour votre indulgence envers des rapports de bogues succincts ou
-peu clairs ; faites de votre mieux pour éliminer le problème.
-
-<p>
-Les problèmes les plus couramment rencontrés par les porteurs sont causés par
-des erreurs de mise en paquet dans le paquet source. Voici une
-<em>checklist</em> de choses auxquelles vous devez être attentif :
-
- <enumlist>
- <item>
- Vérifiez que les champs <tt>Build-Depends</tt> et
- <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
- corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
- paquet <package>debootstrap</package> pour créer un environnement
- <em>unstable</em> <em>chrooté</em>. Dans cet environnement
- <em>chrooté</em> il faudra installer le paquet
- <package>build-essential</package> et tous les paquets mentionnés dans
- les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
- Ensuite, vous essayerez de fabriquer votre paquet dans cette
- environnement.
- <p>
- Consultez le <url id="&url-debian-policy;" name="Debian Policy
- Manual"> pour en savoir plus sur les dépendances de fabrication.
- <item>
- Ne choisissez pas d'autre valeur que <em>all</em> ou <em>any</em> pour
- le champ architecture sans avoir de bonnes raisons pour le faire. Trop
- souvent, les développeurs ne respectent pas les instructions du
- <url id="&url-debian-policy;" name="Debian Policy Manual">. Choisir
- la valeur « i386 » est la plupart du temps incorrect.
-
- <item>
- Vérifiez que votre paquet source est bon. Faites <tt>dpkg-source -x
- <var>package</var>.dsc</tt> pour vous assurer que le paquet se
- désarchive correctement. En utilisant le résultat de ce test,
- construisez votre paquet binaire à l'aide de la commande
- <tt>dpkg-buildpackage</tt>.
-
- <item>
- Vérifiez que les fichiers <file>debian/files</file> et
- <file>debian/substvars</file> ne sont pas dans votre paquet source.
- Ils doivent être effacés par la cible <em>clean</em> de
- <file>debian/rules</file>.
-
- <item>
- Assurez-vous que vous ne vous appuyez pas sur des éléments de
- configuration ou des logiciels installés ou modifiés localement. Par
- exemple, vous ne devriez jamais appeler des programmes du répertoire
- <file>/usr/local/bin</file> ou de répertoires équivalents. Essayez de ne pas vous
- appuyer sur des logiciels configurés de manière spéciale. Essayez de
- construire votre paquet sur une autre machine, même s'il s'agit de la
- même architecture.
-
- <item>
- Ne vous appuyez pas sur une installation préexistante de votre paquet
- (un sous-cas de la remarque précédente).
-
- <item>
- Si possible, ne vous appuyez pas sur une particularité présente dans
- un compilateur précis ou dans certaine version d'un compilateur. Si
- vous ne pouvez pas faire autrement, assurez-vous que les dépendances
- de fabrication reflètent bien cette restriction. Dans ce cas, vous
- cherchez sûrement les problèmes car quelques architectures pourraient
- choisir un compilateur différent.
-
- <item>
- Vérifiez que votre <file>debian/rules</file> distingue les cibles
- <em>binary-arch</em> et <em>binary-indep</em> comme l'exige le
- <em>Debian packaging manual</em>. Vérifiez que ces cibles sont
- indépendantes l'une de l'autre, c'est à dire qu'il n'est pas
- nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre.
- Pour vérifier cela, essayez d'exécuter <tt>dpkg-buildpackage -b</tt>.
-
- </enumlist>
-
-
-
-
- <sect id="porter-guidelines">Instructions pour les mises à jour des
- porteurs
-
-<p>
-Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez
-de la chance et votre travail est facile. Cette section s'applique dans ce
-cas ; elle décrit comment construire et installer correctement votre mise à
-jour indépendante binaire dans l'archive Debian. Si vous devez modifier le
-paquet pour le rendre compilable sur votre architecture cible vous devez faire
-une mise à jour des sources, consultez la section <ref id="nmu-guidelines">.
-
-<p>
-Pour une mise à jour indépendante binaire, ne faites pas de changement
-dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet
-source (cela inclut <file>debian/changelog</file>).
-
-<p>
-La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
-<tt>dpkg-buildpackage -B -e<var>adresse-porteur</var></tt>. Bien sûr,
-remplacez <var>adresse-porteur</var> par votre adresse électronique. Cette
-commande construira les portions du paquet qui dépendent de l'architecture, en
-utilisant la cible <em>binary-arch</em> de <file>debian/rules</file>.
-
-
- <sect1 id="recompile-nmu-versioning">
- <heading>Numéro de version des mises à jour indépendantes
- binaires</heading>
-
-<p>
-Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
-tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
-changer le numéro de version pour que le système de comparaison des numéros de
-version fonctionne correctement. Ce type de mise à jour reste une mise à jour
-indépendante binaire — 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 ».
-
-
-
-
- <sect1 id="source-nmu-when-porter"> <heading>Quand faire une mise à
- jour indépendante source pour un portage ?</heading>
-
-<p>
-Les porteurs qui font des mises à jour indépendantes sources suivent
-généralement les instructions de la section <ref id="nmu"> tout comme les
-non-porteurs. Les délais d'attente sont cependant plus courts car les porteurs
-doivent manipuler un grand nombre de paquets.
-
-<p>
-À nouveau, la situation diffère selon la distribution visée. Une correction
-cruciale (i.e. rendre un paquet compilable sur une architecture supportée par
-la prochaine distribution) peut être installée <em>sans</em> délai pour la
-distribution gelée.
-
-<p>
-Si vous êtes porteur et faites une mise à jour pour <em>unstable</em>, les
-instructions précédentes sont applicables à deux différences près. Tout
-d'abord, le temps d'attente raisonnable — 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 sévérité <em>sérieuse</em> (i.e.
-<em>serious</em>) ou supérieure quand ils envoient leur rapport au système de
-suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un
-paquet binaire pour chaque architecture supportée au moment de la sortie de la
-distribution. Il est très important d'avoir un paquet source et un paquet
-binaire pour toutes les architectures pour être conforme à plusieurs licences.
-
-<p>
-Les porteurs doivent éviter d'implémenter des contournements pour
-des bogues de l'environnement de compilation, du noyau ou de la libc. Quelques
-fois ces contournements sont inévitables. Si vous devez faire quelque chose de
-ce genre, marquez proprement vos
-modifications avec des <tt>#ifdef</tt> et documentez votre contournement pour
-que l'on sache le retirer une fois que le problème aura disparu.
-
-<p>
-Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de
-leur travail pendant le délai d'attente. Ainsi d'autres personnes peuvent
-bénéficier du travail du porteur même pendant ce délai. Bien sûr ces adresses
-n'ont rien d'officiel alors soyez sur vos gardes si vous les utilisez.
-
-
-
-
- <sect>Outils pour les porteurs
-
-<p>
-Il y a plusieurs outils pour le travail de portage. Cette section contient
-une courte description de ces outils ; reportez-vous à la documentation de
-leurs paquets ou aux références citées ci-après pour une description complète.
-
-
-
-
- <sect1 id="quinn-diff">
- <heading><package>quinn-diff</package>
-
-<p>
-<package>quinn-diff</package> est utilisé pour localiser les différences d'une
-architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de
-l'architecture <var>X</var> doivent être portés sur l'architecture <var>Y</var>.
-
-
-
-
-
- <sect1 id="buildd">
- <heading><package>buildd</package>
-
-<p>
-Le système <package>buildd</package> est un système distribué pour la
-compilation d'une distribution. Il est habituellement utilisé en conjonction
-avec des automates de compilation ; 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. Il regroupe un ensemble de composants très utiles,
-continuellement utilisés mais non encore mis en paquet, tels que
-<prgn>andrea</prgn>, <prgn>sbuild</prgn> et <prgn>wanna-build</prgn>.
-
-<p>
-Une partie des informations produites par <package>buildd</package> — 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
-intéressantes pour tous (une version de Debian compilée avec des vérifications
-relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi de recompiler
-rapidement toute une distribution.
-
-
-
-
- <sect1 id="dpkg-cross">
- <heading><package>dpkg-cross</package>
-
-<p>
-<package>dpkg-cross</package> est un outil qui installe les bibliothèques et
-les entêtes nécessaires à une compilation croisée<footnote><em>cross-compilation</em>
-</footnote> d'une manière similaire à <package>dpkg</package>. De plus
-<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
-améliorés pour supporter les compilations croisées.
-
-
-
-
-
- <chapt id="archive-manip">
- <heading>Déplacer, effacer, renommer, adopter et abandonner des
- paquets</heading>
-
-<p>
-Certaines manipulations de l'archive ne sont pas accessibles avec le processus
-de mise à jour automatisé. Elles sont appliquées manuellement par les
-développeurs. Ce chapitre décrit ce qu'il faut faire dans ces situations.
-
-
-
-
- <sect>Déplacer des paquets
-
-<p>
-Parfois un paquet pourra changer de section. Une nouvelle version d'un paquet
-de la section <tt>non-free</tt> pourrait par exemple être distribuée sous
-licence LGP GNU ; dans ce cas le paquet doit être déplacé dans la section
-<tt>main</tt> ou <tt>contrib</tt><footnote> Reportez-vous au <url
-id="&url-debian-policy;" name="Debian Policy Manual"> pour savoir dans quelle
-section un paquet doit être classé.</footnote>.
-
-<p>
-Si vous avez besoin de modifier la section de l'un de vos paquets, modifiez
-les informations de contrôle du paquet pour le placer dans la section désirée
-et téléchargez à nouveau votre paquet dans l'archive. Reportez-vous au
-<url id="&url-debian-policy;" name="Debian Policy Manual"> pour en savoir
-plus. Lisez attentivement le rapport d'installation qui vous sera envoyé lors
-de l'archivage de votre paquet. Si pour une raison ou une autre le paquet
-est toujours à son ancien emplacement, envoyez un rapport de bogue sur le
-pseudo-paquet <tt>ftp.debian.org</tt> demandant la suppression dudit paquet.
-Décrivez précisément vos manipulations car il pourrait s'agir d'un bogue dans
-le logiciel de gestion de l'archive.
-
-<p>
-Si vous avez besoin de modifier la sous-section de l'un de vos paquets
-(<tt>devel</tt> ou <tt>admin</tt> par exemple) la procédure est légèrement
-différente. Modifiez la sous-section dans le fichier de contrôle de votre
-paquet et téléchargez-le. Il vous faudra ensuite demander la modification du
-fichier <em>override</em> comme décrit dans la section <ref
-id="override-file">.
-
-
-
-
- <sect id="removing-pkgs">Supprimer des paquets
-
-<p>
-Si pour une raison ou une autre vous avez besoin de supprimer un paquet
-de l'archive (disons qu'il s'agit d'une vieille bibliothèque devenue inutile,
-que l'on conservait pour des raisons de compatibilité), il vous faudra
-envoyer un rapport de bogue concernant le pseudo-paquet
-<tt>ftp.debian.org</tt> et demandant sa suppression. N'oubliez pas de
-préciser de quelle distribution le paquet doit être supprimé.
-
-<p>
-Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
-autres développeurs sur la liste &email-debian-devel;. Le programme
-<prgn>apt-cache</prgn> du paquet <package>apt</package> pourra aussi vous être
-utile. La commande <tt>apt-cache showpkg <var>package</var> </tt> vous
-indiquera, entre autres, les paquets qui dépendent de <var>package </var>.
-
- <sect1>Supprimer des paquets dans <tt>Incoming</tt>
-<p>
-Si vous décidez de supprimer un paquet de la section <tt>Incoming</tt>, il
-serait gentil de l'annoncer sur la liste de diffusion appropriée
-(&email-debian-changes; ou &email-debian-devel-changes;). Ce n'est pas
-obligatoire.
-
-
-
- <sect>Remplacer ou renommer un paquet
-
-<p>
-Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de le
-renommer. Dans ce cas, vous devrez intervenir en deux étapes. D'abord,
-modifiez votre fichier <file>debian/control</file> pour que votre paquet
-renommé remplace et entre en conflit avec le nom de paquet que vous voulez
-remplacer. Reportez-vous au <url id="&url-debian-policy;" name="Debian Policy
-Manual"> pour les détails. Une fois que votre paquet est installé dans
-l'archive, faites un rapport de bogue concernant le pseudo-paquet
-<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
-l'archive, faites un rapport de bogue concernant le pseudo-paquet
-<tt>ftp.debian.org</tt> et demandant la suppression du paquet mal nommé.
-
-
-
-
-
- <sect id="orphaning">Abandonner un paquet
-