* It doesn't matter if `rustc` is available, but if rustc can compile to
the hostPlatform. So use a custom condition instead of `availableOn`.
* Explicitly exclude the combination of GCC and riscv which is known
to be broken[1].
[1] https://lore.kernel.org/lkml/31885EDD-EF6D-4EF1-94CA-276BA7A340B7@kernel.org/T/
Co-authored-by: Alyssa Ross <hi@alyssa.is>
This breaks the build like this:
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: Unexpected GOT/PLT entries detected!
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: Unexpected run-time procedure linkages detected!
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: fs/nfs/localio.o: in function `nfs_local_iocb_alloc':
/build/source/build/../fs/nfs/localio.c:290:(.text+0x324): undefined reference to `nfs_to'
[...]
Reported as https://lore.kernel.org/all/D4OUJRP8YWRM.ATQ7KASTYX5H@mbosch.me/
The first assumption[1] we had was that the `aarch64-unknown-none`
target was missing from rustc and that this was the cause for the
regression.
However, it turns out that the relevant code from `rustc` wasn't used
anyways because the Makefile does `--sysroot /dev/null`[2] which prevents
rustc from using its own libcore. So luckily we don't have to patch the
Rust bootstrap to get aarch64-linux back working[3].
In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I
decided to not bother since none of those are longterm versions.
So all that's left here is to enable Rust for aarch64-linux because it
clearly works[5].
[1] https://github.com/NixOS/nixpkgs/pull/315121#issuecomment-2135805876
[2] https://lore.kernel.org/all/20231031201752.1189213-1-mmaurer@google.com/
[3] Of course I only realized this _after_ I spent some time hacking a rustc
patch together 🙃
[4] This broke with
error[E0463]: can't find crate for `core`
|
= note: the `aarch64-unknown-none` target may not be installed
= help: consider downloading the target with `rustup target add aarch64-unknown-none`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
[5] While the build is fine, the VM tests are still panicking, but
that's also the case for `kernel-generic` because of a 9p
regression:
switch_root: can't execute '/nix/store/zv87gw0yxfsslq0mcc35a99k54da9a4z-nixos-system-machine-test/init': Exec format error
[ 1.734997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[ 1.736002] CPU: 0 UID: 0 PID: 1 Comm: switch_root Not tainted 6.12.0-rc1 #1-NixOS
[...]
Reported as https://lore.kernel.org/all/D4LHHUNLG79Y.12PI0X6BEHRHW@mbosch.me/T/#u
Olm was marked as vulnerable in e4767b47.
The issue, however, is controversial and the practical ability to
exploit its vulnerabilities has not been demostrated: ultimately the
users are invited to decide for themselves.
Given that, hydra should still build and distribute the packages
depending on olm to avoid expensive builds in the event the users
decide it's acceptable to continue using these packages.
