[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0214580ca4 mbedtls-2.16.8-1.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c5ced83bcc seamonkey-2.53.4-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-11f765300e singularity-3.6.3-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-17fdec3133 zeromq-4.3.3-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9720b9f379 matio-1.5.18-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b65eda12a7 chromium-85.0.4183.102-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing nohang-0.1-33.20200919gitfaf49b0.el8 Details about builds: nohang-0.1-33.20200919gitfaf49b0.el8 (FEDORA-EPEL-2020-eb68c876fc) Sophisticated low memory handler for Linux Update Information: Update to latest version ChangeLog: * Sun Sep 20 2020 Artem Polishchuk - 0.1-33.20200919gitfaf49b0 - Update to latest git snapshot ___ 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 768 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 507 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 15 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83bdeb2965 ansible-2.9.13-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9a03b mbedtls-2.7.17-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-25e525a9ca seamonkey-2.53.4-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-918ad695f6 proftpd-1.3.5e-10.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d968abb383 golang-1.15.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f3f88c479 nginx-1.16.1-2.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-92064b5b2b singularity-3.6.3-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6b04ee5c07 libuv-1.39.0-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e621d9ff68 matio-1.5.18-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dec199d5a2 chromium-85.0.4183.102-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing nohang-0.1-33.20200919gitfaf49b0.el7 Details about builds: nohang-0.1-33.20200919gitfaf49b0.el7 (FEDORA-EPEL-2020-ccae81aa14) Sophisticated low memory handler for Linux Update Information: Update to latest version ChangeLog: * Sun Sep 20 2020 Artem Polishchuk - 0.1-33.20200919gitfaf49b0 - Update to latest git snapshot ___ 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: Proposed EPEL Playground Documentation
On Wed, Sep 16, 2020 at 11:28:10AM -0700, Troy Dawson wrote: > On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote: > > > > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: > > ...snip... > > > > > > When a maintainer is done with their package in playground, they must > > > untag all builds of it out of epel-playground. We do not want > > > epel-playground cluttered with old test packages. Done means either > > > the package has been moved to regular EPEL, and / or the maintainer no > > > longer wants to play and test in epel-playground. Untagging all > > > builds of a package is currently done via a release engineering > > > ticket. > > > > This puts more work on releng, but I am not sure how often it will come > > up. We could also create a 'epel-sig' permission and grant everyone in > > that group permissions to untag from playground? > > > > Otherwise, looks good to me. > > > > kevin > > If the maintainer could do it themselves, I'm ok with that. But > currently, I don't think they can. They cannot. We would need to create a new koji permission and add people to it, or just have releng do it. > If we can get something better than rel-eng, I'm all for it. But as > far as I know, that's what we currently have to do. > We can update it when we get something better in place. Well, I think it might be worthwhile to add a permission and a small group of people who can do it, then they could process the releng tickets too. 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: proposal: EPEL 8 Next
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > At the EPEL Steering Committee last week, we had an extensive discussion of > this proposal, specifically focused on how to handle the dist macro. I > believe these are the possible choices. > > * keep dist the same as epel8 (.el8) > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for > dist. It would make sense to continue using the same dist for EPEL Next. > However, this would put a little more work on packagers. They would not be > able to build the same commit for both EPEL and EPEL Next because the NVR > will conflict in Koji. In simple rebuild situations, this is not a problem > because at a minimum the release will be higher. But if a packager wanted > to update the package in both EPEL and EPEL Next, they will need to first > update and build it in EPEL, then bump the release and build it in EPEL > Next. This isn't ideal, but isn't terrible either, and can be partially > mitigated by good documentation around EPEL Next workflows. > > * modify dist to always be higher than epel8 (.el8.next or similar) > > In EPEL Next we could define dist to a string that RPM evaluates higher than > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be > in sync and the same commit could be built for both targets. The higher > dist would ensure the upgrade path works. I think this makes the most sense and will help packages workflows the best. 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
