| 19 Oct 2024 |
 hexa | which defaults on config.hardware.enableAllFirmware | 12:57:09 |
| hexa | which defaults to false | 12:57:19 |
| hexa | 🤡 | 12:57:20 |
 hacker1024 | Rip | 12:57:24 |
| hexa | thank you nixos-generate-config | 12:57:34 |
| hacker1024 | No guarantee that it'll fix it but it can't hurt | 12:57:42 |
| hacker1024 | They have long lists of errata | 12:57:52 |
| hexa | yeah, worth a try | 12:58:00 |
| hexa | can always roll back | 12:58:03 |
| hexa | thx | 12:58:58 |
 connor (he/him) | I keep forgetting I added myself as a maintainer to glibc until I get emails for reviews lmao | 19:09:59 |
| connor (he/him) | SomeoneSerge (utc+3) Gaétan Lepage thoughts on having backendStdenv automatically propagate autoAddDriverRunpath and autoPatchelfHook? I feel like forgetting to add the former is a footgun people keep firing, and the latter is a great check to make sure all your dependencies are either present or explicitly ignored. | 19:22:47 |
 Gaétan Lepage | I am not sure to be qualified to answer properly. From my point of view, these kind of automations indeed help and avoid sneaky mistakes. | 19:24:29 |
| hexa | hacker1024: I think your recommendation was spot on | 21:27:27 |
| hexa | at 22% I see the first [pt_main_thread] instances | 21:27:36 |
| hexa | and they don't seem to crash with microcode updates applied | 21:27:50 |
| hexa | wow, I hope that makes python-updates much smoother in the future | 21:28:06 |
 SomeoneSerge (back on matrix) |
a footgun people keep firing,
True
autoAddDriverRunpath
Yes and no. Yes because that'd definitely make one-off and our own contributions easier. No because once we start propagating it we lose the knowledge of which packages actually need to be patched. It still seems to me that most packages we don't have to patch because they call cudart and cudart is patchelfed. Maybe yes because I'm unsure what happens with libcudart_static.
autoPatchelfHook
I'd be rather strongly opposed to this one. Autopatchelf is a huge hammer, coarse and imprecise. It can actually erase correct runpaths from an originally correct binary. Let's reserve it for non
Another important thing to consider is (here we go again) whether we want to keep both backendStdenv and the hook and which of these things should be propagating what
| 21:29:49 |
| SomeoneSerge (back on matrix) | Even right now there's something cursed going on that e.g. triggers a "rebuild" of libcublas when you override nvcc, and I think that happens because of the propagated hook. That at the least is a surprising behaviour | 21:32:25 |
| SomeoneSerge (back on matrix) | Another "no" for autoAddDriverRunpath is that it's also just not enough anyway, because of python and all other sorts of projects where we're forced to use wrappers instead | 21:38:08 |
| SomeoneSerge (back on matrix) | I think I'd vote pro propagation if we could say with some certainty, that that is the only way to make stuff work automatically for users of libcudart_static and of cmake's CUDA::cuda_driver (just because supporting that scope sounds doable) | 21:41:59 |
| SomeoneSerge (back on matrix) | * I think I'd vote pro propagation if we could say with some certainty, that that is the only way to make stuff work automatically/correctly for users of libcudart_static and of cmake's CUDA::cuda_driver (just because supporting that scope sounds doable) | 21:42:31 |
| SomeoneSerge (back on matrix) | * I think I'd vote pro propagation if we could say with some certainty, that that is the only way to guarantee correctness for users of libcudart_static and of cmake's CUDA::cuda_driver (just because supporting that scope sounds doable) | 21:42:47 |
| SomeoneSerge (back on matrix) | hexa (UTC+1): I've been playing with (s)ccache lately and I'm almost amazed we're not using it more widely when building derivations for tests rather for direct consumption | 21:45:20 |
| SomeoneSerge (back on matrix) | * hexa (UTC+1): I've been playing with (s)ccache lately and I'm almost amazed we're not using it more widely when building derivations for tests rather than for direct consumption | 21:45:32 |
| SomeoneSerge (back on matrix) |
not using it more widely
Which I'm guessing based on the fact that the infrastructure for this is rather lacking
| 21:46:18 |
| hexa | where would results be stored? | 21:46:47 |
| hexa | caching of intermediate build steps would also be super helpful 😠| 21:48:49 |
| SomeoneSerge (back on matrix) | Same as usual, derivation outputs would be stored in the nix store, they'd never be confused with the "pure" ones because they'd have different hashes. The (s)ccache directory would have to be set up on each builder | 21:48:52 |
| SomeoneSerge (back on matrix) | In reply to @hexa:lossy.network
caching of intermediate build steps would also be super helpful 😠Yes but that's a much bigger refactor | 21:49:04 |
