Chapitre 7. Au-delà de l'empaquetage

Table des matières

7.1. Signalement de bogues
7.1.1. Signalement d'un grand nombre de bogues en une fois (« mass bug filing »)
7.1.1.1. Étiquettes d'utilisateur « Usertags »
7.2. Effort d'assurance qualité
7.2.1. Travail quotidien
7.2.2. Chasses aux bogues
7.3. Contact avec d'autres responsables
7.4. Gestion des responsables non joignables
7.5. Interaction avec de futurs développeurs Debian
7.5.1. Parrainage de paquets
7.5.1.1. Parrainage d'un nouveau paquet
7.5.1.2. Parrainage de la mise à jour d'un paquet existant
7.5.2. Recommandation d'un nouveau développeur
7.5.3. Gestion des nouvelles candidatures

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à de la simple création et maintenance 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.

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

Signaler de nombreux bogues pour le même problème sur un grand nombre de paquets — 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 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 à .

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

Bien qu'il y ait un groupe de personnes dédié à l'assurance qualité, 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 Section A.2.1, « lintian »). Si cela vous paraît impossible, vous devriez alors envisager d'abandonner certains de vos paquets (voir Section 5.9.4, « 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 ou ). En même temps, vous pouvez rechercher des co-responsables (voir Section 5.13, « Maintenance collective »).

From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on and the announcement explains which area will be the focus of the party: usually they focus on release critical bugs but it may happen that they decide to help finish a major upgrade (like a new perl version that requires recompilation of all the binary modules).

The rules for non-maintainer uploads differ during the parties because the announcement of the party is considered prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don't want an NMU, or if you're only interested in a patch, or if you will deal with the bug yourself, please explain that in the BTS.

People participating in the party have special rules for NMU; they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules apply as usual; they should send the patch of the NMU to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed). They should also respect any particular wishes of the maintainer.

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

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 d'un 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.

You may also be interested in contacting the persons who are subscribed to a given source package via Section 4.10, « The Debian Package Tracker ». You can do so by using the package@packages.qa.debian.org email address.

If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active anymore, but haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder.

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 pour 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 le « 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.

A non-functional e-mail address is a violation of Debian Policy . If an e-mail "bounces", please file a bug against the package and submit this information to the MIA database.

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 ). 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 à demandant si quelqu'un a des informations sur le responsable manquant. Veuillez mettre en CC la personne en question.

Une fois réunies toutes ces informations, vous pouvez contacter . 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 — 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 des conditions 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 !

On the other hand, although we are volunteers, a package maintainer has made a commitment and therefore has a responsibility to maintain the package. So you can stress the importance of the greater good — if a maintainer does not have the time or interest anymore, they should let go and give the package to someone with more time and/or interest.

If you are interested in working on the MIA team, please have a look at the README file in /org/qa.debian.org/mia on qa.debian.org, where the technical details and the MIA procedures are documented, and contact .

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.

Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own. It's not a trivial matter; the sponsor must verify the packaging and ensure that it is of the high level of quality that Debian strives to have.

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

Le processus de parrainage d'un paquet est :

  1. le responsable prépare un paquet source (.dsc) et le met en ligne quelque part (sur mentors.debian.net par exemple) ou, mieux encore, fournit un lien vers un dépôt de gestion de versions (consultez Section 4.4.5, « Serveurs de gestion de versions (VCS) ») où le paquet est maintenu ;

  2. The sponsor downloads (or checks out) the source package.

  3. 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) ;

  4. le parrain ne trouve aucun problème résiduel. Il construit le paquet, le signe, et l'envoie dans Debian.

Before delving into the details of how to sponsor a package, you should ask yourself whether adding the proposed package is beneficial to Debian.

There's no simple rule to answer this question; it can depend on many factors: is the upstream codebase mature and not full of security holes? Are there pre-existing packages that can do the same task and how do they compare to this new package? Has the new package been requested by users and how large is the user base? How active are the upstream developers?

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 apprendre ?

Il est aussi recommandé de connaître sa position par rapport à Debian : approuve-t-il la philosophie Debian et désire-t-il rejoindre Debian ? Vu comme il est facile de devenir mainteneur Debian, vous pourriez ne parrainer que des personnes ayant l'intention de rejoindre le projet. De cette façon, vous savez au départ que vous n'aurez pas a parrainer indéfiniment.

New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. They will make mistakes. That's why sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Sometimes several iterations will be needed until the package is good enough to be uploaded to Debian. Thus being a sponsor implies being a 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. [8]

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

  • Run lintian (see Section A.2.1, « lintian »). It will catch many common problems. Be sure to verify that any lintian overrides set up by the maintainer are fully justified.

  • Exécutez licensecheck (qui fait partie de Section A.6.1, « 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 Section A.4.3, « pbuilder ») pour vérifier que les dépendances de constructions sont exhaustives.

  • Relisez debian/control : est-il conforme aux meilleures pratiques (consultez Section 6.2, « Meilleures pratiques pour debian/control ») ? Les dépendances sont elles exhaustives ?

  • Relisez debian/rules : est-il conforme aux meilleures pratiques (consultez Section 6.1, « 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 Chapitre 6, Meilleures pratiques d'empaquetage) ?

  • Build the packages, install them and try the software. Ensure that you can remove and purge the packages. Maybe test them with piuparts.

If the audit did not reveal any problems, you can build the package and upload it to Debian. Remember that even if you're not the maintainer, as a sponsor you are still responsible for what you upload to Debian. That's why you're encouraged to keep up with the package through Section 4.10, « The Debian Package Tracker ».

Note that you should not need to modify the source package to put your name in the changelog or in the control file. The Maintainer field of the control file and the changelog should list the person who did the packaging, i.e. the sponsee. That way they will get all the BTS mail.

Instead, you should instruct dpkg-buildpackage to use your key for the signature. You do that with the -k option:

dpkg-buildpackage -kidentifiant_de_clef

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

DEBSIGN_KEYID=identifiant_de_clef

You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a deeper look just in case the initial reviewer was sloppy.

To be able to analyze the difference, you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget).

Read the new changelog entry; it should tell you what to expect during the review. The main tool you will use is debdiff (provided by the devscripts package); you can run it with two source packages (.dsc files), or two binary packages, or two .changes files (it will then compare all the binary packages listed in the .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 modification Debian.

If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (some files dropped by mistake, missing dependencies, etc.).

You might want to check out the Package Tracking System (see Section 4.10, « The Debian Package Tracker ») to verify if the maintainer has not missed something important. Maybe there are translation updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the NMU into their package. Maybe there's a release critical bug that they have left unhandled and that's blocking migration to testing. If you find something that they could have done (better), it's time to tell them so that they can improve for next time, and so that they have a better understanding of their responsibilities.

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



[8] You can find more checks in the wiki, where several developers share their own sponsorship checklists.