(Slightly) incompatible update for EPEL 8 and 9: p7zip -> 7zip #367
Labels
No labels
blocked
Closed As
Approved
Closed As
Cant Fix
Closed As
Deferred
Closed As
Duplicate
Closed As
Fixed
Closed As
Nothing to do
Closed As
Rejected
Closed As
Unable to fix
Closed As
Won't fix
meeting
backlog status
needs review
backlog status
ready
chore
documentation
planned
points
01
points
02
points
03
points
05
points
08
points
13
priority
high
priority
low
priority
medium
sprint status
blocked
sprint status
done
sprint status
in progress
sprint status
review
sprint status
to do
technical debt
work item
bug
work item
epic
work item
spike
work item
task
work item
user story
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
epel/steering#367
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I just filed https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/UI3SZQWHFQYGQHE4EHKEYAT72WRJEUGD/ proposing to replace p7zip with 7zip in EPEL 8 and 9 (EPEL 10 already ships 7zip and never shipped p7zip)
Accidentally left out EPEL 8 from the initial email, I'll reply with a correction and link this issue
Seems reasonable at first glance.
Are there any other packages known to be affected? I see a few packages that (build)require p7zip and/or p7zip-plugins. Even if the rawhide versions of these packages built fine with 7zip, the EPEL versions may be older and might not. An impact check in a copr would help check this.
I'll also suggest doing EPEL 9 only first, and then based on those results deciding if it's worth the risk to do the same in EPEL 8.
That makes perfect sense. I've created https://copr.fedorainfracloud.org/coprs/salimma/7zip-transition-epel9/
GraphicsMagick is in a bad state
So I'm checking the others first, and might just propose updating and cleaning up GM in Rawhide and backporting it to EPEL 9 too.
OK, everything builds fine except GraphicsMagick that I'll probably try and fix both in Rawhide and in epel9 - given the CVEs I'd rather fix Fedora as well and fast-forward it to EPEL - there's already an issue open asking to update EPEL 8 and 9 anyway
GraphicsMagick also built using @carlwgeorge 's suggestion of just grabbing the URL for the SRPM from Koji and uploading that. So we do have a COPR bug in that it can't regenerate a patchN SRPM even for targets like EPEL 9 where that's actually valid, but it should not be a blocker for actual builds in Koji (and anyway is not due to this change)
are we ... good to go?
@carlwgeorge wrote in #367 (comment):
conky-manager and retrace-server don't seem to be branched for epel9
As per voted on today's EPEL Steering Committee meeting, this was approved to proceed on epel9 (with appropriate announcements).
epel8 incompat update vote will wait on conky-manager, retrace-server and other epel8 build results.
Should I keep this open for epel8 or should we close and I'll open a new one for that?
I think it's fine to keep using this one ticket.