- Oct 28, 2022
-
-
Simon McVittie authored
If we don't have any better way to choose an implementation, using lexicographic order makes it a little easier to compare log files. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 21, 2022
-
-
Simon McVittie authored
Otherwise, we could end up loading drivers or layers in an unexpected order, with the layer numbered 10 loaded before the layer numbered 2. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 07, 2022
-
-
Simon McVittie authored
Recent Meson versions have warnings if you add the subprojects directory as an include path, because the way Meson wants to consume subprojects is by the subproject's build system producing a Meson dependency object that encapsulates its include directory. libglnx seems to be set up to have the libglnx directory be its include path instead: for example, ostree (by the author of libglnx) already uses "libglnx.h" or <libglnx.h> everywhere. Do the same here. Flatpak equivalent: https://github.com/flatpak/flatpak/pull/4842 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 31, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This requires switching it from flatpak_canonicalize_filename() to g_canonicalize_filename(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The names were confusingly similar, but _srt_util_set_up_logging() was actually orthogonal to pv_set_up_logging(): the former was about the disposition of the stdout and stderr fds, whereas the latter was about the GLib log handler. Rename it to make the difference clearer. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 27, 2022
-
-
Simon McVittie authored
We wrote this, so it's fine to relicense it more permissively, from LGPL to MIT. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 20, 2021
-
-
Simon McVittie authored
g_spawn_check_exit_status() was renamed to g_spawn_check_wait_status() in GLib 2.70 because its name was misleading: the first argument was always a wait-status (the output of wait(), waitpid() or waitid(), encoding either an exit status or a terminating signal) rather than an exit status. Use the modern name in our code. When building for scout or continue to provide our own implementation; when building for anything else older than GLib 2.70, provide a macro to wrap the old, misleading name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 06, 2021
-
-
Simon McVittie authored
PreloadModule is no longer used in pv-adverb, because we needed a different data structure there. Do a similar transformation here. This turns it inside out: instead of what's conceptually map<variable=LD_AUDIT or LD_PRELOAD, values=array<string>> we now have array<struct<variable=LD_AUDIT or LD_PRELOAD, string>> which is a bit easier to deal with in practice. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 03, 2021
-
-
Simon McVittie authored
I think this makes it a bit clearer what's going on: we populate one list (currently a PreloadModule[]) from the command-line options, then translate it to form a second list (in -wrap it's a plain GPtrArray, in -adverb it's implicit in the environment variables we're setting). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 20, 2021
-
-
When a game is launched with the Steam Overlay feature enabled (it's on by default), we end up with an LD_PRELOAD that contains `gameoverlayrenderer.so` two times, one for 32-bit and the other for 64-bit processes. However this leads to a warning that is harmless but scary for users and developers unaware of that: `ERROR: ld.so: object '/home/me/.local/share/steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.` And every 64-bit process prints something similar about the ELFCLASS32. By creating a temporary directory and using the dynamic linker token expansion `$PLATFORM` we can let a process preload only the `gameoverlayrenderer.so` for the right ABI. 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 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>
-
- Apr 22, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 26, 2021
-
-
Simon McVittie authored
These indicate which lines are harmless and which lines are really bad, without taking up too much space. The mapping from GLib log level to message is not 100% obvious, because G_LOG_LEVEL_ERROR is "worse than" an error. We diagnose "can't happen" situations (assertion failures, etc.) as "Internal error". Ideally, users should never see these: they indicate a bug. For situations that will cause pressure-vessel to exit with an error, introduce a new log level flag PV_LOG_LEVEL_FAILURE and map it to the apt-style "E:" prefix. pv_log_failure() is a convenience macro to log at level PV_LOG_LEVEL_FAILURE. Conceptually this is a fatal error, but it's a fatal error prompted by something external to pressure-vessel, for which we want pressure-vessel to clean up "nicely" and exit gracefully, even though it's going to fail - so we can't use g_error() for this. In the parts of main() that involve parsing command-line arguments, add usage_error() as syntactic sugar for pv_log_failure(). I might eventually turn these into G_OPTION_ERROR_FAILED as we factor out more of main() into helper functions, but for now they're handled separately. For less-severe log levels, use single-letter prefixes similar to apt's. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 25, 2021
-
-
Ludovico de Nittis authored
This allows us to reduce the code duplication in pv_bwrap_run_sync(). Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 23, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 13, 2021
-
-
Simon McVittie authored
Previously, pv_capture_output() always inherited pressure-vessel-wrap's own environment, and bwrap->envp was ignored. Thanks to @mawww on Github for spotting this. Fixes: f584a55c "runtime: Don't assume container's env is in the PATH" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 05, 2021
-
-
Ludovico de Nittis authored
This is especially useful when we are logging to a file to keep track of when a specific operation happened. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This is the middle ground between the base logging and the verbose option. Currently we are not logging any messages at the info level, but we might start to do that. And this option gives us more granularity about how much logging we want to print. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Moving this log function to "utils" allows us to avoid a lot of duplication. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Dec 17, 2020
-
-
Simon McVittie authored
To work around older versions of GLib having a potential deadlock in their fd-closing code due to use of non-async-signal-safe functions in the forked child process, the Flatpak-derived code we're using here uses a simple, naive implementation of closing fds: it iterates through every possible fd, up to the rlimit. Unfortunately, Wine users sometimes set their fd rlimit very high (typically around a million), because the "esync" mechanism in Proton's Wine needs a lot of fds. The time taken by each individual syscall is not significant, but when we do a million of them, it adds up. This is arguably a misconfiguration - the recommendation is now to have a soft rlimit of 1024 and a hard rlimit of about a million, so that only processes that opt-in to dealing with a million fds have to be aware of them - but a significant number of misconfigured systems probably still exist. We don't actually *need* to close all the fds here: there's no security boundary, so giving the child access to unnecessary fds isn't a privilage gain; the parent process outlives the child, so leaking fds won't result in them never being closed; and in any case we're reasonably careful to set CLOEXEC on all our fds. So let's just not close them. In particular, this can save literally a million syscalls per helper subprocess invocation (it's not often I get to say that!), reducing pressure-vessel-wrap launch time by 90% on a system with the high fd limit (about 70 seconds down to 7). With the recommended soft limit of 1024, the speedup is less dramatic, but it still takes off nearly 10% (about 6 down to 5.5). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 10, 2020
-
-
Simon McVittie authored
Because we were testing for a prefix match with a trailing slash, when FlatpakExports exports /home/me, we would not rewrite it to /home/me/.var/app/com.valvesoftware.Steam. Instead of adding the necessary special cases, use a slightly refactored version of flatpak_has_path_prefix(), which already does what we need. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 03, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 22, 2020
-
-
Simon McVittie authored
Now that GIO_MODULE_DIR has been backported into scout's GLib, we can disable GIO modules completely, instead of loading them but then not using them. This avoids some misleading warnings (#32). This will not be completely effective on non-Debian systems until we also patch scout's GLib to make GIO_MODULE_DIR take precedence over the hard-coded legacy search path /usr/lib/gio/modules. The unit test for this is still in tests/pressure-vessel/utils.c for now. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 29, 2020
-
-
Simon McVittie authored
While I'm there, add the ability to pass in a pre-opened file descriptor. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 28, 2020
-
-
Simon McVittie authored
This avoids duplicating it in the command-line tools. The test is still in tests/pressure-vessel/ for now, because it needs testutils.py, which uses its own location to find G_TEST_SRCDIR. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 25, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 09, 2020
-
-
Simon McVittie authored
This is preparation for combining pressure-vessel with steam-runtime-tools. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 02, 2020
-
-
Ludovico de Nittis authored
When the current namespace is a Flatpak environment launched with the `--filesystem` option to mount a directory that is under the user's home, e.g. `--filesystem=~/Games`, we don't want to convert the path to `~/.var/app/com.valvesoftware.Steam/[...]`, because on the host we expect to have the same path as we had in the Flatpak environment. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
pressure-vessel had a few hard coded assumptions about the host system and where to look at for the graphics provider. For example it was assumed that the root was the same host system used by both pressure-vessel current environment (where pressure-vessel-wrap runs) and also later on by `bwrap`. But when we run pressure-vessel in a Flatpak container, the final `bwrap` command is expected to be executed against the real host system (mounted in `/run/host`, in Flatpak). Also when we are in a Flatpak container we might want to pick the graphics stack from the host system (`/run/host`), from the Flatpak container itself or it could even be a completely separate one. (T22373, T22371) Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
With this new function it will be possible to test the existence or properties of a given filename under a specific sysroot. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Aug 19, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 18, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 04, 2020
-
-
Simon McVittie authored
This will be used to generate securely-unique socket names that are not an opportunity for denial of service. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 03, 2020
-
-
Simon McVittie authored
This gives us a way to report failure in a signal handler, or between fork() and exec(), both of which are contexts where only a restricted set of async-signal-safe functions are allowed. See signal-safety(7), signal(7) and fork(2) for details. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-