On Mon, Sep 11, 2023 at 05:37:05PM -0300, Andreas Hasenack wrote:
> On Wed, Sep 6, 2023 at 6:19 AM Graham Inggs <email@example.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):
> 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 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
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/