Voici le récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes ayant fait un don pour soutenir mon travail (130,30 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.
Travail sur dpkg
Le début du mois a été marqué par la correction de bogues nouvellement rapportés, ceci pour préparer la publication de la version 1.16.1.1 :
- n°644492 : une erreur sur une de mes modifications du code de mise en place des triggers entraînait le marquage erroné du paquet comme « configuré », alors qu’il n’était que décompressé dans un nouveau chroot.
- n°642656 : le nouveau refus de dpkg-source de fabriquer un paquet source avec des modifications non-enregistrées dans un patch a cassé le format source « 2.0 » (quasi-inutilisé, sauf par la suite de tests lintian apparemment).
- n°644412 : l’extrait de makefile « buildflags.mk » ne respectait pas les nouvelles variables d’environnement spécifiques aux mainteneurs (DEB_CFLAGS_MAINT_APPEND, par exemple), du fait de make qui ne transmet pas lesdites variables à travers le code
$(shell …). Corrigé en exportant manuellement les variables requises. - J’ai également désactivé la sortie de dpkg-buildpackage en ce qui concerne les drapeaux de compilation, dans la mesure où cela induisait en erreurs de nombreux mainteneurs. dpkg-buildpackage invoquant debian/rules il n’a aucun moyen (propre) de prendre connaissance des changements de drapeaux de compilation effectués par le mainteneur en définissant les variables d’environnement associées. Les mainteneurs, quant à eux, s’attendent à voir en sortie les drapeaux de compilation tels qu’ils les ont modifiés, pas tels qu’ils sont initialisés par défaut par la distribution.
Nous avons décidé, avec l’aide de Guillem, d’une correction appropriée concernant une situation d’accès concurrent (race condition) survenant parfois à l’occasion de compilations parallèles, lorsque deux dpkg-gencontrol concurrents essayent de mettre à jour des fichiers debian/files (cf. n°642608). Pour mener à bien cette correction, un nouveau paquet était nécessaire : libfile-fcntllock-perl, qui nous a été gentiment empaqueté par l’équipe Perl. Une fois tout ceci mis en place, la correction était plutôt simple.
Support du multi-architecture
J’ai également passé beaucoup de temps sur le support multi-architecture. Tout d’abord en corrigeant un vieux bogue qui exigeait le support des chemins multi-arch dans le cas d’une cross-compilation (cf. n°595144). Deux patchs avaient été proposés, mais la discussion n’ayant pas vraiment tranchée en faveur de l’un ou l’autre, j’ai appliqué mon propre patch, qui a de plus l’avantage d’être plus proche techniquement de la manière dont nous gérons la compilation croisée.
J’ai ensuite corrigé deux problèmes rapportés sur la version Ubuntu de dpkg. Le premier (LP n°863675) était assez sérieux puisqu’il provoquait la « disparition » de paquets installés à l’avantage de leurs équivalents d’architectures étrangères supprimés (mais dont il restait certains fichiers de configuration). Le second (LP n°853679) n’affectait que les utilisateurs de dselect (il y en a encore apparemment !) dont une bibliothèque multi-architecture installée était en conflit avec elle-même (exemple : Provides: toto, Conflicts: toto).
Mais la plus grosse partie du temps passé sur la problématique multiarch le fut dans des discussions débattant, avec des interlocuteurs variés, de la direction à donner à multiarch. La Release Team intervint sur le planning du merge, afin de s’assurer de la disponibilité pour Wheezy. Le Responsable du projet Debian, quant à lui, fit le résumé des problématiques rencontrées jusqu’ici.
Bien que le déroulé des actions prises pour multiarch ne soit pas forcément celui que j’aurais espéré, ces dernières n’en représentent pas moins un progrès depuis que Guillem a commencé à pousser certains modifications validées. Des 66 modifications présentes il y a une semaine dans ma branche pu/multiarch/full, 20 ont déjà été intégrées dans la branche principale.
Mise à jour de sécurité et bogue RC pour python-django
Le mainteneur de python-django n’ayant pas réussi à préparer les mises à jour de sécurité requises, j’ai pris le relais et réalisé les nouvelles versions 1.2.3-3+squeeze2 pour Squeeze et 1.0.2-1+lenny3 pour Lenny. Cette mise à jour de sécurité est malheureusement un exemple du délai conséquent que peut prendre la publication d’une version de sécurité, lorsque le mainteneur du paquet est inactif.
La situation est compliquée, dans ce cas précis, par le fait que l’équipe en charge de la sécurité sous Debian n’a pas voulu publier de mise à jour pour Squeeze tant que celle de Lenny n’avait pas fait l’objet d’investigations (ce qui requiert un effort d’autant plus important que la version n’est plus supportée upstream). Sur ce point, leur communication ne fut pas des plus claires.
Quelques temps après, un autre bogue RC — Release Critical — a été rapporté sur ce paquet (n°646634) mais s’est révélé être, après investigation, un problème de configuration locale. Sa priorité a donc été rétrogradée, et j’ai transmis aux développeurs amont l’échec de la suite de test, car cette dernière pourrait être améliorée.
Les co-mainteneurs sont quoi qu’il en soit bienvenus : je préfère vraiment n’être que dans la situation du mainteneur « de secours »… 🙂
Empaquetage de WordPress
La situation de WordPress ressemble beaucoup à celle de python-django. Je n’y suis également qu’un « mainteneur de secours », mais Giuseppe est resté inactif de nombreux mois et j’ai du m’atteler à la tâche courant août, car je voulais utiliser la nouvelle version amont. Je n’ai découvert que tardivement le fait que je n’étais pas inscrit à la liste de diffusion des bogues WordPress et, par conséquent, le bogue critique n°639733 (que j’ai introduit en même temps que la nouvelle version) est resté tel quel un certain temps. Je l’ai corrigé dès que je m’en suis aperçu.
J’ai également saisi l’opportunité d’initier une discussion sur debian-devel concernant la gestion des bibliothèques javascript embarquées, et j’ai proposé un « mécanisme de remplacement opportuniste via liens symboliques ». WordPress constitue mon banc de test pour ce mécanisme, vous pouvez consulter son debian/dh_linktree implémentant l’algorithme de remplacement.
La discussion n’a quant à elle pas été très intéressante, bien que j’ai appris que Debian exigeait maintenant que chaque paquet source embarquant des fichiers Javascript « minifiés » inclut également les fichiers originaux. C’est d’autant plus pénible, quelque part, que ce n’est dans de nombreux cas pas imposé par la licence (un grand nombre de ces fichiers ne sont pas sous GPL), mais par Debian uniquement. Et les développeurs amont sont nombreux à ne pas s’y conformer, ce qui est le cas de WordPress. En conséquence, le bogue RC n°646729 ouvert par Jakub Wilk est bien parti pour rester ouvert pendant longtemps. Après de nombreuses heures passées à investiguer chaque fichier Javascript du paquet source de WordPress, j’ai créé en retour un nouveau ticket dans le système de suivi des bogues upstream.
Empaquetage de Dropbox
Le retour d’expérience des mois écoulés depuis l’introduction de nautilus-dropbox dans Debian et Ubuntu me permet d’affirmer que la décision de ne supporter le téléchargement de dropbox que via le script de post-installation était une mauvaise idée.
Du fait de cette décision, j’ai été obligé de faire tomber en erreur le script postinst si le téléchargement échouait. Et, même si le message d’erreur est relativement clair, cela n’en a pas moins engendré de nombreux (la plupart automatisés) rapports de bogues côté Ubuntu. Sans parler des problèmes de natures diverses qui sont venus s’ajouter au tableau (comme essayer de démarrer dropbox alors que le paquet n’était pas configuré – ce qui entraîne une erreur, induite par le fait que l’utilisateur n’a pas les droits requis pour installer le logiciel ; ou encore réinstaller le paquet alors que dropbox est en cours de fonctionnement – ce qui entraîne également une erreur…).
Tous ces problèmes sont corrigés dans la version 0.7.0-2 du paquet. Dorénavant, si l’utilisateur doit installer dropbox, il utilisera PolicyKit afin d’obtenir les droits root. Le script postinst n’échouera plus dans le cas d’un échec du téléchargement de dropbox, puisque ce dernier peut être relancé ultérieurement par l’utilisateur. J’ai également corrigé le code du téléchargement, afin de supprimer le fichier remplacé avant d’extraire un nouveau fichier (au lieu d’écraser le fichier existant). Toutes ces modifications ont été transmises upstream.
Cahiers de l’Admin Debian : point d’avancement
Je suis heureux de vous annoncer que la traduction aura bien lieu. Nous avons en effet atteint l’objectif de financement minimal le 22 octobre, ce grâce à 380 donateurs.
La levée de fonds continue cependant, en vue cette fois de libérer le livre. 25000€ doivent ici être atteints, et nous en sommes aujourd’hui à 39% (soit 9950€ dans le fond de libération — ce qui signifie qu’environ 59% de l’argent collecté l’a été au titre de ce fond de libération).
Cliquez ici si vous souhaitez contribuer à la libération de ce livre.
Parvenir à recueillir cette somme en (moins de) 19 jours constitue un challenge ! Mais nous aimons relever de tels challenges, n’est-ce pas ?
Divers
- J’ai créé le rapport de bogue n°644486. Il concerne dh-make, et a pour objectif un support approprié des drapeaux de compilation dpkg par les nouveaux paquets dès leurs débuts.
- J’ai intégré de nombreux patchs de Luca Falavigna dans le paquet developers-reference.
- J’ai discuté de l’intégration des debtags dans le système de suivi des paquets (PTS – Packages Tracking System) avec Enrico Zini et Paul Wise.
- J’ai mis à jour l’empaquetage du paquet publican pour la nouvelle version 2.8. Cela a nécessité l’écriture d’un patch que j’ai transmis upstream.
- J’ai créé un rapport de bogue upstream pour hamster-applet. Sa fenêtre n’est plus mise en avant lorsqu’on exécute hamster-time-tracker.
Merci
Au mois prochain pour un nouveau résumé de mes activités !
Ceci est une traduction de mon article My Debian activities in October 2011 contribuée par Weierstrass01.
J’ai pu observer de nombreuses personnes, ces dernières années, essayant d’utiliser 
Du point de vue de l’utilisateur, un firmware (ou microprogramme/microcode) n’est qu’un ensemble de données indispensable au bon fonctionnement d’un matériel donné. Généralement le pilote correspondant charge le firmware dans le périphérique au cours de son processus d’initialisation. 
Si vous utilisez Debian, vous savez que cette distribution est entièrement réalisée par des volontaires bénévoles qui forment une communauté très variée. Et vous pourriez en faire partie. Mais pourquoi devriez-vous faire cela? Je ne peux pas répondre pour vous mais je peux vous faire part de ma propre expérience. Cela fait 13 ans que j’ai rejoint le projet Debian et je vais vous dire ce qui fait que j’y reste.