Bugzilla Bug 156784

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 an attachment (id=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 an attachment (id=103761) [details]
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 an attachment (id=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 an attachment (id=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] [details]
> 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 an attachment (id=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.