-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The make_srpm method fails with git safe.directory error #3421
Comments
This is the script we use: https://github.com/SSSD/sssd/blob/master/contrib/fedora/make_srpm.sh |
@pbrezina says "It produces some 20-bytes malformed tarball" |
We run |
Has this stopped working? 77dbe36 |
Or it possibly never worked with |
Btw the last successful build was 16. 5. 2024. It is all red after this day. |
All copr builds are currently failing due to: fedora-copr/copr#3421
All copr builds are currently failing due to: fedora-copr/copr#3421
All copr builds are currently failing due to: fedora-copr/copr#3421 Reviewed-by: Iker Pedrosa <[email protected]> Reviewed-by: Tomáš Halman <[email protected]>
All copr builds are currently failing due to: fedora-copr/copr#3421 Reviewed-by: Iker Pedrosa <[email protected]> Reviewed-by: Tomáš Halman <[email protected]> (cherry picked from commit b4bca98)
All copr builds are currently failing due to: fedora-copr/copr#3421 Reviewed-by: Iker Pedrosa <[email protected]> Reviewed-by: Tomáš Halman <[email protected]> (cherry picked from commit b4bca98)
this is really still hapenning: https://download.copr.fedorainfracloud.org/results/nikromen/playground/srpm-builds/08113937/builder-live.log.gz but once I take builder and try to debug it manually there, it'll pass every time 🤷 shouldn't this also produce the safe.directory fail? |
the command to create safe directory in .gitconfig is correct in both cases, but when srpm build is handled by copr, it somehow either has no effect or something mystically "cancels" the already set safe directory |
It seems that current (autumn 2024) git releases somehow dislike the use of `--remote=file://` when it applies the [safe] directory checks. The option doesn't seem to be useful though, so let's drop it to fix the Copr builds. Relates: fedora-copr/copr#3421
@pbrezina can you take a look at SSSD/sssd#7639 ? Git archive seems to behave fine if we don't use |
It seems that current (autumn 2024) git releases somehow dislike the use of `--remote=file://` when it applies the [safe] directory checks. The option doesn't seem to be useful though, so let's drop it to fix the Copr builds. Relates: fedora-copr/copr#3421 Reviewed-by: Pavel Březina <[email protected]>
It seems that current (autumn 2024) git releases somehow dislike the use of `--remote=file://` when it applies the [safe] directory checks. The option doesn't seem to be useful though, so let's drop it to fix the Copr builds. Relates: fedora-copr/copr#3421 Reviewed-by: Pavel Březina <[email protected]> (cherry picked from commit c1434c1)
It seems that current (autumn 2024) git releases somehow dislike the use of `--remote=file://` when it applies the [safe] directory checks. The option doesn't seem to be useful though, so let's drop it to fix the Copr builds. Relates: fedora-copr/copr#3421 Reviewed-by: Pavel Březina <[email protected]> (cherry picked from commit c1434c1)
This is byproduct of fedora-copr#3421 While <dir> to <dir>/* safe directory is not needed now, since different fix was applied to the issue above, some users might consider this useful - they mmioght be doing manual git clones in their mock directory, which will raise safe-directory error. There is no need to bother them with this, thus turning this off for their whole subdirectory. Relates fedora-copr#3421
This is byproduct of #3421 While <dir> to <dir>/* safe directory is not needed now, since different fix was applied to the issue above, some users might consider this useful - they mmioght be doing manual git clones in their mock directory, which will raise safe-directory error. There is no need to bother them with this, thus turning this off for their whole subdirectory. Relates #3421
Full log: builder-live.log.gz.txt
But strangely enough, after the fatal error, we still produce the SRPM?
The text was updated successfully, but these errors were encountered: