0.3.4

proot-next 0.3.4

Steam, installed in one step

proot-next takes over from proot-bwrap, whose Python stand-in ran Steam's
containers through fakechroot and a PRoot build of its own.

• install-steam.sh installs Steam into a Debian-based amd64 image or system
  that has no user namespaces: Steam from Valve's repository with its keys
  checked against their fingerprints, the 32-bit libraries the client and
  games need, this release's binary checked against its published SHA-256 in
  /usr/local/lib/proot-next with the bwrap name beside it, and Steam's
  launcher diverted so that every way of starting Steam exports BWRAP to it.
  The bwrap name stays off PATH. Run again, it rewires an earlier install,
  proot-bwrap's included.

  curl -fsSL https://raw.githubusercontent.com/selkies-project/proot-next/main/install-steam.sh | sudo sh

• tests/steam/check.sh runs bwrap mode the way Steam does: the soldier,
  sniper and scout-on-soldier containers, OpenGL and Vulkan for both
  architectures against the host's own renderers, an X11 client, a native
  benchmark, a Windows OpenGL program through GE-Proton, and the client's
  sign-in window.

Fixes

• bwrap mode exports PWD as the directory the command starts in, and starts
  where bubblewrap does: --chdir's directory, else the caller's where the
  container has it, else $HOME, else /. It passed the caller's PWD
  through and started in / without --chdir, so GE-Proton's protonfixes,
  which finds the game's library through PWD, stopped with
  KeyError: 'PWD' under pressure-vessel before Wine started.
• A program named through a directory that does not exist fails to execute
  with ENOENT again, as under the kernel's own exec. 0.3.3's walk on pinned
  descriptors refuses such a lookup itself, and the ptrace tier skipped the
  syscall without setting its result, so the program saw ENOSYS: a shell
  said "Function not implemented" and returned 126 rather than "not found"
  and 127. Any syscall the ptrace tier refuses now fails with its own errno.