Ansible in EPEL 8
by Maxwell G
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+...
--
Happy automating,
Maxwell G (@gotmax23)
Pronouns: He/They
11 months, 2 weeks
Upcoming removal of rust2rpm + major Rust packaging toolchain update for EPEL 9
by Fabio Valentini
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
11 months, 2 weeks
Incompatible change in apptainer-suid-1.1.8 now in epel-testing
by Dave Dykstra
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...
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
11 months, 3 weeks
Ansible in EPEL 9
by Maxwell G
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
11 months, 3 weeks