econf() from <=sys-apps/portage-2.0.51.22-r1 should verify the writability of config.{sub,guess} before copying them. Could it be fixed in portage-stable? Note: Fixed on portage-cvs in ebuild-functions.sh since rev 1.7
Created attachment 59401 [details, diff] ebuild.sh.diff
Summary changed, I was thinking in something like if [ -w ${x} ]; then chmod u+w ${x}... Seems to be better to use the `-f` argument from cp, so no "verification" needed, just replace it.
*** Bug 87301 has been marked as a duplicate of this bug. ***
*** Bug 93180 has been marked as a duplicate of this bug. ***
Not exactly the same bug, but really closely related: When "libtool" is ran by an ebuild without the --copy option, config.sub is symlinked to the /usr/share/gnuconfig file. Then the "cp -f" fails, and then the chmod violates sandboxing. Example (with app-text/evince): * econf: updating evince-0.3.2/config.sub with /usr/share/gnuconfig/config.sub cp: `/usr/share/gnuconfig/config.sub' and `/var/tmp/portage/evince-0.3.2/work/evince-0.3.2/config.sub' are the same file ACCESS DENIED chmod: /var/tmp/portage/evince-0.3.2/work/evince-0.3.2/config.sub chmod: changing permissions of `/var/tmp/portage/evince-0.3.2/work/evince-0.3.2/config.sub': Permission denied I've not found the magic "cp" option that would allow copying a file over a symlink on itself, so i suggest adding an "rm -f" before the copy. Patch follows, in case my explanation is not clear.
Created attachment 62139 [details, diff] ebuild-functions.sh--fix_econf.patch Patch is against latest CVS HEAD revision (1.11) of ebuild-functions.sh
Err... not such a smart fix actually... The real bug is the "find" expression just above which tries to match only real files, but does not because of operators precedence. Patch follows.
Created attachment 62140 [details, diff] ebuild-functions.sh--rev1.11--fix_econf.patch
See Bug #96242
fixed the find expr in cvs
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
