- Jul 28, 2021
-
-
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>
-
- Jul 19, 2021
-
-
Simon McVittie authored
runtime: try to bind /etc/nvidia and /usr/share/nvidia Closes #73 See merge request !334
-
- Jul 14, 2021
-
-
Ludovico de Nittis authored
If we have libGLX_nvidia.so.0 from the provider, we should also bind `/etc/nvidia` and `/usr/share/nvidia` because they usually contain the application profiles. http://us.download.nvidia.com/XFree86/Linux-x86_64/470.42.01/README/profiles.html#ApplicationProf9ccbe Fixes: #73 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 05, 2021
-
-
Simon McVittie authored
Add licensing information in REUSE format See merge request !332
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 02, 2021
-
-
Simon McVittie authored
tests: Make sure artifacts directory is shared with container See merge request !331
-
Simon McVittie authored
If the artifacts directory is a symlink (or has a symlink in one of its parents) then we need to make sure that both the symlink and its target get shared with the container. We have code for that; use it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Reference: https://reuse.software/ 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 01, 2021
-
-
Simon McVittie authored
We exercise scout via the .deb packaging, there's little point in doing a redundant set of builds. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-