+++ This bug was initially created as a clone of Bug #201434 +++ 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 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 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! -- Additional comment from Axel.Thimm on 2006-08-05 06:07 EST -- 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. -- Additional comment from misa on 2006-08-17 18:18 EST -- Fix (based on your suggestion) included in python-2.4.3-15 - thanks!
Did the fix in -15 not work? Beta1 was frozen a while back and thus doesn't include a lot of fixes which have occurred in the meantime; beta2 will reconverge with FC6 and all the fixes in between
-15 on FC6 was OK, I cloned the report because beta1 carries -14 and some builds against beta1 started failing.
The fix was not a beta1 blocker, therefore it didn't make it. Rest assured it will be there in beta2. I'll leave the bug open so we can make sure that will happen.
I verified that this is fixed in beta2, thanks! But I cannot close this bug, it says: "You tried to change the Status field from MODIFIED to CLOSED, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field." Well, I'm the submitter, but anyway, please close this bug whoever is "sufficiently empowered". :)
Closing per submitter's request.