On 10/02/2014 20:30, Kerin Millar wrote:
On 10/02/2014 16:05, Stroller wrote:
Hello all,
I'm a little bit rusty, but my recollection is that I should be able
to perform `eix-sync` (or `emerge --sync`?) as a user to synchronise
my local copy of the portage tree with Gentoo's master portage tree.
User is in the portage group:
$ whoami
stroller
$ groups stroller
wheel audio video portage cron users
$
Yet I get these permissons denied errors:
$ eix-sync
* Running emerge --sync
Synchronization of repository 'gentoo' located in '/usr/portage'...
Starting rsync with rsync://91.186.30.235/gentoo-portage...
Checking server timestamp …
…
receiving incremental file list
rsync: delete_file:
unlink(app-accessibility/caribou/caribou-0.4.12.ebuild) failed:
Permission denied (13)
rsync: delete_file:
unlink(app-accessibility/emacspeak/files/emacspeak-33.0-respect-ldflags.patch)
failed: Permission denied (13)
rsync: delete_file:
unlink(app-accessibility/emacspeak/files/emacspeak-33.0-greader-garbage.patch)
failed: Permission denied (13)
(full output attached)
Googling the problem I see a bunch of Gentoo Forums posts talking
about changing at random the permissions of /var/tmp/ or
/var/tmp/portage/, but no rationale is given, and I don't think this
is the cause:
$ emerge --info | grep -i tmpdir
PORTAGE_TMPDIR="/var/tmp"
$ ls -ld /var/tmp/
drwxrwxrwt 3 root root 4096 Feb 5 13:47 /var/tmp/
$ ls -ld /var/tmp/portage/
drwxrwxr-x 5 portage portage 4096 Feb 5 12:32 /var/tmp/portage/
$
More likely seems to be the permissions of /usr/portage/:
$ ls -ld /usr/portage/
drwxr-xr-x 167 portage portage 4096 Jan 5 02:31 /usr/portage/
$ ls -ld /usr/portage/app-accessibility/caribou/caribou*.ebuild
-rw-r--r-- 1 portage portage 2432 Aug 25 23:11
/usr/portage/app-accessibility/caribou/caribou-0.4.12.ebuild
-rw-r--r-- 1 portage portage 2431 Dec 8 18:01
/usr/portage/app-accessibility/caribou/caribou-0.4.13.ebuild
$
This would seem to allow portage itself to synchronise the Portage
tree, but not members of the portage group.
I am able to run `emerge --sync` as root, but it doesn't solve the
solve the problem - next time I run `eix-sync` as user, I'm
permissions denied, again.
Shouldn't a sync reset the permissions of the portage tree to be correct?
`emerge --info | grep -i feature` shows that FEATURES="userfetch
userpriv usersandbox usersync" (and some others - see attached) are set.
I can reproduce this on a second AMD64 machine, both are running
portage-2.2.7.
Thanks in advance for any help, advice or suggestions you can offer,
This should work:-
PORTAGE_RSYNC_EXTRA_OPTS="--chmod=g+w"
Please excuse the reply-to-self but this issue piqued my interest and I
think that I now have a better answer.
1) chown -R portage:portage "$(portageq envvar PORTDIR)"
2) find "$(portageq envvar PORTDIR)" -type f -exec chmod 0664 {} +
3) find "$(portageq envvar PORTDIR)" -type d -exec chmod 2775 {} +
4) Add to make.conf: PORTAGE_RSYNC_EXTRA_OPTS="--no-p --chmod=g+w"
5) Sync as yourself thereafter (as root should work equally well!)
The reason for using --no-p is to prevent rsync from spewing errors
about not being able to set the file modes when you sync as a regular
user. These errors don't necessarily indicate that a file cannot be
written - merely that the mode couldn't be set.
Such errors would occur because, though you are in the portage group,
you are not necessarily the owner of the files that rsync is in the
course of modifying. However, as long as the g+w bit is set for all
newly created files/directories, I would posit that it doesn't actually
matter. Instead, you can simply avoid synchronizing the permissions with
the remote.
Finally, having the setgid bit set on directories ensures that files
written out by your user beneath PORTDIR will always inherit the portage
group rather than whatever your primary group happens to be.
I am still in the course of testing this out but I am fairly certain
that it will work.
--Kerin
