❮ nix-build --arg config '{ allowUnfree = true; cudaSupport = true; }' -A firefox
this derivation will be built:
  /nix/store/7s1dyndj7r33wck6dywjf6kqxah7ngm2-firefox-144.0.2.drv
building '/nix/store/7s1dyndj7r33wck6dywjf6kqxah7ngm2-firefox-144.0.2.drv'...
structuredAttrs is enabled
error: output '/nix/store/b3cyrj28jf03mrf15jmy9whhfrgy2bxw-firefox-144.0.2' is not allowed to refer to the following paths:
         /nix/store/x8mydcgbry214s802nzvy7fdljx404ym-gcc-wrapper-14.3.0

You said upfront "The addition of CUDA 13 does not mean packages will suddenly work with CUDA 13. Expect breakages." I know I'm just a random bloke from GitHub an fairly new but I've had really bad burnout in the past, I'd suggest still doing a little bit of triaging and technical support here and there for the CUDA Team in strict time blocks, so you can at least see the fruits of your labour (given to the world, for free) as the breakages all get sorted out in the coming weeks in our collective efforts.

From my perspective I'm just excited about the prospect of using CUDA 13 with Nixpkgs, I've basicaly used nixos-unstable, sometimes master, since starting to use Nix, and still have no idea how the release cycle is supposed to work 🙃.

I reckon for the next big CUDA update, do something like how the haskell-updates branch gets merged into staging first.

You said upfront "The addition of CUDA 13 does not mean packages will suddenly work with CUDA 13. Expect breakages." I know I'm just a random bloke from GitHub and fairly new but I've had really bad burnout in the past, I'd suggest still doing a little bit of triaging and technical support here and there for the CUDA Team in strict time blocks, so you can at least see the fruits of your labour (given to the world, for free) as the breakages all get sorted out in the coming weeks in our collective efforts.

From my perspective I'm just excited about the prospect of using CUDA 13 with Nixpkgs, I've basicaly used nixos-unstable, sometimes master, since starting to use Nix, and still have no idea how the release cycle is supposed to work 🙃.

I reckon for the next big CUDA update, do something like how the haskell-updates branch gets merged into staging first.

This is quite a convincing argument to revert the 99 commits https://github.com/NixOS/nixpkgs/pull/437723#issuecomment-3472997390

Maybe there could be a cuda-refactor branch that is continually built and tested by e.g. https://hydra.nixos-cuda.org/jobset/nixpkgs/cuda-refactor while it gets the attention it deserves?

Gaétan LepageSomeoneSerge (back on matrix) are you okay with merging:

• https://github.com/NixOS/nixpkgs/pull/457338
• https://github.com/NixOS/nixpkgs/pull/457220

I’d like there to be consensus as a team for those reverts to go through. Serge, I know you’re in favor of the config.cudaSupport one, but I’d like to issue the statement/decision as a team.