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
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
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
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!
boost-defaults, and finally
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
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
buildd.debian.org instead, requesting the addition of
libibverbs to the
Packages-arch-specific list (aka.
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
kfreebsd-kernel-headers source package so that it gets
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!)
(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.