| 30 Jan 2026 |
 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 |
| Tristan Ross | libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
| 12:05:07 |
| Tristan Ross | Idk how it's got this issue when libc++ should be statically linked here fully. | 12:05:51 |
| Tristan Ross | Do my buildInputs need the static libc++ derivation? | 12:06:51 |
| Randy Eckenrode | It’s part of the stdenv. | 12:07:35 |
| Randy Eckenrode | You can use otool -L to see whether it’s linking the system one. I can’t remember how libcxxStdenv is defined, but I thought it always used libc++ from Nixpkgs. | 12:08:35 |
| Randy Eckenrode | If you don’t have Xcode installed nix shell nixpkgs#llvmPackages.bintools-unwrapped --command llvm-otool -L IIRC. | 12:09:30 |
| Tristan Ross | It still says:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
| 12:09:31 |
| Tristan Ross | Oh, libsandbox is also being included from the system huh | 12:10:28 |
| Randy Eckenrode | You can try overriding the libcxx of the static stdenv’s unwrapped cc. | 12:10:33 |
