SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
R P Herrold <[log in to unmask]>
Reply To:
R P Herrold <[log in to unmask]>
Date:
Thu, 10 Jul 2014 11:40:48 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
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

ATOM RSS1 RSS2