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-pillowAssignee: Sandro Mani <manisandro>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel10CC: 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
Please branch and build for EPEL 10.

Comment 1 Kevin Fenzi 2024-10-10 20:59:04 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.

Comment 2 Romain Geissler 2024-10-27 22:04:59 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.

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.

Comment 3 Ben Beasley 2024-10-28 14:20:11 UTC
(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}}

Comment 4 Ben Beasley 2024-10-28 14:34:59 UTC
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.

Comment 5 Sandro Mani 2024-10-28 14:40:56 UTC
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

Comment 6 Ben Beasley 2024-10-28 14:48:15 UTC
(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.