On Tue, 23 Jun 2015 18:29:06 -0400
Bryan Chan <bryan.chan(a)ca.ibm.com> wrote:
Thanks Filipe for initiating the discussion.
Dan Horák <dan(a)danny.cz> wrote on 2015-06-23 02:31:23 PM:
> On Tue, 23 Jun 2015 13:52:41 -0400
> Filipe Miranda <fmiranda(a)redhat.com> wrote:
> > 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
Dan, could you elaborate on the emulation aspect? Do you mean IBM zPDT
and Hercules? I am curious if you are using emulation in the build
yeah, I mean zPDT and Hercules. I haven't tried F-22 on Hercules yet,
but F-21 worked fine there. And I suppose zPDT won't have issues as
well. For the Fedora builds we use native builders on a LPAR from the
Red Hat zEC12.
IBM is currently engaging open-source software companies to
support for the platform. IBM partners can essentially get access to
hardware for development purposes at a discount.
For the community, we have a program called Community Development
System for Linux on z, whereby open source projects can sign up for
free access to Linux guests on our z Systems (for a limited time):
During registration, you can request a RHEL installation. I am not
sure whether it comes with a RHN subscription.
Other community hardware access options are now being considered, and
I hope something more streamlined can be announced soon.
That sounds promising, the IBM Power team is promoting the architecture
on the OpenPOWER hubs (now 4 places across the world) where open source
projects can get their own guests to port/fix their projects.
> From the quality point of view we are able to build 90+ percent
> 16k+ 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.
I would imagine that, when EPEL RPMs are built on z for the first
time, a small percentage of them could be broken. We have some
experience in porting and building for z, and can certainly assist
the package maintainers with debugging build-time problems.
> > > 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.
Unless build farm resource is a concern, I actually like the idea of
building all EPEL packages at once. Like Dan said, there probably
won't be many build issues. But yes, we could also supply a list of
the more important packages, to seed the repository.
One of the first steps towards EPEL should taking the current source
RPMs and start building them using mock (which is one level below the
koji build system for proper EPEL) and publish the results. This step
is important even when there won't be an agreement to merge s390x into
EPEL, because the other options like "secondary EPEL", where the builds
will cloned in similar way as being done for Fedora, or maybe even using
COPR  for the builds will profit from it. Or rather it is the
necessary first step for any solution.
> There are other questions like do we know that current content
> EPEL will build, etc.
> And I also suppose we are talking about EPEL-7 (and up).
EL7 and up is a good start, although it would be really nice to
support EL6 as well; many people still have production systems
running RHEL 6.
yes, I can see the importance of EPEL-6, but lets start with something