>>> Source configured. >>> Compiling source in /var/tmp/portage/app-portage/gemato-10.3/work/gemato-10.3 ... * ERROR: app-portage/gemato-10.3::gentoo failed (compile phase): * USE Flag 'python_targets_pypy' not in IUSE for app-portage/gemato-10.3 * * Call stack: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-hardened_abi32+64_20180129-192227 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.0 * Available Python interpreters, in order of preference: [1] python3.5 [2] python2.7 (fallback) Available Ruby profiles: [1] ruby22 (with Rubygems) [2] ruby23 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.6.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm emerge -qpv app-portage/gemato [ebuild N ] app-portage/gemato-9.3 USE="blake2 bzip2 gpg portage-postsync -lzma -sha3 {-test}" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6"
Created attachment 517170 [details] emerge-info.txt
Created attachment 517172 [details] app-portage:gemato-10.3:20180130-202733.log
Created attachment 517174 [details] emerge-history.txt
Created attachment 517176 [details] environment
Created attachment 517178 [details] etc.portage.tbz2
Created attachment 517180 [details] temp.tbz2
But... how? The flags and the conditional are both eclass-generated.
This really doesn't make any sense. If you look into environment, 'python_targets_pypy' is in IUSE... @toralf, you sure this isn't something like 'emerge --sync' in middle of emerge run?
(In reply to Toralf Förster from comment #4) > Created attachment 517176 [details] > environment The python_targets_pypy flag is mysteriously missing from the IUSE_EFFECTIVE variable. Is the problem reproducible?
(In reply to Michał Górny from comment #8) That *might* happen, there's still a race here with "emerge --sync" which I did not fixed yet. So maybe INVALID ?
Well, in that case it's the most likely explanation (i.e. different ebuild when building depgraph and when it got to build it). I don't think we can figure anything else here. If you can reproduce it again, please reopen.
