| 28 Jan 2026 |
 xored | so I was looking into something more permanent kekw | 18:19:02 |
 samasaur | if you're willing to eat the rebuilds you can also use an overlay to set swift to the swift from the most recent working nixpkgs rev | 18:19:26 |
| samasaur | it should? can you put your dev shell here | 18:19:38 |
| xored | I posted in on the nixos matrix https://privatebin.net/?559555911f9a6e7b#4fEWckXtjgczBC4Zn3LUdVSEcYQXJrzB1Z1mNdQdu12Q | 18:20:03 |
 Ihar Hrachyshka | (btw I'm also running a bisect on my machines right now but it's some back and forth because some packages need temp patches to get to swift) | 18:20:07 |
| xored | I think I might've messed up and the overlay is only applied to the host | 18:20:45 |
| xored | not the devshell | 18:20:50 |
| samasaur | that sounds reasonable | 18:21:19 |
| xored | I have no idea how to apply it to the devshell though | 18:21:40 |
| xored | cost of abstraction if you will | 18:21:48 |
| samasaur | yeah i fear you are correct. hopefully i get lucky though haha | 18:22:02 |
| samasaur | i feel like there should be an easy way to detect whether swift itself fails to build or whether a dependency fails to build but the only thing coming to mind is parsing the output of nix build, which i don't want to do | 18:23:02 |
| Ihar Hrachyshka | I think yes, parsing is the way. which is why I was saying - maybe worth instructing an agent with a sample to look for and let it do the job. I'm actually thinking I should take this shower thought seriously and build a tool. will call it 'aisect' :D | 18:24:12 |
| samasaur | that would be cool | 18:24:54 |
| samasaur | my bisect had been running fine but i just tried to SSH into that machine to check and apparently it went offline 4 minutes ago | 18:25:20 |
| Ihar Hrachyshka | the agent could also do the doCheck = true -> false flips I think etc. | 18:25:28 |
| samasaur | which i fear may have been my fault | 18:25:33 |
| Ihar Hrachyshka | I hit bison failures from get go on first good-to-bad iteration | 18:26:04 |
| Ihar Hrachyshka | * I hit bison test suite failures from get go on first good-to-bad iteration | 18:26:12 |
| samasaur | i checked an hour ago or so and the bisect was still running, though ofc it could have logged a bad rev due to deps | 18:26:57 |
 Randy Eckenrode | Hmm. D-Bus 1.16 appears to expect that it will be socket-activated with launchd on macOS. | 18:47:25 |
| Randy Eckenrode | That’s a problem for packages that need D-Bus during their build/tests. | 18:47:51 |
| samasaur | ah ha my build machine is back online! and the bisect finished! unfortunately it has pointed me to d4fd918e which has changes that are cygwin-only, so im gonna take a wild guess and say that it is not the commit causing the problem | 18:49:28 |
| Ihar Hrachyshka | I'm still early in the process, at a point where every step rebuilds the world (as you shrink the diff, the chance is higher that the next step won't require a world rebuild). let's see who's first. :p | 18:52:32 |
| Ihar Hrachyshka | swift> Running phase: unpackPhase
swift> unpackPhase completed in 28 minutes 11 seconds
is this... normal?
| 22:06:48 |
| xored | swift strikes again | 22:13:30 |
| Ihar Hrachyshka | I think it may be my old with the node where coreutils for some reason starts lagging | 22:15:03 |
| Randy Eckenrode | It’s not fast. Swift unpacks itself, LLVM, etc. | 22:15:12 |
| Ihar Hrachyshka | I see xargs ... sed now in patchPhase sitting for 10 mins+ patching | 22:15:21 |
| Ihar Hrachyshka | I had it in the past where at random moments builds stalled. maybe the issue is back. | 22:15:52 |
