With portage-2.0.46-r*, you could run : emerge -u -p world or other query functions, but since portage-2.0.47-r2, this will result in errors: -- start quote -- mcvaio /usr/portage/media-sound/liteamp % emerge -p postgresql These are the packages that I would merge, in order: [postgresql-7.2.3-r1] bash: /fire/1/portage_tmp/portage/homedir/.bashrc: Permission denied rm: cannot remove `/fire/1/portage_tmp/portage/homedir': Permission denied [postgresql-7.2.3-r1] bash: /fire/1/portage_tmp/portage/homedir/.bashrc: Permission denied rm: cannot remove `/fire/1/portage_tmp/portage/homedir': Permission denied Calculating dependencies aux_get(): (2) couldn't open cache entry for dev-db/postgresql-7.2.3-r1 Check for syntax error or corruption in the ebuild. !!! all ebuilds that could satisfy "postgresql" have been masked. !!! Error calculating dependancies. Please correct. -- end quote -- I guess this is a permissions thing, the question is: is this the intended result? if so, then should we have a cleaner error message when run as a non-root user.
Created attachment 8418 [details] strace of a failed non-root 'emerge -s liteamp' process I don't know if this makes a difference, but in the past I only had the features sandbox and ccache enabled. Right now these are my FEATURES="sandbox ccache userpriv" in /etc/make.conf
Created attachment 8419 [details] strace of a failed non-root 'emerge -s liteamp' process I don't know if this makes a difference, but in the past I only had the features sandbox and ccache enabled. Right now these are my FEATURES="sandbox ccache userpriv" in /etc/make.conf
Try remerging postgresql. Do you have a PORTDIR_OVERLAY defined?
this isn't a postgresql problem, its a problem in the new portage....
Correct. I just had the same. Remerging the complaining packages helped... I think it is because I merged the packages from my overlay-directory. After deleting the ebuilds there it began complaining...(and is only complaining about ebuilds I merged from there).
After merging the 2.0.47-r2 upgrade I encountered the same errors. Checking the perms on /var/tmp/portage, I noticed: drwxrwxr-x 280 portage portage 9944 Feb 18 11:32 /var/tmp/portage Adding myself to the portage group seems to have solved the problem. Unless I'm just applying a band-aid, the ebuild should probably be modified to emit a notice informing the admin that membership in the portage group is required for non-root users.
I did that before, so it does not help me. Anyway, when running emerge and no user portage exists, emerge informs you about that. (It would be nice, if the user and group could be created then and there, just by saying 'yes' to that) The portage-user and group is maybe more a thing for baselayout? But it does not tell you, that any user using emerge does have to be in that group.
adding my user to group portage did indeed solve problems i was having.
correction to my last comment. adding myself to group portage didn't solve the problem. it seems that after running the same command as root generates the cache entries that the user didn't have permissions to. so thus the next time i run the same command as the user, it doesn't have to creat the cache entries and hence it runs without error.
Created attachment 8549 [details, diff] proposed patch According to experiments and looking at the source of touch (1), it appears that utime can be called with a second argument of NULL by anyone with write permission on a file, but changing mtime to an arbitrary number can only be done by the owner of the file. This patch deletes stale cache files before running "ebuild depend", so that they will be created by the uid running portage, and the utime call will succeed.
fixed in cvs.
out shortly
