Hi Andreas, On Mon, Sep 11, 2023 at 05:37:05PM -0300, Andreas Hasenack wrote: > Hi, > > On Wed, Sep 6, 2023 at 6:19 AM Graham Inggs <gin...@ubuntu.com> wrote: > > > > The first test rebuild of Mantic Minotaur was started on August 30, > > 2023 for all architectures, all components. The rebuild is finished > > for the main component on all architectures except riscv64, and still > > running for universe and multiverse. > > > > Results (please also look at the superseded builds) can be found at: > > > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20230830-mantic-mantic.html > > Many of these failures are caused by glibc 2.38 now having strlcat and > friends, and this causes a dpkg-gensymbols error like this (example > from src:libqb):
<snip> > Do we have a pattern to fix these, or a checklist? Mark them as > optional I suppose, but how can we be sure reverse dependencies aren't > relying on these strl* symbols, do we rebuild them all? It may sound > far fetched, but I suppose some application could have been relying on > strlcat from bin:libqb100 (even though it's not declared in > libqb-dev's /usr/include/qb/* anywhere). > > I saw the fix[1] to krb5's build issue, but there the symbol was > internal (but still exposed?). Is that what we need to apply, > including the replacing of #MINVER# in the symbols file to a strict > "equals", which is what I assume changes the shlibs:Depends from a ">= > MINVER" to "= $ver", and thus accounts for the ordering of upgrades? > And still a breaks for the other binary packages produced by the same > source? krb5 was a special case because its "internal" symbols used a prefixed name, so the glibc implementation was not a drop-in ABI-compatible replacement. For the common case, libraries are providing symbols with the literal names "strlcat" and "strlcpy"; if the build system detects these names in the system libc it will omit them at build time. Unless there's some extremely unusual linkage, reverse-dependencies that need this symbol will then just pick it up from libc6 instead. So if these library packages pick up a versioned Depends: on libc6 (>= 2.38) automatically, no further source changes should be needed. And if they don't have a versioned Depends: for some reason, it should be sufficient to manually add one. There had previously been mention on IRC of declaring Breaks: between libc6 and the packages. However, having thought this through just now I believe that's unnecessary, and also doesn't actually adequately solve anything. The versioned Depends: should be sufficient. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
