Releases retrieved: 4.0.1 Upstream release that is considered latest: 4.0.1 Current version/release in rawhide: 3.0.7-4.fc39 URL: https://github.com/zlib-ng/minizip-ng Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/301509/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/minizip-ng
As this is a major release bump, the soname has changed its version. Actually, it was changed from `libminizip.so.3` to `libminizip.so.1` due to the PR: https://github.com/zlib-ng/minizip-ng/pull/721 The problem is that the `minizip-compat` (zlib subpackage) uses the `libminizip.so.1`. Thus it would conflict, and we need to resolve it. Also, we would probably need to side-tag rebuild all packages that depend on the `minizip-ng` package to use the new soname. I've discussed this issue with adobes and he will take a look at it with my help.
Here is the list of the packages that require the soname: $ dnf -q repoquery --enablerepo rawhide --whatrequires 'libminizip.so.3()(64bit)' --source OpenColorIO-2.2.1-5.fc39.src.rpm collada-dom-2.5.0-33.fc39.src.rpm dolphin-emu-5.0.19793-3.fc39.src.rpm freexl-2.0.0-2.fc39.src.rpm librasterlite2-1.1.0-0.13.beta1.fc40.src.rpm libsbml-5.19.0-28.fc39.src.rpm libspatialite-5.1.0-1.fc40.src.rpm libxlsxwriter-1.1.5-3.fc39.src.rpm minizip-ng-3.0.7-4.fc39.src.rpm qmc2-0.243-5.fc39.src.rpm sigil-0.9.14-18.fc39.src.rpm vxl-2.0.2-27.fc39.src.rpm widelands-1.1-3.fc39.src.rpm xiphos-4.2.1-20.fc39.src.rpm zfstream-20041202-38.fc39.src.rpm None of them are part of the minimal buildroot.
I've tried to rebuild all of the packages in the COPR project: https://copr.fedorainfracloud.org/coprs/ljavorsk/minizip-ng/packages/ Let's see the results when all of them finish their builds.
Unfortunately, it seems that `minizip-compat` can't be fully replaced by `minizip-ng` due to incompatibilities with some packages. One example is the `libdigidocpp` package, which requires `minizip-compat-devel` to be built. After changing this dependecy to `minizip-ng-devel`, the package fails to build because the CMake configuration for this project requires `minizip` < 2.0.0, which is currently only provided by `minizip-compat`. This version requirement has been introduced in the following upstream commit: https://github.com/open-eid/libdigidocpp/commit/3d40b5d10411587b1bbc4d084429a8a7105e298d After reverting this commit, the package build still fails due to various errors that I haven't been able to fix.
Since we can't use the `libminizip.so.1` I reverted the upstream commit which introduced it (https://github.com/zlib-ng/minizip-ng/commit/d14fb2f29429a0352f2dcffdcb59f4ae213e1b3f) and tried to rebuild all packages with the new soname `libminizip.so.4`. All of the packages has been rebuilt in the COPR project: https://copr.fedorainfracloud.org/coprs/ljavorsk/minizip-ng/packages/ Only two packages are failing with the following errors: dolphin-emu -> error: expected unqualified-id before numeric constant 23 | constexpr u16 IP_PROTOCOL = 0x800; OpenColorIO -> error: too many arguments to function ‘void* mz_zip_reader_create()’ 513 | mz_zip_reader_create(&reader); Looks like the `dolphin-emu` package is FTBFS (I've tried to scratch-build it and it confirmed my suspicion): https://koji.fedoraproject.org/koji/taskinfo?taskID=106188547 However, the `OpenColorIO` fails on the minizip functions. I think it might have something with the new API/ABI changes in the package. I also tried to scratch-build it with the current minizip-ng version and it built successfully: https://koji.fedoraproject.org/koji/taskinfo?taskID=106238675
I've reported the build issues to upstream to see if they know something: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1856
I just checked if the packages that require the `minizip-compat` library, are circle-dependent (they require themselves due to some transitive requirement) and none of them are. Here is the list of the packages I've checked: $ dnf -q repoquery --enablerepo rawhide --whatrequires 'libminizip.so.1()(64bit)' --source chromium-118.0.5993.70-1.fc40.src.rpm domoticz-2022.1-11.fc39.src.rpm hashcat-6.2.6-3.fc39.src.rpm libdigidocpp-3.16.0-1.fc40.src.rpm springlobby-0.273-3.fc39.src.rpm zlib-1.2.13-4.fc39.src.rpm Adam has already filled BZs to the two of them that are failing to built with minizip-ng-compat. Linking them here as well
I've also created a Fedora Change draft for this: https://fedoraproject.org/wiki/Changes/MinizipNGTransition
Releases retrieved: 4.0.2 Upstream release that is considered latest: 4.0.2 Current version/release in rawhide: 3.0.7-4.fc39 URL: https://github.com/zlib-ng/minizip-ng Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/301509/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/minizip-ng
Chromium and libdigidocpp (both FTBFS after migrating to minizip-ng-compat) does have their own minizip library bundled. This could be used if the transition is not ready by the time of implementing the change. OpenColorIO (FTBFS after soname bump with new 4th version API), this could be resolved by not upgrading, however it's not desired as we want to have this new version ready before RHEL-10 fork.
Releases retrieved: 4.0.3 Upstream release that is considered latest: 4.0.3 Current version/release in rawhide: 3.0.7-4.fc39 URL: https://github.com/zlib-ng/minizip-ng Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/301509/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/minizip-ng
All dependent packages have been rebuilt in side-tag and submitted to Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2023-cea7a20e14
Due to the problems with OpenColorIO dependencies with the new API, we decided not to rebase to version 4. Closing this until the OpenColorIO dependencies port to the new API and we can rebase. However, the Fedora Change process is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2252766