Re: Bug#749685: morse-simulator: FTBFS on Kfreebsd - Blocking python3.4 as default python3
Am 01.06.2014 18:28, schrieb Emilio Pozuelo Monfort:
> 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.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.
checking on falla, the failing autoconf test is
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <semaphore.h>
#include <sys/stat.h>
int main(void) {
sem_t *a = sem_open("/autoconf", O_CREAT, S_IRUSR|S_IWUSR, 0);
if (a == SEM_FAILED) {
perror("sem_open");
return 1;
}
sem_close(a);
sem_unlink("/autoconf");
return 0;
}
this fails then with:
configure:13424: ./conftest
sem_open: Function not implemented
configure:13424: $? = 1
configure: program exited with status 1
is this supposed to work?
Reply to: