Description of problem: Please build signify for EPEL 7 and 8. Version-Release number of selected component (if applicable): signify-30-3.fc35 Actual results: No signify in EPEL 7 and 8. Expected results: signify-30-3.el7 and signify-30-3.el8 - or better ;-) Additional info: Please let me know if you are not interested in maintaining the package on EPEL 7 and 8 branches.
What does maintaining packages for EPEL 7 / 8 entail? Is it more than having another branch in my pagure repo?
As of writing it's just another two branches. This might change in the future, if signify e.g. requires newer versions of some build-time components that are not satisfied by RHEL 7 and 8 anymore, or maybe other new dependencies that are not in RHEL or EPEL. But if that happens, you still could retire the branches at that time (also happened to other packages). In general, the EPEL branches might not be able to catch up with latest spec file macro changes (given they are more or less equivalent older Fedora releases) and it's recommented to announce updates with breaking changes to the EPEL mailing list). See also https://fedoraproject.org/wiki/EPEL:Packaging and https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for example. If desired, I'm happy to take care of the EPEL branches or to help in case of issues (also at a later point, Cc me simply).
Finally, I would like to note that signify is IMHO currently a quite simple package (on packaging level) and that I treat it as unlikely that OpenBSD upstream will introduce breaking changes with about every update...both together should make it hopefully smoothly to maintain it for EPEL 7 and 8.
Agreeing with that assessment, but do note I'm not tracking OpenBSD itself, but a project that tracks upstream and extracts signify to be separately buildable, and the maintainer does consider third-party patches; the branches I'll have to request are "epel7", "epel8", right?
Yes, I understand that you're going to use the portable project, but that shouldn't make the project completely differently behaving. And yes, the branches are called "epel7" and "epel8".
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Ping?
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
If you do not wish to maintain signify in epel7 and epel8, or do not think you will be able to do this in a timely manner, I would be happy to be a co-maintainer of the package (FAS robert); please add me through https://src.fedoraproject.org/rpms/signify/adduser
Created the following SCM requests based on permissions from bug #2034331: - https://pagure.io/releng/fedora-scm-requests/issue/44664 - https://pagure.io/releng/fedora-scm-requests/issue/44665
FEDORA-EPEL-2022-a2eb809713 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a2eb809713
FEDORA-EPEL-2022-4f936ca9e4 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4f936ca9e4
FEDORA-EPEL-2022-a2eb809713 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a2eb809713 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-4f936ca9e4 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4f936ca9e4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-a2eb809713 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-4f936ca9e4 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.