This was added for use by ZFS, but it turned out that `pname == "linux"`
is sufficient enough and has better coverage since many of our Linux
variants do not have an existing `passthru.isX`, and instead are
identifiable by a different pname.
These firmware blobs are only applicable on x86 hardware. It doesn't
make sense to package them for other architectures, e.g. aarch64. Thus,
limit them to x86 Linux.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
(adapted from commit 51f1ecaa59)
(adapted from commit 1743662e55)
- This release brings official support for Kernel 6.10
- Also update zfs_unstable as it would otherwise lag behind
- Upstream now links `zpool` completion, so only do so on older zfs
(since we still need to support 2.1.x)
Changelog: https://github.com/openzfs/zfs/releases/tag/zfs-2.2.6
