[EPEL-devel] EPEL-6 is End of Life in 2020-11
EPEL 6 is End Of Life (EOL) on November 2020. EPEL 6 will be moved to archives in December 2020. Plan ahead now. ___ 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: Continuing playground discussion
On Fri, Sep 4, 2020 at 7:18 AM Troy Dawson wrote: > Step 1 - Approve plan via Steering Committee. > Step 1a - Documents and communication > -- No releng needed. > -- Should be done along the whole way > Step 2 - Update fedpkg and remove all package.cfg from epel8. > -- Can be done by a proven packagers, no releng needed. > Step 3 - Change the inheritance in koji so it inherits from epel8 > -- releng work > --- I don't know how easy / hard this will be for releng > Step 4 - Untag all the things that are "older" in playground > -- currently that is a releng process. There is no way for a > maintainer to retire their package from playground. > -- This needs to happen some time (3 months?) after step 2 is > finished. A time that we can see that people have manually built > their package in playground, versus the automatic builds. So that the > "older" packages are obvious. > -- If we do this as a huge batch, it should be a fairly simple (though > long) step for releng. > Step 5 - Send a daily report > -- Is this similar to what we send for EPEL6,7,8 ? > --- If this is true, I'm in favor of it. If not, then please explain more. > -- I have no idea about the work involved for this. > This plan has been approved by the Fedora Steering Committee. Thus Step 1 has been accomplished. Ya!!! We will start steps 1a and 2 next week. Step 4 - We will determine what "older" means, but right now I think Paul has the right idea that anything with the same NVR is both epel8 and epel8-playground is considered "older", or non-automated. Troy ___ 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] Seeking maintainer for perl-Sys-SigAction
Unfortunately this package has fallen behind a few versions in EPEL7 and is absent in EPEL8. BZ 1807857 has been open since February requesting the package for EPEL8 and it appears nobody has taken this up. I'm not in a position to be able to maintain this package outside work hours for family reasons, so I'm here to ask if anyone in this community would be willing to pick this up. Thanks! ___ 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: Continuing playground discussion
On Fri, Sep 4, 2020 at 11:18 AM Paul Howarth wrote: > > On Fri, 4 Sep 2020 07:18:31 -0700 > Troy Dawson wrote: > > Step 4 - Untag all the things that are "older" in playground > > -- currently that is a releng process. There is no way for a > > maintainer to retire their package from playground. > > -- This needs to happen some time (3 months?) after step 2 is > > finished. A time that we can see that people have manually built > > their package in playground, versus the automatic builds. So that the > > "older" packages are obvious. > > Isn't it likely that builds with the same NEVR (apart from the > disttag) in playground as in EPEL-8 proper are automatic builds rather > than manual ones? > > That would certainly reflect my own usage, where almost all of my > packages would be the same, but my manual build of proftpd is different. > Good point. Check and see if they have the same NVR, except el8 is epel8.playground. I like that better. ___ 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: Continuing playground discussion
On Fri, 4 Sep 2020 07:18:31 -0700 Troy Dawson wrote: > Step 4 - Untag all the things that are "older" in playground > -- currently that is a releng process. There is no way for a > maintainer to retire their package from playground. > -- This needs to happen some time (3 months?) after step 2 is > finished. A time that we can see that people have manually built > their package in playground, versus the automatic builds. So that the > "older" packages are obvious. Isn't it likely that builds with the same NEVR (apart from the disttag) in playground as in EPEL-8 proper are automatic builds rather than manual ones? That would certainly reflect my own usage, where almost all of my packages would be the same, but my manual build of proftpd is different. Paul. ___ 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 751 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 491 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-89ad58d02c golang-1.15-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-49c5f31e92 python-pip-epel-8.1.2-14.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-864bc6779e chromium-85.0.4183.83-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing libudfread-1.1.0-2.el7 xl2tpd-1.3.15-1.el7 Details about builds: libudfread-1.1.0-2.el7 (FEDORA-EPEL-2020-930f4b4e58) UDF reader library Update Information: Initial Fedora package. ChangeLog: References: [ 1 ] Bug #1875315 - Review Request: libudfread - UDF reader library https://bugzilla.redhat.com/show_bug.cgi?id=1875315 xl2tpd-1.3.15-1.el7 (FEDORA-EPEL-2020-c53d91e9fe) Layer 2 Tunnelling Protocol Daemon (RFC 2661) Update Information: Resolves: rhbz#1761700 xl2tpd-1.3.15 is available ChangeLog: * Thu Sep 3 2020 Paul Wouters - 1.3.15-1 - Resolves: rhbz#1761700 xl2tpd-1.3.15 is available - Resolves: rhbz#1875262 Unsupported options 'crtscts' and 'lock' in /etc/ppp/options.xl2tpd - Resolves: rhbz#1869420 xl2tpd.service:8: PIDFile= references a path below legacy directory /var/run/ References: [ 1 ] Bug #1761700 - xl2tpd-1.3.15 is available https://bugzilla.redhat.com/show_bug.cgi?id=1761700 [ 2 ] Bug #1869420 - /usr/lib/systemd/system/xl2tpd.service:8: PIDFile= references a path below legacy directory /var/run/ https://bugzilla.redhat.com/show_bug.cgi?id=1869420 [ 3 ] Bug #1875262 - Unsupported options 'crtscts' and 'lock' in /etc/ppp/options.xl2tpd https://bugzilla.redhat.com/show_bug.cgi?id=1875262 ___ 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 23 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c2936180ed ansible-2.9.12-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-96c4037065 ark-19.12.2-3.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2390c71f9c chromium-85.0.4183.83-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing dnsperf-2.3.4-3.el8 getdns-1.6.0-3.el8 libudfread-1.1.0-2.el8 python-aiosmb-0.2.26-1.el8 python-coronavirus-1.1.1-1.el8 python-cssselect2-0.3.0-6.el8 python-discord-1.4.1-1.el8 python-tinycss2-1.0.2-8.el8 stress-ng-0.11.19-1.el8 stubby-0.3.1-0.5.20200318git7939e965.el8 xl2tpd-1.3.15-1.el8 Details about builds: dnsperf-2.3.4-3.el8 (FEDORA-EPEL-2020-be423b974a) Benchmarking authorative and recursing DNS servers Update Information: New build for EPEL8, dnsperf and resperf tools. They measure performance of domain name servers (DNS), both authoritative and recursive. ChangeLog: getdns-1.6.0-3.el8 (FEDORA-EPEL-2020-537cfb7d8f) Modern asynchronous API to the DNS Update Information: Getdns and stubby build for EPEL8. ChangeLog: References: [ 1 ] Bug #1785721 - getdns-1.6.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1785721 [ 2 ] Bug #1874285 - Please build an EPEL 8 build for getdns and getdns-stubby https://bugzilla.redhat.com/show_bug.cgi?id=1874285 libudfread-1.1.0-2.el8 (FEDORA-EPEL-2020-201dd37f38) UDF reader library Update Information: Initial Fedora package. ChangeLog: References: [ 1 ] Bug #1875315 - Review Request: libudfread - UDF reader library https://bugzilla.redhat.com/show_bug.cgi?id=1875315 python-aiosmb-0.2.26-1.el8 (FEDORA-EPEL-2020-752beb67f6) Asynchronous SMB protocol implementation Update Information: Update to latest upstream release 0.2.26 ChangeLog: python-coronavirus-1.1.1-1.el8 (FEDORA-EPEL-2020-e4f591495b) Python client for getting Corona virus info Update Information: Initial package for Fedora ChangeLog: python-cssselect2-0.3.0-6.el8 (FEDORA-EPEL-2020-7009b5495b) CSS selectors for Python ElementTree Update Information: Build for EPEL8 ChangeLog: References: [ 1 ] Bug #1874665 - Please build python-tinycss2 for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1874665 [ 2 ] Bug #1874669 - Please build python-cssselect2 for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1874669 python-discord-1.4.1-1.el8 (FEDORA-EPEL-2020-1bf142dd2a) Python wrapper for the Discord API Update Information: Initial pa
[EPEL-devel] Re: Continuing playground discussion
On Wed, Sep 2, 2020 at 2:08 PM Kevin Fenzi wrote: > I think playground might be fixable/made of use without too much work... > * adjust fedpkg to stop requesting playground branches always/only > request them on explicit ask > * change the inheritence in koji so it inherits from epel8 > * untag all the things that are "older" in playground > * add more docs about what it is and how it works > * perhaps make it send a daily report for each compose > When you start listing the actual steps, I think you are correct. Changing playground to do what we want, is only a little bit more work than it would to drop it. If you don't mind, I'd like to go through those steps in a little more detail, and in order that they need to be done. Step 1 - Approve plan via Steering Committee. Step 1a - Documents and communication -- No releng needed. -- Should be done along the whole way Step 2 - Update fedpkg and remove all package.cfg from epel8. -- Can be done by a proven packagers, no releng needed. Step 3 - Change the inheritance in koji so it inherits from epel8 -- releng work --- I don't know how easy / hard this will be for releng Step 4 - Untag all the things that are "older" in playground -- currently that is a releng process. There is no way for a maintainer to retire their package from playground. -- This needs to happen some time (3 months?) after step 2 is finished. A time that we can see that people have manually built their package in playground, versus the automatic builds. So that the "older" packages are obvious. -- If we do this as a huge batch, it should be a fairly simple (though long) step for releng. Step 5 - Send a daily report -- Is this similar to what we send for EPEL6,7,8 ? --- If this is true, I'm in favor of it. If not, then please explain more. -- I have no idea about the work involved for this. I think Step 5 is a very important step (if I'm understanding it correctly). Because it will give us a good idea about how many people are utilizing playground. I think Step 3, changing the inheritance is the only change in the work involved for releng. We would be changing the inheritance, instead of deleting it. I don't know how much extra work that will be. I have specifically avoided the -next / Stream discussion. Not that I don't think it's important, but because of resources. Let's get playground fixed up if possible. We'll take what we learn, look at how much resources it took, look at how much it is used, and then make a decision. Troy ___ 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
