Package: glibc-source
Version: 2.28-1
Severity: important
autopkgtest fails while trying to test whether glibc in unstable could
migrate to testing:
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/1438735/log.gz
> tar -x -f /usr/src/glibc/glibc-2.28.tar.xz
> cp -a /usr/src/glibc/debian/ glibc-2.28
> cd glibc-2.28 ; \
> QUILT_PATCHES=/tmp/autopkgtest-lxc.ufw2cd2w/downtmp/build.UwU/src/debian/patches/glibc/debian
> quilt --quiltrc /dev/null push -a && \
> rm -rf .pc/
> Applying patch dpkg-shlibs.patch
> patching file debian/rules.d/debhelper.mk
>
> Applying patch local-kill-locales.patch
> patching file debian/rules
> patching file localedata/SUPPORTED
> Hunk #1 FAILED at 2.
> 1 out of 1 hunk FAILED -- rejects in file localedata/SUPPORTED
I think this means glibc-source should have a Breaks: on some binary
package that gets installed by cross-toolchain-base's autopkgtest, so
that the testing migration infrastructure knows that cross-toolchain-base
28 and glibc-source 2.28 is not a valid combination.
Unfortunately, cross-toolchain-base's d/tests/control doesn't include
any binary packages built by cross-toolchain-base. Perhaps one needs to
be added, as a way to tell the testing migration infrastructure what is
going on?
Presumably this also means that cross-toolchain-base's autopkgtest is
not actually testing anything about the previously built .debs, which
seems contrary to the design of autopkgtest. I would have expected an
autopkgtest for cross-toolchain-base to be something more like this:
- install linux-libc-dev-arm64-cross, libc6-arm64-cross, etc.
- use them to compile and link a "hello, world" arm64 executable
- (optionally) use qemu or something to run it
where the choice of arm64 is arbitrary, but should ideally not match
the architecture of the CI infrastructure.
smcv
