Opened 13 years ago

Closed 13 years ago

#2937 closed enhancement (fixed)

Linux-3.1

Reported by: Matthew Burgess Owned by: Matthew Burgess
Priority: normal Milestone: 7.0
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

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.

Change History (13)

comment:1 by bdubbs@…, 13 years ago

Milestone: 7.07.1

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.

comment:2 by Matthew Burgess, 13 years ago

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.

comment:3 by Gilles Espinasse, 13 years ago

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

comment:4 by Matthew Burgess, 13 years ago

Summary: Linux-3.0.6Linux-3.0.7

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.

comment:5 by ken@…, 13 years ago

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.

comment:6 by bdubbs@…, 13 years ago

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?

in reply to:  6 comment:7 by Matthew Burgess, 13 years ago

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.

comment:8 by ken@…, 13 years ago

Milestone: 7.17.0

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.

comment:9 by Matthew Burgess, 13 years ago

Summary: Linux-3.0.7Linux-3.0.8

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.

in reply to:  9 ; comment:10 by ken@…, 13 years ago

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.

in reply to:  10 comment:11 by bdubbs@…, 13 years ago

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.

comment:12 by Matthew Burgess, 13 years ago

Owner: changed from lfs-book@… to Matthew Burgess
Status: newassigned
Summary: Linux-3.0.8Linux-3.1

comment:13 by Matthew Burgess, 13 years ago

Resolution: fixed
Status: assignedclosed

Fixed in r9646.

Note: See TracTickets for help on using tickets.