| 9 Jan 2025 |
 hexa (UTC+1) | take care! | 02:12:08 |
 connor (burnt/out) (UTC-8) | Check out how I packaged https://github.com/ConnorBaker/cuda-packages/tree/main/cuda-packages/common/cudnn-frontend and https://github.com/ConnorBaker/cuda-packages/blob/main/cuda-packages/common/onnxruntime/package.nix | 05:56:56 |
| connor (burnt/out) (UTC-8) | In reply to @hexa:lossy.network
oh, I see your're in the LA area I’m about an hour south so I’m fine apart from poor air quality | 15:01:45 |
| hexa (UTC+1) | torch and tensorboard on python3.13 https://github.com/NixOS/nixpkgs/pull/372406 | 15:33:12 |
 Gaétan Lepage | Thanks for handling that ! | 15:37:46 |
| 11 Jan 2025 |
|  oak 🏳️🌈♥️ removed their profile picture. | 16:46:07 |
| hexa (UTC+1) | can I get some guidance on cudaPackages? | 02:24:33 |
| oak 🏳️🌈♥️ set a profile picture. | 16:47:04 |
| hexa (UTC+1) | https://github.com/NixOS/nixpkgs/pull/364362 | 02:24:37 |
| hexa (UTC+1) |
error: evaluation aborted with the following error message: 'lib.customisation.callPackageWith: Function called without required argument "cuda_cccl" at /nix/store/sj06sl54sc0rxlj0g52pd3pq3glyvpak-source/pkgs/development/cuda-modules/cudnn-frontend/default.nix:5'
| 02:24:46 |
| hexa (UTC+1) | ok, guess I need to pick them out of cudaPackages | 02:33:01 |
 SomeoneSerge (back on matrix) | Odd, I thought we nuked old cuda releases that didn't have cuda_cccl? | 11:47:40 |
| hexa (UTC+1) | oh yeah, that would explain why I could build it just fine, but eval would fail 🙂 | 16:09:02 |
| 13 Jan 2025 |
 ruro | Hi, everyone. In my experience, CUDA packages and CUDA-enabled packages when cudaSupport = true; are quite often broken in nixpkgs (more often than other packages).
For example, https://hydra.nix-community.org/jobset/nixpkgs/cuda/evals has a bunch of Eval Errors and build errors and I don't remember the last time that it was green (although some of those eval errors might not be indicative of actually broken packages).
I was thinking that we might be able to improve the situation by making general nixpkgs contributors more aware of this situation. For example, it would be pretty cool if we could track the nix-community hydra builds on status.nixos.org, on zh.fail (and try to include CUDA packages in future ZHF events).
Also, I understand why hydra.nixos.org doesn't build CUDA packages, but do you think that we could enable evaluation-only checks for CUDA packages on nixpkgs github PRs and then build those PRs using the nix-community builders and report the results on the PR?
Finally, I was wondering if there is some canonical place to track/discuss CUDA-specific build failures in nixpkgs?
| 14:27:12 |
| ruro | * Hi, everyone. In my experience, CUDA packages and CUDA-enabled packages when cudaSupport = true; are quite often broken in nixpkgs (more often than other packages).
For example, https://hydra.nix-community.org/jobset/nixpkgs/cuda/evals has a bunch of Eval Errors and build errors and I don't remember the last time that it was green (although some of those eval errors might not be indicative of actually broken packages).
I was thinking that we might be able to improve the situation by making general nixpkgs contributors more aware of this situation. For example, it would be pretty cool if we could track the nix-community hydra builds on status.nixos.org and on zh.fail (and try to include CUDA packages in future ZHF events).
Also, I understand why hydra.nixos.org doesn't build CUDA packages, but do you think that we could enable evaluation-only checks for CUDA packages on nixpkgs github PRs and then build those PRs using the nix-community builders and report the results on the PR?
Finally, I was wondering if there is some canonical place to track/discuss CUDA-specific build failures in nixpkgs?
| 14:28:08 |
