python312Packages.jaxlib-bin: update gpuSrcs keys to 12.4

[GaetanLepage]

Description of changes

When running nixpkgs-review targetting a darwin architecture (on some indirectly related PRs), I get:

at /home/gaetan/.cache/nixpkgs-review/pr-338197-5/nixpkgs/pkgs/development/python-modules/jaxlib/bin.nix:184:7:

  183|     else
  184|       gpuSrcs."${gpuSrcVersionString}";
     |       ^
  185|
Did you mean one of cuda12.2-3.11, cuda12.2-3.10 or cuda12.2-3.12?

cc @SomeoneSerge @danieldk

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.11 Release Notes (or backporting 23.11 and 24.05 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.

[GaetanLepage]

Probably caused by recently merged #335749

[GaetanLepage]

This solution does not work. I still get the same error when running nixpkgs-review on this PR (only for darwin).

[SomeoneSerge]

Why can't we just delete all binaryNativeCode packages...

[GaetanLepage]

Why can't we just delete all binaryNativeCode packages...

As soon as we get recent tensorflow versisons to build...

[SomeoneSerge]

You changed the url but not the hash?

[SomeoneSerge]

Ah no I'm wrong

[GaetanLepage]

I cannot reproduce the bug consistently.
Anyway, I don't think that my fix is relevant at all. Closing.

[SomeoneSerge]

Odd. We still don't know what the missing key was. FWIW we could replace they attrset look-up with a function that returns a trace or a throw when the key is missing. Wouldn't matter for ofborg as long as all expected branches have the corresponding keys as they should

[Artturin]

Odd. We still don't know what the missing key was. FWIW we could replace they attrset look-up with a function that returns a trace or a throw when the key is missing. Wouldn't matter for ofborg as long as all expected branches have the corresponding keys as they should

#339879