Hi Kevin and EPEL,
Is there any sign of EPEL 7 support for Wine 32 yet? The
lack of Wine 32 is keeping me on SL 6.6 and it is starting
to drive me nuts!
EPEL: think of the guilt you would feel if I get
stuck in an insane asylums over the lack of wine 32
support! Seriously, the guilt would haunt you to the end
of your days. Okay, maybe not, but still ...
Many thanks,
-T
Hey, I had to try. If guilt doesn't work,
I am really good at insincere compliments too.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Could some please run a repoclosure/broken deps report for EPEL7 with
RHEL7.2? I tried, but I only have rhel7 server which is missing some
components in the EPEL7 buildroot. So I think this will have to be done
by releng. It seems that there are some soname bumps in RHEL7.2:
libvala-0.20.so.0 -> libvala-0.26.so.0
libical.so.0()(64bit) -> libical.so.1()(64bit) (this seems to have the
biggest impact)
Also, openmpi was bumped from 1.6.4 to 1.10.0, but there is a
compat-openpi164 package so no dep breakage. But it probably makes
sense to rebuild openmpi packages.
Plus I think there are a fair number of other broken deps in EPEL that
have gone unnoticed for a while.
Thanks.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com

Hi All,
So it's been discussed a little about doing a EPEL bootstrap for new
architectures. We have a number of arches wanting to do this (ppc64le,
aarch64, i686, s390x). So ppc64le will be our first and this is an
overview of the process I'll be using to do it. Once it's complete
I'll do a better write up as I suspect some things will evolve as we
go on down the path.
So the general overview of the process is:
1) add new builders to koji (ppc64le complete)
2) create separate inherited build target and tag
(epel7-archbootstrap) with associated architecture
3) run scratch builds in that target using the git commit hashes from
the latest builds in the epel7, epel7-testing and epel7-candidate tags
4) For each scratch build completed, run mergeScratch(task_id)
5) when all builds are complete enable the arch on the main epel7 target
6) sign all new packages
7) update bodhi, pkgdb, mash configs
7) mirror out
I have some scripts to do the above which I'll publish for reference
once I've cleaned them up a little.
This process isn't perfect. The new arch builds may not have the exact
same build dependency NVRs because, at least in the case of ppc64le,
the first EL7 release with .el7 distags is 7.2 and obviously most of
epel7 is built against < 7.2. The mergeScratch koji API call imports
all the build logs which helps mitigate this from a debug PoV. There's
not really a good way to deal with this, and obviously once the new
arch is enabled they'll be the same moving forward. I don't see it as
an issue really, just making note of it here for reference.
Looking at the current stable epel7 builds, as of a couple of days
ago, we have around 4763 source packages, of which 2686 are noarch
(and hence don't need to be rebuilt) and a touch under 2077 (2077 at
time of check) are arch dependent.
Let me know of any queries, questions, concerns etc
Peter