X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.fr.sgml;h=d90e1140184c9b5b7a7deaf8f42dde627d285054;hb=31829f6e41f3a27b0b12239cf0f25d66d9ec16cf;hp=841dafbc976a849f5ce70b7bf8c28a741a3f463b;hpb=c59ad6556551f785357d6eb7344661c5855a08e5;p=developers-reference.git diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index 841dafb..d90e114 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -4,12 +4,13 @@ %versiondata; %commondata; + %dynamicdata; - + - + FIXME: "> @@ -30,10 +31,10 @@ version française par Frédéric Bothamy (traducteur actuel) et Antoine Hulin (ancien traducteur) et les membres de la liste debian-l10n-french@lists.debian.org - Version &version;, &date-fr; (version française 20041005). + Version &version;, &date-fr; (version française 20050508). - Copyright © 2004 Andreas Barth + Copyright © 2004—2005 Andreas Barth Copyright © 1998—2003 Adam Di Carlo Copyright © 2002—2003 Raphaël Hertzog Copyright © 1997, 1998 Christian Schwarz. @@ -54,6 +55,12 @@ le fichier &file-GPL; de la distribution &debian-formal; ou sur la toile : . Vous pouvez également l'obtenir en écrivant à la &fsf-addr;. + +Si vous désirez imprimer cette référence, vous devriez utiliser la . +]]> + Portée de ce document @@ -89,7 +96,7 @@ id="&url-debian-policy;" name="charte Debian">.

De plus ce document n'est pas l'expression d'une politique officielle. Il contient de la documentation sur le système Debian et des conseils pratiques -largement suivis. C'est une sorte de guide pratique. +largement suivis. Ce n'est donc pas une sorte de guide de normes. Introduction à la version française @@ -231,7 +238,7 @@ Vous suivrez les discussions de cette liste (sans poster) pendant quelque temps

Une autre liste intéressante est &email-debian-mentors;. Voir la section pour les détails. Le canal IRC #debian pourra aussi être - utile. + utile ; voir .

Quand vous avez choisi la manière dont vous contribuerez au projet @@ -250,7 +257,34 @@ Quand vous avez choisi la mani 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. + + Mentors et parrains Debian +

+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 pour +les détails). +

+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. +

+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. + +Veuillez lire en premier la FAQ non officielle de debian-mentors à . +

+Si vous désirez être un mentor et/ou un parrain, vous pouvez trouver +plus d'informations à . S'enregistrer comme responsable Debian

@@ -277,7 +311,7 @@ Le processus d'enregistrement a pour but de v

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 @@ -289,12 +323,11 @@ Pour votre candidature, vous devrez signée, vous devriez essayer de rencontrer un responsable Debian pour le faire. La 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 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 pour en savoir plus).

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 @@ -310,9 +343,9 @@ Debian utilise GNU Privacy Guard (paquet gnupg autre implémentation d'OpenPGP. OpenPGP est un standard ouvert basé sur la .

-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. GNU @@ -327,8 +360,7 @@ Si votre cl 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.

@@ -355,27 +387,6 @@ Pour en savoir plus, consultez le Mentors et parrains Debian -

-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 pour plus de détails). -

-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. -

-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 . Veuillez tout - d'abord lire la FAQ non officielle de debian-mentors à . -

-Si vous désirez être mentor ou parrain, reportez-vous à . - - Les charges du responsable Debian Mise à jour de vos références Debian @@ -398,11 +409,26 @@ Soyez tr copie hors connexion. Lisez la documentation fournie avec votre logiciel et la .

+Vous devez vous assurer que non seulement votre clé est à l'abri des vols, mais + également à l'abri d'une perte. Générez et faites une copie (et également sur + papier) de votre certificat de révocation ; il est nécessaire si votre clé + est perdue. +

Si vous ajoutez des signatures ou des identifiants à votre clé publique, vous pouvez mettre à jour le porte-clés Debian en envoyant votre clé publique à - &keyserver-host;. Si vous voulez ajouter ou supprimer une clé, envoyez - un courrier à &email-debian-keyring;. Les procédures d'extraction de clé - décrites dans s'appliquent ici. + &keyserver-host;. +

+Si vous voulez ajouter une nouvelle clé ou supprimer une ancienne clé, vous +devez faire signer la nouvelle clé par un autre développeur. Après cela, un +courriel signé par cet autre développeur listant votre nom de compte, les +identifiants de clé (« keyids ») de l'ancienne clé et de la nouvelle +et la raison doivent être envoyés à &email-debian-keyring;. Si l'ancienne clé +est compromise ou invalide, vous devez également ajouter le certification de +révocation. S'il n'y pas de vraie raison pour une nouvelle clé, les responsables +du trousseau de clés ne l'accepteront que si elle est plus sure et connectée à +l'ancienne clé. +

+Les mêmes routines d'extraction de clé décrites dans s'appliquent.

Vous pouvez trouver une présentation approfondie de la gestion de clé Debian dans la documentation du paquet debian-keyring. @@ -460,6 +486,14 @@ L'autre chose base de données Debian LDAP (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 ! +

+Idéalement, vous devriez vous connecter sur le + +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. Coordination avec les développeurs amont

@@ -543,11 +577,11 @@ h Pour en savoir plus sur comment s'abonner ou se désabonner, comment envoyer un message et comment ne pas en envoyer, comment retrouver d'anciens messages et comment les rechercher, comment contacter les responsables des listes et pour -sevoir d'autres informations sur les listes de diffusion, veuillez lire . Cette section ne couvrira que les aspects des listes de diffusion qui ont un intérêt particulier pour les développeurs. - Rêgles de base d'utilisation + Règles de base d'utilisation

Lorsque vous répondez sur une liste de diffusion, veuillez ne pas envoyer de copie (CC) à l'auteur d'origine sauf s'il le demande explicitement. @@ -646,8 +680,8 @@ Comme #debian-devel est un canal ouvert, vous ne devriez pas y parler

Il existe d'autres canaux dédiés à des sujets spécifiques. #debian-bugs est utilisé pour la coordination des chasses aux bogues. - #debian-boot est utilisé pour la coordination du travail sur les - disquettes de démarrage (i.e., l'installeur). #debian-doc est utilisé + #debian-boot est utilisé pour la coordination du travail sur + l'installateur Debian. #debian-doc 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 : #debian-bsd, #debian-kde, @@ -661,6 +695,17 @@ Certains canaux pour d Il existe également des canaux dédiés pour Debian sur d'autres réseaux IRC, notamment sur le réseau IRC . +

+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é : +. Le courriel doit être signé par une clé +du porte-clés Debian. Veuillez consulter la + pour plus d'informations sur les uniformes. Documentation @@ -794,6 +839,7 @@ Habituellement, la seule raison pour utiliser un serveur diff Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question. Le serveur CVS +

Notre serveur CVS est situé sur cvs.debian.org.

@@ -853,8 +899,8 @@ Pour plus d'informations, veuillez lire la documentation en ligne que vous pouvez trouver à .

-Il est également possible d'envoyer ses clés SSH pour les utiliser pour - autorisation sur les machines Debian officielles et même d'ajouter de nouvelles +Les développeurs peuvent également envoyer leurs clés SSH pour qu'elles soient utilisées pour + autorisation sur les machines Debian officielles et même ajouter de nouvelles entrées DNS du type *.debian.net. Ces fonctionnalités sont documentées à . @@ -964,7 +1010,7 @@ Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC, reconnaît les architectures i386 et m68k. Debian 2.1 reconnaît les architectures i386, m68k, alpha et sparc. Debian 2.2 accepte en plus les architectures - powerpc et arm. Debian 3.0 accepte cinq + powerpc et arm. Debian 3.0 a ajouté cinq nouvelles architectures : ia64, hppa, s390, mips et mipsel.

@@ -1098,7 +1144,7 @@ deb http://ftp.xy.debian.org/debian/ ../project/experimental main deb-src http://ftp.xy.debian.org/debian/ ../project/experimental main

-Si un logiciel peut causer des dégats importants, il sera sûrement +Si un logiciel peut causer des dégâts importants, il sera sûrement préférable de le mettre dans la distribution experimental. Un système de fichiers compacté expérimental, par exemple, devrait probablement aller dans experimental. @@ -1131,6 +1177,11 @@ Veuillez consid dpkg-buildpackage si l'envoi d'un paquet dans unstable ferme finalement des bogues qui ont d'abord été corrigés dans experimental. +Lors de l'envoi vers unstable d'un paquet contenant des bogues corrigés +dans experimental, veuillez considérer l'utilisation de l'option +-v de dpkg-buildpackage pour qu'ils soient finalement +fermés. + Les noms de distribution

Chaque distribution Debian diffusée a un nom de code : Debian 1.1 @@ -1203,11 +1254,19 @@ Le syst &ftp-master-host; et sur &non-us-host;.

Les paquets sont envoyés par tous les responsables Debian dans un répertoire - nommé unchecked. Ce répertoire est parcouru toutes les 15 minutes + nommé UploadQueue. Ce répertoire est parcouru toutes les + quelques minutes par un démon appelé queued, les fichiers + *.command sont exécutés et les fichiers + *.changes restants et correctement signés sont déplacés + avec leurs fichiers correspondants dans le répertoire + unchecked. 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 katie 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 accepted. S'il s'agit - du premier envoi du paquet, il est déplacé dans le répertoire new + du premier envoi du paquet (ou s'il a de nouveaux paquets binaire), il + est déplacé dans le répertoire new où il attend l'approbation des ftpmasters. Si le paquet contient des fichiers devant être installés à la main, il est déplacé dans le répertoire byhand où il attend une installation manuelle par les ftpmasters. @@ -1217,10 +1276,11 @@ Les paquets sont envoy 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 à (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 Incoming et + maintenant accessible publiquement à 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 Incoming et installé dans le pool avec les autres paquets. Une fois que toutes les autres mises à jour (fabrication des nouveaux fichiers d'index Packages et Sources par exemple) ont été effectuées, un script spécial est @@ -1235,8 +1295,12 @@ de diffusion appropri « experimental », l'annonce sera à la place envoyée à &email-debian-devel-changes;.

+Bien que ftp-master soit à accès restreint, une copie de l'installation + est disponible à tous les développeurs sur &ftp-master-mirror;. + Informations sur un paquet

@@ -1295,7 +1359,7 @@ Chaque paquet a plusieurs pages web d http://&packages-host;/nom-paquet affiche chaque version du paquet disponible dans les différentes distributions. Les informations détaillées par version incluent la description du paquet, les dépendances et - des liens pour récupérer le paquet. + des liens pour télécharger le paquet.

Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder les bogues de chaque paquet à @@ -1304,7 +1368,8 @@ Le syst L'outil madison

madison est un outil en ligne de commande qui est disponible sur - &ftp-master-host; et sur &non-us-host;. Il utilise un seul + &ftp-master-host;, sur &non-us-host; et sur le miroir + &ftp-master-mirror;. Il utilise un seul argument qui correspond au nom du paquet. Il affiche comme résultat quelle version du paquet est disponible pour chaque combinaison d'architecture et de distribution. Un exemple l'expliquera mieux. @@ -1318,10 +1383,9 @@ libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, i

Dans cet exemple, vous pouvez voir que la version dans unstable diffère de celle de testing et qu'il y a eu une NMU binaire seulement pour - l'architecture alpha. À chaque fois, le paquet a été recompilé sur la plupart + l'architecture alpha. Chaque version du paquet a été recompilée sur la plupart des architectures. - Système de suivi des paquets

Le système de suivi des paquets (PTS)« Package Tracking @@ -1590,7 +1654,7 @@ C'est une bonne id Alioth est un service de Debian plutôt récent, basé sur une version légèrement modifiée du logiciel GForge (qui a évolué à partir de SourceForge). Ce logiciel offre aux développeurs l'accès à des outils -faciles d'utilisation comme un un gestionnaire de suivi de bogues, un +faciles d'utilisation comme un gestionnaire de suivi de bogues, un gestionnaire de correctifs, un gestionnaire de tâches et de projets, un service d'hébergement de fichiers, des listes de diffusion, des dépôts CVS, etc. Tous ces outils sont gérés par une interface web. @@ -1859,6 +1923,7 @@ Attention, il est pr être rejetée car l'outil de maintenance de l'archive pourrait lire le fichier changes et constater que les fichiers ne sont pas tous présents.

+ Note : ne téléchargez pas sur ftp-master de paquets concernant la cryptographie qui appartiendraient à contrib ou non-free. Ces logiciels doivent aller sur non-us (voir s'applique Envois de sécurité

N'envoyez PAS un paquet vers la file d'envoi de sécurité (oldstable-security, -stable-security, etc.) sans avoir au préalable l'autorisation de l'équipe de +stable-security, 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, il entraînera beaucoup de problèmes et de délais dans la gestion de cet envoi non désiré. Pour plus de détails, consultez la section . @@ -1990,6 +2055,9 @@ Dans tous les cas, vous recevrez un accus L'accusé de réception indique aussi la section dans laquelle le paquet a été installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier qui vous informera de cette différence (voir ci-dessous). +

+Notez que si vous envoyez via les files, le logiciel de démon de file + vous enverra également une notification par courriel. Spécifier la section, la sous-section et la priorité d'un paquet @@ -2032,15 +2100,14 @@ suivi des bogues" id="&url-bts;"> Debian. Il faut savoir comment remplir des rapports de bogue correctement (voir ), comment les mettre à jour et les réordonner et comment les traiter et les fermer.

-Les fonctionnalités du système de suivi des bogues qui intéressent les -développeurs sont décrites dans la . Ceci inclut la fermeture des bogues, l'envoi des messages de suivi, l'assignation des niveaux de gravité et des marques, l'indication que les bogues ont été envoyés au développeur amont et autres problèmes.

Des opérations comme réassigner des bogues à d'autres paquets, réunir des -rapports de bogues séparés traitant du même problème ou réouvrir des bogues +rapports de bogues séparés traitant du même problème ou rouvrir des bogues quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de courrier de contrôle. Toutes les commandes disponibles pour ce serveur sont décrites dans la . Les documentent les opérations techniques du BTS, telles que comment remplir, @@ -2126,7 +2193,7 @@ Voici une liste des régulièrement, vous devriez vous demander si la documentation est assez bonne ou si le programme ne devrait pas détecter une mauvaise utilisation pour donner un message d'erreur informatif. Il s'agit d'un - problème qui peut être présenté à l'auteur amont. + problème qui peut être discuté avec l'auteur amont.

Si le rapporteur de bogue n'est pas d'accord avec votre décision de fermeture du bogue, il peut le ré-ouvrir jusqu'à ce que vous trouviez un @@ -2144,9 +2211,10 @@ Voici une liste des 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 - &email-debian-devel; ou vous pouvez le réattribuer à - debian-policy pour les laisser décider dans quel - paquet est située l'erreur. + IRC 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é.

Parfois, vous devez également ajuster la gravité du bogue pour qu'elle corresponde à notre définition de gravité des bogues. C'est dû au @@ -2155,6 +2223,19 @@ Voici une liste des certains bogues peut même être rétrogradée en wishlist (souhait) quand le changement demandé est seulement d'ordre cosmétique. + + 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 + merge (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 unmerge (séparation), veuillez + consulter la documentation du serveur de contrôle du BTS. + Le rapporteur de bogue peut avoir oublié de fournir certaines informations. Dans ce cas, vous devez lui demander les informations @@ -2225,13 +2306,25 @@ lignes de changelogs de fermeture de bogues sont identifi /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig -Nous préfèrons la syntaxe closes: #XXX, car c'est l'entrée +Nous préférons la syntaxe closes: #XXX, car c'est l'entrée la plus concise et la plus facile à intégrer dans le texte du fichier changelog.

+Si un envoi est identifié comme une mise à jour indépendante +(NMU) (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é fixed (corrigé) au lieu +d'être fermé. Si un envoi de responsable a pour cible experimental, +l'étiquette fixed-in-experimental est alors ajoutée au bogue ; +pour les mises à jour indépendantes, l'étiquette fixed (corrigé) est +utilisée (il est attendu que la règle spéciale pour experimental sera +modifiée dès que le suivi des versions sera ajouté au système de suivi des +bogues). +

Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les entrées du fichier changelog, n'hésitez pas à annuler tout dommage - que l'erreur a entraîné. Pour réouvrir un bogue fermé par erreur, envoyez une + que l'erreur a entraîné. Pour rouvrir un bogue fermé par erreur, envoyez une commande reopen XXX à l'adresse de contrôle du système de suivi des bogues, &email-bts-control;. Pour fermer tous les bogues restants qui ont été corrigés par votre envoi, envoyez le fichier .changes à @@ -2430,7 +2523,7 @@ s

Dans certains cas, il n'est pas possible de rétroporter un correctif de sécurité, par exemple, quand de grandes quantités de code source doivent être -modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à +modifiées ou récrites. Si cela se produit, il peut être nécessaire de passer à une nouvelle version amont. Cependant, ceci n'est fait que dans des situations extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité au préalable. @@ -2481,12 +2574,6 @@ Assurez-vous de conserver les points suivants identifiant CVE n'a encore été assigné, l'équipe de sécurité en demandera un pour qu'il puisse être inclus dans le paquet et dans le changelog. - - Fournissez des entrées de changelog descriptives et complètes. D'autres - personnes se baseront dessus pour déterminer si un bogue particulier a été - corrigé. Quand cela est possible, incluez une référence externe, de - préférence, un identifiant CVE, pour qu'elle puisse être recoupée. - Assurez-vous que le numéro de version est correct. Il doit être plus élevé que celui du paquet actuel, mais moins que ceux des paquets des versions @@ -3023,9 +3110,9 @@ Dans certaines circonstances, il est n Cette section ne traite que des mises à jour indépendantes de source, c.-à-d., les mises à jour qui envoient une nouvelle version d'un paquet. Pour les mises à jour indépendantes par des porteurs ou des membres de la QA, - veuillez consulter . Pour les envois buildd (qui - sont également strictement parlant des NMU), veuillez consulter . + veuillez consulter . Si un buildd construit et + envoie un paquet, cela est également à strictement parler une NMU binaire. + Veuillez consulter pour plus d'informations.

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 autre @@ -3079,7 +3166,7 @@ suivant des Patientez quelques jours. Si vous n'avez toujours aucune réponse du responsable, envoyez-lui un courrier annonçant votre intention d'effectuer une mise à jour indépendante du paquet. Préparez la NMU comme - décrit dans , testez-la soigneusement sur votre + décrit dans cette section et testez-la soigneusement sur votre machine (cf. ). Re-vérifiez que votre correctif n'a aucun effet de bord inattendu. Assurez-vous que votre correctif est aussi minimaliste et non intrusif que possible. @@ -3112,7 +3199,7 @@ moyen habituel pour un paquet d'entrer dans testing est de passer par

Pour la distribution stable, veuillez y apporter une attention supplémentaire. Bien sûr, les responsables de version peuvent également modifier -les rêgles ici. Veuillez vérifier avant l'envoi que tous vos changements sont +les règles ici. Veuillez vérifier avant l'envoi que tous vos changements sont acceptables pour inclusion dans la prochaine version stable par le responsable de diffusion.

@@ -3246,7 +3333,10 @@ Si l'un de vos paquets a subi une mise les changements dans votre copie des sources. Ceci est aisé, vous avez simplement à appliquer le correctif qui vous a été envoyé. Une fois ceci fait, vous devez fermer les bogues qui ont été marqués comme fixés par la mise à - jour. Vous pouvez soit les fermer manuellement en envoyant les courriers + jour. Le moyen le plus simple est d'utiliser l'option -v de + dpkg-buildpackage car cela vous permet d'inclure tous les + changements depuis votre dernier envoi de responsable. Sinon, vous pouvez soit + les fermer manuellement en envoyant les courriers nécessaires au BTS soit ajouter les closes: #nnnn nécessaires dans l'entrée du changelog de votre prochain envoi.

@@ -3262,11 +3352,12 @@ Dans tous les cas, vous ne devriez pas

Sauf si vous savez que le responsable est toujours actif, il est sage de vérifier le paquet pour voir s'il n'a pas été abandonné. La liste actuelle des -paquets orphelins pour lesquel le champ responsable n'a pas été positionné +paquets orphelins pour lesquels le champ responsable n'a pas été positionné correctement est disponible à . Si vous effectuez une mise à jour indépendante sur un paquet incorrectement orphelin, veuillez positionner le responsable à « Debian QA Group -<packages@qa.debian.org> ». +<packages@qa.debian.org> ». Dans ce cas, les bogues du paquet sont +fermés et pas simplement marqués comme corrigés. Qui peut faire une mise à jour indépendante ?

@@ -3278,6 +3369,20 @@ Seuls les responsables Debian officiels peuvent faire des mises de suivi des bogues. Les responsables apprécient presque toujours les correctifs et les rapports de bogue soignés. + Comment dak détecte les mises à jour indépendantes +

+Le fait qu'un envoi soit traité par les scripts d'archive et par le +système de suivi des bogues (voir ) comme une mise +à jour indépendante ou comme un envoi par le responsable n'est +pas décidé en regardant le numéro de version (voir ). Au lieu de cela, un envoi est géré comme une mise à +jour indépendante si l'adresse du responsable dans le fichier +.changes n'est pas la même binairement que l'adresse du champ +Maintainer ou que l'une des adresses du champ Uploaders +du fichier dsc 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é). + Terminologie

Deux nouvelles expressions sont introduites dans cette section : @@ -3319,7 +3424,7 @@ Les mises (NMU

Non-maintainer upload). Pourtant, cela conduit souvent à des confusions car beaucoup associent « mise à jour indépendante » et « mise à jour indépendante source ». Il faut - donc rester vigilant. Il est préférable de toujours utiliser « mise à jour + donc rester vigilant : utilisez toujours « mise à jour indépendante binaire » ou «NMU binaire » pour les mises à jour indépendantes de binaires seuls. @@ -3361,7 +3466,7 @@ Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>

-La maintenance collaborative peut souvent être facilitée par l'utilisation +La maintenance collective peut souvent être facilitée par l'utilisation d'outils sur Alioth (voir ). @@ -3385,7 +3490,8 @@ une version candidate stable. Veuillez voir ci-dessous pour les d Mises à jour depuis unstable

Les scripts qui mettent à jour la distribution testing 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 britney. Ils fabriquent les fichiers Packages pour la distribution testing, mais ils le font d'une manière intelligente pour éviter toute incohérence et essayer de n'utiliser que des paquets sans bogue. @@ -3396,14 +3502,14 @@ suivantes : Le paquet doit avoir été disponible dans unstable depuis 2, 5 ou 10 jours selon le champ d'urgence de l'envoi (élevée, moyenne ou basse). -Veuillez noter que cette urgence est « collande » (« sticky »), ce qui -veut dire que l'envoi avec l'urgence la plus élevée depuis la dernière +Veuillez noter que cette urgence est « collante » (« sticky »), ce qui +veut dire que l'envoi avec l'urgence la plus élevée depuis la précédente transition dans testing est prise en compte. Ces délais peuvent être -doublés lors d'un gel de distribution, ou la transition dans testing -peut être complètement désactivée ; +doublés lors d'un gel de distribution, ou les transitions dans testing +peuvent être complètement désactivées ; Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la -version disponible dans testing ; +version actuellement disponible dans testing ; Il doit être disponible pour toutes les architectures pour lesquelles il a été auparavant construit. peut être @@ -3414,18 +3520,18 @@ disponible dans testing ; Les paquets dont il dépend doivent soit être déjà disponibles dans testing soit être acceptés dans testing au -même moment (et ils doivent respecter tous les critères nécessaires). +même moment (et ils doivent remplire tous les critères nécessaires).

Pour savoir si un paquet a progressé ou non dans testing, veuillez voir la sortie du script de testing sur la ou utilisez le programme grep-excuses -inclus dans le paquet devscripts. Si l'on veut rester -informé de la progression de ses paquets dans testing, on peut +inclus dans le paquet devscripts. Si vous voulez rester +informé de la progression de vos paquets dans testing, vous pouvez facilement le mettre dans la .

Le fichier update_excuses ne donne pas toujours la raison précise - pour laquelle un paquet est refusé, on peut avoir à la chercher soi-même en + pour laquelle un paquet est refusé ; on peut avoir à la chercher soi-même en regardant ce qui serait cassé avec l'inclusion du paquet. La donne plus d'informations à propos des problèmes courants qui peuvent occasionner cela. @@ -3435,13 +3541,14 @@ Parfois, certains paquets n'entrent jamais dans testing parce que le script. Voir ci-dessous pour des détails.

Des analyses de dépendances plus avancées sont présentées sur - – mais, attention, elles affichent + — mais, attention, cette page affiche également les dépendances de construction qui ne sont pas considérées par britney. Désynchronisation

+ Pour le script de migration dans testing, « désynchronisé » (outdated veut dire ceci : il y a différentes versions dans unstable pour les architectures de version (à l'exception des @@ -3487,9 +3594,9 @@ responsable de glibc ou

Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre paquet : ceci ne se produit que pour permettre à un autre paquet -d'entrer, ce dernier paquet doit être prêt pour tous les autres critères. -Considérons par exemple qu'un paquet a est en conflit avec la nouvelle version -de b  alors a peut être supprimé pour permettre l'entrée de b. +d'entrer, ce dernier doit être prêt pour tous les autres critères. +Considérons, par exemple, qu'un paquet a est en conflit avec la nouvelle version +de b  alors a peut être supprimé pour permettre l'entrée de b.

Bien sûr, il existe une autre raison pour supprimer un paquet de testing : le paquet est trop bogué (et avoir un seul bogue RC est @@ -3498,8 +3605,8 @@ suffisant pour Dépendances circulaires

-Une situation qui n'est pas très bien gérée par britney est si un paquet a -dépend de la nouvelle version d'un paquet b et vice versa. +Une situation qui n'est pas très bien gérée par britney est si un paquet a +dépend de la nouvelle version d'un paquet b et vice versa.

Voici un exemple :

@@ -3510,7 +3617,7 @@ a | 1; d b | 1; dépend: a=1 | 2; dépend: a=2

-Le paquet a n'est pas considéré pour la mise à jour, le paquet b non plus. +Aucun des paquets a et b ne sera considéré pour mise à jour.

Actuellement, ceci nécessite un coup de pouce manuel de l'équipe de diffusion. Veuillez les contacter en envoyant un courrier électronique à @@ -3548,12 +3655,12 @@ cette partie, 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 semblable pour les mises à jour binaires pures, mais cela n'est pas décrit ici. Si vous êtes intéressé par cela, -veuillez utiliser le code.) +veuillez étudier attentivement le code.)

Maintenant, la partie la plus complexe se produit : britney tente de mettre à jour testing 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 testing n'est pas moins +ensemble. Chaque tentative est acceptée si unstable n'est pas moins ininstallable 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 @@ -3581,22 +3688,43 @@ certains cas, il est n Souvenez-vous que les paquets envoyés là ne sont pas traités automatiquement, ils doivent passer entre les mains du responsable de distribution. Vous devez donc avoir une bonne raison pour les y envoyer. Pour savoir ce que -représente une bonne raison aux yeux du responsable de distribution, vous -devriez lire les instructions données qu'il envoie régulièrement sur +représente une bonne raison aux yeux des responsables de distribution, vous +devriez lire les instructions données qu'ils envoient régulièrement sur &email-debian-devel-announce;.

Vous ne devriez pas envoyer un paquet à testing-proposed-updates quand vous pouvez le mettre à jour par unstable. Si vous ne pouvez faire autrement (par exemple, parce que vous avez une nouvelle version de -développement dans unstable), vous pouvez l'utiliser, mais il est +développement dans unstable), vous pouvez utiliser cette facilité, mais il est recommandé de demander l'autorisation du responsable de distribution auparavant. Même si un paquet est gelé, des mises à jour par unstable sont possibles -si l'envoi dans unstable ne tire pas de nouvelle dépendance. +si l'envoi dans unstable ne tire pas de nouvelles dépendances.

Les numéros de version sont habituellement choisis en ajoutant le nom de -code de la distribution testing et un numéro d'incrémentation, comme +code de la distribution testing et un numéro incrémenté, comme 1.2sarge1 pour le premier envoi dans testing-proposed-updates du paquet en version 1.2. +

+Veuillez vous assurer que vous n'oubliez aucun des éléments suivants lors de +votre envoi : + + vérifiez que votre paquet doit vraiment aller dans +testing-proposed-updates et ne peut pas passer par +unstable ; + vérifiez que vous n'incluez que le minimum de changements ; + vérifiez que vous incluez une explication appropriée dans le +changelog ; + vérifiez que vous avez bien indiqué testing ou +testing-proposed-updates comme votre distribution cible ; + vérifiez que vous avez construit et testé votre paquet dans +testing et non dans unstable ; + vérifiez que votre numéro de version est plus élevé que les versions de +testing et de testing-proposed-updates et moins élevé que +celle de unstable ; + après l'envoi et la construction réussie sur toutes les plates-formes, +contactez l'équipe de diffusion à &email-debian-release; et demandez-leur +d'approuver votre envoi. + @@ -3616,12 +3744,16 @@ d' a des bogues bloquants, il n'ira pas dans testing et par conséquent, ne pourra pas être diffusé dans stable.

-Le compte des bogues de testing pour un paquet est considéré comme -étant à peu près le nombre de bogue lors du dernier pointage quand la version -testing a été égale à la version unstable. Les bogues marqués -woody ou sarge ne sont pas comptés. Cependant les bogues -marqués sid sont comptés. - +Le compte des bogues d'unstable est effectué avec tous les bogues +bloquants sans étiquette de version (comme potato, woody) ou +avec une étiquette sid et également s'ils ne sont ni corrigés ou +marqués avec sarge-ignore. +Le compte des bogues de testing pour un paquet est condiséré comme à +peu près le nombre de bogues d'unstable lors du dernier pointage quand +la version testing a été égale à la version unstable. +

+Cela changera après la sortie de Sarge dès que nous aurons des versions +dans le système de suivi des bogues. Comment est-ce que l'installation d'un paquet dans @@ -3700,7 +3832,7 @@ devrait Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous conformiez aux conventions attendues par le script d'aide, celui-ci prend soin de tous les détails. Les changements dans la charte peuvent alors être faits -dans le script d'aide, les paquets ont alors simplement besoin d'être +dans le script d'aide ; les paquets ont alors simplement besoin d'être reconstruits avec la nouvelle version du script et sans aucun changement supplémentaire.

@@ -3740,7 +3872,7 @@ disponibles Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si vous corrigez sans faire attention les bogues dans les sources, vous ne pourrez pas différencier facilement les nombreux correctifs que vous aurez - appliqués. Cela peut devenir trés compliqué de mettre à jour le paquet avec + appliqués. Cela peut devenir très compliqué de mettre à jour le paquet avec une nouvelle version amont qui intègre certains correctifs (mais pas tous). Vous ne pouvez pas prendre l'ensemble des correctifs (par exemple, dans les fichiers .diff.gz) et décider quels correctifs il vous faut @@ -3774,7 +3906,7 @@ Un simple paquet source va souvent permettre de construire plusieurs paquets binaires différents, que ce soit pour fournir plusieurs saveurs du même paquet (par exemple, le paquet source vim) 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).

Le second cas peut facilement être géré dans le fichier @@ -3786,7 +3918,7 @@ Le second cas peut facilement garantissant que vous avez bien défini les dépendances entre les paquets dans le fichier debian/control.

-Le premier cas est un peu plus diffile car il implique de multiples +Le premier cas est un peu plus difficile car il implique de multiples recompilations du même logiciel, mais avec différentes options de configuration. Le paquet source vim est un exemple de la façon de gérer cela avec un fichier rules écrit à la main. @@ -3919,16 +4051,16 @@ sp ispell -d american -g debian/control

-L'utilisateur s'attend habituellement à ce que les réponses aux questions -suivantes soient présentes dans la description du paquet. +Les utilisateurs s'attendent habituellement à ce que les réponses aux questions +suivantes soient présentes dans la description du paquet : Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre paquet, la -description courte du paquet dont il est un ajout devrait le spécifier. +description courte du paquet dont c'est un ajout devrait le spécifier. Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client de messagerie ; il -est cool, rapide, s'interface avec pgp, ldap et imap, a les fonctionnalités +est cool, rapide, s'interface avec PGP, LDAP et IMAP, a les fonctionnalités X, Y et Z). Si ce paquet ne devrait pas être installé directement, mais être tiré par un @@ -3940,9 +4072,11 @@ cela devrait En quoi le paquet est différent des paquets concurrents ? Est-ce que c'est une meilleure implémentation ? A-t-il plus de fonctionnalités, des -fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet (2. -devrait parler de la classe des paquets et ceci à propos de ce paquet -particulier, si vous avez des informations liés au deux). +fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet ? + @@ -4001,7 +4135,7 @@ comportement du programme. Pour plus d'explications, utilisez le fichier README.Debian.

Utilisez un langage anglais commun pour que la majorité des lecteur puissent le -comprendre. Évitez les abbréviations, le parler technique et le jargon quand +comprendre. Évitez les abréviations, le parler technique et le jargon quand vous expliquez des changements fermant un bogue, spécialement pour les rapports de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement à l'aise techniquement. Vous devez être poli et ne pas jurer. @@ -4148,7 +4282,7 @@ cron (3.0pl1-74) unstable; urgency=low functionality provided with that script, please install the new package. - -- Steve Greenland <stevegr&debian.org> Sat, 6 Sep 2003 17:15:03 -0500 + -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500

Le fichier NEWS.Debian est installé comme @@ -4200,7 +4334,7 @@ cas, l'affichage ne doit se faire que dans l' Gardez les scripts de maintenance aussi simples que possible. Nous vous suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous avez besoin d'une fonctionnalité de Bash, le script de maintenance doit -l'indiquer dans sa première ligne. Un shell POSIX ou Bash sont préférés à +préciser bash dans sa première ligne. Un shell POSIX ou Bash sont préférés à Perl car ils permettent à debhelper d'ajouter facilement des parties aux scripts.

@@ -4214,7 +4348,7 @@ Si vous avez besoin de v utiliser quelque chose comme : if [ -x /usr/sbin/install-docs ]; then ... -Si vous ne désirez pas mettre en dur le chemin de la commande dans le script de +Si vous ne désirez pas mettre en dur le chemin d'une commande dans le script de maintenance, la fonction de shell suivante conforme à POSIX peut vous aider : @@ -4251,8 +4385,344 @@ pr Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs communes sont référencées dans la page de manuel . Vous devriez vraiment lire cette page si vous décidez - d'utiliser debconf. - + d'utiliser debconf. Nous documentons également plusieurs des meilleures + pratiques ici. +

+Ces lignes directives incluent plusieurs recommandations de style d'écriture et +de typographie, des considérations générales à propos de l'utilisation de +debconf ainsi que des recommandations plus spécifiques pour certaines parties de +la distribution (par exemple, le système d'installation). + + N'abusez pas de debconf +

+Depuis que debconf est apparu dans Debian, il a été largement abusé et plusieurs +critiques reçues par la distribution Debian proviennent d'utilisation abusive de +debconf avec la nécessité de répondre à un grand nombre de questions avant +d'avoir n'importe quel petit logiciel d'installé. +

+Garder les notes d'utilisation à leur place : le fichier NEWS.Debian ou le +fichier README.Debian. N'utilisez des notes que pour des notes importantes +qui peuvent directement concerner l'utilisation du paquet. Rappelez-vous que les +notes bloqueront toujours l'installation avant leur confirmation ou qu'elles +embêtent l'utilisateur par un courriel. +

+Choisissez avec soin les priorités des questions dans les scripts de +responsable. Reportez-vous à pour plus +de détails sur les priorités. La plupart des questions devraient utiliser un +priorité moyenne ou basse. + + Recommandations générales pour les auteurs et traducteurs +

+ Écrivez un anglais correct +

+La plupart des responsables de paquets Debian n'ont pas l'anglais comme langue +maternelle. Écrire des modèles correctement rédigés peut donc ne pas être facile +pour eux. +

+Veuillez utiliser (et abuser de) la liste de discussions +debian-l10n-english@lists.debian.org. Faites relire vos questionnaires. +

+Des questionnaires écrits incorrectement donnent une pauvre image de votre paquet, +de votre travail... ou même de Debian elle-même. +

+É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 +simplicité. + + Être courtois avec les traducteurs +

+Les questionnaires debconf peuvent être traduits. Debconf, avec son paquet-frêre +po-debconf, offre un cadre de travail simple pour obtenir des questionnaires +traduits par les équipes de traduction ou même par des individus isolés. +

+Veuillez utiliser les questionnaires basés sur gettext. Installez po-debconf sur +votre système de développement et lisez sa documentation (« man +po-debconf » est un bon début). +

+Évitez de changer vos questionnaires trop souvent. Modifier le texte des +questionnaires entraîne plus de travail pour les traducteurs dont les +traductions seront rendues « floues » (« fuzzy »). Si vous +prévoyez des modifications dans vos questionnaires d'origine, veuillez contacter +les traducteurs. La plupart des traducteurs actifs sont très réactifs et obtenir +leur travail inclus avec vos questionnaires modifiés vous économisera des envois +supplémentaires. Si vous utilisez des modèles basés sur gettext, le nom et +l'adresse électronique du traducteur sont mentionnés dans les en-têtes des +fichiers PO. +

+En cas de doutes, vous pouvez également contacter l'équipe de traduction pour +une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de discussions +debian-i18n@lists.debian.org. + + Ne faites pas de suppositions à propos des interfaces +

+Le texte des modèles ne doit pas faire référence aux composants appartenant à +l'une des interfaces debconf. Des phrases comme « If you answer +Yes... » n'a aucun sens pour les utilisateurs d'interfaces graphiques qui +utilisent des cases à cocher pour les questions booléennes. +

+Plus généralement, essayez d'éviter de vous référer à toute action de +l'utilisation. Donnez simplement des faits. + + N'utilisez pas la première personne +

+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 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 +papier scientifique. + + Soyez neutre dans le genre +

+Le monde est fait d'hommes et de femmes. Veuillez utiliser des constructions +neutres dans le genre dans votre texte. Ce n'est pas du politiquement correct, +c'est simplement montrer du respect pour toute l'humanité. + + + Définition des champs de questionnaires +

+Cette partie donne plusieurs informations qui sont principalement extraites de +la page de manuel . + + Type +

+ + string: (chaîne de caractères) +

+Résulte en un champ d'entrée libre dans lequel l'utilisateur peut écrire toute chaîne. + + password: (mot de passe) +

+Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ avec +précaution ; soyez conscient que le mot de passe que l'utilisateur entre +sera écrit dans la base de données debconf. Vous devriez probablement enlever +cette valeur de la base de données dès que possible. + + boolean: (booléen) +

+Un choix vrai/faux. Rappelez-vous : vrai/faux, PAS OUI/NON... + + select: (sélection) +

+Un choix parmi un certain nombre de valeurs. Les choix doivent être spécifiés +dans un champ nommé « Choices ». Séparez les valeurs possibles par des +virgules et des espaces ainsi : Choices: yes, no, maybe + + multiselect: (sélection multiple) +

+Comme le type de données select, excepté que l'utilisateur peut choisir un +nombre quelconque d'éléments dans la liste de choix (ou aucun d'entre eux). + + note: (note) +

+Plutôt que d'être une question en tant que telle, ce type de donnée indiqué une +note qui peut être affichée à l'utilisateur. Il ne devrait être utilisé que +pour des données importantes que l'utilisateur doit réellement voir, car debconf +fera tout ce qu'il peut pour s'assurer que l'utilisateur le voit ; il +stoppera l'installation en attendant que l'utilisateur appuie sur une touche ou +il leur enverra même la note par courrier dans certains cas. + + text: (texte) +

+Ce type est maintenant considéré comme obsolète : ne l'utilisez pas. + + error: (erreur) +

+CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR DEBCONF. +

+Il a été ajouté à cdebconf, la version C de debconf, utilisé en premier dans +l'installateur Debian. +

+Veuillez ne pas l'utiliser à moins que debconf ne le prennent en charge. +

+Ce type est conçu pour gérer des messages d'erreur. Il est presque semblable au +type « note ». Des interfaces peuvent le présenter différemment (par +exemple, l'interface dialog de cdebconf affiche un écran rouge au lieu de +l'écran bleu habituel). + + + Description: description courte et étendue +

+Les descriptions des modèles sont composées de deux parties : une courte et +une étendue. La description courte est dans la ligne « Description: » +du questionnaire. +

+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. +

+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 +la demande explicitement ou même ne l'affichent pas du tout. Évitez des choses +comme « What do you want to do ? ». +

+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 ». +

+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 importante. Si, après tout cela, +vous ne trouvez toujours rien, laissez-la vide. +

+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 paragraphe, mais utilisez plutôt un autre paragraphe. +

+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. +

+Pour des règles spécifiques selon le type de questionnaire (chaîne de +caractères, booléen, etc.), veuillez lire ci-dessous. + + Choices (choix) +

+Ce champ devrait utilisé pour des types Select et Multiselect. Il contient les +choix possibles qui seront présentés aux utilisateurs. Ces choix devraient être +séparés par des virgules. + + + Default (valeur par défaut) +

+Ce champ est facultatif. Il contient la réponse par défaut pour les modèles +chaîne de caractères, sélection et multi-sélection. Pour des questionnaires +multi-sélection, il peut contenir une liste de choix séparés par des virgules. + + Guide de style spécifique par champ de questionnaires +

+ + Champ Type +

+Aucune indication spécifique excepté : utilisez le type approprié en vous +référant à la section précédente. + + Champ Description +

+Voici ci-dessous des instructions spécifiques pour écrire correctement la +description (courte et étendue) selon le type de questionnaire. + + questionnaire chaîne de caractères/mot de passe +

+ + 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 étendue est un complément à la description courte. Dans la + 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é. + + + modèles booléens +

+ + 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 + 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) + + La description étendue ne devrait PAS inclure de question. + + À nouveau, veuillez éviter de vous référer à des composants d'interface + spécifiques. Une erreur courante pour de telles questionnaires est les + constructions du type « if you answer Yes ». + + + sélection/multi-sélection +

+ + 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 étendue devra compléter la description courte. Elle peut se + référer aux choix disponibles. Elle peut également mentionner que + l'utilisateur peut choisir plus d'un des choix disponibles si le + questionnaire est du type sélection multiple (bien que l'interface rende + soivent cela clair). + + + Notes +

+ + La description courte devrait être considéré comme un *titre*. + + La description étendue est ce qui sera affiché comme une description plus + détaillée de la note. Faites de phrases, n'utilisez pas un style d'écriture + trop concis. + + N'ABUSEZ PAS DE DEBCONF. 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 fichiers NEWS.Debian + ou README.Debian sont les endroits appropriés pour un grand nombre de notes. + Si, en lisant ceci, vous envisagez de convertir vos modèles de type note en + entrées dans NEWS/Debian ou README.Debian, veuillez considérer de conserver + les traductions existantes pour une utilisation future. + + + + Champ de choix +

+S'il est probable que les choix changent souvent, veuillez considérer +l'utilisation de l'astuce « __Choices ». Cela séparera chaque choix +individuel en une chaîne de caractères seule, ce qui aidera considérablement les +traducteurs à faire leur travail. + + Champ par défaut +

+S'il est probable que la valeur par défaut d'un modèle « select » +change selon la langue de l'utilisateur (par exemple, s'il s'agit d'un choix de +langue), veuillez utiliser l'astuce « _DefaultChoice ». +

+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 sera utilisé pour +l'anglais. +

+Un exemple tiré des modèles du paquet geneweb : + +Template: geneweb/lang +Type: select +__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv) +# This is the default choice. Translators may put their own language here +# instead of the default. +# WARNING : you MUST use the ENGLISH FORM of your language +# For instance, the french translator will need to put "French (fr)" here. +_DefaultChoice: English (en)[ translators, please see comment in PO files] +_Description: Geneweb default language: + +

+Notez l'utilisation de crochets qui permettent des commentaires internes dans +les champs debconf. Notez également l'utilisation de commentaires qui +apparaîtront dans les fichiers sur lesquels travailleront les traducteurs. +

+Les commentaires sont nécessaires car l'astuce DefaultChoice est un peu +déroutante : les traducteurs peuvent y placer leur propre choix. + + Champ par défaut +

+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. +

+Si vous utilisez po-debconf (et vous DEVRIEZ le faire, voir 2.2), veuillez +considérer de rendre ce champ traduisible, si vous pensez qu'il peut être +traduit. +

+Si la valeur par défaut peut varier selon la langue ou le pays (par exemple, la +valeur par défaut pour un choix de langue), veuillez considérer l'utilisation du +type spécial « _DefaultChoice » documenté dans ). + @@ -4275,7 +4745,7 @@ traductions des questionnaires debconf debconf-mergetemplate. Cependant, cette technique est maintenant déconseillée ; la meilleure façon pour l'internationalisation de debconf est d'utiliser le paquet -po-debconf. Cette méthode est plus facile et pour le +po-debconf. Cette méthode est plus facile pour le responsable et pour les traducteurs ; des scripts de transition sont fournis.

@@ -4414,6 +4884,7 @@ Plusieurs types sp Les paquets Lisp devraient s'enregistrer avec le paquet common-lisp-controller pour lequel vous pouvez vous reporter au fichier &file-lisp-controller;. + @@ -4467,13 +4938,13 @@ LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date Rendre les paquets de transition conformes avec deborphan

-Deborphan est un programme qui aide les utilisateurs à détecter quels paquets +Deborphan est un programme pour aider les utilisateurs à détecter 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 tente d'attraper d'autres paquets inutiles.

-Par exemple, avec --guess-dummy, il cherche tous les paquets de transition qui +Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de transition qui étaient nécessaires pour une mise à jour, mais qui peuvent sans problème être supprimés. Pour cela, il recherche la chaîne de caractères « dummy » ou « transitional » dans la description courte. @@ -4484,6 +4955,206 @@ description courte. Si vous cherchez des exemples, ex apt-cache search .|grep transitional. + + Les meilleures pratiques pour les fichiers orig.tar.gz +

+Il existe deux types d'archives tar (« tarball ») source +d'origine : les sources vierges et les sources amont réempaquetées. +

+ + Sources vierges +

+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. + +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 actuellement à tout moment. +La seule chose à laquelle on peut s'attendre est que c'est identique à +quelque chose que l'amont a 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. + +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. +

+

+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 +dpkg-source est cependant capable de traiter la plupart des +archives tar comme source vierge. Sa stratégie est équivalente à la +suivante : +

+

+ + +Il décompacte l'archive tar dans un répertoire temporaire vide par + + +zcat path/to/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf - + + + +Si, après cela, le répertoire temporaire ne contient qu'un +répertoire et pas d'autres fichiers, dpkg-source renomme ce +répertoire en +<packagename>-<version-amont>(.orig). Le nom du +répertoire de premier niveau dans l'archive tar n'a pas d'importance et +est oublié. + + +Sinon, l'archive tar a du être empaqueté sans répertoire de premier +niveau commun (honte à l'auteur amont !). Dans ce cas, +dpkg-source renomme le répertoire temporaire +lui-même en +<packagename>-<version-amont>(.orig). + + +

+ + + Réempaquetage des sources amonts +

+Vous devriez 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. +

+

+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 .diff.gz séparé et il a +toujours un numéro de version composé de <source-amont> +et de <debian-revision>. +

+

+Il peut y avoir des cas où il est désirable de réempaqueter le source +même si l'amont distribue un fichier .tar.gz qui pourrait en +principe être utilisé dans sa forme vierge. Le plus évident est si des +économies d'espaces significatives 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. +

+

+Un .orig.tar.gz réempaqueté : +

+

+ + +

+doit 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 README.Debian-source ou un +fichier similaire. Ce fichier devrait être dans la partie +diff.gz du paquet source Debian, habituellement dans le +répertoire debian, pas dans le +orig.tar.gz réempaqueté. C'est également une bonne idée de +fournir une cible get-orig-source dans votre fichier +debian/rules qui répète le processus, comme décrit dans la +Charte, . +

+ + +ne devrait pas contenir de fichiers qui ne viennent pas de +l'auteur amont ou dont vous avez changé le contenu. + +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. + + + +

+devrait, 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. +

+

+(Explication : 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). +

 + +devrait utiliser +<nom-du-paquet>-<version-amont>.orig 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. + + +devrait être gzipé avec une compression maximale. + + +

+

+La façon canonique de réaliser les deux derniers points est de laisser +dpkg-source -b construire l'archive tar réempaquetée à partir +du répertoire décompacté. +

+ + + Changer des fichiers binaires dans le diff.gz +

+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, +dpkg-source 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 orig.tar.gz +réempaqueté. Au lieu de cela, incluez le fichier dans le répertoire +debian dans un format uuencode (ou semblable) + +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. +. +Le fichier sera ensuite décodé et copié à son emplacement pendant +l'étape de construction. Le changement sera donc visible assez facilement. +

+

+Certains paquets utilisent dbs pour gérer les correctifs à +leur source amont et créent toujours un nouveau fichier +orig.tar.gz contenant le vrai orig.tar.gz 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 orig.tar.gz nouvellement créé à +côté du vrai et copiez les au bon endroit pendant l'étape de +construction. +

+ + + + @@ -4528,7 +5199,7 @@ name="querybts" section="1"> peuvent reportbug invoquera également habituellement querybts avant l'envoi).

-Essayer d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue +Essayez d'envoyer vos bogues au bon emplacement. Quand, par exemple, votre bogue concerne un paquet qui réécrit des fichiers d'un autre paquet, vérifiez les listes des bogues pour les deux paquets pour éviter de créer des rapports de bogues dupliqués. @@ -4546,8 +5217,8 @@ De temps en temps, vous pourrez vouloir v rapportés, vous avez simplement besoin d'aller à http://&bugs-host;/from:<votre-adresse-de-courrier>. - Ouvrir un grand nombre de rapports d'un seul - coup + Ouvrir un grand nombre de rapports en + une seule fois (« mass bug filing »)

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. @@ -4556,7 +5227,8 @@ Ouvrir un grand nombre de rapports pour le m paquet lintian pour générer une erreur ou un avertissement.

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. @@ -4608,14 +5280,14 @@ Les personnes qui participent mises à jour indépendantes, ils peuvent en faire une sans avertissement préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans DELAYED/3-day. Toutes les autres règles de mise à jour indépendante - s'appliquent comme d'habitude, ils devraient envoyer le correctif de la + s'appliquent comme d'habitude ; ils devraient envoyer le correctif de la mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également - respecter les souhaits du responsable s'il en a exprimés. + respecter tout souhait du responsable s'il en a exprimé.

-Si une personne ne se sent pas à l'aise avec une mise à jour indépendante, elle - devrait simplement envoyer un correctif au BTS. C'est de loin meilleur qu'une - mise à jour défectueuse. +Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante, envoyez + simplement un correctif au BTS. C'est de loin meilleur qu'une mise à jour + défectueuse. Contacter d'autres responsables

@@ -4636,6 +5308,7 @@ Vous pouvez paquet de source donné par le . Vous pouvez le faire en utilisant l'adresse <nom-paquet>@&pts-host;. + Gérer les responsables non joignables

@@ -4646,7 +5319,7 @@ Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer ait simplement besoin d'un rappel.

Il y a un système simple (la base de données MIA) dans laquelle les informations -sur les responsables supposés (deemed ?) inactifs sont enregistrées. Quand un +sur les responsables supposés Absents En Exercice (« Missing In Action) sont enregistrées. Quand un membre du groupe 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 @@ -4656,7 +5329,7 @@ conna utilise comme correspondance de noms d'utilisateur. mia-history --help affiche quels paramètres sont acceptés. 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 devez utiliser la procédure +que vous voulez ajouter plus d'informations, vous deviez utiliser la procédure suivante.

La première étape est de contacter poliment le responsable et d'attendre une @@ -4674,8 +5347,8 @@ informations utiles sur ce responsable. Ceci inclut : Les informations « echelon » disponibles dans la , qui indiquent quand le développeur a envoyé un - message pour la dernière fois sur une liste de diffusion Debian. - (Ceci inclut les envois via les listes debian-*-changes.) + message pour la dernière fois sur une liste de diffusion Debian + (cela inclut les envois via les listes debian-*-changes). Rappelez-vous également de vérifier si le responsable est indiqué comme en vacances dans la base de données. @@ -4685,7 +5358,7 @@ informations utiles sur ce responsable. Ceci inclut : 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 paquets ont subi des mises à jour indépendantes et si oui, par - qui ? + qui. Est-ce que le responsable est actif en dehors de Debian ? Par exemple, il peut avoir envoyé des messages récemment à des @@ -4714,7 +5387,7 @@ Un dernier mot : veuillez vous souvenir d' volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian. Vous n'êtes pas non plus au courant des circonstances de la personne impliquée. Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté -— vous ne savez pas qui recevra vos courriers — imaginez comme un +— vous ne savez pas qui recevra vos courriers. Imaginez comme un proche se sentira s'il lit un courrier pour la personne décédée et trouve un message très impoli, en colère et accusateur !)

@@ -4738,9 +5411,11 @@ Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est pas encore autorisé à le faire lui-même, un candidat nouveau responsable. Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.

+ 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 @@ -4824,13 +5499,13 @@ name="introduction (internationalisation) veut dire la modification d'un logiciel ou de technologies liées pour qu'un logiciel puisse potentiellement gérer des langues multiples, des conventions multiples et ainsi de suite dans le monde -entier » alors que "L10N (localisation) veut dire l'implémentation dans +entier » alors que « L10N (localisation) veut dire l'implémentation dans une langue spécifique pour un logiciel déjà internationalisé ».

-La l10n et l'i18n sont liées, mais les difficultés liées à chacune sont très +La l10n et l'i18n sont interconnectées, mais les difficultés liées à chacune sont très différentes. Il n'est pas vraiment difficile de permettre à un programme de changer la langue dans laquelle sont affichés les textes selon les paramètres de -l'utilisateur, mais il est très couteux en temps de traduire réellement ces +l'utilisateur, mais il est très coûteux en temps de traduire réellement ces messages. D'un autre côté, définir le codage des caractères est trivial, mais adapter le code pour utiliser des codages de caractères différents est un problème vraiment difficile. @@ -4849,24 +5524,24 @@ t 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 -, le ou . La seule ressource centralisée dans Debian est les où vous pouvez trouvez des statistiques sur les + centralisées"> où vous pouvez trouver des statistiques sur les fichiers de traduction trouvés dans les paquets, mais il n'y a aucune infrastructure pour faciliter le processus de traduction.

-Un effort pour traduire les descriptions de paquet a démarré il y a longtemps +Un effort pour traduire les descriptions de paquet a démarré il y a longtemps, même si les outils fournissent très peu de prise en charge pour les utiliser -vraiement (i.e. seul APT peut les utiliser quand il est configuré -convenablement). Il n'y a rien à faire de la part des responsables et les -traducteurs devraient utiliser le . +vraiment (i.e., seul APT peut les utiliser quand il est configuré +convenablement). Les responsables n'ont rien à faire de particulier pour gérer +les traductions des descriptions de paquets ; les traducteurs devraient +utiliser le .

-Pour les questionnaires debconf, le responsable devrait utiliser le paquet +Pour les questionnaires debconf, les responsable devraient utiliser le paquet po-debconf pour faciliter le travail des traducteurs, qui peuvent utiliser le DDTP pour faire leur travail (mais les équipes française et brésilienne ne le font pas). On peut trouver certaines statistiques à la fois sur le site du @@ -4879,14 +5554,18 @@ statistiques sont disponibles sur le site des statistiques de traduction Debian centralisées.

Pour la documentation générale à propos de Debian, le processus est plus ou -moins le même que pour les pages web (les traducteurs ont un accès au CVS), mais +moins le même que pour les pages web (les traducteurs ont accès au CVS), mais il n'y a pas de page de statistiques.

-Pour la documentation spécifique des paquets (pages de manuel, document info, -autres formats), presque tout est encore à faire. Le plus notable, le projet KDE -gère la traduction de ses documentations de la même façon que ses messages de -programme. Les pages de manuel spécifiques Debian sont gérées dans un . +Pour la documentation spécifique aux paquets (pages de manuel, documents info, +autres formats), presque tout est encore à faire. +

+Le plus notablement, le projet KDE gère la traduction de ses documentations de la +même façon que ses messages de programme. +

+Il existe un effort pour gérer les pages de manuel spécifiques Debian au sein +d'un . FAQ I18N & L10N pour les responsables

@@ -4897,25 +5576,25 @@ Si vous avez une meilleure id désaccord avec certains points, vous êtes libre de fournir vos impressions pour que ce document puisse être amélioré. - Comment faire en sorte qu'un texte soit traduit ? + Comment faire en sorte qu'un texte soit traduit

-Pour traduire une description de paquet ou un questionnaire debconf, nous n'avez +Pour traduire des descriptions de paquet ou des questionnaires debconf, vous n'avez rien à faire, l'infrastructure du DDTP répartira le matériel à traduire aux volontaires sans besoin d'interaction de votre part.

Pour tous les autres matériels (fichiers gettext, pages de manuel ou autre documentation), la meilleure solution est de placer votre texte quelque part sur -l'Internet et de demander sur debian-i18n pour une traductions dans différentes +l'Internet et de demander sur debian-i18n la traduction dans différentes langues. Certains membres des équipes de traduction sont abonnés à cette liste et ils prendront soin de la traduction et du processus de relecture. Une fois -ceci fait, vous recevrez de leur part votre document traduit dans votre boîte à -lettre. +qu'ils ont fini, vous recevrez de leur part votre document traduit dans votre +boîte aux lettres. Comment faire en sorte qu'une traduction - donnée soit relue ? + donnée soit relue

De temps en temps, des personnes indépendantes traduiront certains textes -inclus dans votre paquet et vous demanderont de les inclure dans le paquet. +inclus dans votre paquet et vous demanderont d'inclure la traduction dans le paquet. Cela peut devenir problématique si vous n'êtes pas familier avec la langue donnée. C'est une bonne idée d'envoyer le document à la liste de diffusion l10n correspondante en demandant une relecture. Une fois celle-ci faite, vous devriez @@ -4923,13 +5602,13 @@ avoir plus confiance dans la qualit dans votre paquet. Comment faire en sorte qu'une traduction - donnée soit mise à jour ? + donnée soit mise à jour

-Si vous avez certaines traductions d'un texte donné qui trainent (?), chaque fois -que vous mettez à jour l'original, vous devriez gentiment demander au précédent -traducteur de mettre à jour sa traduction avec le texte original. Gardez à -l'esprit que cette tâche demande du temps, au moins une semaine pour obtenir une -mise à jour relue. +Si vous avez certaines traductions d'un texte donné qui traînent, chaque fois +que vous mettez à jour l'original, vous devriez demander au précédent +traducteur de mettre à jour sa traduction avec vos nouveaux changements. Gardez à +l'esprit que cette tâche demande du temps ; au moins une semaine pour +obtenir une mise à jour relue.

Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur la liste de diffusion correspondante. Si tout échoue, n'oubliez pas de mettre un @@ -4941,12 +5620,13 @@ vieux document est souvent mieux que pas de documentation du tout pour les personnes non anglophones. Comment gérer un rapport de bogue concernant - une traduction ? + une traduction

La meilleure solution peut être de marquer le bogue comme « suivi au développeur amont » (forwarded to upstream) et de faire suivre le bogue à la fois au précédent traducteur et à son équipe (en utilisant la liste de diffusion debian-l10n-XXX correspondante). + FAQ I18N & L10N pour les traducteurs

@@ -4954,7 +5634,7 @@ Lorsque vous lirez cela, gardez procédure générale dans Debian concernant ces points et que, dans tous les cas, vous devriez collaborer avec votre équipe et les responsables des paquets. - Comment aider l'effort de traduction ? + Comment aider l'effort de traduction

Choisissez ce que vous désirez traduire, assurez-vous que personne ne travaille déjà dessus (en utilisant votre liste de diffusion debian-l10n-XXX), @@ -4963,7 +5643,7 @@ langue maternelle sur votre liste de diffusion l10n et fournissez-le au responsable du paquet (voir le point suivant). Comment fournir une traduction pour - inclusion dans un paquet ? + inclusion dans un paquet

Assurez-vous que votre traduction est correcte (en demandant une relecture sur votre liste de discussion l10n) avant de la fournir pour inclusion. Cela @@ -4979,7 +5659,7 @@ traduction n'emp

-En tant que responsable, n'éditez jamais les traductions en aucune façon (même +En tant que responsable, ne modifiez jamais les traductions en aucune façon (même pour reformater l'affichage) sans demander à la liste de diffusion l10n correspondante. Vous risquez, par exemple, de casser le codage du fichier en agissant ainsi. De plus, ce que vous considérez comme une erreur peut être @@ -4992,8 +5672,8 @@ trouvent, personne ne le fera. Dans tous les cas, rappelez-vous que le problème principal avec la l10n est qu'elle demande la coopération de plusieurs personnes et qu'il est très facile -de démarrer une guerre incendiaire à propos de petits problèmes dûs à une -incompréhension. Donc, si vous avez des problèmes avec votre interlocuteur, +de démarrer une guerre incendiaire à propos de petits problèmes dûs à des +incompréhensions. Donc, si vous avez des problèmes avec votre interlocuteur, demandez de l'aide sur la liste de diffusion l10n correspondante, sur debian-i18n ou même sur debian-devel (attention, cependant, les discussions sur la l10n tournent très souvent à l'incendie sur cette liste :) @@ -5009,8 +5689,8 @@ Cette section contient un aper Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide des outils les plus utilisés.

-Les outils du responsable Debian sont destinés à améliorer le confort des - responsables et libérer leur temps des tâches plus cruciales. Comme le dit +Les outils du responsable Debian sont destinés à aider les + responsables et libérer leur temps pour des tâches plus cruciales. Comme le dit Larry Wall, il y a plus d'une manière de le faire.

Certaines personnes préfèrent utiliser des outils de haut niveau, d'autres pas. @@ -5040,7 +5720,7 @@ Le paquet dpkg-dev contient les outils (y compris dpkg-source) nécessaires pour déballer, fabriquer et livrer des paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas niveau indispensables pour créer et manipuler les paquets ; en tant que - tels, ils sont indispensables à tout responsable Debian. + tels, ils sont essentiels à tout responsable Debian. debconf @@ -5089,7 +5769,7 @@ charte dans leurs paquets

Vous devriez récupérer la dernière version de lintian depuis unstable régulièrement et vérifier tous vos paquets. Notez que - l'option -i donne des explications détaillées sur la signication de + l'option -i donne des explications détaillées sur la signification de chaque erreur, la partie concernée dans la charte et le moyen habituel de régler le problème.

@@ -5098,14 +5778,14 @@ comment et quand utiliser Lintian.

Vous pouvez aussi obtenir un résumé de tous les problèmes reportés par Lintian sur vos paquets à . Ces rapports contiennent la sortie - de la dernière version de lintian sur l'ensemble de la + de la dernière version de lintian pour l'ensemble de la distribution de développement (unstable). linda

-linda est un autre vérificateur de paquet. Il est sembable à +linda est un autre vérificateur de paquet. Il est semblable à lintian, mais il a un ensemble de tests différents. Il est écrit en Python plutôt qu'en Perl.

@@ -5117,7 +5797,7 @@ en Python plut debdiff (du paquet 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.

@@ -5150,14 +5830,14 @@ ils peuvent

Le paquet debhelper regroupe un ensemble de programmes qui peuvent être utilisés dans debian/rules pour automatiser les - tâches courantes relatives à la fabrication des paquets Debian binaires. Ce - paquet contient des utilitaires pour installer différents fichiers, les - compresser, ajuster leurs droits et intégrer votre paquet dans le système de - menu Debian. -

-À la différence des autres approches, debhelper est divisé en - plusieurs petits utilitaires qui agissent de manière cohérente. Ce découpage - permet un contrôle des opérations plus fin que d'autres « outils + tâches courantes relatives à la fabrication des paquets Debian binaires. + debhelper inclut des programmes pour installer différents + fichiers, les compresser, ajuster leurs droits et intégrer votre paquet dans le + système de menu Debian. +

+À la différence d'autres approches, debhelper est divisé en + plusieurs petits utilitaires simples qui agissent de manière cohérente. Ce découpage + permet un contrôle des opérations plus fin que certains des autres « outils debian/rules ».

Il existe aussi un certain nombre de petites extensions @@ -5252,13 +5932,13 @@ Ce paquet fournit l'infrastructure facilitant l'utilisation de CVS pour le debootstrap

Le paquet debootstrap vous permet d'amorcer un système Debian - de base à n'importe quel endroit dans votre système de fichier. Par + de base à n'importe quel endroit dans votre système de fichiers. Par « système de base », nous entendons le strict minimum nécessaire pour fonctionner et installer le reste du système.

Avoir un système comme celui-ci peut vous servir de différentes manières. Vous pouvez, par exemple, déplacer votre racine dans ce système avec - chroot pour tester vos dépendances de fabrication. Vous pouvez + chroot pour tester vos dépendances de construction. Vous pouvez aussi l'utiliser pour voir comment se comporte votre paquet quand il est installé dans un environnement minimum. @@ -5270,7 +5950,11 @@ Avoir un syst compile des paquets dans ce système. Ceci est très utile pour vérifier que les dépendances de compilation de votre paquet sont correctes et pour vous assurer qu'aucune dépendance de construction inutile ou incorrecte n'existe dans le - paquet résultant. + paquet résultant. +

+Un paquet lié est pbuilder-uml, qui va même plus loin en +réalisant la construction au sein d'un environnement « User Mode Linux ».

+ sbuild @@ -5324,8 +6008,8 @@ aide

Les outils suivants aident à automatiser les différentes tâches de maintenance par l'ajout des entrées de changelog ou de lignes de signatures, par la -recherche de bogues à partir d'Emacs ou par l'utilisation du plus récent fichier -officiel config.sub.

+recherche de bogues à partir d'Emacs et par l'utilisation du fichier officiel +config.sub le plus récent.

@@ -5350,7 +6034,7 @@ V autotools-dev

-Contient les meilleurs pratiques pour des personnes assurant la maintenance de +autotools-dev contient les meilleurs pratiques pour des personnes assurant la maintenance de paquets qui utilisent autoconf et/ou automake. Contient également des fichiers canoniques config.sub et config.guess qui sont connus pour fonctionner avec tous les @@ -5363,11 +6047,11 @@ portages Debian.

dpkg-repack crée un paquet Debian à partir d'un paquet qui a déjà été installé. Si des changements ont été effectués sur le paquet quand il a été décompacté (par exemple, des fichiers dans /etc ont été -modifés), le nouveau paquet héritera de ces changements.

+modifiés), le nouveau paquet héritera de ces changements.

Cet utilitaire peut faciliter la copie de paquet d'un ordinateur vers un autre ou la re-création de paquets installés sur un système, mais qui ne sont plus -disponibles ailleurs ou pour stocker l'état actuel d'un paquet avant de le +disponibles ailleurs ou pour sauvegarder l'état actuel d'un paquet avant de le mettre à jour.

 @@ -5392,9 +6076,9 @@ elles ne sont pas requises par la charte.

dpkg-dev-el fournit des macros Emacs Lisp qui apportent une aide lors de l'édition des fichiers du répertoire debian de votre - paquet. À l'édition de debian/changelog, par exemple, vous - disposez de fonctions pour finaliser une version et consulter la liste des - rapports de bogue ouverts.

+ paquet. Par exemple, il y a des fonctions pratiques pour lister les bogues + actuels d'un paquet et pour finaliser la dernière entrée d'un fichier +debian/changelog file.