Re: [DDR] debian-doc://dpp/manuals.sgml/developers-reference/developers-reference.fr.sgml
Frédéric Bothamy <fbothamy@mail.dotcom.fr> écrivait :
« Bonsoir à tous,
«
« La dernière version française diffusée était basée sur la version
« anglaise 1.91, celle-ci l'est sur la version 1.153. Il y a donc
« beaucoup de changements et vous pouvez restreindre chaque relecture à
« une seule section (il y en a 8) si vous le désirez.
Voici une relecture faite à partir de la version cvs du Thu Dec 12
mais il manque des passages dans ta traduction.
a+
--
Philippe Batailler
in girum imus nocte et consumimur igni
--- developers-reference.fr.sgml Fri Dec 20 14:57:22 2002
+++ deve.relu.sgml Sun Dec 22 18:50:21 2002
@@ -31,7 +31,7 @@
<book>
<title>Référence du développeur Debian
- <author>Adam Di Carlo, current maintainer <email>aph@debian.org</email>
+ <author>Adam Di Carlo, responsable actuel<email>aph@debian.org</email>
<author>Raphaël Hertzog, co-responsable <email>hertzog@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
@@ -72,12 +72,12 @@
<!-- FIXME: rewrites -->
<p>
-Les procédures décrites ci-après expliquent entre autre comment devenir
+Les procédures décrites ci-après expliquent comment devenir
responsable Debian (<ref id="new-maintainer">), comment installer des nouveaux
paquets dans l'archive (<ref id="upload">), quand et comment faire un portage ou
une mise à jour du paquet d'un autre responsable (<ref id="nmu">), comment
déplacer, effacer ou abandonner un paquet (<ref id="archive-manip">) et comment
-gérer les bogues (<ref id="bug-handling">).
+gérer les rapports de bogues (<ref id="bug-handling">).
<p>
Les ressources présentées dans ce manuel incluent les listes de diffusion (<ref
@@ -150,8 +150,11 @@
envoie un rapport de bogue au système de suivi des bogues (<ref
id="submit-bug">).
- <item><em>Release critical bug</em> : bogue remettant en cause la
- distribution. Bogues de gravité <em>critique</em>, <em>grave</em> et
+ <item><em>Release critical bug</em> : bogue empêchant l'intégration du paquet dans la distribution.
+<!-- Il ne remet pas en cause la distribution = stable ou testing ou woody...
+il remet en cause la « distribution » du paquet qui possède ce bogue. il
+remet en cause l'intégration du paquet dans la (une) 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-bugs">).
@@ -215,12 +218,12 @@
<p>
Vous avez lu toute la documentation, vous avez examiné le <url
id="&url-newmaint-guide;" name="guide du nouveau responsable">, vous comprenez
- l'intérêt de tout ce qui se trouve dans le paquet exemple
+ l'intérêt de tout ce qui se trouve dans le paquet d'exemple
<package>hello</package> et vous vous apprêtez à mettre en paquet votre
logiciel préféré. Comment devenir responsable Debian et intégrer votre travail
au projet ?
<p>
-Si vous ne l'avez pas encore fait, vous pouvez commencer par vous inscrire à la
+Si vous ne l'avez pas encore fait, inscrivez-vous à la
liste &email-debian-devel;. Pour cela, envoyez un courrier à l'adresse
&email-debian-devel-req; avec le mot <tt>subscribe</tt> dans la ligne
<em>Objet</em><footnote><p><em>Subject</em> en anglais</footnote> de votre
@@ -273,13 +276,13 @@
Le processus d'enregistrement a pour but de vérifier votre identité, vos
intentions et vos compétences. Le nombre de personnes travaillant pour
&debian-formal; a atteint &number-of-maintainers; et notre système est utilisé
- dans plusieurs endroits très importants : nous devons rester attentifs
+ dans plusieurs endroits très importants : nous devons rester vigilants
pour éviter un acte malveillant. C'est pourquoi nous contrôlons les nouveaux
- responsables avant de leur donner un compte sur nos serveurs et les autoriser à
+ responsables avant de leur donner un compte sur nos serveurs et de les autoriser à
ajouter des paquets dans l'archive.
<p>
Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
- et être un bon contributeur. Pour cela, vous pourrez proposer des correctifs
+ et que vous serez un bon contributeur. Pour cela, vous pourrez proposer des correctifs
par le système de suivi des bogues (BTS) ou maintenir un paquet parrainé
pendant un temps. Nous attendons aussi des contributeurs qu'ils soient
intéressés par le projet dans son ensemble et pas uniquement par leurs propres
@@ -292,7 +295,7 @@
signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
La <url id="&url-gpg-coord;" name="page de coordination des signatures de clé
GnuPG"> devrait vous aider à trouver un responsable Debian près de chez vous.
- (Si vous ne trouvez pas de responsable prè de chez vous, il existe un second
+ (Si vous ne trouvez pas de responsable près de chez vous, il existe un second
moyen pour valider votre identité. Vous pouvez envoyer une photo d'identité
signée avec votre clé GnuPG. Privilégiez tout de même la clé GnuPG signée pour
valider une identité. Reportez-vous à la <url id="&url-newmaint-id;" name="page
@@ -330,8 +333,8 @@
Certains pays limitent l'usage des logiciels de cryptographie. Cela ne devrait
cependant pas avoir d'impact sur l'activité d'un responsable de paquet car il
peut être tout à fait légal d'utiliser des logiciels de cryptographie pour
- l'authentification plutôt que pour le cryptage. &debian-formal; ne nécessite en
- aucune manière de cryptographie en tant que cryptage. Si vous vivez dans un
+ l'authentification plutôt que pour le chiffrement. &debian-formal; ne nécessite en
+ aucun chiffrement. <!-- bizarre, décryptage existe mais pas cryptage ! --> Si vous vivez dans un
pays où l'utilisation de la cryptographie pour authentification est interdite,
contactez-nous pour que nous prenions des dispositions particulières.
<p>
@@ -343,7 +346,7 @@
succès au projet Debian.
<p>
Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est signée et
- quand vous avez contribué pendant un temps au projet, vous êtes prêt pour faire
+ quand vous avez déjà contribué au projet, vous êtes prêt à faire
acte de candidature. Il vous suffit pour cela de vous enregistrer sur notre
<url id="&url-newmaint-apply;" name="page de candidature">. Ensuite, votre
avocat devra confirmer votre candidature. Quand il aura accompli cette tâche,
@@ -369,10 +372,10 @@
doivent aussi poster dans cette liste, un développeur expérimenté se portera
volontaire pour les aider.
<p>
-De plus, si vous avez des paquets prêts à être intégrés mais attendez le
+Si vos paquets sont prêts à être intégrés mais que vous attendiez le
résultat de votre candidature, vous pouvez chercher un parrain qui téléchargera
- les paquets pour vous. Les parrains sont des responsables Debian officiels
- volontaires pour examiner vos paquets et les télécharger pour vous. Vous pouvez
+ les paquets à votre place. Les parrains sont des responsables Debian officiels
+ volontaires pour examiner et télécharger vos paquets. Vous pouvez
demander un parrainage à l'adresse <url id="&url-sponsors;">.
<p>
Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.
@@ -382,7 +385,8 @@
<sect id="user-maint">Mise à jour de vos références Debian
<p>
-Une base de données LDAP contient des informations concernant les développeurs,
+Il existe une base de données LDAP qui contient des informations concernant
+les développeurs ;
vous pouvez y accéder à l'adresse <url id="&url-debian-db;">. Vous pouvez
modifier votre mot de passe (ce mot de passe est diffusé sur la plupart des
machines auxquelles vous avez accès), votre adresse, votre pays, la latitude et
@@ -416,8 +420,8 @@
<sect id="voting">Voter
<p>
-Bien que n'étant pas toujours une vraie démocratie, Debian dispose d'outils à
- caractère démocratique et utilise un procédé démocratique pour élire son leader
+Debian, sans être une vraie démocratie, dispose d'outils à
+ caractère démocratique et utilise un procédé démocratique pour élire son chef
ou pour approuver une résolution. Ces procédures sont décrites dans la <url
id="&url-constitution;" name="Constitution Debian">.
<p>
@@ -441,7 +445,7 @@
besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment
réagir en cas de problème. En général, cela signifie que les autres
développeurs sont autorisés à modifier votre paquet (voir <ref id="nmu">) en
- cas de gros problème (bogues bloquants pour la distribution, mise à jour de
+ cas de gros problème (bogues empêchant l'intégration dans la distribution, mise à jour de
sécurité, etc.) durant vos vacances.
<p>
Il y a deux choses à faire pour en informer les autres développeurs.
@@ -479,15 +483,14 @@
suivantes. Quels que soient les changements dont vous avez besoin, il faut
toujours essayer de rester dans la lignée des sources amonts.
- <sect id="rc-bugs">Gestion des bogues bloquants pour la distribution
+ <sect id="rc-bugs">Comment gérer les bogues empêchant l'intégration du paquet dans la distribution ?
<p>
Habituellement, vous devriez traiter les rapports de bogue sur vos paquets tel
que cela est décrit dans <ref id="bug-handling">. Cependant, il y a une
- catégorie spéciale de bogues qui nécessitent particulièrement votre
- attention — les bogues bloquants pour la
- distribution<footnote>Traduction de l'anglais <em>Release-critical bug (RC
+ catégorie spéciale de bogues qui nécessite particulièrement votre
+ attention : les bogues empêchant l'intégration du paquet dans la distribution ;<footnote>Traduction de l'anglais <em>Release-critical bug (RC
Bugs)</em></footnote>. Tous les rapports de bogue de gravité <em>critique</em>,
- <em>grave</em> et <em>sérieuse</em><footnote>Respectivement <em>critical</em>,
+ <em>grave</em> et <em>sérieuse</em> ;<footnote>Respectivement <em>critical</em>,
<em>grave</em> et <em>serious</em> en anglais</footnote> sont considérés comme
ayant un impact sur la présence du paquet dans la prochaine version stable de
Debian. Ces bogues peuvent retarder la diffusion d'une distribution Debian
@@ -533,7 +536,7 @@
<p>
Le serveur de liste de diffusion est <tt>&lists-host;</tt>.
<p>
-Les archives des listes de diffusions sont consultables à <url
+Les archives des listes de diffusion sont consultables à <url
id="&url-lists-archives;">.
<sect1 id="core-devel-mailing-lists">Principales listes pour les responsables
@@ -542,7 +545,7 @@
devraient suivre sont :
<list>
<item>&email-debian-devel-announce;, utilisée pour les annonces importantes
- faites aux responsables. Tous les responsables Debian doivent être
+ faites aux responsables. Tous les responsables Debian sont censés être
inscrits à cette liste,</item>
<item>&email-debian-devel;, utilisée pour discuter de diverses questions
techniques relatives au développement,</item>
@@ -612,9 +615,9 @@
L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias vers
<tt>irc.openprojects.net</tt>.
<p>
-Le principal canal pour Debian en général est <em>#debian</em>. Il s'agit d'un
- canal vaste à but généraliste où les utilisateurs peuvent trouver des nouvelles
- récentes dans le sujet et qui est administré par des robots. <em>#debian</em>
+Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
+ canal important, généraliste, où les utilisateurs peuvent trouver des nouvelles
+ récentes et qui est administré par des robots. <em>#debian</em>
est destiné aux anglophones ; il existe également <em>#debian.de</em>,
<em>#debian-fr</em>, <em>#debian-br</em> et d'autres canaux avec des noms
semblables pour les personnes parlant d'autres langues.
@@ -622,9 +625,9 @@
Le canal principal pour le développement Debian est <em>#debian-devel</em>.
C'est un canal très actif avec habituellement plus de 150 personnes connectées
en permanence. C'est un canal pour les personnes qui travaillent sur Debian, ce
- n'est pas un canal de support (il existe <em>#debian</em> pour cela). Il est
- cependant ouvert à tous ceux qui veulent écouter (et apprendre). Le sujet est
- toujours rempli d'informations intéressantes.
+ n'est pas un canal d'aide (il existe <em>#debian</em> pour cela). Il est
+ cependant ouvert à tous ceux qui veulent écouter (et apprendre). Les
+ conversations sont toujours pleines d'informations intéressantes.
<p>
Comme <em>#debian-devel</em> est un canal ouvert, vous ne devriez pas y parler
de problèmes discutés sur &email-debian-private;. Il existe un canal protégé
@@ -635,7 +638,7 @@
fichiers.
<p>
Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
- est utilisé pour la coordination des fêtes de suppression des bogues.
+ est utilisé pour la coordination des <em>chasses aux bogues</em>.
<em>#debian-boot</em> est utilisé pour la coordination du travail sur les
disquettes de démarrage (i.e. l'installeur). <em>#debian-doc</em> est utilisé
occasionnellement pour travailler sur la documentation comme celle que vous
@@ -654,19 +657,19 @@
Ce document contient beaucoup d'informations très utiles aux développeurs
Debian, mais il ne peut pas tout contenir. La plupart des autres documents
intéressants sont référencés dans <url id="&url-devel-docs;" name="le coin du
- développeur">. Prenez le temps de parcourir tous les liens, vous apprendrez un
- grand nombre de choses.
+ développeur">. Prenez le temps de parcourir tous les liens, vous apprendrez
+ encore beaucoup de choses.
<sect id="server-machines">Les serveurs Debian
<p>
-Debian possède plusieurs ordinateurs comme serveurs, dont la plupart hébergent
- des fonctions critiques du projet Debian. La plupart des machines sont
+Debian possède plusieurs ordinateurs employés comme serveurs, dont la plupart hébergent
+ les fonctions critiques du projet Debian. La plupart des machines sont
utilisées pour des activités de portage et elles ont toutes un accès permanent
à Internet.
<p>
-La plupart des machines sont disponibles pour utilisation par les développeurs
- individuels tant qu'ils respectent les règles définies dans la <url
+La plupart des machines peuvent être utilisées par les développeurs
+ tant qu'ils respectent les règles définies dans la <url
id="&url-dmup;" name="charte d'utilisation des machines Debian">.
<p>
Dans l'ensemble, vous pouvez faire usage de ces machines pour des buts relatifs
@@ -681,8 +684,8 @@
de données qui envoient les mots de passe en clair par l'Internet comme telnet,
FTP, POP, etc.
<p>
-Veuillez de ne pas déposer de données non relatives à Debian sur les serveurs
- Debian à moins que vous n'ayez obtenu la permission auparavant.
+Veuillez ne pas déposer de données non relatives à Debian sur les serveurs
+Debian à moins que vous n'ayez préalablement obtenu la permission de le faire.
<p>
La liste actuelle des machines Debian est disponible à <url
id="&url-devel-machines;">. Cette page web contient les noms des machines, les
@@ -700,7 +703,7 @@
« pseudo-paquet ». Reportez-vous à la section <ref id="submit-bug">
pour connaître la procédure à suivre.
- <sect1 id="servers-bugs">Le serveur de bogues
+ <sect1 id="servers-bugs">Le serveur pour les rapports de bogues
<p>
<tt>bugs.debian.org</tt> est le serveur maître du système de suivi des bogues
(BTS<footnote><p>Système de suivi des bogues se dit <em>Bug Tracking
@@ -758,8 +761,8 @@
des développeurs concernant ce qui est lié à Debian.
<p>
Si vous avez des informations spécifiques Debian que vous voulez rendre
- disponibles sur le web, vous pouvez le faire en les envoyant dans le répertoire
- <file>public_html</file> dans votre répertoire personnel sur
+ disponibles sur le web, vous pouvez le faire en les plaçant dans le répertoire
+ <file>public_html</file> de votre répertoire personnel sur
<tt>people.debian.org</tt>. Elles seront accessibles à l'adresse
<tt>http://people.debian.org/~<var>votre-user-id</var>/</tt>.
<p>
@@ -803,9 +806,10 @@
serveurs Debian, essayez <prgn>finger yourlogin@debian.org</prgn> pour voir ce
qu'il indique.
<p>
-La base de données vous permet d'enregistrer d'autres informations comme des
+La base de données vous permet d'enregistrer d'autres informations ; par
+exemple, des
clés publiques SSH qui seront installées automatiquement sur les machines
- Debian officielles ou semblable entrée DNS *debian.net. Ces fonctionnalités
+ Debian officielles, ou des entrées DNS de type *debian.net. Ces fonctionnalités
sont documentées à <url id="&url-debian-db-mail-gw;">.
<!-- <sect id="servers-mirrors">Les miroirs des serveurs Debian
@@ -858,7 +862,7 @@
<p>
Dans chacune de ces sections, se trouve un répertoire contenant les paquets
sources (<file>source/</file>) et un répertoire pour chaque architecture
- supportée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
+ acceptée (<file>binary-i386/</file>, <file>binary-m68k/</file>, etc.).
<p>
La section <em>main</em> contient d'autres répertoires destinés aux images de
disquettes et à plusieurs documents essentiels pour installer la distribution
@@ -870,14 +874,14 @@
La section <em>main</em> constitue la <strong>distribution &debian-formal;
officielle</strong>. Elle est officielle parce qu'elle est entièrement conforme
à toutes nos recommandations. Les deux autres sections divergent de ces
- recommandations à différents degrés, elles ne font donc <strong>pas</strong>
+ recommandations à différents degrés, elles <strong>ne</strong> font donc <strong>pas</strong>
officiellement partie de &debian-formal;.
<p>
Chaque paquet de la section <em>main</em> doit être conforme aux <url
id="&url-dfsg;" name="directives Debian pour le logiciel
libre"><footnote>Debian Free Software Guidelines</footnote> et à toutes les
autres recommandations décrites dans <url id="&url-debian-policy;" name="la
- charte Debian"><footnote>Debian Policy Manual</footnote> . Les
+ charte Debian"><footnote>Debian Policy Manual</footnote>. Les
DFSG<footnote><em>Debian Free Software Guidelines</em></footnote> constituent
notre définition de « logiciel libre ». Reportez-vous à la <em>charte
Debian</em> pour en savoir plus.
@@ -902,8 +906,8 @@
interdisent leur distribution à titre commercial par exemple.
<p>
D'un autre coté, un distributeur de cédérom pourra facilement vérifier
- individuellement les licences des paquets de la section <em>non-free</em> et
- ajouter autant de paquets qu'il est autorisé à le faire sur ses cédéroms (dans
+ la licence de chacun des paquets de la section <em>non-free</em> et
+ ajouter tous les paquets qu'il pourra ajouter (dans
la mesure où cela varie énormément d'un distributeur à l'autre, ce travail ne
peut être fait par les développeurs Debian).
@@ -916,9 +920,9 @@
<p>
Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
Motorola, 680x0 (Atari, Amiga, et Macintosh), MIPS et PowerPC. Le noyau 2.2
- supporte encore plus d'architectures dont ARM et UltraSPARC. Puisque Linux
- supporte ces architectures, Debian a décidé qu'elle devait également les
- supporter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
+ reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
+ reconnaît ces architectures, Debian a décidé qu'elle devait également les
+ accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
a aussi des portages vers d'autres noyaux. À coté d'<em>i386</em> (notre nom
pour Intel x86), nous avons, au moment où j'écris <em>m68k</em>,
<em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
@@ -926,15 +930,15 @@
<em>mipsel</em> et <em>sh</em>.
<p>
&debian-formal; 1.3 est disponible uniquement pour <em>i386</em>. Debian 2.0
- supporte les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 supporte
+ reconnaît les architectures <em>i386</em> et <em>m68k</em>. Debian 2.1 reconnaît
les architectures <em>i386</em>, <em>m68k</em>, <em>alpha</em> et
- <em>sparc</em>. Debian 2.2 a ajouté le support des architectures
- <em>powerpc</em> et <em>arm</em>. Debian 3.0 ajoute le support pour cinq
+ <em>sparc</em>. Debian 2.2 accepte en plus les architectures
+ <em>powerpc</em> et <em>arm</em>. Debian 3.0 accepte cinq
nouvelles architectures : <em>ia64</em>, <em>hppa</em>, <em>s390</em>,
<em>mips</em> et <em>mipsel</em>.
<p>
-Vous trouverez des informations destinées aux développeurs à propos d'un portage
- particulier sur la page <url id="&url-debian-ports;" name="Portage Debian">.
+Pour chaque portage, vous trouverez des informations destinées aux
+développeurs et aux utilisateurs sur la page <url id="&url-debian-ports;" name="Portage Debian">. <!-- uses = users ? -->
<sect1>Les paquets
<p>
@@ -970,9 +974,9 @@
Debian se trouve dans <ftppath>/debian</ftppath> ce qui est un emplacement
courant. Un autre emplacement courant est <file>/pub/debian</file>.
<p>
-Une distribution est composée de paquets Debian sources et binaires et des
- fichiers <file>Sources</file> et <file>Packages</file> correspondants. Ces
- derniers contiennent la description de tous les paquets. Les premiers sont
+Une distribution est composée de paquets sources et binaires et des
+ fichiers <file>Sources</file> et <file>Packages</file> correspondants qui
+ contiennent toutes les meta-informations sur les paquets. Les premiers sont
conservés dans le répertoire <file>pool/</file> tandis que les seconds sont
conservés dans le répertoire <file>dists/</file> de l'archive (pour
compatibilité descendante).
@@ -997,10 +1001,10 @@
littéralement « instable ».
<p>
<ref id="testing"> est générée automatiquement en prenant les paquets de
- <em>unstable</em> s'ils satisfont à certains critères. Ces critères devraient
- garantir que les paquets de <em>testing</em> sont de bonne qualité. La mise à
+ <em>unstable</em> s'ils satisfont à certains critères. Ces critères
+ garantissent que les paquets de <em>testing</em> sont de bonne qualité. La mise à
jour de <em>testing</em> est lancée chaque jour après que les nouveaux paquets
- aient été installés.
+ ont été installés.
<p>
Après une période de développement, quand le responsable de
distribution<footnote><p><em>Release manager</em></footnote> le juge opportun,
@@ -1013,8 +1017,9 @@
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
+ dernier cycle de test, la distribution <em>frozen</em> devient <!-- renommée
+ = la renommée; re-nommer; bon, en français, il faut une périphrase !! -->
+<em>stable</em>, remplaçant l'ancienne distribution <em>stable</em> qui est
enlevée à cette occasion (elle peut être retrouvée à l'adresse
<tt>&archive-host;</tt>).
<p>
@@ -1023,7 +1028,7 @@
(<em>testing</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
+ grande attention et sont ajoutées une à une à 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
<file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
@@ -1037,19 +1042,19 @@
<sect2><em>Experimental</em>
<p>
-La distribution <em>experimental</em> est une distribution spécialisée. Ce n'est
+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éveloppement pour les projets expérimentaux qui risquent vraiment 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
lesquels 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
+Si un logiciel peut causer des dégats importants, il sera sûrement
préférable de le mettre dans la distribution <em>experimental</em>. Un
- système de fichier compressé expérimental, par exemple, devrait probablement
+ système expérimental 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
@@ -1089,16 +1094,16 @@
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.
+ reconnues ou pour lesquelles la distribution n'a pas encore été diffusée. Ces
+ architectures seront intégrées ulterieurement à la distribution principale.
<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. Si nous avions nommé le répertoire qui contient la prochaine
- version à diffuser « testing », il aurait fallu le renommer
+ distribution à diffuser « testing », il aurait fallu changer son nom en
« 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).
+ FTP à télécharger à nouveau la distribution complète (qui est plutôt volumineuse).
<p>
D'un autre coté, si une distribution s'appelait <em>Debian-x.y</em> dès le
départ, des personnes pourraient s'imaginer que la distribution Debian
@@ -1120,20 +1125,21 @@
<sect id="mirrors">Les miroirs Debian
<p>
Les différentes archives de téléchargement et le site web disposent de plusieurs
-miroirs pour soulager les serveurs principaux de la lourde charge. En fait,
-certains de ces principaux serveurs ne sont pas publics et le charge est
-répartie sur les serveurs de premier tiers à la place. De cette façon, les
+miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
+certains de ces serveurs ne sont pas publics et la charge est
+répartie sur une première série de serveurs. De cette façon, les
utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
plusieurs réseaux différents et évitent aux utilisateurs de surcharger
-l'emplacement primaire. Notez que les miroirs de premier tiers sont aussi à jour
+l'emplacement primaire. Notez que dans cette première série, les serveurs sont aussi à jour
que possible car la mise à jour est déclenchée par les sites maîtres internes
-(nous appelons cela « push mirroring »).
+(nous appelons cela le « push mirroring »).
+<!-- j'ai la flemme ! mais il faudrait trouver une traduction :) -->
<p>
-Toutes les informations sur les miroirs Debian peut être trouvées à <url
+Toutes les informations sur les miroirs Debian peuvent être trouvées à <url
id="&url-debian-mirrors;">, y compris une liste des miroirs publics disponibles
FTP/HTTP. Cette page utile inclut également des informations et des outils pour
-créer son propre miroir, soit en interne ou pour un accès public.
+créer son propre miroir, soit en interne soit pour un accès public.
<p>
Les miroirs sont en général mis en oeuvre par des tiers qui veulent aider
Debian. C'est pourquoi les développeurs n'ont en général pas de compte sur ces
@@ -1143,7 +1149,7 @@
<heading>Le système Incoming
<p>
Le système Incoming est responsable de la collecte des paquets mis à jour et de
- les installer dans l'archive Debian. Il est constitué d'un ensemble de
+ leur installation dans l'archive Debian. Il est constitué d'un ensemble de
répertoires et de scripts qui sont installés à la fois sur
<tt>&ftp-master-host;</tt> et sur <tt>&non-us-host;</tt>.
<p>
@@ -1154,29 +1160,29 @@
installé, il est déplacé dans le répertoire <file>accepted</file>. S'il s'agit
du premier envoi du paquet, il est déplacé dans le répertoire <file>new</file>
où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers
- devant être installés "à la main", il est déplacé dans le répertoire
- <file>byhand</file> où il attend une installation manuelle des ftpmasters.
+ devant être installés <em>à la main</em>, il est déplacé dans le répertoire
+ <file>byhand</file> où il attend une installation manuelle par les ftpmasters.
Sinon, si une erreur a été détectée, le paquet est refusé et il est déplacé
dans le répertoire <file>reject</file>.
<p>
Une fois que le paquet est accepté, le système envoie une confirmation par
- courrier au responsable, ferme les bogues marqués comme fixés par l'envoi et
- les compilateurs automatiques peuvent commencer à le recompiler. Le paquet est
+ courrier au responsable et ferme les bogues corrigés par l'envoi ; puis
+ les compilateurs automatiques peuvent commencer la recompilation. Le paquet est
maintenant accessible publiquement à <url id="&url-incoming;"> (une telle
adresse n'existe pas pour les paquets de l'archive non-US) jusqu'à ce qu'il
soit vraiment installé dans l'archive Debian. Ceci se produit seulement une
fois par jour, le paquet est alors supprimé de <file>Incoming</file> et
installé dans le pool avec les autres paquets. Une fois que toutes les autres
mises à jour (générant des nouveaux fichiers d'index <file>Packages</file> et
- <file>Sources</file> par exemple) on été effectuées, un script spécial est
+ <file>Sources</file> par exemple) ont été effectuées, un script spécial est
appelé pour demander aux miroirs primaires de se mettre à jour.
<p>
-Tous les développeurs Debian ont un accès en écriture au répertoire
+Tous les développeurs Debian ont un droit d'écriture dans le répertoire
<file>unchecked</file> pour pouvoir y envoyer leurs paquets, ils ont également
accès au répertoire <file>reject</file> pour supprimer les mauvais envois ou
- déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais tous
- les autres répertoires ne sont accessibles en écriture que par les ftpmasters,
- c'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
+ déplacer certains fichiers dans le répertoire <file>unchecked</file>. Mais
+ seuls les ftpmasters ont droit d'écriture dans les autres répertoires.
+ C'est pourquoi vous ne pouvez pas supprimer un envoi une fois qu'il a été
accepté.
<sect1 id="delayed-incoming">Incoming différé
@@ -1199,8 +1205,8 @@
n'est pas complètement satisfait par la NMU. Il peut également enlever
complètement la NMU.
<p>
-L'utilisation de cette fonctionnalité de délai peut être simplifiée avec un peu
- d'intégration avec votre outil d'envoi. Par exemple, si vous utilisez
+L'utilisation de cette fonctionnalité de délai peut être simplifiée en
+ l'intégrant à votre outil d'envoi. Par exemple, si vous utilisez
<prgn>dupload</prgn> (voir <ref id="dupload">), vous pouvez ajouter cette
partie à votre fichier de configuration :
<example>
@@ -1233,20 +1239,20 @@
l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une
urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent
être doublés lors d'un gel de distribution ;</item>
-<item><p>Il doit avoir moins de bogues critiques pour la diffusion que la
+<item><p>Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
version disponible dans <em>testing</em> ;</item>
<item><p>Il doit être disponible pour toutes les architectures pour lesquelles
- il a été auparavant construit. <ref id="madison"> peut être
+ il a été auparavant construit. L'outil <ref id="madison"> peut être
intéressant pour vérifier cette information ;</item>
<item><p>Il ne doit pas casser les dépendances d'un paquet qui est déjà
disponible dans <em>testing</em> ;</item>
<item><p>Les paquets dont il dépend doivent soit être déjà disponibles dans
- <em>testing</em> ou ils doivent être acceptés dans <em>testing</em> au
- même moment (et ils doivent eux-même respecter tous ces
+ <em>testing</em> soit être acceptés dans <em>testing</em> au
+ même moment (et ils doivent eux-mêmes respecter tous ces
critères).</item>
</list>
<p>
-Les scripts génèrent certains fichiers de sortie pour expliquer
+Les scripts génèrent certains fichiers pour expliquer
pourquoi certains paquets sont maintenus hors de <em>testing</em>. Ils sont
disponibles à <url id="&url-testing-maint;">. Sinon, il est possible
d'utiliser le programme <prgn>grep-excuses</prgn> inclus dans le paquet
@@ -1304,9 +1310,10 @@
<sect id="pkg-tracking-system">Le système de suivi des paquets
<p>
Le système de suivi des paquets (PTS)<footnote>« Package Tracking
- System »</footnote> est dans l'ensemble un outil pour suivre par courrier
- l'activité d'un paquet source. Il vous suffit simplement de vous inscrire à un
- paquet source pour commencer à recevoir les courriers liés à celui-ci. Vous
+ System »</footnote> est un outil pour suivre par courrier
+ l'activité concernant un paquet source. Il suffit simplement de s'inscrire
+à un
+ paquet source pour recevoir les courriers liés à celui-ci. Vous
recevez les mêmes courriers que le responsable. Chaque courrier envoyé par le
PTS est classé et associé à l'un des mots-clés listés ci-dessous. Ceci vous
permettra de sélectionner les courriers que vous voulez recevoir.
@@ -1376,7 +1383,7 @@
l'expéditeur si le second argument n'est pas rempli.
<tag><tt>which [<email>]</tt>
- <item>Liste les inscriptions pour l'expéditeur ou l'adresse indiquée
+ <item>Liste les inscriptions pour l'expéditeur ou pour l'adresse indiquée
si elle est spécifiée.
<tag><tt>keyword [<email>]</tt>
@@ -1411,7 +1418,7 @@
Définit la liste (=) des mots-clés acceptés.
<tag><tt>keyword <srcpackage> [<email>] {+|-|=} <list of keywords></tt>
- <item>Identique à l'élément précédent, mais surpasse la liste des mots-clés
+ <item>Identique à l'élément précédent, mais remplace la liste des mots-clés
pour le paquet source indiqué.
<tag><tt>quit | thanks | --</tt>
@@ -1445,7 +1452,7 @@
co-responsables) puissent suivre de près l'évolution du paquet.
<p>
C'est très facile à mettre en place. Une fois que votre dépôt génère des
- notifications de commits, vous devez simplement vous assurer qu'il envoie une
+ notifications d'archivage <!-- ou enregistrement -->, vous devez simplement vous assurer qu'il envoie une
copie de tous ces courriers à <tt><var>srcpackage</var>_cvs@&pts-host;</tt>.
Seules les personnes qui ont accepté le mot-clé <em>cvs</em> recevront les
notifications.
@@ -1453,11 +1460,11 @@
<sect id="ddpo">Vue d'ensemble des paquets d'un développeur
<p>
Un portail web pour l'Assurance Qualité (QA) est disponible à <url
- id="&url-ddpo;"> qui affiche une liste tabulée de tous les paquets d'un
- développeur (y compris ceux pour lequel il est co-responsable). La table donne
+ id="&url-ddpo;"> qui affiche un tableau de tous les paquets d'un
+ développeur (y compris ceux pour lequel il est co-responsable). Le tableau donne
un bon résumé sur les paquets d'un développeur : nombre de bogues par
- gravité, liste des versions disponibles, état de test et bien plus, y compris
- des liens vers d'autres informations utiles.
+ gravité, liste des versions disponibles, état de test <!-- ?? testing =
+distribution ?? --> et des liens vers d'autres informations utiles.
<p>
C'est une bonne idée de vérifier régulièrement vos données pour ne pas oublier
de bogues ouverts et pour ne pas oublier quels paquets sont sous votre
@@ -1498,8 +1505,8 @@
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 :
+Plusieurs raisons nous poussent à demander aux responsables
+ d'annoncer leur intention :
<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
@@ -1507,26 +1514,25 @@
<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>
-<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
+<item>Cela permet aux autres responsables de connaître le nouveau
+ paquet mieux que ne le permettent la description d'une ligne et l'habituelle
+ entrée de type changelog <em>Initial release</em> postée sur
<tt>debian-devel-changes</tt>.
<item>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.
<item>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
+ intéressées peuvent se faire une meilleure idée des évolutions et des
nouveautés du projet.
</list>
<sect1 id="changelog-entries">
Ajouter une entrée à debian/changelog
<p>
-Les modifications que vous apportez au paquet doivent être tracées dans le
- fichier <file>debian/changelog</file>. Ces traces doivent donner une
+Les modifications que vous apportez au paquet doivent être notifiés dans le
+ fichier <file>debian/changelog</file>. Ces notes doivent donner une
description concise des changements, expliquer pourquoi (si ce n'est pas
- clair) et indiquer si des rapports de bogue sont clos. Il faut aussi indiquer
+ clair) et indiquer si des rapports de bogue ont été clos. Il faut aussi indiquer
quand le paquet a été terminé. Ce fichier sera installé dans
<file>/usr/share/doc/<var>paquet</var>/changelog.Debian.gz</file> ou
<file>/usr/share/doc/<var>paquet</var>/changelog.gz</file> pour un paquet
@@ -1535,8 +1541,8 @@
Le fichier <file>debian/changelog</file> a une structure précise comportant
différents champs. Le champ <em>distribution</em> est décrit dans <ref
id="upload-dist">. Vous trouverez plus d'informations sur la structure de ce
- fichier dans la <em>charte Debian</em> dans la section
- « <file>debian/changelog</file> ».
+ fichier dans la section « <file>debian/changelog</file> » de la
+ <em>charte Debian</em>.
<p>
Les entrées du fichier <file>changelog</file> peuvent être
utilisées pour fermer des rapports de bogue au moment où le paquet est
@@ -1666,8 +1672,8 @@
</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
+ n'est pas important car même une modification triviale peut provoquer un
+ bogue. 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 correctif correspondant de
la nouvelle version amont et à l'appliquer à l'ancienne (faire un
@@ -1688,7 +1694,7 @@
décidera si votre paquet peut être inclus dans la distribution
<em>stable</em>. Soyez précis (et, si nécessaire, prolixe) 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é.
+ vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
<sect3 id="upload-t-p-u">Mettre à jour un paquet de la distribution
<em>testing-proposed-updates</em>
@@ -1732,8 +1738,8 @@
<tt>ftp-master</tt> et les déplacer ensuite vers &us-upload-dir;.
<p>
<em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquet
- cryptographique qui appartiendrait à <em>contrib</em> ou <em>non-free</em>.
- Les livraisons de ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
+ concernant la cryptographie qui appartiendrait à <em>contrib</em> ou <em>non-free</em>.
+ Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
id="upload-non-us">). De plus, les paquets contenant un logiciel protégé par
des brevets américains ne peuvent pas être envoyés sur
<tt>ftp-master</tt> ; selon le cas, ils peuvent peut-être pourtant être
@@ -1892,7 +1898,7 @@
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ées
+ paquets sur la distribution <em>unstable</em> sont installées
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
@@ -1946,7 +1952,7 @@
travail normal des porteurs qui compilent les paquets pour d'autres
architectures (voir <ref id="porting">). Un développeur peut aussi faire
des mises à jour indépendantes quand il corrige le paquet d'un autre
- développeur pour éliminer un trou de sécurité ou un bogue bloquant. Cela
+ développeur pour éliminer un problème de sécurité ou un bogue bloquant. Cela
se produit plus particulièrement en période de gel de la distribution de
développement ou quand le responsable officiel du paquet ne peut pas
fournir une correction dans un délai raisonnable.
@@ -2212,7 +2218,7 @@
simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait,
vous devez fermer les bogues qui ont été marqués comme fixés par la mise à
jour. Vous pouvez soit les fermer manuellement en envoyant les courriers
- nécessaires au BTS ou en ajoutant les <tt>closes: #nnnn</tt> nécessaires dans
+ nécessaires au BTS soit ajouter les <tt>closes: #nnnn</tt> nécessaires dans
l'entrée du changelog de votre prochain envoi.
<p>
Dans tous les cas, vous ne devriez pas être perturbé par la NMU. Une NMU n'est
@@ -2226,7 +2232,7 @@
<sect id="porting">Le portage
<p>
-Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas un
+Debian accepte un nombre croissant d'architectures. Même si vous n'êtes pas un
porteur et même si vous n'utilisez qu'une architecture, il est de votre
responsabilité de développeur d'être attentif aux questions de
portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
@@ -2249,6 +2255,7 @@
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. <!-- FIXME : vérifier stymie=bloquer ? -->
+<!-- oui, to be stymied = être dans une impasse -->
<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
@@ -2257,13 +2264,13 @@
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 :
+ des erreurs de mise en paquet dans le paquet source. Voici un
+ pense-bête pour les choses auxquelles vous devez être attentif :
<enumlist>
<item>
Vérifiez que les champs <tt>Build-Depends</tt> et
<tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
- corrects. Le meilleur moyen pour vérifier cela est d'utiliser le paquet
+ corrects. Le meilleur moyen de le vérifier est d'utiliser le paquet
<package>debootstrap</package> pour créer un environnement
<em>unstable</em> <em>chrooté</em>. Dans cet environnement
<em>chrooté</em> il faudra installer le paquet
@@ -2346,7 +2353,7 @@
La manière d'invoquer <prgn>dpkg-buildpackage</prgn> est la suivante :
<tt>dpkg-buildpackage -B -m<var>adresse-porteur</var></tt>. Bien sûr, remplacez
<var>adresse-porteur</var> par votre adresse électronique. Cette commande
- construira les partie du paquet qui dépendent de l'architecture, en utilisant
+ construira les parties du paquet qui dépendent de l'architecture, en utilisant
la cible <em>binary-arch</em> de <file>debian/rules</file>.
<sect2 id="binary-only-nmu">
@@ -2355,7 +2362,7 @@
Parfois l'envoi du portage initial pose problème car l'environnement dans lequel
le paquet a été construit n'était pas bon (bibliothèques plus à jour ou
obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler
- dans un environnement mis à jour. Cependant, dans cas cas, vous devez changer
+ dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer
le numéro de version pour que les mauvais anciens paquets soient remplacés dans
l'archive Debian (<prgn>katie</prgn> refuse d'installer de nouveaux paquets
s'ils n'ont pas un numéro de version supérieur à celui actuellement
@@ -2426,7 +2433,7 @@
du portage des paquets. Cette section contient un bref aperçu de cette
automatisation et du portage de ces outils ; veuillez vous reporter à la
documentation des paquets ou les références pour une information complète.</p>
-
+<!-- ou les références ?? -->
<sect2>
<heading>Listes de diffusion et pages web</heading>
<p>
@@ -2492,7 +2499,7 @@
petit. Il est fortement recommandé que les paquets de priorité
<tt>Standard</tt> ou qui font partie de la base aient des co-responsables.
<p>
-Habituellement, il y a un responsable principale et un ou plusieurs
+Habituellement, il y a un responsable principal et un ou plusieurs
co-responsables. Le responsable principal est celui dont le nom est indiqué
dans le champ <tt>Maintainer</tt> du fichier <file>debian/control</file>. Les
co-responsables sont tous les autres responsables.
@@ -2500,7 +2507,7 @@
Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez
simple :
<list>
-<item><p> Donner un accès au co-responsable aux sources à partir desquelles vous
+<item><p> Donner au co-responsable un accès aux sources à partir desquelles vous
construisez le paquet. Habituellement, cela implique que vous utilisiez un
système de contrôle de version comme <prgn>CVS</prgn> ou
<prgn>Subversion</prgn>.
@@ -2521,7 +2528,7 @@
<sect id="archive-manip">
- <heading>Déplacer, effacer, renommer, adopter et abandonner des paquets
+ <heading>Déplacer, effacer, nommer, adopter et abandonner des paquets
<p>
Certaines manipulations de l'archive ne sont pas accessibles avec le processus
de mise à jour automatisé. Elles sont appliquées manuellement par les
@@ -2557,19 +2564,19 @@
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é. Normalement, vous ne devriez avoir à supprimer des
- paquets que de <em>unstable</em> ou <em>experimental</em>. Les paquets de
+ demander sa suppression. N'oubliez pas de préciser de quelle distribution le
+ paquet doit être supprimé. Normalement, vous ne devriez avoir à supprimer que
+ des paquets de <em>unstable</em> ou de <em>experimental</em>. Les paquets de
<em>testing</em> ne sont pas supprimés directement. Ils sont plutôt enlevés
automatiquement après que le paquet a été supprimé de <em>unstable</em> et
- qu'aucun paquet de <em>testing</em> n'en dépend.
+ si aucun paquet de <em>testing</em> n'en dépend.
<p>
Vous devez également détailler les raisons justifiant cette demande. Ceci a pour
- but d'éviter les suppressions non-désirées et de garder une trace de la raison
+ but d'éviter les suppressions non désirées et de garder une trace de la raison
pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom
du paquet qui remplace celui à supprimer.
<p>
-Habituellement, vous ne pouvez demander la suppression que d'un paquet dont vous
+Vous ne pouvez demander la suppression d'un paquet que si vous en
êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
obtenir l'accord de son dernier responsable.
<p>
@@ -2593,16 +2600,16 @@
paquet avec un numéro de version postérieur à celui que vous voulez
remplacer. Les deux versions seront installées dans l'archive mais seule la
plus récente sera accessible dans <em>unstable</em> car la précédente sera
- immédiatement replacée par la nouvelle. Toutefois, si vous testez
+ immédiatement remplacée par la nouvelle. Toutefois, si vous testez
correctement vos paquets, le besoin d'en remplacer un ne devrait pas être
trop fréquent.
- <sect1>Remplacer ou renommer un paquet
+ <sect1>Remplacer ou nommer 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
+Il peut vous arriver de vous tromper en nommant un paquet et avoir besoin de
+ changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
+ votre fichier <file>debian/control</file> pour que votre nouveau paquet
+ remplace et entre en conflit avec l'ancien paquet que vous voulez remplacer
(Reportez-vous à la <url id="&url-debian-policy;" name="charte Debian"> pour
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
@@ -2610,8 +2617,8 @@
correctement les bogues du paquet en même temps.
<p>
D'autres fois, vous pouvez commettre une erreur en construisant le paquet et
- désirez le remplacer. La seule façon de faire ceci est d'incrémenter le numéro
- de verion et d'envoyer une nouvelle version. L'ancienne version expirera de la
+ désirez le remplacer. La seule façon de faire est d'incrémenter le numéro
+ de version et d'envoyer une nouvelle version. L'ancienne version expirera de la
façon habituelle. Notez que ceci s'applique à chaque partie de votre paquet, y
compris les sources : si vous désirez remplacer l'archive source amont de
votre paquet, vous devez l'envoyer avec un numéro de version différent. Une
@@ -2728,7 +2735,7 @@
<tt>close</tt> à l'adresse &email-bts-control;.Si vous le faites, le rapporteur
n'aura aucune information sur la clôture de son rapport.
- <sect1 id="bug-housekeeping">Nettoyage des bogues
+ <sect1 id="bug-housekeeping">Gestion générale des bogues
<p>
En tant que responsable de paquet, vous trouverez fréquemment des bogues dans
d'autres paquets ou vous aurez des bogues sur vos paquets qui sont en fait des
@@ -2782,10 +2789,10 @@
paquet est située l'erreur.
<p>
Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
- corresponde à notre définition de gravité des bogues. Ceci est dû au
+ corresponde à notre définition de gravité des bogues. C'est dû au
fait que les gens tendent à augmenter la gravité des bogues pour
- s'assurer que leurs bogues sont corrigés rapidement. Certains bogues
- peuvent même être rétrogradés en gravité <em>wishlist</em> (souhait)
+ s'assurer que leurs bogues seront corrigés rapidement. La gravité de
+ certains bogues peut même être rétrogradée en <em>wishlist</em> (souhait)
quand le changement demandé est seulement d'ordre cosmétique.
</item>
<item>
@@ -2818,8 +2825,8 @@
a été inclus dans le dépôt CVS, vous pouvez marquer le bogue avec
<tt>pending</tt> (en attente) pour informer que le bogue est corrigé et
qu'il sera fermé lors du prochain envoi (ajoutez le <tt>closes:</tt>
- dans le <file>changelog</file>). Ceci est particulièrement utile s'il y
- a plusieurs développeurs à travailler sur le même paquet.
+ dans le <file>changelog</file>). C'est particulièrement utile si
+ plusieurs développeurs travaillent sur le même paquet.
</item>
<item>
Une fois que le paquet corrigé est disponible dans la distribution
@@ -2830,7 +2837,7 @@
<sect1 id="bug-security">Gérer les bogues de sécurité
<p>
-À cause de leur nature sensible, les bogues liés à la sécurité doivent être
+À cause de leur nature sensible, <!-- pauvres petits --> les bogues liés à la sécurité doivent être
soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
aider les responsables ayant des problèmes de sécurité ou pour les corriger
@@ -2849,7 +2856,7 @@
<list compact>
<item>
les versions du paquet connues pour être affectées par le bogue. Vérifiez
- chaque version présente dans une distribution supportée de Debian ainsi
+ chaque version présente dans les distributions maintenues par Debian ainsi
que dans <em>testing</em> et dans <em>unstable</em>,
</item>
<item>
@@ -2902,7 +2909,7 @@
</item>
<item>
si le problème est grave (exploitable à distance, possibilité d'accéder
- aux privilèges administrateur), il est préférable de partager cette
+ aux privilèges d'administrateur), il est préférable de partager cette
information avec d'autres vendeurs et de coordonner une diffusion.
L'équipe de sécurité garde des contacts avec les différentes organisations
et individus et peut prendre soin des actions à mener.
@@ -2939,7 +2946,7 @@
une description du problème et de sa portée, y compris :
<list>
<item>
- le type du problème (escalade de provilège, déni de service,
+ le type du problème (escalade de privilège, déni de service,
etc.),
</item>
<item>
@@ -2984,13 +2991,12 @@
lorsque celle-ci est effectuée, donc tout changement qui est fait est
susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour
les bibliothèques : assurez-vous ne de jamais changer l'API ou l'ABI,
- quel que minimal que soit le changement.
+ quelque minimal que soit le changement.
<p>
Cela veut dire que passer à une version amont supérieure n'est pas une bonne
solution. À la place, les changements pertinents devraient être rétro-portés
vers la version présente dans la distribution <em>stable</em> de Debian.
-Habituellement, les développeurs amont sont de bonne volonté pour aider si
-besoin est. Sinon, l'équipe de sécurité Debian peut aider.
+Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.
<p>
Dans certains cas, il n'est pas possible de rétro-porter un correctif de
sécurité, par exemple, quand de grandes quantités de code source doivent être
@@ -2999,13 +3005,13 @@
l'équipe de sécurité au préalable.
<p>
Il existe une autre règle de conduite liée à cela : testez toujours vos
-changements. Si vous avez une exploitation du problème disponible, essayez-là et
+changements. Si une exploitation du problème existe, essayez-là et
vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet
corrigé. Testez aussi les autres actions normales car parfois un correctif de
sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
liées.
<p>
-Examinez et testez vos changements autant que possible. Vérifiez les différences
+Examinez et testez autant que possible vos changements. Vérifiez les différences
avec la version précédente de manière répétée (<prgn>interdiff</prgn> et
<prgn>debdiff</prgn> sont des outils utiles pour cela). Lors de la construction
de la correction, gardez les points suivants à l'esprit :
@@ -3021,7 +3027,7 @@
</item>
<item>
Assurez-vous que le numéro de version est correct. Il doit être plus élevé
- que celui du paquet actuel, mais moins que ceux des paquets des version
+ que celui du paquet actuel, mais moins que ceux des paquets des versions
des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
--compare-versions</tt>. Pour <em>testing</em>, il doit y avoir un numéro
de version supérieur dans <em>unstable</em>. S'il n'y en a pas encore (par
@@ -3036,7 +3042,7 @@
également.
</item>
<item>
- Si la source amont a été envoyée à security.debian.org auparavant (par une
+ Si la source amont a été envoyée auparavant à security.debian.org (par une
précédente mise à jour de sécurité), construisez le paquet sans la source
amont (<tt>dpkg-buildpackage -sd</tt>). Sinon, construisez-le avec le
source complet (<tt>dpkg-buildpackage -sa</tt>).
@@ -3044,11 +3050,11 @@
<item>
Assurez-vous d'utiliser exactement le même nom <file>*.orig.tar.gz</file>
que celui utilisé dans l'archive normale, sinon il ne sera pas possible de
- déplacer le correctif de sécurité dans l'archive principale plus tard.
+ déplacer plus tard le correctif de sécurité dans l'archive principale.
</item>
<item>
Assurez-vous, lors de la compilation du paquet, de compiler sur un système
- propre qui n'a que des paquets de la distribution pour laquelle vous
+ propre, dont tous les paquets appartiennent à la distribution pour laquelle vous
construisez le paquet. Si vous n'avez pas un tel système, vous pouvez
utiliser l'une des machines de debian.org (voir <ref
id="server-machines">) ou mettez en place un chroot (voir <ref id=
@@ -3058,12 +3064,12 @@
<sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
<p>
-Vous ne <em>DEVEZ PAS</em> envoyer un paquet dans la queue d'envoi de sécurité
+Vous <em>NE DEVEZ PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
exactement les impératifs de l'équipe, il causera beaucoup de problèmes, ainsi
que des délais dans la gestion de l'envoi indésirable.
<p>
-Vous ne <em>DEVEZ PAS</em> envoyer votre correction dans
+Vous <em>NE DEVEZ PAS</em> envoyer votre correction dans
<em>proposed-updates</em> sans vous coordonner avec l'équipe de sécurité. Les
paquets seront copiés de security.debian.org dans le répertoire
<file>proposed-updates</file> automatiquement. Si un paquet avec le même numéro
@@ -3078,13 +3084,13 @@
<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt>.
<p>
-Une fois que l'envoi vers la queue de sécurité a été accepté, le paquet sera
+Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera
automatiquement recompilé pour toutes les architectures et stocké pour
vérification par l'équipe de sécurité.
<p>
Les envois en attente d'acceptation ou de vérification ne sont accessibles que
-par l'équipe de sécurité. Cela est nécessaire car il pourrait y avoir des
+par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des
correctifs pour des problèmes de sécurités qui ne peuvent pas encore être
diffusés.
@@ -3094,7 +3100,7 @@
<var>distribution</var>-proposed-updates qui convient sur ftp-master ou dans
l'archive non-US.
- <sect1 id="upload-bugfix">Quand les rapports de bogue sont-il fermés par
+ <sect1 id="upload-bugfix">Quand les rapports de bogue sont-ils fermés par
une mise à jour ?
<p>
Si vous corrigez un bogue dans vos paquets, il est de votre responsabilité de
@@ -3131,7 +3137,7 @@
fichier <file>changelog</file>, n'hésitez pas à annuler tout dommage que
l'erreur a entrainé. Pour réouvrir un bogue fermé par erreur, envoyez une
commande <tt>reopen <var>XXX</var></tt> au robot de contrôle du système de
- suivi des bogues. Pour fermer tous les bogues restants qui ont été fixés par
+ suivi des bogues. Pour fermer tous les bogues restants qui ont été corrigés par
votre envoi, envoyez le fichier <file>.changes</file> à
<email>XXX-done@bugs.debian.org</email> où <var>XXX</var> est le numéro du
bogue.
@@ -3143,22 +3149,21 @@
<email>XXX-done@bugs.debian.org</email>.
<chapt id="best-pkging-practices">
- <heading>Les meilleurs pratiques de construction des paquets
+ <heading>Les meilleures pratiques pour la construction des paquets
<p>
La qualité de Debian est principalement due à la <url id="&url-debian-policy;"
name="charte Debian"> qui définit explicitement les obligations que tous les
paquets doivent suivre. Mais c'est également grâce à une histoire partagée
d'expériences qui va au-delà de la charte Debian, une accumulation d'années
d'expérience pour la construction des paquets ; des développeurs de grand
-talent ont créé de bons outils qui vous aideront, vous, le responsable Debian, à
+talent ont créé de bons outils qui vous aideront, vous, responsable Debian, à
créer et maintenir d'excellents paquets.
<p>
-Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Toutes
-les recommandations ne sont que cela, des recommandations et ne sont pas des
-obligations ou une charte. Ce sont seulement des astuces et conseils subjectifs
-et des liens collectés pour les développeurs Debian. Vous êtes libre de prendre
-et choisir ce qui vous convient le mieux.
+Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce
+ne sont que des recommandations, non pas des obligations ou des règles. Ce sont seulement des astuces et conseils subjectifs
+et des liens collectés pour les développeurs Debian. Prenez
+et choisissez ce qui vous convient le mieux.
<sect id="packaging-tools">
Outils d'empaquètement et cas communs
@@ -3167,11 +3172,11 @@
<p>
La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
<file>debian/rules</file> est que cela permet aux responsables d'utiliser et de
-partager une logique commune parmi un grand nombre de paquets. Prenez, par
-exemple, la question d'installer des entrées de menu : vous avez besoin de
+partager une logique commune pour un grand nombre de paquets. Prenez, par
+exemple, l'installation des entrées de menu : vous avez besoin de
placer un fichier dans <file>/usr/lib/menu</file> et d'ajouter des commandes aux
scripts de maintenance pour enregistrer et désenregistrer ces entrées de menu.
-Comme il s'agit d'une chose très commune pour les paquets, pourquoi chaque
+Comme il s'agit d'une chose très commune, pourquoi chaque
responsable devrait-il écrire sa propre version, parfois avec des bogues ?
Supposons également que le répertoire de menu soit modifié, chaque paquet
devrait être modifié.
@@ -3183,7 +3188,7 @@
reconstruits avec la nouvelle version du script et sans aucun changement
supplémentaire.
<p>
-L'<ref id="tools"> contient plusieurs systèmes d'aide différents. Le plus
+L'<ref id="tools"> contient plusieurs systèmes d'aide. Le plus
courant et le meilleur (à notre avis) système est <package>debhelper</package>.
Les précédents systèmes d'aide comme <package>debmake</package> étaient
« monolithiques » : vous ne pouviez pas choisir quelles parties
@@ -3239,16 +3244,17 @@
-->
<sect1 id="multiple-patches">
<heading>Appliquer des correctifs sur les sources ou appliquer des
- correctifs lors de la construction</heading>
+ correctifs lors de la construction ?</heading>
<p>
-Les gros paquets peuvent avoir plusieurs bogues que vous désirez corriger dans
- le paquet Debian. Si vous corrigez simplement le bogue dans les sources, si
- vous n'êtes pas soigneux, vous ne pourrez pas différencier facilement les
- nombreux correctifs que vous aurez appliqués. Cela devient très désordonné
- quand vous devez mettre à jour le paquet avec une nouvelle version amont qui
+Les gros paquets peuvent avoir plusieurs bogues que vous devez corriger.
+ Si vous corrigez sans faire attention les bogues dans les
+sources,
+ vous ne pourrez pas différencier facilement les
+ nombreux correctifs que vous aurez appliqués. Cela peut devenir trés
+compliqué de mettre à jour le paquet avec une nouvelle version amont qui
intègre certains correctifs (mais pas tous). Vous ne pouvez pas prendre
- l'ensemble des correctifs (par exemple, de fichiers <file>.diff.gz</file>) et
- décider quels correctifs il vous faut enlever en un bloc quand les bogues sont
+ l'ensemble des correctifs (par exemple, dans les fichiers <file>.diff.gz</file>) et
+ décider quels correctifs il vous faut enlever parceque les bogues ont été
corrigés en amont.
<p>
Une bonne solution est de conserver des correctifs séparés sous le répertoire
@@ -3257,7 +3263,7 @@
lors de la compilation (et de les enlever lors du nettoyage). Le paquet
<package>dbs</package> fournit également des facilités pour créer des
correctifs et garder une trace de leur utilité. Comme toujours lorsque vous
- utilisez des outils des maintenance, vous devrez lire la documentation
+ utilisez des outils des maintenance, vous devez lire la documentation
associée. Le paquet <package>hello-dbs</package> est un exemple simple qui
présente comment utiliser <package>dbs</package>.
<p>
@@ -3265,24 +3271,24 @@
<sect1 id="multiple-binary">Paquets binaires multiples
<p>
Un simple paquet source va souvent permettre de construire plusieurs paquets
- binaires différents, que ce soit en fournissant plusieurs saveurs du même
+ binaires différents, que ce soit pour fournir plusieurs saveurs du même
paquet (par exemple, les différents paquets <package>vim-*</package>) ou pour
créer plusieurs petits paquets au lieu d'un seul gros (par exemple, si
- l'utilisateur peut n'installer que la partie dont il a besoin et ainsi
+ l'utilisateur peut installer que la partie dont il a besoin et ainsi
économiser de l'espace disque).
<p>
Le second cas peut facilement être géré dans le fichier
<file>debian/rules</file>. Vous avez simplement besoin de déplacer les fichiers
appropriés du répertoire de construction dans les arborescence temporaires du
paquet. Vous pouvez le faire en utilisant <prgn>install</prgn> (approche
- vierge) ou <prgn>dh_install</prgn> (du <package>debhelper</package>).
+ vierge) <!-- vanilla = vierge ? --> ou <prgn>dh_install</prgn> (du <package>debhelper</package>).
Assurez-vous de vérifier les différentes permutations de paquets, en
garantissant que vous avez bien défini les dépendances entre les paquets dans
le fichier <file>debian/control</file>.
<p>
Le premier cas est un peu plus diffile car il implique de multiples
recompilations du même logiciel, mais avec différentes options de
- configurations. Le paquet <package>vim</package> est un exemple de la façon de
+ configuration. Le paquet <package>vim</package> est un exemple de la façon de
gérer cela avec un fichier rules écrit à la main.
<!-- &FIXME; Find a good debhelper example with multile configure/make cycles
@@ -3295,16 +3301,16 @@
<p>
Les scripts de maintenance incluent les fichiers <file>debian/postinst</file>,
<file>debian/preinst</file>, <file>debian/prerm</file> et
-<file>debian/postrm</file>. Ces scripts prennent soin de la configuration
-d'installation ou de désinstallation des paquets qui n'est pas gérée par l'ajout
-ou la suppression de fichiers et répertoires. Les instructions suivantes
-suppléent la <url id="&url-debian-policy;" name="charte Debian">.
+<file>debian/postrm</file>. Ces scripts prennent soin de l'installation et de
+ la suppression des paquets, ce qui n'est pas simplement créer ou
+supprimer des fichiers et des répertoires. Les instructions suivantes
+supplémentent <!-- la différence est subtile !! -->la <url id="&url-debian-policy;" name="charte Debian">.
<p>
Les scripts de maintenance doivent être idempotents. Cela veut dire que vous
devez vous assurer que rien de grave ne se produit si un script est appelé deux
fois là où il ne devrait habituellement être appelé qu'une fois.
<p>
-Les entrée et sortie standards peuvent être redirigées (par exemple, dans des
+Les entrée et sortie standard peuvent être redirigées (par exemple, dans des
tubes<footnote><p>pipes</p></footnote>) pour des besoins d'enregistrement
d'activité, donc vous ne devez pas supposer que ce sont des tty.
<p>
@@ -3316,15 +3322,15 @@
<p>
Gardez les scripts de maintenance aussi simples que possible. Nous vous
suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
-avez besoin d'une fonctionnalité de bash, le script de maintenance doit
-l'indiquer dans sa première ligne. Un shell POSIX ou le Bash sont préférés à
+avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
+l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à
Perl car ils permettent à <package>debhelper</package> d'ajouter facilement des
parties aux scripts.
<p>
Si vous modifiez les scripts de maintenance, assurez-vous de tester la
suppression du paquet, la double installation et la purge complète. Assurez-vous
-qu'un paquet purgé est bien complètement parti, c'est-à-dire, qu'il doit enlever
-tout fichier créé, directement ou indirectement, dans tous les scripts de
+qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever
+tout fichier créé, directement ou indirectement, par les scripts de
maintenance.
<p>
Si vous avez besoin de vérifier l'existence d'une commande, vous devriez
@@ -3332,7 +3338,7 @@
<example>if [ -x /usr/sbin/install-docs ]; then ...</example>
Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de
-maintenance, la fonction de shell suivante conforme avec POSIX peut vous
+maintenance, la fonction de shell suivante conforme à POSIX peut vous
aider :
&example-pathfind;
@@ -3342,9 +3348,9 @@
trouvé et faux sinon. Il s'agit réellement de la façon la plus portable de faire
car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn> ne sont pas
POSIX. Bien que <prgn>which</prgn> soit une alternative acceptable car il est
-présent dans le paquet nécessaire <package>debianutils</package>, il n'est pas
-présent dans la partition racine, bien que ce n'est probablement pas quelque
-chose qui puisse poser problème.
+présent dans le paquet classé <em>required</em><package>debianutils</package>, il n'est pas
+présent dans la partition racine ; mais cela ne posera sans doute pas de
+problème.
<sect id="bpp-debian-control">
@@ -3353,25 +3359,25 @@
<p>
Les pratiques suivantes viennent en complément de la <url
id="&url-debian-policy;ch-miscellaneous.html#s-descriptions"
- name="charte sur les descriptions de paquet">.</p>
+ name="règles pour les descriptions de paquet">.</p>
<sect1 id="bpp-pkg-desc">
<heading>Écrire des descriptions utiles</heading>
<p>
La description du paquet (telle qu'elle est définie dans le champ correspondant
- dans le fichier <file>control</file>) est habituellement la première
- information que l'utilisateur a de disponible avant de l'installer. Aussi,
+ du fichier <file>control</file>) est habituellement la première
+ information dont dispose l'utilisateur avant d'installer un paquet. Aussi,
elle devrait fournir toutes les informations nécessaires pour le laisser
décider de l'installation du paquet.
<p>
-Pour des raisons de consistence et d'esthétisme, vous devriez mettre en
- majuscule la première lettre de la description. Ne mettez pas de point (de
- ponctuation) à la fin. La description devrait elle-même n'être constituée
+Pour des raisons de cohérence et d'esthétique, vous devriez mettre en
+ majuscule la première lettre du résumé de la description. Ne mettez pas
+de point à la fin. La description elle-même devrait n'être constituée
que de phrases entières.
<p>
Enfin, comme la première impression de l'utilisateur est basée sur cette
- description, vous devriez être vigilant pour éviter des fautes d'anglais.
- Assurez-vous de passer un vérificateur orthographique dessus.
+ description, vous devriez éviter les fautes d'orthographe et de grammaire.
+ N'oubliez pas votre vérificateur orthographique.
<prgn>ispell</prgn> possède une option spéciale (<tt>-g</tt>) pour
cela : <example>ispell -d american -g debian/control</example>. Si
vous voulez qu'une personne relise la description que vous avez l'intention
@@ -3393,13 +3399,13 @@
lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez vous
reporter à <url id="&url-eg-desc-upstream-info;">.
<p>
-S'il n'existe pas de page d'accueil pour le logiciel, ceci devrait naturellement
-être laissé vide.
+Ne mettez rien s'il n'existe pas de page pour le logiciel.
+
<p>
-Veuillez noter que nous nous attendons à ce que ce champ soit remplacé par un
+Veuillez noter que nous espèrons que ce champ sera remplacé par un
vrai champ de <file>debian/control</file> que comprendraient <prgn>dpkg</prgn>
-et <tt>&packages-host;</tt>. Si vous ne voulez pas être préoccupé à migrer la
-page d'accueil de la description dans ce nouveau champs, vous devriez
+et <tt>&packages-host;</tt>. Si vous ne voulez pas vous embêter à mettre la
+page d'accueil de la description dans ce nouveau champ, vous devriez
probablement attendre qu'il soit disponible.</p>
</sect1>
</sect>
@@ -3416,13 +3422,14 @@
<p>
<p>
-<package>Debconf</package> est un système de gestion de la configuration qui
- peut être utilisé par tous les divers scripts d'empaquètement (principalement
- en post-installation dans le fichier <file>postinst</file>) pour demander une
- information à l'utilisateur concernant la configuration du paquet. Les
- interactions directes avec l'utilisateur doivent maintenant être évitées en
- faveur d'interactions de <package>debconf</package>. Ceci permettra à l'avenir
- des installations non-interactives.
+<package>Debconf</package> est un système de gestion de configuration qui
+ peut être utilisé par les divers scripts de maintenance (principalement
+ en post-installation dans le fichier <file>postinst</file>) pour demander à
+l'utilisateur des informations concernant la configuration du paquet. Il
+faut maintenant éviter les interactions directes avec l'utilisateur et
+préférer les interactions utilisant <package>debconf</package>. Ceci permettra
+ à l'avenir des installations non interactives. <!-- pas de trait d'union
+entre non et adjectif -->
<p>
Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
communes sont référencées dans la page de manuel <manref section="8"
@@ -3445,11 +3452,11 @@
langue maternelle, il se peut que vous deviez être particulièrement patient
avec eux.
<p>
-Le but de <package>debconf</package> était de rendre la configuration des
-paquets aisée pour les responsables et les utilisateurs. À l'origine, les
+Le but de <package>debconf</package> était de faciliter la configuration des
+paquets aux responsables et aux utilisateurs. À l'origine, les
traductions des questionnaires debconf étaient gérées avec
<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
-dépréciée ; la meilleure façon pour l'internationalisation de
+déconseillée ; la meilleure façon pour l'internationalisation de
<package>debconf</package> est d'utiliser le paquet
<package>po-debconf</package>. Cette méthode est plus facile et pour le
responsable et pour les traducteurs ; des scripts de transition sont
@@ -3459,7 +3466,7 @@
stockée dans des fichiers <file>po</file> (à l'instar des techniques de
traduction de <prgn>gettext</prgn>). Des fichiers modèles contiennent les
messages d'origine et indiquent quels sont les champs traduisibles. Quand vous
-modifiez l'état d'un champs traduisible en appelant
+modifiez l'état d'un champ traduisible en appelant
<prgn>debconf-updatepo</prgn>, la traduction est marquée comme ayant besoin de
l'attention des traducteurs. Puis, lors de la construction du paquet, le
programme <prgn>dh_installdebconf</prgn> prendra soin de toute la magie
@@ -3479,7 +3486,7 @@
plus facile pour les traducteurs d'avoir accès à un système de contrôle de
source. Ceci permet aux traducteurs de voir les différences entre deux versions
de la documentation, pour, par exemple, qu'ils puissent voir ce qui a besoin
-d'être retraduit. Il est recommandé que le document traduit inclut une note à
+d'être retraduit. Il est recommandé que le document traduit inclue une note à
propos de la révision de contrôle du source sur laquelle la traduction est
basée. Un système intéressant est fourni par <url id="&url-i18n-doc-check;"
name="doc-check"> dans le paquet <package>boot-floppies</package> qui donne un
@@ -3489,9 +3496,9 @@
est basée. Vous pouvez vouloir adapter et fournir ceci dans votre dépôt CVS.
<p>
Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons
-d'isoler les informations indépendantes de tout langage et de définir celles-ci
-comme entités dans un fichier séparé qui sera inclus par les différentes
-traductions. Ceci aide, par exemple, à garder à jour les adresses parmi
+d'isoler les informations indépendantes de la langue et de les définir
+comme des entités dans un fichier séparé qui sera inclus par les différentes
+traductions. Ceci aide, par exemple, à garder à jour les adresses pour
plusieurs fichiers.
</sect1>
</sect>
@@ -3542,10 +3549,9 @@
<sect1 id="bpp-autotools">
<heading>Paquets utilisant <prgn>autoconf</prgn>/<prgn>automake</prgn>
<p>
-Conserver des fichiers d'<prgn>autoconf</prgn> <file>config.sub</file> et
-<file>config.guess</file> à jour est critique pour les porteurs, spécialement
-pour les architectures plus changeantes. De très bonnes pratiques d'empaquetage de
-paquet utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été
+Conserver à jour les fichiers d'<prgn>autoconf</prgn>, <file>config.sub</file> et
+<file>config.guess</file>, est critique pour les porteurs, spécialement
+pour les architectures plus changeantes. De très bonnes pratiques d'empaquetage utilisant <prgn>autoconf</prgn> et/ou <prgn>automake</prgn> ont été
regroupées dans &file-bpp-autotools; du paquet <package>autotools-dev</package>.
Vous êtes vivement encouragé à lire ce fichier et à suivre les recommandations
indiquées.
@@ -3557,7 +3563,7 @@
raisons. La charte impose plusieurs contraintes pour faciliter la maintenance
et pour garantir que les mises à jour sont aussi simples que possible quand une
nouvelle version amont est disponible. Une erreur dans une bibliothèque peut
- entraîner qu'une douzaines de paquets qui en dépendent seront cassés.
+ rendre défectueux une douzaine de paquets qui en dépendent.
<p>
Les bonnes pratiques d'empaquètement des bibliothèques ont été regroupées dans
<url id="&url-libpkg-guide;" name="le guide d'empaquètement des
@@ -3565,21 +3571,20 @@
<sect1 id="bpp-docs">Documentation
<p>
-Assurez-vous de suivre la <url id="&url-debian-policy;ch-docs.html" name="charte
- de la documentation">.</p>
+Assurez-vous de suivre les <url id="&url-debian-policy;ch-docs.html" name="regles sur la documentation">.</p>
<p>
Si votre paquet contient de la documentation construite à partir de XML ou SGML,
nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s)
paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la
-documentation, ils devraient récupérer le paquet source.</p>
+documentation, ils peuvent récupérer le paquet source.</p>
<p>
-La charte spécifie que la documentation devrait être fournie au format HTML.
+La charte spécifie que la documentation doit être fournie au format HTML.
Nous vous recommandons également de la fournir au format PDF et texte simple si
c'est adapté et qu'une sortie de qualité est possible. Cependant, il n'est
généralement pas approprié de fournir des versions en texte simple pour la
documentation dont le format source est du HTML.</p>
<p>
-Les principaux manuels fournis devraient s'enregistrer auprès du paquet
+Les principaux manuels fournis devraient être enregistrés par le paquet
<package>doc-base</package> à l'installation. Reportez-vous à la documentation
du paquet <package>doc-base</package> pour plus d'information.</p>
@@ -3630,28 +3635,29 @@
<chapt id="beyond-pkging">
<heading>Au-delà de l'empaquètement
<p>
-Debian, c'est beaucoup plus que simplement de l'empaquètement de logiciels et de
- la maintenance de ces paquets. Ce chapitre contient des informations sur les
- façons, souvent vraiment critiques, de contribuer à Debian au-delà de la
+Debian, c'est beaucoup plus que de l'empaquètement de logiciels et de
+ la maintenance de paquets. Ce chapitre contient des informations sur les
+ façons, souvent vraiment importantes, de contribuer à Debian au-delà de la
simple création et maintenance de paquets.
<p>
-En tant qu'organisation de volontaires, Debian repose sur la discrétion de ses
- membres pour choisir ce sur quoi ils désirent travailler et choisir la
- partie la plus critique à laquelle ils veulent consacrer leur temps.
+En tant qu'organisation de volontaires, Debian repose sur la liberté de
+ choisir ce sur quoi l'on désire travailler et de choisir la
+ partie la plus importante à laquelle on veut consacrer son temps.
+<!-- dur de rendre intelligent un texte redondant !! -->
<sect id="submit-bug">
<heading>Rapporter des bogues
<p>
Nous vous encourageons à remplir des rapports de bogue quand vous trouvez des
bogues dans les paquets Debian. En fait, les développeurs Debian sont souvent
- les testeurs en première ligne. Trouver et rapporter les bogues dans les
+ les testeurs de première ligne. Trouver et rapporter les bogues dans les
paquets d'autres développeurs améliore la qualité de Debian.
<p>
-Essayez de soumettre le bogue d'un compte utilisateur normal sur lequel vous
- êtes susceptible de recevoir des courriers. Ne soumettez pas de bogues en tant
+Essayez de soumettre le bogue à partir d'un compte utilisateur normal sur lequel vous
+ pouvez recevoir des courriers. Ne soumettez pas de bogues en tant
que root.
<p>
-Assurez-vous que le bogue n'a pas déjà été rapporté sur un paquet. Essayez de
+Assurez-vous que le bogue n'a pas déjà été rapporté. Essayez de
faire du bon boulot quand vous rapportez le bogue et indiquez l'emplacement
exact. Vous pouvez également parcourir les bogues d'autres paquets, en les
regroupant s'ils sont indiqués plus d'une fois, ou en modifiant la gravité d'un
@@ -3690,15 +3696,14 @@
<sect1 id="qa-daily-work">Travail journalier
<p>
-Bien qu'il y ait un groupe dédié de personnes pour l'assurance qualité, les
+Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
cet effort en conservant vos paquets aussi exempts de bogues que possible et
- aussi propres selon <prgn>lintian</prgn> (reportez-vous à <ref id="lintian">)
- que possible. Si vous ne trouvez pas que cela est possible, vous devriez alors
- considérer d'abandonner certains de vos paquets (reportez-vous à <ref
+ aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref id="lintian">). Si cela vous paraît impossible, vous devriez alors
+ envisager d'abandonner certains de vos paquets (reportez-vous à <ref
id="orphaning">). Sinon, vous pouvez demander de l'aide à d'autres personnes
- pour qu'elles puissent reprendre le retard de bogues que vous avez (vous pouvez
- demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
+ pour qu'elles puissent rattraper votre retard dans la correction des bogues
+(vous pouvez demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
id="collaborative-maint">).
@@ -3708,8 +3713,8 @@
bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
supprimer le plus de problèmes possible. Elles sont annoncées sur
&email-debian-devel-announce; et l'annonce explique quel domaine sera visé
- pendant la chasse : habituellement, il s'agit des bogues critiques pour la
- version (« Release Critical »), mais il peut arriver qu'ils décident
+ pendant la chasse : habituellement, il s'agit des bogues empêchant
+l'intégration du paquet dans la distribution (« Release Critical »), mais il peut arriver qu'ils décident
d'aider à finir une transition majeure (comme une nouvelle version de Perl qui
demande la recompilation de tous les modules binaires).
<p>
@@ -3734,7 +3739,7 @@
<p>
Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle
devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une
- mise à jour cassée.
+ mise à jour défectueuse.
<sect id="mia-qa">Gérer les responsables non joignables
<p>
@@ -3774,13 +3779,12 @@
<sect id="newmaint">
- <heading>Interagir avec des développeurs prospectifs de Debian
+ <heading>Interagir avec de futurs développeurs Debian
<p>
Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
recommandons de vous impliquer dans le processus d'apport des nouveaux
- responsables. Cette section décrit comment aider les développeurs
- prospectifs.
+ responsables. Cette section décrit comment aider les futurs développeurs.
<sect1 id="sponsoring">Parrainer des paquets
@@ -3799,13 +3803,13 @@
devront également l'inspecter avant de l'intégrer)
<p>
Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
- paquet n'est <strong>définitivement pas recommandé</strong>. Vous devez
+ paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
construire le paquet source comme si vous vouliez construire l'un de vos
paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
- candidat développeur prospectif dans le changelog et dans le fichier de
- contrôle, l'envoi peut toujours être tracé comme venant de vous.
+ candidat développeur dans le changelog et dans le fichier de
+ contrôle, l'envoi peut toujours vous être attribué.
<p>
-Si vous êtes un gestionnaire de candidature pour un développeur prospectif, vous
+Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
candidat gère la partie « Tâches et Capacités »<footnote>Tasks and
Skills</footnote> de sa candidature.
@@ -3918,8 +3922,7 @@
Beaucoup pensent que ce système devrait être utilisé pour tout paquet
nécessitant une configuration interactive ; reportez-vous à <ref
id="bpp-config-mgmt">. <package>debconf</package> n'est pas requis par la
- <em>charte Debian</em> pour le moment ; cependant, cela pourra changer
- dans le futur.
+ <em>charte Debian</em> pour le moment ; cependant, cela pourra changer.
</sect1>
<sect1 id="fakeroot">
@@ -4028,8 +4031,8 @@
<p>
Quoique les fichiers de règles générés par <prgn/dh_make/ constituent en général
une base suffisante pour un paquet fonctionnel, ce ne sont que les
-fondations : la charge incombe toujours au responsable à affiner avec
-précision les fichiers générés et à rendre le paquet complètement fonctionnel et
+fondations : la charge incombe toujours au responsable d'affiner
+les fichiers générés et de rendre le paquet complètement fonctionnel et
en conformité avec la charte.
</sect1>
@@ -4073,6 +4076,9 @@
récupérer des paquets sources dans un référentiel CVS, il permet de fabriquer
un paquet Debian depuis le référentiel CVS et il assiste le développeur lors de
l'intégration de modifications amonts dans le référentiel.
+<!-- plus haut tu as choisi dépôt au lieu de référentiel. Moi je préfère
+référentiel. mais tu dois choisir une traduction. -->
+
<p>
Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le
responsable Debian. Il permet de conserver des branches CVS distinctes pour les
@@ -4187,7 +4193,7 @@
<sect1 id="dpkg-repack">
<heading><package>dpkg-repack</package></heading>
<p>
-<prgn>dpkg-repack</prgn> crée un fichier paquet Debian à partir d'un paquet qui
+<prgn>dpkg-repack</prgn> crée un paquet Debian à partir d'un paquet qui
a déjà été installé. Si des changements ont été effectués sur le paquet quand il
a été décompressé (par exemple, des fichiers dans <file>/etc</file> ont été
modifés), le nouveau paquet héritera de ces changements.</p>
@@ -4247,7 +4253,7 @@
croisée<footnote><p><em>cross-compilation</em></footnote> d'une manière
similaire à <package>dpkg</package>. De plus, les paquets
<prgn>dpkg-buildpackage</prgn> et <prgn>dpkg-shlibdeps</prgn> ont été
- améliorés pour supporter les compilations croisées.
+ améliorés pour accepter les compilations croisées.
<sect id="tools-doc">
<heading>Documentation et information</heading>
Reply to: