| 19 Feb 2025 |
 SomeoneSerge (back on matrix) | Let's start with some high-level questions before delving into the code?
setup hooks for the package set (this includes wrapping NVCC such that we get rid of backendStdenv)
Removing backendStdenv for wrappers implies we commit t hey o support mixed stdenvs. This might not even be supported by upstream projects (llvm, gcc), and you've already discovered the incompatibility for LTO. I'm thinking if there are any downsides to introducing the wrapper code and still using the wrapper with the single (no mixing) stdenv in Nixpkgs. That way out-of-tree derivations already can (ab)use the wrapper without knowing it exists and without knowing they actually need to replace the stdenv
introduction of rewritten modules, top-level/cuda-packages.nix, and the remainder of the changes
What's the gist of the rewrite?
| 09:52:44 |
| SomeoneSerge (back on matrix) | Something like, an individual buys a piece of equipment and gets a reimbursement from the opencollective fund? Totally fine by me, the question is, is this transparent enough for users and sponsors. In addition to off-boarding issues, we should sooner or later figure out transparency of physical access to the infra (for all you know I'm a Russian sleeper agent) | 10:01:21 |
| SomeoneSerge (back on matrix) | * Something like, an individual buys a piece of equipment and gets a reimbursement from the opencollective fund? Totally fine by me (EDIT: except we can't write VAT off?), the question is, is this transparent enough for users and sponsors. In addition to off-boarding issues, we should sooner or later figure out transparency of physical access to the infra (for all you know I'm a Russian sleeper agent) | 10:02:23 |
 Jonas Chevalier | We can maintain a page like OpenWRT does, with who owns what machine: https://openwrt.org/infrastructure#servers | 10:55:50 |
| 20 Feb 2025 |
 connor (burnt/out) (UTC-8) | I’ll get on a gist of a rewrite, as well as design tradeoffs in offering a wrapped cuda_nvcc, cudaStdenv, or changing the global stdenv when cudaSupport is enabled (to provide both LTO and to prevent any possibilities of linking against multiple copies of glibc/glibcxx) | 06:31:21 |
| 21 Feb 2025 |
|  @tillerino:matrix.org joined the room. | 17:14:13 |
| 23 Feb 2025 |
|  asa joined the room. | 09:07:57 |
| 25 Feb 2025 |
| connor (burnt/out) (UTC-8) | In reply to @connorbaker:matrix.org
I’ll get on a gist of a rewrite, as well as design tradeoffs in offering a wrapped cuda_nvcc, cudaStdenv, or changing the global stdenv when cudaSupport is enabled (to provide both LTO and to prevent any possibilities of linking against multiple copies of glibc/glibcxx) I am still doing this, among other things | 00:09:17 |
| 26 Feb 2025 |
| connor (burnt/out) (UTC-8) | Anyone free to review https://github.com/NixOS/nixpkgs/pull/383214 and https://github.com/NixOS/nixpkgs/pull/383511? | 15:34:10 |
| SomeoneSerge (back on matrix) | In my backlog but might take me until the end of the week. I wish I could switch earlier | 15:54:52 |
 hexa | wondering if anyone here cares about onnxruntime a bit | 17:52:35 |
| hexa | enabling openvino support breaks the tests for some reason, since it cannot find libonnxruntime_providers_shared.so in $out/lib/ | 17:52:55 |
| hexa | * enabling openvino support breaks the tests for some reason, since it cannot find libonnxruntime_providers_shared.so in $out/lib/ | 17:53:06 |
| hexa | * enabling openvino support breaks the tests for some reason, since it cannot find libonnxruntime_providers_shared.so in $out/lib/ | 17:53:11 |
| hexa | so I added a condition to disable the tests with openvinoSupport | 17:53:39 |
| hexa | >>> rt.get_available_providers()
['OpenVINOExecutionProvider', 'CPUExecutionProvider']
| 17:53:42 |
| hexa | * so I added a condition to disable the tests with openvinoSupport, which gets me to here: | 17:53:54 |
| hexa | now I wonder if enabling openvino by default is a good idea, when it requires disabling the tests | 17:54:14 |
| hexa | the alternative would be that I enabled openvino support just in the downstream package that wants it | 17:58:20 |
| hexa | * the alternative would be that I enable openvino support just in the downstream package that wants it | 17:58:26 |
| connor (burnt/out) (UTC-8) | I haven’t found a use for it yet for the stuff I’d work on if I had time, so my only interaction with the ONNX ecosystem has been packaging it with CUDA support, and that’s been horrible… so I’m not inclined to look into it beyond what I absolutely must | 19:38:57 |
| 27 Feb 2025 |
|  mac joined the room. | 02:57:20 |
| 28 Feb 2025 |
| hexa | SomeoneSerge (UTC+U[-12,12]): in opencv, why cxxdev and not dev as the output name? | 05:57:42 |
| hexa | and what does that mean for buildInputs? | 05:58:37 |
| hexa | oh, opencv has no dev output | 05:59:19 |
| hexa | and openvino has been using the wrong output all along | 05:59:33 |
| hexa | 🤦♂️ | 05:59:36 |
| hexa | couldn't the effectiveStdenv pattern be reduced to | 06:19:53 |
| hexa | +, stdenv ? if cudaSupport then cudaPackages.backendStdenv else stdenv
| 06:19:56 |
| hexa | * , stdenv ? if cudaSupport then cudaPackages.backendStdenv else stdenv
| 06:20:01 |
