koji

#3351 git 2.35.2+ breaks buildSRPMFromSCM
Closed: Fixed by tkopecek. Opened by kevin.

Closed: Fixed
Reopen Issue

Downstream issue: https://pagure.io/fedora-infrastructure/issue/10677

builds started to fail buildSRPMFromSCM tasks with: "GenericError: Error getting commit hash for git"

This started happening when builders upgraded to git-core 2.35.3 (but the issue is the CVEs fixed in .2)

In git 2.35.3, git added a check that the top level dir of the repo needed to be the same uid as the one running git commands in that repo.
See: https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9

In the koji case, the repo is owned by mockbuild (or kojibuild) but at the end of the buildSRPMFromSCM task koji does a 'git rev-parse HEAD' in the repo as root to record the hash. This fails with this additional check.

So, I think koji either needs to do this as mockbuild/kojibuild or set the override that this is a 'safe.directory' to git.
Note however that I am seeing some things about that setting not being properly checked. ;(

Maybe we need a pygit2-based wrapper to replace using git itself. Our usage of git is pretty simple, so using pygit2 instead would probably be better.

It should be pretty easy fix here. Just parse the source before chowning the content. /I'll test it/

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

Seems to work: PR #3355

Metadata Update from @tkopecek:
- Issue tagged with: easyfix

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.29
- Issue tagged with: testing-ready

Metadata Update from @jcupova:
- Issue tagged with: testing-done

Commit 904ab880 fixes this issue

Commit 61b84325 fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3351

Please continue any further discussion there.
Metadata
None

easyfix testing-done testing-ready

None
None
Low
None
Related Pull Requests
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.