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
On 1/11/07, Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote:
On Friday 12 January 2007 05:43, Richard Fish wrote:
> My idea would be to extend emaint to check package.keywords and
> package.use for obsolete flags, unnecessary atoms (like foo-1.2 in
> keywords when foo-1.3 is stable), atoms that don'
On Friday 12 January 2007 05:43, Richard Fish wrote:
> My idea would be to extend emaint to check package.keywords and
> package.use for obsolete flags, unnecessary atoms (like foo-1.2 in
> keywords when foo-1.3 is stable), atoms that don't match any current
> ebuild, and so on.
app-portage/eix al
On 1/11/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
The Gentoo Council is looking for some ideas for some small projects
that we could initiate that would help Gentoo.
My idea would be to extend emaint to check package.keywords and
package.use for obsolete flags, unnecessary atoms (like foo
On Thu, Jan 11, 2007 at 07:17:41PM -0800, Robin H. Johnson wrote:
> See attached.
And I need to look at my calendar again, it's 2007 now and not 2006.
--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpE
See attached.
--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Summary of the Gentoo Council meeting held 11 January 2006
--
(Summary prepared by robb
Seemant Kulleen wrote:
GIT is a good alternative, but has massive changes of it's own,
particularly I think in workflow. Workflow is important, and it's
beneficial to make the workflow changes at the same time as the backend
is changed.
Alec,
Can you speak to some of these workflow changes?
> GIT is a good alternative, but has massive changes of it's own,
> particularly I think in workflow. Workflow is important, and it's
> beneficial to make the workflow changes at the same time as the backend
> is changed.
Alec,
Can you speak to some of these workflow changes?
I only have expe
Seemant Kulleen wrote:
> On Thu, 2007-01-11 at 14:08 -0800, Robin H. Johnson wrote:
>
>> However, for several reasons this is not yet feasible, and furthermore
>
> Just for the sake of completeness can you outline those reasons?
>
> Thanks,
>
The status quo is a harsh mistress. 'There is no c
Simon Stelling wrote:
> I like the idea. Something really useful I could think of is *drums*
>
> the implementation of GLEP 42.
>
GLEP 42 is almost fully implemented and is currently undergoing local
testing (by me) to find the last of the obvious bugs.
--
gentoo-dev@gentoo.org mailing list
On Thu, Jan 11, 2007 at 05:51:43PM -0500, Seemant Kulleen wrote:
> On Thu, 2007-01-11 at 14:08 -0800, Robin H. Johnson wrote:
> > However, for several reasons this is not yet feasible, and furthermore
> Just for the sake of completeness can you outline those reasons?
I'm not saying it won't happen
On Thu, 2007-01-11 at 14:08 -0800, Robin H. Johnson wrote:
> However, for several reasons this is not yet feasible, and furthermore
Just for the sake of completeness can you outline those reasons?
Thanks,
--
Seemant Kulleen
Developer, Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
K, so my account hasn't been retired yet, so I'm making this comment as a
developer (at least until someone gets around to my retirement bug). :-)
I really like blubb's idea here. Not just of implementing GLEP 42, but the
idea of having the Council responsible for overseeing and assigning tasks
fo
I like the idea. Something really useful I could think of is *drums*
the implementation of GLEP 42.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list
Chris Gianelloni wrote:
Submit your ideas here, so we can discuss them. I will be choosing one
idea that we think we can accomplish to test out the idea of
Council-driven projects.
Construction of a dynamic website for tracking kernel security issues.
There are too many of them and too many k
On Thu, Jan 11, 2007 at 11:49:43PM +0200, Simon Stelling wrote:
> Piotr Jaroszy??ski wrote:
> >What do you think?
> I think it would be much nicer to have a VCS with support for atomic
> commits.
I agre, from multiple points of view including those of 1. developer
who has broken stuff with epkgmov
On Thu, Jan 11, 2007 at 10:29:58PM +0100, Piotr Jaroszy??ski wrote:
> After yesterday epkgmove fun I thought that it would be nice to have some
> control on when our cvstree is synced with mirrors. My first very basic idea
> is just to put a block_sync file in the tree when smth big is going on,
Piotr Jaroszyński wrote:
What do you think?
I think it would be much nicer to have a VCS with support for atomic
commits.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list
Piotr Jaroszyński kirjoitti:
> Hello,
>
> After yesterday epkgmove fun I thought that it would be nice to have some
> control on when our cvstree is synced with mirrors. My first very basic idea
> is just to put a block_sync file in the tree when smth big is going on, like
> new kde version sta
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
Hello,
After yesterday epkgmove fun I thought that it would be nice to have some
control on when our cvstree is synced with mirrors. My first very basic idea
is just to put a block_sync file in the tree when smth big is going on, like
new kde version stabilization or big pkg move. Inside the fi
On Thu, Jan 11, 2007 at 04:04:31PM -0500, Chris Gianelloni wrote:
> Robin Johnson came up with a good example, which was "genflags" an
> application that was to gather information from the running system and
> spit out a customized set of C(XX)FLAGS for the user.
I should clarify, that genflags was
Chris Gianelloni wrote:
The Gentoo Council is looking for some ideas for some small projects
that we could initiate that would help Gentoo. These project ideas
should be things that are attainable in a measurable amount of time, and
should be fairly small in scope. This would be in the same vei
The Gentoo Council is looking for some ideas for some small projects
that we could initiate that would help Gentoo. These project ideas
should be things that are attainable in a measurable amount of time, and
should be fairly small in scope. This would be in the same vein as the
Google Summer of
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 Wed, 10 Jan 2007 22:30:32 -0800
Ned Ludd <[EMAIL PROTECTED]> wrote:
> 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 th
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
35 matches
Mail list logo
