Description of problem: /usr/include/python2.4/pyconfig.h is now a wrapper for 32/64 bit sub-includes. This breaks the usual query mechanism for extracting python build flags. Version-Release number of selected component (if applicable): python-2.4.3-14.fc6 How reproducible: always Steps to Reproduce: 1.config_h = sysconfig.get_config_h_filename() 2.config_h_vars = sysconfig.parse_config_h(open(config_h)) 3. Actual results: {} Expected results: {'STRICT_SYSV_CURSES': "/* Don't use ncurses extensions */", 'HAVE_SELECT': 1, 'HAVE_ST_BLOCKS': 1, [...] Additional info: o Breaks builds of smart package on FC6 o One can argue that the bug is in the implementation of parse_config_h, which should be able to descend into further included files. OTOH it would then need to understand nested conditionals, too. o maybe the 32/64 bits switch should be performed already on get_config_h_filename level? E.g. get_config_h_filename should return pyconfig-32.h and pyconfig-64.h respectively? Thanks!
Turns out this is due to the fix for multilib -devel support in bug #139911 comment 2. This fix only considered C/C++ consumers of pyconfig.h. python's querying mechanism needs to be redirected, too, by patching get_config_h_filename. A simple untested specfile fix is in bug #139911 comment 4.
Fix (based on your suggestion) included in python-2.4.3-15 - thanks!
This fixes bug #201435, thanks! Wrt to organisation, I'll just go ahead and close #201435 w/o removing the dependency, I hope that's the proper procedure. Otherwise feel free to remove the dependency. Thanks, again!