X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.fr.sgml;h=5fc96443285fbeb0d19e3bbfa9a87df0f12429ef;hb=4d3846471cf785e8bc5623e71adcb46bba604efe;hp=09e9bfff42770d276bb3521a3b4946358b205f1c;hpb=fa5fe30fb0e0a4cae7d6fa90359604922f3bb68f;p=developers-reference.git diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml index 09e9bff..5fc9644 100644 --- a/developers-reference.fr.sgml +++ b/developers-reference.fr.sgml @@ -5,12 +5,12 @@ %commondata; - + ]> @@ -36,7 +36,7 @@ avec la participation de Alain Meessen et des membres de la liste debian-l10n-french@lists.debian.org -version &version;, 4 mai 2001 +version &version;, &date-fr; @@ -46,20 +46,25 @@ Copyright ©1997, 1998 Christian Schwarz.

-Ce manuel est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier -selon les termes de la licence grand public GNU publiée par la FSF -(Free Software Foundation) dans sa version 2 (ou toute version supérieure). -

+Ce manuel est un logiciel libre ; il peut être redistribué et/ou modifié selon +les termes de la licence grand public du projet GNU (GNU GPL), telle que +publiée par la « Free Software Foundation » (version 2 ou toute +version supérieure). +

Il est distribué dans l'espoir qu'il sera utile, mais sans aucune -garantie, sans même la garantie implicite d'une valeur marchande -ou d'une adéquation à un besoin particulier. Consulter la Licence grand -public GNU pour plus de détails. -

-Une copie de la Licence grand public GNU est disponible dans le fichier -&file-GPL; de la distribution Debian GNU-Linux ou sur le site web du . Vous pouvez aussi l'obtenir en écrivant à -&fsf-addr;. +garantie, sans même la garantie implicite d'une possible valeur marchande +ou d'une adéquation à un besoin particulier. Consultez la licence grand public +du projet GNU pour plus de détails. + +

+Une copie de la licence grand public du projet GNU est disponible dans le +fichier &file-GPL; de la distribution Debian GNU-Linux ou sur la toile : . Vous pouvez +également l'obtenir en écrivant à la &fsf-addr;. + + + @@ -159,7 +164,7 @@ r id="submit-bug">). Release critical bug : bogue remettant en cause la - distribution. Bogues de sévérité critique, grave + distribution. Bogues de gravité critique, grave et sérieuse. Ces bogues ne doivent pas apparaître dans une distribution stable. Ils doivent être corrigés ou bien les paquets en cause doivent être supprimés (). @@ -172,7 +177,8 @@ r Testing : Nom de la distribution en test. Cette distribution reçoit les paquets des développeurs qui ont passé une période de deux semaines dans unstable et pour lesquels aucun - bogue sévère n'a été découvert. Cette distribution n'a pas été testée + bogue remettant en cause la distribution (cf. Release critical bug) + n'a été découvert. Cette distribution n'a pas été testée en profondeur. Elle est cependant sensée être plus stable que unstable (). @@ -189,13 +195,13 @@ r Debian maintainer : responsable Debian, développeur Debian (parfois mainteneur). Personne qui fait officiellement partie du projet Debian. Elle a accès aux serveurs Debian et participe - au développement -- au sens large -- de la distribution (). La plupart des responsables font de la mise en paquet mais il existe d'autres activités telles que documentation, site web, création des cédéroms, administration des serveurs... Upstream version : version amont. Il s'agit du - logiciel tel qu'il est fournit par le responsable amont -- par + logiciel tel qu'il est fournit par le responsable amont — par opposition à la version fournie par la distribution Debian. (Voir .) @@ -482,10 +488,10 @@ dans la documentation du paquet debian-keyring. Prendre des vacances courtoisement

-La plupart des développeurs prennent des vacances ; généralement, cela signifie +La plupart des développeurs prennent des vacances ; généralement, cela signifie qu'ils ne peuvent ni travailler pour Debian ni être joints par courrier électronique si un problème se présentait. Les autres développeurs -ont besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment +ont besoin de savoir que vous êtes en vacances ; ainsi ils sauront comment réagir en cas de problème. En général, cela signifie que les autres développeurs sont autorisés à modifier votre paquet (voir ) en cas de gros problème (bogues bloquants pour la distribution, mise à jour de @@ -509,29 +515,25 @@ celles-ci sont termin

Une grosse part de votre travail de responsable Debian sera de rester en -contact avec les développeurs amonts car il vous faudra leur transmettre les -informations collectées par le système de suivi des bogues. Il n'est pas de -votre responsabilité de corriger les bogues qui ne sont pas spécifiques à -Debian. Il vous faudra plutôt transmettre ces rapports de bogues aux -développeurs amonts. (Bien sûr, si vous êtes capable de les résoudre...) -De cette manière, ces bogues seront corrigés dans la prochaine -version amont. +contact avec les développeurs amonts. Parfois, les utilisateurs établissent +des rapports de bogue qui ne sont pas spécifiques à Debian. Vous devez +transmettre ces rapports de bogue aux développeurs amonts pour qu'ils soient +corrigés dans les prochaines versions. Il n'est pas de votre responsabilité +de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois, +si vous êtes capable de le faire, nous vous encourageons à contribuer au +développement amont en proposant un patch qui corrige ce bogue. +Les utilisateurs et responsables Debian proposent souvent des patches +pour corriger des bogues amonts, il vous faudra alors évaluer ce +patch puis le transmettre aux développeurs amonts.

-De temps en temps, vous trouverez un patch attaché à un rapport de bogue. -Il vous faudra envoyer ce patch en amont et vous assurer qu'il est bien -inclus dans la prochaine version amont (si les auteurs acceptent le patch -proposé). - -

-Si vous avez besoin de modifier les sources amonts pour respecter le Debian -Policy Manual, vous devriez proposer un joli patch aux développeurs amonts. Une -fois ce patch inclus, vous n'aurez plus besoin de modifier les sources -lors des mises à jour amonts suivantes. - -

-Quels que soient les changements dont vous avez besoin, il faut toujours -essayer de rester dans la lignée des sources amonts. +Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un +paquet conforme à la charte Debian, alors vous devriez proposer un +patch aux développeurs amonts pour qu'il soit inclus dans leur +version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des +mises à jour amonts suivantes. Quels que soient les changements dont vous +avez besoin, il faut toujours essayer de rester dans la lignée des sources +amonts. @@ -541,7 +543,7 @@ essayer de rester dans la lign

Les bogues bloquants pour la distributionTraduction de l'anglais -Release critical bug (RCB) sont les bogues de sévérité +Release critical bug (RCB) sont les bogues de gravité critique, grave et sérieuseRespectivement critical, grave et serious en anglais. Ces bogues peuvent retarder la diffusion d'une distribution Debian et/ou @@ -552,8 +554,8 @@ id="&url-debian-qa;" name ="assurance qualit et essaient de vous aider chaque fois qu'ils le peuvent. Si vous ne pouvez pas corriger un bogue de ce type dans les deux semaines, vous devriez soit demander de l'aide en envoyant un courrier à l'équipe d'assurance qualité -(QA group &email-debian-qa;), soit vous expliquer et présenter un -plan pour corriger le problème en répondant au rapport de bogue +(QA group &email-debian-qa;), soit expliquer vos difficultés et +présenter un plan pour corriger le problème en répondant au rapport de bogue concerné. Si rien n'est fait, des personnes de l'équipe d'assurance qualité pourraient chercher à corriger votre paquet (voir ) après avoir tenté de vous contacter. Ils pourraient attendre moins longtemps que @@ -569,9 +571,8 @@ M activité ne leur est pas réservée. Vous pouvez participer à cet effort en éliminant, autant que faire se peut, tout bogue de vos paquets et en observant les remarques émises par lintian (voir ). Si cela -vous semble tout à fait impossible, il faudrait songer à abandonner certains -de vos paquets, vous pourrez ainsi faire du bon travail avec les paquets dont -vous restez responsable (voir ). Vous pouvez aussi +ne vous semble pas possible, il faudrait songer à abandonner certains +de vos paquets (voir ). Vous pouvez aussi demander l'aide d'autres personnes pour rattraper votre retard dans la liste des bogues (vous pouvez demander de l'aide sur les listes &email-debian-qa; et &email-debian-devel;). @@ -859,7 +860,7 @@ sont stock l'archive et aux logiciels qui l'accompagnent. Le premier répertoire contient les distributions stable, testing et unstable. Le découpage en sous-répertoires est identique d'un répertoire de distribution à -l'autre ; nous nous contenterons donc d'exposer ce découpage pour la +l'autre ; nous nous contenterons donc d'exposer ce découpage pour la distribution stable. Les fichiers Packages et Sources qui se trouvent dans les répertoires de distribution peuvent faire référence à des fichiers du répertoire pool/. @@ -1035,7 +1036,7 @@ incluse dans le r En résumant, une archive Debian a un répertoire racine sur un serveur FTP. Par exemple, sur le site miroir ftp.us.debian.org, l'archive Debian se trouve dans /debian ce qui est un emplacement -courant. Un autre emplacement courant est /pub/debian. +courant. Un autre emplacement courant est /pub/debian.

Une distribution est composée de paquets Debian sources et binaires et des @@ -1149,7 +1150,7 @@ s experimental.

-Un système de fichier crypté, par exemple, devrait probablement aller dans +Un système de fichier compressé, par exemple, devrait probablement aller dans experimental. Une nouvelle version non finalisée d'un logiciel qui utilise une méthode de configuration complètement différente pourrait aller dans experimental à la discrétion du responsable. Un nouveau logiciel @@ -1160,13 +1161,11 @@ fournir un acc

Par contre, utiliser experimental comme plate-forme n'est pas -toujours la meilleure idée. Vous ne pouvez pas remplacer ou mettre à jour des -paquets dans cet espace vous-même (c'est le logiciel de maintenance de -l'archive qui s'en charge). De plus, il vous faudra penser à demander la -suppression de vos paquets à l'équipe d'administration de l'archive une fois -qu'ils seront installés dans unstable. Utiliser vos pages web -personnelles sur le serveur klecker.debian.org est en général une -meilleure idée, cela permet de décharger l'équipe de maintenance de l'archive. +toujours la meilleure idée, surtout pour les paquets éphémères. +Vous ne pouvez pas effacer un paquet qui a été installé dans cet espace +vous même ; cela doit être fait par l'équipe d'administration de l'archive. +Une solution consiste à utiliser vos pages web personnelles sur le serveur +klecker.debian.org (c.-à-d. people.debian.org). @@ -1175,8 +1174,8 @@ meilleure id

Chaque distribution Debian diffusée a un nom : Debian 1.1 s'appelle « buz » ; Debian 1.2, « rex » ; Debian 1.3 « bo » ; -Debian 2.0, « hamm » ; Debian 2.1, « slink » et Debian 2.2 -« potato ». Il y a aussi une pseudo-distribution nommée +Debian 2.0, « hamm » ; Debian 2.1, « slink »; Debian 2.2 +« potato » et Debian 3.0 « woody ». Il y a aussi une pseudo-distribution nommée « sid », il s'agit de la distribution unstable ; comme les paquets vont de unstable à testing quand ils approchent de la stabilité, la distribution « sid » n'est jamais diffusée. En plus @@ -1239,14 +1238,23 @@ travail. Consultez aussi cette page si vous voulez en savoir plus.

Supposons que personne ne travaille sur le paquet que vous visez, vous devez alors envoyer un rapport de bogue (voir ) concernant le -pseudo-paquet wnpp et envoyer une copie à &email-debian-devel;. Ce +pseudo-paquet wnpp. Ce courrier devra décrire le paquet que vous projetez de créer, la licence de ce paquet et l'URL à laquelle le source peut être téléchargé. Cette liste n'est -pas limitative. Le sujet de votre rapport de bogue devra être -<ITPIntent To Package : intention de mise en -paquet : NomDuPaquet -- courte description ->, en remplaçant NomDuPaquet par le nom du paquet. La -sévérité du bogue sera whishlist. Il faudra aussi ajouter une entrée +pas limitative. + +

+Le sujet de votre rapport de bogue devra être <ITPIntent To +Package : intention de mise en paquet : +NomDuPaquet — courte description >, en remplaçant +NomDuPaquet par le nom du paquet. La gravité du bogue sera +whishlist. Si vous le jugez nécessaire, envoyez une copie à +&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de +l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le +sujet du message ne contiendra pas le numéro du bogue. + +

+Il faudra aussi ajouter une entrée Closes: bug#nnnnn dans le fichier changelog du nouveau paquet. Cette indication fermera automatiquement le rapport de bogue à l'installation du nouveau paquet sur les serveurs d'archivage (voir @@ -1388,7 +1396,7 @@ pour frozen.

Il est tentant de toujours mettre en paquet la dernière version d'un logiciel -pour Debian ; mais il est bien plus important que le système soit stable et +pour Debian ; mais il est bien plus important que le système soit stable et qu'il fonctionne de la manière attendue.

@@ -1399,28 +1407,28 @@ conseils :

- Les corrections de bogues de sévérité critique, + Les corrections de bogues de gravité critique, grave ou sérieuserespectivement critical, grave ou serious sont toujours autorisées pour les paquets qui doivent exister dans la distribution. - Les corrections pour les bogues de sévérité critique, + Les corrections pour les bogues de gravité critique, grave ou sérieuserespectivement critical, grave ou serious sont autorisées pour les paquets non indispensables uniquement si elles n'ajoutent pas de nouvelle fonctionnalité. - Les corrections pour les bogues de sévérité importante, + Les corrections pour les bogues de gravité importante, normale et mineurerespectivement important, normal et minor sont autorisées, bien que découragées, sur tous les paquets si et seulement s'elles n'ajoutent pas de nouvelle fonctionnalité. - Les corrections de sévérité wishlist ne sont pas autorisées (ce + Les corrections de gravité wishlist ne sont pas autorisées (ce ne sont pas vraiment des bogues après tout). @@ -1433,8 +1441,8 @@ conseils : L'expérience montre qu'il y a 15% de chance d'introduire un nouveau bogue en corrigeant un autre bogue. L'introduction et la découverte d'un nouveau bogue retarde la mise à disposition de la distribution ou affaiblit le produit -final. Il y a très peu de corrélation entre la sévérité du bogue corrigé et -la sévérité du bogue introduit par la correction. +final. Il y a très peu de corrélation entre la gravité du bogue corrigé et +la gravité du bogue introduit par la correction. @@ -1466,7 +1474,7 @@ du paquet pour cela) :

Pour en savoir plus sur lintian reportez-vous à la section lintian . Faites régresser le paquet - vers sa version précédente si elle existe -- cela permet de tester les + vers sa version précédente si elle existe — cela permet de tester les scripts postrm et prerm. @@ -1486,7 +1494,7 @@ Pour installer un paquet vous avez besoin d'un compte sur ftp-master, ce que vous devez avoir en tant que développeur Debian. Si vous utilisez scp ou rsync pour télécharger vos paquets, placez-les dans -&us-upload-dir;. Si vous utilisez un FTP anonyme, +&us-upload-dir;. Si vous utilisez un FTP anonyme, placez-les dans /pub/UploadQueue/.

@@ -1525,12 +1533,14 @@ sur votre fichier .changes : (pandora)

-Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle -des exportations américain ne doivent pas être installés sur ftp-master. -Pour installer votre paquet, utilisez scp ou alors ouvrez une -session FTP sur non-us.debian.org en vous identifiant avec -votre login. Par défaut, vous pouvez utiliser le même login/mot de -passe que pour ftp-master. +Comme nous l'avons dit un peu plus haut, les programmes soumis au contrôle des +exportations américain ne doivent pas être installés sur ftp-master. +Utilisez scp ou rsync pour copier votre paquet sur +non-us.debian.org. Placer les fichiers dans le répertoire +&non-us-upload-dir;. Par défaut, vous pouvez utiliser le même +login/mot de passe que pour ftp-master. Si vous utilisez +une connexion FTP anonyme pour le téléchargement, placez vos fichiers dans le +répertoire /pub/UploadQueue/.

Le programme dupload est, lui aussi, capable de télécharger sur @@ -1545,7 +1555,7 @@ avec :

-Attention, les personnes résidant aux États-unis et les citoyens américains +Attention, les personnes résidant aux États-Unis et les citoyens américains sont soumis à des restrictions sur l'exportation des logiciels de cryptographie. Au moment où j'écris, les citoyens américains peuvent exporter quelques logiciels de cryptographie soumis à une obligation de déclaration @@ -1555,7 +1565,7 @@ aupr Le Debian Policy Manual n'empêche pas les résidents et citoyens américains de livrer des paquets sur non-US mais ils devront être vigilants en le faisant. Nous recommandons aux responsables concernés de -prendre toutes les précautions nécessaires, y compris consulter un +prendre toutes les précautions nécessaires, y compris la consultation d'un juriste, pour s'assurer qu'ils n'enfreignent pas une loi américaine en livrant un paquet sur non-US. @@ -1697,8 +1707,8 @@ id="dupload">.

Les administrateurs de l'archive Debian sont responsables de l'installation des mises à jour. La plupart des mises à jour sont gérées -quotidiennement par le logiciel de gestion de l'archive dak -(aussi appelé katie ou dinstall). Les mises à jour +quotidiennement par le logiciel de gestion de l'archive katie. +Les mises à jour de paquets sur la distribution unstable, en particulier, sont installés ainsi. Dans les autres cas et notamment dans le cas d'un nouveau paquet, celui-ci sera installé manuellement. Il peut s'écouler jusqu'à un mois @@ -1707,10 +1717,14 @@ effective. Soyez patients.

Dans tous les cas vous recevrez un accusé de réception par courrier -électronique indiquant que votre paquet a été installé. Lisez attentivement ce -courrier. Vous pourriez remarquer que votre paquet n'a pas été installé dans -la section que vous aviez désignée. La raison de ce changement sera dans le -courrier. +électronique indiquant que votre paquet a été installé et quels rapports +de bogues ont été clos. Lisez attentivement ce courrier et vérifiez que tous +les rapports de bogues que vous vouliez clore sont bien dans cette liste. + +

+L'accusé de réception indique aussi la section dans laquelle le paquet a +été installé. S'il ne s'agit pas de votre choix, vous recevrez un second +courrier qui vous informera de cette différence (voir plus loin). @@ -1727,10 +1741,20 @@ indications.

Les administrateurs de l'archive indiquent les sections et priorités des paquets -dans le fichier override. De temps en temps, ce fichier doit être -corrigé. Modifier le fichier control du paquet n'aura aucun -effet. Il vous faudra écrire à &email-override; ou faire un rapport de bogue -sur le pseudo-paquet ftp.debian.org. +dans le fichier override. Si ce fichier override et le +fichier debian/control de votre paquet diffèrent, vous en serez +informé par courrier électronique quand votre paquet sera installé dans +l'archive. Vous pourrez corriger votre fichier debian/control +avant votre prochain téléchargement ou alors vous aurez envie de modifier le +fichier override. + +

+Pour modifier la section dans laquelle un paquet est archivé, vous devez +d'abord vérifier que fichier debian/control est correct. Ensuite, +envoyez un courrier à &email-override; ou un rapport de bogue sur le pseudo +paquet ftp.debian.org demandant la modification de la +section ou de la priorité de votre paquet. Exposez bien les raisons qui vous +amènent à demander ces changements.

Pour en savoir plus sur le fichier override, reportez-vous à debian/changelog. -Ce changement peut tout aussi bien concerner la version amont du source que la -partie du source spécifique à Debian. +Ce changement peut tout aussi bien concerner la partie amont du source que la +partie spécifique à Debian. Une mise à jour indépendante source peut aussi +inclure des paquets spécifiques à une architecture, un fichier diff +modifié ou, plus rarement, des nouveaux sources amonts.

-Une mise à jour indépendante binaire est une recompilation et un archivage -d'un paquet pour une nouvelle architecture. Il s'agit souvent du résultat d'un +Une mise à jour indépendante binaire est 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 @@ -1807,7 +1833,7 @@ par l'expression (NMUNon-maintainer upload). Pourtant cela conduit souvent à des confusions car beaucoup associent « mise à jour indépendante » et « mise à jour indépendante source ». Il faut donc rester -vigilant. Dans ce chapitre, si j'utilise « mise à jour +vigilant. Dans ce chapitre, si nous utilisons « mise à jour indépendante » seul, il s'agit des deux types de livraisons. @@ -1847,7 +1873,7 @@ ind

Pendant la phase de gel (voir ), les livraisons qui -corrigent les bogues de sévérité sérieuse (i.e. serious) et +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 devrez 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 @@ -1917,7 +1943,7 @@ id="porter-guidelines">. 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 patch aussi petit que +corrigez pas ce qui n'est pas cassé. Faites un patch 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 @@ -1962,7 +1988,7 @@ doit choisir du paquet doit, lui, démarrer sa numérotation à « 1 ». Notez que pour faire cela vous devrez utiliser dpkg-buildpackage avec l'option -sa pour le forcer à utiliser le nouveau paquet source (par défaut il -reconnaît les numéros de révisions « 0 » ou « 1 » -- il +reconnaît les numéros de révisions « 0 » ou « 1 » — il n'est pas suffisamment intelligent pour reconnaître « 0.1 »).

@@ -2016,7 +2042,7 @@ est disponible, un bogue a vous devez tout de même ajouter une entrée dans le fichier changelog; il y aura donc une modification. Si vous êtes porteur, vous êtes probablement en train de faire une mise à jour indépendante binaire. (Note : ce système ne -tient pas compte des porteurs qui font des recompilations -- tenez cela pour +tient pas compte des porteurs qui font des recompilations — tenez cela pour une faiblesse de notre système de gestion des paquets.)

@@ -2027,7 +2053,7 @@ et le rapporteur du bogue sont autoris Cependant, la personne qui fait une mise à jour indépendante doit envoyer une note à chaque bogue concerné expliquant qu'il est corrigé par cette mise à jour indépendante. Cette personne doit ensuite utiliser l'adresse -control@bugs.debian.org pour modifier la sévérité des bogues +control@bugs.debian.org pour modifier la gravité des bogues corrigés et leur donner la valeur corrigé (i.e. fixed). Cela permet de s'assurer que chacun sait que le bogue est corrigé par une mise à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que @@ -2095,7 +2121,7 @@ C'est une activité remarquable et essentielle. En fait, les porteurs sont à l'origine de la plupart des compilations de paquet Debian. Pour un paquet binaire i386, par exemple, il faut compter une recompilation pour chaque -autre architecture, soit un total de cinq recompilations. +autre architecture, soit un total de &number-of-arches; recompilations. @@ -2106,7 +2132,7 @@ autre architecture, soit un total de cinq 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 modification. Malheureusement, c'est rarement le cas. Cette section contient -une liste d'erreurs commises régulièrement par les responsables Debian -- +une liste d'erreurs commises régulièrement par les responsables Debian — problèmes courants qui bloquent souvent les porteurs et compliquent inutilement leur travail. @@ -2114,7 +2140,8 @@ inutilement leur travail. Ici, le mot d'ordre 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). +manière). Merci pour votre indulgence envers des rapports de bogues succincts ou +peu clairs ; faites de votre mieux pour éliminer le problème.

Les problèmes les plus couramment rencontrés par les porteurs sont causés par @@ -2123,6 +2150,20 @@ des erreurs de mise en paquet dans le paquet source. Voici une + Vérifiez que les champs Build-Depends et + Build-Depends-Indep du fichier debian/control sont + corrects. Le meilleur moyen pour vérifier cela est d'utiliser le + paquet debootstrap pour créer un environnement + unstable chrooté. Dans cet environnement + chrooté il faudra installer le paquet + build-essential et tous les paquets mentionnés dans + les champs Build-Depends et Build-Depends-Indep. + Ensuite, vous essayerez de fabriquer votre paquet dans cette + environnement. +

+ Consultez le pour en savoir plus sur les dépendances de fabrication. + Ne choisissez pas d'autre valeur que all ou any pour le champ architecture sans avoir de bonnes raisons pour le faire. Trop souvent, les développeurs ne respectent pas les instructions du @@ -2146,7 +2187,7 @@ des erreurs de mise en paquet dans le paquet source. Voici une Assurez-vous que vous ne vous appuyez pas sur des éléments de configuration ou des logiciels installés ou modifiés localement. Par exemple, vous ne devriez jamais appeler des programmes du répertoire - /usr/local/bin ou équivalents. Essayez de ne pas vous + /usr/local/bin ou de répertoires équivalents. Essayez de ne pas vous appuyer sur des logiciels configurés de manière spéciale. Essayez de construire votre paquet sur une autre machine, même s'il s'agit de la même architecture. @@ -2156,8 +2197,12 @@ des erreurs de mise en paquet dans le paquet source. Voici une (un sous-cas de la remarque précédente). - Ne supposez pas qu'egcc est disponible, ni que vous - utilisez une version précise de gcc. + Si possible, ne vous appuyez pas sur une particularité présente dans + un compilateur précis ou dans certaine version d'un compilateur. Si + vous ne pouvez pas faire autrement, assurez-vous que les dépendances + de fabrication reflètent bien cette restriction. Dans ce cas, vous + cherchez sûrement les problèmes car quelques architectures pourraient + choisir un compilateur différent. Vérifiez que votre debian/rules distingue les cibles @@ -2188,26 +2233,41 @@ Pour une mise dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet source (cela inclut debian/changelog). -

-Parfois il est nécessaire de recompiler des paquets quand d'autres paquets, -tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez -changer le numéro de version pour que le système de gestion des paquets -fonctionne correctement. Ce type de mise à jour reste une mise à jour -indépendante binaire -- il n'est pas nécessaire de faire une recompilation sur -toutes les architectures. Vous devez utiliser la même règle de numérotation -que pour une mise à jour indépendante mais en ajoutant « .0. » -devant le numéro de révision Debian. Par exemple une recompilation du paquet -source « foo_1.3-1 » portera le numéro de version -foo_1.3-1.0.1. -

La manière d'invoquer dpkg-buildpackage est la suivante : -dpkg-buildpackage -B -madresse-porteur. Bien sûr, +dpkg-buildpackage -B -eadresse-porteur. Bien sûr, remplacez adresse-porteur par votre adresse électronique. Cette commande construira les portions du paquet qui dépendent de l'architecture, en utilisant la cible binary-arch de debian/rules. + + Numéro de version des mises à jour indépendantes + binaires + +

+Parfois il est nécessaire de recompiler des paquets quand d'autres paquets, +tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez +changer le numéro de version pour que le système de comparaison des numéros de +version fonctionne correctement. 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. + +

+Ces recompilations nécessitent des numéros de version « magiques » pour que le +système de maintenance de l'archive comprennent que, bien qu'il y ait une +nouvelle version, il n'y a pas eu de modification des sources. Si vous ne +faites pas cela correctement, les administrateurs de l'archive rejetteront +votre mise à jour (car il n'y aura pas de code source associé). + +

+Cette magie associée à une mise à jour par recompilation est déclenchée en +utilisant un troisième nombre dans la partie debian du numéro de version. Si, +par exemple, la dernière version du paquet que vous recompilez était +« 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 ». @@ -2230,9 +2290,9 @@ distribution gel

Si vous êtes porteur et faites une mise à jour pour unstable, les instructions précédentes sont applicables à deux différences près. Tout -d'abord, le temps d'attente raisonnable -- délai entre le moment où vous +d'abord, le temps d'attente raisonnable — délai entre le moment où vous envoyez un rapport au système de suivi des bogues et le moment où vous pouvez -faire une mise à jour indépendante (NMU) -- est de sept jours. Ce +faire une mise à jour indépendante (NMU) — est de sept jours. 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 @@ -2240,7 +2300,7 @@ commun

Deuxième différence, les porteurs qui font des mises à jour indépendantes -sources doivent choisir une sévérité sérieuse (i.e. +sources doivent choisir une gravité sérieuse (i.e. serious) ou supérieure quand ils envoient leur rapport au système de suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un paquet binaire pour chaque architecture supportée au moment de la sortie de la @@ -2292,7 +2352,7 @@ l'architecture X doivent

Le système buildd est un système distribué pour la compilation d'une distribution. Il est habituellement utilisé en conjonction -avec des automates de compilation ; ce sont des machines « esclaves » +avec des automates de compilation ; ce sont des machines « esclaves » qui récupèrent des paquets sources et tentent de les compiler. Il est aussi possible d'interagir par courrier électronique avec ce système. Cette interface est utilisée par les porteurs pour récupérer un paquet source (en @@ -2307,14 +2367,14 @@ continuellement utilis andrea, sbuild et wanna-build.

-Une partie des informations produites par buildd -- utiles -pour les porteurs -- est disponible sur la toile à l'adresse buildd — utiles +pour les porteurs — est disponible sur la toile à l'adresse . Ces informations incluent les résultats produits toutes les nuits par andrea (dépendances des sources) et quinn-diff (paquets à recompiler).

Nous sommes très enthousiasmés par ce système car il a de nombreux usages potentiels. Des groupes de développeurs indépendants peuvent utiliser ce système pour créer -différentes saveurs de la Debian -- qui peuvent être ou ne pas être +différentes saveurs de la Debian — qui peuvent être ou ne pas être intéressantes pour tous (une version de Debian compilée avec des vérifications relatives à gcc). Ce système nous permettra aussi de recompiler rapidement toute une distribution. @@ -2435,15 +2495,21 @@ Group &orphan-address; dans le champ maintainer du paquet et faire un rapport de bogue sur le pseudo-paquet wnpp. Le titre de votre rapport de bogue devra être « OOrphaned : abandonné.: -paquet -- courte description » pour indiquer -que le paquet est orphelin. La sévérité du bogue sera normale. Si le -paquet est particulièrement important pour la distribution il vous faudra -faire un rapport de bogue sur le pseudo-paquet wnpp, titrer +paquet — courte description » pour indiquer +que le paquet est orphelin. La gravité du bogue sera normale. +Si vous le jugez nécessaire, envoyez une copie à +&email-debian-devel; en mettant cette adresse dans le champ X-Debbugs-CC: de +l'en-tête du message. N'utilisez pas le champ CC: car de cette manière le +sujet du message ne contiendra pas le numéro du bogue. + +

+Si le paquet est particulièrement important pour la distribution il vous +faudra faire un rapport de bogue sur le pseudo-paquet wnpp, titrer « RFARequest For Adoption : offre -d'adoption.: paquet -- courte -description » et lui affecter la sévérité importante. -Il vous faudra aussi envoyer une annonce sur la liste &email-debian-devel; -pour demander un nouveau responsable. +d'adoption.: paquet — courte +description » et lui affecter la gravité importante. +Envoyez une copie de votre rapport de bogue à la liste debian-devel comme +décrit précédemment.

Reportez-vous à la page WNPPWork-needing and prospective @@ -2464,7 +2530,7 @@ susmentionn

Prendre un paquet parce qu'il vous semble que celui-ci est négligé n'est pas -correct -- ce serait une prise d'otage. Vous pouvez prendre contact avec le +correct — ce serait une prise d'otage. Vous pouvez prendre contact avec le responsable actuel et lui demander si vous pouvez prendre en charge ce paquet. Vous ne pouvez le faire sans son accord. Qu'il vous ignore n'est pas une raison suffisante pour le faire. Si vous avez le sentiment qu'un responsable @@ -2541,7 +2607,7 @@ propre en d

Pour faire encore mieux, vous pouvez consulter d'autres paquets, grouper les -bogues qui ont été rapportés plusieurs fois ou affecter la sévérité +bogues qui ont été rapportés plusieurs fois ou affecter la gravité corrigé (i.e. fixed) à un rapport dont le bogue a été corrigé. Attention, quand vous n'êtes ni le rapporteur d'un bogue ni le responsable du paquet vous ne devez pas clore le rapport (à moins que vous @@ -2606,7 +2672,7 @@ L'auteur pr est facilement repérable dans le fichier changelog.

-Si vous voulez fermer un rapport de bogue manuellement -- à l'ancienne -- il +Si vous voulez fermer un rapport de bogue manuellement — à l'ancienne — il suffit d'envoyer le fichier .changes à l'adresse XXX-done@bugs.debian.org où XXX est le numéro du bogue. @@ -2633,7 +2699,7 @@ avec la derni

Ouvrir un grand nombre de rapports pour le même problème sur un grand nombre de -paquet -- plus de dix -- est une pratique que nous déconseillons. Prenez +paquet — plus de dix — est une pratique que nous déconseillons. Prenez toutes les mesures possibles pour éviter cette situation. Si le problème peut être détecté automatiquement par exemple, ajoutez un nouveau test dans le paquet lintian pour générer une erreur ou un avertissement. @@ -2654,6 +2720,63 @@ pas redirig + + Interaction avec les nouveaux responsables + +

+Ce chapitre décrit les procédures que doivent suivre les responsables +Debian quand ils ont affaire à un futur responsable Debian. + + Parrainer un paquet +

+Parrainer un paquet signifie télécharger un paquet dans l'archive Debian pour +un responsable qui n'est pas capable de le faire lui-même : un futur +responsable. Parrainer un paquet signifie aussi assumer la responsabilité de +ce parrainage. + +

+Les nouveaux responsables éprouvent souvent quelques difficultés pour créer +des paquets Debian — ce qui est bien compréhensible. C'est là que le parrain +intervient. Il doit vérifier que le paquet est suffisamment bon pour intégrer +la distribution. Notez que si le paquet est nouveau les administrateurs FTP +devront eux aussi inspecter ce paquet avant de le laisser entrer. + +

+Parrainer un paquet en se contentant de recompiler le paquet ou de signer le +téléchargement n'est franchement pas recommandé. Vous devez +reconstruire le paquet source comme vous le feriez avec vos propres paquets. +N'oubliez pas qu'il sera possible de voir que vous avez téléchargé un paquet +même si vous avez laissé le nom du futur responsable dans les fichiers de +contrôle et changelog. + +

+Si vous êtes responsable de candidatureApplication +manager pour un développeur, vous pouvez aussi être son parrain. De +cette manière, vous aurez la possibilité de vérifier vous-même comment ce +candidat accomplit la partie « Tâches et compétences »`Tasks and +Skills' de sa candidature. + + + + Aider un nouveau responsable + +

+Consultez la page sur le site du projet Debian. + + + + Suivre la candidature d'un nouveau responsable + +

+Consultez la page sur le site du projet Debian. + + + + + + Aperçu des outils du responsable Debian

@@ -2684,7 +2807,7 @@ documentations de ces paquets. Le paquet dpkg-dev contient les outils (y compris dpkg-source) nécessaires pour déballer, fabriquer et livrer des paquets Debian source. Ces utilitaires fournissent les fonctionnalités de bas -niveau indispensables pour créer et manipuler les paquets ; en tant que tels, +niveau indispensables pour créer et manipuler les paquets ; en tant que tels, ils sont indispensables à tout responsable Debian. @@ -2741,7 +2864,7 @@ Ce d debmake

-debmake -- un précurseur de debhelper -- +debmake — un précurseur de debhelper — est un assistant moins modulaire pour manipuler le fichier debian/rules. Il inclut deux programmes principaux : deb-make, utile au développeur Debian pour convertir un paquet