<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.55 $">
+ <!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.271"> -->
+ <!-- <!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 20051026).</version>
+ <version>Version &version;, &date-fr; (version française 20051114).</version>
<copyright>
<copyrightsummary>Copyright © 2004—2005 Andreas Barth</copyrightsummary>
est invité à s'abonner à cette liste (voir <ref id="mailing-lists"> pour
les détails).
<p>
-Ceux qui préfère recevoir une aide plus personnalisée (par exemple, par
+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ériementé se proposera de les aider.
+et un développeur expérimenté se proposera de les aider.
<p>
-De plus, vous avez des paquets prêts à être inclus dans Debian, mais que
+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
<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. Si l'ancienne clé
- est compromise ou invalide, vous devez également ajouter le certification de
+ 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">.
<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
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.
<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>
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;)
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é).
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
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
<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>
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>
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
# 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
+ addgroup - -quiet - -system $SERVER_GROUP 2>/dev/null ||true
echo "..done"
fi
# 2. Création du répertoire personnel s'il n'existe pas
# 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 \
+ adduser - -quiet \
+ - -system \
+ - -ingroup $SERVER_GROUP \
+ - -no-create-home \
+ - -disabled-password \
$SERVER_USER 2>/dev/null || true
echo "..done"
fi
-g $SERVER_GROUP \
$SERVER_USER
# 5. Ajuste les permissions de fichiers et répertoires
- if ! dpkg-statoverride --list $SERVER_HOME >/dev/null
+ if ! dpkg-statoverride - -list $SERVER_HOME >/dev/null
then
chown -R $SERVER_USER:adm $SERVER_HOME
chmod u=rwx,g=rxs,o= $SERVER_HOME
<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>.
+<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
+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 :
if [ "$FIST_SYSTEM_UID" -le "$USERID" ] && \
[ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
echo -n "Removing $CREATEDUSER system user.."
- deluser --quiet $CREATEDUSER || true
+ deluser - -quiet $CREATEDUSER || true
echo "..done"
fi
fi
if [ -n "$GROUPGID" ]; then
if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
echo -n "Removing $CREATEDGROUP group.."
- delgroup --only-if-empty $CREATEDGROUP || true
+ delgroup - -only-if-empty $CREATEDGROUP || true
echo "..done"
fi
fi
</sect1>
</sect>
-
+ -->
<sect id="bpp-config-mgmt">
<heading>Gestion de la configuration avec <package>debconf</package></heading>
<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)
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
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>
</p>
</sect2>
<sect2 id="repackaged origtargz">
- <heading>Réempaquetage des sources amonts</heading>
+ <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
</p>
<p>
Dans tous ces cas, le développeur doit construire un fichier
-.orig.tar.gz convenable lui-même. Nous nous référérons à une telle
+.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
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