Vous êtes ici: Accueil / Archives pour Raphaël Hertzog

Mes activités Debian en janvier 2012

04/02/2012 Par Laisser un commentaire:

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 (213,68 €, 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

La plus « importante » modification réalisée a consisté en un petit patch mettant un terme à des années de discussions récurrentes à propos des cibles build-arch et build-indep de debian/rules (cf. bogue n°229357).

Le Comité Technique s’était auparavant saisi du dossier (cf. bogue n°629385) mais avait échoué à prendre une quelconque décision. Cela nous a néanmoins permis d’obtenir des chiffres concrets sur les dommages collatéraux infligés aux archives pour chacune des méthodes envisagées. Guillem et moi-même sommes finalement parvenus à un accord sur la voie à emprunter.

Le reste de ce que j’ai accompli en tant que mainteneur du paquet dpkg n’a pas grand chose à voir avec de la programmation : j’ai passé en revue le travail qu’a effectué Gianluca Ciccarelli sur dpkg-maintscript-helper. Celui-ci essaye de mettre au point des outils facilitant la migration entre dossiers et liens symboliques. J’ai également revu le patch long de 2000 lignes de Patrick Schoenfeld : la finalité étant de mettre à disposition une API Perl permettant de parcourir les logs de dpkg, et d’en extraire des informations utiles.

J’ai mis à jour la page de manuel de dpkg-architecture en documentant l’extrait de code Makefile /usr/share/dpkg/architecture.mk, et en retirant les informations qui ne sont plus pertinentes aujourd’hui.

J’ai passé en revue un énorme patch mis au point par Russ Alberry, et destiné à mettre à jour le guide de référence Debian, ainsi que documenter l’usage des fichiers symboles pour les bibliothèques. En tant que mainteneur de dpkg-gensymbols, je ne pouvais qu’être heureux de le voir proprement documenter au niveau de la référence développeur.

J’ai abordé sur la liste de diffusion dpkg un détail qui m’a ennuyé pendant un bon moment : certaines mentions de copyright étaient embarquées dans des chaînes traduisibles et, par conséquent, les mettre à jour demandait des efforts inutiles aux traducteurs. Nous avons finalement décidé de supprimer ces mentions, et de les garder uniquement dans les sources.

J’ai mis à jour ma branche multiarch sur celle de Guillem plusieurs fois, et toutes les corrections qu’elle contenait ont été intégrées (souvent sous une forme modifiée).

Malheureusement, et même si le code fonctionne plutôt bien, Guillem ne veut rien pousser dans Debian tant qu’il n’a pas fini de tout passer en revue… et le délai que cela entraîne affecte un certain nombre de personnes. Cyril Brulebois a essayé de publier un instantané de l’état actuel de la branche multiarch dans experimental, mais Guillem est revenu rapidement sur cet upload.

Je suis quelque peu perdu face à cette situation. Il continue de travailler dans son coin malgré mes offres répétées de l’aider, il ne partage pas beaucoup de détails, excepté certains commentaires dans les logs d’envoi ou lorsque cela touche l’interface publique. Je me suis une nouvelle fois plaint de cette triste situation.

Debian Package Maintenance Hub

Il s’agit du nom de code que j’utilise pour la nouvelle infrastructure que je souhaiterais développer, afin de remplacer le Système de Suivi des Paquets actuel (PTS – Packages Tracking System) ainsi que le tableau de bord des mainteneurs et d’autres services. J’ai commencé une ébauche de proposition d’amélioration (DEP – Debian Enhancement Proposal), cf. DEP-2, et demandé l’avis des personnes impliquées dans l’équipe Assurance Qualité.

Il semble que personne n’ait pour l’instant d’objections majeures quant à l’idée directrice de ce projet, et les commentaires exprimés sont plutôt enthousiastes. Je vais continuer à peaufiner cette proposition d’amélioration au sein de l’équipe Assurance Qualité jusqu’à ce qu’elle soit mûre pour une audience plus large, comme debian-devel@lists.debian.org.

Système de Suivi des Paquets

Même si j’ai commencé à concevoir son remplaçant, le Système de Suivi des Paquets actuel continuera à être utilisé pour quelques temps encore. En conséquence, j’ai implémenté deux nouvelles fonctionnalités qui me semblaient importantes : notifier le mainteneur (via la section « TODO ») lorsqu’au moins un bogue relatif à un objectif de publication est ouvert, et afficher une notification lorsque le paquet correspondant est concerné par une transition prévue ou en cours.

Tâches diverses d’empaquetage

J’ai créé et uploadé le paquet dh-linktree, un addon debhelper permettant de créer des arborescences de liens symboliques (utiles pour remplacer les copies embarquées de bibliothèques PHP/JavaScript par des liens symboliques vers leurs équivalents empaquetés).

J’ai également empaqueté quilt en version 0.50, et aidé les auteurs upstream à intégrer un patch Debian transmis par Martin Quinson (co-mainteneur de quilt). Autres empaquetages réalisés : celui de la mise à jour de sécurité de WordPress (3.3.1), et ceux des nouvelles versions amont de feed2omb et de gnome-shell-timer.

Enfin, j’ai préparé une nouvelle version Debian de python-django, corrigeant le bogue RC n°655666, et ce grâce à un patch récupéré depuis le dépôt SVN amont.

Traduction du Cahier de l’Admin : point d’étape

Nous continuons à progresser de manière satisfaisante dans la traduction du Cahier de l’Admin Debian : 12 chapitres sont maintenant traduits.

La campagne de libération poursuit (doucement) son bonhomme de chemin : 72% de la somme totale a été atteinte (grâce à 63 nouveaux donateurs !), contre 67% début janvier.

Merci

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

Ceci est une traduction de mon article My Debian Activities in January 2012 contribuée par Weierstrass01.

Dans la/les catégorie(s): Actualités, Actualités Debian Etiqueté avec: , , , , ,

4 astuces pour maintenir un paquet Debian « 3.0 (quilt) » dans un système de suivi de versions (VCS)

27/01/2012 Par Laisser un commentaire:

La plupart des paquets Debian sont gérés grâce à un logiciel de gestion de versions (VCS – Version Control System) tel que git, subversion, bazaar ou mercurial. Les particularités du format « 3.0 (quilt) » ne sont pas sans conséquences sur la gestion des paquets dans un VCS, et cet article va vous présenter quelques astuces afin d’en rendre l’usage plus agréable.

(Tous les exemples présentés ci-dessous s’appuient sur l’utilisation de git comme VCS).

1. Exclusion du répertoire .pc

Le répertoire .pc est utilisé par quilt afin de stocker ses données internes (liste des patchs appliqués, sauvegarde des fichiers modifiés). Il est également créé par dpkg-source de telle sorte que quilt « sache » que les patchs sont situés dans debian/patches (et non dans patches, qui est le répertoire que quilt utilise par défaut). À ce titre, le répertoire est conservé même lorsque plus aucun patch n’est actuellemement appliqué.

Vous ne tenez cependant pas à conserver ce répertoire dans votre dépôt : il doit donc être mentionné dans la liste des fichiers exclus. Avec git, il suffit d’indiquer :

$ echo ".pc" >>.gitignore
$ git add .gitignore
$ git commit -m "Ignore quilt dir"

Le fichier .gitignore n’étant pas pris en compte par dpkg-source, le paquet source généré par ce dernier ne sera pas « pollué ».

2. Retirer les patchs après la compilation

Si vous stockez vos sources « amont » avec les patchs non appliqués (ce que font la plupart des gens) et que vous ne compilez pas vos paquets dans un répertoire temporaire prévu à cet effet, alors vous souhaitez probablement « désappliquer » les patchs après la compilation, de sorte à retrouver un dépôt dans un état « propre ».

C’est désormais le comportement par défaut de dpkg-source. S’il a dû appliquer les patchs, il les enlèvera automatiquement également.

Mais on peut tout de même forcer ce comportement en ajoutant « unapply-patches » à debian/source/local-options :

$ echo "unapply-patches" >>debian/source/local-options
$ git add debian/source/local-options
$ git commit -m "Unapply patches after build"

svn-buildpackage compilant systématiquement dans un répertoire temporaire, le dépôt est laissé exactement dans le même état qu’avant la compilation : cette option est inutile dans ce cas. Ce comportement peut également être demandé à git-buildpackage grâce à l’option --git-export-dir=../build-area/ (../build-area/ étant le répertoire utilisé par svn-buildpackage, cette option force git-buildpackage à se comporter comme svn-buildpackage).

3. Gérer vos patchs quilt comme une branche git

Plutôt que de gérer les patchs spécifiques à Debian via quilt, il est possible d’utiliser git lui-même. Avec git-buildpackage vient l’outil gbp-pq (Git-BuildPackage Patch Queue – File des patchs de git-buildpackage). gbp-pq permet l’export d’une série quilt dans une branche git, que vous pouvez alors manipuler comme vous le souhaitez. Chaque commit représentant un patch, vous devez « rebaser » cette branche afin d’éditer les commits intermédiaires. Jetez un oeil à la documentation de gbp-pq pour appronfondir le sujet.

Alternative à gbp-pq, l’utilisation de git-dpm est plus compliquée, mais présente l’avantage de conserver l’historique de toutes les branches utilisées pour générer les séries quilt de toutes les publications Debian. Son principe de fonctionnement est très bien expliqué sur son site, et vous pouvez également souhaiter lire la revue qu’en a fait Sam Hartman, qui en présente les limites.

4. Documenter la manière de passer en revue les modifications

L’un des principaux bénéfices liés à l’utilisation du nouveau format source tient au fait qu’il est dorénavant simple de passer en revue les modifications amont : celles-ci sont conservées en autant de patchs distincts proprement documentés (et, idéalement, en utilisant le format DEP-3). En utilisant les outils décrits précédemment, le message de commit devient l’en-tête du patch. Il devient donc important de saisir des messages de commit explicites.

Cette méthode fonctionne bien tant que votre méthode de travail prend appui sur les patchs Debian, regroupés dans une branche que vous rebasez sur les sources amont à chaque publication. Certains mainteneurs n’aiment pas cette méthode de travail et préfèrent voir appliquer les modifications propres à Debian directement sur la branche d’empaquetage. Ils sautent alors vers une nouvelle version amont en la fusionnant dans cette dernière. Il est difficile dans ce cas de générer une série quilt à partir du système de suivi de versions. Il faut à la place indiquer à dpkg-source de stocker toutes les modifications dans un seul patch (qui devient alors équivalent au bon vieux .diff.gz), et documenter dans son en-tête comment mieux passer en revue les modifications, par exemple dans l’interface Web du VCS.

Le premier comportement est obtenu en passant l’option --single-debian-patch, et le second en écrivant l’en-tête dans debian/source/patch-header :

$ echo "single-debian-patch" >> debian/source/local-options
$ cat >debian/source/patch-header <<END
This patch contains all the Debian-specific
changes mixed together. To review them
separately, please inspect the VCS history
at http://git.debian.org/?=collab-maint/foo.git
<Put more details here>
END

Ceci est une traduction de mon article 4 tips to maintain a “3.0 (quilt)” Debian source package in a VCS 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.

Dans la/les catégorie(s): Documentation, Documentation pour les contributeurs Etiqueté avec: , , , , ,

Mes activités Debian en décembre 2011

09/01/2012 Par Laisser un commentaire:

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 (364,18 €, 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 et multiarch

J’avais quelques espoirs d’obtenir pour Noël, dans Sid, une version de dpkg supportant multi-arch. L’objectif était jugé réaliste par Guillem, mais celui-ci tomba malade… ce qui nous renvoie à ce mois de janvier, où rien n’a vraiment avancé.

La taille de sa branche pu/multiarch/master n’a pas vraiment diminué, et ce alors que certains de ses commits de décembre concernaient le support multi-architecture. Il nous en reste encore 36 à intégrer, et la majorité du travail qu’il a réalisé s’apparente à de la re-factorisation de bouts de code déjà intégrés. Il a également lancé plusieurs discussions concernant des changements d’interface. J’y ai participé, avec l’espoir de pouvoir de les amener à une conclusion rapide.

De mon côté, je maintiens toujours ma propre branche pu/multiarch/full, dérivée de celle de Guillem, mais augmentée de correctifs supplémentaires que j’ai réalisés, mais qui n’ont pas encore été intégrés. De plus, ma branche n’inclut pas une des modifications de Guillem : sa branche autorise en effet la mise à jour croisée de paquets entre architectures, tandis que dpkg ne gère pas encore correctement cette fonctionnalité.

J’ai commencé à travailler sur ce projet il y a un an déjà, et je ne peux qu’espérer que ce mois de janvier verra la conclusion de cette histoire sans fin. :-|

Travaux divers concernant dpkg

J’ai revu (et plus tard intégré) un patch de Kees Cook améliorant dpkg-buildflags de sorte que ce dernier puisse faire état des options de compilation renforcée activées. Cette fonctionnalité pourra ainsi permettre à des outils tels que lintian de détecter les options de compilation renforcée manquantes.

J’ai encadré/guidé Gianluca Ciccarelli qui essaye d’améliorer dpkg-maintscript-helper afin de gérer correctement le remplacement de répertoires par des liens symboliques, et vice-versa.

Je me suis occupé du bogue n°651993, de sorte que dpkg-mergechangelogs n’échoue plus lorsqu’il rencontre une version de changelog invalide. Je me suis également occupé du n°652414, de telle sorte que dpkg-source --commit accepte un nom de fichier relatif lorsqu’un fichier de patch lui est explicitement passé.

Guillem a également intégré un correctif que j’ai développé concernant le bogue LP n°369898.

Travaux d’empaquetage

Je me suis attelé à l’empaquetage de WordPress 3.3 dès que la version est sortie. L’upstream n’a pas mis à jour sa page de conformité à la licence GPL, ce en dépit du rapport de bogue que j’avais créé. Je me suis donc mis en chasse des sources requises, et les ai intégrées dans l’archive debian.tar.xz du paquet source Debian. C’est une solution assez brutale, mais qui présente le double avantage, d’une part, de permettre la clôture du bogue critique pour la publication n°646729 ; et d’autre part, de réintroduire les fichiers Flash écartés par le passé… ce qui est une bonne chose, dans la mesure où cet uploader à base de Flash est beaucoup plus joli que celui tirant parti du navigateur.

Quilt 0.50 est sortie après 2 ans de (lent) développement. Le paquet Debian comporte de nombreux patchs, et plusieurs de ces derniers ont du être mis à jour afin de tenir compte de cette publication. Certains d’entre eux furent heureusement intégrés upstream, mais cela ne me pris pas moins d’une matinée entière pour boucler cette mise à jour. J’ai également converti l’empaquetage de CDBS vers dh avec un mini-fichier debian/rules.

Zim 0.54 est sortie, et j’ai immédiatement mis à jour le paquet, car cette dernière version corrige un bogue qui m’ennuyait.

Revue de l’empaquetage de ledgersmb

En tant que mainteneur de sql-ledger (et utilisateur de ce logiciel pour ma comptabilité), j’espérais voir ledgersmb empaqueté, de sorte qu’il puisse tenir lieu de remplaçant pour ce premier. J’ai suivi tous les efforts déployés au fil du temps dans ce but, mais aucun n’a abouti à un véritable paquet Debian.

C’est vraiment dommage, et c’est la raison pour laquelle j’ai essayé d’y remédier en me proposant pour parrainer l’envoi du paquet. D’où une première revue de l’empaquetage. Cette revue a pris plusieurs heures, car il est nécessaire d’expliquer absolument tout ce qui n’est pas à la hauteur des standards attendus.

J’ai également créé un rapport de bogue/demande d’évolution pour le paquet lintian (cf. n°652963), suggérant que ce dernier devrait détecter les utilisations incorrectes de dpkg-statoverride (un exemple de « mauvaise » utilisation était présent dans le paquet de ledgersmb).

nautilus-dropbox

Je souhaitais fignoler les derniers détails du paquet dans les temps pour la sortie de la prochaine Ubuntu LTS, compte tenu du fait que le gel de l’import Debian est en janvier. J’ai ainsi intégré certaines des importantes corrections que je souhaitais apporter.

Le paquet Debian diverge de celui amont dans la mesure où les binaires non-libres ne sont pas installés dans $HOME, mais dans /var/lib/dropbox. Ma première correction a concerné un bogue qui avait pour effet une possession incorrecte des fichiers (normalement par root exclusivement). Décompresser le tarball en tant que root entraîne la réutilisation des informations de l’utilisateur et du groupe embarqués, informations ayant changé récemment du côté de Dropbox apparemment.

Nous avons ensuite identifié d’autres problèmes en lien avec la gestion des serveurs mandataires (proxy), cf. n°651065. J’ai également corrigé ce dernier, car il est relativement fréquent que le téléchargement initial déclenché durant la configuration du paquet échoue… et dans ce cas, il appartient à l’utilisateur de re-déclencher le téléchargement après avoir obtenu les autorisations appropriées via PackageKit. Sans mon correctif, l’usage de pkexec aurait entraîné la perte de la variable d’environnement http_proxy, et donc l’impossibilité pour l’utilisateur de télécharger à travers un serveur mandataire.

Enfin, j’ai également réorganisé les patchs spécifiques à Debian, ce afin de mieux séparer ce qui pourrait et devrait être intégré par les auteurs amonts, et ce dont ils ne veulent pas. Dropbox est malheureusement contre l’installation sous /var/lib/dropbox (et les changements qui en découlent), car ils tiennent à mettre à jour automatiquement leurs binaires non-libres.

Un point sur le livre

La traduction du Cahier de l’Admin Debian progresse : 6 chapitres sont déjà traduits (bien que non encore relus).

Sa campagne de libération, quant à elle, avance (lentement). Grâce à 90 nouveaux donateurs, la somme collectée est passée de 60 (début décembre) à 67% de la somme visée !

Merci

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

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

Dans la/les catégorie(s): Actualités, Actualités Debian Etiqueté avec: , , , , , , ,

Mes activités Debian en novembre 2011

05/12/2011 Par

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 (310,73 €, 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 : la saga « Multi-Arch »

J’en connais beaucoup qui, tout comme moi, attendent impatiemment l’arrivée de multiarch dans unstable. Les choses avancent, pas aussi vite toutefois que je l’aurais espéré. Guillem a intégré la moitié de la branche entre le 24 octobre et le 6 novembre, après quoi la majorité du travail a été effectuée dans son dépôt personnel sur la branche pu/multiarch/master.

J’ai examiné son dépôt de temps en temps, dans la mesure où il ne m’a pas informé de ses avancées. J’ai ainsi pu noter des modifications les 10, 19, 23 et 28 novembre, ainsi que le 1er décembre.

Voilà un certain temps, Guillem avait annoncé des « modifications d’interface », mais n’a communiqué depuis qu’à propos d’un passage de l’option --foreign-architecture (à déclarer dans /etc/dpkg/dpkg.cfg) vers la commande explicite dpkg --add-architecture. Cette dernière n’ayant besoin d’être appelée qu’une seule fois (cf. ce mail). Au jour d’aujourd’hui (2 décembre), aucun autre mail évoquant des modifications d’interface n’a été envoyé.

J’ai passé en revue le travail de Guillem le 23 novembre et essayé de lancer le code de sa branche. La journée entière fut consacrée à traquer les régressions et à soumettre les correctifs correspondants à Guillem. Un tel travail fut rendu relativement simple grâce à la suite de tests que j’ai créé lorsque j’ai développé ma propre branche.

Toutes les anomalies rapportées à Guillem ont été corrigées dans la dernière version de sa branche, bien que les correctifs appliqués soient légèrement différents de ceux que j’avais soumis.

dpkg : rétro-portage vers Squeeze

En début de mois, j’ai envoyé ce que je pensais être un rétro-portage très consensuel de dpkg 1.16.1.1. Les événements ont montré que j’avais tort !

Après quelques discussions, je pense que nous sommes tombés d’accord sur le fait que seuls les rétro-portages de dpkg-dev et libdpkg-perl étaient acceptables. Mon but n’était pas d’apporter la toute dernière version de dpkg aux utilisateurs, mais de permettre aux mainteneurs de rétro-porter leurs paquets en tirant profit des dernières fonctionnalités de dpkg-dev >= 1.16 (telles que les drapeaux de compilation renforcée, les extraits de makefile fournis par /usr/share/dpkg/ ou l’interface améliorée de dpkg-buildflags).

En conséquence, j’ai modifié le paquet source pour squeeze-backports afin de compiler uniquement dpkg-dev et libdpkg-perl. Chose faite le 23 novembre, le paquet attend maintenant dans la file « NEW » qu’un administrateur le prenne en charge.

Travaux dpkg divers

J’ai intégré le patch de Colin Watson qui permet de vérifier les dépendances de compilation sur des architectures étrangères (en tenant compte du statut « Multi-Arch » de chaque paquet listé).

J’ai publié la version 1.16.1.2 de dpkg, comportant deux corrections mineures qui attendaient dans la branche sid. Je tenais à m’en débarrasser pour libérer la voie à un nouvel « upload » pour la version 1.16.2 avec le support multi-architecture. Le paquet venant juste de migrer vers testing, tout va bien.

Une journée entière a été consacrée au tri des bogues dpkg sur Launchpad, et nous en sommes maintenant à moins de 77 bogues. Un grand nombre d’entre eux étant tagués « incomplet », il est probable qu’ils expirent dans deux mois.

Le cahier de l’admin Debian

eBookUn des chapitres du livre a été rendu librement consultable, ce qui permet de se faire une idée de la qualité de celui-ci. Ce chapitre couvre les outils APT de manière approfondie : je parie que même vous qui me lisez régulièrement pourriez apprendre à sa lecture sur apt-get/aptitude !

La campagne de financement sur Ulule a pris fin ce 28 novembre, et nous avons rassemblé 24835€, grâce à 675 donateurs. De cette somme, 14395€ ont été versés au titre de la libération du livre, tandis que le complément correspond aux différentes récompenses offertes ou pré-commandes.

La traduction de ce livre est donc chose acquise (nous venons juste de la commencer), au contraire de sa libération sous une licence libre. Mais ne désespérez pas, puisque la campagne de libération continue comme prévu jusqu’à ce que l’objectif des 25000€ soit atteint !

Cette campagne permanente sera hébergée sur le site du projet plutôt que sur Ulule. A noter que toute contribution d’au moins 10€ vous garantit l’envoi d’une copie du livre électronique dès qu’il sera disponible, et ce même si l’objectif des 25000€ n’est pas encore atteint.

Système de suivi des paquets (PTS)

J’ai soumis, en début de mois, deux idées d’améliorations du PTS (Package Tracking System) :

  • Afficher les bogues ouverts correspondant à des objectifs pour la publication (n°647258)
  • Afficher un avertissement lorsque le paquet est impliqué dans une transition en cours afin d’éviter une mise à jour qui perturberait cette dernière (#647901).

Si vous codez et souhaitez commencer à contribuer à Debian et son équipe Qualité, ces bogues pourraient être un bon début. :-)

J’ai été en contact pour ces deux tickets avec la Release Team, étant donné qu’ils ont besoin tout deux en entrée de données structurées en provenance de cette équipe. Merci à Meddi Dohguy et Niels Thykier pour leur aide.

Le débat concernant la « re-localisation » du PTS a ressurgi un peu plus tard dans le courant de ce mois. Pour des raisons historiques, le PTS était hébergé sur master.debian.org, de concert avec le BTS (Bugs Tracking System – Système de Suivi des Bogues). Ce dernier a maintenant sa machine dédiée et il n’y a plus de raison pour que le PTS soit séparé du reste des services d’Assurance Qualité hébergés sur qa.debian.org (actuellement quantz.debian.org). Nous nous sommes occupés (Martin Zobel Helas et moi) de planifier sa migration, que nous avons exécutée le 19 novembre. Elle s’est parfaitement bien déroulée et pratiquement personne n’a remarqué le changement (seule une dépendance non documentée était manquante, ce qui brisa l’interface SOAP).

Travaux d’empaquetage divers

WordPress était non fonctionnel dans Ubuntu, en plus de ne plus être proprement synchronisé avec Debian, et ce du fait d’un changement quasi-inutile de leur côté. J’ai donc demandé une synchronisation, de sorte que la version de Debian soit importée dans Ubuntu.

J’ai sponsorisé l’upload de docbook-xsl 1.76.1, qui m’était utile pour Publican. J’ai ensuite uploadé Publican et ai découvert que la suite de tests levait un bogue dans fop (consigné dans le bogue n°649476). J’ai temporairement désactivé cette dernière et ait envoyé Publican 2.8 dans unstable. En parallèle, j’ai soumis deux autres bogues upstream et leurs correctifs pour des problèmes que j’ai découvert alors que j’essayais de générer le chapitre librement consultable de mon livre (cf. ici et ici).

J’ai uploadé nautilus-dropbox en version 0.7.1 et corrigé le bogue n°648215 du même coup. J’ai également procédé à un non-maintainer upload de bison afin de corriger un bogue critique pour la publication ouvert depuis longtemps, et qui m’a encore touché durant une mise à jour (cf. le bogue n°645038).

J’ai déposé sur experimental une nouvelle version de gnome-shell-timer compatible avec GNOME 3.2. J’en ai profité pour installer depuis experimental les quelques paquets GNOME 3.2 non encore disponibles dans unstable…

Merci

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

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

Dans la/les catégorie(s): Actualités, Actualités Debian, Meta Etiqueté avec: , , , , , , ,

Le Cahier de l’Admin Debian Squeeze est disponible

17/11/2011 Par

Nous n’avons pas réussi à renouveler le tour de force de sortir le livre moins d’un mois après la sortie de la nouvelle version de Debian… c’est donc avec quelques mois de retard par rapport à la publication de Debian Squeeze que j’ai le plaisir de vous annoncer la disponibilité d’une nouvelle édition de mon livre.

Cette cinquième mouture du livre a été mise à jour pour tenir compte des changements introduits par la version 6.0 de Debian. Il bénéficie également de nouvelles sections traitant des technologies de virtualisation KVM et de LXC.

Le livre est disponible immédiatement en librairie, mais je vous invite à faire un tour sur la page officielle du livre pour découvrir des extraits, le sommaire, le quatrième de couverture, des témoignages de lecteurs, etc.

Une traduction en anglais à venir

Grâce au soutien de plusieurs centaines de personnes, la campagne de financement de la traduction a atteint son premier objectif et nous sommes désormais certains que le livre sera traduit en anglais.

Une libération possible

Cette campagne poursuit son cours jusqu’au 27 novembre, et est désormais animée par un second objectif : la publication sous licence libre du livre traduit. Pour cela il faut que le fond de libération atteigne 25000 € et nous en sommes à un peu plus de 11000 € (soit environ 45% de l’objectif).

Cliquez ici pour apporter votre contribution dans cette campagne de libération. Signalons qu’en retour vous pouvez obtenir une copie de ce livre (la version française est incluse dans la contrepartie à 50€).

Dans la/les catégorie(s): Actualités, Actualités Debian Etiqueté avec: , , , ,

Mes activités Debian en octobre 2011

09/11/2011 Par

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.

Dans la/les catégorie(s): Actualités, Actualités Debian, Meta Etiqueté avec: , , , , , ,

Ne créez pas votre paquet Debian avec dpkg -b

04/11/2011 Par

J’ai pu observer de nombreuses personnes, ces dernières années, essayant d’utiliser dpkg --build pour créer des paquets Debian. Et, de fait, si vous lisez les pages de manuel de dpkg et de dpkg-deb, l’option semble bien appropriée à cet usage :

-b, --build répertoire [archive|répertoire]

Crée une archive Debian avec l’arborescence contenue dans répertoire. répertoire doit posséder un sous-répertoire DEBIAN qui contient les fichiers de contrôle tel que le fichier « control » lui-même. Ce répertoire n’apparaît pas dans l’archive de l’arborescence du paquet binaire ; mais les fichiers qu’il contient sont mis dans la zone de contrôle du paquet binaire.

On peut en conclure que oui, effectivement, dpkg-deb est l’outil créant en dernière étape les fichiers .deb (aussi connus sous le nom de paquets binaires). Ce qui ne veut pas dire que vous êtes censé appeler un tel outil « bas-niveau » vous-même. En effet, si vous souhaitez empaqueter proprement un logiciel, vous devez plutôt créer un paquet source Debian, qui partira du code source amont pour créer des paquets binaires respectant la charte technique Debian.

Créer un tel paquet source implique également de préparer une arborescence de répertoires (mais avec un sous-répertoire « debian »), ce qui est probablement plus compliqué que d’appliquer dpkg -b à un répertoire ciselé « à la main ». Mais le résultat en est d’autant plus versatile : les outils utilisés apportent une valeur ajoutée en analysant/modifiant dynamiquement les fichiers à l’intérieur de votre paquet (par exemple, les dépendances envers les bibliothèques C requises par votre paquet sont insérées automatiquement).

Si cette méthodologie vous était inconnue, vous souhaiterez peut-être approfondir le sujet grâce au manuel du Nouveau Mainteneur ou à la Charte Debian.

Ceci est une traduction de mon article Avoid a newbie packager mistake: don’t build your Debian packages with dpkg -b 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.

Dans la/les catégorie(s): Documentation, Documentation pour les contributeurs Etiqueté avec: , , , , , ,

Firmwares manquants dans Debian ? Apprenez à gérer le problème

28/10/2011 Par

Vous en avez déjà certainement entendu parler : Debian Squeeze est la première version de Debian dont l’installation standard est dépourvue de firmwares non libres. Ce qui peut entraîner quelques difficultés pour les utilisateurs en ayant besoin. Après une rapide introduction du sujet, nous allons voir comment remédier aux désagréments engendrés par ce changement.

Les firmwares : que sont-ils et comment sont-ils utilisés ?

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.

Au sein du noyau Linux, les pilotes utilisent tous la même interface normalisée (request_firmware) pour récupérer le firmware avant de l’envoyer au périphérique. Cette standardisation permet d’embarquer ce dernier directement dans le noyau, ou de le charger à la demande depuis l’espace utilisateur (lorsqu’il est requis).

Debian, à l’instar de la plupart des autres distributions, a choisi la deuxième option. Ainsi, lorsque le noyau a besoin d’un firmware, il envoie une requête en espace utilisateur : udev intercepte la demande (contenant le nom du firmware), et, grâce à sa configuration par défaut (cf. /lib/udev/rules.d/80-drivers.rules) exécute /lib/udev/firmware.agent en réponse.

Où sont enregistrés les firmwares ?

Le script shell firmware.agent essaye de localiser un firmware avant de le renvoyer au noyau via une entrée sysfs. Les répertoires analysés sont les suivants :

  • /lib/firmware/$(uname -r)
  • /lib/firmware
  • /usr/local/lib/firmware
  • /usr/lib/hotplug/firmware

Les paquets installant des firmwares les enregistrent habituellement dans /lib/firmware, et vous pouvez utiliser /usr/local/lib/firmware lorsque vous en installez manuellement.

Comment savoir si vous en avez besoin ?

Première source d’informations : les messages du noyau vous disant qu’il essaye de charger un firmware, mais n’y arrive pas. Ils ressemblent à ceci :

e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin": -2

Ceci étant, le système peut vous informer du problème plus tôt : lorsque vous installez une nouvelle version du noyau Linux, le script de post-installation va parcourir tous les modules chargés (ceux listés par la commande lsmod) et vérifier si chacun de ces derniers, dans leurs versions installées par le dernier noyau, nécessitent ou pas des firmwares. Cette information est également disponible via modinfo :

$ modinfo -F firmware /lib/modules/2.6.32-5-amd64/kernel/drivers/net/e100.ko
e100/d102e_ucode.bin
e100/d101s_ucode.bin
e100/d101m_ucode.bin

Si certains des firmwares requis ne sont pas présents sur le système, vous obtiendrez un message d’avertissement semblable à celui-ci :

update-initramfs affiche également des avertissements similaires :

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

L’installateur Debian détecte également le matériel pouvant nécessiter un firmware manquant, et vous permet de le lui passer via une clé USB (soit directement, soit grâce aux paquets correspondants).

Comment trouver et installer les firmwares manquants ?

Maintenant que vous connaissez le nom du firmware manquant, il est relativement facile d’identifier le paquet le proposant. En effet, la description des paquets contient le nom des fichiers de firmwares qu’ils proposent, « apt-cache search <nom_du_firmware> » ramènera ainsi la liste des paquets le contenant.
Utiliser « apt-file » (fourni par le paquet du même nom) est également possible, comme le fait de rechercher via packages.debian.org.

$ apt-cache search d101m_ucode.bin
firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel
$ apt-file search d101m_ucode.bin
firmware-linux-nonfree: /lib/firmware/e100/d101m_ucode.bin

Si aucune des commandes précédentes ne retourne quoi que ce soit, vous devrez probablement ajouter le dépôt non-free à votre /etc/apt/sources.list (action réalisable également via synaptic). N’oubliez pas sudo apt-file update, afin de disposer des informations les plus à jour !

Il vous est maintenant possible d’installer le paquet requis, firmware-linux-nonfree dans l’exemple précédent.

Comment installer tous les firmwares, pour être sûr de n’en oublier aucun ?

Comme il n’existe aucun méta-paquet dépendant de tous les paquets de firmwares, la réponse n’est pas simple, et ce d’autant plus que tous les paquets embarquant des firmwares ne se conforment pas à la convention de nommage « firmware-* » (comme par exemple zd1211-firmware).

La « meilleure » option consiste peut-être à effectuer une recherche de termes génériques, comme par exemple :

$ apt-file --package-only search /lib/firmware/
atmel-firmware
[...]

et à installer les paquets listés.

Existe-t’il des images CD ou DVD comprenant les firmwares non libres ?

Oui, Debian propose de telles images « netinst » non-officielles pour les architectures i386, amd64 et powerpc. Elles sont téléchargeables ici : http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/.

De mon côté, un jeu de DVD avec les firmwares, et des CD/DVD multi-architectures avec firmwares, sont disponibles dans ma boutique DVD : http://raphaelhertzog.com/go/debian-cd/ (uniquement i386 ou amd64).

L’installateur Debian, avec ces disques, trouvera immédiatement les firmwares requis, vous évitant d’avoir à les charger au moyen d’une clé USB.

D’autres questions ?

Arrivant au terme de cet article, je pense avoir couvert les aspects les plus importants qu’il vous faut connaître au sujet des firmwares dans Debian. Ceci étant, s’il vous reste des questions, n’hésitez pas à les poser en commentaires ! Vos questions (et mes réponses) me permettront d’améliorer ce billet.

Ceci est une traduction de mon article Missing firmware in Debian? Learn how to deal with the problem contribuée par Weierstrass01.

Suivez moi sur Identi.ca, Google+, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: , , , , , , , , , ,

5 raisons pour lesquelles je contribue encore à Debian 13 ans après mes débuts

25/10/2011 Par

Debian met en paquet le monde du logiciel libre.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.

1. L’excellence technique

Lorsque Debian doit faire face à un nouveau challenge, Debian fera les efforts nécessaires pour implémenter une solution correcte et propre. Cela paie sur le long terme. Dans de nombreux cas, cela veut dire que l’on prendra plus de temps pour implémenter notre solution comparée à d’autres distributions, mais c’est également la raison pour laquelle notre infrastructure de gestion de paquets est si réputée pour la facilité de mettre à jour un système. C’est aussi ce qui permet d’assurer une cohérence entre tous les paquets.

Debian attache une grande importance à la qualité et va de l’avant en s’appuyant sur son expérience grâce à la charte technique. Mon temps est précieux, et j’aime le passer à quelque chose qui est utile sur le long-terme.

2. Des objectifs motivants

Dans son contrat social, Debian a décidé de créer un système d’exploitation 100% libre. Les critères définissant ce qu’est une œuvre libre sont listés dans les principes du logiciel libre selon Debian (Debian Free Software Guidelines).

Si les objectifs ci-dessus sont ambitieux, ils ne m’inspirent pas plus que cela. Ce qui fait la différence pour moi c’est l’importance particulière que le contrat social donne à nos utilisateurs et au logiciel libre. On ne fabrique pas un système d’exploitation libre dans le néant, on le fabrique pour des gens.

Le slogan de Debian — le système d’exploitation universel — peut également être interprété de multiple façons: universel comme « pour tout le monde », « sur tout type d’ordinateur », ou « pour tous les usages possibles ».

3. Du travail qui compte avec des conséquences importantes

Savoir que mon travail est utile est important, mais c’est encore mieux lorsque je sais qu’il va bénéficier à beaucoup de personnes. Avec Ubuntu et les centaines d’autres dérivées de Debian, il y a littéralement des millions d’utilisateurs impactés par mon travail. Même une amélioration insignifiante de une seconde constatée par 10 millions d’utilisateurs représente 115 jours de temps économisé pour quelque chose d’autre…

4. Travailler avec des personnes exceptionnelles

Debian a la chance d’avoir de nombreuse personnes très intelligentes en son sein. Il y a toujours quelqu’un en train de partager des conseils pertinents lorsque vous lisez les listes de diffusion Debian. Lorsque j’ai rejoint le projet en 1998, j’étais un vrai débutant et j’ai appris de nombreuses choses en lisant et en interagissant avec des personnes plus expérimentées que moi. Vous pouvez encore vivre la même chose de nos jours mais il faut savoir faire le tri entre les différents types de contributeurs sur les listes de diffusion, y compris les « intelligents mais pas très civilisés » (ne soyez pas offensés trop vite !) et le troll occasionnel (il vaut mieux l’ignorer, et surtout ne pas le nourrir en répondant !).

5. Reconnaissance du travail

Lorsque vous contribuez à Debian, les gens vous connaissent par le biais de vos contributions. C’est très gratifiant d’être remercié par ses pairs et par les utilisateurs de Debian. Visitez thanks.debian.net pour vous convaincre que de nombreuses personnes sont reconnaissantes pour le travail que l’on fait dans le cadre de Debian.

Voilà ce qu’il en est pour ma part. Mais qu’en est-il de vous ? Qu’est-ce qui vous pousse à contribuer année après année, ou qu’est-ce qui vous pousserait à commencer en tant que contributeur potentiel ?

Si vous appréciez mon travail pour Debian, la meilleure façon de me remercier est de contribuer à la libération de mon livre. Cliquez-ici pour apporter votre soutien.

Ceci est une traduction de mon article 5 reasons why I still contribute to Debian after 12 years.

Dans la/les catégorie(s): Opinions Etiqueté avec: , , , ,

Garder un système Debian propre, astuce n°6 : supprimer les paquets automatiquement installés devenus inutiles

18/10/2011 Par

Pour le dernier billet de cette série, et après avoir vu comment débarrasser son système des fichiers ne provenant pas d’un paquet Debian, nous allons voir aujourd’hui comment nettoyer les paquets ayant été installés comme dépendances, et dont vous n’avez plus besoin.

APT garde automatiquement la trace de l’installation des paquets

Vous n’installez que rarement un paquet tout seul : lorsque vous en sélectionnez un dans apt-get/aptitude/synaptic, ces derniers vous en rajoutent la plupart du temps plusieurs – ses dépendances, sans lesquelles ils ne veulent pas installer celui qui vous intéresse. Un exemple :

$ sudo apt-get install pino
[...]
Les paquets supplémentaires suivants seront installés :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon
Les NOUVEAUX paquets suivants seront installés :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon pino
0 mis à jour, 6 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 478 kB dans les archives.
Après cette opération, 2531 kB d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?

Les 5 paquets « supplémentaires » seront marqués à la fin de l’installation comme ayant été « automatiquement installés ». Qu’est-ce que cela signifie ? Tout simplement que vous n’avez pas explicitement demandé leur installation. Et, par conséquent, cela autorise le système à les retirer dès qu’il n’en a plus besoin.

apt-mark showauto, qui retourne une liste des paquets installés automatiquement, permet de vérifier que c’est bien le cas :

$ apt-mark showauto |grep libdbusmenu
libdbusmenu-glib1
$ apt-mark showauto |grep pino
$

aptitude montre cette information via la lettre « A » en regard du paquet (dans son interface ncurses), et nommément dans sa sortie en ligne de commande, par exemple aptitude show :

$ aptitude show libdbusmenu-glib1
Paquet : libdbusmenu-glib1
Nouveau : oui
État: installé
Automatiquement installé: oui
Version: 0.3.7-1
[...]

L’information est moins visible dans synaptic : vous pouvez y avoir accès en sélectionnant un paquet installé, et en vérifiant dans le menu « paquet » si la case « installé automatiquement » est cochée ou non.

APT liste les paquets qui ne sont plus nécessaires

Certains paquets installés automatiquement peuvent, au fil du temps, ne plus être requis, car les paquets qui autrefois en dépendaient ne les appellent plus. Ce peut être car ils dépendent d’une version plus récente de la même bibliothèque, qu’ils dépendent d’autre chose pour assurer la même fonction, ou bien qu’ils sont dorénavant capables d’assurer tout seul la fonction.

Bref, quelle qu’en soit la raison, la dépendance originelle n’est plus, et le paquet automatiquement installé n’est plus requis pour le bon fonctionnement du système.

aptitude supprime automatiquement (à son prochain lancement) dans ce cas les paquets devenus inutiles, ce qui n’est pas le cas d’apt-get ou de synaptic.

apt-get, quant à lui, vous dresse par contre la liste des paquets superflus, et vous dit même parfois comment vous en débarrasser :

$ sudo apt-get remove pino
[...]
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  notification-daemon libdbusmenu-glib1 libnotify1 libgee2 libindicate4
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
  pino
0 mis à jour, 0 nouvellement installés, 1 à enlever et 219 non mis à jour.
Après cette opération, 1225 kB d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ?
[...]
$ sudo apt-get autoremove
[...]
Les paquets suivants seront ENLEVÉS :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon
0 mis à jour, 0 nouvellement installés, 5 à enlever et 219 non mis à jour.
Après cette opération, 1307 kB d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ?
[...]

synaptic, enfin, dispose dans ce but d’une nouvelle section accessible via le bouton « État » situé en bas à gauche : « Installés (pouvant être supprimés) ».

C’est une bonne habitude à prendre que de supprimer, à intervalle régulier, de tels paquets.

Drapeau d’installation automatique et réduction de la taille de votre système

Bien qu’APT positionne le drapeau « installé automatiquement » par lui-même, vous pouvez également le forcer manuellement. C’est une manière très simple de dire au système : « je n’ai pas particulièrement besoin de ce paquet, tu peux le désinstaller lorsque plus aucun autre n’en a besoin ».

# Avec apt-get
$ sudo apt-mark markauto libxml-simple-perl
# Ou avec aptitude
$ sudo aptitude markauto libxml-simple-perl

aptitude le permet également via son interface ncurses, grâce à la touche « M », pour marquer comme automatiquement installé le paquet sélectionné (et « m » pour enlever cet attribut). En ce qui concerne synaptic, il faut passer par le menu « Paquet > installé automatiquement ».

Un nombre important d’utilisateurs souhaiterait disposer d’une base installée minimale, tout en ne sachant pas réellement quels sont les paquets vraiment importants. Et la méthode consistant à « désinstaller le paquet et voir ce qui se passe » n’est pas une option très pratique…

Cette fonctionnalité permet donc, sans retirer (immédiatement) le paquet, de laisser le système décider, selon qu’il soit encore requis comme dépendance d’autres paquets ou non, s’il doit être désinstallé. Cette méthode comporte très peu de risques lorsqu’on l’applique aux bibliothèques (y compris les modules Python ou Perl).

Mon conseil serait de ne pas marquer comme « installés automatiquement » les paquets ayant une priorité supérieure ou égale à « important », ce afin d’éviter les surprises désagréables. Ceci étant, je dis cela uniquement pour me dédouaner d’éventuels problèmes créés parce que vous avez supprimé trop de paquets par ce biais. Car le système — en théorie — ne devrait pas supprimer ses constituants essentiels, le jeu des dépendances étant supposé être correctement et complètement renseigné.

Gardez également à l’esprit la conséquence du marquage d’un paquet tel que « gnome » : le système vous suggérera de supprimer entièrement votre bureau. Si tel est votre souhait, vous devriez alors dé-marquer les quelques paquets que vous souhaitez garder :

$ sudo apt-mark unmarkauto gnome-session gnome-panel

Ceci est une traduction de mon article Debian Cleanup Tip #6: Remove automatically installed packages that are no longer needed 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.

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: , , , , , ,
« Anciens articles