On Fri, 12 Jan 2007 08:48:37 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| | When does upstream get to install arbitrary content on my
| |
On Fri, Jan 12, 2007 at 08:00:18AM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 08:48:37 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| |
On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| Why else would a user want to refuse ebuilds that set userpriv?
|
| As a safeguard against accidental mistakes by upstream.
But ebuilds setting RESTRICT=userpriv are explicitly saying we can't
use userpriv not because
Quoting Ciaran McCreesh [EMAIL PROTECTED]:
On Fri, 12 Jan 2007 16:02:01 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
... nothing to add here, sounds alright ...
| Still, your point makes sense. But I hope that you will agree that
| as long as FEATURES=userpriv exists it should be
On Fri, 12 Jan 2007 17:39:44 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| And there are probably just as many situations when the RESTRICT is
| abused. I can vaguely recall only one such example: either vpopmail
| or courier-imap refuse to compile *not* as root which is silly.
If that's
On Fri, Jan 12, 2007 at 08:30:49AM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| Why else would a user want to refuse ebuilds that set userpriv?
|
| As a safeguard against accidental mistakes by upstream.
But ebuilds setting
On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 08:30:49AM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| But ebuilds setting RESTRICT=userpriv are explicitly saying we
| can't
On Fri, Jan 12, 2007 at 10:11:59AM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| ACCEPT_RESTRICT=-userpriv (or whatever) would mean I want to be
| protected against accidental mistakes, even if it means I can't
| install some
On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 10:11:59AM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| | ACCEPT_RESTRICT=-userpriv (or whatever) would mean I want to be
| |
On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| I don't think anyone was planning on encouraging people to mess with
| ACCEPT_RESTRICT if it gets implemented.
Implementing it *is* encouraging
On Fri, 12 Jan 2007 13:04:21 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| | I don't think anyone was planning on encouraging people to mess
| |
On Fri, Jan 12, 2007 at 12:19:18PM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 13:04:21 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| |
On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| FEATURES has legitimate values. The feature as a whole is useful,
| even if some of the options have very restricted target audiences.
|
| So if ACCEPT_* were implemented in a way that lets you write
|
On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| FEATURES has legitimate values. The feature as a whole is useful,
| even if some of the options have very restricted target audiences.
|
| So if
On Fri, 12 Jan 2007 14:05:49 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| | FEATURES has legitimate values. The feature as a whole is
| |
On Fri, Jan 12, 2007 at 05:19:02PM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 14:05:49 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk
| [EMAIL PROTECTED] wrote:
| |
On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| And noauto and noclean do have specific genuine use, so it's not a
| fair comparison.
|
| Again irrelevant to the point, since regardless of whether they have
| some small valid use, they should not be recommended to
On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk [EMAIL PROTECTED]
| With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with
| RESTRICT=fetch, so portage /should/ complain regardless of whether the
| sources are
maillog: 13/01/2007-02:05:45(+0100): Harald van Dijk types
On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk [EMAIL PROTECTED]
| With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with
| RESTRICT=fetch, so portage
On Sat, 13 Jan 2007 02:05:45 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk
| [EMAIL PROTECTED]
| | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages
| | with
On Sat, Jan 13, 2007 at 05:45:31AM +, Ciaran McCreesh wrote:
On Sat, 13 Jan 2007 02:05:45 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote:
| On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk
| [EMAIL PROTECTED]
| | With
On Wed, 2007-01-10 at 13:32 -0500, Mike Frysinger wrote:
On Wednesday 10 January 2007 13:03, Jakub Moc wrote:
And RESTRICT=sandbox is still completely unneeded,
commercial packages or not... We don't need to introduce a special
RESTRICT because of two borked packages in the tree and we
On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote:
getting quite hostile. The only thing I can possibly gather from this
is you're intentionally being fucking dense, so it's not worth my time.
How is it that you can ignore half an email and only respond to
something out of context and then
On Thu, 2007-01-11 at 09:07 +0900, Georgi Georgiev wrote:
Further, by adopting ACCEPT_RESTRICT, it would be possible to be able to say:
ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch anything outside
the sandbox.
ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated
On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote:
On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger [EMAIL PROTECTED]
| as stated in original e-mail, unattended/sandbox are just some
| examples, not the only ones
So which RESTRICT values *should* the user legitimately have to care
On Thu, 11 Jan 2007 11:56:09 -0500 Mike Frysinger [EMAIL PROTECTED]
wrote:
| On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote:
| On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger
| [EMAIL PROTECTED]
| | as stated in original e-mail, unattended/sandbox are just some
| | examples, not
maillog: 11/01/2007-17:02:48(+): Ciaran McCreesh types
On Thu, 11 Jan 2007 11:56:09 -0500 Mike Frysinger [EMAIL PROTECTED]
wrote:
| On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote:
| On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger
| [EMAIL PROTECTED]
| | as stated in
On Fri, 12 Jan 2007 06:38:23 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| I agree that if an ebuild wants to misbehave it can and there is no
| stopping it. However, code that is executed in pkg_* is generally
| restricted to code written by the person who is involved in
| maintaining the
Quoting Ciaran McCreesh [EMAIL PROTECTED]:
On Fri, 12 Jan 2007 06:38:23 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| I agree that if an ebuild wants to misbehave it can and there is no
| stopping it. However, code that is executed in pkg_* is generally
| restricted to code written by the
On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| When does upstream get to install arbitrary content on my computer?
| Upstream's build system gets to write stuff to $D, but not to $ROOT
| (malice aside). The move to $ROOT, and anything after that, is the
| ebuild
On Fri, 12 Jan 2007 16:02:01 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| Why would it not be removed? Upstream installs in the sandbox, the
| contents of the sandbox are recorded in the package database and
| with collision-protect it will not override random stuff on my
| computer.
Unless
On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote:
On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk [EMAIL PROTECTED]
wrote:
| When does upstream get to install arbitrary content on my computer?
| Upstream's build system gets to write stuff to $D, but not to $ROOT
| (malice
Kevin F. Quinn napsal(a):
On Tue, 9 Jan 2007 23:23:55 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
If a RESTRICT value is questionable, it shouldn't be supported or
used.
I agree; it'd be useful to know exactly what is failing the sandbox and
why, with the aim of fixing sandbox if it
On Wed, 2007-01-10 at 09:40 +0100, Jakub Moc wrote:
into pkg_setup and be done with it; no need for RESTRICT=sandbox or
ACCEPT_RESTRICT. Users can decide whether they really wish to install
such app and disable sandbox temporarily if they think it's a good idea.
Uhh... you missed
On Wednesday 10 January 2007 03:40, Jakub Moc wrote:
If you want to write an ebuild for some commercial broken stuff that
doesn't work w/ sandbox and stick it into some overlay, then stick
before you start anymore ignorant rants, why dont you look at what actually
needs this
app-editors/emacs
On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote:
On Wed, 2007-01-10 at 09:40 +0100, Jakub Moc wrote:
into pkg_setup and be done with it; no need for RESTRICT=sandbox or
ACCEPT_RESTRICT. Users can decide whether they really wish to install
such app and disable sandbox temporarily if they
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 03:40, Jakub Moc wrote:
if you're categorizing those as commercial broken stuff you might want to
look up the word commercial
Huh? I was referring to this link [1] on Bug 161045 (which presumably
started this whole debate)
[1]
maillog: 10/01/2007-15:34:52(+0100): Jakub Moc types
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 03:40, Jakub Moc wrote:
if you're categorizing those as commercial broken stuff you might want to
look up the word commercial
Huh? I was referring to this link [1] on Bug 161045
On Wednesday 10 January 2007 09:34, Jakub Moc wrote:
Huh? I was referring to this link [1] on Bug 161045 (which presumably
started this whole debate)
so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the
threads arent even closely related ? how does that make sense ?
Georgi Georgiev napsal(a):
The gcl borkage is your job [2] and you might want to finally revert
your broken commit:
[2]
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lisp/gcl/gcl-2.6.7-r2.ebuild?r1=1.2r2=1.3
I looked at the diff and it replaces export SANDBOX_ON=0 with
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 09:34, Jakub Moc wrote:
Huh? I was referring to this link [1] on Bug 161045 (which presumably
started this whole debate)
so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the
threads arent even closely related ?
Chris Gianelloni napsal(a):
Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended
when calling for no ACCEPT_RESTRICT...
Don't see how's userpriv related here; also the original idea was to
stick FEATURES=unattended (or non-interactive or whatever else) into
portage, instead
On Wednesday 10 January 2007 13:03, Jakub Moc wrote:
And RESTRICT=sandbox is still completely unneeded,
commercial packages or not... We don't need to introduce a special
RESTRICT because of two borked packages in the tree and we should not
introduce any more packages borked in a similar way
Mike Frysinger napsal(a):
this is what you should have said in the first place
we need a real solution for emacs/gcl ... exporting SANDBOX_ON=0 is not the
answer
-mike
Real solution, sure... RESTRICT=sandbox is not a solution, it's
identical to the current hackish workaround, so I guess we
On Wednesday 10 January 2007 13:45, Jakub Moc wrote:
Real solution, sure... RESTRICT=sandbox is not a solution, it's
identical to the current hackish workaround, so I guess we can save
portage folks the trouble...
except that RESTRICT is the documented method for disabling user FEATURES in
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 13:45, Jakub Moc wrote:
Real solution, sure... RESTRICT=sandbox is not a solution, it's
identical to the current hackish workaround, so I guess we can save
portage folks the trouble...
except that RESTRICT is the documented method for
On Wednesday 10 January 2007 19:03, Jakub Moc wrote:
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 09:34, Jakub Moc wrote:
Huh? I was referring to this link [1] on Bug 161045 (which presumably
started this whole debate)
so you're replying to a non-gentoo-dev thread on a
On Wed, 10 Jan 2007 08:02:37 -0500 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| Besides, if I want to maintain some nasty application that
| doesn't work with sandbox, who are you (or anyone, for that matter) to
| tell me that I cannot?
Given how Portage relies upon sandbox to ensure that packages
On Wed, 2007-01-10 at 19:06 +0100, Jakub Moc wrote:
Chris Gianelloni napsal(a):
Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended
when calling for no ACCEPT_RESTRICT...
Don't see how's userpriv related here; also the original idea was to
stick FEATURES=unattended
On Wed, 2007-01-10 at 21:01 +0100, Paul de Vrieze wrote:
On Wednesday 10 January 2007 19:03, Jakub Moc wrote:
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 09:34, Jakub Moc wrote:
Huh? I was referring to this link [1] on Bug 161045 (which presumably
started this whole debate)
Chris Gianelloni napsal(a):
On Wed, 2007-01-10 at 19:06 +0100, Jakub Moc wrote:
Don't see how's userpriv related here; also the original idea was to
stick FEATURES=unattended (or non-interactive or whatever else) into
portage, instead of inventing new variables to handle this, AFAICR.
Wow.
On Wed, 10 Jan 2007 16:43:52 -0500 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| That's fine, but it still doesn't remove the usefulness of an
| ACCEPT_RESTRICT for some other variables.
For what other variables? We already established that it doesn't work
for fetch, and that it's unsafe for
On Wed, 2007-01-10 at 23:02 +0100, Jakub Moc wrote:
The name of the GLEP is even RESTRICT=unattended... not
FEATURES=unattended...
And how's that in contradiction? Why can't a user stick 'unattended'
into FEATURES instead of having to care about yet another variable?
Sticking
Chris Gianelloni napsal(a):
On Wed, 2007-01-10 at 23:02 +0100, Jakub Moc wrote:
The name of the GLEP is even RESTRICT=unattended... not
FEATURES=unattended...
And how's that in contradiction? Why can't a user stick 'unattended'
into FEATURES instead of having to care about yet another
On Wednesday 10 January 2007 18:36, Jakub Moc wrote:
OK, dunno which of us is being dense; the whole point is that the damned
ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly?
You already *don't* accept the restrict by sticking 'unattended' into
FEATURES... WTH would you
Quoting Jakub Moc [EMAIL PROTECTED]:
Georgi Georgiev napsal(a):
I looked at the diff and it replaces export SANDBOX_ON=0 with
RESTRICT=sandbox. It seems that the problem is older than that
revision.
No, the gcl problem didn't exist until vapier fixed the ebuild. I
still fail to see why
On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| Further, by adopting ACCEPT_RESTRICT, it would be possible to be able
| to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch
| anything outside the sandbox.
| ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 18:36, Jakub Moc wrote:
OK, dunno which of us is being dense; the whole point is that the damned
ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly?
You already *don't* accept the restrict by sticking 'unattended' into
Quoting Ciaran McCreesh [EMAIL PROTECTED]:
On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| Further, by adopting ACCEPT_RESTRICT, it would be possible to be able
| to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch
| anything outside the sandbox.
|
On Wednesday 10 January 2007 19:22, Jakub Moc wrote:
Mike Frysinger napsal(a):
On Wednesday 10 January 2007 18:36, Jakub Moc wrote:
OK, dunno which of us is being dense; the whole point is that the damned
ACCEPT_RESTRICT is completely redundant; hard to grok or what exactly?
You already
On Thu, 11 Jan 2007 09:38:29 +0900 Georgi Georgiev [EMAIL PROTECTED]
wrote:
| Quoting Ciaran McCreesh [EMAIL PROTECTED]:
| On Thu, 11 Jan 2007 09:07:54 +0900 Georgi Georgiev [EMAIL PROTECTED]
| wrote:
| | Further, by adopting ACCEPT_RESTRICT, it would be possible to be
| | able to say:
On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger [EMAIL PROTECTED]
wrote:
| as stated in original e-mail, unattended/sandbox are just some
| examples, not the only ones
So which RESTRICT values *should* the user legitimately have to care
about?
--
Ciaran McCreesh
Mail
On Wed, 10 Jan 2007 14:00:42 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Wednesday 10 January 2007 13:45, Jakub Moc wrote:
Real solution, sure... RESTRICT=sandbox is not a solution, it's
identical to the current hackish workaround, so I guess we can save
portage folks the trouble...
On Wed, 10 Jan 2007 19:06:09 +0100
Jakub Moc [EMAIL PROTECTED] wrote:
Chris Gianelloni napsal(a):
Uhh... you missed RESTRICT=userpriv and the upcoming
RESTRICT=unattended when calling for no ACCEPT_RESTRICT...
Don't see how's userpriv related here; also the original idea was to
stick
On Tue, 9 Jan 2007 23:23:55 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 09 Jan 2007 14:41:50 -0800 Zac Medico [EMAIL PROTECTED]
wrote:
| Bug #161045 [1] requests that portage support RESTRICT=sandbox.
| This is certainly a valid request but a user may wish to reject a
| package
Kevin F. Quinn wrote:
On Tue, 9 Jan 2007 23:23:55 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Tue, 09 Jan 2007 14:41:50 -0800 Zac Medico [EMAIL PROTECTED]
wrote:
| Bug #161045 [1] requests that portage support RESTRICT=sandbox.
| This is certainly a valid request but a user may wish
On Tue, 09 Jan 2007 21:13:14 -0500 Alec Warner [EMAIL PROTECTED]
wrote:
| RESTRICT=fetch is between the package, the manager, and the user (as
| someone has to fetch the files).
Except that the user shouldn't have to care about it then either. The
user need only care when a package requires
67 matches
Mail list logo
