| 5 Feb 2026 |
connor (he/him) | Merging; also made a backport for it since it's worth having there as well | 01:31:25 |
Benjamin Isbarn | Yes it's currently on JetPack 5.1.3. I'm using 11cb3517b3af6af300dd6c055aeda73c9bf52c48 from nixpkgs (still 25.05 ;)). As for opencv:
opencv = pkgs.opencv.override {
enableCudnn = true;
cudaPackages = pkgs.cudaPackages_11_4;
};
and I'm using this for the nixpkgs config:
{
config = {
cudaSupport = true;
allowUnfree = true;
allowBroken = true;
};
overlays = [
(import rust-overlay)
];
}
| 07:31:18 |
Benjamin Isbarn | ok, i did make some progress, turns out libcuda has a couple of more dependencies on the jetson
ldd /run/opengl-driver/lib/libcuda.so linux-vdso.so.1 (0x0000ffffa1fb3000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffa0796000) libnvrm_gpu.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so (0x0000ffffa0729000) libnvrm_mem.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_mem.so (0x0000ffffa0711000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffa0666000) libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffffa0652000) librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffffa063a000) libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffffa0609000) libnvrm_sync.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_sync.so (0x0000ffffa05f2000) libnvrm_host1x.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_host1x.so (0x0000ffffa05d1000) /lib/ld-linux-aarch64.so.1 (0x0000ffffa1f83000) libnvos.so => /usr/lib/aarch64-linux-gnu/tegra/libnvos.so (0x0000ffffa05b1000) libnvsocsys.so => /usr/lib/aarch64-linux-gnu/tegra/libnvsocsys.so (0x0000ffffa059d000) libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffa03b8000) libnvsciipc.so => /usr/lib/aarch64-linux-gnu/tegra/libnvsciipc.so (0x0000ffffa0393000) libnvrm_chip.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_chip.so (0x0000ffffa037f000) libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffffa035b000)
I set LD_LIBRARY_PATH such that the linker is able to load those which did work for a small sample c program that I wrote. Need to try this workaround for the "big app" now ;)
| 10:23:26 |
Benjamin Isbarn | * ok, i did make some progress, turns out libcuda has a couple of more dependencies on the jetson
`` dd /run/opengl-driver/lib/libcuda.so linux-vdso.so.1 (0x0000ffffa1fb3000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffa0796000) libnvrm_gpu.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so (0x0000ffffa0729000) libnvrm_mem.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_mem.so (0x0000ffffa0711000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffa0666000) libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffffa0652000) librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffffa063a000) libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffffa0609000) libnvrm_sync.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_sync.so (0x0000ffffa05f2000) libnvrm_host1x.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_host1x.so (0x0000ffffa05d1000) /lib/ld-linux-aarch64.so.1 (0x0000ffffa1f83000) libnvos.so => /usr/lib/aarch64-linux-gnu/tegra/libnvos.so (0x0000ffffa05b1000) libnvsocsys.so => /usr/lib/aarch64-linux-gnu/tegra/libnvsocsys.so (0x0000ffffa059d000) libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffa03b8000) libnvsciipc.so => /usr/lib/aarch64-linux-gnu/tegra/libnvsciipc.so (0x0000ffffa0393000) libnvrm_chip.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm_chip.so (0x0000ffffa037f000) libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffffa035b000)
I set LD\_LIBRARY\_PATH such that the linker is able to load those which did work for a small sample c program that I wrote. Need to try this workaround for the "big app" now ;)
| 10:23:58 |
Benjamin Isbarn | * ok, i did make some progress, turns out libcuda has a couple of more dependencies on the jetson
dd /run/opengl-driver/lib/libcuda.so linux-vdso.so.1 (0x0000ffffa1fb3000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffa0796000) libnvrm\_gpu.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm\_gpu.so (0x0000ffffa0729000) libnvrm\_mem.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm\_mem.so (0x0000ffffa0711000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffa0666000) libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffffa0652000) librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffffa063a000) libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffffa0609000) libnvrm\_sync.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm\_sync.so (0x0000ffffa05f2000) libnvrm\_host1x.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm\_host1x.so (0x0000ffffa05d1000) /lib/ld-linux-aarch64.so.1 (0x0000ffffa1f83000) libnvos.so => /usr/lib/aarch64-linux-gnu/tegra/libnvos.so (0x0000ffffa05b1000) libnvsocsys.so => /usr/lib/aarch64-linux-gnu/tegra/libnvsocsys.so (0x0000ffffa059d000) libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffa03b8000) libnvsciipc.so => /usr/lib/aarch64-linux-gnu/tegra/libnvsciipc.so (0x0000ffffa0393000) libnvrm\_chip.so => /usr/lib/aarch64-linux-gnu/tegra/libnvrm\_chip.so (0x0000ffffa037f000) libgcc\_s.so.1 => /lib/aarch64-linux-gnu/libgcc\_s.so.1 (0x0000ffffa035b000)
I set LD_LIBRARY_PATH such that the linker is able to load those which did work for a small sample c program that I wrote. Need to try this workaround for the "big app" now ;)
| 10:24:24 |
Benjamin Isbarn | Ok that was the issue, it works now ;) | 11:08:10 |
connor (he/him) | Are you using the JetPack NixOS or cuda-legacy overlays?
Make sure you’re changing the default CUDA package set globally through an overlay — it’s not okay or enough to just change it for a single package because it doesn’t change it for dependencies etc.
Jetson compute capabilities are never built by default so make sure you’re setting cudaCapabilities per the docs | 16:33:58 |
| 6 Feb 2026 |
Yorusaka Miyabi | https://matrix.to/#/!hQKBiJjjGQdiJBvMgK:matrix.org/$4uVDwhUB5SqzFlJ5lGGTc-419hRN2vzXUoJ0_rJhv-A?via=matrix.org&via=t2bot.io&via=beeper.com
We won't be adding cache.nixos-cuda.org to the trusted caches on garnix, sorry! Our users trust us to build software for them that they run on their machines and servers, so we have to be very conservative here. (Of course we don't have any reason to believe that nixos-cuda.org is not trustworthy. But yeah, we just have to be very conservative.)
What Garnix said when asked about adding NixOS CUDA Cache to Garnix
| 02:16:22 |
Yorusaka Miyabi | * https://matrix.to/#/!hQKBiJjjGQdiJBvMgK:matrix.org/$4uVDwhUB5SqzFlJ5lGGTc-419hRN2vzXUoJ0_rJhv-A?via=matrix.org&via=t2bot.io&via=beeper.com
We won't be adding cache.nixos-cuda.org to the trusted caches on garnix, sorry! Our users trust us to build software for them that they run on their machines and servers, so we have to be very conservative here. (Of course we don't have any reason to believe that nixos-cuda.org is not trustworthy. But yeah, we just have to be very conservative.)
What Garnix team said when asked about adding NixOS CUDA Cache to Garnix
| 02:16:27 |
SomeoneSerge (back on matrix) | Makes sense, why cross-contaminate the caches any further | 02:17:45 |
| Yinfeng joined the room. | 02:22:45 |
connor (he/him) | Gaétan LepageI’d like to merge https://github.com/NixOS/nixpkgs/pull/484031 but I’m still concerned about whether the patch needs to be guarded by something — it shouldn’t since the compiler NVCC uses should always use the GLIBC from the default stdenv which should be the newest GLIBC, right? | 16:35:17 |
SomeoneSerge (back on matrix) | Mind waiting until tomorrow, I'd like to take a look? | 17:20:39 |
| 4 Aug 2022 |
| Winter (she/her) joined the room. | 03:26:42 |
Winter (she/her) | (hi, just came here to read + respond to this.) | 03:28:52 |
tpw_rules | hey. i had previously sympathzied with samuela and like i said before had some of the same frustrations. i just edited my github comment to add "[CUDA] packages are universally complicated, fragile to package, and critical to daily operations. Nix being able to manage them is unbelievably helpful to those of us who work with them regularly, even if support is downgraded to only having an expectation of function on stable branches." | 03:29:14 |
Winter (she/her) | In reply to @tpw_rules:matrix.org i'm mildly peeved about a recent merging of something i maintain where i'm pretty sure the merger does not own the expensive hardware required to properly test the package. i don't think it broke anything but i was given precisely 45 minutes to see the notification before somebody merged it ugh, 45 minutes? that's... not great. not to air dirty laundry but did you do what samuela did in the wandb PR and at least say that that wasn't a great thing to do? (not sure how else to word that, you get what i mean) | 03:30:23 |
tpw_rules | no, i haven't yet, but i probably will | 03:31:03 |
Winter (she/her) | i admittedly did that with a PR once, i forget how long the maintainer was requested for but i merged it because multiple people reported it fixed the issue. the maintainer said "hey, don't do that" after and now i do think twice before merging. so it could help, is what i'm saying. | 03:31:50 |
tpw_rules | i'm not sure what went wrong with the wandb PR anyway, i think it was just a boneheaded move on the maintainer's part | 03:32:10 |
Winter (she/her) | (it was also simple enough that it was fine and the maintainer said it looked good after) | 03:32:15 |
tpw_rules | * i'm not sure what went wrong with the wandb PR anyway, i think it was just a boneheaded move on the merger's part | 03:32:19 |
tpw_rules | but i thought most of the frustration was around packages which don't really involve CUDA breaking the fragile CUDA packages, and i'm not sure how the warning helps in this case. it's not like nixpkgs-review prints out the comments. maybe i'm wrong. but it is a legitimate problem | 03:34:19 |
Winter (she/her) | the frustration that i see is that people are touching packages that he maintains, am i missing further context here? | 03:35:09 |
tpw_rules | did you ever see this? https://discourse.nixos.org/t/nixpkgss-current-development-workflow-is-not-sustainable/18741 | 03:35:43 |
Winter (she/her) | oh yes i did | 03:35:49 |
Winter (she/her) | but that's not what the topic of this PR/the notice is, though? | 03:36:11 |
Winter (she/her) | this wouldn't help that | 03:36:14 |
Winter (she/her) | ~~is that what you're saying and i'm just lagging behind~~ | 03:36:27 |
tpw_rules | no it wouldn't, but it reads to me like that's the underlying problem and this is a manifestation which can be controlled more easily. not to put thoughts in people's head | 03:37:07 |