Hi, On 2026-10-21 13:03, Nick Desaulniers wrote: > On 2026-04-08 11:11, Florian Bezdeka wrote: > > Hi Aurelien, > > > > On Tue, 2026-04-07 at 21:44 +0200, Aurelien Jarno wrote: > > > > > > At this stage I am not fully convinced: > > > > > > - It is not clear to me which software is currently affected by this > > > bug, and thus it's difficult to judge how important is it to fix this > > > bug, especially given this is not a regression from bullseye (the bug > > > is present in that version). Do you have some real examples of > > > affected software that can show it's important to fix this bug in > > > bookworm? > > > > That's hard to tell. I'm quite sure that there are Debian package > > affected by this problem but the "lockup" isn't happening that often, so > > that those problems likely stay unreported. > > Hi, I think we're also hitting this issue on Android's host build > machines running bookworm; it seems that LLVM's multithreaded linker, > lld, can miss wakeup signals causing the linker to deadlock. > > See also: https://github.com/llvm/llvm-project/pull/231314 > > Did this ever end up getting resolved?
At this stage no. The patchset is not trivial, and while it definitely fixes the issue, we know it breaks software using process-shared condition variables in files on disk, which at minimum needs to be restarted. It is difficult to evaluate what could be the impact of bookworm as a whole and on usual third party software used on it. At least compared to RPM based distributions we know that the upgrade part is not an issue (db5.3 in bookworm is not patched for this issue). And the fact it is not a regression from bullseye, makes it more problematic to possibly break other things. Now, if the debian-lts team has more ressources to evaluate that, or if they want to take the risk, it's pretty fine. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
