[DDR] debian-doc://ddp/manuals.sgml/developers-reference/developers-reference.fr.sgml
Bonsoir à tous,
Je viens de mettre à jour la traduction de la dernière version de la
Référence du développeur Debian (du paquet developers-reference v3.3.3)
Voici le fichier developers-reference.fr.sgml.diff (par rapport à la
version v1.37 du CVS Debian). Vous pouvez également consulter le
document complet source SGML (ou compressé) à :
http://olympie.dyndns.org/debian/doc/dev-ref/ ainsi que sous différents
formats (HTML, texte, ps, pdf).
Merci d'avance pour les relectures.
Fred
Index: developers-reference.fr.sgml
===================================================================
RCS file: /cvs/debian-doc/ddp/manuals.sgml/developers-reference/developers-reference.fr.sgml,v
retrieving revision 1.37
diff -u -r1.37 developers-reference.fr.sgml
--- developers-reference.fr.sgml 4 May 2003 14:32:31 -0000 1.37
+++ developers-reference.fr.sgml 19 Jun 2003 22:45:33 -0000
@@ -6,11 +6,11 @@
<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.37 $">
+ <!entity cvs-rev "$Revision: 1.38 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
- <!entity cvs-en-rev "1.197">
+ <!entity cvs-en-rev "1.207">
-->
<!-- -->
@@ -31,11 +31,11 @@
<translator>version française par Antoine Hulin</translator>
<translator>et Frédéric Bothamy (traducteur actuel)</translator>
<translator>et les membres de la liste <email>debian-l10n-french@lists.debian.org</email></translator>
- <version>Version &version;, &date-fr; (version française 20030502).</version>
+ <version>Version &version;, &date-fr; (version française 20030620).</version>
<copyright>
<copyrightsummary>Copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
- <copyrightsummary>Copyright © 2002 Raphaël Hertzog</copyrightsummary>
+ <copyrightsummary>Copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
<copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary>
<p>
Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié
@@ -972,7 +972,7 @@
de contrôle (<prgn>md5sums</prgn>) et quelques informations supplémentaires
concernant le paquet (responsable, version, etc.).
- <sect1>Les répertoires des distributions
+ <sect1>Les distributions
<p>
L'organisation des répertoires présentée précédemment est elle-même englobée par
les <em>répertoires des distributions</em>. Chaque distribution est incluse
@@ -1046,6 +1046,61 @@
Notez que, pendant la période de gel, les développements continuent sur la
distribution <em>unstable</em> car cette distribution reste en place.
+ <sect2 id="testing">
+ <heading>Informations complémentaires sur la distribution
+ « testing »</heading>
+<p>
+Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
+ chaque jour après l'installation des paquets mis à jour. Ils génèrent les
+ fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
+ le font d'une manière intelligente pour éviter toute incohérence et essayer de
+ n'utiliser que des paquets sans bogue.
+<p>
+L'inclusion d'un paquet d'<em>unstable</em> est soumise aux
+ conditions suivantes :
+<list compact="compact">
+<item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis
+ plusieurs jours ; le nombre précis dépend du champ d'urgence de
+ 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 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
+ 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> 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>
+Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
+ sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
+id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
+inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
+informé de la progression de ses paquets dans <em>testing</em>, on peut
+facilement le mettre dans la <manref
+ section="5" name="crontab">.
+<p>
+Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
+ pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
+ regardant ce qui serait cassé avec l'inclusion du paquet. La <url
+ id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
+ d'informations à propos des problèmes courants qui peuvent occasionner cela.
+<p>
+Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
+ jeu des inter-relations est trop compliqué et ne peut être résolu par le
+ script. Dans ce cas, le responsable de version doit être contacté et il forcera
+ l'inclusion du paquet.
+ <p>
+En général, veuillez vous référer à la <url name="page web de la distribution testing"
+id="&url-testing-maint;"> pour plus d'informations. Cette page inclut également
+des réponses aux questions fréquemment posées.
+
+
<sect2 id="experimental">Experimental
<p>
La distribution <em>experimental</em> est une distribution particulière. Ce n'est
@@ -1245,60 +1300,6 @@
<example>DELAY=5 dupload --to delayed <changes-file></example>
- <sect id="testing">
- <heading>La distribution « testing »
-<p>
-Les scripts qui mettent à jour la distribution <em>testing</em> sont exécutés
- chaque jour après l'installation des paquets mis à jour. Ils génèrent les
- fichiers <file>Packages</file> pour la distribution <em>testing</em>, mais ils
- le font d'une manière intelligente pour éviter toute incohérence et essayer de
- n'utiliser que des paquets sans bogue.
-<p>
-L'inclusion d'un paquet d'<em>unstable</em> est soumise aux
- conditions suivantes :
-<list compact="compact">
-<item><p>Le paquet doit avoir été disponible dans <em>unstable</em> depuis
- plusieurs jours ; le nombre précis dépend du champ d'urgence de
- 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 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
- 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> 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>
-Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
- sortie du script de <em>testing</em> sur la <url name="page web de la distribution testing"
-id="&url-testing-maint;"> ou utilisez le programme <prgn>grep-excuses</prgn>
-inclus dans le paquet <package>devscripts</package>. Si l'on veut rester
-informé de la progression de ses paquets dans <em>testing</em>, on peut
-facilement le mettre dans la <manref
- section="5" name="crontab">.
-<p>
-Le fichier <file>update_excuses</file> ne donne pas toujours la raison précise
- pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en
- regardant ce qui serait cassé avec l'inclusion du paquet. La <url
- id="&url-testing-maint;" name="page web de la distribution testing"> donne plus
- d'informations à propos des problèmes courants qui peuvent occasionner cela.
-<p>
-Parfois, certains paquets n'entrent jamais dans <em>testing</em> parce que le
- jeu des inter-relations est trop compliqué et ne peut être résolu par le
- script. Dans ce cas, le responsable de version doit être contacté et il forcera
- l'inclusion du paquet.
- <p>
-En général, veuillez vous référer à la <url name="page web de la distribution testing"
-id="&url-testing-maint;"> pour plus d'informations. Cette page inclut également
-des réponses aux questions fréquemment posées.
-
-
<sect id="pkg-info">Informations sur un paquet
<p>
@@ -1336,10 +1337,6 @@
<sect id="pkg-tracking-system">Système de suivi des paquets
-<!-- FIXME: talk about
-http://qa.debian.org/developer.php?login=aph@debian.org
-http://packages.qa.debian.org/
-http://packages.qa.debian.org/pkgname -->
<p>
Le système de suivi des paquets (PTS)<footnote>« Package Tracking
System »</footnote> est un outil pour suivre par courrier l'activité
@@ -1370,7 +1367,11 @@
<tag><tt>default</tt>
<item>Tout courrier non automatique envoyé au PTS par les personnes qui
- veulent contacter les inscrits au paquet.
+ veulent contacter les inscrits au paquet. Ceci peut être fait en
+ envoyant un courrier à <tt><var>srcpackage</var>@&pts-host;</tt>. Pour
+ prévenir l'envoi de spam, les courriers envoyés à ces adresses doivent
+ contenir l'en-tête « X-PTS-Approved » avec une chaîne non
+ vide.
<tag><tt>summary</tt>
<item>À l'avenir, vous pourriez recevoir des courriers de résumé pour vous
@@ -1496,6 +1497,93 @@
Seules les personnes qui ont accepté le mot-clé <em>cvs</em> recevront les
notifications.
+ <sect1 id="pts-web">L'interface web du PTS
+<p>
+Le PTS a été étendu avec une interface web qui réunit plusieurs informations au
+même endroit à propos de chaque paquet source. Il propose plusieurs liens utiles
+(BTS, statistiques QA, informations de contact, état de traduction DDTP,
+journaux de compilation automatique) et il regroupe d'autres informations
+provenant de différents endroits (les 30 dernières entrées de changelog, l'état
+dans <em>testing</em>, etc.). Il s'agit d'un outil très pratique si vous désirez
+connaître ce qu'il en est d'un paquet source spécifique. De plus, il y a un
+formulaire qui vous permet facilement de vous inscrire au service de courrier
+fourni par le PTS.
+ <p>
+Vous pouvez aller directement à la page web concernant un paquet source avec une
+URL comme <tt>http://&pts-host;/<var>srcpackage</var></tt>. Vous pouvez sinon y
+accéder par la <url id="http://&pts-host;"; name="page principale">.
+<p>
+Cette interface a été conçue comme un portail pour le développements des
+paquets : vous pouvez ajouter du contenu personnalisé aux pages de vos
+paquets. Vous pouvez ajouter des « informations
+statiques »<footnote><em>Static information</em></footnote> (des annonces
+qui sont destinées à rester disponibles indéfiniment) et des nouvelles dans la
+section « dernières nouvelles »<footnote><em>Latest
+news</em></footnote>.
+<p>
+Les annonces statiques peuvent être utilisées pour indiquer :
+<list>
+<item>la disponibilité d'un projet hébergé sur alioth.debian.org pour la
+co-maintenance du paquet,
+<item>un lien vers le site web amont,
+<item>un lien vers le suivi de bogues amont,
+<item>l'existence d'un canal IRC dédié au logiciel,
+<item>toute autre ressource disponible qui peut être utile à la maintenance du paquet.
+</list>
+Les nouvelles usuelle peuvent être utilisées pour annoncer que :
+<list>
+<item>des paquets bêta sont disponibles pour test,
+<item>des paquets finaux sont attendus pour la semaine prochaine,
+<item>l'empaquètement est sur le point d'être intégralement refait,
+<item>des rétro-portages sont disponibles,
+<item>le responsable est en vacance (s'il désire publier cette information),
+<item>une mise à jour indépendante (NMU) est en cours de réalisation,
+<item>quelque chose d'important va affecter le paquet.
+</list>
+<p>
+Les deux types d'informations sont générés de façon similaire : il vous
+suffit d'envoyer un courrier soit à <email>pts-static-news@qa.debian.org</email>
+(pour les annonces statiques), soit à <email>pts-news@qa.debian.org</email>
+(pour les nouvelles usuelles). Le courrier devrait indiquer quel paquet est
+concerné par la nouvelle en donnant le nom du paquet source dans un en-tête de
+courrier <tt>X-PTS-Package</tt> ou dans un pseudo-en-tête <tt>Package</tt>
+(comme pour les rapports de bogue du BTS). Si une URL est disponible dans
+l'en-tête de courrier <tt>X-PTS-Url</tt> ou dans un pseudo-en-tête <tt>Url</tt>,
+le résultat est un lien vers cette URL au lieu d'une nouvelle complète.
+<p>
+Voici quelques exemples de courriers valides utilisés pour générer des nouvelles dans
+le PTS. Le premier ajoute un lien vers l'interface cvsweb de debian-cd dans la
+section « Informations statiques ».
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: pts-static-news@qa.debian.org
+Subject: Browse debian-cd CVS repository with cvsweb
+
+Package: debian-cd
+Url: http://cvs.debian.org/debian-cd/
+</example>
+Le second est une nouvelle envoyée à une liste de diffusion et également
+envoyée au PTS pour qu'elle soit publiée sur la page web du PTS du paquet. Notez
+l'utilisation du champ BCC pour éviter que des réponses ne soient envoyées par
+erreur au PTS ...
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: debian-gtk-gnome@lists.debian.org
+Bcc: pts-news@qa.debian.org
+Subject: Galeon 2.0 backported for woody
+X-PTS-Package: galeon
+
+Hello gnomers !
+
+I'm glad to announce that galeon has been backported for woody. You'll find
+everything here:
+...
+</example>
+<p>
+Réfléchissez-y à deux fois avant d'ajouter une nouvelle au PTS car vous ne
+pourrez pas l'enlever par la suite et vous ne pourrez pas non plus l'éditer. La
+seule chose que vous puissiez faire est d'envoyer une deuxième nouvelle qui va
+déprécier l'information contenue dans la première nouvelle.
<sect id="ddpo">Vue d'ensemble des paquets d'un développeur
<p>
@@ -1554,7 +1642,7 @@
personne travaille déjà dessus.
<item>D'autres personnes qui envisagent de travailler sur le même paquet
apprendront ainsi qu'il existe déjà un volontaire, l'effort peut alors
- être partagé.</item>
+ être partagé.
<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
@@ -1698,8 +1786,8 @@
distributions. En particulier, il est absurde de combiner la distribution
<em>experimental</em> avec tout autre chose.
- <sect1 id="upload-stable">Mise à jour d'un paquet de la distribution
- <em>stable</em>
+ <sect1 id="upload-stable">Cas spécial mise à jour d'un paquet de
+ la distribution <em>stable</em>
<p>
Livrer un paquet pour la distribution <em>stable</em> signifie que le paquet
sera dirigé vers le répertoire <file>stable-proposed-updates</file> des
@@ -1710,20 +1798,22 @@
supplémentaires. Un paquet de cette distribution ne devrait être mis à jour
que dans les cas suivants :
<list>
-<item>un problème de sécurité (un avis de sécurité Debian<footnote>Debian
- security advisory</footnote>),
<item>un problème fonctionnel vraiment critique,
<item>un paquet devenu ininstallable,
<item>un paquet indisponible pour une architecture.
</list>
<p>
+Par le passé, des envois vers <em>stable</em> étaient également utilisés pour
+corriger les problèmes de sécurité. Cependant, cette pratique est dépréciée car
+les envois utilisés pour les avis de sécurité Debian<footnote>Debian security
+advisory</footnote> sont automatiquement copiés dans l'archive
+<file>proposed-updates</file> appropriée quand l'avis est publié. Reportez-vous
+à <ref id="bug-security"> pour des informations plus détaillées sur la gestion
+des problèmes de sécurité.
+<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 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
- rétroportage<footnote><em>backport</em></footnote> du correctif).
+ bogue.
<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
@@ -1742,8 +1832,8 @@
décrivez, dans le fichier changelog, vos changements pour une livraison
vers <em>stable</em>, sinon le paquet ne sera pas pris en considération.
- <sect1 id="upload-t-p-u">Mise à jour d'un paquet de la distribution
- <em>testing-proposed-updates</em>
+ <sect1 id="upload-t-p-u">Cas spécial : Mise à jour d'un paquet de la
+ distribution <em>testing-proposed-updates</em>
<p>
La distribution <em>testing</em> est peuplée avec des paquets en provenance
d'<em>unstable</em> selon des règles expliquées dans <ref id="testing">.
@@ -1776,7 +1866,14 @@
que développeur Debian. Si vous utilisez <prgn>scp</prgn> ou
<prgn>rsync</prgn> pour télécharger vos paquets, placez-les dans
&us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans
- &upload-queue;. Attention, il est préférable de transférer le fichier
+ &upload-queue;.
+<p>
+Si vous désirez utiliser la fonctionnalité de délai décrite dans <ref
+id="delayed-incoming">, vous devez effectuer votre envoi vers
+<tt>ftp-master</tt>. Il s'agit de la seule destination d'envoi supportant
+l'incoming différé.
+<p>
+Attention, il est préférable de transférer le fichier
<tt>changes</tt> en dernier. Dans le cas contraire, votre livraison pourrait
être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier
<tt>changes</tt> et constater que les fichiers ne sont pas tous présents. Si
@@ -2017,7 +2114,8 @@
<sect1 id="bug-answering">Répondre à des rapports de bogue
<p>
-Assurez-vous que toutes vos discussions concernant les bogues sont envoyées au
+Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes vos
+ discussions concernant les bogues sont envoyées au
rapporteur du bogue et au bogue lui-même (<email>123@&bugs-host;</email>
par exemple). Si vous rédigez un nouveau courrier et que vous ne vous souvenez
plus de l'adresse du rapporteur de bogue, vous pouvez utiliser l'adresse
@@ -2026,6 +2124,10 @@
dire que vous n'avez pas besoin d'envoyer une copie du courrier à
<email>123@&bugs-host;</email>).
<p>
+Si vous recevez un bogue mentionnant « FTBFS », cela veut dire
+« Fails To Build From Source » (Erreur de construction à partir du
+source). Les porteurs emploient fréquemment cet acronyme.
+<p>
Une fois que vous avez traité un rapport de bogue (i.e. que vous l'avez
corrigé), marquez-le comme <em>done</em> (fermez-le) en envoyant un message
d'explication à <email>123-done@&bugs-host;</email>. Si vous corrigez un
@@ -2198,14 +2300,11 @@
aider les responsables ayant des problèmes de sécurité ou pour les corriger
elle-même, pour envoyer les annonces de sécurité et pour maintenir le site
security.debian.org.
-
- <sect2 id="bug-security-you">Que faire si vous apprenez l'existence d'un
- problème de sécurité ?
<p>
Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
paquet Debian, que vous soyez ou non le responsable, regroupez les
informations pertinentes sur le problème et contactez rapidement l'équipe de
- sécurité à &email-security-team;. Les informations utiles incluent, par
+ sécurité à &email-security-team; dès que possible. Les informations utiles incluent, par
exemple :
<list compact>
@@ -2220,7 +2319,12 @@
</item>
<item>
tout paquet corrigé que vous avez vous-même préparé (envoyez seulement les
- fichiers <file>.diff.gz</file> et <file>.dsc</file>),
+ fichiers <file>.diff.gz</file> et <file>.dsc</file> et lisez d'abord <ref
+ id="bug-security-building">),
+ </item>
+ <item>
+ toute assistance que vous pouvez fournir pour aider les tests (exploits,
+ tests de régression, etc.),
</item>
<item>
toute information nécessaire pour l'annonce de sécurité (voir <ref
@@ -2232,7 +2336,9 @@
<p>
À la différence de la plupart des autres activités au sein de Debian, les
informations sur les problèmes de sécurité doivent parfois être gardées en
- privé pour un certain temps. Cette décision dépend de la nature du problème
+ privé pour un certain temps. Ceci permet les distributeurs de logiciels de
+ coordonner leur dévoilement afin de minimiser l'exposition de leurs
+ utilisateurs. Cette décision dépend de la nature du problème
et de l'existence d'une solution correspondante et également s'il s'agit d'un
fait connu publiquement.
<p>
@@ -2258,13 +2364,12 @@
<list>
<item>
- si le problème est trivial (comme des fichiers temporaires non sécurisés),
- il n'y a pas besoin de garder le secret sur le problème et une correction
- devrait être effectuée et diffusée,
+ si l'exposition de sécurité est mineure, il n'y a parfois pas besoin de
+ garder le secret sur le problème et une correction devrait être effectuée
+ et diffusée,
</item>
<item>
- si le problème est grave (exploitable à distance, possibilité d'accéder
- aux privilèges d'administratation), il est préférable de partager cette
+ si le problème est grave, 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.
@@ -2272,10 +2377,11 @@
</list>
<p>
-Dans tous les cas, si la personne qui indique le problème demande à ne pas
-diffuser l'information, cela devrait être respecté avec l'évidente exception
-d'informer l'équipe de sécurité (assurez-vous d'informer l'équipe de sécurité
-que l'information ne doit pas être révélée).
+Dans tous les cas, si la personne qui indique le problème demande à ce que
+l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception
+d'informer l'équipe de sécurité pour qu'une correction puisse être effectuée
+pour la version stable de Debian. Quand vous envoyez des informations
+confidentielles à l'équipe de sécurité, assurez-vous de bien mentionner ce fait.
<p>Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer
un correctif vers <em>unstable</em> (ou ailleurs) puisque les informations de
@@ -2288,7 +2394,7 @@
<sect2 id="bug-security-advisories">Annonces de sécurité
<p>
Les annonces de sécurité ne sont émises que pour la distribution actuelle
- diffusée <em>stable</em>, pas pour <em>testing</em> ou <em>unstable</em>.
+ diffusée <em>stable</em>, <em>PAS</em> pour <em>testing</em> ou <em>unstable</em>.
Quand elle est diffusée, l'annonce est envoyée à la liste de diffusion
&email-debian-security-announce; et elle est postée sur <url
id="&url-debian-security-advisories;" name="la page de sécurité">. Les
@@ -2305,6 +2411,10 @@
etc.),
</item>
<item>
+ quels privilèges peuvent être gagnés et par qui (si c'est le
+ cas)
+ </item>
+ <item>
comment il peut être exploité,
</item>
<item>
@@ -2314,6 +2424,9 @@
comment le problème a été corrigé,
</item>
</list>
+ Ces informations permettent aux utilisateurs d'estimer la menace pesant
+ sur leurs systèmes.
+
</item>
<item>
les numéros de version des paquets affectés,
@@ -2322,7 +2435,8 @@
les numéros de version des paquets corrigés,
</item>
<item>
- une information sur la façon de récupérer les paquets mis à jour,
+ une information sur la façon de récupérer les paquets mis à jour
+ (habituellement l'archive de sécurité Debian),
</item>
<item>
des références à des annonces amont, des identifiants <url
@@ -2334,7 +2448,7 @@
<sect2 id="bug-security-building">
<heading>Préparer les paquets pour corriger des problèmes de sécurité
<p>
-Une façon d'aider l'équipe de sécurité dans ses travaux est de fournir des
+Une façon d'aider l'équipe de sécurité dans ses travaux est de leur fournir des
paquets corrigés convenables pour une annonce de sécurité pour la version
<em>stable</em> de Debian
<p>
@@ -2357,8 +2471,9 @@
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
modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à
-une nouvelle version amont. Cependant, vous devez toujours coordonner cela avec
-l'équipe de sécurité au préalable.
+une nouvelle version amont. Cependant, ceci n'est fait que dans des situations
+extrêmes et vous devez toujours coordonner cela avec 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 une exploitation du problème existe, essayez-la et
@@ -2386,6 +2501,12 @@
<var>distribution</var>-proposed-updates !
</item>
<item>
+ Fournissez des entrées de changelog descriptives et complètes. D'autres
+ personnes se baseront dessus pour déterminer si un bogue particulier a été
+ corrigé. Quand cela est possible, incluez une référence externe, de
+ préférence, un identifiant CVE, pour qu'elle puisse être recoupée.
+</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 versions
des distributions suivantes. En cas de doute, testez-le avec <tt>dpkg
@@ -2413,7 +2534,7 @@
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
+ Assurez-vous de compiler sur un système
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
@@ -2425,6 +2546,7 @@
<sect2 id="bug-security-upload">Mettre à jour le paquet corrigé
<p>
Vous <em>NE DEVEZ PAS</em> envoyer un paquet dans la file d'attente des envois de sécurité
+(oldstable-security, stable-security, etc.)
sans l'accord préalable de l'équipe de sécurité. Si le paquet ne remplit pas
exactement les exigences de l'équipe, il causera beaucoup de problèmes, ainsi
que des délais dans la gestion de l'envoi indésirable.
@@ -2723,7 +2845,7 @@
charte Debian. Vérifiez que ces cibles sont indépendantes l'une de
l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une de
ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
- d'exécuter <tt>dpkg-buildpackage -b</tt>.
+ d'exécuter <tt>dpkg-buildpackage -B</tt>.
</item>
</enumlist>
@@ -3557,7 +3679,7 @@
lors du lancement de foo avec l'option bar ; envoyez-moi plus
d'informations. »), ni celui de phrases génériques sur la vie, l'univers et
tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé
-la grippe. ») ou celui de demandes d'aide (" La liste des bogues sur
+la grippe. ») ou celui de demandes d'aide (« La liste des bogues sur
ce paquet est énorme, donnez-moi un coup de main. »). Ceci ne sera
généralement pas remarqué par les personnes ciblées, mais peut ennuyer les
personnes qui désirent lire des informations sur les changements réels du
@@ -3724,11 +3846,10 @@
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 -->
+ à l'avenir des installations non interactives.
<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"
+ communes sont référencées dans la page de manuel <manref section="7"
name="debconf-devel">. Vous devriez vraiment lire cette page si vous décidez
d'utiliser debconf.
</sect>
@@ -4200,14 +4321,10 @@
paquet ne soit dans un état acceptable. Être un parrain veut dire être un
mentor.
<p>
-Une fois que le paquet a atteint les standards Debian, construisez le paquet
- avec
-<example>
- dpkg-buildpackage -us -uc
-</example>
- et signez-le avec
+Une fois que le paquet a atteint les standards Debian, construisez et signez le
+paquet avec
<example>
- debsign -m <var>"Nom complet</var> <var>votre-adresse-courrier</var> <var>changes-file</var>
+dpkg-buildpackage -k<var>KEY-ID</var>
</example>
avant de l'envoyer dans le répertoire Incoming.
<p>
Reply to: