make[1]: Entering directory `/usr/src/linux-2.6.19-gentoo' CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_auth.o In file included from /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_auth.c:36: /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drmP.h:44:26: error: linux/config.h: No such file or directory make[2]: *** [/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_auth.o] Error 1 make[1]: *** [_module_/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.19-gentoo' make: *** [modules] Error 2
sed -i "s:#include <linux/config.h>:#ifndef _LINUX_CONFIG_H\n\ #define _LINUX_CONFIG_H\n\ #include <linux/autoconf.h>\n\ #endif:" *.c sed -i "s:#include <linux/config.h>:#ifndef _LINUX_CONFIG_H\n\ #define _LINUX_CONFIG_H\n\ #include <linux/autoconf.h>\n\ #endif:" *.h hope this bug be fixed soon. the same problem with ati-drivers. confgi.h had been removed from the new kernel.
Are we even sure that, 6 months later, the drivers in this package are more up-to-date than the in-kernel ones? Perhaps some sort of version bump is more in order.
4 days passed. this bug is still "Leave as NEW"
As a temporary workaround you may be interested in using live ebuild, which is found here: http://sturmartillerie.org/portage/mesa-cvs/x11-base/x11-drm/
If you search bugzilla for '2.6.19', you'll see that a TON of packages that build external sources against the kernel are failing. I have a ticket open to bump x11-drm to a more recent version. The in-kernel drivers are stale and old compared to the ones from the DRM folks, and it makes a lot of sense to use external ones that can be toyed-with and/or upgraded and downgraded to suit a user's needs.
(In reply to comment #5) > If you search bugzilla for '2.6.19', you'll see that a TON of packages that > build external sources against the kernel are failing. :O And anyone knows why this is happening? Kernel fault?
(In reply to comment #6) > :O And anyone knows why this is happening? Kernel fault? I'm totally out of my area of expertise, this is all inference, but it seems that a major kbuild cleanup results in a file (config.h?) not being built, and a lot of Gentoo's ebuilds use said file to build against the kernel sources. Packages that make modules from outside the shipping kernel can't seem to build correctly, and those that can are getting sandbox errors.
Created attachment 103760 [details] x11-drm-20061207.ebuild This ebuild works with kernel 2.6.19. However, I haven't tested with 2.4.x (and probably it won't work).
Created attachment 103761 [details, diff] x11-drm-20061207-linux-core-Makefile.patch Misc fixes to linux-core/Makefile (adapted from the previous gentoo patches).
The snapshot I've used to build with kernel 2.6.19 can be found here: http://personales.alumno.upv.es/sanmove/stuff/x11-drm-20061207.tar.bz2
(In reply to comment #10) > The snapshot I've used to build with kernel 2.6.19 can be found here: > http://personales.alumno.upv.es/sanmove/stuff/x11-drm-20061207.tar.bz2 > it tries to download something like blabla-kernelsource-blabla which not found on that server
(In reply to comment #11) > (In reply to comment #10) > > The snapshot I've used to build with kernel 2.6.19 can be found here: > > http://personales.alumno.upv.es/sanmove/stuff/x11-drm-20061207.tar.bz2 > > > it tries to download something like blabla-kernelsource-blabla which not found > on that server > Sure, I named the files incorrectly. You can edit the ebuild and write the correct file name on SRC_URI. I'll correct the ebuild and do some tests later.
Created attachment 103792 [details] x11-drm-20061207.ebuild Fixed ebuild.
(In reply to comment #10) > The snapshot I've used to build with kernel 2.6.19 can be found here: > http://personales.alumno.upv.es/sanmove/stuff/x11-drm-20061207.tar.bz2 Hi, that URI yields an "Internal Server Error" and "Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request." I'd really like to check out x11-drm-20061207, since x11-drm-20060608 fails with the very same config.h error here. BTW, why is x11-drm-20060608 marked "stable" for x86 when it so obviously fails with a recent kernel? Best regards, Florian
Hi, I have a simple work around. Before emerging x11-drm you can create config.h, for example (assuming kernel is a symblic lynk for a 2.6.19 kernel) : ln -s /usr/include/linux/config.h /usr/src/kernel/include/linux/config.h It is not very clean but it works.
(In reply to comment #15) > Hi, > > I have a simple work around. It works! :DDD Thanks. :)
Created attachment 104170 [details] x11-drm-20060608-r1.ebuild Well, it would appear that the long term solution is to update the snapshot to something that works. In the meanwhile, we have Velasco's ebuild which seems to have hosting problems and droop's quick hack. This ebuild just has one extra line that removes references to config.h that you can dump into your overlay and should JustWork(TM).
(In reply to comment #14) > that URI yields an "Internal Server Error" and "Additionally, a 403 Forbidden > error was encountered while trying to use an ErrorDocument to handle the > request." The links works again. Sorry for the inconvenience. > > BTW, why is x11-drm-20060608 marked "stable" for x86 when it so obviously fails > with a recent kernel? x11-drm is marked stable because it works with the stable kernels. 2.6.19 is not marked stable yet.
(In reply to comment #18) Oh yes, I see. I'm just too used to have sys-kernel/vanilla-sources in package.keywords. ;-) x11-drm-20060608-r1.ebuild from comment 17 does fine here when emerged with FEATURES="-sandbox" because of the 2.6.19 sandbox issue that breaks emerging. Thanks, now DRM is running again. Florian
(In reply to comment #17) > Created an attachment (id=104170) [edit] > x11-drm-20060608-r1.ebuild This is incorrect - the sed needs to only happen on >=2.6.18 Try using kernel_is Another approach would be to unconditionally apply a patch which does something like #include <linux/version.h> #if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,18) #include <linux/config.h> #endif Maintainers, please ensure this is fixed in the stable tree ASAP
Bump... any volunteers to produce a patch based on the info in my last comment?
Created attachment 105022 [details] x11-drm-20060608.ebuild > Bump... any volunteers to produce a patch based on the info in my last comment? Sure. Sorry, I didn't intend the previous one to be an actual fix. It is still probably better for maintainers to just grab a new CVS snapshot. I guess this is no longer a -r1 because there is no reason to reemerge if it already works and -r1 is already used for FreeBSD stuffs.
It needs to be fixed in the stable tree so a patch is necessary even if a new version enters portage. Also you use a kernel-mod function in a linux-mod eclass, that won't work. A patch would still be better.
Okay, I've added a patch to do conditional includes per dsd's suggestion. New patchball is version 0.3 for the 20060608 ebuilds. I've tested building against Gentoo's 2.6.18, 2.6.19 and 2.4.32 sources. Any problems, let me know. I haven't added a new snapshot yet. Upstream has removed 2.4 kernel support, so I'll need to do some work on the ebuild to compensate.
