nixUnstable was removed in 2b4e18f3d4
but is still referred to from a variety of places, including Hydra's
cross-trunk jobset:
```
in job ‘armv7l-hf.nixUnstable.aarch64-linux’:
error:
… while evaluating a branch condition
at /nix/store/m549zq6lcl10d1jqcdgcdaxxj9xdhxfv-source/lib/customisation.nix:479:5:
478| in
479| if drv == null then null else deepSeq drv' drv';
| ^
480|
… in the left operand of the update (//) operator
at /nix/store/m549zq6lcl10d1jqcdgcdaxxj9xdhxfv-source/lib/meta.nix:43:9:
42| addMetaAttrs = newAttrs: drv:
43| drv // { meta = (drv.meta or {}) // newAttrs; };
| ^
44|
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: nixUnstable has been removed. For bleeding edge (Nix
master, roughly weekly updated) use nixVersions.git, otherwise
use nixVersions.latest.
```
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
The dontConfigure line can be removed in staging, as it's the default
there.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
The dontConfigure line can be removed in staging, as it's the default
there.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. Most
packages can just enable useFetchCargoVendor and regenerate their
hashes, but this one hits a fetchCargoVendor edge case, so the only
safe mechanism post-1.84.0 is importCargoLock.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.