Friday, 30 November 2018

Re: help with sbuild dep8 failures on i386/bionic

On Fri, Nov 30, 2018 at 05:04:35PM -0200, Andreas Hasenack wrote:
> The test basically uses sbuild to build procenv on the current devel
> version of ubuntu. Today, that's disco. At the end of the build, it
> tries to install the built package on the host, and this is the first
> red flag.

I guess this should either build on the host series, or else it should
create a new temporary schroot and install the built package in that for

> That is why it's failing on i386:
> The following packages have unmet dependencies:
> procenv : Depends: libc6 (>= 2.28) but 2.27-3ubuntu1 is to be installed
> E: Unable to correct problems, you have held broken packages.
> bionic has libc6 2.27, disco has libc6 2.28. So the above error makes sense.
> But in the amd64 build, this does not happen. The built package has
> this Depends line:
> Depends: libc6 (>= 2.17), libcap2 (>= 1:2.10), libnuma1 (>= 2.0.11),
> libselinux1 (>= 1.32)
> How?? Going up in the dep8 logs even shows that it used libc6-dev-2.28
> in the sbuild :)

The libc6 dependency that a binary package gains when built isn't
necessarily the same as the libc6-dev version that was installed when it
was built. The major point of symbols files is to allow library
dependencies to be weaker when the binary doesn't actually need a newer
version of the library, checking on a symbol-by-symbol basis.

Presumably some quirk of the architecture-specific code for i386 in libc
means that procenv ends up needing 2.28 on that architecture; for
instance, this might happen if the implementation of a syscall wrapper
changed on i386 in such a way as to cause binaries built using 2.28
headers to require a newer libc at runtime. This sort of thing is in
fact not all that uncommon, particularly given the large amount of
architecture-specific code in libc.

You could probably narrow down exactly what symbols are involved by
doing "objdump -wT" on the built i386 procenv binary and looking for
GLIBC_2.28 symbols, although it probably isn't necessary to track that
down since it's clear that the test is buggy: building a package on a
newer series and trying to install it on an older one isn't something
that can be guaranteed even if it often works.

Colin Watson []

ubuntu-devel mailing list
Modify settings or unsubscribe at: