Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
On Tuesday 11 April 2006 04:28, Zac Medico wrote: > Simon Stelling wrote: > > Zac Medico wrote: > >> What do people think about adding userpriv and usersandox to > >> make.globals FEATURES? I've been using these for a long time and > >> haven't had any trouble with them. Are there any arguments against > >> making them default? > > > > I didn't verify this personally, but a few days ago mkay came to > > #g-portage and asked whether FEATURES='usersandbox -sandbox' resulting > > in sandbox enabled is expected behaviour or not. Before we add > > usersandbox to the default FEATURES we should make sure that -sandbox > > always disables sandbox. > > Yeah, we should fix that. In fact, usersandbox seems like a redundant > feature to me. Can we deprecate usersandbox and recommend "sandbox" as > the sole means of toggling sandbox on and off (whether userpriv is > enabled or not)? "sandbox userpriv" thus far has meant to prefer userpriv and fallback to sandbox when the ebuild doesn't work with userpriv. When those two are combined with "usersandbox" on the other hand, it has meant to throw everything possible at the ebuild. I personally prefer to not use usersandbox as the sandbox gives a sometimes-not-small performance hit and I'm a ricer. :P -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: > On Monday 10 April 2006 08:08, Ned Ludd wrote: >> On Mon, 2006-04-10 at 02:24 -0700, Zac Medico wrote: >>> What do people think about adding userpriv and usersandox to make.globals >>> FEATURES? I've been using these for a long time and haven't had any >>> trouble with them. Are there any arguments against making them default? >> This is would qualify as core change. Please post this on the -dev ml. > > agreed, this is the inappropriate forum for such a change > -mike Okay, I'll post it there instead, along with my question about usersandbox deprecation. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEOrOH/ejvha5XGaMRAvr2AJ9BNq9YslFwaUds7H+DMIWqCI6HPwCfYfU+ uK2l6RgMyO/fP63bXwb6lGM= =GLtN -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: > Zac Medico wrote: >> What do people think about adding userpriv and usersandox to >> make.globals FEATURES? I've been using these for a long time and >> haven't had any trouble with them. Are there any arguments against >> making them default? > > I didn't verify this personally, but a few days ago mkay came to > #g-portage and asked whether FEATURES='usersandbox -sandbox' resulting > in sandbox enabled is expected behaviour or not. Before we add > usersandbox to the default FEATURES we should make sure that -sandbox > always disables sandbox. Yeah, we should fix that. In fact, usersandbox seems like a redundant feature to me. Can we deprecate usersandbox and recommend "sandbox" as the sole means of toggling sandbox on and off (whether userpriv is enabled or not)? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEOrHs/ejvha5XGaMRApNiAKCUkza2rTSmG0d51OlUsEN++xexaACeNKnl X03PHolSFdQzrV7iglO70Pg= =9QWG -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
On Monday 10 April 2006 08:08, Ned Ludd wrote: > On Mon, 2006-04-10 at 02:24 -0700, Zac Medico wrote: > > What do people think about adding userpriv and usersandox to make.globals > > FEATURES? I've been using these for a long time and haven't had any > > trouble with them. Are there any arguments against making them default? > > This is would qualify as core change. Please post this on the -dev ml. agreed, this is the inappropriate forum for such a change -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Saturday 08 April 2006 21:48, Ned Ludd wrote:
> On Sat, 2006-04-08 at 11:18 +0900, Jason Stubbs wrote:
> > On Saturday 08 April 2006 07:36, Ned Ludd wrote:
> > > On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> > > > FEATURES="buildpkg" ROOT=/ emerge gcc
> > > > rm -rf /dev/shm/foo
> > > >
> > > > ROOT=/dev/shm/foo emerge gcc -pvK
> > > >
> > > > Notice how it selects the incorrect deps?
> > > > IE: eselect cuz it's the first listed dep in the || ( ) vs the
> > > > gcc-config
> > >
> > > + When you already have a copy of gcc-config installed on / and in
> > > .tbz2 format in ${PKGDIR}/All and no eselect anywhere.
> >
> > This should work. I believed I had fixed it by adding the use_binaries
> > parameter and code paths to dep_zapdeps. If it's not working then there must
> > be a bug left somewhere.
>
> Must be a bug left somewhere then. I just tested with
> Portage 2.1_pre7-r4 and the result is the same.
Got it. The bug was in bindbapi. For consistency's sake, I changed most of the
db["/"] to db[myroot] except where db["/"] is specifically required. However,
db[myroot]["bintree"].dbapi.* were all working with an empty repository as
bintree holds all the data and uses lazy initialization which bindbapi wasn't
triggering.
I've fixed the current use case and covered aux_get as well, but this bug could
easily come back if another method of bindbapi is used.
> > Having a quick look at the dep_zapdeps function, I can't see what but I
> > think
> > I've discovered another bug. If use_binaries is true, porttree isn't checked
> > for matches which means that it'll fall through to the "last resort" code
> > when there's no matching binaries which could end up selecting an atom that
> > only has masked porttree matches.
>
> yikes.
This is and isn't the case. use_binaries is only enabled with -K so masking
doesn't take affect anyway.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
On Mon, 2006-04-10 at 02:24 -0700, Zac Medico wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > > What do people think about adding userpriv and usersandox to make.globals > FEATURES? > I've been using these for a long time and haven't had any trouble with them. > Are there any arguments against making them default? This is would qualify as core change. Please post this on the -dev ml. > Zac > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQFEOiRf/ejvha5XGaMRAn+kAJ9ieh37OjEwTriDQt/xPnmMGqEPsQCg7qvf > XEcYhyzdGSDBj8HtH8QYJzk= > =ge1C > -END PGP SIGNATURE- -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Re: should we add userpriv and usersandox to make.globals FEATURES?
Zac Medico posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 10 Apr 2006 02:24:49 -0700: > What do people think about adding userpriv and usersandox to make.globals > FEATURES? I've been using these for a long time and haven't had any > trouble with them. Are there any arguments against making them default? I've had very occasional problems, but no more than with the default sandbox on its own. I'd say go for it, as I appreciate the slightly better security, and it shouldn't cause many issues beyond what's already there. For the few it may, better to catch and fix them anyway! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
Zac Medico wrote: What do people think about adding userpriv and usersandox to make.globals FEATURES? I've been using these for a long time and haven't had any trouble with them. Are there any arguments against making them default? I didn't verify this personally, but a few days ago mkay came to #g-portage and asked whether FEATURES='usersandbox -sandbox' resulting in sandbox enabled is expected behaviour or not. Before we add usersandbox to the default FEATURES we should make sure that -sandbox always disables sandbox. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, What do people think about adding userpriv and usersandox to make.globals FEATURES? I've been using these for a long time and haven't had any trouble with them. Are there any arguments against making them default? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEOiRf/ejvha5XGaMRAn+kAJ9ieh37OjEwTriDQt/xPnmMGqEPsQCg7qvf XEcYhyzdGSDBj8HtH8QYJzk= =ge1C -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] intrusive spring cleaning/sanitizing
Updated version available at http://gentooexperimental.org/~ferringb/intrusive-spring-cleaning.patch Since it's what I'm running now, I'll be updating it off and on as I hit bugs locally for anyone looking to guinnea pig it. ~harring pgpEB4IQ8b7kR.pgp Description: PGP signature
Re: [gentoo-portage-dev] spring cleaning.
On Sun, Apr 09, 2006 at 01:40:13PM -0700, Mark Pagano wrote: >On 4/9/06, Brian Harring <[EMAIL PROTECTED]> wrote: > > Attached is a buttload of patches cleaning modules for the > following > things- > > > ~harring > >These are super helpful. Would you consider a 'best practices' >document? http://gentooexperimental.org/~ferringb/bzr/pkgcore/HACKING ~harring pgpvCyiJXXneJ.pgp Description: PGP signature
