-Notez qu'avec l'introduction de la nouvelle organisation de l'archive (voir le
-répertoire racine <em>pool/</em>), les sous-sections matérialisées par des
-répertoires pourraient disparaître à l'avenir. Elles seront cependant
-conservées dans le champ <tt>Section</tt> de l'en-tête des paquets.
-
-
-
-
- <sect>Les paquets
-
-<p>
-Il existe deux types de paquets Debian : les paquets sources et les
-paquets binaires.
-
-<p>
-Les paquets sources sont constitués de deux ou trois fichiers :
-
- <list compact>
- <item>
- un fichier <tt>.dsc</tt> et un fichier <tt>.tar.gz</tt> ou,
-
- <item>
- un fichier <tt>.dsc</tt>, un fichier <tt>.orig.tar.gz</tt> et un
- fichier <tt>.diff.gz</tt>.
-
- </list>
-
-<p>
-Si un paquet est développé spécifiquement pour le projet Debian et n'est pas
-distribué en dehors de Debian, il n'y a qu'un fichier <tt>.tar.gz</tt> qui
-contient les sources du programme. Si un paquet est distribué ailleurs, le
-fichier <tt>.orig.tar.gz</tt> contient ce que l'on appelle <em>code source
-amont</em>, c'est-à-dire le code source distribué par le <em>mainteneur
-amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le
-fichier <tt>.diff.gz</tt> contient les modifications faites par le responsable
-Debian.
-
-<p>
-Le fichier <tt>.dsc</tt> liste tous les fichiers sources avec leurs sommes de
-contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
-concernant le paquet (responsable, version, etc).
-
-
-
-
- <sect>Les répertoires des distributions
-
-<p>
-L'organisation des répertoires présentée précédemment est elle-même englobée
-par les <em>répertoires des distributions</em>. Chaque distribution est
-incluse dans le répertoire <tt>pool</tt> à la racine de l'archive Debian.
-
-<p>
-En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par
-exemple, sur le site miroir <ftpsite>ftp.us.debian.org</ftpsite>, l'archive
-Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
-courant. Un autre emplacement courant est <tt>/pub/debian</tt>.
-
-<p>
-Une distribution est composée de paquets Debian sources et binaires et des
-fichiers <tt>Sources</tt> et <tt>Packages</tt> correspondants. Ces derniers
-contiennent la description de tous les paquets. Les premiers sont
-conservés dans le répertoire <tt>pool/</tt> tandis que les seconds sont
-conservés dans le répertoire <tt>dists/</tt> de l'archive (pour des questions
-de compatibilité descendante)
-
-
-
-
- <sect1 id="life-cycle"><em>Stable</em>, <em>testing</em>,
- <em>unstable</em> et parfois <em>frozen</em>
-
-<p>
-Il y a toujours une distribution appelée <em>stable</em> (dans le répertoire
-<tt>dists/stable</tt>), une distribution appelée <em>testing</em> (dans le
-répertoire <tt>dists/testing</tt>) et une distribution appelée
-<em>unstable</em> (dans le répertoire <tt>dists/unstable</tt>). Ceci reflète
-le processus de développement du projet Debian.
-
-<p>
-Les développements se font sur la distribution <em>unstable</em><footnote>
-<em>unstable</em> signifie « instable »</footnote> (c'est pourquoi
-elle est aussi appelée <em>distribution de développement</em>). Chaque
-développeur Debian peut modifier ses paquets à tout moment dans cette
-distribution. Ainsi son contenu change tous les jours. Comme aucun effort
-particulier n'est fait pour s'assurer que tout fonctionne correctement dans
-cette distribution, elle est parfois <em>instable</em>.
-
-<p>
-Les paquets sont copiés de <em>unstable</em> vers <em>testing</em> s'ils
-satisfont certains critères. Pour entrer dans la distribution <em>testing</em>
-un paquet doit faire partie de l'archive depuis deux semaines et ne doit pas
-avoir de bogue bloquant pour la distribution<footnote><em>Release critical
-bug</em></footnote>. Passée cette période, le paquet sera installé dans
-<em>testing</em> dès que les paquets dont il dépend y seront. Ce processus est
-automatique.
-
-<p>
-Après une période de développement, quand le responsable de
-distribution<footnote><em>Release manager</em></footnote> le juge opportun, la
-distribution <em>testing</em> est renommée <em>frozen</em>. Une fois que cela
-est fait, aucun changement n'est autorisé sur cette distribution en dehors des
-corrections de bogues ; c'est pourquoi nous l'appelons <em>frozen<footnote>
-<em>frozen</em> signifie « gelée »</footnote></em>. Après un mois
-ou un peu plus selon l'avancement, la distribution entre dans une phase de
-« gel complet » où les seules modifications acceptées concernent la
-procédure d'installation. Cette phase s'appelle un « cycle de test »
-et cela peut durer jusqu'à deux semaines. Il peut y avoir plusieurs cycles de
-tests avant que le responsable de distribution ne la déclare prête pour la
-diffusion. À la fin du dernier cycle de test, la distribution <em>frozen</em>
-est renommée <em>stable</em>, remplaçant l'ancienne distribution <em>stable</em> qui
-est enlevée à cette occasion.
-
-<p>
-Ce cycle de développement est basé sur l'idée que la distribution
-<em>instable</em> devient <em>stable</em> après une période de test en tant
-que distribution <em>gelée</em>. Une distribution contient inévitablement des
-bogues, même si elle est classée stable. C'est pourquoi les distributions
-stables sont mises à jour de temps en temps. Les corrections introduites sont
-testées avec une grande attention et ajoutées individuellement à l'archive
-pour diminuer les risques d'introduire de nouveaux bogues. Vous pouvez trouver
-des paquets proposés pour les mises à jour de <em>stable</em> dans le
-répertoire <tt>proposed-updates</tt>. De temps en temps, les paquets de ce
-répertoire qui ne présentent pas de problème sont installés dans la
-distribution <em>stable</em> et le numéro de révision de cette distribution
-est incrémenté (« 1.3 » devient « 1.3r1 »,
-« 2.0r2 » devient « 2.0r3 » et ainsi de suite).
-
-<p>
-Notez que pendant la période de gel les développements continuent sur la
-distribution instable car cette distribution reste en place quand
-<em>testing</em> devient <em>frozen</em>. Quand la distribution
-<em>frozen</em> devient officiellement <em>stable</em>, l'ancienne distribution
-stable est entièrement supprimée de l'archive Debian (elle reste cependant
-disponible à l'adresse <tt>&archive-host;</tt>).
-
-<p>
-En résumé, les distributions <em>stable</em>, <em>testing</em> et
-<em>unstable</em> sont disponibles en permanence et de temps en temps, une
-distribution <em>frozen</em> apparaît pour quelques mois.
-
-
-
-
-
- <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 ou bien pour des logiciels qui sont vraiment trop instables pour être
-inclus dans la distribution <em>unstable</em> (mais pour qui une mise en
-paquet est justifiée). Les utilisateurs qui téléchargent et
-installent des paquets depuis
-<em>experimental</em> sont prévenus : on ne peut pas faire confiance à la
-distribution <em>experimental</em>.
-
-<p>
-Si un logiciel risque de causer des dégats importants, il sera
-sûrement préférable de le mettre dans la distribution <em>experimental</em>.
-Un système de fichier compressé, par exemple, devrait probablement aller dans
-<em>experimental</em>.
-
-<p>
-Une nouvelle version amont qui ajoute de nouvelles fonctions tout en
-supprimant de nombreuses autres ne devra pas être téléchargée dans l'archive
-Debian, elle pourra cependant être téléchargée dans <em>experimental</em>. Une
-nouvelle version non finalisée d'un logiciel qui utilise une méthode de
-configuration complètement différente pourrait aller dans
-<em>experimental</em> au gré du responsable. Si vous travaillez sur
-un cas de mise à jour complexe ou incompatible vous pouvez aussi utiliser
-<em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
-accès aux testeurs.
-
-<p>
-Quelques logiciels expérimentaux peuvent 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 ne risque pas d'endommager le système ira
-directement dans <em>unstable</em>.
-
-<p>
-Une alternative à <em>experimental</em> consiste à utiliser vos pages
-personnelles sur le serveur <tt>people.debian.org</tt>
-(<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 »; 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
-du contenu habituel d'une distribution Debian, « sid » contient des
-paquets pour des architectures qui ne sont pas encore officiellement
-supportées ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
-architectures doivent rejoindre les architectures supportées à une date
-future.
-
-<p>
-Comme Debian est un projet de développement ouvert (i.e. tout le monde peut
-participer et suivre les développements) même les distributions
-<em>unstable</em> et <em>testing</em> sont disponibles sur les serveurs HTTP
-et FTP de Debian.
-
-<p>
-Si nous avions nommé le répertoire qui contient la prochaine version àc
-diffuser « testing », il aurait fallu le renommer
-« stable » au moment de la diffusion, ce qui aurait forcé les
-miroirs FTP à re-télécharger la distribution complète (qui est plutôt
-volumineuse).
-
-<p>
-D'un autre coté, si une distribution s'appelle <em>Debian-x.y</em> dès le
-départ, des personnes pourraient s'imaginer que la distribution Debian
-<em>x.y</em> est disponible. (Cela s'est produit par le passé, un distributeur
-avait gravé des cédéroms Debian 1.0 en utilisant une version de développement
-pré-1.0. C'est pour cette raison que la première version officielle était la
-version 1.1 et non la 1.0.)
-
-<p>
-En conséquence, les noms de répertoire des distributions dans l'archive sont
-déterminés par leurs noms de code et non par leur statut (exemple : slink). Ces
-noms sont identiques pendant la période de développement et une fois la
-distribution diffusée ; des liens symboliques, qui peuvent être modifiés
-facilement, indiquent la distribution stable actuelle.
-
-<p>
-Tout ceci explique pourquoi les répertoires des distributions sont nommés à
-partir des noms de code des distributions alors que <em>stable</em>,
-<em>testing</em>, <em>unstable</em> et <em>frozen</em> sont des liens
-symboliques qui pointent vers les répertoires appropriés.
-
-
-
-
-
- <chapt id="upload">La mise à jour d'un paquet
-
-
- <sect>Annoncer un nouveau paquet
-
-<p>
-Si vous voulez créer un nouveau paquet pour la distribution Debian vous
-devriez commencer par consulter la liste des <url id="&url-wnpp;"
-name="paquets en souffrance et paquets souhaités">. Vous pourrez ainsi
-vérifier que personne ne travaille déjà sur ce paquet et éviter un double
-travail. Consultez aussi cette page si vous voulez en savoir plus.
-
-<p>
-Supposons que personne ne travaille sur le paquet que vous visez, vous devez
-alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
-pseudo-paquet <tt>wnpp</tt>. Ce
-courrier devra décrire le paquet que vous projetez de créer, la licence de ce
-paquet et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
-pas limitative.
-
-<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 gravité du bogue sera
-<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champ 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
-<tt>Closes: bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file>
-du nouveau paquet. Cette indication fermera automatiquement le rapport de
-bogue à l'installation du nouveau paquet sur les serveurs d'archivage (voir
-<ref id="upload-bugfix">).
-
-<p>
-Il y a plusieurs raisons qui nous poussent à demander aux responsables d'annoncer
-leurs intentions :
-
- <list compact>
- <item>
- Les responsables ont ainsi la possibilité de puiser dans l'expérience
- des autres responsables et cela leur permet de savoir si une autre personne
- travaille déjà dessus.
-
- <item>
- D'autres personnes qui envisagent de travailler sur le même paquet
- apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
- être partagé.
-
- <item>
- Cela permet aux autres responsables d'en savoir plus sur le nouveau
- paquet que ne le permettent la description d'une ligne et l'habituelle
- entrée « <em>Initial release</em> » que l'on trouve dans les
- fichiers <em>changelog</em> qui sont postés sur
- <tt>debian-devel-changes</tt>.
-
- <p>
- C'est une information utile pour les gens qui utilisent la
- distribution <em>unstable</em> et qui sont nos premiers testeurs. Nous
- devons faciliter la tâche de ces gens.
-
- <p>
- Avec ces annonces, les développeurs Debian et toutes les autres personnes
- intéressées peuvent se faire une meilleure idée des évolutions et nouveautés du
- projet.
-
- </list>
-
-
- <sect id="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) :
- <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
- pas les messages générés par <prgn>lintian</prgn> essayez l'option
- <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
- bavard dans sa description du problème.
- <p>
- En principe, un paquet pour lequel
- <prgn>lintian</prgn> génère des erreurs (elles commencent par
- <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
- <p>
- Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
- section lintian <ref id="lintian">.
-
- <item>
- Faites régresser le paquet
- vers sa version précédente si elle existe — cela permet de tester les
- scripts <tt>postrm</tt> et <tt>prerm</tt>.
-
- <item>
- Désinstallez le paquet et réinstallez-le.
-
- </list>
-
-
-
- <sect>Générer le fichier « changes »
-<p>
-Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
-être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
-l'administrateur de l'archive Debian ce qu'il doit faire du paquet. Il est en
-général créé par <prgn>dpkg-genchanges</prgn> au cours du processus de
-fabrication du paquet.
-
-<p>
-Le fichier <tt>changes</tt> est un fichier de contrôle qui contient les champs
-suivants :
-
-<p>
-&control-file-fields;
-
-<p>
-Tous ces champs sont obligatoires pour une installation sur les serveurs
-Debian. Vous pouvez consulter la liste des champs de contrôle dans le
-<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
-les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
-automatiquement avec le champ <tt>Description</tt> (voir <ref
-id="upload-bugfix">).
-
-
- <sect1>L'archive des sources amonts
-<p>
-La première fois qu'un paquet est installé dans l'archive pour une version
-amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
-téléchargé et mentionné dans le fichier <tt>.changes</tt>. Par la suite, ce
-fichier <tt>tar</tt> sera utilisé pour générer les fichiers <tt>diff</tt> et
-<tt>.dsc</tt> et il ne sera pas nécessaire de le télécharger à nouveau.
-
-<p>
-Par défaut, <prgn>dpkg-genchanges</prgn> et <prgn>dpkg-buildpackage</prgn>
-incluront le fichier <tt>tar</tt> amont si et seulement si le numéro de
-révision du paquet source est 0 ou 1, ce qui indique une nouvelle version
-amont. Ce comportement peut être modifié en utilisant <tt>-sa</tt> pour
-l'inclure systématiquement ou <tt>-sd</tt> pour ne jamais l'inclure.
-
-<p>
-Si la mise à jour ne contient pas le fichier <tt>tar</tt> des sources
-originaux, <prgn>dpkg-source</prgn> <em>doit</em>, pour construire les
-fichiers <tt>.dsc</tt> et <tt>diff</tt> de la mise à jour, utilisez un fichier
-<tt>tar</tt> identique à l'octet près à celui sur le serveur. Si pour une
-raison ou pour une autre il y a une différence, la nouvelle version de ce
-fichier doit à nouveau être incluse dans la mise à jour (en utilisant l'option
-<tt>-sa</tt> par exemple).
-
-
-
-
- <sect1 id="upload-dist">Choisir une distribution
-
-<p>
-Le champ <tt>Distribution</tt>, qui provient de la première ligne du fichier
-<file>debian/changelog</file>, indique à quelle distribution le paquet est
-destiné.
-
-<p>
-Il y a 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 un paquet de la distribution <em>frozen</em>
-
-<p>
-Le gel de la distribution est un moment crucial pour Debian. C'est l'occasion
-de synchroniser et de stabiliser notre distribution en un tout
-cohérent. Il faut donc être très vigilant quand on fait une mise à jour
-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
-qu'il fonctionne de la manière attendue.
-
-<p>
-Le mot d'ordre pour télécharger vers <em>frozen</em> est : <strong>pas de code
-nouveau</strong>. C'est une chose difficile à quantifier, voici quelques
-conseils :
-
-<p>
- <list compact>
- <item>
- 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 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 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 gravité <em>wishlist</em> ne sont pas autorisées (ce
- ne sont pas vraiment des bogues après tout).
-
- <item>
- Les corrections liées à la documentation sont autorisés car il est
- important d'avoir une bonne documentation.
-
- </list>
-
-<p>
-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 gravité du bogue corrigé et
-la gravité du bogue introduit par la correction.
-
-
- <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>
-
-<p>
-Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
-sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
-pour y être testé avant d'être effectivement inclus dans <em>stable</em>.
-
-<p>
-Une livraison pour la distribution <em>stable</em> requière des soins
-supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
-que dans les cas suivants :
-
- <list>
- <item>un problème de sécurité (un avis de sécurité
- Debian<footnote>Debian security advisory.</footnote>),
- <item>un probleme fonctionnel vraiment critique,
- <item>un paquet devenu ininstallable,
- <item>un paquet indisponible pour une architecture.
- </list>
-
-<p>
-Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
-important car même une modification triviale peut causer un bogue plus
-tard. Livrer une nouvelle version amont d'un logiciel pour corriger un
-problème de sécurité est désapprouvé ; dans la plupart des cas la
-bonne solution consiste à prendre la rustine correspondante de la
-nouvelle version amont et à l'appliquer à l'ancienne (faire un
-portage (<em>backport</em>) de la rustine.
-
-<p>
-Les paquets livrés pour <em>stable</em> doivent être compilés avec la
-distribution <em>stable</em> pour que leurs dépendances se limitent aux
-bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
-un paquet livré pour la distribution <em>stable</em> qui dépend d'une
-bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
-Modifier les dépendances d'autres paquets (en manipulant le champ
-<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
-ininstallables, est fortement déconseillé.
-
-<p>
-L'équipe responsable de la distribution<footnote><em>the Release
-team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera
-régulièrement le contenu de <em>proposed-updates</em> et décidera si votre
-paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis
-(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog,
-vos changements pour une livraison vers <em>stable</em> sinon le paquet ne
-sera pas considéré.
-
-
-
- <sect id="uploading">Mettre à jour un paquet
-
-
- <sect1 id="upload-ftp-master">Installer un paquet sur
- <tt>ftp-master</tt>
-
-<p>
-Pour installer un paquet vous avez besoin d'un compte sur
-<ftpsite>ftp-master</ftpsite>, ce que vous devez avoir en tant que
-développeur Debian. Si vous utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn>
-pour télécharger vos paquets, placez-les dans
-<tt>&us-upload-dir;</tt>. Si vous utilisez un FTP anonyme,
-placez-les dans <ftppath>/pub/UploadQueue/</ftppath>.
-
-<p>
-<em>Note :</em> ne téléchargez pas de paquet soumis aux lois de contrôle des
-exportations américaines sur le serveur <tt>ftp-master</tt>, ni sur les serveurs
-<tt>chiark</tt> et <tt>erlangen</tt>. Cet interdit couvre à peu près tous les
-logiciels de cryptographie ainsi que quelques logiciels liés aux logiciels de
-cryptographie comme les clients de courrier électronique qui utilisent le
-cryptage et l'authentification PGP. Ces logiciels doivent être téléchargés sur
-le serveur <tt>non-us</tt>. Reportez-vous à la section <ref
-id="upload-non-us"> pour en savoir plus. Si vous ne savez pas si votre paquet
-est soumis aux lois de contrôle des exportations américaines posez la question sur la
-liste &email-debian-devel;.
-
-<p>
-Le paquet <package>dupload</package> pourra vous faciliter le travail lors du
-téléchargement. Ce programme, bien pratique, est configuré par défaut pour
-se connecter par FTP sur les serveurs <tt>ftp-master</tt>,
-<tt>chiark</tt> et <tt>erlangen</tt>. Il peut aussi être configuré pour
-utiliser <prgn>ssh</prgn> ou <prgn>rsync</prgn>. Se reporter à <manref
-name="dupload" section="1"> et <manref name="dupload" section="5"> pour en
-savoir plus.
-
-<p>
-Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en fera le
-logiciel de maintenance de l'archive en exécutant <prgn>dinstall</prgn>
-sur votre fichier <file>.changes</file> :
-
-<example>dinstall -n foo.changes</example>
-
-
-
-
-
- <sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
- (pandora)
-
-<p>
-Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
-exportations américain ne doivent pas être installés sur <tt>ftp-master</tt>.
-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 vos fichiers dans le
-répertoire <ftppath>/pub/UploadQueue/</ftppath>.
-
-<p>
-Le programme <prgn>dupload</prgn> est, lui aussi, capable de télécharger sur
-<tt>non-us</tt> ; consultez la documentation de ce programme pour en savoir
-plus.
-
-<p>
-Tout comme sur <tt>ftp-master</tt>, vous pouvez vérifier votre téléchargement
-avec :
-
-<example>dinstall -n foo.changes</example>
-
-
-<p>
-Attention, les personnes résidant aux États-Unis et les citoyens américains
-sont soumis à des restrictions sur l'exportation des logiciels de
-cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter
-quelques logiciels de cryptographie soumis à une obligation de déclaration
-auprès du département du commerce américain.
-
-<p>
-Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens
-américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être
-vigilants en le faisant. Nous recommandons aux responsables concernés de
-prendre toutes les précautions nécessaires, <em>y compris la consultation d'un
-juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en
-livrant un paquet sur <tt>non-US</tt>.
-
-<p>
-Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>
-les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
-name="procédure décrite par le gouvernement américain">. Les responsables de
-paquets <em>non-US/non-free</em> devront en plus consulter les <url
-id="&url-notification-of-export;" name="règles de déclaration d'exportation
-pour les logiciels commerciaux">.
-
-<p>
-Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
-juridique. Une fois encore, nous recommandons aux résidents et citoyens
-américains de consulter un juriste avant de livrer un paquet sur
-<tt>non-US</tt>.
-
-
- <sect1>Installer un paquet via <tt>chiark</tt>
-
-<p>
-Si votre connexion vers <tt>ftp-master</tt> est lente, vous avez plusieurs
-possibilités. L'une d'elles consiste à télécharger vos fichiers dans
-<tt>Incoming</tt> en passant par le serveur <tt>chiark</tt> en Europe. Pour
-les détails consultez <url id="&url-chiark-readme;">.
-
-<p>
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
-lois de contrôle des exportations américaines sur <tt>chiark</tt>.
-Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
-les indications de la section <ref id="upload-ftp-master"> sont applicables ici
-aussi.
-
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur
-<tt>chiark</tt> ; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
- <sect1>Installer un paquet via <tt>erlangen</tt>
-
-<p>
-Vous pouvez aussi accéder à un serveur situé en Allemagne : 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>
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux
-lois de contrôle des exportations américaines sur <tt>erlangen</tt>.
-Les paquets téléchargés sur ce serveur sont redirigés vers <tt>ftp-master</tt>,
-les indications de la section <ref id="upload-ftp-master"> sont applicables ici
-aussi.
-
-<p>
-Le programme <prgn>dupload</prgn> est capable de télécharger sur
-<tt>erlangen</tt> ; consultez la documentation de ce programme pour en savoir
-plus.
-
-
-
-
-
- <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>
-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 rustines qui le méritent au
-système de suivi des bogues. Les responsables apprécient presque toujours les
-rustines et les rapports de bogue soignés.
-
-
- <sect id="nmu-when">Quand faire une mise à jour indépendante source ?
-
-<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>
-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,
-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 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
-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 rustine au système de
- suivi des bogues. Construisez le paquet et testez-le comme décrit dans
- la section <ref id="upload-checking">. Utilisez le paquet chez vous.
-
- <item>
- Attendez une réponse pendant quelques semaines.
-
- <item>
- Envoyez un courrier au responsable lui demandant son accord pour faire
- une mise à jour indépendante <em>(NMU)</em>.
-
- <item>
- Vérifiez une nouvelle fois que votre modification n'a pas d'effet de
- bord inattendu et qu'elle est aussi minimaliste et peu intrusive que
- possible.
-
- <item>
- Attendez une réponse une semaine encore.
-
- <item>
- Faites votre mise à jour indépendante comme décrit dans la section
- <ref id="nmu-guidelines">.
-
- </list>
-
-
-
-
-
-
- <sect id="nmu-guidelines">Comment faire une mise à jour indépendante
- source ?
-
-<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 une rustine aussi petite que
-possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en
-au responsable du paquet, au responsable amont ou soumettez un rapport de
-bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em>
-être faits lors d'une mise à jour indépendante.
-
-
-
-
-
- <sect1 id="nmu-version">Numéro de version pour les mises à jour
- indépendantes sources
-
-<p>
-Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
-changer, même pour la plus triviale des modifications. Notre système de
-gestion de paquets s'appuie sur ces numéros de version.
-
-<p>
-Si vous faites une mise à jour indépendante <em>(NMU)</em>, vous devez ajouter
-un numéro de version mineur à la partie <var>debian-revision</var> du numéro
-de version (la partie qui suit le dernier trait d'union). Ce numéro
-supplémentaire débutera à « 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 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 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 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 rustines de la mise à jour
-indépendante, il devra s'assurer que cette nouvelle version corrige
-effectivement chacun des bogues corrigés dans la mise à jour indépendante.
-
-<p>
-De plus, le responsable officiel devrait <em>toujours</em> conserver les
-entrées documentant une mise à jour indépendante dans le fichier
-<file>changelog</file>.
-
-
-
-
-
-
- <sect1 id="nmu-build">Fabriquer une mise à jour indépendante source
-
-<p>
-Les paquets faisant l'objet d'une mise à jour indépendante source sont
-construits comme les
-autres. Sélectionnez une distribution en utilisant les règles décrites dans
-la section <ref id="upload-dist"> et construisez un fichier <tt>.changes</tt>
-classique avec tout ce qui l'accompagne conformément à la description <ref
-id="uploading">.
-
-<p>
-En fait, toutes les prescriptions de la section <ref id="upload"> sont
-applicables ici, y compris l'obligation d'annoncer la mise à jour sur la liste
-idoine.
-
-<p>
-Vérifiez que vous n'avez pas modifié la valeur du champ <tt>maintainer</tt>
-dans le fichier <file>debian/control</file>. Votre nom, mentionné dans
-l'entrée du fichier <file>debian/changelog</file> concernant la mise à jour,
-sera utilisé pour signer le fichier <tt>.changes</tt>.
-
-
-
-
- <chapt id="porting">Le portage
-
-<p>
-Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas
-un porteur et même si vous n'utilisez qu'une architecture, il est de votre
-responsabilité de développeur d'être attentif aux questions de portabilité.
-C'est pourquoi il est important que vous lisiez ce chapitre même si vous
-n'êtes pas un porteur.
-
-<p>
-Porter un paquet consiste à faire un paquet binaire pour une architecture
-différente de celle du paquet binaire fait par le responsable du paquet.
-C'est une
-activité remarquable et essentielle. En fait, les porteurs sont à l'origine
-de la plupart des compilations de paquet Debian. Pour un paquet binaire
-<em>i386</em>, par exemple, il faut compter une recompilation pour chaque
-autre architecture, soit un total de &number-of-arches; recompilations.
-
-
-
-
- <sect id="kind-to-porters">Être gentil avec les porteurs
-
-<p>
-Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
-grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
-modification. Malheureusement, c'est rarement le cas. Cette section contient
-une liste d'erreurs commises régulièrement par les responsables Debian —
-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 gravité <em>sérieuse</em> (i.e.
-<em>serious</em>) ou supérieure quand ils envoient leur rapport au système de
-suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un
-paquet binaire pour chaque architecture supportée au moment de la sortie de la
-distribution. Il est très important d'avoir un paquet source et un paquet
-binaire pour toutes les architectures pour être conforme à plusieurs licences.
-
-<p>
-Les porteurs doivent éviter d'implémenter des contournements pour
-des bogues de l'environnement de compilation, du noyau ou de la libc. Quelques
-fois ces contournements sont inévitables. Si vous devez faire quelque chose de
-ce genre, marquez proprement vos
-modifications avec des <tt>#ifdef</tt> et documentez votre contournement pour
-que l'on sache le retirer une fois que le problème aura disparu.
-
-<p>
-Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de
-leur travail pendant le délai d'attente. Ainsi d'autres personnes peuvent
-bénéficier du travail du porteur même pendant ce délai. Bien sûr ces adresses
-n'ont rien d'officiel alors soyez sur vos gardes si vous les utilisez.
-
-
-
-
- <sect>Outils pour les porteurs
-
-<p>
-Il y a plusieurs outils pour le travail de portage. Cette section contient
-une courte description de ces outils ; 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
-
-<p>
-Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres
-et faire le nécessaire pour qu'il soit marqué <em>abandonné</em>(i.e.
-<em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
-Group &orphan-address;</tt> dans le champ
-<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
-pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
-« <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>:
-<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 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 gravité <em>importante</em>.
-Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
-décrit précédemment.
-
-<p>
-Reportez-vous à la page WNPP<footnote><em>Work-needing and prospective
-packages</em> : paquets en souffrance et paquets souhaités.</footnote> <url
-id="&url-wnpp;"> pour en savoir plus.
-
-
-
-
-
- <sect id="adopting">Adopter un paquet
-
-<p>
-Une liste des paquets en attente de nouveau responsable est disponible à la
-page <url id="&url-wnpp;" name="Work-Needing and Prospective Packages">. Si
-vous voulez prendre en charge un paquet de cette liste reportez-vous à la page
-susmentionnée pour connaître la procédure à suivre.
-
-<p>
-Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas
-correct — ce serait une prise d'otage. Vous pouvez prendre contact avec le
-responsable actuel et lui demander si vous pouvez prendre en charge ce paquet.
-Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une
-raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable
-est parti sans prévenir depuis un moment, demandez-le sur la liste
-&email-debian-private;.
-
-<p>
-Si vous reprenez un vieux paquet, vous voudrez sûrement que le système de
-suivi des bogues indique que vous êtes le responsable du paquet. Cela se
-produira automatiquement une fois que vous aurez installé une nouvelle version
-du paquet dans l'archive avec le champ <tt>Maintainer</tt> à jour. Cela peut
-prendre quelques heures après le téléchargement. Si vous pensez ne pas avoir
-de mise à jour à faire pour un moment, envoyez un courrier électronique à
-&email-override; pour pouvoir recevoir les rapports de bogue.
-
-
-
-
-
- <chapt id="bug-handling">Gérer les bogues
-
-
-
- <sect>Superviser les rapports de bogues