<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
-
-
-
+ <!-- include version information so we don't have to hard code it
+ within the document -->
<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
-
- <?xml version="1.0" encoding="iso-8859-1"?>
-<!-- common entities file
-
- Bits of text which are language independent. In some cases it
- makes sense to break these out because repetitively maintaining
- them in different translations of the Developer's Reference is
- wasteful. In other cases, the data is rather volatile and
- breaking it out make maintenance easier.
- -->
-
-<!-- volatile information -->
-
-<!ENTITY number-of-pkgs "9000">
-<!ENTITY number-of-maintainers "900">
-
-<!ENTITY number-of-arches "12">
-
-<!-- standard information -->
-<!ENTITY fsf-addr "Free Software Foundation, Inc.,
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA">
-<!ENTITY file-GPL "<file>/usr/share/common-licenses/GPL</file>">
-<!ENTITY debian-formal "Debian GNU/Linux">
-
-<!--
- URLs, Debian
- -->
-<!ENTITY www-debian-org "www.debian.org">
-<!ENTITY ftp-debian-org "ftp.debian.org">
-<!ENTITY ftp-host "&ftp-debian-org;">
-<!ENTITY www-host "&www-debian-org;">
-<!ENTITY lists-host "lists.debian.org">
-<!ENTITY archive-host "archive.debian.org">
-<!ENTITY keyserver-host "keyring.debian.org">
-<!ENTITY packages-host "packages.debian.org">
-<!ENTITY bugs-host "bugs.debian.org">
-<!ENTITY pts-host "packages.qa.debian.org">
-<!ENTITY ftp-master-host "ftp-master.debian.org">
-<!ENTITY ftp-master-mirror "merkel.debian.org">
-<!ENTITY non-us-host "non-us.debian.org">
-<!ENTITY upload-queue "<ftppath>/pub/UploadQueue/</ftppath>">
-
-<!ENTITY url-debian-policy "http://&www-debian-org;/doc/debian-policy/">
-<!ENTITY url-perl-policy "http://&www-debian-org;/doc/packaging-manuals/perl-policy/">
-<!ENTITY url-emacs-policy "http://&www-debian-org;/doc/packaging-manuals/debian-emacs-policy">
-<!ENTITY url-java-policy "http://&www-debian-org;/doc/packaging-manuals/java-policy/">
-<!ENTITY url-libpkg-guide "http://www.netfort.gr.jp/~dancer/column/libpkg-guide/">
-
-<!ENTITY url-social-contract "http://&www-debian-org;/social_contract">
-<!ENTITY url-constitution "http://&www-debian-org;/devel/constitution">
-<!ENTITY url-dfsg "&url-social-contract;#guidelines">
-<!ENTITY url-debian-lists "http://&www-debian-org;/MailingLists/">
-<!ENTITY url-debian-lists-txt "http://&ftp-debian-org;/debian/doc/mailing-lists.txt">
-<!ENTITY url-debian-lists-subscribe "http://&www-debian-org;/MailingLists/subscribe">
-<!ENTITY url-debian-lists-new "http://&www-debian-org;/MailingLists/HOWTO_start_list">
-<!ENTITY url-lists-archives "http://&lists-host;/">
-<!ENTITY url-bts "http://&www-debian-org;/Bugs/">
-<!ENTITY url-bts-report "&url-bts;Reporting">
-<!ENTITY url-bts-devel "&url-bts;Developer">
-<!ENTITY url-bts-control "&url-bts;server-control">
-<!ENTITY url-debian-mirrors "http://&www-debian-org;/mirror/">
-<!ENTITY url-debian-mirroring "&url-debian-mirrors;">
-<!ENTITY url-debian-ports "http://&www-debian-org;/ports/">
-<!ENTITY url-debian-port-lists "http://&lists-host;/ports.html">
-<!ENTITY url-wnpp "http://&www-debian-org;/devel/wnpp/">
-<!ENTITY url-devel-docs "http://&www-debian-org;/devel/">
-<!ENTITY url-vote "http://&www-debian-org;/vote/">
-<!ENTITY url-cvsweb "http://cvs.debian.org/">
-<!ENTITY url-devel-machines "http://db.debian.org/machines.cgi">
-<!ENTITY url-buildd "http://buildd.debian.org/">
-<!ENTITY url-lintian "http://lintian.debian.org/">
-<!ENTITY url-debian-qa "http://qa.debian.org/">
-<!ENTITY url-debian-qa-orphaned "http://qa.debian.org/orphaned.html">
-<!ENTITY url-debian-db "https://db.debian.org/">
-<!ENTITY url-debian-db-login "https://db.debian.org/login.html">
-<!ENTITY url-debian-db-mail-gw "http://db.debian.org/doc-mail.html">
-<!ENTITY url-debian-db-doc "http://db.debian.org/doc-general.html">
-<!ENTITY url-newmaint "http://&www-debian-org;/devel/join/newmaint">
-<!ENTITY url-newmaint-checklist "http://&www-debian-org;/devel/join/nm-checklist">
-<!ENTITY url-newmaint-db "http://nm.debian.org/">
-<!ENTITY url-newmaint-advocate "http://&www-debian-org;/devel/join/nm-advocate">
-<!ENTITY url-newmaint-amchecklist "http://&www-debian-org;/devel/join/nm-amchecklist">
-<!ENTITY url-newmaint-apply "http://nm.debian.org/newnm.php">
-<!ENTITY url-newmaint-id "http://&www-debian-org;/devel/join/nm-step2">
-<!ENTITY url-newmaint-guide "http://&www-debian-org;/doc/maint-guide/">
-<!ENTITY url-gpg-coord "http://nm.debian.org/gpg.php">
-<!ENTITY url-debian-security-advisories "http://&www-debian-org;/security/">
-<!ENTITY url-tech-ctte "http://&www-debian-org;/devel/tech-ctte">
-<!ENTITY url-ddpo "http://qa.debian.org/developer.php">
-
-<!ENTITY url-debian-keyring "http://&ftp-debian-org;/debian/doc/debian-keyring.tar.gz">
-<!ENTITY url-readme-non-us "http://&ftp-debian-org;/debian/README.non-US">
-<!ENTITY url-incoming "http://incoming.debian.org/">
-<!ENTITY url-testing-maint "http://www.debian.org/devel/testing">
-<!-- deprecated -->
-<!ENTITY url-testing-faq "&url-testing-maint;">
-
-<!ENTITY us-upload-dir "<file>/org/ftp.debian.org/incoming/</file>">
-<!ENTITY non-us-upload-dir "<file>/org/non-us.debian.org/incoming/</file>">
-<!ENTITY url-chiark-readme "ftp://ftp.chiark.greenend.org.uk/pub/debian/private/project/README.how-to-upload">
-<!ENTITY url-upload-erlangen "ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue/">
-<!ENTITY url-upload-samosa "ftp://samosa.debian.org/pub/UploadQueue/">
-<!ENTITY url-upload-jp "ftp://master.debian.or.jp/pub/Incoming/upload/">
-
-<!ENTITY url-mentors "http://people.debian.org/~mpalmer/debian-mentors_FAQ.html">
-<!ENTITY url-sponsors "http://www.internatif.org/bortzmeyer/debian/sponsor/">
-
-<!ENTITY url-rules-files "http://arch.debian.org/arch/private/srivasta/">
-
-<!ENTITY url-debconf-l10n-help "http://&www-debian-org;/intl/l10n/templates/hints">
-
-<!ENTITY url-dmup "http://&www-debian-org;/devel/dmup">
-<!ENTITY url-worldmap "http://&www-debian-org;/devel/developers.loc">
-
-<!ENTITY url-i18n-doc-check "http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD&content-type=text/vnd.viewcvs-markup">
-
-<!ENTITY url-eg-desc-upstream-info "http://&packages-host;/unstable/web/wml">
-
-<!ENTITY url-alioth "http://alioth.debian.org/">
-
-<!--
- URLs, non-debian
- -->
-<!ENTITY url-gnu-manifesto "http://www.gnu.org/gnu/manifesto.html">
-<!ENTITY url-gpl "http://www.gnu.org/copyleft/gpl.html">
-<!ENTITY url-pgp-faq "http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/">
-<!ENTITY url-rfc2440 "http://www.rfc-editor.org/rfc/rfc2440.txt">
-<!ENTITY url-u.s.-export "http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html">
-<!ENTITY url-notification-of-export "http://www.bxa.doc.gov/Encryption/">
-<!ENTITY url-openprojects "http://www.freenode.net/">
-
-<!-- Debian email addresses -->
-<!ENTITY email-listmaster "<email>listmaster@&lists-host;</email>">
-<!ENTITY email-debian-announce "<email>debian-announce@&lists-host;</email>">
-<!ENTITY email-devel-ref "<email>developers-reference@&packages-host;</email>">
-<!ENTITY email-debian-changes "<email>debian-changes@lists.debian.org</email>">
-<!ENTITY email-debian-devel "<email>debian-devel@&lists-host;</email>">
-<!ENTITY email-debian-devel-announce "<email>debian-devel-announce@&lists-host;</email>">
-<!ENTITY email-debian-devel-changes "<email>debian-devel-changes@lists.debian.org</email>">
-<!ENTITY email-debian-devel-req "<email>debian-devel-REQUEST@&lists-host;</email>">
-<!ENTITY email-debian-i18n "<email>debian-i18n@&lists-host;</email>">
-<!ENTITY email-debian-mentors "<email>debian-mentors@&lists-host;</email>">
-<!ENTITY email-debian-private "<email>debian-private@&lists-host;</email>">
-<!ENTITY email-debian-project "<email>debian-project@&lists-host;</email>">
-<!ENTITY email-debian-policy "<email>debian-policy@&lists-host;</email>">
-<!ENTITY email-debian-user "<email>debian-user@&lists-host;</email>">
-<!ENTITY orphan-address "<packages@qa.debian.org>">
-<!ENTITY email-debian-qa "<email>debian-qa@&lists-host;</email>">
-<!ENTITY email-debian-release "<email>debian-release@&lists-host;</email>">
-<!ENTITY email-debian-email "<email>debian-email@&lists-host;</email>">
-<!ENTITY email-debian-vote "<email>debian-vote@&lists-host;</email>">
-<!ENTITY email-debian-security-announce "<email>debian-security-announce@&lists-host;</email>">
-<!ENTITY email-debian-l10n-english "<email>debian-l10n-english@&lists-host;</email>">
-<!ENTITY email-mia "<email>mia@qa.debian.org</email>">
-
-<!ENTITY email-new-maintainer "<email>new-maintainer@debian.org</email>">
-<!ENTITY email-debian-keyring "<email>keyring-maint@debian.org</email>">
-<!ENTITY email-debian-admin "<email>debian-admin@debian.org</email>">
-<!ENTITY email-ftpmaster "<email>ftpmaster@debian.org</email>">
-<!ENTITY email-override "<email>override-change@debian.org</email>">
-<!ENTITY email-wnpp "<email>wnpp@debian.org</email>">
-<!ENTITY email-bts-control "<email>control@&bugs-host;</email>">
-<!ENTITY email-security-team "<email>team@security.debian.org</email>">
+ <!-- common, language independent entities -->
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
-<!-- misc Debian info -->
-<!ENTITY file-mail-lists "<file>/usr/share/doc/debian/mailing-lists.txt</file>">
-<!ENTITY file-bts-docs "<file>/usr/share/doc/debian/bug-*</file>">
-<!ENTITY file-python-policy "<file>/usr/share/doc/python/python-policy.txt.gz</file>">
-<!ENTITY file-ocaml-policy "<file>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</file>">
-<!ENTITY file-lisp-controller "<file>/usr/share/doc/common-lisp-controller/README.packaging</file>">
-<!ENTITY file-debian-private-archive "~debian/archive/debian-private/">
-<!ENTITY file-bpp-autotools "<file>/usr/share/doc/autotools-dev/README.Debian.gz</file>">
+ <!-- CVS revision of this document -->
+ <!ENTITY cvs-rev "$Revision: 1.64 $">
-<!ENTITY cron-bug-report '0 17 * * fri echo "index maint <var>address</var>" | mail request@&bugs-host;'>
+ <!-- if you are translating this document, please notate the CVS
+ revision of the original developer's reference in cvs-en-rev -->
+ <!-- <!ENTITY cvs-en-rev "1.315"> -->
-<!ENTITY control-file-fields "<list compact>
- <item><tt>Format</tt>
- <item><tt>Date</tt>
- <item><tt>Source</tt>
- <item><tt>Binary</tt>
- <item><tt>Architecture</tt>
- <item><tt>Version</tt>
- <item><tt>Distribution</tt>
- <item><tt>Urgency</tt>
- <item><tt>Maintainer</tt>
- <item><tt>Description</tt>
- <item><tt>Changes</tt>
- <item><tt>Files</tt>
- </list>">
-
-<!--
- misc, non-debian
- -->
-<!ENTITY pgp-keyserv "<tt>subkeys.pgp.net</tt>">
-<!ENTITY file-keyservs "<file>/usr/share/doc/pgp/keyserv.doc</file>">
-
-<!ENTITY sample-dist-dirtree "<example>
-dists/stable/main/
-dists/stable/main/binary-i386/
-dists/stable/main/binary-m68k/
-dists/stable/main/binary-alpha/
- ...
-dists/stable/main/source/
- ...
-dists/stable/main/disks-i386/
-dists/stable/main/disks-m68k/
-dists/stable/main/disks-alpha/
- ...
-
-dists/stable/contrib/
-dists/stable/contrib/binary-i386/
-dists/stable/contrib/binary-m68k/
-dists/stable/contrib/binary-alpha/
- ...
-dists/stable/contrib/source/
-
-dists/stable/non-free/
-dists/stable/non-free/binary-i386/
-dists/stable/non-free/binary-m68k/
-dists/stable/non-free/binary-alpha/
- ...
-dists/stable/non-free/source/
-
-dists/testing/
-dists/testing/main/
- ...
-dists/testing/contrib/
- ...
-dists/testing/non-free/
- ...
-
-dists/unstable
-dists/unstable/main/
- ...
-dists/unstable/contrib/
- ...
-dists/unstable/non-free/
- ...
-
-pool/
-pool/main/a/
-pool/main/a/apt/
- ...
-pool/main/b/
-pool/main/b/bash/
- ...
-pool/main/liba/
-pool/main/liba/libalias-perl/
- ...
-pool/main/m/
-pool/main/m/mailx/
- ...
-pool/non-free/n/
-pool/non-free/n/netscape/
- ...
-</example>">
-
-<!ENTITY example-pathfind '<example>pathfind() {
- OLDIFS="$IFS"
- IFS=:
- for p in $PATH; do
- if [ -x "$p/$*" ]; then
- IFS="$OLDIFS"
- return 0
- fi
- done
- IFS="$OLDIFS"
- return 1
-}</example>'>
-
- <!ENTITY % dynamicdata SYSTEM "dynamic.ent"> %dynamicdata;
-
-
- <!ENTITY cvs-rev "$Revision: 1.61 $">
-
-
-
-
-
-
+ <!-- how to mark a section that needs more work -->
<!ENTITY FIXME "<em>FIXME:</em> ">
]>
-<?xml version="1.0" encoding="iso-8859-1"?><debiandoc>
+<debiandoc>
<book>
<titlepag>
<title>
<author>
<name>Ian Jackson </name>
</author>
-<!-- <!ENTITY cvs-en-rev "1.288"> -->
<translator>
version française par Frédéric Bothamy (traducteur actuel)
</translator>
et les membres de la liste <email>debian-l10n-french@lists.debian.org</email>
</translator>
<version>
- Version &version;, &date-fr; (version française 20060405).
+ Version &version;, &date-fr; (version française 20061130).
</version>
<copyright>
<copyrightsummary>
- Copyright © 2004—2005 Andreas Barth
+ Copyright © 2004—2006 Andreas Barth
</copyrightsummary>
<copyrightsummary>
Copyright © 1998—2003 Adam Di Carlo
travaillent déjà sur ces tâches et proposer des correctifs et des
améliorations.
</p>
+ <p>
+ Un écueil à éviter est d'avoir la partie locale de votre adresse
+ électronique trop générique : des termes comme mail, admin, root ou
+ master devraient être évitées. Veuillez consulter <url
+ id="http://www.debian.org/MailingLists/"> pour plus de détails.
+ </p>
</sect>
<sect id="mentors">
<heading>
<p>
Avant de décider de devenir responsable Debian, il vous faudra lire
toute la documentation disponible dans le <url id="&url-newmaint;"
- name="coin du nouveau responsable">. Elle décrit toutes les étapes
- préparatoires qu'il vous faudra franchir avant de déposer votre
+ name="coin du nouveau responsable">. Elle décrit en détail toutes les
+ étapes préparatoires qu'il vous faudra franchir avant de déposer votre
candidature. Par exemple, avant d'être candidat, il vous faudra lire le
<url id="&url-social-contract;" name="contrat social Debian">. Devenir
responsable Debian implique que vous adhériez à ce contrat social et
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) et maintenir un paquet parrainé pendant un temps. Nous attendons
+ (BTS) et maintenir un paquet parrainé par un responsable Debian 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 informations sur un
</p>
<p>
Si votre clé publique n'est pas sur un serveur public tel que
- &pgp-keyserv;, reportez-vous à la documentation disponible localement
- dans &file-keyservs;. Cette documentation explique comment mettre votre
+ &pgp-keyserv;, reportez-vous à la documentation disponible à
+ <url id="&url-newmaint-id;" name="Étape 2 : Vérification d'identité">.
+ Cette documentation explique comment mettre votre
clé publique sur un serveur. L'équipe <em>New maintainer</em> mettra
votre clé publique sur les serveurs de clés si elle n'y est pas déjà.
</p>
</p>
<p>
Pour faire acte de candidature, il vous faut un responsable Debian qui
- vérifiera votre candidature (un <em>avocat</em>). Après avoir contribué
+ soutiendra votre candidature (un <em>avocat</em>). Après avoir contribué
au projet Debian pendant un temps, quand vous choisissez de devenir un
responsable Debian officiel, un responsable déjà enregistré avec qui
vous aurez travaillé dans les derniers mois devra exprimer que, d'après
lui, vous pouvez contribuer avec succès au projet Debian.
</p>
<p>
- Quand vous avez trouvez un <em>avocat</em>, quand votre clé GnuPG est
+ Quand vous avez trouvé un <em>avocat</em>, quand votre clé GnuPG est
signée et quand vous avez déjà contribué au projet, vous êtes prêt à
faire acte de candidature. Il vous suffit pour cela de vous enregistrer
sur notre <url id="&url-newmaint-apply;" name="page de
<p>
Habituellement, cela veut dire que les autres développeurs peuvent
faire des NMU (voir <ref id="nmu">) sur votre paquet si un gros
- problème (bogues empêchant l'intégration dans la distribution, mise à
+ problème (bogue empêchant l'intégration dans la distribution, mise à
jour de sécurité, etc.) se produit pendant que vous êtes en
vacances. Parfois, ce n'est pas très important, mais il est de toute
façon approprié d'indiquer aux autres que vous n'êtes pas disponible.
<em>grave</em> et <em>serious</em> en anglais</p></footnote> sont
considérés comme ayant un impact sur la présence du paquet dans la
prochaine version stable de Debian. Ces bogues peuvent retarder la
- diffusion d'une distribution Debian ou peuvent justifier la suppression
+ publication d'une distribution Debian ou peuvent justifier la suppression
d'un paquet d'une distribution gelée. C'est pourquoi ces bogues doivent
être corrigés au plus vite.
</p>
</heading>
<p>
Plusieurs canaux IRC sont dédiés au développement Debian. Ils sont
- principalement hébergés sur le réseau <url id="&url-openprojects;"
- name="freenode"> (anciennement connu sous le nom de Open Projects
- Network). L'entrée DNS <tt>irc.debian.org</tt> est simplement un alias
- vers <tt>irc.freenode.net</tt>.
+ principalement hébergés sur le réseau <url id="&url-oftc;"
+ name="Open and free technology community (OFTC)">. L'entrée DNS
+ <tt>irc.debian.org</tt> est simplement un alias vers
+ <tt>irc.oftc.net</tt>.
</p>
<p>
Le principal canal pour Debian est <em>#debian</em>. Il s'agit d'un
</p>
<p>
Il existe également des canaux dédiés pour Debian sur d'autres réseaux
- IRC, notamment sur le réseau IRC <url id="http://www.oftc.net/"
- name="Open and free technology community (OFTC)">.
+ IRC, notamment sur le réseau IRC <url id="&url-openprojects;"
+ name="Freenode">, sur lequel pointait l'alias <tt>irc.debian.org</tt>
+ jusqu'au 4 juin 2006.
</p>
<p>
Pour obtenir un uniforme (« cloak ») sur freenode, vous devez
Debian 2.0, « Hamm » ; Debian 2.1,
« Slink »; Debian 2.2, « Potato » ;
Debian 3.0, « Woody » ; Debian 3.1,
- « Sarge » ; Debian (nombre à déterminer)
+ « Sarge » ; Debian 4.0,
« Etch ». Il y a aussi une pseudo-distribution nommée
« Sid », il s'agit de la distribution
<em>unstable</em> ; comme les paquets vont d'<em>unstable</em> à
serveurs HTTP et FTP de Debian. Si nous avions nommé le répertoire qui
contient la prochaine distribution à diffuser « testing »,
il aurait fallu changer son nom en « stable » au moment de
- la diffusion, ce qui aurait forcé les miroirs FTP à télécharger à
+ la publication, ce qui aurait forcé les miroirs FTP à télécharger à
nouveau la distribution complète (qui est plutôt volumineuse).
</p>
<p>
serveurs. De cette façon, les utilisateurs ont toujours accès aux
miroirs et s'y habituent, ce qui permet à Debian de mieux répartir les
besoins en bande passante sur plusieurs serveurs et plusieurs réseaux
- différents et évitent aux utilisateurs de surcharger l'emplacement
+ différents et évite aux utilisateurs de surcharger l'emplacement
primaire. Notez que, dans cette première série, les serveurs sont aussi
à jour que possible car la mise à jour est déclenchée par les sites
maîtres internes.
<p>
<prgn>madison</prgn> est un outil en ligne de commande qui est
disponible sur <tt>&ftp-master-host;</tt> et sur le miroir
- <tt>&ftp-master-mirror;</tt>. Il utilise un seul argument qui
+ <tt>&ftp-master-mirror;</tt>. Il utilise un seul paramètre qui
correspond au nom du paquet. Il affiche comme résultat quelle version
du paquet est disponible pour chaque combinaison d'architecture et de
distribution. Un exemple l'expliquera mieux.
</tag>
<item>
<p>
- (Ceci est une extension prévue). Les courriers de résumé réguliers
- sur l'état du paquet (statistiques sur les bogues, vue générale du
- portage, progression dans <em>testing</em>, etc.).
+ Des courriers de résumé réguliers sur l'état du paquet. Actuellement,
+ seule la progression du paquet dans <em>testing</em> est envoyée.
</p>
</item>
</taglist>
DDTP</em></p></footnote>.
</p>
</item>
+ <tag>
+ <tt>derivatives</tt>
+ </tag>
+ <item>
+ <p>
+ Des informations sur les changements effectués sur le paquet dans les
+ distributions dérivées (par exemple, Ubuntu).
+ </p>
+ </item>
</taglist>
</p>
<sect1 id="pts-commands">
</heading>
<p>
Vous pouvez contrôler votre (vos) inscription(s) au PTS en envoyant
- différents commandes à <email>pts@qa.debian.org</email>.
+ différentes commandes à <email>pts@qa.debian.org</email>.
<taglist>
<tag>
<tt>subscribe <paquet source> [<adresse>]</tt>
<p>
Inscrit <var>adresse</var> aux communications liées au paquet
source <var>paquet source</var>. L'adresse de l'expéditeur est
- utilisée si le second argument n'est pas présent. Si <var>paquet
+ utilisée si le second paramètre n'est pas présent. Si <var>paquet
source</var> n'est pas un paquet source valide, vous obtiendrez un
avertissement. Cependant, s'il s'agit d'un paquet binaire valide,
le PTS vous inscrira pour le paquet source correspondant.
<p>
Supprime une inscription précédente au paquet source <var>paquet
source</var> en utilisant l'adresse spécifiée ou l'adresse de
- l'expéditeur si le second argument n'est pas rempli.
+ l'expéditeur si le second paramètre n'est pas rempli.
+ </p>
+ </item>
+ <tag>
+ <tt>unsubscribeall [<adresse>]</tt>
+ </tag>
+ <item>
+ <p>
+ Supprime toutes les inscriptions précédentes de l'adresse spécifiée
+ ou de l'adresse de l'expéditeur si le second paramètre n'est pas
+ rempli.
</p>
</item>
<tag>
questionnaires debconf
</p>
</item>
+ <item>
+ <p>
+ <tt>derivatives</tt> : changements effectués sur le paquet
+ dans des distributions dérivées
+ </p>
+ </item>
<item>
<p>
<tt>upload-source</tt> : annonce d'un nouvel envoi de
<item>
<p>
Accepte (+) ou refuse (-) les courriers classés sous le(s)
- mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés.
+ mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
+ change l'ensemble par défaut des mots-clés acceptés par un
+ utilisateur.
+ </p>
+ </item>
+ <tag>
+ <tt>keywordall [<adresse>] {+|-|=} <liste de
+ mots-clés></tt>
+ </tag>
+ <item>
+ <p>
+ Accepte (+) ou refuse (-) les courriers classés sous le(s)
+ mot(s)-clé(s). Définit la liste (=) des mots-clés acceptés. Ceci
+ change les mots-clés de toutes les inscriptions actuellement en cours
+ d'un utilisateur.
</p>
</item>
<tag>
</item>
</taglist>
</p>
+ <p>
+ L'utilitaire en ligne de commande <prgn>pts-subscribe</prgn> (du paquet
+ <package>devscripts</package>) peut être pratique pour s'inscrire
+ temporairement à certains paquets, par exemple après avoir fait une mise
+ à jour indépendante (NMU).
+ </p>
+
</sect1>
<sect1 id="pts-mail-filtering">
<heading>
</p>
</item>
</list>
- Les nouvelles usuelle peuvent être utilisées pour annoncer que :
+ Les nouvelles usuelles peuvent être utilisées pour annoncer que :
<list>
<item>
<p>
bogue à l'installation du nouveau paquet sur les serveurs d'archivage
(voir <ref id="upload-bugfix">).
</p>
+ <p>
+ Lors de la fermeture de bogues de sécurité, incluez les numéros CVS ainsi
+ que « Closes: #nnnnn ». Ceci est utile l'équipe de sécurité
+ pour suivre les failles de sécurité. Si un envoi est effectué pour
+ corriger le bogue avant que l'identifiant de l'alerte soit connu, il est
+ conseillé de modifier l'entrée de changelog historique lors du prochain
+ envoi. Même dans ce cas, veuillez inclure tous les pointeurs disponibles
+ vers les informations de contexte dans l'entrée de changelog d'origine.
+ </p>
<p>
Plusieurs raisons nous poussent à demander aux responsables d'annoncer
leur intention :
<p>
C'est une information utile pour les gens qui utilisent la
distribution <em>unstable</em> et qui sont nos premiers
- testeurs. Nous devons faciliter la tâche de ces gens.
+ testeurs. Nous devons leur faciliter la tâche.
</p>
</item>
<item>
</item>
</list>
</p>
+ <p>
+ Veuillez consulter <url
+ id="http://ftp-master.debian.org/REJECT-FAQ.html"> pour les raisons
+ courantes de rejet des nouveaux paquets.
+ </p>
</sect>
<sect id="changelog-entries">
<heading>
</p>
<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
+ faciliter le travail lors du téléchargement. Ces programmes bien
+ pratiques aident à automatiser le processus d'envoi de paquets vers
Debian
</p>
<p>
Les envois différés sont pour le moment réalisés <em>via</em> la file
différée sur gluck. Le répertoire d'envoi est
<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>. 0-day est
- envoyé approximativement une heure avant l'exécution de dinstall.
+ envoyé approximativement plusieurs fois par jour vers ftp-master.
</p>
<p>
Avec une version assez récente de dput, cette section
Envois de sécurité
</heading>
<p>
- N'envoyez PAS un paquet vers la file d'envoi de sécurité
+ N'envoyez <strong>PAS</strong> un paquet vers la file d'envoi de sécurité
(<em>oldstable-security</em>, <em>stable-security</em>, etc.) sans
avoir obtenu au préalable l'autorisation de l'équipe de sécurité. Si
le paquet ne correspond pas tout à fait aux besoins de cette équipe,
Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes
vos discussions concernant les bogues sont envoyées au rapporteur du
bogue et au bogue lui-même (<email>123@&bugs-host;</email> par
- exemple). Si vous rédigez un nouveau courrier et que vous ne vous
+ exemple). Si vous rédigez un nouveau courrier et si vous ne vous
souvenez plus de l'adresse du rapporteur de bogue, vous pouvez
utiliser l'adresse <email>123-submitter@&bugs-host;</email> pour
contacter le rapporteur <em>et</em> enregistrer votre courrier dans le
l'archive Debian. C'est pourquoi, vous pouvez et vous devez clore les
rapports dans le système de suivi des bogues une fois que vous avez
reçu l'avis indiquant que votre nouveau paquet a été installé dans
- l'archive.
+ l'archive. Le bogue devrait être fermé avec la bonne version.
</p>
<p>
Cependant, il est possible d'éviter d'avoir à fermer manuellement les
fichier <file>changelog</file>.
</p>
<p>
- Si un envoi est identifié comme une <qref id="nmu">mise à jour
- indépendante (NMU)</qref> (et c'est le cas si le nom de la personne
- qui a réalisé ce changement n'est pas exactement le même que celui de
- l'un des responsables ou expéditeurs, sauf si le responsable est le
- groupe d'Assurance Qualité), le bogue est alors marqué <tt>fixed</tt>
- (corrigé) au lieu d'être fermé. Si un envoi de responsable a pour
- cible <em>experimental</em>, l'étiquette
- <tt>fixed-in-experimental</tt> est alors ajoutée au bogue ; pour
- les mises à jour indépendantes, l'étiquette <tt>fixed</tt> (corrigé)
- est utilisée (il est attendu que la règle spéciale pour
- <em>experimental</em> sera modifiée dès que le suivi des versions sera
- ajouté au système de suivi des bogues).
+ À moins que cela soit spécifié différemment par l'option <var>-v</var> de
+ <prgn>dpkg-buildpackage</prgn>, seuls les bogues fermés dans l'entrée de
+ changelog la plus récente sont fermés (fondamentalement, seuls les
+ bogues mentionnés dans la partie de changelog du fichier
+ <file>.changes</file> sont fermés).
+ </p>
+ <p>
+ <!-- les bogues des envois ... ? -->
+ Historiquement, les envois identifiés comme <qref id="nmu">Mise à jour
+ indépendante</qref> (« Non-maintainer upload » ou NMU) étaient
+ marqués comme <tt>fixed</tt> au lieu d'être fermés, mais cette pratique
+ a cassé avec l'ajout du suivi des versions. Le même raisonnement
+ s'applique à l'étiquette <tt>fixed-in-experimental</tt>.
</p>
<p>
Si vous entrez un numéro de bogue incorrect ou si vous oubliez un
bogues, &email-bts-control;. Pour fermer tous les bogues restants qui
ont été corrigés par votre envoi, envoyez le fichier
<file>.changes</file> à <email>XXX-done@&bugs-host;</email> où
- <var>XXX</var> est le numéro du bogue.
+ <var>XXX</var> est le numéro du bogue et placez « Version:
+ YYY » et une ligne vide dans les deux premières lignes du corps du
+ courrier où <var>YYY</var> est la première version dans laquelle le
+ bogue a été corrigé.
</p>
<p>
Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en
<p>
À la différence de la plupart des autres activités au sein de Debian,
les informations sur les problèmes de sécurité doivent parfois être
- gardées en privé pour un certain temps. Ceci permet les distributeurs
+ gardées en privé pour un certain temps. Ceci permet aux distributeurs
de logiciels de coordonner leur dévoilement afin de minimiser
l'exposition de leurs utilisateurs. Cette décision dépend de la
nature du problème et de l'existence d'une solution correspondante et
<p>
si le problème est grave, il est préférable de partager cette
information avec d'autres vendeurs et de coordonner une
- diffusion. L'équipe de sécurité garde des contacts avec les
+ publication. L'équipe de sécurité reste en contact avec les
différentes organisations et individus et peut prendre soin des
actions à mener.
</p>
Préparer les paquets pour corriger des problèmes de sécurité
</heading>
<p>
- Une façon d'aider l'équipe de sécurité dans ses travaux est de leur
+ Une façon d'aider l'équipe de sécurité dans ses travaux est de lui
fournir des paquets corrigés convenables pour une annonce de sécurité
pour la version <em>stable</em> de Debian
</p>
diffusée, donc tout changement qui est fait est susceptible de casser
le système de quelqu'un. Ceci est spécialement vrai pour les
bibliothèques : assurez-vous ne de jamais changer l'API ou
- l'ABI, quelque minimal que soit le changement.
+ l'ABI, aussi minimal que soit le changement.
</p>
<p>
Cela veut dire que passer à une version amont supérieure n'est pas
</p>
<p>
Si une personne de l'équipe de sécurité accepte un paquet, il sera
- installé sur security.debian.org ainsi que dans le répertoire
- <var>distribution</var>-proposed-updates qui convient sur ftp-master
- ou dans l'archive non-US.
+ installé sur security.debian.org et proposé pour le répertoire
+ <var>distribution</var>-proposed-updates qui convient sur ftp-master.
</p>
</sect2>
</sect1>
modifiez les informations de contrôle du paquet pour le placer dans la
section désirée et téléchargez à nouveau votre paquet dans
l'archive. Reportez-vous à la <url id="&url-debian-policy;"
- name="charte Debian"> pour en savoir plus. Si votre nouvelle section
+ name="charte Debian"> pour en savoir plus. Vous devez vous assurer
+ d'inclure le fichier <file>.orig.tar.gz</file> dans votre envoi (même si
+ vous n'envoyez pas de nouvelle version amon) ou il n'apparaîtra pas dans
+ la nouvelle section avec le reste du paquet. Si votre nouvelle section
est valide, il sera déplacé automatiquement. Si ce n'est pas le cas,
contactez les responsables ftp pour comprendre ce qui s'est passé.
</p>
<em>testing</em> n'en dépend.
</p>
<p>
- Vous devez également détailler les raisons justifiant cette
+ Il existe une exception pour laquelle il n'est pas nécessaire de faire
+ une demande explicite de suppression : si un paquet (source ou
+ binaire) est orphelin, il sera supprimé de façon semi-automatique. Pour
+ un paquet binaire, cela veut dire s'il n'y a plus de paquet source
+ produisant le paquet binaire ; si le paquet binaire n'est
+ simplement plus produit pour certaines architectures, une demande de
+ suppression est toujours nécessaire. Pour un paquet source, cela veut
+ dire que tous les paquets binaires auxquels il se réfère ont été
+ récupérés par un autre paquet source.
+ </p>
+ <p>
+ Vous devez détailler dans votre demande de suppressions les raisons
+ justifiant cette
demande. Ceci a pour but d'éviter les suppressions non désirées et de
garder une trace de la raison pour laquelle un paquet a été
supprimé. Par exemple, vous pouvez fournir le nom du paquet qui
programme <prgn>apt-cache</prgn> du paquet <package>apt</package>
pourra aussi vous être utile. La commande <tt>apt-cache showpkg
<var>paquet</var> </tt> vous indiquera, entre autres, les paquets qui
- dépendent de <var>paquet</var>. Le retrait de paquets orphelins est
- discuté sur &email-debian-qa;.
+ dépendent de <var>paquet</var>.
+ Parmi d'autres programmes utiles, citons <tt>apt-cache rdepends</tt>,
+ <prgn>apt-rdepends</prgn> et <prgn>grep-dctrl</prgn>.
+ Le retrait de paquets orphelins est discuté sur &email-debian-qa;.
</p>
<p>
Une fois que le paquet a été supprimé, les bogues du paquet doivent
pour le faire. Les plaintes à propos des responsables devraient être
portées sur la liste de diffusion des développeurs. Si la discussion
ne se termine pas par une conclusion positive et que le problème est
- de nature technique, considérez de porter le cas à l'attention du
+ de nature technique, envisagez de porter le cas à l'attention du
comité technique (voir la <url id="&url-tech-ctte;" name="page web du
comité technique"> pour plus d'information).
</p>
les porteurs doivent manipuler un grand nombre de paquets. À nouveau,
la situation diffère selon la distribution visée. Elle varie
également selon que l'architecture est candidate pour inclusion dans
- la prochaine version stable ; les responsables de diffusion
+ la prochaine version stable ; les responsables de publication
décident et annoncent quelles architectures sont candidates.
</p>
<p>
de portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
recommandations communément acceptées). Pour les envois de
<em>stable</em> ou <em>testing</em>, veuillez tout d'abord vous
- coordonner avec l'équipe de diffusion appropriée.
+ coordonner avec l'équipe de publication appropriée.
</p>
<p>
Deuxième différence, les porteurs qui font des mises à jour
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.
+ également et l'indiquera à un lecteur humain sans vraiment essayer.
</p>
</item>
<item>
</p>
<p>
La raison principale pour laquelle une mise à jour indépendante est
- réalisée est quand un développeur a besoin de corriger des paquets d'un
+ réalisée est quand un développeur a besoin de corriger le paquet d'un
autre développeur pour résoudre des problèmes sérieux ou des bogues
paralysants ou quand le responsable d'un paquet ne peut pas fournir une
correction dans un délai raisonnable.
</p>
<p>
Pour la distribution <em>testing</em>, les règles peuvent être
- changées par les responsables de diffusion. Veuillez porter une
+ changées par les responsables de publication. Veuillez porter une
attention spéciale au fait que le moyen habituel pour un paquet
d'entrer dans <em>testing</em> est de passer par <em>unstable</em>.
</p>
d'informations.
</p>
<p>
- Pour les différences pour les mises à jour indépendantes par les
+ Pour les différences concernant les mises à jour indépendantes par les
porteurs, veuillez voir <ref id="source-nmu-when-porter">.
</p>
<p>
une entrée dans le fichier <file>changelog</file> qui indique les
bogues corrigés et qui précise pourquoi cette mise à jour était
nécessaire. Cette entrée comportera l'adresse de la personne ayant
- fait la mise à jour ainsi que la version livrée.
+ fait l'envoi ainsi que la version livrée.
</p>
<p>
Par convention, dans le cas d'une mise à jour indépendante source
</p>
<p>
Après avoir fait une mise à jour indépendante, il vous faudra aussi
- envoyer cette information aux bogues existants que vous avez corrigés
- par votre NMU en incluant le diff unifié. Sinon, vous pouvez créer un
+ envoyer l'information aux bogues existants que vous avez corrigés
+ par votre NMU en incluant le diff unifié. Historiquement, c'était une
+ habitude de créer un
nouveau rapport de bogue et inclure un correctif comprenant toutes les
modifications que vous avez réalisées. Le responsable officiel pourra
choisir d'appliquer le correctif, il pourra aussi employer une autre
Les paquets faisant l'objet d'une mise à jour indépendante source sont
construits comme les autres. Sélectionnez une distribution en
utilisant les règles décrites dans la section <ref id="distribution">
- en suivant toutes les prescriptions de la section <ref id="upload">.
+ en suivant toutes les instructions de la section <ref id="upload">.
</p>
<p>
Vérifiez que vous n'avez pas modifié la valeur du champ
id="&url-debian-qa-orphaned;">. Si vous effectuez une mise à jour
indépendante sur un paquet incorrectement orphelin, veuillez
positionner le responsable à « Debian QA Group
- <packages@qa.debian.org> ». Dans ce cas, les bogues du
- paquet sont fermés et pas simplement marqués comme corrigés.
+ <packages@qa.debian.org> ».
</p>
</sect1>
<sect1 id="nmu-who">
toujours les correctifs et les rapports de bogue soignés.
</p>
</sect1>
- <sect1 id="nmu-katie">
- <heading>
- Comment dak détecte les mises à jour indépendantes
- </heading>
- <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é).
- </p>
- </sect1>
<sect1 id="nmu-terms">
<heading>
Terminologie
paquet : ceci ne se produit que pour permettre à un
<em>autre</em> paquet d'entrer, ce dernier doit être prêt pour tous
les autres critères. Considérons, par exemple, qu'un paquet
- <em>a</em> est en conflit avec la nouvelle version de
+ <em>a</em> ne peut pas être installé avec la nouvelle version de
<em>b</em> alors <em>a</em> peut être supprimé pour permettre
l'entrée de <em>b</em>.
</p>
<em>testing</em> : le paquet est trop bogué (et avoir un seul
bogue RC est suffisant pour être dans cet état).
</p>
+ <p>
+ De plus, si un paquet a été supprimé d'<em>unstable</em> et qu'aucun
+ paquet de <em>testing</em> n'en dépend plus, il sera alors
+ automatiquement supprimé.
+ </p>
+
</sect2>
<sect2 id="circular">
<heading>
</p>
<p>
Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de
- diffusion. Veuillez les contacter en envoyant un courrier
+ publication. Veuillez les contacter en envoyant un courrier
électronique à debian-release@lists.debian.org si cela se produit
pour l'un de vos paquets.
</p>
</sect2>
<sect2>
<heading>
- Influence de paquet dans <em>testing</em>
+ Influence d'un paquet dans <em>testing</em>
</heading>
<p>
Généralement, l'état d'un paquet dans <em>testing</em> ne change rien
valides. Cela donne le fichier « update excuses ». Les
raisons les plus communes pour lesquelles un paquet n'est pas
considéré sont la jeunesse du paquet, le nombre de bogues RC et la
- désynchronisation pour certaines architectures. Pour cette partie,
+ désynchronisation pour certaines architectures. Pour cette partie de britney,
les responsables de version ont des marteaux de toute taille pour
forcer britney à considérer un paquet. (Le gel de la base est
également codé dans cette partie de britney.) (Il y a une chose
<item>
<p>
après l'envoi et la construction réussie sur toutes les
- plates-formes, contactez l'équipe de diffusion à
+ plates-formes, contactez l'équipe de publication à
&email-debian-release; et demandez-leur d'approuver votre envoi.
</p>
</item>
</p>
<sect2 id="rc">
<heading>
- Qu'est-ce que sont les bogues bloquant l'intégration dans la version
- stable et comment sont-ils comptés ?
+ Quels sont les bogues bloquant l'intégration dans la version stable
+ et comment sont-ils comptés ?
</heading>
<p>
Tous les bogues de gravité assez élevée sont par défaut considérés
paquets 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 nécessaire et ainsi économiser de l'espace disque).
+ d'un seul gros (afin, par exemple, que l'utilisateur puisse n'installer
+ que la partie nécessaire et ainsi économiser de l'espace disque).
</p>
<p>
Le second cas peut facilement être géré dans le fichier
<p>
C'est une vieille tradition de valider les bogues fixés par une mise à
jour indépendante dans la première entrée du changelog de l'envoi du
- vrai responsable. Veuillez utiliser l'option <tt>-v</tt> de
- <prgn>dpkg-buildpackage</prgn> pour fermer les rapports de bogue
- correspondants.
+ vrai responsable. Comme nous avons maintenant le suivi des versions, il
+ est suffisant de garder les entrées de changelog des mises à jour
+ indépendantes et de simplement mentionner ce fait dans votre propre
+ entrée de changelog.
</p>
</sect1>
<sect1 id="bpp-changelog-errors">
Les scripts de maintenance incluent les fichiers
<file>debian/postinst</file>, <file>debian/preinst</file>,
<file>debian/prerm</file> et <file>debian/postrm</file>. Ces scripts
- prennent soin de la configuration d'installation ou de désinstallation
- des paquets, ce qui n'est pas simplement créer ou supprimer des
- fichiers et des répertoires. Les instructions suivantes complètent la
- <url id="&url-debian-policy;" name="charte Debian">.
+ prennent en charge la configuration d'installation ou de
+ désinstallation des paquets, ce qui n'est pas simplement créer ou
+ supprimer des fichiers et des répertoires. Les instructions suivantes
+ complètent la <url id="&url-debian-policy;" name="charte Debian">.
</p>
<p>
Les scripts de maintenance doivent être idempotents. Cela veut dire que
script de maintenance, la fonction de shell suivante conforme à POSIX
peut vous aider : &example-pathfind; Vous pouvez utiliser cette
fonction pour rechercher le <tt>$PATH</tt> pour un nom de commande
- passé en argument. Il renvoie vrai (zéro) si la commande a été trouvée
+ passé en paramètre. Il renvoie vrai (zéro) si la commande a été trouvée
et faux sinon. Il s'agit réellement de la façon la plus portable de
faire car <tt>command -v</tt>, <prgn>type</prgn> et <prgn>which</prgn>
ne sont pas POSIX.
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 papier scientifique.
+ questionnaires comme vous écririez un papier scientifique.
</p>
</sect2>
<sect2>
boolean: (booléen)
</heading>
<p>
- Un choix vrai/faux. Rappelez-vous : vrai/faux, PAS OUI/NON...
+ Un choix vrai/faux. Rappelez-vous : vrai/faux, <strong>pas oui/non</strong>...
</p>
</sect3>
<sect3>
premier dans l'installateur Debian.
</p>
<p>
- Veuillez ne pas l'utiliser à moins que debconf ne le prennent en
+ Veuillez ne pas l'utiliser à moins que debconf ne le prenne en
charge.
</p>
<p>
La description courte devrait être gardée courte (50 caractères
ou moins) 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 longues que l'originale.
+ car les traductions ont tendance à être plus longues que l'original.
</p>
<p>
La description courte devrait se suffire à elle-même. Certaines
utilisez plutôt un autre paragraphe.
</p>
<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 cette limite.
+ Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les
+ écrans trop longs. Par expérience, 20 lignes est la limite à
+ éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue
+ classique, les utilisateurs devront faire défiler le texte et un grand
+ nombre de personnes ne le font simplement pas.
</p>
<p>
Pour des règles spécifiques selon le type de questionnaire (chaîne de
<list>
<item>
<p>
- La description courte est une invite et NON un titre. Évitez des
- invites de style question (« IP Address? ») en faveur
- d'invites « ouvertes »à (« IP
- address: »). L'utilisation des deux-points est recommandée.
+ La description courte est une invite et <strong>non</strong> un
+ titre. Évitez des invites de style question (« IP
+ Address? ») en faveur d'invites « ouvertes »à
+ (« IP address: »). L'utilisation des deux-points est
+ recommandée.
</p>
</item>
<item>
</item>
<item>
<p>
- La description étendue ne devrait PAS inclure de question.
+ La description étendue ne devrait <strong>pas</strong> inclure de
+ question.
</p>
</item>
<item>
<list>
<item>
<p>
- La description courte est une invite et NON un titre. N'utilisez
- PAS des constructions inutiles du type « Please
- choose... ». Les utilisateurs sont assez intelligents pour
- réaliser qu'ils doivent choisir quelque chose...:)
+ La description courte est une invite et <strong>non</strong> un
+ titre. N'utilisez <strong>pas</strong> des constructions inutiles
+ du type « Please choose... ». Les utilisateurs sont assez
+ intelligents pour réaliser qu'ils doivent choisir quelque chose...:)
</p>
</item>
<item>
<item>
<p>
La description étendue est ce qui sera affiché comme une
- description plus détaillée de la note. Faites de phrases,
+ description plus détaillée de la note. Faites des phrases,
n'utilisez pas un style d'écriture trop concis.
</p>
</item>
<item>
<p>
- N'ABUSEZ PAS DE DEBCONF. Les notes sont le moyen le plus courant
+ <strong>N'abusez pas de debconf.</strong> Les notes sont le moyen le plus courant
d'abus de debconf. Comme il est écrit dans la page de manuel de
debconf-devel : il est préférable de ne les utiliser que
pour des avertissements à propos de problèmes très sérieux. Les
<p>
Ce champ spécial permet aux traducteurs de positionner le choix le
plus approprié selon leur propre langue. Cela deviendra le choix par
- défaut quand leur langue sera sélectionné alors votre choix par
+ défaut quand leur langue sera sélectionnée alors votre choix par
défaut sera utilisé pour l'anglais.
</p>
<p>
</heading>
<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
+ utiliser de valeurs par défaut, n'utilisez simplement pas du tout
Default.
</p>
<p>
- Si vous utilisez po-debconf (et vous DEVRIEZ le faire, voir 2.2),
+ Si vous utilisez po-debconf (et vous <strong>devriez</strong> le faire, voir 2.2),
veuillez considérer de rendre ce champ traduisible, si vous pensez
qu'il peut être traduit.
</p>
quels paquets peuvent être enlevés sans problème du système, i.e. ceux
dont aucun paquet ne dépend. L'opération par défaut est de chercher
seulement parmi les sections libs et oldlibs pour débusquer les
- bibliothèques inutilisées. Mais si l'on passe le bon argument, il
+ bibliothèques inutilisées. Mais si l'on passe le bon paramètre, il
tente d'attraper d'autres paquets inutiles.
</p>
<p>
<p>
Il décompacte l'archive tar dans un répertoire temporaire vide par
<example>
-zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -</example>
+zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
+ </example>
</p>
</item>
<item>
</item>
<item>
<p>
- Sinon, l'archive tar a du être empaqueté sans répertoire de
+ Sinon, l'archive tar a dû ê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><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.
+ Il peut y avoir des cas où il est souhaitable 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é :
<strong>ne devrait pas</strong> contenir de fichiers qui ne
viennent pas de l'auteur amont ou dont vous avez changé le
contenu. <footnote><p>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 à 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.</p></footnote>
+ fichier non libre devait entraîner 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 à 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.</p></footnote>
</p>
</item>
<item>
semblable) <footnote><p>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.</p></footnote>. Le fichier sera ensuite décodé et copié à
+ d'origine. Notez que vous n'avez pas besoin de dépendre de
+ <package>sharutils</package> pour avoir le programme
+ <prgn>uudecode</prgn> si vous utilisez la fonction <tt>pack</tt> de
+ <prgn>perl</prgn>. Le code pourrait ressembler à ceci :
+ <example>
+uuencode-file:
+ perl -ne 'print(pack "u", $$_);' $(file) > $(file).uuencoded
+
+uudecode-file:
+ perl -ne 'print(unpack "u", $$_);' $(file).uuencoded > $(file)
+ </example>
+ </p></footnote>. Le fichier sera ensuite décodé et copié à
son emplacement pendant l'étape de construction. Le changement sera
donc visible assez facilement.
</p>
d'éviter que plusieurs responsables ne rédigent les mêmes rapports de
bogue simultanément.
</p>
+ <p>
+ Veuillez utiliser les programmes <prgn>dd-list</prgn> et si nécessaire,
+ <prgn>whodepends</prgn> (du paquet <package>devscripts</package>) pour
+ générer une liste de tous les paquets concernés et incluez la sortie
+ dans votre courrier à &email-debian-devel;.
+ </p>
<p>
Quand vous envoyez un grand nombre de rapports sur le même sujet, vous
devriez les envoyer à <email>maintonly@&bugs-host;</email> pour qu'ils
QA contacte un responsable inactif ou trouve plus d'informations sur
celui-ci, c'est enregistré dans la base de données MIA. Ce système est
disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut
- être interrogé avec un outil de nom <prgn>mia-history</prgn>. Par
- défaut, <prgn>mia-history</prgn> affiche des informations sur toutes
- les personnes qu'il connaît, mais il accepte des expressions
- rationnelles comme paramètre qu'il utilise comme correspondance de noms
- d'utilisateur.
- <example>mia-history --help</example>
- affiche quels paramètres sont acceptés. Si vous déterminez qu'aucune
+ être interrogé avec un outil de nom <prgn>mia-query</prgn>.
+ Utilisez <example>mia-query --help</example> pour voir comment interroger
+ la base de données. Si vous déterminez qu'aucune
information n'a encore été enregistrée pour un responsable inactif ou
- que vous voulez ajouter plus d'informations, vous deviez utiliser la
+ si vous voulez ajouter plus d'informations, vous deviez utiliser la
procédure suivante.
</p>
<p>
</list>
</p>
<p>
- Un gros problème est représenté par les paquets parrainés
+ Un problème particulier 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é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 parraine.
+ l'envoi de toute façon et il est probable qu'il sait ce qui s'est passé
+ avec la personne qu'il parraine.
</p>
<p>
Il est également permis d'envoyer une demande à &email-debian-devel;
demandant si quelqu'un est au courant d'information sur le responsable
- manquant.
+ manquant. Veuillez mettre en CC: la personne en question.
</p>
<p>
Une fois que vous avez réuni toutes ces informations, vous pouvez
l'envie, il devrait « laisser filer » et donner le paquet à
quelqu'un ayant plus de temps.
</p>
+ <p>
+ Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez
+ étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org
+ où les détails techniques et les procédures MIA sont documentées et
+ contactez &email-mia;.
+ </p>
</sect>
<sect id="newmaint">
<heading>
~ianmdlvl / developers-reference.git / blobdiff