Linux 2.6.24.3

[Joe Ciccone]

New Release

[William Harrington]

Replying to jciccone:

New Release

I built my latest svn with linux-2.6.24.3. Linux-2.6.24.3 included if_addrlabel.h into the headers target but forgot the header itself. Look at this for more info:

​http://lkml.org/lkml/2008/2/25/529

Here is the patch:

diff --git a/include/linux/if_addrlabel.h b/include/linux/if_addrlabel.h new file mode 100644 index 0000000..9fe79c9 --- /dev/null +++ b/include/linux/if_addrlabel.h @@ -0,0 +1,32 @@ +/* + * if_addrlabel.h - netlink interface for address labels + * + * Copyright (C)2007 USAGI/WIDE Project, All Rights Reserved. + * + * Authors: + * YOSHIFUJI Hideaki @ USAGI/WIDE <yoshfuji@…> + */ + +#ifndef LINUX_IF_ADDRLABEL_H +#define LINUX_IF_ADDRLABEL_H + +struct ifaddrlblmsg +{ + u8 ifal_family; /* Address family */ + u8 ifal_reserved; /* Reserved */ + u8 ifal_prefixlen; /* Prefix length */ + u8 ifal_flags; /* Flags */ + u32 ifal_index; /* Link index */ + u32 ifal_seq; /* sequence number */ +}; + +enum +{ + IFAL_ADDRESS = 1, + IFAL_LABEL = 2, + IFAL_MAX +}; + +#define IFAL_MAX (IFAL_MAX - 1) + +#endif

If one uses the headers, checking the headers will error cause the header is not included. Mistake by kernel devs.

[William Harrington]

Update on using 2.6.24.3 headers for a build.

Do not use these headers for a build. Animeloe and I both had issues when using these headers and continuing into CBLFS.

Most common error to be seen when using these headers:

error: expected '=', ',', ';', 'asm' or 'attribute' before <anythinghere>

If someone decides to build with 2.6.24.3 headers and is successful through cblfs, let us know. Maybe we actually screwed something up.

Also if_addrlable.h is for 2.6.25 kernel, I don't suggest using the patch for 2.6.24.3 and removing the if_addrlable.h target from the Makefile.

I suggest not using these kernel headers any time soon till it is figured out exactly where the problem is. So far 2.6.24.2 headers are working fine for me.

[ken]

Replying to kb0iic:

Update on using 2.6.24.3 headers for a build.

Do not use these headers for a build. Animeloe and I both had issues when using these headers and continuing into CBLFS.

Most common error to be seen when using these headers:

error: expected '=', ',', ';', 'asm' or 'attribute' before <anythinghere>

If someone decides to build with 2.6.24.3 headers and is successful through cblfs, let us know. Maybe we actually screwed something up.

I wouldn't dream of using 2.6.24.3 (nothing obviously-relevant to me since 2.6.24.2, and I've got plenty of other things to do rather than patch the immediate problem in headers_check). But, 2.6.24.4 is due out very soon - do you have examples of which packages failed, so that *somebody* can test ? Also, if it is still a problem in 2.6.24.4 that should help us assess the extent of the damage - one or two uncommon packages implies they should be patched (I've seen this in the past for e.g. strace), general breakage of common packages implies the kernel itself maybe needs to be fixed before 2.6.25, or at least made aware there are issues.

Your example looks very like what happens if a header is missing. I'm not saying you made a mistake, perhaps these packages were expecting something which has now disappeared.

[William Harrington]

Okay heads up on users using 2.6.24+ linux kernel headers:

proftpd-1.3.1 needs a fix regarding umode_t in types.h. Here is the link to reference for now:

​http://www.redhat.com/archives/fedora-extras-commits/2007-December/msg04594.html

Is this good to keep anything related to 2.6.24 headers in this ticket?

[William Harrington]

Ken,

A list of packages, no, but I suspect it has to do with configure scripts not autodetecting types properly with the new headers. For example, with proftpd, it is assuming that umode_t doesn't exist and ends up just using mode_t. I'll check to see how 2.6.24.4 fairs in the future when released. I'm wondering if a lot of package maintainers are going to have to update their configure scripts for new headers? I'm not an expert on how all this works, but someone out there has some more knowledge.

William

[David B]

I am doing testing for 2.6.24.4 under sparc 64 pure. I hope they have fixed the issues. I will post back when my build is done......

[William Harrington]

2.6.24.4 has worked well with the ppc64 mulitlib build.

I think 2.6.24.4 looks promising. Maybe 2.6.25 will be a good target.

Who the heck knows with these kernel devs!

[William Harrington]

Replying to kb0iic:

2.6.24.4 has worked well with the ppc64 mulitlib build.

I think 2.6.24.4 looks promising. Maybe 2.6.25 will be a good target.

Who the heck knows with these kernel devs!

Built ppc64 twice and haven't had an issue with these headers, even going through cblfs. This ticket should be closed. This isn't about 2.6.24.3 anymore. 2.6.24.3 wasn't a nice release and should not be touched anymore. It should burn in the depths of hell.

[laxy]

I finished X86_64 pure64 CLFS some days ago with 2.6.24.4, and haven't had any trouble in CBLFS.

[William Harrington]

There are confirmed cases with PPC64, SPARC64, x86_64 and CBLFS with the previous arches with no issues as were found with 2.6.24.3 in builds. I'm resolving this. 2.6.24.4 is good for me and those who have posted in this ticket. When 2.6.24.5 is released we can test that. For now, I suggest we stick with 2.6.24.4 and not 2.6.24.3. The book is still at 2.6.24. I recommend this kernel as if_addrlable.h issue has been reverted and major patches to headers have been applied. Please read ​http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24.4 for more info. If something does not work in the future, please start a new ticket or bring it to the team's attention and we'll start a ticket. Do not use 2.6.24.3! -End of transmission-