Thanks for asking this question (and for the heads-up that the problem
is fixed). I’ll do as Neal suggested for python-Rtree, as well as a
couple of other packages (python-mapbox-earcut, iml) that were in a
similar situtation.
– Ben
On 5/27/22 08:37, Neal Gompa wrote:
On Fri, May 27, 2022 at 8:00 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
Hey EPEL folks,
The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as
the frozen set of packages from CentOS Stream made it segfault during build.
So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the
meantime).
So, we should probbaly build and ship the package in EPEL 9.
But we should also remove/obsolete/replace the EPEL 9 build somehow.
I suppose there are multiple options here:
1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next
2. build in epel9, untag the old epel9-next build
Generally, you bump to raise the EVR and then the automation Troy has
can untag everything in EPEL next that's lower than what's in EPEL.
What is the general guideline in this situation?
Related, but not necessarily blocking question: Should EPEL 9 Next be purged
after each RHEL 9.Y release and all the purged builds built in regular EPEL 9
instead?
Yes, please, for the sake of my mirror hosting space...
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
