Hi,
On (03/09/07 16:13) William Xu wrote:
> Rumen Yotov <[EMAIL PROTECTED]> writes:
>
> > May be because this directory is meant to be used by portage only.
>
> Since it's just a tmp dir, only allowing portage user to read seems too
> strict.
>
May be 'yes' but it's kind of security measure - so while compiling if
anything breaks you'll get an user shell not a root one (just guessing).
BTW anybody knows if gpg-signing of sources/eclasses is getting ready ?
> > IMHO that is so because of FEATURES="... userpriv ..." (please check
> > the syntax). Same must be valid for /usr/portage/distfiles (FAETURES=
> > " ... parallel-fetch userpriv usersandbox...")
>
> Do you mean that I should add `userpriv' etc to FEATURES flag? My
> present setting is:
>
> ,----
> | FEATURES="cvs parallel-fetch ccache keepwork"
> `----
>
IIRC 'userpriv' uses portage uid to actually compile things, and root
only during final merge. But please check again (paludis user ;-)
> > Why you need user access to this work-dir.
>
> Yes, it's a big weird that debugging emacs requires me running the
> executable.
>
> ,----[ /usr/share/emacs/23.0.0/etc/DEBUG ]
> | ** When you debug Emacs with GDB, you should start it in the directory
> | where the executable was made. That directory has a .gdbinit file
> | that defines various "user-defined" commands for debugging Emacs.
> | (These commands are described below under "Examining Lisp object
> | values" and "Debugging Emacs Redisplay problems".)
> `----
>
Could do the compilation in src|work directory in your HOME dir.
Or use step-by-step install:
ebuild /path/to/ebuild unpack|compile|install|qmerge|clean
check 'man ebuild' etc.
> --
> William
>
> --
> [EMAIL PROTECTED] mailing list
>
HTH. Rumen
--
[EMAIL PROTECTED] mailing list