In the next hours or even days, I might be quite verbose so that people can have a tiny idea of what porting looks like. Or eventually what being in a bootstrapping phase looks like.

I love it when a plan comes together!

One important goal was trying to get sbuild installable within sid. Of course it is already installed on the buildds, but having it handy should help developers hack on their own boxes.

The chain of dependencies wasn’t very long, but still:

sbuild → libsbuild-perl           [not installable]
libsbuild-perl → schroot          [not built]
schroot → libboost-dev            [not built]
libboost-dev → libboost1.38-dev   [not built]
libboost1.38-dev → libopenmpi-dev [not installable]

First of all, I filed #535202 so that libibverbs can be built on GNU/kFreeBSD, which was needed because libopenmpi-dev depends on one of its binaries. We weren’t sure it was appropriate, though, since it looked like pretty much Linux-specific. So I filed #535225 to get installability issues of libopenmpi-dev on non-Linux architectures fixed (by excluding libibverbs-dev from the Depends on those architectures, matching what was already done for the build dependencies). A fixed package was uploaded in some hours only!

In the meanwhile, I gave mpi-defaults a shot, using the locally-built libopenmpi-dev package. It could have gone flawlessly if I didn’t stumble upon an FTBFS due to a toolchain change. #535230 got filed accordingly, and fixed some hours later too!

Building boost1.38, then boost-defaults, and finally schroot went smoothly, and all the above-mentioned packages are now installable on the porter box. And thanks to the responsiveness of those maintainers, plus some extra bits of wanna-build magic (give-backs using dep-waits), packages got tried (and built successfully) when their build dependencies became available on the buildds.

In the meanwhile, the maintainer of libibverbs confirmed that it’s not worth building useless binaries on non-Linux architectures, so I closed #535202 and opened a bug against buildd.debian.org instead, requesting the addition of libibverbs to the Packages-arch-specific list (aka. P-a-s): #535360.

Now, there are still some issues when trying to use sbuild, but it’s at least installable and people can try it out.

Working on another package also made me noticed that there was a bug in a FreeBSD kernel header: #535243. The fix is already in the repository, and it looks like I’m going to be added to the Uploaders of the kfreebsd-kernel-headers source package so that it gets uploaded quickly.

I hate impromptu toolchain-related FTBFSes

While I’m all for making tools as strict as possible (especially build-related tools), I really think it would be very nice for toolchain maintainers to deliver advance warnings.

GCC folks do that perfectly: File bugs, provide patches, raise severity when the new version is around, NMU if needed.

Dpkg folks prefer making a parser stricter, without caring at all which packages they might break. The previously-mentioned mpi-defaults was one of them.

The list of FTBFSes triggered by dpkg 1.15.3 (at least, the ones I spotted using 3 basic UNIX commands and spending a few seconds in lintian’s lab on lintian.debian.org, see how difficult that was!) follows: #535230, #535276, #535279, #535283, #535284, #535287, #535292, #535297, #535299, #535301, #535303, #535304, #535306, #535310, #535312 (all of them with tested patches because I didn’t feel like being lazy and shrugging over IRC after being notified).

At least it’s not about trying to sneak *FLAGS handling into a frozen testing this time. But that’s still annoying.