[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
Lance, Just to add a bit more on some of Kevin's comments, this does not break any of your backups and existing backups are both readable and writable with both versions. What is broken is the backup process in some cases, as a Python3 master cannot talk to a Python2 slave, and visa- versa. It would not be as simple as having both installed, as you also need to select which version you are attempting to talk to on the remote machine, and the default configuration assumes that the name is the same on the remote machine, although this is changeable, if you know the full command syntax. I will probably make a special version of rdiff-backup v1.2.8 that can be parallel installed available on COPR, but it won't be part of EPEL, as, for example EPEL-8 will only have rdiff-backup v2. I'm just in discussion with packagers for other distributions to get some common naming for such a package, and it is generally agree that we need the latest version to be rdiff-backup. Also, it is only on a master server, i.e. one invoking remote backups, that you would need have two versions, and some method of selection which one you want to run based on the slave's version. This could be as simple as two separate backup jobs or a much more complicate script. RegardsFrank On Mon, 2020-04-20 at 09:59 -0700, Lance Albertson wrote: > What does the upgrade path look like from if folks are currently > creating backups using 1.x and they suddenly switch to 2.x? Is there > an upgrade path? Is there a way in EPEL to allow for both versions to > exist to ease migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we > don't end up breaking all of our backups. > > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford < > fr...@crawford.emu.id.au> wrote: > > We have pushed into testing and intend to eventually release a new > > version of rdiff-backup which has a significant incompatibly with > > the current distributed version, when used in client-server mode. > > > > The current version is v1.2.8 and written in Python2, while the new > > version is v2.0.0 and written in Python3, and the language change > > breaks client-server mode, due to incompatible data representations > > between Python2 and Python3. In all other respects the two > > versions are compatible including the ability to read and write > > existing backup repositories. > > > > It should be noted that the v1.2.8 was released over 11 years ago > > and while a small number of bug fixes have been added by the > > community, there has been no co-ordinated work for a number of > > years, and no further development will occur on the Python2 > > version. All future work, enhancements and bugfixes, including > > security bugfixes, will be to the Python3 version. > > > > If it is necessary to stay with the Python2 version, it is > > recommended that you exclude rdiff-backup from future updates. > > > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) > > some of the dependencies (python3-pyxattr and py3libacl) are also > > in the testing repositories. > > > > If you have any questions about the update, please contact me. > > > > Frank Crawford > > FAS: frankcrawford > > ___ > > > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > > > To unsubscribe send an email to > > epel-devel-le...@lists.fedoraproject.org > > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > > > ___epel-devel mailing > list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to > epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fedora EPEL 8 updates-testing report
Am 20.04.20 um 22:27 schrieb upda...@fedoraproject.org:
The following Fedora EPEL 8 Security updates need testing:
Age URL
12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8fcf741d7f
cacti-1.2.11-1.el8 cacti-spine-1.2.11-1.el8
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dfc01a6be3
chromium-81.0.4044.113-1.el8
0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5af12f8767
ansible-2.9.7-1.el8
JFYI: I installed (updated) chromium from epel-testing today. What I
noticed was that chromium-common package was not pulled at the same
time while updating (yum update --enablerepo=epel-testing chromium).
At the end I had a chromium-81 and a chromium-common-80 package installed.
Maybe adding something like
Requires: chromium-common = %{version}-%{release}
into the chromium.spec file resolves this?
--
Leon
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8fcf741d7f cacti-1.2.11-1.el8 cacti-spine-1.2.11-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dfc01a6be3 chromium-81.0.4044.113-1.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5af12f8767 ansible-2.9.7-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing htslib-1.9-5.el8 systemd-extras-245.5-1.el8 zimg-2.9.3-1.el8 znc-1.7.5-4.el8 Details about builds: htslib-1.9-5.el8 (FEDORA-EPEL-2020-2a53b59df4) C library for high-throughput sequencing data formats Update Information: Initial import. ChangeLog: systemd-extras-245.5-1.el8 (FEDORA-EPEL-2020-90e46bd3bc) System and Service Manager (optional components) Update Information: Upgrade to 245.5 (and synchronize with systemd-245.5-1.fc33) ChangeLog: * Mon Apr 20 2020 Robert Scheck 245.5-1 - Upgrade to 245.5 (and synchronize with systemd-245.5-1.fc33) zimg-2.9.3-1.el8 (FEDORA-EPEL-2020-5dd960521f) Scaling, color space conversion, and dithering library Update Information: Add additional filter. ChangeLog: * Wed Mar 4 2020 Simone Caronni - 2.9.3-1 - Update to 2.9.3. * Fri Jan 31 2020 Fedora Release Engineering - 2.9.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild znc-1.7.5-4.el8 (FEDORA-EPEL-2020-1871ee819e) An advanced IRC bouncer Update Information: Initial build of ZNC for epel8 ChangeLog: ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Trying to find Sponsor to help me get Sensu Go into EPEL7/EPEL8
Hello, Devin. Welcome to Fedora (EPEL)! On Monday, 20 April 2020 at 17:54, Devin Acosta wrote: > My name is Devin Acosta, I am a Red Hat Certified Architect, and I > have for the past about month now been trying to get Sensu Go (Open > Source Edition) into EPEL 7 / EPEL 8. I have joined the fedora-devel > mailing list and followed the process so far to the best of my > ability. I was wondering if anyone here could provide some assistance, > as this is the EPEL devel list. Unfortunately, we don't have that many sponsors, and many of the existing ones are not very active. Please be patient. > I have opened a bugzilla back on March 30th, located here: > https://bugzilla.redhat.com/show_bug.cgi?id=1818670# > > I have had a few people comment on my SPEC file, and I have made > several modifications per their request on it, but then the track has > gone cold at this point. > > Hoping someone may have some ideas or shed light on what I need to do > in order to try to get this finally into EPEL? I checked out your SPEC file. It's not too bad, but it still needs a bit more work. I put some more comments in the review ticket. Do you intend your package to be built for EPEL only or in Fedora as well? I hope it's the latter, as the package would be very useful for server applications. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 614 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 356 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 354 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 63 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-34295ace88 cacti-1.2.11-1.el7 cacti-spine-1.2.11-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b6453e2708 nrpe-4.0.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ede50a3d8b libasr-1.0.4-2.el7 opensmtpd-6.6.4p1-3.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6783237c17 chromium-81.0.4044.113-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3f2d4cea8a ansible-2.9.7-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e3e05f0ce4 gnuchess-6.2.6-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing htslib-1.9-5.el7 libuv-1.37.0-1.el7 python-pysocks-1.6.8-7.el7 zimg-2.9.3-1.el7 Details about builds: htslib-1.9-5.el7 (FEDORA-EPEL-2020-128fdf5e57) C library for high-throughput sequencing data formats Update Information: Initial import. ChangeLog: libuv-1.37.0-1.el7 (FEDORA-EPEL-2020-9f10160493) Platform layer for node.js Update Information: Update to 1.37.0 Update to libuv 1.36.0 ChangeLog: * Mon Apr 20 2020 Stephen Gallagher - 1.37.0-1 - Update to 1.37.0 - https://github.com/libuv/libuv/blob/v1.37.0/ChangeLog * Fri Apr 17 2020 Stephen Gallagher - 1.36.0-3 - Actually add gating.yaml - Fix build for EPEL 7 * Fri Apr 17 2020 Stephen Gallagher - 1.36.0-2 - Add abidiff ignore file and add ABI gating test * Thu Apr 16 2020 Stephen Gallagher - 1.36.0-1 - Update to 1.36.0 - https://github.com/libuv/libuv/blob/v1.36.0/ChangeLog * Thu Feb 6 2020 Stephen Gallagher - 1.34.2-1 - Update to 1.34.2 - https://github.com/libuv/libuv/blob/v1.34.2/ChangeLog * Wed Jan 29 2020 Fedora Release Engineering - 1:1.34.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Mon Jan 13 2020 Stephen Gallagher - 1.34.1-1 - Update to 1.34.1 - https://github.com/libuv/libuv/blob/v1.34.1/ChangeLog References: [ 1 ] Bug #1790260 - libuv-1.36.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1790260 [ 2 ] Bug #1825715 - libuv-1.37.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1825715 python-pysocks-1.6.8-7.el7 (FEDORA-EPEL-2020-3413d94460) A Python SOCKS client module Update Information: Obsolete/Provide python-SocksiPy in epel7. Fixes bug #1648422 ChangeLog: * Sun Apr 19 2020 Kevin Fenzi - 1.6.8-7 - Obsolete/Provide python-SocksiPy in epel7. Fixes bug #1648422 References: [ 1 ] Bug #1648422 - python2-pysocks upgrade requires python-SocksiPy which conflicts with each other. https://bugzilla.redhat.com/show_bug.cgi?id=1648422 zimg-2.9.3-1.el7 (FEDORA-EPEL-2020-5ac302966d) Scaling, color space conversion, and dithering library Update Information: Add additional filter. ChangeLog: * Wed Mar 4 2020 Simone Caronni - 2.9.3-1 - Update to 2.9.3. * Fri Jan 31 2020 Fedora Release Engineering - 2.9.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild -
[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
On Mon, Apr 20, 2020 at 09:59:17AM -0700, Lance Albertson wrote: > What does the upgrade path look like from if folks are currently creating > backups using 1.x and they suddenly switch to 2.x? Is there an upgrade > path? Is there a way in EPEL to allow for both versions to exist to ease > migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we don't > end up breaking all of our backups. You can stay on the old 1.2 version on all machines and keep on the way you have been. Of course it won't get any updates or fixes, but thats pretty much been the case for the last N years anyhow. Just 'exclude=rdiff-backup-2*' in your yum.conf. For new installs you can get it from koji or from Frank's copr. If you upgrade to 2.0, you need to do so on all clients and servers at the same time so they can talk to each other. The existing backups you have on disk will work with either version. Does that help clarify any? kevin -- > > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford > wrote: > > > We have pushed into testing and intend to eventually release a new version > > of rdiff-backup which has a significant incompatibly with the current > > distributed version, when used in client-server mode. > > > > The current version is v1.2.8 and written in Python2, while the new > > version is v2.0.0 and written in Python3, and the language change breaks > > client-server mode, due to incompatible data representations between > > Python2 and Python3. In all other respects the two versions are compatible > > including the ability to read and write existing backup repositories. > > > > It should be noted that the v1.2.8 was released over 11 years ago and > > while a small number of bug fixes have been added by the community, there > > has been no co-ordinated work for a number of years, and no further > > development will occur on the Python2 version. All future work, > > enhancements and bugfixes, including security bugfixes, will be to the > > Python3 version. > > > > If it is necessary to stay with the Python2 version, it is recommended > > that you exclude rdiff-backup from future updates. > > > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > > the dependencies (python3-pyxattr and py3libacl) are also in the testing > > repositories. > > > > If you have any questions about the update, please contact me. > > > > Frank Crawford > > FAS: frankcrawford > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > > > -- > Lance Albertson > Director > Oregon State University | Open Source Lab > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
What does the upgrade path look like from if folks are currently creating backups using 1.x and they suddenly switch to 2.x? Is there an upgrade path? Is there a way in EPEL to allow for both versions to exist to ease migration? i.e. maybe by creating rdiff-backup2 which supercedes rdiff-backup. Ideally, it would be nice to have some kind of an upgrade path so we don't end up breaking all of our backups. Thanks- On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford wrote: > We have pushed into testing and intend to eventually release a new version > of rdiff-backup which has a significant incompatibly with the current > distributed version, when used in client-server mode. > > The current version is v1.2.8 and written in Python2, while the new > version is v2.0.0 and written in Python3, and the language change breaks > client-server mode, due to incompatible data representations between > Python2 and Python3. In all other respects the two versions are compatible > including the ability to read and write existing backup repositories. > > It should be noted that the v1.2.8 was released over 11 years ago and > while a small number of bug fixes have been added by the community, there > has been no co-ordinated work for a number of years, and no further > development will occur on the Python2 version. All future work, > enhancements and bugfixes, including security bugfixes, will be to the > Python3 version. > > If it is necessary to stay with the Python2 version, it is recommended > that you exclude rdiff-backup from future updates. > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > the dependencies (python3-pyxattr and py3libacl) are also in the testing > repositories. > > If you have any questions about the update, please contact me. > > Frank Crawford > FAS: frankcrawford > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > -- Lance Albertson Director Oregon State University | Open Source Lab ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Trying to find Sponsor to help me get Sensu Go into EPEL7/EPEL8
My name is Devin Acosta, I am a Red Hat Certified Architect, and I have for the past about month now been trying to get Sensu Go (Open Source Edition) into EPEL 7 / EPEL 8. I have joined the fedora-devel mailing list and followed the process so far to the best of my ability. I was wondering if anyone here could provide some assistance, as this is the EPEL devel list. I have opened a bugzilla back on March 30th, located here: https://bugzilla.redhat.com/show_bug.cgi?id=1818670# I have had a few people comment on my SPEC file, and I have made several modifications per their request on it, but then the track has gone cold at this point. Hoping someone may have some ideas or shed light on what I need to do in order to try to get this finally into EPEL? Thanks much. Devin Acosta, RHCA ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-release.
>
> They don't have -testing repos, but -testingx, so you don't accidentally
> enable
> them with dnf --enablerepo=\*-testing.
>
> Usage:
>
> $ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
> pungi-legacy-0:4.1.38-1.el8.2.noarch
> python2-pungi-0:4.1.38-1.el8.2.noarch
>
I also have a simple little tool I use for querying distributions and
repos with DNF: https://pagure.io/rpmdistro-repoquery
It comes with collections of repo definitions for Fedora, CentOS +
EPEL, Mageia, and openSUSE, and might be useful for things like
this...
--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On 20. 04. 20 13:45, Fabio Valentini wrote:
and it seems I
can't even figure out how to determine which EPEL packages require
python*-lockfile.
Take the attached repo files.
They are good for repoquery, adapted from epel-release.
They don't have -testing repos, but -testingx, so you don't accidentally enable
them with dnf --enablerepo=\*-testing.
Usage:
$ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
pungi-legacy-0:4.1.38-1.el8.2.noarch
python2-pungi-0:4.1.38-1.el8.2.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
[epel7]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-testingx]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel7-testingx-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel8]
name=Extra Packages for Enterprise Linux 8 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-8&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-testingx]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel8&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-source]
name=Extra Packages for Enterprise Linux 8 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-8&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
[epel8-testingx-source]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel8&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Upgrade to rdiff-backup in EPEL-7
We have pushed into testing and intend to eventually release a new version of rdiff-backup which has a significant incompatibly with the current distributed version, when used in client-server mode. The current version is v1.2.8 and written in Python2, while the new version is v2.0.0 and written in Python3, and the language change breaks client-server mode, due to incompatible data representations between Python2 and Python3. In all other respects the two versions are compatible including the ability to read and write existing backup repositories. It should be noted that the v1.2.8 was released over 11 years ago and while a small number of bug fixes have been added by the community, there has been no co-ordinated work for a number of years, and no further development will occur on the Python2 version. All future work, enhancements and bugfixes, including security bugfixes, will be to the Python3 version. If it is necessary to stay with the Python2 version, it is recommended that you exclude rdiff-backup from future updates. Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of the dependencies (python3-pyxattr and py3libacl) are also in the testing repositories. If you have any questions about the update, please contact me. Frank Crawford FAS: frankcrawford ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On a RHEL8 machine, doing a dnf repoquery --whatrequires python3-lockfile dnf repoquery --whatrequires python2-lockfile Shows that the following depend on it duplicity python3-fedora pungi-legacy I haven't checked EPEL7 yet. On Mon, Apr 20, 2020 at 4:46 AM Fabio Valentini wrote: > > Hi everybody, > > I took over python-lockfile some time ago because it was FTBFS in > fedora / orphaned at the time, but it's a dependency of some of my > packages. > > However, I have zero interest in maintaining the EPEL branches of that > package, because I have no packages in EPEL myself, and it seems I > can't even figure out how to determine which EPEL packages require > python*-lockfile. > > I have received two PRs for the epel7 branch already, and I don't even > know if they're fine or not, so any help would be appreciated. > > If nobody steps up within the next two weeks, I will probably retire > the epel7 and epel8 branches of python-lockfile. > > Fabio > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Cannot retire epel7 package
It is a bug, I have already opened a ticket for this. https://pagure.io/fedpkg/issue/395 Thanks, guys for letting me know. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Cannot retire epel7 package
On 20. 04. 20 12:13, Miro Hrončok wrote: On 20. 04. 20 6:09, Orion Poplawski wrote: zabbix22 (epel7)]$ fedpkg retire 'Zabbix 2.2 is no longer maintained upstream' Fedora release (epel7) is in state 'current' - retire operation is not allowed. Sounds like fedpkg bug. See https://pagure.io/fedpkg/issue/337 As a workaround, git rm everything, git add dead.package and commit/push manually. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Cannot retire epel7 package
On 20. 04. 20 6:09, Orion Poplawski wrote: zabbix22 (epel7)]$ fedpkg retire 'Zabbix 2.2 is no longer maintained upstream' Fedora release (epel7) is in state 'current' - retire operation is not allowed. Sounds like fedpkg bug. See https://pagure.io/fedpkg/issue/337 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
