DAVROMANIAK
Le site de Cyril "Davromaniak" Lavier, sysadmin ascendant geek
If you're watching this, it means I'm dead now.

Informatique et nouvelles technologies

Tout ce qui a rapport avec l'informatique, les jeux vidéos, etc....

Fil des billets - Fil des commentaires

lundi 2 avril 2012

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

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.

DDB lenny-backports discontinued

Hello everybody.

As Debian discontinued the support of the 5.0 "Lenny" release, I decided to do so in the DDB.

I will continue to maintain the squeeze-backports, and lenny-backports will be moved into another repository at http://archives.ddb.davromaniak.eu which will be created in the next hours or days.

Thanks.

dimanche 25 mars 2012

My pbuilderrc using qemu-debootstrap

Hello everybody.

First, I'm sorry for this late translation. I had a quite bad and busy period of time, so I was unable to take time to perform this translation.

As you are already aware of, Debian packaging takes a lot of my time, as well on the practical side as on the theoretical part of it.

Recently, I became co-maintainer of audacious and audacious-plugins Debian packages. Also, in few weeks, I will become co-maintainer of the NGINX package in Debian (it happened on March 16th).

I'm also working on making the NGINX maintaining team work as an actual team. I try to achieve this by scheduling milestones and managing Wheezy goals for the packaging. I also try to make all co-maintainers speaking when an important decision need to be taken (new upstream release to upload, module adding/removal, etc...). By far, I think it's working and we are finally working as a team.

But without any building/development environment, Debian packaging would be like playing Russian-roulette with a fully loaded machine-gun.

Why ?

It's simple.

Before any source package upload in Debian, building a package in a clean environment is highly recommended. You need to be sure of the build-deps and binary dependencies. Building a package on your own PC doesn't ensure you the well working of a package. Because like every user, you have packages already installed on machine, which some of them may be undeclared build-deps. So the package built well on your machine, but won't build in a clean environment.

There are a lot of ways to have a clean environment, here is a list :

  • Virtualized machines, which will be reinstalled after every build try (perfect for patient people with a lot of spare time).
  • The same as above, but with physical machines (sponsored by the electrical company because of the power consumption and useful during winter, because you can shutdown you house heating system).
  • Find a intern for reinstalling machines while you are working on source packages (expensive and may cause antidepressant drugs abuse by the intern).
  • Handmade chroots with debootstrap (We barely have a long-lasting solution, because we need to recreate chroots after every build. Hmmm, not so handy).
  • Use Debian powered tools, which create clean chroots (compressed in TGZ) and unpack them to build packages in it (pbuilder and its friend debootstrap are doing this very well).

As you guessed, the following will be about the pbuilder tool.

A pbuilderrc file can be used to configure pbuilder. Often placed in $HOME/.pbuilderrc, this i a shell script which is launched by pbuilder at the beginning of its work.

Like I already explained in the posts The ultimate Debian/Ubuntu package building system and Pbuilder and tmpfs can be friends, the .pbuilderrc file helps setting all aspects of these chroots creation and use.

After a lot of work on this configuration, I wrote a quite complete pbuilderrc now, supporting the use of qemu-debootstrap, which is an evolved debootstrap. It uses QEMU to virtualize the chroot hardware architecture. So now we can build ARM packages on a I386 or AMD64 machine without using a cross-compilation.

Before using this pbuilderrc, you need to install the qemu-debootstrap package. Available on squeeze-backports, wheezy and sid for Debian, and starting natty for Ubuntu.

I also recommend the reading of the post The ultimate Debian/Ubuntu package building system to have all needed tools to use pbuilder with this kind of configuration.

The pbuilderrc is available on my GIT repository named "scriptomaniak" available on github.

Download it in your /root/ folder, under the .pbuilderrc name.

Don't hesitate to comment this work and submit patches/pull requests.

That's all folks !

vendredi 24 février 2012

Mon pbuilderrc utilisant qemu-debootstrap

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 :).

vendredi 30 décembre 2011

Thruk + NGINX + authentication

Sometimes, when one line is missing, the whole system seems broken.

Lire la suite...

Thruk + NGINX + authentification

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

Lire la suite...

mardi 29 novembre 2011

Debian/Ubuntu package building using virtual machines

Hi.

As you know, I often work on Debian package building.

For some months now, the DDB provides packages for others architecures (powerpc and mips).

For the basic architectures (amd64, i386 and armel), I have physical machines for building, but for powerpc and mips, I use QEMU virtual machines.

As it took some time to create them, I decided to distribute them.

Every virtual machine is pre-configured using this article posted on March 2011, and pbuilders are created for Debian Lenny, Squeeze, Wheezy, Sid and Ubuntu Hardy, Karmic, Lucid, Maverick, Natty, Oneiric, Precise. Also, a README file containing all information for launching machines.

So here they are :

here are the MD5 sums, to check if the download went well :

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

To conclude, I thank Aurélien Jarno (aurel32), because he distributes QEMU virtual machines for most architectures, which served as base for these building machines.

Thanks.

Machines virtuelles de compilation de paquets Debian/Ubuntu

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 :

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.

samedi 6 août 2011

Moments de joie et backports

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 :).

Backports and some moments of joy

Good evening everybody.

A month after proposing the backport to Debian Squeeze of audacious 2.4.4, when I was starting to think it won't be accepted in the backports, I received 3 mails from Kilian Krause, who wants to sponsor the packages (audacious, audacious-plugins and libmowgli).

I was very surprised and so happy because this backport is very different from the nginx backport I made some months ago (and I'm working with the maintainers to keep the backport up to date, and to synchronise work).

As some people know, I use nginx as a daily base, it's installed on the server which serves this website, I used to make custom packages for my work (with adding some third party modules), so backporting nginx and contributing to it was barely normal.

But for audacious, it's completely different. Mid June, on the backport mailing list, somebody (rent0n) requested a backport of audacious, I simply answered to the mail saying I've added the maintainers in CC and that I think we might wait until the 2.5.1 gets in unstable, to make the backport. Few days later, no answer from the maitainers, so I wanted to try to make the backport, in case it's not possible. So it was possible, but, as a first try, I didn't wanted to change the needed versions of the build dependencies, so it was a raw backport, but I had to recompile barely the whole world (it was about 10-15 packages). 2 days later, I cleaned the package, so I just needed to backport the libmowgli. Then, the requester tested it, was happy, and for me, that was all, I just asked for anybody to review it and upload. Actually, I was not thinking about official inclusion, and so I didn't upload the package to mentors.debian.net. So then, I leaved for 10 days, to go on holidays, and I forgot about the package, but not rent0n, which was very enthousiast, and sent me a mail about upload the packages to mentors, so I did it, because I thought maybe somebody will be interested about this package.

One month later, the package was sponsored, and now it's waiting the ultimate validation.

So it's the second time I get a backport sponsored and uploaded. Strangely, it feels the same as if it was the first time. Some excitation about the next steps, then I will regularily check the buildd status, and I will be divised into 2 feelings. The first being the relief, this work is done, so all the moments passed working on it are just memories. The second being the joy, as people think my work is good enough to be included in the official backport repository.

Also, for every package I backport, I subscribe to the qa page, in order to receive notifications about bugs, updates, and everything related to the package.

Now, some news about the DDB.

Few days ago, I decided to remove all references to the chromium backport, as I was unable to maintain it, and it was not clean at all. Because of this, I may create a "dev" component for the DDB, but for the moment, it's not decided.

Also, I updated the nginx backport to the version 1.1.0, it's also uploaded to mentors, but will have to wait at least a week, to have it uploaded.

That's all folks !

- page 2 de 5 -