venez ici

Archive pour la catégorie ‘Général’

Adieu papa, bienvenue Baptiste

Lundi 8 février 2010

Il y a des périodes de la vie où beaucoup de choses changent brusquement, l’année de mes 30 ans en fait partie. D’abord mon fils Baptiste est né le 13 décembre 2009 et maintenant mon père André est décédé le 30 janvier 2010.

Papa tenant Baptiste

Papa est mort d’un cancer des poumons (à petites cellules), 16 mois après le diagnostic de la maladie. Malgré une première chimiothérapie fructueuse, le cancer est réapparu seulement 3 mois après. Aucune des chimio ultérieures n’a réussi à faire régresser le cancer, tout juste à ralentir sa progression. Il était hospitalisé depuis 3 semaines, étant devenu trop faible pour se déplacer seul dans la maison familiale. Il est mort en dormant, il s’est simplement arrêté de respirer.

Papa était apprécié de tout le monde, il était bon-vivant et avait le contact facile. En témoignent les 500 cartes de condoléances que nous avons reçues. Le président du cercle d’histoire de Hésingue (duquel papa était un membre très actif) a même rédigé un article publié dans les DNA et dans l’Alsace pour rendre hommage à son implication dans le milieu associatif (l’article oublie cependant sa participation au sein de la Ligue pour la Protection des Oiseaux).

Debian related goals for 2010

Samedi 9 janvier 2010

Here’s stuff that I’d like to do this year, more or less by decreasing order of importance:

  • translate my Debian book into English and get it published;
  • finish the cleanup of the perl API in dpkg-dev in order to create libdpkg-perl;
  • create dpkg-buildflags to export default build flags that packages should use (and get rid of the code setting those environment variables in dpkg-buildpackage), needed to properly fix #489771;
  • ensure the new source formats continue to gain acceptance by improving whatever is needed;
  • design a generic vcs-buildpackage infrastructure to be integrated in dpkg-dev. This design will probably happen through a DEP (Debian Enhancement Proposal) to ensure we have had proper discussion before someone gets to the implementation;
  • continue fixing dpkg bugs faster than they are reported;
  • enhance our infrastructure to ease interaction between contributors and to have a better view of how each package is maintained (see my last blog entry on this topic);
  • update the developers-reference where needed and fix some of the numerous wishlist bugs;
  • rewrite in C the last perl scripts provided by the dpkg binary package (update-alternatives/mksplit mainly, for dpkg-divert there’s a preliminary patch available already) so that it’s easier to build a minimal system without perl-base;
  • integrate the 3-way merge tool for Debian changelogs in dpkg-dev;

All of this probably doesn’t fit in my free time (being a father since last month does not help increasing my free time :-) ), so if you’re interested in seeing one or more of those projects completed, and if you know some person/company that could sponsor them, get in touch with me!

5 years of Freexian

Mardi 5 janvier 2010

5 years ago I founded my own company Freexian SARL with the goal to make a living out of my free software experience. I marketed the company as being specialized on the Debian distribution in the hope to combine my Debian work and my professional work.

Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration.

However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I’m able to contribute something back to Debian, it’s usually not in areas that I care about.

My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it’s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment — either in the blog or by mail).

That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don’t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows… maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome!

New source formats allowed in testing/unstable

Lundi 2 novembre 2009

The ftpmasters merged my dak branch last week during their meeting and have enabled the support of new source formats “3.0 (quilt)” and “3.0 (native)” in testing, unstable and testing-proposed-updates. I have uploaded 3 packages using the new formats already: logidee-tools using “3.0 (native)”, quilt and ftplib using “3.0 (quilt)”. The latter is arch any and has been successfully built on all architectures even those that still use an old version of sbuild (it looks like the fears that the old version would not cope with the new format were unfounded). For logidee-tools I built it with “-Zbzip2” in order to use bzip2 compression on the native tarball.

I have updated the wiki page and the release goal page with latest information. Feel free to convert some of your packages to give it a try. For ftplib, it led me to discover a Debian specific patch that I completely missed when I took the package over. This is precisely the kind of benefit that I expect from generalizing this format, it will encourage us to have separate documented patches instead of keeping everything hidden inside the usual .diff.gz. Combined with DEP-3 (patch tagging guidelines), we have a better infrastructure to share our patches with the rest of the free software community.

The next step is to fix all bugs listed here and make dpkg-source use the new source formats by default (#553928). Feel free to help by preparing patches (and offering NMUs), it’s a release goal to have all packages buildable with new source formats.

3-way merge of Debian changelog files

Jeudi 8 octobre 2009

I’ve been considering for some time now to create a merge tool specifically suited for debian/changelog files. My goal was to let Git use it automatically thanks to gitattributes.

I’ve just gone ahead, so let me introduce you git-merge-dch. Grab it with git clone git://git.debian.org/~hertzog/git-merge-dch.git, you can build a package if you wish. Beware, you need to have a dpkg-dev 1.15.5 that is not yet published (so you need to build dpkg from its git repository, git clone git://git.debian.org/dpkg/dpkg.git) as I rely on features that I introduced recently… you will also need the libalgorithm-merge-perl package.

Using it in a git repository requires two changes:

  • defining a new merge driver somewhere in the git configuration (in .git/config or ~/.gitconfig for example):
    [merge "git-merge-dch"]
            name = debian/changelog merge driver
            driver = git-merge-dch -m %O %A %B %A
    
  • defining the merge attribute for debian/changelog files either in .gitattributes in the repository itself or in .git/info/attributes:
    debian/changelog merge=git-merge-dch
    

Now you can safely maintain two branches of a package with changelog files evolving separately and merge one into the other without creating undue conflicts. Suppose you created an experimental branch for version 2.28 (you use a version 2.28-1~exp1) when 2.26.2 was current stable in the master branch. In the mean time, 2.26.3 got out and was packaged in master. Next time you merge stable into experimental, the changelog entries for 2.28 and 2.26.3 won’t collide despite being at the same place in the changelog file compared to the common ancestor.

Let’s continue with this example, 2.28 is out. Instead of adding a new changelog entry with « New upstream release » without further changes, you keep the current changelog entry and simply change the version into 2.28-1. While preparing this you discover a branch with fixes that was based on 2.28-1~exp1, if you merge it it will reintroduce a 2.28-1~exp1 entry that you don’t want. Fortunately you can use the --merge-prereleases (-m) option of git-merge-dch so that it strip the prerelease part of the version string and considers 2.28-1~exp1 and 2.28-1 to be the same entry really.

The only limitation is that this merge tool will remove any lines which are not parsed by Dpkg::Changelog (and which in theory are not supposed to be there).

Feel free to test, share your comments, report bugs and send patches!

Interdependence in Debian, how to suffer less from it

Mardi 1 septembre 2009

Listening to Martin Krafft’s talk at Debconf (related to his PhD) shed some new light on the idea that I expressed last year — I wanted that each maintainer regularly answers a questionnaire so that he has to ask himself whether he does a good enough job with his packages.

When thinking of this idea, I only saw the QA side of ensuring good maintenance on all packages, however I believe that the root problem lies further and this project would not be enough: we are interdependent but we are not equipped to deal with this reality. Martin’s only merit has been to mention that we are interdependent, but it’s worth analyzing a bit.

Our organization is centered around individuals acting as package maintainers, and in theory each package maintainer can work on his corner and all goes well. We know that this model doesn’t hold any more: transitions to testing require coordination of uploads and timely fixes of RC bugs, keeping up with the work frequently requires several volunteers that have to coordinate, etc. More and more of the work requires a level of availability that a single individual can’t offer, yet in our day-to-day work we mainly interact with individuals. Wouldn’t it be better if we could immediately know what we can expect from any Debian developer:

  • mean time to reply to Debian mail (reading every day or once a week is not the same);
  • amount/periods of time spent on Debian (knowing that they spend up to 4 hours mainly on Saturday can be useful);
  • current availability for Debian (if they are currently busy with life, we should be able to know it, if they know when it will end, it would also be good to share);
  • best way to get in touch for issues (they might have preference between IRC or mail);
  • kind of relationship they have with packages where they are listed in Maintainer/Uploaders (an active maintainer that uses the software daily is not the same than a passive maintainer that only packaged the software because it was a build-dependency for some other software that they care about);
  • any other information that the maintainer wants to share (about his habits/constraints/values/goals/whatever).

All this information should be shared by all Debian maintainers (some of it is already available but either not publicly or not in any machine-parseable way) and we should actively use it. Here are some examples of use: for each RC bug report, you could look up if at least one maintainer is available and you could ping him explicitly if needed. When you plan an NMU, you could look up if the maintainer is likely to respond in the next day or not, and possibly adjust the number of days spent in the DELAYED queue. When organizing a large-scale transition, you could extract a list of packages whose maintainers are not available and arrange immediate NMUs.

Furthermore there are many cases where the project’s usual expectation exceed what the maintainer is ready to do. Documenting what part of the job is done (or not) by the maintainer makes it clear for volunteers whether their help is needed and whether they could/would be a better maintainer for a given package.

Designing solutions to all these problems is going to be the scope of the DEP2 that I reserved some time ago. It’s likely to be some sort of dedicated web interface. I would welcome supplementary drivers for this DEP, so if you’re interested, get in touch with me.

La semaine de 4 heures

Mercredi 29 juillet 2009

Couverture de La semaine de 4 heures

Je vous propose à nouveau une lecture pour cet été, ca parle de vacances mais pas seulement…

Thimoty Ferriss s’appuie sur sa propre expérience pour expliquer comment tout un chacun peut essayer de devenir un « Nouveau Bienheureux », une de ces personnes qui profitent de la vie maintenant au lieu de se contenter d’une perspective de retraite encore lointaine. Partant de là, il nous invite à réfléchir sur nos rêves et sur ce que nous souhaitons réellement réaliser dans la vie. Une étude détaillée de ces derniers nous apprend qu’ils ne sont souvent pas si inaccessibles que nous voulons bien le croire. Simplement notre mode de vie et nos préjugés nous empêchent de les considérer comme réalistes. De plus, leur coût paraît souvent rédhibitoire.

L’auteur entreprend donc de nous guider pas à pas pour résoudre ces différents problèmes. Il remet en cause notre mode de vie et nous incite à devenir propriétaire d’une entreprise dont l’objectif ultime est d’assurer le financement de nos rêves tout en ne nécessitant qu’un minimum de travail. Les chapitres se succèdent pour expliquer les modalités : trouver une idée de produit à marge importante, automatisation de tout ce qui peut l’être, externalisation du reste… le tout saupoudré de conseils concrets pour obtenir une efficacité maximum. Efficacité d’autant plus importante lorsque l’on est salarié, et qu’il faut être meilleur que ses collègues pour mettre toutes les chances de son côté en vue d’une négociation d’un accord de télétravail. En effet, la mobilité fait partie intégrante de l’art de vivre des nouveaux bienheureux. Le livre se termine sur des conseils pratiques pour organiser ses voyages et profiter pleinement des nombreuses mini-retraites que ce nouveau mode de vie rend désormais possibles.

En achetant ce livre, je n’en attendais pas grand chose… je suis habitué aux livres de boursicotage faisant miroiter des perspectives alléchantes mais dont la mise en œuvre est très délicate pour ne pas dire impossible. J’ai pourtant été agréablement surpris, ce livre ne se concentre pas uniquement sur la partie entrepeneuriale du projet, il distille des conseils applicables à tous et nous pousse à remettre en cause notre situation… certaines de ses recommandations recoupent d’ailleurs les principes énoncés dans Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent. Ayant lu la semaine de 4 heures avant ce dernier, les réflexions de Thimoty Ferriss ont réellement attisé un désir de réfléchir sur ma situation et mon mode de vie.

Travailler quatre heures par semaine n’est pas réaliste pour tout le monde, mais tout le monde a la possibilité de changer son mode de vie pour l’améliorer et ce genre de livres est là pour nous le rappeler.

Squeeze freeze en décembre 2009

Mardi 28 juillet 2009

Debian 6.0 devrait donc être publiée dans le premier semestre 2010. Cela vient d’être annoncé pendant la keynote des Release Managers à la conférence Debian à Cáceres en Espagne.

Ensuite chaque nouvelle version devrait freezer en décembre des années impaires, donc squeeze+1 freezerait en décembre 2011, squeeze+2 en décembre 2013. Cela permet une meilleure coopération avec Ubuntu puisqu’ils prépareront leur version LTS en même temps que Debian préparera sa nouvelle version.

Voilà une nouvelle inattendue dont il est difficile d’évaluer les conséquences à ce point. Les prochains mois promettent d’être intéressants…

Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent

Mercredi 22 juillet 2009

Couverture les 7 habitudes de ceux qui réalisent tout ce qu'ils entreprennent

Bien que le titre laisse craindre un énième livre avec des recettes miracles, il n’en est rien. Le terme d’habitude signale simplement qu’il est important d’assimiler les principes énoncés pour que les mettre en œuvre devienne naturel. Ces principes ne sont pas des recettes mais des lignes directrices qui doivent nous guider dans chacun de nos choix pour tirer le meilleur de nous-mêmes et des autres. Voici un bref résumé.

Habitude 1 : soyez proactifs

De choix il est justement question dans la première habitude. Celle-ci nous explique en effet qu’à chaque « stimulus » nous pouvons choisir notre réaction. Ainsi, lorsqu’un événement nous énerve ou nous agace, il en va ainsi parce que nous l’avons choisi. Bien souvent la société ou notre entourage nous fournit des réactions toutes faites (et dans ce cas nous ne faisons pas réellement usage de notre possibilité de choisir), mais elles ne sont que rarement en concordance avec nos objectifs personnels.

Habitude 2 : sachez dès le départ où vous voulez aller

La deuxième habitude s’attache justement à définir nos objectifs personnels. L’auteur nous invite à nous projeter dans le futur le plus lointain possible : « que voulez-vous qu’on dise de vous le jour de votre décès ? ». Ainsi pour chaque rôle que l’on assume (employé, parent, ami, membre d’une association, etc.), il faut trouver des objectifs qui nous motivent réellement et dont on serait fier. Puis il faut les formaliser dans un énoncé de mission personnel. Cette capacité à se projeter dans le futur et à imaginer les conséquences de ses actes est le fondement de cette habitude. Les choix quotidiens sont plus faciles à faire si l’on sait où l’on va.

Habitude 3 : donnez la priorité aux priorités

La troisième habitude nous aide à gérer notre temps. Nous avons tous des longues listes de choses à faire et il est facile de se laisser submerger malgré une organisation méthodique. L’auteur nous invite à évaluer toutes les tâches selon deux axes, l’urgence et l’importance. La première s’évalue selon le délai disponible et la seconde selon la contribution de la tâche à nos objectifs personnels. À partir de là, il faut consacrer son temps aux tâches importantes (qu’elles soient urgentes ou non) et limiter le temps alloué aux tâches non-importantes. Il est important de passer du temps sur les tâches importantes non-urgentes car celles-ci contribuent généralement à l’amélioration de la situation à long terme (ex : prévenir les problèmes au lieu de les gérer).

Ces trois premières habitudes sont centrées sur l’individu et permettent normalement à tout un chacun de mieux appréhender sa vie. Mais la vie humaine se conçoit avant tout en société, c’est pourquoi les trois habitudes suivantes concernent les relations avec les autres.

Habitude 4 : pensez gagnant/gagnant

La quatrième habitude nous invite à dépasser les situations inutilement manichéennes. Lorsqu’une décision ne convient pas à l’une des parties, il est souvent possible de prendre une autre décision qui convienne à tout le monde. Il ne s’agit pas forcément de compromis : une fois les attentes de chacun clairement formulées, notre imagination peut trouver des solutions inattendues. Enfin, en dernier recours, on peut aussi envisager le statu-quo pour éviter de faire un perdant.

Habitude 5 : cherchez d’abord à comprendre, ensuite à être compris

La mise en œuvre de la 4ème habitude requiert une volonté de satisfaire les attentes des autres et cette 5ème habitude en est un prolongement naturel. L’écoute par empathie suppose d’aller dans le sens de son interlocuteur pour mieux connaître son mode de pensée, le paradigme dans lequel il évolue. Cela permettra aussi de formuler nos attentes de manière à ce qu’elles résonnent plus dans son esprit.

Habitude 6 : profitez de la synergie

La sixième habitude nous laisse miroiter des perspectives aussi intéressantes qu’inattendues. Créer des situations synergiques nécessite que les différents participants aient bien acquis les principes 4 et 5 et qu’ils se fassent confiance pour trouver collectivement une solution innovante. En effet, un processus de création synergique est dirigé par tout le monde et personne à la fois, il est donc difficile de prévoir les résultats mais ils sont bien souvent meilleurs qu’espérés car l’ensemble forme un tout bien plus important que la somme des parties.

Habitude 7 : aiguisez vos facultés

Enfin, la septième et dernière habitude est probablement une des plus importantes. Elle nous rappelle que nous devons chercher un équilibre conjuguant le physique, le mental, le social et le spirituel. Nous ne pouvons aller de l’avant que si nous le voulons et cela n’est possible que si l’on est bien dans sa peau. Il est donc important de passer du temps à s’entretenir physiquement, à apprendre de nouvelles choses, à faire le point sur ses objectifs, c’est un investissement sur soi-même — le plus rentable qui soit.

Avis personnel

Je ne saurai que vous recommander ce livre de Stephen R. Covey. En le lisant je me demandais pourquoi notre éducation à l’école ne passait pas par la lecture de ce genre de témoignages, tant il me semble que ce livre peut aider à se forger une identité et à donner du sens à nos vies. Quoi qu’il en soit, même si l’on n’adhère pas forcément à cette vision des choses, l’exploration de ces principes reste intéressante, d’autant plus qu’ils sont agrémentés d’exemples très concrets.

Stand Debian aux RMLL 2009

Lundi 13 juillet 2009

De retour des RMLL, il y a tout lieu d’être satisfait. Xavier Oswald avait pris l’initiative d’organiser un stand Debian, et il a connu un succès certain. Xavier, Aurélien Couderc, Roland Mas, ma femme Sophie et moi-même nous nous sommes relayés sur le stand pour assurer une permanence malgré les nombreuses conférences intéressantes.

Pour la première fois depuis longtemps, le stand Debian a pu proposer des articles de merchandising : t-shirts, badges, stickers et mêmes quelques livres (anciens cahiers de l’admin bradés) ont ravis les nombreux utilisateurs venus nous voir. Nous avons également récolté une dizaine d’adhésions à l’association Debian France qui prend enfin son départ officiel après deux ans de stand-by à cause d’un malentendu avec le ministère des finances.

La présence sur ces événements permet aussi de nous faire entendre au sein de la communauté du libre, plusieurs d’entre nous ont répondu à des interviews et nous avons pu ainsi défendre le point de vue du projet Debian. Pour ma part, j’ai été interviewé 20 minutes par Radio RMLL et j’ai également été filmé par Annexe21. Dans les deux cas, j’ai pu expliquer ce qu’était le projet Debian et éclaircir les raisons qui font que nous n’avons pas Firefox mais Iceweasel.

Face à ce bilan plutôt positif, j’espère que les utilisateurs qui rejoignent Debian France permettront d’assurer une présence de notre projet sur de nombreux événements locaux afin de renouveler cette expérience et nous rendre plus visible. Dans cette optique, Aurélien Couderc vient de rejoindre l’association pour prendre le rôle de responsable Merchandising. :-)


Close
E-mail It