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.
