- Jun 08, 2021
-
-
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>
-
- 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
This is helpful when trying to reduce this time by parallelizing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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 no longer used. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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>
-
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
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>
-
Simon McVittie authored
We now use our own check-vulkan executable instead of vulkaninfo, because it can give us more machine-readable information about non-default GPUs. A side benefit is one less dependency. 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 19, 2021
-
-
Simon McVittie authored
This avoids the depot being a mixture of source files and generated files. Signed-off-by:
Simon McVittie <smcv@collabora.com> (originally steamlinuxruntime@f36fbcda)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> (originally steamlinuxruntime@3f821430)
-
(originally steamlinuxruntime@fa634281)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> (originally steamlinuxruntime@13ae83de)
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com> (originally steamlinuxruntime@0c0e1b3a)
-
- Apr 16, 2021
-
-
Simon McVittie authored
We did this as a very early prototype, but it never fully worked, and required configuring Flatpak specially to allow Steam to escape from the sandbox (which obviously undermines Flatpak's intended sandboxing). Now that we've implemented the features we need in Flatpak's sub-sandboxing code, we have a better way to handle this, and can simplify the code by not trying to have it both ways. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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>
-
Simon McVittie authored
The Steam Flatpak app can't have this property set by default until the Flatpak version used to build apps on Flathub's buildbot supports it, but we need it (either that or --device=shm, but --device=shm weakens the sandbox). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Everything we need is in Flatpak git master now, so we don't need to allow for people who have patched their Flatpak with my WIP versions of the same code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-