| 10 Jan 2026 |
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 (he/him) | 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 |
| 11 Jan 2026 |
| ivan joined the room. | 01:55:43 |
Gaétan Lepage | FYI, merged the onnx 1.20.1 update
https://github.com/NixOS/nixpkgs/pull/478567 | 09:31:04 |
| ghpzin changed their display name from ghpzin (moved to @ghpzin:envs.net) to ghpzin. | 15:04:47 |
| @ghpzin:envs.net left the room. | 16:16:27 |
connor (he/him) | Anyone want to start on the OpenCV bump if there isn’t one already | 18:50:29 |
Gaétan Lepage | Sure, opened https://github.com/NixOS/nixpkgs/pull/479136. Not tested yet. | 20:19:53 |
Gaétan Lepage | After a shameful number of hours spend on building the latest ORT, I finally succeeded!
The PR has been opened since Oct. 10 2025!
Thanks to @yuyurureka who found the last missing patch to make the thing build!
Not thanks to Microslop for shipping broken software.
https://github.com/NixOS/nixpkgs/pull/450587 | 23:30:41 |
Gaétan Lepage | * After a shameful number of hours spend on building the latest ORT, I finally succeeded!
The PR has been opened since Oct. 10 2025!
Thanks to @yuyurureka who found the last missing patch to make the thing build!
Not thanks to Microslop for shipping broken software.
https://github.com/NixOS/nixpkgs/pull/450587
EDIT: still fails with cudaSupport and rocmSupport :') | 23:36:02 |
Gaétan Lepage | * After a shameful number of hours spend on building the latest ORT, I finally succeeded!
The PR has been opened since Oct. 10 2025!
Thanks to @yuyurureka who found the last missing patch to make the thing build!
Not thanks to Microslop for shipping broken software.
https://github.com/NixOS/nixpkgs/pull/450587
EDIT: still fails with cudaSupport and rocmSupport :')
EDIT2: turns out they seem to have removed Rocm support (https://github.com/microsoft/onnxruntime/pull/25181) | 23:59:01 |
| 12 Jan 2026 |
ghpzin | Madouura has not been active for over a year and their maintainer entry was removed, probably better to ping rocm team. From PR description they seem to have removed support for ROCM EP and expectation is to use MIGraphX EP instead. https://onnxruntime.ai/docs/execution-providers/ROCm-ExecutionProvider.html
NOTE ROCm Execution Provider has been removed since 1.23 release. Please Migrate your applications to use the MIGraphX Execution Provider
| 00:28:11 |
Gaétan Lepage | Thanks for the heads up regarding Madouura's situation.
Considering the amount of code removed, I wondered whether we could still do something. | 08:58:39 |
Gaétan Lepage | Thanks for the review connor (burnt/out) (UTC-8). Anything left to consider before merging?
I didn't spot any major regressions. | 15:45:59 |
Gaétan Lepage | opencv4Full with cudaSupport looks problematic actually. | 15:49:06 |
connor (he/him) | I didn't build for aarch64-linux (with or without CUDA) or for any darwin platforms, so I guess there's still that.
As a general concern with larger rebuilds around this size it's the "use your discretion" vs. "always target staging" divide. | 15:49:52 |
connor (he/him) | How so? | 15:50:07 |
Gaétan Lepage | Nevermind, it's already broken. Not a regression. | 15:50:46 |
Gaétan Lepage | hexa (UTC+1) suggested that it could be merged into master.
I'll try to build it on the other platforms. | 15:52:23 |
hexa | you can throw opencv on top of staging-next which started earlier | 15:53:09 |
connor (he/him) | To clarify, can or should? | 15:53:42 |
hexa | slight preference | 15:54:13 |
hexa | because while these were 500-1000 builds they gravitated to the more annoying end of builds | 15:54:29 |
Gaétan Lepage | Ok, I'll target staging-next once I'm done building for all platforms | 15:55:50 |
connor (he/him) | Any thoughts on whether it’s suitable for backport to 25.11? Would unbreak CUDA 13 functionality there which I welcome | 17:09:22 |