Control: tags -1 = confirmed On 2022-10-30 19:06:09 +0100, Aurelien Jarno wrote: > On 2022-10-30 17:10, Sebastian Ramacher wrote: > > Control: forwarded -1 > > https://release.debian.org/transitions/html/glibc-2.36.html > > Control: tags -1 moreinfo > > > > On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian....@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: debian-gl...@lists.debian.org > > > > > > Dear release team, > > > > > > I would like to get a transition slot for glibc 2.36. It has been > > > available in experimental for a bit more than one month and does not > > > have any known major issue. It has been built successfully on all > > > release architectures and many ports architectures. A few issues found > > > through the autopkgtest pseudo excuses for experimental have been fixed. > > > The remaining ones are due to britney bugs, broken autopkgtest or > > > packages parts of the transition. > > > > > > As glibc is using symbol versioning, there is no soname change. That > > > said a few packages are using libc internal symbols and have to be > > > rebuilt for this transition. Here is the corresponding ben file: > > > > > > title = "glibc"; > > > is_affected = .depends ~ /libc[0-9.]* \(<</; > > > is_good = .depends ~ /libc[0-9.]* \(<< 2.37\)/; > > > is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/; > > > > > > In addition a few new symbols have been added that might prevent a few > > > other packages to migrate to testing until glibc migrates if they pick > > > up the new symbols, however those are really limited in this version and > > > mostly linked to new filesystem, processes or random functions, so > > > unlikely to be massively used by default. > > > > > > Note that this version builds with GCC 12 instead of GCC 11, so it is a > > > prerequisite for not shipping bookworm with GCC 11. > > > > Speaking of GCC 12 … #1022991 seems to have a first patch available > > upstream. Is there any chance that we could start this transition > > together with a fix for that bug? > > I would not say we have patch yet. I posted a first patch on the mailing > list yesterday [1], and we have two epidermic answers from both sides > ("Why this patch is approved?" or "So MIPS ABI idiocrasies strike > again"). One come with a proposal and another one with a partial patch. > So that's 3 different options in total. I am also worried that the > problem could be more widespread as there is a claim that clock_adjtime > is broken on all 64bit system. > > So IMHO, we should just wait that things calm done, and that people > really try to understand the problem, its consequences and how to fix > it, instead of just proposing random patches. > > But once we have something acceptable, I am find including it either in > a 2.35 upload or a 2.36 one, both are fine to me.
Okay, then let's not wait for #1022991. None of the reverse dependencies should get stuck behind gcc-12. Please go ahead with this transition. Cheers -- Sebastian Ramacher
