<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
<!-- common, language independent entities -->
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.42 $">
+ <!ENTITY cvs-rev "$Revision: 1.60 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
- <!-- <!ENTITY cvs-en-rev "1.253"> -->
+ <!-- <!ENTITY cvs-en-rev "1.282"> -->
<!-- how to mark a section that needs more work -->
<!ENTITY FIXME "<em>FIXME:</em> ">
<translator>version française par Frédéric Bothamy (traducteur actuel)</translator>
<translator>et Antoine Hulin (ancien traducteur)</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 20050109).</version>
+ <version>Version &version;, &date-fr; (version française 20051114).</version>
<copyright>
- <copyrightsummary>Copyright © 2004 Andreas Barth</copyrightsummary>
+ <copyrightsummary>Copyright © 2004—2005 Andreas Barth</copyrightsummary>
<copyrightsummary>Copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>Copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
<copyrightsummary>Copyright © 1997, 1998 Christian Schwarz.</copyrightsummary>
<url id="&url-gpl" name="la licence publique générale du projet GNU">. Vous
pouvez également l'obtenir en écrivant à la &fsf-addr;.
+<![ %htmltext [
+<p>
+Si vous désirez imprimer cette référence, vous devriez utiliser la <url
+id="developers-reference.pdf" name="version PDF">.
+Cette page est également disponible en <url id="index.en.html" name="anglais">.
+]]>
+
<toc detail="sect1">
<chapt id="scope">Portée de ce document
l'assurance qualité (QA), vous pouvez contacter les responsables qui
travaillent déjà sur ces tâches et proposer des correctifs et des
améliorations.
+
+ <sect id="mentors">Mentors et parrains Debian
+<p>
+La liste de diffusion &email-debian-mentors; a été mise en place pour
+les responsables débutants recherchant de l'aide avec l'empaquetage
+initial et d'autres problèmes de développeur. Chaque nouveau développeur
+est invité à s'abonner à cette liste (voir <ref id="mailing-lists"> pour
+les détails).
+<p>
+Ceux qui préfèrent recevoir une aide plus personnalisée (par exemple, par
+courriels privés) devraient également envoyer des messages à cette liste
+et un développeur expérimenté se proposera de les aider.
+<p>
+De plus, si vous avez des paquets prêts à être inclus dans Debian, mais que
+vous attendez que votre demande pour devenir responsable soit acceptée,
+vous pouvez trouver un parrain pour envoyer vos paquets pour vous. Les
+parrains sont des développeurs Debian officiels qui sont volontaires
+pour critiquer et envoyer vos paquets pour vous.
+<!-- FIXME - out of order
+Those who are seeking a
+sponsor can request one at <url id="&url-sponsors;">.
+-->
+Veuillez lire en premier la FAQ non officielle de debian-mentors à <url
+id="&url-mentors;">.
+<p>
+Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver
+plus d'informations à <ref id="newmaint">.
<sect id="registering">S'enregistrer comme responsable Debian
<p>
<p>
Pour devenir responsable, il faudra montrer que vous pouvez faire du bon travail
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é
+ par le système de suivi des bogues (BTS) et 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
paquets. Si vous pouvez aider d'autres responsables en fournissant des
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è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
- d'identification"> pour en savoir plus sur ces deux options).
-
+ (S'il n'y a pas de responsable près de chez vous, il peut y
+ avoir des moyens alternatifs pour valider votre identité en tant
+ qu'exception absolue étudiée au cas par cas. Veuillez vous
+ reporter à la <url id="&url-newmaint-id;" name="page
+ d'identification"> pour en savoir plus).
<p>
Si vous n'avez pas de clé OpenPGP, créez-la. Tout responsable a besoin d'une clé
OpenPGP pour signer et vérifier les mises à jour de paquets. Vous lirez la
id="&url-rfc2440;" name="RFC 2440">.
<p>
<!-- FIXME: DSS is not exactly equivalent to DSA, is it? -->
-L'algorithme à clé publique recommandé pour les développements Debian est DSA
- (parfois appelé « DSS » ou « DH\ElGamal »). Vous pouvez
- aussi utiliser d'autres types de clés. La longueur de votre clé doit être au
+Vous avez besoin d'une clé de type 4 à utiliser pour le
+ développement Debian. La longueur de votre clé doit être au
minimum de 1024 bits ; il n'y a pas de raison d'utiliser une clé plus
courte et le faire serait beaucoup moins sûr. Votre clé doit être signée avec
votre propre identifiant ; cela évite les falsifications. <prgn>GNU
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 chiffrement. &debian-formal; ne nécessite
- en aucune façon l'utilisation de chiffrement. Si vous vivez dans un pays où
+ l'authentification plutôt que pour le chiffrement. 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>
Vous gagnerez beaucoup de temps si vous êtes bien préparé.
- <sect id="mentors">Mentors et parrains Debian
-<p>
-La liste de diffusion &email-debian-mentors; a été créée pour les responsables
- débutants qui cherchent de l'aide pour leur première création de paquet ainsi
- que pour des problèmes spécifiques aux développeurs. Tout responsable débutant
- est invité à s'y inscrire (voir <ref id="mailing-lists"> pour plus de détails).
-<p>
-Ceux qui préfèrent une aide personnalisée (via une correspondance privée)
- doivent aussi poster dans cette liste, un développeur expérimenté se portera
- volontaire pour les aider.
-<p>
-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 à 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;">. Veuillez tout
- d'abord lire la FAQ non officielle de debian-mentors à <url id="&url-mentors;">.
-<p>
-Si vous désirez être mentor ou parrain, reportez-vous à <ref id="newmaint">.
-
-
<chapt id="developer-duties">Les charges du responsable Debian
<sect id="user-maint">Mise à jour de vos références Debian
pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à
<tt>&keyserver-host;</tt>.
<p>
-Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé, vous
-devez faire signer la nouvelle clé par un autre développeur. Après cela, un
-courriel signé par cet autre développeur listant votre nom de compte, les
-identifiants de clé (« keyids ») de l'ancienne clé et de la nouvelle
-et la raison doivent être envoyés à &email-debian-keyring;. Si l'ancienne clé
-est compromise ou invalide, vous devez également ajouter le certification de
-révocation. S'il n'y pas de vraie raison pour une nouvelle clé, les responsables
-du trousseau de clés ne l'accepteront que si elle est plus sure et connectée à
-l'ancienne clé.
+Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé, vous
+ devez faire signer la nouvelle clé par un autre développeur. Si l'ancienne clé
+ est compromise ou invalide, vous devez également ajouter la certification de
+ révocation. S'il n'y pas de vraie raison pour une nouvelle clé, les responsables
+ du trousseau de clés peuvent rejeter la nouvelle clé. Vous pouvez trouver plus
+ de détails à <url id="http://keyring.debian.org/replacing_keys.html">.
<p>
Les mêmes routines d'extraction de clé décrites dans <ref id="registering"> s'appliquent.
<p>
<qref id="devel-db">base de données Debian LDAP</qref> (l'accès à cette
information est réservé aux développeurs). N'oubliez pas de retirer votre
indicateur « en vacances » lorsque celles-ci sont terminées !
+<p>
+Idéalement, vous devriez vous connecter sur le
+<url id="http://nm.debian.org/gpg.php" name="site de coordination GPG">
+quand vous réservez pour des vacances et vérifier si quelqu'un recherche
+un échange de signatures. Cela est particulièrement important quand des
+personnes vont à des endroits exotiques où nous n'avons pas encore de
+développeurs, mais où il y a des personnes intéressées pour poser leur
+candidature.
<sect id="upstream-coordination">Coordination avec les développeurs amont
<p>
<sect1 id="mailing-lists-new">Demander une nouvelle liste relative au développement
<p>
-Avant de demander un liste de diffusion liée au développement d'un paquet (ou
+Avant de demander une liste de diffusion liée au développement d'un paquet (ou
d'un petit groupe de paquets liés), veuillez considérer si l'utilisation d'un
alias (via un fichier .forward-aliasname sur master.debian.org, ce qui se
traduit en une adresse raisonnablement agréable
<p>
Il existe d'autres canaux dédiés à des sujets spécifiques. <em>#debian-bugs</em>
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'installateur).
-<!-- FIXME: is boot-floppies an anachronism, or still the channel name? -->
-<em>#debian-doc</em> est utilisé
+ <em>#debian-boot</em> est utilisé pour la coordination du travail sur
+ l'installateur Debian. <em>#debian-doc</em> est utilisé
occasionnellement pour travailler sur la documentation comme celle que vous
lisez actuellement. D'autres canaux sont dédiés à une architecture ou un
ensemble de paquets : <em>#debian-bsd</em>, <em>#debian-kde</em>,
Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC,
notamment sur le réseau IRC <url name="Open and free technology community
(OFTC)" id="http://www.oftc.net/">.
+<p>
+Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
+envoyer un courriel signé à Göran Weinholt
+<weinholt@debian.org> dans lequel vous indiquez quel est votre
+pseudonyme (« nick ». Mettez « cloak » quelque part
+dans le sujet. Votre pseudonyme devrait être enregistré :
+<url id="http://freenode.net/faq.shtml#nicksetup" name="Page de
+configuration des pseudonymes">. Le courriel doit être signé par une clé
+du porte-clés Debian. Veuillez consulter la
+<url id="http://freenode.net/faq.shtml#projectcloak" name="documentation
+de Freenode"> pour plus d'informations sur les uniformes.
<sect id="doc-rsrcs">Documentation
<sect1 id="servers-non-us">Le serveur non-US
<p>
+<!--
Le serveur non-US <tt>non-us.debian.org</tt> est le serveur maître de la partie
non-US de l'archive Debian. Si vous avez besoin d'envoyer un paquet dans l'une
des sections non-US, envoyez-le vers ce serveur. Reportez-vous à la section
de vérifier si quelqu'un n'aurait pas déjà rempli un rapport de bogue
concernant le problème sur le <url id="http://&bugs-host;/nonus.debian.org"
name="système de suivi des bogues">.
+-->
+Le serveur non-US <tt>non-us.debian.org</tt> a été interrompu avec la
+ publication de <em>Sarge</em>. Le pseudo-paquet
+ <package>nonus.debian.org</package> existe encore pour le moment.
<sect1 id="servers-www">Le serveur www-master
<p>
Habituellement, la seule raison pour utiliser un serveur différent est que vous
avez besoin de publier des informations soumises aux restrictions d'exportation
américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
- en dehors des États-Unis, comme le serveur mentionné ci-dessus
- <tt>non-us.debian.org</tt>.
+ en dehors des États-Unis.
<p>
Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.
distribué en dehors de Debian, il n'y a qu'un fichier <file>.tar.gz</file> qui
contient les sources du programme. Si un paquet est distribué ailleurs, le
fichier <file>.orig.tar.gz</file> contient ce que l'on appelle <em>code source
- amont</em>, c'est-à-dire, le code source distribué par le <em>mainteneur
+ amont</em>, c'est-à-dire, le code source distribué par le <em>responsable
amont</em> (il s'agit souvent de l'auteur du logiciel). Dans ce cas, le fichier
<file>.diff.gz</file> contient les modifications faites par le responsable
Debian.
à remplir pour qu'un paquet passe d'<em>unstable</em> à <em>testing</em> sont
durcies. Les paquets trop bogués sont supprimés et les seules mises à jours
autorisées concernent les corrections de bogues. Après quelque temps, selon
- l'avancement, la distribution entre dans une phase de « gel complet »
+ l'avancement, la distribution <em>testing</em>
+ <!--
+ entre dans une phase de « gel complet »
où les seules modifications acceptées concernent la procédure d'installation.
Cette phase s'appelle un « cycle de test » et cela peut durer jusqu'à
deux semaines. Il peut y avoir plusieurs cycles de tests avant que le
dernier cycle de test, la distribution <em>frozen</em> devient <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>).
+ -->
+ est gelée encore plus. Les détails de la gestion de la distribution
+ <em>testing</em> sont publiées par l'équipe de publication sur la liste
+ debian-devel-announce. Après la résolution des problèmes restants à la
+ satisfaction de l'équipe de publication, la distribution est publiée.
+ La publication veut dire que <em>testing</em> est renommée en
+ <em>stable</em>, une nouvelle copie est créée pour la nouvelle
+ <em>testing</em> et l'ancienne <em>stable</em> est renommée en
+ <em>oldstable</em> et y reste jusqu'à ce qu'elle soit finalement
+ archivée. Lors de l'archivage, son contenu est déplacé sur
+ <tt>&archive-host;</tt>.
<p>
Ce cycle de développement est basé sur l'idée que la distribution
<em>unstable</em> devient <em>stable</em> après une période de test
<file>proposed-updates</file>. De temps en temps, les paquets de ce répertoire
qui ne présentent pas de problème sont installés dans la distribution
<em>stable</em> et le numéro de révision de cette distribution est incrémenté
- (« 3.0 » devient « 3.0r1 », « 2.0r4 » devient
- « 2.0r5 » et ainsi de suite).
+ (« 3.0 » devient « 3.0r1 », « 2.2r4 » devient
+ « 2.2r5 » et ainsi de suite). Veuillez vous référer aux
+ <qref id="upload-stable">envois dans la distribution <em>stable</em></qref>
+ pour plus de détails.
<p>
Notez que, pendant la période de gel, les développements continuent sur la
distribution <em>unstable</em> car cette distribution reste en place.
<p>
Le système Incoming est responsable de la collecte des paquets mis à jour et 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>.
+ répertoires et de scripts qui sont installés sur <tt>&ftp-master-host;</tt>.
<p>
Les paquets sont envoyés par tous les responsables Debian dans un répertoire
- nommé <file>unchecked</file>. Ce répertoire est parcouru toutes les 15 minutes
+ nommé <file>UploadQueue</file>. Ce répertoire est parcouru toutes les
+ quelques minutes par un démon appelé <prgn>queued</prgn>, les fichiers
+ <file>*.command</file> sont exécutés et les fichiers
+ <file>*.changes</file> restants et correctement signés sont déplacés
+ avec leurs fichiers correspondants dans le répertoire
+ <file>unchecked</file>. Ce répertoire n'est pas visible de la plupart
+ des développeurs car ftp-master est à accès restreint ;
+ il est parcouru toutes les 15 minutes
par le script <prgn>katie</prgn> qui vérifie l'intégrité des paquets envoyés et
leurs signatures de chiffrage. Si le paquet est considéré comme prêt à être
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>
+ du premier envoi du paquet (ou s'il a de nouveaux paquets binaire), 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 <em>à la main</em>, il est déplacé dans le répertoire
<file>byhand</file> où il attend une installation manuelle par les ftpmasters.
Une fois que le paquet est accepté, le système envoie une confirmation par
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
+ maintenant accessible publiquement à <url id="&url-incoming;"> jusqu'à
+ ce qu'il soit vraiment installé dans l'archive Debian. Cela se produit
+ seulement une fois par jour (et c'est également appelé une
+ « exécution dinstall » pour des raisons historiques) ;
+ 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 (fabrication des nouveaux fichiers d'index <file>Packages</file> et
<file>Sources</file> par exemple) ont été effectuées, un script spécial est
« experimental », l'annonce sera à la place envoyée à
&email-debian-devel-changes;.
<p>
+Bien que ftp-master soit à accès restreint, une copie de l'installation
+ est disponible à tous les développeurs sur <tt>&ftp-master-mirror;</tt>.
+ <!-- FIXME: delete it or keep it for historical purposes?
+<p>
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
};</example>
Une fois que vous avez fait ce changement, <prgn>dupload</prgn> peut être
utilisé pour envoyer facilement dans l'un des répertoires de délai ainsi :
-<example>DELAY=5 dupload --to delayed <changes-file></example>
-
+<example>DELAY=5 dupload -X-to delayed <changes-file></example>
+-->
<sect id="pkg-info">Informations sur un paquet
<p>
<sect1 id="madison">L'outil <prgn>madison</prgn>
<p>
<prgn>madison</prgn> est un outil en ligne de commande qui est disponible sur
- <tt>&ftp-master-host;</tt>, sur <tt>&non-us-host;</tt> et sur le miroir
+ <tt>&ftp-master-host;</tt> et sur le miroir
<tt>&ftp-master-mirror;</tt>. Il utilise un seul
argument qui correspond au nom du paquet. Il affiche comme résultat quelle
version du paquet est disponible pour chaque combinaison d'architecture et de
<item>Tout courrier non automatique envoyé au PTS par les personnes qui
veulent contacter les inscrits au paquet. Ceci peut être fait en
envoyant un courrier à <tt><var>paquet-source</var>@&pts-host;</tt>. Pour
- prévenir l'envoi de spam, tous les courriers envoyés à ces adresses doivent
+ prévenir l'envoi de pourriels, tous les courriers envoyés à ces adresses doivent
contenir l'en-tête <tt>X-PTS-Approved</tt> avec une valeur non vide.
<tag><tt>summary</tt>
externes aux projets initiés par Debian et à aider des projets dont les buts
sont de promouvoir Debian ou ses dérivés.
<p>
+Tous les développeurs Debian ont automatiquement un compte sur Alioth. Ils
+peuvent l'activer en utilisant la fonctionnalité de récupération des mots de
+passe. Les développeurs externes peuvent demander un compte invité sur Alioth.
+<p>
Pour plus d'informations, veuillez visiter <url id="&url-alioth;">.
+ <sect id="developer-misc">« Goodies » pour les développeurs
+ <p>
+ <sect1 id="lwn">Abonnements LWN
+ <p>
+Depuis octobre 2002, HP parraine l'abonnement à LWN pour tous les
+développeurs Debian intéressés.
+
+Les détails sur les moyens d'accéder à cet avantage sont expliqués dans <url
+id="http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html">.
+
+
<chapt id="pkgs">Gestion des paquets
<p>
Ce chapitre contient des informations relatives à la création, l'envoi, la
que dans les cas suivants :
<list>
<item>un problème fonctionnel vraiment critique,
-<item>un paquet devenu ininstallable,
+<item>un paquet devenu non installable,
<item>un paquet indisponible pour une architecture.
</list>
<p>
bibliothèque qui n'est disponible que dans <em>unstable</em> sera rejeté.
Modifier les dépendances d'autres paquets (en manipulant le champ
<tt>Provides</tt> ou les fichiers shlibs) et, peut-être, rendre ces paquets
- ininstallables, est fortement déconseillé.
+ non installables, est fortement déconseillé.
<p>
L'équipe responsable de la distribution<footnote><em>the Release
team</em></footnote> (joignable à l'adresse &email-debian-release;)
<tt>changes</tt> et constater que les fichiers ne sont pas tous présents.
<p>
<!-- FIXME: is this still topical? Explain the rationale? -->
+<!--
<em>Note :</em> ne téléchargez pas sur <tt>ftp-master</tt> de paquets
concernant la cryptographie qui appartiendraient à <em>contrib</em> ou <em>non-free</em>.
Ces logiciels doivent aller sur <tt>non-us</tt> (voir <ref
exportations américaines, posez la question sur la liste
&email-debian-devel;.
<p>
+-->
Les paquets <ref id="dupload"> ou <ref id="dput"> pourront vous faciliter le
travail lors du téléchargement. Ces programmes, bien pratiques, aident à
automatiser le processus d'envoi de paquets vers Debian
<sect1 id="upload-non-us">Installer un paquet sur <tt>non-US</tt>
<p>
+<!--
<em>Note :</em> non-us n'est plus traité actuellement.
<p>
Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
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>.
+-->
+<em>Note :</em> non-us a été interrompu avec la publication de
+ <em>Sarge</em>.
<sect1 id="delayed-incoming">Envois différés
<p>
<sect1>Les autres files d'envoi
<p>
-Les files scp sur ftp-master, non-us et security sont pratiquement inutilisables
+Les files scp sur ftp-master et security sont pratiquement inutilisables
à cause des restrictions de connexion sur ces hôtes.
<p>
Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
vous amènent à demander ces changements.
<p>
Pour en savoir plus sur les <em>fichiers override</em>, reportez-vous à <manref
-name="dpkg-scanpackages" section="8"> et <url
+name="dpkg-scanpackages" section="1"> et <url
id="&url-bts-devel;#maintincorrect">.
<p>
Notez que le champ <tt>Section</tt> décrit à la fois la section et la
Si le bogue est réel, mais est causé par un autre paquet,
réattribuez simplement le bogue à l'autre paquet. Si vous ne savez pas à
quel paquet il doit être réattribué, vous pouvez demander de l'aide sur
- <qref id="irc-channels">IRC"</qref> ou sur &email-debian-devel;.
+ <qref id="irc-channels">IRC</qref> ou sur &email-debian-devel;.
+ Veuillez vous assurer que le (ou les) responsable(s) du paquet
+ sur lequel est réattribué le paquet sait pourquoi vous l'avez
+ ainsi réattribué.
<p>
Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
corresponde à notre définition de gravité des bogues. C'est dû au
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>
+ Si le bogue est réel, mais que le problème a déjà été rapporté
+ par quelqu'un d'autre, les deux rapports de bogues pertinents
+ devraient être fusionnés en un seul en utilisant la commande
+ <tt>merge</tt> (fusion) du BTS. Ainsi, quand le bogue sera
+ corrigé, tous les créateurs de rapport de bogue en seront
+ informés (notez, cependant, que les courriels envoyés à l'un des
+ créateurs de rapport de bogue ne seront pas automatiquement envoyés
+ aux autres créateurs de rapport de bogue). Pour plus de
+ détails sur les technicités de la commande de fusion et sa
+ voisine, la commande <tt>unmerge</tt> (séparation), veuillez
+ consulter la documentation du serveur de contrôle du BTS.
+ </item>
<item>
Le rapporteur de bogue peut avoir oublié de fournir certaines
informations. Dans ce cas, vous devez lui demander les informations
identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera
un pour qu'il puisse être inclus dans le paquet et dans le changelog.
</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
s'ils n'ont pas un numéro de version supérieur à celui actuellement
disponible).
<p>
-Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
+Vous devez vous assurer que votre mise à jour indépendante binaire ne rend pas
le paquet non installable. Cela peut arriver si un paquet source génère des
paquets dépendants et indépendants de l'architecture qui dépendent
les uns des autres <em>via</em> $(Source-Version).
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
+ pour que le système de maintenance de l'archive comprenne que, bien qu'il y
ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous
ne faites pas cela correctement, les administrateurs de l'archive rejetteront
votre mise à jour (car il n'y aura pas de code source associé).
intéressantes pour tous (par exemple, une version de Debian compilée avec des
vérifications relatives à <prgn>gcc</prgn>). Ce système nous permettra aussi
de recompiler rapidement toute une distribution.
-</sect2>
+<p>
+Les administrateurs des buildds pour chaque architecture peuvent être
+ contactés à l'adresse électronique $arch@buildd.debian.org.
+
+ <sect1 id="packages-arch-specific">Quand votre paquet <em>n'est pas</em>
+ portable
+ <p>
+Certains paquets ont encore des problèmes pour être construits et/ou pour
+fonctionner sur certaines des architectures prises en charge par Debian et ne
+peuvent pas du tout être portés, ou pas dans un laps de temps raisonnable. Un
+exemple est un paquet qui est spécifique SGVA (i386 seulement) ou qui utilise
+des fonctionnalités spécifiques au matériel qui ne sont pas gérées sur toutes
+les architectures.
+ <p>
+Pour éviter que des paquets cassés soient envoyés dans l'archive et qu'ils fassent
+perdre du temps des buildd, vous devez faire plusieurs choses :
+ <p>
+ <list>
+ <item>
+ <p>
+Tout d'abord, assurez-vous que votre paquet <em>échoue</em> à la compilation
+sur les architectures qu'il ne gère pas. Il y a plusieurs moyens de faire
+cela. Le moyen préféré est d'avoir une petite suite de tests pendant la
+construction qui testera la fonctionnalité et qui échouera si cela ne
+fonctionne pas. C'est de toute façon une bonne idée et empêchera des
+(certains) envois cassés pour toutes les architectures, et cela permettra
+également au paquet d'être construit dès que la fonctionnalité nécessaire est
+disponible.
+ <p>
+De plus, si vous croyez que la liste des architectures gérées est plutôt
+constante, vous devriez changer « any » en une liste des
+architectures gérées dans le fichier <file>debian/control</file>. Ainsi, la
+construction échouera également et l'indiquera à un lecture humain sans
+vraiment essayer.
+ <item>
+ <p>
+Pour empêcher les compilateurs automatiques de tenter sans raison de
+construire votre paquet, il peut être inclus dans
+<file>packages-arch-specific</file>, une liste utilisée par le script
+<prgn>wanna-build</prgn>. La version actuelle est disponible à
+<url
+id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup"> ;
+veuillez consulter le début du fichier pour savoir qui contacter pour le
+modifier.
+ </list>
+ <p>
+Veuillez noter qu'il est insuffisant de simplement ajouter votre paquet à
+Packages-arch-specific sans le faire également échouer lors de compilation sur
+les architectures non gérées : un porteur ou toute autre personne
+essayant de construire votre paquet peut accidentellement l'envoyer sans
+remarquer qu'il ne fonctionne pas. Si dans le passé certains paquets binaires
+ont été envoyés pour des architectures non gérées, demandez leur suppression
+en remplissant un bogue sur <package>ftp.debian.org</package>.
<sect id="nmu">Mise à jour indépendante
<p>
paquet, il faut en créer une en démarrant à « 0.1 ». S'il est
absolument nécessaire qu'une personne qui n'est pas responsable d'un paquet
fasse une livraison basée sur une nouvelle version amont, cette personne doit
- choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
+ choisir « 0.1 » comme numéro de révision Debian. Le responsable du
paquet doit, lui, démarrer sa numérotation à « 1 ».
<p>
Si vous envoyez un paquet vers <em>testing</em> ou <em>stable</em>, vous devrez
de suivi des bogues. Les responsables apprécient presque toujours les
correctifs et les rapports de bogue soignés.
+ <sect1 id="nmu-katie">Comment dak détecte les mises à jour indépendantes
+<p>
+Le fait qu'un envoi soit traité par les scripts d'archive et par le
+système de suivi des bogues (voir <ref id="nmu-patch">) comme une mise
+à jour indépendante ou comme un envoi par le responsable <em>n'est
+pas</em> décidé en regardant le numéro de version (voir <ref
+id="nmu-version">). Au lieu de cela, un envoi est géré comme une mise à
+jour indépendante si l'adresse du responsable dans le fichier
+<tt>.changes</tt> n'est pas la même binairement que l'adresse du champ
+<tt>Maintainer</tt> ou que l'une des adresses du champ <tt>Uploaders</tt>
+du fichier <tt>dsc</tt> et également si l'adresse du responsable n'est
+pas spéciale (c.-à-d. elle n'est pas positionnée à l'adresse du groupe
+d'Assurance Qualité).
+
<sect1 id="nmu-terms">Terminologie
<p>
Deux nouvelles expressions sont introduites dans cette section :
inclure des paquets spécifiques à une architecture tout comme un fichier
<em>diff</em> modifié.
<p>
-Une mise à jour indépendante binaire est constitué par la recompilation et
+Une mise à jour indépendante binaire est constituée par la recompilation et
l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
résultat d'un effort de portage. Une mise à jour indépendante binaire est la
livraison d'un paquet compilé (souvent pour une autre architecture) à condition
après avoir atteint un certain degré de test dans <em>unstable</em>.
<p>
Ils doivent être en synchronisation pour toutes les architectures et ne doivent
-pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
+pas avoir de dépendances qui les rendraient non installables ; ils doivent
également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
stable (« release-critical ») au moment où ils sont installés dans
<em>testing</em>. Ainsi, <em>testing</em> devrait toujours être prête pour être
<heading>Mises à jour depuis <em>unstable</em></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 fabriquent les
+ chaque jour après l'installation des paquets mis à jour ; ces
+ scripts sont appelés <em>britney</em>. Ils fabriquent 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.
<item>
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 remplire tous les critères nécessaires).
+même moment (et ils doivent remplir tous les critères nécessaires).
</list>
<p>
Pour savoir si un paquet a progressé ou non dans <em>testing</em>, veuillez voir la
à jour <em>testing</em> avec des candidats valides ; en premier, chaque
paquet individuellement, puis des groupes de plus en plus larges de paquets
ensemble. Chaque tentative est acceptée si <em>unstable</em> n'est pas moins
-ininstallable après la mise à jour qu'avant celle-ci. (Avant et après cette
+non installable après la mise à jour qu'avant celle-ci. (Avant et après cette
partie, certains coups de pouce sont traités ; mais, comme seuls les
responsables de version peuvent positionner des coups de pouce, cela n'est
probablement pas très important pour vous.)
bloquants sans étiquette de version (comme <em>potato</em>, <em>woody</em>) ou
avec une étiquette <em>sid</em> et également s'ils ne sont ni corrigés ou
marqués avec <em>sarge-ignore</em>.
-Le compte des bogues de <em>testing</em> pour un paquet est condiséré comme à
+Le compte des bogues de <em>testing</em> pour un paquet est considéré comme à
peu près le nombre de bogues d'<em>unstable</em> lors du dernier pointage quand
la version <em>testing</em> a été égale à la version <em>unstable</em>.
<p>
supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
<p>
Évidemment, cela touche principalement des paquets qui fournissent des jeux
-changeants de paquets binaires dans différentes version (par suite,
+changeant de paquets binaires dans différentes versions (par suite,
principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
<p>
binaires différents, que ce soit pour fournir plusieurs saveurs du même
paquet (par exemple, le paquet source <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 n'installer que la partie nécessaire et ainsi
économiser de l'espace disque).
<p>
Le second cas peut facilement être géré dans le fichier
une meilleure implémentation ? A-t-il plus de fonctionnalités, des
fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet ?
<!-- FIXME: what's this?
-+(the second questions is about the class of packages, and
+(the second questions is about the class of packages, and
this about this particular package, if you have information related to both).
-+-->
+-->
</list>
</sect1>
problème.
</sect>
+<!-- Les 2 prochaines sections sont provisoirement commentées tant que
+ le bogue 337086 n'est pas clos -->
+<!--
+ <sect id="bpp-debian-security-audit">
+ <heading>Les meilleures pratiques en matière de sécurité</heading>
+
+<p>Si vous empaquetez un logiciel pour d'autres utilisateurs, vous devez
+vous efforcer de garantir que l'installation du logiciel et son
+utilisation n'introduisent pas de risques pour la sécurité du
+système sur lequel il est installé ou de ses utilisateurs.</p>
+
+<p>Vous devez vous efforcer d'examiner le code source du paquet
+et détecter les problèmes qui pourraient amener des bogues concernant la
+sécurité. Les erreurs de programmation qui entraînent des bogues concernant la sécurité
+sont généralement du type : <url
+id="http://en.wikipedia.org/wiki/Buffer_overflow" name="dépassement de
+tampon">, <url
+id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="dépassement
+de chaînes de formatage">, <url
+id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="dépassement
+de tas"> et <url
+id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="dépassement
+d'entier"> (dans les programmes C/C++), <url
+id="http://en.wikipedia.org/wiki/Symlink_race" name="situation de
+concurrence entre liens symboliques"> temporaire (dans les scripts), <url
+id="http://en.wikipedia.org/wiki/Directory_traversal" name="traversée de
+répertoire"> et injection de commandes (dans les serveurs) et <url
+id="http://en.wikipedia.org/wiki/Cross_site_scripting"
+name="scripts intersites">, et <url
+id="http://en.wikipedia.org/wiki/Cross_site_scripting" name="bogues
+d'injection SQL"> (dans le cas d'applications orientées web).</p>
+
+<p>Certains de ces problèmes peuvent ne pas être évidents à détecter à
+moins d'être un expert dans le langage de programmation utilisé par le
+programme, mais d'autres sont faciles à détecter et
+à corriger. Par exemple, il est facile de trouver des situations de concurrence
+temporaires dans un code source : on peut exécuter
+<tt>grep -r "/tmp/" .</tt> dans le code source et remplacer les noms
+de fichier codés en dur utilisant des répertoires temporaires par des
+appels soit à <prgn>mktemp</prgn> ou à <prgn>tempfile</prgn> dans les
+scripts shell, à <manref name="File::Temp" section="3perl"> dans les
+scripts Perl, et à <manref name="tmpfile" section="3"> pour du C/C++.
+Vous pouvez également utiliser des <url
+id="http://www.debian.org/security/audit/tools" name="outils
+spécifiques"> qui facilitent la phase d'étude du code du point de vue de la sécurité.</p>
+
+<p>Quand vous empaquetez un logiciel, assurez-vous que :
+
+<list>
+
+<item>le logiciel fonctionne avec le minimum de privilèges :
+
+<list>
+<item>le paquet installe des binaires setuid ou setgid.
+<prgn>Lintian</prgn> émettra un avertissement pour les binaires <url
+id="http://lintian.debian.org/reports/Tsetuid-binary.html"
+name="setuid">, <url id="http://lintian.debian.org/reports/Tsetgid-binary.html"
+name="setgid"> et <url
+id="http://lintian.debian.org/reports/Tsetuid-gid-binary.html"
+name="setuid et setgid">.
+
+<item>les démons fournis par le paquet s'exécutent avec un utilisateur à
+privilège réduit (voir <ref id="bpp-lower-privs">).
+
+</list>
+
+<item>les tâches programmées (par exemple, <prgn>cron</prgn>)
+ne s'exécutent PAS en tant que root ou si
+elles le font, elles n'implémentent pas de tâches complexes.
+
+</list>
+
+<p>Si votre paquet se trouve dans l'un des cas ci-dessus, assurez-vous que les programmes
+qui s'exécutent avec des privilèges plus élevés ont été audités pour les
+bogues de sécurité. Si vous n'en êtes pas certain ou si vous avez besoin
+d'aide, contactez l'<url
+id="http://www.debian.org/security/audit/" name="équipe d'audit de
+sécurité Debian">. Dans le cas de binaires setuid/setgid, suivez la
+charte Debian en ce qui concerne les
+<url id="http://www.debian.org/doc/debian-policy/ch-files.html#s10.9"
+name="permissions et propriétaires">.
+</p>
+
+<p>Pour d'autres informations spécifiques à la programmation sécurisée,
+lisez (ou signalez au développeur amont) <url
+id="http://www.dwheeler.com/secure-programs/" name="Secure Programming
+for Linux and Unix HOWTO"> et le portail <url
+id="https://buildsecurityin.us-cert.gov/portal/" name="Build Security
+In">. Pour des informations spécifiques à la sécurité dans la distribution Debian, vous
+pouvez lire le <url
+id="http://www.debian.org/doc/manuals/securing-debian-howto/"
+name="guide de sécurisation de Debian">.
+</p>
+ -->
+
+<!-- This should be explained here until #291177 gets fixed and this is
+ added to poliy -->
+
+<!--
+ <sect1 id="bpp-lower-privs">
+ <heading>Créer des groupes et des utilisateurs pour des démons
+ logiciels
+
+<p>Si votre logiciel exécute un démon qui n'a pas besoin des privilèges
+du superadministrateur, vous devez lui créer un utilisateur. Il existe
+deux types d'utilisateurs Debian pouvant être utilisés par des
+paquets : les identifiants statiques (assignés par
+<package>base-passwd</package>) et les identifiants dynamiques dans
+l'intervalle assigné aux utilisateurs système.
+
+<p>Dans le premier cas, vous devez demander un identifiant d'utilisateur
+ou de groupe à <package>base-passwd</package> et ajouter une dépendance
+versionnée correctement sur le paquet <package>base-passwd</package>
+fournissant cet utilisateur.
+
+<p>Dans le second cas, vous devez créer l'utilisateur système dans
+le script <em>preinst</em> ou <em>postinst</em> et rendre le paquet
+dépendant de <tt>adduser (>= 3.11)</tt>.
+
+<p>Le code exemple suivant crée l'utilisateur et le groupe du démon avec
+lequel le démon fonctionnera au moment de l'installation ou de la mise à
+jour du paquet :
+
+<example>
+[...]
+case "$1" in
+ install|upgrade)
+
+ # Si le paquet a un fichier par défaut, il peut être sourcé afin
+ # que l'administrateur local puisse écraser les valeurs par défaut
+
+ [ -f "/etc/default/<var>packagename</var>" ] && .
+ /etc/default/<var>packagename</var>
+
+
+ # Valeurs par défaut saines :
+
+ [ -z "$SERVER_HOME" ] && SERVER_HOME=<var>server_dir</var>
+ [ -z "$SERVER_USER" ] && SERVER_USER=<var>server_user</var>
+ [ -z "$SERVER_NAME" ] && SERVER_NAME="<var>Server description</var>"
+ [ -z "$SERVER_GROUP" ] && SERVER_GROUP=<var>server_group</var>
+
+ # Groupes auxquels l'utilisateur sera ajouté, si non défini, alors rien.
+ ADDGROUP=""
+
+
+ # Crée l'utilisateur pour éviter d'exécuter le serveur en tant que root
+ # 1. Création du groupe s'il n'existe pas
+ if ! getent group | grep -q "^$SERVER_GROUP:" ; then
+ echo -n "Adding group $SERVER_GROUP.."
+ addgroup - -quiet - -system $SERVER_GROUP 2>/dev/null ||true
+ echo "..done"
+ fi
+ # 2. Création du répertoire personnel s'il n'existe pas
+ test -d $SERVER_HOME || mkdir $SERVER_HOME
+ # 3. Création de l'utilisateur s'il n'existe pas
+ if ! getent passwd | grep -q "^$SERVER_USER:"; then
+ echo -n "Adding system user $SERVER_USER.."
+ adduser - -quiet \
+ - -system \
+ - -ingroup $SERVER_GROUP \
+ - -no-create-home \
+ - -disabled-password \
+ $SERVER_USER 2>/dev/null || true
+ echo "..done"
+ fi
+ # 4. Ajuste l'entrée du mot de passe
+ usermod -c "$SERVER_NAME" \
+ -d $SERVER_HOME \
+ -g $SERVER_GROUP \
+ $SERVER_USER
+ # 5. Ajuste les permissions de fichiers et répertoires
+ if ! dpkg-statoverride - -list $SERVER_HOME >/dev/null
+ then
+ chown -R $SERVER_USER:adm $SERVER_HOME
+ chmod u=rwx,g=rxs,o= $SERVER_HOME
+ fi
+ # 6. Ajoute l'utilisateurs au groupe ADDGROUP
+ if test -n $ADDGROUP
+ then
+ if ! groups $SERVER_USER | grep -q $ADDGROUP; then
+ adduser $SERVER_USER $ADDGROUP
+ fi
+ fi
+ ;;
+ configure)
+
+[...]
+</example>
+
+<p>Vous devez vous assurer que le fichier script d'init.d :
+
+<list>
+<item>lance le démon en abandonnant les privilèges, si le logiciel ne
+fait pas les appels <manref name="setuid" section="2"> ou <manref
+name="seteuid" section="2"> lui-même, vous pouvez utiliser l'option
+<tt>- -chuid</tt> de <prgn>start-stop-daemon</prgn>.
+
+<item>arrête le démon seulement si l'identifiant utilisateur correspond,
+vous pouvez utiliser l'option <tt>- -user</tt> de
+<prgn>start-stop-daemon</prgn> pour cela.
+
+<item>ne s'exécute pas si l'utilisateur ou le groupe n'existe pas :
+<example>
+ if getent passwd | grep -q "^<var>server_user</var>:"; then
+ echo "Server user does not exist. Aborting" >&2
+ exit 1
+ fi
+ if getent group | grep -q "^<var>server_group</var>:" ; then
+ echo "Server group does not exist. Aborting" >&2
+ exit 1
+ fi
+</example>
+
+</list>
+
+<p>Si le paquet crée l'utilisateur système, il peut l'enlever quand il
+est purgé dans son script <em>postrm</em>, cela a certains inconvénients
+<footnote>Par exemple, les fichiers créés par celui-ci seront sans
+propriétaire et peuvent être récupérés par un nouvel utilisateur système
+dans le futur si celui-ci reçoit le même identifiant utilisateur.
+Voir les fils de discussion suivants qui traitant de ces
+inconvénients : <url
+id="http://lists.debian.org/debian-mentors/2004/10/msg00338.html">
+et
+<url id="http://lists.debian.org/debian-devel/2004/05/msg01156.html">
+</footnote>,
+ce n'est donc pas obligatoire et cela dépend des besoins du paquet. En
+cas de doute, cela peut être géré en demandant à l'administrateur son
+choix lors de l'installation du paquet (voir <ref
+id="debconf">). Le code exemple suivant supprime l'utilisateur et le
+groupe créés auparavant si et seulement si l'identifiant utilisateur est
+dans l'intervalle des identifiants d'utilisateur système assignés
+dynamiquement et si l'identifiant de groupe appartient à un groupe
+système :
+
+<example>
+case "$1" in
+ purge)
+[...]
+ # Trouve les premier et dernier numéros SYSTEM_UID
+ for LINE in `grep SYSTEM_UID /etc/adduser.conf | grep -v "^#"`; do
+ case $LINE in
+ FIRST_SYSTEM_UID*)
+ FIST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
+ ;;
+ LAST_SYSTEM_UID*)
+ LAST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
+ ;;
+ *)
+ ;;
+ esac
+ done
+ # Supprime le compte système si nécessaire
+ CREATEDUSER="<var>server_user</var>"
+ if [ -n "$FIST_SYSTEM_UID" ] && [ -n "$LAST_SYSTEM_UID" ]; then
+ if USERID=`getent passwd $CREATEDUSER | cut -f 3 -d ':'`; then
+ if [ -n "$USERID" ]; then
+ if [ "$FIST_SYSTEM_UID" -le "$USERID" ] && \
+ [ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
+ echo -n "Removing $CREATEDUSER system user.."
+ deluser - -quiet $CREATEDUSER || true
+ echo "..done"
+ fi
+ fi
+ fi
+ fi
+ # Supprime le groupe système si nécessaire
+ CREATEDGROUP=<var>server_group</var>
+ FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
+ if [ -n "$FIST_USER_GID" ] then
+ if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
+ if [ -n "$GROUPGID" ]; then
+ if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
+ echo -n "Removing $CREATEDGROUP group.."
+ delgroup - -only-if-empty $CREATEDGROUP || true
+ echo "..done"
+ fi
+ fi
+ fi
+ fi
+[...]
+</example>
+
+<p>Exécuter des programmes avec un utilisateur ayant des privilèges
+limités garantit que tout problème de sécurité du programme n'entraînera
+que des dommages limités au système et cela suit le principe du <em>moindre
+privilège</em>, vous pouvez limiter les privilèges dans les programmes
+par d'autres mécanismes en plus de le faire s'exécuter en tant que
+non-superutilisateur. Pour plus d'informations, lisez le chapitre <url
+id="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html"
+name="Minimize Privileges"> du livre <em>Secure Programming for Linux
+and Unix HOWTO</em>.
+
+</sect1>
+
+</sect>
+ -->
+
<sect id="bpp-config-mgmt">
<heading>Gestion de la configuration avec <package>debconf</package></heading>
pour eux.
<p>
Veuillez utiliser (et abuser de) la liste de discussions
-debian-l10n-english@lists.debian.org. Faites relire vos questionnaires.
+&email-debian-l10n-english;. Faites relire vos questionnaires.
<p>
-Des questionnaires écrits incorrectement donne une pauvre image de votre paquet,
+Des questionnaires écrits incorrectement donnent une pauvre image de votre paquet,
de votre travail... ou même de Debian elle-même.
<p>
-Évitez le jargon technique autant que possible. Si certains termes vous semble
+Évitez le jargon technique autant que possible. Si certains termes vous semblent
courants, ils peuvent être impossibles à expliquer à d'autres personnes. Si vous
ne pouvez pas les éviter, essayez de les expliquer (en utilisant la description
étendue). Quand vous faites cela, essayez d'équilibrer la verbosité et la
<sect2>Être courtois avec les traducteurs
<p>
Les questionnaires debconf peuvent être traduits. Debconf, avec son paquet-frêre
-po-debconf, offre un cadre de travail simple pour obtenir des questionnaires
+<package>po-debconf</package>, offre un cadre de travail simple pour obtenir des questionnaires
traduits par les équipes de traduction ou même par des individus isolés.
<p>
-Veuillez utiliser les questionnaires basés sur gettext. Installez po-debconf sur
+Veuillez utiliser les questionnaires basés sur gettext. Installez <package>po-debconf</package> sur
votre système de développement et lisez sa documentation (« man
po-debconf » est un bon début).
<p>
l'adresse électronique du traducteur sont mentionnés dans les en-têtes des
fichiers PO.
<p>
+L'utilisation de <prgn>podebconf-report-po</prgn> du paquet
+<package>po-debconf</package> est hautement recommandée pour avertir les
+traducteurs qui ont des traductions incomplètes et pour leur demander
+des mises à jour.
+ <p>
En cas de doutes, vous pouvez également contacter l'équipe de traduction pour
une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions
-debian-i18n@lists.debian.org.
+&email-debian-i18n;.
+ <p>
+Les appels à traductions postés sur &email-debian-i18n; avec le fichier
+<file>debian/po/templates.pot</file> attaché ou référencé dans une URL
+sont encouragés. Assurez-vous de mentionner dans ces appels pour de
+nouvelles traductions quelles sont les langues pour lesquelles vous avez
+déjà des traductions existantes, pour éviter toute duplication de
+travail.
+
+<sect2>« Dé-fuzzy-fiez » les traductions complètes lors des
+corrections de typos et d'orthographe
+ <p>
+Quand le texte d'un questionnaire debconf est corrigé et que vous êtes
+<strong>certain</strong> que les changements <strong>n'ont aucun</strong>
+effet sur les traductions, soyez courtois avec les traducteurs et
+dé-fuzzy-fiez leurs traductions.
+ <p>
+Si vous ne le faites pas, le questionnaire entier ne sera pas traduit
+jusqu'à ce qu'un traducteur vous envoie une mise à jour.
+ <p>
+Pour <strong>dé-fuzzy-fier</strong> les traductions, vous pouvez
+procéder ainsi :
+<enumlist>
+<item>
+enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si les
+fichiers sont complets en utilisant (il faut que le paquet
+<package>gettext</package> soit installé) :
+<example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</example>
+<item>
+déplacez tous les fichiers ayant des chaînes floues
+(« fuzzy ») dans un emplacement temporaire. Les fichiers
+n'ayant aucune chaîne floue (seulement des chaînes traduites et non
+traduites) seront conservées où ils sont placés,
+<item>
+maintenant <strong>et seulement maintenant</strong>, corrigez les typos
+dans le questionnaire et vérifiez que les traductions ne sont pas
+impactées (les typos, les fautes d'orthographe et parfois les
+corrections de typographie sont généralement acceptables),
+<item>
+exécutez <prgn>debconf-updatepo</prgn>. Cela va fuzzifier toutes les
+chaînes que vous avez modifiées dans les traductions. Vous pouvez
+constater cela en exécutant à nouveau la commande ci-dessus,
+<item>
+utilisez la commande suivante :
+<example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
+<item>
+déplacez dans debian/po les fichiers qui avaient des chaînes floues dans
+la première étape,
+<item>
+exécutez à nouveau <prgn>debconf-updatepo</prgn>.
+</enumlist>
<sect2>Ne faites pas de suppositions à propos des interfaces
<p>
Yes... » n'a aucun sens pour les utilisateurs d'interfaces graphiques qui
utilisent des cases à cocher pour les questions booléennes.
<p>
+Les modèles de chaînes de caractères devraient éviter de mentionner les
+valeurs par défaut dans leur description. Tout d'abord, parce que cela
+est redondant avec les valeurs lues par les utilisateurs. Ensuite, parce
+ces valeurs par défaut peuvent être différentes selon les choix du
+responsable (par exemple, quand la base de données debconf a été
+préremplie).
+ <p>
Plus généralement, essayez d'éviter de vous référer à toute action de
l'utilisation. Donnez simplement des faits.
<p>
Vous devriez éviter d'utiliser la première personne (« I will do
this... » ou « We recommend... »). L'ordinateur n'est pas une
-personne et les qustionnaires debconf ne parlent pas pour les développeurs
+personne et les questionnaires debconf ne parlent pas pour les développeurs
Debian. Vous devriez utiliser une construction neutre et souvent une forme
passive. Pour ceux d'entre vous qui écrivent déjà des publications
scientifiques, écrivez simplement vos questionnaires comme vous écriveriez un
<sect2>Description: description courte et étendue
<p>
Les descriptions des modèles sont composées de deux parties : une courte et
-une étendu. La description courte est dans la ligne « Description: »
+une étendue. La description courte est dans la ligne « Description: »
du questionnaire.
<p>
La description courte devrait être gardée courte (50 caractères ou moins)
-poru qu'elle puissent être ajustée par la plupart des interfaces debconf. La
+pour qu'elle puisse être ajustée par la plupart des interfaces debconf. La
garder courte aide également les traducteurs, car les traductions ont tendance à
-être plus longue que l'originale.
+être plus longues que l'originale.
<p>
La description courte devrait se suffire à elle-même. Certaines interfaces
n'affichent pas la description longue par défaut ou seulement si l'utilisateur
Il n'est pas nécessaire que la description courte soit une phrase complète. Cela
fait partie de la recommandation « gardez-la courte et efficace ».
<p>
-La description étendu ne devrait pas répétée la description courte mot pour mot.
+La description étendue ne devrait pas répéter la description courte mot pour mot.
Si vous ne trouvez pas de description longue, commencez par à y réfléchir plus.
Envoyez un message sur debian-devel. Demandez de l'aide. Suivez un cours
-d'écriture ! La description étendue est imprtante. Si, après tout cela,
+d'écriture ! La description étendue est importante. Si, après tout cela,
vous ne trouvez toujours rien, laissez-la vide.
<p>
La description étendue devrait utiliser des phrases complètes. Des paragraphes
devraient être gardés court pour améliorer la lisibilité. Ne mélangez pas deux
-idées dans le même paragrpahe, mais utilisez plutôt un autre paragraphe.
+idées dans le même paragraphe, mais utilisez plutôt un autre paragraphe.
<p>
Ne soyez pas trop verbeux. Certaines interfaces debconf ne gèrent pas très bien
les descriptions de plus de 20 lignes, essayez donc de les conserver sous
<sect2>Champ Type
<p>
-Aucun indication spécifique excepté : utilisez le type approprié en vous
+Aucune indication spécifique excepté : utilisez le type approprié en vous
référant à la section précédente.
<sect2>Champ Description
deux-points est recommandée.
<item> La description étendue est un complément à la description courte. Dans la
- partie étendue, expliquez ce qui est demandé, plutpot que de poser la même
+ partie étendue, expliquez ce qui est demandé, plutôt que de poser la même
question à nouveau en utilisant des mots plus longs. Utilisez des phrases
complètes. Un style d'écriture trop concis est fortement découragé.
</list>
<p>
<list>
<item> La description courte devrait être rédigée sous la forme d'une question
- qui devrait être gardée courte et devrait généralement se termier par un
+ qui devrait être gardée courte et devrait généralement se terminer par un
point d'interrogation. Un style d'écriture concis est permis et même
encouragé si la question est plutôt longue (rappelez-vous que les
traductions sont souvent plus longue que les versions d'origine)
-<item> La description étendu ne devrait PAS inclure de question.
+<item> La description étendue ne devrait PAS inclure de question.
<item> À nouveau, veuillez éviter de vous référer à des composants d'interface
spécifiques. Une erreur courante pour de telles questionnaires est les
utilisateurs sont assez intelligents pour réaliser qu'ils doivent choisir
quelque chose...:)
-<item> La description étendu devra compléter la description courte. Elle peut se
+<item> La description étendue devra compléter la description courte. Elle peut se
référer aux choix disponibles. Elle peut également mentionner que
l'utilisateur peut choisir plus d'un des choix disponibles si le
questionnaire est du type sélection multiple (bien que l'interface rende
- soivent cela clair).
+ souvent cela clair).
</list>
<sect3>Notes
Les commentaires sont nécessaires car l'astuce DefaultChoice est un peu
déroutante : les traducteurs peuvent y placer leur propre choix.
- <sect2>Champ par défau
+ <sect2>Champ par défaut
<p>
N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas utiliser de
valeurs par défaut, n'utilisez pas simplement pas du tout Default.
<prgn>debconf-mergetemplate</prgn>. Cependant, cette technique est maintenant
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
+<package>po-debconf</package>. Cette méthode est plus facile pour le
responsable et pour les traducteurs ; des scripts de transition sont
fournis.
<p>
le paquet source <package>camlzip</package>.
</item>
<item>
- Les paquets fournissant des DTDs XML ou SGML devraient se conformer aux
+ Les paquets fournissant des DTD XML ou SGML devraient se conformer aux
recommandations que l'on peut trouver dans le paquet
<package>sgml-base-doc</package>
<item>
<example>apt-cache search .|grep transitional</example>.
</sect1>
+ <sect1 id="bpp-origtargz">
+ <heading>Les meilleures pratiques pour les fichiers <file>orig.tar.gz</file></heading>
+ <p>
+Il existe deux types d'archives tar (« tarball ») source
+d'origine : les sources vierges et les sources amont réempaquetées.
+ </p>
+ <sect2 id="pristine source">
+ <heading>Sources vierges</heading>
+ <p>
+La caractéristique définissant une archive source vierge est que le
+fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar
+officielle distribuée par l'auteur amont.
+<footnote>
+Nous ne pouvons pas empêcher les auteurs amont de changer l'archive tar
+qu'ils distribuent sans également incrémenter le numéro de version, il
+ne peut donc pas y avoir de garantie qu'une archive vierge est identique
+à ce que l'auteur amont distribue <em>actuellement</em> à tout moment.
+La seule chose à laquelle on peut s'attendre est que c'est identique à
+quelque chose que l'amont <em>a</em> un jour distribué.
+
+Si une différence se produit plus tard (par exemple, si l'amont remarque
+qu'il n'a pas utilisé la compression maximale pour sa distribution
+d'origine et qu'il la recompresse), c'est vraiment trop dommage.
+Comme il n'y a pas de bonne façon d'envoyer un nouveau .orig.tar.gz
+pour la même version, il n'y a même pas de raison de traiter cette
+situation comme un bogue.
+</footnote>
+Cela rend possible d'utiliser des vérifications de somme pour vérifier
+facilement que tous les changements entre la version Debian et celle de
+l'amont sont contenus dans le fichier diff Debian. Également, si le source
+amont est énorme, les auteurs amont et d'autres qui ont déjà l'archive
+tar amont peuvent économiser du temps de téléchargement s'ils veulent
+inspecter votre empaquetage en détail.
+ </p>
+ <p>
+Il n'y a pas de règles universellement acceptées suivies par les auteurs
+amont concernant la structure des répertoires dans leur archive tar, mais
+<prgn>dpkg-source</prgn> est cependant capable de traiter la plupart des
+archives tar comme source vierge. Sa stratégie est équivalente à la
+suivante :
+ </p>
+ <p>
+ <enumlist>
+ <item>
+Il décompacte l'archive tar dans un répertoire temporaire vide par
+
+<example>
+zcat path/to/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
+</example>
+ </item>
+ <item>
+Si, après cela, le répertoire temporaire ne contient qu'un
+répertoire et pas d'autres fichiers, <prgn>dpkg-source</prgn> renomme ce
+répertoire en
+<tt><packagename>-<version-amont>(.orig)</tt>. Le nom du
+répertoire de premier niveau dans l'archive tar n'a pas d'importance et
+est oublié.
+ </item>
+ <item>
+Sinon, l'archive tar a du être empaqueté sans répertoire de premier
+niveau commun (honte à l'auteur amont !). Dans ce cas,
+<prgn>dpkg-source</prgn> renomme le répertoire temporaire
+<em>lui-même</em> en
+<tt><packagename>-<version-amont>(.orig)</tt>.
+ </item>
+ </enumlist>
+ </p>
+ </sect2>
+ <sect2 id="repackaged origtargz">
+ <heading>Réempaquetage des sources amont</heading>
+ <p>
+Vous <strong>devriez</strong> envoyer des paquets sources avec une
+archive tar vierge si possible, mais il peut y avoir diverses raisons
+pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne
+distribue pas le source comme un tar gzipé du tout ou si l'archive tar
+amont contient du matériel non libre au sens des DFSG que vous devez
+supprimer avant l'envoi.
+ </p>
+ <p>
+Dans tous ces cas, le développeur doit construire un fichier
+.orig.tar.gz convenable lui-même. Nous nous référerons à une telle
+archive tar comme un « source amont réempaqueté ». Notez qu'un
+« source amont réempaqueté » est différent d'un paquet natif
+Debian. Un source réempaqueté est toujours fourni avec des changements
+spécifiques Debian dans un fichier <tt>.diff.gz</tt> séparé et il a
+toujours un numéro de version composé de <tt><source-amont></tt>
+et de <tt><debian-revision></tt>.
+ </p>
+ <p>
+Il peut y avoir des cas où il est désirable de réempaqueter le source
+même si l'amont distribue un fichier <tt>.tar.gz</tt> qui pourrait en
+principe être utilisé dans sa forme vierge. Le plus évident est si des
+économies d'espaces <em>significatives</em> peuvent être réalisées en
+recompressant l'archive tar ou en supprimant des parties
+fondamentalement inutiles de l'archive source. Agissez à votre guise à
+cet endroit, mais soyez prêt à défendre votre décision si vous
+réempaquetez un source qui aurait pu être vierge.
+ </p>
+ <p>
+Un .orig.tar.gz réempaqueté :
+ </p>
+ <p>
+ <enumlist>
+ <item>
+<p>
+<strong>doit</strong> contenir des informations détaillées sur la façon
+dont a été obtenu le source réempaqueté et comment cela peut être
+reproduit dans le fichier <file>README.Debian-source</file> ou un
+fichier similaire. Ce fichier devrait être dans la partie
+<file>diff.gz</file> du paquet source Debian, habituellement dans le
+répertoire <file>debian</file>, <em>pas</em> dans le
+<file>orig.tar.gz</file> réempaqueté. C'est également une bonne idée de
+fournir une cible <tt>get-orig-source</tt> dans votre fichier
+<file>debian/rules</file> qui répète le processus, comme décrit dans la
+Charte, <url id="&url-debian-policy;ch-source.html#s-debianrules"
+name="debian/rules, le principal script de construction">.
+</p>
+ </item>
+ <item>
+<strong>ne devrait pas</strong> contenir de fichiers qui ne viennent pas de
+l'auteur amont ou dont vous avez changé le contenu.
+<footnote>
+Comme exception spéciale, si l'omission d'un fichier non libre
+entraînerait l'échec de la compilation du source sans assistance du diff
+Debian, il peut être approprié au lieu de cela d'éditer les fichiers, en
+omettant seulement les parties non libres de ceux-ci et/ou d'expliquer
+la situation dans un fichier README.Debian-source <!-- ou nommé de -->
+<!-- manière similaire --> à la racine de l'arborescence du source. Mais
+dans ce cas, veuillez également demander instamment à l'auteur amont de
+faciliter la séparation des composants non libres du reste du source.
+</footnote>
+ </item>
+ <item>
+<p>
+<strong>devrait</strong>, sauf cas impossible pour des raisons légales,
+préserver l'infrastructure de construction entière et de portabilité
+fournie par l'auteur amont. Par exemple, ce n'est pas une raison
+suffisante pour omettre un fichier qui n'est utilisé que pour la
+construction sur MS-DOS. De manière similaire, un Makefile fourni par
+l'amont ne devrait pas être réécrit en exécutant un script configure.
+</p>
+<p>
+(<em>Explication :</em> il est courant que les utilisateurs Debian qui
+ont besoin de reconstruire un logiciel pour des plates-formes non-Debian
+récupèrent le source d'un miroir Debian plutôt que de chercher à
+localiser un point de distribution amont).
+</p> </item>
+ <item>
+<strong>devrait</strong> utiliser
+<tt><nom-du-paquet>-<version-amont>.orig</tt> comme nom du
+répertoire de premier niveau dans son archive tar. Cela rend
+possible la distinction entre des archives tar vierges d'archives
+réempaquetées.
+ </item>
+ <item>
+<strong>devrait</strong> être gzipé avec une compression maximale.
+ </item>
+ </enumlist>
+ </p>
+ <p>
+La façon canonique de réaliser les deux derniers points est de laisser
+<tt>dpkg-source -b</tt> construire l'archive tar réempaquetée à partir
+du répertoire décompacté.
+ </p>
+ </sect2>
+ <sect2 id="changed-binfiles">
+ <heading>Changer des fichiers binaires dans le <tt>diff.gz</tt></heading>
+ <p>
+Il est parfois nécessaire de changer des fichiers binaires
+contenus dans l'archive tar d'origine ou d'ajouter des fichiers binaires
+qui ne sont pas dans celle-ci. Si cela est fait en copiant simplement les
+fichiers dans l'arborescence de l'archive debianisée,
+<prgn>dpkg-source</prgn> ne pourra pas gérer cela. D'un autre côté,
+selon les règles détaillées ci-dessus, vous ne pouvez pas inclure un tel
+fichier binaire modifié dans un fichier <file>orig.tar.gz</file>
+réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire
+<file>debian</file> dans un format <prgn>uuencode</prgn> (ou semblable)
+<footnote>
+Le fichier devrait avoir un nom qui indique clairement quel fichier
+binaire il encode. Habituellement, un postfixe indiquant le codage
+devrait être ajouté au nom du fichier d'origine.
+</footnote>.
+Le fichier sera ensuite décodé et copié à son emplacement pendant
+l'étape de construction. Le changement sera donc visible assez facilement.
+</p>
+<p>
+Certains paquets utilisent <prgn>dbs</prgn> pour gérer les correctifs à
+leur source amont et créent toujours un nouveau fichier
+<tt>orig.tar.gz</tt> contenant le vrai <tt>orig.tar.gz</tt> dans son
+répertoire de premier niveau. Cela est discutable concernant la
+préférence pour un source vierge. D'un autre côté, il est facile de
+modifier ou d'ajouter des fichiers binaires dans ce cas : placez
+les simplement dans le fichier <tt>orig.tar.gz</tt> nouvellement créé à
+côté du vrai et copiez les au bon endroit pendant l'étape de
+construction.
+ </p>
+ </sect2>
+ </sect1>
+
+
</sect>
</chapt>
rapportés, vous avez simplement besoin d'aller à
<tt>http://&bugs-host;/from:<var><votre-adresse-de-courrier></var></tt>.
- <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports d'un seul
- coup
+ <sect1 id="submit-many-bugs">Ouvrir un grand nombre de rapports en
+ une seule fois (« mass bug filing »)
<p>
Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de
paquets — plus de dix — est une pratique que nous déconseillons.
paquet <package>lintian</package> pour générer une erreur ou un avertissement.
<p>
Si vous ouvrez plus de dix rapports sur le même sujet, il est préférable
- d'indiquer votre intention sur la liste &email-debian-devel;. Cela donnera à
+ d'indiquer votre intention sur la liste &email-debian-devel; et de
+ mentionner le fait dans le sujet de votre message. Cela donnera à
d'autres développeurs la possibilité de vérifier que le problème existe
vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent
les mêmes rapports de bogue simultanément.
<sect1 id="qa-daily-work">Travail journalier
<p>
-Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
+Bien qu'il y ait un groupe de personnes dédié à 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 corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
comme en vacances dans la base de données.
<item>Le nombre de paquets de ce responsable et les conditions de ces
- paquets. En particulier, restent-ils des bogues empêchant
+ paquets. En particulier, reste-t-il des bogues empêchant
l'intégration du paquet dans la distribution qui sont ouverts
depuis des lustres ? De plus, combien de bogues y a-t-il en
général ? Un autre point d'information important est si les
<p>
Un gros problème est représenté par les paquets parrainés — le responsable
n'est pas un développeur Debian officiel. Les informations « echelon »
-ne sont pas disponibles pour les personnes parrainés, par exemple, vous devez
+ne sont pas disponibles pour les personnes parrainées, par exemple, vous devez
donc trouver et contacter le responsable Debian qui a réellement envoyé le
paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
— vous ne savez pas qui recevra vos courriers. Imaginez comme un
proche se sentira s'il lit un courrier pour la personne décédée et trouve un
-message très impoli, en colère et accusateur !)
+message très impoli, en colère et accusateur !
<p>
D'un autre côté, bien que nous soyons tous volontaires, nous avons une
responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
<p>
+<!-- FIXME: service down
Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
<url id="&url-sponsors;">.
<p>
+-->
Les nouveaux responsables ont habituellement certaines difficultés à créer des
paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain
est là pour vérifier que le paquet parrainé est assez bon pour être inclus
Pour les messages des programmes, l'infrastructure gettext est utilisée pour la
plupart d'entre eux. La plupart du temps, la traduction est gérée en amont dans
des projets comme le
-<url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de trduction
+<url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de traduction
libre">, le <url id="http://developer.gnome.org/projects/gtp/"
name="projet de traduction de Gnome"> ou <url
id="http://i18n.kde.org/" name="celui de KDE">.
<prgn>debdiff</prgn> (du paquet <package>devscripts</package>, <ref
id="devscripts">) compare des listes de fichiers et des fichiers de contrôle de
deux paquets. C'est un simple test de régression qui peut vous aider à remarquer
-si le nombre de paquets binaires à changer depuis le dernier envoi ou si autre
+si le nombre de paquets binaires a changé depuis le dernier envoi ou si autre
chose a changé dans le fichier de contrôle. Bien sûr, certains des changements
qu'il indique sont normaux, mais il peut aider à empêcher différents accidents.
<p>
~ianmdlvl / developers-reference.git / blobdiff