[Git][glibc-team/glibc][sid] restore hurd's ld.so symlink
Samuel Thibault pushed to branch sid at GNU Libc Maintainers / glibc Commits: 0cff7e8b by Samuel Thibault at 2021-04-25T18:57:59+02:00 restore hurds ld.so symlink It is not related to the multiarch path issue, but rather to a mismatch between gccs rtld name and glibcs. - - - - - 1 changed file: - debian/sysdeps/hurd-i386.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/0cff7e8b61d03ac5597d219be3b5f831a2681e7e -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/0cff7e8b61d03ac5597d219be3b5f831a2681e7e You're receiving this email because of your account on salsa.debian.org.
Processed: Bug#973278 marked as pending in glibc
Processing control commands: > tag -1 pending Bug #973278 [src:glibc] glibc autopkgtest-virt-lxc failure on arm64 Ignoring request to alter tags of bug #973278 to the same tags previously set -- 973278: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973278 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Bug#985617 marked as pending in glibc
Processing control commands: > tag -1 pending Bug #985617 [src:glibc] glibc: flaky autopkgtest on most architectures Ignoring request to alter tags of bug #985617 to the same tags previously set -- 985617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Bug#985617 marked as pending in glibc
Processing control commands: > tag -1 pending Bug #985617 [src:glibc] glibc: flaky autopkgtest on most architectures Added tag(s) pending. -- 985617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Bug#973278 marked as pending in glibc
Processing control commands: > tag -1 pending Bug #973278 [src:glibc] glibc autopkgtest-virt-lxc failure on arm64 Added tag(s) pending. -- 973278: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973278 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
[Git][glibc-team/glibc][sid] debian/patches/any/local-rtlddir-cross.diff: drop patch, letting upstream...
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc Commits: d430db62 by Aurelien Jarno at 2021-04-25T18:49:38+02:00 debian/patches/any/local-rtlddir-cross.diff: drop patch, letting upstream makefiles to install the dynamic linker symlink directly in the right location. This fixes the temporary installation done by upstream makefiles to run some tests in a container. Closes: #973278, #985617. * debian/patches/any/local-rtlddir-cross.diff: drop patch, letting upstream makefiles to install the dynamic linker symlink directly in the right location. This fixes the temporary installation done by upstream makefiles to run some tests in a container. Closes: #973278, #985617. * debian/rules.d/build.mk: do not create the dynamic linker manually. * debian/sysdeps/*.mk: do not create the dynamic linker manually for bi/tri-arch packages. * debian/rules.d/build.mk: create the soname symlink for ld-2.xx.so, to avoid its creation later by ldconfig. * debian/debhelper.in/libc.install, debhelper.in/libc-alt.install, debhelper.in/libc-udeb.install, debhelper.in/libc-udeb.install.hurd-i386: adjust given that the dynamic linker symlink is now already at the correct location. - - - - - 25 changed files: - debian/changelog - debian/debhelper.in/libc-alt.install - debian/debhelper.in/libc-udeb.install - debian/debhelper.in/libc-udeb.install.hurd-i386 - debian/debhelper.in/libc.install - − debian/patches/any/local-rtlddir-cross.diff - debian/patches/series - debian/rules.d/build.mk - debian/sysdeps/amd64.mk - debian/sysdeps/armel.mk - debian/sysdeps/armhf.mk - debian/sysdeps/hurd-i386.mk - debian/sysdeps/kfreebsd-amd64.mk - debian/sysdeps/mips64.mk - debian/sysdeps/mips64el.mk - debian/sysdeps/mips64r6.mk - debian/sysdeps/mips64r6el.mk - debian/sysdeps/mipsn32.mk - debian/sysdeps/mipsn32el.mk - debian/sysdeps/mipsn32r6.mk - debian/sysdeps/mipsn32r6el.mk - debian/sysdeps/ppc64.mk - debian/sysdeps/s390x.mk - debian/sysdeps/sparc64.mk - debian/sysdeps/x32.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/d430db6224603b9e2eb55de11fd9a0f9a61676ec -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/d430db6224603b9e2eb55de11fd9a0f9a61676ec You're receiving this email because of your account on salsa.debian.org.
Bug#985617: glibc: flaky autopkgtest on most architectures
On 2021-04-25 10:39, Simon McVittie wrote:
> On Sun, 25 Apr 2021 at 10:14:51 +0100, Simon McVittie wrote:
> > On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> > > On 25-04-2021 01:55, Aurelien Jarno wrote:
> > > > It appears that all the failures are related to containers. I have been
> > > > able to reproduce the issue with a bullseye kernel, which defaults to
> > > > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners
> > > > still use a buster kernel (at least in the case of this build log).
>
> Looking at support/test-container.c, it seems that these tests will
> automatically be skipped (FAIL_UNSUPPORTED) on a kernel that restricts
> userns creation (like buster), and will be run (and perhaps fail)
> on a kernel that does not (like bullseye). So it is not necessarily
> a *regression* that they fail - they might just never have been tried
> before we started using bullseye kernels.
>
> The brute-force approach to making the autopkgtest not be flaky would be
> to make these tests FAIL_UNSUPPORTED unconditionally, which will result
> in the same coverage we would have had on buster kernels. Obviously it
> would be better if they could be made to pass, but some reliable testing
> is better than none.
>
> These tests seem to be failing here (support/test-container.c:1095):
>
> execvp (new_child_proc[0], new_child_proc);
>
> /* Or don't run the child? */
> FAIL_EXIT1 ("Unable to exec %s\n", new_child_proc[0]);
>
> It would be useful if this printed strerror(errno) at least, so that we
> can see whether it's ENOENT or EACCES or something else.
>
> Perhaps the test support code is not copying/mounting everything that needs
> to be copied/mounted into the container's filesystem? More debug logging in
> support/test-container.c would probably be helpful here - perhaps even
> running 'find . -ls' in the new_root_path before chrooting into it?
Yes, this is exactly the problem. This is due to patch
any/local-rtlddir-cross.diff, which remove a snippet of code installing
the ld.so symlink. Instead this is done in an ugly way in the
debian/rules.d/build.mk. Both can be dropped to make things working
fine. However I am not sure what are the consequences on cross builds,
which anyway also use the same code from build.mk. I am currently
investigating.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#985617: glibc: flaky autopkgtest on most architectures
On Sun, 25 Apr 2021 at 10:14:51 +0100, Simon McVittie wrote:
> On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote:
> > On 25-04-2021 01:55, Aurelien Jarno wrote:
> > > It appears that all the failures are related to containers. I have been
> > > able to reproduce the issue with a bullseye kernel, which defaults to
> > > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners
> > > still use a buster kernel (at least in the case of this build log).
Looking at support/test-container.c, it seems that these tests will
automatically be skipped (FAIL_UNSUPPORTED) on a kernel that restricts
userns creation (like buster), and will be run (and perhaps fail)
on a kernel that does not (like bullseye). So it is not necessarily
a *regression* that they fail - they might just never have been tried
before we started using bullseye kernels.
The brute-force approach to making the autopkgtest not be flaky would be
to make these tests FAIL_UNSUPPORTED unconditionally, which will result
in the same coverage we would have had on buster kernels. Obviously it
would be better if they could be made to pass, but some reliable testing
is better than none.
These tests seem to be failing here (support/test-container.c:1095):
execvp (new_child_proc[0], new_child_proc);
/* Or don't run the child? */
FAIL_EXIT1 ("Unable to exec %s\n", new_child_proc[0]);
It would be useful if this printed strerror(errno) at least, so that we
can see whether it's ENOENT or EACCES or something else.
Perhaps the test support code is not copying/mounting everything that needs
to be copied/mounted into the container's filesystem? More debug logging in
support/test-container.c would probably be helpful here - perhaps even
running 'find . -ls' in the new_root_path before chrooting into it?
smcv
Bug#985617: glibc: flaky autopkgtest on most architectures
On Sun, 25 Apr 2021 at 08:11:48 +0200, Paul Gevers wrote: > On 25-04-2021 01:55, Aurelien Jarno wrote: > > It appears that all the failures are related to containers. I have been > > able to reproduce the issue with a bullseye kernel, which defaults to > > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners > > still use a buster kernel (at least in the case of this build log). > > That's correct, all workers run stable except s390x. > > > Could it be that kernel.unprivileged_userns_clone is enabled on some of > > the runners? > > If I want to make our workers equal, I guess > changing them all to the default sounds sane, right? Do you know if the > default is different for buster and bullseye? The default was kernel.unprivileged_userns_clone=0 in buster kernels and was switched to kernel.unprivileged_userns_clone=1 in bullseye kernels. References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446 https://salsa.debian.org/kernel-team/linux/-/commit/a381917851e762684ebe28e04c5ae0d8be7f42c7 If you want a quick way to get consistent behaviour, installing the bubblewrap package from bullseye (but not buster-backports!) installs a sysctl.d fragment to set kernel.unprivileged_userns_clone=1 even on older kernels. smcv
Bug#985617: glibc: flaky autopkgtest on most architectures
Hi Aurelien, On 25-04-2021 01:55, Aurelien Jarno wrote: > It appears that all the failures are related to containers. I have been > able to reproduce the issue with a bullseye kernel, which defaults to > kernel.unprivileged_userns_clone=1. It seems the autopkgtest runners > still use a buster kernel (at least in the case of this build log). That's correct, all workers run stable except s390x. > Could it be that kernel.unprivileged_userns_clone is enabled on some of > the runners? It doesn't seem to be the case of all the runners as the > autopkgtest ran successfully for the latest glibc upload. paul@mulciber ~/debian-maint/ci.d.n-config $ rake -j40 run:workers # Enter command to run (use arrow keys for history): $ cat /proc/sys/kernel/unprivileged_userns_clone [] ci-worker-armhf-01: 0 ci-worker13: 1 ci-worker-s390x-01: 1 ci-worker12: 0 ci-worker11: 0 ci-worker03: 0 ci-worker05: 0 ci-worker-i386-04: 1 ci-worker-i386-01: 1 ci-worker-i386-03: 1 ci-worker06: 0 ci-worker01: 1 ci-worker09: 0 ci-worker07: 0 ci-worker-i386-02: 0 ci-worker02: 0 ci-worker10: 0 ci-worker-ppc64el-02: 0 ci-worker-ppc64el-04: 0 ci-worker04: 0 ci-worker08: 0 ci-worker-arm64-04: 0 ci-worker-ppc64el-03: 0 ci-worker-arm64-07: 1 ci-worker-arm64-02: 0 ci-worker-arm64-05: 0 ci-worker-arm64-06: 0 ci-worker-arm64-03: 0 ci-worker-arm64-11: 0 ci-worker-arm64-08: 0 ci-worker-arm64-09: 1 ci-worker-arm64-10: 0 ci-worker-ppc64el-01: 0 [Note: some ci-workerXX are i386 workers, most are amd64]. > In anycase as it is reproducible with the bullseye kernel, this > definitely needs a fix. Thanks for working on this. If I want to make our workers equal, I guess changing them all to the default sounds sane, right? Do you know if the default is different for buster and bullseye? If so, does it make sense to already go with the bullseye default? Paul OpenPGP_signature Description: OpenPGP digital signature
