I've had a few weeks with very little time spent on Debian. I did set aside
some time to try to find and fix an RC bug, to help the release. Steven C
commented to let me know about the UDD Developer's
Dashboard
which is a great way to find RC bugs relevant to a team. I sat down to try and
fix #648272 in 'Abuse' but sadly I didn't
manage, instead finding another possible RC bug
#689457 on the way.
I was curious as to how long the version 1 web services API for musicbrainz
will be kept around, in case there was a strong likelyhood it would be turned
off during the lifetime of wheezy. If that were the case, then it might have
been worth requesting freeze exceptions to patch the last few WS1 clients to
use WS2 instead. However, the musicbrainz developers have no plans to turn off
WS1 as long as there are people still using it. This is a bit of a chicken and
egg situation for wheezy, but probably not strong enough grounds to persue it
any further.
So last night was my first "Debian Day" in a while, and by chance I've had a
number of enquiries for software and packages which I haven't touched in a
while.
For the prboom package, we rebuild the upstream tarball to remove some
material we don't have the right to distribute. The code that does the
repackaging lives in a script called debian/fix_upstream.sh. Prboom upstream
release very infrequently, so the script hasn't been run in a while. Fabian
Greffrath noticed some bashisms which meant it would not work reliably with a
non-bash /bin/sh. He also noticed that we couldn't build the binary lump
data/prboom.wad using only free software since some changes that were made to
freedoom. One possible fix was to expand the deutex package to recognise
freedoom.wad, which I've now applied.
Fabian has fixed the bashism issue, but I suspect a more robust solution
long-term would be to always rebuild data/prboom.wad during package build, so
that code gets exercised more often.
The prboom changes are in the Git repository but I haven't release them yet. I
need to decide whether it's worth requesting a freeze exception for the orig
tarball build issue. It's not an FTBFS but it's similar: you could not rebuild
a binary distributed in the source tarball using software only in Debian, at
least not without some workarounds.
We've had another
request to package
Prboom+. I've never been particularly
interested in doing this myself, but it would probably be very little work, you
could more-or-less take the prboom packaging as it stands. One thing I thought
would be interesting to try would be to set up a git repository for the
packaging and import the upstream Subversion repository in its entirety via
git svn, rather than just import the released tarballs. Sadly their repository
layout is not quite ideal for this.
game-data-packager continues to grow. Following hot on the heels of Hexen 2
support, Markus Koschany has written preliminary support for LGeneral, a game
which has been in Debian, at least in part, on and off. Hopefully we'll have
that merged soon, and finish of Hexen 2 support whilst we're at it. On that note,
here's a lazyweb question: what's the most convenient way to determine the length
(at microsecond resolution) of a PCM WAV file from the command-line?
Finally, we've been building Debian-based virtual machines at work, which meant
dusting off some old preseed files and tweaking them to have unattended installs.
This took a lot longer than I thought. It's certainly a lot more painful than
kickstart and Redhat-based systems, and it's very unlikely that a preseed file
that worked for one version of Debian would fully work for another. I'm not
certain but I think even different releases of d-i targetting the same release
"break" assumptions you might make, particularly about which questions you need
to answer via the kernel command line, rather than in the preseed file. That's
one thing we really need to sort. It's crazy having to specify keyboard layouts
in the command line for VMs which won't ever have a keyboard. The disparity
between what the user is asked, what value is written to the debconf database at
that point in the install process, and what ends up in the debconf database at
the end of the process is also a real pain: answering a question about keyboard
layout sets half a dozen different debconf values in a cascade that is probably
sensitive to other things like priority or whether d-i is in expert mode, too.
So working backwards from the debconf database of an installed machine is an
exercise in frustration, and figuring out which questions are asked prior to
the preseed file being read for any given d-i or Debian release is a slow trial
and error process.
I'm going to get in touch with the d-i folks and see what kind of continuous
integration systems they have in place. It would be great to have commit-level
notification that you've broken preseed builds. If not for the d-i folks, then
certainly at work.