On Thursday 23 March 2006 22:32, Donnie Berkholz wrote:
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
On Friday 24 March 2006 01:23, Mike Frysinger wrote:
so we're clear, users would be able to create their own overlays and
publish their ebuilds right ?
Not on gentoo servers though. They are able already and we can't prevent
it. What I think an overlays.gentoo.org could add is something like
On Friday 24 March 2006 01:54, Thomas Cort wrote:
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
Hi Andres,
On 3/23/06, Andres Loeh [EMAIL PROTECTED] wrote:
dcoutts has described the current practice we use in the Haskell
team, but that doesn't necessarily mean that it's the only practice
that would work for us. I can imagine that if we can come up with
reasonable policies for o.g.o, we
It is a Gentoo problem, because Gentoo gets innundated with bogus bug
reports when users screw up their systems in weird ways and don't
realise the cause.
Convince me that this is something more than just a power play, and
I'll work with you. But that's the hurdle you'll need to overcome
Ciaran McCreesh wrote:
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
On Fri, Mar 24, 2006 at 09:52:30AM +0100, Paul de Vrieze wrote:
Things that are not suited for public consumption should not be made
public in the first place. This is one reason that I don't think that
users should be given the opportunity to create their own gentoo-hosed
overlays. I
Thomas Cort wrote:
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
Hi Stuart.
dcoutts has described the current practice we use in the Haskell
team, but that doesn't necessarily mean that it's the only practice
that would work for us. I can imagine that if we can come up with
reasonable policies for o.g.o, we can switch to a slightly different
(i.e.,
On Thu, 2006-03-23 at 18:45 -0500, Alec Warner wrote:
PROPOSAL:
a) overlays.gentoo.org - A sub-domain for hosting overlays or
'development sandboxes'. Developers want an area for sandboxed
development of packages outside of the main tree. As stated in the
previous thread this allows
On Thu, 2006-03-23 at 20:04 -0600, Jory A. Pratt wrote:
-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
On Fri, 2006-03-24 at 08:59 +, Stuart Herbert wrote:
It is a Gentoo problem, because Gentoo gets innundated with bogus bug
reports when users screw up their systems in weird ways and don't
realise the cause.
Convince me that this is something more than just a power play, and
I'll
On Fri, 2006-03-24 at 10:16 +0100, Jakub Moc wrote:
As this should be a separate thread, just one reason or example - I'm
really uncomfortable e.g. w/ QA intervening in overlays stuff,
considering the current way QA is being done in Gentoo... Current
non-interactivity policy has clearly
On Fri, 2006-03-24 at 12:46 +0100, Andres Loeh wrote:
If the overlay's changelog is included on o.g.o's front-page, and the
wiki / GuideXML site is publically readable, but we just disallow
anonymous access to the overlay itself (only if requested, this
wouldn't be the default setup) ...
On Friday 24 March 2006 14:55, Chris Gianelloni wrote:
My main point is I don't want one of my tree packages to break because
some ricer told some n00b to use some crazy ebuild from some random
overlay that isn't really fit for the general masses. If we take at
least *some* measures to
Chris Gianelloni wrote: [Fri Mar 24 2006, 08:55:30AM EST]
As I've said, my only request is a single policy that before an overlay
can become publicly readable on overlays.gentoo.org (which is Gentoo
infrastructure) that it does not break packages in the main tree that
are not in the overlay.
Hi Chris,
On 3/24/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
As I've said, my only request is a single policy that before an overlay
can become publicly readable on overlays.gentoo.org (which is Gentoo
infrastructure) that it does not break packages in the main tree that
are not in the
Stuart,
I like the idea of overlays but your email here is completely bogus.
Ciaran just explained why overlays are a Gentoo problem, rebutting
Jakub's assertion that there's no need for policies. I don't see any
agenda here, so either you're pulling in external context, or you're
reading into
Hi Andres,
On 3/24/06, Andres Loeh [EMAIL PROTECTED] wrote:
Here's a list of things that I think are essential or highly helpful to
our working process:
* We should be allowed to continue using darcs for our version management.
If that's not possible on Gentoo infra, we should be allowed to
Chris Gianelloni wrote:
On Fri, 2006-03-24 at 08:59 +, Stuart Herbert wrote:
It is a Gentoo problem, because Gentoo gets innundated with bogus bug
reports when users screw up their systems in weird ways and don't
realise the cause.
Convince me that this is something more than just a power
On 3/24/06, Mike Frysinger [EMAIL PROTECTED] wrote:
so we're clear, users would be able to create their own overlays and publish
their ebuilds right ?
Not on overlays.g.o, no.
Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list
On Thursday 23 March 2006 19:54, Thomas Cort wrote:
Will there be restrictions on what can go into these overlays?
common sense
-mike
--
gentoo-dev@gentoo.org mailing list
If the overlay's changelog is included on o.g.o's front-page, and the
wiki / GuideXML site is publically readable, but we just disallow
anonymous access to the overlay itself (only if requested, this
wouldn't be the default setup) ... how would that work for you?
It would work, of
On Fri, 24 Mar 2006 10:16:15 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| We get innundated with tons of bogus bug reports every day, overlays
| or not - see the number of invalid/duplicate bugs flowing every days.
| We got a couple of bugs in last two a three days basically stating
| ZOMG, glibc
On 3/24/06, Andres Loeh [EMAIL PROTECTED] wrote:
Here's a list of things that I think are essential or highly helpful to
our working process:
* We should be allowed to continue using darcs for our version management.
If that's not possible on Gentoo infra, we should be allowed to host
Chris Gianelloni wrote:
On Fri, 2006-03-24 at 12:46 +0100, Andres Loeh wrote:
As I've said, my only request is a single policy that before an overlay
can become publicly readable on overlays.gentoo.org (which is Gentoo
infrastructure) that it does not break packages in the main tree that
are
On 3/24/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:
I'm really uncomfortable with QA intervening anywhere. It would be far
nicer if the appropriate developers ensured that they weren't breaking
anything.
+1
--
gentoo-dev@gentoo.org mailing list
Ciaran McCreesh wrote:
On Fri, 24 Mar 2006 10:16:15 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| We get innundated with tons of bogus bug reports every day, overlays
| or not - see the number of invalid/duplicate bugs flowing every days.
| We got a couple of bugs in last two a three days
On 3/24/06, Alec Warner [EMAIL PROTECTED] wrote:
At least in my mind the overlays should be developmental overlays; not
for public comsumption. This doesn't mean don't tell anyone about it
so that no one shows up. It means interested users will probably
inquire about helping out, etc...and
Dňa Fri, 24 Mar 2006 17:15:37 +0100
Jakub Moc [EMAIL PROTECTED] napísal:
Yeah, and the point is? It happens every day, there are already tons
of third-party overlays used by Gentoo users, but once this thread
about official overlays started, you came here to tell us wow,
this all will cause
Dňa Fri, 24 Mar 2006 15:23:14 +
Stuart Herbert [EMAIL PROTECTED] napísal:
On 3/24/06, Mike Frysinger [EMAIL PROTECTED] wrote:
so we're clear, users would be able to create their own overlays
and publish their ebuilds right ?
Not on overlays.g.o, no.
FWIW, this is already possible
On 3/24/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
Again, try to keep this technical discussion technical and leave your
personal biases out of it.
It's not meant as a personal critisism of Ciaran. Ciaran's being very
helpful in this thread. It just happens that it was his post that
On Friday 24 March 2006 11:32, Andrej Kacian wrote:
Dňa Fri, 24 Mar 2006 15:23:14 +
Stuart Herbert [EMAIL PROTECTED] napísal:
On 3/24/06, Mike Frysinger [EMAIL PROTECTED] wrote:
so we're clear, users would be able to create their own overlays
and publish their ebuilds right ?
On Fri, 2006-03-24 at 09:47 -0500, Aron Griffis wrote:
Chris Gianelloni wrote: [Fri Mar 24 2006, 08:55:30AM EST]
As I've said, my only request is a single policy that before an overlay
can become publicly readable on overlays.gentoo.org (which is Gentoo
infrastructure) that it does not
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled where, and by whom? Are we
considering a fairly tightly controlled system, or a wild free-for-all?
Exactly which
Grant Goodyear wrote: [Fri Mar 24 2006, 02:35:34PM EST]
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled where, and by whom? Are we
considering a fairly tightly
On Friday 24 March 2006 14:35, Grant Goodyear wrote:
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled where, and by whom? Are we
considering a fairly tightly
On Friday 24 March 2006 15:06, Daniel Ostrow wrote:
On Friday 24 March 2006 14:35, Grant Goodyear wrote:
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled
Thanks for the summary. I think that's a fair assessment of where we are at.
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed a
preference for a
On Fri, 2006-03-24 at 08:40 -0500, Chris Gianelloni wrote:
On Thu, 2006-03-23 at 20:04 -0600, Jory A. Pratt wrote:
-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
Stuart Herbert wrote:
Thanks for the summary. I think that's a fair assessment of where we are at.
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed
On Friday 24 March 2006 21:44, Stuart Herbert wrote:
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed a
preference for a different distributed VCS
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Thursday 23 March 2006 21:35, tvali wrote:
BINSLOT is a new word for me.
Ok BINSLOT is normally slot. However in some cases packages are in the
same slot, but not binary compatible (like their libraries having a
different SONAME e.g.
On Fri, Mar 24, 2006 at 01:40:01PM +0200, tvali wrote:
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Thursday 23 March 2006 21:38, Gustavo Sverzut Barbieri wrote:
Cons:
- it's not the final solution to the problem, as said, interfaces
would be better... but interfaces would
On 24/03/06, Brian Harring [EMAIL PROTECTED] wrote:
Checking the interfaces/symbols sucks however, because you can only do
it _after_ you've built whatever you're building (packages do adjust
the defines/typedefs/structs dependant on configure/build options).
As I stated earlier, bincompat
On Friday 24 March 2006 12:40, tvali wrote:
Interface can be made somewhat automatically checkable.
For example:
void a(int);
void b(int, int);
void b(int, char);
Is compatible with:
void a(int);
void b(int, int);
Unfortunately, your wrong. This only makes sure that you have the right
On Friday 24 March 2006 13:10, Brian Harring wrote:
As I stated earlier, bincompat (not binslot paul :P) is the route to
If you want to call it bincompat, I'd have to insist to make it
BINCOMPAT ;-).
go- it gives you up front information so a resolver can plan out what
has to be rebuilt
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Friday 24 March 2006 12:40, tvali wrote:
Interface can be made somewhat automatically checkable.
For example:
void a(int);
void b(int, int);
void b(int, char);
Is compatible with:
void a(int);
void b(int, int);
48 matches
Mail list logo
