Le site de Cyril "Davromaniak" Lavier, sysadmin ascendant geek - Mot-clé - FRsAG

Inclure un fichier dans un autre en AWK

Cyril Lavier — Fri, 21 Sep 2012 13:58:00 +0200

Bonjour.

Une fois n'est pas coutume, un peu d'informatique sur ce blog (ne vous inquiétez pas, ça ne durera pas longtemps, le prochain INT10 est prévu pour mercredi soir :D).

J'ai été confronté au besoin de remplacer une chaine de caractères par le contenu d'un fichier dans un fichier texte.

Exemple : je désire remplacer "##__youpi_tralala__##" par le contenu du fichier nommé "youpi_tralala".

J'ai essayé en sed, mais ça ne fonctionnait pas à tout les coups, avec sed qui voulait interpréter le contenu du fichier "youpi_tralala".

Donc j'ai sorti mes moufles et mon outil préféré (AWK).

Voici le résultat, le script include_file.awk :

{
	str=$0
	where=match(str,regexp)
	if (where) {
		while (("cat "file) | getline tstr > 0) {
			if (newstr == "") {
				newstr=tstr
			} else {
				newstr=newstr"\n"tstr
			}
		}
		close (tstr)
		sub(regexp,newstr,str)
	}
	print str
}

C'est un beau script AWK, qui s'appelle de la façon suivante : awk -v regexp="belle regexp" -v file=/chemin/vers/le/fichier/a/inclure -f include_file.awk fichier_contenant_la_regex

Je m'en sers souvent en LaTeX pour débugguer certains include un peu farfelus que je veux faire, pour savoir si c'est le contenu du fichier à inclure ou mon include qui cause le problème.

Pour l'utiliser avec LaTeX, voici un exemple :

awk -v regexp="^%%__paragraphe1__%%$" -v file=includes/paragraphe1.tex -f include_file.awk document.tex | pdflatex -jobname=document

Ici, la chaîne présente dans mon fichier document.tex est "%%__paragraphe1__%%".

Et comme on dit : "Ça marche mais c'est crado... C'est made in davro !!"

Merci.

Debian Wheezy a été freezé

Cyril Lavier — Sun, 01 Jul 2012 18:42:00 +0200

Bonjour.

Hier soir, les migrations automatiques de paquets depuis Unstable vers Testing ont été arrêtées. Seul les paquets qui étaient en attente de cette migration ont reçu des autorisations.

Cela fait 8 ans que j'utilise Debian et je suis habitué aux processes de release. Mais je n'y ai jamais réellement porté attention jusqu'a ce que je contribue à Debian en 2011.

Cette freeze est importante pour moi car c'est la première fois que j'en vie une de l'autre côté, vu que j'aide à la maintenance des paquets Nginx (et audacious, mais j'ai été inactif ces derniers temps pour me concentrer pleinement sur Nginx jusqu'a ce que je retrouve une meilleure forme).

Le 27 Mai 2011, J'ai envoyé un mail à la mailing list debian-backports disant que j'ai réalisé un backport de Nginx 1.0.1 vers Squeeze et que j'espérait que quelqu'un l'uploaderait.

La première réponse provenait de Kartik Mistry, un des mainteneurs des paquets nginx (devenu le mainteneur principal depuis). Il a vérifié mon paquet et m'a proposé de l'aider dans la maintenance des paquets.

Ce fut le début d'un fabuleux périple au travers du projet Debian.

Au début, on a travaillés à synchroniser notre travail sur le packaging et le backporting, ensuite j'ai commencé à aider sur certains bugs. Mais j'ai surtout commencé à comprendre le processus de packaging.

Sur la dernière année, le plus gros travail sur le packaging Nginx n'a pas été technique, mais humain. Nous travaillons en équipe, dans laquelle chaque membre connait son rôle.

Je voudrai remercier quelques personnes :

Kartik Mistry et toute l'équipe de maintenance des paquets Nginx (Michael Lustfield, Jose Parrella, Fabio Tranchitella, Dmitry Oboukhov)
Sven Hoexter, qui sponsorise les backports nginx.
Benjamin Drung, qui m'a beaucoup aidé quand j'ai commencé à travailler sur les paquets audacious.
Et biensûr, tous les gens avec lesquels j'ai discuté sur les canaux IRC et les mailing lists.

Maintenant, quelques chiffres sur le packaging Nginx depuis la Squeeze freeze :

68 commits sur le dépôt GIT
262 commits sur le dépôt SVN
78 bugs fermés grâce à un upload
18 nouvelles versions de Nginx envoyées vers les dépôts debian.
28 uploads
- 19 par Kartik Mistry
- 4 par Michael Lustfield
- 4 par Moi
- 1 par Dmitry Oboukhov

Si vous voulez discuter ou nous aider, vous pouvez venir sur le canal IRC #debian-nginx sur le réseau OFTC.

Arrêt du support des lenny-backports sur le DDB

Cyril Lavier — Mon, 02 Apr 2012 08:52:00 +0200

Bonjour à tous et à toutes.

Debian arrêtant la maintenance pour la version 5.0 du système, j'ai décidé de faire de même sur le DDB.

Je continue toujours de maintenir les squeeze-backports et je déplacerai les backports lenny vers un autre dépôt, qui sera accessible depuis http://archives.ddb.davromaniak.eu dans les prochaines heures/jours.

Merci.

Mon pbuilderrc utilisant qemu-debootstrap

Cyril Lavier — Fri, 24 Feb 2012 16:27:00 +0100

Bonjour à tous.

Comme vous le savez déjà, je passe beaucoup de temps sur tout ce qui est packaging Debian, tant sur le côté pratique que théorique de la chose.

Récemment, je suis devenu mainteneur Debian des paquets audacious et audacious-plugins. Et d'ici quelques semaines, je deviendrai co-mainteneur du paquet nginx sous debian.

En dehors de ça, j'essaye d'améliorer le travail en équipe au niveau du packaging nginx en fixant des objectifs à atteindre pour la prochaine freeze, et en essayant d'impliquer tous les co-mainteneurs dès qu'une décision importante doit être prise (upload d'une nouvelle version, ajout/suppression d'un module, etc...). Ce qui porte pas mal ses fruits, et on commence à bien travailler en équipe.

Mais sans environnement de compilation, le packaging Debian serait similaire au fait de jouer à la roulette russe avec une Gatling.

Pourquoi ?.

La raison est simple.

Avant d'uploader un paquet source dans Debian, il vaut mieux tester sa compilation dans un environnement le plus vierge possible, afin d'être certain des dépendances de compilation (les fameuses build-dep) et des dépendances binaires. Compiler un paquet en local ne garantit aucunement la bonne compilation d'un paquet, car comme tout utilisateur, on a déjà des paquets installés sur la machine, dont certains sont des dépendances de compilation, ce qui peut fausser l'appréciation de la justesse du paquet.

Pour avoir un environnement vierge, il existe plusieurs méthodes, dont voici une liste :

Des machines virtuelles qu'on réinstalle à chaque compile (méthode pour les gens patients et qui ont surtout beaucoup de temps libre).
La même chose, avec des machines physiques (fonctionnement sponsorisé par EDF, vu la conso électrique que ça doit engendrer, et pratique en hiver, ça permet de couper le chauffage).
Trouver un stagiaire, qui s'occupera des réinstall pendant que vous bossez sur les paquets sources (relativement cher, et peut engendrer une consommation excessive d'anti dépresseurs en tout genre de la part du stagiaire).
Faire des chroots à la main, à coup de debootstrap (on s'approche d'une solution pérènne, mais on doit recréer les chroots à chaque compile, pas pratique).
Utiliser des outils fournis par Debian, qui créent des chroots vierges (compressés dans des TGZ) et les décompressent afin de les utilisent pour lancer les compilation (ce que fait parfaitement pbuilder avec son pote debootstrap).

Comme vous avez dû le deviner, je vais parler de l'outil pbuilder.

Pbuilder peut se configurer à l'aide d'un fichier nommé pbuilderrc, souvent placé dans $HOME/.pbuilderrc, qui est un script bash, que pbuilder lit et exécute avant de commencer à travailler selon les actions qu'on lui ordonne.

Comme déjà expliqué dans les billets La machine ultime pour compiler ses paquets debian et Pbuilder et tmpfs peuvent être bons amis, le fichier .pbuilderrc permet de configurer tous les aspects de la création et de l'utilisation de ces chroots.

À force de travailler pour personaliser ma configuration, j'en suis arrivé à écrire un pbuilderrc assez complet, qui peut gérer plusieurs aspects de l'utilisation des pbuilders, y compris l'utilisation de qemu-debootstrap, qui est un debootstrap plus évolué, qui peut utiliser qemu afin de virtualiser l'architecture matérielle du chroot. On peut donc compiler du arm sur une machine i386 ou amd64 sans avoir besoin de passer par la création d'un environnement de cross-compilation.

Avant d'utiliser ce pbuilderrc, il faut donc posséder qemu-debootstrap, compris dans le paquet "qemu-user-static". Ce paquet est dispo dans le dépôt squeeze-backports, wheezy et sid pour debian et à partir de Natty pour Ubuntu.

Il est aussi fortement recommandé d'avoir lu le billet La machine ultime pour compiler ses paquets debian avant de l'utiliser, afin d'avoir toutes les dépendances nécessaires pour utiliser pbuilder avec une telle configuration.

Le pbuilderrc est disponible sur mon dépôt GIT "scriptomaniak", disponible sur github.

Il est à placer dans le dossier /root/, sous le nom .pbuilderrc

N'hésitez pas à faire des remarques et à me proposer des patchs/pull requests si vous voulez l'améliorer.

Bonne lecture et merci :).

Thruk + NGINX + authentification

Cyril Lavier — Fri, 30 Dec 2011 10:25:00 +0100

Quand une seule ligne vous manque, tout est dépeuplé.

Bonjour.

Comme vous le savez, j'utilise NGINX sur mes machines. Et hier soir, j'ai voulu passer la dernière machine en NGINX, sauf qu'elle héberge notament un Shinken + Thruk.

Bon, le problème arrive avec Thruk.

Il utilise son propre serveur CGI, la conf avec Apache est assez triviale et tellement documentée, que j'me suis jamais posé la question sur cette partie de la conf.

Mais avec NGINX, c'est une autre paire de manches.

Mon thruk est installé dans /opt/thruk.

Voici le morceau de configuration NGINX que j'utilise, et qui fonctionne correctement :

location /thruk {
	auth_basic            "Monitoring Access";
	auth_basic_user_file  /opt/thruk/htpasswd.users;	
	fastcgi_index index.cgi;
	fastcgi_param REMOTE_USER $remote_user;
	fastcgi_pass	unix:/tmp/thruk_fastcgi.socket;
	include fastcgi_params;
}

Surtout NE PAS OUBLIER la ligne "fastcgi_param REMOTE_USER $remote_user;", qui envoie l'utilisateur logué à Thruk, qui donc le reconnait et vous autorise à accéder à l'interface.

Grand merci à ScriptFanix du canal IRC #shinken sur Freenode de m'avoir proposé cette solution, qui fonctionne :).

Merci.

Machines virtuelles de compilation de paquets Debian/Ubuntu

Cyril Lavier — Tue, 29 Nov 2011 12:05:00 +0100

Bonjour à tous.

Après quelques mois sans grande activité, le blog se réveille.

Comme vous le savez, je travaille souvent sur la compilation de paquets Debian.

Depuis quelques temps, je compile les paquets du DDB pour d'autres architectures (powerpc et mips).

Pour les autres architectures, j'ai ce qu'il faut en machines physiques, mais pour ces deux architectures, j'utilise des machines virtuelles qemu.

À force des les utiliser, je me suis décidé à vous les proposer, afin que vous puissiez compiler facilement des paquets Debian/Ubuntu.

Chaque machine est fournie pré-configurée en accord avec le billet posté en mars dernier et les pbuilder pour Debian Lenny, Squeeze, Wheezy et Sid et Ubuntu Hardy, Karmic, Lucid, Maverick, Natty, Oneiric et Precise. De plus, un fichier README contenant toutes les informations utiles pour le lancement des machines.

Donc les voici :

AMD64 (environ 6Go) : http://www.davromaniak.eu/qemu/build_machine_amd64.tar
I386 (environ 4Go) : http://www.davromaniak.eu/qemu/build_machine_i386.tar
MIPS (environ 2Go) : http://www.davromaniak.eu/qemu/build_machine_mips.tar
MIPSEL (environ 2Go) : http://www.davromaniak.eu/qemu/build_machine_mipsel.tar
POWERPC (environ 3Go) : http://www.davromaniak.eu/qemu/build_machine_powerpc.tar

Voici les sommes MD5, afin de pouvoir vérifier si le téléchargement s'est bien passé :

AMD64 : 3e55dd81c20c2a6f67a43a97d7eab986
I386 : 75c10975e65b1f816bc0a0711e9d12f3
MIPS : 9192d16ec83d31b3de0b381179e6eeef
MIPSEL : e01b1b1cdae64786d56b278c97e90c65
POWERPC : 63d0d2ceac849de0b0c1ad51eea4ee44

Pour finir, je tiens à remercier Aurélien Jarno (aurel32), car il fournit des machines virtuelles qemu pour différentes architectures, qui ont servi de base à ces machines de compilation.

Merci.

Moments de joie et backports

Cyril Lavier — Sat, 06 Aug 2011 21:41:00 +0200

Bonjour à tous.

Un mois est passé depuis la proposition (sur mentors) du backport de audacious 2.4.4 vers Debian Squeeze. Alors que je me faisais à l'idée que ces paquets n'allaient pas finir dans les backports, j'ai reçu 3 mails de Kilian Krause, qui accepte de sponsoriser les paquets (audacious, audacious-plugins et libmowgli)

J'étais très surpris et heureux, car ce backport est très différent de celui de nginx.

Comme certains le savent, j'utilise nginx régulièrement. Le site utilise nginx, je travaille dessus dans le cadre de mon travail, donc contribuer à nginx et réaliser le backport était naturel pour moi.

Mais pour audacious, c'est différent. Vers la mi-Juin, rent0n envoie une demande de backport d'audacious sur la mailing list backports. Je lui ai répondu, en ajoutant les mainteneurs en CC, et en disant qu'il serait plus judicieux d'attendre que la version 2.5.1 arrive dans unstable. Mais quelques jours après, aucune réponse des mainteneurs, alors je me suis demandé si ce backport est possible. Je l'ai fais, et ça fonctionnait, sauf que j'ai dû recompiler 10-15 paquets (pour un premier test, je n'ai pas voulu changer la version des dépendances, afin juste de voir si le reste du système était bon pour la compilation). 2 jours, j'ai nettoyé le paquet, testé chaque dépendance de compilation, and il s'est avéré que je n'avais besoin de backporter que la libmowgli. Donc j'ai proposé à rent0n de tester le paquet, il était content, donc pour moi, c'était bon, j'ai juste demandé si quelqu'un voulait valider et uploader le paquet. Mais je ne l'ai pas envoyé sur mentors.debian.net, car je ne pensais pas à une inclusion dans le dépôt officiel, pensant que les mainteneurs le feront mieux que moi. Après, je suis parti en vacances, donc j'ai un peu décroché de tout ça, mais pas rent0n, qui m'a proposé de l'envoyer vers mentors. Son enthousiame était tel qu'il était communicatif, donc j'ai envoyé le paquet sur mentors.

1 mois après, le paquet a été sponsorisé, et est maintenant en attente des dernières étapes de validation.

Donc voila, c'est la seconde fois qu'un de mes backports est sponsorisé et inclus. Bizarrement, ça me fait le même effet que si c'était la première fois. Un peu d'excitation, d'impatience par rapport aux prochaines étapes. Ensuite, j'irai voir son status sur le buildd presque une fois par jour, et ensuite, je vais être tiraillé entre 2 sentiments. Le premier, le soulagement, le travail est fait, tous ces moments passés à travailler sur le paquet sont maintenant des souvenirs. Le second, c'est la joie, car des personnes ont estimés que mon travail est d'assez bonne qualité pour mériter une inclusion officielle.

De plus, pour chaque paquet que je backport, je m'inscrit à page QA, pour être courant des bugs, mises à jour, et des infos du paquet.

Maintenant, parlons de DDB.

J'ai décidé de supprimer toute référence au backport de chromium, car je ne suis pas capable de le maintenir à jour, et que le paquet est si peu propre, que j'ai préféré le supprimer. Cependant, je pense créer une section "dev" pour le DDB, mais pas dans l'immédiat.

D'ailleurs, j'ai mis à jour le backport de nginx en version 1.1.0. Je l'ai envoyé sur mentors, mais devra attendre au moins une semaine avant un upload.

Voila, c'est tout :).

Pbuilder et tmpfs peuvent être bons amis

Cyril Lavier — Tue, 12 Jul 2011 17:31:00 +0200

Ou comment accélérer de façon non négligeable les compiles de paquets sous Debian/Ubuntu.

Salut à tous.

Suite au dernier billet sur la mise en place d'une machine de compilation de paquets Debian, j'ai continué mes bidouilles et mes recherches sur ce système de compilation.

Et il m'est pris l'idée d'utiliser un tmpfs (stocké en ram) pour accélérer mes compilations.

Alors déjà, il faut une grosse quantité de mémoire vive, à savoir 4Go minimum, car il faut pouvoir y stocker les données temporaire de compilation, et laisser assez de mémoire vive pour le système.

Dans mon, cas ayant 16Go de mémoire vive, aucun problème :).

Pour mettre ça en place, c'est plutôt simple (toutes les actions sont à effectuer en root, donc sous Ubuntu, préfixez les commandes par sudo).

Déjà, créez le dossier /var/cache/pbuilder/build s'il n'est pas créé :

mkdir /var/cache/pbuilder/build

Ensuite, armez vous de votre éditeur texte préféré, et ajoutez la ligne suivante au fichier /etc/fstab :

tmpfs 			/var/cache/pbuilder/build	tmpfs	defaults,auto			0	0

Montez la partition :

mount /var/cache/pbuilder/build

Ensuite, dans votre fichier /root/.pbuilderrc, ajoutez la ligne suivante :

APTCACHEHARDLINK=no

Cette ligne évitera que des hardlinks soient créés entre le cache et l'environnement de compilation, au profit de liens symboliques, vu que les 2 dossiers sont maintenant sur des partitions différentes.

J'ai effectué un test de performance avec une compile complète OWFS amd64 et i386 (11 systèmes supportés, donc 22 compilations), et voici donc les résultats :

Avec tmpfs : 53 minutes et 52 secondes
Sans tmpfs : 67 minutes et 18 secondes

Comme vous pouvez le voir, les perfomances sont au rendez vous.

Bon bidouillage :).

Quelques news

Cyril Lavier — Tue, 21 Jun 2011 11:11:00 +0200

Bonjour.

Après quelques mois d'inactivité, voici les dernières nouvelles.

Déjà, comme vous pouvez le voir, la nouvelle apparence du blog, plus sobre, et plus lisible.

Ensuite, les deux dépôts Debian que je maintiens (qui sont maintenant dans le menu principal).

Le dépôt OWFS est toujours là, et mis à jour régulièrement, avec la dernière version (2.8p9 sortie fin Mai), je prépare doucement le passage à Ubuntu Oneiric, ça devrait arriver dans les prochaines semaines.

Le nouvel arrivant, DDB (pour Davromaniak's Debian Backports), qui est un dépôt contenant les backports de paquets Debian que je réalise. Sachant qu'ils ont tous vocation à être proposés pour une inclusion dans les backports debian officiels. C'est un dépôt relativement stable, mais comme tout backports, il peut y avoir des risques.

Pour l'instant, j'ai mis à dispo les backports de nginx 1.0.4, chromium 11.0.696.71 et audacious 2.4.4. Le tout accompagnées de leurs dépendances de fonctionnement et de compilation.

D'ailleurs, concernant nginx 1.0.4, il a été récemment accepté dans les backports officiels, son inclusion est en cours là. Le paquet disponible (pour la version 1.0.4) sur DDB est donc le même que celui qui arrive sur les dépôts officiels, seul la version change (j'utilise "davrobpo60+1" au lieu de "bpo60+1" pour différencier mes paquets des paquets officiels).

Pour chromium, c'est un backport assez complexe (entre 20 et 30h de travail pour arriver à un fonctionnement correct), cependant, il n'est pas très propre, car j'ai préféré backporter les binutils, afin de ne pas trop altérer le paquet officiel.

Concernant audacious, il fonctionne, mais le travail est toujours en cours, surtout au niveau de la quantité de dépendances à backporter.

J'essaie de proposer les paquets dans le plus grand nombre d'architectures matérielles, et cela dépend de la taille des paquets. Pour l'instant, seulement OWFS et nginx sont proposés en 5 architectures différentes (amd64, armel, i386, mips et powerpc), car leur compilation n'est pas très longue. Concernant audacious, le nombre de dépendances le rendent pas facile à compiler sous autre architecture que amd64 et i386. Pour chromium, il n'est compatible que amd64, i386 et armel, cependant, sa compilation seule dure environ 25 minutes sur ma machine de compilation (8 cœurs, 16Go de ram), ma machine armel étant totalement l'inverse au niveau puissance, la compilation risque de durer des jours entiers.

Voila, c'est tout.

OWFS : Paquets Debian et Ubuntu

Cyril Lavier — Mon, 07 Mar 2011 14:34:00 +0100

Bonjour.

OWFS est une suite logicielle libre (sous GPL) qui permet d'utiliser facilement le système 1-wire de maxim, permettant d'exploiter divers capteurs (température, humidité, luminosité, ouverture/fermeture de portes, etc...).

Dans mon entreprise actuelle, ça fait environ 1 an et demi qu'on utilise le 1-wire, et à ce moment là, j'avais réalisé des paquets pour OWFS.

Ces paquets étaient plutôt bruts et relativement peu en accord avec la Debian Policy, mais ils fonctionnaient, et ça suffisait pour le moment.

Cependant, il y a quelques temps, il a été décider de publier ces paquets, afin d'aider la communauté qui existe autour d'OWFS, et plus généralement de la domotique.

Pour cela, j'ai donc travailler à mettre à jour et à rendre les paquets plus propres, et donc publiables.

Ce midi, par un mail (en anglais) sur la liste de diffusion, la diffusion des paquets pour OWFS a été officialisée et rendue publique.

Le mail étant en anglais, je ne vais pas le traduire dans son intégralité, vu que l'introduction de ce billet reprend en partie l'introduction du mail, je vais plutôt transcrire la suite du mail.

Les paquets sont disponibles pour les versions suivantes de Debian et Ubuntu :

Debian 5.0 "Lenny" (oldstable)
Debian 6.0 "Squeeze" (stable)
Debian 7.0 "Wheezy" (testing)
Debian Sid (unstable)

Ubuntu 8.04 "Hardy" (LTS)
Ubuntu 9.04 "Jaunty"
Ubuntu 9.10 "Karmic"
Ubuntu 10.04 "Lucid" (LTS)
Ubuntu 10.10 "Maverick"
Ubuntu 11.04 "Natty" (testing)

Maintenant, parlons des paquets.

Pour l'instant, je n'ai pas créé de paquets pour owperl, owmon, owtap, owphp, owcapi, owpython, owtcl, owftpd et owhttpd

Pour owftpd et owhttpd, je pense créer des paquets dans un futur pas trop lointain, sûrement pour une version 2.8p8 ou 2.8p9.

Pour les autres paquets, je n'ai, à l'heure ou j'écris ces lignes, aucune idée de quand je le ferai, mais ce n'est pas un abandon, plus une volonté de réaliser des paquets propres et fiables pour les composants essentiels d'OWFS, pour ensuite m'atteler aux autres composants.

Voici la liste des paquets (en versions 2.8p6 et 2.8p7, sauf indication) :

owfs-common : contient le fichier de configuration et la page de manuel.
owfs-server : contient le serveur owfs (/usr/sbin/owserver, il était placé dans /usr/bin, mais je l'ai déplacé dans /usr/sbin pour coller au mieux à la Debian Policy), sa page de manuel et son script de lancement.
owfs (2.8p7 seulement) : contient le serveur qui gère le système de fichiers 1-wire (/usr/sbin/owfs, il était placé dans /usr/bin, mais comme pour owserver, je l'ai déplacé dans /usr/sbin), sa page de manuel et son script de lancement.
owfs-client : contient les clients (owdir, owpresent, owread, owwrite and owread), et leurs pages de manuel.
libow-2.8-7 (2.8p7 seulement) : contient la libow en version 2.8p7
libow-2.8-6 (2.8p6 seulement) : contient la libow en version 2.8p6
owfs-dev : contient le fichier /usr/include/owfs_config.h
owfs-doc : contient toutes les pages de manuel restantes (notament celles sur les capteurs)
owfs-dbg : contient les symboles de débogage.

Pour l'installer le serveur et les clients, installez les paquets owfs-server et owfs-client. Pour utiliser directement le système de fichiers 1-wire, installez le paquet owfs.

Voici l'adresse du dépôt : http://owfs.davromaniak.eu

Voila, vous avez toutes les informations.

Je remercie Paul Alfille et les contributeurs du projet OWFS pour tout leur travail.

Là, j'ai réalisé quelques patchs qui sont inclus dans les paquets, je vais m'occuper aussi de leur diffusion.

De plus, il n'est pas impossible que je travaille à faire inclure ces paquets dans Debian (et aussi Ubuntu par la suite). Je vous tiendrai au courant pour tout ça.

La machine ultime pour compiler ses paquets debian.

Cyril Lavier — Thu, 03 Mar 2011 16:15:00 +0100

Voici un "petit" billet qui est à la frontière entre le perso et le boulot, mais qui risque d'être utile pour beaucoup de gens.

Dans le cadre de mon emploi actuel, je passe un certain temps à faire des paquets Debian, mais aussi Ubuntu.

Au début, j'utilisais 2 machines virtuelles, avec un petit pbuilderrc, cependant, ayant eu l'opportunité d'utiliser une machine plus puissante (4 coeurs et 4Go de ram), je me suis dis qu'il serait plutôt pratique de fusionner les 2 machines, et d'avoir qu'une machine de build.

Ma machine de build tourne sous Debian sid, même si j'ai longtemps été fidèle à Ubuntu, maintenant, je suis passé du coté de Debian (y compris pour mon poste de travail).

Pourquoi Debian sid ?, juste pour avoir les dernières versions des outils de build, surtout pour debootstrap.

Ça peut marcher aussi sous Debian stable, et même Ubuntu (mais quelques petites choses sont différentes).

Bon, commençons.

Les commandes précédées d'un "#" sont à exécuter en root, les commandes précédées d'un "$" sont à exécuter en utilisateur normal, non privilégié.

Précision, ma machine étant en 64 bits, j'ai la possibilité de compiler des paquets 32 et 64 bits.

En premier, il faut installer sudo, car avec le temps, j'ai appris (à mes dépends) qu'il ne faut jamais bidouiller ses paquets source en root, car ce n'est pas nécessaire, et que de plus, après quelques heures de tapotage de clavier, la fatigue faisant, on peut faire des actes regrétables et se transformer en Rage Guy pendant 5 minutes.

# aptitude install sudo

Ensuite, il faut adapter la configuration de sudo à ce qu'on fera avec pbuilder.

# visudo

Voici mon fichier de configuration de sudo :

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset,env_keep="DIST ARCH CONCURRENCY_LEVEL"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

#includedir /etc/sudoers.d

# Members of the admin group may gain root privileges
%adm ALL=(ALL:ALL) ALL

Remarquez surtout la ligne Defaults qui contient les instructions pour garder le contenu des variables DIST, ARCH et CONCURRENCY_LEVEL. Gardez les noms de ces variables dans la tête, on les utilisera après.

Après avoir installé sudo, on va s'occuper de la partie concrète de la compilation, avec l'installation des outils de compilation.

# aptitude install debhelper build-essential dpkg-dev pbuilder devscripts debootstrap

Parmis ces paquets, les plus remarquables sont pbuilder et debootstrap

pbuilder permet de construire ses paquets dans un chroot de la distribution que l'on veut utiliser.
debootstrap permet de créer ce chroot (il est appelé par pbuilder lors de la création d'un pbuilder)

Le paquet Lintian est aussi utile, car il permet de tester la conformité des paquets avec la Debian Policy.

Après avoir installé tout ça, il faut encore configurer le pbuilder, avec le fichier pbuilderrc. Vu que je n'aime pas trop aller modifier la configuration par défaut (placée dans /etc/pbuilderrc), je préfére créer le fichier /root/.pbuilderrc). Dont voici le mien.

# Codenames for Debian suites according to their alias. Update these when
# needed.
UNSTABLE_CODENAME="sid"
TESTING_CODENAME="wheezy"
STABLE_CODENAME="squeeze"
STABLE_BACKPORTS_SUITE="$STABLE_CODENAME-backports"
OLD_STABLE_CODENAME="lenny"
OLD_STABLE_BACKPORTS_SUITE="$OLD_STABLE_CODENAME-backports"

# List of Debian suites.
DEBIAN_SUITES=($UNSTABLE_CODENAME $TESTING_CODENAME $STABLE_CODENAME $OLD_STABLE_CODENAME "unstable" "testing" "stable" "experimental")

# List of Ubuntu suites. Update these when needed.
UBUNTU_SUITES=("natty" "maverick" "lucid" "karmic" "jaunty" "intrepid" "hardy" "gutsy")

# Mirrors to use. Update these to your preferred mirror.
DEBIAN_MIRROR="ftp.fr.debian.org/"
UBUNTU_MIRROR="fr.archive.ubuntu.com"

# Use old-releases mirrors for EOL versions
if [ "${DIST}" == "gutsy" ]; then
	UBUNTU_MIRROR="old-releases.ubuntu.com"
fi
if [ "${DIST}" == "intrepid" ]; then
	UBUNTU_MIRROR="old-releases.ubuntu.com"
fi
# Optionally use the changelog of a package to determine the suite to use if
# none set.
if [ -z "${DIST}" ] && [ -r "debian/changelog" ]; then
    DIST=$(dpkg-parsechangelog | awk '/^Distribution: / {print $2}')
    # Use the unstable suite for Debian experimental packages.
    if [ "${DIST}" == "experimental" ]; then
        DIST="unstable"
    fi
fi

# Optionally set a default distribution if none is used. Note that you can set
# your own default (i.e. ${DIST:="unstable"}).
: ${DIST:="$(lsb_release --short --codename)"}

# Optionally set the architecture to the host architecture if none set. Note
# that you can set your own default (i.e. ${ARCH:="i386"}).
: ${ARCH:="$(dpkg --print-architecture)"}

NAME="$DIST"
if [ -n "${ARCH}" ]; then
    NAME="$NAME-$ARCH"
    DEBOOTSTRAPOPTS=("--arch" "$ARCH" "${DEBOOTSTRAPOPTS[@]}")
fi
BASETGZ="/var/cache/pbuilder/$NAME-base.tgz"
DISTRIBUTION="$DIST"
BUILDRESULT="/var/cache/pbuilder/$NAME/result/"
APTCACHE="/var/cache/pbuilder/$NAME/aptcache/"
BUILDPLACE="/var/cache/pbuilder/build/"

if $(echo ${DEBIAN_SUITES[@]} | grep -q $DIST); then
    # Debian configuration
    MIRRORSITE="http://$DEBIAN_MIRROR/debian/"
    COMPONENTS="main contrib non-free"
    if $(echo "$STABLE_CODENAME stable" | grep -q $DIST); then
        EXTRAPACKAGES="$EXTRAPACKAGES debian-backports-keyring"
        OTHERMIRROR="$OTHERMIRROR | deb http://backports.debian.org/debian-backports $STABLE_BACKPORTS_SUITE $COMPONENTS"
    elif $(echo "$OLD_STABLE_CODENAME stable" | grep -q $DIST); then
        EXTRAPACKAGES="$EXTRAPACKAGES debian-backports-keyring"
        OTHERMIRROR="$OTHERMIRROR | deb http://backports.debian.org/debian-backports $OLD_STABLE_BACKPORTS_SUITE $COMPONENTS"
    elif $(echo "unstable" | grep -q $DIST); then
	DIST="$UNSTABLE_CODENAME"
	OTHERMIRROR="$OTHERMIRROR | deb http://ftp.fr.debian.org/debian/ experimental main"
    fi
elif $(echo ${UBUNTU_SUITES[@]} | grep -q $DIST); then
    # Ubuntu configuration
    MIRRORSITE="http://$UBUNTU_MIRROR/ubuntu/"
    COMPONENTS="main restricted universe multiverse"
     v=0
     n=0
     for i in ${DEBOOTSTRAPOPTS[@]}; do
	if [ $v -ne 0 ]; then
		DEBOOTSTRAPOPTS[$n]="/usr/share/keyrings/ubuntu-archive-keyring.gpg"
	fi
	if [ $i == "--keyring" ]; then
		v=1;
	fi
	n=$((n+1))
     done
else
    echo "Unknown distribution: $DIST"
    exit 1
fi

Afin de faciliter son téléchargement, vous pouvez le télécharger ici

Cependant, avant de vous jeter à corps perdu à créer les pbuilder des différentes versions de Ubuntu, il y a un petit truc à faire si vous êtes sous debian.

Dans les paquets debootstrap de Debian et Ubuntu, Il s'avère que les fichiers /usr/share/debootstrap/scripts/gutsy sont légèrement différents (une ligne), mais ça suffit pour causer des soucis, surtout sous Ubuntu 11.04 "Natty".

Donc sous Debian, à la ligne 72 du fichier /usr/share/debootstrap/gutsy, ajoutez la ligne suivante :

ln -nsf . "$TARGET/var/lib/dpkg/info/$ARCH"

Là, nous sommes enfin prets.

Avec ce beau .pbuilderrc, vous n'aurez qu'à taper la commande suivante pour créer un pbuilder Debian Squeeze en 64 bits :

$ DIST=squeeze ARCH=amd64 sudo pbuilder create

Ou un pbuilder Ubuntu Natty en 32 bits :

$ DIST=natty ARCH=i386 sudo pbuilder create

Mais là, vous vous demandez "Pourquoi nous a-t-il parlés de la variable CONCURRENCY_LEVEL ?".

Voici la réponse.

La variable CONCURRENCY_LEVEL permet de lancer plusieurs processus pour une compilation, en d'autres termes, pour ceux qui connaissent make, ça correspond à l'option "-j".

Pour compiler un paquet source avec 4 processus sous Debian Squeeze 64 bits voici comment faire :

$ CONCURRENCY_LEVEL=4 DIST=squeeze ARCH=amd64 sudo pbuilder build paquet.dsc

Pour compiler un paquet source avec 2 processus sous Ubuntu Natty 32 bits voici comment faire :

$ CONCURRENCY_LEVEL=2 DIST=natty ARCH=i386 sudo pbuilder build paquet.dsc

Voila, la machine de build est prête et fonctionnelle.

Mais sachant que j'aime bien avoir mes propres fonctions qui peuvent m'aider à automatiser certaines tâches, j'ai créé dans le dossier personnel de mon utilisateur non privilégié un dossier .scripts avec un fichier nommé pbuilder_utils dont voici le contenu :

function update_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder update
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder update
	done
}
function create_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder create
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder create
	done
}
function clean_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder --clean
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder --clean
	done
}
function build_pbuilder() {
	nprocs=$(grep -cE "^processor" /proc/cpuinfo)
	dsc=$1
	shift
	dists=$@
	for i in $dists; do
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=i386 sudo pbuilder build $dsc
		CONCURRENCY_LEVEL=$nprocs DIST=$i ARCH=amd64 sudo pbuilder build $dsc
	done
}

Dans le fichier .bashrc, j'ai ajouté la ligne source ~/.scripts/pbuilder_utils.

Vu comme ça, c'est un peu bourrin, mais voici les explications :

update_pbuilder : Permet de faire une mise à jour des pbuilders voulus, dans les 2 architectures, exemple : update_pbuilder squeeze natty
create_pbuilder : Permet de créer les pbuilders voulus, dans les 2 architectures, exemple : create_pbuilder squeeze natty
clean_pbuilder : Permet de nettoyer les pbuilders voulus, dans les 2 architectures, exemple : clean_pbuilder squeeze natty
build_pbuilder : Permet de compiler un paquet pour les distributions voulues et dans les 2 architectures, exemple : build_pbuilder paquet.dsc natty lenny squeeze

Voila, c'est à peu près tout.

Pour le pbuilderrc fourni ici, j'ai pris comme base celui fourni sur le wiki de ubuntu.com à l'adresse suivante : https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders

Pour le reste, ben c'est de l'arrachage de cheveux, de la bidouille et de multiples essais infructueux.

Sur ce, bonne lecture.