On Tue, 23 Jun 2015 13:52:41 -0400
Filipe Miranda <fmiranda(a)redhat.com> wrote:
> On Jun 23, 2015, at 1:17 PM, Stephen John Smoogen
> <smooge(a)gmail.com> wrote:
> On 23 June 2015 at 10:29, Filipe Miranda <fmiranda(a)redhat.com>
>> I would like to suggest a great addition to the EPEL, the z Systems
>> architecture (s390x).
>> I have seem a great number of requests around EPEL for z Systems,
>> its definitely a growing platform around Linux as IBM keeps
>> offering better and more efficient servers that are basically a
>> datacenter in a box - which is a great way for customers to reduce
>> costs by consolidating Linux workloads. EPEL repository to s390x
>> can be a great way to allow customers to try an unsupported
>> package that still not available to RHEL on z Systems - that can
>> in time mature, and can skip some of the processes to make into
>> the RHEL for z Systems distro.
>> The idea is to offer more technology options (Fedora Packages) to
>> customers using RHEL on z Systems - this can flag us what packages
>> are customers really interested into for RHEL on z Systems that
>> are still not available in the Enterprise distro.
>> Please let’s brainstorm this suggestion here, IBMers, community
>> members, Fedora members, RedHatter, you are all welcome to join
>> this discussion.
> 1) How would such items be built? The rest of EPEL is built with our
> builders in PHX2. We don't have an s390 system in PHX2. Build
> engineering requires access and the ability to 'rebuild' builders
> when needed. EPEL has no
We (Red Hat) have a z Systems server in Westford, and the Fedora for
s390x is built over there, maybe we could use the same environment
(same LPAR, just add a few VMs with Fedora to do so) maybe Dan Horak
can help sort his out.
yes, technically Koji allows the builders to be anywhere on the
Internet and with some caching there shouldn't any visible slowdown
when compared to local builders. This is how Fedora/s390x
infrastructure is designed.
> 2) How would developers test these builds? Much of the pushback
> have in EPEL for other architectures is that developers have no
> systems which they can test to see why something is broken or not.
> This means we end up with a large amount of spec files with
> ExcludeArch: ppc etc etc. The lack of hardware and cost-free
> software (eg CentOS port) pretty much make any build problem get
> the hammer of ExcludeArch)
This can be addressed maybe by IBM, by offering build systems to help
developers test their packages.
Ack, that's something for IBM, from Red Hat side it would require
providing RHEL for System z subscriptions to such devel systems.
Currently we have one public guest running Fedora available to the
community, so it should be solvable. In addition to real HW there are 2
solutions capable running current Linux distributions under emulation.
From the quality point of view we are able to build 90+ percent of
packages in recent Fedora, so I don't expect many new issues related to
running in EL environment. But I can be wrong and it is also a place
where IBM engineers can step in :-) I would rather expect runtime issue
than build time ones.
> 3) There isn't really a way to tell you which packages
> interested in for two reasons:
> a) If we build packages for an arch, then every EPEL package gets
> built for it (except those with the ExcludeArch hammer)
The idea is to start with what IBM thinks it will be good to have
there, then if the project gets traction, we can have feedback from
customers using bugzilla.
> b) User logs of yum does not show which package is requested... it
> will show an estimate of users which for PPC is mainly engineers
> inside of RH and IBM and a handful of sites. From talking with
> people using PPC EPEL, they mirror it internally and no usage is
Thank you for sharing these thoughts Stephen, let’s see what others
have to say about it,
There are other questions like do we know that current content of EPEL
will build, etc.
And I also suppose we are talking about EPEL-7 (and up).