Vous êtes ici: Accueil / Archives pour Libre

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: , , , , , ,

Mes activités Debian en septembre 2011

13/10/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 (144,3 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Travail sur dpkg

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

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

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

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

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

Le Cahier de l’Admin Debian

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

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

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

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

Mises à jour diverses du blog anglophone

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

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

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

Travail d’empaquetage divers

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

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

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

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

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

Merci

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

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

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

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

07/10/2011 Par

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

Fichiers non-empaquetés

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

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

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

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

L’installation manuelle : une mauvaise idée

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

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

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

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

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

Utilisation de cruft

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

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

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

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

Analyse du résultat

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

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

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

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

Conclusion: utile, mais à parfaire

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

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

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

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

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

30/09/2011 Par

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

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

Utiliser debsums pour identifier les fichiers modifiés

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28/09/2011 Par

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

Bonjour,

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

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

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

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

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

À bientôt,
    Raphaël Hertzog.

Bilan à J+1

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

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

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

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

Soutenir Debian et le projet de traduction

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

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

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

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

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