epel-announce May 2023

epel-announce@lists.fedoraproject.org

2 participants
5 discussions

Update of minor version of golang-1.19 coming to EPEL7
by Dave Dykstra 30 May '23

30 May '23

golang-1.19.6 is now available in epel-testing for EPEL7, an update of a minor version from 1.18.9. I expect it to be promoted in about a week unless karma changes that. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ba899b9717 My policy for updating golang in EPEL7 is to follow the updates in RHEL8, including whatever patches they include. RHEL 8.8 released yesterday updated to golang-1.19.6. Dave

1 1

Ansible in EPEL 8
by Maxwell G 17 May '23

17 May '23

Hello EPEL users and developers, RHEL 8.8 was released yesterday, so I have updated ansible in EPEL 8 from 6.3.0 to 7.2.0 to match RHEL 8.8's ansible-core bump from 2.13.3 to 2.14.2. Each ansible major version is tied to a specific major version of ansible-core, and we keep them in sync. Along with this change, RHEL 8.8 builds ansible-core for the python3.11 stack instead of the python39 stack that it was previously built for. Therefore, ansible in EPEL 8 is now built for python3.11 as well. I also updated ansible-collection-community-general to 7.0.0 as per the discussions in [1]. Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ca07fe358c Please help test and give karma. Until this update is pushed to stable, you may receive an error like this when running dnf upgrade ``` Error: Problem: package ansible-6.3.0-2.el8.1.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed - cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-2.el8_7.x86_64 - cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-1.el8.x86_64 - cannot install the best update candidate for package ansible-core-2.13.3-2.el8_7.x86_64 - cannot install the best update candidate for package ansible-6.3.0-2.el8.1.noarch (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ``` There are a couple potential solutions: 1. Run $ dnf upgrade --exclude ansible-core to skip ansible-core and upgrade everything else. 2. Later today or tomorrow, you'll be able to install ansible 7.2.0 from testing with $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core and then run a plain `dnf upgrade` as usual. Note that EPEL tracks RHEL and not rebuilds. Some rebuilds may lag behind RHEL and not yet have 8.8 content. Our goal is to get packages out as soon as possible so we don't break updates for RHEL users. [1] https://lists.fedoraproject.org/archives/search?q=A+coordinated+plan+for+an… -- Happy automating, Maxwell G (@gotmax23) Pronouns: He/They

1 0

Upcoming removal of rust2rpm + major Rust packaging toolchain update for EPEL 9
by Fabio Valentini 12 May '23

12 May '23

Hello EPEL packagers, The latest version of the Rust packaging toolchain will soon be available for EPEL 9 (i.e. rust2rpm v24, rust-packaging v24, and cargo2rpm v0.1). This is a major upgrade from rust2rpm v21 which is currently in EPEL 9, but also comes with the drawback that it now requires Python >= 3.10. However, I have split the Rust packaging tools into three separate projects (previously everything was in a monorepo) to make packaging them easier: The two components which are needed at build-time (RPM macros + the cargo2rpm Python module that powers them) can still be built for EPEL 9, as cargo2rpm has no third-party dependencies and only needs Python >= 3.10, and will hence be built with python3.11 on EPEL 9 as soon as that is available. The spec generator (rust2rpm) has also been split off from rust-packaging into a separate package, which will *not* be available on EPEL 9. rust2rpm requires Python >= 3.10, but it also has a few non-trivial third-party dependencies (most notably, jinja2). Since most Rust packagers primarily work on Fedora, I don't think the effort of packaging all missing dependencies for Python 3.11 just to make /usr/bin/rust2rpm available for EPEL 9 would be worth it. There are three Pull Requests which will implement this update: https://src.fedoraproject.org/rpms/cargo2rpm/pull-request/1 https://src.fedoraproject.org/rpms/rust-packaging/pull-request/6 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/65 (kudos to @gotmax23!) These changes (i.e. rust-packaging v24 + cargo2rpm) have now been live in "production" in Fedora for over a week, and based on user and CI feedback, I expect these updates to cause no regressions on EPEL 9. Fabio

2 1

Incompatible change in apptainer-suid-1.1.8 now in epel-testing
by Dave Dykstra 10 May '23

10 May '23

The apptainer-suid package version 1.1.8 now in epel-testing has an incompatible change because of a security vulnerability. The change is that a new option "allow setuid-mount extfs" was added which defaults to no, preventing ordinary users from mounting ext3 filesystems in setuid-root mode. Those filesystems are used by a subset of users primarily for the overlay feature which adds changes on top of a base container image. If unprivileged user namespaces are enabled, users will be able to still mount ext3 filesystems by using the "-u/--userns" option or if the apptainer-suid package is removed. If system administrators review the vulnerability description at https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f… and decide they still want to allow setuid-root access to this feature, they can enable it by setting "allow setuid-mount extfs = yes" in /etc/apptainer/apptainer.conf. This package will not be promoted to the epel repository for at least two weeks, pending approval by the EPEL Steering Committee according to the EPEL incompatible change policy. Apptainer 1.1.8 release notes are at https://github.com/apptainer/apptainer/releases/tag/v1.1.8 Dave

1 1

Ansible in EPEL 9
by Maxwell G 09 May '23

09 May '23

Hello EPEL users and developers, RHEL 9.2 was released today, so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL 9.2's ansible-core bump from 2.13.3 to 2.14.2. Each ansible major version is tied to a specific major version of ansible-core, and we keep them in sync. Along with this change, RHEL 9.2 builds ansible-core for the python3.11 stack instead of the default python3 (3.9) stack. Therefore, ansible in EPEL now built for python3.11 as well. Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1 Please help test and give karma. Until this update is pushed to stable, you may receive an error like this when running dnf upgrade ``` Error: Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed - cannot install both ansible-core-2.14.2-4.el9.x86_64 and ansible-core-2.13.3-2.el9_1.x86_64 - cannot install both ansible-core-2.14.2-4.el9.x86_64 and ansible-core-2.13.3-1.el9.x86_64 - cannot install the best update candidate for package ansible-core-2.13.3-2.el9_1.x86_64 - cannot install the best update candidate for package ansible-6.3.0-2.el9.noarch (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ``` There are a couple potential solutions: 1. Run $ dnf upgrade --exclude ansible-core to skip ansible-core and upgrade everything else. 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install ansible 7.2.0 from testing with $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core and then run a plain `dnf upgrade` as usual. -- Happy automating, Maxwell G (@gotmax23) Pronouns: He/They

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

epel-announce May 2023