-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux.stdenv: revert gcc11 update for x86_64-linux #175319
Conversation
The list you posted in matrix https://gist.github.com/cab404/96259f25450d778e744108c0ea9bfaa8 All the hardened kernel kernel modules can be ignored, they are constantly broken. Only 150 breakages for such a change is IMO very good work. No reason to revert that bump a month later. I'd suggest to rather fix the broken packages from that list you personally care about. |
That’s 150 top-level ones. I’ve dropped every "Dependency failed" from that list, and everything except x86_64 — here’s a complete list of everything (1424 packages) broken in that PR https://hydra.nixos.org/eval/1756238#tabs-now-fail |
And we’ve tried some automated fixing with @balsoft — that’s doable, however the concept that something breaking several percents of all nixpkgs got merged in the first place is a bit strange to me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will always leave unmaintained software behind every now and then. A stdenv compiler bump is one of these occasions and I'm opposed to reverting this bump on a whim.
Sorry, we can't go that route. The only way for these stragglers is forward. |
Oh, yeah, sure, forgot to close it. Still sad nixpkgs is like that( |
If there are specific program which only work with gcc10 we can always build them with gcc10 but reverting the default because of a small amount of none essential programs break is not how we can keep things up to date. |
It's more or less about having to break anything at all, especially since it's Nix we are talking about. |
This changeset still tries to downgrade gcc on x86_64. |
Sorry, missed the button – mobile layout is not that great) |
Some treewide changes can break things and that is not super great but okay. You can't test every change with over 50 000 packages beforehand and then the fallout should be cleaned up. |
I would probably say that with frequency at which gcc updates, we can let it check all of the packages over a week or so 🤷 (at least them compiling) And after that what you can do is to notify maintainers of imminent breakage of their stuff, and give them some time to react. |
Description of changes
Reverting changes to x86_64-linux stdenv from this PR.
This should fix everything broken by mismatched glibc — and we should only start updating gcc when we have ways to propagate this change recursively through dependencies on per-package basis.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes