Re: [gentoo-dev] Anyone still maintaining dev-libs/dietlibc ?

[Daniel]

On Sat, 7 Jan 2006 10:19 am, Mike Frysinger wrote:
> On Friday 06 January 2006 16:13, Christian Heim wrote:
> > devs who contributed/touched the ebuilds:
> > - Ned Ludd <[EMAIL PROTECTED]>
> > - Mike Frysinger <[EMAIL PROTECTED]>
>
> i regret ever touching this package ... and i'm pretty sure Ned feels the
> same way

Ditto - please take it away

> ... i'm 100% uClibc now ;) 
>
> > If no one complains, I'll take this package.
>
> check with hansmi/dragonheart, but i know i dont care
> -mike
I

-- 
Daniel Black <[EMAIL PROTECTED]>
Gentoo Crypto/PPC/dev-embedded/Forensics/NetMon


pgptaR1ZHXr06.pgp
Description: PGP signature

Re: [gentoo-dev] net-proxy/squid should be demoted to ~mips

[Alin Nastac]

Mike Frysinger wrote:

>On Friday 06 January 2006 08:07, Alin Nastac wrote:
>  
>
>>Given the lack of interest manifested by mips team regarding
>>net-proxy/squid and its security bumps, I propose to remove the last
>>mips-stable version of this package - 2.5.10-r2 - marked as such by
>>hardave on September the 4th 2005.
>>
>>Objections anyone?
>>
>>
>
>any reason you felt the need to e-mail gentoo-dev ?  this is a pure 
>security/mips issue, the rest of gentoo dev could care less
>-mike
>  
>
I've already been informed about the procedure in this case.
Sorry for the hassle, I thought I should inform gentoo-dev before
breaking keywords policy.


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Anyone still maintaining dev-libs/dietlibc ?

[Michael Hanselmann]

Hello Christian

On Fri, Jan 06, 2006 at 10:13:39PM +0100, Christian Heim wrote:
> devs who contributed/touched the ebuilds:
> - Michael Hanselmann <[EMAIL PROTECTED]>

> If no one complains, I'll take this package.

I don't mind if you do that.

Greets,
Michael

-- 
Gentoo Linux Developer using m0n0wall | http://hansmi.ch/
*** Rince is [EMAIL PROTECTED] (We have Joey, we have Fun, we have 
Linux on a Sun)
-- Seen on #Debian


pgpiYBFLDmlFr.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Re: Split ebuilds for GCC

[Tomasz Mloduchowski]

Aron Griffis wrote:
> Duncan wrote: [Wed Jan 04 2006, 02:49:39PM EST]
> 
>>Forget formal logic, it still "begs the question", in that it "begs
>>that the question be asked".
> 
> 
> No, the reason you used the expression "begs the question" is because
> it sounds familiar to you.  Otherwise you would have said something
> like "brings up the question."  The fact is that "begs the question"
> is an expression with a particular meaning, and it shouldn't be
> confused with the sum of its parts.
Altough, the primary function of the language is as a means of
communication. While I must agree that 'official' meaning of 'begs the
question' is not 'brings up the question', I believe the number of
English users who understands this statement in 'brings up' meaning
exceeds the number of formalists.

English is not a standard, until somebody RFC'd it. It's evolving, we
saw the career of podcasting, I believe we will see in 20 years:

begs the question:
brings up the question. (archaic: ...)

So, why not make this linguistic debate EOT for now... and resume it
with Gentoo 2020.0 ?

Best wishes,
Tomasz Mloduchowski
- Gentoo User



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Re: Split ebuilds for GCC

[Aron Griffis]

Duncan wrote:   [Wed Jan 04 2006, 02:49:39PM EST]
> Forget formal logic, it still "begs the question", in that it "begs
> that the question be asked".

No, the reason you used the expression "begs the question" is because
it sounds familiar to you.  Otherwise you would have said something
like "brings up the question."  The fact is that "begs the question"
is an expression with a particular meaning, and it shouldn't be
confused with the sum of its parts.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer



pgpQZl3QOtvu1.pgp
Description: PGP signature

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

Duncan wrote:
> Chris Gianelloni posted <[EMAIL PROTECTED]>,
> excerpted below,  on Fri, 06 Jan 2006 14:30:28 -0500:
> 
> 
>>Perhaps a good explanation of the binpkg format would be in order to
>>give us a chance to determine what could/should be changed?
> 
> 
> As I regularly use the binpkg features on packages I've build with
> FEATURES=buildpkg, I believe I can answer this:
> 
> The format is really pretty simple.  It's a tar.bz2 (labeled as
> package-ver-r#.tbz2), with some additional data appended to the end. 
> As such, it can be handled with the usual tarball tools, save that they
> usually complain about the extra data at the end, but proceed anyway.  I
> regularly open them in mc's utar virtualfs for instance, to compare what's
> actually tarballed in one version to what's in another or to what's on my
> system.



I think a key thing that is missing is build info that is only kept on
the installed system. If we were to ever create a build server setup, we
need to be able to have multiple binpkg's of the same version depending
on differences between sub-arch, use flags, cflag differences, gcc
version differences, etc. The key one i'm after is use flags. I'm not
sure of the technical details behind it, but we need something to make
the binpkgs more useful outside of the local system. Having the ebuild
packed at the end is a great idea! I think its just time to extend the
format to include more and possibly add things for build servers.

-- 
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] Need help fixing executable stack

[Mike Frysinger]

On Friday 06 January 2006 12:30, Thomas Cort wrote:
> When emerging wxGTK-2.4.2-r4 on alpha I get a QA message about
> executable stacks ( http://bugs.gentoo.org/113119#c10 ). I read the
> GNU Stack Quickstart (
> http://gentoo.org/proj/en/hardened/gnu-stack.xml ).

well you didnt read far enough down :)
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml#doc_chap7

we are not able to qa check all arches at the moment for executable stacks due 
to toolchain limitations, alpha included ... that means dont waste your time 
trying to fix it

i've already updated portage to only warn about exec stacks on "fully 
supported" architectures, that version just has yet to be released
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] net-proxy/squid should be demoted to ~mips

[Mike Frysinger]

On Friday 06 January 2006 08:07, Alin Nastac wrote:
> Given the lack of interest manifested by mips team regarding
> net-proxy/squid and its security bumps, I propose to remove the last
> mips-stable version of this package - 2.5.10-r2 - marked as such by
> hardave on September the 4th 2005.
>
> Objections anyone?

any reason you felt the need to e-mail gentoo-dev ?  this is a pure 
security/mips issue, the rest of gentoo dev could care less
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Anyone still maintaining dev-libs/dietlibc ?

[Mike Frysinger]

On Friday 06 January 2006 16:13, Christian Heim wrote:
> devs who contributed/touched the ebuilds:
> - Ned Ludd <[EMAIL PROTECTED]>
> - Mike Frysinger <[EMAIL PROTECTED]>

i regret ever touching this package ... and i'm pretty sure Ned feels the same 
way ... i'm 100% uClibc now ;)

> If no one complains, I'll take this package.

check with hansmi/dragonheart, but i know i dont care
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Olivier Crete]

On Fri, 2006-06-01 at 09:39 -0800, Brian Harring wrote:
> On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote:
> > On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote:
> > > On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> > > 1)  Manpower. There are already 10,000 open bugs in bugzilla (and
> > > growing) without adding more.
> > 
> > This is probably the primary reason it died.  This, of course, ties in
> > greatly to #2.
> 
> Automation can reduce workload, within limits.  Fex, scripting for 
> yanking packages/deptree out of normal tree for merging into a g19 
> tree.

Baz has developed a script that would yank a subtree with the proper
deps for the original GLEP 19 effort. It wasn't that hard to do.

And the idea of having a subtree is that the backports would be done by
a specific group of developers instead of the package maintainers and
therefore not getting any more work on the other devs.

I'm not really sure why the older one died... We were pretty close to
being able to build the stages and starting to distribute it... I would
be very favorable to seeing the whole thing restarted.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Tobias Matzat (SirSeoman)

[Wernfried Haas]

On Fri, Jan 06, 2006 at 11:25:57PM +0100, Tobias Scherbaum wrote:
> Yo, Welcome Tobias!

Oh no, not another Tobias!

Welcome++

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


pgpfbXGcSDQ8z.pgp
Description: PGP signature

[gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Duncan]

Chris Gianelloni posted <[EMAIL PROTECTED]>,
excerpted below,  on Fri, 06 Jan 2006 14:30:28 -0500:

> Perhaps a good explanation of the binpkg format would be in order to
> give us a chance to determine what could/should be changed?

As I regularly use the binpkg features on packages I've build with
FEATURES=buildpkg, I believe I can answer this:

The format is really pretty simple.  It's a tar.bz2 (labeled as
package-ver-r#.tbz2), with some additional data appended to the end. 
As such, it can be handled with the usual tarball tools, save that they
usually complain about the extra data at the end, but proceed anyway.  I
regularly open them in mc's utar virtualfs for instance, to compare what's
actually tarballed in one version to what's in another or to what's on my
system.

The tarball itself consists of all the files in the fake-install image,
that would ordinarily be transferred to the live filesystem during the
qmerge step.  (Note that with FEATURES=buildpkg, rather than qmerging from
the fake-install image, portage creates the binpkg, then decompresses it
and does the merge from it, thereby testing the binpkg in the process.  If
something's wrong with the binpkg, the merge will fail right away, thereby
avoiding creating bad ones that cannot be relied upon.)

The extra data on the end includes a plain-text (not compressed) version
of the ebuild, very handy if that ebuild disappears from the tree for
some reason or to compare the ebuild from when the package was built with
the same one now in the tree.  The rest of the data tacked on is
essentially what's stored in /var/db/portage when the ebuild is actually
merged.  Keep in mind that the binpkg must contain all that info as it 
must be self-contained -- no portage tree need be available to merge from
binpkg.

All this extra data is packed using a call from portage to a data-packer,
then simply appended (not compressed into, literally appended) to the end
of the existing package-files tarball.  Again, the format is such that in
an emergency, the tarball itself can be extracted directly over the live
filesystem, replacing whatever damaged package files created the emergency
in the first place in the process.  This is in fact exactly the procedure
recommended in the README for emergency portage recovery (using a portage
binpkg retrieved from the internet, since most don't have
FEATURES=buildpkg toggled on and therefore don't have a local copy). 
Naturally, one is urged to backup make.conf or other such config files as
may be in the package, before doing such direct extraction.  The extractor
will normally complain about the extra data, but will ignore it and
perform the extraction anyway.

It's really quite a clever system.  Whoever came up with it came up with
a very good thing, in my book! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Tobias Matzat (SirSeoman)

[Tobias Scherbaum]

On Mon, 2006-01-02 at 23:00 +0100, Danny van Dyk wrote:
> Please help me to welcome Tobias Matzat aka SirSeoman who just entered
> the ranks of Gentoo Developers. Tobias is our new German GWN Translator.
> 
> He is 25 years old and lives in Trier where he studies computer science
> at the Trier University of Applied Sciences. Though he's been using
> Linux and Gentoo for several years now, he found and still find time
> playing basketball, reading a good book (especially Tolkien and Tad
> Williams) and listening to loud music.

Yo, Welcome Tobias!


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

[gentoo-dev] Re: Gentoo "Stable" Portage/Releases

[Duncan]

Chris Gianelloni posted <[EMAIL PROTECTED]>,
excerpted below,  on Fri, 06 Jan 2006 14:18:58 -0500:

> Remember that the release trees would only be security fixes.  No other
> package updates should be happening.  This would allow for companies to
> actually certify their software against "Gentoo 2006.0", for example.

Not an unreasonable proposal.  I've a couple of comments, however. 
(Naturally. =8^)

1) AFAIK, most such certification would require nailing down a bit
further, including gcc version used to compile, and CFLAGS, among other
things.  Basically, what they'd then be certifying against would be the
GRP releases.  This could mean expanding them somewhat, altho it should be
fine to build software unrelated to that being certified, and unrelated to
the necessary boot environment, from source, without destroying the
certification, and that limits the required GRP package count somewhat.

2) I was going to say that without keyword support it might be difficult
to nail down the distinction between those running current and those
running stable, but I just realized it could/should be right there in the
repository and/or profile information, as I'm sure that'll need to be
reported in emerge info, once  multi-repository gets full support.  It
/will/ be a bit of extra bug tracking for either devs or bug-wranglers or
both, as devs not wanting the work of supporting "stale" packages will,
I'm sure, still get bugs assigned that belong to the stable tree only. 
However, that should be minimal and manageable.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Need help fixing executable stack

[lnxg33k]

Thomas Cort wrote:
> When emerging wxGTK-2.4.2-r4 on alpha I get a QA message about
> executable stacks ( http://bugs.gentoo.org/113119#c10 ). I read the
> GNU Stack Quickstart (
> http://gentoo.org/proj/en/hardened/gnu-stack.xml ). However, I
> couldn't find any assembly files for wxGTK (ls -R | grep S$ only
> returns NEWS), nor could I find ENABLE_EXECUTE_STACK or TRAMPOLINE in
> any source files. Would append-flags -Wa,--noexecstack fix it, and is
> it the best fix?
> 
> -Thomas
> 
> Output of scanelf:
> # scanelf -qeR .


Hi. I was just messing with this regarding games-emu/zsnes (Bug: 117771). In my
case, they were .asm files. Perhaps that's the same. Mine was an easy fix;
scanelf reported !WX errors. RWX seems to imply, from what I've read on the
gnu-stack guide, is that actual coding needs to take place. Just like the guide
says, --noexecstack will "fix" the issue, but it's really a work around. I'd
suggest posting a bug and let someone with assembly experience take it from
there; unless of course you can patch it yourself. Pretty much regurgitating
what was in the guide, but fixing the problem in the code is the "best fix".

Btw, nice email addy ;)

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] GLEP 20 /srv - Services Home Directory Support

[Luca Barbato]

I'm thinking about adding the srvdir[1] global useflag.

Scream if I miss some discussion preventing it.

(fenice[2] will use it, that's why I'm adding it)

lu

[1] http://www.gentoo.org/proj/en/glep/glep-0020.html#implementation
[2] http://packages.gentoo.org/search/?sstring=fenice

--

Luca Barbato

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

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: Monthly Gentoo Council Reminder for January

[Duncan]

Grant Goodyear posted <[EMAIL PROTECTED]>, excerpted
below,  on Fri, 06 Jan 2006 11:10:11 -0600:

> Most of the things that people like about Gentoo have little to do with
> the underlying C library, kernel, and userland.  Instead, it's portage,
> sane configuration files, and dependency-based start-up scripts that
> tend to attract people, and as such it's not surprising that people
> would like to have all of that on a nominally *BSD-based system (for
> those people who actually do care about the underlying C library,
> kernel, and userland).
> 
> That's the practical reason.  A slightly more idealistic reason is that
> part of the Gentoo philosophy is that packages should work as portably
> as possible, and we should be a member-in-good-standing of the
> community.  The native *BSD teams have been known to patch their ports
> to work on their systems without sending their patches upstream.  We
> have a single portage tree that handles packages for all archs (and
> OSs), and our Alt teams work hard to generate patches that are (a)
> applied independent of arch/os/whatever and (b) sent upstream.  Consequently, 
> work on non-Linux actually does a fair bit to improve the entire
> community.

Clear, short, and simple.  Thanks.

I like the "good citizen" thing, but obviously, that's hardly enough to do
it, because there are so many possible "good citizen" things out there to
do, and too little time to do them all, so there has to be another reason.

You gave one, the stuff that makes Gentoo Gentoo, independent of the
underlying kernel and userland flavor.  That stimulated me to think of
another.  Testing our packages (and the stuff from upstream) on another
base system will by definition catch bugs unseen on a single
kernel/userland, thus making both Gentoo and the upstream packages (since
we submit patches upstream)  more robust.  That's /always/ going to be a
good thing!

Thanks again.  I don't believe I would have seen that particular angle on
my own, or at least not made the connection right away.  Your explanation
made it easy!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: GLEP 42 (news) Round Seven

[Duncan]

Jan Kundrát posted <[EMAIL PROTECTED]>, excerpted below,  on
Fri, 06 Jan 2006 18:02:57 +0100:

> Duncan wrote:
>> My thinking too, until I saw the portage dev (JStubbs?) mention it wasn't
>> needed.
>> 
>> I believe the thinking is that emerge --ask is basically emerge --pretend
>> with an opportunity to continue stuck on the end, thus eliminating running
>> the same command only without the --pretend again, therefore eliminating
>> running portage's dep calculation step twice, once for the pretend, then
>> again for the run.
> 
> Okay, but I'd say that Portage internals like if the the same code gets
> used by --ask and --pretend are not relevant for this GLEP. Why don't
> add a note specifying the correct behavior?

Because that code will be implemented in portage, and the portage dev
likely to implement it said it was a superfluous reference. =8^)

Still, I'd prefer it referenced just for definition's sake, but when the
portage dev says it isn't a superfluous reference, and that  particular
section is specifying portage implementation...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Anyone still maintaining dev-libs/dietlibc ?

[Christian Heim]

Is there anyone maintaining dev-libs/dietlibc ?

devs who contributed/touched the ebuilds:
- Michael Hanselmann <[EMAIL PROTECTED]>
- Mike Frysinger <[EMAIL PROTECTED]>
- Ned Ludd <[EMAIL PROTECTED]>
- Daniel Black <[EMAIL PROTECTED]>
- Michael Sterrett <[EMAIL PROTECTED]>

If no one complains, I'll take this package.

Christian

-- 
Christian Heim <[EMAIL PROTECTED]>
Gentoo Linux Developer - vserver


pgpkvUf0DSpoe.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Enterprise Future - Summary Attempt #2

[Lance Albertson]

Matthew Marlowe wrote:

> 1)  enterprise devs form their own mailing list and/or herd and spend the 
> next several
> weeks attempting to come up with a consensus on a GLEP that might 
> realistically
> address their needs.  There is no need for the details to be worked out on 
> the -dev
> ml.  Once a consensus is reached, it can be proposed and discussed on -dev 
> like
> all other GLEPS.  Note, that I think this thread can be mined for a rather 
> comprehensive
> list of issues that would need to be addressed by the GLEP.

This has already happened in the past. We got to a point, and then
people lost interest/got busy.

> 2) Other devs should probably realize that this isnt a one way street.  
> Enterprise devs
> have contributed to many other areas of gentoo and if they are dissatisfied 
> it might impact
> other areas of gentoo development.  Furthermore, as the gentoo foundation is 
> a rather
> cash poor organization, enterprise development might be a way to bring in 
> badly needed
> funds without compromising our principles or greatly increasing the overall 
> developer 
> workload.  These issues would have to be addressed by the GLEP, but this isnt 
> an issue
> that only impacts enterprise devs.

I can't tell you how many times this topic has come up between -dev and
-server (at least dozen or so). And EVERY time its come up, everyone
decided to put their $0.02 in and so we have 100 different ways to
accomplish something. History will repeat itself, it tends to do that.

> 3) It might be the consensus that there is no solution here.  We should all 
> be willing to face
> that and be willing to take the consequences if it is true. Either way, the 
> enterprise support
> aspect has been a significant source of confusion and we need to get a clear 
> and fair 
> resolution determined and communicated to the entire gentoo community within 
> the next
> few months.

The problem I foresee is that nobody will be able to decide on a final
implementation that makes everyone happy. Everyone will want their
method to be used and it'll get no where. That's kind of why I think an
outside project that has its own set of goals and management will
accomplish more of the outcome we need. Sure, we can make another TLPish
thing for server, but we'll end up waiting for months while people
decide on the GLEP(s) that it may have to achieve to finish it properly.
I'd hate to see such an outside project alienate itself from Gentoo,
rather they could offer their patches/fixes in return.

>From what I can see, Gentoo itself is really moving towards a premiere
desktop OS. Most of the goals/ideals for having a desktop ideals are
totally different than a server based one. I feel that both sides will
have too many conflicting things that will hamper development. By doing
an outside project, we can define things in portage/other areas that
won't break things for the general gentoo project. They could even
'start from scratch' and possibly fix the legacy issues right off. It
gives the enterprise group the flexibility of doing whatever they need
to do without the backlash of everyone else.

Just my thoughts on the whole situation.

-- 
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

[gentoo-dev] Gentoo Enterprise Future - Summary Attempt #2

[Matthew Marlowe]

Fellow devs,

I know this thread is getting long, but to ensure we get the right closure
I'd like to ensure that there is a consensus summary and action plan.

That said, the interpretation below is just my own, but I've tried to be
as neutral as possible given that I've been a proponent of moderate gentoo
enterprise deployments in the past.  That said, rather than responding to 
each messege as its come in, I've tried to limit my participation in the 
discussion
to about 1 email/day which I think allows the proper time for reflection on
everyone else's input.

Summary:

Thread was kicked off by a proposal to modify the gentoo organization 
structure to emphasize a 'leader' or 'central distribution vision'.  This 
generated
alot of disagreement as most devs appear to be quite happy with the current
gentoo progress and had no interest in reversing what they had seen as the
gradual 'democratization' without any compelling reason.  The experiences of
other distributions and the history with drobbins was brought up to strengthen
that argument.
At that point, the thread went off on several tangents relating to 'how come
we cant all get along', 'we need more communication', and 'yes, in fact - there
really has been lots of progress within gentoo the last few years'.  It was 
gradually
realized that the dissatisfied group was primarily composed of enterprise gentoo
proponents who had had enough of waiting for GLEP19 implementation and some
leadership that could impose some form of enterprise gentoo.
   Naturally, the non-enterprise devs didnt want to have enterprise support 
work imposed
on them or have the gentoo organizational structure significantly changed for
enterprise reasons.  Several comments were made that perhaps enterprise 
developers
should spin off their own version of gentoo, produce some code rather whining, 
and/or
just drop gentoo all together and go work for some other commercial 
distribution company
that would have the $$ and resources possible to make things happen for them.
  At that point, some of the enterprise devs had enough and decided not to 
continue
the discussion.  Others said they would put together their own proposals.

My Recommendations for Action Plan:

1)  enterprise devs form their own mailing list and/or herd and spend the next 
several
weeks attempting to come up with a consensus on a GLEP that might realistically
address their needs.  There is no need for the details to be worked out on the 
-dev
ml.  Once a consensus is reached, it can be proposed and discussed on -dev like
all other GLEPS.  Note, that I think this thread can be mined for a rather 
comprehensive
list of issues that would need to be addressed by the GLEP.

2) Other devs should probably realize that this isnt a one way street.  
Enterprise devs
have contributed to many other areas of gentoo and if they are dissatisfied it 
might impact
other areas of gentoo development.  Furthermore, as the gentoo foundation is a 
rather
cash poor organization, enterprise development might be a way to bring in badly 
needed
funds without compromising our principles or greatly increasing the overall 
developer 
workload.  These issues would have to be addressed by the GLEP, but this isnt 
an issue
that only impacts enterprise devs.

3) It might be the consensus that there is no solution here.  We should all be 
willing to face
that and be willing to take the consequences if it is true. Either way, the 
enterprise support
aspect has been a significant source of confusion and we need to get a clear 
and fair 
resolution determined and communicated to the entire gentoo community within 
the next
few months.

Regards,
MattM
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 09:39 -0800, Brian Harring wrote:
> Automation can reduce workload, within limits.  Fex, scripting for 
> yanking packages/deptree out of normal tree for merging into a g19 
> tree.

Exactly, though I am not sure GLEP19 is the right way to go anyway, as
it still put a decent additional load on ebuild developers.

> Hell, script work that needs be done, nothing has been done in that 
> direction either- again, specifics haven't been stated, so there isn't 
> anything to contribute on.

That is the primary thing my proposal aims to solve... to give people
something to work on.

> > Truthfully, for any "large" enterprise, the company will be maintaining
> > a fair number of their own packages, with custom patches and whatnot.
> > Where I work, we use Red Hat Enterprise Linux.  Why?  Because we can pay
> > for support.  That isn't the point I am going to make here, however.  We
> > also have to maintain several hundred RPM packages that either are not
> > included in RHEL or modified by us in some way.  What this means is we
> > are now in the business of maintaining a package set, using arguably
> > inferior tools versus ebuilds and portage.  The binary support in
> > portage does make it very possible to "build once, deploy everywhere"
> > quite easily.
> 
> The binary support is a bit weak- realistically, for a binpkg distro 
> based off of gentoo, it would need a bit of an enema to improve it.  
> 
> So... consider that a statement of "proposals welcome on how to 
> improve it".  Right now, since (same with ebuild support) the format 
> is effectively hardcoded into portage, it's hard to replace/make large 
> changes to binpkg format.  Abstraction work has/is underway to resolve 
> that (something that help would be appreciated on also).

Perhaps a good explanation of the binpkg format would be in order to
give us a chance to determine what could/should be changed?

-- 
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] Gentoo "Stable" Portage/Releases

[Chris Gianelloni]

First off, let me just say that this was just an idea I'd cooked up a
while back, so I am sure there's lots of holes in it for you guys to rip
apart.  Anyway, without further ado...

The proposal is quite simple insofar as it requires no changes to
portage, whatsoever (though there are possibilities to make extensions
to portage).  It introduces no new KEYWORDS and adds no load on the
current ebuild developers, other than those that wish to work on the
stable tree.

Allow me to explain.

First, there is the creation of the "release" tree.  This tree is tied
to a specific release of Gentoo Linux.  The tree is based on the release
snapshot used to build the release.  The tree consists of the highest
version stable ebuild per slot and architecture for each package.  This
means if there is no stable version of, say, vmware-player, then the
entire package is omitted.  For things like GTK+, there would be at
least 2 versions in the tree, since there are 2 slots and both are
stable on at least one architecture.  By only limiting the tree in this
manner, it can be built entirely by a script and require no manual
interactions to repair dependencies, etc.

So let's imagine that 2006.0 is rolling around.  The 2006.0 snapshot is
frozen, and the release-building begins.  This snapshot tarball is run
through our "stable" script, and a new gentoo-2006.0 CVS module is
created.  A corresponding rsync module is created for this tree.

To facilitate "enterprise" usage, we break up the releases into a
"desktop" and "server" set.  This means the current
"default-linux/$arch/2006.0" profile would be
"default-linux/$arch/2006.0/desktop" with a
"default-linux/$arch/2006.0/server" profile, also.  The stages would be
built against the "default-linux/$arch/2006.0" profile, which would have
any USE, etc. that are common between desktop and server.  During
installation, the user can choose to use either the desktop or server
profiles, or stay with the more "generic" 2006.0 profile (good for
developers, etc. that might need components of both, or want a more
minimal default set of USE flags).  The desktop and server profiles will
have a defined set of default USE flags that will benefit the most
people, similar to how the current profiles are designed to be "desktop"
profiles, to benefit the most people.

The release media has SYNC set to this rsync module.  What we would have
is SYNC="rsync://rsync.gentoo.org/gentoo-2006.0" in make.conf for this
release.  Security updates would be applied to gentoo-2006.0, so "emerge
--sync" still allows for getting package updates, as we currently do.  A
user can upgrade to 2006.1 by simply changing the SYNC setting and
updating their profile.  A simple tool could be created for this, or
portage could be extended to allow for it (emerge --distupgrade 2006.1).

The current "gentoo-x86" CVS module would be the equivalent to Slackware
or FreeBSD's -current tree.  Users that wish to participate in Gentoo
development, either via actual patches or simply by assisting in testing
new packages and filing bug reports, can use this tree with no
difference from how they operate now.  This would also allow us to get
wider testing on the release profiles before the actual release is made.

Of course, a team would need to be created to work on the gentoo-$relver
trees.  However, the trees would already exist with minimal effort on
anyone's part, allowing for an easier transition.  In the end, this
would be only marginally more work for Release Engineering, so I don't
see much argument from my project, and minimal to no extra work for any
ebuild developers working on gentoo-x86 that do not also volunteer to
work on gentoo-$relver.  Patches from gentoo-$relver would be
"upstreamed" into the gentoo-x86 tree, if they did not originate on
gentoo-x86, so the next gentoo-$relver tree would be already fixed.  

Remember that the release trees would only be security fixes.  No other
package updates should be happening.  This would allow for companies to
actually certify their software against "Gentoo 2006.0", for example.

Even with no updates going into this tree, as would be the case when it
is originally implemented, we would still have a stable, unchanging
platform for external parties to test and verify against.  They would
never be caught unaware with an apache upgrade or a gcc upgrade.  They
would upgrade to new releases when *they* choose, giving them a stable
platform to build their Gentoo systems against.  This concept also
allows for us to take "baby steps" in getting to a fully-supported set
of packages with back-ported security fixes.  Because of this, I have
specifically omitted any retention or support periods, since I think
some kind of consensus would need to be reached on that, and I would
prefer that those particular details not cloud this proposal.

Speaking hypothetically, it would even be possible to create a separate
corporate entity that pays developers to work on gentoo-$relver trees by
back-porting

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 17:19 +0100, Carsten Lohrke wrote:
> On Friday 06 January 2006 16:27, Lance Albertson wrote:
> > As seen from the discussion earlier this week, I don't think Gentoo has
> > the proper open-mindness to create a proper enterprise distro.
> 
> This has nothing to with open-mindness, but having enough people doing the 
> general maintenance of a clearly defined frozen (sub-)tree as well as 
> backports to fix vulnerabilities and other critical issues, without negative 
> effects on other Gentoo subprojects (like "I work now on GLEP 19 stuff and 
> don't care what I leave unmaintained instead."). Don't expect that 
> maintainers of packages of the current tree do backports for a GLEP 19 tree. 
> This is something the proponents would need to do themselves. You can't 
> expect a commitment of the whole developer crowd in something only a minority 
> is interested in. This doesn't mean there can't be a frozen tree within the 
> context of Gentoo or as a separate project, of course.

Exactly.  I'm finishing up my proofreading and spell-checking and should
be sending out my little idea within the hour.

-- 
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: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 09:27 -0600, Lance Albertson wrote:
> Chris Gianelloni wrote:
> > On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> > 
> >>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
> >>emerge at some point.  IMO, however, there's enough conflict with what
> >>makes Gentoo great at what it does today, that such efforts should be
> >>separate from Gentoo itself.
> > 
> > 
> > I don't disagree with you entirely, but there's nothing stopping us from
> > *also* producing a "Gentoo Enterprise Linux" distribution.
> > 
> > Like I said, I'll post my proposal, modified to fit the times, of
> > course, as soon as I get a chance (it'll take a while to write back up).
> 
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro. There are
> too many things that would get in the way of Gentoo proper to make it
> work right. I agree with Duncan that the best route is an outside
> project so that they don't have the constraints of Gentoo proper. Trying
> to inflict the ideals of an enterprise distro into Gentoo right now will
> be an uphill battle the whole way. Just look at all the comments made
> from my thread earlier. You cannot make an enterprise distro without
> focus or direction and a leader. You'll be stuck in committee decisions
> all the time.

I agree with you.  My point was that it could be done, still.  Let me
get my proposal sent out and we'll see what people think.  More than
likely, it'll be something along the lines of "great idea, now where do
we find the time/money/people/goats to do it" but we can always hope.

> Not saying its impossible, but it won't be easy.

Hopefully my proposal gives enough of a split to allow for a separate
"Enterprise" solution without alienating the current developers,
dramatically increasing their workload, or changing what Gentoo
currently is and isn't...

-- 
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: Monthly Gentoo Council Reminder for January

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jon Portnoy wrote:
| On Fri, Jan 06, 2006 at 01:37:45AM -0700, Duncan wrote:
|
|>What word to use in place of "distribution", when one wants to include the
|>BSDs and other "non-distributions" as well, other than
|>Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term?
|>
|
|
| Well we could say "meta operating system" if we wanted to be really
| stupid, or we could just admit that we don't have to make a bunch of
| anal terminology nerds happy and continue on using sane naming

Hey, we could be like Yoper and call ourselves GentooOS!

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDvrsKXVaO67S1rtsRAgWlAJ0aZu8IlPoNANBi6VeKOfr0EBHEzgCgwEuT
LYABrSmTYV3EEq6QdYJvOTo=
=FRpL
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

[Marius Mauch]

Lance Albertson wrote:

I never meant that each subproject can't have their own goals. They need
to have those of course! I was more directed that there isn't a person
in charge of all the subprojects just to keep track of them (Not
governing them). i.e. if subproject foo is working on adding feature X
to portage, then this person could make sure the portage people know
that these folks are wanting to add that feature instead of blind siding
them. Of course, if we lived in a perfect world, they would go ahead and
work together like that.


Can you give examples where this has actually been a problem?

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

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lance Albertson wrote:
| As seen from the discussion earlier this week, I don't think Gentoo has
| the proper open-mindness to create a proper enterprise distro. There are
| too many things that would get in the way of Gentoo proper to make it
| work right. I agree with Duncan that the best route is an outside
| project so that they don't have the constraints of Gentoo proper. Trying
| to inflict the ideals of an enterprise distro into Gentoo right now will
| be an uphill battle the whole way. Just look at all the comments made
| from my thread earlier. You cannot make an enterprise distro without
| focus or direction and a leader. You'll be stuck in committee decisions
| all the time.

As a couple people have alluded to, there's very little stopping anyone
from essentially creating a sub-distribution as part of a server TLP.
Particularly if it doesn't affect the work of other people if they
aren't interested, and you can get infra to agree to whatever you need.
You can treat the lead of your server TLP as this single corporate-style
leader if you want.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDvrnzXVaO67S1rtsRAhS7AJwJHeT0meNdqhSzCBgBue57wGGK2QCfcxzn
ngITehzzU+XMBrUC0z18uoM=
=Iwzg
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote:
> On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote:
> > On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> > 
> > > Probably better to iron out what y'all actually need and what the dev
> > > community is willing to put up with.
> > >
> > > Eg, would do some research into it, read the archives from last few
> > > wars over it, in general find (and address) the issues that lead to
> > > glep19 going still born.
> > 
> > The problems being:
> > 
> > 1)  Manpower. There are already 10,000 open bugs in bugzilla (and
> > growing) without adding more.
> 
> This is probably the primary reason it died.  This, of course, ties in
> greatly to #2.

Automation can reduce workload, within limits.  Fex, scripting for 
yanking packages/deptree out of normal tree for merging into a g19 
tree.

Doing it by hand is possible, but error prone- same reason we have 
ekeyword, bit harder to screw things up via ekeyword (and it's a bit 
quicker in use then loading up $EDITOR).


> > 2)  Lack of interest. Most developers aren't interested in supporting
> > "old" packages.

I tend to believe interest is there- specifically resources/manpower 
to do it.

That said, I don't think anyone has yet provided the folks who are 
interested any way to help- hell, can't even tap interested folk to 
help with maintaining the ebuild subset at this point since their is no 
subset. 

Hell, script work that needs be done, nothing has been done in that 
direction either- again, specifics haven't been stated, so there isn't 
anything to contribute on.

Not going to find people doing all the work for you, but if 
_something_ were available for people to build from I'd expect more 
folks to jump in and help.


> The only real "subset" that can easily work without dramatically 
> increasing workload is to limit to only arch rather than both arch 
> and ~arch.  This is simply because it can be scripted.

Agreed on pulling from arch.


> > 3)  The enterprise. Both of the above problems would be fixed if
> > enterprises were contributing developers and/or money. However, they
> > aren't, so why is that? The truth is most enterprises want to go to a
> > big company to buy their software. They want one homogeneous binary
> > system, not a flexible way of building packages from source, and they
> > want someone else to do it and be responsible for it.
> 
> While I don't think enterprise support is necessary to accomplish a
> stable portage tree, it certainly wouldn't hurt.

Tend to think either we wait for someone to step in and contribute 
(potentially waiting a _long_ time), or just do it.

Kind of obvious my preferred route is "just do it" ;)


> Truthfully, for any "large" enterprise, the company will be maintaining
> a fair number of their own packages, with custom patches and whatnot.
> Where I work, we use Red Hat Enterprise Linux.  Why?  Because we can pay
> for support.  That isn't the point I am going to make here, however.  We
> also have to maintain several hundred RPM packages that either are not
> included in RHEL or modified by us in some way.  What this means is we
> are now in the business of maintaining a package set, using arguably
> inferior tools versus ebuilds and portage.  The binary support in
> portage does make it very possible to "build once, deploy everywhere"
> quite easily.

The binary support is a bit weak- realistically, for a binpkg distro 
based off of gentoo, it would need a bit of an enema to improve it.  

So... consider that a statement of "proposals welcome on how to 
improve it".  Right now, since (same with ebuild support) the format 
is effectively hardcoded into portage, it's hard to replace/make large 
changes to binpkg format.  Abstraction work has/is underway to resolve 
that (something that help would be appreciated on also).

~harring


pgpz8eZVbUoZQ.pgp
Description: PGP signature

[gentoo-dev] Need help fixing executable stack

[Thomas Cort]

When emerging wxGTK-2.4.2-r4 on alpha I get a QA message about
executable stacks ( http://bugs.gentoo.org/113119#c10 ). I read the
GNU Stack Quickstart (
http://gentoo.org/proj/en/hardened/gnu-stack.xml ). However, I
couldn't find any assembly files for wxGTK (ls -R | grep S$ only
returns NEWS), nor could I find ENABLE_EXECUTE_STACK or TRAMPOLINE in
any source files. Would append-flags -Wa,--noexecstack fix it, and is
it the best fix?

-Thomas

Output of scanelf:
# scanelf -qeR .
--- --- RWX  ./build_gtk/lib/libwx_gtk-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_gl-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_canvas-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_fl-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_gizmos-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_net-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_ogl-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_plot-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_stc-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_dcsvg-2.4.so.0.1.1
--- --- RWX  ./build_gtk/lib/libwx_gtk_xrc-2.4.so.0.1.1

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

On Fri, Jan 06, 2006 at 09:27:23AM -0600, Lance Albertson wrote:
> Chris Gianelloni wrote:
> > On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> > 
> >>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
> >>emerge at some point.  IMO, however, there's enough conflict with what
> >>makes Gentoo great at what it does today, that such efforts should be
> >>separate from Gentoo itself.
> > 
> > 
> > I don't disagree with you entirely, but there's nothing stopping us from
> > *also* producing a "Gentoo Enterprise Linux" distribution.
> > 
> > Like I said, I'll post my proposal, modified to fit the times, of
> > course, as soon as I get a chance (it'll take a while to write back up).
> 
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro.

Why should gentoo do it?  While this statement likely will be twisted 
around as "gentoo developers don't want enterprise", what I'm asking 
specifically is why pulling and maintaining a subset of ebuilds is 
something that must exist within gentoo.  We *do* have projects 
external to gentoo.

Either way, 'open-mindness' bit is off- I'm mentioning this 
alternative due to the fact that it's not a matter of 'open-mindness', 
matter of interest.  Can't make folk do what they don't give a damn 
about.

> Just look at all the comments made from my thread earlier. 
> You cannot make an enterprise distro without
> focus or direction and a leader. You'll be stuck in committee decisions
> all the time.

If y'all spawn an enterprise distro of gentoo you can run it however 
you want.  Sub project or external, your stuff, your decisions- 
reaction was to y'all pushing that management structure upon gentoo as 
a whole, rather then the folk who desire it.

Meanwhile, either we can discuss glep19 specifics, or continue working 
over an issue that bluntly doesn't matter right now- management 
structure matters not if y'all don't have the basic technical reqs 
nailed down.

So can we stick tech crap at this point please?

~harring


pgp8bRh00TqAl.pgp
Description: PGP signature

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Grant Goodyear]

Grant Goodyear wrote: [Fri Jan 06 2006, 10:46:55AM CST]
> Addressing your point about Enterprise Gentoo, I think you're probably
> right about it needing focus, direction, and a leader, but that's quite
> different from needing Gentoo as a whole to have any of those.  The
> Gentoo *BSD work is a good example of how much can be done by a team 
  working on stuff that the vast majority of our devs do not care about
  at all.

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpn1Y1RdFn2P.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January

[Grant Goodyear]

Duncan wrote: [Fri Jan 06 2006, 09:15:42AM CST]
> Tell me, from someone who obviously has some FBSD experience, what
> advantages does Gentoo/FreeBSD have over the normal FreeBSD?  Why would
> someone use it who is currently using regular FreeBSD, and why are you
> spending the time?  There are obviously reasons, as you're a very
> talented person spending quite a bit of time on the project, but equally
> obviously, I'm not familiar enough with them to make a good G/FBSD
> representative, at this point.

Most of the things that people like about Gentoo have little to do with
the underlying C library, kernel, and userland.  Instead, it's portage,
sane configuration files, and dependency-based start-up scripts that
tend to attract people, and as such it's not surprising that people
would like to have all of that on a nominally *BSD-based system (for
those people who actually do care about the underlying C library,
kernel, and userland).

That's the practical reason.  A slightly more idealistic reason is that
part of the Gentoo philosophy is that packages should work as portably
as possible, and we should be a member-in-good-standing of the
community.  The native *BSD teams have been known to patch their ports
to work on their systems without sending their patches upstream.  We
have a single portage tree that handles packages for all archs (and
OSs), and our Alt teams work hard to generate patches that are (a)
applied independent of arch/os/whatever and (b) sent upstream.  Consequently, 
work on non-Linux actually does a fair bit to improve the entire
community.

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpVWVEQ7uLkQ.pgp
Description: PGP signature

[gentoo-dev] Re: Re: Re: Monthly Gentoo Council Reminder for January

[Duncan]

Grobian posted <[EMAIL PROTECTED]>, excerpted below,  on
Fri, 06 Jan 2006 16:33:46 +0100:

[reply to my question on the purpose of G/FBSD]

> You better bring this up on the gentoo-alt mailing list.  Please
> consider posting it there instead of going in a private discussion.

You sure you want my "disruption" there as well? =8^)

It's now on my todo list to subscribe and come up to speed with current
messages, before posting my own.  That and reading up on Flameeyes' blog,
as he suggested.

Does gmane happen to carry gentoo-alt?  It doesn't seem to, by any name I
could recognize as such, anyway.  If I ask for it to be added, should I
ask for address encryption (gentoo.devel isn't address encrypted on gmane,
but some lists, like the PAN lists I'm a member of, are)?  Is there an
archive anywhere that I can point to, to be added (and to read myself
before posting)?

Hmm..  as I'm looking... looks like the documentation list, which I've
been meaning to join, is on gmane.  Subscribing while I'm thinking about
it...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (news) Round Seven

[Jan Kundrát]

Duncan wrote:
> My thinking too, until I saw the portage dev (JStubbs?) mention it wasn't
> needed.
> 
> I believe the thinking is that emerge --ask is basically emerge --pretend
> with an opportunity to continue stuck on the end, thus eliminating running
> the same command only without the --pretend again, therefore eliminating
> running portage's dep calculation step twice, once for the pretend, then
> again for the run.

Okay, but I'd say that Portage internals like if the the same code gets
used by --ask and --pretend are not relevant for this GLEP. Why don't
add a note specifying the correct behavior?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: GLEP 42 (news) Round Seven

[Duncan]

Jan Kundrát posted <[EMAIL PROTECTED]>, excerpted below,  on
Fri, 06 Jan 2006 17:10:52 +0100:

> Ciaran McCreesh wrote:
>> * Removed --ask message, apparently it's superfluous.
> 
> Why? I haven't found any conclusion about that in the last thread. It
> doesn't make sense to show the message in both `emerge -p foo` and
> `emerge foo`, but not in `emerge -a foo`, IMHO.

My thinking too, until I saw the portage dev (JStubbs?) mention it wasn't
needed.

I believe the thinking is that emerge --ask is basically emerge --pretend
with an opportunity to continue stuck on the end, thus eliminating running
the same command only without the --pretend again, therefore eliminating
running portage's dep calculation step twice, once for the pretend, then
again for the run.

Looked at this way, -a automatically gets the same treatment as -p. 
Actually, -a might spit out the unread news warning twice, once as part of
the pretend output, then again as part of the regular emerge once the user
has said to continue.  In any case, it should spit it out in at least the
first instance, just as --pretend would.

So, yes, it was mentioned in (one of) the previous threads.  It was only a
small mention, however, so you might have missed it.  I might have myself,
had I not commented on -a functionality myself earlier, and was therefore
watching for discussion of that aspect in particular.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Grant Goodyear]

Lance Albertson wrote: [Fri Jan 06 2006, 09:27:23AM CST]
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro. There are
> too many things that would get in the way of Gentoo proper to make it
> work right. I agree with Duncan that the best route is an outside
> project so that they don't have the constraints of Gentoo proper. Trying
> to inflict the ideals of an enterprise distro into Gentoo right now will
> be an uphill battle the whole way. Just look at all the comments made
> from my thread earlier. You cannot make an enterprise distro without
> focus or direction and a leader. You'll be stuck in committee decisions
> all the time.

I understand that you are naturally disheartened that the discussion you
started did not end as you would have liked.  Fair enough, but I think
you should also take another look at that body of responses.  Many were,
indeed, sulky "I don't wanna leader" comments, but there were also a
number of well-written, cogently-argued replies both in favor of and
opposed to what you wrote.  All in all, I would say that the discussion
you started was a net "win" for Gentoo.  (Of course, I also happen to
disagree with your premise, so I'm biased, but I hope that I'm
open-minded enough that I would feel the same if the results had gone
the other way.)  Indeed, I suggest that this reasonably well-behaved
discussion indicates that the Gentoo community is rather open-minded
itself.

Addressing your point about Enterprise Gentoo, I think you're probably
right about it needing focus, direction, and a leader, but that's quite
different from needing Gentoo as a whole to have any of those.  The
Gentoo *BSD work is a good example of how much can be done by a team 

> Not saying its impossible, but it won't be easy.

Absolutely true.  That said, there's relatively little resistance to the
concept of Enterprise Gentoo, as far as I know.  There is substantial
resistance to anything that might add additional work to
already-overwhelmed package maintainers, however, and I believe that
the lack of an acceptable solution there is what stalled things the last
time around.

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpvosMa1rv23.pgp
Description: PGP signature

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Carsten Lohrke]

On Friday 06 January 2006 16:27, Lance Albertson wrote:
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro.

This has nothing to with open-mindness, but having enough people doing the 
general maintenance of a clearly defined frozen (sub-)tree as well as 
backports to fix vulnerabilities and other critical issues, without negative 
effects on other Gentoo subprojects (like "I work now on GLEP 19 stuff and 
don't care what I leave unmaintained instead."). Don't expect that 
maintainers of packages of the current tree do backports for a GLEP 19 tree. 
This is something the proponents would need to do themselves. You can't 
expect a commitment of the whole developer crowd in something only a minority 
is interested in. This doesn't mean there can't be a frozen tree within the 
context of Gentoo or as a separate project, of course.


Carsten


pgpMv2GjOlXIr.pgp
Description: PGP signature

Re: [gentoo-dev] GLEP 42 (news) Round Seven

[Jan Kundrát]

Ciaran McCreesh wrote:
> * Removed --ask message, apparently it's superfluous.

Why? I haven't found any conclusion about that in the last thread. It
doesn't make sense to show the message in both `emerge -p foo` and
`emerge foo`, but not in `emerge -a foo`, IMHO.

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January

[Jon Portnoy]

On Fri, Jan 06, 2006 at 08:15:42AM -0700, Duncan wrote:
> 
> Tell me, from someone who obviously has some FBSD experience, what
> advantages does Gentoo/FreeBSD have over the normal FreeBSD?  Why would
> someone use it who is currently using regular FreeBSD, and why are you
> spending the time?  There are obviously reasons, as you're a very
> talented person spending quite a bit of time on the project, but equally
> obviously, I'm not familiar enough with them to make a good G/FBSD
> representative, at this point.
> 

I'll probably be using it sometime soon because ports is archaic at best

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January

[Grobian]

You better bring this up on the gentoo-alt mailing list.  Please
consider posting it there instead of going in a private discussion.

On 06-01-2006 08:15:42 -0700, Duncan wrote:
> And I definitely wish you well in your G/FBSD efforts, but when I
> mentioned them on my local ISP's unix (*ix) group, the FBSD groupies
> reaction was  "Yuck!"
> 
> Tell me, from someone who obviously has some FBSD experience, what
> advantages does Gentoo/FreeBSD have over the normal FreeBSD?  Why would
> someone use it who is currently using regular FreeBSD, and why are you
> spending the time?  There are obviously reasons, as you're a very
> talented person spending quite a bit of time on the project, but equally
> obviously, I'm not familiar enough with them to make a good G/FBSD
> representative, at this point.
> 
> (If you like and don't consider this topical for the list or thread, mail
> me.  If I have the question, however, it's possible others do as well,
> and just haven't asked, so maybe it is worth keeping to the list. 
> Whatever.  /I'm/ interested, anyway.)
> 
> TIA

-- 
Fabian Groffen
Gentoo/Alt
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

Chris Gianelloni wrote:
> On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> 
>>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
>>emerge at some point.  IMO, however, there's enough conflict with what
>>makes Gentoo great at what it does today, that such efforts should be
>>separate from Gentoo itself.
> 
> 
> I don't disagree with you entirely, but there's nothing stopping us from
> *also* producing a "Gentoo Enterprise Linux" distribution.
> 
> Like I said, I'll post my proposal, modified to fit the times, of
> course, as soon as I get a chance (it'll take a while to write back up).

As seen from the discussion earlier this week, I don't think Gentoo has
the proper open-mindness to create a proper enterprise distro. There are
too many things that would get in the way of Gentoo proper to make it
work right. I agree with Duncan that the best route is an outside
project so that they don't have the constraints of Gentoo proper. Trying
to inflict the ideals of an enterprise distro into Gentoo right now will
be an uphill battle the whole way. Just look at all the comments made
from my thread earlier. You cannot make an enterprise distro without
focus or direction and a leader. You'll be stuck in committee decisions
all the time.

Not saying its impossible, but it won't be easy.

-- 
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] Re: Re: Monthly Gentoo Council Reminder for January

[Diego 'Flameeyes' Pettenò]

On Friday 06 January 2006 16:15, Duncan wrote:
> And I definitely wish you well in your G/FBSD efforts, but when I
> mentioned them on my local ISP's unix (*ix) group, the FBSD groupies
> reaction was  "Yuck!"
Same for FreeBSD devs that tries to hinder us. But why? They think to be the 
keeper of The Only Truth? Well the "bsd is dying" joke born for that reason.
Check on my blog if you want to know why I continue working on this and I 
continue thinking it's a good way to _improve_ software. Might not have, 
right now, any appeal to sysadmins, but it has some advantages (and some 
drawbacks, as everything), and I like the improvements.
But this is not the place to discute this.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpQBx4J8HqEg.pgp
Description: PGP signature

[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January

[Duncan]

Diego 'Flameeyes' Pettenò posted
<[EMAIL PROTECTED]>, excerpted below, 
on Fri, 06 Jan 2006 12:23:52 +0100:

> On Friday 06 January 2006 09:37, Duncan wrote:
>> Well, for that matter, "distribution" is considered at least by my *BSD
>> friends, to be a peculiarly Linux term.  From their perspective, Linux has
>> 1001 "distributions", but they only have the one *BSD they choose to use.
> That's what we started changing. Gentoo/FreeBSD is by all means a FreeBSD 
> distribution (actually, PC-BSD started this a bit before of us).
> We didn't fork it to change the base system, we use FreeBSD basesystem and 
> portage, so it's not like others BSD.

And I definitely wish you well in your G/FBSD efforts, but when I
mentioned them on my local ISP's unix (*ix) group, the FBSD groupies
reaction was  "Yuck!"

Tell me, from someone who obviously has some FBSD experience, what
advantages does Gentoo/FreeBSD have over the normal FreeBSD?  Why would
someone use it who is currently using regular FreeBSD, and why are you
spending the time?  There are obviously reasons, as you're a very
talented person spending quite a bit of time on the project, but equally
obviously, I'm not familiar enough with them to make a good G/FBSD
representative, at this point.

(If you like and don't consider this topical for the list or thread, mail
me.  If I have the question, however, it's possible others do as well,
and just haven't asked, so maybe it is worth keeping to the list. 
Whatever.  /I'm/ interested, anyway.)

TIA

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
> emerge at some point.  IMO, however, there's enough conflict with what
> makes Gentoo great at what it does today, that such efforts should be
> separate from Gentoo itself.

I don't disagree with you entirely, but there's nothing stopping us from
*also* producing a "Gentoo Enterprise Linux" distribution.

Like I said, I'll post my proposal, modified to fit the times, of
course, as soon as I get a chance (it'll take a while to write back up).

-- 
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] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote:
> On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> 
> > Probably better to iron out what y'all actually need and what the dev
> > community is willing to put up with.
> >
> > Eg, would do some research into it, read the archives from last few
> > wars over it, in general find (and address) the issues that lead to
> > glep19 going still born.
> 
> The problems being:
> 
> 1)  Manpower. There are already 10,000 open bugs in bugzilla (and
> growing) without adding more.

This is probably the primary reason it died.  This, of course, ties in
greatly to #2.

> 2)  Lack of interest. Most developers aren't interested in supporting
> "old" packages.

Again, another of the issues.  Another problem was the insistence on
using some form of subset of the tree.  Using a subset of the tree
actually *increases* the workload rather than reduces it.  The only real
"subset" that can easily work without dramatically increasing workload
is to limit to only arch rather than both arch and ~arch.  This is
simply because it can be scripted.

> 3)  The enterprise. Both of the above problems would be fixed if
> enterprises were contributing developers and/or money. However, they
> aren't, so why is that? The truth is most enterprises want to go to a
> big company to buy their software. They want one homogeneous binary
> system, not a flexible way of building packages from source, and they
> want someone else to do it and be responsible for it.

While I don't think enterprise support is necessary to accomplish a
stable portage tree, it certainly wouldn't hurt.

Truthfully, for any "large" enterprise, the company will be maintaining
a fair number of their own packages, with custom patches and whatnot.
Where I work, we use Red Hat Enterprise Linux.  Why?  Because we can pay
for support.  That isn't the point I am going to make here, however.  We
also have to maintain several hundred RPM packages that either are not
included in RHEL or modified by us in some way.  What this means is we
are now in the business of maintaining a package set, using arguably
inferior tools versus ebuilds and portage.  The binary support in
portage does make it very possible to "build once, deploy everywhere"
quite easily.

> Look at the arch/~arch split - as a guideline ebuilds are supposed to
> move from ~arch -> arch after some reasonable period of time with no
> bugs reported (eg. 30 days). Yet as the friendly script shows us,
> there are many ebuilds that that stuck in ~arch for a long long time.
> Why? The main reason is developer interest - a lot of people only run
> ~arch, so the motivation is reduced. It's difficult for users to help
> - in the end it's easier to mark stuff ~arch in
> /etc/portage/package.keywords than to file a bug requesting that some
> developer test and change the ebuild. Proper testing of a tree
> requires developers to run both arch and ~arch. The stable proposals
> would add yet another tree to test.

The current stable proposals do, yes.

I'll post up my proposal (in another email), which I believe I had given
a couple years ago, somewhere around when GLEP19 was introduced.  Given
it has been a while, I can't say for certain exactly what order anything
came about in, so I won't even try.

> The only way I can see to solve these problems is more automation.
> Link bugs directly to individual versions (or sets) of ebuilds. Have a
> defined process for marking stuff stable - either x days with no bugs,
> and/or through sampling of users installed packages to see what is
> actually installed out there. Bug voting would fix the disconnect
> between users and devs (sometimes people are interested in working on
> a random problem to help gentoo - at the moment it's difficult to see
> which bugs are really the important ones to users). Decentralise
> development - allow users to share their own patches in a searchable
> system, rather than force everything through bugzilla; add support to
> portage to utilise other peoples trees - the current system of devs
> publishing overlays on their web pages/svn and users having to
> manually wget or svn up is too difficult for users and removes ebuilds
> from the tree - so they are less visible and get less testing. For QA
> gentoo really needs a compile farm with automated compile, install and
> test (from those ebuilds that support it).  Make the system smarter,
> instead of throwing more people at the problem.

All of these solutions I think are good period, not just to be for some
"enterprise" usage, especially multiple repositories (it's coming, yay!)
and automated build systems.

-- 
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] last rites - x11-misc/bbapm

[Jakub Moc]

Try #2, following the suggestion in 
http://bugs.gentoo.org/show_bug.cgi?id=20201#c11

x11-misc/bbapm: Bug 20201, segfaults, last release 6 years ago (a.k.a. dead
as a nail in the lamp-room door)

Unless someone steps up, it'll be package masked in two weeks and removed from 
portage.

-- 
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 ;)




pgpIjwuRDEgJE.pgp
Description: PGP signature

[gentoo-dev] net-proxy/squid should be demoted to ~mips

[Alin Nastac]

Given the lack of interest manifested by mips team regarding
net-proxy/squid and its security bumps, I propose to remove the last
mips-stable version of this package - 2.5.10-r2 - marked as such by
hardave on September the 4th 2005.

Objections anyone?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

[Diego 'Flameeyes' Pettenò]

On Friday 06 January 2006 09:37, Duncan wrote:
> Well, for that matter, "distribution" is considered at least by my *BSD
> friends, to be a peculiarly Linux term.  From their perspective, Linux has
> 1001 "distributions", but they only have the one *BSD they choose to use.
That's what we started changing. Gentoo/FreeBSD is by all means a FreeBSD 
distribution (actually, PC-BSD started this a bit before of us).
We didn't fork it to change the base system, we use FreeBSD basesystem and 
portage, so it's not like others BSD.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgp49E4a6O4La.pgp
Description: PGP signature

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Thu, 2006-01-05 at 23:23 -0500, Philip Webb wrote:
> After reading -- quickly -- this thread for a day or two,
> to see what Gentoo devs are thinking, I'm surprised
> anyone has been taking this rubbish seriously enough to reply at length.
> The final line suggests the writer has no serious interest in Gentoo.
I'd say the writer has an interest in Gentoo that does not fully overlap
with what has happened lately and wants to see things move
differently ...

> "Appoint one person to lead": the Germans did that back in 1933
> -- as did the French in 1799, the Russians in 1917 & the Chinese in 1949 --
dude ... like ... y'know ... the americans have one of those, too?
That was a really unneeded comment.

> & we have had a long time to reflect on the kind of thing which results.
... but still haven't learned much yet I think

> The community which achieved the most with the least in human history
> was ancient Athens, which was even less directed than Gentoo.
How about the Mongols or Turks? Atlantis? 

> Democracy ?  Consensus ?  Co-operative efforts ?  Rational discussion ?
> Apparently they are of no interest to the OP.
hmmm?
> As soon as anyone starts to order Gentoo devs to do anything,
> they will leave & not come back & the project really will die a prompt death.
> What makes it work is precisely "arguing among ourselves".
Inefficient. The collective demands to assimilate your individuality.


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


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

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

[Jon Portnoy]

On Fri, Jan 06, 2006 at 01:37:45AM -0700, Duncan wrote:
> 
> What word to use in place of "distribution", when one wants to include the
> BSDs and other "non-distributions" as well, other than
> Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term?
> 

Well we could say "meta operating system" if we wanted to be really 
stupid, or we could just admit that we don't have to make a bunch of 
anal terminology nerds happy and continue on using sane naming

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Duncan]

Chris Bainbridge posted <[EMAIL PROTECTED]>,
excerpted below,  on Fri, 06 Jan 2006 09:00:59 +:

> The problems being:
> 
> 1)  Manpower. There are already 10,000 open bugs in bugzilla (and
> growing) without adding more.
> 2)  Lack of interest. Most developers aren't interested in supporting
> "old" packages.
> 3)  The enterprise. Both of the above problems would be fixed if
> enterprises were contributing developers and/or money. However, they
> aren't, so why is that? The truth is most enterprises want to go to a
> big company to buy their software. They want one homogeneous binary
> system, not a flexible way of building packages from source, and they
> want someone else to do it and be responsible for it.

> The only way I can see to solve these problems is more automation. []
> For QA gentoo really needs a compile farm with automated compile,
> install and test (from those ebuilds that support it).  Make the system
> smarter, instead of throwing more people at the problem.

You didn't say it, but it should be self-evident.  The automation solution
is tied to money, which, ultimately, comes back to #3.

I know it's been said before, but really, Gentoo doesn't seem to fit the
enterprise  mold well enough to get the enterprise money.  There are
better fitting organizations out there, that require less direct
modificatiion to get them into the enterprise mold, so /they/ get the
enterprise money.  I know some disagree with this and think Gentoo should
be specifically targeting the enterprise, but IMO, that's not Gentoo's
niche and never will be.

OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
emerge at some point.  IMO, however, there's enough conflict with what
makes Gentoo great at what it does today, that such efforts should be
separate from Gentoo itself.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Bainbridge]

On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote:

> Probably better to iron out what y'all actually need and what the dev
> community is willing to put up with.
>
> Eg, would do some research into it, read the archives from last few
> wars over it, in general find (and address) the issues that lead to
> glep19 going still born.

The problems being:

1)  Manpower. There are already 10,000 open bugs in bugzilla (and
growing) without adding more.
2)  Lack of interest. Most developers aren't interested in supporting
"old" packages.
3)  The enterprise. Both of the above problems would be fixed if
enterprises were contributing developers and/or money. However, they
aren't, so why is that? The truth is most enterprises want to go to a
big company to buy their software. They want one homogeneous binary
system, not a flexible way of building packages from source, and they
want someone else to do it and be responsible for it.

Look at the arch/~arch split - as a guideline ebuilds are supposed to
move from ~arch -> arch after some reasonable period of time with no
bugs reported (eg. 30 days). Yet as the friendly script shows us,
there are many ebuilds that that stuck in ~arch for a long long time.
Why? The main reason is developer interest - a lot of people only run
~arch, so the motivation is reduced. It's difficult for users to help
- in the end it's easier to mark stuff ~arch in
/etc/portage/package.keywords than to file a bug requesting that some
developer test and change the ebuild. Proper testing of a tree
requires developers to run both arch and ~arch. The stable proposals
would add yet another tree to test.

The only way I can see to solve these problems is more automation.
Link bugs directly to individual versions (or sets) of ebuilds. Have a
defined process for marking stuff stable - either x days with no bugs,
and/or through sampling of users installed packages to see what is
actually installed out there. Bug voting would fix the disconnect
between users and devs (sometimes people are interested in working on
a random problem to help gentoo - at the moment it's difficult to see
which bugs are really the important ones to users). Decentralise
development - allow users to share their own patches in a searchable
system, rather than force everything through bugzilla; add support to
portage to utilise other peoples trees - the current system of devs
publishing overlays on their web pages/svn and users having to
manually wget or svn up is too difficult for users and removes ebuilds
from the tree - so they are less visible and get less testing. For QA
gentoo really needs a compile farm with automated compile, install and
test (from those ebuilds that support it).  Make the system smarter,
instead of throwing more people at the problem.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Monthly Gentoo Council Reminder for January

[Duncan]

Carsten Lohrke posted <[EMAIL PROTECTED]>, excerpted
below,  on Thu, 05 Jan 2006 20:30:27 +0100:

> On Thursday 05 January 2006 16:46, Diego 'Flameeyes' Pettenò wrote:
>> Yeah ok, let me end up these holidays, and I'll prepare a written request
>> to change the Linux part in something else
> 
> You should also contact the folks working on the gentoo.org redesign. While 
> there was a bit of fuss about the infinity symbol, I always wondered why no 
> one lost a word against the "Linux" below, given that we claim to provide a 
> meta-distribution.

Well, for that matter, "distribution" is considered at least by my *BSD
friends, to be a peculiarly Linux term.  From their perspective, Linux has
1001 "distributions", but they only have the one *BSD they choose to use. 
They don't consider BSD fragmented, even with multiple "distributions" as
it were, because each BSD is its own thing, yet at the same time, no Linux
is its own thing, it's fragmented into 1001 "distributions".

So, while Gentoo is certainly more than Linux, even maintaining the
"metadistribution" term in the definition, will be the same thing as
keeping the "Linux", from the viewpoint of the many tending toward the BSD
side of the FLOSS community.

What word to use in place of "distribution", when one wants to include the
BSDs and other "non-distributions" as well, other than
Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list