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?
This bug appears to have been reported against 'rawhide' during the Fedora Linux 45 development cycle. Changing version to 45.