On Wed, Sep 13, 2023 at 6:25 PM Steve Langasek
<steve.langasek@ubuntu.com> wrote:
>
> 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 <ginggs@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.
We still need to address the removal of the strl* symbols from each
library package that previously had it in its d/*.symbols packages,
right? Should we settle on marking them as optional?
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
