Hi,
I'm announcing a new kernel tree; -as. The goal of this tree is to form
a stable base for vendors/distributors to use for their kernels. In
order to do this, I intend to include only security fixes and obvious
bugfixes, from various sources. I do not intend to include driver
updates, large subsystem fixes, cleanups, and so on. Basically, this is
what I'd want 2.6.10.1 to contain.
This first release should have been done last week, but the various
security advisories kept me pretty busy. It includes various iptables
and nfs fixes, the various security fixes announced over the past two
weeks (including the latest, CAN-2005-0001), and misc. others. My hope
is that people find this useful, so less work is duplicated by
distribution packagers. Debian kernels are basically a combination of
this tree, as well as debian-specific patches and more experimental
stuff.
The kernel patches can be grabbed from here:
http://www.acm.rpi.edu/~dilinger/patches/2.6.10/as1/
02e412361955fa80c0ea3a5a59a37c36 ChangeLog
0a75d0e8922491fb2540b3c6178dfd58 linux-2.6.10-as1.tar.gz
540effd229ea72dad4bd274bba40fb94 patch-2.6.10-as1.gz
patch-2.6.10-as1.gz is a patch against vanilla 2.6.10.
linux-2.6.10-as1.tar.gz are the patches, individually broken out.
Patches pulled from bitkeeper include their comment headers.
As mentioned, this should've been released last week; as such, it's
about a week behind bitkeeper. I shall go through the remaining 600 or
so changesets within the next few days, and release -as2.
--
Andres Salomon <[email protected]>
Andres Salomon wrote
> Hi,
>
> I'm announcing a new kernel tree; -as. The goal of this tree is to form
> a stable base for vendors/distributors to use for their kernels. In
> order to do this, I intend to include only security fixes and obvious
> bugfixes, from various sources. I do not intend to include driver
> updates, large subsystem fixes, cleanups, and so on. Basically, this is
> what I'd want 2.6.10.1 to contain.
Very nice idea! Not only for distributors! Thanks for doing this!
Do you plan to maintain -as only for the latest release, i.e., will
2.6.10-as still be maintained with security fixes even when 2.6.11-as
comes up?
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Thu, 2005-01-13 at 11:09 +0100, Frank Steiner wrote:
> Andres Salomon wrote
>
> > Hi,
> >
> > I'm announcing a new kernel tree; -as. The goal of this tree is to form
> > a stable base for vendors/distributors to use for their kernels. In
> > order to do this, I intend to include only security fixes and obvious
> > bugfixes, from various sources. I do not intend to include driver
> > updates, large subsystem fixes, cleanups, and so on. Basically, this is
> > what I'd want 2.6.10.1 to contain.
>
> Very nice idea! Not only for distributors! Thanks for doing this!
> Do you plan to maintain -as only for the latest release, i.e., will
> 2.6.10-as still be maintained with security fixes even when 2.6.11-as
> comes up?
>
My plan is to include security fixes for a kernel or two behind what is
the latest. Currently, I'm supporting (for Debian) 2.6.8 through
2.6.10. Of course, normally I wouldn't support 2.6.8 for this long, but
since sarge will (hopefully?) be releasing someday, and this is the
kernel chosen for it, I must continue support.
I do not plan to continue small bugfixes for older kernels too much
longer after a new kernel is released; however, if people were to feed
me patches for older kernels, I'd be more than happy to do releases.
--
Andres Salomon <[email protected]>
On Thu, Jan 13, 2005 at 03:37:28AM -0500, Andres Salomon wrote:
> Hi,
>
> I'm announcing a new kernel tree; -as. The goal of this tree is to form
Would be nice to have the changelog in the announcement IMO.
Phil
Andres Salomon wrote
> My plan is to include security fixes for a kernel or two behind what is
> the latest. Currently, I'm supporting (for Debian) 2.6.8 through
That would definitely help a lot. I always try to upgrade to a new major
release, but sometimes this is not easy. We have 60 hosts here and are,
for example, using Ati Radeons and nvidia Gforce cards. So when 2.6.10
came out, I couldn't just upgrade until patches came out that made
the fglrx and nv modules compile and work again.
So from time to time, there are reasons to stay with the former major
release for a while (and if it is only because one currently doesn't
have time for testing the new one) and I'm sure that I'm not the only
one with this problem. If at least one kernel behind the latest was
supplied with security fixes that would give people enough time to
test the new release without ruffle while still getting security
fixes for the former release.
> I do not plan to continue small bugfixes for older kernels too much
> longer after a new kernel is released; however, if people were to feed
> me patches for older kernels, I'd be more than happy to do releases.
I guess that for most people security fixes would already be enough,
or say, that's at least what you want in the first place...
I hope that many people make use of this tree and that is will be
included on the kernel.org page as official tree. It definitely is
a very useful tree!
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
Hi,
Andres Salomon wrote:
> I'm announcing a new kernel tree; -as. The goal of this tree is to form
> a stable base for vendors/distributors to use for their kernels. In
> order to do this, I intend to include only security fixes and obvious
> bugfixes, from various sources. I do not intend to include driver
> updates, large subsystem fixes, cleanups, and so on. Basically, this is
> what I'd want 2.6.10.1 to contain.
After all of the recent discussion it's nice to see someone step up and do this :)
Thanks a lot, I'm sure I will find it useful when producing gentoo's kernel
packages..
Just one suggestion- maybe could you distinguish security patches from
bugfixes? I.e. prepend or append the security patches with "sec" or something?
Thanks,
Daniel
On 13 Jan 2005, at 21:11, Daniel Drake wrote:
> Hi,
>
> Andres Salomon wrote:
>> I'm announcing a new kernel tree; -as. The goal of this tree is to
>> form
>> a stable base for vendors/distributors to use for their kernels. In
>> order to do this, I intend to include only security fixes and obvious
>> bugfixes, from various sources. I do not intend to include driver
>> updates, large subsystem fixes, cleanups, and so on. Basically, this
>> is
>> what I'd want 2.6.10.1 to contain.
>
> After all of the recent discussion it's nice to see someone step up
> and do this :)
> Thanks a lot, I'm sure I will find it useful when producing gentoo's
> kernel packages..
Will this release get enough exposure? I mean, will this patchset will
get published in http://www.kernel.org?
On Thu, 2005-01-13 at 20:11 +0000, Daniel Drake wrote:
> Hi,
>
> Andres Salomon wrote:
> > I'm announcing a new kernel tree; -as. The goal of this tree is to form
> > a stable base for vendors/distributors to use for their kernels. In
> > order to do this, I intend to include only security fixes and obvious
> > bugfixes, from various sources. I do not intend to include driver
> > updates, large subsystem fixes, cleanups, and so on. Basically, this is
> > what I'd want 2.6.10.1 to contain.
>
> After all of the recent discussion it's nice to see someone step up and do this :)
> Thanks a lot, I'm sure I will find it useful when producing gentoo's kernel
> packages..
>
> Just one suggestion- maybe could you distinguish security patches from
> bugfixes? I.e. prepend or append the security patches with "sec" or something?
>
I could certainly do that. Right now, I mark them w/ [SECURITY] in the
changelog.
--
Andres Salomon <[email protected]>
On Thu, 2005-01-13 at 19:48 +0100, Felipe Alfaro Solana wrote:
[...]
>
> Will this release get enough exposure? I mean, will this patchset will
> get published in http://www.kernel.org?
>
I suppose that depends whether or not I get Linus & co's official
blessing for the tree. I assume hpa is the person who would actually be
setting everything up?
--
Andres Salomon <[email protected]>
On Thu, Jan 13, 2005 at 03:37:28AM -0500, Andres Salomon wrote:
> The goal of this tree is to form a stable base for vendors/distributors
> to use for their kernels. In order to do this, I intend to include only
> security fixes and obvious bugfixes, from various sources.
Thank you very much for your effort. I'am looking forward to see your
tree as 2.6.x.y :)
By the way, I don't hink this is intentional:
killekulla@flori:~/src/kernel/test$ find linux-2.6.10 -name '*.orig'
killekulla@flori:~/src/kernel/test$ cp -rl linux-2.6.10 linux-2.6.10-as1
killekulla@flori:~/src/kernel/test$ zcat patch-2.6.10-as1.gz | patch -sp1 -d linux-2.6.10-as1
killekulla@flori:~/src/kernel/test$ find linux-2.6.10-as1/ -name '*.orig'
linux-2.6.10-as1/fs/nfs/dir.c.orig
linux-2.6.10-as1/fs/binfmt_elf.c.orig
linux-2.6.10-as1/mm/mmap.c.orig
linux-2.6.10-as1/net/sunrpc/sched.c.orig
linux-2.6.10-as1/net/sunrpc/xdr.c.orig
linux-2.6.10-as1/arch/x86_64/ia32/ia32_aout.c.orig
linux-2.6.10-as1/drivers/acpi/video.c.orig
linux-2.6.10-as1/security/dummy.c.orig
linux-2.6.10-as1/include/linux/ipv6.h.orig
linux-2.6.10-as1/include/asm-sparc64/pgtable.h.orig
On Fri, 2005-01-14 at 09:05 +0100, Raphael Zimmerer wrote:
> On Thu, Jan 13, 2005 at 03:37:28AM -0500, Andres Salomon wrote:
> > The goal of this tree is to form a stable base for vendors/distributors
> > to use for their kernels. In order to do this, I intend to include only
> > security fixes and obvious bugfixes, from various sources.
>
> Thank you very much for your effort. I'am looking forward to see your
> tree as 2.6.x.y :)
>
> By the way, I don't hink this is intentional:
>
> killekulla@flori:~/src/kernel/test$ find linux-2.6.10 -name '*.orig'
Nope; next time, i'll use patch --posix.
--
Andres Salomon <[email protected]>
9607 execve("/bin/mount", ["mount", "-o", "loop", "initrd", "/mnt/tmp/"], [/* 70 vars */]) = 0
9607 uname({sys="Linux", node="riemann", ...}) = 0
9607 brk(0) = 0x8062000
9607 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe7000
9607 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/tls/i686/mmx", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/tls/i686", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/tls/mmx", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/tls", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/i686/mmx", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/i686", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux/mmx", 0xbfffe8d0) = -1 ENOENT (No such file or directory)
9607 open("/opt/gridengine/lib/glinux/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
9607 stat64("/opt/gridengine/lib/glinux", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
9607 open("/etc/ld.so.cache", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=148993, ...}) = 0
9607 old_mmap(NULL, 148993, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fc2000
9607 close(3) = 0
9607 open("/lib/i686/libc.so.6", O_RDONLY) = 3
9607 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320]\1"..., 512) = 512
9607 fstat64(3, {st_mode=S_IFREG|0755, st_size=1461208, ...}) = 0
9607 old_mmap(NULL, 1256644, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7e8f000
9607 old_mmap(0xb7fbb000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12c000) = 0xb7fbb000
9607 old_mmap(0xb7fc0000, 7364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fc0000
9607 close(3) = 0
9607 munmap(0xb7fc2000, 148993) = 0
9607 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
9607 brk(0) = 0x8062000
9607 brk(0x8083000) = 0x8083000
9607 brk(0) = 0x8083000
9607 open("/usr/share/locale/locale.alias", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
9607 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe6000
9607 read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
9607 read(3, "", 4096) = 0
9607 close(3) = 0
9607 munmap(0xb7fe6000, 4096) = 0
9607 open("/usr/lib/locale/en_US/LC_IDENTIFICATION", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=370, ...}) = 0
9607 mmap2(NULL, 370, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe6000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_MEASUREMENT", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
9607 mmap2(NULL, 28, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe5000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_TELEPHONE", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=64, ...}) = 0
9607 mmap2(NULL, 64, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe4000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_ADDRESS", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=160, ...}) = 0
9607 mmap2(NULL, 160, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe3000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_NAME", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=82, ...}) = 0
9607 mmap2(NULL, 82, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe2000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_PAPER", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=39, ...}) = 0
9607 mmap2(NULL, 39, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe1000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_MESSAGES", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0
9607 mmap2(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe0000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_MONETARY", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=291, ...}) = 0
9607 mmap2(NULL, 291, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fdf000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0
9607 mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fde000
9607 close(3) = 0
9607 open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3
9607 fstat64(3, {st_mode=S_IFREG|0644, st_size=178468, ...}) = 0
9607 mmap2(NULL, 178468, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e63000
9607 close(3) = 0
9607 open("/dev/null", O_RDWR|O_LARGEFILE) = 3
9607 close(3) = 0
9607 getuid32() = 0
9607 geteuid32() = 0
9607 lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=2832, ...}) = 0
9607 stat64("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
9607 open("/dev/loop0", O_RDONLY|O_LARGEFILE) = 3
9607 ioctl(3, 0x4c05, 0xbfffecc0) = -1 ENXIO (No such device or address)
9607 close(3) = 0
9607 open("initrd", O_RDWR|O_LARGEFILE) = 3
9607 open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
9607 mlockall(MCL_CURRENT|MCL_FUTURE) = 0
9607 ioctl(4, 0x4c00, 0x3) = 0
9607 close(3) = 0
9607 ioctl(4, 0x4c05, 0xbfffe170) = 0
9607 ioctl(4, 0x4c04, 0xbfffed70) = 0
9607 close(4) = 0
9607 rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV], NULL, 8) = 0
9607 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
9607 +++ killed by SIGSEGV +++
Frank Steiner wrote:
> When I take an unpatched 2.6.10 and apply only the 033 patch, it fails,
> too. Is it possible that the rlimit patch needs some more patches from
> the bitkeeper repository to work correctly? And that those patches
> are missing in the -as1? Or is the patch just wrong?
>
> Can anyone confirm this problem? I attach my config for the full -as1
> tree kernel and a strace log for some segfaulting mount. Hope this helps!
I can confirm this. For me, fsck exits with sig11 during bootup sequence,
which causes my init scripts to think my root partition is dead. Investigating
now...
Daniel
On Fri, 2005-01-14 at 23:31 +0000, Daniel Drake wrote:
> Frank Steiner wrote:
> > When I take an unpatched 2.6.10 and apply only the 033 patch, it fails,
> > too. Is it possible that the rlimit patch needs some more patches from
> > the bitkeeper repository to work correctly? And that those patches
> > are missing in the -as1? Or is the patch just wrong?
> >
> > Can anyone confirm this problem? I attach my config for the full -as1
> > tree kernel and a strace log for some segfaulting mount. Hope this helps!
>
> I can confirm this. For me, fsck exits with sig11 during bootup sequence,
> which causes my init scripts to think my root partition is dead. Investigating
> now...
>
Odd. I'll have to try Frank's .config and see if I can reproduce it (it
doesn't happen w/ mine).
--
Andres Salomon <[email protected]>
Hi Andres, Frank,
Andres Salomon wrote:
>
> Odd. I'll have to try Frank's .config and see if I can reproduce it (it
> doesn't happen w/ mine).
Here is the patch that fixes it for me:
http://linux.bkbits.net:8080/linux-2.6/[email protected]
Needs to be applied alongside the rlimit and stack expansion fixes.
Andres, I have not tried the patch you suggested, since I found that the above
one fixes it. However, judging by the description of the one you mailed me, I
don't think it will make any difference (I do not use highmem).
Thanks,
Daniel
Hi Andres, hi Daniel,
sorry for the delayed reply, but I was ill for a few days.
Daniel Drake wrote
> Hi Andres, Frank,
>
> Andres Salomon wrote:
>>Odd. I'll have to try Frank's .config and see if I can reproduce it (it
>>doesn't happen w/ mine).
>
> Here is the patch that fixes it for me:
> http://linux.bkbits.net:8080/linux-2.6/[email protected]
> Needs to be applied alongside the rlimit and stack expansion fixes.
yes, this one fixes it for me, too. vgchange and "mount -o loop" work again!
I saw it was included in as2, too. I will test as2 during the next days.
>
> Andres, I have not tried the patch you suggested, since I found that the above
> one fixes it. However, judging by the description of the one you mailed me, I
> don't think it will make any difference (I do not use highmem).
The highmem patch doesn't fix it here, but anyway, I've included it
in my patchset because we use CONFIG_4G on all out SMP hosts who have
a few GB of memory.
Thanks for your help!
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Thu, Jan 13, 2005 at 03:37:28AM -0500, Andres Salomon wrote:
> Hi,
>
> I'm announcing a new kernel tree; -as. The goal of this tree is to form
> a stable base for vendors/distributors to use for their kernels. In
> order to do this, I intend to include only security fixes and obvious
> bugfixes, from various sources. I do not intend to include driver
> updates, large subsystem fixes, cleanups, and so on. Basically, this is
> what I'd want 2.6.10.1 to contain.
>
Hi!
This is good!
Is anybody doing the same for 2.4 kernel series? Only security-fixes for vanilla
2.4 kernels.. that would be nice too.
-- Pasi K?rkk?inen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
On Mon, Jan 24, 2005 at 07:10:11PM +0200, Pasi K?rkk?inen wrote:
> On Thu, Jan 13, 2005 at 03:37:28AM -0500, Andres Salomon wrote:
> > Hi,
> >
> > I'm announcing a new kernel tree; -as. The goal of this tree is to form
> > a stable base for vendors/distributors to use for their kernels. In
> > order to do this, I intend to include only security fixes and obvious
> > bugfixes, from various sources. I do not intend to include driver
> > updates, large subsystem fixes, cleanups, and so on. Basically, this is
> > what I'd want 2.6.10.1 to contain.
> >
>
> Hi!
>
> This is good!
>
> Is anybody doing the same for 2.4 kernel series? Only security-fixes for vanilla
> 2.4 kernels.. that would be nice too.
Nope, nobody has done that for v2.4 kernels.
Security fixes are included in v2.4-pre which is later shipped as v2.4.x final.
If someone is willing to maintain a list of the upcomming security updates I'm more than
happy to cooperate.