Saturday started well, reading two stimulating articles on Planet_Debian. One about GitTogether2011, and the other about the use of Git in the Baserock company.

I like a lot the idea of using Git beyond source code management. This article is itself distributed via a network of Git repositories. For the Debian package I develop and that are maintained with Git, I started some time ago to store their build logs in a branch that I called meta. Since sbuild can filter some variable chains in its logs, the command git diff --word-diff=color became a nice tool to inspect the difference between two package builds. Here is for instance the update I made this morning for bedtools: we can see that -D_FORTIFY_SOURCE=2 is not passed anymore, and that consequently the -Wunused-result warnings disappeared.

Another advantages of storing build logs is simply to make available information that was not previously: contains the build logs for every architecture except the one used by the package maintainer, often one of the most popular architectures, because the uploads combine source and binary packages. This problem will be solved when our archive will automatically rebuild the binary packages uploaded with the source packages, but it will not be entirely solved as it is still possible to upload binary packages alone.

In the meta branch of my Git repositories, the logs are kept side-to-side for every architecture. I am unsure if that the best layout, but for the moment I am uncomfortable with having too many parallel branches. I am starting to automate the work with the logs, for instance with that small script to gather them from


for version in "$*"

  scp $BASEURL/${PACKAGE:0:1}/$PACKAGE/${version}/* .
  for arch in $(ls *bz2 | sed 's/_.*//g')
    do bzcat ${arch}*bz2 > ${arch}.log
    rm ${arch}_*_log.bz2;