Skip to content
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

Closed
FrostyX opened this issue Sep 24, 2024 · 9 comments
Closed

The make_srpm method fails with git safe.directory error #3421

FrostyX opened this issue Sep 24, 2024 · 9 comments
Assignees

Comments

@FrostyX
Copy link
Member

FrostyX commented Sep 24, 2024

Full log: builder-live.log.gz.txt

./contrib/fedora/make_srpm.sh --prerelease --output /mnt/safe-resultdir-c3dy38x1
remote: fatal: detected dubious ownership in repository at '/mnt/workdir-a7gx95j6/sssd/.git'        
remote: To add an exception for this directory, call:        
remote: 
remote: 	git config --global --add safe.directory /mnt/workdir-a7gx95j6/sssd/.git        
remote: git upload-archive: archiver died with error
fatal: sent error to the client: git upload-archive: archiver died with error

But strangely enough, after the fatal error, we still produce the SRPM?

Creating SRPM without extra patches.
setting SOURCE_DATE_EPOCH=1611187200
Wrote: /mnt/workdir-a7gx95j6/sssd/rpmbuild/SRPMS/sssd-2.10.0~beta2-0.240924.083430.git5f5077ac1.src.rpm
@pbrezina
Copy link
Contributor

@FrostyX
Copy link
Member Author

FrostyX commented Sep 24, 2024

But strangely enough, after the fatal error, we still produce the SRPM?

@pbrezina says "It produces some 20-bytes malformed tarball"

@pbrezina
Copy link
Contributor

pbrezina commented Sep 24, 2024

We run git archive ... | gzip > "$RPMBUILD/SOURCES/$NAME.tar.gz" so if git archive fail we still feed gzip with the error message and rpmbuild does not care that the tarball is malformed.

@praiskup
Copy link
Member

Has this stopped working? 77dbe36

@FrostyX
Copy link
Member Author

FrostyX commented Sep 24, 2024

Or it possibly never worked with make_srpm? I am not sure.

@pbrezina
Copy link
Contributor

Btw the last successful build was 16. 5. 2024. It is all red after this day.

pbrezina added a commit to pbrezina/sssd that referenced this issue Sep 27, 2024
All copr builds are currently failing due to:
fedora-copr/copr#3421
pbrezina added a commit to pbrezina/sssd that referenced this issue Sep 27, 2024
All copr builds are currently failing due to:
fedora-copr/copr#3421
@nikromen nikromen self-assigned this Sep 30, 2024
pbrezina added a commit to SSSD/sssd that referenced this issue Oct 4, 2024
All copr builds are currently failing due to:
fedora-copr/copr#3421

Reviewed-by: Iker Pedrosa <ipedrosa@redhat.com>
Reviewed-by: Tomáš Halman <thalman@redhat.com>
pbrezina added a commit to SSSD/sssd that referenced this issue Oct 4, 2024
All copr builds are currently failing due to:
fedora-copr/copr#3421

Reviewed-by: Iker Pedrosa <ipedrosa@redhat.com>
Reviewed-by: Tomáš Halman <thalman@redhat.com>
(cherry picked from commit b4bca98)
pbrezina added a commit to SSSD/sssd that referenced this issue Oct 4, 2024
All copr builds are currently failing due to:
fedora-copr/copr#3421

Reviewed-by: Iker Pedrosa <ipedrosa@redhat.com>
Reviewed-by: Tomáš Halman <thalman@redhat.com>
(cherry picked from commit b4bca98)
@nikromen
Copy link
Member

nikromen commented Oct 7, 2024

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?
What's the difference between taking a builder and running
/usr/bin/copr-rpmbuild --verbose --drop-resultdir --srpm --task-url https://copr.fedorainfracloud.org/backend/get-srpm-build-task/8113937
there and letting copr to do the same in a build automatically...

@nikromen
Copy link
Member

nikromen commented Oct 7, 2024

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

praiskup added a commit to praiskup/sssd that referenced this issue Oct 14, 2024
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
@praiskup
Copy link
Member

@pbrezina can you take a look at SSSD/sssd#7639 ? Git archive seems to behave fine if we don't use --remote=file://, which I'm not really sure why is needed (shouldn't be).

pbrezina pushed a commit to SSSD/sssd that referenced this issue Oct 14, 2024
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 <pbrezina@redhat.com>
pbrezina pushed a commit to SSSD/sssd that referenced this issue Oct 14, 2024
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 <pbrezina@redhat.com>
(cherry picked from commit c1434c1)
pbrezina pushed a commit to SSSD/sssd that referenced this issue Oct 14, 2024
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 <pbrezina@redhat.com>
(cherry picked from commit c1434c1)
nikromen added a commit to nikromen/copr that referenced this issue Oct 18, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

4 participants