X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.fr.sgml;h=87a9d3c2e9736c2688706c7644091b8d1e7f0328;hb=5f967f6b8ccadb1406109379128f1c40ed1c3db4;hp=ccaa238fabc1966a43d4f0a62844d054177357d6;hpb=f0a848531ec8388509a50fde213aaf15d5017d39;p=developers-reference.git diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index ccaa238..87a9d3c 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -2,16 +2,15 @@ %versiondata; - + %commondata; + %dynamicdata; - + - + FIXME: "> @@ -23,17 +22,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,14 +250,42 @@ 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
+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 à .
@@ -276,7 +312,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
@@ -288,12 +324,11 @@ Pour votre candidature, vous devrez
signée, vous devriez essayer de rencontrer un responsable Debian pour le faire.
La
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
@@ -309,9 +344,9 @@ Debian utilise
-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.
@@ -354,26 +388,6 @@ Pour en savoir plus, consultez le
-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
-Si vous désirez être mentor ou parrain, reportez-vous à .
-
-
+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. 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 peuvent rejeter la nouvelle clé. Vous pouvez trouver plus
+ de détails à
+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
+Idéalement, vous devriez vous connecter sur le
+
@@ -541,11 +575,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
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.
@@ -644,8 +678,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,
@@ -659,6 +693,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é :
+
+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 +781,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
+
+Le serveur non-US non-us.debian.org a été interrompu avec la
+ publication de Sarge. Le pseudo-paquet
+
@@ -780,12 +836,12 @@ Vous ne devriez utiliser que cet emplacement particulier car il sera sauvegard
Habituellement, la seule raison pour utiliser un serveur différent est que vous
avez besoin de publier des informations soumises aux restrictions d'exportation
américaines, dans ce cas, vous pouvez utiliser l'un des autres serveurs situés
- en dehors des États-Unis, comme le serveur mentionné ci-dessus
- non-us.debian.org.
+ en dehors des États-Unis.
Veuillez envoyer un courrier à &email-debian-devel; si vous avez une question.
Notre serveur CVS est situé sur cvs.debian.org.
@@ -802,6 +858,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 +901,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 +1002,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 +1012,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 +1078,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
Ce cycle de développement est basé sur l'idée que la distribution
unstable devient stable après une période de test
@@ -1040,66 +1124,23 @@ Ce cycle de d
Notez que, pendant la période de gel, les développements continuent sur la
distribution unstable car cette distribution reste en place.
-
-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 +1161,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 +1189,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 +1244,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
@@ -1217,15 +1267,22 @@ Les miroirs sont en g
Le système Incoming est responsable de la collecte des paquets mis à jour et de
leur installation dans l'archive Debian. Il est constitué d'un ensemble de
- répertoires et de scripts qui sont installés à la fois sur
- &ftp-master-host; et sur &non-us-host;.
+ répertoires et de scripts qui sont installés sur &ftp-master-host;.
Les paquets sont envoyés par tous les responsables Debian dans un répertoire
- nommé
+Bien que ftp-master soit à accès restreint, une copie de l'installation
+ est disponible à tous les développeurs sur &ftp-master-mirror;.
+
@@ -1309,7 +1375,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 à
@@ -1318,7 +1384,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 +1522,7 @@ Vous pouvez contr
chaque paquet source.
+Tous les développeurs Debian ont automatiquement un compte sur Alioth. Ils
+peuvent l'activer en utilisant la fonctionnalité de récupération des mots de
+passe. Les développeurs externes peuvent demander un compte invité sur Alioth.
+
Pour plus d'informations, veuillez visiter
+
+Depuis octobre 2002, HP parraine l'abonnement à LWN pour tous les
+développeurs Debian intéressés.
+
+Les détails sur les moyens d'accéder à cet avantage sont expliqués dans
Ce chapitre contient des informations relatives à la création, l'envoi, la
@@ -1637,7 +1718,7 @@ Supposons que personne ne travaille sur le paquet que vous visez, vous devez
peut être téléchargé. Cette liste n'est pas limitative.
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 +1926,36 @@ 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.
+
+
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 a été interrompu avec la publication de
+ Sarge.
-
-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 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
Pour en savoir plus sur les fichiers override, reportez-vous à
-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 +2248,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 à
-
Parfois, vous devez également ajuster la gravité du bogue pour qu'elle
corresponde à notre définition de gravité des bogues. C'est dû au
@@ -2215,6 +2260,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 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,35 +2572,52 @@ 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 +2761,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 +2858,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 +2867,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 +2876,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 +2978,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 +3020,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 +3046,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)
@@ -3018,7 +3134,59 @@ Nous sommes tr
intéressantes pour tous (par exemple, une version de Debian compilée avec des
vérifications relatives à
+Les administrateurs des buildds pour chaque architecture peuvent être
+ contactés à l'adresse électronique $arch@buildd.debian.org.
+
+
+Certains paquets ont encore des problèmes pour être construits et/ou pour
+fonctionner sur certaines des architectures prises en charge par Debian et ne
+peuvent pas du tout être portés, ou pas dans un laps de temps raisonnable. Un
+exemple est un paquet qui est spécifique SGVA (i386 seulement) ou qui utilise
+des fonctionnalités spécifiques au matériel qui ne sont pas gérées sur toutes
+les architectures.
+
+Pour éviter que des paquets cassés soient envoyés dans l'archive et qu'ils fassent
+perdre du temps des buildd, vous devez faire plusieurs choses :
+
+
+Tout d'abord, assurez-vous que votre paquet échoue à la compilation
+sur les architectures qu'il ne gère pas. Il y a plusieurs moyens de faire
+cela. Le moyen préféré est d'avoir une petite suite de tests pendant la
+construction qui testera la fonctionnalité et qui échouera si cela ne
+fonctionne pas. C'est de toute façon une bonne idée et empêchera des
+(certains) envois cassés pour toutes les architectures, et cela permettra
+également au paquet d'être construit dès que la fonctionnalité nécessaire est
+disponible.
+
+De plus, si vous croyez que la liste des architectures gérées est plutôt
+constante, vous devriez changer « any » en une liste des
+architectures gérées dans le fichier
+Pour empêcher les compilateurs automatiques de tenter sans raison de
+construire votre paquet, il peut être inclus dans
+
+Veuillez noter qu'il est insuffisant de simplement ajouter votre paquet à
+Packages-arch-specific sans le faire également échouer lors de compilation sur
+les architectures non gérées : un porteur ou toute autre personne
+essayant de construire votre paquet peut accidentellement l'envoyer sans
+remarquer qu'il ne fonctionne pas. Si dans le passé certains paquets binaires
+ont été envoyés pour des architectures non gérées, demandez leur suppression
+en remplissant un bogue sur
@@ -3028,103 +3196,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 +3333,13 @@ S'il n'y a pas de partie
-
-
+
+