- Feb 10, 2020
-
-
Simon McVittie authored
Add --test command line argument to pressure-vessel-wrap. See merge request steam/pressure-vessel!19
-
- Feb 03, 2020
-
-
Jeremy Whiting authored
When --test is used check for bubble wrap executable and return 0 if found, 1 otherwise.
-
- Jan 08, 2020
-
- Jan 07, 2020
-
-
Simon McVittie authored
wrap: Don't pass --lock-file to bwrap See merge request steam/pressure-vessel!18
-
- Jan 06, 2020
-
-
Simon McVittie authored
Non-OFD locks don't propagate across fork(), and bwrap needs to clone() itself (which behaves like fork() in this respect) to separate itself into a parent outside the container and a child inside the container. This change adds a weak dependency on Linux 3.15. If we run on an older version, everything should still *work*, but there will be a short period of time during which we have already decided to use the runtime, but it is not locked (and in particular not protected from deletion). Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These more modern locks, introduced in Linux 3.15 and not yet included in POSIX, propagate across fork(), dup(), fd-passing etc. the way you'd expect: as long as at least one copy of the inherited or fd-passed file descriptor remains open, the lock remains held. This allows us to pass a lock fd to a child process across bwrap's fork-and-exec the way we were already trying to, and have it actually work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is redundant with us passing the fd to be held by pressure-vessel-with-lock, and it causes bwrap to produce the wrong exit status (see https://github.com/containers/bubblewrap/issues/336 and https://github.com/containers/bubblewrap/pull/325 ). It should have been removed when the "pass the lock fd" code path was added. Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 16, 2019
-
-
Simon McVittie authored
Enable AddressSanitizer, UndefinedBehaviourSanitizer See merge request steam/pressure-vessel!14
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
wrap: Mount pressure-vessel on /run/pressure-vessel if using runtime See merge request steam/pressure-vessel!17
- Dec 13, 2019
-
-
Simon McVittie authored
When we're using a non-trivial runtime, we need to make pressure-vessel-with-lock available to the container. Previously, if your pressure-vessel installation was visible via your home directory (if shared), via $(realpath ~/.steam/steam), or via the current working directory at the time of running pressure-vessel-wrap, then it would exist in the container at the same path as outside the container, so this would work. However, if you have installed it in an alternative Steam library such as /media/big/library, none of these mount points would make it visible and bwrap would fail to run it. Circumvent this by mounting the relocatable pressure-vessel prefix on /run/pressure-vessel, which lets us run it via that path. Bug: https://github.com/ValveSoftware/steam-runtime/issues/204 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 15, 2019
-
-
Simon McVittie authored
Add fcntl locking See merge request steam/pressure-vessel!10
- Nov 14, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can use this in the SteamLinuxRuntime depot to deploy and garbage-collect runtimes stored in tarballs. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we upgrade from runtime 0.20191024.0 to 0.20191108.0 while an app or game is still running under runtime 0.20191024.0, then deleting the app or game's shared libraries out from under it will probably break it. Flatpak solves this problem with a read/write lock on the file `files/.ref` - for runtimes this is `/usr/.ref` in the container. Each instance of `flatpak run` takes a read-lock on that file. Any number of processes can hold a read-lock at the same time. Before a package-manager-style operation like `flatpak uninstall` does anything destructive to a runtime, it takes a write-lock, which only succeeds if there are currently no read- or write-locks. Depending on the operation, the lock is either taken directly or by asking bubblewrap to do it. We'll use the same scheme. Different families of locking APIs interact unpredictably, so it's important that we use the same locking API as bubblewrap, namely POSIX byte-range (record) advisory locks via fcntl F_SETLK. In particular, this means flock(1) and flock(2) are not going to help us: they use POSIX file-level advisory locks. One difference between our locking and flatpak's is that we support runtimes that are not "merged /usr". In this case, we could either take a lock on files/.ref (/.ref in the container) or on files/usr/.ref (/usr/.ref in the container). I've chosen to do the former here, so that it's always files/.ref. It doesn't matter, as long as we're consistent. (For apps the lock file is `/app/.ref` and for extensions it's `$mountpoint/.ref`, but pressure-vessel doesn't have an equivalent of Flatpak apps or extensions yet.) This version is only a partial solution. We can't use bwrap --lock-file or bwrap --sync-fd without also using --unshare-pid, which breaks gameoverlayrenderer.so; so we do the next best thing, by leaking the lock fd to the bubblewrap process, which will leak it to the game's main process. This won't work if the game forks background processes, but it's good enough for a straightforward execve() chain. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is inspired by `ostree --version` and `docker version`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of {0, 0}, represent the absence of a short option with '\0' and the absence of flags with G_OPTION_FLAG_NONE. To support older GLib, provide a compatibility definition for the latter. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 12, 2019
-
-
Simon McVittie authored
Enable and squash compiler warnings See merge request steam/pressure-vessel!11
-
Simon McVittie authored
This might give us more/different compiler warnings. 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
We assume that GArray aligns memory "nicely". Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Detected by scan-build. 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 ensures that we include it in every translation unit. Rename it to _pressure-vessel-config.h to avoid accidentally including the wrong config.h in the presence of submodules. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's inconsistent to ask for this in warning_cflags, and immediately disable it in no_warning_cflags. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
libglnx assumes gcc/clang extensions to variadic macro syntax. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're using GLib, and GLib explicitly doesn't support pedantic Standard C compilers: it assumes and requires the ability to cast between function pointers and data pointers. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Getting warnings when an unlikely code path isn't inlined is not actually very interesting for fixing bugs. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Go back to non-native versioning See merge request steam/pressure-vessel!15
-
Simon McVittie authored
Versioning pressure-vessel as a native package interacts poorly with the combination of the Open Build Service pseudo-binNMU suffix and the deb-build-snapshot tool used for prereleases: 0.20190927.0+7+g1234567+srt1 is less than 0.20190927.0+srt1, so 0.20190927.0 would wrongly be preferred over the prerelease at commit 1234567, 7 commits later than 0.20190927.0. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids needing to install steam-runtime-tools there if we want to run "ninja dist". Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
https://gitlab.gnome.org/GNOME/libglnx/merge_requests/13 upstream. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-