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 uwe@hermann-uwe.de Acked-by: Stefan Reinauer stepan@coresystems.de
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
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.
* Richard Smith smithbone@gmail.com [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
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.
maybe this: svn diff send proposed patch to test@linuxbios.org 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
* Richard Smith smithbone@gmail.com [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.
* ron minnich rminnich@gmail.com [061027 20:25]:
maybe this: svn diff send proposed patch to test@linuxbios.org 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 ;-)
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.
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.
* Uwe Hermann uwe@hermann-uwe.de [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.
-
Anton -
LinuxBIOS information -
Richard Smith -
ron minnich -
Stefan Reinauer -
Uwe Hermann