X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developers-reference.fr.sgml;h=d5f27591dfe9c0f1b1a11a0552f5b41475045760;hp=ccaa238fabc1966a43d4f0a62844d054177357d6;hb=f87e8d649212e9841554fb17d10b59dfef3b7c45;hpb=f0a848531ec8388509a50fde213aaf15d5017d39 diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index ccaa238..d5f2759 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -2,16 +2,14 @@ %versiondata; - + %commondata; - + - + FIXME: "> @@ -23,17 +21,19 @@
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.
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
@@ -242,7 +242,8 @@ Quand vous avez choisi la mani
sur vos paquets avec vous et les téléchargera dans l'archive Debian une fois
qu'il sera satisfait de votre mise en paquet. Pour trouver un parrain, envoyez
une demande de parrainage à la liste &email-debian-mentors; en vous présentant
- et en décrivant votre paquet (voir pour en savoir plus
+ et en décrivant votre paquet (voir et
+
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
@@ -369,7 +371,8 @@ Si vos paquets sont pr
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
Si vous désirez être mentor ou parrain, reportez-vous à .
@@ -396,11 +399,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
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.
@@ -645,7 +663,9 @@ 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é
+ disquettes de démarrage (i.e., l'installateur).
+
+#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,
@@ -711,19 +731,23 @@ Si votre probl
il vous faudra en général ouvrir un rapport de bogue sur un
« pseudo-paquet ». Reportez-vous à la section
pour connaître la procédure à suivre.
+
+Certains des serveurs de base sont à accès restreint, mais les informations de
+ceux-ci sont fournies par d'autres serveurs miroirs.
&bugs-host; est le serveur maître du système de suivi des bogues
(BTS Système de suivi des bogues se dit Bug Tracking
- System en anglais
+Ce serveur est à accès restreint ; un miroir est disponible sur merkel.
+
+ Si vous envisagez de manipuler les rapports
de bogue ou d'en faire une analyse statistique, ce sera le bon endroit pour le
faire. Informez la liste &email-debian-devel; de votre intention avant
d'implémenter quoi que ce soit afin d'éviter un travail en double ou un
gaspillage de temps machine.
-
-Tous les développeurs Debian ont un compte sur
- &bugs-host;.
@@ -732,6 +756,8 @@ Le serveur ftp-master.debian.org est le serveur ma
paquets se font sur ce serveur. Reportez-vous à la section
pour en savoir plus.
+Ce serveur est à accès restreint ; un miroir est disponible sur merkel.
+
Les problèmes avec l'archive Debian FTP doivent généralement être rapportés
comme bogues sur le pseudo-paquet
Notre serveur CVS est situé sur cvs.debian.org.
@@ -802,6 +829,20 @@ Pour obtenir un espace CVS, envoyez une demande
en précisant le nom de l'espace, le compte Debian propriétaire du répertoire
racine et pourquoi vous en avez besoin.
+
+Sur certaines machines, des chroots de différentes distributions sont
+disponibles. Vous pouvez les utiliser comme ceci :
+
+
@@ -831,8 +872,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 à
La section main constitue la distribution &debian-formal;
officielle. Elle est officielle parce qu'elle est entièrement conforme
@@ -932,7 +973,7 @@ Le noyau 2.0 existe pour les architectures Intel x86, DEC Alpha, SPARC,
reconnaît de nouvelles architectures, comme ARM et UltraSPARC. Puisque Linux
reconnaît ces architectures, le projet Debian a décidé qu'il devait également les
accepter. C'est pourquoi plusieurs portages sont en cours ; en fait, il y
- a aussi des portages vers d'autres noyaux. À côté d'i386 (notre nom
+ a aussi des portages vers d'autres noyaux non-Linux. À côté d'i386 (notre nom
pour Intel x86), nous avons, au moment où j'écris, m68k,
alpha, powerpc, sparc, hurd-i386,
arm, ia64, hppa, s390, mips,
@@ -942,7 +983,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.
@@ -1008,11 +1049,12 @@ Les d
que tout fonctionne correctement dans cette distribution, elle est parfois
littéralement « instable ».
- est générée automatiquement en prenant les paquets
+La distribution
Après une période de développement, quand le responsable de
distribution Release manager
-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
- fichiers
-L'inclusion d'un paquet d'unstable est soumise aux
- conditions suivantes :
- Le paquet doit avoir été disponible dans unstable depuis
- plusieurs jours ; le nombre précis dépend du champ d'urgence de
- l'envoi. Il s'agit de 10 jours pour une urgence faible, 5 jours pour une
- urgence moyenne et 2 jours pour une urgence élevée. Ces délais peuvent
- être doublés lors d'un gel de distribution ; Il doit avoir moins de bogues empêchant l'intégration dans la distribution que la
- version disponible dans testing ; Il doit être disponible pour toutes les architectures pour lesquelles
- il a été auparavant construit. peut être
- intéressant pour vérifier cette information ; Il ne doit pas casser les dépendances d'un paquet qui est déjà
- 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 eux-mêmes respecter tous ces
- critères).
-Pour savoir si un paquet a progressé ou non dans testing, veuillez voir la
- sortie du script de testing sur la
-Le fichier
-Parfois, certains paquets n'entrent jamais dans testing parce que le
- jeu des inter-relations est trop compliqué et ne peut être résolu par le
- script. Dans ce cas, le responsable de version doit être contacté et il forcera
- l'inclusion du paquet.
+
+Les paquets sont habituellement installés dans la distribution testing
+après avoir atteint un certain degré de test dans unstable.
-En général, veuillez vous référer à la
@@ -1120,7 +1117,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.
@@ -1148,6 +1145,15 @@ Un nouveau logiciel qui ne risque pas d'endommager le syst
Une solution de rechange à experimental consiste à utiliser vos pages
personnelles sur le serveur people.debian.org.
+
+Veuillez considérer l'utilisation de l'option -v de
+
@@ -1194,7 +1200,7 @@ En cons
Les différentes archives de téléchargement et le site web disposent de plusieurs
miroirs pour soulager les serveurs principaux d'une lourde charge. En fait,
-certains de ces serveurs ne sont pas publics et la charge est
+certains de ces serveurs ne sont pas publics — la charge est
répartie sur une première série de serveurs. De cette façon, les
utilisateurs ont toujours accès aux miroirs et s'y habituent, ce qui permet à
Debian de mieux répartir les besoins en bande passante sur plusieurs serveurs et
@@ -1223,7 +1229,7 @@ Le syst
Les paquets sont envoyés par tous les responsables Debian dans un répertoire
nommé
Tous les développeurs Debian ont un droit d'écriture dans le répertoire
-
+Note : la description présentée ici ne fonctionne pas
+ car ftp-master est à accès restreint. Veuillez vous reporter à pour la façon actuelle de faire.
Le répertoire
Le système de suivi des bogues trie les bogues par paquet. Vous pouvez regarder
les bogues de chaque paquet à
@@ -1318,7 +1328,8 @@ Le syst
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.
-
Le système de suivi des paquets (PTS)
-Chaque courrier envoyé par le PTS est classé et associé à l'un des mots-clés
+Chaque courrier envoyé par le PTS est classé sous l'un des mots-clés
listés ci-dessous. Ceci vous permettra de sélectionner les courriers que vous
voulez recevoir.
@@ -1456,7 +1466,7 @@ Vous pouvez contr
chaque paquet source.
Le sujet de votre rapport de bogue devra être <ITP Intent To
- Package : intention de d'empaquetage
-Il est techniquement possible d'envoyer un paquet dans plusieurs distributions
- en même temps, mais ceci n'a habituellement aucun sens d'utiliser cette
- fonctionnalité car les dépendances d'un paquet peuvent varier selon les
- distributions. En particulier, il est absurde de combiner la distribution
- experimental avec tout autre chose.
+Il n'est pas possible d'envoyer un paquet dans plusieurs distributions
+ en même temps.
-
Livrer un paquet pour la distribution stable signifie que le paquet
@@ -1848,56 +1855,35 @@ L'
stable. Soyez précis (et, si nécessaire, prolixe) quand vous
décrivez, dans le fichier changelog, vos changements pour une livraison
vers stable, sinon le paquet ne sera pas pris en considération.
+
+Il est fortement conseillé de discuter avec le responsable de la version stable avant
+de réaliser un envoi dans stable/stable-proposed-updates, pour
+que le paquet envoyé corresponde aux besoins de la prochaine révision de stable.
-
-La distribution testing est peuplée avec des paquets en provenance
- d'unstable selon des règles expliquées dans .
- Cependant, le responsable de distribution peut stopper les scripts de
- testing quand il veut geler la distribution. Dans ce cas, vous
- pouvez envoyer vos paquets vers testing-proposed-updates pour
- fournir des paquets corrigés durant le gel.
-
-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
- &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 dans
- unstable), vous pouvez l'utiliser, mais il est recommandé de
- demander l'autorisation du responsable de distribution auparavant.
-
+Veuillez consulter les informations dans la
-Pour installer un paquet, vous avez besoin d'un compte sur
-
-Si vous désirez utiliser la fonctionnalité de délai décrite dans , vous devez effectuer votre envoi vers
-ftp-master. Il s'agit de la seule destination d'envoi supportant
-l'incoming différé.
+Pour installer un paquet, vous devez envoyer les fichiers (y compris les
+ fichiers changes et dsc signés) par ftp anonyme sur
+
Attention, il est préférable de transférer le fichier
changes en dernier. Dans le cas contraire, votre livraison pourrait
ê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. Si
- vous ne voulez pas vous embêter avec l'ordre de transfert des fichiers, vous
- pouvez tout simplement copier vos fichiers dans un répertoire temporaire de
- ftp-master et les déplacer ensuite vers &us-upload-dir;.
+ 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 non-free à cause de problèmes de distribution et non pas à cause de
la licence du logiciel). Quand vous ne pouvez télécharger sur
ftp-master, vous ne pouvez pas non plus télécharger sur
- chiark ou erlangen. Si vous ne savez pas si votre paquet
+ les sites de repli qui arrivent finalement sur ftp-master. Si vous ne savez pas si votre paquet
est protégé par un brevet ou s'il est soumis aux lois de contrôle des
exportations américaines, posez la question sur la liste
&email-debian-devel;.
@@ -1917,27 +1903,19 @@ Les paquets ou pourront vous faciliter le
travail lors du téléchargement. Ces programmes, bien pratiques, aident à
automatiser le processus d'envoi de paquets vers Debian
-Après avoir téléchargé votre paquet, vous pouvez vérifier ce qu'en
- fera le logiciel de maintenance de l'archive en exécutant
-
-Notez que
+Note : non-us n'est plus traité actuellement.
+
Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des
exportations américaines ne doivent pas être installés sur
- ftp-master. Installez le paquet sur
-
-Tout comme sur ftp-master, vous pouvez vérifier votre téléchargement
- avec :
Attention, les personnes résidant aux États-Unis et les citoyens américains sont
soumis à des restrictions sur l'exportation des logiciels de cryptographie.
@@ -1970,65 +1948,52 @@ Cette section a pour seul but d'informer, elle n'a pas valeur de conseil
américains de consulter un juriste avant de livrer un paquet sur
non-US.
-
-Si votre connexion vers ftp-master est lente, vous avez plusieurs
- possibilités. L'une d'elles consiste à télécharger vos fichiers dans
-
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
- contrôle des exportations américaines sur chiark. Les paquets
- téléchargés sur ce serveur sont redirigés vers ftp-master, les
- indications de la section sont applicables ici
- aussi.
-
-Le programme
-Vous pouvez aussi accéder à un serveur situé en Allemagne : il vous suffit
- d'ouvrir une connexion anonyme sur
-Le téléchargement fait sur ce serveur doit être aussi complet que s'il était
- fait dans le répertoire
-Il n'est pas nécessaire de déplacer votre fichier dans un autre répertoire après
- le téléchargement, contrairement au serveur chiark. Vous devriez
- ensuite recevoir un courrier du serveur expliquant ce qu'il a fait de votre
- paquet. Normalement, il devrait avoir été déplacé vers
- ftp-master ; vous serez informé par le même biais si une erreur
- s'est produite au cours du processus.
-
-Attention, ne téléchargez pas de paquet contenant un logiciel soumis aux lois de
- contrôle des exportations américaines sur erlangen. Les paquets
- téléchargés sur ce serveur sont redirigés vers ftp-master, les
- indications de la section sont applicables ici
- aussi.
-
-Le programme
-Un autre serveur est disponible aux États-Unis ; c'est un bon point de
- repli quand il est difficile de joindre ftp-master. Livrez vos
- paquets à l'adresse
-Il existe aussi un serveur au Japon : téléchargez vos paquet par FTP
- anonyme sur
+Les envois différés sont pour le moment réalisés via la file différée
+ sur gluck. Le répertoire d'envoi est
+
+Avec une version assez récente de dput, cette section
+
+Note :
+Comme la file d'envoi va sur ftp-master, la
+prescription que l'on trouve dans s'applique
+également ici.
+
+
+N'envoyez PAS un paquet vers la file d'envoi de sécurité (oldstable-security,
+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 .
+
+
+Les files scp sur ftp-master, non-us et security sont pratiquement inutilisables
+à cause des restrictions de connexion sur ces hôtes.
+
+Les files anonymes sur ftp.uni-erlangen.de et ftp.uk.debian.org sont
+actuellement arrêtées. Un travail est en cours pour les restaurer.
+
+Les files sur master.debian.org, samosa.debian.org, master.debian.or.jp
+et ftp.chiark.greenend.org.uk sont arrêtées de façon permanente et ne seront pas
+restaurées. La file du Japon sera remplacée par une nouvelle file sur
+hp.debian.or.jp un jour.
+
+À l'heure actuelle, la file en ftp anonyme sur auric.debian.org (le précédent
+ftp-master) fonctionne, mais elle est déconseillée et sera supprimée à un moment
+donné.
+Notez que si vous envoyez via les files, le logiciel de démon de file
+ vous enverra également une notification par courriel.
-
Les champs Section et Priority du fichier
-Notez également que le terme « section » est utilisé pour la
- séparation des paquets selon leur licence, e.g main, contrib
- et non-free. Ceci est décrit dans une autre section, .
+Notez que le champ Section décrit à la fois la section et la
+sous-section, comme décrit dans . Si la section est
+« main », elle devrait être omise. La liste des sous-sections
+autorisées peut être trouvée dans
Chaque développeur doit être capable de travailler avec le
-Les fonctionnalités du système de suivi des bogues qui intéressent les
-développeurs sont décrites dans la
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
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
@@ -2204,9 +2171,7 @@ 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 à
-
Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
corresponde à notre définition de gravité des bogues. C'est dû au
@@ -2285,13 +2250,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
+Si un envoi est identifié comme une
Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans les
entrées du fichier
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.
@@ -2499,23 +2479,44 @@ corrig
sécurité peut casser de manière subtile des fonctionnalités qui ne semblent pas
liées.
+N'incluez PAS de changements dans votre paquet qui ne soient
+pas liés directement à la correction de la vulnérabilité. Ceux-ci devraient être
+ensuite enlevés et cela perd du temps. S'il y a d'autres bogues dans votre
+paquet que vous aimeriez corriger, faites un envoi vers
+proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité.
+Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des
+changements dans votre paquet qui seraient sinon rejetés de la distribution
+stable, n'essayez donc pas de faire cela, s'il vous plaît.
+
Examinez et testez autant que possible vos changements. Vérifiez les différences
avec la version précédente de manière répétée (
-Lors de la construction de la correction, gardez les points suivants à
-l'esprit :
+Assurez-vous de conserver les points suivants à l'esprit :
Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis des
autres développeurs sur la liste &email-debian-devel;. Le programme
Une fois que le paquet a été supprimé, les bogues du paquet doivent être gérés.
Soit ils sont réattribués à un autre paquet dans le cas où le code actuel a
@@ -2669,7 +2674,7 @@ Une fois que le paquet a
Par le passé, il était possible de supprimer un paquet de
-Il peut vous arriver de vous tromper en nommant un paquet et de vouloir
-changer son nom. Dans ce cas, vous devrez intervenir en deux étapes. D'abord, modifiez
+Si vous vous trompez en nommant un paquet, vous devrez intervenir en deux
+ étapes pour changer son nom. D'abord, modifiez
votre fichier Orphaned : abandonné.
-Si le paquet est particulièrement important pour la distribution, il vous faudra
- faire un rapport de bogue sur le pseudo-paquet Request For Adoption :
- offre d'adoption.
-Reportez-vous à la page WNPP Work-needing and prospective
- packages : paquets en souffrance et paquets souhaités.
+Vous pouvez trouver plus d'informations sur les Work-needing and prospective
+ packages : paquets en souffrance et paquets
+ souhaités.
@@ -2766,8 +2771,8 @@ Debian accepte un nombre croissant d'architectures. M
portabilité. C'est pourquoi il est important que vous lisiez ce chapitre
même si vous n'êtes pas un porteur.
-Porter un paquet consiste à faire un paquet binaire pour une architecture
- différente de celle du paquet binaire fait par le responsable du paquet.
+Porter un paquet consiste à faire un paquet binaire pour des architectures
+ différentes de celle du paquet binaire fait par le responsable du paquet.
C'est une activité remarquable et essentielle. En fait, les porteurs sont
à l'origine de la plupart des compilations de paquets Debian. Pour un
paquet binaire i386, par exemple, il faut compter une
@@ -2775,7 +2780,7 @@ Porter un paquet consiste
&number-of-arches; recompilations.
-
Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un
grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans
@@ -2784,7 +2789,7 @@ Les porteurs ont une t
problèmes courants qui bloquent souvent les porteurs et compliquent inutilement
leur travail.
-Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et
+Ici, la première et la plus importante chose est de répondre rapidement aux rapports de bogues et
remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils
étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière).
Merci pour votre indulgence envers des rapports de bogue succincts ou peu
@@ -2886,6 +2891,12 @@ La mani
adresse-porteur par votre adresse électronique. Cette commande
construira les parties du paquet qui dépendent de l'architecture, en utilisant
la cible binary-arch de
+Si vous travaillez sur une machine Debian pour vos efforts de portage et que
+vous devez signer votre envoi localement pour son acceptation dans l'archive,
+vous pouvez exécuter
+Vous devez vous assurez que votre mise à jour indépendante binaire ne rend pas
+ le paquet non installable. Cela peut arriver si un paquet source génère des
+ paquets dépendants et indépendants de l'architecture qui dépendent
+ les uns des autres via $(Source-Version).
+
+
+ Malgré les modifications nécessaires du changelog, ce type de mise
à jour reste une mise à jour indépendante binaire — il n'est pas
nécessaire de reconsidérer le statut des paquets binaires des autres
architectures pour les marquer périmés ou à recompiler.
@@ -2914,6 +2933,10 @@ Cette
« 2.9-3 », votre mise à jour portera le numéro
« 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre
mise à jour portera le numéro « 3.4-2.1.1 ».
+
+De manière similaire aux envois du porteur initial, la façon correcte d'invoquer
+
Si vous êtes porteur et faites une mise à jour pour unstable, les
instructions précédentes sont applicables à deux différences près. Tout
@@ -2933,7 +2959,10 @@ Si vous
Ce délai peut être raccourci si le problème est crucial et met l'effort de
portage en difficulté : c'est à la discrétion de l'équipe de portage.
(Souvenez-vous, il ne s'agit pas d'un règlement, mais de recommandations
- communément acceptées).
+ communément acceptées). Pour les envois de stable ou
+ testing, veuillez tout d'abord vous coordonner avec l'équipe de
+ diffusion appropriée.
+
Deuxième différence, les porteurs qui font des mises à jour indépendantes
sources doivent choisir une gravité sérieuse (i.e. serious)
@@ -3028,103 +3057,53 @@ Dans certaines circonstances, il est n
upload (NMU). Dans le présent document, nous traduisons librement
cette expression par « mise à jour indépendante ».
-Ces mises à jour indépendantes de binaires font de temps en temps partie du
- travail normal des porteurs qui compilent les paquets pour d'autres
- architectures (voir ). Un développeur peut aussi faire
- des mises à jour indépendantes quand il corrige le paquet d'un autre
- développeur pour éliminer un problème de sécurité ou un bogue bloquant. Cela
- se produit plus particulièrement en période de gel de la distribution de
- développement ou quand le responsable officiel du paquet ne peut pas
+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 . 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
+ développeur pour résoudre des problèmes sérieux ou des bogues paralysants
+ ou quand le responsable d'un paquet ne peut pas
fournir une correction dans un délai raisonnable.
-Ce chapitre contient des informations qui vous expliqueront quand et comment
- faire des mises à jour indépendantes. Une distinction fondamentale doit
- être faite entre les mises à jour indépendantes sources et les mises à
- jour indépendantes binaires. Elle est explicitée dans la section suivante.
-
-
-Deux nouvelles expressions sont introduites dans cette section :
- « mise à jour indépendante source » et « mise à jour
- indépendante binaire ». Ces expressions ont une définition précise dans le
- monde Debian. Elles correspondent toutes deux au même type d'activité ;
- elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
- alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
- nous qualifions ces mises à jours
- d'indépendantes
-Une mise à jour indépendante source est une livraison de paquet faite par une
- personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
- de corriger un bogue dans le paquet. Une mise à jour indépendante source
- implique toujours une modification des sources du paquet, même s'il ne s'agit
- que d'un changement dans le fichier
-Une mise à jour indépendante binaire est constitué par la recompilation et
- l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
- résultat d'un effort de portage. Une mise à jour indépendante binaire est la
- livraison d'un paquet compilé (souvent pour une autre architecture) à condition
- que cette compilation n'ait pas nécessité de modifications des sources. Dans de
- nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
- compilables sur leur architecture cible ; il s'agira alors d'une mise à
- jour indépendante source et non d'une mise à jour indépendante binaire. Comme
- vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
- jour indépendantes faites par des porteurs et les autres mises à jour
- indépendantes.
-
-Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
- par l'expression « mise à jour indépendante »
- (NMU Non-maintainer upload
-Seuls les responsables Debian officiels peuvent faire des mises à jour
- indépendantes. Un responsable officiel est une personne dont la clé est dans le
- porte-clés Debian. Toute personne est invitée à télécharger les paquets sources
- pour corriger des bogues ; au lieu de faire des mises à jour
- indépendantes, ils pourront soumettre les correctifs qui le méritent au système
- de suivi des bogues. Les responsables apprécient presque toujours les
- correctifs et les rapports de bogue soignés.
+Et souvenez-vous du Serment d'Hippocrate « Par dessus tout, ne pas
+faire de mal ». Il est préférable qu'un paquet ait un bogue ouvert grave
+plutôt qu'un correctif non fonctionnel soit appliqué et que le bogue devienne
+caché, mais toujours non résolu.
+
+Les mises à jour indépendantes qui corrigent des bogues de gravité importante,
+sérieuse et plus élevée sont encouragées et acceptées. Vous devriez vous
+efforcer de contacter le responsable actuel du paquet : il est peut-être
+sur le point d'envoyer un correctif pour le problème ou il a peut-être une
+meilleure solution.
+
+Les mises à jour indépendantes doivent être réalisées pour assister un
+responsable de paquet à résoudre des bogues. Les responsables devraient être
+reconnaissants pour cette aide et les personnes faisant la mise à jour
+indépendante devraient respecter les décisions du responsable et tenter
+d'aider personnellement le responsable dans son travail.
+
+Une mise à jour indépendante devrait suivre toutes les conventions décrites dans
+cette section. Pour un envoi vers testing ou unstable, l'ordre
+suivant des étapes est recommandé :
+
-
-Les recommandations pour déterminer quand faire une mise à jour indépendante
- source dépendent de la distribution visée (i.e. stable,
- unstable ou experimental). Les porteurs, ayant une activité
- particulière, obéissent à des règles légèrement différentes (voir ).
-
-Quand une bogue de sécurité est détecté, l'équipe de sécurité peut faire une
- mise à jour indépendante. Veuillez vous reporter à pour
- plus d'informations.
-
-Pendant le cycle de mise au point (release cycle, voir ), les livraisons qui corrigent les bogues de gravité
- sérieuse (i.e. serious) et supérieures sont encouragées et
- acceptées. Même pendant cette période, vous devriez tenter d'entrer en contact
- avec le responsable du paquet ; il pourrait bien être sur le point de
- livrer un paquet corrigé lui aussi. Comme pour n'importe quelle mise à jour
- indépendante source, les recommandations de la section doivent être respectées. Des exceptions spéciales sont
- effectuées pour .
-
-Envoyer des corrections de bogues vers unstable par une autre personne
- que le responsable ne devrait être fait qu'en suivant ce protocole :
-
-Les règles qui suivent s'appliquent aux porteurs tant qu'ils jouent le double
- rôle de correcteur de bogue et de porteur. Si un porteur doit modifier le
- paquet source, cette mise à jour est automatiquement une mise à jour
- indépendante source et est soumise aux règles qui suivent. Si un porteur
- construit un paquet binaire recompilé, les règles sont différentes (voir .
+Pour la distribution testing, les règles peuvent être changées par les
+responsables de diffusion. Veuillez porter une attention spéciale au fait que le
+moyen habituel pour un paquet d'entrer dans testing est de passer par
+unstable.
-Tout d'abord, il est capital que ces mises à jour indépendantes soient aussi peu
- intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
- modules ou des fichiers, ne déplacez pas les répertoires ; plus
- généralement, ne corrigez pas ce qui n'est pas cassé. Faites un correctif aussi
- petit que possible. Si certaines choses froissent votre sens de l'esthétique,
- parlez-en au responsable du paquet, au responsable amont ou soumettez un
- rapport de bogue. Quoiqu'il en soit, les changements esthétiques ne doivent
- pas être effectués lors d'une mise à jour indépendante.
-
+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
+acceptables pour inclusion dans la prochaine version stable par le responsable
+de diffusion.
+
+Quand un bogue de sécurité est détecté, l'équipe de sécurité peut effectuer une
+mise à jour indépendante en utilisant ses propres règles. Veuillez vous référer
+à pour plus d'informations.
+
+Pour les différences pour les mises à jour indépendantes par les porteurs,
+veuillez voir .
+
+Bien sûr, il est toujours possible de s'accorder avec un responsable pour des
+règles spéciales (comme quand le responsable demande « merci d'envoyer le
+correctif directement pour moi et pas de diff nécessaire »).
-
Chaque fois que vous modifiez un paquet, le numéro de version de ce paquet doit
changer, même pour la plus triviale des modifications. Notre système de
@@ -3211,9 +3194,13 @@ S'il n'y a pas de partie r
fasse une livraison basée sur une nouvelle version amont, cette personne doit
choisir « 0.1 » comme numéro de révision Debian. Le mainteneur du
paquet doit, lui, démarrer sa numérotation à « 1 ».
+
+Si vous envoyez un paquet vers testing ou stable, vous devrez
+ parfois créer une branche (« fork ») dans l'arbre de numéro des version. Pour cela, vous
+ pouvez utiliser des numéros de version comme 1.1-3sarge0.1.
-
@@ -3231,7 +3218,7 @@ Par convention, dans le cas d'une mise
-
Un développeur qui n'est pas responsable d'un paquet doit faire aussi peu de
@@ -3248,8 +3235,8 @@ Et si vous recompilez simplement le paquet ? Si vous avez simplement besoin
Si la mise à jour indépendante source (source NMU) corrige des bogues,
ceux-ci doivent être marqués fixed (corrigé) dans le système de
suivi des bogues plutôt que clos. Par convention, seul le responsable du
- paquet et la personne qui a ouvert le rapport de bogue peuvent clore ce
- rapport. Heureusement, le système d'archivage Debian reconnaît les mises à
+ paquet et la personne qui a ouvert le rapport de bogue ferment les
+ rapports. Heureusement, le système d'archivage Debian reconnaît les mises à
jours indépendantes et positionne correctement le statut des bogues à
fixed si la personne qui fait la mise à jour a listé tous les bogues
dans le fichier changelog en utilisant la syntaxe Closes:
@@ -3260,10 +3247,11 @@ Si la mise
jusqu'à ce que le responsable du paquet incorpore les modifications de cette
mise à jour dans la version officielle du paquet.
-Après avoir fait une mise à jour indépendante, il vous faudra aussi ouvrir un
- nouveau rapport de bogue qui inclura un correctif contenant toutes les
- modifications que vous avez faites. Sinon, vous pouvez envoyer cette
- information aux bogues qui sont fixés par votre NMU. Le responsable officiel
+Après avoir fait une mise à jour indépendante, il vous faudra aussi envoyer
+ cette information aux bogues existants que vous avez corrigés par votre NMU
+ en incluant le diff unifié. Sinon, vous pouvez créer un nouveau rapport de
+ bogue et inclure un correctif comprenant toutes les modifications que vous
+ avez réalisées. Le responsable officiel
pourra choisir d'appliquer le correctif, il pourra aussi employer une autre
méthode pour régler le problème. Certains bogues sont corrigés dans la
version amont, ce qui est une bonne raison pour annuler les modifications
@@ -3277,7 +3265,7 @@ De plus, le responsable officiel devrait toujours conserver les entr
Les paquets faisant l'objet d'une mise à jour indépendante source sont
construits comme les autres. Sélectionnez une distribution en utilisant les
@@ -3295,7 +3283,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
+
@@ -3307,6 +3298,71 @@ Dans tous les cas, vous ne devriez pas
comme co-responsable ou responsable de secours (cf. ).
+
+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 lesquels le champ responsable n'a pas été positionné
+correctement est disponible à
+Seuls les responsables Debian officiels peuvent faire des mises à jour
+ indépendantes binaire ou source. Un responsable officiel est une personne dont la clé est dans le
+ porte-clés Debian. Tout autre personne est toutefois invitée à télécharger les paquets sources
+ pour corriger des bogues ; au lieu de faire des mises à jour
+ indépendantes, ils pourront soumettre les correctifs qui le méritent au système
+ de suivi des bogues. Les responsables apprécient presque toujours les
+ correctifs et les rapports de bogue soignés.
+
+
+Deux nouvelles expressions sont introduites dans cette section :
+ « mise à jour indépendante source » et « mise à jour
+ indépendante binaire ». Ces deux expressions ont une signification
+ technique précise dans ce document. Elles correspondent toutes deux au même type d'activité ;
+ elles impliquent toutes deux qu'une personne fait une mise à jour d'un paquet
+ alors qu'elle n'est pas officiellement responsable de ce paquet. C'est pourquoi
+ nous qualifions ces mises à jours
+ d'indépendantes
+Une mise à jour indépendante source est une livraison de paquet faite par une
+ personne qui n'est pas le responsable officiel de ce paquet avec pour objectif
+ de corriger un bogue dans le paquet. Une mise à jour indépendante source
+ implique toujours une modification des sources du paquet, même s'il ne s'agit
+ que d'un changement dans le fichier
+Une mise à jour indépendante binaire est constitué par la recompilation et
+ l'archivage d'un paquet pour une architecture donnée. Il s'agit souvent du
+ résultat d'un effort de portage. Une mise à jour indépendante binaire est la
+ livraison d'un paquet compilé (souvent pour une autre architecture) à condition
+ que cette compilation n'ait pas nécessité de modifications des sources. Dans de
+ nombreux cas, les porteurs sont obligés de modifier les sources pour les rendre
+ compilables sur leur architecture cible ; il s'agira alors d'une mise à
+ jour indépendante source et non d'une mise à jour indépendante binaire. Comme
+ vous pouvez le remarquer, nous ne faisons pas de distinction entre les mises à
+ jour indépendantes faites par des porteurs et les autres mises à jour
+ indépendantes.
+
+Les mises à jour indépendantes sources et binaires sont toutes deux couvertes
+ par l'expression « mise à jour indépendante »
+ (NMU Non-maintainer upload
Habituellement, il y a un responsable principal et un ou plusieurs
- co-responsables. Le responsable principal est celui dont le nom est indiqué
+ co-responsables. Le responsable principal est la personne dont le nom est indiqué
dans le champ Maintainer du fichier
@@ -3346,8 +3402,327 @@ 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 ).
+
+
+Les paquets sont habituellement installés dans la distribution testing
+après avoir atteint un certain degré de test dans unstable.
+
+Ils doivent être en synchronisation pour toutes les architectures et ne doivent
+pas avoir de dépendances qui les rendraient ininstallables ; ils doivent
+également n'avoir aucun bogue bloquant l'inclusion du paquet dans une version
+stable (« release-critical ») au moment où ils sont installés dans
+testing. Ainsi, testing devrait toujours être prête pour être
+une version candidate stable. Veuillez voir ci-dessous pour les détails.
+
+
+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
+ fichiers
+L'inclusion d'un paquet d'unstable est soumise aux conditions
+suivantes :
+
+Pour savoir si un paquet a progressé ou non dans testing, veuillez voir la
+sortie du script de testing sur la
+Le fichier
+Parfois, certains paquets n'entrent jamais dans testing parce que le
+ jeu des inter-relations est trop compliqué et ne peut être résolu par le
+ script. Voir ci-dessous pour des détails.
+
+Des analyses de dépendances plus avancées sont présentées sur
+
+
+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
+architectures dans fuckedarches ; fuckedarches est une liste des
+architectures qui ne suivent pas le rythme (dans update_out.py), mais
+actuellement cette liste est vide). « Désynchronisé » n'a rien à voir
+avec les architectures que le paquet fournit pour testing.
+
+Considérons cet exemple :
+
+
+Le paquet est désynchronisé pour alpha dans unstable et n'entrera pas
+dans testing. Supprimer foo de testing n'aiderait en rien, le
+paquet serait toujours désynchronisé pour alpha et ne se propagerait pas dans
+testing.
+
+Cependant, si ftp-master supprime un paquet d'unstable (ici pour arm) :
+
+
+Dans ce cas, le paquet est synchronisé pour toutes les architectures de version
+dans unstable (et l'architecture supplémentaire hurd-i386 ne compte pas
+car ce n'est pas une architecture de version).
+
+Quelquefois, la question est soulevée pour savoir s'il est possible de permettre
+à des paquets de passer dans testing qui ne sont pas encore construits
+pour toutes les architectures : non. Simplement non. (Excepté si vous êtes
+responsable de glibc ou équivalent).
+
+
+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 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
+suffisant pour être dans cet état).
+
+
+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 :
+
+
+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 à
+debian-release@lists.debian.org si cela se produit pour l'un de vos paquets.
+
+
+
+Généralement, l'état d'un paquet dans testing ne change rien pour la
+transition de la prochaine version d'unstable vers testing,
+avec deux exceptions : si le nombre de bogues RC du paquet est réduit, le
+paquet peut migrer même s'il a encore des bogues RC. La seconde exception est
+que si la version du paquet dans testing est désynchronisée entre les
+différentes architectures, alors toute architecture peut être mise à jour vers
+la version du paquet source ; cependant, cela ne peut se produire que si le
+paquet a été précédemment forcé, si l'architecture est dans fuckedarches ou s'il
+n'y avait pas du tout de paquet binaire de cette architecture présent dans
+unstable lors de la migration dans testing.
+
+En résumé, cela veut dire : la seule influence qu'un paquet de
+testing a sur la nouvelle version du même paquet est que la nouvelle
+version peut rentrer plus facilement.
+
+
+Si vous êtes intéressé par les détails, voici comment fonctionne britney :
+
+Les paquets sont examinés pour savoir si ce sont des candidats valides. Cela
+donne le fichier « update excuses ». Les raisons les plus communes
+pour lesquelles un paquet n'est pas considéré sont la jeunesse du paquet, le
+nombre de bogues RC et la désynchronisation pour certaines architectures. Pour
+cette partie, 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 é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 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
+probablement pas très important pour vous.)
+
+Si vous voulez voir plus de détails, vous pouvez le voir dans
+merkel:/org/ftp.debian.org/testing/update_out/ (ou dans
+~aba/testing/update_out pour voir une configuration avec un fichier de paquets
+plus petit). Par le web, c'est à
+Les coups de pouce sont visibles sur
+La distribution testing est peuplée avec des paquets en provenance
+d'unstable selon des règles expliquées ci-dessus. Cependant, dans
+certains cas, il est nécessaire d'envoyer des paquets construits seulement pour
+testing. Pour cela, vous pouvez envoyer vos paquets vers
+testing-proposed-updates.
+
+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 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 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 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 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 :
+
+
+
+Tous les bogues de gravité assez élevée sont par défaut considérés
+comme bloquant l'intégration du paquet dans la version stable ;
+actuellement, ce sont les bogues critiques, graves et sérieux.
+
+Certains bogues sont supposés avoir un impact sur les chances que le paquet a
+d'être diffusé dans la version stable de Debian : en général, si un paquet
+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 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.
+
+
+La structure des archives de la distribution est faite de telle façon qu'elles
+ne peuvent contenir qu'une version d'un paquet ; un paquet est défini par
+son nom. Donc, quand le paquet source acmefoo est installé dans
+testing avec ses paquets binaires acme-foo-bin, acme-bar-bin,
+libacme-foo1 et libacme-foo-dev, l'ancienne version est supprimée.
+
+
+Cependant, l'ancienne version pouvait fournir à un paquet binaire un vieux
+soname d'une bibliothèque, comme libacme-foo0. Supprimer l'ancien acmefoo va
+supprimer libacme-foo0, ce qui va casser tout paquet qui en dépend.
+
+Évidemment, cela touche principalement des paquets qui fournissent des jeux
+changeants de paquets binaires dans différentes version (par suite,
+principalement des bibliothèques). Cependant, cela va aussi toucher des paquets
+sur lesquels une dépendance versionnée a été déclarée du type ==, <= ou <<.
+
+Quand le jeu de paquets binaires fournis par un paquet source change de cette
+façon, tous les paquets qui dépendent des anciens binaires doivent être mis à
+jour pour dépendre de la nouvelle version à la place. Comme l'installation d'un
+tel paquet source dans testing casse tous les paquets qui en dépendent
+dans testing, une certaine attention doit y être portée : tous les
+paquets en dépendant doivent être mis à jour et prêts à être installés eux-même
+pour qu'ils ne cassent pas et, une fois que tout est prêt, une intervention
+manuelle du responsable de version ou d'un de ses assistants est normalement
+requise.
+
+Si vous avez des problèmes avec des groupes compliqués de paquets comme ceci,
+contactez debian-devel ou debian-release en demandant de l'aide.
+
@@ -3432,7 +3807,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
-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
Les pratiques suivantes sont relatives au fichier
La description du paquet, telle qu'elle est définie par le champ correspondant
@@ -3610,6 +3985,35 @@ sp
+Les utilisateurs s'attendent habituellement à ce que les réponses aux questions
+suivantes soient présentes dans la description du paquet :
+
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.
@@ -3785,6 +4189,49 @@ O
descriptif, commencez par insérer le titre de chacun des différents bogues.
+Les nouvelles importantes à propos des changements dans un paquet peuvent
+également être placées dans les fichiers NEWS.Debian. Ces nouvelles seront
+affichées par des outils comme apt-listchanges, avant le reste des changelogs.
+Ceci est le moyen préféré pour informer les utilisateurs des changements
+significatifs dans un paquet. Il est préférable d'utiliser ce fichier plutôt que
+d'utiliser des notes debconf car c'est moins ennuyeux et l'utilisateur peut y
+revenir et se référer au fichier NEWS.Debian après l'installation. Et c'est
+mieux que de lister les changements principaux dans README.Debian car
+l'utilisateur peut facilement rater de telles notes.
+
+Le format du fichier est le même que pour un fichier de changelog Debian, mais
+il n'utilise pas d'astérisques et décrit chaque élément de nouvelle dans un
+paragraphe complet si nécessaire plutôt que les résumés concis qui iraient dans un
+changelog. C'est une bonne idée de passer votre fichier par dpkg-parsechangelog
+pour vérifier son formatage car il n'est pas vérifié automatiquement pendant la
+construction comme le changelog. Voici un exemple d'un vrai fichier NEWS.Debian :
+
+Le fichier NEWS.Debian est installé comme
+/usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a toujours ce
+nom même dans les paquets natifs Debian. Si vous utilisez debhelper,
+dh_installchangelogs installera les fichiers debian/NEWS pour vous.
+
+À la différence des fichiers changelog, vous n'avez pas besoin de mettre à jour
+les fichiers NEWS.Debian à chaque nouvelle version. Ne les mettez à jour que si
+vous avez quelque chose de particulièrement important que l'utilisateur a
+besoin de savoir. Si vous n'avez pas de nouvelles du tout, il n'est pas
+nécessaire de fournir de fichier NEWS.Debian dans votre paquet. Pas de
+nouvelles, bonne nouvelle !
+
+Si vous avez besoin d'une certaine locale pendant la construction, vous pouvez
+créer un fichier temporaire par cette astuce :
+
+Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et LC_ALL au nom
+de la locale que vous générez, vous devriez obtenir ce que vous voulez sans être
+root. Quelque chose comme ceci :
+
+
+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, 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.
+
+Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte dans la
+description courte. Si vous cherchez des exemples, exécutez simplement :
+
-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.
@@ -4187,14 +5014,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.
@@ -4215,6 +5042,7 @@ Vous pouvez
paquet de source donné par le . Vous pouvez le
faire en utilisant l'adresse <nom-paquet>@&pts-host;.
+
@@ -4224,6 +5052,20 @@ Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
soit pas désenregistré du système. D'un autre côté, il est possible qu'il
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 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
+interrogé avec un outil de nom
La première étape est de contacter poliment le responsable et d'attendre une
réponse pendant un temps raisonnable. Il est assez difficile de définir le
« temps raisonnable », mais il est important de prendre en compte que
@@ -4239,8 +5081,8 @@ informations utiles sur ce responsable. Ceci inclut :
@@ -4303,9 +5145,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
@@ -4348,7 +5192,9 @@ paquet avec
Le champ Maintainer du fichier
+Debian prend en charge un nombre toujours croissant de langues naturelles. Même
+si l'anglais est votre langue maternelle et que vous ne parlez pas d'autre
+langue, il est de votre devoir de responsable d'être conscient des problèmes
+d'internationalisation (abrégé en i18n à cause des 18 lettres entre le i et
+le n dans internationalisation). C'est pourquoi, même si des programmes
+seulement en anglais vous suffisent, vous devriez lire la plupart de ce chapitre.
+
+Selon l'
+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 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.
+
+En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas de règle
+générale, il n'y a pas actuellement d'infrastructure centralisée pour la l10n
+dans Debian qui puisse être comparée au mécanisme dbuild pour le portage. Le
+plus gros du travail doit donc être réalisé manuellement.
+
+
+
+La gestion des traductions des textes contenus dans un paquet est encore une
+tâche manuelle et le processus dépend du type de texte que vous désirez voir traduit.
+
+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
+
+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
+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, 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
+DDTP (à propos de ce qui est vraiment traduit) et sur le site des
+Pour les pages web, chaque équipe l10n a accès au CVS correspondant et les
+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 accès au CVS), mais
+il n'y a pas de page de statistiques.
+
+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
+Voici une liste des problèmes que les responsables peuvent rencontrer concernant
+l'i18n et la l10n. Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
+consensus sur ces points au sein de Debian et que ce ne sont que des conseils.
+Si vous avez une meilleure idée pour un problème donné ou si vous êtes en
+désaccord avec certains points, vous êtes libre de fournir vos impressions pour
+que ce document puisse être amélioré.
+
+
+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 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
+qu'ils ont fini, vous recevrez de leur part votre document traduit dans votre
+boîte aux lettres.
+
+
+De temps en temps, des personnes indépendantes traduiront certains textes
+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
+avoir plus confiance dans la qualité de la traduction et l'inclure sans crainte
+dans votre paquet.
+
+
+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
+avertissement dans le document traduit, indiquant que la traduction est un peu
+obsolète et que le lecteur devrait se référer au document d'origine si possible.
+
+Évitez de supprimer complètement une traduction à cause de son obsolescence. Un
+vieux document est souvent mieux que pas de documentation du tout pour les
+personnes non anglophones.
+
+
+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).
+
+
+
+Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
+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.
+
+
+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),
+traduisez-le, faites-le relire par d'autres personnes dont c'est également la
+langue maternelle sur votre liste de diffusion l10n et fournissez-le au
+responsable du paquet (voir le point suivant).
+
+
+Assurez-vous que votre traduction est correcte (en demandant une relecture sur
+votre liste de discussion l10n) avant de la fournir pour inclusion. Cela
+gagnera du temps à tout le monde et évitera le chaos qui résulterait d'avoir
+plusieurs versions du même document dans les rapports de bogue.
+
+La meilleure solution est de remplir un bogue standard contenant la traduction
+sur le paquet. Assurez-vous d'utiliser l'étiquette « patch » et
+n'utilisez pas une gravité supérieure à « wishlist » car l'absence de
+traduction n'empêche jamais un programme de fonctionner.
+
+
+
-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.
@@ -4411,7 +5454,7 @@ Le paquet
Vous devriez récupérer la dernière version de
@@ -4469,14 +5512,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 à
-
Le paquet
-À la différence des autres approches,
+À la différence d'autres approches,
Il existe aussi un certain nombre de petites extensions
@@ -4574,11 +5617,14 @@ en conformit
Le paquet
-Remarque :
+Pour plus d'informations, voir le
+
Le paquet
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
-
+Un paquet lié est
+Le script
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
-Contient les meilleurs pratiques pour des personnes assurant la maintenance de
+
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.
-
-
+
+
+
+
+
+
+
+
+