| 31 Dec 2025 |
 Collin Arnett | Oh no worries. As far as the dcgm nix module I was mostly mentioning you above to make sure credit was given where credit is due :D | 16:21:47 |
| 1 Jan 2026 |
|  matthewcroughan changed their display name from matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) to matthewcroughan. | 20:04:02 |
| 5 Jan 2026 |
 Ari Lotter | is there a more general python/ml Nix chat anywhere? trying to get some stuff that isn't technically cuda-related going | 21:24:26 |
 Gaétan Lepage | Just ask it here. There is no other "python+ML" official room I'm aware of.
The closest would be the official Python room, but you would end up pinging even more people. | 21:27:55 |
| Ari Lotter | yeah fair enough.
trying to depend on the python module outlines, it seems not to build because it has a hard requirement of outlines-core==0.2.11, but the version of -core in nixpkgs is 0.2.13. seems like latest outlines release still does depend on 0.2.11. wondering if it makes more sense to PR to.. revert the core update? because it seems like outlines must have been "broken" since https://github.com/NixOS/nixpkgs/commit/a5370c8752db2465791097660563b3b2441b56ac
either that or something changed about the pythonRuntimeDepsCheck - the error i get is that f"{package_name}{requirement.specifier} not satisfied by version {package.version}"
| 21:46:53 |
|  Kevin Mittman (UTC-8) changed their display name from Kevin Mittman (EOY sleep) to Kevin Mittman (UTC-8). | 22:03:14 |
| Ari Lotter | * yeah fair enough.
trying to depend on the python module outlines, it seems not to build because it has a hard requirement of outlines-core==0.2.11, but the version of -core in nixpkgs is 0.2.13. seems like latest outlines release still does depend on 0.2.11. wondering if it makes more sense to PR to.. revert the core update? because it seems like outlines must have been "broken" since https://github.com/NixOS/nixpkgs/commit/a5370c8752db2465791097660563b3b2441b56ac
either that or something changed about the pythonRuntimeDepsCheck - the error i get is that f"{package_name}{requirement.specifier} not satisfied by version {package.version}": outlines-core==0.2.11 not satisfied by version 0.2.13
| 22:39:27 |
| 6 Jan 2026 |
| Gaétan Lepage | Yes, I already fixed it in https://github.com/NixOS/nixpkgs/pull/476381.
You can track it here: https://nixpkgs-tracker.ocfox.me/?pr=476381 | 11:39:15 |
 apyh | everyone is so fast lol thank you | 15:04:29 |
| 8 Jan 2026 |
| Gaétan Lepage | RE onnxruntime-dependent segfaults when cudaSupport is enabled.
Apparently, this does not only happen in onnxscript, but also in rapidocr-onnxruntime. | 10:12:03 |
| Gaétan Lepage | Addressed in https://github.com/NixOS/nixpkgs/pull/478028. | 10:46:28 |
| Gaétan Lepage | connor (burnt/out) (UTC-8) what is your plan for updating the default cudaPackages alias?
Bumping to 12.9 or directly to 13? | 11:02:00 |
| Gaétan Lepage | I ask this because evaluating nixpkgs with cudaSupport = true is currently broken because of python3Packages.paddlepaddle which doesn't have sources for Cuda 12.8. | 12:39:45 |
| Gaétan Lepage | And this broke our cuda-packages-unstable hydra jobset :/ | 12:40:29 |
|  wilhelmines joined the room. | 16:58:46 |
 connor (burnt/out) (UTC-8) | Is that backport-able? | 17:19:30 |
| connor (burnt/out) (UTC-8) | I’d be okay bumping to the latest CUDA once we get OpenCV bumped to the latest release (4.13 came out recently and includes fixes to build with CUDA 13), assuming nothing super important breaks | 17:20:53 |
| connor (burnt/out) (UTC-8) | One of the longer discussions I keep pushing back is deciding on whether or not we want to do release gating, and if so, which packages should be considered blockers. | 17:21:32 |
 SomeoneSerge (back on matrix) | Yes we should, at the least on pytorch | 19:52:18 |
| SomeoneSerge (back on matrix) | Eval error like that is a bug. if you have the time, append "or null" to the attribute look up | 19:56:31 |
| 10 Jan 2026 |
| connor (burnt/out) (UTC-8) | okay well this absolutely sucked and took way too long: https://github.com/NixOS/nixpkgs/pull/478619 | 03:26:56 |
| connor (burnt/out) (UTC-8) | good news is it helped me discover an issue with the refactor I was doing for jetpack-nixos: https://github.com/ConnorBaker/jetpack-nixos/commit/82d0eb506ad4a1791a1ba44781a64a48b819a54d | 03:30:13 |
| Gaétan Lepage | Sure, done: https://github.com/NixOS/nixpkgs/pull/478681 | 09:54:12 |
| Gaétan Lepage | * Sure, done: https://github.com/NixOS/nixpkgs/pull/478681
EDIT: merged by happysalada | 11:34:03 |
|  Gilles Poncelet joined the room. | 15:34:07 |
| connor (burnt/out) (UTC-8) | Suppose you’ve got a project where different object files are compiled with different versions of NVCC/GCC. Under what conditions can they be linked into shared objects?
As an example, assume you’ve got a project which builds with an older version of CUDA, and you’re using stdenv (not cudaPackages.backendStdenv). The CUDA portion of the build would produce object files using an older, NVCC-compatible GCC (by virtue of how we wrap NVCC so it always sees a compatible GCC), but the rest would produce object files using the GCC provided by stdenv. Linking happens with some combination of stdenv’s linker, the linker corresponding to the bintools (I think) of the GCC available to NVCC, and NVLink.
Under what conditions would linking succeed?
I ask because I remember trying to use multiple versions of LLVM-produced object files and getting something along the lines of a bitstream version mismatch, but I don’t remember if that was because I was using LTO or something else.
| 16:45:25 |
| SomeoneSerge (back on matrix) | I'm pretty sure there are no compatibility guarantees, but idk under what conditions it might work by accident | 17:00:55 |
| SomeoneSerge (back on matrix) | But this still fails early, no? | 17:04:11 |
| Gaétan Lepage | Yes, because this package is not available for cuda 12.8 | 19:46:18 |
| SomeoneSerge (back on matrix) | In reply to @glepage:matrix.org
Yes, because this package is not available for cuda 12.8 But this should not be an eval error, unless via meta.unsupported or meta.broken | 20:06:56 |
