Hi, Russ - thank you for pointing to the redsleeve package - I did not know about it -
and when I was looking for such last Summer, it did not turn up - I ended up using
Fedora 20 for my test system, but prefer EL based for final production.

But with the redsleeve web currently down ("Error establishing a database connection"),
do you know if they provide a preinstalled rootfs image? One that is easy
to network-boot (via NFS-Root). My ARM hardware cannot run any installer (requires
a custom linux kernel, low on RAM and not too speedy). Fedora 20 provides rootfs images and
was easy to network boot (NFS-Root). And for development, network boot is so much
faster and easier compared to writing and rewriting the very slow SD flash cards,
plus having to move the flash card from crashed arm to PC and back.


K.O.


On Thu, Jul 10, 2014 at 11:40:48AM -0400, R P Herrold wrote:
> On Thu, 10 Jul 2014, Lamar Owen wrote:
> 
> > I'd like to see ARM as well, but IA-32 is lower-hanging fruit, since many of
> > the packages are already built and the same hardware can build it as builds
> > x86_64.
> > 
> > As smooge said, the ARM port needs builders (and by that I assume he means the
> > hardware on which to build, or a cross-compiler devchain that works for mock
> > building).
> 
> [I understand the RH history and desire for 'builds for 
> record' to be on 'real' hardware.  I can advocate until I am 
> blue in the face as well as the rest of you that the compiler 
> is just moving ((optionally ascii, altho' ebcdic also works in 
> Z arch ... )) 8-bit text string tokens aroung and emitting new 
> bit patterns, BUT, there is less room for excuses / blind 
> paths for binary partition debugging when one is 'going 
> native']
> 
> The round one 'starter yeast' for the clefos s390 / s390x RHEL 
> 6 sources rebuild ['Azure Duck'] was build entirely under a 
> stable of x86_64 under Hercules -- not pretty, nor fast, but 
> not all that bad either.  Later rounds moved through native 
> re-compiles to remove and doubt as to self-hosting, or 
> objection as not 'built on native'
> 
> As I recall, there is a qemu arm VM that runs under libvirt 
> out there.  No reason not to start there
> 
> I and others have a wide stable of 32 bit arm hardware, and 
> saw a 64 bit devkit board announcement by ARM earlier this 
> week; and there is the overdue AMD offering to the same effect 
> which I am waiting to see in the market; after the Blacksburg 
> fudcon, I also 'infected' jbj with an interest in such and he 
> too has a build farm.  Most compelling of course is Gordon 
> Bobic's 'redsleve' rebuild of the RHEL 6 sources under arm 32
> 
> It really seems more having a trusted central binary [and 
> sources] archive and a mechanism for a federation of 
> mutually trusted builders to do retrieval, build, and return 
> of binary fruit, is the issue
> 
> Suporting as low as one person in such a federation is of 
> course possible, but then the tragedy of the commons costs, 
> vs benefits returned, rears its head
> 
> I personally implicitly trust each enumerated person in the 
> CC list as we have been working together since 'testers-list 
> days' save Gordan --- perhaps we just need to tactically solve 
> the management of ad hoc federations, and the minimal glue for 
> diing the 'distributed' -- the latter really a solved problem 
> already with buildbot C and C
> 
> Thoughts?
> 
> My 0.02
> 
> -- Russ herrold

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada