[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4ff425606f openssl11-1.1.1k-7.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-54270ec4b3 clojure-1.8.0-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing barman-3.10.0-1.el7 Details about builds: barman-3.10.0-1.el7 (FEDORA-EPEL-2024-e3e54fa722) Backup and Recovery Manager for PostgreSQL Update Information: Update to 3.10.0 ChangeLog: * Thu Jan 25 2024 Simone Caronni - 3.10.0-1 - Update to 3.10.0. References: [ 1 ] Bug #2260108 - barman-3.10.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2260108 -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 26 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3a29f0d349 python-paramiko-2.12.0-2.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-76443fce3f indent-2.2.13-5.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-272d6fcaca atril-1.26.2-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-93d34f40f0 chromium-121.0.6167.85-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing AMF-1.4.33-1.el8 barman-3.10.0-1.el8 dfuzzer-2.3-2.el8 Details about builds: AMF-1.4.33-1.el8 (FEDORA-EPEL-2024-39ccf80406) Advanced Media Framework (AMF) SDK Update Information: AMD release 1.4.33. ChangeLog: * Mon Jan 29 2024 Simone Caronni - 1.4.33-1 - Update to 1.4.33. barman-3.10.0-1.el8 (FEDORA-EPEL-2024-e255d6b671) Backup and Recovery Manager for PostgreSQL Update Information: Update to 3.10.0 ChangeLog: * Thu Jan 25 2024 Simone Caronni - 3.10.0-1 - Update to 3.10.0. References: [ 1 ] Bug #2260108 - barman-3.10.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2260108 dfuzzer-2.3-2.el8 (FEDORA-EPEL-2024-fdb44ee08b) D-Bus fuzz testing tool Update Information: Work around old meson in EL8 ChangeLog: * Mon Jan 29 2024 Frantisek Sumsal - 2.3-2 - Work around old meson in EL8 * Mon Jan 29 2024 Frantisek Sumsal - 2.3-1 - Bump to v2.3 -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa wrote: > On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel > wrote: > > > > Dear all, > > > > Following advice from Neal elsewhere on this list [1], I’m requesting > that the singularity-ce EPEL packages may be updated to 4.1.0 following the > incompatible upgrade procedure. The justification for the upgrade is that > 3.x singularity-ce is no longer maintained upstream. Note that because > singularity-ce necessarily bundles many Go dependencies specified in > upstream go.mod/go.sum, lack of maintenance can quickly lead to inherited > security issues. > > > > Upstream singularity-ce (https://github.com/sylabs/singularity) > maintenance is limited to the latest x.y minor version, currently 4.1. The > upstream project has committed more formally to semantic versioning > conventions since 4.0.0, so any 4.y.z minor (y) and patch (z) version > updates are expected to be compatible upgrades for EPEL purposes. > > > > At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to > incompatible changes. > > > > Incompatibilities from 3.11.5 -> 4.1.0 are as follows: > > > > (a) The CLI has split some functionality previously provided by the > `singularity remote` command into new `singularity registry` and > `singularity keyserver` commands. > > (b) The `singularity remote add` command now sets a newly added remote > as the default (unless suppressed). Previously the user had to set the > default remote manually. > > (c) The `—vm` flag to start `singularity` inside a Virtual Machine has > been removed. This was not intended to be user facing, but was used by a > separate and proprietary Singularity Desktop project that has been retired > for some time. `—vm` was unmaintained, and I don’t believe there is any > practical use outside of this context. > > > > (d) Bind mounts are now performed in the order in which they are > specified. Previously, image based bind mounts were performed before others. > > (e) Current working directory on the host is now created in the > container, restoring a behaviour from Singularity <3.6.0 unless suppressed. > > (f) If the current directory paths on the container and host contains > symlinks to different locations, the current working directory is not > mounted. > > > > The above are expected to have a minor impact on users. Arguably > (d)/(e)/(f) are bug fixes as they address issues reported by users as > unexpected behaviour. Changes (e)/(f) were also previously included in the > apptainer project's upgrade to their v1.2.0 that was not submitted as an > incompatible upgrade. > > > > Highlighting also for Dave Dykstra’s benefit that any thoughts around > the relevance of incompatible upgrade policy to (b) & (c) will also be > relevant to apptainer’s upcoming 1.3.0 upgrade, as apptainer has pulled > both of these changes from singularity-ce upstream. > > > > Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible. > Configuration files do not need to be modified. > > > > This seems reasonable to me. > I agree with Neal, this looks good to me. Thank you for the nice explanation/write-up. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel wrote: > > Dear all, > > Following advice from Neal elsewhere on this list [1], I’m requesting that > the singularity-ce EPEL packages may be updated to 4.1.0 following the > incompatible upgrade procedure. The justification for the upgrade is that 3.x > singularity-ce is no longer maintained upstream. Note that because > singularity-ce necessarily bundles many Go dependencies specified in upstream > go.mod/go.sum, lack of maintenance can quickly lead to inherited security > issues. > > Upstream singularity-ce (https://github.com/sylabs/singularity) maintenance > is limited to the latest x.y minor version, currently 4.1. The upstream > project has committed more formally to semantic versioning conventions since > 4.0.0, so any 4.y.z minor (y) and patch (z) version updates are expected to > be compatible upgrades for EPEL purposes. > > At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to > incompatible changes. > > Incompatibilities from 3.11.5 -> 4.1.0 are as follows: > > (a) The CLI has split some functionality previously provided by the > `singularity remote` command into new `singularity registry` and `singularity > keyserver` commands. > (b) The `singularity remote add` command now sets a newly added remote as the > default (unless suppressed). Previously the user had to set the default > remote manually. > (c) The `—vm` flag to start `singularity` inside a Virtual Machine has been > removed. This was not intended to be user facing, but was used by a separate > and proprietary Singularity Desktop project that has been retired for some > time. `—vm` was unmaintained, and I don’t believe there is any practical use > outside of this context. > > (d) Bind mounts are now performed in the order in which they are specified. > Previously, image based bind mounts were performed before others. > (e) Current working directory on the host is now created in the container, > restoring a behaviour from Singularity <3.6.0 unless suppressed. > (f) If the current directory paths on the container and host contains > symlinks to different locations, the current working directory is not mounted. > > The above are expected to have a minor impact on users. Arguably (d)/(e)/(f) > are bug fixes as they address issues reported by users as unexpected > behaviour. Changes (e)/(f) were also previously included in the apptainer > project's upgrade to their v1.2.0 that was not submitted as an incompatible > upgrade. > > Highlighting also for Dave Dykstra’s benefit that any thoughts around the > relevance of incompatible upgrade policy to (b) & (c) will also be relevant > to apptainer’s upcoming 1.3.0 upgrade, as apptainer has pulled both of these > changes from singularity-ce upstream. > > Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible. Configuration > files do not need to be modified. > This seems reasonable to me. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Incompatible Upgrade Request - singularity-ce
Dear all, Following advice from Neal elsewhere on this list [1], I’m requesting that the singularity-ce EPEL packages may be updated to 4.1.0 following the incompatible upgrade procedure. The justification for the upgrade is that 3.x singularity-ce is no longer maintained upstream. Note that because singularity-ce necessarily bundles many Go dependencies specified in upstream go.mod/go.sum, lack of maintenance can quickly lead to inherited security issues. Upstream singularity-ce (https://github.com/sylabs/singularity) maintenance is limited to the latest x.y minor version, currently 4.1. The upstream project has committed more formally to semantic versioning conventions since 4.0.0, so any 4.y.z minor (y) and patch (z) version updates are expected to be compatible upgrades for EPEL purposes. At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to incompatible changes. Incompatibilities from 3.11.5 -> 4.1.0 are as follows: (a) The CLI has split some functionality previously provided by the `singularity remote` command into new `singularity registry` and `singularity keyserver` commands. (b) The `singularity remote add` command now sets a newly added remote as the default (unless suppressed). Previously the user had to set the default remote manually. (c) The `—vm` flag to start `singularity` inside a Virtual Machine has been removed. This was not intended to be user facing, but was used by a separate and proprietary Singularity Desktop project that has been retired for some time. `—vm` was unmaintained, and I don’t believe there is any practical use outside of this context. (d) Bind mounts are now performed in the order in which they are specified. Previously, image based bind mounts were performed before others. (e) Current working directory on the host is now created in the container, restoring a behaviour from Singularity <3.6.0 unless suppressed. (f) If the current directory paths on the container and host contains symlinks to different locations, the current working directory is not mounted. The above are expected to have a minor impact on users. Arguably (d)/(e)/(f) are bug fixes as they address issues reported by users as unexpected behaviour. Changes (e)/(f) were also previously included in the apptainer project's upgrade to their v1.2.0 that was not submitted as an incompatible upgrade. Highlighting also for Dave Dykstra’s benefit that any thoughts around the relevance of incompatible upgrade policy to (b) & (c) will also be relevant to apptainer’s upcoming 1.3.0 upgrade, as apptainer has pulled both of these changes from singularity-ce upstream. Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible. Configuration files do not need to be modified. Many Thanks, Dave Trudgian [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/IQENLTYUAIMOTAX4LUWHYINOPSCRWCIS/ -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Canceling this weeks EPEL Steering Committee meeting
Hello, Many of the EPEL Steering Committee members will be at a conference this Wedensday. We have also changed the meeting time to 1800 UTC (Same date and location). We don't have much (or anything) to cover. Unless something dramatic comes up. I would like to cancel this weeks meeting. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
