- Jul 08, 2020
-
-
Simon McVittie authored
Pass --library-knowledge to capsule-capture-libs See merge request steam/pressure-vessel!56
-
Simon McVittie authored
For runtimes that support it, this gives us a way to override library comparisons. In particular, we can make sure libgcc_s.so.1 is compared by its version-definitions and symbols. (T16561, T16562) Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This doesn't currently include the --dest because that varies - it's usually arch->libdir_on_host, but not always. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
runtime: Add arguments to the right bwrap invocation See merge request steam/pressure-vessel!57
-
Simon McVittie authored
Mount Steam "compat tool" directories See merge request steam/pressure-vessel!55
-
Simon McVittie authored
When we're entering the container to generate locales, we need to bind-mount the staging area for /overrides in *that* bwrap invocation, not add it as a bind-mount to the bwrap invocation that will actually run the game. Fixes: 5e2f9f25 "runtime: Bind-mount /overrides to run locale-gen" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, any test that refers to the username or home directory will fail with a warning. Prior to GLib 2.35.9 (in particular, in GLib 2.32) this happens in g_get_any_init_do(), which is also called to get the TMPDIR, so any test that wants to create a temporary directory will fail like this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
- Jul 02, 2020
-
-
Simon McVittie authored
This is necessary for Steam "compat tools" such as Proton. STEAM_COMPAT_DATA_PATH points to data associated with the current (compat tool, game) pair, for example the ${WINEPREFIX}. STEAM_COMPAT_TOOL_PATH doesn't exist yet, but I'm assuming that it will be set by some later version of the Steam client to point to Proton itself. STEAM_COMPAT_CLIENT_INSTALL_PATH points to the Steam installation. This is hopefully in the home directory, so hopefully we bind-mount it anyway; but if we don't, we should. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is desirable if we are running something other than the main game, for example steam-runtime-system-info or various preparatory steps involved in running Proton. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 24, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
- Jun 23, 2020
-
-
Simon McVittie authored
Follow-ups for !26 See merge request steam/pressure-vessel!54
-
Simon McVittie authored
runtime: handle merged-/usr host OS with non merged-/usr container See merge request steam/pressure-vessel!53
-
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
Because we do a "cheap copy" with hard-links where possible, .ref is a hard-link to its counterpart in the original (non-copied) runtime, so a lock on one is a lock on the other. We hold a lock on the original runtime while we do setup, so we would never actually delete the temporary runtimes unless we break the hard-link by re-creating the lock file. Resolves: T22035 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This log file contains pressure-vessel's debug messages (which happen outside the scout container), not just the output of inside-scout.py, so calling it inside-scout.log is misleading. If we're running pressure-vessel-wrap --only-prepare, then we never actually get as far as running inside-scout.py or entering the container, so the log file name is doubly misleading. 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>
-
Simon McVittie authored
This makes it easier to try out UI changes in the source tree: we can do everything except actually launching pressure-vessel-wrap. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Prioritize "/usr/" over "/lib/" if it is available to avoid issues when we use a non merged-/usr container with a host system that is merged-/usr (Fixes: T22125) Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
This has the advantage of always being an absolute path. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 17, 2020
-
-
Simon McVittie authored
Create a mutable copy of the runtime See merge request steam/pressure-vessel!26
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a mutable sysroot, overwrite ld.so with a symlink into /run/host. We overwrite both the interoperable path (to avoid long chains of symlinks in the common case) and the canonicalized path (to make sure nothing can end up finding the container's ld.so, which is incompatible with the libc we have dropped in). If building a long bwrap command-line, we have to mount over the canonicalized path, and just live with the fact that there will be a long chain of symlinks leading to it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We currently arrange for the overridden libraries to be used by setting the LD_LIBRARY_PATH, but this fails in two cases: - If we want to use the scout LD_LIBRARY_PATH Steam Runtime inside a newer container (approximating how Steam games currently run in practice), it will reset the LD_LIBRARY_PATH instead of prepending to it. - Games also sometimes overwrite the LD_LIBRARY_PATH instead of prepending to it. We can avoid all that by arranging for our directories in /overrides to be in the default search path for ld.so, by editing ld.so.conf and running ldconfig, like Flatpak does (T14481). However, if we do that, we cannot reliably force a resolution order: ldconfig considers the OS ABI tag, which exists on some libraries and in particular on the versions of glibc and Mesa in scout, to be more important than directory search order. See also: https://bugs.freedesktop.org/show_bug.cgi?id=26663 If we don't remove the unwanted version of glibc, we also run the risk of encountering mismatched copies of glibc and ld.so, leading to an immediate crash. This is particularly likely to happen if we use bwrap to enter the partially-set-up container. Because we have a temporary mutable copy of the sysroot, we can solve this easily by deleting the overridden libraries. That way, there can be no confusion: the only remaining implementation of each SONAME is the one we wanted :-) Note that after removing the overridden libraries, we will be unable to execute code in the sysroot without mounting /overrides/lib and setting up the LD_LIBRARY_PATH to point into it: for example, in the common case where we have taken libc from the host, the mutable sysroot no longer contains libc.so.6. This is why it's so important that a previous commit avoided the call to readlink(1) inside the container for the mutable case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we have a mutable copy of the sysroot (which we know is a complete sysroot, not just /usr), then we don't need to use bwrap to rearrange it into something where we can canonicalize a path. 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>
-
Simon McVittie authored
This no longer needs to be read/write, because we make all the changes we are going to make during setup. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The host system is assumed to be at least as new as scout (otherwise nothing will work, least of all pressure-vessel-wrap), so we can assume that the host glibc will be used. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we don't need to alter the PATH in the runtime. If we're using a mutable runtime, we'll delete the version in the runtime and replace it with a symlink to /run/host/usr/bin/locale or similar; if not, we'll bind-mount the host /usr/bin/locale onto it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Because that isn't going to work if you have EGL/Vulkan ICDs installed in your home directory or something, and the JSON file is small, we fall back to copying in this case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Feature parity with the existing code requires that we check for a compatible container: in containers where /usr/share/libdrm is not a directory, this won't work. Beef up the compatibility check a bit so that it checks for directory vs. non-directory generically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-