- Aug 03, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Use more glibc executables from provider when appropriate See merge request !344
-
- Aug 02, 2021
-
-
Simon McVittie authored
Resolves: T29581 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
runtime: Delete overridden libraries from the correct "mesa" path See merge request !342
-
Ludovico de Nittis authored
g_string_replace: Backport from GLib See merge request !343
-
Simon McVittie authored
Note that this implementation does not cope gracefully with zero-length patterns (https://gitlab.gnome.org/GNOME/glib/-/issues/2452 ) so we should be careful not to use it like that. For the use-case that I have in mind, that won't be a problem. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 29, 2021
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
flatpak-exports: Update to flatpak 1.11.2 See merge request !341
-
- Jul 28, 2021
-
-
Simon McVittie authored
With the previous two commits, we are in sync with 1.11.2. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
/usr/local points to ../var/usrlocal on Fedora Silverblue. Originally Flatpak commits 3aaea7d2 and 97d1eb84, thanks to Casey Jao and Alexander Larsson. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Originally commit 08f69296 in Flatpak. Thanks to Phaedrus Leeds. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
tests: Link pressure-vessel tests to static libsteam-runtime-tools See merge request !340
-
Simon McVittie authored
We were linking these both statically and dynamically, so it's anyone's guess which one would end up implementing each symbol. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes it consistent with what we do when building official packages. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Update libcapsule to v0.20210728.0 See merge request !339
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 22, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pv-runtime: Don't rewrite /nix/store/... to /run/host/nix/store/... See merge request !336
-
Simon McVittie authored
Previously, we assumed that if OS files on the provider are in a location that is not /usr or a related directory, for example if the OS has /lib/ld-linux.so.2 -> /some/odd/path/i386/ld.so, then they will appear below the same path_in_container_ns as /usr, for example /run/host/some/odd/path/i386/ld.so. However, nothing sets this up for directories other than /usr, /lib*, /bin, /sbin and /etc, so it's a bad assumption. A previous commit handled /etc by redirecting it to /run/host/etc, /run/parent/etc or /run/gfx/etc as appropriate, so we don't need to worry about that here. For the rest, assume that if they appear in the container at all, they'll appear at a path that matches their location in the provider. For the common case where provider = host, which is the only one where we really need to support non-FHS layouts, this means that users can work around lack of explicit support for a particular non-FHS directory with something like PRESSURE_VESSEL_FILESYSTEMS_RO=/some/odd/path. In particular, if we didn't have explicit support for /nix, NixOS users would have been able to use that workaround to get it mounted. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the realpath() of an OS file is below /etc, each of our code paths ends up with it visible below /run/host/etc, /run/parent/etc or /run/gfx/etc, as appropriate. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We must expose /nix in the sandbox as /nix, not /run/host/nix, because hard-coding paths below /nix is ubiquitous on NixOS. There's already a special case in wrap.c to mount /nix read-only. This resolves a regression that occurred when we switched to a runtime structure that relies on PRESSURE_VESSEL_COPY_RUNTIME. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/431 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 21, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 20, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Adjust LD_PRELOAD and LD_AUDIT to prevent ELF warnings See merge request !333
-
Simon McVittie authored
Optionally run each pressure-vessel game in a systemd scope See merge request !328
-
Simon McVittie authored
This neatly separates the processes for the game (which can be numerous, for example for Proton games that need to run wineserver and winedevice.exe) from the processes for Steam. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Taken from Flatpak 1.11.2. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
When a game is launched with the Steam Overlay feature enabled (it's on by default), we end up with an LD_PRELOAD that contains `gameoverlayrenderer.so` two times, one for 32-bit and the other for 64-bit processes. However this leads to a warning that is harmless but scary for users and developers unaware of that: `ERROR: ld.so: object '/home/me/.local/share/steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.` And every 64-bit process prints something similar about the ELFCLASS32. By creating a temporary directory and using the dynamic linker token expansion `$PLATFORM` we can let a process preload only the `gameoverlayrenderer.so` for the right ABI. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
pressure-vessel: Remove the concept of "locking" environment variables See merge request !329
-
Ludovico de Nittis authored
runtime: Look for NVIDIA driver data in /usr/share/nvidia first Closes #73 See merge request !335
-
Simon McVittie authored
This was only necessary because we were reusing a single container across multiple entry-point invocations, and expecting "most" arbitrary environment variables from each new invocation to be taken into account for commands running in the container, which meant that we needed to keep track of which environment variables had to be exceptions to that rule for technical reasons. Now that we're no longer injecting multiple commands into the same container like that, we don't need this complexity. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we have libGLX_nvidia.so.0 for *any* architecture - even if we are msising some instances - then we still want to share /usr/share/nvidia with the container. Because we always use libGLX_nvidia.so.0 from the graphics stack provider and do not have a concept of whether it is older or newer, and we do not expect our runtime to have a copy of libGLX_nvidia.so.0, we do not need to worry about giving the runtime's library an incompatible version of the data files from the provider. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The NVIDIA driver hard-codes /usr/share/nvidia even if it is installed in /opt or something, so instead of deriving ${prefix} from the library path and then checking for ${prefix}/share/nvidia followed by /usr/share/nvidia as a fallback, we do the opposite: check for /usr/share/nvidia first, followed by ${prefix}/share/nvidia as a fallback. Signed-off-by:
Simon McVittie <smcv@collabora.com> Resolves: #73 (T29292)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-