[gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

I would like to ask that the Council discuss the current state and
future of the GWN at their next meeting.

1. Reliability. The GWN claims to be a weekly publication, yet it
frequently fails to publish without prior warning. There was no edition
this week, and Patrick Lauer says that it is "unknown" whether there
will be an edition next week as Ulrich Plate is AWOL.

2. Permissions. Although it could be considered flattering that the GWN
should choose a developer's blog as inspiration for an article, they
should ensure that they have the developer / author's permission before
quoting them (see previous complaints by brix, ciaranm and others).

I also believe that when posting an article or interview, a copy should
be sent to the relevant people to ensure that they are ok with what is
being posted (my dev of the week interview, for example, was rather
screwed up and misrepresentative). When someone contacts GWN to have
something corrected, it would be appreciated were the GWN staff to at
least deign to acknowledge receipt, even if for some reason they choose
not to honour the corrections or post a retraction (although refusing to
publish corrections is extremely insulting to those wronged).

3. Misinformation, misquotations and outright fabrications. Sure,
there's freedom of the press, but that shouldn't be used as an excuse
for deliberately making up quotes and printing intentional
misinformation.

4. Credit. Care should be taken to ensure that crrect credit is given.

From a PR perspective, Gentoo could benefit greatly by better
utilisation of the GWN. I believe that as it stands, however, the GWN is
discouraging people from contributing and damaging Gentoo's credibility.

Another thing that concerns me is the way the articles are written. It
is blatanly obvious that the GWN writers are not native English speakers
as both the grammar and the flow of the articles is far from attractive.
Having read through the archives, I notice that there was once a time
when the GWN was a great publication, and I would like to think that it
could become great yet again; in its current state, though, it is doing
more harm than good.

Lack of content and poorly written or incorrect articles are often
justified by the GWN team on grounds of overwork and insufficient
manpower. When I asked why they were not recruiting, I was informed that
no-one has any interest in contributing. Upon speaking with others,
however, I find that this is not the case -- people are interested, but
fear (and rightly so) that their work will be edited in such a way that
it is no longer something with which they want to be associated.

Another complaint is that the GWN rejects any writing style which has
any degree of character or levity. Any attempt at dececnt writing (the
kind that would make it into publication in English newspapers or
magazines, for example), is met with the claim that "the GWN is not a
humorous publication".

I would like to see discussion about the way the GWN is
(mis)representing Gentoo, how we can better actualise its full potential
and what can be done to address the concerns listed above. 

I have the honour to be, sir, your obedient servant, 
Christel -- conventionally stuck in the 1920s.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Ned Ludd]

On Sat, 2006-06-10 at 02:01 +0100, Roy Marples wrote:
> On Saturday 10 June 2006 01:33, Alec Warner wrote:
> > > So we have two use flags - client and server. Here are the possabilities
> > >
> > > -client -server
> > > +client -server
> > > +client +server
> > > -client +server
> > >
> > > Do we read -client -server and +client +server to mean the same thing?
> > > If so the logic can read
> > >
> > > if use client || ! use server ; then
> > > # build client
> > > fi
> > > if use server || ! use client ; then
> > > # build server
> > > fi
> > >
> > > How does portage stop us from doing that now?
> >
> > built_with_use is then incorrect, since for -client -server you really
> > built both.
> 
> use client && build client
> use server && build server
> 
> The problem here is that breaks existing ebuilds, which could be viewed as 
> equally bad.
> 
> But technically built_with_use isn't incorrect as the ebuild wasn't built 
> with 
> it. To effectively use built_with_use you cannot assume that the flag does 
> what it says on the tin - you have to inspect the ebuild code you're 
> querying.

> Prior history shows deps of db vs gdbm where if both or neither then db was 
> used, otherwise the flagged db was used.

Maybe along the same lines as what you are pointing out here it should
also be noted that built_with_use is semi faulty and can return wrong
results when no /var/db/pkg/$CATEGORY/$PVR/USE exists. This happens when
using the most recent ppc-uclibc stages which omitted a few entries
from the vdb. We end up having some ebuild or other assuming that
uclibc itself was built with +nls when it's really (-nls) use.masked
etc..



> Roy Marples <[EMAIL PROTECTED]>
> Gentoo/Linux Developer (baselayout, networking)
-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Dealing with /var/cache on unmerge

[Andrew Ross]

Apologies if this has been addressed previously, but my searches of the 
Gentoo website, devmanual, forums, and mailing list archives didn't turn 
up anything definitive.


Is there any sort of policy covering how an ebuild should deal with 
/var/cache during unmerge?


The devmanual pages for pkg_prerm (http://tinyurl.com/huh7n) and 
pkg_postrm (http://tinyurl.com/f5b7o) are the closest I've come to an 
answer, but I don't consider deletion of the cache dir to be the same as 
updating it.


I've looked at a few ebuilds in the tree (including samba and squid) and 
they seem to leave in place any cache files created during normal 
execution of the package in question.


This means that after an unmerge the sysadmin needs to go and clean out 
/var/cache/whatever.


During ebuild development and testing, I can see why one might want the 
cache files to remain, so unconditional cleaning of /var/cache is out of 
the question. However, removing of cache files could be controlled by a 
FEATURE (eg. keepcache - unless that implies the retention of cache 
files from the original merge a la keepwork and keeptemp).


A similar issue exists with log files, but I'd expect them to occupy 
less space than caches, and generally be considered more useful (since 
they can't be regenerated). If they were to be dealt with, perhaps 
portage could have a purge option that removes all traces of a package 
from the system - including log and cache files (it looks like temp 
files should already be cleaned out by the ebuild).


Of course, the general opinion might be that management of /var/cache is 
outside the scope of portage, and best left to the sysadmin (and/or an 
separate automated tool), although the FHS doesn't specify either way 
(http://tinyurl.com/26gpd). That's fine with me, but I think it's good 
to have this on record in the mailing list archives, and perhaps in the 
devmanual as well.


Cheers

Andrew

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Roy Marples]

On Saturday 10 June 2006 01:33, Alec Warner wrote:
> > So we have two use flags - client and server. Here are the possabilities
> >
> > -client -server
> > +client -server
> > +client +server
> > -client +server
> >
> > Do we read -client -server and +client +server to mean the same thing?
> > If so the logic can read
> >
> > if use client || ! use server ; then
> > # build client
> > fi
> > if use server || ! use client ; then
> > # build server
> > fi
> >
> > How does portage stop us from doing that now?
>
> built_with_use is then incorrect, since for -client -server you really
> built both.

use client && build client
use server && build server

The problem here is that breaks existing ebuilds, which could be viewed as 
equally bad.

But technically built_with_use isn't incorrect as the ebuild wasn't built with 
it. To effectively use built_with_use you cannot assume that the flag does 
what it says on the tin - you have to inspect the ebuild code you're 
querying.

Prior history shows deps of db vs gdbm where if both or neither then db was 
used, otherwise the flagged db was used.

Problems problems - soltutions that work with existing installs or do we just 
bite the bullet and do

! use client && ! use server && die "must select either client or server"

Which kinda defeats the purpose of a clean install.

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Stuart Herbert]

How does portage stop us from doing that now?


I don't think it does ... but you'll have to go back and clean it up
when USE-based DEPs support eventually arrives.  But we can worry
about that nearer the time.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Alec Warner]

Roy Marples wrote:

On Friday 09 June 2006 23:34, Mike Frysinger wrote:


On Friday 09 June 2006 16:35, Chris Gianelloni wrote:


This is the "official" (hehe) request for comments on making a policy of
how to handle ebuilds than can be used for either client or server and
how to allow for building client-only.


rather than moving to some sort of policy that satisfies no one completely
and we'll have to back out of later, why dont we wait until portage can
give us proper support for USE=client/server
-mike



So we have two use flags - client and server. Here are the possabilities

-client -server
+client -server
+client +server
-client +server

Do we read -client -server and +client +server to mean the same thing?
If so the logic can read

if use client || ! use server ; then
# build client 
fi

if use server || ! use client ; then
# build server
fi

How does portage stop us from doing that now?



built_with_use is then incorrect, since for -client -server you really 
built both.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Roy Marples]

On Friday 09 June 2006 23:34, Mike Frysinger wrote:
> On Friday 09 June 2006 16:35, Chris Gianelloni wrote:
> > This is the "official" (hehe) request for comments on making a policy of
> > how to handle ebuilds than can be used for either client or server and
> > how to allow for building client-only.
>
> rather than moving to some sort of policy that satisfies no one completely
> and we'll have to back out of later, why dont we wait until portage can
> give us proper support for USE=client/server
> -mike

So we have two use flags - client and server. Here are the possabilities

-client -server
+client -server
+client +server
-client +server

Do we read -client -server and +client +server to mean the same thing?
If so the logic can read

if use client || ! use server ; then
# build client 
fi
if use server || ! use client ; then
# build server
fi

How does portage stop us from doing that now?

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: Sunrise Project -- Sunrise FAQ

[Stefan Schweizer]

Anders Hellgren wrote:
> What the faq entry didn't say, and what amne asked for in his previous
> e-mail was that questions related to ebuilds not distributed as part of
> the official tree should be posted to the Unsupported Software forum [1].
Yes


> We have neither reason nor desire to treat sunrise ebuilds differently
> from other user contributed ebuilds.
Yeah, I was just taking ebuild related questions in account. Of course
useage questions are only valid in an "Unsupported Software forum"

I added:

- For useage questions the "Unsupported Software forum" on forums.gentoo.org
is the right place

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Luca Barbato]

Mike Frysinger wrote:

> rather than moving to some sort of policy that satisfies no one completely 
> and 
> we'll have to back out of later, why dont we wait until portage can give us 
> proper support for USE=client/server
> -mike

+1

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ

[Anders Hellgren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 10 Jun 2006, Stefan Schweizer wrote:


I actually was trying to adress your issues with that FAQ entry, sorry if
you feel like I have decided something. Please give me a reasonable
rewording if you think my assumption is not correct that this will be
treated equally by forums users (I count me in here, that is why I made the
assumption).
I will of course explicitly forbid any forums activity in the FAQ when you
have a problem with that.

- Stefan

What the faq entry didn't say, and what amne asked for in his previous 
e-mail was that questions related to ebuilds not distributed as part of 
the official tree should be posted to the Unsupported Software forum [1]. 
We have neither reason nor desire to treat sunrise ebuilds differently 
from other user contributed ebuilds.


[1] http://forums.gentoo.org/viewforum-f-51.html

/Anders
- -- 
Anders Hellgren (kallamej)

Gentoo Forums Administrator
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEigfVFX025WX+RG4RAoCdAKDGJvqNtORg28ZwC4FQrfHmGueLMwCfTLB8
OcB/l+0yVTG4sTWgAUyCecw=
=bSqm
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [RFC] i18n project

[Diego 'Flameeyes' Pettenò]

So, as someone might have read in my blog[1] I've been thinking for a couple 
of days about creating an i18n project.

What would an i18n project be needed for? Mainly, to try to provide to our 
non-English native users a more friendly environment. We discussed many times 
in the past about making simpler having UTF-8 support, or even enabling it by 
default, but of course it's difficult to handle this right now, and this is 
not the only concern.

What I have in mind is establishing some kind of team that would collaborate 
with the current doc translators that would like to help, trying to get other 
parts of Gentoo accessible to non-English speakers. Translating man pages for 
Gentoo-specific software, making Portage and other gentoo-specific packages 
i18n-capable and translating them, translating forums (I think the Forums 
stuff already handle that, but maybe it would help if we're able to get a 
more "complete" team).

Least but not last, also translating software that's missing translator, like 
I did for xine-lib/xine-ui/gxine and Italian this week, or at least 
release "poupdate" tarballs with translations updated from CVS when the ones 
in the releases are obsolete.

This might also help to find a "home" to utf8 and cjk herds, for instance.

I'm actually going to work to add to Portage (will-be-2.2) i18n capabilities 
next week, and I'll be doing for sure the Italian translation.

Comments, thoughts, translation, are all welcome :)

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/08/do-we-need-an-i18n-project
-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpdosLJCtYfL.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Stuart Herbert]

Hi Chris,

On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:

> > This means if the client and the
> > server for a particular package is in a single package, we should build
> > both by default.
>
> No thanks.  That doesn't match the standard operating procedure
> mentioned above.  By default, why don't we just build whatever
> $UPSTREAM intended built by default?

That is *exactly* what I said.


Sorry, that's not how I read it.  I read you saying that, if $UPSTREAM
ship both server/client in a single package, we should build both.  I
didn't grok that as being the same as building whatever $UPSTREAM
indented being built by default.

For example, let's say package 'foo' has both client and server code
in the one package, but running ./configure w/ no parameters only
enables the client.  This is the behaviour I believe we should be
following.  From what you said in your initial email, I understood
that you'd like to see both server and client enabled, regardless of
what running ./configure w/ no parameters would enable.

Seems to be a mis-communication here.


> How will you support building the server-only portions of the package?
I honestly never bothered to consider it, and really don't care.


I'm sorry to hear that :(


Someone else can come up with that idea.  The problem with using two USE
flags is what do you do when someone chooses neither?


This is easily solved by the IUSE requested functionality for Portage,
so that each ebuild can propose a default set of USE flags.  If the
user ends up switching off all required USE flags, this should be
detected, and the emerge should refuse to proceed.  (Why? Because
otherwise USE-based DEPs can't work deterministically).

Ciaran filed a bug about what we'd need a year or so back.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] What is "official"?

[Josh Saddler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To me, "official" means it's found anywhere within the gentoo.org/ webspace.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEif8drsJQqN81j74RApMAAJ9/e3txjQTIz1RHmpRAkbVc5DV4ggCfRhn1
T1D2O5hZMuUIouwc1iHYQhw=
=A7/n
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Henrik Brix Andersen]

On Fri, Jun 09, 2006 at 06:19:53PM -0400, Ned Ludd wrote:
> Seems logical.
> 
> But for what you are proposing I'd suggest not making USE of minimal at
> all for this. I'd rather see that flag reserved for mostly 
> embedded alike use.

Me too. A server/client set of USE flags seems more appropriate to me.

Sincerely,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpwzLLFM0rG6.pgp
Description: PGP signature

Re: [gentoo-dev] Portage-2.1 released

[Josh Saddler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alec Warner wrote:
> Portage-2.1 final is released,

Thanks for the hard work, Portage team. 2.1 is fabulous. Really, really good 
job!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEif5ArsJQqN81j74RAjq9AJ9mle+qd7Gb9Gc8dV2uLy9XyKe1qACfZo+A
bsPUWSobuCcGbLUSarqj7Lw=
=aTjI
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ

[Stefan Schweizer]

Wernfried Haas wrote:
> - Ebuild development questions should for example be discussed in
>   #gentoo-dev-help and I have seen threads about it on
> forums.gentoo.org and even helped there. There is no reason why
> questions about ebuild writing for the Sunrise overlay should not be
> treated equally.
> --snip--
> 
> Maybe i wasn't clear enough in my previous mail (which may be the
> reason why it was simply ignored), but while we were taken by surprise
> of a new project being announced and no one talking to us about where
> this may fit in on the forums, this FAQ entry completely ignores what
> i explicitely asked for in the mail above.
> If you want to use the forums, that's fine and they are here to help
> with problems, but deciding things without approaching us to find a
> solution that also fits into our forums structure makes me have
> reasonable doubts how this project will integrate into Gentoo.

I actually was trying to adress your issues with that FAQ entry, sorry if
you feel like I have decided something. Please give me a reasonable
rewording if you think my assumption is not correct that this will be
treated equally by forums users (I count me in here, that is why I made the
assumption).
I will of course explicitly forbid any forums activity in the FAQ when you
have a problem with that.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Wernfried Haas]

On Fri, Jun 09, 2006 at 08:10:26PM +0200, Stefan Schweizer wrote:
> Markus Ullmann wrote:
> > Maybe that way we avoid any misunderstandings, nearly doubled posts and
> > repeating ourselves over and over again.
> 
> The problem is that some questions and answers easily get lost in a mailing
> list. To solve this shortcoming, I am starting to make a FAQ page in the
> trac wiki:
> http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

Read Message-ID: <[EMAIL PROTECTED]> before you
set up FAQ entries like: 

--snip--
Do I need to support Sunrise users and their questions now? 

You can treat this as you like on a case-by-case basis:

- Ebuild development questions should for example be discussed in
  #gentoo-dev-help and I have seen threads about it on
forums.gentoo.org and even helped there. There is no reason why
questions about ebuild writing for the Sunrise overlay should not be
treated equally. 
--snip--

Maybe i wasn't clear enough in my previous mail (which may be the
reason why it was simply ignored), but while we were taken by surprise
of a new project being announced and no one talking to us about where
this may fit in on the forums, this FAQ entry completely ignores what
i explicitely asked for in the mail above.
If you want to use the forums, that's fine and they are here to help
with problems, but deciding things without approaching us to find a
solution that also fits into our forums structure makes me have
reasonable doubts how this project will integrate into Gentoo.

cheers,
Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org


pgpEz1xWRQSmV.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Mike Frysinger]

On Friday 09 June 2006 16:35, Chris Gianelloni wrote:
> This is the "official" (hehe) request for comments on making a policy of
> how to handle ebuilds than can be used for either client or server and
> how to allow for building client-only.

rather than moving to some sort of policy that satisfies no one completely and 
we'll have to back out of later, why dont we wait until portage can give us 
proper support for USE=client/server
-mike


pgpW7HbKAYULr.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Ned Ludd]

On Fri, 2006-06-09 at 16:35 -0400, Chris Gianelloni wrote:
> This is the "official" (hehe) request for comments on making a policy of
> how to handle ebuilds than can be used for either client or server and
> how to allow for building client-only.
> 
> The idea is quite simple.
> 
> Gentoo's standard operating procedure is to build packages as they were
> intended and packaged from upstream.  This means if the client and the
> server for a particular package is in a single package, we should build
> both by default.  To facilitate building the client portions only, the
> use of the local "minimal" USE flag is allowed.  This can be shown in
> the openldap and dhcp ebuilds.  

That is backwards however. 
The first ebuild to take advantage of building server/client 
was net-snmp and it uses minimal to build only the snmpd, snmptrapd.
Sense then others have been bastardizing the USE flag.

Being that net-snmp was historically first in doing this I'd rather 
not have to change all my setups on all my servers to accommodate your
idea of inverting the logic of declaring it minimal to mean client-only.

> Each package which uses this flag should
> document what is built when the "minimal" USE flag is in use, via
> use.local.desc as it will remove any ambiguity into what is being done.
> Because of this, I would request that "minimal" not become a global USE
> flag, since its meaning would actually be different between some
> packages, 

Seems logical.

But for what you are proposing I'd suggest not making USE of minimal at
all for this. I'd rather see that flag reserved for mostly 
embedded alike use.

-peace


-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:

> Since when was overlays.gentoo.org supposed to even be a service to our
> users?  As I understand it, the goal was to ease development, not to
> provide an easy method for half-working ebuilds to make it to our user's
> machines.

What's the point of development if not to help users? 
Everything we do should be done to help users (and worst case we help
that small group of users that are devs). 

> > > This means it *CANNOT* be left up to a small group of developers to
> > > decide without any discussion on the matter.
> > So now we're a democracy where everything needs to be voted upon?
> 
> Anything this abhorrently stupid doesn't need a vote. 
Bullshit.
If you need to resort to insults you failed to show on a technical level
why it is bad.

>  It should be cast
> out on its complete lack of merit, alone.  Also, at no point did I ever
> ask for a vote.  Don't put words in my mouth and I'll try to pretend
> like I care what you say, OK?
So now you're El Cheffe? 

And please, stop sounding like my father. 


> > *sigh*
> > Let's leave that debate for another day ...
> 
> You brought it up, not I.  Feel free to debate it with yourself until
> you're blue in the face.
I debated it for about 27 seconds, seems quite obvious now. Thanks for
the hint.

> > > > Yes, now it is easier to check out the ebuilds. More users ==> better
> > > > testing.
> > > 
> > > Except that now the developer has to do much more work to get the same
> > > information, making it even less likely that he'll bother to pick up one
> > > of these maintainer-wanted bugs.  
> > s/the developer/I/
> 
> You're right... I had that wrong.
> 
> s/the developer/the developers/
> 
> After all, there have been quite a number of people agreeing with me.

That's a non sequitur.
There's also quite a number of people agreeing with me, but that doesn't
make any point of view better or more thruthful. So either we try to
discuss in the hope of finding a compromise or we do a headcount and do
something stupid. I'd prefer a discussion, but if you just want to HULK
SMASH SUNRISE I won't stop you.

> > there are some devs that would prefer this overlay environment.
> > Please don't push your personal preferences as The Right Way (tm)
> 
> Ehh.  Were you an ebuild developer, your opinion might actually count
> for something when it comes to an ebuild development discussion.  By the
> way, where's the GWN this week?
Ulrich is MIA, nothing I can change. He does that from time to time.

> I'm glad your faith in them is so high.  My faith in *any* group this
> small having the ability to watch over a large number of outside
> contributors simply isn't there.
Let it grow. Slowly. 
Either it stands on its own or it dies from lack of interest.

> > That doesn't stop me from giving out access to my server to anyone who
> > has a good reason ... like the Gentoo/HURD repository or the Java
> > overlay.
> Well, we thank you for your immense self-sacrifice.  What this has to do
> with the topic at hand, I have no idea.
Well ... think about it. It's kinda obvious once you grok it.


> > Just don't kill an idea before it is even tested ...
> Why not?  What reason is there to stop me from aborting this brain-dead
> monstrosity before it claims a single user casualty, let alone our
> reputation?  I would have thought that your involvement in "PR" would
> have you thinking better.  A reputation is something that takes years to
> establish, and seconds to demolish.  You, of all people, should know
> that.
Yes. But killing an idea like this seems almost as damaging to me.

There's a group of devs thinking "Hey, how can we make things better?".
They come up with a few ideas, throw away those that are just not
feasible. Then they have one idea that looks useful, they try to
implement it. So either you convince those people (with whom I am only
tangentially involved) that it is a bad idea or you let them do their
thing.

I think what is more damaging to the reputation of Gentoo is the
incessant discussion of ideas before they are even tried, killing many
good things before they even have a chance on a technical level. 

> Yes, we are *so* lagged behind everyone else.  Where do you come up with
> these "facts" anyway?  I'd like to visit this mythical land.
Like, gcc 4 ? Gentoo is lagging behind most others (because our QA has grown 
from non-existant to really really good)

Sidenote: I don't mind that at all. But I see a split here ... one group going 
the debian route of making everything really really stable.
And the other group that doesn't mind mild b0rkage, but wants to be on
the bleeding edge.

Those two populations will be hard to reconcile. Give the second group a
sandbox and the first group can do their thing much easier ...
 
> > Where you see a problem I see potential: More well-tested ebuilds,
> > recruiting potential developers ... if you don't want that you're an
> > elitist bastard. ;-)
> 
> Aww, how sweet

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Andrea Barisani]

On Fri, Jun 09, 2006 at 05:22:18PM -0400, Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 22:51 +0200, Patrick Lauer wrote:
> > On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> > [snip]
> > > > If someone wanted to exploit boxen he'd use a much simpler attack
> > > > vector ... our rsync mirrors are wide open. No need to secure the little
> > > > window over there when the front door is open ...
> > > 
> > > Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> > > that?  You can't?  What a wonder!
> > 
> > I don't need that ...
> > Look, three-step plan to hacking Gentoo boxen:
> > 
> > 1) open a few rsync mirrors and get them into the official rotation
> 
> Umm... the rsync servers in rsync.gentoo.org are all controlled by infra
> now.  If you're using another rsync server (read, untrusted) then you
> get what you deserve.  ;]
>

Right.

Besides all distro suffer this same problem, indeed shouting that our mirror
system is a wide open door is far from being fair. This new project though
could be a nice attack vector, in the FAQ you state that you don't allow
eclasses, that's nice...but I can think thousand of other ways for
compromises without them using ebuilds.

Not pointing fingers here, just stating that if this is an "official" project
(whatever that means)...or even if it's not, much caution is advised
security-wise in who you trust and what you are going to put in the tree (and
most important what the perception of your authority/reliability will be
user-wise).

Cheers

-- 
Andrea Barisani <[EMAIL PROTECTED]>.*.
Gentoo Linux Infrastructure Developer  V
 (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E^^_^^
  "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage-2.1 released

[Henrik Brix Andersen]

On Fri, Jun 09, 2006 at 10:42:55AM -0500, Andrew Gaffney wrote:
> Alec Warner wrote:
> >Portage-2.1 final is released,
> 
> Is that the 4th horseman I see off in the distance?

No! It's a flying pig! :)

Seriously, a big thank you to all the people who invested their spare
time contributing and getting this release done. Good work guys and
gals.

Sincerely,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpiw3kWe6CyV.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Henrik Brix Andersen]

On Fri, Jun 09, 2006 at 02:46:39PM -0500, James Potts wrote:
> I have a counter-question to this:  What modifications to the sunrise
> (not sunrice, btw) project would have to be made to get you to stop
> actively trying to shut it down?  I really don't care if you think the
> team will be willing to make the changes, list them anyway, please. :)

It should be hosted on a non *.gentoo.org domain (nongentoo.org?) to
signal the fact that it contains unofficial and unsupported
ebuilds. I'll leave it up to infra to comment if this domain can be
hosted on official Gentoo hardware.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpOqorJC3drk.pgp
Description: PGP signature

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Ciaran McCreesh]

On Fri, 9 Jun 2006 11:24:34 +0100 "Stuart Herbert"
<[EMAIL PROTECTED]> wrote:
| On 6/9/06, Edward Catmur <[EMAIL PROTECTED]> wrote:
| > With an overlay: search sunrice.gentoo.org for the package
| 
| If you want people to debate seriously with you, stop calling this
| project 'sunrice'.

Why? It's a small amount of mild entertainment in what is otherwise a
highly depressing state of affairs. It doesn't in any way detract from
the other valid points he raised.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Lance Albertson]

Patrick Lauer wrote:
> On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> [snip]
>>> If someone wanted to exploit boxen he'd use a much simpler attack
>>> vector ... our rsync mirrors are wide open. No need to secure the little
>>> window over there when the front door is open ...
>> Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
>> that?  You can't?  What a wonder!
> 
> I don't need that ...
> Look, three-step plan to hacking Gentoo boxen:
> 
> 1) open a few rsync mirrors and get them into the official rotation

Actually, the only rotation you can get on is a community one (which
minimizes the amount of users). All the servers under rsync.g.o are
strictly controlled by infra.

So nice try ...

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
> Peper wrote:
> >>> well. A couple of examples:
> >>>
> >>> http://bugs.gentoo.org/show_bug.cgi?id=122500
> >> And again, you use my project of an example.  Perhaps you should try
> >> looking at something that actually supports your argument?
> > 
> > I think it's an example of how user-friendly is bugzilla...
> 
> Yeah, exactly... I don't understand where did this idea of me using
> someone else's own project against himself came from in the first place.
> *confused*
> 
> I've merely posted a few examples illustrating that bugzilla and
> attachments suck big time for new ebuilds' development. Or, why did you
> switch vmware-server work to SVN if bugzilla is *the* place for all
> this? Apparently it's not all that great, otherwise you wouldn't have
> done that.

#1.  *I* (as the vmware team) didn't do it, the (then) user who posted
the package did
#2.  We also built it up as the entire vmware overlay... it had little
to do with any limitations in bugzilla, and more to do with my
already-established desires to make maintaining vmware-* easier

This really is a case of you not knowing what the actual facts were in
regards to the situation, yet pointing it out as some kind of
corroborating evidence for your argument.  This is definitely not the
case.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Chris Gianelloni]

On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote:
> On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > Gentoo's standard operating procedure is to build packages as they were
> > intended and packaged from upstream.
> 
> +1
> 
> > This means if the client and the
> > server for a particular package is in a single package, we should build
> > both by default.
> 
> No thanks.  That doesn't match the standard operating procedure
> mentioned above.  By default, why don't we just build whatever
> $UPSTREAM intended built by default?

That is *exactly* what I said.

> It means that different packages will behave differently throughout
> the tree, but that's okay, and is more Gentoo-like than your proposal.

Except that you're just saying exactly what I said, just in different
words.

> > To facilitate building the client portions only, the
> > use of the local "minimal" USE flag is allowed.
> 
> How will you support building the server-only portions of the package?

I honestly never bothered to consider it, and really don't care.
Someone else can come up with that idea.  The problem with using two USE
flags is what do you do when someone chooses neither?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 22:51 +0200, Patrick Lauer wrote:
> On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
> [snip]
> > > If someone wanted to exploit boxen he'd use a much simpler attack
> > > vector ... our rsync mirrors are wide open. No need to secure the little
> > > window over there when the front door is open ...
> > 
> > Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> > that?  You can't?  What a wonder!
> 
> I don't need that ...
> Look, three-step plan to hacking Gentoo boxen:
> 
> 1) open a few rsync mirrors and get them into the official rotation

Umm... the rsync servers in rsync.gentoo.org are all controlled by infra
now.  If you're using another rsync server (read, untrusted) then you
get what you deserve.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] What is "official"?

[Henrik Brix Andersen]

On Fri, Jun 09, 2006 at 09:22:08PM +0200, Kevin F. Quinn wrote:
> On Fri, 09 Jun 2006 07:50:27 -0400
> Ned Ludd <[EMAIL PROTECTED]> wrote:
> 
> > Keeping it simple...
> > 
> > If it's hosted on gentoo infrastructure it's official.
> > If it's hosted on gentooexp.org/SF/Non infra then it's not official.
> 
> I think this is the best way to define it.  Anything on Gentoo
> infrastructure has to have broad support from the Gentoo community.
> Anything elsewhere can do whatever it wants.

I fully agree with you and Ned on this.

> We could take a leaf from the GNU book, and register nongentoo.org if
> infra wish to host stuff that is not official (c.f. savannah.gnu.org vs
> savannah.nongnu.org).  Then sunrise could go on overlays.nongentoo.org

That's not a half bad idea, actually. Question is - does infra want to
host unofficial projects?

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpF5QPzHl4Am.pgp
Description: PGP signature

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Christel Dahlskjaer]

On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote:
> On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer
> <[EMAIL PROTECTED]> wrote:
> | I'd say that it's entirely possibly for some non-dev to sneak
> | malicious code into the tree as is now, just as it will be possible
> | to do in an overlay.   
> | 
> | It's not like it's particulary difficult to have someone proxy for
> | you, and let's face it, if someone is willing to do so then they
> | probably can't be arsed checking that what they are committing is
> | clean and nice.. I mean, I trust you, right? 
> 
> Huge difference between committing a few things for a person you know,
> where you have time to review code, and bulk committing random stuff
> where you don't have time to check anything. That's the deal here -- if
> a large number of developers can't handle maintainer-wanted, what makes
> people think a far smaller number can without screwing up?

I was actually agreeing with you. 

I also believe to be mistaken as I believed that all overlays on o.g.o
would be in the style of say the existing PHP and Haskell overlays, and
as such those with access would be trusted contributors, and I also
believed that the individual projects would be making sure that they
were testing and reviewing whatever patches were made to their stuff. 




signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] client+server packages - build which one?

[Chris Gianelloni]

On Fri, 2006-06-09 at 16:22 -0400, Mike Frysinger wrote:
> On Friday 09 June 2006 15:04, Chris Gianelloni wrote:
> > On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote:
> > > On Friday 09 June 2006 14:10, Roy Marples wrote:
> > > > Some packages provide both a client and a server. As such, users
> > > > usually only want one or the other - and rarely both.
> > >
> > > Thanks to wolf31o2 for pointing out that current policy dictates that we
> > > install both by default and the minimal USE flag should be used to stop
> > > server only compoment from installing.
> >
> > Not policy (I don't think) but current accepted practice.
> >
> > Should this become a policy?
> 
> i dont think it should ... minimal has a very floating definition and varies 
> widely based on the package

See my RFC for how this is handled.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Chris Gianelloni]

On Fri, 2006-06-09 at 16:18 -0400, Daniel Ostrow wrote:
> On Fri, 2006-06-09 at 14:46 -0500, James Potts wrote:
> > On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > > On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote:
> > > > Markus Ullmann wrote:
> > > > > Maybe that way we avoid any misunderstandings, nearly doubled posts 
> > > > > and
> > > > > repeating ourselves over and over again.
> > > >
> > > > The problem is that some questions and answers easily get lost in a 
> > > > mailing
> > > > list. To solve this shortcoming, I am starting to make a FAQ page in the
> > > > trac wiki:
> > > > http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
> > > >
> > > > We are adding new questions there, if you have some additions, please 
> > > > talk
> > > > to me and I will add them for you.
> > >
> > > I have one...
> > >
> > > What will it take for this project to go away?
> > >
> > I have a counter-question to this:  What modifications to the sunrise
> > (not sunrice, btw) project would have to be made to get you to stop
> > actively trying to shut it down?  I really don't care if you think the
> > team will be willing to make the changes, list them anyway, please. :)
> > 
> > I'm asking because I think that this project is a Good Thing, if it
> > gets handled correctly.  I also agree that if it is not handled
> > correctly it can and will be a Very Bad Thing.
> 
> 
> To start with (and mind you this is just my list):
> 
> 1). At least one member of the project must be familiar enough with each
> of the officially supported architectures, x86, amd64, ppc, ppc64, hppa,
> alpha, mips, sparc and ia64, to support any bugs which arise due to arch
> specific issues. The level of knowledge must be on par with that which
> is required to join any of the aforementioned arch teams. This is the
> only way to ensure that arch teams do not experience a higher work load
> because of this overlay's existence.
> 
> 2). For a package to be added to the overlay at least one member of the
> project must be familiar enough with the package that they would be
> accepted into the team that would maintain the package if it were in the
> mainline tree if they are not already a team member.  This is the only
> way to ensure that non-arch teams do not experience a higher work load
> because of this overlay's existence.
> 
> 3). Teams must have the option to "opt-out" of participation. What this
> would mean is if a team "opts-out" no packages may be placed in the
> overlay that would be maintained by said team if the package was added
> to the main tree. 
> 
> 4). Packages cannot be added that are version bumps or bug fixes of
> packages that are already in the tree.
> 
> 5). The project must have an active security liaison who's job it would
> be to ensure that there are no packages in the overlay that have
> outstanding vulnerabilities.
> 
> 6). The project must have an active QA liaison who's job it would be to
> ensure that *all* of the QA standards that are applied to the main tree
> are also applied to the projects overlay.
> 
> And the above is just the tip of the iceberg...but satisfy those and
> I'll give you the rest.
> 
> The next thing I'll hear is "But this is really no different then
> hosting them on Bugzilla except it lowers the bar for their use..."
> Which brings me to my next point...like it or not the lower the bar for
> their use the more generally accepted the idea that using the ebuilds in
> this overlay is "officially supported".

I would accept these steps being completed as a nice barrier for entry
for this project to start to be useful as a development tool.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] herds.xml

[Chris Gianelloni]

On Fri, 2006-06-09 at 16:19 -0400, Mike Frysinger wrote:
> On Thursday 08 June 2006 21:08, Brian Harring wrote:
> > One additional to this- the location for the file in the tree *should*
> > be metadata/ - shoving it into profiles is the wrong location (it's
> > not profile data, it's repo metadata).
> 
> that is the correct location for it but we have no metadata tree tracked in 
> cvs

How about we keep it where it is (in CVS) and simply have it added to
metadata during the normal runs before sync?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

[Stuart Herbert]

On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:

Gentoo's standard operating procedure is to build packages as they were
intended and packaged from upstream.


+1


This means if the client and the
server for a particular package is in a single package, we should build
both by default.


No thanks.  That doesn't match the standard operating procedure
mentioned above.  By default, why don't we just build whatever
$UPSTREAM intended built by default?

It means that different packages will behave differently throughout
the tree, but that's okay, and is more Gentoo-like than your proposal.


To facilitate building the client portions only, the
use of the local "minimal" USE flag is allowed.


How will you support building the server-only portions of the package?
I don't want clients I don't need on my servers.  "client" and
"server" USE flags would appear to make much more sense here (for
packages that have any such clear distinction), and will play better
when USE-based DEPs become reality.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Chris Gianelloni]

On Fri, 2006-06-09 at 14:46 -0500, James Potts wrote:
> On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote:
> > > Markus Ullmann wrote:
> > > > Maybe that way we avoid any misunderstandings, nearly doubled posts and
> > > > repeating ourselves over and over again.
> > >
> > > The problem is that some questions and answers easily get lost in a 
> > > mailing
> > > list. To solve this shortcoming, I am starting to make a FAQ page in the
> > > trac wiki:
> > > http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
> > >
> > > We are adding new questions there, if you have some additions, please talk
> > > to me and I will add them for you.
> >
> > I have one...
> >
> > What will it take for this project to go away?
> >
> I have a counter-question to this:  What modifications to the sunrise
> (not sunrice, btw) project would have to be made to get you to stop
> actively trying to shut it down?  I really don't care if you think the
> team will be willing to make the changes, list them anyway, please. :)

It needs to not be a Gentoo project and not hosted on Gentoo
infrastructure, with absolutely no support from Gentoo.

I have absolutely no problem with overlays that are for a specific
target.  I would have no problems with either of the sunrise
"maintainers" starting their own overlays in projects they manage.  I
just can't imagine a dumping ground such as this being a good idea,
ever.  It would require an enormous amount of manpower.  How exactly can
2 people possibly cover the manpower needed for this when the *entire
developer pool* cannot handle it now in bugzilla?

> I'm asking because I think that this project is a Good Thing, if it
> gets handled correctly.  I also agree that if it is not handled
> correctly it can and will be a Very Bad Thing.

Unfortunately, I don't have much faith in this possibly being handled
correctly.  There simply isn't the manpower to do it properly *and*
officially.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote:
> Huge difference between committing a few things for a person you know,
> where you have time to review code, and bulk committing random stuff
> where you don't have time to check anything. That's the deal here -- if
> a large number of developers can't handle maintainer-wanted, what makes
> people think a far smaller number can without screwing up?

*ding* *ding* *ding* *ding* *ding*

We have a winner!

What do we have for our winner, today, Dianne?

Isn't that nice, a turkey baster!

;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
[snip]
> > If someone wanted to exploit boxen he'd use a much simpler attack
> > vector ... our rsync mirrors are wide open. No need to secure the little
> > window over there when the front door is open ...
> 
> Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> that?  You can't?  What a wonder!

I don't need that ...
Look, three-step plan to hacking Gentoo boxen:

1) open a few rsync mirrors and get them into the official rotation
2) replace ebuilds on the server with your preferred rootkit installer
3) harvest all the zombies you just got 

Since not all ebuilds are signed and signing is not enforced portage
will not throw any errors if I take care  of a few things (fixing
manifests etc.). So any person running an rsync mirror has implicitly
the same level of trust as a dev.  

As for the rest of your email, I'd appreciate it if you didn't take this
so personal. There's no need to belittle or insult others to push your
agenda, it should stand on its own technical merits. 

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Portage-2.1 released

[Chris Gianelloni]

On Fri, 2006-06-09 at 21:17 +0200, Jochen Maes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Chris Gianelloni wrote:
> > On Fri, 2006-06-09 at 11:12 -0400, Alec Warner wrote:
> >> Portage-2.1 final is released,
> >>
> >> RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4]
> >>
> >>
> [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup
> >> 
> >>
> [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup
> >>  [3]http://bugs.gentoo.org/show_bug.cgi?id=115839
> >> [4]http://bugs.gentoo.org/show_bug.cgi?id=136198
> >
> > So like... should we put up a news item about this?  I think so.
> > After all, it is good PR when something as major as this happens.
> >
> indeed we should do this.

 wolf31o2 * gentoo/xml/htdocs/news/20060609-portage.xml:
Announce portage 2.1's release.

Done.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] [RFC] client/server policy for ebuilds

[Chris Gianelloni]

This is the "official" (hehe) request for comments on making a policy of
how to handle ebuilds than can be used for either client or server and
how to allow for building client-only.

The idea is quite simple.

Gentoo's standard operating procedure is to build packages as they were
intended and packaged from upstream.  This means if the client and the
server for a particular package is in a single package, we should build
both by default.  To facilitate building the client portions only, the
use of the local "minimal" USE flag is allowed.  This can be shown in
the openldap and dhcp ebuilds.  Each package which uses this flag should
document what is built when the "minimal" USE flag is in use, via
use.local.desc as it will remove any ambiguity into what is being done.
Because of this, I would request that "minimal" not become a global USE
flag, since its meaning would actually be different between some
packages, for example, "minimal" in xorg-server, that causes it to only
build the primary server, and not the secondary servers, such as DMX.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Donnie Berkholz]

Chris Gianelloni wrote:
> Since when was overlays.gentoo.org supposed to even be a service to our
> users?  As I understand it, the goal was to ease development, not to
> provide an easy method for half-working ebuilds to make it to our user's
> machines.

Our users are our biggest base of testers, and the point of overlays is
to develop and test, so of course one of the goals is to get overlays
onto users' (testers') machines. Making testing as easy as possible is
important. But it should be clear that it is testing, and if the apps
were ready for the real Portage tree, they'd be in it.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] last call for xml2 (#116346)

[Mike Frysinger]

On Thursday 08 June 2006 08:35, Roy Marples wrote:
> On Thursday 08 June 2006 11:00, Mike Frysinger wrote:
> > On Thursday 08 June 2006 02:58, Roy Marples wrote:
> > > On Wednesday 07 June 2006 12:03, Mike Frysinger wrote:
> > > > you guys have had plenty of time to do this ... so last call before i
> > > > scrub xml2 from use.desc and repoman starts complaining :P
> > >
> > > Stable samba-3.0.22 has both xml and xml2 still.
> >
> > tell it to the samba maintainers
>
> samba maintainers ^^ :P

way to join the party after everyone is already passed out

(translation: they already fixed & announced it)
-mike


pgpSSSQgl3OUv.pgp
Description: PGP signature

Re: [gentoo-dev] client+server packages - build which one?

[Mike Frysinger]

On Friday 09 June 2006 15:04, Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote:
> > On Friday 09 June 2006 14:10, Roy Marples wrote:
> > > Some packages provide both a client and a server. As such, users
> > > usually only want one or the other - and rarely both.
> >
> > Thanks to wolf31o2 for pointing out that current policy dictates that we
> > install both by default and the minimal USE flag should be used to stop
> > server only compoment from installing.
>
> Not policy (I don't think) but current accepted practice.
>
> Should this become a policy?

i dont think it should ... minimal has a very floating definition and varies 
widely based on the package
-mike


pgp70xhe57Py6.pgp
Description: PGP signature

Re: [gentoo-dev] Portage-2.1 released

[Wernfried Haas]

On Fri, Jun 09, 2006 at 01:55:44PM -0400, Alec Warner wrote:
> Wernfried Haas wrote:
> >* config files as directories enabling more flexible settings
> >management.
> 
> /etc/portage/package.mask/* fex, assuming I am remembering correctly.
> 
> Then you can maintain:
> 
> /etc/portage/package.unmask/xorg
> /etc/portage/package.unmask/paludis
> /etc/portage/package.unmask/... you get the picture?
> 

Ah, i see.
Sorry for the probably stupid question, but i couldn't find any
documentation on it (probably because most search engines don't make
much of a difference between "/etc/portage/package.unmask/" and
"/etc/portage/package.unmask" - could someone give me a hint where to
find it?

cheers,
Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org


pgp6XYwVaeCp5.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Daniel Ostrow]

On Fri, 2006-06-09 at 14:46 -0500, James Potts wrote:
> On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote:
> > > Markus Ullmann wrote:
> > > > Maybe that way we avoid any misunderstandings, nearly doubled posts and
> > > > repeating ourselves over and over again.
> > >
> > > The problem is that some questions and answers easily get lost in a 
> > > mailing
> > > list. To solve this shortcoming, I am starting to make a FAQ page in the
> > > trac wiki:
> > > http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
> > >
> > > We are adding new questions there, if you have some additions, please talk
> > > to me and I will add them for you.
> >
> > I have one...
> >
> > What will it take for this project to go away?
> >
> I have a counter-question to this:  What modifications to the sunrise
> (not sunrice, btw) project would have to be made to get you to stop
> actively trying to shut it down?  I really don't care if you think the
> team will be willing to make the changes, list them anyway, please. :)
> 
> I'm asking because I think that this project is a Good Thing, if it
> gets handled correctly.  I also agree that if it is not handled
> correctly it can and will be a Very Bad Thing.


To start with (and mind you this is just my list):

1). At least one member of the project must be familiar enough with each
of the officially supported architectures, x86, amd64, ppc, ppc64, hppa,
alpha, mips, sparc and ia64, to support any bugs which arise due to arch
specific issues. The level of knowledge must be on par with that which
is required to join any of the aforementioned arch teams. This is the
only way to ensure that arch teams do not experience a higher work load
because of this overlay's existence.

2). For a package to be added to the overlay at least one member of the
project must be familiar enough with the package that they would be
accepted into the team that would maintain the package if it were in the
mainline tree if they are not already a team member.  This is the only
way to ensure that non-arch teams do not experience a higher work load
because of this overlay's existence.

3). Teams must have the option to "opt-out" of participation. What this
would mean is if a team "opts-out" no packages may be placed in the
overlay that would be maintained by said team if the package was added
to the main tree. 

4). Packages cannot be added that are version bumps or bug fixes of
packages that are already in the tree.

5). The project must have an active security liaison who's job it would
be to ensure that there are no packages in the overlay that have
outstanding vulnerabilities.

6). The project must have an active QA liaison who's job it would be to
ensure that *all* of the QA standards that are applied to the main tree
are also applied to the projects overlay.

And the above is just the tip of the iceberg...but satisfy those and
I'll give you the rest.

The next thing I'll hear is "But this is really no different then
hosting them on Bugzilla except it lowers the bar for their use..."
Which brings me to my next point...like it or not the lower the bar for
their use the more generally accepted the idea that using the ebuilds in
this overlay is "officially supported".

--Dan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 19:41 +0200, Patrick Lauer wrote:
> > This *will* affect *every* ebuild developer.
> Maybe you don't realize that taking ebuilds for packages that are _not in 
> portage_ and providing them in a nice bundle does not affect every developer?

I'm sorry for the language, but I call bullshit.  It is painfully
obvious by your response that you've never had a library that is an
optional dependency (and one we don't --without durng configure, since
it isn't in the tree) cause a problem in one of your packages.  Allowing
libraries means it can cause breakage.  Period.

> Noone wants to push a new cvs-snapshot of glibc. That so not the point
> here.

Nobody ever said that you have to push a new glibc to cause mass
breakage.

> But having a controlled managed overlay with ebuilds that are now spread
> all across bugzilla ... that would be a good service to our users.

Since when was overlays.gentoo.org supposed to even be a service to our
users?  As I understand it, the goal was to ease development, not to
provide an easy method for half-working ebuilds to make it to our user's
machines.

> > This means it *CANNOT* be left up to a small group of developers to
> > decide without any discussion on the matter.
> So now we're a democracy where everything needs to be voted upon?

Anything this abhorrently stupid doesn't need a vote.  It should be cast
out on its complete lack of merit, alone.  Also, at no point did I ever
ask for a vote.  Don't put words in my mouth and I'll try to pretend
like I care what you say, OK?

> *sigh*
> Let's leave that debate for another day ...

You brought it up, not I.  Feel free to debate it with yourself until
you're blue in the face.

> > > Yes, now it is easier to check out the ebuilds. More users ==> better
> > > testing.
> > 
> > Except that now the developer has to do much more work to get the same
> > information, making it even less likely that he'll bother to pick up one
> > of these maintainer-wanted bugs.  
> s/the developer/I/

You're right... I had that wrong.

s/the developer/the developers/

After all, there have been quite a number of people agreeing with me.

> there are some devs that would prefer this overlay environment.
> Please don't push your personal preferences as The Right Way (tm)

Ehh.  Were you an ebuild developer, your opinion might actually count
for something when it comes to an ebuild development discussion.  By the
way, where's the GWN this week?

> > You also completely gloss over the
> > ability of a single rogue user to now compromise countless users with a
> > single commit.
> And an ebuild on bugzilla has more security?

Nope.  However, I'm also not proposing that ebuilds from bugzilla
automatically get pulled in over some magical overlay that is supposed
to fix all of the problems Gentoo's ever had with unmaintained packages.

> We're just making it easier to use these ebuilds. Also I expect the
> maintainers to keep a reasonable quality standard.

I'm glad your faith in them is so high.  My faith in *any* group this
small having the ability to watch over a large number of outside
contributors simply isn't there.

> >   Please come back once you've firmly grounded yourself in
> > the reality that we're a pretty popular distribution, and that makes
> > this project a prime target for malicious abuse.  Perhaps if you were
> > responsible for some ebuilds, you've be more cognizant of the
> > implications that a bad commit can cause our users.
> I am not responsible for ebuilds because I don't trust myself enough :-)

That's great.  I don't trust you enough, either.  ;]

> That doesn't stop me from giving out access to my server to anyone who
> has a good reason ... like the Gentoo/HURD repository or the Java
> overlay.

Well, we thank you for your immense self-sacrifice.  What this has to do
with the topic at hand, I have no idea.

> > > That differs from the 20 or so overlays maintained by users how?
> > 
> > Let's see.  They aren't on Gentoo infrastructure, which means they don't
> > give off any immediate assumption of being "official" or "supported" in
> > any way.  Hell, go back and look at Peter's response about how he would
> > use an overlay such as this only *because* it is on Gentoo
> > infrastructure.
> > 
> > So what exactly was your counter-point again?
> We have control over sunrise. And hey, if it sucks kill the project with 
> silver bullets, a stake to the heart and two pounds of garlic.

I'm locked and loaded.

> Just don't kill an idea before it is even tested ...

Why not?  What reason is there to stop me from aborting this brain-dead
monstrosity before it claims a single user casualty, let alone our
reputation?  I would have thought that your involvement in "PR" would
have you thinking better.  A reputation is something that takes years to
establish, and seconds to demolish.  You, of all people, should know
that.

> > Having an overlay such as this will tarnish Gentoo's reputation.
> No :-)
> What reputation a

Re: [gentoo-dev] herds.xml

[Mike Frysinger]

On Thursday 08 June 2006 21:08, Brian Harring wrote:
> One additional to this- the location for the file in the tree *should*
> be metadata/ - shoving it into profiles is the wrong location (it's
> not profile data, it's repo metadata).

that is the correct location for it but we have no metadata tree tracked in 
cvs
-mike


pgpZtoLv6aiaF.pgp
Description: PGP signature

[gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ

[Stefan Schweizer]

James Potts wrote:
> I do have a question:  If you're allowing just anybody who asks to
> have commit access to the repo, what guarantees can you give me that
> they won't commit something deliberately malicious or which will break
> the entire overlay to the overlay?

I have added this to the FAQ:
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq#Howareyouensuringthatthereisnob0rken/maliciuscodegettingintotheoverlay

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[James Potts]

On 6/9/06, Stefan Schweizer <[EMAIL PROTECTED]> wrote:

Markus Ullmann wrote:
> Maybe that way we avoid any misunderstandings, nearly doubled posts and
> repeating ourselves over and over again.

The problem is that some questions and answers easily get lost in a mailing
list. To solve this shortcoming, I am starting to make a FAQ page in the
trac wiki:
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

We are adding new questions there, if you have some additions, please talk
to me and I will add them for you.


I do have a question:  If you're allowing just anybody who asks to
have commit access to the repo, what guarantees can you give me that
they won't commit something deliberately malicious or which will break
the entire overlay to the overlay?

--Arek
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[James Potts]

On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:

On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote:
> Markus Ullmann wrote:
> > Maybe that way we avoid any misunderstandings, nearly doubled posts and
> > repeating ourselves over and over again.
>
> The problem is that some questions and answers easily get lost in a mailing
> list. To solve this shortcoming, I am starting to make a FAQ page in the
> trac wiki:
> http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
>
> We are adding new questions there, if you have some additions, please talk
> to me and I will add them for you.

I have one...

What will it take for this project to go away?


I have a counter-question to this:  What modifications to the sunrise
(not sunrice, btw) project would have to be made to get you to stop
actively trying to shut it down?  I really don't care if you think the
team will be willing to make the changes, list them anyway, please. :)

I'm asking because I think that this project is a Good Thing, if it
gets handled correctly.  I also agree that if it is not handled
correctly it can and will be a Very Bad Thing.

--Arek
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Stefan Schweizer]

Luis Francisco Araujo wrote:
> Fine. I highly agree on that, now my question is,
> why this needs to be officially supported?

See
"Why does this have to be on official gentoo hardware?"

http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Ciaran McCreesh]

On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer
<[EMAIL PROTECTED]> wrote:
| I'd say that it's entirely possibly for some non-dev to sneak
| malicious code into the tree as is now, just as it will be possible
| to do in an overlay.   
| 
| It's not like it's particulary difficult to have someone proxy for
| you, and let's face it, if someone is willing to do so then they
| probably can't be arsed checking that what they are committing is
| clean and nice.. I mean, I trust you, right? 

Huge difference between committing a few things for a person you know,
where you have time to review code, and bulk committing random stuff
where you don't have time to check anything. That's the deal here -- if
a large number of developers can't handle maintainer-wanted, what makes
people think a far smaller number can without screwing up?

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Donnie Berkholz]

Chris Gianelloni wrote:
> Initially, yes.  What happens once the user gets complete access to the
> repository, though?  Are we going to be keeping people from adding
> packages without bugs?

Absolutely. This is for maintainer-wanted stuff, so it should be
documented in Bugzilla and assigned to maintainer-wanted with a special
keyword to indicate it's in the overlay. The question is how to come up
with some QA tool to enforce this.

I don't find this overlay objectionable, assuming it's only used for
maintainer-wanted packages.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] client+server packages - build which one?

[Roy Marples]

On Friday 09 June 2006 20:04, Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote:
> > On Friday 09 June 2006 14:10, Roy Marples wrote:
> > > Some packages provide both a client and a server. As such, users
> > > usually only want one or the other - and rarely both.
> >
> > Thanks to wolf31o2 for pointing out that current policy dictates that we
> > install both by default and the minimal USE flag should be used to stop
> > server only compoment from installing.
>
> Not policy (I don't think) but current accepted practice.
>
> Should this become a policy?

I think so, as many packages provide such a split and it would make choosing 
flags a little easier :)

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage-2.1 released

[Jochen Maes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 11:12 -0400, Alec Warner wrote:
>> Portage-2.1 final is released,
>>
>> RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4]
>>
>>
[1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup
>> 
>>
[2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup
>>  [3]http://bugs.gentoo.org/show_bug.cgi?id=115839
>> [4]http://bugs.gentoo.org/show_bug.cgi?id=136198
>
> So like... should we put up a news item about this?  I think so.
> After all, it is good PR when something as major as this happens.
>
indeed we should do this.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEiclUMXMsRNMHhmARAqquAKCDOj/tdftL6EvPsXplSGYhQwVPnwCg8Khr
aZlG4knJs4fseveWBWispXM=
=oJwv
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] client+server packages - build which one?

[Donnie Berkholz]

Chris Gianelloni wrote:
> Not policy (I don't think) but current accepted practice.
> 
> Should this become a policy?

I'd say so, since this discussion regularly comes up again, and how we
do it is really an expression of the Gentoo philosophy and our
differences from a typical binary distribution.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Chris Gianelloni]

On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote:
> Markus Ullmann wrote:
> > Maybe that way we avoid any misunderstandings, nearly doubled posts and
> > repeating ourselves over and over again.
> 
> The problem is that some questions and answers easily get lost in a mailing
> list. To solve this shortcoming, I am starting to make a FAQ page in the
> trac wiki:
> http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
> 
> We are adding new questions there, if you have some additions, please talk
> to me and I will add them for you.

I have one...

What will it take for this project to go away?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 10:05 -0700, Donnie Berkholz wrote:
> Chris Gianelloni wrote:
> >> With an overlay: search sunrice.gentoo.org for the package (no, I don't
> >> know category/name), sync that directory (no, I'm not syncing the whole 
> >> sunrice tree), check it over, note some mistakes, compile it if I feel
> >> OK with it, it fails, I fix it - and what then? Where do I discuss the
> >> problems? How do I get my fixes to other users, considering the package
> >> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
> >> it be read? 
> 
> If the overlay were using a decent distributed SCM, you would get your
> fixes to users by posting your repository and requesting that it be
> merged in. I was under the impression that all ebuilds in this overlay
> would already have an associated bug for discussion.

Initially, yes.  What happens once the user gets complete access to the
repository, though?  Are we going to be keeping people from adding
packages without bugs?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] What is "official"?

[Kevin F. Quinn]

On Fri, 09 Jun 2006 07:50:27 -0400
Ned Ludd <[EMAIL PROTECTED]> wrote:

> Keeping it simple...
> 
> If it's hosted on gentoo infrastructure it's official.
> If it's hosted on gentooexp.org/SF/Non infra then it's not official.

I think this is the best way to define it.  Anything on Gentoo
infrastructure has to have broad support from the Gentoo community.
Anything elsewhere can do whatever it wants.

We could take a leaf from the GNU book, and register nongentoo.org if
infra wish to host stuff that is not official (c.f. savannah.gnu.org vs
savannah.nongnu.org).  Then sunrise could go on overlays.nongentoo.org

Official means supported, however supported does not necessarily mean
official.  Just because some people support something doesn't make it
"official".  For example, if a project is official, then it's not
acceptable for devs to just ignore a problem related to the
project in stuff that isn't part of the project (at the very
least the problem should be referred to the project).

What I'm getting at is that "officialness" can be thought of in terms
of the effects it has, "how does the way something official is dealt
with differ from something unofficial?".  My take is that official stuff
is something that all devs accept some level of responsibility for.
Thus official stuff is supported by the dev community as a whole. If
something isn't supported by the dev community as a whole, in that a
reasonable portion of the dev community actively discourage it, then it
shouldn't be official.  Works both ways, of course - official projects
need to make reasonable efforts not to cause pain for everyone else.

> On Fri, 2006-06-09 at 10:32 +0100, Stuart Herbert wrote:
> > Hi,
> > 
> > One of the issues that the o.g.o project has brought to a head is
> > the definition of what is "official" and what is not "official"
> > when it comes to Gentoo.  The term is already being thrown about in
> > the Project Sunrise thread; I'm sure it'll come up again in future.
> > 
> > It's an issue I think we should discuss and find an agreement on.
> > 
> > Personally, I think what makes something official or not is 100%
> > down to who does it.  I think something is official if it is done
> > by the project (where a project matches the definition in the
> > metastructure project) responsible for whatever we're applying the
> > label "official" to, then that's all that matters.

I think this delegates "officialness" too much.  I don't think a
project should encourage something that directly contadicts what is
official in a broader sense.

> > So (picking something entirely at random for an example), if the
> > Java project had an overlay somewhere (say, on
> > gentooexperimental.org), because it's their overlay, the overlay is
> > "official".  Doesn't matter where it is hosted - all that matters
> > is that it is run by the Java project.

My argument would be that the experimental overlay would not be
official for Gentoo as a whole.  For example, any problems caused by
people using stuff from the experimental overlay (such that
returning to the official tree would eliminate the problem) could be
RESOLVED/INVALID.  We come back to the same thing; how can anyone be
expected to maintain stuff against a sea of unofficial overlays?

> > Equally (because it is the hot topic of the moment), Project
> > Sunrise's overlay would be "official" because they're a Gentoo
> > project.  The way to stop them being "official" is simply to have
> > the Council pass a resolution to shut down the project.

With regards sunrise, I think a good solution would be to start it as
an unofficial project.  If in the long term it proves acceptable to the
community as a whole, it could become official.  One thing that is a
distasteful is the way sunrise is presented as a fait-accompli,
when prior discussion on this list had clearly implied (to my mind
at least) that overlays.g.o would not be used for such a thing.

> > I think the other side of the term "official" is clarifying the
> > scope of how far something can be "official".  Using the Java
> > project as an example again (sorry guys :), the Java team can put
> > in place "official" policies and procedures for what their team
> > does, but that doesn't make them mandatory for the whole Gentoo
> > project.  Other developers remain free to form competitive
> > projects, and put their own "official" policies and procedures in
> > place if they wish.
> > 
> > (I hope I explained that last bit properly.  What I'm trying to do
> > is keep in mind the terms of the metastructure document, which
> > explicitly allow for two or more teams to be competing with each
> > other).

This is about delegation, which is fine - however I don't think it's a
good idea to have two conflicting official positions.  With regards
Gentoo-wide policy

> > 
> > What are the alternatives?  If a project's activities are not
> > automatically "official", then who gets to decide, and how is that
> > decision made?  How can that decision b

Re: [gentoo-dev] client+server packages - build which one?

[Chris Gianelloni]

On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote:
> On Friday 09 June 2006 14:10, Roy Marples wrote:
> > Some packages provide both a client and a server. As such, users usually
> > only want one or the other - and rarely both.
> >
> 
> Thanks to wolf31o2 for pointing out that current policy dictates that we 
> install both by default and the minimal USE flag should be used to stop 
> server only compoment from installing.

Not policy (I don't think) but current accepted practice.

Should this become a policy?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Portage-2.1 released

[Chris Gianelloni]

On Fri, 2006-06-09 at 11:12 -0400, Alec Warner wrote:
> Portage-2.1 final is released,
> 
> RELEASE-NOTES[1]
> NEWS[2]
> BUGS-FIXED[3]
> STABLIZING BUG[4]
> 
> [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup
> [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup
> [3]http://bugs.gentoo.org/show_bug.cgi?id=115839
> [4]http://bugs.gentoo.org/show_bug.cgi?id=136198

So like... should we put up a news item about this?  I think so.  After
all, it is good PR when something as major as this happens.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Re: Project Sunrise thread -- a try of clarification

[Stefan Schweizer]

Chris Gianelloni wrote:
> Everyone that you happen to include as allowed to actually commit, you
> mean.  As opposed to "everyone that can sign themselves up for
> bugzilla"?
> 
>> It is designed to be more open and more easily fixable.
> 
> Sure.  More open then a self-registering system.  Gotcha.
> 

We actually have a FAQ entry about that. See "But there is access controls?
Why is there access controls?" on
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] client+server packages - build which one?

[Donnie Berkholz]

Chris Gianelloni wrote:
> The truth is that we don't ever want to become like the binary
> distributions.  We don't want to have to have separate
> client/server/common/devel as it removes many of the advantages that
> Gentoo has.  The default should *always* be to install the package as it
> was intended from upstream, completely intact.  Now, it has started to
> become a practice to have a "minimal" USE flag on certain packages that
> reduces the functionality to the bare client portion.  I see no real
> problem with this, so long as the default is to always build/install the
> full package.

I suppose we should get the "server" flag on cvs changed to "minimal," then.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Project Sunrice: arch team perspective

[Chris Gianelloni]

On Fri, 2006-06-09 at 15:35 +0200, Stefan Schweizer wrote:
> > It seems like genstef and jokey have completely 
> > ignored support from arch teams for this overlay.  What are you
> > proposing with respect to arch keywords and package.mask? 
> users are supported to do everything themselves in the sunrise overlay. We
> are not trying to add any additional workload to your current one. We are
> in fact trying to make life easier for everyone.

Except that you aren't accomplishing this.  I have shown lots of points
where this will increase workload on an already overworked group of
volunteers, yet the proponents of this project are either overlooking
them, avoiding them, or simply ignoring them.

> > Do you 
> > actually expect us to do anything but close assigned bugs for sunrice
> > ebuilds as WONTFIX? 
> It is more like, explain the users how to fix it themselves, because they
> can with the sunrise overlay.

...or just mark it as WONTFIX because we won't fix it.  It isn't our job
to go around policing things that are not in the portage tree.  If it
was good enough or popular enough to be of concern to us, it would be
*IN THE TREE* where it belongs.  Why is this so hard to understand?

> > Where else would these bugs go except for arch 
> > teams, seeing as we clearly can't assign them to end users who
> > originally submitted the maintainer-wanted ebuilds?
> These are not expected to be filed as bugs, they should be fixed by the
> users in question.

So now we will have random users also doing work of the architecture
team?

How about you guys start building the releases, too?  I'm sure you'll
have a wonderful time with the reiser4/broken-sources ricer crowd out
there.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] client+server packages - build which one?

[Chris Gianelloni]

On Fri, 2006-06-09 at 14:10 +0100, Roy Marples wrote:
> Some packages provide both a client and a server. As such, users usually only 
> want one or the other - and rarely both.
> 
> A good candidate is net-misc/dhcp as it installs a DHCP client and server. 
> Which makes no sense really, so I'd like to put some USE flags here to show 
> what I want, or not want to build.
> 
> A quick scan through the use flags show no real consistency, so here's what I 
> propose
> 
> USE client server
> client - just build the client - duh
> server - just build the server - duh
> client and server OR neither then build both.
> 
> Other packages to possably beneift
> udhcp
> mldonkey
> samhain
> bacula
> boxbackup
> 
> Interestingly, many packages have a server USE flag but not a client one - 
> maybe make both a global USE flag?
> 
> Good idea? Bad idea? Thoughts?

(Yeah, I know, repeating our IRC conversation.)

Bug #12499

The truth is that we don't ever want to become like the binary
distributions.  We don't want to have to have separate
client/server/common/devel as it removes many of the advantages that
Gentoo has.  The default should *always* be to install the package as it
was intended from upstream, completely intact.  Now, it has started to
become a practice to have a "minimal" USE flag on certain packages that
reduces the functionality to the bare client portion.  I see no real
problem with this, so long as the default is to always build/install the
full package.

That's my $0.02 on the matter.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Peter]

On Fri, 09 Jun 2006 14:15:01 -0400, Chris Gianelloni wrote:

Chris, I am not familiar enough about gentoo's hierarchy, politics, or
team responsibilities to question your sincerity or authority to say
something like: Sorry, but if it isn't supported, it doesn't belong on
Gentoo infrastructure.

I do think that is a pretty heavy-handed statement though. However,
authority issues aside, I would like to respond to your comments.
>> Secondly, my bias against a third party repository is perhaps
>> unwarranted. I am sure the bmg site is excellent and the people running
>> it are well-intentioned and experienced. However, that said, as a user,
>> I have a higher comfort level staying in the gentoo.realm.
> 
> Again, you are *proving* the point on why this would be bad.  It would
> be not nearly as well maintained, yet users such as yourself will have
> this rose-colored perception that "it's from Gentoo, so it must be
> good."  This is the *exact* thing that I am trying to avoid.  This will
> *not* be from Gentoo and it will *not* be good.
> 

I do not understand how ebuilds created by gentoo developers or interested
users who may have contributed via bugzilla that are hosted on o.g.o would
not be good? My perspective is primarily as a user. However, there are
several ebuilds in portage, and one eclass with my name on it. So, I feel
that I have the ability to discern between good and bad. I choose to
contribute to gentoo because I want to. Some projects will never see the
light of day. Others will. However, some bugs have a large following. And
to keep those ebuilds in limbo is unfair to those users who are interested.

>> Thirdly, the opportunity to be able to publish ebuilds that would
>> otherwise languish in bugzilla is very exciting. I think it also gives
>> the bugday people an opportunity to close out bugs. Despite what others
>> have written, having multi-year old bugs is very counter productive. If
>> something has not been fixed in so long, it probably either can't be
>> fixed, or may not even apply anymore. I know this is a generalization,
>> but if a bug was filed against gentoo 2004.3, who knows if it still
>> applies with gentoo 2006.0. Especially if there has been little or no
>> activity.
> 
> Perhaps there is no activity because the interest is not there?  Nobody
> seems to be taking this into account.
> 

That's a fair point. However, if there is no activity and no interest,
then nuke the bug. Post an announcement like they do periodically on
-devel saying "Last rites for." and see who comes forward.

> If you really think your package should be added to the tree, then add
> yourself to CC, get your friends on CC, drum up some support in the
> forums, find yourself a developer to proxy maintain for you.  We don't
> need a dumping ground for abandoned or little-use ebuilds.
> 

Done that. However, there are some packages that won't ever make it. Like
some kernel sources, java and gcc hacks, etc. I don't think the process of
committing and ebuild should be a popularity contest. I do not infer that
sunrise would be a dumping ground at all. I think that it's a very low
chance that every maintainer-wanted bug will get there, don't you?

>> Personally, I don't see the conflict, or the risk, or the additional
>> work for devs. In fact, I see the opposite. Removing maintainer-wanted
>> bugs is a net positive. If that means the proposed ebuild lives in
>> o.g.o that's fine. Just point users who see the bug over to it. And, if
>> an ebuild proves to be useful, or popular, it's conceivable that it
>> could ultimately find its way over to the main tree.
> 
> Well, I've done about as good as I can do to point out how it would be
> additional work and a major risk.  If you cannot see it, there's not
> much else I can do.  Luckily, a growing number of official developers
> *do* see the risks and are taking a stand against this egregious waste
> of time.
> 

I've had some conversations with devs personally and on irc. Most complain
about how overworked they are or how little time they have. Something like
this will remove a burden from their plates. The "risk" aspect has been
covered in other posts far more eloquently than I could (see Christel's
post for example). What WOULD be a risk is adding a profile to the main
tree with this overlay.

snip...
> 
>> Again, I think you need to consider your audience for o.g.o. The newbie
>> won't be there or be syncing to o.g.o. The server admin probably would
>> not be there either for updating a production machine. I think the main
>> audience for o.g.o. would be the power user, or the wannabe power user
>> or certain project teams, or people with a particular interest or need
>> in a project not hosted on the main tree -- that is people who actively
>> need sunrise's services.
> 
> You're absolutely right.  We need to think of the audience.  The
> overlays.gentoo.org project was touted as a way to foster the community
> and to help *developers* develop things that m

Re: [gentoo-dev] client+server packages - build which one?

[Kevin F. Quinn]

On Fri, 9 Jun 2006 14:10:51 +0100
Roy Marples <[EMAIL PROTECTED]> wrote:

> Some packages provide both a client and a server. As such, users
> usually only want one or the other - and rarely both.
> 
> A good candidate is net-misc/dhcp as it installs a DHCP client and
> server. Which makes no sense really, so I'd like to put some USE
> flags here to show what I want, or not want to build.
> 
> A quick scan through the use flags show no real consistency, so
> here's what I propose
> 
> USE client server
> client - just build the client - duh
> server - just build the server - duh
> client and server OR neither then build both.

Doing this by USE flag would cause problems I think; if other stuff
depends on the server or the client, you get USE-flag problems
with portage dependencies met but the actual dependency not met.  We
have some of this sort of thing already - which manifests with ebuilds
aborting in pkg_setup if they detect that a dependency wasn't emerged
with the necessary USE flags.

A better approach in this case, IMO, is to split it into two ebuilds -
well, three if you keep the existing package as a meta-package
depending on both client and server.  So you would have:

net-misc/dhcp-client

net-misc/dhcp-server

net-misc/dhcp - empty but for RDEPEND on the above.


A similar thing already happens with net-dns/bind and
net-dns/bind-tools, which are both built from the same upstream tarball
but one installs the server, the other installs just the client
programs.


> 
> Other packages to possably beneift
> udhcp
> mldonkey
> samhain
> bacula
> boxbackup
> 
> Interestingly, many packages have a server USE flag but not a client
> one - maybe make both a global USE flag?
> 
> Good idea? Bad idea? Thoughts?
> 
> Thanks
> 


-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 05:42 -0700, Brian Harring wrote:
> On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote:
> > On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote:
> > > > This is a bug for an ebuild that the user does not think is related to
> > > > the pam_skey.  Go back and read what I wrote.
> > > > 
> > > 
> > > it was agreed upon that we don't keep extra bugzilla or whatever for all
> > > things on o.g.o but keep track of all issues within bugs.g.o. and btw,
> > > most work on "new" bugs is done by bug wranglers and not the common
> > > devs. So if they say the workload from it is too high, I'll take it as
> > > valid reason as they have to handle it.
> > 
> > I'm sorry, but you're avoiding the question here.  How will the
> > bug-wranglers even *know* that this is related to a package in the
> > overlay?  They wouldn't.  As I ststed *repeatedly* now.  The user has
> > not mentioned that they're using pam_skey, as is a common occurrence in
> > bugs.
> 
> Curious, how will the wrangler know in general?  *cough* they won't.

I already covered this.  If you're going to be a part of the
conversation, try to keep up, will you?  *grin*

> You're using a generic arguement against a specific target- iow, apply 
> it to overlays.g.o in general instead of singling sunrise out via it.

Except the other overlays are not designed as end-user overlays.  They
are designed to aid developers.  Also, they are targeted at a specific
task/goal, as opposed to being a dumping ground for the unwanted and
unmaintained.

> Meanwhile, answer to that one is better bug data for reporting- dump 
> of (random out of the ass example) first level deps, and where they 
> came from (overlay/portdir).

I definitely agree that better bug data would help the situation.
However, it does not change the fact that this is still a dumping
ground.  Again, this was something that was *explicitly* stated that
overlays.gentoo.org would *not* become, yet here we are.

> Downside to that data is that slackers will automatically punt the bug 
> if they see non portdir in cases where it's obvious it's an issue in 
> the pkg rather then the deps, but there always is a downside...

Most people tend to not punt the bug so much as ask for proof that it
isn't caused by the overlay.  I know that we have done this in games and
it has almost always ended up as something the user has done thanks to
an overlay.  In the cases where it truly is a bug, we fix it.

> > > We're not the first large overlay project, there are other ones out
> > > there already and these "wrong" bugs aren't a new thing arising here...
> > 
> > No.  You're the first large overlay project that is on official Gentoo
> > infrastructure, even after it was agreed that there wouldn't be
> > something like this.  With the non-official projects, we simply don't
> > support any bugs from anyone using them.  It's that simple.  With this
> > project, you're vying for official status, meaning we cannot do that.
> > This will be an *enormous* time sink for the entire ebuild developer
> > pool.
> 
> Same for above re: "large overlay", realistically, like it or not the 
> general case of N overlay/repo is coming down the pipe.

Sure.  Doesn't mean I have to support anything but the one and only
official Gentoo package repository.  Complain all you want, but I became
a Gentoo developer, not a $random_repository developer for a reason.

> Personally, I'd rather see this particular case be handled from the 
> get go as an experiment- lay out from the start the exit conditions 
> for it (if it becomes a dumping ground, out she goes).

I'd rather the things that were agreed upon when the overlays project
was started were actually adhered to, instead.  I guess it is just too
much to ask from some people to keep their word.

...and people wonder why Gentoo developers don't trust each other
anymore.

> Reason?  Devs/users have been after a true testing branch/repo from 
> day one, if we're doing overlays and people are willing to try and 
> supply that demand, lets get the question answered once and for all 
> (instead of everyone and their mother shooting off about every 
> potential they can think of for why it might fail).

Fine.  Make a proposal to actually add it to the tree and do it
properly.  There's no need to have this sort of thing limited to a very
small subset of developers who couldn't *possibly* keep up with the
workload.  Yes, there will only be a few developers and they'll be
really busy, especially since they're going to be checking every commit
to ensure that there's no malicious code..

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Luis Francisco Araujo]

Chris Bainbridge wrote:

On 09/06/06, Luis Francisco Araujo <[EMAIL PROTECTED]> wrote:

Yes, i agree, writting and maintaining ebuilds is a hard and
*time-consuming* task.
So if an user can't even take the time to fix a digest, why we should
support him
officially?.


The point is that there are lots of users who are interested in niche
packages that no developers use or are interested in. These users have
the skills to write an ebuild, and other users of the package have the
skills to fix and maintain that ebuild over time. These guys don't
mind downloading ebuilds from bugzilla and fixing digests. But there
are a larger class of users of niche packages that don't have the
ebuild skills, and don't want the hassle of bugzilla and digest
fixing. This larger group of users are the ones that would benefit
from an overlay.

Fine. I highly agree on that, now my question is,
why this needs to be officially supported?
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Luis Francisco Araujo]

Chris Bainbridge wrote:

On 09/06/06, Luis Francisco Araujo <[EMAIL PROTECTED]> wrote:

Chris Bainbridge wrote:
> There are already loads of semi-official overlays. Besides the stuff
> actually hosted by gentoo (random example
> http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official
> groups (again, not picking on anyone but exampes would be java, php,
> webapps...) with semi-official overlays. I don't know if the overlays
> are actually hosted on gentoo hardware, but when they're run by gentoo
> devs, publically available, and referred to in forums, bugzilla,
> mailing lists etc. then that at least makes them "semi-official".
I don't agree with that "semi-official" term.

We for example have an overlay for the Haskell project. Nevertheless,
we consider it the official overlay for our group, but not for 
Gentoo. So

that way we can use it as our sand-box, to play with it as much as we
can, and giving commit access to even non-developers, the advantage


The Haskell overlay isn't publically available (at least, layman
doesn't know about it). That makes it quite different from the
"semi-official" overlays I gave as examples.


I really don't know what "semi-official" means.

And our overlay has always been publically available,
http://haskell.org/~gentoo/gentoo-haskell/

But we don't have it as a way to offer "extra" ebuilds. We have it
for testing, and experimental works and it has been used as playground 
for new

developers too.

Whether something is "semi-official" or not is all about perception.
If people see that a project is run by gentoo developers, possibly
formed into a gentoo group, using gentoo resources (bugzilla, forums,
mailing lists etc) to discuss and organise, then there will be a
perception that the project has some semblance of officiality.

I am not against the overlay idea, i like it very much!, and we have been
using it successfully in our team.

I just don't see the point of having another official portage tree
with maintainer-wanted packages as an overlay. Don't you see that
what you are asking for is to have another portage tree, but now,
with bunch of unmaintained and orphaned stuff, plus the extra sugar
of *dangerous* consequences as some developers have already pointed out in
this thread?

I think we already have LOT of work with only one tree.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 14:04 +0200, Stefan Schweizer wrote:
> Carsten Lohrke wrote:
> > You should at least make it visible in bold letters on the overlay.g.o
> > front page, what the conditions of each overlay are and which [EMAIL 
> > PROTECTED]
> > address bugs have to be assigned to. 
> 
> 
> Please, do not assume our users being stupid. They know that they are using
> an ebuild from the sunrise overlay with zero support. They deliberately
> typed 
> 
> "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application";
> "emerge application"

Umm... and what if they checkout the entire repository and get something
they weren't expecting?

I love how you simply just dismiss this possibility as something that
either can't happen, or something that won't happen because the users
will "know what they're doing" when they use this overlay.

> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not supposed
> to overwrite files from other ebuilds it is unlikely that they can cause
> any damage to applications that have not been directly installed from the
> overlay.

Hahahahahahahahahahahaha!!

Oh wait... Are you serious?  What if it is a library?  What if it is an
alternative to a library already in the tree?  Hrrrmn... plot thickens.

> > Also some warning that an overlay may
> > break the tree or fubar the users system 
> That is not the intention of the overlay. Everyone can help fixing breakage,
> it is not like with the current tree, where you have apps broken for a few
> days, weeks or even months because the maintainer is unreachable. With
> fixes (by users) spread all over bugzilla.

Everyone that you happen to include as allowed to actually commit, you
mean.  As opposed to "everyone that can sign themselves up for
bugzilla"?

> It is designed to be more open and more easily fixable.

Sure.  More open then a self-registering system.  Gotcha.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Daniel Ostrow]

On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
> Peper wrote:
> >>> well. A couple of examples:
> >>>
> >>> http://bugs.gentoo.org/show_bug.cgi?id=122500
> >> And again, you use my project of an example.  Perhaps you should try
> >> looking at something that actually supports your argument?
> > 
> > I think it's an example of how user-friendly is bugzilla...
> 
> Yeah, exactly... I don't understand where did this idea of me using
> someone else's own project against himself came from in the first place.
> *confused*
> 
> I've merely posted a few examples illustrating that bugzilla and
> attachments suck big time for new ebuilds' development. Or, why did you
> switch vmware-server work to SVN if bugzilla is *the* place for all
> this? Apparently it's not all that great, otherwise you wouldn't have
> done that.
> 

See you are just missing the point. He switched it to a VMware specific
SVN repo maintained by people who know VMware inside and out, otherwise
known as the VMware team. There is a HUGE difference between an overlay
with ${random_ebuilds} maintained by a small group who cannot possibly
know all of the ins and outs of every package and their impact on every
architecture and a targeted overlay for a very specific purpose which
only contains ebuilds for which the maintainers have 100% complete
understanding. Targeted overlays maintained by people who understand the
packages in question in totality == good, Catchall overlays maintained
by a few people who cannot possibly (and this isn't meant as a dig
against anyone it's just a fact) understand the implications and
interactions of *all* the packages in said overlay == BAD!

--Dan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Fri, 2006-06-09 at 07:44 -0400, Peter wrote:
> Firstly, I think it is very clear that anything in sunrise is experimental
> or not supported in the main gentoo tree. That's fine! I don't think any
> user who goes through the trouble to set up an overlay would miss that
> point. You can't go to o.g.o and not see the disclaimers. And, anyone who
> goes through the trouble to svn the overlay, edit make.conf, etc., would
> not be an ignorant newbie (no disrespect to newbies intended). Anyone who
> fetches the sunrise overlay would know exactly what he/she intends to do
> and why. Much different than emerge --sync with keyword x86.

Sorry, but if it isn't supported, it doesn't belong on Gentoo
infrastructure.

> Secondly, my bias against a third party repository is perhaps unwarranted.
> I am sure the bmg site is excellent and the people running it are
> well-intentioned and experienced. However, that said, as a user, I have a
> higher comfort level staying in the gentoo.realm.

Again, you are *proving* the point on why this would be bad.  It would
be not nearly as well maintained, yet users such as yourself will have
this rose-colored perception that "it's from Gentoo, so it must be
good."  This is the *exact* thing that I am trying to avoid.  This will
*not* be from Gentoo and it will *not* be good.

> Thirdly, the opportunity to be able to publish ebuilds that would
> otherwise languish in bugzilla is very exciting. I think it also gives the
> bugday people an opportunity to close out bugs. Despite what others have
> written, having multi-year old bugs is very counter productive. If
> something has not been fixed in so long, it probably either can't be
> fixed, or may not even apply anymore. I know this is a generalization, but
> if a bug was filed against gentoo 2004.3, who knows if it still applies
> with gentoo 2006.0. Especially if there has been little or no activity.

Perhaps there is no activity because the interest is not there?  Nobody
seems to be taking this into account.

If you really think your package should be added to the tree, then add
yourself to CC, get your friends on CC, drum up some support in the
forums, find yourself a developer to proxy maintain for you.  We don't
need a dumping ground for abandoned or little-use ebuilds.

> Personally, I don't see the conflict, or the risk, or the additional work
> for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is
> a net positive. If that means the proposed ebuild lives in o.g.o that's
> fine. Just point users who see the bug over to it. And, if an ebuild
> proves to be useful, or popular, it's conceivable that it could ultimately
> find its way over to the main tree.

Well, I've done about as good as I can do to point out how it would be
additional work and a major risk.  If you cannot see it, there's not
much else I can do.  Luckily, a growing number of official developers
*do* see the risks and are taking a stand against this egregious waste
of time.

> As for the more sinister aspects of a rogue ebuild finding its way onto
> o.g.o, sure that's a possibility. However, any dev could do the same in
> portage because they have commit access (and the problem may not be
> caught right away). Moreover, it's possible that an ebuild may be fine,
> but a particular version of a package tarball could have outright
> malicious code or an undetected security hole in it that has not been
> caught yet. That could find its way onto portage too. IMHO, I don't see
> any more risk to security in o.g.o.

Sure, a developer could be a risk, but they've gone through much more
extensive checking and testing than some user who submitted an ebuild to
a bug.

> Again, I think you need to consider your audience for o.g.o. The newbie
> won't be there or be syncing to o.g.o. The server admin probably would not
> be there either for updating a production machine. I think the main
> audience for o.g.o. would be the power user, or the wannabe power user or
> certain project teams, or people with a particular interest or need in a
> project not hosted on the main tree -- that is people who actively need
> sunrise's services.

You're absolutely right.  We need to think of the audience.  The
overlays.gentoo.org project was touted as a way to foster the community
and to help *developers* develop things that might be intrusive to the
portage tree, as well as allow for easier non-developer contributions.
It was *never* touted as a place where we would allow dumping of
half-correct, unsupported, and only marginally quality ebuilds for mass
user consumption.

> And, looking at this from a broader perspective, I see this as a real
> enhancement to gentoo. Offering an experimental tree for packages not
> intended or not wanted in the main tree. This is an added benefit, it
> demonstrates a policy of inclusion, not exclusion. It shows a willingness
> to push the envelope and give certain packages a home where they would not
> normally get one.

It also shows th

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Jakub Moc]

Peper wrote:
>>> well. A couple of examples:
>>>
>>> http://bugs.gentoo.org/show_bug.cgi?id=122500
>> And again, you use my project of an example.  Perhaps you should try
>> looking at something that actually supports your argument?
> 
> I think it's an example of how user-friendly is bugzilla...

Yeah, exactly... I don't understand where did this idea of me using
someone else's own project against himself came from in the first place.
*confused*

I've merely posted a few examples illustrating that bugzilla and
attachments suck big time for new ebuilds' development. Or, why did you
switch vmware-server work to SVN if bugzilla is *the* place for all
this? Apparently it's not all that great, otherwise you wouldn't have
done that.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] What is "official"?

[Luis Francisco Araujo]

Everything maintained by the Gentoo project, instead than for the Gentoo 
project.


Stuart Herbert wrote:

Hi,

One of the issues that the o.g.o project has brought to a head is the
definition of what is "official" and what is not "official" when it
comes to Gentoo.  The term is already being thrown about in the
Project Sunrise thread; I'm sure it'll come up again in future.

It's an issue I think we should discuss and find an agreement on.

Personally, I think what makes something official or not is 100% down
to who does it.  I think something is official if it is done by the
project (where a project matches the definition in the metastructure
project) responsible for whatever we're applying the label "official"
to, then that's all that matters.

So (picking something entirely at random for an example), if the Java
project had an overlay somewhere (say, on gentooexperimental.org),
because it's their overlay, the overlay is "official".  Doesn't matter
where it is hosted - all that matters is that it is run by the Java
project.

Equally (because it is the hot topic of the moment), Project Sunrise's
overlay would be "official" because they're a Gentoo project.  The way
to stop them being "official" is simply to have the Council pass a
resolution to shut down the project.

I think the other side of the term "official" is clarifying the scope
of how far something can be "official".  Using the Java project as an
example again (sorry guys :), the Java team can put in place
"official" policies and procedures for what their team does, but that
doesn't make them mandatory for the whole Gentoo project.  Other
developers remain free to form competitive projects, and put their own
"official" policies and procedures in place if they wish.

(I hope I explained that last bit properly.  What I'm trying to do is
keep in mind the terms of the metastructure document, which explicitly
allow for two or more teams to be competing with each other).

What are the alternatives?  If a project's activities are not
automatically "official", then who gets to decide, and how is that
decision made?  How can that decision be made fairly, without
contradicting the metastructure, and without giving rise to any
accusations of 'cabals'?

Best regards,
Stu


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Christel Dahlskjaer]

On Fri, 2006-06-09 at 02:08 +0100, Ciaran McCreesh wrote:
> On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann <[EMAIL PROTECTED]>
> wrote:
> | > No.  It clearly says that you would be doing the basic QA checks and
> | > repoman checking on initial commit.  You even said it right above
> | > where I commented!
> | 
> | You're doing some witch hunting here... I said we keep an eye on
> | non-devs commits.
> 
> How much do you want to bet that I couldn't sneak malicious code past
> you?
> 
> And if you accept that I could do it, you're also admitting that quite
> a few other random people, some of whom don't share my own ethical
> objections to such a stunt, could also pull it off given sufficient
> time and effort...

I'd say that it's entirely possibly for some non-dev to sneak malicious
code into the tree as is now, just as it will be possible to do in an
overlay.   

It's not like it's particulary difficult to have someone proxy for you,
and let's face it, if someone is willing to do so then they probably
can't be arsed checking that what they are committing is clean and
nice.. I mean, I trust you, right? 




signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Peper]

> > well. A couple of examples:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=122500
>
> And again, you use my project of an example.  Perhaps you should try
> looking at something that actually supports your argument?

I think it's an example of how user-friendly is bugzilla...

-- 
Best Regards,
Piotr Jaroszynski
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Fri, 2006-06-09 at 12:20 -0400, Chris Gianelloni wrote:
> > bugzilla sucks. Ever had to download 10 attachments for one ebuild?
> > It is a good tool for discussion, but I would prefer a simple tool (like
> > layman) that can automatically update things. You obviously don't like
> > overlays, but that shouldn't be a reason to stop us from using it. 
> 
> Well, I thank you for your vast experience as an ebuild developer in
> this matter.

My pleasure. I'd rather see myself as poweruser in this regard since I
try not to break too many ebuilds ...

> You do realize that this isn't one of those things where you can say
> that if you don't like it you don't have to use it, right?
>
> This *will* affect *every* ebuild developer.
Maybe you don't realize that taking ebuilds for packages that are _not in 
portage_ and providing them in a nice bundle does not affect every developer?
Noone wants to push a new cvs-snapshot of glibc. That so not the point
here.

But having a controlled managed overlay with ebuilds that are now spread
all across bugzilla ... that would be a good service to our users.

> This means it *CANNOT* be left up to a small group of developers to
> decide without any discussion on the matter.
So now we're a democracy where everything needs to be voted upon?
*sigh*
Let's leave that debate for another day ...

> > Yes, now it is easier to check out the ebuilds. More users ==> better
> > testing.
> 
> Except that now the developer has to do much more work to get the same
> information, making it even less likely that he'll bother to pick up one
> of these maintainer-wanted bugs.  
s/the developer/I/
there are some devs that would prefer this overlay environment.
Please don't push your personal preferences as The Right Way (tm)

> You also completely gloss over the
> ability of a single rogue user to now compromise countless users with a
> single commit.
And an ebuild on bugzilla has more security?
We're just making it easier to use these ebuilds. Also I expect the
maintainers to keep a reasonable quality standard.  
>   Please come back once you've firmly grounded yourself in
> the reality that we're a pretty popular distribution, and that makes
> this project a prime target for malicious abuse.  Perhaps if you were
> responsible for some ebuilds, you've be more cognizant of the
> implications that a bad commit can cause our users.
I am not responsible for ebuilds because I don't trust myself enough :-)
That doesn't stop me from giving out access to my server to anyone who
has a good reason ... like the Gentoo/HURD repository or the Java
overlay. 

> > That differs from the 20 or so overlays maintained by users how?
> 
> Let's see.  They aren't on Gentoo infrastructure, which means they don't
> give off any immediate assumption of being "official" or "supported" in
> any way.  Hell, go back and look at Peter's response about how he would
> use an overlay such as this only *because* it is on Gentoo
> infrastructure.
> 
> So what exactly was your counter-point again?
We have control over sunrise. And hey, if it sucks kill the project with silver 
bullets, a stake to the heart and two pounds of garlic.
Just don't kill an idea before it is even tested ...

> Having an overlay such as this will tarnish Gentoo's reputation.
No :-)
What reputation are we talking about? The distro that lags in updates
behind others?
Where you see a problem I see potential: More well-tested ebuilds,
recruiting potential developers ... if you don't want that you're an
elitist bastard. ;-)

>   We
> should not be providing *anything* that is only half-supported or
> half-tested.  Anything less than being sully supported via the security
> team and QA is a failure on the part of Gentoo.  We have enough *crap*
> in the *tree* that is unsupported, which makes us look bad, yet you want
> to insist on supporting a project that affects all of the ebuild
> developers, which you have not mentioned is a group which you are not a
> part of, so can gladly speak of increasing their workload with no
> consequences to yourself, and provides an avenue for low-quality or
> possibly malicious ebuilds to be distributed to our users, all under a
> Gentoo banner?
No :-)
1) It doesn't increase your workload - these packages are things that
are _not_ in the main tree.
No overlap --> no stupid bugs with overwritten ebuilds etc.
2) low-quality? I might mention that I'm hosting some overlays that have
non-gentoo contributors (*gasp!*)
Why are they hosted on my server? Because the contributors are not (yet)
gentoo devs, but provide good to excellent input to the projects. So now
you tell me that I'm doing wrong in helping Gentoo development? These
people can't contribute to other gentoo-hosted projects, so it is easier
to move the repositories to a more liberal server. 

That tells me that Gentoo development is fundamentally buggy when we
complain about a lack of manpower and then say "yeah, but not _that_
kind of manpower" when users try to help.

Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

[Danny van Dyk]

Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer:
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not
> supposed to overwrite files from other ebuilds it is unlikely that
> they can cause any damage to applications that have not been directly
> installed from the overlay.
Only when you have FEATURES="collision-protect".

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Chris Gianelloni]

On Fri, 2006-06-09 at 13:28 +0200, Carsten Lohrke wrote:
> > we do support it security wise, we will be reacting upon security issues.
> > We do have package.mask support in the overlay and we are going to use it.
> > The ebuilds have a quality, repoman is required to be run. Also
> > contributors should be knowing what they are doing - they are submitting an
> > ebuild to the sunrise overlay, it needs to follow certain standards.
> 
> See, I don't go over this bridge, that an overlay of arbitrary packages, with 
> varying skills and knowledge needed, can be decently controlled with very few 
> people caring and not having a security team backing you up.

I couldn't agree more.  With the entire security team, plus arch teams,
plus package maintainers, plus arch testers, it is *still* a complex job
to maintain security in the tree.  However, this group thinks that
without any backup support whatsoever, that they'll be able to maintain
the security of a project with countless contributors of varying degrees
of skill and proficiency in writing ebuilds, as well as the security of
the packages themselves.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

[Danny van Dyk]

Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer:
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not
> supposed to overwrite files from other ebuilds it is unlikely that
> they can cause any damage to applications that have not been directly
> installed from the overlay.
>
That is only true, if you have enabled FEATURES="collision-protect".

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

[Danny van Dyk]

Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer:
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not
> supposed to overwrite files from other ebuilds it is unlikely that
> they can cause any damage to applications that have not been directly
> installed from the overlay.
Only when you got FEATURES="collision-protect".

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

[Stefan Schweizer]

Markus Ullmann wrote:
> Maybe that way we avoid any misunderstandings, nearly doubled posts and
> repeating ourselves over and over again.

The problem is that some questions and answers easily get lost in a mailing
list. To solve this shortcoming, I am starting to make a FAQ page in the
trac wiki:
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

We are adding new questions there, if you have some additions, please talk
to me and I will add them for you.

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Donnie Berkholz]

Chris Gianelloni wrote:
>> With an overlay: search sunrice.gentoo.org for the package (no, I don't
>> know category/name), sync that directory (no, I'm not syncing the whole 
>> sunrice tree), check it over, note some mistakes, compile it if I feel
>> OK with it, it fails, I fix it - and what then? Where do I discuss the
>> problems? How do I get my fixes to other users, considering the package
>> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
>> it be read? 

If the overlay were using a decent distributed SCM, you would get your
fixes to users by posting your repository and requesting that it be
merged in. I was under the impression that all ebuilds in this overlay
would already have an associated bug for discussion.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 12:33 +0200, Jakub Moc wrote:
> well. A couple of examples:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=122500

And again, you use my project of an example.  Perhaps you should try
looking at something that actually supports your argument?

A subversion repository was built for this.  However, if you took the 3
seconds to *look* at the repository, you would see that it is actually
an overlay for *all* of the vmware stuff.  Then again, I guess it is
just easier to ignore the facts and use things as you wish in an attempt
to strengthen a weak argument.

Of course, this is also an example of how a repository with an actual
defined goal can bring on developers, since Mike is now a developer and
a part of the VMware team.  So again, I thank you for strengthening my
position, while attempting to support your own.  If you keep this up, I
won't even have to reply anymore.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Portage-2.1 released

[Alec Warner]

Wernfried Haas wrote:

On Fri, Jun 09, 2006 at 12:12:31PM -0400, Alec Warner wrote:


Portage-2.1 final is released,



Congrats to the portage team!

While i'm at it, may i ask which files are affected by these changes /
which docs i missed to read?
* config files as directories enabling more flexible settings
management.


/etc/portage/package.mask/* fex, assuming I am remembering correctly.

Then you can maintain:

/etc/portage/package.unmask/xorg
/etc/portage/package.unmask/paludis
/etc/portage/package.unmask/... you get the picture?



Oh, and -U has finally been killed :-)

cheers,
Wernfried



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 11:01 +0100, Edward Catmur wrote:
> > Hmmm. I think an overlay does have some advantages there ...
> 
> Advantages? With bugzilla I: search for the bug, cc myself on it,
> download the relevant files, look over them, note a style error, try to
> merge it, fix a compilation bug, re-upload the fixed ebuild and patch to
> bugzilla with a comment to the ebuild author on their mistake. When an
> update hits my inbox I can go directly to the bug...
> 
> With an overlay: search sunrice.gentoo.org for the package (no, I don't
> know category/name), sync that directory (no, I'm not syncing the whole 
> sunrice tree), check it over, note some mistakes, compile it if I feel
> OK with it, it fails, I fix it - and what then? Where do I discuss the
> problems? How do I get my fixes to other users, considering the package
> is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will
> it be read? 
> 
> This seems like *raising* the barrier to entry to me...

Thank you.  This explains my point about no longer having a definitive
place to look for things much better than I did, and from a user
point-of-view no less.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] client+server packages - build which one?

[Roy Marples]

On Friday 09 June 2006 14:10, Roy Marples wrote:
> Some packages provide both a client and a server. As such, users usually
> only want one or the other - and rarely both.
>

Thanks to wolf31o2 for pointing out that current policy dictates that we 
install both by default and the minimal USE flag should be used to stop 
server only compoment from installing.

-- 
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout, networking)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Andrew Gaffney]

Chris Gianelloni wrote:




Well, I am going to do everything within my power to stop it.  I will
not back down until this project is dead.  It really is that simple.


*golf-clap*

--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer   Installer Project

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] client+server packages - build which one?

[Luca Barbato]

Patrick McLean wrote:
>>
> finger, telnet and ssh are probably other candidates. (though not too
> many people set up boxes without a ssh server these days).
> 
> ++ to this, I have always found it a little absurd having dhcpd
> installed on my laptop just for dhclient.

dhcpcd could be a better temp solution =)

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 11:06 +0200, Jakub Moc wrote:
> The thing has been sitting in bugzilla for ages, I've asked Flameeyes to
> commit it and he said he's not going to put any mode pam stuff into the
> tree unless he's using the modules himself. Nothing wrong w/ that. So, I
> can either keep on maintaining it in my local overlay or let other
> people use it if they find it useful. I prefer the latter. pam_abl and
> pam_mount is also stuff that I'm testing/using myself. The only thing I
> haven't tested beyond "it compiles and installs" is pam_pgsql, that one
> doesn't touch system-auth at all, comes w/ commented-out .conf and so
> has no effect until the user has  configured it.

Uhh... You're a developer.  How about instead, you simply join the pam
team with Flameeyes and add these packages and maintain them yourself?

Do you really need an overlay with *countless* possibilities for other
ebuilds to maintain 4 packages?

> There are about 3 other bugs requesting pam stuff, but since that stuff
> is essentially dead upstream, it won't be in the overlay. So, are you
> asking to have a separate overlay project for 4 pam ebuilds? Heh, really
> an overkill.

No.  It is called a repository that actually has an explicit purpose.  I
guess you've missed all of the other overlays out there that are limited
to a specific scope.  The funny thing is that I *know* that you use at
least one of these external repositories, and I haven't heard you
complaining that you need to move these packages to some free-for-all
overlay such as this.  I wonder why that is?

> > Could be part of the policy to not touch existing ebuilds.
> 
> IMHO the sunrice project is a good place for maintainer-wanted/needed
> bugs. Shouldn't be a dumpspace for whatever experimental patches for
> stuff that's actually being maintained in the main tree.

It really is funny when you're arguing *for* something, yet you call it
the "sunrice" project.  Freudian slip, or an admission of truth?

> >> This is a prime example of totally glossing over any discussion to make
> >> it sound promising for you. 
> > If bugzilla wasn't so sucky people wouldn't try to use other methods of
> > communication ;-)
> 
> Erm, look at the vmware-server bug
> (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless
> for grabbing any ebuilds, there are ~350 comments and tons of obsolete,
> yet not marked as such ebuilds, that's why you switched to subversion,
> right? And it boosted the effectivity by a huge margin. Also comes w/ a
> nice side-effect of not bugspamming another 200 folks CCed on the bug
> when someone screws w/ attachments for a couple of times.

So you're going to try to use my own project as an example against me?
Great.  Bring it on.

The vmware overlay is limited to only vmware products.  When someone
uses the overlay, they *know* that they are only getting ebuilds related
to vmware.  The project sunricer overlay is for any ebuilds of any kind.
It is not focused on anything, what-so-ever, and has had many arguments
against its use for many reasons.  In the future, if you're going to try
to use someone's project as an argument against them, at least try to
come up with an argument that works.  Using a focused overlay as an
example of why a massive, bloated, free-for-all overlay should exist
isn't exactly helping your argument, but instead helps mine.  Thanks for
making my work easier. =]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Chris Gianelloni]

On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote:
> On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:
> > > You don't need a subversion client, you perhaps notice the http in front
> > > of the url.. just open it up in your browser and you get the source
> > > immediately.
> > 
> > Umm... so now I need to go and instead of clicking a nice link in
> > bugzilla, trawl through the subversion repository and find what I'm
> > looking for?  How exactly is downloading things via http any different
> > than downloading them from bugzilla, which is also http?
> just my point of view - 
> 
> bugzilla sucks. Ever had to download 10 attachments for one ebuild?
> It is a good tool for discussion, but I would prefer a simple tool (like
> layman) that can automatically update things. You obviously don't like
> overlays, but that shouldn't be a reason to stop us from using it. 

Well, I thank you for your vast experience as an ebuild developer in
this matter.

You do realize that this isn't one of those things where you can say
that if you don't like it you don't have to use it, right?

This *will* affect *every* ebuild developer.

This means it *CANNOT* be left up to a small group of developers to
decide without any discussion on the matter.

> > > Or, if you want some history like sources.g.o, you can do so as well here:
> > > http://overlays.gentoo.org/proj/sunrise/browser/
> > 
> > Excellent.  So we're moving the history from being in a single location
> > (the bug) to being in multiple locations.  That will definitely improve
> > the development process.  
> Yes, now it is easier to check out the ebuilds. More users ==> better
> testing.

Except that now the developer has to do much more work to get the same
information, making it even less likely that he'll bother to pick up one
of these maintainer-wanted bugs.  You also completely gloss over the
ability of a single rogue user to now compromise countless users with a
single commit.  Please come back once you've firmly grounded yourself in
the reality that we're a pretty popular distribution, and that makes
this project a prime target for malicious abuse.  Perhaps if you were
responsible for some ebuilds, you've be more cognizant of the
implications that a bad commit can cause our users.

> >   No offense, but everything I have seen looks
> > as if it will add even *more* overhead to actually getting packages into
> > the tree.  The only thing this seems to provide is a half-baked
> > repository for the users to get marginally-tested ebuilds for software
> > that wasn't interesting enough for inclusion in the tree.
> That differs from the 20 or so overlays maintained by users how?

Let's see.  They aren't on Gentoo infrastructure, which means they don't
give off any immediate assumption of being "official" or "supported" in
any way.  Hell, go back and look at Peter's response about how he would
use an overlay such as this only *because* it is on Gentoo
infrastructure.

So what exactly was your counter-point again?

> Honestly I'd prefer an overlay where I can marginally trust the content
> over a "foreign" repository maintained by people I don't know.

Having an overlay such as this will tarnish Gentoo's reputation.  We
should not be providing *anything* that is only half-supported or
half-tested.  Anything less than being sully supported via the security
team and QA is a failure on the part of Gentoo.  We have enough *crap*
in the *tree* that is unsupported, which makes us look bad, yet you want
to insist on supporting a project that affects all of the ebuild
developers, which you have not mentioned is a group which you are not a
part of, so can gladly speak of increasing their workload with no
consequences to yourself, and provides an avenue for low-quality or
possibly malicious ebuilds to be distributed to our users, all under a
Gentoo banner?

I seriously question your motives towards the Gentoo project.

> Hmmm ... bugzilla.
> Instead of a simple cvs up; cd /usr/local/portage/category/package I
> need to search for ALL bugs with $name in it, look which one it is,
> curse bugzilla for falling asleep again, see which attachments are
> relevant, download them, curse bugzilla for falling asleep again, copy
> them to my overlay, read the bugcomments to see if any special renaming
> or directory structure is needed ...
> 
> Hmmm. I think an overlay does have some advantages there ...

Sure.  Until I sneak in some obfuscated code as a "fix" to a "bug" and
it gets executed on your machine because the actual *developers* that
are used to maintaining this stuff and know what to look for aren't a
part of the process.

Making something easier does not make it better.  I'm sorry, but you've
yet to convince me on how your laziness is supposed to be an improvement
for the development process of Gentoo.

> > Again, read what I wrote.  I said that the developer would see "sunrise"
> > in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> > wit

Re: [gentoo-dev] Portage-2.1 released

[Wernfried Haas]

On Fri, Jun 09, 2006 at 12:12:31PM -0400, Alec Warner wrote:
> Portage-2.1 final is released,

Congrats to the portage team!

While i'm at it, may i ask which files are affected by these changes /
which docs i missed to read?
* config files as directories enabling more flexible settings
management.

Oh, and -U has finally been killed :-)

cheers,
Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org


pgpUo7w48Cw3G.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

[Carsten Lohrke]

On Friday 09 June 2006 14:04, Stefan Schweizer wrote:
> Please, do not assume our users being stupid. They know that they are using
> an ebuild from the sunrise overlay with zero support. They deliberately
> typed

You have said stupid, not me. Some won't care enough, I'm quite sure about 
that. We had such invalid bug reports occasionally in the past and I expect 
this to happen more often, the easier and more common dealing with overlays 
becomes. Regarding "zero support": Making this abslutely clear is what I miss 
looking at overlays.g.o.

> "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application";
> "emerge application"
>
> And also there are only applications from maintainer-wanted or
> maintainer-needed allowed in the overlay. Because packages are not supposed
> to overwrite files from other ebuilds it is unlikely that they can cause
> any damage to applications that have not been directly installed from the
> overlay.

maintainer-needed is imho not acceptable at all, as any dev trying to clean up 
bugs, won't know if a bug report comes from a user of the main tree ebuild or  
from your overlay.

> > Also some warning that an overlay may
> > break the tree or fubar the users system
>
> That is not the intention of the overlay.

If it were intended, it would be malicious. Even if not intended, it doesn't 
mean tree breakages won't happen. Some dev may change an eclass, without 
taking overlay ebuilds into account (and he doesn't have to), but the change 
may break all ebuilds inheriting the eclass in an overlay, leaving all the 
users of the overlay with a broken tree. And to make that clear: Eclasses in 
overlays are only "sort of" acceptable, when the same team handles the eclass 
in the the main tree, as eclasses in overlays hide the main tree eclasses.


Carsten



pgpU7l3V10Wea.pgp
Description: PGP signature

Re: [gentoo-dev] Portage-2.1 released

[Andrew Gaffney]

Alec Warner wrote:

Portage-2.1 final is released,


Is that the 4th horseman I see off in the distance?

--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer   Installer Project

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

[Carsten Lohrke]

On Friday 09 June 2006 13:44, Peter wrote:
> Secondly, my bias against a third party repository is perhaps unwarranted.
> I am sure the bmg site is excellent and the people running it are
> well-intentioned and experienced. However, that said, as a user, I have a
> higher comfort level staying in the gentoo.realm.

It's not. The problem is, that the assumption an overlays.g.o overlay of the 
sort we speak about would be better, is false.


Carsten


pgpbAFzd7YMoI.pgp
Description: PGP signature

[gentoo-dev] Portage-2.1 released

[Alec Warner]

Portage-2.1 final is released,

RELEASE-NOTES[1]
NEWS[2]
BUGS-FIXED[3]
STABLIZING BUG[4]

[1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup
[2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup
[3]http://bugs.gentoo.org/show_bug.cgi?id=115839
[4]http://bugs.gentoo.org/show_bug.cgi?id=136198
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Project Sunrice: arch team perspective

[Stuart Herbert]

On 6/9/06, Stephen P. Becker <[EMAIL PROTECTED]> wrote:

Apparently, this is not the case.  Policy for overlays.gentoo.org> stipulates 
that all bugs in overlays must use our bugzilla.


The intention of the policy is to prevent the use of third-party bug
trackers for tracking problems w/ ebuilds in overlays.  There's no
requirement that developers and users must use bugzillla to track
changes to ebuilds (which is what I believe Stefan was trying to say).

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] client+server packages - build which one?

[Patrick McLean]

Roy Marples wrote:
> USE client server
> client - just build the client - duh
> server - just build the server - duh
> client and server OR neither then build both.
> 
> Other packages to possably beneift
> udhcp
> mldonkey
> samhain
> bacula
> boxbackup
> 
finger, telnet and ssh are probably other candidates. (though not too
many people set up boxes without a ssh server these days).

++ to this, I have always found it a little absurd having dhcpd
installed on my laptop just for dhclient.

George Shapovalov wrote:
> Of course this multiplies the number of packages to support, if such 
> situation 
> is common. However the solution you describe can be considered "clean" only 
> after #2272 is finally resolved..
> https://bugs.gentoo.org/show_bug.cgi?id=2272
I doubt whether any devs would argue against USE based dependencies.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Sunrise Project -- Open questions post requirement

[Markus Ullmann]

Hi,

so as I was told that I avoid the questions regarding this project
several times now, please repost all open issues you have with this
project clearly, each in one or max two short sentences here.
I'll answer them all the same way to keep out all non-belonging stuff.

Maybe that way we avoid any misunderstandings, nearly doubled posts and
repeating ourselves over and over again.

Greetz,
Jokey



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] client+server packages - build which one?

[Alec Warner]

Roy Marples wrote:
Some packages provide both a client and a server. As such, users usually only 
want one or the other - and rarely both.


A good candidate is net-misc/dhcp as it installs a DHCP client and server. 
Which makes no sense really, so I'd like to put some USE flags here to show 
what I want, or not want to build.


A quick scan through the use flags show no real consistency, so here's what I 
propose


USE client server
client - just build the client - duh
server - just build the server - duh
client and server OR neither then build both.

Other packages to possably beneift
udhcp
mldonkey
samhain
bacula
boxbackup

Interestingly, many packages have a server USE flag but not a client one - 
maybe make both a global USE flag?


Good idea? Bad idea? Thoughts?



My thought is wait until portage-2.2_alpha where we will have default 
USE flags.  Then I can see putting client/server flags up and having 
both be default, letting the user turn off clients and servers in 
/etc/portage/package.use.



Thanks



--
gentoo-dev@gentoo.org mailing list