Hi, On 2023-03-16 13:44, Paul Gevers wrote: > Hi, > > [@aurel32, glibc question at the bottom] > > On 16-03-2023 11:57, Bastian Germann wrote: > > Am 16.03.23 um 09:13 schrieb Paul Gevers: > > > I'm not 100% sure I parse that sentence as you intended, so let me > > > ask explicitly: if we binNMU (now or in the future) src:argon2 > > > version 0~20171227-0.3 in bookworm, would it also loose its linking > > > to libpthread? That would be a time bomb (not only in the archive, > > > but also for downstreams and other users that do rebuilds). I > > > *think* you're saying that despite libc's version, that is *not* the > > > case. > > > > Time bomb confirmed. > > Thanks. That changes things. > > > > For the record, with my current understanding I prefer the scenario > > > of keeping the versions of argon2 and cryptsetup in bookworm as they > > > are. Feel free to convince the Release Team of the opposite in an > > > unblock request. > > > > cryptsetup will need to migrate to mitigate the time bomb. > > Ack. > > > As I already mentioned on this or some related bug, I would find it nice > > for #1014110 to be fixed in bookworm (threaded argon2 executable) but I > > do not insist on it. > > cryptsetup can only migrate when argon2 migrates, which leaves me two > options: letting argon2 in as it is now in unstable or going for cryptsetup > via t-p-u. Both sub-optimal, because argon2 has changes that weren't even > meeting the freeze policy rules at the time of the upload. > > While writing this up and discussing with others, I realized that the error > is coming from one of glibc's binaries. It has been stated that the issue > started with with a change there, but is that change done on purpose, or a From what I understand the change has been triggered by the move of the pthread_exit() function from libpthread.so.1 to libc.so.6, which happened in glibc 2.34. libgcc_s.so.1 is loaded dynamically when such function is used to avoid a dependency loop, so libc.so.6 is NOT linked against libgcc_s.so.1. This is not something new, it has been like that for 10+ years. > bug? I.e. is one of glibc's binaries missing a dependency? Technically the libc6 package is indeed missing a dependency against libgcc-s1. This is not an issue given libgcc-s1 is de facto essential. On the glibc side, it should be possible to add such a dependency (although it would not have prevented this bug), but that will create a dependency loop, and tools (apt, aptitude, rebootstrap, ...) would have to learn how to deal with it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature