7. Au-delà de l'empaquetage

Debian, c'est beaucoup plus que de l'empaquetage de logiciels et de la maintenance de paquets. Ce chapitre contient des informations sur les façons, souvent vraiment importantes, de contribuer à Debian au-delà des simples création et entretien de paquets.

En tant qu'organisation de volontaires, Debian repose sur la liberté de choisir ce sur quoi l'on désire travailler et de choisir la partie la plus importante à laquelle on veut consacrer son temps.

7.1. Signalement de bogues

Nous vous encourageons à signaler des bogues quand vous en trouvez dans les paquets Debian. En fait, les développeurs Debian sont souvent les testeurs de première ligne. Trouver et signaler les bogues dans les paquets d'autres développeurs améliore la qualité de Debian.

Lisez les instructions pour signaler un bogue dans le système de suivi des bogues Debian.

Essayez de signaler un bogue à partir d'un compte utilisateur normal avec lequel vous pouvez recevoir des courriers, pour que les personnes puissent vous joindre si elles ont besoin de plus d'informations à propos du bogue. Ne signalez pas de bogues en tant que root.

Vous pouvez utiliser un outil comme reportbug(1) pour signaler des bogues. Il peut automatiser et, dans l'ensemble, faciliter le processus.

Assurez-vous que le bogue n'a pas déjà été signalé. Chaque paquet dispose d'une liste de bogues facilement accessible à https://bugs.debian.org/nomdupaquet. Des outils comme querybts(1) peuvent également vous fournir ces informations (et reportbug invoquera également normalement querybts avant l'envoi).

Essayez d'envoyer vos bogues au bon endroit. Quand, par exemple, votre bogue concerne un paquet qui écrase des fichiers d'un autre paquet, vérifiez les listes des bogues pour les deux paquets afin d'éviter de créer des rapports de bogue dupliqués.

Vous pouvez également parcourir les bogues d'autres paquets, en les regroupant s'ils sont indiqués plus d'une fois, ou en les marquant avec fixed quand ils ont déjà été corrigés. Notez cependant que si vous n'êtes ni le rapporteur du bogue, ni le responsable du paquet, vous ne devriez pas fermer réellement le bogue (à moins d'avoir obtenu la permission du responsable).

De temps en temps, vous pourriez vouloir vérifier ce qui s'est passé à propos des bogues que vous avez signalés. Saisissez cette occasion pour fermer les bogues que vous ne pouvez plus reproduire. Pour trouver tous les bogues que vous avez signalés, vous avez simplement besoin de vous rendre à la page https://bugs.debian.org/from:votre-adresse-de-courrier.

7.1.1. Signalement d'un grand nombre de bogues en une fois (`mass bug filing`)

Signaler de nombreux bogues pour le même problème sur un grand nombre de paquets — c'est-à-dire plus de dix — est une pratique déconseillée. 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.

Si vous voulez signaler plus de dix rapports sur le même sujet, il est préférable d'indiquer votre intention sur la liste debian-devel@lists.debian.org et de le mentionner dans le sujet de votre message. Cela donnera à d'autres développeurs la possibilité de vérifier que le problème existe vraiment. De plus, cela permet d'éviter que plusieurs responsables ne rédigent les mêmes rapports de bogue simultanément.

Veuillez utiliser les programmes dd-list et si nécessaire, whodepends (du paquet devscripts) pour générer une liste de tous les paquets concernés et incluez la sortie dans votre courrier à debian-devel@lists.debian.org.

Quand vous envoyez un grand nombre de rapports sur le même sujet, vous devriez les envoyer à maintonly@bugs.debian.org pour éviter qu'ils soient renvoyés vers les listes de diffusion.

Le programme mass-bug (du paquet devscripts) peut être utilisé pour envoyer des rapports de bogue pour une liste de paquets.

7.1.1.1. Étiquettes d'utilisateur (`Usertags`)

Vous pouvez utiliser les étiquettes d'utilisateur du BTS lors du signalement de bogues sur un grand nombre de paquets. Les étiquettes d'utilisateur se comportent de la même façon que les étiquettes patch et wishlist à la différence qu'elles sont définies par l'utilisateur et occupent un espace de définition spécifique propre à l'utilisateur. Cela permet à plusieurs groupes de développeurs de marquer Usertags le même bogue de différentes façons sans conflit.

Pour ajouter des étiquettes d'utilisateur lors du signalement de bogues, précisez les pseudo-en-têtes User et Usertags :

To: submit@bugs.debian.org
Subject: title-of-bug

Package: pkgname
[ ... ]
User: email-addr
Usertags: tag-name [ tag-name ... ]

description-of-bug ...

Remarquez que les étiquettes sont séparées par des espaces et ne peuvent contenir de tiret bas. Si vous signalez des bogues au nom d'un groupe ou d'une équipe spécifique, il vaut mieux définir User comme une liste de diffusion appropriée après y avoir décrit votre intention.

Pour voir les bogues marqués par une étiquette d'utilisateur en particulier, rendez-vous sur la page https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=adresse-mail&tag=nom-d-etiquette.

7.2. Effort d'assurance qualité

7.2.1. Travail quotidien

Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité (QA), les devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à cet effort en conservant vos paquets aussi exempts de bogues que possible et aussi corrects que possible selon lintian (voir lintian). Si cela vous paraît impossible, vous devriez alors envisager d'abandonner certains de vos paquets (voir Abandon de paquet). Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles puissent rattraper votre retard dans la correction des bogues (vous pouvez demander de l'aide sur debian-qa@lists.debian.org ou debian-devel@lists.debian.org). En même temps, vous pouvez rechercher des co-responsables (voir Maintenance collective).

7.2.2. Chasses aux bogues

De temps en temps, le groupe d'assurance qualité organise des chasses aux bogues (Bug Squashing Party) pour essayer de résoudre autant de problèmes que possible. Elles sont annoncées sur debian-devel-announce@lists.debian.org en précisant quel domaine sera visé pendant la chasse : habituellement, il s'agit des bogues empêchant l'intégration du paquet dans la distribution (bogues de gravité Release Critical), mais il peut être décidé d'aider à finir une transition majeure (comme une nouvelle version de Perl qui demande la recompilation de tous les modules binaires).

Les règles pour les mises à jour indépendantes (NMU) sont différentes au cours de la chasse parce que l'annonce de la chasse est considérée comme une annonce préalable pour les NMU. Si vous avez des paquets qui peuvent être affectés par la chasse (parce qu'ils ont des bogues critiques par exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous ne voulez pas de NMU, si vous n'êtes intéressé que par un correctif, ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer dans le BTS.

Les personnes qui participent à la chasse ont des règles spécifiques pour les NMU, elles peuvent en faire une sans avertissement préalable si elles envoient leur paquet avec un délai d'au moins trois jours dans DELAYED/3-day. Toutes les autres règles de NMU s'appliquent comme d'habitude ; le correctif de la NMU devrait être envoyé dans le BTS (pour l'un des bogues ouverts corrigé par la NMU ou pour un nouveau bogue marqué corrigé). Les participants devraient également respecter tout souhait du responsable s'il en a exprimé.

Si vous ne vous sentez pas à l'aise avec une NMU, envoyez simplement un correctif au BTS. C'est de loin préférable à une NMU défectueuse.

7.3. Contact avec d'autres responsables

Pendant vos activités dans Debian, vous contacterez d'autres responsables pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez simplement rappeler à quelqu'un qu'une nouvelle version est disponible et que vous en avez besoin.

Chercher l'adresse du responsable d'un paquet peut être fastidieux. Heureusement, il existe un alias de courrier simple, paquet@packages.debian.org, qui fournit un moyen d'envoyer un courrier à un responsable, quelle que soit son adresse (ou ses adresses). Remplacez paquet par le nom du paquet source ou binaire.

Vous pouvez également vouloir contacter les personnes inscrites à un paquet source donné à l’aide de Suivi de paquets Debian (Debian Package Tracker). Vous pouvez le faire en utilisant l'adresse paquet@packages.qa.debian.org.

7.4. Gestion des responsables non joignables

Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer que le responsable est toujours actif et qu'il continue à travailler sur ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il n'ait pas démissionné 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 manquant à l'appel (Missing In Action) sont enregistrées. Quand un membre du groupe QA` contacte un responsable inactif ou trouve plus d'informations sur celui-ci, un enregistrement dans la base de données MIA a lieu. Ce système est disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être interrogé avec mia-query. Utilisez mia-query --help pour voir comment interroger la base de données. Si aucune information n'a encore été enregistrée sur un responsable inactif ou si vous pouvez ajouter plus d'informations, vous devriez utiliser la procédure suivante.

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 ce qu'est un temps raisonnable, mais il est important de prendre en compte que la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait être d'envoyer un rappel après deux semaines.

Une adresse de courriel non valable est une violation de la politique de Debian. Si un courriel est rejeté (bounce), veuillez soumettre un bogue pour le paquet et informer la base de données MIA.

Si le responsable ne répond pas après quatre semaines (un mois), on peut supposer qu'il n'y aura probablement pas de réponse. Si cela se produit, vous devriez poursuivre vos investigations et essayer de réunir toutes les informations utiles sur ce responsable. Cela inclut :

les informations echelon disponibles dans la base de données LDAP des développeurs, qui indiquent quand le développeur a envoyé un message pour la dernière fois sur une liste de diffusion Debian (cela inclut les envois vers les listes debian-devel-changes@lists.debian.org). Pensez aussi à vérifier si le responsable est indiqué comme en vacances dans la base de données ;
le nombre de paquets de ce responsable et l'état de ces paquets. En particulier, reste-t-il des bogues empêchant l'intégration des paquets dans la distribution qui sont ouverts depuis des lustres ? De plus, combien de bogues y a-t-il en général ? Un autre renseignement important est si les paquets ont subi des NMU, et si oui, par qui ;
est-ce que le responsable est actif en dehors de Debian ? Par exemple, il peut avoir envoyé des messages récemment à des listes de diffusion non-Debian ou des groupes de discussion ;

Un problème particulier est représenté par les paquets parrainés — le responsable n'est pas un développeur Debian officiel. Les informations echelon ne sont pas disponibles pour les personnes parrainées, par exemple ; vous devez donc trouver et contacter le responsable Debian qui a réellement envoyé le paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de toute façon et il sait probablement ce qui s'est passé avec la personne qu'il parraine.

Il est également permis d'envoyer une demande à debian-devel@lists.debian.org demandant si quelqu'un a des informations sur le responsable manquant. Veuillez mettre en copie (CC) la personne en question.

Une fois réunies toutes ces informations, vous pouvez contacter mia@qa.debian.org. Les personnes de cet alias utiliseront les informations que vous aurez fournies pour décider comment procéder. Par exemple, elles peuvent abandonner tout ou partie des paquets du responsable. Si un paquet a subi une NMU, elles peuvent préférer contacter le responsable ayant fait cette NMU avant de déclarer le paquet orphelin — il pourrait être intéressé par le paquet.

Un dernier mot : veuillez rester poli. Tout le monde est volontaire et ne peut dédier l'intégralité de son temps à Debian. Vous n'êtes pas non plus au courant de la situation de la personne impliquée. Elle est peut-être sérieusement malade ou pourrait même nous avoir définitivement quitté — vous ne savez pas qui recevra vos courriers. Imaginez le sentiment d'un proche qui lit un courrier pour la personne décédée, et trouve un message très impoli, de colère et accusateur !

D'un autre côté, bien que nous soyons des bénévoles, le responsable d’un paquet s’est engagé et a donc la responsabilité d’entretenir le paquet. Aussi, vous pouvez faire valoir l’importance du bien collectif — si un responsable n'a plus le temps ou l'envie, il devrait « laisser filer » et donner le paquet à quelqu'un ayant plus de temps ou plus intéressé.

Si vous êtes intéressé pour travailler dans l'équipe MIA, veuillez étudier le fichier README dans /org/qa.debian.org/mia sur qa.debian.org où les détails techniques et les procédures MIA sont documentés et contactez mia@qa.debian.org.

7.5. Interaction avec de futurs développeurs Debian

Le succès de Debian dépend de sa faculté à attirer et conserver de nouveaux et talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous recommandons de vous impliquer dans le processus pour devenir un nouveau responsable. Cette section décrit comment aider les futurs développeurs.

7.5.1. Parrainage de paquets

Parrainer un paquet signifie envoyer un paquet pour un responsable qui n'est pas encore autorisé à le faire lui-même. Ce n'est pas une mince affaire, le parrain doit vérifier l'empaquetage et s'assurer qu'il respecte le haut niveau d'exigence qualité que Debian s'efforce de conserver.

Les développeurs Debian peuvent parrainer des paquets, mais pas les responsables Debian.

Le processus de parrainage d'un paquet est :

le responsable prépare un paquet source (.dsc) et le met en ligne quelque part (par exemple sur mentors.debian.net) ou mieux, fournit un lien vers un dépôt public de logiciel de gestion de versions (voir salsa.debian.org : dépôts Git et plateforme de développement collaborative) où le paquet est entretenu.
le parrain télécharge (ou extrait du dépôt) le paquet source ;
le parrain vérifie le paquet source. En cas de problème, il informe le responsable et lui demande de fournir une version corrigée (le processus reprend à la première étape) ;
le parrain ne trouve aucun problème résiduel. Il construit le paquet, le signe, et l'envoie dans Debian.

Avant de se plonger dans les détails du parrainage de paquet, vous devriez vous demander si l'ajout du paquet proposé est profitable à Debian.

Il n'y a pas de règle simple pour répondre à cette question, cela peut dépendre de plusieurs facteurs : le code source amont est-il suffisamment achevé et pas miné de trous de sécurité ? Existe-t-il déjà des paquets qui font la même chose et que donnent les comparaisons avec ce nouveau paquet ? Le paquet a-t-il été demandé par des utilisateurs et le nombre d'utilisateurs est-il significatif ? Les développeurs amont sont-ils actifs ?

Vous devriez également vérifier que le futur responsable sera un bon responsable. A-t-il déjà de l'expérience avec d'autres paquets ? Si oui, réalise-t-il du bon travail avec ceux-ci (contrôlez quelques bogues) ? Est-il familier avec le paquet et son langage de programmation ? A-t-il les compétences nécessaires pour ce paquet ? Si non, est-il capable de les acquérir ?

C'est aussi une bonne idée de savoir comment il se situe par rapport à Debian : est-il en accord avec la philosophie de Debian et a-t-il l'intention de rejoindre Debian ? Étant donné la facilité de devenir un membre de Debian, vous voudrez peut-être n'être le parrain que de personnes qui prévoient de rejoindre Debian. De cette manière, vous savez dès le début que vous n'aurez pas à jouer le rôle de parrain indéfiniment.

7.5.1.1. Parrainage d'un nouveau paquet

Les nouveaux responsables ont souvent quelques difficultés à créer des paquets Debian — cela est bien compréhensible. Ils feront des erreurs. C'est pourquoi le parrainage d'un tout nouveau paquet dans Debian demande une inspection minutieuse de l'empaquetage. Parfois plusieurs itérations seront nécessaires avant que le paquet ne soit assez bon pour être envoyé dans Debian. Ainsi, être un parrain signifie être un mentor.

Ne parrainez jamais de paquet sans l'avoir vérifié. La vérification de nouveau paquet réalisée par les responsables de l'archive veille principalement à ce que le logiciel soit vraiment libre. Bien sûr, ils tombent parfois sur des problèmes d'empaquetage, mais ça ne devrait vraiment pas arriver. Il est de votre responsabilité de vérifier que le paquet envoyé est compatible avec les principes du logiciel libre selon Debian et qu'il est de bonne qualité.

La construction du paquet et l'essai du logiciel fait partie de la vérification, mais ça ne suffit pas. La suite de cette section est une liste non exhaustive de points à vérifier lors de votre contrôle. [1]

Vérifiez que l'archive source fournie est la même que celle distribuée par l'auteur amont (quand les sources ont été réempaquetées pour Debian, créez vous-même l'archive modifiée).
Exécutez lintian (consulter lintian). De nombreux problèmes usuels seront découverts. Prenez soin de vérifier que tous les contrôles de lintian ignorés par le responsable sont pleinement justifiés.
Exécutez licensecheck (qui fait partie de devscripts) et vérifiez que debian/copyright ait l'air correct et exhaustif. Recherchez des problèmes de licence (comme des fichiers avec « All rights reserved » — tous droits réservés — en en-tête, ou ayant une licence non compatible avec les principes du logiciel libre selon Debian). grep -ri peut vous aider ici.
Construisez le paquet avec pbuilder (ou n'importe quel outil du même genre, consultez pbuilder) pour vérifier que les dépendances de constructions sont exhaustives.
Relisez debian/control : est-il conforme aux meilleures pratiques (consultez Meilleures pratiques pour debian/control) ? Les dépendances sont elles exhaustives ?
Relisez debian/rules : est-il conforme aux meilleures pratiques (consultez Meilleures pratiques pour debian/rules) ? Pouvez-vous apporter quelques améliorations ?
Relisez les scripts du responsable (preinst, postinst, prerm, postrm, config) : est-ce que preinst et postrm fonctionneront si les dépendances ne sont pas installées ? Est-ce que tous les scripts sont idempotents (c'est-à-dire peuvent-ils être exécutés plusieurs fois sans conséquences) ?
Vérifiez toutes les modifications des fichiers amont (dans .diff.gz, debian/patches/ ou directement dans l'archive debian pour les fichiers binaires). Sont-elles justifiées ? Sont-elles correctement documentées (conformément à DEP-3 pour les correctifs) ?
Pour chaque fichier, demandez-vous pourquoi le fichier est là et si c'est la bonne façon d'atteindre le but voulu. Est-ce que le responsable suit les meilleurs pratiques d'empaquetage (consultez Meilleures pratiques d'empaquetage) ?
Construisez les paquets, installez-les et essayez le logiciel. Vérifiez de pouvoir supprimer et purger les paquets. Essayez-les si possible avec piuparts.

Si la vérification n'a révélé aucun problème, vous pouvez construire le paquet et l'envoyer dans Debian. Rappelez-vous que même sans être le responsable du paquet, le parrain est toujours responsable de ce qu'il envoie dans Debian. C'est pourquoi vous devriez suivre le paquet (cf. Suivi de paquets Debian (Debian Package Tracker)).

Remarquez que vous ne devriez pas avoir à modifier le paquet source pour mettre votre nom dans les fichiers changelog ou control. Le champ Maintainer du fichier control et le fichier changelog devraient afficher la personne qui a fait l'empaquetage, c'est-à-dire, le filleul. Ainsi, ils recevront tous les courriers du système de suivi des bogues (BTS).

À la place, vous devriez indiquer à dpkg-buildpackage d'utiliser votre clef en signature. L'option -k le permet :

dpkg-buildpackage -kKEY-ID

Si vous utilisez debuild et debsign, vous pouvez même le configurer de façon permanente dans ~/.devscripts :

DEBSIGN_KEYID=KEY-ID

7.5.1.2. Parrainage de la mise à jour d'un paquet existant

Vous pourrez en général supposer que le paquet a déjà été vérifié complètement. Au lieu de recommencer depuis le début, vous devriez analyser précautionneusement les différences entre la version actuelle et la nouvelle version préparée par le responsable. Si vous n'avez pas fait la vérification initiale vous-même, vous pourriez tout de même regarder de plus près au cas où elle aurait été négligée.

Afin de comparer les différences, il vous faudra les deux paquets. Téléchargez la version actuelle du paquet source (avec apt-get source) et reconstruisez-le (ou téléchargez les paquets binaires actuels avec aptitude download). Téléchargez le paquet source à parrainer (normalement avec dget).

Lisez la nouvelle entrée du journal de modification, elle devrait vous apprendre ce que vous devriez trouver lors de la vérification. L'outil principal à utiliser est debdiff (du paquet devscripts), vous pouvez l'exécuter avec deux paquets source (fichiers .dsc), deux paquets binaires, ou deux fichiers .changes (seront alors comparés tous les paquets binaires présents dans le fichier .changes).

Si vous comparez les paquets source (à l'exception des fichiers amont dans le cas d'une nouvelle version amont, en filtrant par exemple la sortie de debdiff avec filterdiff -i '*/debian/*'), vous devez comprendre toutes les modifications et elles devraient être convenablement documentées dans le journal de modifications Debian.

Si tout est correct, construisez le paquet et comparez les paquets binaires pour vérifier que les modifications du paquet source n'ont pas des conséquences inattendues (comme certains fichiers supprimés par erreur, des dépendances manquantes, etc.).

Vous pourriez consulter le système de suivi des paquets (consultez Suivi de paquets Debian (Debian Package Tracker)) pour vérifier que le responsable n'a rien oublié d'important. Des mises à jour de traductions pourraient attendre d'être intégrées dans le BTS. Le paquet pourrait avoir été la cible d'une NMU précédente et le responsable pourrait avoir oublié d'intégrer les modifications apportées. Un bogue critique pour la publication oublié pourrait empêcher la migration vers testing. Si vous trouvez quelque chose à améliorer, il est temps de le signaler pour que le responsable puisse s'améliorer la prochaine fois, et ainsi lui donner l'opportunité de mieux comprendre ses responsabilités.

Si vous n'avez pas trouvé de problème majeur, envoyez la nouvelle version. Sinon, demandez au responsable de fournir une version corrigée.

7.5.2. Granting upload permissions to DMs

After a Debian Maintainer's key has been added to the debian-maintainers keyring, a Debian Developer may grant upload permissions to the DM for specific packages by uploading a signed dak command to ftp.upload.debian.org as described in the FTP-Master's announcement to debian-devel.

This process can be simplified with the help of the dcut command from the dput-ng package. Note that this does not work with the dcut command from the dput package!

For example:

dcut dm --uid 0xfedcba9876543210 --allow nano --deny bash

If the DM's key is not in the keyring package yet but in the DD's local keyring, use the --force option and the fingerprint, without spaces and, in this special case, without the 0x prefix and in all uppercase:

dcut --force dm --uid FEDCBA9876543210FEDCBA9876543210 --allow nano

7.5.3. Recommandation d'un nouveau développeur

Les recommandations pour un futur développeur sont disponibles sur le site web de Debian.

7.5.4. Gestion des nouvelles candidatures

La liste de contrôle pour les responsables de candidature est disponible sur le site web de Debian.