Re: Relecture du Manuel de référence du développeur
Comme me l'a fait remarquer Philipe Batailler, il manque quelque chose dans mon
appel à relecture : le fichier à relire...
Et bien le voici. Il ne s'agit pas d'un fichier diff car j'ai éliminé les lignes
remplacées, les corrections dûes aux précédentes relectures et les « -- » remplacés
par des « — ». Il ne reste plus que les paragraphes ajoutés et ceux dont le
texte a été modifiés.
Antoine Hulin
PS : Si vous tenez à relire le diff brut de décoffrage faites le moi savoir.
PS2: À l'un des trois gardiens de l'archive : le manuel de référence est en demande
de relecture. Voici les modification à apporter au fichier doccurrent_status.pl.
Y a-t-il moyen d'indiquer 2 paquets dans le champs translation-package ?
Ce manuel est aussi dans le paquet de l'original (developers-reference).
'developers-reference' => {
'status' => 3,
'since' => '28/05/2001',
'translation_name' => 'Manuel de référence du développeur Debian',
'translation_maintainer'=> ['Antoine Hulin <antoine@origan.fdn.fr>'],
'base_revision' => '',
'translation_package' => 'doc-debian-fr',
'translation_url' => 'http://www.debian.org/doc/manuals/developers-reference/index.fr.html',
'old_translators' => ['Alain Meessen <ameessen@ulb.ac.be>',
'Herve Floch <Herve.Floch@linux.eu.org>',
'Laurent Picouleau <laurent.picouleau@wanadoo.fr>'],
},
--- Ligne 512 ---
<sect id="upstream-coordination">Coordination avec les développeurs
amonts
<p>
Une grosse part de votre travail de responsable Debian sera de rester en
+contact avec les développeurs amonts. Parfois, les utilisateurs établissent
+des rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez
+transmettre ces rapports de bogue aux développeurs amonts pour qu'ils soient
+corrigés dans les prochaines versions. Il n'est pas de votre responsabilité
+de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
+si vous êtes capable de le faire, nous vous encourageons à contribuer au
+développements amonts en proposant un <em>patch</em> qui corrige ce bogue.
+Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
+pour corriger des bogues amonts, il vous faudra alors évaluer ce
+<em>patch</em> puis le transmettre aux développeurs amonts.
+
+<p>
+Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
+paquet conforme à la charte Debian, alors vous devriez proposer un
+<em>patch</em> aux developpeurs amonts pour qu'il soit inclus dans leur
+version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
+mises à jour amonts suivantes. Quels que soient les changements dont vous
+avez besoin, il faut toujours essayer de rester dans la lignée des sources
+amonts.
--- Ligne 1160 ---
<p>
Par contre, utiliser <em>experimental</em> comme plate-forme n'est pas
+toujours la meilleure idée, surtout pour les paquets éphémères.
+Vous ne pouvez pas effacer un paquet qui a été installé dans cet espace
+vous même ; cela doit être fait par l'équipe d'administration de l'archive.
+Une solution consiste à utiliser vos pages web personnelles sur le serveur
+<tt>klecker.debian.org</tt> (c.-à-d. <tt>people.debian.org</tt>).
--- Ligne 1237 ---
<p>
Supposons que personne ne travaille sur le paquet que vous visez, vous devez
alors envoyer un rapport de bogue (voir <ref id="submit-bug">) concernant le
+pseudo-paquet <tt>wnpp</tt>. Ce
courrier devra décrire le paquet que vous projetez de créer, la licence de ce
paquet et l'URL à laquelle le source peut être téléchargé. Cette liste n'est
+pas limitative.
+
+<p>
+Le sujet de votre rapport de bogue devra être <ITP<footnote><em>Intent To
+Package</em> : intention de mise en paquet</footnote> :
+<var>NomDuPaquet</var> — <var> courte description </var>>, en remplaçant
+<var>NomDuPaquet</var> par le nom du paquet. La sévérité du bogue sera
+<em>whishlist</em>. Si vous le jugez nécessaire, envoyez une copie à
+&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
+l'entête du message. N'utilisez pas le champs CC: car de cette manière le
+sujet du message ne contiendrait pas le numéro du bogue.
+
+<p>
+Il faudra aussi ajouter une entrée
<tt>Closes: bug#<var>nnnnn</var></tt> dans le fichier <file>changelog</file>
du nouveau paquet. Cette indication fermera automatiquement le rapport de
bogue à l'installation du nouveau paquet sur les serveurs d'archivage (voir
<ref id="upload-bugfix">).
--- Ligne 1531 ---
<sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
(pandora)
<p>
+Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
+exportations américain ne doivent pas être installés sur <tt>ftp-master</tt>.
+Utilisez <prgn>scp</prgn> ou <prgn>rsync</prgn> pour copier votre paquet sur
+<ftpsite>non-us.debian.org</ftpsite>. Placer les fichiers dans le répertoire
+<tt>&non-us-upload-dir;</tt>. Par défaut, vous pouvez utiliser le même
+<em>login/mot de passe</em> que pour <tt>ftp-master</tt>. Si vous utilisez
+une connexion FTP anonyme pour le téléchargement, placez vous fichiers dans le
+répertoire <ftppath>/pub/UploadQueue/</ftppath>.
--- Ligne 1556 ---
+<p>
+Attention, les personnes résidant aux États-unis et les citoyens américains
+sont soumis à des restrictions sur l'exportation des logiciels de
+cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter
+quelques logiciels de cryptographie soumis à une obligation de déclaration
+auprès du département du commerce américain.
+
+<p>
+La charte Debian n'empêche pas les résidents et citoyens américains de livrer
+des paquets sur <tt>non-US</tt> mais ils devront être vigilants en le faisant.
+Nous recommandons aux responsables concernés de prendre toutes les précautions
+nécessaires, <em>y compris consulter un juriste</em>, pour s'assurer qu'ils
+n'enfreignent pas une loi américaine en livrant un paquet sur <tt>non-US</tt>.
+
+<p>
+Pour les paquets des sections <em>non-US/main</em> et <em>non-US/contrib</em>
+les responsables devraient au moins suivre la <url id="&url-u.s.-export;"
+name="procédure décrite par le gouvernement américain">. Les responsables de
+paquets <em>non-US/non-free</em> devront en plus consulter les <url
+id="&url-notification-of-export;" name="règles de déclaration d'exportation
+pour les logiciels commerciaux">.
+
+<p>
+Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
+juridique. Une fois encore, nous recommandons aux résidents et citoyens
+américains de consulter un juriste avant de livrer un paquet sur
+<tt>non-US</tt>.
--- Ligne 1716 ---
<p>
Dans tous les cas vous recevrez un accusé de réception par courrier
+électronique indiquant que votre paquet a été installé et quels rapports
+de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous
+les rapports de bogues que vous vouliez clore sont bien dans cette liste.
+<p>
+L'accusé de réception indique aussi la section dans laquelle le paquet a
+été installé. S'il ne s'agit pas de votre choix, vous recevrez un second
+courrier qui vous informera de cette différence (voir plus loin).
+
--- Ligne 1740 ---
<p>
Les administrateurs de l'archive indiquent les sections et priorités des paquets
+dans le fichier <em>override</em>. Si ce fichier <em>override</em> et le
+fichier <file>debian/control</file> de votre paquet diffèrent, vous en serez
+informé par courrier électronique quand votre paquet sera installé dans
+l'archive. Vous pourrez corriger votre fichier <em>debian/control</em>
+avant votre prochain téléchargement ou alors vous aurez envie de modifier le
+fichier <em>override</em>.
+
+<p>
+Pour modifier la section dans laquelle un paquet est archivé, vous devez
+d'abord vérifier que fichier <file>debian/control</file> est correct. Ensuite,
+envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo
+paquet <package>ftp.debian.org</package> demandant la modification de la
+section ou de la priorité de votre paquet. Exposez bien les raisons qui vous
+amènent à demander ces changements.
--- Ligne 1805 ---
<p>
Une mise à jour indépendante source est une livraison de paquet faite par
une personne qui n'est pas le responsable officiel de ce paquet avec pour
objectif de corriger un bogue dans le paquet. Une mise à jour indépendante
source implique toujours une modification des sources du paquet, même s'il
ne s'agit que d'un changement dans le fichier <file>debian/changelog</file>.
+Ce changement peut tout aussi bien concerner la partie amont du source que la
+partie spécifique à Debian. Une mise à jour indépendante source peut aussi
+inclure des paquets spécifiques à une architectures, un fichier <em>diff</em>
+modifié ou, plus rarement, des nouveaux sources amonts.
<p>
Une mise à jour indépendante binaire est une recompilation et un archivage
+d'un paquet pour une architecture donnée. Il s'agit souvent du résultat d'un
effort de portage. Une mise à jour indépendante binaire est la livraison d'un
paquet compilé (souvent pour une autre architecture) à condition que cette
compilation n'ait pas nécessité de modifications des sources. Dans de
nombreux cas, les porteurs
sont obligés de modifier les sources pour les rendre compilables sur leur
architecture cible ; il s'agira alors d'une mise à jour indépendante source et
non d'une mise à jour indépendante binaire. Comme vous pouvez le remarquer,
nous ne faisons pas de distinction entre les mises à jour indépendantes
faites par des porteurs et les autres mises à jour indépendantes.
--- Ligne 2138 ---
<p>
Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine
+manière). Merci pour votre indulgence envers des rapport de bogues succints ou
+peu clair ; faites de votre mieux pour éliminer le problème.
<p>
Les problèmes les plus couramment rencontrés par les porteurs sont causés par
des erreurs de mise en paquet dans le paquet source. Voici une
<em>checklist</em> de choses auxquelles vous devez être attentif :
<enumlist>
<item>
+ Vérifiez que les champs <tt>Build-Depends</tt> et
+ <tt>Build-Depends-Indep</tt> du fichier <file>debian/control</file> sont
+ corrects. Le meilleur moyen pour vérifier cela est d'utiliser le
+ paquet <package>debootstrap</package> pour créer un environnement
+ <em>unstable</em> <em>chrooter</em>. Dans cet environnement
+ <em>chrooté</em> il faudra installer le paquet
+ <package>build-essential</package> et tous les paquets mentionnés dans
+ les champs <tt>Build-Depends</tt> et <tt>Build-Depends-Indep</tt>.
+ Ensuite, vous essayerez de fabriquer votre paquet dans cette
+ environnement.
+ <p>
+ Consultez le <url id="&url-debian-policy;" name="Debian Policy
+ Manual"> pour en savoir plus sur les dépendances de fabrication.
--- Ligne 2198 ---
<item>
+ Si possible, ne vous appuyez pas sur une particularité présente dans
+ un compilateur précis ou dans certaines version d'un compilateur. Si
+ vous ne pouvez pas faire autrement, assurez-vous que les dépendances
+ de fabrication reflètent bien cette restriction. Dans ce cas, vous
+ cherchez surement les problèmes car quelques architectures pourraient
+ choisir un compilateur différent.
--- Ligne 2243 ---
+ <sect1 id="recompile-nmu-versioning">
+ <heading>Numéro de version des mises à jour indépendantes
+ binaires</heading>
+<p>
+Parfois il est nécessaire de recompiler des paquets quand d'autres paquets,
+tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez
+changer le numéro de version pour que le système de comparaison des numéros de
+version fonctionne correctement. Ce type de mise à jour reste une mise à jour
+indépendante binaire — il n'est pas nécessaire de reconcidérer le status
+des paquets binaires des autres architectures pour les marquer périmés ou à
+recompiler.
+
+<p>
+Ces recompilations nécessitent des numéros de version « magiques » pour que le
+système de maintenance de l'archive comprennent que, bien qu'il y ait une
+nouvelle version, il n'y a pas eu de modification des sources. Si vous ne
+faites pas cela correctement, les administrateurs de l'archive rejeteront
+votre mise à jour (car il n'y aura pas de code source associé).
+
+<p>
+Cette magie associée à une mise à jour par recompilation est déclenchée en
+utilisant un troisième nombre dans la partie debian du numéro de version. Si,
+par exemple, la dernière version du paquet que vous recompilez était
+« 2.9-3 », votre mise à jour portera le numéro
+« 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
+mise à jour portera le numéro « 3.4-2.1.1 ».
--- Ligne 2487 ---
<sect id="orphaning">Abandonner un paquet
<p>
Si vous ne pouvez plus maintenir un paquet, vous devez en informer les autres
et faire le nécessaire pour qu'il soit marqué <em>abandonné</em>(i.e.
<em>orphaned</em>). Vous devriez aussi remplacer votre nom par <tt>Debian QA
Group &orphan-address;</tt> dans le champ
<tt>maintainer</tt> du paquet et faire un rapport de bogue sur le
pseudo-paquet <tt>wnpp</tt>. Le titre de votre rapport de bogue devra être
« <tt>O<footnote><em>Orphaned</em> : abandonné.</footnote>:
+<var>paquet</var> — <var>courte description</var></tt> » pour indiquer
+que le paquet est orphelin. La sévérité du bogue sera <em>normale</em>.
+Si vous le jugez nécessaire, envoyez une copie à
+&email-debian-devel; en mettant cette adresse dans le champs X-Debbugs-CC: de
+l'entête du message. N'utilisez pas le champs CC: car de cette manière le
+sujet du message ne contiendrait pas le numéro du bogue.
+
+<p>
+Si le paquet est particulièrement important pour la distribution il vous
+faudra faire un rapport de bogue sur le pseudo-paquet <tt>wnpp</tt>, titrer
« <tt>RFA<footnote><em>Request For Adoption</em> : offre
+d'adoption.</footnote>: <var>paquet</var> — <var>courte
description</var></tt> » et lui affecter la sévérité <em>importante</em>.
+Envoyez une copie de votre rapport de bogue à la liste debian-devel comme
+décrit précédemment.
--- Ligne 2719 ---
+ <chapt id="newmaint">
+ <heading>Interaction avec les nouveaux responsables</heading>
+
+<p>
+Ce chapitre décrit les procédures que doivent suivre les responsables
+Debian quand ils ont affaire à un futur responsable Debian.
+
+ <sect>Parrainer un paquet
+<p>
+Parrainer un paquet signifie télécharger un paquet dans l'archive Debian pour
+un responsable qui n'est pas capable de le faire lui même : un futur
+responsable. Parrainer un paquet signifie aussi assumer la résponsabilité de
+ce parrainage.
+
+<p>
+Les nouveaux responsables éprouvent souvent quelques difficultés pour créer
+des paquets Debian — ce qui est bien compréhensible. C'est là que le parrain
+intervient. Il doit verifier que le paquet est suffisamment bon pour intégrer
+la distribution. Notez que si le paquet est nouveau les administrateurs FTP
+devront eux aussi inspecter ce paquet avant de le laisser entrer.
+
+<p>
+Parrainer un paquet en se contentant de recompiler le paquet ou de signer le
+téléchargement <strong>n'est franchement pas recommandé</strong>. Vous devez
+reconstruire le paquet source comme vous le feriez avec vos propres paquets.
+N'oubliez pas qu'il sera possible de voir que vous avez téléchargé un paquet
+même si vous avez laissé le nom du futur responsable dans les fichiers de
+contrôle et changelog.
+
+<p>
+Si vous êtes responsable de candidature<footnote>Application
+manager</footnote> pour un developpeur, vous pouvez aussi être son parrain. De
+cette manière, vous aurez la possibilité de vérifier vous même comment ce
+candidat accomplit la partie `Tâches et compétences'<footnote>`Tasks and
+Skills'</footnote> de sa candidature.
+
+
+
+ <sect>Soutenir un nouveau responsable
+
+<p>
+Consultez la page <url id="&url-newmaint-advocate;" name="Soutenir un futur
+responsable"> sur le site du projet Debian.
+
+
+
+ <sect>Suivre la candidature d'un nouveau responsable
+
+<p>
+Consultez la page <url id="&url-newmaint-amchecklist;" name="Aide mémoire du
+responsable de candidature"> sur le site du projet Debian.
+
+
+
+
+
+
Reply to: