So, it seems that the latest glibc (2.42) brought by the latest staging-next iteration does not play well with cuda 12.8.
This at least breaks bitsandbytes.

See more details here: https://github.com/NixOS/nixpkgs/pull/483507

Thanks for the reviews connor (burnt/out) (UTC-8).

Btw, if you have a minute for the cuda-bindings PR, that would help me unblocking torch.
https://github.com/NixOS/nixpkgs/pull/482638

Hello everyone!

I want to share some news regarding the progress yorik.sar and I made on the infra. Some were already communicated, but it doesn't work to summarize everything.

• We have been building and caching all cudaSupport-sensitive nixpkgs packages on both stable and unstable nixpkgs channels on our Hydra instance for a few weeks. You can check the cuda-packages-unstable and cuda-packages-stable jobsets.
• All gpuCheck instances across nixpkgs are now automatically and exhaustively collected and built in Hydra as well. See the cuda-gpu-checks-unstable and cuda-gpu-checks-stable jobsets. For a reminder, gpuChecks are derivations that run some package tests that need access to a physical GPU.
• Regarding package maintenance and updates, recent times were hectic as nixpkgs received several breaking changes since the beginning of 2026 (recursing into python314Packages, update to GCC 15 and more staging-next treats). Besides, here are notable ones:
  • [MERGED] onnxruntime update to 1.23.1
  • [MERGED] triton-bin 3.6.0 + torch-bin 2.10.0
  • [WIP] triton 3.6.0 + torch 2.10.0
  • [WIP] opencv 4.13.0. This one should allow us to migrate to CUDA 13 treewide.
  • [WIP] jax 0.9.0
  • [WIP] vllm 0.14.1
  • [MERGED] mistral-rs 0.7.0
• This is still an idea, but my plan is to create two cuda-specific nix channels: nixos-unstable-cuda and nixos-stable-cuda where we could ensure that a curated set of package builds and tests are succesful (release blockers). I would be glad to hearing your feedback on this idea.

We're trying our best to move things forward as fast as possible. Unfortunately, time and compute resources are limited, so it's never fast enough 😅

Have a nice day!

Hello everyone!

I want to share some news regarding the progress yorik.sar, connor (burnt/out) (UTC-8), SomeoneSerge (back on matrix) and I made recently. Some were already communicated, but it doesn't work to summarize everything.

• We have been building and caching all cudaSupport-sensitive nixpkgs packages on both stable and unstable nixpkgs channels on our Hydra instance for a few weeks. You can check the cuda-packages-unstable and cuda-packages-stable jobsets.
• All gpuCheck instances across nixpkgs are now automatically and exhaustively collected and built in Hydra as well. See the cuda-gpu-checks-unstable and cuda-gpu-checks-stable jobsets. For a reminder, gpuChecks are derivations that run some package tests that need access to a physical GPU.
• Regarding package maintenance and updates, recent times were hectic as nixpkgs received several breaking changes since the beginning of 2026 (recursing into python314Packages, update to GCC 15 and more staging-next treats). Besides, here are notable ones:
  • [MERGED] onnxruntime update to 1.23.1
  • [MERGED] triton-bin 3.6.0 + torch-bin 2.10.0
  • [WIP] triton 3.6.0 + torch 2.10.0
  • [WIP] opencv 4.13.0. This one should allow us to migrate to CUDA 13 treewide.
  • [WIP] jax 0.9.0
  • [WIP] vllm 0.14.1
  • [MERGED] mistral-rs 0.7.0
• This is still an idea, but my plan is to create two cuda-specific nix channels: nixos-unstable-cuda and nixos-stable-cuda where we could ensure that a curated set of package builds and tests are succesful (release blockers). I would be glad to hearing your feedback on this idea.

We're trying our best to move things forward as fast as possible. Unfortunately, time and compute resources are limited, so it's never fast enough 😅

Have a nice day!

Hello everyone!

I want to share some news regarding the progress yorik.sar, connor (burnt/out) (UTC-8), SomeoneSerge (back on matrix) and I made recently. Some were already communicated, but it doesn't work to summarize everything.

• We have been building and caching all cudaSupport-sensitive nixpkgs packages on both stable and unstable nixpkgs channels on our Hydra instance for a few weeks. You can check the cuda-packages-unstable and cuda-packages-stable jobsets.
• All gpuCheck instances across nixpkgs are now automatically and exhaustively collected and built in Hydra as well. See the cuda-gpu-checks-unstable and cuda-gpu-checks-stable jobsets. For a reminder, gpuChecks are derivations that run some package tests that need access to a physical GPU.
• Regarding package maintenance and updates, recent times were hectic as nixpkgs received several breaking changes since the beginning of 2026 (recursing into python314Packages, update to GCC 15 and more staging-next treats). Besides, here are notable ones:
  • [MERGED] onnxruntime update to 1.23.1
  • [MERGED] triton-bin 3.6.0 + torch-bin 2.10.0
  • [WIP] triton 3.6.0 + torch 2.10.0
  • [WIP] opencv 4.13.0. This one should allow us to migrate to CUDA 13 treewide.
  • [WIP] jax 0.9.0
  • [WIP] vllm 0.14.1
  • [MERGED] mistral-rs 0.7.0
• This is still an idea, but my plan is to create two cuda-specific nix channels: nixos-unstable-cuda and nixos-25.11-cuda where we could ensure that a curated set of package builds and tests are succesful (release blockers). I would be glad to hearing your feedback on this idea.

We're trying our best to move things forward as fast as possible. Unfortunately, time and compute resources are limited, so it's never fast enough 😅

Have a nice day!