| 29 Jan 2026 |
 Ihar Hrachyshka | link to a bug report and/or details of what's going on at least? | 15:29:29 |
 eveeifyeve | I don't think they reported the issue directly, but I know about it hearing from ericson. | 15:30:18 |
| Ihar Hrachyshka | ericson? a man? a company? :) | 15:30:42 |
| eveeifyeve | John Ericson. | 15:31:08 |
| Ihar Hrachyshka | I guess I will proceed with bisect but...
$ git bisect visualize --no-merges --oneline
d4fd918e2cc2 libarchive: fix cygwin build
f4cd05d2e7c9 haskellPackages: mark builds failing on hydra as broken
4922225f956f haskellPackages.rhine-bayes: downgrade to match rhine
51c78494b9ff openldap: use --replace-fail instead of --replace
b770f35b4de1 openldap: fix build with structuredAttrs
79429223426a moltenvk: 1.4.0 -> 1.4.1
70f40e0a3b82 python313Packages.aiodns: 3.5.0 -> 3.6.1
50776d0e56eb apple-sdk: drop `FamilyDisplayName`
176c6512ba96 darwin.libcxx: 19.1.2+apple-sdk-15.5 -> 20.1.0+apple-sdk-26.0
Randy Eckenrode fyi
| 17:14:36 |
| Ihar Hrachyshka | anyone up to try the revert of 176c6512ba96 while I'm proceeding with the current bisect? | 17:18:01 |
|  shorden joined the room. | 17:26:56 |
 Randy Eckenrode | The idea that updating the libc++ headers would break the Swift compiler hurts my head. | 17:54:05 |
| Randy Eckenrode | Or maybe it’s that plus the hardening flags interacting badly for our 5.10.1 build. | 17:54:35 |
| Ihar Hrachyshka | I think folks on github refuted the hardening theory | 17:54:58 |
| Randy Eckenrode | Though that wouldn’t explain Linux. | 17:55:23 |
| Ihar Hrachyshka | is linux crashing the same way | 17:55:49 |
| Ihar Hrachyshka | thought it's darwin only (with swift-frontend burning) | 17:56:22 |
 samasaur | Linux was already broken in a different way; unsure if this new issue affects it too | 18:12:56 |
| Ihar Hrachyshka | if it's darwin.libcxx it just can't | 18:16:23 |
| eveeifyeve | I am just building your update-branch. WIth nix build .#swift | 18:16:28 |
| samasaur | In reply to @ihar.hrachyshka:matrix.org
if it's darwin.libcxx it just can't yea. from a "solving this" standpoint I hope it is libcxx. from an "our shared sanity" standpoint I hope it isn't | 18:22:59 |
| Ihar Hrachyshka | what would be the approach forward if we confirm the bump for libcxx is the problem? is it realistic to revert it while this is being fixed? | 18:23:34 |
| samasaur | vendor the old version inside the swift directory? | 18:23:50 |
| Ihar Hrachyshka | ah right. the power of Nix :p | 18:24:20 |
| samasaur | actually that wouldn't work I think... | 18:26:18 |
| samasaur | bc swift doesn't reference darwin.libcxx directly | 18:26:27 |
| samasaur | it builds the LLVM one | 18:26:39 |
| samasaur | so if libcxx broke something it's due to transitive behavior I think | 18:26:50 |
| Ihar Hrachyshka | "just" build a second stdenv tree for swift? | 18:26:52 |
| samasaur | dear god I hope not | 18:27:37 |
| samasaur | maybe try and track down which specific package is causing the transitive error? | 18:27:57 |
| samasaur | a dependency could have actually different behavior due to availability checking, if I understand correctly | 18:28:38 |
| samasaur | and knowing what the actual difference is might help | 18:28:54 |
| samasaur | In reply to @samasaur:matrix.org
maybe try and track down which specific package is causing the transitive error? not really sure how we'd do that though, since libcxx is in the stdenv so it affects ~all Darwin programs | 18:30:23 |
