* QA Notice: the following files are outside of the prefix: * /usr * /usr/sbin * /usr/sbin/build-docbook-catalog * ERROR: app-text/build-docbook-catalog-1.20::gentoo_prefix failed: * Aborting due to QA concerns: there are files installed outside the prefix Seems bug #416679 resurfaced. The fix back then was http://overlays.gentoo.org/proj/alt/changeset/60694/. But the Makefile has an EPREFIX variable these days. So the solution which worked for me was adding the following line to src_prepare: sed -i -e "/^EPREFIX *=/s:=.*:='${EPREFIX}':" Makefile || die Of course, it might be considered cleaner if the EPREFIX variable got exported to the environment, and if the Makefile would use the value from the environment in preference to its own value. Or, as an alternative, if the EPREFIX value were passed to the invocation of “make install”. More work, though.
I don't quite understand, what you suggest already is in the ebuild. Could it be that you have an outdated tree?
(In reply to Fabian Groffen from comment #1) > Could it be that you have an outdated tree? I had synced just before encountering this. > I don't quite understand, what you suggest already is in the ebuild. http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/app-text looks like build-docbook-catalog currently has no overridden version in the prefix overlay repository. It was removed in commit 61682. So the overlay uses the main portage version. And in that main portasge x86 tree, the latest ebuild is build-docbook-catalog-1.20.ebuild, CVS revision 1.2: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-text/build-docbook-catalog/build-docbook-catalog-1.20.ebuild?revision=1.2&view=markup That file does sed the build-docbook-catalog script, but not its Makefile. Where do you see the ebuild with the fix included?
Created attachment 363318 [details, diff] Makefile EPREFIX patch I can confirm that this causes a problem for me on a CentOS 6-based prefix. The issue is that only the script is patched, not the Makefile. I've amended the sed script to handle this.
Reopening, since it's definitely not me, so definitely not WORKSFORME.
I moved this to gx86 a while ago, but I don't really understand the error! The ebuild has MAKEOPTS+=" PREFIX=${EPREFIX}" in it, so no need to sed the Makefile. The installation looks like: >>> Install build-docbook-catalog-1.20 into /home/junghans/Gentoo/var/tmp/portage/app-text/build-docbook-catalog-1.20/image/ category app-text make -j5 PREFIX=/home/junghans/Gentoo DESTDIR=/home/junghans/Gentoo/var/tmp/portage/app-text/build-docbook-catalog-1.20/image/ install install -d /home/junghans/Gentoo/var/tmp/portage/app-text/build-docbook-catalog-1.20/image//home/junghans/Gentoo/sbin install -m 755 build-docbook-catalog /home/junghans/Gentoo/var/tmp/portage/app-text/build-docbook-catalog-1.20/image//home/junghans/Gentoo/sbin >>> Completed installing build-docbook-catalog-1.20 into /home/junghans/Gentoo/var/tmp/portage/app-text/build-docbook-catalog-1.20/image/ for me. Could you post your build.log?
Created attachment 363348 [details] build log I see no PREFIX in that make call. Strange.
You set that variable, but you don't export it. And as far as I know, exporting variables should not happen at the top level, but in pkg_setup or something like this, right? In any case, if I do MAKEOPTS= emerge -1 build-docbook-catalog then everything works fine. The reason being that in this case, MAKEOPTS is already on the environment, so it will be exported to children as well. Without that, it will be a bash internal variable which doesn't get inherited by the emake helper script, so it won't have the desired effect.
That is actually a good point, I have set MAKEOPTS in my make.conf. A lot of packages do the same thing. @zac: Should MAKEOPTS="-j2" by default and hence set?
Yes, that is what it is - this was a completely new prefix and I hadn't bothered tweaking anything much. If I add MAKEOPTS="" to make.globals, the problem goes away with the standard ebuild (ie, -1.20 from the tree, not patched by me). As MAKEOPTS="" is the effective default anyway, and I can't imagine anything that would break by including it, perhaps this change to make.globals should be patched in portage?
$ find /usr/portage -name "*.ebuild" -exec grep -E '^MAKEOPTS\+?=' {} + | wc -l 141 There are 141 ebuilds doing something similar.
Fixed by exporting MAKEOPTS in pkg_setup().
