[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4 ansible-2.9.6-1.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2cb1029c5a okular-18.12.2-2.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-913d6d1779 coturn-4.5.1.1-3.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-98e8249e5c chromium-80.0.3987.162-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing epel-rpm-macros-8-9 nohang-0.1-26.20200403git18f90d7.el8 python-tqdm-4.45.0-1.el8 suricata-5.0.2-2.el8 Details about builds: epel-rpm-macros-8-9 (FEDORA-EPEL-2020-dea4090509) Extra Packages for Enterprise Linux RPM macros Update Information: Add qt5_qtwebengine_arches to macros ChangeLog: * Fri Apr 3 2020 Troy Dawson - 8-9 - Add i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 armv3l armv4b armv4l armv4tl armv5tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl aarch64 mips mipsel mips64el to macros nohang-0.1-26.20200403git18f90d7.el8 (FEDORA-EPEL-2020-ebc1a98f68) Highly configurable OOM prevention daemon Update Information: Update to latest version ChangeLog: * Fri Apr 3 2020 Artem Polishchuk - 0.1-26.20200403git18f90d7 - Update to latest git snapshot * Mon Mar 23 2020 Artem Polishchuk - 0.1-25.20200323gitdaca5cc - Update to latest git snapshot python-tqdm-4.45.0-1.el8 (FEDORA-EPEL-2020-117ad76a4d) Fast, Extensible Progress Meter Update Information: Update to 4.45.0 ChangeLog: * Fri Apr 3 2020 Stephen Gallagher - 4.45.0-1 - Update to 4.45.0 * Mon Feb 10 2020 Stephen Gallagher - 4.42.1-1 - Update to 4.42.1 * Mon Feb 10 2020 Stephen Gallagher - 4.41.1-1 - Update to 4.41.1 * Thu Jan 30 2020 Fedora Release Engineering - 4.37.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild suricata-5.0.2-2.el8 (FEDORA-EPEL-2020-1219d4aced) Intrusion Detection System Update Information: Add python3-pyyaml to resolve (#1818935) ChangeLog: * Fri Apr 3 2020 Jason Taylor 5.0.2-2 - Add python3-pyyaml to resolve (#1818935) References: [ 1 ] Bug #1818935 - The Suricata package should require pythonX-pyyaml https://bugzilla.redhat.com/show_bug.cgi?id=1818935 ___ 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 598 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 340 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 338 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 47 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-61faf4c2ff libmodsecurity-3.0.2-6.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7bc15e9271 coturn-4.5.1.1-3.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-414ebc38c5 chromium-80.0.3987.162-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing nohang-0.1-26.20200403git18f90d7.el7 python-tox-1.4.2-9.el7 python-tqdm-4.45.0-1.el7 thunderbird-enigmail-2.1.6-1.el7 Details about builds: nohang-0.1-26.20200403git18f90d7.el7 (FEDORA-EPEL-2020-b36b1f6519) Highly configurable OOM prevention daemon Update Information: Update to latest version ChangeLog: * Fri Apr 3 2020 Artem Polishchuk - 0.1-26.20200403git18f90d7 - Update to latest git snapshot python-tox-1.4.2-9.el7 (FEDORA-EPEL-2020-4b3752c0f5) Virtualenv-based automation of test activities Update Information: Fix tox to be able to run with newer pip that has been shipped in RHEL 7.7 ChangeLog: * Thu Apr 2 2020 Michael Scherer - 1.4.2-9 - fix run on newer pip on EL7 python-tqdm-4.45.0-1.el7 (FEDORA-EPEL-2020-34b0ae2ac4) A Fast, Extensible Progress Meter Update Information: Update to 4.45.0 and fix issue with python2-tqdm pulling in python3. ChangeLog: * Fri Apr 3 2020 Stephen Gallagher - 4.45.0-1 - Update to 4.45.0 - Install /usr/bin/tqdm only for python2 References: [ 1 ] Bug #1771143 - python-tqdm-4.45.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=1771143 [ 2 ] Bug #1816790 - Installing python2-tqdm will bring in Python 3. https://bugzilla.redhat.com/show_bug.cgi?id=1816790 thunderbird-enigmail-2.1.6-1.el7 (FEDORA-EPEL-2020-cd54f8f3d2) Authentication and encryption extension for Mozilla Thunderbird Update Information: new upstream version 2.1.6: bugfix update ChangeLog: * Fri Apr 3 2020 Felix Schwarz - 2.1.6-1 - update to 2.1.6 References: [ 1 ] Bug #1819128 - enigmail 2.1.6 is available as bugfix release https://bugzilla.redhat.com/show_bug.cgi?id=1819128 ___ 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] Input Requested: revising policy for stalled EPEL requests
EPEL Issue #101 [1] has pointed out that our current policy for stalled EPEL requests is fairly in-efficient and can cause some long delays. What do people think the process should be? Here is an example: * A packager opens a bugzilla requesting a package be added to EPEL. They also express that they are willing to help maintain / co-maintain that package in EPEL. * A period of time goes by with no response * They re-say that they are willing to maintain / co-maintain the package in EPEL * Another period of time goes by with no response * They file a rel-eng ticket, that points to the bugzilla, requesting appropriate privileges to be able to branch and build that package in EPELX * That happens. * They then request branch, and build the package in EPELX following normal ways. This is just an example, but it's what I picture in my head. Troy [1] - https://pagure.io/epel/issue/101 ___ 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] Putting qt5 srpm macro into epel-rpm-macros
RHEL 8.2 will have a newer qt5 (qt5-5.12.5).
They have also cleaned up their qt5-srpm-macros, to remove a macro for
a package they do not support, nor plan on supporting. I have
verified this was their intention and they do not plan on putting it
back.
%qt5_qtwebengine_arches %{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el
The problem is that this is in all the KDE spec files for EPEL8 that
depend on qtwebengine. It's essentially telling them to not build on
s390x.
I've look at all the alternatives, and putting that macro into
epel-rpm-macros solves the problem.
I have verified that rpmfusion doesn't build on s390x, so they will
not be affected by this problem.
I'll be putting that in today, and letting it sit testing for the
usual time. If anyone has any problems, please let me know before the
two weeks are up.
Troy Dawson
___
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 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9190462510 ckeditor-4.14.0-1.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0c0d9690e1 drupal6-6.38-3.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing librabbitmq-0.5.2-2.el6 Details about builds: librabbitmq-0.5.2-2.el6 (FEDORA-EPEL-2020-b1a5eb3ef5) Client library for AMQP Update Information: Security fix for CVE-2019-18609 ChangeLog: * Thu Apr 2 2020 Than Ngo - 0.5.2-2 - Resolves: #1809991 - CVE-2019-18609, integer overflow References: [ 1 ] Bug #1786646 - CVE-2019-18609 librabbitmq: integer overflow in amqp_handle_input in amqp_connection.c leads to heap-based buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1786646 ___ 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: Help with cfitsio update in epel6, proven packager needed
It is true that probably it's not worth the effort. Thank you anyway El sáb., 21 mar. 2020 a las 18:33, Troy Dawson () escribió: > On Fri, Mar 20, 2020 at 4:40 AM Sergio Pascual > wrote: > > > > Hello. I would like to update cfitsio in epel6. The current version here > has longstanding bugs. > > > > My first question is the correct repoquery command. I'm doing, in a > centos 6 machine, > > > > repoquery --whatrequires cfitsio --disablerepo=* --enablerepo=epel > -s|sort | uniq > > > > that returns > > > > cfitsio-3.240-3.el6.src.rpm > > cpl-5.2.0-2.el6.src.rpm > > gdal-1.7.3-15.el6.src.rpm > > healpix-2.13a-2.el6.src.rpm > > munipack-1.2.10-1.el6.src.rpm > > nightview-0.3.3-1.el6.src.rpm > > perl-Astro-FITS-CFITSIO-1.05-6.el6.src.rpm > > root-5.34.38-3.el6.src.rpm > > siril-0.8-9.el6.src.rpm > > skyviewer-1.0.0-3.el6.src.rpm > > wcslib-4.3.1-3.el6.src.rpm > > > > So, I did a check, and all of those will rebuild except wcslib. So > wcslib will need a bit of work. It builds on i686 but not x86_64. > https://koji.fedoraproject.org/koji/taskinfo?taskID=42643273 > > When you say you want to fix the bugs. are you meaning apply some > patches, or update to a newer version? > If it's just applying patches, and leaving the library the same > version, you wouldn't need to rebuild anything. > > Those bugs have been there for 9 years, and EPEL6 is going to be > retired in 7 months. Is it going to be worth the effort? > > > Second, I understand that I have to create a buildroot override and the > owners rebuild their packages. Later, to create a common update in bodhi. I > can't create the update because I'm do not have the required permissions. > Could a proven packager coordinate this? > > > > I don't have time until mid week (wednesday I believe). > If you decide it's worth the effort, and nobody else has volunteered, > I could give it a try. > > 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 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: [Fedocal] Reminder meeting : EPEL Steering Committee
A couple things I have on the agenda to think about * https://pagure.io/epel/issue/101 Policy for stalled EPEL requests - Is this something that we pursue, and figure out a new/better policy, or do we stick to the past way of doing it. * With the -devel stuff in place, as we go through the issues related to missing packages, do we open the CentOS bugs on behalf of the person who filed the EPEL issue, or do we simple tell them about the procedure and let them file the bug. On Thu, Apr 2, 2020 at 2:00 PM wrote: > > Dear all, > > You are kindly invited to the meeting: >EPEL Steering Committee on 2020-04-03 from 21:00:00 to 22:00:00 UTC >At freenode@fedora-meeting > > The meeting will be about: > This is the weekly EPEL Steering Committee Meeting. > > A general agenda is the following: > > #meetingname EPEL > #topic Intros > #topic Old Business > #topic EPEL-6 > #topic EPEL-7 > #topic EPEL-8 > #topic Openfloor > #endmeeting > > > > > Source: https://apps.fedoraproject.org/calendar/meeting/9722/ > > ___ > 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
