Skip to content
Snippets Groups Projects
  1. Feb 25, 2025
  2. Feb 20, 2025
    • Simon McVittie's avatar
      pressure-vessel/THIRD-PARTY.md: Update · 2d914bcc
      Simon McVittie authored
      
      Not all of our binary builds actually need to include all of these
      libraries any more, so adjust some of the text to reflect that.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      2d914bcc
    • Simon McVittie's avatar
      build-relocatable-install: Automatically collect executables' dependencies · 154fc315
      Simon McVittie authored
      
      Instead of hard-coding selected libraries that our executables depend
      on, we can ask capsule-capture-libs to inspect them and parse their
      dependencies automatically.
      
      One benefit of this is that it allows us to build a relocatable
      installation of pressure-vessel on any Debian release, and expect that
      relocatable installation to be runnable on any distro where glibc is equal
      to or newer than the chosen Debian release, reducing our dependence on
      Steam Runtime 1 'scout'.
      
      Another benefit is that when building on scout, we no longer need to
      bundle libraries or source code for libpcre (because scout's GLib backport
      statically links its vendored copy instead, since steamrt/tasks#112) or
      libselinux and util-linux (because we compile scout's GLib with SELinux
      and libmount integration disabled, also since steamrt/tasks#112).
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      154fc315
    • Simon McVittie's avatar
      build-relocatable-install: Discover library dependencies automatically · 1c4a7726
      Simon McVittie authored
      
      Instead of hard-coding the list of library packages that we depend on,
      look at the output of capsule-capture-libs and find out which package
      owns the library that each symlink points to. Those packages are our
      dependencies.
      
      This is necessary if we want to run build-relocatable-install on
      anything other than scout, because some of the libraries we depend on
      have changed between Debian releases: for example libgio-2.0.so.0 used
      to be in libglib2.0-0 but is now in libglib2.0-0t64. Similarly, some of
      the libraries have changed their dependencies: GLib used to depend on
      libffi.so.6 and libpcre.so.3, but now depends on libffi.so.8 and
      libpcre2-8.so.0.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1c4a7726
    • Simon McVittie's avatar
      build-relocatable-install: Don't explicitly depend on libpcre3 · febda80a
      Simon McVittie authored
      
      In newer Debian releases, GLib depends on libpcre2-8-0 instead.
      Let capsule-capture-libs pull in whichever one we actually depend on.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      febda80a
    • Simon McVittie's avatar
      CI: Build the source package (.dsc) separately · cba31202
      Simon McVittie authored
      
      If we run deb-build-snapshot more than once in different container
      environments, they can produce different source packages or even
      different version numbers (because `git describe` does not guarantee
      to emit any specific number of hex digits in the abbreviated sha1).
      Ensure that all our builds are consistent by using deb-build-snapshot
      to create a single source package (.dsc), and then doing all other
      package builds from that .dsc rather than from git.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      cba31202
  3. Feb 13, 2025
    • Simon McVittie's avatar
      pv-wrap: Export parent dir of LD_PRELOAD modules, unless it's $HOME · ba0ffa1e
      Simon McVittie authored
      
      LD_PRELOAD modules are an inherently fragile mechanism, and any symbols
      exported by either a LD_PRELOAD module or its direct dependencies
      will "interpose" in front of symbols of the same name from any other
      library. In some cases this can lead to crashes, for example when
      the Python ctypes module from Steam Runtime 2 'soldier' (which depends
      on libffi.so.6) gets its libffi references resolved to symbols from
      a more modern host system's libffi.so.7 or libffi.so.8 pulled in by
      the dependency chain:
      
          libMangoHud.so -> libwayland-client.so.0 -> libffi.so.8
      
      Authors of LD_PRELOAD modules like MangoHud can avoid this situation
      by making their LD_PRELOAD module only depend on highly long-term-stable
      projects (ideally only glibc), and then loading the implementation of
      its real functionality via `dlopen()`, using `RTLD_LOCAL|RTLD_DEEPBIND`
      to avoid symbol conflicts.
      
      For example, newer versions of MangoHud separate the module into
      libMangoHud_shim.so (the actual LD_PRELOAD module, no dependencies
      except glibc) and libMangoHud_opengl.so (dlopen'd by the shim module,
      depends on whatever it needs to depend on).
      
      This is a good approach and we should encourage it, but in the current
      pressure-vessel codebase it isn't going to be completely reliable for
      modules that are installed other than in /usr: for libMangoHud_shim.so
      to be able to load libMangoHud_opengl.so, we need to ensure that they
      are both visible in the filesystem of the game's container. However,
      since we can't know what modules and/or libraries libMangoHud_shim.so
      is going to load at runtime, we will have to use a heuristic.
      
      The heuristic I've chosen here is to say that if you have
      `LD_PRELOAD=/path/to/some/module.so`, then instead of sharing
      `/path/to/some/module.so` with the container as we did previously,
      we should share the parent directory `/path/to/some/`. In particular,
      this is enough for MangoHud's requirements.
      
      However, one notable exception is that if the module is situated
      directly inside `$HOME`, and we are using `--unshare-home` to avoid
      sharing the home directory with the container, we probably do not want
      to overrule that. In this case, users will still need to use
      `PRESSURE_VESSEL_FILESYSTEMS_RO` to share the dependency explicitly.
      
      steamrt/tasks#595
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      ba0ffa1e
  4. Feb 12, 2025
  5. Feb 07, 2025
  6. Feb 04, 2025
    • Simon McVittie's avatar
      pressure-vessel: Add STEAM_COMPAT_RUNTIME_SDL2=sdl2-compat · b29ffab9
      Simon McVittie authored
      
      After we add sdl2-compat to container runtimes, we will presumably want
      a reasonably long testing period in which the default is still
      "classic" SDL2, but users, developers and testers can opt-in to using
      sdl2-compat as a replacement for it. This mechanism lets us achieve that.
      
      This will not be practically useful until soldier and/or sniper includes
      a copy of sdl2-compat.
      
      steamrt/tasks#579, steamrt/tasks#573
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b29ffab9
  7. Jan 31, 2025
  8. Nov 28, 2024
  9. Nov 21, 2024
  10. Nov 18, 2024
    • Simon McVittie's avatar
      pressure-vessel: Generate /etc/passwd, /etc/group for the container · 23a52654
      Simon McVittie authored
      Sometimes our current uid will not be present in /etc/passwd.
      For example, when using systemd-homed the equivalent of a passwd(5)
      record is synthesized by libnss_systemd. A similar thing could happen
      when using a remote user directory like LDAP, or for the group database.
      
      Inside the container, we have the basic nsswitch plugins from glibc
      (notably libnss_files, which reads /etc/passwd and /etc/group), but
      we do not have access to non-standard nsswitch plugins like
      libnss_systemd or LDAP. This can cause crashes or bugs in games that
      assume that `getpwuid(getuid())` will always succeed (like Factorio),
      especially if they do not respect `$HOME` (like Factorio).
      
      Instead of bind-mounting the host system's /etc/passwd and /etc/group
      as-is, we can synthesize a /etc/passwd and /etc/group that are
      guaranteed to contain at least our uid and primary gid, matching what
      Flatpak does.
      
      Flatpak generates very minimal files that list our uid and gid, plus
      the default overflow uid and gid 65534 (labelled as `nfsnobody` for
      historical reasons). However, pressure-vessel has historically provided
      more complete files, so it's conceivable that a game might be relying
      on being able to resolve (for example) root as uid 0; so we copy
      everything from the host /etc/passwd and /etc/group, excluding only
      the line(s) that would duplicate the one we synthesize.
      
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/705
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23a52654
  11. Nov 05, 2024
    • Simon McVittie's avatar
      pv-adverb: Set SDL_DYNAMIC_API to a suitable value on request · 0f1133b3
      Simon McVittie authored
      
      It's difficult for users of non-Debian-derived distros to select the
      runtime's SDL, especially if they don't know whether the game is 32- or
      64-bit, because the expansion of `$LIB` and `$PLATFORM` varies between
      distro glibc builds.
      
      However, we can normally predict `$LIB` and `$PLATFORM` well enough to
      do the right thing programmatically. For example, if `$PLATFORM` expands
      to `i686` in 32-bit processes and `xeon-phi` in 64-bit, then we can
      create symlinks at `/tmp/XX/i686/libSDL2-2.0.so.0` and
      `/tmp/XX/xeon-phi/libSDL2-2.0.so.0`, and then set
      `SDL_DYNAMIC_API='/tmp/XX/${PLATFORM}/libSDL2-2.0.so.0'` to have the
      runtime linker dynamically select the correct word size.
      
      While I'm here, we might as well provide the same setup for SDL3.
      
      steamrt/tasks#578
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      0f1133b3
  12. Oct 30, 2024
  13. Oct 15, 2024
    • Simon McVittie's avatar
      pv-runtime: Use host versions of the libdrm family, if newer · 9d346343
      Simon McVittie authored
      In current Mesa versions, typically these are pulled in via explicit
      linking that generates a `DT_NEEDED` ELF header, either in individual
      DRI drivers in very old Mesa, in the Gallium "megadriver" in
      intermediate Mesa versions like the one in Debian 12, or in
      `libgallium-${VERSION}.so` in newer Mesa.
      
      However, Mesa merge request
      https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658
      
      
      suggests demoting the dependency on `libdrm_amdgpu.so.1` from
      `DT_NEEDED` to `dlopen()`. Changing that dependency from declarative to
      imperative breaks our ability to follow it, resulting in the container's
      older `libdrm_amdgpu.so.1` being used.
      
      In principle there's nothing to stop the same thing from happening for
      any of the libraries in the libdrm family, so look for all of them.
      For future-proofing, I've included all available drivers even if they
      are not available on x86 (but excluding exynos and omap, which seem to
      be only for 32-bit ARM hardware, which is probably no longer
      interesting).
      
      Tested-by: Dmitry Osipenko
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9d346343
Loading