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