[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ce8d5824ad halibut-1.3-3.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-aaaeae50ce rubygem-jmespath-1.3.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing perl-Parse-DMIDecode-0.03-6.el7 python-bottle-0.12.21-1.el7 tio-1.39-1.el7 Details about builds: perl-Parse-DMIDecode-0.03-6.el7 (FEDORA-EPEL-2022-c94627008d) Interface to SMBIOS using dmidecode Update Information: This release fixes a memory leak and warnings about unportable hexadecimal numbers and about an uninitialized number of structures on machines with SMBIOS version 3. ChangeLog: * Mon Jun 13 2022 Petr Pisar - 0.03-6 - Fix a memory leak when destructing Parse::DMIDecode::Handle objects (CPAN RT#125088) - Fix supressing portability warnings (CPAN RT#143252) - Do not warn on SMBIOS version 3 (bug #1661251) References: [ 1 ] Bug #1661251 - Fails due to uninitialised value https://bugzilla.redhat.com/show_bug.cgi?id=1661251 python-bottle-0.12.21-1.el7 (FEDORA-EPEL-2022-0286a0e93a) Fast and simple WSGI-framework for small web-applications Update Information: Security fix for CVE-2020-28473 ChangeLog: * Mon Jun 13 2022 Ali Erdinc Koroglu - 0.12.21-1 - Update to 0.12.21 (rhbz #1926760) References: [ 1 ] Bug #1926760 - CVE-2020-28473 python-bottle: Web Cache Poisoning by using a vector called parameter cloaking may lead to integrity and availability compromise [epel-7] https://bugzilla.redhat.com/show_bug.cgi?id=1926760 tio-1.39-1.el7 (FEDORA-EPEL-2022-639e144f14) Simple TTY terminal I/O application Update Information: # tio v1.39* Improve key command response for local echo and timestamp* Fix invalid hex character error message* Make sure only matched config section is parsed* Add support for `disable` keyword in config file* Unify error message formating* Cleanup list devices code* Fix command- line `tty-device|config` parsing Allow user to add options on both sides of the provided config argument. For example: `$ tio -b 9600 am64-evm -e` Before, tio only allowed adding arguments after the config argument. Implemented as simple as possible by introducing two stage option parsing.* Update bash completion* Add support for IPv4 and IPv6 network sockets Add support for IPv4 and IPv6 network sockets via socket syntax `inet:` and `inet6:` respectively. For example, to listen and redirect serial device I/O to a host bound IPv4 socket simply do: `$ tio /dev/ttyUSB0 --socket inet:` To connect do e.g.: `$ nc 127.0.0.1 ` Likewise, for IPv6 do: `$ tio /dev/ttyUSB0 --socket inet6:` To connect do e.g.: `$ nc ::1 ` If port is `0` or no port is provided default port `` is used.* Fix tio deleting unix socket file If tio has a unix file socket open, a second tio instance of tio may delete the socket file. This change fixes so that it will not be deleted and tio will instead error and complain about conflicting socket file.* Rework color option Rework the color option to support setting ANSI color code values ranging from 0..255 or `none` for no color or `list` to print a list of available ANSI colors codes. Also, disables color when piping.* Remove print of hex mode status at startup* Remove newline option in hex mode* Fix configfile memory leaks* Remove command-line option inconsistencies Optional arguments, as parsed by the `getopt_long` mechanism, are inherently inconsistent with how you define required arguments. To avoid confusion we decide to avoid this inconsistency by replacing optional options with additional options with required argmuments. * Replace `1` with `enable` in config files * Convert errors to warnings * Extended hexadecimal mode. While in hex mode (`ctrl`-`t` `h`) you can output hexadecimal
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-287b3b64f6 halibut-1.3-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing python-bottle-0.12.21-2.el8 tio-1.39-1.el8 Details about builds: python-bottle-0.12.21-2.el8 (FEDORA-EPEL-2022-17d14b279e) Fast and simple WSGI-framework for small web-applications Update Information: Cookie test fix backported from upstream (0.12) Security fix for CVE-2022-31799 ChangeLog: * Mon Jun 13 2022 Ali Erdinc Koroglu - 0.12.21-2 - Cookie test fix backported from upstream (0.12) * Thu Jun 9 2022 Ali Erdinc Koroglu - 0.12.21-1 - Update to 0.12.21 (rhbz #2094655 + #2094654 and #2021856) References: [ 1 ] Bug #2094654 - CVE-2022-31799 python-bottle: error mishandling during early request binding https://bugzilla.redhat.com/show_bug.cgi?id=2094654 tio-1.39-1.el8 (FEDORA-EPEL-2022-e7eeb6922a) Simple TTY terminal I/O application Update Information: # tio v1.39* Improve key command response for local echo and timestamp* Fix invalid hex character error message* Make sure only matched config section is parsed* Add support for `disable` keyword in config file* Unify error message formating* Cleanup list devices code* Fix command- line `tty-device|config` parsing Allow user to add options on both sides of the provided config argument. For example: `$ tio -b 9600 am64-evm -e` Before, tio only allowed adding arguments after the config argument. Implemented as simple as possible by introducing two stage option parsing.* Update bash completion* Add support for IPv4 and IPv6 network sockets Add support for IPv4 and IPv6 network sockets via socket syntax `inet:` and `inet6:` respectively. For example, to listen and redirect serial device I/O to a host bound IPv4 socket simply do: `$ tio /dev/ttyUSB0 --socket inet:` To connect do e.g.: `$ nc 127.0.0.1 ` Likewise, for IPv6 do: `$ tio /dev/ttyUSB0 --socket inet6:` To connect do e.g.: `$ nc ::1 ` If port is `0` or no port is provided default port `` is used.* Fix tio deleting unix socket file If tio has a unix file socket open, a second tio instance of tio may delete the socket file. This change fixes so that it will not be deleted and tio will instead error and complain about conflicting socket file.* Rework color option Rework the color option to support setting ANSI color code values ranging from 0..255 or `none` for no color or `list` to print a list of available ANSI colors codes. Also, disables color when piping.* Remove print of hex mode status at startup* Remove newline option in hex mode* Fix configfile memory leaks* Remove command-line option inconsistencies Optional arguments, as parsed by the `getopt_long` mechanism, are inherently inconsistent with how you define required arguments. To avoid confusion we decide to avoid this inconsistency by replacing optional options with additional options with required argmuments. * Replace `1` with `enable` in config files * Convert errors to warnings * Extended hexadecimal mode. While in hex mode (`ctrl`-`t` `h`) you can output hexadecimal values. E.g.: to send `0x0A` you have to type `0A` (always 2 characters). Added option `-x`, `--hex` to start in hexadecimal mode. Added option `--newline-in-hex` to interpret newline characters in hex mode. This is disabled by default, because, in my opinion, hex stream is fundamentally different from text, so a "new line" is meaningless in this context. ChangeLog: * Sun Jun 12 2022 Robert Scheck 1.39-1 - Upgrade to 1.39 (#2096097) * Sat Jun 4 2022 Robert Scheck 1.38-1 - Upgrade to 1.38 (#2092955) References: [ 1 ] Bug #2096097 - tio-1.39 is available https://bugzilla.redhat.com/show_bug.cgi?id=2096097 ___ 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:
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1fbc5ebf38 python-elasticsearch-7.17.4-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing pam_radius-2.0.0-1.el9 python-bottle-0.12.21-2.el9 qxmledit-0.9.17-1.el9 socnetv-3.0.4-3.el9 Details about builds: pam_radius-2.0.0-1.el9 (FEDORA-EPEL-2022-4066a90f19) PAM Module for RADIUS Authentication Update Information: Rebase to version 2.0.0 ChangeLog: * Thu May 26 2022 Iker Pedrosa - 2.0.0-1 - Rebase to version 2.0.0 python-bottle-0.12.21-2.el9 (FEDORA-EPEL-2022-6812bb3862) Fast and simple WSGI-framework for small web-applications Update Information: Cookie test fix backported from upstream (0.12) Security fix for CVE-2022-31799 ChangeLog: * Mon Jun 13 2022 Ali Erdinc Koroglu - 0.12.21-2 - Cookie test fix backported from upstream (0.12) * Thu Jun 9 2022 Ali Erdinc Koroglu - 0.12.21-1 - Update to 0.12.21 (rhbz #2094655 + #2094654 and #2021856) References: [ 1 ] Bug #2094654 - CVE-2022-31799 python-bottle: error mishandling during early request binding https://bugzilla.redhat.com/show_bug.cgi?id=2094654 qxmledit-0.9.17-1.el9 (FEDORA-EPEL-2022-563acb9527) Simple XML Editor and XSD Viewer Update Information: Version bump ChangeLog: * Mon Jun 13 2022 TI_Eugene - 0.9.17-1 - Version bump - Patches removed socnetv-3.0.4-3.el9 (FEDORA-EPEL-2022-015e25e9f2) A Social Networks Analyser and Visualiser Update Information: Rebuild with fresh qtchart ChangeLog: * Mon Jun 13 2022 TI_Eugene 3.0.4-3 - Rebuild with fresh qtchart ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Mon, Jun 13, 2022, 4:17 PM Chris Adams wrote: > Once upon a time, Josh Boyer said: > > If the dependency is only needed at build time, which is what CRB > > content is intended for > > If that's the intent, then it's not implemented correctly. For example, > there are well over 100 perl modules in CRB 9. They may only be used > _by Red Hat_ in building, but they are not exclusively build-time > packages by a long shot. > I know. I'm actually looking at squaring this in one way or another, but whatever that results in doesn't change that content in CRB will have different considerations to take into account than other repos. The same has always been true of RHEL 7 Optional as well, so it's not a new dynamic. I also know most of those considerations don't matter to users or EPEL packagers, but I'm trying to avoid surprise in the long run. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Mon, Jun 13, 2022 at 5:03 AM Josh Boyer wrote: > However, if a package needs something > at runtime it would be better to first inquire about putting that > dependency in BaseOS or AppStream rather than just blindly using it > from CRB. > My first attempt as requesting a critical runtime CRB package be put into AppStream: poppler-qt5 https://bugzilla.redhat.com/show_bug.cgi?id=2096452 https://bugzilla.redhat.com/show_bug.cgi?id=2096451 We'll see how it goes. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Once upon a time, Josh Boyer said: > If the dependency is only needed at build time, which is what CRB > content is intended for If that's the intent, then it's not implemented correctly. For example, there are well over 100 perl modules in CRB 9. They may only be used _by Red Hat_ in building, but they are not exclusively build-time packages by a long shot. -- Chris Adams ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)
On Mon, 13 Jun 2022 at 10:44, Troy Dawson wrote: > It was a configuration mix up that pulled in ALL the modules instead of > just the default ones. > It only lasted a week (I think) and has been fixed. > It was just bad timing, nothing you could have done to prevent, or fix it. > > I thought we'd caught all the packages that were built that might have > been affected, but I guess we didn't catch them all. > > It lasted for 72 hours, and I missed the ImageMagick needing a rebuild. > Troy > > > On Mon, Jun 13, 2022 at 7:26 AM Sérgio Basto wrote: > >> On Mon, 2022-06-13 at 09:34 +0200, Petr Pisar wrote: >> > V Sun, Jun 12, 2022 at 12:29:06AM +0100, Sérgio Basto napsal(a): >> > > On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote: >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=2095649 >> > > >> > > Hi, >> > > for some reason the build on epel 8 to update ImageMagick-6.9.12 >> > > from >> > > 48 to 50 ( >> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) >> > > used perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I >> > > guess >> > > modules repo >> > >> > Interesting. I'm courious how it could happen. DNF rejects installing >> > modular >> > packages if they are not listed in a defintion of a module stream. So >> > either >> > somebody enabled perl:5.32 stream explicitly (improbable), or mock >> > repositories in Koji are configured with module_hotfixes=true which >> > is alarming. >> >> "Koji are configured with module_hotfixes=true" , but usually don't >> push perl:5.32 stream , why this time it was pushed ? how I can avoid >> it ? >> >> Thank you >> >> > Koji configuration confirm the other theory: >> > >> > $ koji mock-config -a x86_64 --target epel8-candidate | grep >> > module_hotfixes >> > config_opts['yum.conf'] = >> > '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum. >> > log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumey >> > es=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# >> > repos\n\n[build]\nname=build\nbaseurl= >> > https://kojipkgs.fedoraproject.org/repos/epel8- >> > build/4655904/x86_64\nmodule_hotfixes=1\n' >> > >> > I recommend Koji maintainers to add and use RHEL repositories next to >> > epel8-build with EPEL8 packages: >> > >> > [build] >> > name=build >> > baseurl= >> > https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64 >> > >> > [rhel-AppStream] >> > name=rhel-AppStream >> > baseurl=WHEREVER_FEDORA_TAKES_RHEL8_PACKAGES_FROM >> > >> > -- Petr >> > >> > ___ >> > 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 >> > Do not reply to spam on the list, report it: >> > https://pagure.io/fedora-infrastructure >> >> -- >> Sérgio M. B. >> ___ >> 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 >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Mon, 2022-06-13 at 07:41 -0400, Josh Boyer wrote: > On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto > wrote: > > > > On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote: > > > Let me start with examples that I get *regularly*: Pagure fails > > > to > > > install from EPEL on RHEL/CentOS/Alma/etc. because python3- > > > markdown > > > is > > > not available. KDE Plasma fails to install because of a mass of > > > missing dependencies. > > > > if epel use crb to build some package, crb should be enabled when > > we > > install epel repo, yes , that is my opinion > > If the dependency is only needed at build time, which is what CRB > content is intended for, then there is no reason to default to having > CRB enabled because nothing will be installed from CRB anyway. The > issue that people are running into is that EPEL packages have > developed *runtime* dependencies on CRB content. For a subset of > users, that is probably fine. However, if a package needs something > at runtime it would be better to first inquire about putting that > dependency in BaseOS or AppStream rather than just blindly using it > from CRB. at least [1] we should be add to BaseOS or AppStream [1] aspell.x86_64 12:0.60.8-8.el9 @crb poppler-qt5.x86_64 21.01.0-12.el9 @crb python3-markdown I got the results running `dnf --disablerepo=crb list extras` > josh > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)
It was a configuration mix up that pulled in ALL the modules instead of just the default ones. It only lasted a week (I think) and has been fixed. It was just bad timing, nothing you could have done to prevent, or fix it. I thought we'd caught all the packages that were built that might have been affected, but I guess we didn't catch them all. Troy On Mon, Jun 13, 2022 at 7:26 AM Sérgio Basto wrote: > On Mon, 2022-06-13 at 09:34 +0200, Petr Pisar wrote: > > V Sun, Jun 12, 2022 at 12:29:06AM +0100, Sérgio Basto napsal(a): > > > On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2095649 > > > > > > Hi, > > > for some reason the build on epel 8 to update ImageMagick-6.9.12 > > > from > > > 48 to 50 ( > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) > > > used perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I > > > guess > > > modules repo > > > > Interesting. I'm courious how it could happen. DNF rejects installing > > modular > > packages if they are not listed in a defintion of a module stream. So > > either > > somebody enabled perl:5.32 stream explicitly (improbable), or mock > > repositories in Koji are configured with module_hotfixes=true which > > is alarming. > > "Koji are configured with module_hotfixes=true" , but usually don't > push perl:5.32 stream , why this time it was pushed ? how I can avoid > it ? > > Thank you > > > Koji configuration confirm the other theory: > > > > $ koji mock-config -a x86_64 --target epel8-candidate | grep > > module_hotfixes > > config_opts['yum.conf'] = > > '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum. > > log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumey > > es=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# > > repos\n\n[build]\nname=build\nbaseurl= > > https://kojipkgs.fedoraproject.org/repos/epel8- > > build/4655904/x86_64\nmodule_hotfixes=1\n' > > > > I recommend Koji maintainers to add and use RHEL repositories next to > > epel8-build with EPEL8 packages: > > > > [build] > > name=build > > baseurl= > > https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64 > > > > [rhel-AppStream] > > name=rhel-AppStream > > baseurl=WHEREVER_FEDORA_TAKES_RHEL8_PACKAGES_FROM > > > > -- Petr > > > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > -- > Sérgio M. B. > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)
On Mon, 2022-06-13 at 09:34 +0200, Petr Pisar wrote: > V Sun, Jun 12, 2022 at 12:29:06AM +0100, Sérgio Basto napsal(a): > > On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=2095649 > > > > Hi, > > for some reason the build on epel 8 to update ImageMagick-6.9.12 > > from > > 48 to 50 ( > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) > > used perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I > > guess > > modules repo > > Interesting. I'm courious how it could happen. DNF rejects installing > modular > packages if they are not listed in a defintion of a module stream. So > either > somebody enabled perl:5.32 stream explicitly (improbable), or mock > repositories in Koji are configured with module_hotfixes=true which > is alarming. "Koji are configured with module_hotfixes=true" , but usually don't push perl:5.32 stream , why this time it was pushed ? how I can avoid it ? Thank you > Koji configuration confirm the other theory: > > $ koji mock-config -a x86_64 --target epel8-candidate | grep > module_hotfixes > config_opts['yum.conf'] = > '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum. > log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumey > es=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# > repos\n\n[build]\nname=build\nbaseurl= > https://kojipkgs.fedoraproject.org/repos/epel8- > build/4655904/x86_64\nmodule_hotfixes=1\n' > > I recommend Koji maintainers to add and use RHEL repositories next to > epel8-build with EPEL8 packages: > > [build] > name=build > baseurl= > https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64 > > [rhel-AppStream] > name=rhel-AppStream > baseurl=WHEREVER_FEDORA_TAKES_RHEL8_PACKAGES_FROM > > -- Petr > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Am 13.06.22 um 13:41 schrieb Josh Boyer:
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto wrote:
On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
Let me start with examples that I get *regularly*: Pagure fails to
install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown
is
not available. KDE Plasma fails to install because of a mass of
missing dependencies.
if epel use crb to build some package, crb should be enabled when we
install epel repo, yes , that is my opinion
If the dependency is only needed at build time, which is what CRB
content is intended for, then there is no reason to default to having
CRB enabled because nothing will be installed from CRB anyway. The
issue that people are running into is that EPEL packages have
developed *runtime* dependencies on CRB content. For a subset of
users, that is probably fine. However, if a package needs something
at runtime it would be better to first inquire about putting that
dependency in BaseOS or AppStream rather than just blindly using it
from CRB.
Not sure if there is a misconception but crb repo has all kind of
packages also runtime ones. The concept that RH is applying against
crb is; supported or not supported period. Everthing else would mean
that RH should move everything without -devel in %{NAME} into appstream
or baseos.
Example (powertools aka crb):
#repoquery --repoid=powertools ladspa
Last metadata expiration check: 1 day, 1:43:56 ago on Sun Jun 12
13:02:39 2022.
ladspa-0:1.13-20.el8.x86_64
# rpm -ev --test ladspa.x86_64
error: Failed dependencies:
ladspa is needed by (installed) rubberband-1.9.0-1.el8.x86_64
# repoquery --repoid=epel rubberband
Last metadata expiration check: 1 day, 1:44:41 ago on Sun Jun 12
13:02:40 2022.
rubberband-0:1.9.0-1.el8.x86_64
# repoquery --repoid=powertools ladspa-devel
Last metadata expiration check: 1 day, 1:46:06 ago on Sun Jun 12
13:02:39 2022.
ladspa-devel-0:1.13-20.el8.i686
ladspa-devel-0:1.13-20.el8.x86_64
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto wrote: > > On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote: > > Let me start with examples that I get *regularly*: Pagure fails to > > install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown > > is > > not available. KDE Plasma fails to install because of a mass of > > missing dependencies. > > if epel use crb to build some package, crb should be enabled when we > install epel repo, yes , that is my opinion If the dependency is only needed at build time, which is what CRB content is intended for, then there is no reason to default to having CRB enabled because nothing will be installed from CRB anyway. The issue that people are running into is that EPEL packages have developed *runtime* dependencies on CRB content. For a subset of users, that is probably fine. However, if a package needs something at runtime it would be better to first inquire about putting that dependency in BaseOS or AppStream rather than just blindly using it from CRB. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)
V Sun, Jun 12, 2022 at 12:29:06AM +0100, Sérgio Basto napsal(a): > On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=2095649 > > Hi, > for some reason the build on epel 8 to update ImageMagick-6.9.12 from > 48 to 50 ( > https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) > used perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I guess > modules repo Interesting. I'm courious how it could happen. DNF rejects installing modular packages if they are not listed in a defintion of a module stream. So either somebody enabled perl:5.32 stream explicitly (improbable), or mock repositories in Koji are configured with module_hotfixes=true which is alarming. Koji configuration confirm the other theory: $ koji mock-config -a x86_64 --target epel8-candidate | grep module_hotfixes config_opts['yum.conf'] = '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# repos\n\n[build]\nname=build\nbaseurl=https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64\nmodule_hotfixes=1\n' I recommend Koji maintainers to add and use RHEL repositories next to epel8-build with EPEL8 packages: [build] name=build baseurl=https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64 [rhel-AppStream] name=rhel-AppStream baseurl=WHEREVER_FEDORA_TAKES_RHEL8_PACKAGES_FROM -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
