| 25 Apr 2026 |
 kirillrdy | this is the consequences of recent staging-next merge | 10:52:17 |
 Randy Eckenrode | Oh. ☹️ | 10:52:45 |
| Randy Eckenrode | I wonder if the problem is the way it’s calculating the signature, and it’s a happy accident that both ld64 and ld-prime are effected. | 11:11:02 |
 toonn | Do the linkers use different code to perform signing? | 11:21:17 |
| Randy Eckenrode | We don’t have the source to ld-prime. My hypothesis is that the signing calculation is shared between them. | 11:31:07 |
 emily | this seems hard to reconcile with the state dependence observed by zhaofengli | 11:33:14 |
| emily | though really every data point is hard to reconcile :( | 11:33:33 |
| Randy Eckenrode | Race condition? | 11:34:02 |
| emily | it was "succeeds once on a machine and fails thereafter" IIRC | 11:35:48 |
| emily | or the reverse | 11:35:57 |
| emily | though I don't know if the test setup ruled out the path rewriting from partially present outputs thing | 11:36:20 |
| emily | but it was apparently very consistent | 11:36:39 |
| Randy Eckenrode | https://github.com/reckenrode/ld64/blob/ld64-956.6-nixpkgs/src/ld/OutputFile.cpp#L3967_L3997 | 11:40:46 |
| Randy Eckenrode | It’s calculating the hashes in parallel. Is it safe to use a std::vector like that? | 11:41:22 |
 K900 | As long as it's not pushing anything yes | 11:42:13 |
| Randy Eckenrode | Even on arm64? | 11:44:29 |
| K900 | I don't think it matters? | 11:44:41 |
| K900 | As long as all it's doing is writing to non-overlapping items | 11:45:00 |
| Randy Eckenrode | The other place it calculates the hash is in libcodedirectory. | 11:49:03 |
| Randy Eckenrode | Which ld-prime appears to be using …. | 11:51:23 |
 Ihar Hrachyshka | is TIME_WAIT 49d ticking bomb solved in latest macos or is it still a thing? I just hit it on my mac mini and i wonder if I will have to implement some kind of periodic force restart ... | 17:54:31 |
| Ihar Hrachyshka | * is TCP TIME_WAIT 49d ticking bomb solved in latest macos or is it still a thing? I just hit it on my mac mini and i wonder if I will have to implement some kind of periodic force restart ... | 17:54:47 |
 samasaur | i can't seem to reproduce it on a mac running 15.7.3 that's been up for 67d | 17:59:27 |
| Ihar Hrachyshka | mine is on 26.x | 17:59:42 |
| samasaur | hmm | 18:00:04 |
| samasaur | (also assuming u mean https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking ?) | 18:00:19 |
| Ihar Hrachyshka | yes | 18:00:51 |
| samasaur | i am surprised that i don't experience this bug on this mac but i very clearly have no connections in TIME_WAIT state | 18:01:40 |
| samasaur | which actually i should have some, shouldn't I? | 18:02:23 |
| Ihar Hrachyshka | yeah mine was full of these and so when my laptop was trying to use that mac mini as a remote builder, I was getting errors saying that all my substituters are disabled. in UI, if I tried to update macos, it said it couldn't check for new updates. etc. but - interestingly - the laptop COULD ssh into the mac mini, I guess the initiator is an important bit. | 18:03:18 |
