- Mar 16, 2021
-
-
Ludovico de Nittis authored
Features without tests can easily regress. For this reason we added a check about the directories that we expect to have inside the container when we don't share the home directory. And we also compare the "steam-installation" issues of the container srsi with the one on the host. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 22, 2021
-
-
Ludovico de Nittis authored
If we don't have duplicated ICDs/Layers in the host system, we want to be sure that this holds true also inside a container. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 12, 2021
-
-
Simon McVittie authored
This is a container-manager-agnostic version of probing /.flatpak-info and /run/pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 11, 2021
-
-
Simon McVittie authored
Clear Linux uses the same cross-architecture ld.so.cache as most distributions (Debian, Fedora, etc.), but puts it in /var/cache/ldconfig to meet their goal of /etc being empty. Create a symlink so that when their glibc tries to load that filename inside the runtime, what it gets is the runtime's /etc/ld.so.cache. Exherbo uses a ld.so.cache per architecture, which we added to a table of known per-architecture ld.so.cache filenames in commit c10e8831. Create symlinks for those too, similar to the Clear Linux case; this has not yet been verified to work, but it can't hurt. It's looking as though NixOS might be adding a Nix-specific filename for the ld.so cache (currently they don't have one at all). When that happens, we can add it to the same array as the Clear Linux filename. Other distributions that turn out to need this can be treated like Clear Linux if they share one cache between all architectures, or like Exherbo if they have a separate cache per architecture. Partially addresses <https://github.com/ValveSoftware/steam-runtime/issues/345>, which also needs <https://gitlab.collabora.com/vivek/libcapsule/-/merge_requests/43>. Also partially addresses <https://github.com/ValveSoftware/steam-runtime/issues/230 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 14, 2020
-
-
Simon McVittie authored
These are drivers for which our best guess is that the native loader would not actually load them. We want to include them in steam-runtime-system-info's diagnostic output in case we are wrong, but we don't want to include them in the container: if our guess is correct, then the host system doesn't actually load them, and the worst-case scenario is that they are somehow broken, in which case adding them to the search path might *break* the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 21, 2020
-
-
Ludovico de Nittis authored
Setting STEAM_RUNTIME=/ caused configuration changes in libraries like Pango and GTK, which broke module loading when not in the LD_LIBRARY_PATH Steam Runtime. We updated the affected libraries' search paths so it is safe now to reimplement the STEAM_RUNTIME change. This reverts commit dc71943a and reapplies commit eb716698. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 09, 2020
-
-
Simon McVittie authored
This avoids them colliding with steam-runtime-tools' tests. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2020
-
-
Simon McVittie authored
This should go some way towards resolving failures to run games ported by Feral Interactive, which explicitly check that they have been run by Steam. See <https://github.com/ValveSoftware/steam-runtime/issues/202> and <https://github.com/ValveSoftware/steam-runtime/issues/249 >. Resolves: pressure-vessel#8 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 09, 2020
-
-
Simon McVittie authored
This is included in prerelease versions of SteamRT 2 'soldier', but because it uses the post-gcc-5 C++ ABI of libLLVM-7.so.1, it's incompatible with versions of libLLVM-7.so.1 that were compiled to be compatible with the gcc 4 C++ ABI, and in particular the one in SteamOS 2 'brewmaster'. This and the previous commit are sufficient to make tests/containers.py pass on SteamOS 2 'brewmaster', if we also configure libxcb.so.1 to be chosen by counting symbols (T22538) and libgcc_s.so.1 to be chosen by counting verdefs (T16561). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
For the moment, this is basically scout with fewer guarantees: we can't assume whether the host glibc is newer (like Arch Linux or Ubuntu 20.04) or older (like SteamOS 2 'brewmaster'). Only tested successfully on Debian testing/unstable, for now. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 17, 2020
-
-
Simon McVittie authored
Flatpak is not going to give us control over the root directory when using sub-sandboxing - the most we're likely to get is control over which directory is chosen to be /usr. Prepare for this by using /usr/lib/pressure-vessel/overrides instead of /overrides for the things we overwrite. To be nice to developers and steam-runtime-tools, put a symlink overrides -> usr/lib/pressure-vessel/overrides at the root, as a hint for where to look. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
A possible future enhancement would be to have an option to mount some of these (those that live in the mutable sysroot) read/write, but for now any ad-hoc developer modifications will have to happen outside the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 16, 2020
-
-
Simon McVittie authored
Workaround for T21931. Fully fixing this is low-priority, because we have been removing libldap dependencies anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 12, 2020
-
-
Simon McVittie authored
This requires resources external to pressure-vessel, and makes some assumptions about the container - but that's OK, because the first significant user of pressure-vessel is Steam Runtime 1 'scout', which is not exactly a moving target. We also do some of these checks in various OSs' virtual machines when we build Steam Runtime releases, but having this in-tree with the pressure-vessel source should shorten the testing cycle. See the doc-comment in tests/containers.py for usage. At the moment all tests require a working version of bubblewrap, but current/future work in the direction of pre-preparing a modified runtime on disk should mean that we can do a subset of these tests even if we cannot run bubblewrap. In particular, if we can do that inside a Docker container, that will make it a lot easier for CI to validate our assumptions on non-Debian-derived host operating systems. Attentive reviewers will notice that there's infrastructure here to be able to skip generating locales, but it isn't yet used. It will be used when we have more variations on the theme of "enter a scout container and run inside-scout.py", to avoid the time cost of generating locales every time - but at the moment we only have two runs, so the time taken to generate locales is not problematic. This test is a bit slow, and it's going to get slower as we add more thorough testing, so increase its timeout away from the Meson default. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-