Linux-3.1

[Matthew Burgess]

New version. Release announcement at ​http://lkml.indiana.edu/hypermail/linux/kernel/1110.0/00886.html. The homepage at ​http://www.kernel.org is now back up, but tarballs don't appear to be available quite yet.

[bdubbs@…]

Moving to 7.1 because we can't find it on kernel.org. If it shows up between lfs-7.0-rc2 and the final release, we can change it back.

[Matthew Burgess]

Note that 3.0.7 will be out within the next couple of days (see the call for review at ​http://lkml.indiana.edu/hypermail/linux/kernel/1110.1/01049.html). The 3.0.4 tar.bz2 file has also made its way back on to kernel.org, so things look as if they're starting to get back to normal.

[Gilles Espinasse]

There is too the long awaited .xz package version for the kernel and module-init-tools

[Matthew Burgess]

Now 3.0.7. Release announcement at ​http://lkml.indiana.edu/hypermail/linux/kernel/1110.2/00437.html. It looks as if there isn't going to be a released tarball, and users are advised to pull from git. We could make our own tarball from such a pull, but I'm wary of doing that in case folks somehow mistake it for an 'official' kernel.

[ken@…]

I was going to say that, in this case (the kernel.org pwning), we should roll our own and note how we got it. I was even going to offer an md5sum and sha1sum from my own attempt to tar it up. Unfortunately, I can't clone it

ken@milliways /data/git $git clone git://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git
Initialized empty Git repository in /data/git/linux-stable/.git/
fatal: The remote end hung up unexpectedly

There *is* also a place to download it - ​http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary then navigate to the v3.0.7 tag and then in that select the "snapshot" option.

Unfortunately, this gives .tar.gz - linux-stable-62bf792.tar.gz so it's an unnecessarily large [ 93.0 MB, according to firefox] download (again, my first attempt to download it hung up, so I guess kernel.org is busy). As you would expect, it creates linux-stable-62bf792 which might baffle the occasional user, but the Makefile is, of course, set for 3.0.7

ken@bluesbreaker ~ $md5sum /sources/linux-stable-62bf792.tar.gz
9c3e4d3c3360bb0d8d5cbc2918fe6600  /sources/linux-stable-62bf792.tar.gz
ken@bluesbreaker ~ $sha1sum /sources/linux-stable-62bf792.tar.gz
c7533e30f585eb0998c13fd62f64b149a7589a70  /sources/linux-stable-62bf792.tar.gz

Whatever we do, we *ought* to be using current -stable, but not forcing our users to have git installed.

[bdubbs@…]

For now, I think we should leave the kernel at 3.0.4 unless there is something critical. Hopefully by the time we get to 3.1, the tarballs will be back. Does anyone want to ask on lkml?

[Matthew Burgess]

Replying to bdubbs@…:

For now, I think we should leave the kernel at 3.0.4 unless there is something critical. Hopefully by the time we get to 3.1, the tarballs will be back. Does anyone want to ask on lkml?

I rather think asking on lkml will result in "it'll be ready when it's ready" response. Greg KH responded at ​http://lwn.net/Articles/463358/ saying that they're still working on the upload machinery. There's also a comment on that page saying that a patch from 3.0.4 to 3.0.7 is available via git at ​https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff_plain;h=v3.0.7;hp=v3.0.4.

Given the nature of the patches that go into the stable tree, I'd be more comfortable having this in the book than not, and leaving our users exposed to potential security vulnerabilities.

[ken@…]

Per ​http://www.gossamer-threads.com/lists/linux/kernel/1445460 all three versions of both the kernel tarball and the patch (.bz2, .gz, .xz) are now at kernel.org. So, resetting to 7.0.

For post-7.0, I think we should consider using the xz version to minimise bandwidth.

[Matthew Burgess]

Now 3.0.8. Release announcement at ​http://lkml.indiana.edu/hypermail/linux/kernel/1110.3/00459.html. I don't see why we can't move to the xz version now; Coreutils-8.14 only has an xz version.

[ken@…]

Replying to matthew@…:

Now 3.0.8. Release announcement at ​http://lkml.indiana.edu/hypermail/linux/kernel/1110.3/00459.html. I don't see why we can't move to the xz version now; Coreutils-8.14 only has an xz version.

It means that the *host* system needs xz-utils *and* a recent enough version of tar to find it (from my notes, tar-1.20 was not new enough, but 1.23 was able to find and use xz - or, perhaps I mistook that for "xz must exist when tar is compiled"). This only really matters for the chapter 5 headers at the moment, but it will be another nail in the coffin for anyone trying to use the LFS live CD, I guess. Alternatively, we add an optional "build xz-utils into /tools, and linked to the host, if your host cannot otherwise extract .xz files", before pass 1 binutils, and, for anyone doing that on e.g. older LFS systems, mention that they will need to use something like xzcat $tarball.xz | tar -xv.

[bdubbs@…]

Replying to ken@…:

It means that the *host* system needs xz-utils *and* a recent enough version of tar to find it (from my notes, tar-1.20 was not new enough, but 1.23 was able to find and use xz - or, perhaps I mistook that for "xz must exist when tar is compiled").

The system requirements say tar-1.18 and xz-5.0.3. I don't know if tar-1.18 picks up xz or not. We may need to update the host requirements for tar.

tar-1.18 was released in June 2007. tar-1.23 in March 2010. That's getting pretty recent.

[Matthew Burgess]

Linux-3.1 release announcement at ​http://lkml.indiana.edu/hypermail/linux/kernel/1110.3/00210.html.

[Matthew Burgess]

Fixed in r9646.