[gentoo-dev] Contribute many ebuilds at once

[gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Hello,

While learning to develop ebuild packages, I have created
12 ebuilds for really small, but IMHO useful, programs (mostly wmaker 
dock apps, but also some bigger ones, like squeak and smalltalk/X).
  I know I should fill a "bug" report for each of them, but
I must admit my hatered on web-interfaces and this kind of
repeatitive work.
  I understand bugzilla may be a good tool, but is there an alternative ?
Could a willing developer with CVS access take at least my 9 WindowMaker
dockapps and commit them at once. I think it would be less work for both.
  Should I write a bug report containg the collection of the packages ?
(even if they are possibly unreleated). I'm asking this not only
for those small number of ebuilds, but because I plan in the near
future to package a large number of small (or at least simple) apps;
and I wanted to know how to behave.

Thanks

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

> I must admit my hatered on web-interfaces and this kind of
> repeatitive work.

Depending on how important you feel it is that your ebuilds go into CVS
asap, you might want to hold for two more weeks, and help test a new,
prototype ebuild submission system where you can submit from your
commandline, or even text-mode webbrowser :)

Kind regards,

Karl T

Re: [gentoo-dev] Contribute many ebuilds at once

[Jano Lukac]

Or... you could submit a single "bug" report with a link to where you
are storing all your ebuilds.  *shrug*

On Sun, Jun 09, 2002 at 02:18:00AM +0200, Karl Trygve Kalleberg wrote:
> 
> > I must admit my hatered on web-interfaces and this kind of
> > repeatitive work.
> 
> Depending on how important you feel it is that your ebuilds go into CVS
> asap, you might want to hold for two more weeks, and help test a new,
> prototype ebuild submission system where you can submit from your
> commandline, or even text-mode webbrowser :)
> 
> Kind regards,
> 
> Karl T
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Jano Lukac wrote:
> Or... you could submit a single "bug" report with a link to where you
> are storing all your ebuilds.  *shrug*

This is not a problem for me. But I think
it makes sense only for grouped packages, like
wm docks in this case, but not for etherogeneus ebuilds.
  If it's not a problem for the developers I can do so.

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

On Sat, 8 Jun 2002, Jano Lukac wrote:

> 
> Or... you could submit a single "bug" report with a link to where you
> are storing all your ebuilds.  *shrug*

That is probably the best recipe for being marked "INVALID" in bugzilla.
It is highly unlikely that all submissions should go to the same
developer. We each have different areas of interest that we stick to.

Of course, if all the ebuilds are closely related (say a media player with
associated plugins, or similar), this approach is perfectly okay.

Karl T

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Karl Trygve Kalleberg wrote:
>>I must admit my hatered on web-interfaces and this kind of
>>repeatitive work.
>>
> 
> Depending on how important you feel it is that your ebuilds go into CVS
> asap, you might want to hold for two more weeks, and help test a new,
> prototype ebuild submission system where you can submit from your
> commandline, or even text-mode webbrowser :)

I want just to avoid duplicate work, in case someone feels
the need to use, say wmtop, and than wm*; sure they are
nice apps to start understanding portage, because they are small,
but if someone already did that three weeks ago without telling .... 
aargh :-)

I would like to help developing a flexible command line submission system.
I'm interested in how are you currently organized, how and who read the
"bug" submissions ...
  Alternatively I could write a dummy client which connects to the 
bugzilla like a webbrowser and automates the submission.
  (I suppose there is not a secure straight connection to the bugzilla 
backend)
  I see all this by a user perspective, not as a maintainer; so I would
like to learn more.

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Paul de Vrieze]

On Sunday 09 June 2002 08:41, Marko Mikulicic wrote:
>   Alternatively I could write a dummy client which connects to the
> bugzilla like a webbrowser and automates the submission.
>   (I suppose there is not a secure straight connection to the bugzilla
> backend)

The problem is not so much the submission itself, but what happens afterwards. 
New ebuilds take a lot of time to be included in the tree (if you have bad 
luck)

The new system tries to resolve that.

Paul

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Paul de Vrieze wrote:
> On Sunday 09 June 2002 08:41, Marko Mikulicic wrote:
> 
>>  Alternatively I could write a dummy client which connects to the
>>bugzilla like a webbrowser and automates the submission.
>>  (I suppose there is not a secure straight connection to the bugzilla
>>backend)
>>
> 
> The problem is not so much the submission itself, but what happens afterwards. 
> New ebuilds take a lot of time to be included in the tree (if you have bad 
> luck)
This is why I thought it was better to group them, so at least they
will get in all in once.

> 
> The new system tries to resolve that.

What are the main reasions for this latency ?
I imagine the package need to be tested somehow.

How is this "new system" you are talking about ?
How is the "old system", from a maintainer perspective ?
  What appens "afterwards" ?

  Wouldn't be nice if new ebuilds would committed to
a middle place (purgatory) where they wait in a queue.
  But in the mean time audacious users could try the ebuilds
(simply downloading them with ftp, or ebuild rsyinc-purgatory -> 
/usr/portage/purgatory) so at least they can be tested.
  Does it make sense ?

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Jeremiah Mahler]

On Sun, Jun 09, 2002 at 01:35:20PM -0400, Marko Mikulicic wrote:
> Paul de Vrieze wrote:
> >On Sunday 09 June 2002 08:41, Marko Mikulicic wrote:
> >
> >> Alternatively I could write a dummy client which connects to the
> >>bugzilla like a webbrowser and automates the submission.
> >> (I suppose there is not a secure straight connection to the bugzilla
> >>backend)
> >>
> >
> >The problem is not so much the submission itself, but what happens 
> >afterwards. New ebuilds take a lot of time to be included in the tree (if 
> >you have bad luck)
> This is why I thought it was better to group them, so at least they
> will get in all in once.
> 
> >
> >The new system tries to resolve that.
> 
> What are the main reasions for this latency ?
> I imagine the package need to be tested somehow.
> 
> How is this "new system" you are talking about ?
> How is the "old system", from a maintainer perspective ?
>  What appens "afterwards" ?
> 
>  Wouldn't be nice if new ebuilds would committed to
> a middle place (purgatory) where they wait in a queue.
>  But in the mean time audacious users could try the ebuilds
> (simply downloading them with ftp, or ebuild rsyinc-purgatory -> 
> /usr/portage/purgatory) so at least they can be tested.
>  Does it make sense ?
> 
> Marko
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Marko, I am not answering your question, but I also have
some similar ideas.

What about a rating system for ebuilds?

A brand new ebuild would start no votes and no rating
which indicates it is not been thoroughly used and hence
should only be used by those willing to deal with problems.
As more people use the ebuild, they rate it and it gets
more ratings. If the ratings are bad, people will know
to stay away from it. If the ratings are good, people will
known that the ebuild should not have problems.

I can't think of any reason why this would not work. If anyone
knows of one I would like to hear it.

-- 
Jeremiah Mahler
<jmahler@pacbell.net>

Re: [gentoo-dev] Contribute many ebuilds at once

[Markus Krainer]

Jeremiah Mahler wrote:


> What about a rating system for ebuilds?

Sth. near this is discussed in bug #1523 and in the links in
George Shapovalov's comments.
http://bugs.gentoo.org/show_bug.cgi?id=1523

   -Markus-

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

>>
>>_______________________________________________
>>gentoo-dev mailing list
>>gentoo-dev@gentoo.org
>>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>>
> 
> Marko, I am not answering your question, but I also have
> some similar ideas.
> 
> What about a rating system for ebuilds?
> 
> A brand new ebuild would start no votes and no rating
> which indicates it is not been thoroughly used and hence
> should only be used by those willing to deal with problems.
> As more people use the ebuild, they rate it and it gets
> more ratings. If the ratings are bad, people will know
> to stay away from it. If the ratings are good, people will
> known that the ebuild should not have problems.
> 
> I can't think of any reason why this would not work. If anyone
> knows of one I would like to hear it.
> 

I think it's a good idea, but still there should be a firm barrier
from what goes in to "official" distribution and what is
in the middle zone. This rating could apply to both but I
think its only really useful in the middle zone (purgatory).

  What kind of interface for voting do you have in mind ?
(how to vote + how to read the rate. integrate with emerge ... ?)

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Jeremiah Mahler]

On Sun, Jun 09, 2002 at 02:46:08PM -0400, Marko Mikulicic wrote:
> 
> >>
> >>_______________________________________________
> >>gentoo-dev mailing list
> >>gentoo-dev@gentoo.org
> >>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> >>
> >
> >Marko, I am not answering your question, but I also have
> >some similar ideas.
> >
> >What about a rating system for ebuilds?
> >
> >A brand new ebuild would start no votes and no rating
> >which indicates it is not been thoroughly used and hence
> >should only be used by those willing to deal with problems.
> >As more people use the ebuild, they rate it and it gets
> >more ratings. If the ratings are bad, people will know
> >to stay away from it. If the ratings are good, people will
> >known that the ebuild should not have problems.
> >
> >I can't think of any reason why this would not work. If anyone
> >knows of one I would like to hear it.
> >
> 
> I think it's a good idea, but still there should be a firm barrier
> from what goes in to "official" distribution and what is
> in the middle zone. This rating could apply to both but I
> think its only really useful in the middle zone (purgatory).
> 
Yes, a "rating" is not a definitive answer such as yes or no.
Good point. Perhaps a rating system with definitive labels.

>  What kind of interface for voting do you have in mind ?
> (how to vote + how to read the rate. integrate with emerge ... ?)

I imagine it as something where the user configures the
minimum level of packages that they are willing to install.
For example, a user might only be willing to install packages
that are stable or rated 4/5 by 20 or more people.

I am not sure how to implement it yet. Where there is a will
there is a way.

> 
> Marko
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Here is my opinion on the whole situation. I think it is
good to allow anyone to make changes for public use,
especially when the process is automated and does not
require any input from an intermediary person. It is very
fast. But it leaves the door open to malicious people.
Rating a package or labeling it as "stable" are possible
solutions for preventing people from using malicious code
or code that is not stable.

So, in summary, the problem I see is that of building a
completely automated development system that is open to
the public and at the same time can give the user ways to
decide in general what level of programs they want to
install (stable, unstable, rated 4/5 or better by 20 or
more people, etc...).

What do you think?

-- 
Jeremiah Mahler
<jmahler@pacbell.net>

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Jeremiah Mahler wrote:

> 
> I imagine it as something where the user configures the
> minimum level of packages that they are willing to install.
> For example, a user might only be willing to install packages
> that are stable or rated 4/5 by 20 or more people.

I'm not sure that many people would like this,
because nothing stops someone to multiple rate a package.
(you can make it difficult, but not so difficult).

It could be good, and perhaps an option for
non production systems used to test gentoo. But I think
that a clean cut somewhere must be made. For
example all packages non labeled definitive are placed
in a category. When you emerge rsync
the files are updated and the rating is contained in the .emerge
"RATING = 5". You can browse packages, install them by hand,
but they should not be used as depend for a stable ebuild.
  This way an administrator has more control over what gets installed
and it can be a bit more relaxed when installing official packages.

I don't know if this could be done better with masks, and here
I would like to hear more experienced gentooers than me.

I have felt the need of something like this because when
when I build a ebuild script and submit I have to wait some long
time. If a friend of mide needs this ebuild a copy it to him,
which then pass it to his friend which fixes a bug, then ....
in the mean time changed something .... chaos.

I think the more difficult part is to develop a policy, which
should not be too restrictive but should also be secure.

> 
> I am not sure how to implement it yet. Where there is a will
> there is a way.

I'm more concerned with the requisites right now.
Implementation is important but you can't implement something
if you don't know what you have to do.

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[George Shapovalov]

Hi guys.

I think you may be interested in taking a look at #1523:
http://bugs.gentoo.org/show_bug.cgi?id=1523
This is a proposal of ebuild submission/processing system, that involves 
streamlined submission, multiple stability levels, votes, even some ideas on 
developer ratings :).
Its implementation is moving not particularly fast I should admit. Quite 
expectedly, as it involves modifications to numerous subsistems and 
resolution of other problems along the way (such as enhanced 
masking/stability levels).
Any thoughts/comments are wellcome!.

George

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

Jeremiah Mahler wrote:

> 
> I imagine it as something where the user configures the
> minimum level of packages that they are willing to install.
> For example, a user might only be willing to install packages
> that are stable or rated 4/5 by 20 or more people.

I'm not sure that many people would like this,
because nothing stops someone to multiple rate a package.
(you can make it difficult, but not so difficult).

It could be good, and perhaps an option for
non production systems used to test gentoo. But I think
that a clean cut somewhere must be made. For
example all packages non labeled definitive are placed
in a category. When you emerge rsync
the files are updated and the rating is contained in the .emerge
"RATING = 5". You can browse packages, install them by hand,
but they should not be used as depend for a stable ebuild.
  This way an administrator has more control over what gets installed
and it can be a bit more relaxed when installing official packages.

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

On Sun, 9 Jun 2002, George Shapovalov wrote:

> Hi guys.
> 
> I think you may be interested in taking a look at #1523:
> http://bugs.gentoo.org/show_bug.cgi?id=1523

I have already read this, and I am working on a well-thought reply to it.
My current interest is the front-end part of the ebuild submission
pipeline. From what I can understand from your code and writings, my
work will be complementary to yours.


Karl T

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

On Sun, 9 Jun 2002, Marko Mikulicic wrote:

> > The new system tries to resolve that.
> 
> What are the main reasions for this latency ?

In my experience, the latency is that each submitted ebuild is usually
malformed in some way. Which means that I have to spend time clean it up
before I commit it. 

Worst example so far was an ebuild that depended on "GLP-2", but did not
have a license set. Of course, what the author meant was that the
package's license was "GPL-2", and he didn't know of any dependencies (so
I had to figure out those as well).

In the end, it turned out that the package was in the public domain, just
to make my day perfect....

But it was such an important package (subjectively), that I elected to
spend the necessary time to essentially rebuild it from scratch.

> I imagine the package need to be tested somehow.

Yes, in the above case, a "screener" script would detect that there is no
package named "GLP-2", and also warn the author that an empty license is
not acceptable.


> How is this "new system" you are talking about ?

It is wonderful ;P

> How is the "old system", from a maintainer perspective ?

It can be very time-consuming. Especially considering bugzilla's
less-than-elegant way of handling uploaded submissions (filenames are
lost).

> What appens "afterwards" ?

Bit rot, usually. How to keep the packages in the tree working slickly
all of the time is a massive problem that we are taking steps to handle,
but there is only so many developers and so little time [and our pesky
users keep submitting bugs and suggestions for improvements that we have
to deal with along the way also... :P]

>   Wouldn't be nice if new ebuilds would committed to
> a middle place (purgatory) where they wait in a queue.
>   But in the mean time audacious users could try the ebuilds
> (simply downloading them with ftp, or ebuild rsyinc-purgatory -> 
> /usr/portage/purgatory) so at least they can be tested.
>   Does it make sense ?

Yes. Variants of this have been suggested already. The first step would be
for end-users to be able to browse the ebuild submission pipeline.
This way, they could see whether the ebuild passes all
automatic conformance tests, whether it actually compiles, comments from
developers (if any).

Also, interested users could download the ebuild (probably packaged in a
.zip file with associated digest, auxiliary files and changelog), so that
they could just unpack/splice it into their local portage tree to test it.

By making this process more open, interested end-users would be able to
help out the development by detecting/fixing/reporting issues at an early
stage.


Karl T

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Paul de Vrieze wrote:
> On Sunday 09 June 2002 08:41, Marko Mikulicic wrote:
> 
>>  Alternatively I could write a dummy client which connects to the
>>bugzilla like a webbrowser and automates the submission.
>>  (I suppose there is not a secure straight connection to the bugzilla
>>backend)
>>
> 
> The problem is not so much the submission itself, but what happens afterwards. 
> New ebuilds take a lot of time to be included in the tree (if you have bad 
> luck)
> 
> The new system tries to resolve that.

are you talking about portage2 ?

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

On Sun, 9 Jun 2002, Marko Mikulicic wrote:

> I want just to avoid duplicate work, in case someone feels
> the need to use, say wmtop, and than wm*; sure they are
> nice apps to start understanding portage, because they are small,
> but if someone already did that three weeks ago without telling .... 
> aargh :-)

Increasing the visibility of which ebuild submissions are in the pipe is
something we'd very much like to do. It is a fairly easy affair, and will
probably be handled in my proposition for a new ebuild submission system.

 
> I would like to help developing a flexible command line submission
> system.  I'm interested in how are you currently organized, how and who
> read the "bug" submissions ... 

Currently, we have a set (with cardinality of one) of bug wranglers 
that traverse the list of incoming bugs periodically, then assign each bug
to a suitable developer.

Then each developer will traverse his bug list, picking out bugs in the
order of subjective importance, and commit fixes/updates to our CVS.

It is a simple, two-step procedure.

>   Alternatively I could write a dummy client which connects to the
> bugzilla like a webbrowser and automates the submission. 

The biggest problem for the maintainers is the varying quality of ebuilds.
Few, if any submissions are correct on the first go, and many of the
bugs/problems identified could be checked programmatically.

Submissions should then be run through a "screening" script that checks
for syntactic and semantic completeness, verifies dependencies,
well-formedness of ebuild, digest, changelog, etc.

If any of these tests fail, the submitter is notified, and no developers'
time is wasted needlessly until the ebuild script follows all the basic
guidelines and its sources actually compile.

>   (I suppose there is not a secure straight connection to the bugzilla
> backend) 

Not afaik, and it will not be a wise path at any rate.

>   I see all this by a user perspective, not as a maintainer; so I would
> like to learn more.

That is excellent, because admittedly, some of us have lost some of that
perspective somewhere along the way.


Karl T

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Karl Trygve Kalleberg wrote:
> 

> 
> The biggest problem for the maintainers is the varying quality of ebuilds.
> Few, if any submissions are correct on the first go, and many of the
> bugs/problems identified could be checked programmatically.
> 
> Submissions should then be run through a "screening" script that checks
> for syntactic and semantic completeness, verifies dependencies,
> well-formedness of ebuild, digest, changelog, etc.
> 
> If any of these tests fail, the submitter is notified, and no developers'
> time is wasted needlessly until the ebuild script follows all the basic
> guidelines and its sources actually compile.
> 

insightful.
Do you have a prototype of this new system or the "screening" script ?

Should the package submitter decide in which cathegory its'
package should go, and how should the RCS string (in ChangeLog + 
*.ebuild's third line) be formatted ?

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

On Sun, 9 Jun 2002, Marko Mikulicic wrote:

> Do you have a prototype of this new system or the "screening" script ?

Not currently. That is why I asked if you could hold out for two more
weeks.

> Should the package submitter decide in which cathegory its'
> package should go ?

Yes. It is excruciatingly difficult to have script figure that one out.


> and how should the RCS string (in ChangeLog + 
> *.ebuild's third line) be formatted ?

Exactly as in the skel.ChangeLog:
$Header: $
and skel.ebuild:
# $Header: $

CVS will fill in the rest upon commit.

Karl T

Re: [gentoo-dev] Contribute many ebuilds at once

[Markus Krainer]

Karl Trygve Kalleberg wrote:
> 
>>and how should the RCS string (in ChangeLog + 
>>*.ebuild's third line) be formatted ?
> 
> 
> Exactly as in the skel.ChangeLog:
> $Header: $
> and skel.ebuild:
> # $Header: $
> 
> CVS will fill in the rest upon commit.

Yes, and of course it fills in the rest in skel.ebuild and
skel.ChangeLog, too. ;)

# /space/gentoo/cvsroot/gentoo-x86/skel.ebuild,v 1.8 2002/05/30 01:54:49 
sandymac Exp

   -Markus-

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Markus Krainer wrote:
> Karl Trygve Kalleberg wrote:
> 
>>
>>> and how should the RCS string (in ChangeLog + *.ebuild's third line) 
>>> be formatted ?
>>
>>
>>
>> Exactly as in the skel.ChangeLog:
>> $Header: $
>> and skel.ebuild:
>> # $Header: $
>>
>> CVS will fill in the rest upon commit.
> 
> 
> Yes, and of course it fills in the rest in skel.ebuild and
> skel.ChangeLog, too. ;)
> 

The CVS docs state that there is no way to selectively
disable kw substitution, but alternatively, couldn't the skel
files be committed as binary files. I suppose that there wouln't be many 
changes to those files, and they are small.
It isn't a big deal, but it confuses new users like me.
Comments ?

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

On Sun, 9 Jun 2002, Marko Mikulicic wrote:

> The CVS docs state that there is no way to selectively
> disable kw substitution, but alternatively, couldn't the skel
> files be committed as binary files. I suppose that there wouln't be many 
> changes to those files, and they are small.
> It isn't a big deal, but it confuses new users like me.
> Comments ?

It is not CVS that fucks this one up, because then it'd look different
(the Header: would still be there, only filled out). I will see what can
be done about it. It is really annoying, because all user-submitted
ebuilds have screwed headers these days.

Karl T

Re: [gentoo-dev] cvs keywords (was: Contribute many ebuilds at once)

[Alexander Holler]

Hi,

--On Sonntag, Juni 09, 2002 20:54:50 -0400 Marko Mikulicic <marko@seul.org> 
wrote:

> The CVS docs state that there is no way to selectively
> disable kw substitution, but alternatively, couldn't the skel
> files be committed as binary files. I suppose that there wouln't be many
> changes to those files, and they are small. It isn't a big deal, but it
> confuses new users like me.
> Comments ?

checkin with -ko.

Alexander

PS: it seems The $Header etc. are getting lost anywhere from the way out of 
the cvs to the rsync. Maybe there's some shell script which interprets 
those files (recognizing $Header and $ as variables and replacing them with 
zero content)

Re: [gentoo-dev] cvs keywords (was: Contribute many ebuilds at once)

[Marko Mikulicic]

Alexander Holler wrote:
> Hi,
> 
> --On Sonntag, Juni 09, 2002 20:54:50 -0400 Marko Mikulicic 
> <marko@seul.org> wrote:
> 
>> The CVS docs state that there is no way to selectively
>> disable kw substitution, but alternatively, couldn't the skel
>> files be committed as binary files. I suppose that there wouln't be many
>> changes to those files, and they are small. It isn't a big deal, but it
>> confuses new users like me.
>> Comments ?
> 
> 
> checkin with -ko.

yes but is not selective; it applies to all files.

> 
> Alexander
> 
> PS: it seems The $Header etc. are getting lost anywhere from the way out 
> of the cvs to the rsync. Maybe there's some shell script which 
> interprets those files (recognizing $Header and $ as variables and 
> replacing them with zero content)

as pointed out by Karl is probably not CVS's fault.
But still I don't understand how you can put a file
containing a keyword in CVS without being substituted
and having another file in the same repository to which this
doesn't apply. All docs I read about CVS stated that they own
documentation used some forms of escape (ex: @asis{} in texinfo)
to avoid it in the examples. How is it solved in the skel ?

Marko

Re: [gentoo-dev] cvs keywords

[Alexander Holler]

Hi,

--On Sonntag, Juni 09, 2002 23:46:30 -0400 Marko Mikulicic <marko@seul.org> 
wrote:

>> checkin with -ko.
>
> yes but is not selective; it applies to all files.

It applies to files given as arguments. So, at the initial checkin you just 
have to make a separate checkin for the files you want to turn off 
substitution. E.g.

cvs add myfile1 myfile2 ...
cvs add -ko myfileWithouSubstitution1 myfileWithouSubstitution2 ...
cvs add -kb myBinary1 myBinary2 ...

Because this had to be done just once (initial checkin), where's the 
problem?

Alexander

Re: [gentoo-dev] cvs keywords

[Marko Mikulicic]

Alexander Holler wrote:
> Hi,
> 
> --On Sonntag, Juni 09, 2002 23:46:30 -0400 Marko Mikulicic 
> <marko@seul.org> wrote:
> 
>>> checkin with -ko.
>>
>>
>> yes but is not selective; it applies to all files.
> 
> 
> It applies to files given as arguments. So, at the initial checkin you 
> just have to make a separate checkin for the files you want to turn off 
> substitution. E.g.
> 
> cvs add myfile1 myfile2 ...
> cvs add -ko myfileWithouSubstitution1 myfileWithouSubstitution2 ...
> cvs add -kb myBinary1 myBinary2 ...
> 
> Because this had to be done just once (initial checkin), where's the 
> problem?

nowhere. I misinterpreted the cvs docs. I should try it out before talking.

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Marko Mikulicic]

Karl Trygve Kalleberg wrote:
> 
> On Sun, 9 Jun 2002, Marko Mikulicic wrote:
> 
> 
>>Do you have a prototype of this new system or the "screening" script ?
>>
> 
> Not currently. That is why I asked if you could hold out for two more
> weeks.

After seeing one of my applets in a emerge rsync I decided to submit
to bugzilla the whole stuff befere someone like me builds packages which
are already build. But In two weeks I'have another bundle, dont worry :-)

>

What if a new category should be created, simply use it's name ?


> 
>>and how should the RCS string (in ChangeLog + 
>>*.ebuild's third line) be formatted ?
>>
> 
> Exactly as in the skel.ChangeLog:
> $Header: $
> and skel.ebuild:
> # $Header: $
> 

my /usr/portage/skel.ChangeLog contains:

# /space/gentoo/cvsroot/gentoo-x86/skel.ChangeLog,v 1.4 2002/05/30 
01:54:49 sandymac Exp

it seems that CVS completed something that should not be completed.

Marko

Re: [gentoo-dev] Contribute many ebuilds at once

[Karl Trygve Kalleberg]

> my /usr/portage/skel.ChangeLog contains:
> 
> # /space/gentoo/cvsroot/gentoo-x86/skel.ChangeLog,v 1.4 2002/05/30 
> 01:54:49 sandymac Exp

Yes, that is absolutely wrong.

Karl T

Re: [gentoo-dev] cvs keywords (was: Contribute many ebuilds at once)

[Alexander Holler]

Hi,

--On Sonntag, Juni 09, 2002 18:11:56 -0400 Marko Mikulicic <marko@seul.org> 
wrote:

>> # $Header: $
>>
>
> my /usr/portage/skel.ChangeLog contains:
>
># /space/gentoo/cvsroot/gentoo-x86/skel.ChangeLog,v 1.4 2002/05/30
># 01:54:49 sandymac Exp
>
> it seems that CVS completed something that should not be completed.

If there was a $Header$, then there would be a $Header: blabla $.

Alexander

Re: [gentoo-dev] cvs keywords (was: Contribute many ebuilds at once)

[Markus Krainer]

Alexander Holler wrote:

>> my /usr/portage/skel.ChangeLog contains:
>>
>> # /space/gentoo/cvsroot/gentoo-x86/skel.ChangeLog,v 1.4 2002/05/30
>> # 01:54:49 sandymac Exp
>>
>> it seems that CVS completed something that should not be completed.
> 
> 
> If there was a $Header$, then there would be a $Header: blabla $.

It seems, the cvs option '-kv' (generate only the values for keywords)
was used.

   -Markus-

Re: [gentoo-dev] Contribute many ebuilds at once

[Justin Lambert]

On Sunday 09 June 2002 10:39 am, Karl Trygve Kalleberg wrote:

> Increasing the visibility of which ebuild submissions are in the pipe is
> something we'd very much like to do. It is a fairly easy affair, and will
> probably be handled in my proposition for a new ebuild submission system.

I haven't really developed the idea sitting around in my head yet but trying 
to piece all of the ideas floating around for an interface (note: i am not an 
interface design person so this could be way wrong).  Would it make sense to 
have maybe a heirarchial view for submitted ebuilds for where their creator? 
thinks they should go in the portage tree.  Maybe on the views have different 
icons showing which tree has new ebuilds that need testing and it would be 
easier for people that only like to test, for example, chat programs (assume 
there are these people) to focus on their area of expertise.  I don't know if 
the new ebuild submission thing will be something that will help this problem 
or not.  I also could be way out in left field.

> The biggest problem for the maintainers is the varying quality of ebuilds.
> Few, if any submissions are correct on the first go, and many of the
> bugs/problems identified could be checked programmatically.
>
> Submissions should then be run through a "screening" script that checks
> for syntactic and semantic completeness, verifies dependencies,
> well-formedness of ebuild, digest, changelog, etc.

It wouldn't be very hard to write a recursive descent parser to run through an 
ebuild would it?  I can try to whip something out myself if needed or work 
with someone to write possibly a perl script that can be run on the files 
after an ebuild is submitted, before the confirmation page saying that they 
tested the layout and formality requirements.  The biggest problems I'd have 
with this is that I know a very little bit of python and don't have a whole 
lot of experience with complex ebuilds.  I don't think it would be super hard 
with basic ones though.  Let me know if this is something that is of use and 
someone would like to help me with it.


Justin Lambert