Bug#749685: Re: Bug#749685: morse-simulator: FTBFS on Kfreebsd - Blocking python3.4 as default python3
Emilio Pozuelo Monfort
pochu at debian.org
Sun Jun 1 16:28:49 UTC 2014
On 01/06/14 12:13, Sebastian Ramacher wrote:
> On 2014-05-29 00:55:09, Scott Kitterman wrote:
>> Source: morse-simulator
>> Version: 1.2-2
>> Severity: serious
>> Justification: fails to build from source (but built successfully in the past)
>>
>> FTBFS on both Kfreebsd i386 and amd64. The end of the build log looks like:
>>
>> reading sources... [ 12%] media
>> reading sources... [ 12%] morse
>> reading sources... [ 13%] multinode
>> reading sources... [ 13%] pymorse
>> [error] install python-concurrent.futures
>> make[3]: *** [CMakeFiles/doc] Error 1
>> CMakeFiles/doc.dir/build.make:52: recipe for target 'CMakeFiles/doc' failed
>> make[3]: Leaving directory '/«PKGBUILDDIR»/obj-i486-kfreebsd-gnu'
>> CMakeFiles/Makefile2:967: recipe for target 'CMakeFiles/doc.dir/all' failed
>> make[2]: *** [CMakeFiles/doc.dir/all] Error 2
>> make[2]: Leaving directory '/«PKGBUILDDIR»/obj-i486-kfreebsd-gnu'
>> make[1]: *** [all] Error 2
>> Makefile:126: recipe for target 'all' failed
>> make[1]: Leaving directory '/«PKGBUILDDIR»/obj-i486-kfreebsd-gnu'
>> dh_auto_build: make -j1 returned exit code 2
>> make: *** [build-arch] Error 2
>> debian/rules:8: recipe for target 'build-arch' failed
>> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
>>
>> While this is not new (it's three months old), it's now blocking getting
>> packages rebuilt for python3.4 as default python3 (See #746709).
>
> The issue here is that importing concurrent.futures fails.
> morse-simulator tries to import ThreadPoolExectur and Future from
> concurrent.futures. On falla, this fails with
>
> % python3 -c "from concurrent.futures import ThreadPoolExecutor, Future"
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File "/usr/lib/python3.4/concurrent/futures/__init__.py", line 17, in <module>
> from concurrent.futures.process import ProcessPoolExecutor
> File "/usr/lib/python3.4/concurrent/futures/process.py", line 55, in <module>
> from multiprocessing.connection import wait
> File "/usr/lib/python3.4/multiprocessing/connection.py", line 21, in <module>
> import _multiprocessing
> ImportError: No module named '_multiprocessing'
>
> Adding python-concurrent.futures to Build-Depends didn't help because
> it is the backport of concurrent.futures for Python 2. Python >= 3.2 (I
> think, or maybe >= 3.3) provides concurrent.futures in the standard lib.
>
> This looks like a python3.4 bug to me, but someone with more knowledge
> of concurrent.futures needs to decide that.
I think the problem (or at least one of them) is this:
(sid_kfreebsd-amd64-dchroot)pochu at falla:~$ dpkg -L libpython3.3-stdlib | grep
multiprocessing.cpython
/usr/lib/python3.3/lib-dynload/_multiprocessing.cpython-33m-x86_64-kfreebsd-gnu.so
(sid_kfreebsd-amd64-dchroot)pochu at falla:~$ dpkg -L libpython3.4-stdlib | grep
multiprocessing.cpython
(sid_kfreebsd-amd64-dchroot)pochu at falla:~$
That's why importing _multiprocessing fails with python3.4.
That is not shipped because of this: (from
https://buildd.debian.org/status/fetch.php?pkg=python3.4&arch=kfreebsd-amd64&ver=3.4.1-1&stamp=1400800890
)
*** WARNING: renaming "_multiprocessing" since importing it failed:
build/lib.gnukfreebsd-9.0-2-amd64-x86_64-3.4/_multiprocessing.cpython-34m.so:
undefined symbol: _PyMp_sem_unlink
[...]
find debian/tmp/usr/lib/python3.4 -name '*_failed*.so'
debian/tmp/usr/lib/python3.4/lib-dynload/_multiprocessing.cpython-34m_failed.so
_PyMp_sem_unlink is defined in semaphore.c. setup.py has:
if host_platform == 'win32':
multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
'_multiprocessing/semaphore.c',
]
else:
multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
]
if (sysconfig.get_config_var('HAVE_SEM_OPEN') and not
sysconfig.get_config_var('POSIX_SEMAPHORES_NOT_ENABLED')):
multiprocessing_srcs.append('_multiprocessing/semaphore.c')
But the kfreebsd-amd64 build log has:
/* Define to 1 if you have the `sem_open' function. */
#define HAVE_SEM_OPEN 1
[...]
/* Define if POSIX semaphores aren't enabled on your system */
#define POSIX_SEMAPHORES_NOT_ENABLED 1
Thus semaphore.c is not built (as can be verified by looking for "semaphore.c"
in the log), and we get that undefined symbol.
(The same thing happens on hurd).
I'm not sure if the file should be built on kfreebsd/hurd, or if it shouldn't
but there should be some fallback code in python3.4. Adding the python
maintainer, and the bsd and hurd porters to Cc.
Regards,
Emilio
More information about the debian-science-maintainers
mailing list