Destination Debian

Infos à la source, maîtrisez votre distribution Debian/Ubuntu

  • Soutenir
  • Mes livres
    • Mémento Git à 100%
    • Debian 8 Jessie
  • Lettre d’informations
  • Mes activités chez Debian
    • Historique
    • Mes projets
  • Mes autres sites
    • My blog on free software
    • Freexian, ma société
    • Mon blog perso
  • Contact
Home Archives for Ubuntu

Comment recompiler un paquet Debian

Posted on 12/07/2011 Written by Raphaël Hertzog

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.

Filed Under: Documentation, Documentation pour les utilisateurs Tagged With: APT, apt-get, dch, Debian, devscripts, dget, dpkg-checkbuilddeps, dpkg-source, HOWTO, Libre, Packaging, Recompilation, Ubuntu

Comment Ubuntu s’appuie sur Debian pour son développement

Posted on 22/06/2011 Written by Raphaël Hertzog

Dans quelle mesure Ubuntu est-elle liée à Debian ? De quelle façon les paquets « migrent »-ils de l’un vers l’autre ? Cet article est une ébauche de réponse à ces questions qui m’ont été posées.

D’où viennent les paquets ?

La plupart des paquets ont été créés par des contributeurs Debian, et uploadés dans dans Debian unstable (ou experimental). Les nouveaux paquets sont passés en revue par les ftpmasters Debian pour acceptation dans l’archive officielle. Le temps de l’audit, ces paquets sont conservés dans une file d’attente dédiée, pour une durée allant de quelques heures à quelques mois (une à deux semaines généralement).

Ubuntu importe tous les paquets Debian officiels, auxquels s’ajoutent leurs propres paquets. Environ 7% de la base de paquets Ubuntu correspondent à des applications tierces empaquetées pour Ubuntu et non pour Debian.

Quelles sont les modifications faites par Ubuntu ?

De tous les paquets en provenance de Debian, 17% incluent des modifications supplémentaires faites par Ubuntu. La plupart des paquets concernés appartiennent au dépôt main, qui est activement maintenu par Canonical et les core developers d’Ubuntu. Le dépôt universe est quant à lui beaucoup plus fidèle aux paquets Debian d’origine.

La plupart des modifications faites par Ubuntu sont motivées par les décisions prises lors du Ubuntu Developer Summit. Celles-ci tendent vers des objectifs bien précis : meilleure interface utilisateur, temps de démarrage plus rapide, meilleure accessibilité en tant que plateforme pour les applications tierces, intégration avec leurs propres services en ligne (Launchpad, Ubuntu One), etc. Les autres modifications sont le fruit des corrections de bogues soumis par les utilisateurs d’Ubuntu.

Il est à noter que même les paquets binaires Ubuntu n’ayant pas subi de modifications au niveau de leurs sources diffèrent de la version binaire Debian. Il s’agit là d’une conséquence du changement d’environnement de compilation réalisé par Ubuntu : ils ne supportent que les processeurs type x86 de classe supérieure ou égale à 686, activent des options de compilation que Debian n’activent pas, … Tous les paquets binaires sont de plus modifiés par un programme appelé pkgbinarymangler.

Cycle de publication d’Ubuntu et lien avec Debian

Ubuntu publie une nouvelle version tous les 6 mois (sur le concept des publications à date fixe). Le rapport au temps étant radicalement différent chez Debian, comment Ubuntu parvient-elle à réutiliser le travail de Debian ?

Réponse : en important les paquets de Debian unstable (parfois même d’experimental), ce qui assure la « fraîcheur » des paquets. Si la version Ubuntu du paquet contient déjà des modifications spécifiques à la distribution, elles sont simplement fusionnées dans le paquet Debian nouvellement copié. Dans le cas contraire, le paquet Debian est juste importé, puis recompilé pour Ubuntu… ce qui fonctionne plutôt bien, Debian unstable l’étant beaucoup moins que son nom le laisse supposer.

Cet import automatique ne dure que les deux premiers mois du cycle, jusqu’au gel de l’import Debian. Il reste donc pas mal de temps après coup pour corriger le plus gros des problèmes.

Durant les troisième et quatrième mois, l’import de paquets est toujours possible, mais non automatique : il doit être explicitement demandé par un développeur. A la fin du quatrième mois, le gel des fonctionnalités est décrété, mettant définitivement fin à la période d’import.

Les deux mois restants sont dédiés aux corrections de bogues, ainsi qu’aux finitions de détail. De nombreux gels mineurs interviennent durant cette période, le planning de publication de Natty en donne un exemple. L’import de paquets Debian est maintenant exceptionnel, et autorisé uniquement s’il s’agit de mises à jour correctives côté Debian.

Crédits : certains chiffres sont repris d’une conférence de Lucas Nussbaum, basés sur les paquets disponibles pour la version Lucid Lynx d’Ubuntu.

Cet article est une traduction de How Ubuntu builds up on Debian contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Filed Under: Documentation, Documentation pour les utilisateurs Tagged With: Debian, experimental, gel, Introduction, Libre, Release, Ubuntu, unstable

La bonne manière de supprimer un fichier de configuration obsolète dans un paquet Debian

Posted on 06/06/2011 Written by Raphaël Hertzog

Un conffile est un fichier de configuration géré par dpkg, mais je suis certain que vous vous souvenez de cet article introductif à propos des conffiles. Lorsque votre paquet cesse de fournir un conffile, celui-ci reste simplement sur le disque et est considéré comme « obsolète » par le gestionnaire de paquets. Il n’est retiré que dans le cas de la purge (et non de la simple suppression) du paquet. Si vous souhaitez que ce fichier soit retiré avant ce terme, il ne vous reste plus qu’à coder vous-même en ce sens les scripts de configuration de vos paquets. Voyons donc comment.

Quand est-ce nécessaire ?

dpkg privilégie la sécurité en ne supprimant pas ce fichier sauf en cas de purge. Pourtant, il est généralement plus avisé de le faire plus tôt pour ne pas induire l’utilisateur en erreur. C’est même obligatoire dans certains cas, puisque garder le conffile pourrait provoquer des erreurs logicielles (par exemple dans le cas où il se trouve dans un dossier « .d », et qu’il contient des entrées plus supportées ou contradictoires avec celles de nouveaux conffiles).

Qu’est-ce que « rm » a donc de compliqué ?

Vous souhaitez donc supprimer le conffile. Ajouter une commande « rm » dans debian/postinst semble plutôt facile. Certes, mais ce n’est pas du tout la bonne manière de procéder ! Il se pourrait que le conffile contienne certaines adaptations faites par l’administrateur, que vous ne souhaitez pas perdre. Plutôt que de supprimer, vous souhaitez plutôt garder le fichier dans un coin, afin que l’administrateur puisse récupérer ce qu’il avait fait et s’en servir comme bon lui semble.

La bonne action à prendre est donc de demander le déplacement de ce fichier dans le script prerm, afin d’éviter toute interférence avec la nouvelle version. Simultanément, vous devez vérifier si le conffile a été modifié par l’utilisateur, et, si c’est le cas, le retenir pour plus tard. Puis, dans le script postinst, le supprimer s’il n’y aucun changement entre la nouvelle et l’ancienne version, ou le garder sous un autre nom, si différence il y a. Ajouter un suffixe type .dpkg-bak est généralement suffisant, dans la mesure où de nombreuses applications sont configurées pour ne prendre en compte que les fichiers d’une certaine extension (*.conf, au hasard). run-parts, par exemple, ignore tous les fichiers contenant un point dans leurs noms. Dans le script postrm enfin, il est nécessaire de supprimer les conffiles conservés jusque-là en raison de changements locaux et, au cas où l’installation rendant obsolète le conffile est annulée, restaurer l’ancienne version.

Automatisons tout cela grâce à dpkg-maintscript-helper

Fioouuuu… c’est une longue liste de tâches à réaliser pour une action apparemment simple ! Heureusement, tout cela peut être automatisé grâce à dpkg-maintscript-helper. Partons du principe que vous souhaitez supprimer /etc/foo/conf.d/bar, du fait qu’il est maintenant dépassé et que vous préparez une nouvelle version 1.2-1 qui le supprimera lors de la mise à jour. Il vous suffit de copier-coller l’extrait de code suivant dans les 3 scripts (preinst, postinst, postrm) :

if dpkg-maintscript-helper supports rm_conffile 2>/dev/null; then
    dpkg-maintscript-helper rm_conffile /etc/foo/conf.d/bar 1.2-1 -- "$@"
fi

Le if peut être évité en posant une dépendance à « dpkg (>= 1.15.7.2) », ou s’il s’est écoulé suffisamment de temps pour supposer que tout le monde dispose d’une version assez récente. La page de manuel de dpkg-maintscript-helper vous apportera tous les détails nécessaires.

Cet article est une traduction de The right way to remove an obsolete conffile in a Debian package 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.

Filed Under: Documentation, Documentation pour les contributeurs Tagged With: conffile, Debian, dpkg, dpkg-maintscript-helper, HOWTO, Libre, Packaging, Ubuntu

Comment trouver le bon paquet Debian: interfaces de recherche de haut-niveau

Posted on 30/05/2011 Written by Raphaël Hertzog

L’archive Debian est connue comme l’une des plus larges collections de logiciels libres au monde. Avec plus de 16 000 paquets source et plus de 30 000 binaires, les utilisateurs ont parfois quelques difficultés à trouver les paquets qui leurs sont utiles. Le développeur Debian Enrico Zini a travaillé sur l’infrastructure pour résoudre ce problème. Durant la dernière mini-debconf à Paris, Enrico a présenté ce sur quoi il travaillait ces dernières années lors d’une conférence; travaux qui « n’avaient pas encore obtenu l’attention qu’ils méritaient ».

Enrico est connu dans la communauté Debian pour l’introduction des debtags, système de classification des paquets se basant sur des facettes. Chaque facette décrit une propriété spécifique : type d’interface utilisateur, langage de programmation utilisé, types de document manipulés, vocation du logiciel, … Ses derniers travaux s’appuient sur cette classification, et sont disponibles au travers du paquet apt-xapian-index, que ce soit sous Debian ou sous Ubuntu. L’objectif étant de permettre l’interrogation de la base des paquets disponibles au travers de requêtes complexes.

Utilisateurs de apt-xapian-index

Lors de cette présentation, Enrico a évoqué les premières utilisations de ses travaux. La plus connue étant celle proposée dans l’Ubuntu Software Center, à travers sa fonction de recherche renvoyant quasi-instantanément les résultats, et ce grâce à apt-xapian-index. Il ne s’agit là toutefois que d’une utilisation basique, n’exploitant que peu des fonctionnalités avancées fournies par apt-xapian-index.

GoPlay! est également un des premiers à l’avoir adopté, et à en utiliser certaines fonctionnalités avancées. Il s’agit d’une interface graphique permettant de rechercher des jeux. À cette fin, GoPlay! utilise les debtags pour classer les jeux en différentes catégories de sorte que vous puissiez, par exemple, naviguez parmi tous les jeux d’action/arcade 3D ayant un lien avec les voitures. Le concept de GoPlay! a même été étendu jusqu’à devenir un navigateur de paquets plus généraliste se basant sur les debtags. C’est ainsi que le paquet fournit maintenant également GoLearn!, GoAdmin!, GoNet!, GoOffice!, GoSafe!, et GoWeb!.

Autre exemple, Fuss-launcher est un lanceur d’application, et non pas un navigateur de paquets. Mais il utilise également apt-xapian-index, et il est du coup capable, en se basant sur les informations stockées au niveau des paquets, de retrouver plus facilement les applications installées. En effet, les descriptions de paquets sont généralement plus verbeuses que celles contenues dans les fichiers .desktop. Autre fonctionnalité sympathique qu’Enrico a montré à son audience : en faisant un glisser-déposer d’un document dans Fuss-launcher, ce dernier vous dresse la liste des applications pouvant l’ouvrir !

Enfin, apt-xapian-index met également à disposition un outil de recherche en ligne de commande qui est beaucoup plus efficace, et de loin, au traditionnel apt-cache search : il s’agit de axi-cache search (axi étant ici l’acronyme de apt-xapian-index). Enrico fit la comparaison de la sortie d’apt-cache avec celle d’axi-cache, avec comme entrée la recherche de la lettre « r » : tandis que apt-cache énumérait une liste infinie de paquets contenant cette lettre quelque part dans leurs descriptions, axi-cache ne lista que les paquets concernant GNU R. Il fit également une démonstration de la complétion contextuelle automatique : contextuelle car se basant sur les debtags pour raffiner la recherche. En effet, une fois un premier mot-clé tapé, la complétion via la touche Tab ne montre que certains mots-clé ou debtags : ceux permettant de restreindre encore plus la recherche. L’interrogation via des requêtes à base d’opérateurs logiques (AND, OR, NOT, XOR) est également supportée.

Sous le capot

Enrico présenta ensuite les rouages de cette mécanique. Le moteur de recherche Xapian est au cœur de l’infrastructure, et il l’apprécie car il ne s’agit que d’une simple librairie (et non un démon), pourvue de sympathiques bindings Python. Des plugins, également écrits en Python, peuvent venir étendre les capacités d’apt-xapian-index, qui, même si sa fonction principale reste l’indexation des descriptions de paquets, enregistre beaucoup plus d’informations que nécessaires à cette tâche.

Parmi les informations stockées, on compte par exemple :

  • des mots apparaissant dans la description des paquets (ce qui inclut les traductions, dans le cas où l’utilisateur utilise une locale non anglaise);
  • l’origine des paquets;
  • leurs sections;
  • leurs tailles, ainsi que l’empreinte disque une fois installés;
  • leurs dates de première apparition;
  • les icônes, catégories ou descriptions des fichiers .desktop contenus (via app-install-data);
  • les alias d’applications populaires non disponibles sous Linux (par exemple « excel » renvoie au debtag office::spreadsheet).

Enrico a d’ores et déjà prévu d’enregistrer encore plus d’information : ajouter les données du popularity contest (cf. les rapports de bogue #602180 et #602182) lui permettrait ainsi de trier les résultats de manière efficace. En effet, les applications les plus utilisées sont généralement un bon choix en terme de support de la communauté, ainsi que du point de vue de la qualité, précisément du fait de cette large base d’utilisateurs. Stocker les dates de dernière installation/mise à jour/suppression rendrait plus facile la détermination d’une régression, due à une mise à jour d’un paquet particulier.

L’index étant accessible sans restriction, n’importe quelle application peut en tirer profit, sous réserve qu’elle puisse utiliser la librairie Xapian – écrite en C++ mais disposant de bindings Perl, Python, PHP, Java, Tcl, C# et Ruby.

Appel à l’expérimentation

De nombreuses applications utiles reposant sur apt-xapian-index restent encore à inventer, selon Enrico. Il lance ainsi un appel à « l’expérimentation », ainsi qu’à de nouvelles idées. La seule limite pratique à laquelle il s’est confronté est la taille de l’index : entre 50 (Debian unstable sans aucune traduction) et 70 Mo (Debian stable/testing/unstable avec les traductions dans une langue). Il préférerait ne pas le voir dépasser 100 Mo, dans la mesure, d’une part, où le paquet est installé par défaut (étant un paquet recommandé par aptitude), et d’autre part parce qu’il serait mal à l’aise à l’idée d’utiliser plus de 20% de l’empreinte disque d’une installation minimale juste pour ce service. C’est la raison pour laquelle l’index a été configuré pour ne pas stocker la position des mots-clé : il n’est donc pas possible de trouver les paquets dont la description contient le terme « calcul » immédiatement suivi de « statistique ». Par contre, il est possible de trouver ceux contenant les deux mots n’importe où dans leurs descriptions.

Apt-xapian-index offrirait-il trop de libertés ? C’est la question que s’est posé Enrico. Ce qui pourrait expliquer pourquoi si peu de personnes l’ont testé, malgré les nombreux billets sur son blog, dûment documentés avec exemples de code et tutoriaux. Mais il n’est pas difficile d’imaginer d’autres exemples d’utilisation : on pourrait ainsi étendre les fonctionnalités d’outils tels que rc-alert ou wnpp-alert par exemple, qui fournissent une longue liste de paquets Debian cherchant un peu d’aide, et qui sont installés sur la machine. Il serait ainsi possible d’utiliser apt-xapian-index pour restreindre les résultats aux seuls paquets écrits dans un certain langage, ou dédiés à un environnement de bureau particulier.

L’explication la plus probable étant certainement que trop peu de personnes ont entendu parler de cet outil. Il y a bien d’autres cas où les fonctionnalités d’apt-xapian-index pourrait être utile, et, à mon sens, le souhait d’Enrico pourrait bien devenir réalité.

Cet article est une traduction de How to find the right Debian packages: high-level search interface contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Filed Under: Actualités, Actualités Debian, Actualités Ubuntu Tagged With: apt-xapian-index, Debian, debtags, Enrico Zini, Libre, Recherche, Ubuntu, Xapian

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • Next Page »

Découvrez mes ouvrages

Apprenez en plus en cliquant sur leur couverture :

Lettre d’informations

Abonnez-vous à ma lettre d'informations, saisissez votre adresse électronique et cliquez sur « S'abonner » :

Suivez moi

  • Adresse mail
  • Facebook
  • GitHub
  • RSS
  • Twitter

Archives

Planètes

  • Planète April
  • Planète Debian-Fr
  • Planète des utilisateurs Debian
  • Planète Libre

Flux Mon blog anglophone sur le libre

  • Freexian is looking to expand its team with more Debian contributors 29/03/2024
  • Freexian’s report about Debian Long Term Support, July 2022 31/08/2022
  • Freexian’s report about Debian Long Term Support, June 2022 26/07/2022
  • Freexian’s report about Debian Long Term Support, May 2022 23/06/2022
  • Freexian’s report about Debian Long Term Support, April 2022 03/06/2022
  • Debian 9 soon out of (free) security support 11/05/2022

Mots-clés

3.0 (quilt) Annonce aptitude Cahier Admin conffile Contribuer DebConf Debian Debian France Debian Live Distro Tracker dpkg dpkg-source Eyrolles Freexian GNOME GSOC HOWTO Informatique Kali Linux Libre Livres LTS Moi multiarch nautilus-dropbox nettoyage Packaging Politique Presse Pro Programmation PTS publican python-django Release Rolling Référence Résumé d'activité synaptic Testing Tryton Ubuntu unstable wordpress

Articles récents

  • Le logiciel libre a t’il une couleur politique ?
  • Mes activités libres en janvier 2017
  • Élections présidentielles, logiciel libre et Charlotte Marchandise
  • Mes activités libres en décembre 2016
  • Mes activités libres en novembre 2016

Copyright © 2025 · Focus Pro Theme sur Genesis Framework · WordPress · Log in