"common" is just a lot of shared code, not a component in and of
itself. There's no Makefile, so if we try to build it Make will go up
a directory and try to build all of NetBSD.
The kbd package was outdated for years and the last version bump has
been in 2017 and the package has no maintainer. The pull request in
question adds @davidak as maintainer, updates the package to version
2.4.0 and adds a keymap test for the "bone" layout.
Since the dvp and neo layouts are now included, we now no longer need
the kbdKeymaps package.
While the package is one of the dependencies of systemd, its impact is
nonetheless relatively low, because the worst that could happen is that
the keymap can't be set at boot time but it should not break any
software further down the line.
This is the reason why I'm merging this regardless of only having tested
this via running the "keymap" NixOS VM test but without testing on a
real system yet.
This is another one of those packages that's just a rebuild of a
certain part of libc...
Tested by building pkgsCross.x86_64-netbsd.netbsd.librt on
x86_64-linux.
libc's postPatch was entirely fixes for librt, so move that to librt
and inherit it in libc.
82c231d17e ("netbsd: Generalize builder to any-bsd setup hook")
missed libterminfo when it added bsdSetupHook to every other
package. (I checked it didn't miss anything else.)
It also didn't change a NETBSDSRCDIR to BSDSRCDIR, but in fairness
that line was added about half an hour before the setupHook change was
merged in a16384e118.
Fixes: 82c231d17e ("netbsd: Generalize builder to any-bsd setup hook")
Tested building pkgsCross.x86_64-netbsd.netbsd.libm from x86_64-linux.
At some point we should probably set SHLIBINSTALLDIR in the setupHook,
but I think I'd like to get everything working first, and then make
changes that affect all the builds like that. It's easier to spot
regressions when you know _everything_ worked before.
- No splicing makes everything less finnicky.
- Normal bootstrapping matches e.g. linux where kernel headers are also
`stdenvNoCC` but part of this stage.
In https://github.com/openzfs/zfs/commit/658fb802 OpenZFS introduced a
new compatibility feature. This is accompanied by some default profiles
which are located in the $out output of the Nix derivation. However,
these compatibility profiles are used by both the zpool executable
located in $out and the libzfs library located in $lib. This
inadvertently creates a cycle, because zpool refers to $lib to link
against libzfs but libzfs refers back to $out for the compatibility
profiles.
There are two possible routes to rectify this problem:
1. Patch the zpool source code to not read the compatibility profiles
and adjust the build system to put them into the $lib output.
2. Simply remove the $out/$lib split.
Since no other derivation in nixpkgs refers to the $lib output
explicitly we opt for the latter, because this is also in accordance
with upstream.
Before, we were only building the headers, firmware, and bootloader.
CONFIG could be overridden to use another pre-defined kernel, but
there's no way to pass a custom kernel configuration yet.
Tested booting the built kernel in a NetBSD VM.
This option allows to use portions of the system RAM as block devices.
It was configured to 'y' (built-in, therefore not unloadable or
reconfigurable) and configured 16 4MB RAM disks which, to my knowledge,
currently have no purpose in NixOS.
Removing the option restores it to it's default value of 'm', which
enables it to be loaded at runtime (which is also required to be able to
change it's configuration without rebuilding the kernel).
when mounting a fuse fs by fstab on can write:
/nix/store/sdlflj/bin/somefuseexe#argument /mountpoint fuse setuid=someuser
mount is run by root, and setuid is a way to tell mount.fuse to run
somefuseexe as someuser instead. Under the hood, mount.fuse uses su.
The problem is that mount is run by systemd in a seemingly very empty
environment not containing /run/current-system/sw/bin nor
/run/wrappers/bin in $PATH, so mount fails with "su command not found".
We now patch the command to run su with an absolute path.
man mount.fuse3 indicates that this option is reserved to root (or with
enough capabilities) so not using
/run/wrappers/bin/su is thus correct. It has the very small advantage of
possibly working on non nixos.
For a while now it's possible to specify an additional config file in
`wpa_supplicant`[1]. In contrast to the file specified via `-c` this was
supposed to be used for immutable settings and not e.g. additional
networks.
However I'm a little bit unhappy about the fact that one has to choose
between a fully imperative setup and a fully declarative one where the
one would have to write credentials for e.g. WPA2-enterprise networks
into the store.
The primary problem with the current state of `wpa_supplicant` is that
if the `SAVE_CONFIG` command is invoked (e.g. via `wpa_cli`), all known
networks will be written to `/etc/wpa_supplicant.conf` and thus all
declarative networks would get out of sync with the declarative
settings.
To work around this, I had to change the following things:
* The `networking.wireless`-module now uses `-I` for declarative config,
so the user-controlled mode can be used along with the
`networks`-option.
* I added an `ro`-field to the `ssid`-struct in the
`wpa_supplicant`-sources. This will be set to `1` for each network
specified in the config passed via `-I`.
Whenever config is written to the disk, those networks will be
skipped, so changes to declarative networks are only temporary.
[1] https://w1.fi/cgit/hostap/commit/wpa_supplicant?id=e6304cad47251e88d073553042f1ea7805a858d1
For some reason fetchcvs was taken from the cross package set when
cross compiling netbsd.* instead of from buildPackages. I suspect that
this was no issue previously because it just could be substituted as it
only ever produced fixed output derivations. However since
00a2084a40 the evaluation of fetchcvs
would depend on `stdenv.cc` (via its openssh dependency). Since
netbsd.libc is required to evaluate stdenv.cc this caused a infinite
recursion when staging the cross stdenv for pkgsCross.amd64-netbsd. The
fix for this is pretty easy: Just take fetchcvs from buildPackages
explicitly instead of hoping for mkDerivation to get it right.
Resolves#119323.
In wpa_supplicant and hostapd 2.9, forging attacks may occur because
AlgorithmIdentifier parameters are mishandled in tls/pkcs1.c and
tls/x509v3.c.
Fixes: CVE-2021-30004
