Latest upstream release: 1.1 Current version/release in rawhide: 0.7.6-9.fc33 URL: https://stachenov.github.io/quazip/ 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://fedoraproject.org/wiki/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/4141/
An HTTP error occurred downloading the package's new Source URLs: Getting https://github.com/stachenov/quazip/archive/1.1/quazip-1.1.tar.gz to ./quazip-1.1.tar.gz
Hi Nicolas, what's your plan with this update? I have got a project update (qmapshack 1.16.0) that requires quazip 1.1. Seems the major change is in the cmake module name, not in API.
I don't have much time theses days. Help welcomed...
Hi Nicolas, I maintain a package (chessx) that is going to depend on quazip once I unbundle it [1], so I came across this BZ. I had a go at updating quazip to the new 1.1 version - see [2]. It seems the API itself remained unchanged/backwards compatible, but the name of the library, include paths, and CMake modules have changed. While some packages (ckb-next, keepassxc, krita, qcad) are smart enough to detect either quazip version, others (bletchmame, fritzing, gimagereader, GLC_lib, nomacs, qmapshack, texstudio, chessx with my current unbundle patch) would fail to build against the new library. To allow for smoother transition for these packages, I added compat symlinks and the legacy CMake module to the -devel subpackages, so that they will still build against the new quazip without modification. The rebuild will, however, make them link against the new library name and thus needs to happen in a side tag along with the quazip update. I built all the dependent packages against quazip 1.1 in COPR [3] and it seems the compat hacks are working (see also COPR without the hacks [4] for comparison). Once quazip 1.1 is in Rawhide, the dependent packages should gradually be moved to using the new pkgconfig or CMake modules so that the compat hacks can be eventually removed. If you're fine with this approach, let me know and I'll upload the new tarball and open a proper pull request. If you don't have time, I'd be happy to become a co-maintainer and coordinate the rebuilds with the dependent package maintainers (I'm not a provenpackager). [1] https://src.fedoraproject.org/rpms/chessx/pull-request/3 [2] https://src.fedoraproject.org/fork/omos/rpms/quazip/c/4113b6e724503d45d382971e1b8d15451098ff04 [3] https://copr.fedorainfracloud.org/coprs/omos/quazip/monitor/ [4] https://copr.fedorainfracloud.org/coprs/omos/quazip-nohack/monitor/
Thanks for this excellent work. I've added you as a co-maintainer. Feel free to proceed with your plan as needed.
Cool, thanks! I'll start with the preparation, then.
FEDORA-2021-cfc992d3e9 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.