This adds a NixOS module for XScreenSaver (from @aidalgol in #130218,
with a few updates).
The module:
* Installs XScreenSaver
* Sets up a suid wrapper for xscreensaver-auth
* Sets up a user service for xscreensaver
The suid wrapper should function correctly when xscreensaver is
installed via the derivation update in 40a00547b71.
Co-authored-by: Aidan Gauland <aidalgol@fastmail.net>
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com>
This adds a patch for XScreenSaver that ensures that the suid wrapper
for xscreensaver-auth is run correctly.
The patch is a simple update to drivers/xscreensaver.c that inserts
/run/wrappers/bin before the DEFAULT_PATH_PREFIX, which is the directory
for xscreensaver hacks/demos, and should be preserved.
The wrapper directory can be modified in the derivation, or even
disabled.
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com>
The previous version stopped working when we started elaborating Rust
metadata. Here, I've made it a bit nicer by actually setting
targetPlatform to an elaborated system. Setting the config to wasi to
get elaborate to understand it is a bit of a hack, but I think it's
less of a hack than what we had before.
The only actual difference this makes to the rustc-wasm32 derivation
compared to the previous working version, is that now crt-static is
set. This is probably the right thing anyway.
Fixes: e3e57b8f18 ("lib.systems: elaborate Rust metadata")
Usually, attributes passed explicitly to elaborate take precedence
over the elaborated ones, but since we also elaborate the nested
"rust" attrset, we need to push that one level down, so the rest of
"rust" is still filled in if you just pass
{ rust = { config = ... } }.
I've had to drop the assertion that checked that at most one of "rust"
and "rustc" was part of the un-elaborated system, because doing this
broke passing an elaborated system in, which should be idempotent.
For the same reason, I've also had to make it possible for
rust.rustcTargetSpec to be passed in. Otherwise, on the second call,
since platform was filled in by the first, the custom target file
would be constructed. The only other way to avoid this would be to
compare the platform attrs to all built in Rust targets to check it
wasn't one of those, and that isn't feasible.
Fixes: e3e57b8f18 ("lib.systems: elaborate Rust metadata")
Gaetan Lepage