[Arm-dev] a plague farm ?

[Troy Dawson]

On Thu, Apr 23, 2015 at 10:26 AM, Gordan Bobic <gordan at redsleeve.org> wrote:

> On 2015-04-23 16:08, Karanbir Singh wrote:
>
>> On 04/23/2015 02:38 PM, Troy Dawson wrote:
>>
>>>
>>> On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists at karan.org
>>> <mailto:mail-lists at karan.org>> wrote:
>>>
>>>     On 17/04/15 14:38, Mandar Joshi wrote:
>>>     >> I can work with Online/Scaleway to build the first CentOS image
>>> for
>>>     >> their systems.
>>>     > I would like to join the CentOS ARM effort officially.
>>>
>>>     nothing official here :) people doing the work are in, people hanging
>>>     around talking and hand waving are not.
>>>
>>>
>>> This doesn't make any sense.
>>> So, if people want to join the CentOS arm effort,  they cannot, unless
>>> they are already part of the CentOS arm effort?
>>> How can people change from "hand waving" to actually doing work?
>>>
>>
>> as you can see, there is no real 'CentOS Arm Effort' - whatever is
>> happening is being done by people on their own, on their own hardware
>> using the centos sources from git.centos.org or srpms.
>>
>> hoping to fix that with a plague setup, across some nodes, that people
>> can ask for access to and then pool in the work being done.
>>
>
> Having been doing exactly this kind of thing for the past 3-4 years with
> the RedSleeve project, IMO the most important part of this kind of an
> effort,
> if it is to be a community effort that scales, is coordination.
>
> Ultimately, anyone can take a F19 image and packages and write a 20
> line bash script to rebuild the EL7 src.rpms using mock, then do it
> again based on the packages that fell out of the first stage, and
> then doing it again based on the package that fall out of the second
> stage just to make sure. That just takes CPU time, and situation
> today is massively less bad than it was about 4 years ago when I first
> started working on it. For example, back the RedSleeve builders were
> all Sheeva/Guru/Dream Plus, with 512MB of RAM and running on an NFS
> rootfs.
>
> Today you can get a single 8-core ARM board with 4GB of RAM, which
> will outright outperform my entire old build farm on it's own, and
> avoid the complications of running on NFS by having a SATA port
> (running NFS root on the build directory caused some package self
> tests to fail, at least back on EL6).
>
> The part that is human time consuming is fixing all the packages
> that refuse/fail to build. On EL6 there was over a hundred. On EL7,
> I'm told it's less bad, but I'm not so sure - having tried to build
> an i686 EL7 build, there seems to be a lot of spurious build breakages
> so it isn't a plain, simple, out of the box "just works" process.
> Having some way to distribute that effort is the difficult part to
> coordinate. Raising tickets is cumbersome, and some issues often
> disappear on a subsequent rebuild (and some things fail in stage 2
> even though they build in stage 1 based off Fedora packages).
>
> If anyone has a sensible method to automate such a process, I would
> love to hear about it. Otherwise it takes somebody to take charge
> and effectively perform such coordination as almost a full time job
> until the initial complete release build is rolled out (after that
> the effort reduces dramatically).
>

I wish I could say I had a nice way.  It seems to be 90% of the work on 10%
of the packages.
For the most part, doing the build loop like you said works for alot of the
packages.  The majority of the packages that needed tweaking are the ones
that RHEL7 has marked as x86_64 only.
I will give this tip.  Don't start on Fedora 20 for your build repo, or
even use it partway through.  I did that on my arm build and was delighted
that so many package built.  Then after a month I started checking
dependencies on them.  Hardly anything would install because of the crazy
dependencies.  I think libpng was the biggest issue.  It wanted the version
of libpng in Fedora 20, which was newer than the version in RHEL7.  Had to
rebuild the whole thing again.


Troy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20150424/f3129d12/attachment.html>