- Feb 25, 2025
-
-
Simon McVittie authored
This avoids having them in the PATH where they might be relied on as an "API" by Steam or Steam games, and makes them more distinctive in ps(1) or similar. steamrt/tasks#669 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 20, 2025
-
-
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:
Simon McVittie <smcv@collabora.com>
-
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:
Simon McVittie <smcv@collabora.com>
-
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:
Simon McVittie <smcv@collabora.com>
-
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:
Simon McVittie <smcv@collabora.com>
-
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:
Simon McVittie <smcv@collabora.com>
-
- Feb 13, 2025
-
-
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:
Simon McVittie <smcv@collabora.com>
-
- Feb 12, 2025
-
-
Simon McVittie authored
This will allow the LD_PRELOAD handling code to use a real or mock home directory, as appropriate. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This can be used to set a mock home directory for unit testing, which we now do in the wrap-setup test (although it isn't used for anything yet). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we don't have to thread it through so much of wrap-setup as an explicit function parameter. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's slightly simpler without duplicating 1 bit of information like this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This lets us pass it to various functions as one parameter rather than two. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This keeps more of the things we have to mock for unit testing together, avoiding needing to thread a copy of the environment through the LD_PRELOAD setup code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're just looking at this, not altering it (not that we would be able to alter it with correct memory management under this calling convention, but that isn't necessarily immediately obvious to a reader). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes no practical difference yet, but we can use this for more consistent handling of a mock root directory for unit-testing in future. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 07, 2025
-
-
Simon McVittie authored
No functional change. Best reviewed with `git show --ignore-space-change`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means all the parsing and serialization is in one place, and we can round-trip between the struct representation and the command-line option representation. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will help us to centralize the code that maps to/from pv-adverb command-line options. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Convert to a concrete pv-adverb option name at the last possible moment. This will help us to centralize the code to map to/from pv-adverb command-line options. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows it to have test coverage. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 04, 2025
-
-
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:
Simon McVittie <smcv@collabora.com>
-
- Jan 31, 2025
-
-
Simon McVittie authored
Previously we had this in two places, but we can share code between pv-adverb and pv-wrap to make this easier to understand. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a useful thing to have if we might ever want a PvAdverbPreloadModule on the stack. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
All of our supported architectures define _SRT_MULTIARCH from the build system, and pressure-vessel can't be compiled for other architectures without defining _SRT_MULTIARCH, so we don't need to override this to a mock string; we can leave it set to the real multiarch tuple of the architecture. This avoids setting up inconsistencies between this code path, and other parts of pressure-vessel that do not force a mock architecture. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Until now, the case where only one architecture is supported has only been tested if pressure-vessel was built for a non-x86 architecture such as ARM, which is rarely (if ever) done. We can get coverage for this case by making pv-wrap behave as if only the first architecture was supported, as a runtime rather than compile-time decision: this means that an ordinary x86_64 build can exercise both the x86 and non-x86 code paths. This is important because steamrt/tasks#595 will add new code that differs according to whether there is only a single architecture, or more than one. In the test, this means we need to be able to mark which of the expected paths are expected on i386 only, and which ones are expected in general. Instead of the verbosity that would result from turning all of our test data into structs, I've done this with an ad-hoc mini-language: the ones that are only expected on i386 are prefixed with `i386:`. We also might conceivably want to make use of something similar to PV_APPEND_PRELOAD_FLAGS_ONE_ARCHITECTURE in production in future, if we start providing legacy-free containers that only support running x86_64 games. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fixes: 08751fff "tests: Assert that modules with ${LIB} or ${PLATFORM} are handled" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If compiled for a non-x86 architecture, we don't expect to be emulated by some foreign architecture with a mechanism like FEX or qemu-user, so PV_N_SUPPORTED_ARCHITECTURES_AS_EMULATOR_HOST is zero. In this case don't try to allocate and loop over an array of length 0. This also avoids gcc warnings with -Wtype-limits, "comparison of unsigned expression in ‘< 0’ is always false". Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instantiating this can't fail, and if it somehow does, trying it again is unlikely to help. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 28, 2024
-
-
Simon McVittie authored
This avoids the man pages misrendering on Gitlab when a definition list item has more than one paragraph. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 21, 2024
-
-
Simon McVittie authored
Compatibility tool 1070560 used to be named `Steam Linux Runtime`, but is now `Steam Linux Runtime 1.0 (scout)`. With the current naming, we should only say `Steam Linux Runtime` if we are talking generically about the whole family of container-based runtimes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These don't actually affect the behaviour of pv-wrap, but they're sufficiently closely-related that it makes sense to document them here. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Followup from steamrt/tasks#404 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Followup from steamrt/tasks#578 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 18, 2024
-
-
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:
Simon McVittie <smcv@collabora.com>
-
- Nov 05, 2024
-
-
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:
Simon McVittie <smcv@collabora.com>
-
- Oct 30, 2024
-
-
Simon McVittie authored
This will let us highlight warnings and fatal errors from bwrap as such. In particular, if bwrap fails with a fatal error, putting the <3> prefix on it will ensure that it's highlighted as an error. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can only add one directory to the search path for VDPAU drivers, so to support both 32- and 64-bit, we have to multiplex via ld.so dynamic string tokens like `${PLATFORM}`. Unfortunately, we were creating symbolic links pointing to paths like /overrides/x86_64-linux-gnu/vdpau (no "lib" infix) rather than the correct /overrides/lib/x86_64-linux-gnu/vdpau, so the VDPAU driver would not actually have been found. Fixes: 4f3d2d4b "pv-runtime: Delegate setup of VDPAU to pv-adverb" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 15, 2024
-
-
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:
Simon McVittie <smcv@collabora.com>
-