On Thu, Apr 23, 2015 at 10:26 AM, Gordan Bobic <gordan@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@karan.org
<mailto:mail-lists@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