Trouble Pushing New Release of Package Due to Checksum Mismatch [Resolved]

Project Discussion
1

Hey all. Been maintaining the Diffuse package (a python-based diff utility) for some years now, and have hit a wall while attempting to build and push a new release. You can see the task for my fourth attempt to do so here: Koji Task 144857186.

Failure appears to be due to a checksum mismatch (check mock_output.log and root.log), but when building the package locally or on COPR, there is no such issue, and I have verified that the offending file’s checksum matches that listed in sources numerous times.

I am already using the new release on my primary workstation. Any help resolving this issue would be greatly appreciated, and apologies in advance if I’m overlooking something that may be obvious to another.

2

Check that the checksum in the sources? file matches the tarball you uploaded.

I suspect it does not match.

3

Make sure you’re not hitting this bug that causes the lookaside cache to serve files with wrong HTTP headers.

1 Like
4

Unfortunately, I have done this many times and it is always a match :upside_down_face:

5

This seems likely. Thank you for the tip! Reading that thread now.

Update 1: Looks like I am hitting that bug. Tarball generated by running fedpkg sources differs significantly from the one generated by running fedpkg import on the src.rpm file (from local and COPR builds). Mime type differs as well. First time I have run into this.

Update 2: Assumed I could work around it through using the tarball pulled in by fedpkg sources (and changing the hash to match that file), but curl spits out a 404 error. Not quite sure how to proceed now, but I think you pointed me in the right direction.

6

Bring up the issue in a fedora infra ticket maybe?

Or bring up the fedora devel mailing list.

7

Thank you Barry. About to do just that.

8

Resolved after a good deal of fussing around, just when I was at the end of my rope. Builds are now succeeding. Looks like I was hitting issues related to the codeload URL in the spec, and the bug mentioned by @decathorpe . Many thanks to you both!

9

The bug mentioned upthread should not affect official builds at all, only scratch builds.

10

Noted and thank you for clarifying. Purely a change on github’s side then. For reference, switching from codeload.github.com to github.com in the source URL is what produced the expected results and resolved the issue. While contents were identical when decompressed, the tarballs themselves — when fetched with curl during the build process — were not.

I habitually import from a source RPM when preparing to push new releases, so this went by unnoticed (tarballs pulled in that way did not differ on my end, so no checksum mismatch). Happy to have it sorted and, ultimately, @decathorpe did send me down the right trail :grinning_face: