On Saturday 13 January 2007 05:17, Georgi Georgiev wrote:
>
> Something similar could be done about userpriv. Another red letter
> indicating that a package will compile as root (and the user is free to
> go ahead or abort as they see fit). The letter can be green if userpriv
> is not in FEATURES.
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]>
>
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
| > |
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
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 a
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 t
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]> wr
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 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.
> |
> |
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
| ACCEPT="keywo
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]> wr
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 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* encouragin
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 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 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
|
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 s
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 re
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 enfor
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 becau
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]> wr
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 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
> | (mali
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.
Unles
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 writ
On Fri, Jan 12, 2007 at 06:22:03AM +, Ciaran McCreesh wrote:
> 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
> | restri
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 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 ebu
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 sta
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
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 c
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 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 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 w
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
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 trou
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 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 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?
> >> Yo
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.
| ACC
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'
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 ru
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 R
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 yo
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 anoth
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 RESTR
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 sandb
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.
>
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 w
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=unat
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 package
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
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 meth
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):
> 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 gues
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 wa
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, inste
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 re
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.2&r2=1.3
>
> I looked at the diff and it replaces export SANDBOX_ON=0 with
>
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 ?
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
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] http
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 t
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/emac
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 RESTRICT=us
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 s
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 ma
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
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
> | pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Bug #161045 [1] requests that portage support RESTRICT=sandbox.
This is certainly a valid request but a user may wish to reject a
package based on certain questionable values of RESTRICT. Examples
other than sandbox incude unattended [2]
70 matches
Mail list logo
