Currently, our config tools fail to compile because xf86Optrec.h can't be found, which is included by xf86Parser.h. While investigating this, I determined that modular X is not installing the header, however I also discovered that modualr X is not installing xf86Parser.h either. After further investigation along with jkeating, we determined that pyxf86config itself is including it's own private copies of X headers for a library with a non-stable and ever changing API! -rw-rw-r-- 1 mharris mharris 46 Apr 10 2002 AUTHORS -rw-rw-r-- 1 mharris mharris 17992 Feb 22 2002 COPYING -rw-rw-r-- 1 mharris mharris 5407 Nov 13 17:20 ChangeLog -rw-rw-r-- 1 mharris mharris 7831 Feb 22 2002 INSTALL -rw-rw-r-- 1 mharris mharris 460 Nov 13 22:28 Makefile.am -rw-rw-r-- 1 mharris mharris 21216 Nov 13 22:32 Makefile.in -rw-rw-r-- 1 mharris mharris 177 May 24 2002 NEWS -rw-rw-r-- 1 mharris mharris 253 Apr 14 2004 README -rw-rw-r-- 1 mharris mharris 256826 Nov 13 22:32 aclocal.m4 -rwxr-xr-x 1 mharris mharris 42037 Sep 29 17:51 config.guess* -rw-rw-r-- 1 mharris mharris 1700 Nov 13 22:32 config.h.in -rwxr-xr-x 1 mharris mharris 30253 Sep 29 17:51 config.sub* -rwxrwxr-x 1 mharris mharris 752141 Nov 13 22:32 configure* -rw-rw-r-- 1 mharris mharris 1223 Nov 13 22:30 configure.in -rwxr-xr-x 1 mharris mharris 15936 Jul 19 12:44 depcomp* -rwxr-xr-x 1 mharris mharris 9233 Jul 19 12:44 install-sh* -rw-r--r-- 1 mharris mharris 186760 Sep 29 17:51 ltmain.sh -rwxr-xr-x 1 mharris mharris 11014 Jul 19 12:44 missing* -rw-rw-r-- 1 mharris mharris 75755 Feb 9 2004 pyxf86conf.c -rw-rw-r-- 1 mharris mharris 595 Feb 26 2002 pyxf86conf.h -rw-rw-r-- 1 mharris mharris 4318 Nov 13 22:31 pyxf86config.spec -r--r--r-- 1 mharris mharris 12177 Nov 13 17:16 xf86Parser.h -rw-rw-r-- 1 mharris mharris 1968 Feb 22 2002 xf86ParserExt.h -rw-rw-r-- 1 mharris mharris 9181 Nov 13 16:58 xf86config.py -rw-rw-r-- 1 mharris mharris 4814 Nov 13 17:16 xf86config_ext.c ARGH!!!!! Please remove these X headers from pyxf86config, as this library changes every single X release, and can and does change at any time. This could very well be the cause for so much of the instability in our X config tool. My best guess as to why these headers are here, is because X didn't install them. The proper thing to have done, would have been to file a bug against X stating that it isn't installing headers for libxf86config, so that we can fix that, instead of having an ancient invalid header being used that doesn't match the library we ship. Please remove these headers from pyxf86config, while I figure out how to get modular X to install them. Thanks in advance.
Ok, some good news.. It took more effort than I would have thought, but I managed to finally convince the xorg-x11-server package to install the headers properly. When pyxf86config gets updated, you'll want to remove the private copy of the header(s), and add: BuildRequires: libxf86config-devel >= 1.0.0-2 Hope this helps! Take care..
Install xorg-x11-server-sdk and change configure in spec file to %configure --x-libraries=/usr/%{_lib} --x-includes=/usr/include/xorg/ --with-python-version=%{pyver}
(In reply to comment #2) > Install xorg-x11-server-sdk and change configure in spec file to > > %configure --x-libraries=/usr/%{_lib} --x-includes=/usr/include/xorg/ > --with-python-version=%{pyver} This is incorrect. The X server sdk does not install to a fixed location, it is configurable. Anything that needs to find the sdk should query for the location with pkg-config. Examples for how to do so are present in the video driver src.rpms. HTH
I just checked, and this bug is still present. If pyxf86config's private copies of the X headers differ in any substantial manner, then X config file parsing may be broken. Since this is a static library (libxf86config) because it is not a stable API/ABI, it can change at any time incompatibly, and it makes no sense for things linking to it to include private copies of the header files. Upping to FC5Blocker
Closing as per today's rawhide report.