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

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

14/09/2011 Par

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.

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

Mes activités Debian en août 2011

07/09/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 (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.

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

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

23/08/2011 Par

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.

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

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

16/08/2011 Par

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.

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

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

12/08/2011 Par

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.

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

Mes activités Debian en juillet 2011

10/08/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 (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.

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

Correctement renommer un fichier de configuration dans un paquet Debian

26/07/2011 Par

Après avoir traité de la suppression de conffiles obsolètes, je vais maintenant aborder la question du renommage des fichiers de configuration gérés par dpkg.

La problématique

Prenons pour hypothèse que la version 1.2 d’une quelconque application ne fournisse plus le fichier /etc/foo.conf. En lieu et place, elle fournit /etc/bar.conf, car le fichier de configuration a été renommé. Si vous ne faîtes rien de particulier, le nouveau conffile sera installé et contiendra la configuration par défaut, tandis que l’ancien restera. Toutes les modifications éventuellement réalisées par l’administrateur seront perdues (inutilisées, pour être exact : elles seront toujours consignées dans le fichier foo.conf, qui ne sera plus pris en compte).

Bien entendu, il vous est toujours possible de procéder à un mv /etc/foo.conf /etc/bar.conf dans le script de pré-installation. Mais ce n’est pas satisfaisant : une questions sera posée à l’utilisateur final lors de la mise à jour, dont il ne comprendra pas la raison.

La solution

Vous devez vérifier, dans le script de pré-installation, si l’ancien conffile a été modifié par l’administrateur. Si tel est le cas, vous souhaitez le garder de côté. Dans le cas contraire, vous pourrez le supprimer une fois la mise à jour réalisée, et, pour bien s’en rappeler, vous le renommez en /etc/foo.conf.dpkg-remove dans ce cas.

Vous supprimez ensuite /etc/foo.conf.dpkg-remove dans le script de post-installation. Si l’ancien conffile (/etc/foo.conf) existe toujours, c’est qu’il a été modifié par l’administrateur. Il ne reste plus alors qu’à faire une copie de sauvegarde du nouveau conffile vers /etc/bar.conf.dpkg-dist, et renommer l’ancien en /etc/bar.conf.

Dans le script postrm, dans le cas d’un appel pour annuler la mise à jour, le fichier /etc/foo.conf.dpkg-remove doit retrouver son nom originel.

En pratique, utilisez dpkg-maintscript-helper

dpkg-maintscript-helper permet d’automatiser toutes ces tâches. Vous n’avez qu’à ajouter l’extrait de code suivant dans chaque script (postinst, postrm, preinst) :

if dpkg-maintscript-helper supports mv_conffile 2>/dev/null; then
    dpkg-maintscript-helper mv_conffile /etc/foo.conf /etc/bar.conf 1.1-3 -- "$@"
fi

J’ai considéré dans cet exemple que la dernière version du paquet contenant /etc/foo.conf (i.e. la dernière version avant la parution de la 1.2-1) était la 1.1-3.

Vous pouvez faire l’économie des tests préliminaires en imposant une pré-dépendance à « dpkg (>= 1.15.7.2) », ou si suffisamment de temps s’est écoulé pour considérer comme probable que tout le monde dispose d’une version plus récente. Vous trouverez tous les détails sur ce point dans la page de manuel de dpkg-maintscript-helper.

Cet article est une traduction de Correctly renaming a conffile in Debian package maintainer scripts contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

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

5 raisons pour lesquelles Debian unstable ne mérite pas son nom

19/07/2011 Par

Debian unstable (également connue sous le nom de sid) est l’une des 3 distributions proposées par Debian (les deux autres étant stable et testing).

Elle n’est pas conçue comme un produit pour les utilisateurs finaux, son rôle essentiel est de servir de dépôt pour les toutes dernières versions de paquets envoyés par les contributeurs, et ce quotidiennement. unstable est donc perpétuellement en évolution rapide, et par conséquent pas nécessairement appropriée pour tout public. Ceci étant, il est possible de l’utiliser sans que votre ordinateur n’explose !

1. unstable contient principalement des versions stables de logiciels

Oui oui, vous avez bien lu. unstable ne contient pas tout plein de versions de développement bien que, ponctuellement pour certains logiciels, ce soit le cas. Il s’agit la plupart du temps d’une décision réfléchie de la part du mainteneur de paquets, considérant qu’en l’état cette version particulière est déjà supérieure à l’ancienne.

Ceci s’explique par le fait que sid est l’antichambre de testing, dépôt où la prochaine version stable est préparée. Les mainteneurs ne doivent donc y envoyer que des paquets d’une qualité suffisante en vue de la publication, le reste devant prendre le chemin de experimental.

2. Elle ne crashe pas tous les jours

Des dysfonctionnements surviennent, mais ne sont en règle générale ni sérieux, ni difficiles à corriger. Voilà un bout de temps maintenant qu’il ne m’est pas arrivé, après une mise à jour, de ne plus pouvoir redémarrer mon ordinateur, ou que l’interface graphique soit non fonctionnelle. La plupart du temps, les dysfonctionnements rencontrés prennent la forme d’un logiciel cessant de fonctionner ou souffrant d’un bogue nouveau, ou bien que certains paquets ne puissent plus être installés.

Vous pouvez vous en sortir, dans la grande majorité des cas, en installant la version du paquet incriminé présente dans testing, ou en trouvant dans le suivi des bogues un moyen de contourner le problème. Il est également possible de prévenir plutôt que de guérir : apt-listbugs, en vous prévenant du problème, peut vous dissuader de mettre à jour.

3. Elle est à la base d’autres distributions

Si Debian unstable était de si piètre qualité, elle ne servirait pas de base de départ pour des distributions dérivées. Logique, non ? Deux exemples basées sur sid parmi d’autres : Ubuntu et Sidux Aptosid.

4. Sa conception ne la rend pas moins sécurisée que stable ou testing

Les vulnérabilités importantes sont généralement rapidement corrigées dans stable et unstable. L’équipe chargée de la sécurité s’occupe de stable, tandis que la correction d’unstable revient aux mainteneurs des paquets concernés. testing récupère généralement la correction à travers la mise à jour des paquets provenant d’unstable, entraînant ainsi une latence à l’obtention des corrections.

Les problèmes de sécurités d’importance moindre peuvent n’entraîner aucune correction dans stable. Dans ce cas, les utilisateurs de testing/unstable sont mieux servis, dans la mesure où ils récupèreront la correction avec la nouvelle version du paquet, quoi qu’il arrive.

Bien évidemment, il peut arriver que les mainteneurs soient particulièrement occupés ou que certaines failles arrivent quand même à se faufiler. Si le mainteneur ne réagit pas, d’autres personnes examinant les bogues RC (Release Critical) proposeront les corrections nécessaires.

5. Je l’utilise sur mon ordinateur principal

Et je ne suis pas le seul ! Vous pouvez le faire également si vous remplissez les conditions suivantes :

  • vous savez utiliser la ligne de commande (du moins suffisamment pour rétrograder de version un paquet, éditer des fichiers de configuration, …) ;
  • vous connaissez le fonctionnement d’APT et l’utilisation simultanée de plusieurs dépôts dans /etc/apt/sources.list ;
  • l’anglais lu/écrit n’est pas un problème, de telle sorte que vous pouvez lire/écrire les rapports de bogue, le cas échéant ;
  • vous disposez d’un autre ordinateur relié à Internet, d’où vous pouvez rechercher de la documentation (ou le système de suivi des bogues, ou les listes de diffusion dédiées au support) lorsque votre ordinateur principal est hors service pour une raison qui vous échappe.

Si vous ne vous sentez pas prêt à faire le grand saut, vous pouvez vous abonner à ce blog (ou vous abonner au flux RSS), dans la mesure où je posterai certainement d’autres articles permettant d’acquérir les compétences nécessaires pour y arriver.

PS: Sans renier ce qui précède, si vous avez une installation fonctionnelle de sid, n’allez pas jusqu’à la mettre à jour juste avant une importante présentation, ou un voyage : le crash a toujours lieu au pire moment. À moins que vous ne vous sentiez l’âme d’un aventurier, bien sûr !

Cet article est une traduction de 5 reasons why Debian Unstable does not deserve its name contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook.

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

Comment recompiler un paquet Debian

12/07/2011 Par

Savoir recompiler un paquet Debian existant est particulièrement utile. En effet, il s’agit là d’un prérequis indispensable à certaines tâches qu’un administrateur peut vouloir effectuer : activer une fonctionnalité désactivée dans le paquet Debian officiel, recompiler les sources pour un autre environnement (récupérer la version correspondant à Debian testing pour faire fonctionner le paquet sous Debian stable par exemple — ce qui, d’ailleurs, est le principe même des applications disponibles dans les backports), inclure une correction que les développeurs upstream ont mise à disposition, … Cet article vous propose de découvrir les 4 étapes nécessaires à cette recompilation :

1. Télécharger les sources

La « meilleure » manière de télécharger les sources reste l’utilisation d’APT. Il permet de les télécharger depuis les dépôts source paramétrés dans le fichier /etc/apt/sources.list, comme par exemple :

deb-src http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

Comme on le voit, le premier mot-clé indique clairement à APT que l’on s’intéresse aux sources, et non pas aux binaires.

Si les dépôts source n’étaient pas présents dans le fichier auparavant, un petit apt-get update permettra de mettre à jour la base et vous pourrez récupérer par exemple la dernière version des sources du paquet publican, via la commande apt-get source publican. Il est également possible d’indiquer la distribution au sein de laquelle il faut récupérer les sources, avec la syntaxe « package/distribution« . Dans notre cas, apt-get source publican/testing récupérera les sources de publican à partir du dépôt testing et les extraira dans le répertoire courant (via la commande dpkg-source -x, avec comme prérequis le paquet dpkg-dev installé).

$ apt-get source publican/testing
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Note : la maintenance du paquet de « publican » est réalisée dans le système de suivi de versions « Git » à l'adresse :
git://git.debian.org/collab-maint/publican.git
Nécessité de prendre 888 ko dans les sources.
Réception de : 1 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (dsc) [2 292 B]
Réception de : 2 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (tar) [879 kB]
Réception de : 3 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (diff) [6907 B]
888 ko réceptionnés en 8s (104 ko/s)
dpkg-source: info: extraction de publican dans publican-2.5
dpkg-source: info: extraction de publican_2.5.orig.tar.gz
dpkg-source: info: extraction de publican_2.5-2.debian.tar.gz
dpkg-source: info: mise en place de perl-critic-fixes-svn1732
$ ls -dF publican*
publican-2.5/
publican_2.5-2.debian.tar.gz
publican_2.5-2.dsc
publican_2.5.orig.tar.gz

Si vous ne souhaitez pas utiliser APT, ou si le paquet source n’est pas hébergé par un dépôt APT, il est toujours possible de télécharger le paquet source complet via dget -u dsc-url, où dsc-url représente l’URL du fichier .dsc, image des sources du paquet. L’utilitaire dget est fourni par le paquet devscripts. L’option -u mérite d’être retenue : elle signifie que l’origine des sources ne sera pas vérifiée avant extraction.

2. Installer les dépendances de compilation

Là-aussi, APT peut faire le boulot ingrat à votre place. Tout ce que vous avez à faire est de lancer apt-get build-dep mon-paquet afin que les dépendances nécessaires à la compilation de mon-paquet soient installées. La syntaxe restant la même que pour apt-get source, il est possible de lancer apt-get build-dep publican/testing, ce qui aura pour effet d’installer les dépendances pour la compilation de la version testing de publican.

Si vous ne pouvez pas utiliser APT pour faire cela, placez-vous directement dans le répertoire contenant l’extraction du paquet source et lancez dpkg-checkbuilddeps. En sortie, vous aurez une liste de dépendances de compilation non satisfaites (dans le cas contraire, la commande restera muette, et vous pourrez continuer tranquillement). Dans ce cas, un enchaînement de copier/coller et d’apt-get install permettra de remédier au problème en quelques secondes.

3. Faites les modifications requises

Je ne détaillerai pas cette étape, dans la mesure où elle dépend totalement des objectifs particuliers qui vous poussent à recompiler. Vous serez peut-être amené à modifier le fichier debian/rules, ou à appliquer un patch.

Dans tous les cas, une chose est sûre : si vous avez changé quoi que ce soit, ou recompilé le paquet dans un environnement différent, vous devriez vraiment changer son numéro de version. dch --local perso (toujours du paquet devscripts) vous permet de le faire simplement : remplacer simplement perso par un nom court vous identifiant comme le pourvoyeur de cette version. debian/changelog sera modifié en conséquence et vous serez invité à documenter brièvement les changements opérés.

4. Compiler le paquet

La dernière étape est également la plus simple, maintenant que tout est en place. Vous devez vous placer à la racine du répertoire où sont extraites les sources, et lancer debuild -us -uc (procédure recommandée, nécessite le paquet devscripts), ou directement dpkg-buildpackage -us -uc. Les options « -us -uc » évitent l’étape de la signature qui provoquerait une erreur (bénigne) à la fin si vous ne disposez pas de clé GPG correspondant au nom entré au début du fichier des modifications Debian (debian/changelog).

$ cd publican-2.5
$ debuild -us -uc
dpkg-buildpackage: export de CFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de CPPFLAGS depuis dpkg-buildflags (origine : vendor):
dpkg-buildpackage: export de CXXFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de FFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de LDFLAGS depuis dpkg-buildflags (origine : vendor):
dpkg-buildpackage: paquet source publican
dpkg-buildpackage: version source 2.5-2
dpkg-buildpackage: source changé par Raphaël Hertzog
dpkg-buildpackage: architecture hôte amd64
[...]
dpkg-deb: compilation du paquet `publican' en `../publican_2.5-2rh1_all.deb'.
 dpkg-genchanges  >../publican_2.5-2rh1_amd64.changes
dpkg-genchanges: sources originales non incluses en version amont
 dpkg-source --after-build publican-2.5
dpkg-buildpackage: binary and diff upload (sources originales NON incluses)
Lancement de lintian...
lintian : terminé.

La compilation est terminée. Les sources mises à jour ainsi que les paquets binaires ont été générés dans le dossier parent.

$ cd ..
$ ls -dF publican*
publican-2.5/                    publican_2.5-2rh1.dsc
publican_2.5-2.debian.tar.gz     publican_2.5-2rh1_amd64.changes
publican_2.5-2.dsc               publican_2.5-2rh1_source.changes
publican_2.5-2rh1_all.deb        publican_2.5.orig.tar.gz
publican_2.5-2rh1.debian.tar.gz

Cet article est une traduction de Howto to rebuild Debian 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.

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

Mes activités Debian en juin 2011

06/07/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 (195 €, 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.

Dropbox pour Debian

Dropbox n’est pas un logiciel libre, mais n’en est pas moins très populaire. Ils ne mettent à disposition qu’un paquet pour Ubuntu, qui ne fonctionne pas sous Debian. J’ai donc créé un paquet officiel.

En contact avec des développeurs Dropbox, ils m’ont été d’une aide précieuse. Ils vont très prochainement lancer un mécanisme de signatures (avec GPG), de telle sorte que nous pourrons bientôt améliorer le paquet en vérifiant l’origine des binaires téléchargés.

SAT Britney

J’ai continué — au début du mois — mon travail sur la ré-implémentation de britney (l’application créant testing à partir d’unstable). J’ai cependant rapidement mis en sommeil mon travail, dans la mesure où les release managers ont demandé l’avis de Stefano Zacchiroli et Ralf Treinen (qui ont une connaissance approfondie du sujet, de par leur travail de recherche sur Mancoosi). Je n’ai pas souhaité aller plus loin, au cas où ils identifient une faiblesse majeure. Leur retour n’est arrivé qu’en fin de ce mois, et, bien que quelque peu négatif, je continue à penser que le travail mérite d’être poursuivi plus en avant.

Conversion de ftplib à multiarch

Tandis que dpkg ne supporte toujours pas multiarch (aucune nouvelle de Guillem à ce sujet, et aucun signe de progression visible :-( ), unstable a récupéré les derniers éléments nous permettant de convertir les bibliothèques au multi-architecture (cf. l’annonce correspondante). A l’instant où la version requise de libc6 a atterri dans unstable, j’ai cherché à convertir le seul paquet de bibliothèque que je maintiens. Je n’ai eu aucune difficulté majeure, seulement deux problèmes dans Lintian (référencés sous le n°630164 et rapidement corrigés par Niels Thykier).

Support build-arch / build-indep

L’idée d’utiliser des cibles build-arch/build-indep dans le fichier debian/rules a ressurgi pour la 42ème fois en 10 ans. J’avais déjà décidé, voilà quelques temps de cela, d’accepter un patch implémentant un champ Builld-Features: build-arch, afin de permettre à dpkg-buildpackage d’utiliser ces cibles. Bill Allombert a terminé ce patch, je l’ai donc intégré.

Le comité technique a également décidé qu’il prendrait une décision définitive sur ce sujet (cf. n°629385). Roger Leigh a apporté une contribution utile en recompilant l’archive complète avec toutes les solutions proposées. Étant donné qu’une majorité souhaite rendre la cible obligatoire dans le futur, j’ai contribué un patch dpkg pour ma solution préférée. L’auto-détection de la cible serait utilisée temporairement jusqu’à ce que tous les paquets soient modifiés afin d’embarquer de telles cibles.

Le comité technique n’a encore pris aucune décision, bien que la discussion soit au point mort depuis le 12 juin. Rien d’anormal ici, je suis sûr que le point sera soldé durant la DebConf. ;-)

Activités diverses sur dpkg

  • Modification de dpkg-source --after-build permettant de retirer automatiquement les patchs, s’ils ont été appliqués via dpkg-source --before-build
  • Pas mal de corrections de bogues (n° 628726, 629582, 630996, 631435, 631439, 631547, 632168), ce qui permet à peine d’équilibrer avec le nombre de nouveaux bogues rapportés !
  • Ajout de 2 modules Perl supplémentaires à l’API supporté, au profit de Lintian.
  • Une soirée passée à investiguer les causes possibles d’une vieille et ennuyeuse assertion failure liée aux triggers.
  • Mise à jour de ma branche avec les directives triggers améliorées, pour prendre en compte les remarques de Guillem, puis intégration de cette branche.
  • En traitant le point précédent, j’ai découvert une faiblesse conceptuelle dans l’usage de « prerm failed-upgrade », et intégré une correction.
  • Discussion de l’intégration de dpkg-buildflags dans debhelper dans le bogue 544844, ce qui a conduit à la décision d’implémenter de nouvelles améliorations pour dpkg-buildflags.

Mise à jour de l’applet Hamster

Hamster-applet est une application GNOME n’ayant pas de version 3.0, mais une en développement (2.91.x). J’ai regardé s’il n’était pas possible de l’empaqueter pour experimental, et ainsi avoir l’applet fonctionnelle dans le mode dégradé de GNOME 3. Apparemment pas. Le code n’a pas encore été mis à jour pour être compatible avec le nouveau panneau.

J’ai envoyé dans unstable la dernière version stable (2.32.1) à la place, qui a quelques améliorations intéressantes dans sa version standalone (et le nom de l’exécutable est différent). En attendant une meilleure intégration avec GNOME 3, j’ai créé un raccourci pour le démarrer rapidement (avec gconf-editor, entrer la valeur « <Mod4>t » pour le champ /apps/metacity/global_keybindings/run_command_1, et « hamster-time-tracker » pour /apps/metacity/keybinding_commands/command_1. Le panneau de contrôle de GNOME 3 ne semble en effet pas gérer les raccourcis claviers actuellement).

Traduction de mon site professionnel en anglais

Bien que particulièrement reconnaissant envers les personnes supportant activement mon travail, je suis encore loin d’avoir atteint mon objectif d’être financé pour un tiers de mon temps de travail par des donations et la vente de produits via ce site.

J’ai donc décidé de donner un peu plus de visibilité à mon site professionnel, et en particulier à son offre de services liée à Debian. Elle n’était disponible qu’en français, je l’ai traduite et étoffée quelque peu. Ma « page de soutien » sur ce blog pointe maintenant également vers le site web de mon entreprise.

Si votre entreprise a besoin d’aide pour créer des paquets Debian, ou requiert un support technique par mail, ne cherchez plus ! :-)

Je propose d’ailleurs des réductions pour les particuliers ou organisations à but non lucratifs désirant bénéficier de mon expertise pour créer des paquets Debian.

The Debian Administrator’s Handbook

Il s’agit là du titre de la traduction à venir de mon livre. Ce projet dispose maintenant d’un site dédié : debian-handbook.info.

Vous pouvez vous inscrire à son flux RSS pour obtenir les dernières nouvelles le concernant. La table des matières complète est en ligne, accompagnée d’une FAQ.

Je recherche activement des partenaires pour promouvoir la campagne de financement à venir. Si vous êtes en mesure de toucher un nombre conséquent de lecteurs intéressés par une bonne référence sur Debian, contactez-moi afin de rejoindre le programme affilié.

Merci

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

Ceci est une traduction de mon article My Debian activities in June 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.

Dans la/les catégorie(s): Actualités Etiqueté avec: , , , , , , , , ,
« Anciens articles
Articles récents »