Created attachment 749037 [details] emerge-info.text Per Sam James in bug 809410: "Please file a new bug for this with the full emerge log and emerge —-info. Interestingly, I’ve heard a few reports of this yesterday, but not many." Apparently, no one has yet. >>> Installing (1 of 11) sys-libs/libxcrypt-4.4.25::gentoo * checking 28 files for package collisions * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at https://bugs.gentoo.org/ unless you report exactly * which two packages install the same file(s). See * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how * to solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * Detected file collision(s): * * /usr/include/crypt.h * /lib64/libcrypt.so.1 * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * sys-libs/glibc-2.33-r7:2.2::gentoo * /lib64/libcrypt.so.1 * * Package 'sys-libs/libxcrypt-4.4.25' NOT merged due to file collisions. * If necessary, refer to your elog messages for the whole content of the * above message. >>> Failed to install sys-libs/libxcrypt-4.4.25, Log file: >>> '/var/log/portage/sys-libs:libxcrypt-4.4.25:20211106-082551.log' * GNU info directory index is up-to-date.
Please do include the build.log too as it has useful information at the top and so on. Anyway, I think we fixed this last night for -preserve-libs.
(In reply to Sam James from comment #1) > Please do include the build.log too as it has useful information at the top > and so on. > > Anyway, I think we fixed this last night for -preserve-libs. https://bugs.gentoo.org/809410#c19
Created attachment 749073 [details] ibxcrypt-4.4.25 build log
(In reply to Sam James from comment #1) > Please do include the build.log too as it has useful information at the top > and so on. > > Anyway, I think we fixed this last night for -preserve-libs. Added the build log. So I need to re-emerge glibc then?
(In reply to Sam James from comment #1) > Anyway, I think we fixed this last night for -preserve-libs. Now, the ebuild can't find perl (I have 5.34.0-r3 installed). >>> Emerging (1 of 11) sys-libs/libxcrypt-4.4.25::gentoo * libxcrypt-4.4.25-autotools.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking libxcrypt-4.4.25-autotools.tar.xz to /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work >>> Source unpacked in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work >>> Preparing source in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25 ... * xcrypt_compat: running multilib-minimal_src_configure * abi_x86_64.amd64: running multilib-minimal_abi_src_configure * econf: updating libxcrypt-4.4.25/config.sub with /usr/share/gnuconfig/config.sub * econf: updating libxcrypt-4.4.25/config.guess with /usr/share/gnuconfig/config.guess * econf: updating libxcrypt-4.4.25/build-aux/config.sub with /usr/share/gnuconfig/config.sub * econf: updating libxcrypt-4.4.25/build-aux/config.guess with /usr/share/gnuconfig/config.guess /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libxcrypt-4.4.25 --htmldir=/usr/share/doc/libxcrypt-4.4.25/html --with-sysroot=/ --disable-werror --libdir=/lib64/ --with-pkgconfigdir=/usr/lib64/pkgconfig --includedir=/usr/include/ --disable-static --disable-xcrypt-compat-files --enable-obsolete-api=yes checking for a BSD-compatible install... /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c checking whether build environment is sane... yes checking for a race-free mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to enable C11 features... none needed checking whether x86_64-pc-linux-gnu-gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of x86_64-pc-linux-gnu-gcc... none checking for x86_64-pc-linux-gnu-pkg-config... /usr/bin/x86_64-pc-linux-gnu-pkg-config checking pkg-config is at least version 0.9.0... yes checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking whether make sets $(MAKE)... (cached) yes checking whether ln -s works... yes checking for perl... /usr/bin/perl checking whether /usr/bin/perl is version 5.14.0 or later... no configure: error: Perl version 5.14.0 or later is required !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_compat-abi_x86_64.amd64/config.log * ERROR: sys-libs/libxcrypt-4.4.25::gentoo failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 127: Called src_configure * environment, line 2563: Called multibuild_foreach_variant 'multilib-minimal_src_configure' * environment, line 1464: Called _multibuild_run 'multilib-minimal_src_configure' * environment, line 1462: Called multilib-minimal_src_configure * environment, line 1534: Called multilib_foreach_abi 'multilib-minimal_abi_src_configure' * environment, line 1787: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 1464: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 1462: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure' * environment, line 394: Called multilib-minimal_abi_src_configure * environment, line 1528: Called multilib_src_configure * environment, line 2011: Called econf '--disable-werror' '--libdir=/lib64/' '--with-pkgconfigdir=/usr/lib64/pkgconfig' '--includedir=/usr/include/' '--disable-static' '--disable-xcrypt-compat-files' '--enable-obsolete-api=yes' * phase-helpers.sh, line 711: Called __helpers_die 'econf failed' * isolated-functions.sh, line 112: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=sys-libs/libxcrypt-4.4.25::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/libxcrypt-4.4.25::gentoo'`. * The complete build log is located at '/var/log/portage/sys-libs:libxcrypt-4.4.25:20211106-170209.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_compat-abi_x86_64.amd64' * S: '/var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25' >>> Failed to emerge sys-libs/libxcrypt-4.4.25, Log file: >>> '/var/log/portage/sys-libs:libxcrypt-4.4.25:20211106-170209.log'
I still don't understand any of this. Looking at the glibc file in elog, I have never had FEATURES=collision-protect, and always had FEATURES=unmerge-orphans. Did I break my system re-emering glibc believing that you had fixed the problem?
(In reply to ta2002 from comment #6) > I still don't understand any of this. Looking at the glibc file in elog, I > have never had FEATURES=collision-protect, and always had > FEATURES=unmerge-orphans. > I think there was at least a race with FEATURES="-preserve-libs". > Did I break my system re-emering glibc believing that you had fixed the > problem? No, it is fixed (if you're hitting the same issue) but the problem is this: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.33-r7.ebuild#n1506 glibc checks if you have the older version *with* crypt enabled before trying to perserve. Can you try: emerge -v1O "<sys-libs/glibc-2.33-r7", then emerge -v1O "~sys-libs/glibc-2.33-r7", then emerge -v1O libxcrypt?
(In reply to ta2002 from comment #5) > checking whether /usr/bin/perl is version 5.14.0 or later... no > configure: error: Perl version 5.14.0 or later is required > > !!! Please attach the following file when seeking support: > !!! > /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25- > xcrypt_compat-abi_x86_64.amd64/config.log Can you include /var/tmp/portage/sys-libs/libxcrypt-4.4.25/work/libxcrypt-4.4.25-xcrypt_compat-abi_x86_64.amd64/config.log? That said, I think I know what the problem is (see previous comment).
Looks like it went through this time (thanks for your help). I still got the collision warning message, but just for /lib64/libcrypt.so.1, and not for /usr/include/crypt.h. The install log from the first time I upgraded to sys-libs/glibc-2.33-r7 shows the removal of /usr/include/crypt.h, but the file still existed after the upgrade. This time, it seems the file really did get removed. I encountered the same problem on another machine. It did not have the /usr/include/crypt.h in the detected collisions, though. I will attach the config log from that machine.
Created attachment 749238 [details] libxcrypt-4.4.25_config.log
(In reply to ta2002 from comment #9) > Looks like it went through this time (thanks for your help). I still got the > collision warning message, but just for /lib64/libcrypt.so.1, and not for > /usr/include/crypt.h. > No problem, and thank you for your patience. I understand this is a bit frustrating/worrisome. > The install log from the first time I upgraded to sys-libs/glibc-2.33-r7 > shows the removal of /usr/include/crypt.h, but the file still existed after > the upgrade. This time, it seems the file really did get removed. > > I encountered the same problem on another machine. It did not have the > /usr/include/crypt.h in the detected collisions, though. I will attach the > config log from that machine. OK, so if we're in the situation where there's no libcrypt.so at all, we have two choices: - emerge libxcrypt (... which you can't do, because it needs Perl, and Perl needs libcrypt) or - emerge older glibc temporarily to get libcrypt back, to allow us to build the replacement (libxcrypt) => use the same fix as before (emerge older glibc, then newer, then libxcrypt) -- Feel free to ignore the below, I just want to explain what happened. The reason for the different collisions is a bit long. I'll explain it here. Normally, collisions are the result of something really straightforward and should be fixed ASAP (of course this should be/was too). But there were a few cases here. The important thing is that we're _handing over_ ownership of crypt.h and libcrypt.so.1 from sys-libs/glibc -> sys-libs/libxcrypt. This is an unusual-ish thing for packages to do. There's a few situations which have occurred. Background: - FEATURES="-preserve-libs" is not a recommended configuration (because not many people use it) but it is allowed. When this happens, Portage will not keep around a library if a package stops installing it, even if binaries on your system are linked against it. - With FEATURES="preserve-libs", we do not have to worry about preserving anything within the ebuild (which exposes us to risks of collisions) because Portage will keep around the needed .sos until all things linked against the old version have been rebuilt. Or until something else installs said .so. - With FEATURES="preserve-libs", there was an "expected" collision which _by default_ would be warned about but ignored by Portage (we mentioned it in the news item + glibc's pkg_postinst) -- this is what happens when FEATURES="unmerge-orphans". crypt.h would be installed but orphaned and so would libcrypt.so.1. "unmerge-orphans" lets Portage ignore the fact there'll be a collision because while the files already exist on the system, they're not technically owned by the previous package (glibc here) because of the way we installed them in the glibc ebuild. We needed to add crypt.h *as well* because of bugs in dependency resolution which was made worse by Python unnecessarily including crypt.h and linking against -lcrypt (harmless b/c of -Wl,--as-needed, but this leaked into every application using python-config --libs/linking against libpython, and resulted in build failures even when everything was fine!). We have since dropped it because we added new Pythons which avoid both those issues. - With FEATURES="-preserve-libs", we were doing crypt.h correctly, but libcrypt.so.1 was actually being installed _within the image_ of glibc when it needed to be preserved without any of us realising. The correct method was to sneak it into the root after merging so it counts as an orphan. This is what floppym's fix did in the end. - This whole thing has been rather confusing because of the various Portage collision detection/prevention features, made worse by the fact that a lot of people had FEATURES="collision-protect" from years ago(?) even though it is non-default which results in fatal errors even for orphaned files. But I _think_ the situation is fixed now.
Thank you for the detailed explanation (though I still don't understand why the collisions prevented the merge of sys-libs/libxcrypt-4.4.25 the first time, but not the second. Where do the default FEATURES get set? I looked in the profile, but only saw a few of the options enabled. I don't recall how I ended up with -preserve-libs. I can certainly change that. The second machine has libxcrypt installed, and has started to work its way through the rebuilds. Thank you again for your help.
