This is Simon McVittie's software development blog. Main site: pseudorandom.co.uk

still aiming to be the universal operating system

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.

Posted
Debian activities

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:

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...

Announcing gfcombinefs

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 libgfshare.

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).

Posted
RC Bugs of W48-W49

More release critical bug squashing of the "week" (fortnight, really):

Removals from testing and proposed removals from unstable:

Possible candidates for removal:

  • bfm (unmaintained upstream since 2004, declining popcon score)

Other drive-by QA:

RC Bugs of W47

I've been intermittently prodding at the Debian release-critical bug list for some time, but inspired by Zack and Tim I've decided to start keeping track, if only for my own interest.

  • Monday: openipmi Debian bug #474087 + patch (not uploaded since I have no way to test IPMI libraries, not having the appropriate hardware...)

  • Monday: potential candidates for removal:

    • skyutils (RC bug, library with no reverse dependencies since smssend was removed in 2008)
    • libhid (RC bug, RFA since August 2008, mainly exists to support libphidgets)
    • libphidgets (RC bug, RFA since 2007)
    • libnoise (RC bug, library with no reverse dependencies or popcon votes)
  • Thursday: hercules Debian bug #553110 uploaded to DELAYED/7, with various bonus changes including making the copyright file sufficient to satisfy Policy §12.5

  • Friday: spider Debian bug #537631 fixed by a QA upload, fast-forwarding through 8 years of Debian policy and upgrading from debhelper 3 (!) to 7 in the process

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 :-)

Older posts:

telepathy-qt4 0.2.0: first shared library release
Posted
DSpam and how not to do it
Posted
Converting Debian packaging from bzr to git
Posted
Why you shouldn't block on D-Bus calls
Posted
Encrypted root filesystem on a Debian laptop
Posted
Compiling against uninstalled versions of libraries
Posted
Integrating Enemies of Carlotta with Postfix
Posted
Speeding up builds with ccache and icecc
Posted
Spec-writing On A Plane
Posted
\o/
Posted
Implementing D-Bus services with telepathy-glib
Posted
Here's how it works
Posted
A magical xrandr incantation
Posted

This blog is powered by ikiwiki.