[EPEL-devel] Re: nagios-plugins missing from epel-10.0 repo
On Tue, Aug 26, 2025 at 10:11 AM Lance Albertson wrote:
>
>
>
> On Mon, Aug 25, 2025 at 8:15 PM Carl George wrote:
>>
>> On Mon, Aug 25, 2025 at 7:20 PM Lance Albertson wrote:
>> >
>> > We just noticed something rather odd while working on adding EL10 support
>> > to our infrastructure.
>> >
>> > Previously, we had tested and verified that we could install
>> > nagios-plugins-http, but today that's no longer the case if you're on
>> > AlmaLinux 10 pointed at the 10.0 EPEL repo.
>>
>> How did you previously set up EPEL? nagios-plugins has only been
>> built in EPEL 10.1, so RHEL 10.0 and Alma 10.0 systems shouldn't see
>> it available.
>>
>> https://bodhi.fedoraproject.org/updates/?search=&packages=nagios-plugins&releases=EPEL-10.0&releases=EPEL-10.1&releases=EPEL-10
>>
>> If you're using a custom repo definition, it needs to match to
>> commented out baseurl examples in the official epel-release to ensure
>> you get packages targeting the appropriate minor version. If you were
>> previously able to install nagios-plugins-http with your repo setup,
>> that sounds like it was misconfigured to use 10.1 (pub/10) instead of
>> 10.0 (pub/10z)
>
>
> We had it pointed to "10" which likely pointed to "10.1" (up until yesterday)
> which didn't have any issues until.. (see below)
>
>>
>> > The reason we're pointing directly at 10.0 is due to some issues we ran
>> > into with clamav linking against newer openssl libraries using the 10.1
>> > branch. I would expect packages that were in 10.0 to remain, but is that
>> > not the case anymore?
>>
>> Indeed, clamav in EPEL 10.1 is built against openssl 3.5.1, but in
>> EPEL 10.0 is built against openssl 3.2.2. Subtle differences like
>> this are why we have minor versions in EPEL now.
>
>
> This breaks on AlmaLinux if pointed to 10.1 (or 10 at the time), still also
> breaks pointing to 10.2:
>
> clamav-1.4.3-1.el10_1.x86_64
>
> $ clamscan
> clamscan: symbol lookup error: /lib64/libclamav.so.12: undefined symbol:
> EVP_MD_CTX_get_size_ex, version OPENSSL_3.4.0
>
> IMHO this shouldn't break on AlmaLinux 10 like it did.
This is the same type of problem that can happen if you tried to
install a RHEL 10.1 package on RHEL 10.0. RHEL's compatibility
guarantees are designed around third party software building on a
minor version and then continuing to work on subsequent minor
versions. There are no guarantees that a package will work on earlier
minor versions than the one it was built on. This is explicitly
called out in the RHEL Application Compatibility Guide.
https://access.redhat.com/articles/rhel10-abi-compatibility#:~:text=An%20application%20is,newer.
>
> An interesting note, the AlmaLinux 10 container uses 10.0:
>
> [root@2452e995dddb /]# dnf repolist -v epel
> Last metadata expiration check: 0:03:50 ago on Tue Aug 26 15:03:19 2025.
> Repo-id: epel
> Repo-name : Extra Packages for Enterprise Linux 10 - x86_64
> Repo-status: enabled
> Repo-revision : 1756173563
> Repo-updated : Tue Aug 26 01:59:37 2025
> Repo-pkgs : 17771
> Repo-available-pkgs: 17771
> Repo-size : 16 G
> Repo-metalink :
> https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64
> Updated : Tue Aug 26 15:03:19 2025
> Repo-baseurl :
> rsync://ftp-osl.osuosl.org/fedora-epel/10.0/Everything/x86_64/ (218 more)
> Repo-expire: 86400 second(s) (last: Tue Aug 26 15:03:19 2025)
> Repo-filename : /etc/yum.repos.d/epel.repo
> Total packages: 17771
>
> The epel.repo has this line:
>
> metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch
Yes, that's the correct behavior. The repo name in that metalink
expands to epel-z-10 on RHEL and Alma, and epel-10 on CentOS (based on
whether releasever_minor is defined). Mirrormanager is configured to
return 10.0 mirror paths for the former, and 10.2 mirror paths for the
latter. That will change over time with new minor versions.
For a custom repo config using baseurl instead of metalink, see the
commented out baseurl example in epel.repo.
#baseurl=https://download.example/pub/epel/$releasever${releasever_minor:+z}/Everything/$basearch/
That release section expands to 10z on RHEL and Alma, and 10 on
CentOS. These are symlinks on the mirrors to 10.0 and 10.2
respectively, following the same pattern as mirrormanager.
>
> So if we're on AlmaLinux, should we be using the minor branch of epel to
> ensure ABI compatibility? If that's the case, then I will contact the package
> maintainer to add the 10.0 tag to get it included.
Yes, that is how epel-release is designed. Using the wrong minor
version repo may work initially or for some packages, but will
eventually lead to problems.
The maintainer can't manually add tags to their builds, only releng
can do that (or more specifically, koji admins). But it would be
inappropriate to add the 10.0 tag to a 10.1 build, as you have noticed
with clama
[EPEL-devel] Re: nagios-plugins missing from epel-10.0 repo
On Mon, Aug 25, 2025 at 8:15 PM Carl George wrote:
> On Mon, Aug 25, 2025 at 7:20 PM Lance Albertson wrote:
> >
> > We just noticed something rather odd while working on adding EL10
> support to our infrastructure.
> >
> > Previously, we had tested and verified that we could install
> nagios-plugins-http, but today that's no longer the case if you're on
> AlmaLinux 10 pointed at the 10.0 EPEL repo.
>
> How did you previously set up EPEL? nagios-plugins has only been
> built in EPEL 10.1, so RHEL 10.0 and Alma 10.0 systems shouldn't see
> it available.
>
>
> https://bodhi.fedoraproject.org/updates/?search=&packages=nagios-plugins&releases=EPEL-10.0&releases=EPEL-10.1&releases=EPEL-10
>
> If you're using a custom repo definition, it needs to match to
> commented out baseurl examples in the official epel-release to ensure
> you get packages targeting the appropriate minor version. If you were
> previously able to install nagios-plugins-http with your repo setup,
> that sounds like it was misconfigured to use 10.1 (pub/10) instead of
> 10.0 (pub/10z)
>
We had it pointed to "10" which likely pointed to "10.1" (up until
yesterday) which didn't have any issues until.. (see below)
> > The reason we're pointing directly at 10.0 is due to some issues we ran
> into with clamav linking against newer openssl libraries using the 10.1
> branch. I would expect packages that were in 10.0 to remain, but is that
> not the case anymore?
>
> Indeed, clamav in EPEL 10.1 is built against openssl 3.5.1, but in
> EPEL 10.0 is built against openssl 3.2.2. Subtle differences like
> this are why we have minor versions in EPEL now.
>
This breaks on AlmaLinux if pointed to 10.1 (or 10 at the time), still also
breaks pointing to 10.2:
clamav-1.4.3-1.el10_1.x86_64
$ clamscan
clamscan: symbol lookup error: /lib64/libclamav.so.12: undefined symbol:
EVP_MD_CTX_get_size_ex, version OPENSSL_3.4.0
IMHO this shouldn't break on AlmaLinux 10 like it did.
An interesting note, the AlmaLinux 10 container uses 10.0:
[root@2452e995dddb /]# dnf repolist -v epel
Last metadata expiration check: 0:03:50 ago on Tue Aug 26 15:03:19 2025.
Repo-id: epel
Repo-name : Extra Packages for Enterprise Linux 10 - x86_64
Repo-status: enabled
Repo-revision : 1756173563
Repo-updated : Tue Aug 26 01:59:37 2025
Repo-pkgs : 17771
Repo-available-pkgs: 17771
Repo-size : 16 G
Repo-metalink :
https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64
Updated : Tue Aug 26 15:03:19 2025
Repo-baseurl : rsync://
ftp-osl.osuosl.org/fedora-epel/10.0/Everything/x86_64/ (218 more)
Repo-expire: 86400 second(s) (last: Tue Aug 26 15:03:19 2025)
Repo-filename : /etc/yum.repos.d/epel.repo
Total packages: 17771
The epel.repo has this line:
metalink=
https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch
So if we're on AlmaLinux, should we be using the minor branch of epel to
ensure ABI compatibility? If that's the case, then I will contact the
package maintainer to add the 10.0 tag to get it included.
Thanks-
--
Lance Albertson
Director
Oregon State University | Open Source Lab
--
___
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: nagios-plugins missing from epel-10.0 repo
On Mon, Aug 25, 2025 at 7:25 PM Chris Adams wrote: > > Once upon a time, Lance Albertson said: > > Previously, we had tested and verified that we could install > > nagios-plugins-http, but today that's no longer the case if you're on > > AlmaLinux 10 pointed at the 10.0 EPEL repo. > > I believe Alma uses "10" by default, so has been getting 10.1 (and will Alma should have releasever_minor defined like RHEL does, and thus requests an epel-z-10 metalink or epel/10z baseurl. These currently resolve to 10.0 repos, and will be switched to 10.1 when RHEL 10.1 is released. CentOS does not have releasever_minor defined, and thus requests an epel-10 metalink or epel/10 baseurl. Before today these resolved to 10.1 repos, and they were switched to 10.2 today as part of the mass branching processes. > now be getting 10.2 with today's branching). If an EPEL 10 branch was > requested after the release of RHEL 10 and the maintainer just did > epel10, that would be epel10.1. > > If you need an epel10.0 branch, you'll need to request the maintainer > create it. > > -- > Chris Adams > -- > ___ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: nagios-plugins missing from epel-10.0 repo
On Mon, Aug 25, 2025 at 7:20 PM Lance Albertson wrote: > > We just noticed something rather odd while working on adding EL10 support to > our infrastructure. > > Previously, we had tested and verified that we could install > nagios-plugins-http, but today that's no longer the case if you're on > AlmaLinux 10 pointed at the 10.0 EPEL repo. How did you previously set up EPEL? nagios-plugins has only been built in EPEL 10.1, so RHEL 10.0 and Alma 10.0 systems shouldn't see it available. https://bodhi.fedoraproject.org/updates/?search=&packages=nagios-plugins&releases=EPEL-10.0&releases=EPEL-10.1&releases=EPEL-10 If you're using a custom repo definition, it needs to match to commented out baseurl examples in the official epel-release to ensure you get packages targeting the appropriate minor version. If you were previously able to install nagios-plugins-http with your repo setup, that sounds like it was misconfigured to use 10.1 (pub/10) instead of 10.0 (pub/10z) https://src.fedoraproject.org/rpms/epel-release/blob/epel10/f/epel.repo See the EPEL docs on branches for additional details. https://docs.fedoraproject.org/en-US/epel/branches/ You can also read this issue for more background on why the repos are constructed the way they are. https://pagure.io/epel/issue/324 > > I did some digging and noticed that the package doesn't seem to have the > epel10.0 tag listed in koji [1]. However, I do see a lot of other packages > that include 10.0, 10.1 and 10.2 [2]. neovim-0.10.1-4.el10_0 was built for 10.0 (hence the el10_0 dist tag), and then tagged forward to 10.1 and 10.2 during the respective mass branching events. > > Is this intentional or was there a mistake made somewhere and it had 10.0 > removed? > > The reason we're pointing directly at 10.0 is due to some issues we ran into > with clamav linking against newer openssl libraries using the 10.1 branch. I > would expect packages that were in 10.0 to remain, but is that not the case > anymore? Indeed, clamav in EPEL 10.1 is built against openssl 3.5.1, but in EPEL 10.0 is built against openssl 3.2.2. Subtle differences like this are why we have minor versions in EPEL now. > > Thanks- > > [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=2594 > [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2540722 > > -- > Lance Albertson > Director > Oregon State University | Open Source Lab > -- > ___ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: nagios-plugins missing from epel-10.0 repo
Once upon a time, Lance Albertson said: > Previously, we had tested and verified that we could install > nagios-plugins-http, but today that's no longer the case if you're on > AlmaLinux 10 pointed at the 10.0 EPEL repo. I believe Alma uses "10" by default, so has been getting 10.1 (and will now be getting 10.2 with today's branching). If an EPEL 10 branch was requested after the release of RHEL 10 and the maintainer just did epel10, that would be epel10.1. If you need an epel10.0 branch, you'll need to request the maintainer create it. -- Chris Adams -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
