- 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>
-
- Apr 28, 2021
-
-
Simon McVittie authored
If we are operating from ./scout_platform_x.y.z, self->id will be NULL. Instead of matching on the names of directories, we can just check whether the deployment we are going to use is the same file (device and inode number) as the old deployment we are considering deleting. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 27, 2021
-
-
Simon McVittie authored
SrtSystemInfo is not thread-aware, but can safely be handed off from one thread to another, and caches its results internally; so we can use a thread per architecture, plus an extra thread for cross-architecture Vulkan and EGL ICDs, to enumerate graphics drivers and populate the cache in parallel with any other container setup. We join the threads just before looking at their results, to maximize the length of time for which we're running in parallel. On slow hardware (Lenovo T520 circa 2011, with 500G 7200rpm HDD) this cuts something like 20% off the setup time with a cold cache (`echo 3 | sudo tee /proc/sys/vm/drop_caches`). It also has a benefit (more like 15%) with a warm cache, immediately after a previous pressure-vessel run. This does make it somewhat harder to profile pressure-vessel, because when two I/O-bound operations run in parallel, they both take longer than they otherwise would, even though the overall task finishes sooner; this makes it hard to attribute I/O cost to particular actions. The new --single-thread option can be used to get a better idea of where the time is really going. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This encapsulates both the PROVIDER_GRAPHICS_STACK flag and the associated paths: if the object is null then the paths are meaningless, and if the object is non-null then they are meaningful. Making this an immutable "value object" also means we can share it between threads, unlike PvRuntime, which has state. This could become important if we want to make graphics driver enumeration multi-threaded to speed up pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Unset SDL_VIDEODRIVER if it was previously set to "wayland", when we are in a Scout SteamLinuxRuntime, because Scout is too old to support Wayland. This is not necessary for Soldier or Sniper because we expect it to be working for them. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Apr 26, 2021
-
-
Simon McVittie authored
There's no point in doing this when we aren't going to use them. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 22, 2021
-
-
Simon McVittie authored
This is surprisingly expensive to do, particularly with a cold cache. If we can avoid this, then deleting unwanted libraries from the mutable copy of the runtime becomes a lot faster. With the disk cache cleared and running on slow hardware, this cuts down deletion of the unwanted libraries from 2-4 seconds to basically instantaneous. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Some development libraries follow this pattern, and we already delete those without needing to use libelf to load the library and find out its SONAME: libfcitx-config.so -> libfcitx-config.so.4 libfcitx-config.so.4 -> libfcitx-config.so.4.1 libfcitx-config.so.4.1 However, other libraries follow this pattern, which results in the code that uses libelf to find the SONAME being the only way we can figure out that the .so symlink needs removing: libdbus-glib-1.so -> libdbus-glib-1.so.2.2.2 libdbus-glib-1.so.2 -> libdbus-glib-1.so.2.2.2 libdbus-glib-1.so.2.2.2 To avoid relying on the libelf code path, which is surprisingly slow when run with a cold disk cache, we can do one scan through the directory removing regular files and runtime symlinks, and a second scan through the directory removing development symlinks that have become dangling as a result. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If libfoo.so.0 is a symlink pointing to libfoo.so.0.1.2, and we have overridden libfoo.so.0, then we can know that libfoo.so.0.1.2 is also to be avoided, even without opening it to determine its SONAME. This reduces the need to use libelf, which is surprisingly slow if the disk cache is cold. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we got libbz2.so.1.0 from the host, for which libbz2.so.1 is an alias, we will also want to remove libbz2.so.1 from the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The comments here are not really clear enough to express what's going on, particularly in the presence of libraries that have aliases. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We need to 'goto out' to free some arrays of objects, which are too complicated for `__attribute__((__cleanup__))`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As well as making this giant function a bit smaller, this will make it easier to insert profiling markers to see where the time goes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 21, 2021
-
-
Simon McVittie authored
These refer to the host, but in a Flatpak subsandbox environment the graphics stack provider is not actually the host. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 20, 2021
-
-
Simon McVittie authored
We don't actually need this information, and it has a significant startup time cost with a cold cache. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 16, 2021
-
-
Simon McVittie authored
At the moment we assume it's just "bwrap" when using Flatpak, but when we stop supporting the Flatpak sandbox escape code path, that will become meaningless. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 13, 2021
-
-
Simon McVittie authored
Since !269, on systems where PulseAudio is available, we set PULSE_SERVER to a suitable non-empty value, and "lock" it into the environment to avoid it getting overridden by pressure-vessel-launch (in use-cases where we're using that). We also create an /etc/asound.conf in the container's namespace that will make PulseAudio the default for applications that use the ALSA user-space library libasound.so.2, such as Shadowrun Returns. Conversely, on systems where PulseAudio is *not* available (for example where the system is using plain ALSA), we "lock" PULSE_SERVER to a null value so that we will actively remove it from the environment if set. However, this caused a regression: we created /etc/asound.conf based on whether PULSE_SERVER was "locked", which effectively meant this was done unconditionally. An /etc/asound.conf that configures PulseAudio to be the default is not going to work on non-PulseAudio systems. Instead of checking whether PULSE_SERVER is "locked", check whether it's null. This has the desired effect: we configure PulseAudio to be the default if and only if we detected that it's available. Helps: https://github.com/ValveSoftware/steam-runtime/issues/344 Helps: https://github.com/ValveSoftware/steam-runtime/issues/384 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
libdrm.so.2 is not included in the freedesktop.org GL Platform runtime and this leads us to search for the libdrm directory in the wrong place. For this reason we first look at libdrm_amdgpu.so.1 and use libdrm.so.2 as a fallback. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
When we are in a Flatpak environment there are two issue: - It's common to have multiple data directory, usually one for every multiarch - If we bind the data directory in "/usr/share/${dir_basename}" there is no guarantee that it will be in the library search path For this reason we avoid raising a warning if we have multiple data directory and also we bind them preserving their original path. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
If we modify "/app" we want to bind it to the new subsandbox instead of always binding an empty directory. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
When we are in a Flatpak environment there are two issue: - It's common to have multiple data directory, usually one for every multiarch - If we bind the data directory in "/usr/share/${dir_basename}" there is no guarantee that it will be in the library search path For this reason we avoid raising a warning if we have multiple data directory and also we bind them preserving their original path. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
If we modify "/app" we want to bind it to the new subsandbox instead of always binding an empty directory. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Apr 09, 2021
-
-
Ludovico de Nittis authored
When we are in a Flatpak environment we want to pick "localedef", "locale" and "ldconfig" from the Flatpak runtime instead of the ones provided by Scout/Soldier. By searching in the "provider_in_current_namespace" we can ensure to create a subsandbox where these executables are symlinked to the "/run/parent" counterpart. Fixes: T27438 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
When we search for gconv in the provider, if the directory we derived from libc starts with "/app/", we should not prepend "/usr/" because we don't expect to have "/usr/app/" in the provider. Without this patch, pressure-vessel in a Flatpak container fails to load i386 gconv with the following message: "We were expecting the gconv modules directory in the provider to be located in "/app/lib/i386-linux-gnu/gconv", but instead it is missing" Fixes: T27437 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 17, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
When using Exherbo as the host system, the locales are located in "/usr/${gnu_tuple}/lib/locale". For this reason if we notice that the canonical "/usr/lib/locale" is missing, we also try the Exherbo's paths before skipping it. Partially addresses: #67 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
This fixes two separate issues: * It's parsed by all known versions of libasound.so.2, so it will work for both Steam Runtime 1 'scout' and Steam Runtime 2 'soldier', as well as future runtimes. Previously, we were using a path that only works in runtimes newer than scout. * It's a direct child of /etc, which in our case is a tmpfs, so we don't need to worry about whether we will be able to create a mount point in a subdirectory. Fixes: 1b720eb7 "wrap: Set PulseAudio as the default ALSA driver if available" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, the first time we use a particular runtime, GC will fail with a user-visible warning. We're going to create the variable directory moments later anyway, so this should be no big deal. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
If the host system stores the shared libraries in a directory that is not what we expect, we try as a last resort `/usr/share`, in an effort to increase the number of OSs that we are able to cover. For example this should help Exherbo to find the right libdrm and drirc.d directories. Fixes: #68 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 16, 2021
-
-
Ludovico de Nittis authored
If a library has different SONAMEs, called aliases in "steam-runtime-abi.json", it might lead to errors when a game tries to load a SONAME that is not the "real" library SONAME (the DT_SONAME that objdump shows). Because `ld.so.cache` will not consider the aliases when searching for the right match. To workaround this problem we create a directory called "aliases" that contains symlinks of the libraries aliases that we know about. By adding these directories, one for every multiarch, in the `LD_LIBRARY_PATH`, we ensure that even games that were linked to an alias will be able to find the library they were looking for. Helps: https://github.com/ValveSoftware/steam-runtime/issues/246 Fixes: T26816 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 04, 2021
-
-
Simon McVittie authored
When using Primus/Bumblebee, having this available is apparently enough for at least some games to work, and having this not available will result in the driver failing to load. Note that Primus/Bumblebee is not really supported by any of the GPU or driver vendors. Using PRIME render offloading (DRI_PRIME=1 for open-source Mesa drivers, __NV_PRIME_RENDER_OFFLOAD=1 for the proprietary NVIDIA drivers) is likely to work more reliably. Helps: https://github.com/ValveSoftware/steam-runtime/issues/372 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 03, 2021
-
-
Ludovico de Nittis authored
Respect the `STEAM_COMPAT_FLAGS` values in pressure-vessel. Currently the only expected flag is `search-cwd` that is used to append the game current working directory, stored in `STEAM_COMPAT_INSTALL_PATH`, to the `LD_LIBRARY_PATH`. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/371 Fixes: #46 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 26, 2021
-
-
Simon McVittie authored
Flatpak subsandboxes don't have sufficiently powerful control over the container to use bubblewrap or FlatpakExports directly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
My Flatpak branch puts it at /run/parent/app, alongside /run/parent/usr. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is experimental and subject to change. It requires branches of Flatpak that have not yet been reviewed or merged, so it's guarded by (deliberately undocumented) environment variables by default. Only enable this if you are a pressure-vessel developer and know precisely what you're doing. This feature also requires a non-setuid bwrap executable, and a kernel that allows the non-setuid bwrap to create new user namespaces. Fedora, Ubuntu, Debian >= 11, and Arch Linux's default kernel are examples of systems that should be OK; Debian <= 10, SteamOS 2, and Arch Linux's linux-hardened are not. I'm landing this despite its experimental status because leaving it in a branch means we have to rebase it all the time, which just slows us down. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-