On 1/11/07, Ned Ludd <[EMAIL PROTECTED]> wrote:
Or we/gentoo could just support it and stop breaking the end user.
uh, the point was, what will happen to all those apps for users who
switched to the -new- standard by using make.conf, who will therefore
have no make.profile dir, so programs lo
On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote:
> On 1/11/07, Marius Mauch <[EMAIL PROTECTED]> wrote:
>
> > And I assume there is a non-trivial number of custom scripts out there
> > using make.profile, but that's nothing we can do about.
> >
>
> You could give them all a grace period for
On 1/11/07, Marius Mauch <[EMAIL PROTECTED]> wrote:
And I assume there is a non-trivial number of custom scripts out there
using make.profile, but that's nothing we can do about.
You could give them all a grace period for which have to comply with
the new standard by then end of it, and have
On Wed, 10 Jan 2007 16:30:00 +0200
Simon Stelling <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> As per bug 148388 [1] comment 1, I'd like to discuss the deprecation
> of /etc/make.profile and the use of a PORTAGE_PROFILE variable
> instead. Reason for this change aside from consistency with all other
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
On Wed, 2007-01-10 at 16:30 +0200, Simon Stelling wrote:
> Hi all,
>
> As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of
> /etc/make.profile and the use of a PORTAGE_PROFILE variable instead.
> Reason for this change aside from consistency with all other portage
> settings
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, 2007-01-10 at 16:47 -0500, Daniel Drake wrote:
> Please mention this in the next GWN.
I don't always read every post of every thread. In the future, send
such requests to [EMAIL PROTECTED] to be sure I'll actually see it
before making up the GWN.
Thanks,
--
Chris Gianelloni
Release Eng
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.
>
So the openquicktime package was up to now broken with GCC 3.4 and later, see
bug #65453; as nobody seemed to actually give a damn about it, and there's
libquicktime that works decently enough, I've masked it and will be remove it
in 30 days.
--
Diego "Flameeyes" Pettenò - http://farragut.flam
Hi,
A few weeks ago I posted that gentoo-sources-2.4 needs a maintainer.
antarus stepped up but realised his fatal mistake and has now fled from
the scene.
If anyone is interested please step up, otherwise this will go through
the usual mask/removal process. Recruiting a non-developer to tak
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
A fellow Dutchman, and he also likes cats! Gentoo keeps getting better all
the time. :-)
Welkom, Martijn!
--
Hans de Graaff
--
gentoo-dev@gentoo.org mailing list
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
Simon Stelling wrote:
> Hi all,
>
> As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of
> /etc/make.profile and the use of a PORTAGE_PROFILE variable instead.
> Reason for this change aside from consistency with all other portage
> settings is the annoyance of re-adjusting the
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
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10.01.2007 at 13:56, Chris Gianelloni wrote:
On Wed, 2007-01-10 at 01:15 +0100, Robert Buchholz wrote:
* Who will add the entries to base/make.defaults? Can I do this?
Not only *can* you, but you absolutely *must* do this if you're making
the ch
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 ?
Make a transition like locales.build and locales.gen, for instance.
That would be handy.
On 1/10/07, Piotr Jaroszyński <[EMAIL PROTECTED]> wrote:
On Wednesday 10 January 2007 15:30, Simon Stelling wrote:
> Before the change to portage is finally made, a few things will have to
> be done:
>
> * A
Welcome on board, Marijn, I'm looking forward to doing the gnucash bumps
with you soon :)
--
Seemant Kulleen
Developer, Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
On Wednesday 10 January 2007 15:30, Simon Stelling wrote:
> Before the change to portage is finally made, a few things will have to
> be done:
>
> * Adjust handbook
> * Adjust the eselect plugin
> * (Anything I'm missing?)
Am I right in thinking there would be a transition period when profile setti
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
Hi all,
As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of
/etc/make.profile and the use of a PORTAGE_PROFILE variable instead.
Reason for this change aside from consistency with all other portage
settings is the annoyance of re-adjusting the /etc/make.profile link
before
net-www/bk_edit has been dead upstream since the end of 2003 and does
not build with GCC 4.x. We've only had one report of it failing to
build, thus I am led to believe it will not be profoundly missed.
--
gentoo-dev@gentoo.org mailing list
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
On Wed, 2007-01-10 at 01:15 +0100, Robert Buchholz wrote:
> If no one objects, I'd like to implement these changes. But there are
> some questions still open:
> * Who will add the entries to base/make.defaults? Can I do this?
Not only *can* you, but you absolutely *must* do this if you're making
t
It's my pleasure to introduce to you Marijn "hkBst" Schouten. He is
joining us to take care of the packages related to the weird programming
language called scheme.
He hails from Zeist, near Utrecht in the Netherlands. This is how he
describes himself: "I'm working on my combined master thesis for
# Raúl Porcel gentoo.org> (10 Jan 2007)
# Upstream dead almost 2 years ago and doesn't compile with GCC 4.x.
# Pending removal 10 Feb 2007, bug 152464
net-p2p/ww
--
gentoo-dev@gentoo.org mailing list
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
Hey,
Thanks to phreak`` for that great introduction and all his help over the
last month or so, much appreciated, if you (or any gentoo dev) find
yourself in switzerland, I'll gladly buy you a drink.
As phreak`` mentioned I have a strong security interest and I will
thusly be harassing Taviso for
52 matches
Mail list logo
