So here's my plan: 1. Repackage openexr from scratch including review request (Rex?) 1a. Include appropriate Provides/Obsoletes for current OpenEXR and ilmbase packages 2. Perform all testing and dependent rebuilds in a COPR first. 3. Build openexr and dependencies in a side-tag 4. Merge the side tag and retire OpenEXR and ilmbase So what am I forgetting? Thoughts?

Le jeu. 10 déc. 2020 à 13:41, Richard Shaw <hobbes1069(a)gmail.com&gt; a écrit : > > OpenEXR and ilmbase are several releases behind in Fedora and the main reason is that they combined OpenEXR & ilmbase and changed build systems to CMake. > > In digging into this, it makes sense. OpenEXR doesn't even provide a library named OpenEXR, instead: > > $ dnf repoquery --provides OpenEXR-libs > ... > libIlmImf-2_3.so.24 > libIlmImf-2_3.so.24()(64bit) > libIlmImfUtil-2_3.so.24 > libIlmImfUtil-2_3.so.24()(64bit) > > And strangely ilmbase provides mostly libraries that don't contain ilm! > > $ dnf repoquery --provides ilmbase > ... > libHalf.so.24 > libHalf.so.24()(64bit) > libIex-2_3.so.24 > libIex-2_3.so.24()(64bit) > libIexMath-2_3.so.24 > libIexMath-2_3.so.24()(64bit) > libIlmThread-2_3.so.24 > libIlmThread-2_3.so.24()(64bit) > libImath-2_3.so.24 > libImath-2_3.so.24()(64bit) > > And ALL of the headers for both packages get installed into /usr/include/OpenEXR! > > So here's my plan: > > 1. Repackage openexr from scratch including review request (Rex?) > 1a. Include appropriate Provides/Obsoletes for current OpenEXR and ilmbase packages > 2. Perform all testing and dependent rebuilds in a COPR first. > 3. Build openexr and dependencies in a side-tag > 4. Merge the side tag and retire OpenEXR and ilmbase I'm not quite following why you want to retire ilmbase ? Is the openexr package enough ?

unrelated to the package name ? That's two separate things.

OpenImageIO

For posterity here's the affected packages as far as I can tell: lembic aqsis blender calligra cinelerra-gg CTL darktable Field3D freeimage gegl04 gimp gmic gstreamer1-plugins-bad-free gtatool hugin ilmbase ImageMagick kdebase3 kdelibs kdelibs3 kde-runtime kf5-kimageformats kio-extras krita luminance-hdr luxcorerender opencv OpenEXR OpenEXR_Viewers OpenEXR_Viewers-nonfree OpenImageIO OpenSceneGraph openshadinglanguage openvdb pfstools povray prusa-slicer synfig synfigstudio vigra vips YafaRay

On Thu, Dec 10, 2020 at 1:52 PM Richard Shaw <hobbes1069(a)gmail.com <mailto:hobbes1069@gmail.com>> wrote: For posterity here's the affected packages as far as I can tell: lembic aqsis blender calligra cinelerra-gg CTL darktable Field3D freeimage gegl04 gimp gmic gstreamer1-plugins-bad-free gtatool hugin ilmbase ImageMagick kdebase3 kdelibs kdelibs3 kde-runtime kf5-kimageformats kio-extras krita luminance-hdr luxcorerender opencv OpenEXR OpenEXR_Viewers OpenEXR_Viewers-nonfree OpenImageIO OpenSceneGraph openshadinglanguage openvdb pfstools povray prusa-slicer synfig synfigstudio vigra vips YafaRay All deps built fine in COPR with the following exceptions: 1. Random strange aarch64 failures on some packages, resubmitting usually worked, so I'll ignore those errors. 2.  kdelibs is FTBFS probably due to new error reported by GCC 11, https://bugzilla.redhat.com/show_bug.cgi?id=1907031 <https://bugzilla.redhat.com/show_bug.cgi?id=1907031>;. 3. kdebase3 needs kdelibs 4. gstreamer1-plugins-bad-free refused to build in COPR due to missing deps but a scratch build completed fine... Not sure what's going on here. Overall there were not any weird issues or need to port any of them so I plan to move forward with the plan.

On Sun, Dec 13, 2020 at 9:20 AM Jeff Law <law(a)redhat.com <mailto:law@redhat.com>> wrote: So I've committed fixes for kdelibs.  So you shouldn't have to worry about that anymore. Also note I fixed an issue with OpenEXR this weekend that you don't want to lose.  Essentially it uses the wrong format directive and as a result can create a bogus compression table on some platforms (ppc64le for example).  gcc-11 will detect the bogus values in the compression table and issue a diagnostic.    See OpenEXR-gcc11.patch in rawhide. Just grabbed it and updated it for 2.5.3 (offset 10 lines). Trying a new scratch build and see if it addresses an issue with the built in testing failing on aarch64 and s390x.

On 1/1/21 7:08 PM, Richard Shaw wrote: > All builds have completed in a side tag with the exception of gmic > which looks to be failing for gcc 11 related issues? But only on > 32-bit arches. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=58753095 > <https://koji.fedoraproject.org/koji/taskinfo?taskID=58753095> Looks like a GCC bug to me. Can you get a bug report filed? THanks!