Created attachment 337468 [details] build.log Write deny
Created attachment 337470 [details, diff] tcc-0.9.26_pre1.ebuild.patch Sets DESTDIR="${D}" in make install to fix write deny
I can confirm it works.
docdir="${D}"/usr/share/doc/${PF} \ that's already in the ebuild, and I cannot reproduce the failure. ... so what makes our systems different enough so that you can make it fail?
My gentoo install isn't modified in any manner for /usr/ directory. It's quite old (~5years), but has been maintained up to date regulary since my last install. Another user (comment #2), seems to encounter this problem. I don't think one need to use ${D} for each install directory, at the risk to have a missing one, but rather to set it "globally" through DESTDIR="${D}". It the common way used by EAPI4 (I think it's same in EAPI5 used by this ebuild) in src_install.
(In reply to comment #3) > docdir="${D}"/usr/share/doc/${PF} \ > > that's already in the ebuild, and I cannot reproduce the failure. > > ... so what makes our systems different enough so that you can make it fail? I just experienced this bug as well. The failure is because the tcc configure script only uses ${infodir} to create a canonical path for info files so docdir="${D}"/usr/share/doc/${PF} \ has no effect. I added infodir="${D}"/usr/share/info/${PF} \ to the ebuild to correct the problem which I believe is "more correct" than specifying DESTDIR="${D}".
Is the patch going to be pushed to portage? I'm having tcc problems with my build server, and while I'm not apposed to using ~amd64 testing, I won't use a patch unless it's in portage on this machine.
+ 16 Apr 2013; Patrick Lauer <patrick@gentoo.org> tcc-0.9.26_pre1.ebuild: + Fix for sandbox violation #454874 Reproduced, and fixed
