Bug 2390998 - Please branch and build bear in epel10 and epel10.0
Summary: Please branch and build bear in epel10 and epel10.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: bear
Version: epel10
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Aleksei Bavshin
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-08-26 09:11 UTC by François Poirotte
Modified: 2026-07-15 00:26 UTC (History)
6 users (show)

Fixed In Version: bear-4.1.4-1.el10_3
Clone Of:
Environment:
Last Closed: 2026-07-15 00:26:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description François Poirotte 2025-08-26 09:11:23 UTC
Hello,

I would like to use bear on CentOS Stream 10 and noticed it isn't included in EPEL anymore.

The package builds fine on Fedora Rawhide (see https://koschei.fedoraproject.org/package/bear?collection=f44).
Please include it in EPEL 10.

Best regards,
François

Comment 1 Ben Beasley 2025-08-26 11:43:30 UTC
Since EPEL10.1 branching just happened, you’re probably asking for EPEL10, EPEL10.1, and EPEL10.0.

I’m not interested in maintaining this in EPEL (I’m not the primary maintainer or an active co-maintainer of the bear package, and salimma is the EPEL bug assignee – weirdly, despite not being an official maintainer of the package), but I did a quick test and confirmed that "fedpkg --release epel10 mockbuild -- --postinstall" would succeed just fine using the current contents of the Rawhide branch, so I don’t see any real obstacles.

Comment 2 fedepell 2026-06-26 13:24:27 UTC
I would be interested in this too as asked at my org. I confirm also current rawhide which is pretty new builds with no issues in mock. I would not be asking to "backport" to 10.0/10.1, we can attach from 10/10.3, but if there are more requests we can also "backport" (maybe at least to 10.2) 

If I can give a hand to maintain in EPEL10 I'd gladly do if I can have permissions on the branch!

Thanks!
F.

Comment 3 Ben Beasley 2026-06-27 10:07:41 UTC
I’ve talked to Michel Lind, and it’s my understanding that he isn’t interested in maintaining an EPEL10 branch. Since fedepell is a packager and has offered to co-maintain, ideally Aleksei Bavshin (alebastr) would assign EPEL branch permissions. If you aren’t able to get in contact with Aleksei, you can use https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#stalled-request-process to get co-maintainership via FESCo and release engineering.

Comment 4 Aleksei Bavshin 2026-07-06 06:20:12 UTC
Sorry for delay, I wanted to find some time to adequately test the package before branching. Well, I managed to verify that bear 4.x works on a small project with GCC only, but nothing more and I don't foresee any improvement.

Thus, fedepell gets the collaborator access to all epel branches. Thanks for offering to help, and let me know if you also want commit access to Fedora branches.

A good question is which version we want to have in epel10:

 - 3.x is unmaintained and fails the tests due to incompatibility with the available version of python3-lit. Otherwise it should be buildable for all branched epel10.x versions.

 - 4.x is being actively developed, with Rust dependency bumps made in each release. For example, this week's release no longer builds in Fedora due to an incompatible ctor dependency update 0.6 -> 1.0.
   EPEL update policy forbids incompatible rust dependency package updates in branched versions, making maintenance of this package in 10.2 and older branches tricky or outright impossible. Upstream development style is also very unfriendly (completely unintentionally) to backporting of any fixes to previous releases.

Comment 5 Ben Beasley 2026-07-06 09:08:27 UTC
(In reply to Aleksei Bavshin from comment #4)
>    EPEL update policy forbids incompatible rust dependency package updates
> in branched versions, making maintenance of this package in 10.2 and older
> branches tricky or outright impossible. Upstream development style is also
> very unfriendly (completely unintentionally) to backporting of any fixes to
> previous releases.

I maintain some large Rust packages, like uv and ruff, that have EPEL10 branches and very frequent SemVer-breaking changes in their dependency tree. I have simply accepted that, in almost all cases, these will not get bugfix or even security fixes in EPEL minor-version branches, and therefore users of these branches will have to wait six months or so for these updates to be branched from the leading branch with the next RHEL minor release. (CentOS Stream users can benefit from the leading branch, of course.) I don’t think that this is particularly good for users, but I have accepted that it is the system working as the EPEL Steering Committee has designed it, and I have chosen to stop worrying about it.

Comment 6 fedepell 2026-07-09 02:20:48 UTC
Aleksei thanks for the access to the repository!

Following also the comments from Ben I would go for 4.1.4 (current as in Rawhide) that works on EL10 (specifically will go to 10.3) and then as suggested we possibly will bump at next 10.x.

If there are no complaints I will merge from Rawhide and build in EPEL10 in the coming days!

Thanks!

Comment 7 Fedora Update System 2026-07-11 02:53:13 UTC
FEDORA-EPEL-2026-63520f00d3 (bear-4.1.4-1.el10_3) has been submitted as an update to Fedora EPEL 10.3.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-63520f00d3

Comment 8 Fedora Update System 2026-07-12 01:18:00 UTC
FEDORA-EPEL-2026-63520f00d3 has been pushed to the Fedora EPEL 10.3 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-63520f00d3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2026-07-15 00:26:23 UTC
FEDORA-EPEL-2026-63520f00d3 (bear-4.1.4-1.el10_3) has been pushed to the Fedora EPEL 10.3 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.