Re: [gentoo-dev] Several portage trees

Re: [gentoo-dev] Several portage trees

[Joshua Brindle]

>I was wondering about having several portage trees to allow external 
>distributor having repositories of packages.
>Recently, people have been talking in this list about the difficult proccess 
>of making a deploy of their packages. 

Actually I like this idea and advocated it a while back but it was shot down..
>
>As we know, Debian uses this. Everyone can add a new source of packages to get 
>installed to the system in a clear way. Just by putting deb lines into the 
>sources.list.

irrelavent

>Now the portage have the possibility of using a different portage from 
>PORTDIR_OVERLAY. 
>It could be really useful, if we could use something like it

not PORTDIR_OVERLAY per se, i think something like
/usr/portage/gentoo
/usr/portage/othervendor
/usr/potage/anothervendor

would do, the problem is dependancy tracking and caching.
right now dependancy metadata is generated before rsync
mirrors are updated, this is a tremendous benefit for users 
(nuke your metadata and try an emerge -ep world or emerge -s 
and you'll see what i mean). Having separate trees pretty much 
disallows using server side metadata in this way since the 
metadata wouldn't show inter-tree dependancies.

>In make.conf
>------
>PORT_SOURCES="rsync://source1 rsync://source2" ( it also could be useful if 
>ftp:// is allowed to ( mirror command ) because setup an ftp server is much 
>easier than a rsync one for several reasons like permissions ;) )
>
>PORT_SOURCES_DIR=/usr/local/portages/
>------
>
>So, after making an emerge rsync, we have:
>/usr/portage -> with the official gentoo portage mirror
>/usr/local/portages/source1 -> with the mirror of the source1
>/usr/local/portages/source2 -> with the mirror of the source2
>and so...

yea, this might work too.. 

>So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
>trees allowed ).
>
>Is this too hard to implement?
>
>I think it solves a lot of complains about flexibility and edging of Gentoo.
>

this isn't a flexibility issue, it's trivial to download ebuilds and use them, 
write your own, distribute them, maintain your own portdir_overlay
etc, there are inherent problems, especially with bugtracking, third
party ebuilds can cause problems in other gentoo proper ebuilds, 
especially if you are using third party libraries to link against, etc. 
Also say someone write an ebuild (for example oracle, and distributes
if in his own tree), this extra ebuild has essentially done nothing
for the system or the user. Countless other ebuilds would have to be
edited to add support for oracle, patches if required, conf flags, etc. 
the user would end up having to maintain lots of duplicate ebuilds
in his tree, and run the risk of his getting out of date and a user updating
with newer gentoo ebuilds (which dont' have oracle support). 
This situation doesn't help anyone.. adding the ebuilds into the main
gentoo tree and adding support to ebuilds there is an optimal solution.


On the other hand their are no doubt companies which will want
to keep proprietary products/ebuilds for themselves, and they can
with the current PORTDIR_OVERLAY system, but portage won't 
handle distribution manually. 

Summary: I agree with the need for these but it certainly isn't 
as simple as you apparently believe. I think portage will probably
go in this direction but don't count on it pre portage 2.1

Joshua Brindle

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[kikov]

> >As we know, Debian uses this. Everyone can add a new source of packages to get 
> >installed to the system in a clear way. Just by putting deb lines into the 
> >sources.list.
> 
> irrelavent
ehh..... well, it's not irrelevant, IMHO. Debian has good things and bad
things... 
I think that Gentoo is reaching the top of his development model. We
have seen this on thi delaying of recent packages. 

Seemant is setting up the new development model. Maybe, what I'm saying
it's an idea about it.

> >So, when implementing, it could be used as the PORTDIR_OVERLAY ( with several 
> >trees allowed ).
> >
> >Is this too hard to implement?
> >
> >I think it solves a lot of complains about flexibility and edging of Gentoo.
> 
> this isn't a flexibility issue, it's trivial to download ebuilds and use them, 
> write your own, distribute them, maintain your own portdir_overlay
> etc, there are inherent problems, especially with bugtracking, third
> party ebuilds can cause problems in other gentoo proper ebuilds, 
Well... I'm a developer of a project. I have submitted via bugzilla
several bugs of one of the packages I need ( not from the project, just
a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333
ohh, yeah, 2002-05-02 07:28 EST... One year ago...
The bug is still opened.

I have come back to the new versions of the software... In a completely
new system, and the ebuild works fine.


So, I need to make 1 dependency package, and 6 for the rest of the
project. I don't want to wait 6 years ( 1 -> 1 year, 2 -> 2 years, and
so... ) to get my ebuilds in. 

The way: make an ebuild repository...
The problem: deploy them easily

Yes, I know that I can make a .tar.gz of my port_overlay... But users
have to do:
1) Localize URL of the tar.gz
2) Download it
3) Move it to /usr/local
4) Untar it
5) emerge them
When using the portage mirror, just 
1) Add the portage mirror to the list
2) emerge rsync 
3) emerge them

> Also say someone write an ebuild (for example oracle, and distributes
> if in his own tree), this extra ebuild has essentially done nothing
> for the system or the user. Countless other ebuilds would have to be
> edited to add support for oracle, patches if required, conf flags, etc. 
> the user would end up having to maintain lots of duplicate ebuilds
> in his tree, and run the risk of his getting out of date and a user updating
> with newer gentoo ebuilds (which dont' have oracle support). 
> This situation doesn't help anyone.. adding the ebuilds into the main
> gentoo tree and adding support to ebuilds there is an optimal solution.
The support should be of the project development team. 
> On the other hand their are no doubt companies which will want
> to keep proprietary products/ebuilds for themselves, and they can
> with the current PORTDIR_OVERLAY system, but portage won't 
> handle distribution manually. 
ouch... This is the problem.
> 
> Summary: I agree with the need for these but it certainly isn't 
> as simple as you apparently believe. I think portage will probably
> go in this direction but don't count on it pre portage 2.1
I hope it

BR.
Thx

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Several portage trees

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Fri, Apr 25, 2003 at 09:57:15PM +0200, kikov@fco-gimeno.com wrote:
> Well... I'm a developer of a project. I have submitted via bugzilla
> several bugs of one of the packages I need ( not from the project, just
> a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333
> ohh, yeah, 2002-05-02 07:28 EST... One year ago...
> The bug is still opened.
Go back and read my posting about why many ebuilds don't get into the
tree.
Subject = Re: [gentoo-dev] Ebuilds not getting in :(
Date = Tue, 22 Apr 2003 15:36:55 -0700

If you fix those issues, and fix that ebuild. 
Things to fix:
add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES
instead of patch+src_unpack, local variable declarations, unnessicary
statement block in src_install, broken homepage URI, ALL documentation
with the package should be installed (manpages and even the guys pgp
key) , einstall instead of 'make install' and most importantly EBUILD
CHANGELOG!!!!!

> I have come back to the new versions of the software... In a completely
> new system, and the ebuild works fine.
Is libcap even actively maintained still? If not and it is not widely
used, then it is not likely to get into the tree at all.

If you resolve all of the above issues, and the package is still widely
used (I want some proof of this), then I'll take the ebuild and maintain
it in portage myself.

Update the bug with your new ebuild and mark the old ones obsolete.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Several portage trees

[Daniel Armyr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I went back and reread the post you mentioned. I feel this should go
into the developer docs. I have read them quite thouroughly, adn most of
~ what you say IS mentioned there, but not in an accessible way. Perhaps
a before-you-submit-checklist at the end of the policy doc? Since you
obviously have quite specific preferences as to how you want the ebuilds
to look, stating these plainy and clearly would be nice.
//Daniel Armyr

| Go back and read my posting about why many ebuilds don't get into the
| tree.
| Subject = Re: [gentoo-dev] Ebuilds not getting in :(
| Date = Tue, 22 Apr 2003 15:36:55 -0700
|
| If you fix those issues, and fix that ebuild.
| Things to fix:
| add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES
| instead of patch+src_unpack, local variable declarations, unnessicary
| statement block in src_install, broken homepage URI, ALL documentation
| with the package should be installed (manpages and even the guys pgp
| key) , einstall instead of 'make install' and most importantly EBUILD
| CHANGELOG!!!!!
- --
=========================================
daniel.armyr@home.se     f00-dar@f.kth.se

C118 KEVII Hall
1A Kent Ridge Rd S.119224
Singapore                 PGP@pgp.mit.edu
=========================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+qeohhxtTUWLs2lERAgkJAJ9bmKRcyk0P8KA2TgsuJyrxHVgAogCePRJt
3B1LbN/rGqd60CH2+ThfsTk=
=r9lH
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Mikael Andersson]

Gentoo is moving to slow this is why this kind of ideas emerge. It might be 
moving fast, but obviously still too slow for many. I've got a few ebuilds 
done which i haven't even bothered to try to get in since i've seen the queue 
in bugzillla and I'm sure several others are in the same situation.

Communication between developers and users is always hard. Esp since many 
gentoo users isn't strictly users. Some of the points i make might sound a 
bit harsh - but try to smile while you read them - i think it will make 
gentoo a better distribution if you do .)

On Friday 25 April 2003 21.00, Robin H.Johnson wrote:
> On Fri, Apr 25, 2003 at 09:57:15PM +0200, kikov@fco-gimeno.com wrote:
> > Well... I'm a developer of a project. I have submitted via bugzilla
> > several bugs of one of the packages I need ( not from the project, just
> > a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333
> > ohh, yeah, 2002-05-02 07:28 EST... One year ago...
> > The bug is still opened.
>
> Go back and read my posting about why many ebuilds don't get into the
> tree.

I didn't see a lot of comments about the ebuild not being up to par in 
bugzilla. Maybe if a developer seeing a build not beeing 'good-enough' could 
add a small note about this so we - The Users(tm)  - or in another word, the 
user community [3] can fix whats wrong. We aim to please ...

> Subject = Re: [gentoo-dev] Ebuilds not getting in :(
> Date = Tue, 22 Apr 2003 15:36:55 -0700
>
> If you fix those issues, and fix that ebuild.
> Things to fix:
> add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES
> instead of patch+src_unpack, local variable declarations, unnessicary
> statement block in src_install, broken homepage URI, ALL documentation
> with the package should be installed (manpages and even the guys pgp
> key) , einstall instead of 'make install' and most importantly EBUILD
> CHANGELOG!!!!!

No need to yell, instead add that information to [1]. In a way it's written in 
[2] but as that is targeted for developers it's hard to know whether or not 
I'm required to add that to my update, and if i should attach another file 
with the entire changelog/changelog entry. And equally important, somebody 
with the proper knowledge should get lintool online again. Apparently it's 
broken ( see warnings in [2] ) and sure enough it reports errors for 
baselayout and other core packages so it's probably at least somewhat broken.

>
> > I have come back to the new versions of the software... In a completely
> > new system, and the ebuild works fine.
>
> Is libcap even actively maintained still? If not and it is not widely
> used, then it is not likely to get into the tree at all.

Maybe Larry the cow will stop using gentoo then ? After all he liked being in 
control. If the users isn't in control gentoo will stop beeing bleeding edge 
and maybe end up only bleeding.

What are the purpose of being a meta distribution if only widely used packages 
get into the tree ?

>
> If you resolve all of the above issues, and the package is still widely
> used (I want some proof of this), then I'll take the ebuild and maintain
> it in portage myself.

Well, this is a problem since not all packages wanting to be in portage will 
be widely used. But i have hopes that these kind of problems will be resolved 
with the restructuring of ebuild submission and maintainance in progress.

>
> Update the bug with your new ebuild and mark the old ones obsolete.

[1] http://www.gentoo.org/doc/en/ebuild-submit.xml
[2] http://www.gentoo.org/doc/en/gentoo-howto.xml
[3] http://www.gentoo.org/main/en/about.xml

/Mikael 'snikkt' Andersson

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Henti Smith]

On Tue, 29 Apr 2003 19:44:41 +0000
Mikael Andersson <snikkt@telia.com> wrote:

> Gentoo is moving to slow this is why this kind of ideas emerge. It might be 
> moving fast, but obviously still too slow for many. I've got a few ebuilds 
> done which i haven't even bothered to try to get in since i've seen the queue 
> in bugzillla and I'm sure several others are in the same situation.

Agreed ..

> Communication between developers and users is always hard. Esp since many 
> gentoo users isn't strictly users. Some of the points i make might sound a 
> bit harsh - but try to smile while you read them - i think it will make 
> gentoo a better distribution if you do .)

Personally .. I think a good "how to build ebuilds" would help alot if not a ebuild spacific 
mailling list. This way I can submit questions I have or ebuild for testing before submitting them to 
bugzilla ... 

I use existing ebuilds as a base for new ones since the skel in /usr/portage is really not that helpfull when you doin git for the first time.
Maybe change skel can be a fully functional ebuils to do ummm .. nothing .. but have valid and correct ebuild structures and ways of doing things 
to help guide a new ebuilder in the right direction.

I've had ebuilds that does wierd things that I don't understand .. and have asked for comments in bugzilla and on devel
list but got no reply.

this makes it hard to understand what I'm doing wrong or right .. 

> > Go back and read my posting about why many ebuilds don't get into the
> > tree.
> 
> I didn't see a lot of comments about the ebuild not being up to par in 
> bugzilla. Maybe if a developer seeing a build not beeing 'good-enough' could 
> add a small note about this so we - The Users(tm)  - or in another word, the 
> user community [3] can fix whats wrong. We aim to please ...

I think the suggestion of a ebuild mailling list for ebuild developers could be helpfull here as well.

> No need to yell, instead add that information to [1]. In a way it's written in 
> [2] but as that is targeted for developers it's hard to know whether or not 
> I'm required to add that to my update, and if i should attach another file 
> with the entire changelog/changelog entry. And equally important, somebody 
> with the proper knowledge should get lintool online again. Apparently it's 
> broken ( see warnings in [2] ) and sure enough it reports errors for 
> baselayout and other core packages so it's probably at least somewhat broken.
> >
> > > I have come back to the new versions of the software... In a completely
> > > new system, and the ebuild works fine.
> >
> > Is libcap even actively maintained still? If not and it is not widely
> > used, then it is not likely to get into the tree at all.
> 
> Maybe Larry the cow will stop using gentoo then ? After all he liked being in 
> control. If the users isn't in control gentoo will stop beeing bleeding edge 
> and maybe end up only bleeding.

The time it takes to get feedback is discouraging ... I have helped with the ebuild for openexr and since then a new version has been released which I 
submitted and then an update to work with nv-cg-toolkit and the NVSDK and still no feedback ... 

I understand there are things happening to correct this and I'm waiting in antisipation for those changes as the only real 
contribution I can make to gentoo is bug reporting and ebuilds ... I'm doing lots of bug reporting ... but only one ebuild I had any interaction with has been 
incorporated into the tree. 

> > If you resolve all of the above issues, and the package is still widely
> > used (I want some proof of this), then I'll take the ebuild and maintain
> > it in portage myself.
> 
> Well, this is a problem since not all packages wanting to be in portage will 
> be widely used. But i have hopes that these kind of problems will be resolved 
> with the restructuring of ebuild submission and maintainance in progress.

If you meet a hungry man and give him a fish .. he eats for a day ... give him a fishing rod and he eats for a live time
I knwo it's cliche'd .. but it's because it's true .. 

It will take alot less effort in the long run to help a "new" developer get it right and then monitor him to make sure he knows what 
he's doing then he can maintain he's own package. 

I do however thing a proper document on how to create correct ebuilds will go along way to helping ebuilders do things right.
What is required etc etc. Sinply reading the emerge and ebuild documentation is not enought to understand the inner workings of the ebuild,
and it has changed quiet a bit in the last few months.

Once again I suggest a ebuild mailling list with the sole use of creating discussing and testing new ebuilds .. 

Henti 

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Community driven meta distribution or only distribution (was Re: Several portage trees)

[Denys Duchier]

Henti Smith <bain@tcsn.co.za> writes:

> If you meet a hungry man and give him a fish .. he eats for a day ... give him a fishing rod and he eats for a live time
> I knwo it's cliche'd .. but it's because it's true .. 

I rather like Pratchett's twist on that old saw:

    Build a fire for a man, and he'll be warm for a day.
    Set a man on fire, and he'll be warm for the rest of his life.

seems oddly relevant in connection to Gentoo :-)

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Community driven meta distribution or only distribution (was Re: Several portage trees)

[Björn Lindström]

Henti Smith <bain@tcsn.co.za> [20030429 19:45]:
> Maybe change skel can be a fully functional ebuils to do ummm ..
> nothing .. but have valid and correct ebuild structures and ways of
> doing things to help guide a new ebuilder in the right direction.

...or maybe portage should include a neat and well commented ebuild for
GNU Hello World. I believe Debian has something like that for deb.

-- 
Björn Lindström <bkhl@privat.utfors.se>
Home page: http://hem.fyristorg.com/bkhl/
Blog: http://bkhl.livejournal.com/
Elektrubadur demo: http://hem.fyristorg.com/bkhl/elektrubadur/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Community driven meta distribution or only distribution (was Re: Several portage trees)

[Henti Smith]

On Tue, 29 Apr 2003 21:09:26 +0200
Björn Lindström <bkhl@privat.utfors.se> wrote:

> Henti Smith <bain@tcsn.co.za> [20030429 19:45]:
> > Maybe change skel can be a fully functional ebuils to do ummm ..
> > nothing .. but have valid and correct ebuild structures and ways of
> > doing things to help guide a new ebuilder in the right direction.
> 
> ...or maybe portage should include a neat and well commented ebuild for
> GNU Hello World. I believe Debian has something like that for deb.

This would be awesome  :)) 

Henti 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Community driven meta distribution or only distribution (was Re: Several portage trees)

[George Shapovalov]

On Tuesday 29 April 2003 12:09, Björn Lindström wrote:
> ...or maybe portage should include a neat and well commented ebuild for
> GNU Hello World. I believe Debian has something like that for deb.
Do you by any chance mean /usr/portage/skel.ebuild ;)?
(check the skel.ChangeLog at the same location).

Also you might want to look at dev-util/ebuilder, though looks like this one 
isn't actively maintained lately :(.

George

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Community driven meta distribution or only distribution (was Re: Several portage trees)

[Björn Lindström]

George Shapovalov <george@gentoo.org> [20030430 02:10]:
> Do you by any chance mean /usr/portage/skel.ebuild ;)?  (check the
> skel.ChangeLog at the same location).

Nah. skel.ebuild is a good outline to start a new ebuild if you now how
to do it, but it's a pretty bad example, as it doesn't actually install
anything.

Since GNU Hello World is meant as an example of use for autoconf and
generally packaging GNU software, the idea to use that for this is a
pretty obvious one.

-- 
Björn Lindström <bkhl@privat.utfors.se>
Home page: http://hem.fyristorg.com/bkhl/
Blog: http://bkhl.livejournal.com/
Elektrubadur demo: http://hem.fyristorg.com/bkhl/elektrubadur/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Susie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 29 Apr 2003 19:45:43 +0200
Henti Smith <bain@tcsn.co.za> wrote:

> On Tue, 29 Apr 2003 19:44:41 +0000
> Mikael Andersson <snikkt@telia.com> wrote:
> 
> > Gentoo is moving to slow this is why this kind of ideas emerge. It
> > might be moving fast, but obviously still too slow for many. I've
> > got a few ebuilds done which i haven't even bothered to try to get
> > in since i've seen the queue in bugzillla and I'm sure several
> > others are in the same situation.

Actually I've had one or two of my ebuilds added no prob.  I did recieve
one warning to remember to include a change log.  Which I fixed with one
ebuild and I need to do for some others I made.  I'm also going to
update a few of them.  I've been very busy this week offline which is
why I've not got to it all yet.  When I upload ebuilds to bugzilla I
also include the digests as well.  I'm not sure if that helps it along. 
One thing I do need to figure out for ebuilds is putting in multiple
URI's as some packages come from source forge and they offer multiples. 
I put in my default at the time.

With a few people I think there were conflicts over packages(ie two
diffrent people submit packages not realizing someone just did submit
one).  I know that seemed to be the case with limewire.  While the
newest package for that one was more complex et al it still relied on
"${P}" and well limewires tar doesn't have a version number so at least
for me that wouldn't build but the earlier ebuild worked just fine.  
I'm not sure (ok I didn't pay attention I'll admit that) if buzilla is
searching message bodies or only subjects.  If it's only subjects
perhaps if it searched bodies that would make it more appearant on a
search if something exists already.

> > Communication between developers and users is always hard. Esp since
> > many gentoo users isn't strictly users. Some of the points i make
> > might sound a bit harsh - but try to smile while you read them - i
> > think it will make gentoo a better distribution if you do .)
> 
> Personally .. I think a good "how to build ebuilds" would help alot if
> not a ebuild spacific mailling list. This way I can submit questions I
> have or ebuild for testing before submitting them to bugzilla ... 

I got told by someone to do "man 5 ebuild" but prior to that all I had
was looking in others ebuilds to get an idea or looking at the online
howto.  I think it would help if it was in condensed form showing the
most commonly used bits and how to use them.  Tho to some extent I
suppose the online howto already does that.

Btw I'm one of those people who I guess gets bored and surfs
stable.gentoo.org or portage on my drive and looks for unstables/masked
that might prove intresting.  Weather or not I use them in the long run
I do try several and report on how they function on stable.gentoo in
hopes that more packages get added to the database.  I think more people
need to participate in ranking packages and that might help shove them
into the tree faster.

As for nix experience.  I'm self taught from hands on.  Granted I
started from mandrake 6.5 and quit it at 9(it was definitly nix
bloatware tho good for newbies) moving to gentoo.  I'm now learning much
more as life the past few years was hecktic(my daughter died last august
from brain cancer at age 12).  Anyways I'm gradually going to be
teaching myself a few other distros(just built 2 486's... one to use for
debian and another to use for freebsd).  I don't know what I'd get
classed (as ok I duel book with 2k as well)... But on the plus side I
did take programming in the 80's granted though not used that in so long
I can barely remember it. :/

Anyways yes probably many are just installing and being done with it. 
ie going only with the stables or going fully with the unstables.  They
want no hassle but it to just work.
 
> I use existing ebuilds as a base for new ones since the skel in
> /usr/portage is really not that helpfull when you doin git for the
> first time. Maybe change skel can be a fully functional ebuils to do
> ummm .. nothing .. but have valid and correct ebuild structures and
> ways of doing things to help guide a new ebuilder in the right
> direction.

I made myself a template frankly and I keep my finished/submitted
ebuilds in a finished work directory for refrence at what I did to get
whatever going right.  But there are also a few other skel's one for the
changelog at least.  But I too have looked in others existing trying to
figure out how to make things work.  I wanted to make an ebuild for
hackedbox(blackbox varient with no slit and no toolbar; that is slimed
down) and saw that there was a specific eclass for *box family.  But the
ebuild failed at one spot.(amusingly it was something about "Bloat_IT"
in the error... the bloat option for that window manager adds in the
slit and toolbar)

> I've had ebuilds that does wierd things that I don't understand .. and
> have asked for comments in bugzilla and on devel list but got no
> reply.
> 
> this makes it hard to understand what I'm doing wrong or right .. 

Oh I know that one too.  I was asking questions on the gentoo user list
about that.  But saw this one reciently and thought maybe I should take
such talk here and people in this list are probably the ones doing
ebuilds anyways.


> I think the suggestion of a ebuild mailling list for ebuild developers
> could be helpfull here as well.

Yes tho to some extent I thought that was somewhat what this was. 
Unless this is ment more for those doing the base/core packages for
gentoo.  I think it would be handy tho if we had a spot to show are
ebuilds and say how does this look?  It's working good for me would
someone like to try it?


> The time it takes to get feedback is discouraging ... I have helped
> with the ebuild for openexr and since then a new version has been
> released which I submitted and then an update to work with
> nv-cg-toolkit and the NVSDK and still no feedback ... 

I've gotten reasonable enough feedback but mind you that was typically
regarding regular bugs not ebuilds.  But I do see when ebuilds get
shifted from one gentoo bug wrangler to another as they take a peak at
it.  When my first ebuild got added to the tree (wmmsg) I did get a note
saying good job as well as remember to include change logs on another
ebuild(I think it was another and not the wmmsg one ... I'd have to dig
in my bugs email to see for sure).  Right now I'm slowly working on a
few ebuilds.  A few I abandoned because they were just weird and I
didn't know what the heck to do to get around the errors in question. 
One I've finished making but can neither build nor submit affects
several other packages I'm making as they depend on a ebuild which is
masked due to some issues it has.(either it was libtool or autoconf or
both are masked.  I need autoconf 2.5 and the 1.4.2 libtool)


> I understand there are things happening to correct this and I'm
> waiting in antisipation for those changes as the only real
> contribution I can make to gentoo is bug reporting and ebuilds ... I'm
> doing lots of bug reporting ... but only one ebuild I had any
> interaction with has been incorporated into the tree. 

I'm doing about the same.
 
> If you meet a hungry man and give him a fish .. he eats for a day ...
> give him a fishing rod and he eats for a live time I knwo it's
> cliche'd .. but it's because it's true .. 

Well people will build ebuilds out of attachment to programs that they
miss or due to things not meeting what they require.  Mind you I've done
several ebuilds just for the heck of it.  To hopefully expand what is
available and be of use to someone.  That is why I've taken on trying to
make some ham radio ebuilds as tho I'm a ham radio operator(licensed for
VHF) I'm unlikely to use it(as it is typically for people with HF) but I
noticed a few ham radio operators also using gentoo.  I figured packages
in that line would be used.  As well I made some that looked
intresting(in the amusing sense or in the useful sense).

> It will take alot less effort in the long run to help a "new"
> developer get it right and then monitor him to make sure he knows what
> he's doing then he can maintain he's own package. 

True.  If we know what we are doing and we know the packages we've made
it isn't a big deal to bump them.  Unless the program itself has
undergone major revision and the ebuild has to change alot to deal with
that.  But again if they understand things it's likely to be less a
problem.
 
> I do however thing a proper document on how to create correct ebuilds
> will go along way to helping ebuilders do things right. What is
> required etc etc. Sinply reading the emerge and ebuild documentation
> is not enought to understand the inner workings of the ebuild, and it
> has changed quiet a bit in the last few months.

have you done "man 5 ebuild"?  That has far more listed command wise
than the online howto.  Tho somethings I'm still wondering what the heck
it means(syntax or usage as not everything has an example... as well as
I've been out of doing any sort of programming for many years so I
probably admittedly need a refresher course on the lingo)
 
> Once again I suggest a ebuild mailling list with the sole use of
> creating discussing and testing new ebuilds .. 

Question here as I am new to this list(though have posted on gentoo user
and gentoo desktop).  Isn't this list for that to some extent?  For
making ebuilds and general gentoo development?  Or what is the exact
usage of this list to be?  I know there was a like discussion in the
security list(frankly after the announcements shifted to the other list
I unsubscribed to security as that was the only real reason I was
reading it).

- -- 

Susie
arienadean@shaw.ca
http://arienadean.tripod.com/

Digitally signed
GPG Key ID: E93F0D23
Key fingerprint = 33F8 0E9D 3AD1 23E0 C70F  ECC6 7871 D811 E93F 0D23

- -----------------------------------------------------------------------

"We are not human beings having a spiritual experience. We are
spiritual beings having a human experience." - Unknown



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

iD8DBQE+ruYieHHYEek/DSMRAq+4AJ9cC0Aq/OadlpwoLf+8sEy6sWUN6gCffHde
skO4pH8xs/cs+rDEx90JTqU=
=nZMw
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 6641 bytes --]

On Tue, Apr 29, 2003 at 07:44:41PM +0000, Mikael Andersson wrote:
> Gentoo is moving to slow this is why this kind of ideas emerge. It might be 
> moving fast, but obviously still too slow for many. I've got a few ebuilds 
> done which i haven't even bothered to try to get in since i've seen the queue 
> in bugzillla and I'm sure several others are in the same situation.
Seeing this. I have a specific request to make. Could you please ensure
that your ebuilds are tagged with the 'EBUILD' keyword, to make them
easier to find firstly. Secondly, just as an idea, a developer that has
some time to go thru submitted ebuilds and review them for style and
correctness (as I did for the ebuild mentioned above in this thread).

> On Friday 25 April 2003 21.00, Robin H.Johnson wrote:
> > On Fri, Apr 25, 2003 at 09:57:15PM +0200, kikov@fco-gimeno.com wrote:
> > > Well... I'm a developer of a project. I have submitted via bugzilla
> > > several bugs of one of the packages I need ( not from the project, just
> > > a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=2333
> > > ohh, yeah, 2002-05-02 07:28 EST... One year ago...
> > > The bug is still opened.
> > Go back and read my posting about why many ebuilds don't get into the
> > tree.
> I didn't see a lot of comments about the ebuild not being up to par in 
> bugzilla. Maybe if a developer seeing a build not beeing 'good-enough' could 
> add a small note about this so we - The Users(tm)  - or in another word, the 
> user community [3] can fix whats wrong. We aim to please ...
My comments were included below in my previous email. I have also
attached them to the bug item now.

> > If you fix those issues, and fix that ebuild.
> > Things to fix:
> > add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES
> > instead of patch+src_unpack, local variable declarations, unnessicary
> > statement block in src_install, broken homepage URI, ALL documentation
> > with the package should be installed (manpages and even the guys pgp
> > key) , einstall instead of 'make install' and most importantly EBUILD
> > CHANGELOG!!!!!
> No need to yell, instead add that information to [1]. In a way it's written in 
> [2] but as that is targeted for developers it's hard to know whether or not 
lintool/repoman do remind you that some of those are required, but for
the most part they require a human to check. The original ebuild looked
as if it was written using only the guide, and none of the existing
ebuilds in portage, many of which server as excellent examples of ebuild
style and how things are done.
However you are partially correct that some of this should be added to
[1].
most importantly,
- say required items SLOT/KEYWORDS/IUSE/HOMEPAGE
- say that all documentation should be installed
- recommend econf/emake/einstall instead of normal variants
- patch+src_unpack is not efficent and maybe incorrect, use PATCHES="..."


Some of the things I mentioned are also partially my personal
preferences to make life easier on myself. People's code says a lot
about them generally, and if your submitted ebuilds look sloppy and
that lessens the chance that developers will even go thru them and
say what is wrong, let along clean them up.

> I'm required to add that to my update, and if i should attach another file 
> with the entire changelog/changelog entry.
Attaching a simple text file with just your changelog entry would be
sufficent if you are updating an existing package, or including a new
changelog from the skeleton file for a new ebuild. (This is a personal
preference again).

> And equally important, somebody with the proper knowledge should get
> lintool online again. Apparently it's broken ( see warnings in [2] )
> and sure enough it reports errors for baselayout and other core
> packages so it's probably at least somewhat broken.
Repoman replaced lintool. I don't unfortunetly know of a tool that users
can use to check ebuilds themselves, as repoman requires a CVS checkout.
I have said previously that lintool needs to come back myself, and I
have submitted some fixes for it to bugzilla myself. That document [2]
does appear to contradict itself.

> > Is libcap even actively maintained still? If not and it is not widely
> > used, then it is not likely to get into the tree at all.
> Maybe Larry the cow will stop using gentoo then ? After all he liked being in 
> control. If the users isn't in control gentoo will stop beeing bleeding edge 
> and maybe end up only bleeding.
I personally try to avoid packages that do not fill at least one of the
following requirements:
1) is actively maintained
2) is widely used
3) not directly useful to myself

the reasoning behind 1) is that unmaintained packages upstream of Gentoo
do cause problems. media-plugins/avi-xmms is a recent example. It is
presently masked in packages.mask while it dies down further, at which 
point if it is no maintained again, it will probably be trimmed from the 
tree.

> What are the purpose of being a meta distribution if only widely used packages 
> get into the tree ?
> > If you resolve all of the above issues, and the package is still widely
> > used (I want some proof of this), then I'll take the ebuild and maintain
> > it in portage myself.
> Well, this is a problem since not all packages wanting to be in portage will 
> be widely used. But i have hopes that these kind of problems will be resolved 
> with the restructuring of ebuild submission and maintainance in progress.
For 2) packages that aren't actively maintained, but are widely used
usually have enough other support and people working with them that it
is possible to support them ourselves. An active and responsive mailing
list for a package fills this well, or if there are good pages written
up about the package on the web. Several actively maintained packages that
use the library as a requirement would also serve to show that it is
still in general use.

Item 3) is somewhat different than the other two. If there is a package
that doesn't fit into the other two, and I have a personal everyday use
for it, I'm willing to put some of my time to keeping it working.

> [1] http://www.gentoo.org/doc/en/ebuild-submit.xml
> [2] http://www.gentoo.org/doc/en/gentoo-howto.xml
> [3] http://www.gentoo.org/main/en/about.xml

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Henti Smith]

> Seeing this. I have a specific request to make. Could you please ensure
> that your ebuilds are tagged with the 'EBUILD' keyword, to make them
> easier to find firstly. Secondly, just as an idea, a developer that has
> some time to go thru submitted ebuilds and review them for style and
> correctness (as I did for the ebuild mentioned above in this thread).

I do this .. however I see your point.

> My comments were included below in my previous email. I have also
> attached them to the bug item now.

could this and others "requirements" for a ebuild to be accepted not be put into proper documentation
and added to the gentoo site. 

> lintool/repoman do remind you that some of those are required, but for
> the most part they require a human to check. The original ebuild looked
> as if it was written using only the guide, and none of the existing
> ebuilds in portage, many of which server as excellent examples of ebuild
> style and how things are done.
> However you are partially correct that some of this should be added to
> [1].
> most importantly,
> - say required items SLOT/KEYWORDS/IUSE/HOMEPAGE
> - say that all documentation should be installed
> - recommend econf/emake/einstall instead of normal variants
> - patch+src_unpack is not efficent and maybe incorrect, use PATCHES="..."

I have used the guide/skel/ebuilds to write the ebuilds I have done. I however do not expect them to be 
the best or maybe even acceptable since there is so many different "styles" of doing ebuilds. 

which ebuilds can be used for referance? once again a guide would be a good thing at this point.
I'm by no means a linux developer, I'm but a user that can do scripting and figure things out given 
enought information. providing the information to do things correcly can greatly relieve full time developers
from having to deal with broken ebuilds as active ebuilders can help fix problems they have experianced before.

> Some of the things I mentioned are also partially my personal
> preferences to make life easier on myself. People's code says a lot
> about them generally, and if your submitted ebuilds look sloppy and
> that lessens the chance that developers will even go thru them and
> say what is wrong, let along clean them up.

everybody has to start somewhere ;PP 
some just take longer to learnt he correct way and need a little more attention .. but in the end the effort 
can pay off and make everybodies lives easer.

> Attaching a simple text file with just your changelog entry would be
> sufficent if you are updating an existing package, or including a new
> changelog from the skeleton file for a new ebuild. (This is a personal
> preference again).

It's still a good pointer.. 

If need be I will start writing a "ebuild developers howto" to get all the information 
together and get some base for new and existing ebuilders to work off. The way an ebuild is developed / coded / created 
really should be on par and consistant with how portage works and features it supports. legacy support is a good thing, but left for to long
without havin proper guidelines will only agrivate the situation which I acuallt think it has judging by your comment regarding using only the ebuild guide.

People should be capabile of writing an ebuil dusing ONLY the ebuilde guide and not need to go throught 4000 ebuilds to find what the best and latest way of doing things are.

> Repoman replaced lintool. I don't unfortunetly know of a tool that users
> can use to check ebuilds themselves, as repoman requires a CVS checkout.
> I have said previously that lintool needs to come back myself, and I
> have submitted some fixes for it to bugzilla myself. That document [2]
> does appear to contradict itself.

Human eyes are always the best way... I habe mentioned before having an ebuild mailling list. 
I do really think the ebuild situation is becomming like a software package on it's own with a core set of developers that can commit changes 
and users on the mailling list offering support and helping each other get their stuff working without having the bug the developers all the time to 
get things working .. 

creating a tree of developers -> experianced ebuilders -> new ebuilders in a mailling list can help solve problems as it can be a central place to "promote" ebuild for 
testing before going into bugzilla until a ebuilder has had the experiance and "well wishes" of he's peers that he's reached a point where he can manage on he's own. in turn he then start helping people with ebuild development problems and "training" new ebuilders. in the end the develop interaction is really only at the bugzilla stage where incorporating into the portage tree is needed. by then an ebuild has been looked at by other ebuilders and helped get into a shape that is correct and tought the ebuild creator new things about how to create a correct ebuild. 

> I personally try to avoid packages that do not fill at least one of the
> following requirements:
> 1) is actively maintained
> 2) is widely used
> 3) not directly useful to myself
> 
> the reasoning behind 1) is that unmaintained packages upstream of Gentoo
> do cause problems. media-plugins/avi-xmms is a recent example. It is
> presently masked in packages.mask while it dies down further, at which 
> point if it is no maintained again, it will probably be trimmed from the 
> tree.

If nobody is using the application then sure I understand drop the support and ebuild from the tree, but 
as the mail shows there is somebody and he's more then willing to help and work at keeping something he wants.
IF he doesn't know how a guide and/or system must be in place to provide the user with the knowledge and means to 
have he's contribution accepted into the tree. 

> For 2) packages that aren't actively maintained, but are widely used
> usually have enough other support and people working with them that it
> is possible to support them ourselves. An active and responsive mailing
> list for a package fills this well, or if there are good pages written
> up about the package on the web. Several actively maintained packages that
> use the library as a requirement would also serve to show that it is
> still in general use.
> 
> Item 3) is somewhat different than the other two. If there is a package
> that doesn't fit into the other two, and I have a personal everyday use
> for it, I'm willing to put some of my time to keeping it working.

If each user can be a developer in he's own mind and has access to the right tools and information 
no package will fall into disuse as there will be somebody out there using it. Such is the way of choice :) 

Hope this is taken as suggestions and user input and nothing more .. or less :) 

Henti 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

> which ebuilds can be used for referance? once again a guide would be a good thing at this point.
> I'm by no means a linux developer, I'm but a user that can do scripting and figure things out given 
> enought information. providing the information to do things correcly can greatly relieve full time developers
> from having to deal with broken ebuilds as active ebuilders can help fix problems they have experianced before.
> 

A good "reference" ebuild can be found by "man 5 ebuild".


-g2boojum-
-- 
Grant Goodyear <g2boojum@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Susie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 29 Apr 2003 11:17:13 -0700
"Robin H.Johnson" <robbat2@gentoo.org> wrote:


> lintool/repoman do remind you that some of those are required, but for
> the most part they require a human to check. The original ebuild

I've found lintool useful.  Though it does complain sometimes if you
omit a tag as it wont be used or if you comment it out.  RDEPEND I think
is one it made some complaint on so admittedly I forgot to re comment it
out on my template I use so I have to go check later and make sure all
my older ebuilds again comment it out.

> looked as if it was written using only the guide, and none of the
> existing ebuilds in portage, many of which server as excellent
> examples of ebuild style and how things are done.

My first ebuild or two was only using the guide or peaking at some
existing ebuilds.  Then I found "man 5 ebuild" alot more useful as it
listed more things I seemed to need to use.  But I was unaware that that
particular man page existed til someone pointed it out to me.

> However you are partially correct that some of this should be added to
> [1].
> most importantly,
> - say required items SLOT/KEYWORDS/IUSE/HOMEPAGE
> - say that all documentation should be installed

Yes that doccumention comment is important.  For example I had no clue
what should be added that way at first.  Til again someone pointed it
out.  I was unsure if the "README" etc that comes with a tar should be
in there.   As for the slots I understand their usage however I'm unsure
as to if new ebuilds that have no priors for that software if they need
a slot number or should just stay at "0".  Personally I've left them at
"0" as I've seen no other ebuild for them.  I get the keyword use good
enough for the homepages tho some things don't have them and I've had to
resort to using source forge project page or freshmeat info page.

> - recommend econf/emake/einstall instead of normal variants
> - patch+src_unpack is not efficent and maybe incorrect, use
> PATCHES="..."

I do like the comments in the skel ebuild for pointing out that emake
and einstall don't work for everything.  I've had builds fail and found
out that I just had to switch that then they were fine.  As for the
patch yes I have no clue how to do that so that has stopped me from
trying to make the odd thing.  Also I'm unsure as to how to make an
ebuild fetch secondary packages other than listing them as depends and
then writing ebuilds for those items.  I'd like to make an ebuild for a
ham radio quiz program for those wanting to write their license but for
example if I do it requires I fetch a group of text files from the arrl
site.  The perl script that generates the quizes needs those texts to
make the questions.  I grasp how to make the ebuild for the perl script
for the most part but not how to make that ebuild grab those files and
shift them to where it's needed.  I'm guessing I'd have to put a symlink
in the /usr/bin for the script and have the script and the text files in
a /usr/share/<dir>

> Some of the things I mentioned are also partially my personal
> preferences to make life easier on myself. People's code says a lot
> about them generally, and if your submitted ebuilds look sloppy and
> that lessens the chance that developers will even go thru them and
> say what is wrong, let along clean them up.

Yes but one point is a person wouldn't have a clue if it's sloppy or not
if someone doesn't say why and make a suggestion.  Though I've found so
far people have nicely done that for me.  They've not been nasty and put
me off making ebuilds frankly they were reasonably encouraging and just
pointed out things I'd missed.  Which I felt bad about some were
probably dumb errors at the time but we all have lives outside our boxes
and sometimes that gets in the way for a moment or two.(I myself have a
special needs child to take care of, am busy with divorce stuff, about
to have surgery in about a month, and dealing with a variety of other
things... so occasionally I miss things.  I do know people have quite
the work load and are doing it voluntarily here so I do honestly feel
bad if I've needlessly added to that.  But usually I get told it once or
twice... I've taken the hint..)
 

> Repoman replaced lintool. I don't unfortunetly know of a tool that
> users can use to check ebuilds themselves, as repoman requires a CVS
> checkout. I have said previously that lintool needs to come back
> myself, and I have submitted some fixes for it to bugzilla myself.
> That document [2] does appear to contradict itself.

lintool is still there.  I know as I use it.  But it does complain on
odd things it probably shouldn't.  Not sure the full spectrum of what it
will complain about but on "lintool ebuild <path to ebuild>" I've had it
complain about tags that wont be used that I've either commented out or
just not put in.  But now I've learned it does that and I've got just
enough experience that most ebuilds are straight forward and if it fails
when I'm using it I check it further with lintool or start asking
questions.
 
> I personally try to avoid packages that do not fill at least one of
> the following requirements:
> 1) is actively maintained
> 2) is widely used
> 3) not directly useful to myself

I think that is a given for most people.  Except in my case if it looks
intresting/that it might be useful in the long run(even if it's not
personally useful to me) I may give it a try and check it out on gentoo
stable to help pass on stability, etc info to help it maybe get bumped
into portage.  
 
- -- 

Susie
arienadean@shaw.ca
http://arienadean.tripod.com/

Digitally signed
GPG Key ID: E93F0D23
Key fingerprint = 33F8 0E9D 3AD1 23E0 C70F  ECC6 7871 D811 E93F 0D23

- -----------------------------------------------------------------------

"Science is everything we understand well enough to explain to a
computer. Art is everything else." - David Knuth 



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

iD8DBQE+ruqIeHHYEek/DSMRAicIAKCTEbm5bM2IZnf1JpHajWHAkV+E9wCfUIHt
z958tQXCSA33RXKWWYToD3s=
=rshx
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Tue, Apr 29, 2003 at 11:17:13AM -0700, Robin H. Johnson wrote:
> most importantly,
> - say required items SLOT/KEYWORDS/IUSE/HOMEPAGE
> - say that all documentation should be installed
> - recommend econf/emake/einstall instead of normal variants
> - patch+src_unpack is not efficent and maybe incorrect, use PATCHES="..."

Perhaps this is the moment to mention that you are using base.eclass...
I see users setting PATCHES and wondering why nothing happens.

Just my 0.02 EUR,

Patrick	

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1225 bytes --]

On Tuesday 29 April 2003 22:44, Mikael Andersson wrote:
> Gentoo is moving to slow this is why this kind of ideas emerge. It might be
> moving fast, but obviously still too slow for many. I've got a few ebuilds
> done which i haven't even bothered to try to get in since i've seen the
> queue in bugzillla and I'm sure several others are in the same situation.

A big reason for not giving in to requests for either non-gentoo.org ebuild 
trees 'affiliation' or less tightly controlled adding of ebuilds to the 
central tree is that we're currently going through that famous reorganization 
of our. The herds proposal/RFC was just yesterday finally confirmed by 
drobbins and now we've begun discussing implementation (yes, the discussion 
_will_ move to -dev when appropriate). Once we have that in place, we can 
work on the various things related to faster/smoother ebuild submission 
acceptance. So we'd rather be slower now, but better in the longer run of two 
or three months from now, with a central ebuild tree that scales well and 
accepts ebuilds more smoothly.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]