Is it possible that CCCL got renamed from cuda_cccl to just cccl in the manifests?

diff --git a/pkgs/development/cuda-modules/packages/cccl.nix b/pkgs/development/cuda-modules/packages/cccl.nix
new file mode 100644
index 0000000000..1f863f770a
--- /dev/null
+++ b/pkgs/development/cuda-modules/packages/cccl.nix
@@ -0,0 +1,1 @@
+{ cuda_cccl }: cuda_cccl
diff --git a/pkgs/development/cuda-modules/packages/cuda_cccl.nix b/pkgs/development/cuda-modules/packages/cuda_cccl.nix
index a10f165f25..78c5274686 100644
--- a/pkgs/development/cuda-modules/packages/cuda_cccl.nix
+++ b/pkgs/development/cuda-modules/packages/cuda_cccl.nix
@@ -7,7 +7,8 @@
 }:
 buildRedist {
   redistName = "cuda";
-  pname = "cuda_cccl";
+  # Renamed from "cuda_cccl" to "cccl" in the CUDA 13.3 redist manifest.
+  pname = if cudaAtLeast "13.3" then "cccl" else "cuda_cccl";

   # Restrict header-only packages to a single output.
   # Also, when using multiple outputs (i.e., `out`, `dev`, and `include`), something isn't being patched correctly,

Tehcnically yes, but the team is currently

• under staffed
• lacking compute, both for CI and development/testing

So we're doing our best to keep the lights on and things somehow up to date. All the extras, as much as we'd love to work on them (and I truly do), are currently out of scope.

(Having said that, backporting this one to 26.05 shouldn't be too bad. Don't hesitate to open a PR, I'll try to do it today otherwise)

🔥 PyTorch 2.12.0 (+ triton 3.7.0 + torchcodec 0.14.0) 🔥

That one was painful... Many thanks to all the reviewers, to Lun for handling the ROCm regressions and especially @NickCao for daring to push the button.

Changelog: https://github.com/pytorch/pytorch/releases/tag/v2.12.0
PR: https://github.com/NixOS/nixpkgs/pull/519925
PR tracker: https://nixpk.gs/pr-tracker.html?pr=519925

As usual, please report any regression here (or by email)

⚠️ Due to the limited hardware availability, testing is best-effort. It will probably break some downstream consumers.
Also, for the same reason, nothing could be properly built/tested on ARM, especially with CUDA support.

I'm starting to look at getting Orin SBSA support up. I've hacked up the linux-sbsa/linux-aarch64 getRedistSystem logic so that Orin goes through linux-sbsa and it works! But, I think that the logic for deciding linux-sbsa vs linux-aarch64 in getRedistSystem might not be enough? I think we'd rather know the CUDA driver version (i.e. 540.5.0 vs 595.78) + capabilities to know which system to use? Using cudaMajorMinorVersion could be sad: if someone is on SBSA Orin, they might want to use SBSA CUDA 12? I don't personally care for this usecase, so if y'all think it's not something to worry about

I've uploaded a PR since code is probably easier to read: https://github.com/NixOS/nixpkgs/pull/528562/changes

I'm starting to look at getting Orin SBSA support up. I've hacked up the linux-sbsa/linux-aarch64 getRedistSystem logic so that Orin goes through linux-sbsa and it works! But, I think that the logic for deciding linux-sbsa vs linux-aarch64 in getRedistSystem might not be enough? I think we'd rather know the CUDA driver version (i.e. 540.5.0 vs 595.78) + capabilities to know which system to use? Using cudaMajorMinorVersion could be sad: if someone is on SBSA Orin, they might want to use SBSA CUDA 12? I don't personally care for this usecase, so if y'all think it's not something to worry about

I've uploaded a PR since code is probably easier to read: https://github.com/NixOS/nixpkgs/pull/528562

I'm starting to look at getting Orin SBSA 1 support up. I've hacked up the linux-sbsa/linux-aarch64 getRedistSystem logic so that Orin goes through linux-sbsa and it works! But, I think that the logic for deciding linux-sbsa vs linux-aarch64 in getRedistSystem might not be enough? I think we'd rather know the CUDA driver version (i.e. 540.5.0 vs 595.78) + capabilities to know which system to use? Using cudaMajorMinorVersion could be sad: if someone is on SBSA Orin, they might want to use SBSA CUDA 12? I don't personally care for this usecase, so if y'all think it's not something to worry about

I've uploaded a PR since code is probably easier to read: https://github.com/NixOS/nixpkgs/pull/528562

I'm starting to look at getting Orin SBSA 1 support up. I've hacked up the linux-sbsa/linux-aarch64 getRedistSystem logic so that Orin goes through linux-sbsa and it works! But, I think that the logic for deciding linux-sbsa vs linux-aarch64 in getRedistSystem might not be enough? I think we'd rather know the CUDA driver version (i.e. 540.5.0 vs 595.78) + capabilities to know which system to use? Using cudaMajorMinorVersion could be sad: if someone is on SBSA Orin, they might want to use SBSA CUDA 12? I don't personally care for this usecase, so if y'all think it's not something to worry about, then we don't have to worry about it

I've uploaded a PR since code is probably easier to read: https://github.com/NixOS/nixpkgs/pull/528562

I'm starting to look at getting Orin SBSA support up. I've hacked up the linux-sbsa/linux-aarch64 getRedistSystem logic so that Orin goes through linux-sbsa and it works! But, I think that the logic for deciding linux-sbsa vs linux-aarch64 in getRedistSystem might not be enough? I think we'd rather know the CUDA driver version (i.e. 540.5.0 vs 595.78) + capabilities to know which system to use? Using cudaMajorMinorVersion could be sad: if someone is on SBSA Orin, they might want to use SBSA CUDA 12? I don't personally care for this usecase, so if y'all think it's not something to worry about, then we don't have to worry about it

I've uploaded a PR since code is probably easier to read: https://github.com/NixOS/nixpkgs/pull/528562