This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
libBPF does not compile for mips64 targets using clang (rathern than
gcc) because clang lacks the necessary _MIPS_SZPTR compiler builtin.
Let's allow the rest of systemd to compile.
- The glibc people noticed this problem [way back in
2011](https://sourceware.org/pipermail/libc-ports/2011-June/001959.html)
and consider it to be a clang/llvm bug. I am inclined to agree.
- [clang has the `_MIPS_SZPTR`
builtin](3af9cb5375/clang/lib/Basic/Targets/Mips.cpp (L185))
and seems to have had it since before they switched to git.
This may in fact be a nixpkgs bug -- that we're not invoking clang
in a way that tells the frontend to make the mips builtins
available, even if the backend is emitting mips binaries. Or at
least we aren't tricking systemd's build machinery into doing that.
This firmware is completely open source with no blobs, which is
quite rare in the wifi world. Wifi chips have their own dedicated
general-purpose CPUs. This source code allows you to see what those
CPUs are doing and modify their behavior.
When the upstream repository was created in 2013, "open source
firmware" meant "firmware which is open source". In 2023 that is no
longer the generally accepted [definition], so I have chosen an
unambiguous adjective (whose meaning has remained stable for
decades) to use in the pname.
[definition]: https://web.archive.org/web/20221209121315/https://www.opencompute.org/projects/open-system-firmware#:~:text=Another,allows%20it
Co-authored-by: Artturi <Artturin@artturin.com>
