Rust 1.80.0 breaks some packages #332957
Comments
|
|
|
You have 1-2 weeks, remember, so if it's being fixed upstream, you can probably wait. |
|
Useful link for those who want to quote the build log error for the upstream maintainers: https://hydra.nixos.org/jobset/nixpkgs/staging-next#tabs-jobs |
|
or do |
|
I opened an issue in the upstream repo for |
|
Typst 0.11.1 is not compatible with Rust 1.80.0, but the current development snapshot is. |
|
Oh right, I forgot to write above: upgrading to an unstable version is possible, at the package maintainer's discretion — it requires a judgement call on how usable/safe the unstable version will be. But getting upstream to make a release is of course the best! |
I am somewhat inept in navigating Hydra. Could someone help me confirm whether The last real failure I could find using the link in #332957 (comment) is this one, which seems specific to Teleport 15.3.7 does seem to be using a problematic version of the Edit: confirmed locally that it does not build. |
Hydra hasn't built it with 1.80 yet. If you try building it yourself on staging-next you should see that it's broken. |
- Update `nixpkgs` (and use `rust-overlay` for up-to-date `rustc`) - Update `time` crate to fix rust-lang/rust#127343 This helps packagers upstream: NixOS/nixpkgs#332957
- Update `nixpkgs` (and use `rust-overlay` for up-to-date `rustc`) - Update `time` crate to fix rust-lang/rust#127343 - This helps packagers upstream: NixOS/nixpkgs#332957
Seems to me like that sentence there contains a wee contradiction. Either the rust updates will be trivial because all the upstreams are already on top of it XOR there is this shadow looming of 1.79 becoming abandonware that we'll have to forever carry. Looking at the regression, it's the latter one. Indeed, with #333125 I already ran into one of the classics: With 1.80, client builds, but server doesn't without In this case, I was able to fix it, by building against two different lock files, but that's an ugly hack and was hard to find. Obviously, I did open an upstream issue, but if I don't find it reasonable to set a 2 week ultimatium within nixpkgs, then I find it even less reasonable to impose such limits onto our upstream developers. We are not in a corporate environment here. On principle, rust 1.80 is a new language due to the incompatible change (however inadvertent), and should be treated as such. So I think we need to leave 1.79 in nixpkgs, a little while longer. We can, however, disable its hydra builds, such that downstream will learn about the issue through increased build times and have a chance to step up, before their toys break. |
|
|
I think we’ve probably dealt with this issue sufficiently to the point where it no longer needs to be pinned or maybe even open. The user reports of broken packages I’ve seen have diminished to almost nothing by now, and any remaining long tail of packages will be handled during Zero Hydra Failures soon anyway. |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/what-is-nixpkgs-preferred-programming-language/53848/31 |
|
|
and others
Dear maintainers,
Rust 1.80.0 contains a couple of changes that break some packages: an unfixable build regression, and a warning for unrecognized cfg values that some packages treat as an error. Most commonly, the required fix is just to update the "time" crate. I've opened PRs to fix as many regressions as I can, but I can't do all of them.
1.80.0 is currently in staging-next, so will probably be in Nixpkgs master in the next 1-2 weeks. It wasn't really feasible to hold back, because packages tend to start requiring new Rust versions very soon after release, and it also didn't make a lot of sense to keep 1.79.0 as well, because many of the affected packages haven't been touched in a year or more, so there'd be no assurance we'd be able to remove it any time soon.
So, some effort will be required from you to keep your package building with 1.80.0. Usually, the process will be like this:
As a last resort, we can patch if we need to, but especially for packages that include a Cargo.lock in Nixpkgs, this is a pain.
I'll post the affected packages in comments, because GitHub limits how many mentions an issue body can contain.
Sorry for the inconvenience. I've lost a lot of the last week to coordinating the update, collecting broken packages, etc., but hopefully by spreading out the work from here it won't take too much of anybody else's time.
The text was updated successfully, but these errors were encountered: