Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

cab404
Copy link
Member

@cab404 cab404 commented May 29, 2022

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
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.05 Release Notes (or backporting 21.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@SuperSandro2000
Copy link
Member

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.

@cab404
Copy link
Member Author

cab404 commented May 29, 2022

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

@cab404
Copy link
Member Author

cab404 commented May 29, 2022

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

Copy link
Member

@mweinelt mweinelt left a 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.

@mweinelt mweinelt closed this Jun 27, 2022
@mweinelt
Copy link
Member

mweinelt commented Jun 27, 2022

Sorry, we can't go that route. The only way for these stragglers is forward.

@cab404
Copy link
Member Author

cab404 commented Jun 27, 2022

Oh, yeah, sure, forgot to close it. Still sad nixpkgs is like that(

@SuperSandro2000
Copy link
Member

SuperSandro2000 commented Jun 27, 2022

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.

@cab404
Copy link
Member Author

cab404 commented Jun 27, 2022

It's more or less about having to break anything at all, especially since it's Nix we are talking about.

@cab404 cab404 reopened this Jun 27, 2022
@mweinelt
Copy link
Member

This changeset still tries to downgrade gcc on x86_64.

@cab404 cab404 closed this Jun 27, 2022
@cab404
Copy link
Member Author

cab404 commented Jun 27, 2022

This changeset still tries to downgrade gcc on x86_64.

Sorry, missed the button – mobile layout is not that great)

@SuperSandro2000
Copy link
Member

It's more or less about having to break anything at all, especially since it's Nix we are talking about.

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.

@cab404
Copy link
Member Author

cab404 commented Jun 27, 2022

It's more or less about having to break anything at all, especially since it's Nix we are talking about.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants