Re: First Mantic Minotaur test rebuild
On Wed, Sep 13, 2023 at 06:42:11PM -0300, Andreas Hasenack wrote: > > 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? Yes, you would need to update the .symbols files. I would recommend simply dropping them rather than marking them optional, since if they come back again that indicates a DIFFERENT problem. If you need something upstreamable to Debian, then you'll need to mark them optional since Debian unstable is still on glibc 2.37. -- 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
Re: First Mantic Minotaur test rebuild
Hi Steve, On Wed, Sep 13, 2023 at 6:25 PM Steve Langasek 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 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[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
Re: First Mantic Minotaur test rebuild
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 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[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