On Mon, Aug 25, 2025 at 8:15 PM Carl George <[email protected]> wrote:
> On Mon, Aug 25, 2025 at 7:20 PM Lance Albertson <[email protected]> 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
