* Press Ctrl-C to Stop * * sys-libs/musl-1.2.2-r7:0::gentoo * /sbin/ldconfig * /usr/bin/getconf * /usr/bin/getent ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_musl_hardened-j4-20220111-092048 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-gentoo-linux-musl-11.2.1 * clang version 13.0.0 Target: x86_64-gentoo-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/13/bin /usr/lib/llvm/13 13.0.0 Python 3.9.9 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) [3] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.57.0 * php cli: HEAD of ::gentoo commit d963e6e9023cf9a245ee161ea2f0da067508063f Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Jan 12 00:51:50 2022 +0000 2022-01-12 00:51:47 UTC emerge -qpvO sys-libs/glibc [ebuild N ] sys-libs/glibc-2.34-r6 USE="audit clone3 multiarch (ssp) (static-libs) -caps -cet -compile-locales (-crypt) -custom-cflags -doc -gd -headers-only (-multilib) -multilib-bootstrap -nscd -profile (-selinux) -static-pie -suid (-systemd) -systemtap -test (-vanilla)"
Created attachment 761951 [details] emerge-info.txt
Created attachment 761952 [details] emerge-history.txt
Created attachment 761953 [details] etc.portage.tar.bz2
Created attachment 761954 [details] logs.tar.bz2
While obviously invalid in real life, it's quite funny this isn't masked or something.
(In reply to Sam James from comment #5) > While obviously invalid in real life, it's quite funny this isn't masked or > something. +1 FWIW there's sys-libs/musl which might be masked in the opposite direction
(In reply to Toralf Förster from comment #6) > (In reply to Sam James from comment #5) > > While obviously invalid in real life, it's quite funny this isn't masked or > > something. > +1 > FWIW there's sys-libs/musl which might be masked in the opposite direction Hmm: >musl/package.mask:152:sys-libs/glibc So, how did you manage to hit this?
(In reply to Sam James from comment #7) > (In reply to Toralf Förster from comment #6) > > (In reply to Sam James from comment #5) > > > While obviously invalid in real life, it's quite funny this isn't masked or > > > something. > > +1 > > FWIW there's sys-libs/musl which might be masked in the opposite direction > > Hmm: > >musl/package.mask:152:sys-libs/glibc > > So, how did you manage to hit this? It still happens here at musl images , eg at 17.0_musl-j4-20220304-070005 , FIW I do noit test ::musl, just ::gentoo
sys-libs/glibc should be masked in musl profiles; if it isn't, that's a bug features/musl/package.mask: sys-libs/glibc @musl, hardened: You should probably doublecheck the profile inheritance. Something is fishy here.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c9dcdba33971e9b3f9037f1979f3798d736ab80 commit 1c9dcdba33971e9b3f9037f1979f3798d736ab80 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-03-19 17:35:49 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-03-19 17:36:26 +0000 profiles/default/linux: drop trailing slash from musl inherit in 'parent' file We keep seeing reports of collisions between musl/glibc but this shouldn't be possible as glibc is masked on musl profiles. Not clear if this is causing our issue but it's at the very least superfluous and maybe even wrong. Bug: https://bugs.gentoo.org/831063 Bug: https://bugs.gentoo.org/834579 Bug: https://bugs.gentoo.org/631568 Bug: https://bugs.gentoo.org/611094 Signed-off-by: Sam James <sam@gentoo.org> profiles/default/linux/amd64/17.0/musl/parent | 2 +- profiles/default/linux/arm/17.0/musl/parent | 2 +- profiles/default/linux/arm64/17.0/musl/parent | 2 +- profiles/default/linux/powerpc/ppc32/17.0/musl/hardened/parent | 2 +- profiles/default/linux/powerpc/ppc32/17.0/musl/parent | 2 +- profiles/default/linux/riscv/20.0/rv64gc/lp64d/musl/parent | 2 +- profiles/default/linux/x86/17.0/musl/parent | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-)
toralf, please let us know if it happens again
(In reply to Sam James from comment #11) > toralf, please let us know if it happens again * Press Ctrl-C to Stop * * sys-libs/musl-1.2.2-r8:0::gentoo * /sbin/ldconfig * /usr/bin/getconf * /usr/bin/getent * /usr/bin/iconv * /usr/bin/ldd * /usr/include/elf.h * /usr/include/ifaddrs.h * /usr/include/lastlog.h * /usr/include/link.h * /usr/include/netdb.h * /usr/include/pty.h * /usr/include/resolv.h * /usr/include/shadow.h * /usr/include/syscall.h * /usr/include/sysexits.h * /usr/include/syslog.h * /usr/include/utmp.h * /usr/include/utmpx.h * /usr/include/wctype.h * * sys-libs/argp-standalone-1.4.1-r1:0::gentoo * /usr/include/argp.h * * Package 'sys-libs/glibc-2.35' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message. * GNU info directory index is up-to-date.
toralf, I think I found the issue in your tinderbox.git: >data/package.unmask.50unstable:19:=sys-libs/glibc-2.35*
(In reply to Sam James from comment #13) > toralf, I think I found the issue in your tinderbox.git: > >data/package.unmask.50unstable:19:=sys-libs/glibc-2.35* I removed that now b/c glibc is unmasked. But I was under the impression that sys-libs/glibc and sys-libs/musl blocks each other unconditionally from the version ?
(In reply to Toralf Förster from comment #14) > (In reply to Sam James from comment #13) > > toralf, I think I found the issue in your tinderbox.git: > > >data/package.unmask.50unstable:19:=sys-libs/glibc-2.35* > > I removed that now b/c glibc is unmasked. > But I was under the impression that sys-libs/glibc and sys-libs/musl blocks > each other unconditionally from the version ? I don't think the ebuilds actually contain blockers because it's done by profiles and I'm not sure but it might somehow interfere with cross bits (although it shouldn't). In any case, unmasking it had an unfortunate side-effect for you as it unmasked the musl mask, not just the general testing mask. We should probably add the blockers anyway though. @dilfridge: WDYT?
