Python modules sometimes parse the contents of pyconfig.h rather than including
it.  This packages has replaced the standard contents of pyconfig.h with some
macros and further includes for multiarch support which then makes it
impossible
to configure and install these Python modules.  I encountered this when trying
to install cElementTree as part of Turbogears.  I'm not the first either, see
these two mailing list threads:

www.mail-archive.com/turbogears@googlegroups.com/msg00037.html
www.mail-archive.com/turbogears@googlegroups.com/msg00854.html

I'm told (which you can see if you follow the second thread) that Python has
its
own way to deal with multiarch issues, sys.exec_prefix.

I think this is more a bug in their package ( ie incomplete support for parsing
a perfectly valid .h) 
than a problem on our side.

But Mandriva has changed the Python standard distribution.  How can you expect
all Python modules to still work when you have changed something as fundamental
as pyconfig.h?

Anyway, I'm just a lowly user who wanted to install cElementTree on my Mandriva
system and it didn't work.  When I brought it up, all I got was, well it works
on every other distro, what's wrong with Mandriva?  Are you guys comfortable
with that?  If you really think it's a problem on their side, will you get on
comp.lang.python and let them know?

The system is not patched to make your life harder, but to offer a way to
develop 32 bits application on a 64 bits system without having to use a chroot.

if you want to install celementtree, you should change the path to python.h to
the real file :
./usr/include/multiarch-i386-linux/python2.4/pyconfig.h

use grep -r pyconfig.h to find it in the source code where it parse directly,
and it should compile fine.

I do not see a clean way to do it on our side without losing the benefit of
multiarch. 

"is is more a bug in their package"

Sorry, but that's rubbish.  If *you* mess up the standard pyconfig.h files so
Python's standard distribution utilities cannot read them, *your* distribution
is broken.  There are two ways to fix this; either *you* ship proper pyconfig.h
files, or *you* fix Python's distutils library so it can read your non-standard
files (don't forget to contribute your fixes to the python developers).  You
broke it, you fix it.  Until you do, Mandriva's Python distribution is broken.

The cooker package is fixed since 3 weeks, but I do not know if a update will
be issued ( I am neither python maintener, nor a mandriva employee )

[misc@n1 ~] $ python t.py
feature_macro :  HAVE_MEMMOVE
[misc@n1 ~] $ cat t.py
from distutils import sysconfig

config_h = sysconfig.get_config_h_filename()
config_h_vars = sysconfig.parse_config_h(PrivoxyWindowOpen(config_h))
for feature_macro in ["HAVE_MEMMOVE", "HAVE_BCOPY"]:
    if config_h_vars.has_key(feature_macro):
        print "feature_macro : " , feature_macro


* sam oct 08 2005 Frederic Lepied <flepied@mandriva.com> 2.4.1-4mdk
- fixed get_config_h_filename in distutils for multiarch headers


Yes, I was too harsh saying it is a bug in your package. But I tought it was
not a builtin python fonction, but rather some  setup script written by hand (
like we can see from time to time with evey software, like ./configure written
in plain shell instead of using autotools ).

The patch is in cvs :
cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/python/Python-2.4.1-lib64.patch?rev=1.2&content-type=text/x-cvsweb-markup
but I doubt it will applied, as this is very specific to mandriva multiarch
system ( qa.mandriva.com/twiki/bin/view/Main/MultiArch ). 

I can submit it to sourceforge if you think this is worth. 

I have uploaded a fixed package for the 2006 community branch, see
python-base-2.4.1-4.1.20060mdk on mirror.

Comment 7 Bugzilla administrator account 2006-06-15 19:02:04 CEST

No activity has been seen on this bug since 20051111 and it is still in
UNCONFIRMED state. This probably means that the information provided was not
clear enough, or
that the bug is not valid anymore. Please test and confirm that this bug is
still valid with the latest cooker version, or close it.

*** Bug 24253 has been marked as a duplicate of this bug. ***

I have python-base-2.4.1-4.1.20060mdk installed, and I get the following error
when building cElementTree:

"expat/xmlparse.c:75:2: error: #error memmove does not exist on this platform,
nor is a substitute available".

Is there some other action I need to take apart from having that rpm? I'm
running 2006 edition, for what it's worth.

what is the version of the other python package, what does the command 
rpm -qa --qf '%{SOURCERPM} %{NAME}-%{VERSION}-%{RELEASE}\n' | grep '^python-2'

return ?

It returns the following:
python-2.4.1-3mdk.src.rpm libpython2.4-2.4.1-3mdk
python-2.4.1-3mdk.src.rpm tkinter-2.4.1-3mdk
python-2.4.1-3mdk.src.rpm python-2.4.1-3mdk
python-2.3.3-2.2.100mdk.src.rpm libpython2.3-2.3.3-2.2.100mdk
python-2.4.1-4.1.20060mdk.src.rpm python-base-2.4.1-4.1.20060mdk
python-2.4.1-3mdk.src.rpm libpython2.4-devel-2.4.1-3mdk

ok, it was not clear in my first message, but you need to have the other
packages of python with the fixed version.

ie :
libpython2.4-2.4.1-4.1.20060mdk 
libpython2.4-devel-2.4.1-4.1.20060mdk
python-2.4.1-4.1.20060mdk
tkinter-2.4.1-4.1.20060mdk

You should not cherrypick package from a version on another unless you take
care of what you do. 

Shouldn't that be enforced with the RPM dependencies then? I'll try finding
those other RPMs (none of them seem to be in my update source) and see how it
goes.

There is a policy against this, but it was quite controversed. Maybe we should
discuss to change it.

The rpm are in the community source, you can add it by using
easyurpmi.zarb.org.

Ok, it seems to be fixed with all the other packages applied.

Ok, closing this bug as fixed.