Hi Stuart,
I'd like to comment on some of your plans for overlays.g.o.
Am Mittwoch, 22. März 2006 23:03 schrieb Stuart Herbert:
It's probably the right time for me to flesh out what I've been
planning for overlays.g.o.
The vision I have for overlays.g.o is one official home for all Gentoo
On Thursday 23 March 2006 06:38, Greg KH wrote:
i know last time i upgraded, the evdev driver was broken to crap anyways
;)
The evdev kernel driver, or evdev X driver?
Talking about X driver I suppose...
And I think I sort of know what's the big issue there... scancodes given by X
are
Hi Danny,
On 3/23/06, Danny van Dyk [EMAIL PROTECTED] wrote:
Hi Stuart,
I'd like to comment on some of your plans for overlays.g.o.
:)
The vision I have for overlays.g.o is one official home for all Gentoo
overlays run by projects and by individual Gentoo devs. I see the
Also for
On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote:
I'd like to offer two wiki engines and two version control systems on
overlays.g.o. I believe that gives us enough choice without us
loading the box with too much software for us to keep on top of.
One thing that was never planned was
Stuart Herbert wrote:
Developer overlays would only be created for active Gentoo developers,
and they would be accountable for its contents. Non-developers will
not be given write access to developer overlays.
This removes much of the motivation for merging overlays to o.g.o, at
least some of
On 3/23/06, Donnie Berkholz [EMAIL PROTECTED] wrote:
Stuart Herbert wrote:
Developer overlays would only be created for active Gentoo developers,
and they would be accountable for its contents. Non-developers will
not be given write access to developer overlays.
This removes much of the
On 23/03/06, Stuart Herbert [EMAIL PROTECTED] wrote:
The vision I have for overlays.g.o is one official home for all Gentoo
overlays run by projects and by individual Gentoo devs. I see the
Also for Arch/Herd Testers?
The discussion seems to have moved from the original how can we
become
Hi Luis,
On 3/23/06, Luis Medinas [EMAIL PROTECTED] wrote:
I agree with the wiki because it seems to be an easy way to users and
developers comunicate together and work. Like i said a few months ago
the documentation won't give any problems to GDP since GDP provides high
level docs. The wiki
Stuart Herbert wrote:
On 3/23/06, Donnie Berkholz [EMAIL PROTECTED] wrote:
Stuart Herbert wrote:
Developer overlays would only be created for active Gentoo developers,
and they would be accountable for its contents. Non-developers will
not be given write access to developer overlays.
This
Hi Chris,
On 3/23/06, Chris Bainbridge [EMAIL PROTECTED] wrote:
I think that the
use of overlays is more a symptom of a problem with portage. Overlay
problems:
[snip]
Developers are already using overlays, and some teams (including ones
I've been involved in) are actively and successfully
Hi Donnie,
On 3/23/06, Donnie Berkholz [EMAIL PROTECTED] wrote:
I don't think I'm understanding your intent here, because I've read
things two different ways. My main goal is to allow easy contribution by
non-devs, via allowing them to commit directly to some overlay. How is
that possible in
Stuart Herbert wrote:
The confusion is probably because, in the original vision statement, I
said that these things would only happen for overlays setup by, and
for, official projects. I wanted a disctinction between who could
commit to overlays run by projects, and who could commit to
But it seems rather artificial to me, and I suspect some devs might
enjoy contributions to their non-topical overlays.
It *is* artificial; that's fair critisism. I have a personal bias
towards projects. I'll withdraw the distinction.
So, to be clear: the owners of an overlay (the leads for a
On 23/03/06, Stuart Herbert [EMAIL PROTECTED] wrote:
Developers are already using overlays, and some teams (including ones
I've been involved in) are actively and successfully using them to
help with recruitment and to provide a way to access ebuilds that
would otherwise still be rotting in
On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote:
To answer Daniel's other question, about bugs.g.o ... trac on
overlays.g.o will have its bug tracking system disabled. We already
have one bug tracking system - bugs.g.o - and that's sufficient.
Umm... no?
If some random developer goes
Hi Chris,
On 3/23/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
If some random developer goes out there and creates his own fork of
catalyst in his overlay, I sure don't want to receive a *single* bug on
it. Ever.
Your nightmare scenario seems unavoidable. Enabling per-overlay bug
tracking
On Thu, 2006-03-23 at 10:09 +, Chris Bainbridge wrote:
Reduced responsibility for package QA (I expect we don't care about
overlays to become a standard response on bugs.g.o)
You will *definitely* get this from developers that won't be using the
overlays.
Let's just say you decide to use
I personally think this is a bad idea. I can understand and support
links to different overlay repositories, however I do not think that
gentoo should host or support overlays on its own infrastructure. For
one thing supporting overlays on our infrastructure looks like we are
supporting broken
Chris Gianelloni wrote:
On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote:
To answer Daniel's other question, about bugs.g.o ... trac on
overlays.g.o will have its bug tracking system disabled. We already
have one bug tracking system - bugs.g.o - and that's sufficient.
Umm... no?
On Thu, 2006-03-23 at 14:41 +, Stuart Herbert wrote:
Hi Chris,
On 3/23/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
If some random developer goes out there and creates his own fork of
catalyst in his overlay, I sure don't want to receive a *single* bug on
it. Ever.
Your
On 3/23/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
I see no problem with providing these sorts of overlays to
bridge the gap between contributing users and developers. I *do* see a
problem with simply allowing random overlays from any developer for
anything.
That's a reasonable point, and
On 23/03/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
On Thu, 2006-03-23 at 14:41 +, Stuart Herbert wrote:
Your nightmare scenario seems unavoidable. Enabling per-overlay bug
tracking doesn't stop users posting bugs in bugzilla. It just causes
confusion for users, because they're not
Chris Bainbridge wrote:
Another thing that some people may not have considered - with many
developers using various permutations of overlays, how can you
guarantee that what is being checked into the main tree will build for
a normal user? In order to test that, a developer would have to
Chris Bainbridge posted [EMAIL PROTECTED],
excerpted below, on Thu, 23 Mar 2006 12:47:13 +:
Adding the ebuilds to overlays is one option, but
then other users will be expected to find an overlay with their
package in, and then add it to make.conf.
... This hints at something I wasn't
Chris Gianelloni wrote:
I wouldn't mind seeing an actual unstable designation added to
KEYWORDS. The basic premise would be like package.mask packages where
things can be done *within the tree* but still has the same air of this
might be totally busted at some point as overlays. Users would
On Thursday 23 March 2006 19:16, Duncan wrote:
Chris Bainbridge posted [EMAIL PROTECTED],
excerpted below, on Thu, 23 Mar 2006 12:47:13 +:
Adding the ebuilds to overlays is one option, but
then other users will be expected to find an overlay with their
package in, and then add it to
On 3/23/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
Think about it this way, what if we had two competing products in the
tree that do the same thing, with the same file names? We would add a
blocker, no? So what mechanism is there to ensure that there's no
blocking issues between an
On Thu, 23 Mar 2006 19:31:24 +0100 Stefan Schweizer
[EMAIL PROTECTED] wrote:
| What about if we just skip your policies and let the overlays be a
| free place where people can handle issues how they think it is right
| for the specific case and not how $super_dev said somewhere. That is
| what
On 23/03/06, Rumen Yotov [EMAIL PROTECTED] wrote:
Hi,
Using a remote overlays is rather simple, just do emerge layman.
Read the einfo and then man layman.
It works flawlessly, just tested this with one remote overlay.
Beside that man layman explains pretty much of it's innerwork.
PS:There's
Ciaran McCreesh wrote:
On Thu, 23 Mar 2006 19:31:24 +0100 Stefan Schweizer
[EMAIL PROTECTED] wrote:
| What about if we just skip your policies and let the overlays be a
| free place where people can handle issues how they think it is right
| for the specific case and not how $super_dev said
On Thu, 2006-03-23 at 19:31 +0100, Stefan Schweizer wrote:
On 3/23/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
Think about it this way, what if we had two competing products in the
tree that do the same thing, with the same file names? We would add a
blocker, no? So what mechanism is
On Thursday 23 March 2006 13:57, Jakub Moc wrote:
Ciaran McCreesh wrote:
On Thu, 23 Mar 2006 19:31:24 +0100 Stefan Schweizer
[EMAIL PROTECTED] wrote:
| What about if we just skip your policies and let the overlays be a
| free place where people can handle issues how they think it is
On Thu, 2006-03-23 at 13:55 -0500, Chris Gianelloni wrote:
I'm sorry, but I am not OK with just standing by and watching us give
complete access to do anything with no accountability. If you are,
perhaps you really need to rethink your commitment to our users and your
fellow developers.
The
On 3/23/06, Daniel Ostrow [EMAIL PROTECTED] wrote:
You can't have it both ways, either they are wholey Unofficial and do not get
tracked in bugzilla at all (something which would have to be made VERY clear
to our users, e.g. a you use it you get to keep the pieces policy, and the
developer or
On Thursday 23 March 2006 20:43, Chris Bainbridge wrote:
On 23/03/06, Rumen Yotov [EMAIL PROTECTED] wrote:
Hi,
Using a remote overlays is rather simple, just do emerge layman.
Read the einfo and then man layman.
It works flawlessly, just tested this with one remote overlay.
Beside that
On Thu, 2006-03-23 at 18:55 +, Chris Bainbridge wrote:
On 23/03/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
On Thu, 2006-03-23 at 16:40 +, Chris Bainbridge wrote:
If the software a user wants is in an overlay, then the user will be
forced to install the overlay.
It shouldn't
On 3/23/06, Daniel Ostrow [EMAIL PROTECTED] wrote:
That is not what Stuart said, he indicated that overlays would be treated as
supported systems including the use of our bugzilla system to track defects.
If that is the case it crosses the line into the land of the official in
which case
Duncan Coutts wrote:
The way the Haskell team manages this is that we don't tell our end
users about our testing overlay. So we don't get bug reports from them.
We have three outside contributers with write access to the overlay
repo. They make changes in consultation with the team. So we're
As said above, how are you going to get new contributors without people
that are actually using/testing that stuff?
We find the via Bugzilla and/or irc and point them at the overlay.
That way, we more or less know who's using the overlay and make sure
they are briefed a bit before they start
On Thursday 23 March 2006 15:54, Eric Edgar wrote:
I personally think this is a bad idea. I can understand and support
links to different overlay repositories, however I do not think that
gentoo should host or support overlays on its own infrastructure. For
one thing supporting overlays on
On Thursday 23 March 2006 16:31, Chris Gianelloni wrote:
No. It isn't. Look in many developer overlays and you'll see packages
that they have made that work how *they* want them to, even if it is
*very* different from what is in the tree. This is the case for
packages that are not
Paul de Vrieze wrote:
I can only assume that other developers have similar overlays too. These
overlays form actually a wealth of resources that are hidden away. If there
were a semi-public overlay system in which developers could keep their
overlays, this might help in getting this out to
Chris Bainbridge posted [EMAIL PROTECTED],
excerpted below, on Thu, 23 Mar 2006 18:55:15 +:
No. It indicates nothing except that 58% of the 80 people who filled
out the poll are not really happy with the way the portage tree is
handled which by my counts, isn't even a drop in the bucket
Rumen Yotov posted [EMAIL PROTECTED], excerpted below,
on Thu, 23 Mar 2006 20:20:30 +0200:
Using a remote overlays is rather simple, just do emerge layman.
Read the einfo and then man layman.
It works flawlessly, just tested this with one remote overlay.
Beside that man layman explains
Duncan wrote:
I believe that's a fair summation of the arguments. My personal opinion,
for whatever it's worth as a user on the dev list, is that the CC point is
a valid one, the CC list should be a pretty decent measure of interest --
I know it has certainly proven so on some of the bugs
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
Asking developers to proxy takes almost as much time as it does to
ask them to maintain a package by themselves.
wrong
The developer is
directly responsible for anything he commits, so he will have to still
test the ebuild, still test
Ciaran McCreesh wrote: [Wed Mar 22 2006, 12:33:10PM EST]
On Wed, 22 Mar 2006 09:03:38 -0800 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| This definitely sounds like a fun idea. It would be even cooler if we
| were using a distributed SCM on both ends that allowed for easy
| merging.
Word of
Chris Gianelloni wrote: [Thu Mar 23 2006, 09:41:25AM EST]
On Thu, 2006-03-23 at 10:09 +, Chris Bainbridge wrote:
Reduced responsibility for package QA (I expect we don't care about
overlays to become a standard response on bugs.g.o)
You will *definitely* get this from developers that
On 3/23/06, Daniel Goller [EMAIL PROTECTED] wrote:
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
Asking developers to proxy takes almost as much time as it does to
ask them to maintain a package by themselves.
wrong
The developer is
directly responsible for anything he
On 3/24/06, Alec Warner [EMAIL PROTECTED] wrote:
Thoughts on ideas on this somewhat more focussed idea? ( or at least I
think it's more focused :P )
IMO motivation b) is not taken into account enough.
You are missing out a general-user-overlay, where the developer adding
a user to the access
so we're clear, users would be able to create their own overlays and publish
their ebuilds right ?
-mike
--
gentoo-dev@gentoo.org mailing list
Thoughts on ideas on this somewhat more focussed idea? ( or at least I
think it's more focused :P )
Will there be restrictions on what can go into these overlays? There
are some ebuilds that aren't allowed in the main portage tree. One
example is winex-cvs (see
On Thu, 23 Mar 2006 19:57:07 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| Sounds like a perfect way to break lots and lots of systems. Those
| policies are mostly there for good reason.
|
| You want to apply policies on overlays? Well no - sorry, overlays are
| none of QA's or any other policy
Stefan Schweizer wrote:
On 3/24/06, Alec Warner [EMAIL PROTECTED] wrote:
Thoughts on ideas on this somewhat more focussed idea? ( or at least I
think it's more focused :P )
IMO motivation b) is not taken into account enough.
You are missing out a general-user-overlay, where the
Hi all,
One big issue has come up with modular X, which is now fixed in
xorg-server 1.0.2-r1. The problem is that upstream released new versions
of a couple of extensions (composite and xfixes), but didn't release an
xorg-server including the updated knowledge of these extensions. The
code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As many are aware nss-3.11 and nspr-4.6.1 are in the tree. Many
packages still set the {nss|nspr}-libs and includes. With nss-3.11 and
nspr-4.6.1 the proper configs and pkgtools files are included. Any
package in the tree that has them hardcoded in
On Thu, 2006-03-23 at 18:34 -0500, Dan Meltzer wrote:
On 3/23/06, Daniel Goller [EMAIL PROTECTED] wrote:
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
Asking developers to proxy takes almost as much time as it does to
ask them to maintain a package by themselves.
wrong
On Thursday 23 March 2006 23:43, Brian wrote:
On Thu, 2006-23-03 at 22:14 +0900, Jason Stubbs wrote:
On Thursday 23 March 2006 16:23, Brian wrote:
/etc/portage/lists/userlist1
format:
net-www/apache
www-apache/mod_perl
...
If you make that /etc/portage/sets and
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and is there any clear doc of them [as i wouldnt like
to go through them all
tvali wrote:
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and is there any clear doc of them [as i wouldnt like to
On 23/03/06, Alec Warner [EMAIL PROTECTED] wrote:
tvali wrote:
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and
>From Paul de Vrieze:The semantics that make up the relationships between useflags and the actual
source as goes out of the preprocessor is very complicated. Probably theeasiest way to find it out is to try each permutation and somehow hook intogcc/g++ to get the result of that choice.And that's
On Thursday 23 March 2006 20:53, tvali wrote:
So this interaction is one more thing to get simpler? I'm starting to think
that i should seek for some very-very small part of portage to develop,
because size of things [amount of work], which i already think i should
improve in some way, is
On 23/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
Certainly,chroot combined with lvm snapshots would be the easiest way.If you want to focus on binary packages, you might want to start with notdoing it automatically, but using some crude heuristics. You can make it
configurable for when the
Ok... this discussion is missing my initial point that is how to
provide binary dependency and avoid many crashes we have now with
almost no effort.
My initial proposal was to, after compile and before install is done,
we should parse linker information and check for each library it
depends,
On 23/03/06, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:
Ok... this discussion is missing my initial point that is how toprovide binary dependency and avoid many crashes we have now withalmost no effort.
Paul was not missing it ;)
Part of his message was for me, part was for you.
I have
This thread keeps going and going and it's a subject thats already been
covered... So I'll just Re you here.
Search the archives here for RRDEPEND, LDEPEND
As soon as I can figure out a way in python to do fast lookups of libs
it will be integrated. I can do it really really fast in c but
I
67 matches
Mail list logo
