- Jul 29, 2021
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- 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>
-
- Jul 22, 2021
-
-
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
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>
-
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)
-
- 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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 01, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 30, 2021
-
-
Simon McVittie authored
In particular this lets us gather detached debug symbols from the generated -dbgsym packages. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 24, 2021
-
-
Ludovico de Nittis authored
It has been reported that `nvidia-modprobe -u` might not be enough to enable the Nvidia Vulkan ray-tracing: https://github.com/HansKristian-Work/vkd3d-proton/issues/711 Apparently `nvidia-modprobe` needs to be called with the option `-c=0` such that it will create the `/dev/nvidia-uvm` device file if it doesn't already exist. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jun 17, 2021
-
-
Simon McVittie authored
This can be the case on older sysvinit- or Upstart-based Debian-derived distributions, such as Ubuntu 14.04 (with the default Upstart init system) and Debian 9 (with the non-default sysvinit init system). Under systemd or the versions of sysvinit in Debian >= 10, /dev/shm is a real tmpfs and /run/shm is a symlink to /dev/shm. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
bubblewrap mounts filesystems recursively, so mounting /dev is enough, unless /dev/shm is a symbolic link (which will be handled in a subsequent commit). /dev/pts is assumed not to be a symbolic link: there would be no reason to do so. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 15, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 10, 2021
-
-
Ludovico de Nittis authored
Since the commit fce30b8d, this variable was not used anymore. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This commit addresses most of the warnings printed at compilation time while using clang and `ninja scan-build`. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jun 08, 2021
-
-
Simon McVittie authored
The nochange flag is fully implemented here: it suppresses changing the modification time or permissions. The optional flag is mostly implemented here: it suppresses the error that would ordinarily occur if a file with content does not already exist. The ignore flag is not yet implemented, only parsed, because it only really applies when verifying whether a filesystem tree matches a specification. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
time=1.234 has historically meant 1 second + 234 nanoseconds, or what normal people would write as 1.000000234. Parse it as such, but for now treat this ambiguous format as an error, unless the fractional part is exactly ".0" which is unambiguous - we can relax this to a warning later, if we want to. libarchive and FreeBSD mtree show mtimes with exactly 9 decimal digits, which makes them mean the same thing in either interpretation. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
libarchive allows both, although FreeBSD and NetBSD mtree do not. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When combined with changes to SteamLinuxRuntime scripts, this will let us do a new pressure-vessel release and incorporate it into soldier/sniper/etc. depots, without having to do a whole release of scout to provide the new pressure-vessel. These releases don't include anything that we didn't already publish in Gitlab artifacts, and they're relatively small, so they might as well be public immediately (unlike the full scout releases, which we avoid publishing before they are final, both because they are rather large and because game developers could get compatibility issues if they build against a non-finalized scout runtime). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 07, 2021
-
-
Simon McVittie authored
Unusually, libblkid1 and libmount1 have different copyright files despite being from the same package. Ship both. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 25, 2021
-
-
Ludovico de Nittis authored
When inside a Flatpak container, we expect that `libshared-library-guard.so` looks for its blocklist configuration in `/app/etc/freedesktop-sdk.ld.so.blockedlist`. This will not work because we bind `/app` in `/run/parent/app`. For this reason, when we detect this situation, we set the environment variable `SHARED_LIBRARY_GUARD_CONFIG` to point `libshared-library-guard` in the correct path. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- May 20, 2021
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- May 17, 2021
-
-
Simon McVittie authored
This gives us direct access to Pipewire using its native protocol, similar to the direct access we already have to PulseAudio, X11 and Wayland. In a Flatpak subsandbox, applications will have to go via xdg-desktop-portal instead, as they do for any other Flatpak app. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 12, 2021
-
-
Simon McVittie authored
This function was originally written for pressure-vessel and subsequently added to Flatpak. If we use Flatpak's version, we can stay closer to being in sync with Flatpak's flatpak-utils.c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 11, 2021
-
-
Simon McVittie authored
By including this in libsteam-runtime-tools-0-helpers, we reduce the number of modules we need to manage and keep in sync. The rest of libcapsule isn't actively used yet, so this is a significant simplification. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 07, 2021
-
-
Simon McVittie authored
This is slightly simpler, and makes it easy for PvRuntime to locate tools in the helpers path (libexec/steam-runtime-tools-0) too. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 30, 2021
-
-
Simon McVittie authored
At the moment we deploy the runtime from a giant tarball to avoid Steam downloader limitations, but that leads to a noticeable delay the first time we launch a game after a new runtime version has been downloaded. Now that the Steam download mechanism can deal better with larger numbers of smaller files, we're considering returning to the original design where the runtime depot contains unpacked files. However, the Steam download mechanism doesn't preserve permissions, modification times, or filenames that differ only by case, and has not always preserved empty directories, so we need a way to deal with all of those things. By reading a manifest written in a subset of the BSD mtree(5) format, we can create directories and symlinks, and set permissions modification times on regular files. As a bonus, it's actually slightly faster to duplicate a runtime with hard-links (--copy-runtime mode) by reading the manifest than by reading the actual directory tree, because the manifest is more likely to be contiguous on disk. In principle the mtree(5) manifest could also be used to validate that the runtime content has not become corrupted by checking files against their sha256sums. This isn't implemented here (and it would have to be done only on demand rather than routinely, because it would be slow), but the parser does at least read the sha256. In the tests, we now need to remove the mtree manifest when copying and editing a runtime. When we edit a runtime in-place, it no longer conforms to the manifest, so this can't necesarily be expected to work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This can be used to create directories, symlinks and zero-byte files, create files as a clone (hard-link or copy) of files in a reference directory, assert that files exist, set executable/non-executable permissions, and set files' modification times. When cloning files from a reference directory, the default is to use the same filename as the destination, but that can be overridden (for example to deal with inconvenient/non-Windows-friendly filenames). This is also actually slightly faster than pv_cheap_tree_copy(), presumably because the manifest is contiguous on-disk and the directories are not necessarily. Setting directories' modification times is implemented, but probably won't work in practice, because any files we create in the directory will alter its mtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-