Bug#749685: morse-simulator: FTBFS on Kfreebsd - Blocking python3.4 as default python3

[Matthias Klose]

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 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.

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?