Buildfarm build_test script on an embedded device.

[Kai Blin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-10-05 05:47, Andrew Bartlett wrote:
> On Tue, 2011-10-04 at 22:24 -0500, Christopher R. Hertel wrote:
>> Andrew Bartlett wrote:

I'm a bit late to the party here, but let me add some comments here.

>>> I think we should support devices this small, for small workloads, but
>>> the Samba build process is not one of these, and the test process is
>>> certainly not one of these.  

No, the current Samba top-level build doesn't even work on 128 MB of RAM
without using swap. It actually might be nice to fix that at some point
as well.

>>> To get better support for Samba on your dockstar, we should instead
>>> ensure that an Arch Linux x64 machine is in the build farm, and if a
>>> sufficiently fast and well-resourced host can be found, that an emulated
>>> Arch Linux ARM machine is in the build farm.  The will help return
>>> errors that developers can reproduce in a local VM (eg their python
>>> insanity) and look at ARM portability issues.  

As Chris indicated, targeting 32bit might be worthwhile, current ARM
platforms are 32bit. I think the focus on ArchLinux in the discussion is
unfortunate, there's a lot of distros that are less braindead in their
approach towards packaging python that also work on ARMv5.

ArchLinux shipping with a broken python default setting is an orthogonal
problem, in my opinion.

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

I've got a dual-core 1 GHz A9-Cortex box with 1 GB of RAM and an SSD
drive. If that's not fast enough for the build farm, we can simply give
up testing for embedded devices and tell people we don't support low-end
systems.

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

Is this documented somewhere? Getting hold of a new system for the build
farm just to get shot down a couple of days later seems like an
inefficient approach to getting a box in.

If the build farm is not the place to make sure we support embedded
devices, what _is_ the proposed method? Do I just run a cron-job based
build on one of my systems that checks if make test worked and then
emails all authors of the git commits between the last build that worked
and the current one that failed?

Cheers,
Kai

- -- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6MGvgACgkQEKXX/bF2FpQG8gCZAQzwU37c1SolDAjdKmyLfjae
W3sAnRIopFJDrSPgmZlwQA0kH+Az0ixr
=E8Vw
-----END PGP SIGNATURE-----