default-gcc-version: 12 -> 13 if stdenv.isDarwin

[wegank]

Description of changes

I imagine this would rebuild liblapack, since gfortran is now at 13. An easy test would then be to see if python3Packages.numpy still works. (EDIT: OK)

Also Wine according to #283642. (EDIT: OK)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[reckenrode]

I was going to say this shouldn’t affect the DXVK issue because it’s cross-compiling to Windows, but apparently the cross compiler version is based on your platform’s default GCC. That’s … unexpected (and somewhat unhelpful).

The MoltenVK issue is going to be addressed this weekend. In the meantime, Wine can be tested by building it without Vulkan support. If it’s already building on Linux, I don’t expect problems with Wine on Darwin beyond the usual.

[wegank]

@vcunat @trofi Any chance of this being merged?

[vcunat]

Well, what's the risk of mass breakage that won't be solvable within a couple days? (I'm afraid I won't be spending much energy on darwin-only stuff.)

[vcunat]

If it was really risky in this sense, I could create a separate jobset for this PR instead.

[vcunat]

@wegank: did you mean that you'd like a Hydra jobset? (by that 👍🏽)

[wegank]

Yes, I'd like a Hydra jobset.

[vcunat]

Let's base it on some recent commit that's (most likely) not very broken? Say, this one? https://hydra.nixos.org/eval/1805154#tabs-inputs

[vcunat]

aarch64: https://hydra.nixos.org/eval/1805157?compare=1805154

[wegank]

I can't reproduce any failures with a red cross except for python311Packages.moto, python311Packages.softlayer and welle-io, which seems either flaky or failing on master.

@vcunat Is the new failures count (994) okay or should the failing jobs be re-run to reduce it?

[vcunat]

.moto is a common flaky build with lots depending on it. Overall, flakiness is an unpleasant thing and happens for pythonPackages tests a lot. I made sure to clear up those failures. So now it's mainly a question whether to add x86_64-darwin before merging or not.

[wegank]

If I haven't misread the new failures count (which is now 13), the GCC bump on aarch64-darwin is pretty safe.

I don't think it's necessary to have a jobset run on x86_64-darwin: GCC and GFortran are officially supported there, it's even less likely to break than on aarch64-darwin.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/darwin-updates-news/42249/8