Description of problem: It would be very helpful for building libmamba to have yaml-ccp updated to 0.8.0. Perhaps this could be done in epel10.1?
I don't do a lot of EPEL packaging these days and haven't kept up with the process... I'm assuming a epel10.1 branch will show up at some point?
The epel10 branch is currently building for epel10.1. These are the current users in epel10: lhapdf-0:6.5.5-1.el10_0.x86_64 pdns-ixfrdist-0:4.9.7-1.el10_1.x86_64 qt-creator-0:16.0.1-2.el10_1.x86_64 This is an abi/api update so would need coordination
I double checked since "I've slept since then" but it looks like the other two maintainers on the project are primarily doing the EPEL maintenance. Let's see if either of them respond in the near future.
What would you like to do at this point? I think we missed the 10.1 branch.
Just because it's branched does not mean we couldn't update it there. RHEL 10.1 release is still a ways off. I've tried to ping the other maintainers to get them to respond.
I'm not sure how soname bumps work in EPEL and I haven't worked on EPEL for yaml-cpp at all, so I'd leave it up to the other maintainers.
(In reply to Orion Poplawski from comment #2) > The epel10 branch is currently building for epel10.1. > > These are the current users in epel10: > > lhapdf-0:6.5.5-1.el10_0.x86_64 > pdns-ixfrdist-0:4.9.7-1.el10_1.x86_64 > qt-creator-0:16.0.1-2.el10_1.x86_64 > > This is an abi/api update so would need coordination I have verified in a COPR that the above deps build fine.
> I'm assuming a epel10.1 branch will show up at some point? Indeed, epel10.1 mass branching took place on 2025-08-25 [0]. > This is an abi/api update so would need coordination Even more than regular coordination, it would need to follow the Incompatible Upgrade process [1]. > I'm not sure how soname bumps work in EPEL An soname bump would conflict with the EPEL Updates Policy [2], and thus is generally avoided. Sometimes it is unavoidable, which is why we have the Incompatible process. Another alternative in the case of libraries is to create a compat package for the existing soname (e.g. yaml-cpp0.7), update the non-compat package to a newer version, and ship these in the same update. This ensures the change is minimally disruptive to other package, including those outside of EPEL. [0] https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/E374HODQPK6AGOYCLIXSE4PG7Q75AAUL/ [1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy
I've filed https://pagure.io/epel/issue/359
FEDORA-EPEL-2025-b2ba348dbe (lhapdf-6.5.5-2.el10_2, OpenColorIO-2.4.2-7.el10_2, and 4 more) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b2ba348dbe
FEDORA-EPEL-2025-b2ba348dbe has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b2ba348dbe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-b2ba348dbe (lhapdf-6.5.5-2.el10_2, OpenColorIO-2.4.2-7.el10_2, and 4 more) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.