[LinuxBIOS] r2477 build service

[LinuxBIOS information]

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2477 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Rename E7520 to e7520, and E7525 to e7525 in the code. The next commit
will then rename the E7520 and E7525 directories respectively.

Signed-off-by: Uwe Hermann 
Acked-by: Stefan Reinauer

Build Log:
Configuration of dell:s1850 has ben broken
Configuration of intel:jarrell has ben broken
Configuration of supermicro:x6dai_g has ben broken
Configuration of supermicro:x6dhe_g has ben broken
Configuration of supermicro:x6dhe_g2 has ben broken
Configuration of supermicro:x6dhr_ig has ben broken
Configuration of supermicro:x6dhr_ig2 has ben broken

If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision will 
be backed out.

Yours truely,
     LinuxBIOS automatic build system

[Richard Smith]

LinuxBIOS information wrote:
> Build Log:
> Configuration of dell:s1850 has ben broken
> Configuration of intel:jarrell has ben broken
> Configuration of supermicro:x6dai_g has ben broken
> Configuration of supermicro:x6dhe_g has ben broken
> Configuration of supermicro:x6dhe_g2 has ben broken
> Configuration of supermicro:x6dhr_ig has ben broken
> Configuration of supermicro:x6dhr_ig2 has ben broken

'been' is mispelled.

Stefan:

What about setting up a testing throw away tree that people can mail 
patches to and have them tested with abuild prior to submitting to the 
list?  That could be the first step for getting it approved.
That way you know its abuild clean before you review it.

The submitter would mail in their patch and it would pull the latest 
rev, apply the  patch, run abuild, and send back the result.

[Stefan Reinauer]

* Richard Smith  [061027 15:18]:
> LinuxBIOS information wrote:
> > Build Log:
> > Configuration of dell:s1850 has ben broken
> > Configuration of intel:jarrell has ben broken
> > Configuration of supermicro:x6dai_g has ben broken
> > Configuration of supermicro:x6dhe_g has ben broken
> > Configuration of supermicro:x6dhe_g2 has ben broken
> > Configuration of supermicro:x6dhr_ig has ben broken
> > Configuration of supermicro:x6dhr_ig2 has ben broken
>
> 'been' is mispelled.

ouch. ;-) thanks for spotting this. Fixed for future releases.
> What about setting up a testing throw away tree that people can mail 
> patches to and have them tested with abuild prior to submitting to the 
> list?  That could be the first step for getting it approved.
> That way you know its abuild clean before you review it.

Are you suggesting a development and a stable tree?

actually you can run abuild locally at any time (and you should!) before
creating a patch.
> The submitter would mail in their patch and it would pull the latest 
> rev, apply the  patch, run abuild, and send back the result.

Is this better than running abuild locally? (besides potential tool
chain issues)

Stefan

[Richard Smith]

> > list?  That could be the first step for getting it approved.
> > That way you know its abuild clean before you review it.
>
> Are you suggesting a development and a stable tree?

No.
> Is this better than running abuild locally? (besides potential tool
> chain issues)

Because on my laptop (which I do a lot of work on) it takes over an
hour to run abuild.  I suspect a lot of people don't run abuild localy
since it takes so long to run.

But you have abuild on a fast machine that I can send my patch to and
in 5 minutes or so I get an aswer then (the developer) seems more apt
to try and check it before you check in breakage.
Also the reviewer could send the patch at the start of the review
process and by the time he is done reviewing have an answer if its
abuild clean or not.

You reviewed this patch and yet it still broke lots of the tree.  So
It seems the author did not run abuild prior to sending the patch.

I propose something similar to what buildrom does.  Pull a copy, apply
patchs, and build but just send the results back to the sender then
discard the tree.

This also let you send up a cross-compile enviroment for testing the
non-x86 boards.

Part of the patch submission requirement would then be to have it
abuild tested.  If the script succeeds then it could issue a
Abuild-clean: <date> or something like that which the submitter would
include in the patch.

Then at least you know its passed abuild before you commit.

[ron minnich]

maybe this:
svn diff
send proposed patch to [e-mail]
test account applies patch, if patch fails to apply, mail back to user
test account runs abuild, if fails, mail back to user
test account send abuild-passed and patch to mailing list for approval
??

ron

[Stefan Reinauer]

* ron minnich  [061027 20:25]:
> maybe this:
> svn diff
> send proposed patch to [e-mail]
> test account applies patch, if patch fails to apply, mail back to user
> test account runs abuild, if fails, mail back to user
> test account send abuild-passed and patch to mailing list for approval

I agree this is a good idea.

Ok, but with romcc we need a small cluster for that to keep the system
from becoming unusable.

Anyone into clusters? ;-)

Then,.. we need a more intelligent mechanism than diff. ie. a changeset
(well, a diff including a construction plan for the tree
 deletes/moves/copies/permission/attribute changes)

And dont tell me GNU arch now ;-)

[Anton]

> Anyone into clusters? ;-)

openMosix is O'k? ;-)

[Stefan Reinauer]

* Richard Smith  [061027 19:49]:
> > > list?  That could be the first step for getting it approved.
> > > That way you know its abuild clean before you review it.
> >
> > Are you suggesting a development and a stable tree?
>
> No.
> > Is this better than running abuild locally? (besides potential tool
> > chain issues)
>
> Because on my laptop (which I do a lot of work on) it takes over an
> hour to run abuild.  I suspect a lot of people don't run abuild localy
> since it takes so long to run.

opening this up for any number of build runs for any number of users 
will render a single machine pretty slow, too.
> But you have abuild on a fast machine that I can send my patch to and
> in 5 minutes or so I get an aswer then (the developer) seems more apt
> to try and check it before you check in breakage.

the 2*1800MHz Opteron does it in 35 minutes, if its the only job
running. And that's only if you don't rebuild the documentation.
Imagine you and Yinghai and Ron working at the same time. This will
render the compile time slower than what your laptop is capable of doing
at the moment.
> Also the reviewer could send the patch at the start of the review
> process and by the time he is done reviewing have an answer if its
> abuild clean or not.

This could be done with a pass-through repository as well. You check
into a devel tree. the devel tree is running an abuild. If it succeeds,
it goes to the stable tree, where hw tests are run. if it works there,
it continues to a "working" tree.

the reason I am talking about trees all the time is that exactly the
move stuff we've been doing recently requires a patch format that
reflects those changes. A check in to a tree is such a diff. We could
also do a branch for each compile run.
> Part of the patch submission requirement would then be to have it
> abuild tested.  If the script succeeds then it could issue a
> Abuild-clean: <date> or something like that which the submitter would
> include in the patch.

one thing, which would also allow a really quick checking on your own
machine (or therefore centrally on linuxbios.org as well) is to drop 
romcc. This will get build times per board from several minutes back to
several seconds.

Which in fact would maybe even allow to compile the tree on checkin and
reject the checkin if something breaks.

This could even be done intelligently. If you check something in to
the flashrom utility, no board needs to be rebuilt. If you check
something in to the k8 part, epias dont have to be rebuilt either.
and we're at about 2 minutes per complete compile run.
> Then at least you know its passed abuild before you commit.

[Uwe Hermann]

Hi,

On Fri, Oct 27, 2006 at 09:28:46PM +0200, Stefan Reinauer wrote:
> one thing, which would also allow a really quick checking on your own
> machine (or therefore centrally on linuxbios.org as well) is to drop 
> romcc. This will get build times per board from several minutes back to
> several seconds.

That would be great, indeed. How would you do that? Maybe make this an
abuild command line option?

Uwe.

[Stefan Reinauer]

* Uwe Hermann  [061028 22:33]:
> Hi,
>
> On Fri, Oct 27, 2006 at 09:28:46PM +0200, Stefan Reinauer wrote:
> > one thing, which would also allow a really quick checking on your own
> > machine (or therefore centrally on linuxbios.org as well) is to drop 
> > romcc. This will get build times per board from several minutes back to
> > several seconds.
>
> That would be great, indeed. How would you do that? Maybe make this an
> abuild command line option?

Actually I thought of it as a LinuxBIOS v3 option where we're not going
to use romcc anymore.

[Uwe Hermann]

Hi,

On Fri, Oct 27, 2006 at 12:49:38PM -0500, Richard Smith wrote:
> Because on my laptop (which I do a lot of work on) it takes over an
> hour to run abuild.  I suspect a lot of people don't run abuild localy
> since it takes so long to run.
>
> But you have abuild on a fast machine that I can send my patch to and
> in 5 minutes or so I get an aswer then (the developer) seems more apt
> to try and check it before you check in breakage.
> Also the reviewer could send the patch at the start of the review
> process and by the time he is done reviewing have an answer if its
> abuild clean or not.
>
> You reviewed this patch and yet it still broke lots of the tree.  So
> It seems the author did not run abuild prior to sending the patch.

Actually, in this case it didn't really break the tree, and I _did_ run
abuild on my laptop prior to sending the patch (yes, it takes roughly
and hour here, too).

The emails saying 'build broken' are simply caused by the nature of my
commit. I was renaming (e.g.) the E7525/ directory to e7525/, in a
two-step process:

1) Change all E7525 occurences in the code to e7525 (which "breaks" the
    tree, as the directory is still called E7525).

2) Move/rename the directory from E7525/ to e7525/ (which "unbreaks"
    the tree again).

This is the easiest way to do it (and the one which preserves svn
history _and_ is the most easy one to read later on), e.g.:

http://tracker.linuxbios.org/trac/LinuxBIOS/changeset/2477
http://tracker.linuxbios.org/trac/LinuxBIOS/changeset/2478

Doing this in one step will make the diffs very huge, ugly and
unreadable.

Maybe we should make abuild only kick in 5 minutes after every commit or
so, so that such two-step commits don't cause an unnecessary 'build broken'
email?

Uwe.