Bug 2313988
| Summary: | [RFE:EPEL10] Please branch and build python-pillow for EPEL 10 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Michael J Gruber <mjg> |
| Component: | python-pillow | Assignee: | Sandro Mani <manisandro> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel10 | CC: | code, epel-packagers-sig, infra-sig, kevin, manisandro, python-packagers-sig, romain.geissler |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-10-28 14:40:56 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: | |||
| Bug Depends On: | 2321396, 2321397 | ||
| Bug Blocks: | 2303880, 2313930, 2321321 | ||
|
Description
Michael J Gruber
2024-09-21 14:48:44 UTC
Looks like this needs: 'libimagequant-devel' 'python3-olefile' 'python3-qt5' I suppose the qt5 subpackage should/could be dropped? but the other two seem needed. > Looks like this needs: > > 'libimagequant-devel' > 'python3-olefile' > 'python3-qt5' > > I suppose the qt5 subpackage should/could be dropped? but the other two seem needed. The first two dependencies are now available in EPEL 10. For qt5, I saw this recent commit https://src.fedoraproject.org/rpms/python-pillow/c/35ac96e804f4a2b74064ded441e7eec05a199663?branch=rawhide enabling qt5 support in python-pillow *ONLY* for RHEL, doing pretty much the contrary of what is suggested here to drop the qt5 dependency in EPEL. Not sure what should be done here. (In reply to Romain Geissler from comment #2) > For qt5, I saw this recent commit > https://src.fedoraproject.org/rpms/python-pillow/c/ > 35ac96e804f4a2b74064ded441e7eec05a199663?branch=rawhide enabling qt5 support > in python-pillow *ONLY* for RHEL, doing pretty much the contrary of what is > suggested here to drop the qt5 dependency in EPEL. Not sure what should be > done here. The %bcond_with / %bcond_without macros have always been confusing: %bcond_with qt means disable the qt conditional by default. So: %if 0%{?rhel} %bcond_with qt %else %bcond_without qt %endif seems to do what you wanted, default-disabling qt support in RHEL and default-enabling it elsewhere. A clearer way to write this (compatible everywhere but EPEL8) would be: %bcond qt %{expr:!0%{?rhel}} or perhaps even more clearly: %bcond qt %{expr:%{undefined rhel}} I just did a successful scratch-build of the Rawhide branch in EPEL10, so it looks like nothing is blocking this now, and all that remains is for someone to actually branch and build it. https://koji.fedoraproject.org/koji/taskinfo?taskID=125290796 As a python-packagers-sig member, I have adequate permissions to branch and build this, but I’m not signing up to support it. Therefore, I’ll leave branching to Sandro or to an EPEL or Python SIG member who wants to actually support this package. I've built it now [1] - didn't work a couple of days ago when I created the branch, it kept telling me that the package was not listed for epel10-testing or similar. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=125290985 (In reply to Sandro Mani from comment #5) > I've built it now [1] - didn't work a couple of days ago when I created the > branch, it kept telling me that the package was not listed for > epel10-testing or similar. > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=125290985 That usually means your SCM request, https://pagure.io/releng/fedora-scm-requests/issue/69286, failed partway through due to flaky server issues. I’ve been seeing that happen more frequently in the past few months than before. Usually someone, in this case jnsamyak, will eventually try to fix these half-completed requests, but sometimes it takes a few days for that to happen. Since commenting "retry" in the bug is almost always sufficient, and anyone can do it, you can fix these yourself if you like. |