Buildfarm build_test script on an embedded device.

[Christopher R. Hertel]

Andrew Bartlett wrote:
:
> Did it really succeed?  There are a number of fixed (in mins) timeouts
> that should have fired well before 14 hours, so I'm sceptical.  Can I
> get those logs?

Absolutely.  I did offer them early and I'm happy to send them to you off-line.

...and the first run was 23.5 hours.  :)

I have no experience reading through these logs, so your review would be
very welcome.  Even though we are in agreement that adding the Dockstar to
the build farm would be counter-productive, there is still a great deal to
be learned from running the tests themselves.

:
>> Why are you specifically targeting x64?
> 
> Or x86 - just something that doesn't need emulation on a modern CPU, so
> we can just look for Arch-Linux oddity, and developers can set up a
> local Arch Linux box to match the build farm when required. 

I am particularly interested in Arch-Linux ARM, but you covered that as well.

>> Note that the Dockstar is an ARMv5 and that the ARMv5 is somewhat out of
>> date.  There are multi-core ARM processors out now.  I will see if I can get
>> hold of something else to try.
> 
> Getting something with a lot of ram will help a lot. 

Agreed.  :)

:
> If you just want to make the box available, then that's just a matter of
> accepting SSH logins.  The trouble is that the build farm is very much a
> one-size-fits-all solution right now, and the resource demands have
> escalated dramatically in the 10 years I've been involved with it. 

Thanks for the explanation.  Yes, that's what I was getting from your
original message.

>>> We have had slow or 'only once per day' machines in the build farm
>>> before, and fixing them even for simple errors has proved incredibly
>>> tedious.  
>> Are we fixing the machines or the build here?  Please explain.  If the build
>> fails on such a platform, I claim it is still a bug.
> 
> There are a large number of failing boxes on the build farm.  These are
> real bugs, but they also require very real amounts of developer time to
> try and fix.  

...but that would be the point, wouldn't it?

> The difficulty here is the same that was faced for all bugs before
> autobuild - that the developer who sinks time into fixing the tests
> typically is not the domain expert for the code that breaks it.

Fair 'nough.  I would be much more interested in a focused effort.

:
> If you can find a box that is around 10x more powerful (in ram and CPU)
> that might help.  I'll know more when I see the logs.

My gut reaction is that it's primarily the RAM and I/O speed.  The Dockstar
has only 128MB of RAM plus a generous amount of swap, but the swap is on the
same drive as the build environment and it's just a USB-connected 2.5"
laptop drive.  Not much in the way of I/O speed.

Logs on the way...
(Separately)

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org