vanilla-sources should be suitable for all architectures. Reproducible: Always Steps to Reproduce: 1. emerge vanilla-sources 2. 3. Actual Results: older vanilla-sources are installed Expected Results: latest vanilla-sources are installed
Why does 2.6.27 have different keywords than previous versions anyway?
16:27 <@dsd_> no, you still have to drop keywords between 2.6.x and 2.6.y 16:27 <@dsd_> even testing ones 16:28 < mpagano> so I should drop keywords when I bump 16:28 <@dsd_> yes 16:28 <@dsd_> but not for the incremental stable releases 16:29 < mpagano> right 16:29 < mpagano> so .23 to .24, drop keywords 16:29 <@dsd_> yeah, this only applies for kernel
What's the logic? The kernel still supports x86-64, obviously... Anyways, what's the procedure for adding a keyword after a bump? people reporting success upgrading on bugzilla? and will this procedure be applied for _every_ version bump? every two-three months? Last thing, it would've been great if this was announced somewhere, if not in the front page than at least on GMN (I'm sorry if it was but I missed it).
As nvidia-drivers is still broken with this kernel series, we're going to hold off keywording 2.6.27 at least until 2.6.27 final is out.
nvidia-drivers is broken on amd64 but not on x86? BTW, it's great to see the policy change arbitrarily. nvidia/ati/whatever have and always will be catching up on kernel releases and it has never affected the keywording of the kernel. I'm a long time gentoo user and as I recall what has always happend is one of two things - either the package (nvidia-drivers in this case) broke with the specific version, or a patch was applied for it until it was accepted upstream. Seems very odd to prevent ATI users, for example, from using a newer version because of nvidia-drivers. Anyways, can you at least update users when policy changes? It's quite annoying finding this out by mistake, if at all.
You are free to use vanilla-source-2.6.27_rc* by putting this in your /etc/portage/package.keywords file: =sys-kernel/vanilla-source-2.6.27* **
In reference to comment #4 As an amd64 + radeonhd user, I feel that nVidia's shortcomings should be dealt with in the nvidia-drivers ebuild, and not in the vanilla-sources ebuild. Just my $0.02
> I feel that nVidia's shortcomings should be > dealt with in the nvidia-drivers ebuild, and > not in the vanilla-sources ebuild. I completely agree. There is no problem with vanilla-sources. Also, virtualbox-modules is broken in the same way with 2.6.27: In file included from /var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv/SUPDRVShared.c:35: /var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv/SUPDRV.h:104:30: error: asm/semaphore.h: No such file or directory In file included from /var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv/linux/SUPDrv-linux.c:35: /var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv/SUPDRV.h:104:30: error: asm/semaphore.h: No such file or directory make[2]: *** [/var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv/SUPDRVShared.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [/var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv/linux/SUPDrv-linux.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/virtualbox-modules-1.6.4/work/vboxdrv] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.27'
(In reply to comment #8) > Also, virtualbox-modules is broken in the same way with 2.6.27: virtualbox-modules fixes this in version 1.6.6...
