November 14, 2011
On most servers I’m responsible for, I use to compile my own kernels. Instead of downloading/applying patches, which is cumbersome, I was using the (now broken) mercurial mirror http://www.kernel.org/hg/linux-2.6
It was great as i just had to do something like “hg pull -u; hg up -r v2.6.xx” to update my tree.
Though, this has several drawbacks, and among them some very important:
* the minor versions are not there, such as 2.6.xx.y
* the repository cloning is worth 2.1G, not including the checkout
* you need to specify the tag to get a stable kernel
* the repository contains all intermediate versions, which slows down updating both from network and local checkout.
The first point is the one what bothers me the more. For example at some given date, say the 2.6.39 is not yet released, the last version available in the hg mirror is 2.6.38, although 188.8.131.52 is available. So I still need to manually patch my checkout because I think 6 minor stable versions are worth having.
My solution to this is a script that I’ve called by the pretty name of eudyptula (this is a very small penguin..). Eudyptula automatically (using cron) updates a mercurial repository to the latest ‘stable’ version of the linux kernel, according to what is found on the official ftp server. The result is here:
The repository clone weights only 220M (excluding the checkout, on my ext4 partition), and contains only one changeset for each update from a stable version to the next. ‘hg pull -u’ is enough to get the latest stable source. Hence the name.
A typical history will look like
and will drop any 2.6.38.x release that could appear after 2.6.39 is released.
As a convenience, I’m also tagging versions the same way they are tagged in the official git/mercurial repositories (‘v184.108.40.206″ for example).
Of course, it does NOT makes sense to use this repository if you intend to do kernel development. It is supposed to be used readonly.
This is a long term project. As of today (november 14th, 2011), I’ve been using this for updating ~10 servers for the last 9 months. I intend to maintain this clone for long, checking and fixing problems if they ever occur.
If there’s enough interest, I could do another mirror for the long-term support versions. Though those versions, officially created and maintained by kernel developers, are not as formally described, and this is more difficult to do from a cron job.