# # Fix permissions so that it can't fail
# chown -R portage:portage ../../*
# ebuild openldap-2.3.43-r4.ebuild manifest
!!! Repository 'x-overlay' is missing masters attribute in '/root/overlay/metadata/layout.conf'
!!! Set 'masters = gentoo' in this file for future compatibility
/usr/lib64/portage/bin/ebuild.sh: line 545: /root/overlay/net-nds/openldap/openldap-2.3.43-r4.ebuild: Permission denied
* ERROR: net-nds/openldap-2.3.43-r4::x-overlay failed (depend phase):
* error sourcing ebuild
* Call stack:
* ebuild.sh, line 545: Called die
* The specific snippet of code:
* source "$EBUILD" || die "error sourcing ebuild"
* If you need support, post the output of `emerge --info '=net-nds/openldap-2.3.43-r4::x-overlay'`,
* the complete build log and the output of `emerge -pqv '=net-nds/openldap-2.3.43-r4::x-overlay'`.
* Working directory: '/usr/lib64/portage/pym'
* S: '/var/tmp/portage/net-nds/openldap-2.3.43-r4/work/openldap-2.3.43'
# emerge -1 "<portage-2.2"
# repoman manifest
>>> Creating Manifest for /root/overlay/net-nds/openldap
# # FUUUU UUUUUUUUuuuuuuuuuuuuu
It looks like repoman changes to the portage user when FEATURES=userpriv is enabled, and then tries to access the ebuild using an absolute pathname.
Since /root is owned by root with mode 0700, this fails with a permission error.
(In reply to Mike Gilbert from comment #1)
> It looks like repoman changes to the portage user when FEATURES=userpriv is
> enabled, and then tries to access the ebuild using an absolute pathname.
> Since /root is owned by root with mode 0700, this fails with a permission
Yeah, so it seems like the solution is to adjust the permissions somehow, or disable userpriv and usersandbox.
*** This bug has been marked as a duplicate of bug 477664 ***