| 18 Oct 2024 |
 Gaétan Lepage | Glad that it's useful for you ! Sometimes I wonder if there are people using the nix python set ^^.
Indeed, each update involves some work. While most of the time it is pretty straightforward, the recent changes (related to bazel) are much more annoying. | 22:31:53 |
| Gaétan Lepage | hexa (UTC+1) I am indeed unable to build tensordict from my torch 2.5.0 update PR.
I systematically gets stuck at 22%, no matter the core count apparently.
I will try to investigate this tomorrow. | 22:41:37 |
 hexa | Thank you. | 22:42:09 |
| 19 Oct 2024 |
| Gaétan Lepage | Very weird, I was now able to build it.
It does this in the middle, but the tests are apparently all succesfull. | 11:35:50 |
| Gaétan Lepage | 
Download clipboard.png | 11:35:54 |
| Gaétan Lepage | Sometimes this message doesn't show up and the package builds just fine... | 11:47:44 |
| hexa | as I said, 6th gen intel breaks, 8th gen intel works | 12:53:32 |
| hexa | both are essentially skylake | 12:53:40 |
| hexa | my build farm is 6th gen fwiw | 12:53:45 |
 hacker1024 | In reply to @hexa:lossy.network
reliably crashes and gets stuck on 6th gen intel Could it be out of date microcode? | 12:55:56 |
| hexa | 🤔 | 12:56:10 |
| hexa | hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;
| 12:56:44 |
| 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 |
