This is Simon McVittie's software development blog. Main site: pseudorandom.co.uk
Debian's latest round of angry mailing list threads have been about some combination of init systems, future direction and project governance. The details aren't particularly important here, and pretty much everything worthwhile in favour of or against each position has already been said several times, but I think this bit is important enough that it bears repeating: the reason I voted "we didn't need this General Resolution" ahead of the other options is that I hope we can continue to use our normal technical and decision-making processes to make Debian 8 the best possible OS distribution for everyone. That includes people who like systemd, people who dislike systemd, people who don't care either way and just want the OS to work, and everyone in between those extremes.
I think that works best when we do things, and least well when a lot of time and energy get diverted into talking about doing things. I've been trying to do my small part of the former by fixing some release-critical bugs so we can release Debian 8. Please join in, and remember to write good unblock requests so our hard-working release team can get through them in a finite time. I realise not everyone will agree with my idea of which bugs, which features and which combinations of packages are highest-priority; that's fine, there are plenty of bugs to go round!
Regarding init systems specifically, Debian 'jessie' currently works with at least systemd-sysv or sysvinit-core as pid 1 (probably also Upstart, but I haven't tried that) and I'm confident that Debian developers won't let either of those regress before it's released as Debian 8.
I expect the freeze for Debian 'stretch' (presumably Debian 9) to be a couple of years away, so it seems premature to say anything about what will or won't be supported there; that depends on what upstream developers do, and what Debian developers do, between now and then. What I can predict is that the components that get useful bug reports, active maintenance, thorough testing, careful review, and similar help from contributors will work better than the things that don't; so if you like a component and want it to be supported in Debian, you can help by, well, supporting it.
PS. If you want the Debian 8 installer to leave you running sysvinit as pid 1 after the first reboot, here's a suitable incantation to add to the kernel command-line in the installer's bootloader. This one certainly worked when KiBi asked for testing a few days ago:
preseed/late_command="in-target apt-get install -y sysvinit-core"
I think that corresponds to this line in a preseeding file, if you use those:
d-i preseed/late_command string in-target apt-get install -y sysvinit-core
A similar apt-get command, without the in-target prefix, should work on an installed system that already has systemd-sysv. Depending on other installed software, you might need to add systemd-shim to the command line too, but when I tried it, apt-get was able to work that out for itself.
If you use aptitude instead of apt-get, double-check what it will do before saying "yes" to this particular switchover: its heuristic for resolving conflicts seems to be rather more trigger-happy about removing packages than the one in apt-get.
Most of my recent Debian work has been the usual pkg-telepathy stuff (mainly in experimental while we're frozen), and hacking on the Quake III engine.
Having started working on OpenArena DFSG-freeness as random bug-squashing a year ago, I've accidentally ended up taking over the package. The situation for Debian 6.0 (squeeze) looks something like this:
- openarena contains both the engine (a modified ioquake3, which I modified further for Debian) and the game logic compiled to native code
- openarena-data has had the bytecode game logic stripped out, since no Free compiler can produce it; the bytecode has been replaced with stub files that direct our modified engine to load native code
The plan for Quake III in Debian 7.0 (wheezy) has already started in experimental:
- ioquake3 contains the ioquake3.org port of the Quake III engine, which I've modified to be able to run either Quake III Arena or OpenArena based on runtime options
- openarena contains the game logic compiled to native code (in experimental it still contains source code for the engine, but it's no longer patched or compiled, and I'll hopefully drop it entirely after the next upstream release), and launcher scripts to run it under the ioquake3 engine
- openarena-data is much like it is now, although it might move to data.debian.org if that happens
- quake3 (currently in the NEW queue) contains launcher scripts to run Quake III Arena under the ioquake3 engine, requiring a non-distributable quake3-data package
- game-data-packager version 23 or later can build the quake3-data package for local use, if you give it pak0.pk3 (from the CD-ROM) and the latest Quake III patch
I haven't been doing as much QA work as the RCBW crowd, but here's some halfway-recent bug squashing in the hope that it motivates others:
- alsa-lib Debian bug #589896 upstream patch backported, NMU'd and herded into testing
- atftpd Debian bug #598474 downgraded
- courier-authlib Debian bug #554788 patch submitted, uploaded
- isc-dhcp Debian bug #592361 patch submitted, uploaded by maintainer by maintainer
- mixxx Debian bug #587110 patch submitted, acked by maintainer
- tar Debian bug #602184, Debian bug #602209 upstream patches NMU'd
- witty Debian bug #591209 patch submitted, although it doesn't list copyright holders so probably isn't suitable for upload
I also started looking at the series of bugs regarding Flash not compiled from source, but I mostly got distracted by all the webapps having a contrib/ directory containing a million embedded code copies...
gfcombinefs is a side project I did some work on a few weeks ago. It
combines several "shares" of a secret file previously split using Shamir
secret sharing, to produce the original secret, and presents it as a file in
a FUSE filesystem. It uses libgfshare for the actual mathematics, and
expects its input to have been split with the
gfsplit tool shipped with
At this stage of development, I suggest not trusting it with important data, like the GnuPG secret keyrings it's designed for. However, I hope that with some feedback from others I can get it into a state where it's ready to be released and packaged (perhaps I'm being unnecessarily conservative, but for something that deals with GnuPG keys, it seems wise to be careful).
Source code is available in a git repository, and I'd welcome contributions, bug reports (other than the limitations that are already listed in the documentation) and in particular, a systematic code audit from someone (the good news is that there isn't very much code, so that shouldn't actually take long).
More release critical bug squashing of the "week" (fortnight, really):
- openarena-data Debian bug #523323 + patch (the necessary changes in openarena are extensive, so I don't plan to NMU this unless there's no response for a long time)
- fuse Debian bug #550334, Debian bug #553015, Debian bug #557143
Removals from testing and proposed removals from unstable:
- alien-arena Debian bug #559725 (removal from testing only)
- commit-tool Debian bug #558592 (removal from testing only)
- gadfly Debian bug #559375
- gaim-otr Debian bug #552761 (transitional package)
- levee Debian bug #558604
- libroxen-adbanner Debian bug #559251
- libroxen-diary Debian bug #559250
- libroxen-imho Debian bug #559249 (removed from archive)
- libroxen-tokenfs Debian bug #559248
- mailreader Debian bug #559252
- openc++ Debian bug #559111
- overkill Debian bug #558669
- p3nfs Debian bug #559105
- portslave Debian bug #559254
- skyutils2 Debian bug #558605 (removed from archive)
- whirlpool Debian bug #559255
- ziproxy Debian bug #559627
Possible candidates for removal:
- bfm (unmaintained upstream since 2004, declining popcon score)
Other drive-by QA:
- tse3 Debian bug #524726 marked as done (by a binNMU)
- joy2key Debian bug #554521 downgraded to important
- nvidia-graphics-drivers Debian bug #525414 noted as probably fixed, submitter/maintainer pinged for confirmation
- Bugs filed about the packages keeping zope3 around in testing: Debian bug #558204, Debian bug #558205
- mail-notification-evolution Debian bug #559106 upgraded to serious
Monday: potential candidates for removal:
In general I've been trying to avoid resurrecting packages that I don't think should be in the archive, even if the fix is trivial. I'm not sure whether that applies to spider; according to popcon, it still has a substantial number of users, so it may be worth keeping even if there are no upstream releases (also, it amused me to convert such an old package to Debhelper 7 and dpkg source format v3).
In the process I've discovered that git-buildpackage makes a great NMU tool. I'll probably be putting all future NMU diffs in my users/smcv directory on git.debian.org (at least until the maintainer acknowledges or rejects the NMU), just because it's a convenient way to give the maintainer a nice queue of individual changes rather than a monolithic diff; if any maintainers decide they'll use git as a result, that's a bonus :-)
This blog is powered by ikiwiki.