The desktop application and the absoloute path work fine.
But consider desktop environments such as KDE where, in the application
menu, one can right click entries and pin them to widgets/panels, add
them to the desktop, etc.
Doing so effectively means copying
/run/current-system/sw/share/applications/steam.desktop to
~/.local/share/plasma_icons/ or ~/Desktop/, i.e. managed stated gets
duplicated outside the nix scope.
The problem here is that steam.desktop hardcodes
Exec=/nix/store/<derivation hash>-steam/bin/steam %U
this means such copies will point at wrong/outdated derivations once
the steam package changes, i.e. widgets/panels/desktop icons will no
longer work and must be recreated.
Therefore replace the absoloute path with a $PATH lookup to allow "safe"
copying; this isn't optimal but other applications such Firefox and
Thunderbrid currently behave the same way ($PATH lookup in their
.desktop file).
In my previous commit (593c28b) I used the wrong upstream artifact for
the runtime. After reading the documentation in the
ValveSoftware/steam-runtime repo, I now know that the steam-runtime
tarball is what I actually wanted.
I also used 'diff' to compare the various artifacts with the old runtime
this package used before, and the steam-runtime one is certainly the
closest.
Most importantly, switching to the right steam-runtime package
reportedly fixes issues for other users (fixes#90229).
This also entirely removes the amd64/i386 split from runtime.nix because
the upstream package bundles both together, and if that's how upstream
wants to distribute this, it seems best to follow their lead.
Valve has started releasing tarballs of the steam runtime. It seems a
lot easier to download and extract a single tarball than to download a
buncha debs, extract them, and splat em around a bit.
Let's just use the runtime they build. It's a buncha random binary
packages anyway.
Also, the download url for their debs broke, so there's that too.
Noticed that the setup.sh for steam was trying to call the file command.
I'm not sure what the ramifications are for these missing,
but some steam features are quietly disabled when they
don't follow happy paths.
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
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
They aren't meant to be critical (uncatchable) errors.
Tested with nix-env + checkMeta:
[ "x86_64-linux" "i686-linux" "x86_64-darwin" "aarch64-linux" ]
