Matthew Fernandez <matthew.fernan...@gmail.com> added the comment:
I'm trying to follow the history of this issue, as it does not seem fully
resolved to me. While trying to package something for Debian, one of the buildd
[0] logs for hurd-i386 points to this issue as the cause of a failure [1]. This
occurs with Python 3.7, though Debian's Python 3.7 may involve some distro
patches on top of upstream source. If the build log is inaccessible or
incomprehensible, the relevant sections are:
...
The following additional packages will be installed:
... libpython3-stdlib libpython3.7-minimal libpython3.7-stdlib ... python3
python3-minimal python3.7 python3.7-minimal
...
/usr/bin/ctest --force-new-ctest-process -j1
Test project /<<PKGBUILDDIR>>/obj-i686-gnu
Start 1: tests
1/1 Test #1: tests ............................***Failed 0.10 sec
Traceback (most recent call last):
File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 28, in
<module>
from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing'
(/usr/lib/python3.7/lib-dynload/_multiprocessing.cpython-37m-i386-gnu.so)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/<<PKGBUILDDIR>>/tests/run-tests.py", line 46, in <module>
print_lock = multiprocessing.Lock()
File "/usr/lib/python3.7/multiprocessing/context.py", line 66, in Lock
from .synchronize import Lock
File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 32, in
<module>
" synchronization primitives needed will not" +
ImportError: This platform lacks a functioning sem_open implementation,
therefore, the required synchronization primitives needed will not function,
see issue 3770.
Do you know what is happening here? Maybe the compounded ImportError I'm seeing
*was* the resolution referred to in prior comments, but if so it seems strange
to reference this issue in the error message.
The hurd-i386 platform is not a priority for me, so if the answer is
"multiprocessing doesn't work there" I am perfectly OK with this. Also I
realise I am asking you to recall >10 year old memories so I apologise in
advance for any re-opened wounds.
If you need to see the source for what buildd is actually testing here, it's
the debian/v2020.11.01-1 tag of [2].
[0]: https://wiki.debian.org/buildd
[1]:
https://buildd.debian.org/status/fetch.php?pkg=rumur&arch=hurd-i386&ver=2020.01.11-1&stamp=1579290012&raw=0
[2]: https://github.com/Smattr/rumur
----------
nosy: +smattr
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue3770>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
