<!-- common, language independant entities -->
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.13 $">
+ <!entity cvs-rev "$Revision: 1.17 $">
<!-- if you are translating this document, please notate the RCS
revision of the developers reference here -->
<!--
- <!entity cvs-en-rev "1.65">
+ <!entity cvs-en-rev "1.70">
-->
]>
<debiandoc>
id="submit-bug">).
<item><em>Release critical bug</em> : bogue remettant en cause la
- distribution. Bogues de sévérité <em>critique</em>, <em>grave</em>
+ distribution. Bogues de gravité <em>critique</em>, <em>grave</em>
et <em>sérieuse</em>. Ces bogues ne doivent pas apparaître dans une
distribution <em>stable</em>. Ils doivent être corrigés ou bien les
paquets en cause doivent être supprimés (<ref id="rc-bug">).
<item><em>Testing</em> : Nom de la distribution en test. Cette
distribution reçoit les paquets des développeurs qui ont passé une
période de deux semaines dans <em>unstable</em> et pour lesquels aucun
- bogue sévère n'a été découvert. Cette distribution n'a pas été testée
+ bogue remettant en cause la distribution (cf. <em>Release critical bug</em>)
+ n'a été découvert. Cette distribution n'a pas été testée
en profondeur. Elle est cependant sensée être plus stable que
<em>unstable</em> (<ref id="life-cycle">).
corrigés dans les prochaines versions. Il n'est pas de votre responsabilité
de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
si vous êtes capable de le faire, nous vous encourageons à contribuer au
-développements amonts en proposant un <em>patch</em> qui corrige ce bogue.
+développement amont en proposant un <em>patch</em> qui corrige ce bogue.
Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
pour corriger des bogues amonts, il vous faudra alors évaluer ce
<em>patch</em> puis le transmettre aux développeurs amonts.
<p>
Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
paquet conforme à la charte Debian, alors vous devriez proposer un
-<em>patch</em> aux developpeurs amonts pour qu'il soit inclus dans leur
+<em>patch</em> aux développeurs amonts pour qu'il soit inclus dans leur
version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
mises à jour amonts suivantes. Quels que soient les changements dont vous
avez besoin, il faut toujours essayer de rester dans la lignée des sources
<p>
Les bogues bloquants pour la distribution<footnote>Traduction de l'anglais
-<em>Release critical bug (RCB)</em></footnote> sont les bogues de sévérité
+<em>Release critical bug (RCB)</em></footnote> sont les bogues de gravité
<em>critique</em>, <em>grave</em> et <em>sérieuse</em><footnote>Respectivement
<em>critical</em>, <em>grave</em> et <em>serious</em> en anglais</footnote>.
Ces bogues peuvent retarder la diffusion d'une distribution Debian et/ou
<sect1>Experimental
-<p>
-<em>NOTE : <em>experimental</em> ne fonctionne plus depuis la mise en place du
-<em>package pool</em>. Si la distribution <em>experimental</em> est remise en service
-un jour, la présente section aura sûrement besoin d'une mise à jour.</em>
-
<p>
La distribution <em>experimental</em> est une distribution particulière. Ce
n'est pas une distribution à part entière comme le sont <em>stable</em> et
<em>unstable</em>. Elle est prévue pour servir de plate-forme de développement
pour les projets expérimentaux qui ont de grandes chances de détruire le
-système. Les utilisateurs qui téléchargent et installent des paquets depuis
+système ou bien pour des logiciels qui sont vraiment trop instables pour être
+inclus dans la distribution <em>unstable</em> (mais qui ont néanmoins une
+bonne raison pour être mis en paquet). Les utilisateurs qui téléchargent et
+installent des paquets depuis
<em>experimental</em> sont prévenus : on ne peut pas faire confiance à la
distribution <em>experimental</em>.
<p>
-Les responsables doivent être très sélectifs quant à l'utilisation de la
-distribution <em>experimental</em>. Même très instable, un paquet peut aller
-dans <em>unstable</em> ; ajoutez juste quelques avertissements dans la
-description. Par contre, s'il y a une chance que le logiciel endommage
-sérieusement le système, il est préférable de le mettre dans
+S'il y a des chances pour qu'un logiciel cause des dégats importants, il sera
+sûrement préférable de le mettre dans la distribution <em>experimental</em>.
+Un système de fichier compressé, par exemple, devrait probablement aller dans
<em>experimental</em>.
<p>
-Un système de fichier compressé, par exemple, devrait probablement aller dans
-<em>experimental</em>. Une nouvelle version non finalisée d'un logiciel qui
-utilise une méthode de configuration complètement différente pourrait aller
-dans <em>experimental</em> à la discrétion du responsable. Un nouveau logiciel
-qui a peu de chance d'endommager le système ira dans <em>unstable</em>. Si
-vous travaillez sur un cas de mise à jour complexe ou incompatible vous pouvez
-aussi utiliser <em>experimental</em> comme plate-forme d'intégration et ainsi
-fournir un accès aux testeurs.
+Une nouvelle version amont qui ajoute des nouvelles fonctions et en supprime
+beaucoup de plus anciennes ne devra pas être téléchargée dans l'archive
+Debian, elle pourra cependant être téléchargée dans <em>experimental</em>. Une
+nouvelle version non finalisée d'un logiciel qui utilise une méthode de
+configuration complètement différente pourrait aller dans
+<em>experimental</em> à la discrétion du responsable. Si vous travaillez sur
+un cas de mise à jour complexe ou incompatible vous pouvez aussi utiliser
+<em>experimental</em> comme plate-forme d'intégration et ainsi fournir un
+accès aux testeurs.
<p>
-Par contre, utiliser <em>experimental</em> comme plate-forme n'est pas
-toujours la meilleure idée, surtout pour les paquets éphémères.
-Vous ne pouvez pas effacer un paquet qui a été installé dans cet espace
-vous même ; cela doit être fait par l'équipe d'administration de l'archive.
-Une solution consiste à utiliser vos pages web personnelles sur le serveur
-<tt>klecker.debian.org</tt> (c.-à-d. <tt>people.debian.org</tt>).
+Quelques logiciels expérimentaux peuvent aller dans <em>unstable</em>, avec un
+avertissement dans la description mais ce n'est pas recommandé car les paquets
+de <em>unstable</em> se propagent dans <em>testing</em> et aboutissent dans
+<em>stable</em>.
+<p>
+Un nouveau logiciel qui a peu de chance d'endommager le système ira
+directement dans <em>unstable</em>.
+<p>
+Une alternative à <em>experimental</em> consiste à utiliser vos pages
+personnelles sur le serveur <tt>people.debian.org</tt>
+(<tt>klecker.debian.org</tt>).
<sect id="codenames">Les noms de distribution
Le sujet de votre rapport de bogue devra être <ITP<footnote><em>Intent To
Package</em> : intention de mise en paquet</footnote> :
<var>NomDuPaquet</var> — <var> courte description </var>>, en remplaçant
-<var>NomDuPaquet</var> par le nom du paquet. La sévérité du bogue sera
+<var>NomDuPaquet</var> par le nom du paquet. La gravité du bogue sera
<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
-l'entête du message. N'utilisez pas le champs CC: car de cette manière le
-sujet du message ne contiendrait pas le numéro du bogue.
+&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
+l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le
+sujet du message ne contiendra pas le numéro du bogue.
<p>
Il faudra aussi ajouter une entrée
</list>
+ <sect1 id="upload-checking">Vérifier le paquet avant la mise à jour
+<p>
+Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
+devrez au moins faire les tests suivants (il vous faut une ancienne version
+du paquet pour cela) :
+ <list compact>
+ <item>
+ Installez le paquet et vérifiez que le logiciel fonctionne. Si le
+ paquet existait déjà dans une version plus ancienne, faites une mise à
+ jour.
+
+ <item>
+ Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
+ <prgn>lintian</prgn> comme suit : <tt>lintian -v
+ <var>package-version</var>.changes</tt>. Ce programme fera une
+ vérification sur les paquets source et binaire. Si vous ne comprenez
+ par les messages générés par <prgn>lintian</prgn> essayez l'option
+ <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
+ bavard dans sa description du problème.
+ <p>
+ En principe, un paquet pour lequel
+ <prgn>lintian</prgn> génère des erreurs (elles commencent par
+ <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
+ <p>
+ Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
+ section lintian <ref id="lintian">.
+
+ <item>
+ Faites régresser le paquet
+ vers sa version précédente si elle existe — cela permet de tester les
+ scripts <tt>postrm</tt> et <tt>prerm</tt>.
+ <item>
+ Désinstallez le paquet et réinstallez-le.
- <sect id="uploading">Mettre à jour un paquet
+ </list>
- <sect1>Générer le fichier « changes »
+ <sect>Générer le fichier « changes »
<p>
Chaque nouvelle version d'un paquet installé sur les archives FTP Debian doit
être accompagnée d'un fichier <tt>.changes</tt>. Ce fichier explique à
<url id="&url-debian-policy;" name="Debian Policy Manual"> pour connaître
les valeurs que prennent ces champs. Vous pouvez fermer un rapport de bogue
automatiquement avec le champ <tt>Description</tt> (voir <ref
-id="upload-bugfix">). Nous ne verrons ici que le champ <tt>Distribution</tt>
-car il est directement lié aux règles d'administration de l'archive.
-
+id="upload-bugfix">).
-
- <sect1 id="upload-dist">Choisir une distribution
-
-<p>
-Le champ <tt>Distribution</tt>, qui provient du fichier
-<file>debian/changelog</file>, indique à quelle distribution le paquet est
-destiné. Il y a quatre valeurs possibles pour ce champ : <em>stable</em>,
-<em>unstable</em>, <em>frozen</em> et <em>experimental</em> ; ces valeurs
-peuvent aussi être combinées. Si, par exemple, Debian a été gelée et vous
-voulez mettre à jour une correction de bogue sur <em>frozen</em>, il faudra
-indiquer <em>frozen unstable</em> dans le champ distribution (se reporter à
-<ref id="upload-frozen"> pour savoir quand vous pouvez faire une mise à jour
-sur <em>frozen</em>). Notez bien qu'il n'y a pas de raison de combiner
-<em>experimental</em> avec quelque distribution que ce soit.
-
-<p>
-Vous devriez éviter de combiner <em>stable</em> avec d'autres cibles à cause
-des problèmes potentiels de dépendance de bibliothèque (pour votre paquet et
-pour les paquets fabriqués par le démon de compilation pour les autres
-architectures). Notez encore que choisir la valeur <em>stable</em> pour ce
-champ signifie que le paquet sera dirigé vers le répertoire
-<tt>proposed-update</tt> des archives Debian pour y être testé avant d'être
-effectivement inclus dans <em>stable</em>. L'équipe responsable de la
-distribution<footnote><em>the release team</em></footnote> (joignable à
-l'adresse &email-debian-release;) prendra la décision d'inclure ou de ne pas
-inclure votre paquet dans la distribution <em>stable</em>. C'est pourquoi vous
-pourrez choisir de leur envoyer un courrier expliquant les motifs qui vous ont
-incité à faire une mise à jour pour <em>stable</em>, si votre fichier
-<file>changelog</file> n'est pas suffisamment clair sur ce point.
-
+ <sect1>L'archive des sources amonts
<p>
La première fois qu'un paquet est installé dans l'archive pour une version
amont donnée, le fichier <tt>tar</tt> de cette version amont doit être
+ <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>.
- <sect2 id="upload-frozen">Mettre à jour la distribution <em>frozen</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
<p>
<list compact>
<item>
- Les corrections de bogues de sévérité <em>critique</em>,
+ Les corrections de bogues de gravité <em>critique</em>,
<em>grave</em> ou <em>sérieuse</em><footnote>respectivement
<em>critical</em>, <em>grave</em> ou <em>serious</em></footnote> sont
toujours autorisées pour les paquets qui doivent exister dans la
distribution.
<item>
- Les corrections pour les bogues de sévérité <em>critique</em>,
+ Les corrections pour les bogues de gravité <em>critique</em>,
<em>grave</em> ou <em>sérieuse</em><footnote>respectivement
<em>critical</em>, <em>grave</em> ou <em>serious</em></footnote> sont
autorisées pour les paquets non indispensables uniquement si elles
n'ajoutent pas de nouvelle fonctionnalité.
<item>
- Les corrections pour les bogues de sévérité <em>importante</em>,
+ Les corrections pour les bogues de gravité <em>importante</em>,
<em>normale</em> et <em>mineure</em><footnote>respectivement
<em>important</em>, <em>normal</em> et <em>minor</em></footnote> sont
autorisées, bien que découragées, sur tous les paquets si et seulement
s'elles n'ajoutent pas de nouvelle fonctionnalité.
<item>
- Les corrections de sévérité <em>wishlist</em> ne sont pas autorisées (ce
+ Les corrections de gravité <em>wishlist</em> ne sont pas autorisées (ce
ne sont pas vraiment des bogues après tout).
<item>
L'expérience montre qu'il y a 15% de chance d'introduire un nouveau bogue en
corrigeant un autre bogue. L'introduction et la découverte d'un nouveau bogue
retarde la mise à disposition de la distribution ou affaiblit le produit
-final. Il y a très peu de corrélation entre la sévérité du bogue corrigé et
-la sévérité du bogue introduit par la correction.
-
-
+final. Il y a très peu de corrélation entre la gravité du bogue corrigé et
+la gravité du bogue introduit par la correction.
- <sect1 id="upload-checking">Vérifier le paquet avant la mise à jour
+ <sect2 id="upload-stable">Mettre à jour un paquet de la distribution <em>stable</em>
<p>
-Avant de mettre à jour votre paquet vous ferez quelques tests de base. Vous
-devrez au moins faire les tests suivants (il vous faut une ancienne version
-du paquet pour cela) :
+Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
+sera dirigé vers le répertoire <tt>proposed-updates</tt> des archives Debian
+pour y être testé avant d'être effectivement inclus dans <em>stable</em>.
- <list compact>
- <item>
- Installez le paquet et vérifiez que le logiciel fonctionne. Si le
- paquet existait déjà dans une version plus ancienne, faites une mise à
- jour.
+<p>
+Une livraison pour la distribution <em>stable</em> requière des soins
+supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
+que dans les cas suivants :
- <item>
- Exécutez <prgn>lintian</prgn> sur votre paquet. Vous pouvez exécuter
- <prgn>lintian</prgn> comme suit : <tt>lintian -v
- <var>package-version</var>.changes</tt>. Ce programme fera une
- vérification sur les paquets source et binaire. Si vous ne comprenez
- par les messages générés par <prgn>lintian</prgn> essayez l'option
- <tt>-i</tt>. Cette option rendra <prgn>lintian</prgn> beaucoup plus
- bavard dans sa description du problème. <p> Un paquet pour lequel
- <prgn>lintian</prgn> génère des erreurs (elles commencent par
- <tt>E</tt>) <em>ne doit pas</em> être installé dans l'archive.
+ <list>
+ <item>un problème de sécurité (un avis de sécurité
+ Debian<footnote>Debian security advisory.</footnote>),
+ <item>un probleme fonctionnel vraiment critique,
+ <item>un paquet devenu ininstallable,
+ <item>un paquet indisponible pour une architecture.
+ </list>
- <p>
- Pour en savoir plus sur <prgn>lintian</prgn> reportez-vous à la
- section lintian <ref id="lintian">. <item> Faites régresser le paquet
- vers sa version précédente si elle existe — cela permet de tester les
- scripts <tt>postrm</tt> et <tt>prerm</tt>.
+<p>
+Il est fortement déconseillé de changer quoi que ce soit si ce n'est pas
+important car même une modification triviale peut causer un bogue plus
+tard. Livrer une nouvelle version amont d'un logiciel pour corriger un
+problème de sécurité est désapprouvé ; dans la plupart des cas la
+bonne solution consiste à prendre le <em>patch</em> correspondant de la
+nouvelle version amont et à l'appliquer à l'ancienne (faire un
+<em>backport</em> du <em>patch</em>).
- <item>
- Désinstallez le paquet et réinstallez-le.
+<p>
+Les paquets livrés pour <em>stable</em> doivent être compilés avec la
+distribution <em>stable</em> pour que leurs dépendances se limitent aux
+bibliothèques (et autres paquets) disponibles dans <em>stable</em> ;
+un paquet livré pour la distribution <em>stable</em> qui dépend d'une
+librairie qui n'est disponible que dans <em>unstable</em> sera rejeté.
+Modifier les dépendances d'autres paquets (en manipulant le champ
+<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
+ininstallables, est fortement déconseillé.
- </list>
+<p>
+L'équipe responsable de la distribution<footnote><em>the Release
+team</em></footnote> (joignable à l'adresse &email-debian-release;) évaluera
+régulièrement le contenu de <em>proposed-updates</em> et décidera si votre
+paquet peut être inclus dans la distribution <em>stable</em>. Soyez précis
+(et, si nécéssaire, généreux) quand vous décrivez, dans le fichier changelog,
+vos changements pour une livraison vers <em>stable</em> sinon le paquet ne
+sera pas considéré.
+ <sect id="uploading">Mettre à jour un paquet
<sect1 id="upload-ftp-master">Installer un paquet sur
<ftpsite>non-us.debian.org</ftpsite>. Placer les fichiers dans le répertoire
<tt>&non-us-upload-dir;</tt>. Par défaut, vous pouvez utiliser le même
<em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez
-une connexion FTP anonyme pour le téléchargement, placez vous fichiers dans le
+une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le
répertoire <ftppath>/pub/UploadQueue/</ftppath>.
<p>
<p>
-Attention, les personnes résidant aux États-unis et les citoyens américains
+Attention, les personnes résidant aux États-Unis et les citoyens américains
sont soumis à des restrictions sur l'exportation des logiciels de
cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter
quelques logiciels de cryptographie soumis à une obligation de déclaration
Le <em>Debian Policy Manual</em> n'empêche pas les résidents et citoyens
américains de livrer des paquets sur <tt>non-US</tt> mais ils devront être
vigilants en le faisant. Nous recommandons aux responsables concernés de
-prendre toutes les précautions nécessaires, <em>y compris consulter un
+prendre toutes les précautions nécessaires, <em>y compris la consultation d'un
juriste</em>, pour s'assurer qu'ils n'enfreignent pas une loi américaine en
livrant un paquet sur <tt>non-US</tt>.
<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
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 architectures, un fichier <em>diff</em>
+inclure des paquets spécifiques à une architecture, un fichier <em>diff</em>
modifié ou, plus rarement, des nouveaux sources amonts.
<p>
-Une mise à jour indépendante binaire est une recompilation et un archivage
+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
légèrement différentes (voir <ref id="source-nmu-when-porter">).
<p>
-La distribution stable ne peut recevoir que des corrections critiques ou des
-mises à jour de sécurité. Quand une faille de sécurité est détectée, un
-paquet corrigé doit être livré le plus tôt possible. Dans ce cas, le responsable de
-sécurité Debian<footnote>Debian Security Manager</footnote> entrera en contact
+Quand une faille de sécurité est détectée, un
+paquet corrigé doit être livré le plus tôt possible. Dans ce cas, un membre de
+l'équipe de sécurité Debian<footnote>Debian Security officer</footnote>
+entrera en contact
avec le responsable du paquet pour s'assurer qu'un paquet corrigé sera livré dans
un délai raisonnable (moins de 48 heures). Si le mainteneur ne peut
-fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps, le
-responsable de sécurité pourra corriger le paquet (i.e. faire une mise à jour
+fournir une mise à jour suffisamment vite ou s'il ne peut être joint à temps,
+l'équipe de sécurité pourra corriger le paquet (i.e. faire une mise à jour
indépendante source).
<p>
Pendant la phase de gel (voir <ref id="upload-frozen">), les livraisons qui
-corrigent les bogues de sévérité <em>sérieuse</em> (i.e. <em>serious</em>) et
+corrigent les bogues de gravité <em>sérieuse</em> (i.e. <em>serious</em>) et
supérieures sont encouragées et acceptées. Même pendant cette période, vous
devrez tenter d'entrer en contact avec le responsable du paquet ; il pourrait
bien être sur le point de livrer un paquet corrigé lui aussi. Comme pour
Cependant, la personne qui fait une mise à jour indépendante doit envoyer une
note à chaque bogue concerné expliquant qu'il est corrigé par cette mise à
jour indépendante. Cette personne doit ensuite utiliser l'adresse
-<email>control@bugs.debian.org</email> pour modifier la sévérité des bogues
+<email>control@bugs.debian.org</email> pour modifier la gravité des bogues
corrigés et leur donner la valeur <em>corrigé</em> (i.e. <em>fixed</em>).
Cela permet de s'assurer que chacun sait que le bogue est corrigé par une mise
à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que
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 rapport de bogues succints ou
-peu clair ; faites de votre mieux pour éliminer le problème.
+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
<enumlist>
<item>
Vérifiez que les champs <tt>Build-Depends</tt> et
- <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</tt> sont
+ <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>chrooter</em>. Dans cet 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>.
<item>
Si possible, ne vous appuyez pas sur une particularité présente dans
- un compilateur précis ou dans certaines version d'un compilateur. Si
+ 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 surement les problèmes car quelques architectures pourraient
+ cherchez sûrement les problèmes car quelques architectures pourraient
choisir un compilateur différent.
<item>
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 reconcidérer le status
+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.
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 rejeteront
+faites pas cela correctement, les administrateurs de l'archive rejetteront
votre mise à jour (car il n'y aura pas de code source associé).
<p>
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&nbps;».
+mise à jour portera le numéro « 3.4-2.1.1 ».
<p>
Deuxième différence, les porteurs qui font des mises à jour indépendantes
-sources doivent choisir une sévérité <em>sérieuse</em> (i.e.
+sources doivent choisir une gravité <em>sérieuse</em> (i.e.
<em>serious</em>) ou supérieure quand ils envoient leur rapport au système de
suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un
paquet binaire pour chaque architecture supportée au moment de la sortie de la
pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
« <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>:
<var>paquet</var> — <var>courte description</var></tt> » pour indiquer
-que le paquet est orphelin. La sévérité du bogue sera <em>normale</em>.
+que le paquet est orphelin. La gravité du bogue sera <em>normale</em>.
Si vous le jugez nécessaire, envoyez une copie à
-&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
-l'entête du message. N'utilisez pas le champs CC: car de cette manière le
-sujet du message ne contiendrait pas le numéro du bogue.
+&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de
+l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le
+sujet du message ne contiendra pas le numéro du bogue.
<p>
Si le paquet est particulièrement important pour la distribution il vous
faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
« <tt>RFA<footnote><em>Request For Adoption</em> : offre
d'adoption.</footnote>: <var>paquet</var> — <var>courte
-description</var></tt> » et lui affecter la sévérité <em>importante</em>.
+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>
Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les
-bogues qui ont été rapportés plusieurs fois ou affecter la sévérité
+bogues qui ont été rapportés plusieurs fois ou affecter la gravité
<em>corrigé</em> (i.e. <em>fixed</em>) à un rapport dont le bogue a été
corrigé. Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le
responsable du paquet vous ne devez pas clore le rapport (à moins que vous
<sect>Parrainer un paquet
<p>
Parrainer un paquet signifie télécharger un paquet dans l'archive Debian pour
-un responsable qui n'est pas capable de le faire lui même : un futur
-responsable. Parrainer un paquet signifie aussi assumer la résponsabilité de
+un responsable qui n'est pas capable de le faire lui-même : un futur
+responsable. Parrainer un paquet signifie aussi assumer la responsabilité de
ce parrainage.
<p>
Les nouveaux responsables éprouvent souvent quelques difficultés pour créer
des paquets Debian — ce qui est bien compréhensible. C'est là que le parrain
-intervient. Il doit verifier que le paquet est suffisamment bon pour intégrer
+intervient. Il doit vérifier que le paquet est suffisamment bon pour intégrer
la distribution. Notez que si le paquet est nouveau les administrateurs FTP
devront eux aussi inspecter ce paquet avant de le laisser entrer.
<p>
Si vous êtes responsable de candidature<footnote>Application
-manager</footnote> pour un developpeur, vous pouvez aussi être son parrain. De
-cette manière, vous aurez la possibilité de vérifier vous même comment ce
-candidat accomplit la partie `Tâches et compétences'<footnote>`Tasks and
+manager</footnote> pour un développeur, vous pouvez aussi être son parrain. De
+cette manière, vous aurez la possibilité de vérifier vous-même comment ce
+candidat accomplit la partie « Tâches et compétences »<footnote>`Tasks and
Skills'</footnote> de sa candidature.
- <sect>Soutenir un nouveau responsable
+ <sect>Aider un nouveau responsable
<p>
-Consultez la page <url id="&url-newmaint-advocate;" name="Soutenir un futur
+Consultez la page <url id="&url-newmaint-advocate;" name="Aider un futur
responsable"> sur le site du projet Debian.
~ianmdlvl / developers-reference.git / blobdiff