On Fri, Nov 30, 2018 at 7:54 PM Colin Watson 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
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
