Mes activités Debian en septembre 2011

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 (144,3 €, 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

Tout en m’occupant des derniers détails concernant les options de compilation renforcée pour dpkg 1.16.1, j’ai lancé un appel aux bonnes volontés sur la liste de diffusion debian-devel, avec en ligne de mire les objectifs à atteindre pour la publication concernant l’usage de ces drapeaux. Le but étant ici de s’assurer qu’un nombre conséquent de paquets a été converti/recompilé pour les utiliser.

J’ai ensuite rédigé un brouillon pour l’annonce de l’upload de dpkg (Bits of dpkg maintainers), et l’ai envoyée sur la liste debian-devel-announce. Guillem l’a complété, en ajoutant la liste des nouvelles fonctionnalités depuis la version 1.15.7.

Ce dernier a également effectué un peu de « restructuration » (refactoring) sur updates-alternatives, ce qui a engendré une régression fort heureusement découverte par Sven Joachim. Je l’ai corrigée, et poursuivi le nettoyage plus avant, inspiré par les causes originelles de cette régression (cf. les 4 derniers commits).

À noter que Sven est l’une des rares personnes à utiliser la version git de dpkg. J’espère que le nombre d’utilisateurs de cette version va augmenter, dans la mesure où j’ai documenté l’utilisation des dépôts APT de ces versions autocompilées de dpkg dans le wiki.

J’ai commencé à la fin de ce mois (de septembre) à travailler sur une nouvelle version mineure de dpkg (qui s’apprête à devenir la 1.16.1.1), en corrigeant les inévitables problèmes engendrés par un upload représentant 4 mois de travail (cf. les 4 derniers commits).

Le Cahier de l’Admin Debian

Je ne compte plus les heures passées à finaliser le lancement de la campagne de récolte de fonds pour le Cahier de l’Admin Debian en version anglophone, lancement qui a finalement eu lieu le 27 semptembre.

La collecte est actuellement sur de bons rails avec plus de 75% des fonds nécessaires à la traduction assurés. La route est par contre encore longue concernant le fond de libération (24% pour l’instant). Il est toujours intéressant de noter que plus de 55% des fonds récoltés sont destinés à la libération du livre, il y a donc un nombre important de personnes qui se sentent concernés par celle-ci.

Plus de 300 personnes ont apporté leur soutien au projet à ce jour, et la contribution moyenne s’élève à 38€ par personne. Je m’attendais à une contribution moyenne bien plus faible, mais un nombre de donateurs bien plus important. J’espère toujours attirer un nombre croissant de contributeurs grâce à la perspective d’obtenir un livre électronique sur Debian compatible avec les principes du logiciel libre selon Debian.

Alors, avez-vous déjà commandé votre exemplaire ? Si non, cliquez ici pour y remédier ! ;-) . Vous n’êtes d’ailleurs plus obligé de passer par PayPal pour se faire, mais simplement payer grâce à votre carte bleue.

Mises à jour diverses du blog anglophone

J’ai écrit, au fil du temps, plusieurs articles qui peuvent se révéler utiles pour les utilisateurs et contributeurs Debian. Dans les profondeurs de l’historique, ils ne sont malheureusement pas des plus faciles à trouver. C’est pourquoi j’ai créé des pages d’index pour les lister :

Deux nouveaux articles ont rejoint ces catégories ce mois-ci : Comment trier les bogues dans le système de suivi des bogues Debian (BTS) et Comprendre dpkg, et ne pas rester en plan à cause d’une erreur dans un script de maintenance.

L’écriture du premier article m’a fait réaliser que nous ne disposions pas d’une page montrant de manière synthétique les paquets les plus bogués : je l’ai donc rapidement créé (avec l’aide de UDD), et elle est visible ici.

Travail d’empaquetage divers

J’ai apporté une petite amélioration à la référence du développeur Debian. Luca Falavigna a soumis une modification clarifiant la gestion des méta-paquets (cf. bogue n°569219), j’en ai profité pour l’améliorer et l’intégrer dans le dépôt SVN.

J’ai mis à niveau le paquet nautilus-dropbox vers la version 0.6.9 et, tout en faisant cela, découvert un bogue dans l’outil mergechanges (bogue consigné comme le n°640782). J’ai également uploadé une nouvelle version de quilt, principalement pour mettre à disposition le champ Multi-Arch: foreign, de telle sorte que les dépendances sur quilt de paquets d’autres architectures puissent être satisfaites.

Django a publié quelques annonces de sécurité (consignées dans le bogue n°641405). Le mainteneur principal faisant défaut, j’ai pris le parti (je suis mainteneur de réserve) d’apporter les corrections nécessaires et de publier la version 1.3.1 dans unstable. J’en ai également profité pour passer de python-support à dh_python2, et améliorer quelque peu l’empaquetage (cf. la liste des modifications).

J’ai aussi voulu mettre à jour publican, mais cela s’est avéré impossible : Debian ne dispose pas encore de la dernière version de docbook-xsl. Ce fut l’occasion de découvrir quelques bogues et les rapporter aux auteurs amonts (cf. ces bogues). En plus de ces difficultés, fop refusait de fonctionner à cause d’une erreur liée à Java et l’introduction du support multi-architecture. Le mainteneur Java a rapidement diffusé une version corrigée après que j’ai remonté le bogue.

Publican est donc maintenant prêt et attend la mise à jour de dockbook-xsl dans le dépôt git. J’ai pris contact avec son mainteneur qui pense avoir le temps de s’en occuper vers la mi-octobre.

Merci

Au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Debian activities in September 2011 contribuée par Weierstrass01.

Garder un système Debian propre, astuce n°5 : identifier et supprimer les fichiers ne provenant pas de paquets

Après avoir abordé l’altération des paquets installés et comment y remédier, nous allons nous concentrer aujourd’hui sur les fichiers ne provenant pas d’un quelconque paquet.

Fichiers non-empaquetés

Certains fichiers ne proviennent pas d’un paquet Debian. Autrement dit dpkg --search ne trouve aucun paquet associé :

$ dpkg --search /srv/cvs
dpkg-query : aucun chemin ne correspond à /srv/cvs

Votre système en contient forcément, ne serait-ce que les fichiers présents dans votre /home. Et ce ne sont certainement pas les seuls, puisque de nombreux démons créent ce type de fichiers (qui sont habituellement stockés dans /var) lors de leur fonctionnement normal : fichiers locaux pour un serveur de bases de données, pool d’emails pour un serveur de mails, … C’est tout à fait normal, et vous ne souhaitez absolument pas y toucher !

A l’inverse, certains fichiers dans /usr peuvent ne pas avoir été empaquetés, ce qui n’est pas normal si vous installez systématiquement à partir de paquets. Les lister permet donc de détecter un logiciel installé manuellement.

L’installation manuelle : une mauvaise idée

L’installation manuelle d’un logiciel peut être la source de nombreux problèmes. Prenons l’exemple d’un logiciel installé manuellement, et également à partir d’un paquet Debian. Au fil du temps, l’installation faite à partir du paquet sera mise à jour, tandis que celle manuelle non. Les autres paquets dépendant de ce logiciel « croiront » que leurs dépendances seront satisfaites, puisque ledit logiciel est censé être à jour, alors qu’il n’en sera rien : l’installation manuelle prenant l’ascendant sur celle du paquet, les vieux fichiers seront toujours utilisés…

Convaincu de vouloir vous en débarrasser ? Voyons déjà comment les trouver.

Identifier les fichiers non empaquetés grâce à cruft

Comme expliqué précédemment, beaucoup de fichiers ne provenant pas de paquets sont licites, et ne doivent pas être supprimés. cruft propose ainsi un traitement un peu plus élaboré qu’un simple balayage du système de fichiers, couplé à des requêtes sur la base dpkg.

Ainsi, cruft fournit aux paquets un moyen de déclarer les fichiers qu’ils créent durant leurs exécutions, et qu’il ne doit pas considérer comme illégitimes. Et il en connaît beaucoup. Mais cruft n’est ni exhaustif, ni à jour ! La sortie de cruft doit donc être considérée avec beaucoup de recul, et il vous faut regarder à deux fois avant de supprimer quelque fichier que ce soit ! Vous voilà prévenu…

Utilisation de cruft

Une liste de répertoires à ignorer peut (et devrait) être passée en argument, afin de réduire le nombre de faux-positifs en sortie. Par exemple :

$ sudo cruft -d / -r report --ignore /home --ignore /var --ignore /tmp
$ less report
cruft report: mercredi 23 février 2011, 15:45:34 (UTC+0100)

---- missing: ALTERNATIVES ----
        /etc/alternatives/cli-csc.1.gz
        /usr/share/man/man1/cli-csc.1.gz
---- missing: dpkg ----
        /etc/xdg/autostart/gnome-power-manager.desktop
        /usr/lib/libpython2.6_d.so.1.0-gdb.py
        /usr/share/fonts/X11/100dpi
        /usr/share/fonts/X11/75dpi
---- unexplained: / ----
        /boot
        /dev
        /etc/.java
        /etc/.java/.systemPrefs
[...]
        /usr/lib/pymodules/python2.6
        /usr/lib/pymodules/python2.6/.path
        /usr/lib/pymodules/python2.6/Brlapi-0.5.5.egg-info
[...]

Note : cruft ne suit pas les arborescences à travers les différents systèmes de fichiers : si votre /usr est sur une autre partition que /, il vous faudra passer -d "/ /usr" en argument pour que les deux soient scannés.

Analyse du résultat

Il est maintenant possible de parcourir la liste générée en sortie, et décider quels fichiers doivent être — ou non — supprimés. La liste présente également les fichiers « manquants », qui devraient être présents selon dpkg, mais sont manifestement absents. Mais ce qui nous préoccupe avant tout se trouve dans la section « unexplained » : il s’agit là des fichiers ne provenant d’aucun paquet, et dont la présence n’est expliquée par aucun des scripts que les paquets auraient pu fournir.

Je rappelle une fois encore que cette liste n’est pas à prendre pour argent comptant ! Si vous ne savez pas pourquoi tel fichier est présent, il vaudrait mieux ne pas le supprimer… Sur mon système, cruft liste par exemple un nombre important de fichiers sous /usr/lib/pymodules/, et tous ces fichiers sont parfaitement légitimes : ils proviennent de paquets Debian mais sont copiés là dynamiquement depuis /usr/{lib,share}/pyshared, afin de supporter les multiples versions de Python. Si vous supprimez ces fichiers, vous endommagez votre système.

Concernant Python, cruft rapportera également de nombreux fichiers .pyc. Ces derniers sont créés par les paquets Python, et correspondent à des fichiers .py compilés. Les supprimer ne casse rien, par contre vous perdrez un peu en performances.

A contrario de ces « faux-positifs », la plupart des fichiers trouvés sous /usr/local/ sont probablement le résultat d’installations manuelles de logiciels, et leur suppression peut être considérée comme sans risque (si vous n’utilisez pas lesdits logiciels !).

Conclusion: utile, mais à parfaire

En résumé, cruft peut effectivement être utilisé pour trouver les fichiers ne provenant d’aucun paquet. Il vous permettra ainsi d’étudier en détail ce qui est installé sur votre système. L’extraction des données utiles du rapport reste par contre très fastidieuse, vu le nombre conséquent de faux-positifs.

cruft a ainsi grandement besoin de bonnes volontés supplémentaires, ce afin de prendre en charge les nombreuses façons dont les paquets génèrent des fichiers. Les pré-requis pour s’y atteler sont faibles : le paquet est codé principalement en Python et en shell, et /usr/share/doc/cruft/README.gz détaille son fonctionnement.

Ceci est une traduction de mon article Debian Cleanup Tip #5: identify cruft that can be removed from your Debian system contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.

Garder un système Debian propre, astuce n°4 : trouver et réinstaller les paquets altérés

Après avoir vu comment se débarrasser des paquets des éditeurs tiers, nous allons un peu plus loin aujourd’hui en nous intéressant à l’évolution des paquets installés. Plus précisément, ce billet explique comment vérifier que les fichiers composant les paquets sont toujours identiques à ce qu’ils étaient lors de l’installation.

En effet si, en bon bricoleur, vous avez modifié manuellement certains fichiers afin de procéder à quelques tests rapides, ou si vous installez les nouvelles versions de paquets à partir des sources, il est possible que vous ayez remplacé certains fichiers provenant du paquet originel. Ne serait-il pas intéressant de détecter ces modifications (et d’y remédier !) ? debsums est l’outil parfait pour cela.

Utiliser debsums pour identifier les fichiers modifiés

J’utilise fréquemment debsums lorsque je prends en charge la maintenance d’un serveur Debian, afin de dresser la liste des fichiers modifiés par le précédent administrateur.

Lancé sans argument, debsums est très verbeux : il listera chaque fichier installé (à l’exception des fichiers de configuration) en affichant son état en regard : « OK » s’il n’a pas été modifié, et « FAILED » dans le cas contraire.

$ sudo debsums
/usr/bin/a2ps                                               OK
[...]

L’option --all permet d’inclure les fichiers de configuration également. L’option --config permet, au contraire, de ne prendre en compte que les fichiers de configuration.

L’option --changed, enfin, permet de demander à debsums une liste restreinte aux seuls fichiers modifiés. La commande suivante va donc permettre de ne lister que les fichiers ayant été modifiés sur le système, et qui ne sont pas des fichiers de configuration :

$ sudo debsums --changed
/usr/lib/perl5/AptPkg/Config.pm
/usr/lib/perl5/AptPkg.pm
[...]

Remonter aux paquets concernés, et les réinstaller

Parmi les fichiers modifiés, debsums a trouvé /usr/lib/perl5/AptPkg.pm. C’est exact, je me souviens avoir manuellement installé une version modifiée de ce module Perl.

J’en ai déduit le paquet concerné grâce à la commande dpkg --search /usr/lib/perl5/AptPkg.pm : il s’agit de libapt-pkg-perl.

Tout ce qu’il me reste à faire alors est de réinstaller le paquet pour ré-écraser les fichiers modifiés avec les originaux :

$ sudo aptitude reinstall libapt-pkg-perl
[...]
# Ou avec apt-get
$ sudo apt-get --reinstall install libapt-pkg-perl
[...]

Il ne reste plus qu’à recommencer le processus jusqu’à ce que debsums ne remonte plus aucun fichier modifié.

Ceci est une traduction de mon article Debian Cleanup Tip #4: find broken packages and reinstall them contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.

Libérez la traduction anglaise du Cahier de l’Admin Debian Squeeze

La campagne de financement pour la traduction du Cahier de l’Admin Debian Squeeze et sa libération a débutée hier. Vers 10h du matin les abonnés à ma newsletter ont reçu le message suivant:

Bonjour,

Cela fait plus de 6 ans que la première édition du Cahier de l’Admin Debian a été publiée. Malgré son succès incontestable, aucun éditeur international n’a jamais pris le risque d’en réaliser une traduction en anglais. À quelques semaines de la sortie d’une cinquième édition revue pour Debian 6.0 « Squeeze », Roland Mas et moi-même avons décidé de prendre le taureau par les cornes et de réaliser cette traduction.

Pour mener à bien cette opération nous avons toutefois besoin de temps (et donc d’argent), et nous avons mis en place une campagne de financement en ligne pour nous assurer que nous ne travaillerons pas pour rien. Pour rendre le projet encore plus intéressant, nous avons pour objectif de publier le livre traduit sous une licence libre… à la condition toutefois que le fond de libération que nous mettons en place atteigne les 25000 EUR.

Même si vous n’êtes pas intéressé par la version anglaise du livre, vous pouvez obtenir la nouvelle édition à paraître du livre français tout en apportant votre soutien à ce projet. Ce n’est pas tous les jours que l’on a l’opportunité de libérer un livre et je compte sur votre soutien pour faire de ce projet un succès qui donnera envie à d’autres de suivre cet exemple.

Cliquez ici pour vous rendre sur la page du projet, puis choisissez la « récompense » qui vous intéresse dans la colonne de droite. Cela ne prend que quelques minutes et vous aurez apporté votre pierre au fabuleux édifice qu’est Debian.

Je vous serai également reconnaissant de diffuser ce message à vos amis et connaissances qui sont susceptibles de faire un geste pour soutenir ce projet. C’est le bouche à oreille qui a fait le succès du livre, et c’est lui qui fera le succès — je l’espère — de cette campagne.

À bientôt,
    Raphaël Hertzog.

Bilan à J+1

Un peu plus de 24h après le lancement officiel, je suis heureux de constater que l’on vient de franchir les 20% pour le financement de base, mais nous n’en sommes qu’à 7% sur le fond de libération. Il reste donc du chemin à faire…

Je suis toutefois confiant car je pense avoir assez bien expliqué les mérites et l’intérêt de ce projet, et je sais que je peux compter sur la communauté du libre. D’ailleurs nous avons été honoré d’un soutien de 500€ de la part de la Free Software Foundation France:

R. Hertzog and R. Mas have been an instrumental part of Debian GNU/Linux for a long time. This book is a shining example of their contribution and FSF France is proud to participate. Lien vers le commentaire original

Je vous invite donc à suivre l’exemple de la FSF France : cliquez ici pour vous rendre sur la page du projet, décidez d’un montant pour votre don et choisissez votre récompense!

Soutenir Debian et le projet de traduction

Pour rendre ce projet encore plus attirant, vous pouvez choisir de le soutenir en cliquant sur le lien ci-dessous et dans ce cas 15% de l’argent versé (une fois la TVA enlevée) sera reversé au projet Debian.

Lien pour soutenir Debian : http://debian-handbook.info/go/ulule-debian/

N’hésitez pas à partager ce lien à vos amis… Mieux encore vous pouvez mettre un widget sur votre site et 15% des sommes versées par ceux qui supporteront le projet grâce à vous seront également reversées à Debian.

Merci à tous ceux qui contribuent au succès de ce projet !

Garder un système Debian propre, astuce n°3 : se débarrasser des paquets externes à Debian

Le dernier billet de notre série évoquait la suppression des paquets obsolètes. Le billet d’aujourd’hui va vous montrer comment faire retrouver à votre ordinateur un état proche de celui obtenu après une installation de Debian/Ubuntu, sans paquets tiers.

APT a cela de puissant qu’il permet facilement l’ajout de nouveaux dépôts externes, et l’installation de logiciels à partir de ces derniers. Malheureusement, certains de ces logiciels ne s’avèrent pas être très bien maintenus : paquets de piètre qualité ou plus mis à jour. Un paquet fonctionnant parfaitement au début peut devenir une plaie pour la maintenance du système, par exemple en posant une dépendance sur un paquet devant être supprimé lors de la mise à jour.

Mon but ici est donc de vous montrer comment identifier ces paquets, qui ne proviennent ni de Debian, ni d’Ubuntu, de telle sorte que vous puissiez les passer en revue de temps en temps, et ne garder que ceux dont vous avez réellement besoin. Les paquets obsolètes sont en fait un sous-ensemble de ces paquets mais, les ayant traités dans le dernier billet, je n’y reviendrai pas.

Tout dépôt APT bien conçu est fourni avec un fichier Release le décrivant (celui-ci par exemple). Ces fichiers contiennent un certain nombre de valeurs permettant à APT d’identifier les paquets que contiennent les dépôts correspondants. Tous les dépôts officiels Debian mentionnent ainsi Origin=Debian (ou Origin=Ubuntu pour Ubuntu). L’attribut Origin de chaque dépôt présent dans votre fichier sources.list peut être vérifié grâce à apt-cache policy :

[...]
 500 http://ftp.debian.org/debian/ lenny/main i386 Packages
     release v=5.0.8,o=Debian,a=stable,n=lenny,l=Debian,c=main
     origin ftp.debian.org
[...]

Partant de là, il suffit de demander à aptitude de renvoyer la liste des paquets installés mais non présents dans un dépôt Debian officiel :

$ aptitude search '?narrow(?installed, !?origin(Debian))!?obsolete'
ou
$ aptitude search '~S ~i !~ODebian !~o'

search peut être remplacé par purge ou remove si vous souhaitez supprimer/purger tous les paquets correspondants. Ceci étant, il est plus probable que vous ne vouliez en supprimer que quelques-uns, intelligemment choisis : il y en a encore sûrement que vous utilisez !

synaptic vous permet également de parcourir le contenu de chaque dépôt : cliquez sur le bouton « Origine » et une liste de dépôts apparaît. Il suffit de parcourir les dépôts non-Debian à la recherche des paquets installés et à jour.

Mais il est possible de faire mieux : créer une vue personnalisée. Pour cela cliquez sur l’entrée « Filtres » du menu « Configuration ». Cliquez ensuite sur « Nouveau » pour créer un nouveau filtre, appelez-le par exemple « Paquet externe ». Décochez toutes les entrées de l’onglet « État », à l’exception de « Installés ».

Allez ensuite dans l’onglet « Propriété » pour ajouter une nouvelle entrée : « Origine » « exclut » « ftp.debian.org ». Remplacez évidemment ftp.debian.org par le nom du miroir que vous utilisez (il apparaît dans la sortie d’apt-cache policy, cf. l’exemple présenté un peu plus haut).

Note : le terme « Origine » fait référence à deux notions distinctes : un attribut du fichier Release évoqué précédemment, mais aussi le nom de l’hôte d’un dépôt APT. Ce qui est un peu perturbant si l’on y prête pas attention.

Fermez la fenêtre de définition des filtres en cliquant sur « OK ». Une nouvelle liste « Paquet externe » est maintenant disponible dans l’onglet « Filtres personnalisés ». Vous pouvez maintenant voir quels paquets sont installés et à jour, et décider si vous souhaitez les garder ou pas. Si le paquet est également fourni par Debian/Ubuntu et que vous désirez changer pour ce dernier, utilisez « Paquet > Forcer version ».

Ceci est une traduction de mon article Debian Cleanup Tip #3: get rid of third-party packages contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Mes activités Debian en août 2011

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 (91,44 €, 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.

Dpkg

J’ai intégré mon implémentation de dpkg-source --commit à mon retour de la DebConf (travail que je vous avais présenté le mois dernier). J’ai continué à travailler un peu sur les drapeaux de compilation renforcée, mais le projet est gelé tant que Kees Cook n’aura pas fourni la documentation requise pour intégration dans dpkg-buildflags(1).

Pour faire suite à une discussion tenue pendant la DebConf, Michael Prokop a eu la gentillesse de mettre en place un auto-builder de dpkg déclenché par git (en utilisant Jenkins). Vous pouvez maintenant nous aider en testant la dernière version git. Pour ce faire :

$ wget -O - http://jenkins.grml.org/debian/C525F56752D4A654.asc | sudo apt-key add -
$ sudo sponge /etc/apt/sources.list.d/dpkg-git <<END
deb http://jenkins.grml.org/debian dpkg main
END
$ sudo apt-get update && sudo apt-get upgrade

Du côté des corrections de bogues, je me suis occupé de :

  • n°640198 : mise à jour mineure d’une page de man ;
  • n°638291 : correctif permettant de gérer proprement les liens directs (« hardlinks ») des fichiers conffiles ;
  • n°637564 : la logique était défecteuse dans certains cas ;
  • n°631494 : l’interruption de dpkg-source lors de la compilation d’un paquet source natif laissait quelques fichiers temporaires devant être effacés.

Mise à jour de WordPress

J’ai mis à jour WordPress en version 3.2.1 dans unstable (après avoir pris le temps de tester le nouveau paquet sur ce blog !) et corrigé ses bogues RC (n°625773). Ce fut l’occasion de découvrir un faux-positif dans lintian, consigné dans le n°637473.

Paquet Gnome-shell-timer

Je pratique, de temps en temps, la technique dite « Pomodoro ». J’étais donc un utilisateur occasionnel du paquet timer-applet de GNOME 2. Paquet que j’ai perdu avec la bascule vers GNOME 3. Le paquet gnome-shell-timer, que j’ai découvert récemment, est une extension GNOME Shell fournissant les mêmes fonctionnalités.

J’en ai donc fait un paquet Debian, tout en remplissant quelques rapports de bogues à mesure que je le testais (deux problèmes d’ergonomie et un problème d’encodage).

Assurance Qualité

J’ai rencontré Giovanni Mascellani durant la DebConf, qui souhaitait prêter main forte à l’équipe en charge de l’Assurance Qualité. Il s’est tout d’abord attaqué aux bogues en souffrance du système de suivi des paquets (PTS – Package Tracking System) et a soumis un certain nombre de correctifs. Je les ai revus et fusionnés avec la branche principale mais, dans la mesure où ils étaient de bonne qualité, la paresse m’a rapidement gagné et je l’ai fait entrer dans l’équipe Qualité. Il peut maintenant commiter ses corrections tout seul. La confiance en ressort également renforcée lorsque vous avez l’ocassion de discuter entre quatre yeux. :-)

Vacances

Tout cela ne représente pas beaucoup comparé aux mois précédents mais, pour ma défense, j’ai pris deux semaines de vacances. Ceci étant, je ne peux quoi qu’il arrive pas vraiment oublier Debian. Regardez mon fils :

Merci

Au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Debian activities in August 2011 contribuée par Weierstrass01.

Garder un système Debian propre, astuce n°2 : se débarrasser des paquets obsolètes

Dans le billet précédent, nous avons appris comment supprimer les fichiers de configuration inutiles. Dans cet article, nous allons maintenant voir comment s’occuper des paquets obsolètes.

Un paquet est considéré comme obsolète du moment que plus aucun des dépôts APT présents dans le fichier /etc/apt/source.lists (et /etc/apt/sources.list.d/) ne le fournit. De nombreuses raisons peuvent conduire à cet état :

  • L’auteur amont du paquet a arrêté tout support depuis un long moment, personne n’a pris la relève et le mainteneur Debian a préféré retirer le paquet de l’archive Debian. Des alternatives sont la plupart du temps disponibles en remplacement ;
  • Le paquet Debian était orphelin depuis longtemps, personne ne l’a repris en charge et il n’avait que peu d’utilisateurs. Il se peut également que l’équipe Debian QA (Quality Assurance – Assurance Qualité) ait demandé son retrait ;
  • La dernière version du paquet a été empaquetée sous un nom différent. Soit en raison d’un nombre de changements tellement important qu’il était préférable de ne pas mettre à jour automatiquement vers le dernier paquet (ce fut le cas pour request-tracker et nagios par exemple, qui embarquaient tous les deux un numéro de version dans leurs noms), soit simplement parce que le mainteneur du paquet souhaitait permettre à l’utilisateur d’avoir plusieurs versions du paquet installées en même temps (ce qui est le cas par exemple pour le noyau Linux, l’interpréteur Python et de nombreuses bibliothèques) ;
  • l’application a été renommée, et le mainteneur a donc renommé le paquet. Il a gardé un paquet de transition sous l’ancien nom pendant un cycle de publication puis ce dernier a été supprimé.

Ce n’est dans tous les cas jamais une bonne idée de conserver les paquets obsolètes : ils ne profitent d’aucune mise à jour de sécurité, et peuvent causer des problèmes lors des mises à jour, en dépendant de paquets devant être supprimés pour finir celles-ci.

Vous pouvez les supprimez d’un seul coup grâce à aptitude purge ~o (ou aptitude purge ?obsolete), mais vous souhaitez peut-être analyser un peu plus la situation avant : il se pourrait que certains paquets que vous avez installés manuellement (et absents des dépôts APT) fassent partie du lot, et ces derniers ne doivent pas subir le même traitement (me concernant, j’ai par exemple Skype et quelques paquets personnels). Vous pouvez obtenir la liste des paquets concernés via aptitude search ?obsolete.

Cette même liste est bien sûr accessible en passant par Synaptic, gestionnaire de paquets en mode graphique : cliquez sur le bouton « État », puis sur « Installés (locaux ou obsolètes) ». Vous pouvez maintenant parcourir la liste et décider, pour chaque paquet, s’il doit être conservé ou non.

Ceci est une traduction de mon article Debian Cleanup Tip #2: Get rid of obsolete packages contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Garder un système Debian propre, astuce n°1 : se débarrasser des fichiers de configuration inutiles

Si vous êtes de ceux aimant garder un bureau bien rangé, il en va certainement de même avec votre ordinateur ! À cette fin, je vais détailler, au travers de 4 articles dont voici le premier, quelques astuces pour maintenir votre Debian/Ubuntu toute propre !

Au fil du temps et de l’utilisation de votre ordinateur, l’ensemble des paquets installés va évoluer. Soit parce que vous avez installé/supprimé des applications, soit parce que vous avez mis à jour votre distribution.

Ceci étant, le système de gestion des paquets Debian est construit de telle sorte qu’il conserve les fichiers de configuration d’un paquet lors de sa suppression. C’est une fonctionnalité intéressante, dans la mesure où vous n’aurez pas à refaire le paramétrage de ce paquet lorsque vous le réinstallerez. Oui, mais… et si vous ne réinstallez jamais ?

Dans ce dernier cas, ces fichiers de configuration « encombrent » inutilement votre système, voire le « parasitent » ! Un exemple (m’étant récemment arrivé) : des scripts init obsolètes empêchant le passage à une séquence de boot basée sur les dépendances, car ils n’embarquaient aucune dépendance nécessaire. Bref, vous préféreriez vous en débarrasser.

La solution à ce problème consiste à « purger » tous les paquets dont il ne reste plus que les fichiers de configuration présents sur le système. Avec aptitude c’est possible avec la commande aptitude purge ~c (ou aptitude purge ?config-files). Il suffit de remplacer purge par search pour visualiser uniquement la liste des paquets concernés.

Si vous souhaitez une mise en forme adaptée de cette liste, de sorte qu’elle puisse être repassée en argument à un autre programme, utilisez une des commandes suivantes (et passez le résultat à apt-get si aptitude n’est pas installé) :

$ grep-status -n -sPackage -FStatus config-files
[...]
$ dpkg-query -f '${Package} ${Status}\n' -W | grep config-files$ | cut -d" " -f1
[...]

Note : grep-status fait partie du paquet dctrl-tools .

La solution précédente faisait intervenir la ligne de commande, mais vous pouvez tout aussi bien utiliser un gestionnaire graphique de paquets, comme Synaptic. Cliquez sur le bouton « État » en bas à gauche, puis sur « Non installés (résidus de configuration) », et la liste des paquets pouvant être purgés s’affiche. Sélectionnez-les tous, puis clic-droit « Marquer pour suppression complète » (cf. la capture d’écran ci-dessous). Enfin, cliquez sur « Appliquer » pour lancer la purge des paquets.

Ceci est une traduction de mon article Debian Cleanup Tip #1: Get rid of useless configuration files contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.

Gérer des patchs spécifiques à chaque distribution avec un paquet source commun

Un patch peut-il n’être appliqué au paquet cible que pour certaines distributions ? Cette question m’a été posée en commentaire d’un précédent article présentant la gestion différentielle des dépendances entre Ubuntu et Debian, à partir d’un même paquet source. Et la réponse est … oui. C’est possible !

Le format de paquets source 3.0 (quilt) offre à cette fin une possibilité intéressante : plutôt que d’utiliser uniquement le fichier debian/patches/series pour rechercher des patches, dpkg-source essaye en premier lieu d’utiliser debian/patches/distrib.series, où « distrib » vaut « ubuntu », « debian », … Il est important de noter que dpkg-source n’applique pas les patches de tous les fichiers series trouvés : seuls les patches du premier fichier trouvé sont considérés.

Bien, mais comment tirer le meilleur parti de tout cela ? Debian est supposée toujours fournir le fichier debian/patches/series, ce dernier devant indiquer l’ensemble des patches « de base » à appliquer. N’importe quel tiers travaillant avec Debian peut maintenir son propre fichier series dans le dépôt CVS commun de maintenance des paquets. Il peut ainsi laisser de côté certains patches propres à Debian (les patches relatifs à la marque, par exemple), et intégrer les siens en plus des patches restants.

Il est intéressant de noter que c’est au mainteneur de s’assurer, en cas de besoin, de la cohérence des deux fichiers. dpkg-source n’offre ni la possibilité d’agréger plusieurs fichiers series, ni d’établir une quelconque dépendance entre eux.

Pour éditer un fichier series alternatif grâce à quilt, il suffit de positionner temporairement la variable d’environnement QUILT_SERIES à « distrib.series ». Faites simplement attention à bien partir d’un état vierge (i.e. aucun patch appliqué). Si tel n’est pas le cas, quilt sera confronté à une incohérence entre les données du fichier series et ses propres données (stockées dans le dossier .pc).

Ceci est une traduction de mon article Managing distribution-specific patches with a common source package contribuée par Weierstrass01. Si vous avez apprécié cet article, cliquez ici pour découvrir comment m’encourager à en rédiger d’autres.

Mes activités Debian en juillet 2011

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 (170 €, 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.

Le mois de juillet est passé à toute vitesse, en grande partie parce que j’ai participé à la fois aux RMLL – Rencontres Mondiales du Logiciel Libre et à la DebConf.

Les RMLL

Du fait de ma présence d’une semaine complète un peu plus tard dans le mois à la DebConf, je n’ai participé « que 3 jours » sur les 6 que duraient ces Rencontres.

Et, durant ces 3 jours, j’ai aidé à la tenue du stand Debian, déjà en de bonnes mains : celles de Frédéric Perrenot et Arnaud Gambonnet. Nous n’avions malheureusement aucun goodies à vendre, et c’est là un point sur lequel nous devrons nous améliorer d’ici la prochaine fois (par nous j’entends Debian France).

J’ai assisté, entre autres, à une conférence présentant EnVenteLibre. Ce site a été créé, au départ, comme boutique en ligne pour les associations Ubuntu-fr et Framasoft. Toute la logistique est sous-traitée, seules les commandes de goodies et leurs livraisons à l’entrepôt du sous-traitant sont de leur responsabilité. Ils peuvent également envoyer directement du matériel de l’entrepôt pour une conférence, par exemple. Nous avons discuté dans les grandes lignes d’une éventuelle adhésion de Debian France, voire même, pour Debian et toutes ses associations locales, de la possibilité d’opérer à l’échelle internationale.

Une fois de retour, et bien qu’ayant passé trois bonnes journées à Strasbourg, il m’a semblé que cet événement perdait, petit à petit, en importance : il est loin d’être de dimension internationale, et le nombre de conférences ne joue pas en faveur de la qualité.

En passant, est-ce que vous vous rappelez que Debconf 0 et Debconf 1 ont été associées à cet événement lorsqu’il s’est déroulé à Bordeaux ?

Améliorations de dpkg-source

J’ai apporté certaines modifications au format source 3.0 (quilt) durant mon séjour à Strasbourg (et plus particulièrement durant les trajets aller et retour !). dpkg-source refusera maintenant la compilation d’un paquet source si celui-ci comporte des changements upstream qui ne sont pas correctement enregistrés dans un patch quilt :

dpkg-source: info: local changes detected, the modified files are:
 2ping-1.1/README
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/2ping_1.1-1.diff.cki8YB

Comme le suggère le message d’erreur, une nouvelle option --commit supportée par dpkg-source permet de générer le patch quilt correspondant. Vous devrez, dans ce processus, soumettre un nom pour le patch généré et éditer son en-tête (pré-formaté avec des champs compatibles DEP3). Le retour à l’ancien comportement peut être forcé via l’option --auto-commit.

Changement des drapeaux de compilation

Depuis que dpkg-buildpackage définit lui-même les variables d’environnement relatives à la compilation (cf. n°465282, un changement proposé originellement par Ubuntu), de nombreuses voix au sein de Debian ont exprimé leurs insatisfaction quant à l’approche retenue. Ces commentaires mettaient en avant les problèmes créés sur certains paquets, et le fait que ces mêmes variables ne sont pas définies si l’on exécute debian/rules directement.

La modification fut toutefois conservée, et les paquets « cassés » par cette dernière ont été réparés. En dépit de tout ceci, décision fut prise plus tard de créer dpkg-buildflags comme l’interface appropriée pour injecter des drapeaux de compilation.

Avant de modifier dpkg-buildpackage de sorte qu’il ne définisse plus ces drapeaux, j’ai tenu à m’assurer que dpkg-buildflags soit suffisamment répandu (au sens d’utilisé) dans l’archive, afin d’éviter de casser de nouveau un trop grand nombre de paquets. J’ai retenu comme critère l’utilisation de dpkg-buildflags par CDBS et dh (de dhbhelper). La condition d’application fut satisfaite avec la modification récente de debhelper (cf. n°544844), j’ai donc modifié dpkg-buildpackage en conséquence.

Extraits (snippets) de makefile fournis par dpkg

En parallèle de ces travaux, j’ai souhaité mettre à disposition des mainteneurs une manière simple (qui n’utilise ni dh ni CDBS) de réparer les paquets impactés d’une part, et également d’injecter les drapeaux de compilation à partir des fichiers debian/rules. Ce sera possible à compter de la prochaine version de dpkg, via un bout de code ressemblant à ceci :

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk

Sans DPKG_EXPORT_BUILDFLAGS à 1, les variables ne sont pas exportées dans l’environnement et sont sans effet, à moins bien sûr que vous ne les utilisiez autre part.

En plus de ces drapeaux de compilation, bien d’autres variables — pouvant être utiles dans les fichiers debian/rules — seront mises à disposition par ce biais : celles fournies par dpkg-architecture, les variables/macro liées à l’outil dpkg-vendor et quelques informations de base du paquet (principalement liées à la version).

Améliorations de dpkg-buildflags

Étant donné l’importance croissante que dpkg-buildflags va prendre maintenant que dpkg-buildpackage n’initialise plus les variables d’environnement correspondantes, j’ai pris le parti de corriger tous les bogues ouverts et d’implémenter quelques suggestions qui me sont parvenues.

J’ai également discuté avec quelques membres du comité technique de la manière dont les drapeaux de compilation renforcée (hardening build flags) pourraient être activés dans Debian. Discussion qui amena également certaines idées d’amélioration.

En résumé, voici les principales modifications réalisées :

  • Nouvelle directive « prepend » permettant d’injecter les drapeaux au début de la chaîne retournée (cf. ce commit);
  • Nouvelle directive « strip » permettant d’enlever des drapeaux de la sortie retournée par dpkg-buildflags (cf. ce commit);
  • Nouvelles variables d’environnement DEB_flag_MAINT_directive pouvant être initialisées par le mainteneur afin de paramétrer la sortie de dpkg-buildflags (cf. ce commit);
  • Nouvelle option --export=configure permettant d’injecter les drapeaux via la commande ./configure (cf. ce commit);
  • Nouvelle option --dump par défaut (cf. n°603435).

Tous ces changements rendent dpkg-buildflags capable de retourner l’ensemble des drapeaux de compilation possibles (il ne retournait auparavant que les drapeaux par défaut, et l’empaquetage Debian était supposé y ajouter tout élément supplémentaire nécessaire après coup). Le travail du mainteneur se réduit maintenant, pour cette partie, à utiliser les nouvelles variables d’environnement, afin de s’assurer que les valeurs retournées correspondent bien aux besoins des paquets.

DebConf: rolling et drapeaux de compilation renforcée

J’ai participé une semaine entière à la DebConf (du dimanche 24 au dimanche 31) et, comme à l’accoutumée, ce fut un plaisir de revoir mes amis de Debian. C’est toujours difficile de trouver le bon équilibre entre assister aux conférences, travailler au hacklab et développer les relations humaines, mais je suis plutôt content du résultat obtenu.

Je n’avais aucun but précis lorsque je suis arrivé, excepté animer une session de discussion (« BoF ») autour de Debian rolling (diapos et vidéos de la discussion) . Ceci étant, toutes les discussions lors des débats allongent la TODO list, et cette année ne fit pas exception à la règle. Le BoF du comité technique aborda certaines questions en suspens, dont une m’intéresse particulièrement : comment activer les drapeaux de compilation renforcée dans Debian (cf. n°552688).

Une autre discussion sur le sujet fut prévue le mardi et il en ressort que dpkg-buildflags constitue l’interface appropriée pour injecter ces drapeaux. À condition toutefois que ce dernier offre un moyen de laisser tomber les drapeaux indésirables et dispose d’une interface pratique pour les injecter via la commande ./configure.

Compte tenu de tous ces éléments, je me mis au travail pour implémenter ces nouvelles fonctionnalités, et préparai avec Kees Cook un patch d’activation de ces drapeaux par défaut. Il n’est pas encore prêt à être intégré dans la branche officielle, mais est déjà fonctionnel. (cf. mon dernier commentaire du bogue).

Quelques mots à propos du BoF sur rolling également. Les auditeurs venus en nombre témoignent, comme à l’habitude, de l’intérêt que suscite ce sujet. Le but que je souhaitais atteindre était assez limité : mesurer le poids et l’importance respective des différentes opinions exprimées lors de la dernière discussion fleuve sur debian-devel.

Il s’est avéré qu’une majorité significative des participants estiment testing utilisable dès à présent. Mais l’opportunité de lui faire une plus grande publicité recueille des avis plus partagés. Quant à la question de savoir si nous pouvons supporter un grand nombre d’utilisateurs de testing/rolling, peu s’estiment qualifiés pour répondre, mais ceux qui le croient répondent oui.

Encore du travail sur dpkg…

Réalisation de plein de petites choses :

  • J’ai encore fait du triage de bogues sur Launchpad. Brian Murray a abattu un travail monstre et le résultat est impressionnant : nous sommes descendus à environ 150 bogues (à comparer aux 300 et plus du mois précédent !);
  • J’ai mis à jour ma branche multiarch de nombreuses fois. J’espérais rencontrer Guillem pendant la DebConf, afin de faire quelques progrès dans ce domaine, mais il n’y participa malheureusement pas. À plusieurs reprises au cours de la semaine des personnes m’ont interpellé pour avoir des nouvelles sur son intégration;
  • J’ai corrigé une régression affectant update-alternatives (bogue n°633627), l’échec d’une suite de tests lorsque lancée en tant que root (#634961), et une erreur de segmentation dans findbreakcycle(). Un bon paquet d’améliorations mineures furent également de la partie (n°634510, 633539, 608260, 632937).

Système de suivi des paquets (PTS) et DEHS

Un remplaçant de DEHS a été écrit par Christoph Berg, car celui-ci n’était pas vraiment fiable, et pas sous contrôle de l’équipe en charge de la qualité. Pour ceux qui ne connaissent pas cet outil, il s’agit d’un système centralisé utilisant les fichiers debian/watch pour détecter les dernières versions amont des logiciels disponibles dans Debian.

J’ai mis à jour le Système de suivi des paquets (PTS – Package Tracking System), afin qu’il utilise ce nouvel outil en lieu et place de DEHS. Cela fonctionne bien, mais il manque encore les notifications par mail que DEHS envoyait. Si d’aventure quelqu’un voulait contribuer cette fonctionnalité, ce serait chouette !

Empaquetages divers

J’ai accompli quelques tâches préalables à la mise à jour du paquet WordPress vers la toute dernière version upstream (3.2). Il me reste à tester le paquet qui en résulte : remplacer les copies des bibiliothèques javascript/PHP fournies par les développeurs amont présente toujours des risques, et manque de chance, elles ont toutes subies des modifications dans le processus d’intégration.

J’ai également mis à jour nautilus-dropbox vers la version 0.6.8. J’ai également uploadé la version précédente (présente dans testing jusqu’alors) dans squeeze-backports. Un paquet Debian officiel est maintenant présent pour cette application dans toutes les distributions Debian (squeeze, wheezy, sid et experimental).

Merci

Au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Debian activities in July 2011 contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.