!eWOErHSaiddIbsUNsJ:nixos.org

NixOS CUDA

291 Members
CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda57 Servers

Load older messages


SenderMessageTime
6 Feb 2025
@ss:someonex.netSomeoneSerge (back on matrix)

does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs?

That's the idea. We could consider an automation more along the lines of propagatedBuildInputs, but symlinks we hope to avoid, because it's hard to prune the references to static libraries after the build

17:31:10
@ss:someonex.netSomeoneSerge (back on matrix) Maybe gc it? 17:31:58
@ss:someonex.netSomeoneSerge (back on matrix)

4s
Run # Get the latest eval.yml workflow run for the PR's target commit
Comparing against "https://github.com/NixOS/nixpkgs/actions/runs/13155928895"
Workflow was not successful (conclusion: failure), cannot make comparison

Has anyone encountered this? I've no idea what this workflow is even for

17:41:42
@ss:someonex.netSomeoneSerge (back on matrix) changed their display name from SomeoneSerge (Gand St. Pieters) to SomeoneSerge (UTC+U[-12,12]).17:51:07
@ruroruro:matrix.orgruro The upstream in question is NVIDIA/cuda-samples. They are currently using "plain" Makefiles. I think that it's unlikely that we could get them to switch (and I don't really want to try to implement this myself). What would be "the most nixpkgs way" to create a merged CUDA_PATH in this case? 17:54:37
@ruroruro:matrix.orgruro Apart from just using cudatoolkit that is. 17:55:17
@ss:someonex.netSomeoneSerge (back on matrix)It would be what you said, buildEnv/symlinkJoin (which is what cudaPackages.cudatoolkit currently is)17:55:50
@ruroruro:matrix.orgruro

Hmmm. I just noticed that according to this page the latest supported GCC version for CUDA 12.4 is GCC 13.2, but currently

cudaPackages_12_4.backendStdenv.cc.version == "13.3.0"

is this expected?

18:57:21
@ruroruro:matrix.orgruroNvm, I am blind, it says that newer minor versions are also supported.19:02:35
7 Feb 2025
@connorbaker:matrix.orgconnor (he/him) Ugh FINALLY have a test to catch different versions of the package set leaking into each other: https://github.com/ConnorBaker/cuda-packages/commit/6c9cb3a17962427e9772849a3b7ca08899897aae
Got tried of seeing multiple versions of CUDA dependencies in the closure of members of the package set
02:04:37
@ss:someonex.netSomeoneSerge (back on matrix) Let's do Thursday February 13th 2-3PM UTC? 14:41:38
@stick:matrix.orgstickno idea - seems like an intermittent issue?15:07:19
@stick:matrix.orgstickother than that, are you ok with merging the PR? I would love vllm to appear in the cache15:07:44
@stick:matrix.orgstick* other than that, are you ok with merging the PR? I would love vllm to appear in the nix-community cache15:07:50
@stick:matrix.orgstickand i just merged an update from 0.7.1 -> 0.7.2 to master15:08:02
@stick:matrix.orgsticki rebased the PR to check whether the CI fails again on the same test15:09:55
@stick:matrix.orgstick* i rebased the PR https://github.com/NixOS/nixpkgs/pull/379575 to check whether the CI fails again on the same test15:10:13
@stick:matrix.orgstickupdate: no it did not - i guess there was an error in master, not in my branch15:11:22
@ss:someonex.netSomeoneSerge (back on matrix) Yes ofc. I was about to press the button but then this weird action failed even after I restarted it manually 15:23:31
@stick:matrix.orgstickis that the only thing needed to get vllm into nix-community cache?15:23:58
@ss:someonex.netSomeoneSerge (back on matrix)Looks like it's happy after the rebase?15:24:01
@stick:matrix.orgstickyes, it is15:24:09
@stick:matrix.orgstickthanks for the merge!15:33:11
8 Feb 2025
@terrorjack:matrix.orgterrorjack joined the room.01:25:30
@terrorjack:matrix.orgterrorjack set a profile picture.02:24:20
@terrorjack:matrix.orgterrorjack removed their profile picture.02:24:57
@vanishingideal:matrix.orgvanishingideal joined the room.04:06:53
@mabau:matrix.org@mabau:matrix.org left the room.07:11:39
@zopieux:matrix.zopi.euzopieux

alright, we got a recent build, so I tried again. Updated to 550e11f and ran:

$ colmena build -v --show-trace --nix-option builders "" --nix-option cores 0
x | these 11 derivations will be built:
x |   /nix/store/f1s6y83hb8gdl0s49vmj0w54i5a75gd7-ollama-0.5.7.drv
x |   /nix/store/fpfv7cn50ns667qrkwx2frn26di1hnc7-ollama.service.drv
[snip]
x | building '/nix/store/f1s6y83hb8gdl0s49vmj0w54i5a75gd7-ollama-0.5.7.drv'...

even though f1s6… is right there. Is there a way to debug that nix-community is even being requested at all, perhaps?

15:36:58
@zopieux:matrix.zopi.euzopieux ok that was dumb, I should have checked nix flake show first. Something was overriding the substituters this whole time, despite my flake setting them. Sorry for the noise, it's all fine now! 16:02:13

Show newer messages


Back to Room ListRoom Version: 9