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
I need/want/would like to build new node 6 for EL6, but gcc is too old.
For that reason, I'd like to use devtoolset-4-gcc, but the build fails
(obviously) because the package doesn't exist.
So, is there a way to make that work somehow?
I am not sure about enabling external repos during build, maybe someone
will be wiser.
Here's the build:
On 18 October 2016 at 06:26, Steven Roberts <strobert(a)strobe.net> wrote:
> EPEL packages for a new rsnapshot version (1.4.2) have been built and
> available in testing.
> There are many bug fixed in this release. From upstream the config file
> should be comptabile with the existing 1.3.1 currently in EPEL.
> However given new upstream maintainer/hosting, it was about seven years
> between upstream releases, and rsnapshot is used for things like
> backups, we are taking extra caution with this release.
> So we are emailing this list to get extra notice and we are planning on
> at least 4 weeks in testing and hoping to get some good testing and
> karma reflected before moving to push to stable.
> the bugzilla bug:
> the bodhi links for each EPEL version:
> Also, thanks to new co-maintener for the rsnapshot package James Hogarth
> for getting the actually mods, builds put together.
As an update to the announcement, it's been noted in the Fedora users
mailing list that the log file had a change of syntax at 1.3.2 (we
were on 1.3.1) back in 2012 ...
The logfile now has the timestamps in ISO 8601 format rather than
apache-like so if any parsing or logstash tools are being used against
the rsnapshot logs they will need to be updated to account for this
epel-announce mailing list -- epel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to epel-announce-leave(a)lists.fedoraproject.org
As previously agreed on epel-devel and by the EPEL Steering Committee,
I have pushed the Mono 4.2 packages and packages depending on it to
epel-testing on EL7.
These updates will sit in epel-testing for a significant period of
time to allow adequate notice and time for testing.
I hope to push them to stable at around the time when CentOS 7.3 is released.
The old Mono 2.10 packages have been totally outdated, and I wonder if
they still have been used at all. If you still have your own software
running with Mono 2.x, and have problems rebuilding towards Mono 4,
let me know. We have been through that for quite a number of packages
for Fedora 23, and most issues can be solved...
Please do test thoroughly, give positive/negative karma, and open bug reports.
EPEL6 - MongoDB 2.4.x
EPEL7 - MongoDB 2.6.x
Upstream supports only upgrade to next major version. So from 2.4 it is supported only to 2.6.
Therefore I kept MongoDB 2.6 in EPEL7 (even two next major versions are released).
But MongoDB 2.6 is going to EOL (probably this week), so MongoDB in EPEL7 will be unsupported.
How to solve this - what EPEL/Fedora guidelines says about upgrades? Upgrade EPEL6 to EPEL7? Or keep unsupported version in EPEL7?
I've post same question to devel(a)lists.fp.o  - there I was noticed that epel-devel would be better.
Upstream says that there might be some minor incompatibilities between major releases and it suggests users to check and fix these incompatibilities before upgrade. So these upgrade might break some users instances.
I like answer of Peter Robinson  - upgrade to next major version. Left some time for users to upgrade to this new version and after that prepare major upgrade again.
Does this comply to guidelines? (If I send some announcement to this listbefore)