| 30 Jan 2026 |
 Ihar Hrachyshka | there's also smth called max-silent-time that apparently can shoot a job if it doesn't print for a while | 01:18:57 |
 Austin Horstman | ah yeah | 01:19:21 |
| Austin Horstman | so might run into what i saw locally where it seemingly was hanging on the same stdout for hours | 01:19:39 |
| Ihar Hrachyshka | default at 2h though | 01:19:43 |
| Ihar Hrachyshka | yeah if it really hangs there without an output for that long... I haven't seen this happening though locally. | 01:20:19 |
| Austin Horstman | I had the one successful build the other day that took 10 hours and then each build after i had tried would just hang seemingly and i lost patience and killed them | 01:20:39 |
| Austin Horstman | always seems to be on that crash_helper | 01:21:21 |
| Ihar Hrachyshka | not always, I see some jobs end at libavcodec: https://hydra.nixos.org/build/319560478/log | 01:21:49 |
| Austin Horstman | oh okay | 01:22:01 |
| Ihar Hrachyshka | it would be nice of Hydra to 1) show if a job died because of silence and 2) include timestamps in logs. | 01:22:33 |
| Austin Horstman | i was wondering about timestamps the other day, as well | 01:23:30 |
| Austin Horstman | would be nice to see when viewing logs | 01:23:36 |
| Ihar Hrachyshka | I'm leaning to revert this LTO patch and take more time to get it to shape. maybe introduce it as a separate firefox-lto package for now not to disrupt users... | 01:24:47 |
 Randy Eckenrode | FWIW, my kosmickrisp branch is now tracking the Mesa 26.0 release candidates. | 01:30:22 |
| Ihar Hrachyshka | hm. for firefox packages, we already set meta.maxSilent = 14400; # 4h, double the default of 7200s (c.f. #129212, #129115) | 01:41:12 |
| Ihar Hrachyshka | (assuming it's respected by hydra) 4h > time the failing jobs are allowed to run | 01:43:15 |
| Ihar Hrachyshka | this comment suggests that if we would have a silence trigger we would see a message at the end informing about it https://github.com/NixOS/nixpkgs/issues/129115#issuecomment-873390598 | 01:47:18 |
| Ihar Hrachyshka | gonna run overnight this: nix build .#firefox-unwrapped 2>&1 | stdbuf -oL -eL ts '[%Y-%m-%d %H:%M:%S]' | tee build.log to see what's the longest interval between timestamps on my machine | 02:22:35 |
| Ihar Hrachyshka | * gonna run overnight this: nix build -L .#firefox-unwrapped 2>&1 | stdbuf -oL -eL ts '[%Y-%m-%d %H:%M:%S]' | tee build.log to see what's the longest interval between timestamps on my machine | 02:23:10 |
 Tristan Ross | There's a Rust project I have that I am trying to mostly statically link, it seems like it's trying to use libc++ from the system which I am believing is causing a mutex error on exit. Is there an easy way to make libc++ be statically linked instead of dynamically linked. | 11:42:17 |
| Randy Eckenrode | Use pkgsStatic.llvmPackages.libcxxStdenv to build it? | 11:45:02 |
| Tristan Ross | Oh yeah, forgot that exists | 11:48:10 |
| Tristan Ross | Omg, that fixed it. Thanks Randy for reminding me that exists. | 11:48:59 |
| Tristan Ross | Also, I managed to test https://github.com/NixOS/nixpkgs/pull/485174 and it at least fixes swift being compiled. | 11:54:50 |
| Randy Eckenrode | So fixing Linux is what’s left? | 11:57:44 |
| Tristan Ross | Yes, it does appear that way | 11:58:03 |
| Tristan Ross | Which imo, this should be at least a Darwin fix since that seems more critical | 11:58:18 |
| Ihar Hrachyshka | See my nixpkgs review dump there in a comment too. (Probably was an overkill to run the whole tree...) Once commit message is fixed, let's merge it.
I didn't expect swift will be master admissible since it broke a lot for me personally. | 11:58:25 |
| Tristan Ross | A separate PR fixing swift on Linux should be fine. | 11:58:45 |
| Tristan Ross | Oh great, it broke again | 12:04:14 |
