Hi Steve, On Wed, Sep 13, 2023 at 6:25 PM Steve Langasek <steve.langa...@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 <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.
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
