We're working on rebasing the minizip-ng to version 4.0.1 (https://bugzilla.redhat.com/show_bug.cgi?id=2235710). There have been some API changes in the shared library and OpenColorIO is the only dependency that is FTBFS with the new minizip-ng version. Please rebase it to at least 2.3.0 where this commit has been added: https://github.com/AcademySoftwareFoundation/OpenColorIO/commit/bdc4cd124140f997cdec1c5d7db72b1550fe7eac It's now a blocker for us. Reproducible: Always
Yup, saw the new version just hadn't gotten around to it yet. I tried building in mock but got some errors: [ 72%] Linking CXX executable ocioarchive cd /builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build/src/apps/ocioarchive && /usr/bin/cmake -E cmake_link_script CMakeFiles/ocioarchive.dir/link.txt --verbose=1 gmake[2]: Leaving directory '/builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build' /usr/bin/g++ -w -msse2 -DNDEBUG -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes CMakeFiles/ocioarchive.dir/main.cpp.o -o ocioarchive -Wl,-rpath,/builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build/src/OpenColorIO: ../../apputils/libapputils.a ../../OpenColorIO/libOpenColorIO.so.2.3.0 /usr/lib64/libminizip.so /usr/lib64/libpystring.so /usr/lib64/libz.so /usr/bin/ld: CMakeFiles/ocioarchive.dir/main.cpp.o: relocation R_X86_64_32 against `.bss' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status gmake[2]: *** [src/apps/ocioarchive/CMakeFiles/ocioarchive.dir/build.make:105: src/apps/ocioarchive/ocioarchive] Error 1 gmake[2]: Leaving directory '/builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build' gmake[1]: *** [CMakeFiles/Makefile2:15325: src/apps/ocioarchive/CMakeFiles/ocioarchive.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... I've never had to play with the flags before so I may need to report this upstream.
Worked with upstream and got it to build locally but I should probably do a scratch build before I claim success. For posterity, the following packages will need to be rebuilt: blender krita luxcorerender OpenImageIO usd
So i686 failed: [ 8%] Building CXX object src/OpenColorIO/CMakeFiles/OpenColorIO.dir/CPUInfo.cpp.o cd /builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build/src/OpenColorIO && /usr/bin/g++ -DOCIO_HEADLESS_ENABLED -DOpenColorIO_EXPORTS -I/builddir/build/BUILD/OpenColorIO-2.3.0/include/OpenColorIO/.. -I/builddir/build/BUILD/OpenColorIO-2.3.0/include/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build/include/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build/src/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.0/redhat-linux-build/generated_include -isystem /usr/include/Imath -isystem /builddir/build/BUILD/OpenColorIO-2.3.0/ext/sampleicc/src/include -isystem /builddir/build/BUILD/OpenColorIO-2.3.0/src/utils/.. -isystem /builddir/build/BUILD/OpenColorIO-2.3.0/ext/xxHash/src/include -isystem /usr/include/minizip -w -msse2 -O2 -g -DNDEBUG -std=c++14 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -DUSE_GCC -Wall -Wextra -Wswitch-enum -MD -MT src/OpenColorIO/CMakeFiles/OpenColorIO.dir/CPUInfo.cpp.o -MF CMakeFiles/OpenColorIO.dir/CPUInfo.cpp.o.d -o CMakeFiles/OpenColorIO.dir/CPUInfo.cpp.o -c /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp: Assembler messages: /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:54: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:56: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:54: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:56: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:54: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:56: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:54: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:56: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:54: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:56: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:54: Error: bad register name `%rbx' /builddir/build/BUILD/OpenColorIO-2.3.0/src/OpenColorIO/CPUInfo.cpp:56: Error: bad register name `%rbx' I'm tempted to just use ExcludeArch.
Hi, so what is the resolution? This will block us when we will want to continue with: https://src.fedoraproject.org/rpms/minizip-ng/pull-request/2#
3 packages: usd, krita, and blender have not been updated to support a change in the OCIO API. Of the 3, the first two had pull requests but Blender does not plan to support the new API until next year. I have posted to the devel list and blender maintainers for assistance. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IMJJDVACGCYCUW5VM2O6NZKULXMBO2CG/
Hi, could you please ping (maybe file a Bugzilla) the maintainers of the packages that don't build? It looks like they didn't respond to your email on the Fedora Devel list.
I CC'd the blender maintainer email as well. Perhaps a blender bug blocking this one will get more attention.
While you're looking at updating - I'm looking at updating yaml-cpp to 0.8.0 here: https://src.fedoraproject.org/rpms/yaml-cpp/pull-request/2 Looks like OpenColorIO needs to get updated to the new target name: CMake Error at share/cmake/modules/Findyaml-cpp.cmake:46 (get_target_property): get_target_property() called with non-existent target "yaml-cpp". 0.8.0 changes the cmake target name to "yaml-cpp::yaml-cpp".
Upstream issue for yaml-cpp detection: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1858
Current upstream proposal for yaml-cpp fix: https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/1891
I took a quick look at 2.3.2 but get: [ 26%] Building CXX object src/OpenColorIO/CMakeFiles/OpenColorIO.dir/OCIOZArchive.cpp.o cd /builddir/build/BUILD/OpenColorIO-2.3.2/redhat-linux-build/src/OpenColorIO && /usr/lib64/ccache/g++ -DOCIO_HEADLESS_ENABLED -DOpenColorIO_EXPORTS -I/builddir/build/BUILD/OpenColorIO-2.3.2/include/OpenColorIO/.. -I/builddir/build/BUILD/OpenColorIO-2.3.2/include/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.2/src/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.2/redhat-linux-build/include/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.2/redhat-linux-build/src/OpenColorIO -I/builddir/build/BUILD/OpenColorIO-2.3.2/redhat-linux-build/generated_include -isystem /usr/include/Imath -isystem /usr/include/pystring -isystem /builddir/build/BUILD/OpenColorIO-2.3.2/ext/sampleicc/src/include -isystem /builddir/build/BUILD/OpenColorIO-2.3.2/src/utils/.. -isystem /builddir/build/BUILD/OpenColorIO-2.3.2/ext/xxHash/src/include -isystem /usr/include/minizip -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c++14 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -DUSE_GCC -Wall -Wextra -Wswitch-enum -MD -MT src/OpenColorIO/CMakeFiles/OpenColorIO.dir/OCIOZArchive.cpp.o -MF CMakeFiles/OpenColorIO.dir/OCIOZArchive.cpp.o.d -o CMakeFiles/OpenColorIO.dir/OCIOZArchive.cpp.o -c /builddir/build/BUILD/OpenColorIO-2.3.2/src/OpenColorIO/OCIOZArchive.cpp /builddir/build/BUILD/OpenColorIO-2.3.2/src/OpenColorIO/OCIOZArchive.cpp:229:5: error: user-defined literal in preprocessor expression 229 | #if MZ_VERSION_BUILD >= 040000 | ^~~~~~~~~~~~~~~~ /usr/include/minizip/mz.h:#define MZ_VERSION_BUILD (03000a) I have no idea what this error is about. Does it not like the ()? Does it need to be 0x03000a to be a proper hex number?
Very minimal discussion: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1818
Filed https://src.fedoraproject.org/rpms/minizip-ng/pull-request/8
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
I was about to rebuild OpenColorIO in the side tag (f41-build-side-88169) for OpenEXR 3.2.4 when I noticed that Rawhide has had OpenColorIO 2.3.2 committed for two months, but it was never built, and the current build is still 2.2.1. Looking at the release notes[1][2][3] and the source diff[4], this is an ABI-incompatible update from 2.2.1. Is there a particular reason this wasn’t built, or was it an oversight? I’m currently doing a quick impact check[5] of OpenColorIO 2.3.2 without the OpenEXR update. Assuming that looks OK, should I just include the rebuild for this SONAME version bump into the one for OpenEXR? Thanks! [1] https://github.com/AcademySoftwareFoundation/OpenColorIO/releases/tag/v2.3.0 [2] https://github.com/AcademySoftwareFoundation/OpenColorIO/releases/tag/v2.3.1 [3] https://github.com/AcademySoftwareFoundation/OpenColorIO/releases/tag/v2.3.2 [4] https://github.com/AcademySoftwareFoundation/OpenColorIO/compare/v2.2.1...v2.3.2
[5] https://copr.fedorainfracloud.org/coprs/music/OpenColorIO/packages/
Mainly stalled because of the above issues and I haven't gotten around to trying again. There's still the issue of Blender not supporting it unless that has changed.
(In reply to Richard Shaw from comment #17) > Mainly stalled because of the above issues and I haven't gotten around to > trying again. > > There's still the issue of Blender not supporting it unless that has changed. It seems like everything but Blender is working in COPR, although I’m only building for x86_64 there. Blender might work too; I’m waiting for usd to finish building before trying it. Skimming the above, though, it sounds like I should rebuild everything on *all* architectures to be sure. On the other hand, even if this *does* work now, I’m thinking the right thing to do is to revert https://src.fedoraproject.org/rpms/OpenColorIO/c/a5370dab3afe62467c64dafe8c01b9a7a1c98aa8?branch=rawhide for now, bump the release number, and rebuild version 2.2.1 into the side tag for OpenEXR. Then, we can handle the 2.3.2 upgrade as a separate exercise—with a new PR, a proper announcement of the ABI break, and a dedicated impact check. What do you think?
Since you're already in progress, try to build everything, if Blender is still a no-go then I'll revert the update.
(In reply to Richard Shaw from comment #19) > Since you're already in progress, try to build everything, if Blender is > still a no-go then I'll revert the update. OK, everything worked in COPR on x86_64; the arch-dependent issues mentioned earlier in the issue are only on i686; and i686 was already excluded in the current build on Rawhide, so we don’t have to worry about ExcludeArch propagation. I’ll try it. I’ll need to rebuild OpenImageIO, blender, krita, luxcorerender, and usd a second time in the side tag for OpenColorIO 2.3.2, and add calligra to the side tag.
Following up on this... Any progress? Also, having another issue updated to OpenColorIO 2.4.0. Luxcorerender requires a macro from blender-rpm-macros but it's not evaluating properly. Now my side tag has been open too long. I mainly mention this in case we run into the same problem on F40.
Well, I finished my rebuilds for OpenEXR 3.2.4 back in April, so OpenColorIO is at 2.3.2 in F41 and F42. Is there something else that you were waiting for someone to work on? Blender has been updated a couple of times in F41/F42 since then, so if it wasn’t ready for OpenColorIO 2.4.0 then, it might be now. There’s still another upstream release 4.2.3 that hasn’t been packaged yet, bug 2318763. I sometimes fix bugs in Blender or rebuild it as needed, but I don’t normally do significant packaging work on it. Do I understand correctly that you’re trying to update OpenColorIO past 2.2.x in Fedora 40? That doesn’t seem like a good idea, since the SONAME version is e.g. 2.2, and only patch-releases are ABI-compatible. See https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases. The same issue would apply to updating past 2.3.x in Fedora 41.
No, sorry I was noting the new issue in case it was in issue here. If the work is done then I guess we can close this bug?
Sure, given minizip-ng is at 4.x and OpenColorIO is at 2.3.x in F41 and F42, it does seem like we can close the bug.