Bug 1934674

Summary: Please build signify for EPEL 7 and 8
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: signifyAssignee: Robert Scheck <redhat-bugzilla>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: marcus
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: signify-30-6.el8 signify-30-6.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-09 01:12:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Scheck 2021-03-03 16:39:58 UTC
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.

Comment 1 Marcus Müller 2021-03-03 18:12:03 UTC
What does maintaining packages for EPEL 7 / 8 entail? Is it more than having another branch in my pagure repo?

Comment 2 Robert Scheck 2021-03-03 19:06:31 UTC
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).

Comment 3 Robert Scheck 2021-03-03 19:08:23 UTC
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.

Comment 4 Marcus Müller 2021-03-03 19:10:32 UTC
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?

Comment 5 Robert Scheck 2021-03-03 20:38:45 UTC
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".

Comment 6 Ben Cotton 2021-08-10 13:42:38 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 7 Robert Scheck 2021-09-09 19:25:14 UTC
Ping?

Comment 8 Ben Cotton 2022-02-08 21:40:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 9 Robert Scheck 2022-05-28 22:39:32 UTC
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

Comment 10 Robert Scheck 2022-05-28 23:05:18 UTC
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

Comment 11 Fedora Update System 2022-05-31 22:33:40 UTC
FEDORA-EPEL-2022-a2eb809713 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a2eb809713

Comment 12 Fedora Update System 2022-05-31 22:33:41 UTC
FEDORA-EPEL-2022-4f936ca9e4 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4f936ca9e4

Comment 13 Fedora Update System 2022-06-01 03:09:29 UTC
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.

Comment 14 Fedora Update System 2022-06-01 03:15:04 UTC
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.

Comment 15 Fedora Update System 2022-06-09 01:12:43 UTC
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.

Comment 16 Fedora Update System 2022-06-09 01:39:09 UTC
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.