I'm trying to emerge ipsec-tools-0.7.1 and it fails because it can't find asm/swab.h even though asm/swab.h exists Reproducible: Always Steps to Reproduce: 1. emerge ipsec-tools Actual Results: Fails, can not find asm/swab.h Expected Results: Should compile with no errors I'm trying to emerge ipsec-tools-0.7.1 and it fails because it can't find asm/swab.h i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I./../libipsec -D_GNU_SOURCE -include ./src/include-glibc/glibc-bugs.h -I./src/include-glibc -I./src/include-glibc -I./../../src/racoon/missing -D_GNU_SOURCE -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -DSYSCONFDIR=\"/etc\" -DADMINPORTDIR=\"/var/lib/racoon\" -O2 -march=pentium3 -pipe -Wall -Wno-unused -MT isakmp.o -MD -MP -MF .deps/isakmp.Tpo -c -o isakmp.o isakmp.c In file included from ../../src/include-glibc/linux/byteorder/little_endian.h:12, from /usr/include/asm/byteorder.h:79, from ../../src/include-glibc/linux/ip.h:20, from isakmp.c:115: ../../src/include-glibc/linux/swab.h:6:22: error: asm/swab.h: No such file or directory make[4]: *** [isakmp.o] Error 1 I have the following files and earlier versions of ipsec-tools emerged OK. /usr/src/linux-2.6.29/arch/parisc/include/asm/swab.h /usr/src/linux-2.6.29/arch/cris/include/asm/swab.h /usr/src/linux-2.6.29/arch/cris/include/arch-v32/arch/swab.h /usr/src/linux-2.6.29/arch/cris/include/arch-v10/arch/swab.h /usr/src/linux-2.6.29/arch/sparc/include/asm/swab.h /usr/src/linux-2.6.29/arch/h8300/include/asm/swab.h /usr/src/linux-2.6.29/arch/s390/include/asm/swab.h /usr/src/linux-2.6.29/arch/m68k/include/asm/swab.h /usr/src/linux-2.6.29/arch/x86/include/asm/swab.h /usr/src/linux-2.6.29/arch/xtensa/include/asm/swab.h /usr/src/linux-2.6.29/arch/powerpc/include/asm/swab.h /usr/src/linux-2.6.29/arch/sh/include/asm/swab.h /usr/src/linux-2.6.29/arch/arm/include/asm/swab.h /usr/src/linux-2.6.29/arch/blackfin/include/asm/swab.h /usr/src/linux-2.6.29/arch/mips/include/asm/swab.h /usr/src/linux-2.6.29/arch/avr32/include/asm/swab.h /usr/src/linux-2.6.29/arch/alpha/include/asm/swab.h /usr/src/linux-2.6.29/arch/ia64/include/asm/swab.h /usr/src/linux-2.6.29/fs/ufs/swab.h /usr/src/linux-2.6.29/include/asm-mn10300/swab.h /usr/src/linux-2.6.29/include/asm-m32r/swab.h /usr/src/linux-2.6.29/include/linux/swab.h /usr/src/linux-2.6.29/include/asm-frv/swab.h I'm running vanilla-kernel 2.6.29 with server profile.
I have only problems *re*-merging ipsec-tools-0.7.1. I just upgraded gcc and glibc, maybe that is related?!
(In reply to comment #1) > I have only problems *re*-merging ipsec-tools-0.7.1. > I just upgraded gcc and glibc, maybe that is related?! nyx ~ # readlink /var/tmp/portage/net-firewall/ipsec-tools-0.7.1/work/ipsec-tools-0.7.1/src/include-glibc/linux /usr/src/linux/include/linux nyx ~ # So the error comes from /usr/src/linux/include/linux/swab.h (#include <asm/swab.h>). On my x86_64 system, /usr/src/linux/include/asm is a symlink to asm-x86 which in turn does not contain swab.h. The only asm-* subdirectories below /usr/src/linux/include that contain swab.h are asm-frv, asm-m32r and asm-mn10300. I tried touching /usr/src/linux/include/asm/swab.h, but it's not being used. What actually helped was "touch /usr/include/asm/swab.h". Ok, I've investigaged further. Kernel 2.6.28 had '#include <asm/byteorder.h>' in /usr/src/linux/include/linux/swab.h whereas 2.6.29 has '#include <asm/swab.h>'. So it's specific to 2.6.29 and looks like a bug in the kernel sources, no?
Yes, you're right. I have the same directories on my x86 box. So this is a Kernel bug and not Gentoo. I will close this. Thanks Slava
Is this really fixed upstream? It doesn't seem to be..
This is NOT a kernel bug. This is an ipsec-tools bug, please reopen. The include/asm-<arch> files have moved to arch/<arch>/include/asm, so ipsec-tools should be fixed accordingly.
Reopening as requested
The question then becomes... Is this a case of ipsec-tools using kernel headers in a wrong way or kernel headers being wrong? Daniel, CCing you since you seem to have an interest in this package.
The kernel header changes are clearly intentional, as can be seen by searching LKML for this subject.
(In reply to comment #7) > The question then becomes... Is this a case of ipsec-tools using kernel headers > in a wrong way or kernel headers being wrong? ipsec-tools is wrong as per #8. kernel headers change often and really don't care what it breaks as only are small subset are ment to be used. It should be possible to work around with a few ifdef's based on kernel version. > Daniel, CCing you since you seem to have an interest in this package. I never wanted to give that impression. sorry.
This happens only if sys-kernel/gentoo-sources and sys-kernel/linux-headers have different versions, make sure the have both the same version. So for example use both from ~x86 or both from stable but do not mix them. having both in ~x86 solves the problem for me.
(In reply to comment #10) > This happens only if sys-kernel/gentoo-sources and sys-kernel/linux-headers > have different versions, I ran into this problem with ipsec-tools-0.7.2. Updating sys-kernel/linux-headers to match kernel version fixed the problem for me. I've never really paid much attention to linux-headers. This is the first problem I've encountered with version mismatch. As a matter of curiosity, would it be possible to have gentoo-sources depend on a matching linux-headers? Or would this cause similar problems until you actually configured the new kernel? As it is, I'll make sure to add updating linux-headers and rebuilding sys-libs/glibc (to take advantage of the new headers) to my checklist for upgrading the kernel.
I am using both headers and kernel from the stable tree: sys-kernel/linux-headers-2.6.27-r2 sys-kernel/gentoo-sources-2.6.30-r6 it fails to build with the same error. Are you saying that I should be updating the headers to version 2.6.30-r1 which is the latest unstable on the tree? Given that this is the first time it happened to me it doesn't sound right. -- Regards, Mick
Yes, stable linux-headers has been at 2.6.27 for some time now but many subsequent gentoo-sources releases have gone stable in the meantime. "Keep them in sync." isn't practical unless they release in sync. (Grumble, grumble, only had to rebuild ipsec-tools because it's the last package depending on superseded libreadline.so.5....)
Shouldn't >=net-firewall/ipsec-tools-0.7.1 be masked until it can safely merge with what is stable in portage? I just installed ipsec-tools-0.7.2 and the problem persists.
*** Bug 290905 has been marked as a duplicate of this bug. ***
*** Bug 282752 has been marked as a duplicate of this bug. ***
*** Bug 264388 has been marked as a duplicate of this bug. ***
Why net-firewall/ipsec-tools-0.7.2 have been masked instead of making it depend on an appropriate version of linux-headers? Now I get en error while doing "emerge -uDNavt world": !!! The following installed packages are masked: - net-firewall/ipsec-tools-0.7.2 (masked by: package.mask) /usr/portage/profiles/package.mask: # Víctor Ostorga <vostorga@gentoo.org> (02 Nov 2009) # If you use a kernel >= 2.6.29 it is needed >=linux-headers-2.6.29 # as well, otherwise net-firewall/ipsec-tools won't compile. # See bug #264233 for reference Which is completely pointless since I already, no matter how (I have installed linux-headers-2.6.30), have managed to install ipsec-tools. I assume it requires a revision bump to change dependencies. OK, then mask 0.7.2 and release 0.7.2-r1 with proper dependencies. Everyone who have new enough kernel headers won't see any problem and no one who haven't got new kernel headers shouldn't have been able to install 0.7.2. Have I missed something? PS. emerge world does not want to do *anything* with my ipsec-tools, so why errors?
(In reply to comment #18) > Why net-firewall/ipsec-tools-0.7.2 have been masked instead of making it depend > on an appropriate version of linux-headers? Now I get en error while doing > "emerge -uDNavt world": > > !!! The following installed packages are masked: > - net-firewall/ipsec-tools-0.7.2 (masked by: package.mask) > /usr/portage/profiles/package.mask: > # Víctor Ostorga <vostorga@gentoo.org> (02 Nov 2009) > # If you use a kernel >= 2.6.29 it is needed >=linux-headers-2.6.29 > # as well, otherwise net-firewall/ipsec-tools won't compile. > # See bug #264233 for reference > > Which is completely pointless since I already, no matter how (I have installed > linux-headers-2.6.30), have managed to install ipsec-tools. > > I assume it requires a revision bump to change dependencies. OK, then mask > 0.7.2 and release 0.7.2-r1 with proper dependencies. Everyone who have new > enough kernel headers won't see any problem and no one who haven't got new > kernel headers shouldn't have been able to install 0.7.2. > > Have I missed something? > Short history, ipsec-tools will build if kernel headers and kernel sources match. Long history if you have a working kernel >= 2.6.29 and linux-headers <= 2.6.29 it won't build because of mismatching headers. If you want to avoid the message just play with package.unmask as stated in man portage
fix to one build 1. unmask /etc/portage/package.keywords =net-firewall/ipsec-tools-0.7.3 ~x86 2. start emerge -v ipsec-tools-0.7.3 2.1 if unpack source ipsec-tools - [ok] then goto step3 in other terminal 3. dir /var/tmp/portage/net-firewall/ipsec-tools-0.7.3/work/ipsec-tools-0.7.3/src/include-glibc/asm 4. cp /usr/src/linux-2.6.30-gentoo-r8/arch/x86/include/asm/swab.h /var/tmp/portage/net-firewall/ipsec-tools-0.7.3/work/ipsec-tools-0.7.3/src/include-glibc/asm
3. mkdir /var/tmp/portage/net-firewall/ipsec-tools-0.7.3/work/ipsec-tools-0.7.3/src/include-glibc/asm (In reply to comment #20) > fix to one build > 1. unmask /etc/portage/package.keywords > =net-firewall/ipsec-tools-0.7.3 ~x86 > 2. start emerge -v ipsec-tools-0.7.3 > 2.1 if unpack source ipsec-tools - [ok] then goto step3 in other terminal > 3. dir > /var/tmp/portage/net-firewall/ipsec-tools-0.7.3/work/ipsec-tools-0.7.3/src/include-glibc/asm > 4. cp /usr/src/linux-2.6.30-gentoo-r8/arch/x86/include/asm/swab.h > /var/tmp/portage/net-firewall/ipsec-tools-0.7.3/work/ipsec-tools-0.7.3/src/include-glibc/asm
(In reply to comment #10) > This happens only if sys-kernel/gentoo-sources and sys-kernel/linux-headers > have different versions, make sure the have both the same version. So for > example use both from ~x86 or both from stable but do not mix them. > > having both in ~x86 solves the problem for me. > Ok dumb question why wouldn't sys-kernel/gentoo-sources and sys-kernel/linux-headers be in sync with each other? Right now headers is 2.6.30-r1 in unstable yet kernel 2.6.31 is stable? I don't like to install unstable stuff. Why would I have to merge an unstable headers to match my stable kernel?
fixed in 0.7.3-r1 as part of linux-info cleanup.
