In line with the Mass Python 2 Package Removal [0], the following (sub)packages of OpenImageIO were marked for removal: * python2-openimageio According to our query, those (sub)packages only provide a Python 2 importable module. If this is not true, please tell us why, so we can fix our query. Please remove them from your package. As said in the change document, if there is no objection in a week, we will remove the package(s) as soon as we get to it. This change might not match your packaging style, so we'd prefer if you did the change. If you need more time, please let us know here. We hope this doesn't come to you as a surprise. If you want to know our motivation for this, please read the change document [0]. [0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
I need to verify with upstream first but I may be able to switch it to Python3 but I'm also not sure what all the "consumers" are of the Python2 package...
repoquery yields nothing: $ dnf repoquery --repo=rawhide-source --whatrequires python2-openimageio $ dnf repoquery --repo=rawhide --whatrequires python2-openimageio $
I've already completed a local x86_64 mock build successfully and just kicked of a scratch build for the other arches.
I wonder whether we can do the same for OpenColorIO? Only blender depends on it, but that runs on Python 3 so I doubt it uses the Python 2 bits.
Checking Koschi I don't see any direct dependency. https://apps.fedoraproject.org/koschei/package/blender I'll try a scratch build of it next.
OpenColorIO built fine but I just realized that the python library is with the main library... Not sure why I did that but not worth splitting off at this point. # dnf repoquery --whatrequires /usr/lib64/python2.7/site-packages/PyOpenColorIO.so Last metadata expiration check: 0:01:09 ago on Mon 24 Sep 2018 03:18:40 PM CDT. OpenColorIO-devel-0:1.1.0-6.fc28.x86_64 OpenColorIO-doc-0:1.1.0-6.fc28.noarch OpenColorIO-tools-0:1.1.0-6.fc28.x86_64 OpenImageIO-0:1.8.10-1.fc28.x86_64 OpenImageIO-0:1.8.14-1.fc28.x86_64 OpenImageIO-iv-0:1.8.10-1.fc28.x86_64 OpenImageIO-iv-0:1.8.14-1.fc28.x86_64 OpenImageIO-utils-0:1.8.10-1.fc28.x86_64 OpenImageIO-utils-0:1.8.14-1.fc28.x86_64 blender-1:2.79b-2.fc28.x86_64 blender-1:2.79b-6.fc28.x86_64 blenderplayer-1:2.79b-2.fc28.x86_64 blenderplayer-1:2.79b-6.fc28.x86_64 krita-0:3.3.3-2.fc28.x86_64 krita-0:4.1.0-1.fc28.x86_64 python2-openimageio-0:1.8.10-1.fc28.x86_64 python2-openimageio-0:1.8.14-1.fc28.x86_64 It looks like there are 4 consumers of the OCIO library: - Itself - OpenImageIO - Blender - krita I'm doing local mock builds of OIIO and OCIO and will pull down SRPMS of blender and krita if that succeeds.
Not sure what results is this supposed to show: dnf repoquery --whatrequires /usr/lib64/python2.7/site-packages/PyOpenColorIO.so But blender requires just libOpenColorIO.so.1()(64bit) and so does krita.
So theoretically I wouldn't have to rebuilt those two... I can't do a repoquery search on "PyOpenColorIO.so()(64bit)" because the python library is filtered from the provides of the main OpenColorIO package.
Ok, it looks like the python modules for both OCIO and OIIO are unused in Fedora. Both rebuild fine so I'm going to kick off official builds.
Since OCIO put it in the main package I don't need to worry about it but in the case of OIIO, do I need to add an Obsoletes: for the python2 package?
Into fedora-obsolete-packages. But don't worry about it, I do it in batches.