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.