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

[Susie <arienadean@shaw.ca>]

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