Fedora Account System
Red Hat Associate
Red Hat Customer
I tried to rebuild this package recently in copr, but it hit a checksum failure. Would you look into this issue? If not I can help with a PR investigating this after I finish with the CMake 4.0 change, just assign this bug to me. https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0-recheck/build/9986584/ Reproducible: Always
The copr build has been purged, but I had the same issue with a local build. $ fedpkg mockbuild Downloading f5a28c74fba7a99736fe49d3a5243eca29517ae9 from https://src.fedoraproject.org/repo/pkgs Could not execute mockbuild: Could not download sources: f5a28c74fba7a99736fe49d3a5243eca29517ae9 failed checksum Let's try downloading from upstream: $ spectool -g libcorrect.spec Downloading: https://github.com/quiet/libcorrect/tarball/f5a28c74fba7a99736fe49d3a5243eca29517ae9 File '/home/da/fedora-scm/libcorrect/f5a28c74fba7a99736fe49d3a5243eca29517ae9' already present. It was already there, the mockbuild downloaded it successfully but still was unhappy. I removed that file and downloaded again with spectool, which succeeded. The newly downloaded file matches the checksum in sources. The file from dist-git did not match the checksum, it is much larger and only a tar archive, while the new file is gzipped. When unpacked, meld says that the directories are the same. No idea how all of that happened. When I delete the source file and download it via spectool a subsequent mockbuild runs just fine. (It skips the mismatch between source file and the source bundle dist-git.) Note that the name of this source bundle is a bit hard to grasp, I think we can get better results with a different path on Github, I'll look into that.
I don't think I can overwrite the sources uploaded to dist-git: $ fedpkg new-sources f5a28c74fba7a99736fe49d3a5243eca29517ae9 Uploading: f5a28c74fba7a99736fe49d3a5243eca29517ae9 to https://src.fedoraproject.org/repo/pkgs/upload.cgi File already uploaded: f5a28c74fba7a99736fe49d3a5243eca29517ae9 All sources were already uploaded. (Never needed to do that before, I guess it makes sense to deny that in general.) The minimal fix would be to change the hash in the source file to match what currently is in dist-git or to upload the source under a different name. I think while we're at it we could also: - Name the source bundle better like noted in my previous comment. - Update to the latest upstream commit. The changes are minor but would allow us to drop the "CMAKE_POLICY_VERSION_MINIMUM=3.5" from the spec file. - Further clean up the spec file. (License) Let me know if you want me do do that, I can create a PR. Also feel free to add me as a co-maintainer (fas: dreua) so I can merge and create updates as necessary and get informed of any upcoming issues in the future.
Please make a PR to point to a more sane path for `url`, something like `https://github.com/quiet/libcorrect/archive/%{sha}.tar.gz`. Note that there are other packages maintained by vascom with a similar issue.
Actually I meant to ask vascom as he the maintainer and he decides what (not) to merge. But yeah, that sounds sensible and straight forward, might make a PR later anyways.
https://src.fedoraproject.org/rpms/libcorrect/pull-request/2
PR merged.
I took the liberty to trigger a build, for rawhide/45. All green now there. For 44 we could do a rebuild but I don't think that is necessary. Is there anything left to do other than closing this issue?