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@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@falla:~$ dpkg -L libpython3.4-stdlib | grep
multiprocessing.cpython
(sid_kfreebsd-amd64-dchroot)pochu@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.4arch=kfreebsd-amd64ver=3.4.1-1stamp=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
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538b54c1.7050...@debian.org
