I was getting the following error after a Steam update:
internal error: /steamrt/setup.sh is missing, this runtime is invalid or corrupted
The script is used to put things on PATH but it doesn't seem we need to do that.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
* Update dependencies using steam-native-runtime from Arch Linux as a
reference.
* Remove native-only Steam Runtime, just use installed libraries
instead.
* Mark native-only Steam as broken (due to segfault inside D-Bus). Seems it was
already broken for a long time. Doesn't apply to steam-run.
* Some cleanups for chrootenv.
NixOS: Failing to set hardware.opengl.driSupport32Bit will lead to a
confusing error message about missing libGL.so.1. We include a wrapper
around the steam bin to test for working 32bit opengl with glxinfo. When
failing, we display a proper warning hinting towards the option.
Fixes: #19518
Some games (in my case Stardew Valley) require at least something in
/etc/localtime. The actual file linked there doesn't matter as long as
it's some valid timezone.
Example: instead of
(steamPackages.override { newStdcpp = true; }).steam-chrootenv
(which wasn't working anyway) you now do just:
steam.override { newStdcpp = true; }
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
