| 10 Dec 2025 |
 Ari Lotter | hm looks like vllm fails to build because outlines has a test that imports libcuda.so on collection.. | 22:03:19 |
 SomeoneSerge (back on matrix) | https://github.com/NixOS/nixpkgs/pull/465751#issuecomment-3604113652 | 23:30:45 |
 apyh | hahaha you're already ahead of me! | 23:31:20 |
| SomeoneSerge (back on matrix) | Gaetan has been on it | 23:32:00 |
| apyh | yeah, seems like there's a clear path to patch / upstream a fix to llama cpp python to make it lazy | 23:33:22 |
| apyh | btw i posted logs about that torch nvrtc thing | 23:33:36 |
| 11 Dec 2025 |
 Gaétan Lepage | Yes, but it's not as straightforward as they initialize some top-level constants at module import time with the content of the loaded library...
I still think that it would be the best solution to this issue. | 09:19:45 |
|  youthlic changed their profile picture. | 14:36:35 |
| 13 Dec 2025 |
 kaya 𖤐 | I recently found about a feature just for this: pkgsCuda
Could be the right thing for you. | 23:06:15 |
| 14 Dec 2025 |
|  @tillerino:matrix.org left the room. | 10:49:43 |
|  suua joined the room. | 13:32:40 |
| SomeoneSerge (back on matrix) | Not an official team stance, but personally I hope we deprecate it soon enough | 15:32:40 |
| SomeoneSerge (back on matrix) | Yes! | 15:33:21 |
| 15 Dec 2025 |
|  pdealbera joined the room. | 02:45:00 |
| pdealbera | Hi! I am encountering this issue when using the CUDA cache for NixOS, it probably an issue on my end but wanted to know if anybody encounter the same thing because it was working just hours ago:
warning: error: unable to download 'https://cache.nixos-cuda.org/mhf691zwwjrqi8b6an14pblyqbzwn1v2.narinfo': Could not connect to server (7) Failed to connect to cache.nixos-cuda.org port 443 after 6 ms: Could not connect to server; retrying in 258 ms
| 02:47:07 |
 hexa (UTC+1) | looks up from here | 02:47:37 |
| hexa (UTC+1) | might be a transient path issue | 02:47:46 |
| pdealbera | Did you reproduced the same issue? | 02:49:57 |
| hexa (UTC+1) | ❯ curl https://cache.nixos-cuda.org/mhf691zwwjrqi8b6an14pblyqbzwn1v2.narinfo
missed hash⏎
| 02:55:27 |
| pdealbera | Thanks! Not the same thing, I can't reach the host:
❯ curl https://cache.nixos-cuda.org/mhf691zwwjrqi8b6an14pblyqbzwn1v2.narinfo
curl: (7) Failed to connect to cache.nixos-cuda.org port 443 after 675 ms: Could not connect to server
| 02:59:52 |
| pdealbera | But that means its probably a thing on my end. | 03:00:06 |
| hexa (UTC+1) | the server is hosted in helsinki at hetzner fwiw | 03:01:23 |
 connor (burnt/out) (UTC-8) | Slightly off topic but for those of you who use Hydra or nix-eval-jobs with lots of eval time fetchers or substitution, you may be interested in some WIP I’ve been doing to improve that use case https://gist.github.com/ConnorBaker/9e31d3b08ff6d4ac841928412131fe15 | 09:42:32 |
| connor (burnt/out) (UTC-8) | 
Download Numbers from doing a shallow eval (not forcing recursion) of Haskell.nix’s hydraJobs which has a number of flake inputs (and I think also does IFD?) | 09:46:39 |
| connor (burnt/out) (UTC-8) | 
Download I’m also trying to look into using Intel VTune to get a better idea of Nix bottlenecks/areas for improvement
VTune is currently packaged in Nixpkgs through the Intel-oneapi stuff but I couldn’t get it working without using the latest version. I’ll probably try upstreaming the changes at some point unless someone beats me to it. | 09:48:44 |
 yorik.sar | Did you by any chance run a comparison for more common use-case of evaluating a sizeable NixOS config, for example? Just to see what those locks do to less parallel workload. | 10:53:30 |
| yorik.sar | I’m surprised to see parser there - how much code were you evaluating? | 10:54:09 |
| yorik.sar | I think I already saw some lock implementation in Nix code, probably better to reuse that one. Also, Nix code seems to prefer RAII (smth like { auto _thelock = lock.get(); … }) rather than passing continuation to a function (withLock(…)). | 10:56:46 |
| yorik.sar |
I'd like to do further work to deduplicate queries for .narinfo and the like, since Nix already generates quite the network storm by firing them off in serial.
I wonder if Nix uses HTTP/2 there. I think with stream multiplexing, all requests could essentially fit in one pack of packets.
| 10:59:07 |
| yorik.sar | *
I'd like to do further work to deduplicate queries for .narinfo and the like, since Nix already generates quite the network storm by firing them off in serial.
I wonder if Nix uses HTTP/2 there. I think with stream multiplexing, all requests could essentially fit in one pack of packets.
| 10:59:14 |
