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
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
# Raúl Porcel armin76 at 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
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
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
the
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
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
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
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 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 setting
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
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:
* Adjust
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 ?
-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
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
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
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
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
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)
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
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ò -
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 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
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 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 is
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 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 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 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 which have
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
52 matches
Mail list logo
