See logs
Created attachment 425482 [details] build log
Created attachment 425484 [details] emerge --info
snipped out of the full log... /usr/share/GNUstep/Makefiles/mkinstalldirs /var/tmp/portage/gnustep-base/gnustep-base-1.24.6-r1/image//usr/share/GNUstep/Makefiles/Additional /var/tmp/portage/._portage_reinstall_.aTZdfR/bin/ebuild-helpers/xattr/install -c -p -m 644 base.make \ /var/tmp/portage/gnustep-base/gnustep-base-1.24.6-r1/image//usr/share/GNUstep/Makefiles/Additional/base.make make: /var/tmp/portage/._portage_reinstall_.aTZdfR/bin/ebuild-helpers/xattr/install: Command not found Makefile.postamble:46: recipe for target 'before-install' failed make: *** [before-install] Error 127
But what was the command you were running when you got this error? Was portage one of the packages being updated? This path does not look right to me: /var/tmp/portage/._portage_reinstall_.aTZdfR/
This looks like bug 532196. (In reply to Brian Dolbec from comment #4) > This path does not look right to me: > > /var/tmp/portage/._portage_reinstall_.aTZdfR/ A path like this is normal when other packages are built during the same emerge run as as sys-apps/portage upgrade. The problem is that some packages record the path to use in later emerge runs, long after the path has become invalid.
Time to stabilize a fixed version of gnustep-make (>=2.6.6)?
I was doing an emptytree world rebuild.
(In reply to Zac Medico from comment #5) > This looks like bug 532196. > > (In reply to Brian Dolbec from comment #4) > > This path does not look right to me: > > > > /var/tmp/portage/._portage_reinstall_.aTZdfR/ > > A path like this is normal when other packages are built during the same > emerge run as as sys-apps/portage upgrade. The problem is that some packages > record the path to use in later emerge runs, long after the path has become > invalid. Honestly this sounds like a good "gotcha" that should be flagged during QA.
(In reply to shentino from comment #8) > (In reply to Zac Medico from comment #5) > > This looks like bug 532196. > > > > (In reply to Brian Dolbec from comment #4) > > > This path does not look right to me: > > > > > > /var/tmp/portage/._portage_reinstall_.aTZdfR/ > > > > A path like this is normal when other packages are built during the same > > emerge run as as sys-apps/portage upgrade. The problem is that some packages > > record the path to use in later emerge runs, long after the path has become > > invalid. > > Honestly this sounds like a good "gotcha" that should be flagged during QA. Yeah, we could grep for $PORTAGE_BIN_PATH in all the installed files. Not sure if it would be worth the performance penalty for things like kernel sources.
More like I meant that an ebuild trying to use it post-merge should be considered a QA issue with the ebuild.
It looks like this should be fixed by this code in the gnustep-base/gnustep-make-2.6.8 ebuild, which is the latest stable version since bug 579232: econf \ INSTALL="${EPREFIX}"/usr/bin/install \
(In reply to Zac Medico from comment #11) > It looks like this should be fixed by this code in the > gnustep-base/gnustep-make-2.6.8 ebuild, which is the latest stable version > since bug 579232: > > econf \ > INSTALL="${EPREFIX}"/usr/bin/install \ Exactly, I left this one open until the stabling bug got fixed (linked as blocker), which is the case now! So marking this one as fixed, don't hesitate to reopen if you still have the problem after update
