During 'emerge -pU world' after introduction of ...20040619, I get the following errors: Calculating world dependencies \ !!! all ebuilds that could satisfy "=sys-kernel/linux-headers-2.6*" have been masked. !!! possible candidates are: - sys-kernel/linux-headers-2.6.6 (masked by: -* keyword) - sys-kernel/linux-headers-2.6.7 (masked by: -* keyword) - sys-kernel/linux-headers-2.6.1 (masked by: -* keyword) - sys-kernel/linux-headers-2.6.3-r1 (masked by: -* keyword) - sys-kernel/linux-headers-2.6.4 (masked by: -* keyword) - sys-kernel/linux-headers-2.6.5 (masked by: -* keyword) !!! (dependency required by "sys-libs/glibc-2.3.4.20040619" [ebuild]) !!! Problem with ebuild sys-libs/glibc-2.3.4.20040619 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. Note that /etc/portage/package.unmask contains: =sys-kernel/linux-headers-2.6.4 and sys-kernel/linux-headers-2.6.4 is installed Renaming sys-libs/glibc-2.3.4.20040619 to old-sys-libs/glibc-2.3.4.20040619 is a workaround. Reproducible: Always Steps to Reproduce: 1. emerge sync on June 20 2. insure that package sys-libs/glibc-2.3.4.20040619 exists 3. insure that sys-kernel/linux-headers-2.6.N is emerged 4. insure that /etc/portage/package.unmask contains =sys-kernel/linux-headers-2.6.N 5. emerge -pU world Actual Results: Errors as above - emerge fails Expected Results: list of packages to be emerged, ex. without sys-libs/glibc-2.3.4.20040619 [ebuild U ] net-www/mplayerplug-in-2.66 [2.60] [ebuild U ] sys-libs/db-4.1.25_p1-r4 [4.1.25_p1-r3] [ebuild U ] sys-devel/gcc-config-1.3.6 [1.3.5-r1] [ebuild U ] net-www/mozilla-launcher-1.15 [1.14] [ebuild U ] sys-libs/ncurses-5.4-r2 [5.4-r1] [ebuild U ] net-www/mozilla-firefox-bin-0.9-r1 [0.8-r1] Gentoo Base System version 1.4.16 Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7 -rc3) ================================================================= System uname: 2.6.7-rc3 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2 /share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linu x/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa apache2 apm avi berkdb cdr crypt cups dvdr encode esd foomaticd b gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde libg++ libwww mad mikmod motif mozilla mpeg mysql ncurses nls nptl oggvorbis opengl oss pam pdflib perl png postgres ppds python qt quicktime readline samba scanner sdl slang spell ssl svga tcltk tcpd tiff truetype usb x86 xml2 xmms xv zlib"
More simply put, sys-libs/glibc-2.3.4.20040619 depends on =sys-kernel/linux-headers-2.6*, but all such ebuilds are individually masked off.
Yes, and even more simply put, masking is turned off in /etc/portage/package.unmask for =sys-kernel/linux-headers-2.6.4 which is installed and which should resolve the dependancy as is the case for earlier sys-libs/glibc-2.3.4... ebuilds.
/etc/portage/package.unmask will only unmask packages that are masked in $PORTDIR/profiles/package.mask. The linux-headers-2.6.4 ebuild has KEYWORDS="-*". What you need to do is copy the ebuild to your overlay and then change the KEYWORDS according to your architecture.
However, the glibc version you are talking about is not masked which is wrong. Either it should be or a corresponding linux-headers shouldn't be.
*** Bug 54604 has been marked as a duplicate of this bug. ***
I've put this version into package.mask until we can sort out: 1. whether it's a good idea to have 2.6 headers emergable 2. whether to unmask those 2.6 headers into ~arch
this ebuild shouldnt have been keyworded and the nptl logic changed. the ebuild depends on 2.6 linux-headers if using nptl... no need to check header version or muck up the logic unless the problem has been fixed upstream and glibc compiles now with vanilla kernel headers. (even iptables doesnt compile against vanilla kernel 2.6.7 anymore) i added the dependency because i kept seeing new open bugs about glibc+nptl not compiling with the 2.6 source in /usr/src/linux. this dependency should be removed or the nptl logic reverted to be what's present in the 20040605 snapshot ebuild and linux-headers 2.6.6 keyworded ~x86. 2.6.6 is known to work with userspace apps on amd64 and ppc64, i'm unsure about x86 but since plasmaroo fixed them i would assume they would work there as well. the 2.6.7 headers i think are still a work in progress? linux-headers 2.6.6 is marked stable on amd64 and arm. *shrug* test merging sash, sysklogd, and ext2resize with them on x86.
Note: sash-3.7, sysklogd-1.4.1-r10, and ext2resize-1.1.17-r2 emerge just fine on my ~x86 system with linux-headers-2.6.4. And, of course. no problems with glibc-2.3.3.20040420.
Ok, I missed the DEPEND to be honest. As for the logic - its pretty much still the same (meaning it will only check in /usr/include for headers), I just added 2 tests to verify that what we work with is what we expect, and also that we build on a 2.6 kernel, as building on non supporting kernel will also fail. This limit is set to 2.6.5, which is IMHO a fair version to expect. Please check again, I _did_ not depend on 2.6.7 headers ... So fix for now, just mask it again (As Seemant has done, thanks!). For the header issue - it might be a good idea to ~x86/whatever them, and just put them in package.mask, so that you can put whatever in package.unmask.
i didnt mean to imply that you changed the dep to 2.6.7, just that they're a work in progress as far as i know. that and a pain in the butt, even iptables wont compile against vanilla 2.6.7 :(
yeah, stop bad mouthing linux-headers-2.6 lv ... the sash bug was fixed with at least 2.6.6 and sysklogd/ext2resize were fixed before that iptables not compiling doesnt seem to be the headers fault but rather they're using /usr/src/linux instead of /usr/include/linux if things break on amd64, then file bugs to get them fixed, dont say '2.6 headers dont work' they're marked stable on arm because 2.4 arm support doesnt exist in the tree ... there's no plans to maintain it upstream so why should we :)
errr... spanky, i marked 2.6.6 linux-headers stable on amd64. i know they work. ;p i'm also sure that vanilla 2.6.7 has issues galore. :( plasmaroo could probably explain whether or not these issues are fixed better than i. note: add iproute2 to that application list, this wouldnt merge with 2.6.6 headers until the problem was fixed in 2.6.6-r1. i dont think this app would merge with previous versions of linux-headers 2.6, as the needed info was apparently just added between 2.6.6 and 2.6.7. note2: iptables needs to use /usr/src/linux in order to support extensions like grsec... i guess system headers arent really important in this case, but there are issues with vanilla 2.6.7. perhaps we need a testsuite of applications to decide whether or not a given header revision will work? so far we have sash, sysklogd, ext2resize, iproute2, and with the /usr/src/linux symlink removed iptables. anything else that might have trouble with a given header release? note3: amd64 doesnt support 2.4 either.
i fixed iptables2 so it doesnt need any kernel patches ... i dont know why plasmaroo backported them to 2.6.6 ;) sash has been fixed properly ... tim fixed that with Bug 42527 i dont know of any problems with ext2resize ... i use it on my x86/arm boxes ... i did clean up the ebuild though so that may have fixed it :p
Well; I backported the iproute2 thing since Lv didn't want to mark linux-headers-2.6.7 as stable. As SpanKY's said; if things don't work with the headers please file a bug, assign it to me and include the relevant USE [ Use "emerge -pv" ] flags you're using to compile that package and the compiler errors; since saying "They don't work!" won't get anything fixed. Thanks.
welp, x86 has keywords in the 2.6 linux26-headers ebuilds so this shouldnt be a problem anymore
