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.

Some time ago, the box on which my blog is hosted went dramatically down, and I had to restore the blog by populating the git repository again, from my local copy.

Unfortunately, that means that the wiki had to be rebuilt from scratch, and all creation dates were messed up, leading some planet-like sites to show all of my posts again.

To ensure that this won’t happen again (even if I switch branches in the git repositories, move some files around, trash the ikiwiki cache, etc.), it looks like using meta dates is the way to go, for example:

 [[meta date="2009-07-02"]]

(One can use 2009-07-02 00:00:00 and 2009-07-02 01:00:00 to sort several entries on the same day, too.)

This way, all pages are rendered identically on every system.

To help maintaining those extra dates (kind of a burden, to be honest), I’ve written a tiny Perl script to automate it, and specified an alias in .git/config for that repository:

 [alias]
 ikiwiki-check = "!blog/2009/07/02/ikiwiki-dates.pl"

Inline replacement (in case of conflicts: same date without time, or with same time) or additions are then performed, and git status will show what needs tweaking.

More work that I initially imagined, but robustness should follow.

Would someone guess the link between:

• What mail client are you using?

• Are you around during the next two weeks?

After answering those, I’ve been offered to take care of the GNU/kFreeBSD buildds, which is yet another experience. \o/

Quite a good timing since I’ve recently tried to get involved with the GNU/kFreeBSD ports again, prodding maintainers, uploading fixed packages (usually thanks to Petr Salinger’s patches), or providing patches myself.

I thought I’d never have anything to say about Mono, Novell, etc., but some blog posts reminded me of an old story. Thankfully, I have a talented minion:

Random bits:

• Philipp’s now waiting for DAM, I’m very happy to have recommended another new Debian fellow.

• That’s this time of the year again. And to please Yoe: ADD 1 TO KIBI.

• After some time spent trying to fetch Blender sources and updating the packaging accordingly, 2.49 (release logs) finally got uploaded to unstable. Screenshot follows:

A couple of things I loved in the past few days:

• While talking about IP over DNS and aircrack techniques with a friend, being given some credentials to use a near-by hotspot directly (without tunneling).

• Attending a very nice concert with an old friend: das Hager-Trio¹ in Villa Falkenhorst [de]. It featured Claude Debussy, Silvio Lazzari, and Felix Mendelssohn Bartholdy. Of course I'm going to lack words to describe the wonderful moment I had in that very tiny room (approx. 60-70 seats, which probably helped obtain a very warmish atmosphere). Reminds me I should go out more often. :)

¹: Unfortunately, I can't seem able to find a related webpage. Its member: Inge Hager (violin), Elke Hager (cello), and Enrico Pompili (piano).

Of course I’m still waiting for the FrontDesk to check whether I did something wrong, but at first glance, I’m quite happy:

Application Manager assigned              Assigned on 2008-12-31
Application Manager recommends to DAM     Approved on 2009-02-01

Evgeni, it’s been a pleasure.

In experimental you can find:

• blender 2.48a: Finally (sorry for that) packaged. Upstream release logs: 2.47, 2.48.

• python-networkx 0.99 and its companion python-pygraphviz 0.99: Quite a huge step forward, to polish things before a 1.0 release.

• hugin 0.7.0: Lots! of things changed since the last upstream release. Grab it!

• libgphoto2 2.4.3: Upstream release logs from 2.4.1 and even older.

Some of those packages have been there for quite some time already, but experimental being what it is, a bit of advertisement is always welcome I guess.

This blog post is brought up to you by Sergio Leone.

The Ugly

See somebody propose the following change to a Depends line to make sure that a proper versioned dependency is set:

-Depends: ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}
+Depends: libts-0.0-0 (>= 1.0-5), ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}

While the obvious fix is to read Policy §8.6.5 and to use a debian/shlibs.local file accordingly.

The Bad

See the same person blog about his¹ own competences: “I’m not expecting people to have to match my levels of output […]”

¹: He’s a “he”, no point in using some gender-neutral thingy.

The Good

I’ve been proposed to become an Application Manager, which I accepted. Time to get back to my first NM!

Debian has a secretary that:

• doesn’t close the General Resolution: Project membership procedures vote in time. It’s 6:30 (UTC) right now, with a vote running till (past) midnight, and no results around, and the vote is still under “Voting Open”.

• doesn’t open the General Resolution: Lenny and resolving DFSG violations vote in time. Still at 6:30 (UTC), this vote is under “In Discussion”, while it should have started at (past) midnight.

• shortens the voting period for that stupid vote to one single week while it hasn’t been requested, as Sledge confirmed after my asking for a reference.

• initially failed to send the ballot to debian-devel-announce@.

Epic FAIL.

(I won’t mention again the incredible decision of putting everything into a single vote, others have done so already. And that’s of course the worst of all.)

Update: Just for fun (or despair), I sent another ballot for the General Resolution: Project membership procedures vote. And guess what?

This is an acknowledgement for your vote [record msg00356.raw] for
the vote "Project membership procedures"
sent in on Mon, 15 Dec 2008 08:37:16 +0100, with the subject
"Re: Final call for votes: GR: Project membership procedures"
…
Your vote has been recorded as follows
…
I note that this is not your first vote.

The time now is Mon Dec 15 08:08:06 2008

Thanks for your vote.

I’m lacking words, and running out of popcorn.