Email: firstname.lastname@example.org • Twitter: @benhutchingsuk • Debian: benh • Gitweb: git.decadent.org.uk • Github: github.com/bwhacks
I've now spent nearly at week in Heidelberg, attending DebCamp and working on 'kernel stuff'. It's been very sunny and warm here, sometimes uncomfortably so. I've been sitting in a outdoor hacklab - covered but otherwise open to the elements. Right now it is mild and raining, and quite comfortable here.
Hot on the heels of Linux 3.2.70, I prepared another stable update for 3.2 which was announced today. I've now caught up with fixes in Linus's tree up to 4.2-rc5, though there are plenty of others still to consider.
I finally completed the scripts and configuration needed to convert the kernel team's Subversion repository to git, with most of the history of the relevant packages accurately represented. (Several packages are obsolete or had been separately moved to git.) Thanks to Subversion's flexibility with directory layout, this was quite challenging. There were a number of changes of layout in 2005-2006, tags that were copied from the wrong directory level, and merges that somehow didn't get recorded as such.
I pushed the new git repositories onto Alioth on Tuesday and disabled writes to the packaging in Subversion. So far no-one's complained about breakage, so I think I got it all right.
I've been worried for a while that I have so little ability to test for regressions in the kernel. I am mostly reliant on getting bug reports on versions in experimental and unstable to prevent these from getting to testing and stable. However this doesn't help with stable updates for security or general bug fixes.
The autopkgtest framework provides a way to (mostly) automatically test Debian packages, and I've been exploring how this can be used for the linux package. It already allows for tests that need a whole (virtual) machine to themselves and that may need to reboot the machine, so installing and running new kernel packages is fine. I don't want to have to reconfigure a boot loader, and there is no way to specify which boot loader should be used, so at least initially I'm using kexec to boot into the test kernel.
The linux source tree includes a growing number of self-test programs which roughly follow a single spec, although the requirements for some of them (kernel and machine configuration) are not all clearly documented. So far, I have most of the tests passing on 4.2-rc6 under autopkgtest, a few failures that are expected given the kernel configuration we use, and several more failures that I don't yet understand.
Once I have these self-tests integrated, I'd like to move on and add some separate test suites such as xfstests and LTP. Or I may add to the self-tests myself.
I reviewed the 2014 version of "What's new in the Linux kernel" in order to write the follow-up section at the start of this year's talk. Last year I mentioned liblockdep, a port of lockdep to userland that tests use of the pthreads locking APIs, which wasn't packaged. As this is part of the linux source tree, I probably should have worked on it myself.
To avoid embarrassment right at the start of my talk, I worked to add liblockdep binary packages to the linux-tools source package. These are now in the binary-NEW queue, headed for experimental. As lockdep is sadly lacking in documentation and liblockdep seems to be missing the ability to explicitly define lock classes, I'm not sure how useful it will be. Packaging it should make it easier for people to try out, though.
I'm about half way through writing the 2015 version of this talk, which I'm due to give on Monday afternoon. This year I think I've avoided having to spend most of the preceding day preparing it, which was why I skipped the day trip last year.