- Dec 15, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 10, 2022
-
-
Simon McVittie authored
Remove fallback for SLR_soldier not having s-r-launcher-interface-0 See merge request !78
-
- Jul 28, 2022
-
-
Ludovico de Nittis authored
Stop supporting STEAM_COMPAT_LAUNCHER_SERVICE=1391110, etc. See merge request !77
-
Simon McVittie authored
We no longer need to open-code this in shell script, because it's now part of SLR_soldier. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The original design for injecting commands into container code was that it was going to be based on Steam app-IDs, but that's awkward for the compat tool authors (particularly Proton, which has a lot of branches with their own app-IDs), so the plan has changed. It is now meant to be based on the compatmanager_layer_name in toolmanifest.vdf, which only needs to be unique within a stack that makes sense to use together: for instance, SteamLinuxRuntime_anything can share "container-runtime", because it only makes sense for any given stack to include one of them. Similarly, all Proton versions can share "proton". We already recognised those names as a developer convenience, even when they were not going to be used in production, so nothing more needs to be done to support them. This partially reverts commit ee4b6c47 "Add app-ID-based triggering for steam-runtime-launcher-service". The addition of the --steam-app-id option has not been reverted, for backwards-compat, but it no longer does anything. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 26, 2022
-
-
Simon McVittie authored
Use steam-runtime-launcher-interface-0 See merge request !76
-
- Jul 25, 2022
-
-
Simon McVittie authored
As agreed in <https://github.com/ValveSoftware/Proton/pull/5891 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 21, 2022
-
-
Simon McVittie authored
If we're running in a sufficiently new soldier container, then this will be in the PATH. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a simplified interface for applying the policy for whether to set up a launcher-service: we just need to be able to find it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 16, 2022
-
-
Simon McVittie authored
This is !72 again, but now with the individual commits preserved. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This reverts commit 7d70e2b2. It was technically fine, but the individual commits were unintentionally squashed. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Add steam-runtime-launcher-service integration See merge request !72
-
Simon McVittie authored
-
- Jun 15, 2022
-
-
Simon McVittie authored
The idea here is that Steam would set STEAM_COMPAT_LAUNCHER_SERVICE=1628350 to get a way to inject commands at the sniper container runtime layer, and so on. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If run with STEAM_COMPAT_LAUNCHER_SERVICE=container-runtime, we'll inject commands at the container layer and they'll run in a "pure" soldier/sniper environment. This is appropriate for native soldier/sniper games that run with no further compatibility layer, as in ValveSoftware/steam-runtime#508. If run with STEAM_COMPAT_LAUNCHER_SERVICE=scout-in-container, we'll inject commands inside the layered scout-on-soldier runtime (or potentially scout-on-sniper, if we pivot to that at some point) and they'll run in a scout-compatible environment. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 13, 2022
-
-
Simon McVittie authored
In principle ${STEAM_RUNTIME} could include wildcards, which we want taken literally. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 09, 2022
-
-
Simon McVittie authored
populate-depot: Prune unnecessary files See merge request !74
-
- Jun 08, 2022
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Add a list of directories and files that are not needed and can be removed to save disk space. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
If we use the compressed runtime to generate the mtree, we need to extract every single file, on the fly, to calculate their hash. But given that when we call `write_lookaside()` we already have entirely extracted the archive on disk, we can use that uncompressed directory to skip re-extracting the files a second time. Additionally this will allow us to remove some files from the runtimes that can be safely omitted to save space, e.g. documentation or support for additional languages. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
scout-on-soldier: Remove search-cwd compatibility glue See merge request !75
-
Simon McVittie authored
The scout runtime has done this itself since steam-runtime tag v0.20210803.0, and the scout runtime currently in the production version of Steam is build 0.20220315.0 which includes steam-runtime tag v0.20220314.0, so we don't need this any more. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 27, 2022
-
-
Simon McVittie authored
scout-on-soldier: Add a convenience script for developers See merge request !73
-
Simon McVittie authored
It's convenient to be able to use a command like .../SteamLinuxRuntime_soldier/run -- xterm to enter the soldier environment for some quick testing, but there isn't a direct equivalent for scout-on-soldier. Add one. We have to make an assumption about the location of SteamLinuxRuntime_soldier, because officially only Steam knows where to find each compatibility tool; but we can guess that most developers will have put SteamLinuxRuntime_soldier and SteamLinuxRuntime in the same Steam library, whether that's the default or not. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 11, 2022
-
-
Simon McVittie authored
If people want to try this hard to break the runtime, let's play along. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
_v2-entry-point: Make sure ./var is not a symlink See merge request !71
-
- Mar 10, 2022
-
-
Simon McVittie authored
Some users might be tempted to redirect ./var to another filesystem, but this will make the runtime a lot slower, more space-consuming and less reliable, because we rely on being able to make hard links between the distributed files and the temporary container root. The correct way to relocate the Steam Linux Runtime depot is to set up a Steam library on a suitable filesystem (which for best results should be a fully-featured Unix filesystem like ext4, btrfs or xfs, although NTFS can be made to work with some difficulty), and then use Steam's "Properties -> Local Files -> Move install folder..." to move the Steam Linux Runtime into it. Helps: https://github.com/ValveSoftware/steam-runtime/issues/495 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 22, 2022
-
-
Simon McVittie authored
It has had a public release now. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 14, 2022
-
-
Ludovico de Nittis authored
scout-on-soldier: Unpack our own Steam Runtime if necessary See merge request !70
-
- Feb 11, 2022
-
-
Simon McVittie authored
This avoids game crashes in some of the unsupported configurations where a distribution or end user has either disabled the Steam Runtime with STEAM_RUNTIME=0, or switched to a modified, unofficial or otherwise out-of-band Steam Runtime with STEAM_RUNTIME=/some/path. Normally, when developers and tinkerers are experimenting with new Steam Runtime versions, we can assume that they have previously run Steam with the supported runtime at least once. In that scenario, ~/.steam/root/ubuntu12_32/steam-runtime will be a valid scout runtime: it might not be the one the user intended, and it might be out of date, but it will probably work. However, if someone has been *consistently* setting STEAM_RUNTIME ever since the first time they ran Steam, then it will never have had the opportunity to unpack the supported runtime, and ~/.steam/root/ubuntu12_32/steam-runtime will still be the heavily cut-down runtime from the bootstrapper, which is insufficient for launching games because it does not implement the whole Steam Runtime ABI (in particular, Dota 2 fails to launch because libpng12.so.12 is missing). As before, developers and tinkerers can bypass all of this by setting STEAM_RUNTIME_SCOUT in addition to STEAM_RUNTIME. As with STEAM_RUNTIME, setting this variable is unsupported and users who have overridden it are responsible for the consequences (do not report bugs). We cannot reuse the same variable for this purpose, because of the dual role of STEAM_RUNTIME: it's a way for developers to switch to a different scout runtime, but it's also a way for libraries inside the runtime to detect the location of the runtime environment, which needs to be disabled while we are setting up the container runtime. Resolves: https://github.com/ValveSoftware/Dota-2/issues/2018 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 29, 2021
-
-
Ludovico de Nittis authored
scripts: Ignore errors when showing diagnostic messages See merge request !69
-
- Oct 28, 2021
-
-
Simon McVittie authored
If users of an X11 environment restart it inside a terminal emulator, and then close the terminal emulator (which seems to be a somewhat popular meme on various forums), we can end up with stdout/stderr pointing to a pseudo-terminal that is no longer associated with a terminal emulator. All writes to such a terminal fail, and when we're running under `set -e`, that will terminate the script. Worse, we can't even diagnose what has happened, because any error messages we might have shown are also going into the void. Mitigate this by ignoring `set -e` when logging diagnostic messages, analogous to the behaviour of `g_warning()` and similar C API calls. (After all, what would we do about it - log a diagnostic message?) Related to <https://github.com/ValveSoftware/steam-for-linux/issues/8069 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 16, 2021
-
-
Simon McVittie authored
For the pressure-vessel integration tests, we want to include the sysroot version of the SDK, but not the Flatpak-like runtime, which is similar enough to the Platform that it's uninteresting. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that we only have one runtime, there's no point in allowing a separate include-sdk settings per runtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fixes: 70e9947a "Remove python-vdf subproject" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 10, 2021
-
-
Simon McVittie authored
python-vdf is now available in most of our CI images, so we don't need it here. For test:bionic and test:archlinux, clone a known-good copy from git and use that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 09, 2021
-
-
Simon McVittie authored
Fix shellcheck warnings, update for latest pressure-vessel See merge request !67
-
Simon McVittie authored
Newer versions have pv-bwrap instead. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-