Created attachment 391390 [details] Output of emerge --info Output of emerge --info is attached, will attach build log shortly. Checking for the existence of the program that the build log complains about reveals that it is in-fact there.
Created attachment 391392 [details] Build log
I saw this "recipe" errors recently with other packages (not GNUstep, although same version is installed), when rebuilding my entire system with `emerge -e @system; emerge -e @world' (moved my HDD into a better PC). I think I did `emerge --resume' twice, and the list was reordered when it resumed building. Strangely the affected packages built successful the second time. Probably this bug is not really GNUstep related.
(In reply to adr from comment #2) > I saw this "recipe" errors recently with other packages (not GNUstep, > although same version is installed), when rebuilding my entire system with > `emerge -e @system; emerge -e @world' (moved my HDD into a better PC). I > think I did `emerge --resume' twice, and the list was reordered when it > resumed building. Strangely the affected packages built successful the > second time. Probably this bug is not really GNUstep related. Yeah, I'm starting to think that also. I recently re-emerged many of my libraries, and had it on some other packages as well. Interestingly, re-running things does seem to have fixed them. I'm going to re-tag it as a portage bug. Interestingly, until this weekend, I had only seen this on hardened systems, but my desktop system (which isn't running hardened) had the same issue on Saturday (with the same package too).
(In reply to Austin S. Hemmelgarn from comment #3) > Yeah, I'm starting to think that also. I recently re-emerged many of my > libraries, and had it on some other packages as well. Interestingly, > re-running things does seem to have fixed them. I'm going to re-tag it as a > portage bug. Interestingly, until this weekend, I had only seen this on > hardened systems, but my desktop system (which isn't running hardened) had > the same issue on Saturday (with the same package too). Correction, I'm going to open a bug for portage, I forgot it's listed as a separate product.
The bug is in gnustep-make, which incorrectly hardcodes the absolute filename for the "install" program detected at build time into /usr/share/GNUstep/Makefiles/config.make. At a later time, this hardcoded filename is used by gnustep-base. The problem is that the absolute install filename at gnustep-make build time is not necessarily valid in the future. In particular, with USE=xattr, when both portage and gnustep-make are upgraded in a single emerge invocation, you will get this problematic /var/tmp location hardcoded into the installed files, which fails later. So to reproduce: USE=xattr emerge --oneshot portage gnustep-make emerge --oneshot gnustep-base (fails) Workaround is to re-merge gnustep-make by itself: emerge --oneshot gnustep-make emerge --oneshot gnustep-base (problem fixed for now)
Thanks for hunting that one down, I can indeed reproduce Portage used to restart merges after updating istelf, but now it uses local updated files in /var/tmp/portage/._portage_reinstall_ for the rest of the merge (later merges of course use the system ones) That is not an easy one to fix sadly, as it deals with gnustep-make caching configuration options for all gnustep packages invoking it. Or maybe we can force unsetting some variables and get the current system variables? I'll look into it But in the meantime, the workaround is indeed to remerge gnustep-make by itself when this kind of error appears
Created attachment 401364 [details, diff] Possible resolution (In reply to Bernard Cafarelli from comment #6) > That is not an easy one to fix sadly, as it deals with gnustep-make > caching configuration options for all gnustep packages invoking it. Or > maybe we can force unsetting some variables and get the current system > variables? I'll look into it It should be possible to resolve it similarly to the attached patch. Basically, we can override the INSTALL detection in gnustep-make's configure, and if we do that, we can set it to just the name of the "install" program so no absolute path is hardcoded. The disadvantage is that the Autoconf-generated configure script has some logic for probing a suitable "install" program which we are intentionally bypassing. This may not be a problem for Gentoo.
Simple and efficient, thanks! I used the full path with EPREFIX, so it should work fine in all situations in Gentoo Pushed in 2.6.6 and new bump 2.6.7
