steam-runtime
steam-runtime copied to clipboard
ValveSoftware
Updating pango library
Hi,
For the Battle for Wesnoth, we were going to start using the pango_layout_set_line_spacing API from pango, however using this requires pango 1.44 and the Scout runtime has only 1.30. Would it be possible to update the provided libpango library to 1.44?
Alternatively, has any progress been made on allowing native Linux games to specify a non-Scout runtime? Sniper has pango 1.46 it looks like, but both Sniper (like Soldier before it) state that they can't be used by games on Steam:
Games that require sniper cannot yet be released on Steam. This will hopefully become possible in future, when the container runtime infrastructure is more robust.
however using this requires pango 1.44 and the Scout runtime has only 1.30
That's a time interval of 7 years, and backporting Pango 1.44 would also require a newer version of GLib and a backport of a modern version of Harfbuzz. There's also a regression risk, since Pango has changed its text layout at various times (although in practice, games will often end up using the version of Pango from the host system, if present - particularly if the game is 64-bit). Sorry, I don't think that backport into scout is likely to happen any time soon.
If adjusting the line spacing is non-critical and the default line spacing is an acceptable fallback, then you could either use #if PANGO_VERSION_CHECK(1, 44, 0) to conditionalize the method call (so it won't happen in Steam builds, but will happen in distro builds), or use dlopen()/dlsym() (or their GModule equivalents) to look up the symbol dynamically and only call it if found (so it will happen if the executable happens to find a newer Pango at runtime), or combine both those techniques.
Alternatively, has any progress been made on allowing native Linux games to specify a non-Scout runtime?
That's a Steam client question, more than a runtime question. @TTimo?
Pango in soldier is also too old for what you want, but I think Pango in sniper would be suitable.
Hello @Pentarctagon,
We've started making some changes internally to allow soldier/sniper native titles. It's not quite fully ready for partners yet, but would you be interested in doing some early testing? I think we'd approach it like this:
- Build Wesnoth in the sniper SDK (you'll have new pango, new compiler etc.).
- Upload to a test branch in your depot.
- I will work internally to get that branch to run in sniper SLR.
That gives us something to test that isn't Valve titles so that's interesting.
The branch steamrt_sniper_test has been uploaded to Wesnoth's depo with the executable built against sniper.
Ok we've made the change to your app config for that branch and it all checks out. Wesnoth runs and looks great under the new sniper runtime. I don't think the public beta Steam client has support for this yet, that will be in the next major beta iteration we do. I will post updates here.
I don't think the public beta Steam client has support for this yet
Confirmed: when I switch to the steamrt_sniper_test branch on an Ubuntu 22.04 system, Steam tries to run it in the normal LD_LIBRARY_PATH scout runtime, which fails to launch because sniper's libicui18n.so.67 is not found. However, when I force the steamrt_sniper_test branch to run under sniper, it runs well.
If you have GTK 3 and PyGI available, you can force use of sniper in the public beta Steam client. This is unsupported: use at your own risk, and please don't recommend this to non-developers until the Steam client has a supportable way to use sniper.
details
The steam-runtime-launch-options tool is an unsupported UI for developers, and can select lots of broken combinations of options, but it's quite convenient as a way to test different runtimes if you know what you're doing.
You will need to install the sniper runtime: steam steam://install/1628350. If it's installed in a non-default location, the tool might not find it: it looks for runtimes in the default Steam installation path, as well as ~/tmp and ~/SteamLibrary/steamapps/common. I would recommend switching the runtime to its beta branch if you are doing this sort of experiment.
Change the game's Launch Options to
.../steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/bin/steam-runtime-launch-options --compatible-with=sniper -- %command%
and then launch the game. Instead of the game, you'll get an interactive GTK GUI. Change the Container runtime to SteamLinuxRuntime_sniper (using --compatible-with=sniper is meant to do this automatically, but that doesn't work yet) and make sure Layered runtime scripts is set to None.
This tool deliberately doesn't save settings between runs, so for now you'll have to reselect sniper every time.
You might also want to change Interactive shell to Instead of running the command, which will run an xterm instead of Wesnoth. You can explore the container interactively from here. To run Wesnoth, cd back to the wesnoth directory and run "$@" (with the quotes).
I tried forcing the user of sniper using those steps, and can confirm that Wesnoth starts and runs for me as well.
One oddity I did notice: the most recent sniper snapshot (0.20220601.1) has SDL2_image and SDL2_mixer reporting version 2.5.1, which I don't think exist? The sniper runtime downloaded to the steam client has the expected versions of 2.0.5 and 2.0.4, respectively.
Try switching to the beta branch of the sniper runtime, and use the accompanying SDK. The new SDL2 support libs are close to release if they aren't out yet.
I'd recommend using the stable version of sniper to compile Wesnoth, unless you have a specific reason to need to compile against the beta. sniper runtime versions are backwards-compatible but not forwards-compatible, so binaries compiled against the stable SDK will still work with the beta runtime, but binaries compiled with the beta SDK are not guaranteed to work with the stable runtime. This is the same rule that we always had for scout, but you're more likely to notice a problem when using soldier/sniper, because we use more of their libraries and fewer host libraries.
If you use registry.gitlab.steamos.cloud/steamrt/sniper/sdk:latest (which is what you get if you podman pull registry.gitlab.steamos.cloud/steamrt/sniper/sdk, or do the equivalent with Docker or Toolbx), that should always give you the stable version. The SDK corresponding to the current public beta runtime is registry.gitlab.steamos.cloud/steamrt/sniper/sdk:beta. You can also "pin" a specific SDK by using its version number, something like registry.gitlab.steamos.cloud/steamrt/sniper/sdk:0.20220509.0, if you want a predictable SDK to compile against.
More info about the sniper SDK
One oddity I did notice: the most recent sniper snapshot (0.20220601.1) has SDL2_image and SDL2_mixer reporting version 2.5.1, which I don't think exist?
They're release-candidates for the 2.6.0 stable release (SDL_image, SDL_mixer). The beta sniper runtime also has SDL_ttf release candidate 2.19.1 which will be superseded by the 2.20.0 stable release when it's ready.
Alright, thanks for the info. Part of it too was I didn't expect their version to jump like that - they've both been at 2.0.X for a pretty long time and the main SDL2 library has also kept increasing the patch level rather than the minor version.
Yes, SDL recently changed its version-numbering policy. When it was sticking to 2.0.x indefinitely, it wasn't possible to distinguish between bug-fix releases and new "feature" releases, which is awkward if we want to do a new low-risk release to fix a regression or a bad bug, without also releasing new feature work that might cause new regressions. The new policy borrowed from projects like GLib, GTK and Flatpak also has a way to assign more formal version numbers to development snapshots and release-candidates, which is very useful for the way the old scout Steam Runtime needs to work.
The reason the minor version has jumped up so much is to hint at the versioning continuity: the next stable release after SDL 2.0.22 will be 2.24.0, as a hint that the .24 means the same thing that the .22 used to mean (and the smaller libraries like SDL_image have a similar concept).
I always considered even-odd convention rather confusing, mostly because not everyone use it. I guess it exists mostly to make version easier to parse for tools, but I'd prefer suffixes from semver spec myself.
I guess it exists mostly to make version easier to parse for tools, but I'd prefer suffixes from semver spec myself
SDL already used even/odd (in the micro version rather than the minor version), and its API requires version numbers to be representable as a tuple of integers, so non-numeric suffixes like alpha, beta, rc were not suitable.
The Steam client beta should now automatically launch your steamrt_sniper_test branch in the sniper runtime. I think once you're happy with the testing, and this branch rolls out to stable, we can finish this and have your default branch run sniper. You can let me know when you want to proceed.
Yep, looks like it works. The one issue reported was that it didn't work for a dev using Steam through Flatpak initially and they had to disable setuid bubblewrap, which seems to be an issue for non-recent distros (https://github.com/flatpak/flatpak/wiki/User-namespace-requirements).
So for now I'd prefer it only be applied to our development branch (1.17 - development release). The default branch is the current stable release, and we generally try to avoid changing its minimum requirements unless it's absolutely necessary.
The one issue reported was that it didn't work for a dev using Steam through Flatpak initially and they had to disable setuid bubblewrap, which seems to be an issue for non-recent distros
Yes - the container runtime can work from inside Flatpak, but it has some extra requirements: it needs Flatpak 1.12.x or later, and Flatpak needs to be on the non-setuid-bwrap code path. The code path with a setuid system-wide installation of bwrap only works if you're running Steam on the host system directly (no Flatpak). Proton 5.13+ has the same limitation.
As far as I know, Debian 10 and RHEL/CentOS 7 are the main distros affected by this, and both have been superseded. Debian 11 and RHEL/CentOS 8 are the current versions, and are in the unprivileged user namespaces configuration by default.
The stable release of the Steam client for Linux has support for this now, so this can be rolled out for everyone. Please let us know if you'd like sniper to be enabled by default for all your branches.
If there will be an option eventually to allow us to select which branches use the sniper runtime ourselves, then I'd prefer only the branch "1.17 - development release" be changed to use the sniper runtime. If not, then changing both the default branch and the "1.17 - development release" branch to use the sniper runtime is fine.
We definitely want this exposed to dev partners so they can edit it themselves, but I can't give you a timeline. Might be a while.
We're not planning on moving the "1.17 - development release" branch into the default branch until early 2024, so waiting for that functionality is fine for us unless it's likely to take longer than that.
This is done now, we've switched the "1.17" branch to use sniper SLR. You should probably delete the test branch as it doesn't map to sniper SLR anymore.
however using this requires pango 1.44 and the Scout runtime has only 1.30
That's a time interval of 7 years, and backporting Pango 1.44 would also require a newer version of GLib and a backport of a modern version of Harfbuzz. There's also a regression risk
I think this original feature request as stated is probably "won't fix" for these reasons.
However, the more fundamental thing that you wanted (access to a modern version of Pango) has been satisfied in a different way, by giving you the ability to release versions of Wesnoth built against sniper.
You should probably delete the test branch as it doesn't map to sniper SLR anymore
One of my colleagues was caught out by this while using it to test a proposed sniper update today. @Pentarctagon, would you mind deleting the obsolete branch to avoid confusion?
I think this original feature request as stated is probably "won't fix" for these reasons.
Assuming nobody in Valve disagrees: @kisak-valve, would you mind closing this as "not planned"?