Bug 569260 – >sys-apps/portage-2.2.20.1 (all python-r1 versions of it) broken by new eclass changes - mv: cannot stat ‘/var/tmp/portage/sys-apps/portage-2.2.26/image/usr/bin/archive-conf’: No such file or directory

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Ben Kohler 2015-12-23 02:04:29 UTC]

Created attachment 420400 [details]
portage-2.2.26 build.log

It looks like the bin->sbin mv ("Moving admin scripts to the correct directory") happens twice, or once for each enabled python implementation.  I would assume it has to do with the python eclass changes ~4 hrs ago but I cannot quite see what change would have caused this.

[Comment 1 cronolio 2015-12-23 02:45:32 UTC]

after this update
[ebuild     U  ] sys-devel/gnuconfig-20150727::gentoo [20150308::gentoo] 46 KiB
[ebuild     U  ] sys-devel/bison-2.7.1::gentoo [2.4.3::gentoo] USE="nls -static" 1 740 KiB
[ebuild     U  ] sys-boot/grub-2.02_beta2-r8:2::gentoo [2.02_beta2-r7:2::gentoo] USE="fonts multislot nls themes -debug -device-mapper -doc -efiemu (-libzfs) -mount -sdl -static {-test} -truetype" GRUB_PLATFORMS="pc -coreboot -efi-32 -efi-64 -emu -ieee1275 -loongson -multiboot -qemu -qemu-mips -uboot -xen" 15 KiB
[ebuild     U  ] app-editors/nano-2.4.3::gentoo [2.3.6::gentoo] USE="magic ncurses nls spell unicode -debug -justify -minimal -slang -static%" 1 835 KiB

 * Moving /usr/bin/archive-conf to /usr/sbin/archive-conf
mv: cannot stat ‘/var/tmp/portage/sys-apps/portage-2.2.24/image/usr/bin/archive-conf’: No such file or directory
 * ERROR: sys-apps/portage-2.2.24::gentoo failed (install phase):
 *   sbin scripts move failed!

before update normal compile

[Comment 2 Zac Medico 2015-12-23 04:23:37 UTC]

I've narrowed it down to this commit:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=33380ad5e121a47375442de08fd9239b9102b1fa

[Comment 3 Zac Medico 2015-12-23 06:09:30 UTC]

The problem comes from this change in python-r1.eclass:

@@ -460,12 +439,8 @@ _python_obtain_impls() {
 
 	MULTIBUILD_VARIANTS=()
 
-	for impl in "${_PYTHON_ALL_IMPLS[@]}"; do
-		if has "${impl}" "${PYTHON_COMPAT[@]}" \
-			&& use "python_targets_${impl}"
-		then
-			MULTIBUILD_VARIANTS+=( "${impl}" )
-		fi
+	for impl in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
+		use "python_targets_${impl}" && MULTIBUILD_VARIANTS+=( "${impl}" )
 	done
 }
 

Because _distutils-r1_run_common_phase does a local PYTHON_COMPAT setting which is no longer respected.

[Comment 4 Zac Medico 2015-12-23 06:22:54 UTC]

This is fixed in git:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a3612b0a9d870dd7226922483493ae1712b551b6

[Comment 5 Michał Górny 2015-12-23 06:47:52 UTC]

Thanks for the workaround. However, please keep this open. I'd like to eventually remove that hack from distutils-r1 as it's nowhere close to expected.

[Comment 6 Brian Dolbec (RETIRED) 2015-12-23 13:22:40 UTC]

*** Bug 569264 has been marked as a duplicate of this bug. ***

[Comment 7 Michał Górny 2017-03-10 16:09:42 UTC]

Does anyone happen to have any idea what I was supposed to fix here, and how I was supposed to do that? I presume I wanted to kill that 'local PYTHON_COMPAT'.

[Comment 8 Zac Medico 2017-03-10 16:56:32 UTC]

(In reply to Michał Górny from comment #7)
I think you wanted to somehow eliminate the related local PYTHON_COMPAT setting from _distutils-r1_run_common_phase:

	local PYTHON_COMPAT=( "${best_impl}" )

Maybe you could add a _distutils-r1_run_for_one_impl function to call instead of _distutils-r1_run_foreach_impl in this case.