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.
A user recently asked where to find Alacritty's default config on NixOS
[1], since we don't have `/usr/share/doc/` (which is where other
operating systems, like Arch, install it). Now it can be accessed by
building alacritty and referring to `result/share/doc/alacritty.yml`.
[1] https://logs.nix.samueldr.com/nixos/2020-06-13#3598860;
ld: library not found for -lintl
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [Makefile:544: libxsltmod.la] Error 1
The Cargo.lock file is not included in the master branch but it is
currently added for the releases (e.g. [0]). Since the GitHub deploy
action currently fails for other reasons [1] we should use the
Cargo.lock from the repository instead.
[0]: 80573d2bf7
[1]: https://github.com/xiph/rav1e/issues/2373
Cargo sets `CARGO_FEATURE_*` for all features when running a build
script:
https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts
Some crates have build scripts (e.g. openblas-src) that rely on the
feature variables being properly set.
Since we now need several representations of features, this change
also updates `createFeatures` to be a list of features, rather than
`rustc` feature arguments. `configureCrate` and `buildCrate` then
build the required representations as-needed.
Fixes#68978
Upstream has this alias too; so that dbus activation works.
What I don't fully understand is why this would ever be useful given
this unit is already started way in early boot; even before dbus is up.
But lets just keep behaviour similar to upstream and then ask these
questions to upstream.
With this systemd buffers netlink messages in early boot from the kernel
itself; and passes them on to networkd for processing once it's started.
Makes sure no routing messages are missed.
Also makes an alias so that dbus can activate this unit. Upstream has
this too.
