releng

#11469 rpms/nss dist-git repo missing a commit that was used to do a koji build
Closed: Fixed by kalev. Opened by kalev.

Closed: Fixed
Reopen Issue

When we look at https://koji.fedoraproject.org/koji/buildinfo?buildID=2168051 we can see that the build was done from git commit aaf3397a66c43830ea2b234891a488b76464585b. That commit however appears to be missing from nss dist-git repo:

$ fedpkg clone nss
cd Cloning into 'nss'...
remote: Enumerating objects: 5356, done.
remote: Counting objects: 100% (85/85), done.
remote: Compressing objects: 100% (75/75), done.
remote: Total 5356 (delta 60), reused 18 (delta 7), pack-reused 5271
Receiving objects: 100% (5356/5356), 1.46 MiB | 957.00 KiB/s, done.
Resolving deltas: 100% (3307/3307), done.
$ cd nss
$ git describe aaf3397a66c43830ea2b234891a488b76464585b
fatal: aaf3397a66c43830ea2b234891a488b76464585b is neither a commit nor blob

What is going on here? Is it a fallout from an earlier issue where it was possible to do koji builds from pull request forks? Is there a way to fix the repo and merge the missing commit?

I noticed this because it broke one of the flatpak maintenance scripts.

CC @fkrenzel

https://src.fedoraproject.org/fork/fkrenzel/rpms/nss/c/aaf3397a66c43830ea2b234891a488b76464585b

The changes seem to be in the rawhide branch but with different hash https://src.fedoraproject.org/rpms/nss/c/ef1f194244b8c32a4085a153443b4c77dc18ad35?branch=rawhide

@churchyard you are right about the PR, that is what has caused the issue, unfortunately I don't see a way to fix it.
A new version will be released in a couple of day, that should fix the issue.

@churchyard @humaton The build is stable for f38.
Please let me know if the issue still persists.

The issue is that there is a koji build, nss-3.89.0-2.fc38 that doesn't have a matching git commit in the git repository. I don't think a newer build "fixes" it in any way.

I know that in the past, it's been important to keep a track of each git hash that was used to do an official build. See e.g. https://pagure.io/fesco/issue/2387 and https://pagure.io/releng/pull-request/9454 for related discussion.

So my question is: is there a way to make the commit that churchyard found (https://src.fedoraproject.org/fork/fkrenzel/rpms/nss/c/aaf3397a66c43830ea2b234891a488b76464585b) reachable from the HEAD of one of the branches in the main dist-git repo?

Yes, this was one of the cases that happened before it was fixed.

See https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/6DABMA2BPLMBC6NKWBX7PKQLD2TY5VLX/

I have no idea how we can fix it after the fact, but I'm open to ideas on that.

I can only think of a few:

  1. Do nothing, realize that this is a very rare thing and work around it.

  2. force push into the repo the exact commit, but I am not sure we could get the hash to exactly match up? and then it would break everyone who has it checked out.

  3. Modify the koji database and change the hash to the one that is committed.

  4. Something more clever.

I think do nothing is a valid option here. 2 and 3 sound a bit too hacky to me.

What I think we could do is extract the missing commit from the fork, https://src.fedoraproject.org/fork/fkrenzel/rpms/nss/ and git merge it into the f38 branch of the non-fork repo, or alternatively push it to a newly created branch. Either way the commit would then become reachable through a branch.

I don't know how to get the commit from the fork though - it's not reachable through any of the branches so a simple git clone didn't get it for me. I don't seem to be able to git fetch it either:

git fetch fkrenzel aaf3397a66c43830ea2b234891a488b76464585b
error: Server does not allow request for unadvertised object aaf3397a66c43830ea2b234891a488b76464585b

Ideas? Can someone tarball fork/fkrenzel/rpms/nss/ git repo for me, directly on the server? The commit seems to be there, just not accessible through cloning for some reason.
Maybe it's not really worth spending a lot of time on it though :)
Edited by kalev

Hey @kalev
I have created a new branch on my repo missing_commit that has the missing commit. You should be able to fetch the commit now.

Nice, thanks! With this I was able to do a trivial merge like https://src.fedoraproject.org/fork/kalev/rpms/nss/commits/merge_missing_commit_to_f38 that brings the histories together.

@fkrenzel is it OK with you if I push it to the f38 branch? Pagure doesn't let me create a pull request for this for some reason - I guess maybe because it doesn't actually change any files.

It would be Ok with me, but I am not sure it would be possible to push this without the --force flag

OK, pushed. It's a fast-forward (so no --force needed) because of the merge I did. It added two commits on top of the f38 branch, the missing commit + the merge commit:
https://src.fedoraproject.org/rpms/nss/c/aaf3397a66c43830ea2b234891a488b76464585b?branch=f38
https://src.fedoraproject.org/rpms/nss/c/45b3aa116a0c7980ecc12287f31ca5d42f1d2ec9?branch=f38

Should be all good now so I think we can close this ticket. Thanks for the help!

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

@kalev Thanks a lot!
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.