Buxy rêve tout haut

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 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!

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.

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!

During the last weeks I’ve been busy working on adding support of new source package formats to dpkg-source (the wig&pen format, a wig&pen variant based on quilt, Joey’s git based format integrated by djpig, …). I just reached the state where I believe the code is mostly ready to be merged in the master branch. Thus I would like some external testing and feedback.

Grab and install the package here and try building packages with dpkg-source "--format=3.0 (quilt)" -b mypackage (or any other new format). You can find more infos in the call for test on debian-dpkg (here and here). If you find regressions, please report them.

If you want to grab the latest sources, use git clone git://git.debian.org/git/dpkg/dpkg.git dpkg; cd dpkg; git checkout -b sourcev3 origin/sourcev3.

Yes, it’s DPL election time again. On the good side, we’ll spend less time this year than we used to thanks the constitution change. On the bad side, it seems that almost nobody is interested to run for DPL (even HE is not sure yet!).

I’ve been relatively satisfied by the work done by sam (although one can always do better) and it looks like many share this feeling… and when this is the case, we just expect the DPL to run again. But sam clearly said that he won’t run again. What a pity.

I also don’t plan to run this year[1] but I’m always interested in leadership issues and I’d gladly be part of a DPL team. Hopefully someone will provide such an alternative on the ballot this year.

Right now, I’m more in the mood of implementing some real changes (like the symbol based dependencies that I added to dpkg-shlibdeps) instead of trying to convince others to do them. When you associate this to some support of the leadership in place, it can give very good results.

Now back to real work, I still have to test and polish the dpkg-source rewrite which adds support of several brand new source package formats. Feel free to check out our progress in the sourcev3 git branch.

[1] Feel free to convince me otherwise by adding some comments here.

Malgré ma bonne volonté, je n’arrive pas à maintenir un rythme très régulier pour animer mon blog. Il faut dire que rédiger un bon article (c’est-à-dire avec du contenu intéressant, et avec une relecture pour éliminer la majorité des fautes d’orthographe et de grammaire) cela prend beaucoup de temps, et que le temps je n’en ai pas beaucoup à revendre.

En effet, depuis quelques temps je me suis mis à contribuer à dpkg. J’ai commencé avec un projet plutôt important, à savoir l’amélioration de dpkg-shlibdeps pour qu’il génère des dépendances minimales en fonction des symboles des bibliothèques utilisés par chaque programme. Tout au long, j’ai maintenu à jour une page du wiki avec les détails et l’avancement:
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps.
Comme le développement était assez important, il a eu lieu sur une branche dédiée qui vient juste d’être intégrée dans la branche master (autrement dit, le résultat sera dans la prochaine version de dpkg, c’est-à-dire la version 1.14.8).

Ce projet représente à mon avis une avancée très importante car si les bibliothèques les plus importantes emploient ce mécanisme rapidement, la majorité des paquets auront des dépendances moins strictes et il sera beaucoup plus souvent possible d’installer un paquet de unstable dans stable sans avoir besoin de le recompiler. Autrement dit, il y aura moins de rétro-portages (« backports ») à compiler et il sera plus facile d’installer la dernière version d’une application donnée.

Ce premier projet étant terminé, je me suis attaqué à un plus petit problème mais qui est intéressant tout de même. Jusqu’à présent, dpkg-gencontrol se contentait de substituer les variables dans les dépendances et d’écrire le résultat bêtement dans le champ correspondant.
Parfois le jeu des substitutions introduit des dépendances en double (parfois plus ou moins stricte). Comme lintian se plaint de ces problèmes, cela a conduit de nombreux mainteneurs à supprimer les variables et à mettre en dur les dépendances souhaitées. Maintenant, cela n’est plus nécessaire. En outre, les dépendances sont optimisées de telle sorte que si une dépendance dans le champ Pre-Depends implique une dépendance du champ Depends, cette dernière est supprimée (il en va de même pour les dépendances plus faibles listées dans Recommends puis Suggests). Je viens de soumettre une série de patchs pour inclure toutes ces fonctionnalités.

Je ne sais pas encore quel sera mon prochain projet, mais les récentes discussions sur un nouveau format de paquet source m’interpellent et peut-être vais-je essayer d’implémenter quelque chose qui combine le support du format wig&pen et les avancées apportées par les VCS distribués.

Ces différents développements concernent le paquet dpkg-dev qui contient essentiellement du perl. Ceux qui ne maîtrisent pas le C et qui n’osaient pas s’approcher de dpkg à cause de cela peuvent retourner leur veste et nous rejoindre sur #debian-dpkg sur irc.debian.org et la liste de diffusion debian-dpkg.
Enfin, http://wiki.debian.org/Teams/Dpkg contient des informations intéressantes pour qui veut débuter sur ce projet.