#7408 Git commit hash mismatch in Koji builds
Closed: Upstream 5 years ago Opened 5 years ago by churchyard.

I've juts noticed this very weird thing and maybe I'm missing something but here it is:

I've merged this PR https://src.fedoraproject.org/rpms/python3/pull-request/73 at 2018-11-27 15:28:38 UTC.

The master branch was at 4f22584498d101092afb723fde527159a1cf22aa after the merge. Notice how the commit adds the patch number 315.

I build python3 on master/rawhide, built started at 2018-11-27 15:30:44 UTC (that's after I've merged that PR).

The build is python3-3.7.1-4.fc30 yet that page says the source was:

git+https://src.fedoraproject.org/rpms/python3.git#31d96372deeb66e3a6b061f075cf70fdd3205966

That commit hash however is 2 commits before the merged PR.

https://src.fedoraproject.org/rpms/python3/commits/master

And in fact it was already attempted to built before at 2018-11-23.

What's weird is that 31d96372 was FTBFS and the PR fixed it, and in fact, examining the build logs shows that patch 315 (the fix) was applied.

Patch #315 (00315-test_email-mktime.patch):
+ echo 'Patch #315 (00315-test_email-mktime.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0

Patch 315 was not existing at all at 31d96372.

Hence something is very weird and the commit hash in Koji is not the commit hash of the source. This can be very dangerous for both legal and practical reasons.

The Koji build is even listed in src.fp.o under the 31d96372 commit.

(I've laso noticed that the associated task lists the correct hash: https://koji.fedoraproject.org/koji/taskinfo?taskID=31144412)


This looks like a bug in Koji hub, recycle_build() function. I may submit PR upstream, if no one else beats me.

Metadata Update from @mizdebsk:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

5 years ago

I've reproduced the problem in staging Koji, applied a hotfix and verified that it fixes the problem. I will sent PR upstream later.

Metadata Update from @mizdebsk:
- Issue assigned to mizdebsk

5 years ago

Out of curiosity, what does recycling build mean?

Generally Koji allows only one build with given NVR, but there is an exception. Whenever a build fails or is cancelled you can submit a new build with the same NVR, possibly from a different source. This called recycling a build and it means reusing previously failed or cancelled build.

The issue was forwarded upstream and pull request submitted. Waiting for upstream response.

Metadata Update from @mizdebsk:
- Issue priority set to: Waiting on External (was: Waiting on Assignee)

5 years ago

Upstream acknowledged this issue and they are planning to fix it in upcoming Koji 1.17 release. I'm closing this ticket as upstream - Fedora Infrastructure will inherit the fix from upstream release.

Metadata Update from @mizdebsk:
- Issue close_status updated to: Upstream
- Issue status updated to: Closed (was: Open)

5 years ago

Metadata Update from @mizdebsk:
- Issue priority set to: None (was: Waiting on External)

5 years ago

Login to comment on this ticket.

Metadata