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>
Linux has a few PowerPC-specific symbols which are marked as GPL exports; these
symbols wound up being exposed in Linux 5.12 and are needed by OpenZFS. The
symbol licensing was fixed in mainline 5.19; this commit backports the fix to
all previous affected kernels.
This commit is required in order to build the NixOS ISO for PowerPC64.
GHC's js backend depends on systemd via emscripten via closure compiler
via jdk via cups. Before it fails to evaluate, though, since
llvmPackages looks into `targetPackages.stdenv.cc` to determine which
C++ library to use (something that should be rectified in the future).
[Unfortunately], for `pkgsCross.ghcjs`, `stdenv.cc` throws which blows
up evaluating `pkgsCross.buildPackages.llvmPackages.clang`.
This is in principle unnecessary. We want to build
`pkgsCross.ghcjs.buildPackages.haskell.compiler.native-bignum.ghcHEAD`
which depends on `pkgsCross.ghcjs.buildPackages.systemd` which needs
clang and friends only in `nativeBuildInputs`, so
`pkgsCross.ghcjs.buildPackages.buildPackages.llvmPackages.clang`.
Unfortunately, due to the nature of splicing, we first evaluate the
“adjacent” derivation before we can access the spliced derivation we are
actually interested in. If the former
fails (`pkgsCross.ghcjs.buildPackages.llvmPackages.clang`), we can't do
the latter.
The solution is to just not rely on splicing in this case and take
`buildPackages.llvmPackages.clang` directly (relative to
`buildPackages.systemd` in this case!) which avoids the whole problem.
[Unfortunately]: c739c420db (diff-3209527bd27cbc775f579b1e295b0264c850859c7245d526965cec456b8c70a4R61)
