Package: python2.6 Version: 2.6.5+20100630-2 Severity: serious The python2.6 package passes the configure argument --with-system-ffi to try to force the build to ignore its builtin "_ctypes" module and instead link to the installed libffi on the system.
Unfortunately due to some deficiencies in the python2.6 configure scripts it fails to detect libffi (even though it would work perfectly if compiled), and therefore builds its own embedded copy anyways. This violates Debian Policy section 4.13 (Convenience copies of code): http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles The exact failure is caused by the location of the libffi header files: /usr/include/$(gcc -dumpmachine)/ffi.h /usr/include/$(gcc -dumpmachine)/ffitarget.h These paths follow the MultiArch specification [0] and are automatically searched by GCC, so a simple "#include <ffi.h>" works automatically. Unfortunately the python2.6 package seems to search by hand for "ffi.h" in /usr/include and /usr/local/include, and when it does not find it in either of those locations it assumes it is not present. This also causes problems for new Debian ports which have successfully patched libffi to work under their architecture, as Python will ignore the functional system libffi and also quietly fail to build the "_ctypes" module, resulting in a partially-dysfunctional Python installation. Additional testing reveals that python2.5 also has this problem, although it appears to be fixed in python3.1. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
