help with sbuild dep8 failures on i386/bionic

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

help with sbuild dep8 failures on i386/bionic

Andreas Hasenack-5
Hi,

I have a couple of SRUs that are triggering sbuild DEP8 runs on bionic
and these are only failing on i386:

http://autopkgtest.ubuntu.com/packages/s/sbuild/bionic/i386
http://autopkgtest.ubuntu.com/packages/s/sbuild/bionic/amd64

I triggered those using debootstrap from proposed, otherwise we hit
another bug where "disco" is unknown.

I can reproduce the failure on bionic i386, but I cannot explain how
it is even supposed to work in any architecture.

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.

From debian/tests/build-procenv:
...
# We should probably only attempt to install and run procenv if the release of
# the build chroot is equal to the host, but lets be brave and try anyway
if true
#if [ "$release" = "$host_release" ]
then
    echo "INFO: Installing package '$pkg' from '$deb'"

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 :)

I'm baffled.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: help with sbuild dep8 failures on i386/bionic

Colin Watson
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
testing.

> 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                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: help with sbuild dep8 failures on i386/bionic

Andreas Hasenack-5
On Fri, Nov 30, 2018 at 7:54 PM Colin Watson <[hidden email]> wrote:

>
> 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
> testing.

And the fact that it is building in the devel series is another source
of failures, because debootsrap in bionic doesn't know about disco
yet, it's another SRU stuck in proposed.


> > 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.

Thanks, I'll make an MP to fix the test.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel