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)
The following message concerns darktable major update 2.x (actually on
EPEL7 = 1.6.x)
My interpretation of EPEL packaging guidelines  is that the major
update darktable 2.x should be pushed as a darktable2 package .
Moreover, once you read XML files (generated by darktable) of photos
using darktable 2.x, you will not be any longer able to use them with
Kalev Lember said  about :
I think this applies mostly to libraries in order to keep ABI/API stable
in EPEL. I don't think the policy is meant to keep leaf desktop apps on
old, unsupported versions forever.
Since Kalev is a reliable member of the community, I want to listen to
his suggestion, but since I am not 100% sure, I would like to ask for a
feedback from EPEL mailing list members.
Thank you for your time