<!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.48 $">
<!-- 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.263"> -->
<!-- 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 20050412).</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">.
+]]>
+
<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ère 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.
+<p>
+De plus, 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
<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>
<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
<tt>&ftp-master-host;</tt> et sur <tt>&non-us-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>
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
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 :
<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.
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>
Veuillez utiliser (et abuser de) la liste de discussions
debian-l10n-english@lists.debian.org. 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
<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>
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
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>
<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 amonts</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érérons à 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.
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