| 23 Nov 2025 |
jaredmontoya | * Recently firefox and thunderbird started being rebuilt with cudaSupport enabled because they depend on some other package that now has cuda support. For my laptop with 32GB of ram it takes ages to compile either of them and it eventually runs out of RAM when it's time to link the binary even with --max-jobs 1. It seems that they were added to release-cuda in https://github.com/NixOS/nixpkgs/pull/437809 so they should be cached by the nix-community cache. Yet even after I waited for half a week or more for the new commit to be cached nix still tries to build thunderbird and firefox.
Today I found out about hydra.nixos-cuda.org and decided to try the nixpkgs commit that was built by it https://hydra.nixos-cuda.org/eval/2348 that seems to have thunderbird and firefox cached. Yet nix still tried to build firefox and thunderbird.
This seems to only be possible if hydra.nixos-cuda.org doesn't push to nix-community or if it signs things with a key I don't trust.
Here is my configuration:
substituters = [
"https://nix-community.cachix.org"
];
trusted-public-keys = [
"nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs="
];
Does anyone know what I have to do to get build outputs from the cuda hydra?
| 10:16:54 |
Gaétan Lepage | Indeed, it does not push to the nix-community Cachix instance.
You can use our new cache instead. | 10:51:20 |
jaredmontoya | Thank you! | 10:54:45 |
jaredmontoya | * | 10:55:02 |
SomeoneSerge (back on matrix) | connor (burnt/out) (UTC-8): {isDeclared{Array,Map},sortArray}.bash very nice | 11:57:04 |
| 24 Nov 2025 |
connor (burnt/out) (UTC-8) | thanks, I remember it being an incredibly aggravating experience getting them upstreamed | 01:49:00 |
| Gabriel joined the room. | 02:11:02 |
connor (burnt/out) (UTC-8) | updated https://github.com/NixOS/nixpkgs/pull/459416 | 05:14:12 |
yorik.sar | Hello, Nixpkgs CUDA maintainers team! Starting today I am getting paid to help you with improving CUDA support in Nixpkgs. My client doesn’t have specific asks yet, but is eager to contribute long term. This means I am free to jump on whatever the team finds most important. | 13:34:01 |
yorik.sar | I have found https://github.com/orgs/NixOS/projects/27/views/1, but pretty much all tasks there are stale. Could someone please guide me to what would be the best place to start? | 13:35:31 |
yorik.sar | I don’t have much CUDA enabled hardware at hand (yet), but I will have a Jetson Orin available to me soon. | 13:37:12 |
yorik.sar | Another question: could I be officially added to the team? This is planned to be a long term engagement, so I will work on this for some time. Such visibility would help greatly with the client. | 13:42:13 |
SomeoneSerge (back on matrix) | No details in this one, but here what I consider worth focusing on | 16:24:10 |
SomeoneSerge (back on matrix) | * No details in this one, but here what I consider worth focusing on https://md.someonex.net/s/ik86rsZp7# | 16:24:13 |
SomeoneSerge (back on matrix) | Go ahead and open a PR to nixos-homepage. If anyone should have objections they can voice them there, but I don't expect there to be any | 16:27:47 |
yorik.sar | Is there some place where these points are expanded? Like what means “e.g. cudb” there, for example? | 16:40:12 |
yorik.sar | Ok, will do! | 16:40:18 |
SomeoneSerge (back on matrix) | A scattering of PRs and issues on GitHub, but say are you free to join us tomorrow 21:15 CET (20:15 UTC)? We try to sync every Tuesdays by video | 16:55:55 |
SomeoneSerge (back on matrix) | * A scattering of PRs and issues on GitHub, but say are you free to join us tomorrow 21:15 CET (20:15 UTC)? We try to sync every Tuesday by video | 16:56:12 |
yorik.sar | Sure, I could join. | 17:00:21 |
SomeoneSerge (back on matrix) | connor (burnt/out) (UTC-8) Gaétan Lepage doing same time as last week right? | 17:08:59 |
SomeoneSerge (back on matrix) | * connor (burnt/out) (UTC-8) Gaétan Lepage doing same time as last week right? (sent an update, Connor yours seems to auto-reject) | 17:09:47 |
connor (burnt/out) (UTC-8) | Huh, I don’t even see anything in my junk mail :/ | 17:31:54 |
connor (burnt/out) (UTC-8) | Two thoughts:
- Helion backend for einops
- Optuna integration with Helion to allow for persistent studies (e.g., if the seed is fixed and the number of generations is increased, the optimization should resume from where it stopped rather than start an entirely new optimization)
| 17:34:43 |
connor (burnt/out) (UTC-8) | Serge I’m working on a matrix of behavior of propagating and consuming setup hooks through packages | 17:36:11 |
SomeoneSerge (back on matrix) | I think the key bit is that buildInputs already are (0, 0) away from the current derivation (because we're building for (0, 1)) | 17:59:02 |
SomeoneSerge (back on matrix) | But for the PR we should just drop the offset-checking logic from the hook imo | 18:00:16 |
SomeoneSerge (back on matrix) | * But for the PR we should just drop the offset-checking logic from the hook imo, and avoid propagating extra patchelf | 18:00:45 |
connor (burnt/out) (UTC-8) | Created this table by building everything in the scope I added and assembling the information from the logs (no build succeeds since I don't produce an out output): https://github.com/ConnorBaker/nix-propagation-behavior/blob/1afbd58f2af1468d4564722b7180cc4d89967ef3/README.md | 19:28:30 |
connor (burnt/out) (UTC-8) | Using the table, our "users" are packages consuming the stub outputs, which we would expect to happen from nativeBuildInputs or buildInputs (or both). If used in nativeBuildInputs, we need to install the hook in propagated-host-host-deps (for (-1, -1)) or propagated-build-inputs (for (-1, 0)). If used in buildInputs, we need to install the hook in propagated-build-build-deps (for (-1, -1)) or propagated-native-build-inputs (for (-1, 0)). Since we're modifying binaries in-place through patchelf, the (-1, -1) offsets make more sense to me, but I can install to propagated-build-inputs and propagated-native-build-inputs instead for the (-1, 0) offsets. | 19:28:35 |