[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 626 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 368 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 366 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 75 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 15 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19d171a465 python34-3.4.10-5.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e3e05f0ce4 gnuchess-6.2.6-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a46aedd742 php-horde-horde-5.2.22-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-23a94e6d3c pxz-4.999.9-19.beta.20200421git.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-324f1b735d chromium-81.0.4044.122-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c4860b563d openvpn-2.4.9-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-320cd2c3b5 java-latest-openjdk-14.0.1.7-2.rolling.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-12ba1ceddb wordpress-5.1.5-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing fedfind-4.4.2-1.el7 ipmctl-02.00.00.3764-1.el7 Details about builds: fedfind-4.4.2-1.el7 (FEDORA-EPEL-2020-b8c0a84eea) Fedora compose and image finder Update Information: This update provides a new release of fedfind, with a single (but important) bug fix: it fixes `get_current_release(branched=True)`, which broke when the new 'ELN' release was added to Bodhi's database, because it assumes all releases have an integer version, but ELN's version is just "eln". ChangeLog: * Fri May 1 2020 Adam Williamson - 4.4.2-1 - New release 4.4.2: Fix get_current_release for new 'ELN' release ipmctl-02.00.00.3764-1.el7 (FEDORA-EPEL-2020-f76f9b80a9) Utility for managing Intel Optane DC persistent memory modules Update Information: Initial 2.x Release 02.00.00.3764 - Removed ipmctl-monitor - Removed libsafec dependency ChangeLog: * Fri May 1 2020 Juston Li - 02.00.00.3764-1 - Release 02.00.00.3764 * Fri Apr 24 2020 Juston Li - 02.00.00.3759-1 - Inital 2.x Release 02.00.00.3759 - Removed ipmctl-monitor - Removed libsafec dependency ___ 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 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7f0ce51dbd python-bleach-3.1.4-2.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-72116e7775 chromium-81.0.4044.122-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b928468862 openvpn-2.4.9-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c088d8f143 java-latest-openjdk-14.0.1.7-2.rolling.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e16cde6dc5 suricata-5.0.3-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing bashtop-0.8.19-1.el8 ipmctl-02.00.00.3764-1.el8 testdisk-7.1-2.el8 Details about builds: bashtop-0.8.19-1.el8 (FEDORA-EPEL-2020-c7e055d1d8) Linux resource monitor Update Information: bashtop first release ChangeLog: ipmctl-02.00.00.3764-1.el8 (FEDORA-EPEL-2020-a4e2167ebf) Utility for managing Intel Optane DC persistent memory modules Update Information: Initial 2.x Release 02.00.00.3764 - Removed ipmctl-monitor - Removed libsafec dependency ChangeLog: * Fri May 1 2020 Juston Li - 02.00.00.3764-1 - Release 02.00.00.3764 * Mon Apr 27 2020 Juston Li - 02.00.00.3759-2 - Fallback to asciidoc * Fri Apr 24 2020 Juston Li - 02.00.00.3759-1 - Inital 2.x Release 02.00.00.3759 - Removed ipmctl-monitor - Removed libsafec dependency testdisk-7.1-2.el8 (FEDORA-EPEL-2020-f724102927) Tool to check and undelete partition, PhotoRec recovers lost files Update Information: libewf-devel is currently missing from rhel 8, ignore it 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: Playground policy
On Fri, May 01, 2020 at 10:48:54AM -0700, Michel Alexandre Salim wrote: > > > On 5/1/20 1:10 AM, Petr Pisar wrote: > > On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote: > > > Generally speaking (I can make this a separate thread if that helps) - do > > > we > > > expect every package in EPEL8 to also be built for EPEL8-playground, > > > either > > > through package.cfg or by building directly from the epel8-playground > > > branch? > > > > There is no such rule, but in my opinion, it is welcomed for exactly the > > terrible > > experience anybody gets when he tries to use epel8-playground. > > > Right, but if some package repos are missing packages.cfg and the maintainer > does not build it separately for epel8-playground, it is a terrible > experience for other packages depending on this missing package -- everytime > the maintainer submits an epel8 build, the epel8-playground target will > report a build failure. There was no 'rule' but the intent was everyone would keep the package.cfg and build for both. If they were not making any playground changes, they didn't need to commit anything, and fedpkg build would just build for both epel8 and epel8-playground. The problem is that the packages.cfg commit annoys everyone who does a 'merge origin/master' because it's not on the master branch, so they delete it to get their workflow back. I'd like to look at seeing if we can accomplish what we wanted with playground by having it just inherit from epel8. Failing that, we could just look at dropping playground if it's not useful for people. > > The purpose of epel8-playground is to diverge when needed. That's why the > > epel8 > > branch contains package.cfg by default. > > > That seems to be the case for packages branched normally (fedpkg > request-branch). *However* I've seen some packages where the epel8 branch > and master branch are identical -- not sure how it happens, maybe the > committer has force-push permission? Or is there a way to request that a > branch be cloned from another branch instead of created from scratch? There's no force-push allowed. They likely just deleted it and are merging master over it. kevin 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: Python macro backports for EPEL reviews needed
On Fri, May 1, 2020 at 9:36 AM Miro Hrončok wrote: > > On 14. 04. 20 19:04, Miro Hrončok wrote: > > On 14. 04. 20 18:46, Troy Dawson wrote: > >> Yep, I'm having a hard time finding anything relevant to test. > >> I have verified it doesn't conflict with any other rpm macro, but I'm > >> pretty sure you had already checked that. > >> So, I'm giving it a thumbs up. > >> And I'll give it a thumbs up on the pull requests as well. > > > > > > EPEL 7 update and buildroot override: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c0bec7842 > > https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-24 > > > > > > EPEL 8 update and buildroot override: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2bb92fb39 > > https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10 > > > > > > I've disabled both time based and karma based push. We can observe the EPEL > > builds and decide whether to push this or not in ~1 month. > > My EPEL 8 update got overridden by a new one. > Ya, sorry about the timing for that. I kept your changes in, but I wanted something in override fairly quick so packages that needed python could build. I guess I should have just done the override, and not bodhi. It's second nature for me to push things to bodhi when I build them so I don't forget about them. I haven't heard or seen any problems with your macros. And what I have up there probably isn't going to be the final fix for the python36/38 problem. I've never un-updated anything, and I'm not sure if it will make it possible for your packages to be pushed to stable. But, if there is a simple way, I'm fine with pushing your updates out to stable for epel8 > I suggest I push the EPEL 7 one, there was no reported breakage. > Sounds good. > > In case something is needed for EPEL 8 Playground, please do so, I have no > > idea > > really, sorry about that. > > Still no idea what is the story there. > > -- > 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: Playground policy
On 5/1/20 1:10 AM, Petr Pisar wrote: On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote: Generally speaking (I can make this a separate thread if that helps) - do we expect every package in EPEL8 to also be built for EPEL8-playground, either through package.cfg or by building directly from the epel8-playground branch? There is no such rule, but in my opinion, it is welcomed for exactly the terrible experience anybody gets when he tries to use epel8-playground. Right, but if some package repos are missing packages.cfg and the maintainer does not build it separately for epel8-playground, it is a terrible experience for other packages depending on this missing package -- everytime the maintainer submits an epel8 build, the epel8-playground target will report a build failure. The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default. That seems to be the case for packages branched normally (fedpkg request-branch). *However* I've seen some packages where the epel8 branch and master branch are identical -- not sure how it happens, maybe the committer has force-push permission? Or is there a way to request that a branch be cloned from another branch instead of created from scratch? -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ 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: Python macro backports for EPEL reviews needed
On 14. 04. 20 19:04, Miro Hrončok wrote: On 14. 04. 20 18:46, Troy Dawson wrote: Yep, I'm having a hard time finding anything relevant to test. I have verified it doesn't conflict with any other rpm macro, but I'm pretty sure you had already checked that. So, I'm giving it a thumbs up. And I'll give it a thumbs up on the pull requests as well. EPEL 7 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c0bec7842 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-24 EPEL 8 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2bb92fb39 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10 I've disabled both time based and karma based push. We can observe the EPEL builds and decide whether to push this or not in ~1 month. My EPEL 8 update got overridden by a new one. I suggest I push the EPEL 7 one, there was no reported breakage. In case something is needed for EPEL 8 Playground, please do so, I have no idea really, sorry about that. Still no idea what is the story there. -- 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: Looking for someone to take ngircd in EPEL
On Thu, Apr 30, 2020 at 08:39:48PM -0600, Orion Poplawski wrote: > Anyone willing to take over ngircd for EPEL? > > https://bugzilla.redhat.com/show_bug.cgi?id=1830182 Sure. I can do that. Will add it to my list. kevin ___ 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: Broken %python_provide macro for Koji's epel8-playground target?
On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote: > Generally speaking (I can make this a separate thread if that helps) - do we > expect every package in EPEL8 to also be built for EPEL8-playground, either > through package.cfg or by building directly from the epel8-playground > branch? There is no such rule, but in my opinion, it is welcomed for exactly the terrible experience anybody gets when he tries to use epel8-playground. The purpose of epel8-playground is to diverge when needed. That's why the epel8 branch contains package.cfg by default. -- 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: Looking for someone to take ngircd in EPEL
Le 01/05/2020 à 04:39, Orion Poplawski a écrit : > Anyone willing to take over ngircd for EPEL? > > https://bugzilla.redhat.com/show_bug.cgi?id=1830182 On a side note : this package is appreciated here. Last week I published a detailed article about NgIRCd running on CentOS 7. https://blog.microlinux.fr/ngircd-letsencrypt-centos-7/ Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 ___ 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
