- Oct 24, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Steam could run this tool in an arbitrary environment, with necessary signals either blocked (sigprocmask() or similar), or ignored (sigaction() with action SIG_IGN, or similar). Both of these are inherited across fork() and execve() by default, and current versions of Steam do block SIGCHLD in practice. However, blocking or ignoring SIGCHLD breaks handling of subprocesses, which is particularly critical for s-r-launcher-service: that prevents it from detecting that its child processes have exited, causing s-r-launch-client to hang forever, which in turn breaks startup of SteamVR on systems where /bin/sh is dash (but not bash, which apparently resets the disposition of SIGCHLD internally). steamrt/tasks#354, https://github.com/ValveSoftware/SteamVR-for-Linux/issues/618 Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit d2bd4e4b)
-
- Oct 13, 2023
-
-
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
scout-layered.sh: Generate timestamp correctly if HEAD is a merge commit See merge request !608
-
Simon McVittie authored
`git log HEAD~..` can return more than one commit if we're at a merge. Use `git log -1 HEAD` instead, like git-version-gen does. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pv-runtime: Import more Nvidia driver files into the container See merge request !601
-
Ludovico de Nittis authored
pv-runtime: Show warnings if unable to load drivers/layers Closes #108 See merge request !603
-
Simon McVittie authored
build-aux: Fix quoting for clang, clang++ commands See merge request !607
-
Simon McVittie authored
This ensures it won't bit-rot. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The most likely reason for this is misconfiguration: for example, if the user sets VK_DRIVER_FILES to include nonexistent JSON manifests, we should let them know that. Resolves: #108 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
steamrt/tasks#340 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>
-
- Oct 12, 2023
-
-
Simon McVittie authored
Workaround for https://bugs.debian.org/1053836 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 11, 2023
-
-
Simon McVittie authored
pv-runtime: Duplicate symlinks in /etc, /var in the interpreter root See merge request !600
-
- Oct 10, 2023
-
-
Simon McVittie authored
This allows them to point to files that might be virtualized by emulators like FEX-Emu. When running x86 code on ARM under FEX-Emu, we have to populate the container's real /usr with ARM libraries, and populate $FEX_ROOTFS/usr with x86 libraries; otherwise, FEX-Emu itself, which is a dynamically-linked ARM executable, cannot work. /etc/os-release is canonically a symlink to ../usr/lib/os-release, but if we rely on FEX-Emu reading /etc/os-release, we have a problem: it will dereference the symlink and read the real /usr, which contains a /usr/lib/os-release describing the real (ARM) operating system. However, if we create this symlink in the FEX_ROOTFS, when an x86 process dereferences /etc/os-release, FEX-Emu will follow the symlink to $FEX_ROOTFS/usr/lib/os-release, which describes the container runtime (in practice soldier or sniper) as desired. Create both /etc/os-release and $FEX_ROOTFS/etc/os-release, so that both ARM and x86 code do the right thing. We could in principle get the same situation with other symlinks in /etc or /var, so do this uniformly with all members of /etc and /var: if they are symlinks, we create the symlink in both / and $FEX_ROOTFS. steamrt/tasks#342 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pv-runtime: Use a closer match for 99-pulseaudio-default.conf See merge request !597
-
- Oct 06, 2023
-
-
Simon McVittie authored
Add libnvidia-gpucomp to the list of NVIDIA driver libraries See merge request !599
-
Upcoming versions of the NVIDIA driver will include a new component: https://forums.developer.nvidia.com/t/new-driver-component-libnvidia-gpucomp/267060 Update the list of NVIDIA driver libraries so that it can be included in the runtime environment along with the others. steamrt/tasks#340 Signed-off-by:
Daniel Dadap <ddadap@nvidia.com>
-
Simon McVittie authored
log: Lower noisy messages to debug level See merge request !598
-
- Oct 05, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fix duplicate Nvidia Vulkan/EGL drivers under Flatpak (steam-runtime#624) See merge request !595
-
Simon McVittie authored
The unofficial Steam app on Flathub uses an extension to provide i386 graphics drivers, alongside the x86_64 graphics drivers provided by an extension to the base runtime. Unlike typical Linux distribution packaging where the JSON manifests are in /usr/share, the JSON manifests for these drivers are installed into architecture-specific locations. When using Mesa, this is fine, because each driver's JSON manifest refers to the Mesa driver by its absolute path, and Vulkan-Loader will ignore the drivers that are for the other word-size. However, when using the Nvidia proprietary driver, the JSON manifest refers to the driver by its basename, which is equally good for both word-sizes. In a typical Linux distribution, both word-sizes would share a single JSON manifest and there would still be no duplication, but in Flatpak, we get two JSON manifests in different locations with identical content. This has been implicated in crashes in some games, such as The Elder Scrolls Online (although I have not been able to reproduce this with the games I've tried). Before pressure-vessel 0.20230919.0, we accidentally avoided this failure mode by generating broken symlinks for the i386 manifests in /app, which meant that only the manifest originally intended to be for x86_64 was loaded; but that was more a case of compensating errors than anything else, and was probably breaking the ability to load Mesa drivers for i386 games (mitigated by the fact that games requiring Vulkan are more likely to target x86_64). 0.20230919.0 fixed that bug, at the cost of introducing this duplication for Nvidia drivers. We can avoid this becoming an issue by only providing the first one of each set of duplicate JSON manifests. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/624 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Unlike layers, Vulkan/EGL drivers and EGL external platforms have relatively small JSON manifests and no built-in way to exclude duplicates. We can use the full content of the manifest to detect trivial cases of duplication. We don't do this for Vulkan layers, because Vulkan-Loader can already deduplicate those by the layer name, and they're substantially larger than drivers (which would make them more memory-consuming). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us use generic functions to manipulate the SrtLoadable's contents without affecting the public API. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids some overly long lines, and will make subsequent changes more straightforward. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with commit e7fbf19e "pressure-vessel: Use g_debug for messages that only show when verbose" in pv-wrap, if opt_verbose is true, then we know we'll display these even if they are only at debug severity. Using g_debug instead of g_message gives them the correct prefixes in the log, and avoids a distracting level of highlighting in the systemd Journal. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There are two reasons we can get profiling messages: either because we explicitly enabled them with SRT_LOG=timing, or because we have asked to get all debug messages indiscriminately. If we're writing to the Journal, g_message() translates into LOG_NOTICE, which shows up with a distracting level of highlighting. This is appropriate if we specifically asked for timing information, but inappropriate if we just want general debug information, so reduce the log level in the latter case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
tests: Stop assuming libcrypt will be pulled into a scout container See merge request !596
-
- Oct 04, 2023
-
-
Simon McVittie authored
`pcm.!default pulse` assumes that a device named `pulse` already exists in the configuration (which it might, but equally it might not) and overwrites (because of the `!`) the definition of the `default` device with an alias for `pulse`, which could be written as pcm_devices["default"] = pcm_devices["pulse"] in a somewhat more conventional language. In contrast to that, `pcm.!default { type pulse }` overwrites the definition of the `default` device with a newly-defined device whose *type* is `pulse`, more like this pseudocode: pcm_devices["default"] = new PcmDevice(type="pulse") The latter is what `99-pulseaudio-default.conf.example` actually does, and therefore what the fdo runtime's `99-pulseaudio-default.conf` actually does (because it's just a copy of `99-pulseaudio-default.conf.example`, see https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/870889cdde734557298b8e0e4506e275cacb4f90 for the precise implementation). In pressure-vessel we write this to `/etc/asound.conf` rather than into `/etc/alsa/conf.d/` because very old versions of libasound like the one in Steam Runtime 1 'scout' only supported the former and not the latter, but otherwise we intend to mimic what the fdo runtime does, so let's mimic it a little closer. This should make games and other programs that output via libasound, like Shadowrun Returns and `aplay`, more reliable in the container. One other minor divergence from `99-pulseaudio-default.conf.example` is that we don't set the human-readable name `Default ALSA Output (currently PulseAudio Sound Server)` on the device, which seems a bit much for a targeted fix. Thanks: Nozomi Miyamori Resolves: https://github.com/ValveSoftware/steam-runtime/issues/623 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is not guaranteed to be the case now that we are treating libcrypt as potentially a separate library, which is necessary to support use of libxcrypt. Fixes: 81d0099a "Merge libcapsule/v0.20230928.0" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 28, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
libcapsule: Don't treat libcrypt.so.1 as part of glibc See merge request !593
-
Simon McVittie authored
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Some parts of libcapsule are sufficiently low-level to want to avoid calling malloc(), instead using PATH_MAX-sized buffers and an assumption that paths are, in practice, smaller than that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 27, 2023
-
-
Simon McVittie authored
If we have selected a ContainerRuntimeDepot, we might still need to override PRESSURE_VESSEL_PREFIX to its default version of pressure-vessel if there is a different PRESSURE_VESSEL_PREFIX in the environment. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-