- Dec 04, 2020
-
-
Simon McVittie authored
Some OS distributions, notably Exherbo, don't put /usr/bin in their PATH. This means we can't safely use their PATH to invoke standard tools inside the container. Bypass this by setting the PATH without using env(1). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise we can't produce full system diagnostics from the included copy of steam-runtime-system-info. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
https://repo.steampowered.com/steamrt/ sometimes lags behind the image releases, due to its relationship with the LD_LIBRARY_PATH runtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we wrap steam-runtime-system-info in a shell script, its argv[0] will be ld.so, which makes it fail to find its own relocatable prefix in _srt_find_myself(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that s-r-t contains LGPL and Apache-2.0-licensed code, we should reflect that here. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 03, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In particular, when using a SDK runtime, we need to delete overridden 32-bit libraries from /lib32 as well as /lib/i386-linux-gnu. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We return the library directories in most-important-first order here, because that seems like the one that makes most sense (and matches LD_LIBRARY_PATH). When we go looking for DRI drivers, we actually want to take the least important first, but iteration over a GPtrArray in reverse order is easy. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If /lib and /usr/lib are the same file, there's no need to iterate over both. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Vulkan meta-layers doesn't have the `library_path` field in their manifests. For this reason we need to separately handle them because otherwise our assertions about `library_path` not being NULL will fail, like the one in `collect_vulkan_layers()`. This fixes the issue reported on https://github.com/ValveSoftware/steam-runtime/issues/306 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
We need to do this after we have captured glibc-related libraries, otherwise they won't be taken into account while deleting their overridden equivalents. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Since glibc 2.26, the ${PLATFORM} for x86_64 can expand to "haswell" or "xeon_phi" in addition to "x86_64". To make it clearer what's going on, stop pretending that library paths based on ${PLATFORM} have anything to do with multiarch tuples. Instead, create symlinks like /overrides/lib/platform-haswell -> x86_64-linux-gnu and /overrides/lib/platform-i686 -> i386-linux-gnu. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Currently the Vulkan layer loader does not support having multiple layer manifests with the same "name" field. This can be a problem when you want to support multiple ABIs. For this reason some layers, like vkBasalt, use a "library_path" with just the filename of the library. In this way, at execution time, the correct library will be chosen automatically. To expand the special tokens LIB, PLATFORM and ORIGIN we dlopened the layers. But instead of always doing it, now we dlopen layers only if they actually contain at least one of those tokens. In this way we can speed up the whole process a little bit and also keep basenames as is, so that their correct library can still be chosen automatically at execution time. Partial addresses #39 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 30, 2020
-
-
Ludovico de Nittis authored
In case a user is experiencing some problems he might try to disable the import of Vulkan layers to better isolate the issue he is facing. Fixes: #37 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 24, 2020
-
-
Simon McVittie authored
As requested and later documented in <https://github.com/ValveSoftware/steam-for-linux/issues/6310>, Steam looks for compatibility tools in locations determined by this environment variable. Make them available in the container. When running in Flatpak, this will have no effect for compat tools in /app, but we should eventually get the Flatpak app's /app by a different route. Partial fix for https://github.com/ValveSoftware/steam-runtime/issues/302 (we also need to deal with compat tools in /usr/local/share and /usr/share, but that can't easily be done here, and is better addressed when we build the runtimes). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This provides a generic way to get OS-specific library directories, Vulkan layers' configuration, etc. into the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, we made ~/.steam available in the container as part of $HOME, but if it was a symlink outside $HOME or contained symlinks outside $HOME, their targets were not made available in the container. When using the experimental feature of a per-game home directory, we correctly made the targets of symlinks inside ~/.steam available, but not the target of ~/.steam itself (if it was a symlink). Fixes: https://github.com/ValveSoftware/steam-runtime/issues/291 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We might use this later to provide a read-only mount for files from the host OS that shouldn't ever be modified in the container, although we don't yet. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
On NixOS, all hard-coded paths in libraries point into /nix, so mounting it is going to be necessary (although not sufficient) to get pressure-vessel working on NixOS. Manual test, in an updated SteamLinuxRuntime or SteamLinuxRuntime_soldier depot: ./run -- xterm sudo mkdir /nix sudo touch /nix/not-really ./run -- xterm and in the xterm: ls -al /nix Expected result: /nix exists in the container if and only if it exists outside the container. Partially addresses https://github.com/NixOS/nixpkgs/issues/100655 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This function won't work in Flatpak, so we make sure that we only call it when we are *not* in Flatpak. The assertion should match that. This fixes the ability to run: ./pressure-vessel/bin/pressure-vessel-wrap -- xterm when not in a Flatpak environment, which in principle is meant to work (at least on reasonably normal FHS operating systems), although it isn't regularly tested. Thanks to NixOS contributor moben on Github, who spotted this while debugging. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Soldier and Scout include a limited set of fonts that doesn't cover all use cases. For example it is missing the necessary glyphs for Asian languages. For this reason, instead of just using these fonts, we bind the host's ones. This requires an additional configuration file that tells to fontconfig the location of these fonts. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 20, 2020
-
-
Ludovico de Nittis authored
Using the new "--remap-link-prefix" option we can now avoid breaking symlinks because not available under `/run/host`. Fixes: #29 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 18, 2020
-
-
Ludovico de Nittis authored
When we use the provider graphics stack we also try to collect the available Vulkan layers, similarly to what we already do for ICDs. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 17, 2020
-
-
Simon McVittie authored
Apparently NixOS puts it somewhere else, although it does at least concede that a path other than /usr/bin for env is doomed to failure. 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
Any service that has a similar protocol for signalling when it is ready to receive requests is going to need something quite similar to this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Any portal-like service is going to need some common setup and teardown code, so let's move it into this object. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we can't delete a file because it doesn't exist, then ... job done? In practice this happens because the runtime copy is merged-/usr, so /lib and /usr/lib are in fact the same place. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we want to deal with strange operating systems that use a non-standard filename for ld.so.cache, we'll have to special-case it. There's little extra cost to doing this because we already need to understand how ld.so.cache works, to be able to generate our own with different search paths. In situations where we just want a quick container to be able to inspect the runtime, we can deal with this by mounting all of /etc read-only. For the final container, we already iterate over all the files in the runtime's /etc, which will "naturally" include ld.so.cache and alternatives. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a step towards searching all the necessary places for unusual distributions like Exherbo (see https://github.com/ValveSoftware/steam-runtime/issues/230 ), and gives us an obvious extension point for adding more multilib directories. 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>
-
- Nov 16, 2020
-
-
Ludovico de Nittis authored
The latest upstream version of flatpak-context.c has a fix for clang 11 that fixes a warning (treated as error in pressure-vessel) about the cast of a pointer to an int. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 11, 2020
-
-
Ludovico de Nittis authored
This supports the new environment variable "PRESSURE_VESSEL_APP_LD_LIBRARY_PATH" that "_v2-entry-point" will set. The new variable has the advantage to support the eventual custom "LD_LIBRARY_PATH" from game launch options. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 29, 2020
-
-
Simon McVittie authored
I added this to GLib at the beginning of the 2.68 cycle. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-