execline: 2.1.4.5 -> 2.2.0.0
s6-dns: 2.0.0.7 -> 2.1.0.0
s6-linux-utils: 2.0.2.3 -> 2.2.0.0
s6-networking: 2.1.0.4 -> 2.2.1.0
s6-portable-utils: 2.1.0.0 -> 2.1.0.0 (no version change)
s6-rc: 0.0.2.1 -> 0.1.0.0
s6: 2.2.4.3 -> 2.4.0.0
skalibs: 2.3.9.0 -> 2.4.0.1
Also use new --enable-absolute-paths configure arg to correctly set
paths to runtime executables to point within the nix store rather than
relying on PATH resolution.
It is needed to override "explicit" as this is a C++ keyword. But it
is used as variable name in xkb.h. This is causing a failure in C++
compile time. Similar bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=74080
Workaround from
ec62109e0f.
Additional tools:
- gpg-key2latex
- gpgdir
- gpgwrap
This module is really hacky and the dependencies are very messy... :o
However I tried my best at testing all 19 individual tools and they
should (hopefully) all work now (apart from sendmail which can be
provided by multiple packages) :)
The code is very redundant (sorry) but imho it's easier to read and
maintain it that way.
TODO: There are some additional manual pages that could be included (I'm
too exhausted for that atm...). And there might be a lot of stuff that
could be improved in the future.
Having fixed the Google Compute Engine image build process's copying
of store paths in PR #24264, I ran `nixos-rebuild --upgrade switch`...
and the GCE image broke again, because it sets the NixOS configuration
option for the sysctl variable `kernel.yama.ptrace_scope` to
`mkDefault "1"`, i.e., with override priority 1000, and now the
`sysctl` module sets the same option to `mkDefault "0"` (this was
changed in commit 86721a5f78).
This patch raises the override priority of the Google Compute Engine
image configuration's definition of the Yama sysctl option to 500
(still lower than the priority of an unmodified option definition).
I have tested that this patch allows the Google Compute Engine image
to again build successfully for me.
And adopt the tests to add an interface and remove it again.
It should work when deactivating rstp, it will not work when activating
rstp for the first bridge as then the userspace daemon is not yet
available. But once one bridge is active with stp, it should work with
the reload for any further bridge.
Fixes#21745. Also see #22547.
