* ERROR: app-crypt/johntheripper-1.7.9-r11::gentoo failed (install phase): * (no error message) * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-no-multilib-hardened_20180810-165911 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.0 [2] x86_64-pc-linux-gnu-7.3.1 * Available Python interpreters, in order of preference: [1] python3.7 [2] python3.6 [3] python2.7 (fallback) Available Ruby profiles: [1] ruby23 (with Rubygems) * emerge -qpv app-crypt/johntheripper [ebuild N ] app-crypt/johntheripper-1.7.9-r11 USE="openmp -cuda -custom-cflags -libressl -minimal -mozilla -mpi -opencl" CPU_FLAGS_X86="sse2 (-mmx)"
Created attachment 544016 [details] emerge-info.txt
Created attachment 544018 [details] app-crypt:johntheripper-1.7.9-r11:20180819-092032.log
Created attachment 544020 [details] emerge-history.txt
Created attachment 544022 [details] environment
Created attachment 544024 [details] etc.portage.tbz2
Created attachment 544026 [details] temp.tbz2
@Toralf, The strange thing is that your ebuild gave you this error while it was an EAPI 6 one... Right now the ebuild of app-crypt/johntheripper-1.7.9-r11 is EAPI 7 And that gave me almost the same error: XATTR_PAX marking -mre /dev/shm/portage/app-crypt/johntheripper-1.7.9-r11/imageusr/sbin/john with setfattr i.e. setfattr cannot find the file to manipulate... setfattr: /dev/shm/portage/app-crypt/johntheripper-1.7.9-r11/imageusr/sbin/john: No such file or directory But this error is because in EAPI 7 the variables D, ED, ROOT, and EROOT no longer contain a trailing slash and thus the ebuild has to be changed in the part of: pax-mark -mr "${ED}usr/sbin/john" || die to ether EAPI 7 way: pax-mark -mr "${ED}/usr/sbin/john" || die or to cross EAPI way: pax-mark -mr "${ED%/}/usr/sbin/john" || die This fixes the error... So a simple fix to the ebuild should fix it all
this builds for me as it is in the tree right now, although I do see a recent eapi update so that likely fixed it.
As it turns out, this was a bug in pax-utils.eclass caused by a bug in paxctl-ng. fixed in the tree now. thanks!
