Table des matières
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/
.
Des outils comme querybts(1) peuvent également vous fournir ces
informations (et reportbug invoquera également
normalement querybts avant l'envoi).
nomdupaquet
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 <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.
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:titre-du-bogue
Package:nom-de-paquet
[ ... ]
User:adresse-mail
Usertags:nom-d-etiquette [ nom-d-etiquette ... ]
description-du-bogue ...
Note that tags are separated by spaces and cannot contain underscores. If
you are filing bugs for a particular group or team it is recommended that
you set the User
to an appropriate mailing list after
describing your intention there.
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
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
<debian-qa@lists.debian.org>
ou <debian-devel@lists.debian.org>
). En même temps, vous pouvez
rechercher des co-responsables (voir Section 5.12, « 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
<debian-devel-announce@lists.debian.org>
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,
, qui
fournit un moyen d'envoyer un courrier à un responsable, quelle que soit son
adresse (ou ses adresses). Remplacez paquet
@packages.debian.orgpaquet
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
email address.
package
@packages.qa.debian.org
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
<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 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 — 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 <mia@qa.debian.org>
.
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 :
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 ;
The sponsor downloads (or checks out) the source package.
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.
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. [7]
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.
Les recommandations pour un futur développeur sont disponibles sur le site web de Debian.
La liste de contrôle pour les responsables de candidature est disponible sur le site web de Debian.
[7] You can find more checks in the wiki, where several developers share their own sponsorship checklists.