[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7f0ce51dbd python-bleach-3.1.4-2.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-72116e7775 chromium-81.0.4044.122-1.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b928468862 openvpn-2.4.9-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c088d8f143 java-latest-openjdk-14.0.1.7-2.rolling.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e16cde6dc5 suricata-5.0.3-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ac1fd7a29f seamonkey-2.53.2-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing SDL_gfx-2.0.26-1.el8 f32-backgrounds-32.2.2-1.el8 knot-2.9.4-1.el8 nsca-2.10.0-2.el8 python-catkin-sphinx-0.3.1-1.el8 python-cheroot-8.2.1-1.el8 python-cherrypy-18.4.0-1.el8 python-jaraco-functools-2.0-4.el8 python-jaraco-packaging-6.2-6.el8 python-logutils-0.3.5-11.el8 python-path-11.5.0-2.el8 python-portend-2.6-1.el8 python-pygments-pytest-1.2.0-4.el8 python-remoto-1.1.4-4.el8 python-routes-2.4.1-12.el8 python-simplegeneric-0.8.1-17.el8 python-singledispatch-3.4.0.3-18.el8 python-tempora-1.14.1-5.el8 rbldnsd-0.998b-1.el8 samtools-1.9-3.el8 svt-vp9-0.2.0-1.el8 tito-0.6.14-1.el8 Details about builds: SDL_gfx-2.0.26-1.el8 (FEDORA-EPEL-2020-10d168cd24) SDL graphics drawing primitives and other support functions Update Information: First EL-8 build. ChangeLog: References: [ 1 ] Bug #1831617 - Request for SDL_gfx in EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1831617 f32-backgrounds-32.2.2-1.el8 (FEDORA-EPEL-2020-c6f18289e3) Fedora 32 default desktop background Update Information: * Update to 32.2.2 fixing selection in GNOME Settings * New build for epel8 repository ChangeLog: References: [ 1 ] Bug #1829564 - [epel8] Please build f32-backgrounds in EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1829564 [ 2 ] Bug #1830480 - Default background is not one of the choices in Gnome Settings https://bugzilla.redhat.com/show_bug.cgi?id=1830480 knot-2.9.4-1.el8 (FEDORA-EPEL-2020-14f7d4ab1c) High-performance authoritative DNS server Update Information: - new upstream release 2.9.4 ChangeLog: * Tue May 5 2020 Tomas Krizek - 2.9.4-1 - new upstream release 2.9.4 nsca-2.10.0-2.el8 (FEDORA-EPEL-2020-fc472cc3f4) Nagios Service Check Acceptor Update Information: Add patch to remove handling of hex delimiter which breaks regular delimiter behaviour. - Add --quiet mode to send_nsca (Timo Juhani Lindfors) - Add --ds to specify block delimiters (for sending multiple checks at once) in send_nsca (Nate Rini) - Add legacy_2_7_mode (for sending to nsca 2.7.x) to send_nsca (Adrian Freihofer, Xavier Bachelot) - Add foreground mode (Nate Rini) - Send errors to stderr, where they belong (Bas Couwenberg / Sean Finney) - Fix crashes on ECONNABORTED (Craig Leres) - Fix potential buffer overflow (Bas Couwenberg) - Spelling fixes (Josh Soref, Lajos Veres, Bas Couwenberg) - Removed escape newlines so that long output works (Bryan Heden) - IPv6 support (Miquel van Smoorenburg / Stuart D. Gathman) ChangeLog: * Tue May 5 2020 Xavier Bachelot - 2.10.0-2 - Add patch to drop broken hex delimiter handling (RHBZ#1830611) * Thu Apr 16 2020 Xavier Bachelot - 2.10.0-1 - Update to 2.10.0 https://github.com/NagiosEnterprises/nsca/blob/nsca-2.10.0/CHANGELOG.md * Wed Jan 29 2020 Fedora
[EPEL-devel] What to do about python 3.4 in EPEL7?
This is related to my breaking of various packages by dropping python34-six. Should we: - re-add python34-six - Make an announcement and start removing python34- from EPEL7 starting with: # repoquery --whatrequires python34-six --recursive --disablerepo=* --enablerepo=epel* | sort -u python34-dateutil-1:2.4.2-5.el7.noarch python34-httmock-0:1.2.6-2.el7.noarch python34-mock-0:2.0.0-2.el7.noarch python34-pyvirtualize-0:0.10-2.20191018gitdc2d971.el7.noarch python34-pyvmomi-0:6.7.3-4.el7.noarch python34-requests-0:2.14.2-2.el7.noarch python34-slack_cleaner-0:0.5.0-2.el7.noarch python34-slacker-0:0.12.0-4.el7.noarch python34-urllib3-0:1.25.6-1.el7.noarch python36-collada-0:0.4-16.el7.noarch slack-cleaner-0:0.5.0-2.el7.noarch Upstream python 3.4 is EOL. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: Clarification needed: Conflicts in compat packages
On 05. 05. 20 17:48, Troy Dawson wrote: On Tue, May 5, 2020 at 8:07 AM Miro Hrončok wrote: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Conflicts_in_compat_packages """Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat packages than Fedora. When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the Conflicts Guidelines. At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.""" What does "RHEL Base" mean in this context? Is it everything listed in https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F ? Correct, what you are pointing to is considered the "RHEL Base". Thanks for clarifying. What does "At this time" mean? Can an exception be requested for this? I didn't write that, but I believe you are also correct. "At this time" is an escape clause in case something comes up in the future. There would have to be a good reason. It would need to be approved by the steering committee. It would need to be documented somewhere. Understood. Thanks. -- 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: Clarification needed: Conflicts in compat packages
On Tue, May 5, 2020 at 8:07 AM Miro Hrončok wrote: > > https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Conflicts_in_compat_packages > > """Due to the EPEL policy of maintaining backwards compatibility, EPEL has a > greater need for forward compat packages than Fedora. When creating, a compat > package, note that it is okay to set a Conflicts between them as noted in the > Conflicts Guidelines. At this time, this is only allowed for packages > overriding > packages in EPEL, not in RHEL Base.""" > > What does "RHEL Base" mean in this context? > > Is it everything listed in > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F > ? Correct, what you are pointing to is considered the "RHEL Base". > > What does "At this time" mean? Can an exception be requested for this? > I didn't write that, but I believe you are also correct. "At this time" is an escape clause in case something comes up in the future. There would have to be a good reason. It would need to be approved by the steering committee. It would need to be documented somewhere. > -- > 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 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] Clarification needed: Conflicts in compat packages
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Conflicts_in_compat_packages """Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat packages than Fedora. When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the Conflicts Guidelines. At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.""" What does "RHEL Base" mean in this context? Is it everything listed in https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F ? What does "At this time" mean? Can an exception be requested for this? -- 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: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8
On Tue, May 05, 2020 at 04:00:28PM +0200, Petr Pisar wrote: > On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote: > > On Tue, May 5, 2020 at 12:23 AM Petr Pisar wrote: > > > > > > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote: > > > > I have not created any bugzila's for these yet. I have not checked to > > > > see if these are in -testing already. This is just a list showing > > > > what packages currently do not install from EPEL 7. > > > > > > > > perl-Image-SubImageFind > > - nothing provides libMagickCore.so.5()(64bit) needed by > > perl-Image-SubImageFind-0.03-1.el7.x86_64 > > - nothing provides libMagick++.so.5()(64bit) needed by > > perl-Image-SubImageFind-0.03-1.el7.x86_64 > > > > > > perl-X11-GUITest > > perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind), > > but none of the providers can be installed > > > > > > > > I can install these two packages. They were built 6 years ago. Can you > > > provide > > > more details. > > > > > > > If you are running RHEL or CentOS 7.8 then you cannot install them due > > to the updated ImageMagick. > > > I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to > install them because RHEL does not remove old packages from repositories and > my package manager simply chose the older compatible build (because I did not > have installed ImageMagick before). > > > It looks like you just need to rebuild perl-Image-SubImageFind and > > both packages should be able to install. > > > I will rebuild them. > Fixed with perl-Image-SubImageFind-0.03-2.el7. -- Petr 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: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8
On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote: > On Tue, May 5, 2020 at 12:23 AM Petr Pisar wrote: > > > > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote: > > > I have not created any bugzila's for these yet. I have not checked to > > > see if these are in -testing already. This is just a list showing > > > what packages currently do not install from EPEL 7. > > > > > > perl-Image-SubImageFind > - nothing provides libMagickCore.so.5()(64bit) needed by > perl-Image-SubImageFind-0.03-1.el7.x86_64 > - nothing provides libMagick++.so.5()(64bit) needed by > perl-Image-SubImageFind-0.03-1.el7.x86_64 > > > > perl-X11-GUITest > perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind), > but none of the providers can be installed > > > > > I can install these two packages. They were built 6 years ago. Can you > > provide > > more details. > > > > If you are running RHEL or CentOS 7.8 then you cannot install them due > to the updated ImageMagick. > I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to install them because RHEL does not remove old packages from repositories and my package manager simply chose the older compatible build (because I did not have installed ImageMagick before). > It looks like you just need to rebuild perl-Image-SubImageFind and > both packages should be able to install. > I will rebuild them. -- Petr 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: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8
On Tue, May 5, 2020 at 12:23 AM Petr Pisar wrote: > > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote: > > I have not created any bugzila's for these yet. I have not checked to > > see if these are in -testing already. This is just a list showing > > what packages currently do not install from EPEL 7. > > > > perl-Image-SubImageFind - nothing provides libMagickCore.so.5()(64bit) needed by perl-Image-SubImageFind-0.03-1.el7.x86_64 - nothing provides libMagick++.so.5()(64bit) needed by perl-Image-SubImageFind-0.03-1.el7.x86_64 > > perl-X11-GUITest perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind), but none of the providers can be installed > > I can install these two packages. They were built 6 years ago. Can you provide > more details. > If you are running RHEL or CentOS 7.8 then you cannot install them due to the updated ImageMagick. It looks like you just need to rebuild perl-Image-SubImageFind and both packages should be able to install. 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] Re: epel-devel Digest, Vol 85, Issue 7
Thanks Troy! Most of the packages are mine, and it's because I hadn't pushed the SOCI update to stable yet. I'll fix those packages (which, to the best of my knowledge, are the only ones making use of SOCI (which is indeed the reason why I packaged SOCI in the first place)): airinv airrac airtsp opentrep rmol sevmgr simcrs simfqt stdair trademgen travelccm Thanks! Kind regards Denis Date: Mon, 4 May 2020 09:11:00 -0700 > >> From: Troy Dawson > >> Subject: [EPEL-devel] EPEL 7 packages that fail to install on RHEL / > >> CentOS / SL 7.8 > >> To: EPEL Development List > >> Message-ID: > >> a...@mail.gmail.com> > >> Content-Type: text/plain; charset="UTF-8" > >> > I have not created any bugzila's for these yet. I have not checked to > >> see if these are in -testing already. This is just a list showing > >> what packages currently do not install from EPEL 7. > >> > airinv > >> airrac > >> airtsp > >> drawtiming > >> opentrep > >> perl-Image-SubImageFind > >> perl-X11-GUITest > >> php-magickwand > >> python-jenkins-job-builder > >> ripright > >> rmol > >> sevmgr > >> simcrs > >> simfqt > >> slack-cleaner > >> spyder > >> stdair > >> trademgen > >> travelccm > >> > This is a much smaller list than in the past. I appreciate everyone's > >> efforts to keep EPEL7 an installable repo. > 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] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2e91626690 php-horde-horde-5.2.22-1.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ed97a34306 qt5-qtbase-5.6.1-6.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7f0712e439 pxz-4.999.9-19.beta.20200421git.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-aa01e58571 openvpn-2.4.9-1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c8a92d6324 wordpress-5.1.5-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing pgbouncer-1.12.0-5.el6 Details about builds: pgbouncer-1.12.0-5.el6 (FEDORA-EPEL-2020-0fb4836402) Lightweight connection pooler for PostgreSQL Update Information: Update SPEC file (build & runtime requirements, macros, rpmlint fixes, etc.) & update version for CentOS/RHEL. - Fix dependencies in EPEL 8 - Do not touch in scriptlets or SysV init script (CentOS/RHEL 6) folders and files already part of the package - Permissions on the files already part of the package - SELinux context is wrong i(it's not even in the policy) in the SysV init script and if needed should be managed with semanage fcontext, not in the script. - The daemon runs unconfined, so the file context is useless in the SysV init script - Fix build on RHEL/CentOS 6/7/8. - Do not use a normal home folder and shell for the user. - Do not remove/change files in the scriptlets. - Do not start in daemon mode in systemd units. - Trim changelog. - Add template userlist file. 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: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8
On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote: > I have not created any bugzila's for these yet. I have not checked to > see if these are in -testing already. This is just a list showing > what packages currently do not install from EPEL 7. > > perl-Image-SubImageFind > perl-X11-GUITest I can install these two packages. They were built 6 years ago. Can you provide more details. The only issue with them I can see is that they were retired in Fedora master. -- Petr 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
