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 ...
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
What's the status of EPEL7 on i686? I haven't heard anything in a few
months but last I heard EPEL was going to be trialed on antoehr alt-arch
before i686, was this done yet and what's the current hold-up?
I have no idea if there is any interest in this or not. I managed to get the
EPEL7 python34 package to build on EL6 with a few modifications. Is there any
interest in supporting this?
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
As some of you may know, nodejs package that is present in
EPEL is pretty outdated. The current v0.10 that we have will
go EOL in October and npm (package manager) is already not
Currently, upstreams' plan is to have two versions of Long
Term Support (LTS) at once, one in active development and one
in maintenance mode.
Currently active is v4, which is switching to maintenance in
April and v6 which is switching to LTS in October.
This is also reason why we would like to skip v4, although
both will get security updates. Nodejs v6 also comes with
newer npm and v8 (which might best be bundled, as it is in
Fedora and Software Collections) (v8 might concern ruby and
database maintainers, but old v8 package still remains in
There was also an idea to have both LTS versions in repo,
but we're not quite sure, how we'd do it and if it's even a
Also, another thing is, if it is worth of updating every year
to new LTS or update only after the current one goes EOL.
According to guidelines, I'd say it's the latter, but it's
not exactly how node development works and some feedback from
users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6,
v4: will update sooner, shorter support (2018-04-01)
v6: longer support (2019-04-01), *might* break more things,
won't be in stable sooner than mid-October if everything
Also need feedback from users.
I hope I didn't forget anything important.
.the update koji-1.10.1-8.el6 has a require of python2-multilib which is only
added to python-multilib-1.1-5.el6 (and later), so the parallel push of
python-multilib-1.1-4.el6 does not satisfy the dependancy.
the highest version of koji without the dependancy is koji-1.10.1-6.el6.
we are discussing in this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1220138 the work that
would be required to upgrade Mono in Epel.
I am aware that this is a major upgrade, and according to  it
should be avoided.
But Mono is that old in Epel7 already, so the discussion currently
goes into the direction that an upgrade is better than nobody using
Mono in Epel at all.
I would like to upgrade to the latest stable Mono version, which is
4.2 at the moment. That is in rawhide already, F23 has Mono 4.0.
What do people think on this list?
Do I need to create a Fesco ticket to request permission to upgrade
Mono in Epel7, and to do a bootstrap similar to Mono 4 in Fedora ?
Thanks for any hints and suggestions,
Recently, I've been participating in some discussion as to how to enable
C++11 support for EPEL builds. Specifically, R (and its large universe
of addons in CRAN) would benefit significantly from C++11 support.
After much discussion, it seems like the only sane way to do this is to
use the Red Hat Developer Toolset (for el6 and el7). It is my
understanding that all RHEL customers (and CentOS users) should be able
to enable this repository without restrictions.
I'd like to propose that we enable the Developer Toolset repo in EPEL
and allow packages to depend on it. Thoughts?