[FIX] /dev/shm was mounted and unwritable, so python lost its semaphores

sem_open: Permission denied
  checking whether POSIX semaphores are enabled... no

EACCES, not ENOSYS. This port read the failure as a missing mount, mounted the
tmpfs, and got the same result -- because `-o mode=1777` applies only when the
mount is created, and the `mountpoint -q ||` guard skips an existing one. findmnt
showed a tmpfs at /dev/shm while the directory itself was drwxr-xr-x, so the
build user could create nothing in it.

CPython runs sem_open at CONFIGURE time. It concluded the platform has no working
semaphores, set POSIX_SEMAPHORES_NOT_ENABLED, and compiled _multiprocessing
without SemLock -- and every consumer then failed with a message blaming the
platform, days after the cause.

The mode is now set with chmod rather than trusted to the mount option, and the
result is PROVED from inside the chroot as the build user. Every earlier check of
this was made as root and passed while the build kept failing.

--- FR ---

  sem_open: Permission denied
  checking whether POSIX semaphores are enabled... no

EACCES, pas ENOSYS. Ce portage a lu l'échec comme un montage absent, a monté le
tmpfs, et a obtenu le même résultat — car `-o mode=1777` ne s'applique qu'à la
création du montage, et la garde `mountpoint -q ||` saute un montage existant.
findmnt montrait un tmpfs sur /dev/shm alors que le répertoire était drwxr-xr-x :
l'utilisateur de compilation n'y pouvait rien créer.

CPython exécute sem_open au moment de CONFIGURE. Il en a conclu que la plateforme
n'a pas de sémaphores fonctionnels, a posé POSIX_SEMAPHORES_NOT_ENABLED et
compilé _multiprocessing sans SemLock — et chaque consommateur a ensuite échoué
sur un message accusant la plateforme, des jours après la cause.

Le mode est désormais posé par chmod plutôt que confié à l'option de montage, et
le résultat est PROUVÉ depuis l'intérieur du chroot, sous l'utilisateur de
compilation. Toutes les vérifications précédentes avaient été faites en root et
passaient pendant que la construction échouait.

Assisted-by: Claude Opus 5

scripts/build-stage2.sh

@@ -559,6 +559,29 @@ mount_chroot() {
     # rebuild python, which is why this comment says so.
     mountpoint -q "$ROOT/dev/shm" ||
         sudo mount -t tmpfs -o mode=1777,nosuid,nodev tmpfs "$ROOT/dev/shm"
+    # The MODE, set explicitly and not left to the mount option.
+    #
+    # `-o mode=1777` only applies when this mount is created. The guard above
+    # skips an existing one -- and an existing one may have been mounted without
+    # the option, which is exactly what happened: findmnt showed the tmpfs there
+    # while the directory was drwxr-xr-x, so uid 1000 could create nothing in it.
+    #
+    # That is what CPython's configure actually hit:
+    #
+    #   sem_open: Permission denied
+    #   checking whether POSIX semaphores are enabled... no
+    #
+    # EACCES, not ENOSYS. The port spent a pass reading it as a missing mount and
+    # another as a missing tmpfs, when the mount was present and the mode wrong.
+    sudo chmod 1777 "$ROOT/dev/shm"
+    # And PROVED from inside, as the build user, because every previous check of
+    # this was made as root and passed while the build kept failing.
+    if ! sudo chroot --userspec="$BUILD_UID:$BUILD_GID" "$ROOT" \
+            /usr/bin/env -i PATH=/usr/bin sh -c \
+            'f=/dev/shm/.el-probe.$$; : > "$f" && rm -f "$f"' 2>/dev/null; then
+        printf '  WARNING: /dev/shm is not writable by the build user;\n'
+        printf '           python will build without POSIX semaphores\n'
+    fi
     # Sources and PKGBUILDs, already fetched by stage 1. Bind-mounting them
     # means the chroot needs no network at all, which is worth having: this
     # host cannot reach dev.gnupg.org, and a build that silently re-fetches