The make test call was changed to use %make_build in d34bc42 (Use
make_build macro when running tests, 2020-01-14) in order to allow the
options to be more easily overridden. This enabled the -O option by
default, which causes the test output to be printed only after all the
tests have run.
That makes following the progress in both interactive and copr/koji
builds difficult. Replace %make_build with %__make to drop the unwanted
-O option but still allow the make command to be overridden.
The Asciidoctor project is more actively maintained than asciidoc. Use
it for building the documentation on Fedora. Asciidoctor is not
currently available for EL-6 or EL-8, though it is in EPEL for EL-7.
Exclude all EL builds for now, until we can reliably use it on EL-7 and
EL-8 (including CentOS-Stream, ideally).
This is made possible by the excellent work of both the Git and
Asciidoctor communities. Thanks in particular to brian m. carlson,
Martin Ågren, Jeff King, and Dan Allen.
When git is built with gcc10 on s390x, the diff builtin fails many
tests. Use -mtune=zEC12 as a workaround until the issue is fixed
(in gcc and/or git).
Many thanks to Jakub Jelinek for doing the hard work to track this down.
The libsecret package added a weak dependency on gnome-keyring in
4976bb0 (Recommend gnome-keyring, 2019-09-06). This pulls in a bit more
than we would like with the git package. Move the libsecret credential
helper to a subpackage.
This will make it possible for buildroots to inject arguments to
make by redefining the %__make macro.
For example, the test target uses gcc to compile fuzz-commit-graph.c, so
one thing this change will allow us to do is to pass CC=clang to make if
we want to try to build with clang.
This `cat config.mak` was added in 37cec08 (Print config.mak to aid
confirmation/verification of settings, 2019-02-02). Replace it by
piping the earlier cat through tee so we get a copy of the config on
stdout as well as written to config.mak.
The highlight package is not available for aarch64 or s390x in EL7+.
Simplify the conditional (a little) by only listing the 2 known
architectures where highlight is available for EL7+. It's not worth
adding much complexity for a dependency that is only used in 3 tests
for the gitweb subpackage.
When upgrading or reinstalling git-daemon, the rpm %postun scriptlet
runs the %systemd_postun_with_restart macro with git@.service as the
argument. The macro calls 'systemctl try-restart git@.service' which
produces an error:
$ dnf -y update git-daemon
[...]
Running scriptlet: git-daemon-2.24.1-1.fc31.x86_64 2/2
Failed to try-restart git@.service: Unit name git@.service is missing the instance name.
See system logs and 'systemctl status git@.service' for details.
Until systemd-242, the error was hidden because the systemd scriptlets
directed all output to /dev/null. That was changed in systemd commit
b0ca726585 (rpm: avoid hiding errors from systemd commands, 2019-03-20),
exposing this bug in the git-daemon scriptlets.
The misconfiguration also leaves a stale symlink in /etc/systemd if
git.socket is enabled. Removing the git-daemon package and installing
again later results in git.socket being enabled.
Neither of these are the expected nor intended outcomes. Replace
git@.service with git.socket in the systemd scriptlets.
The issue was introduced in 906d847 (Rename git.service into
git@.service and bump release, 2014-10-24). It went unnoticed until now
largely because the systemd scriptlets hid their output.
This effectively reverts 8faf622 (drop jgit BR on Fedora > 30,
2019-07-29). The jgit package is available once again; use it to allow
some compatibility tests to be run.
Resolves: https://bugzilla.redhat.com/1766626
While this could arguably be a Recommends: rather than Requires:, we
chose the latter for a few reasons. The user experience when running
gitk and selecting "Start git gui" from the menu is quite poor. No
indication is shown to the user graphically. The only hint as to why
git gui did not start is output to stdout (and is not terribly helpful
for users who may be using gitk and git-gui because they are unfamiliar
with the command-line).
There are no additional dependencies pulled in by git-gui which are not
already dependencies of gitk. And the git-gui package is relatively
small.
Lastly, the default behavior of Recommends: is the same as Requires: at
this time.
If/when any of these things change, we may revisit whether moving to
Recommends: makes more sense.
Thanks to Vasiliy Glazov and Pavel Cahyna for reporting the issue and
helping to determine the proper resolution.
Adjust skipped test number in t5541-http-push-smart.sh (skipped on
aarch64, %{arm}, and %{power64}). A new test was added in upstream
6f1194246a ("remote-curl: pass on atomic capability to remote side",
2019-10-16), resulting in the "push 2000 tags over http" test number
changing.
Release notes:
https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.24.0.txt
With the move of java packages to modules, jgit looks likely to become
unavailable as a BuildRequires in Fedora soon. Avoid it on Fedora > 30
for now.
This affects 3 tests, 2 for packfile format (t5310-pack-bitmaps) and
1 of ls-remote (t5512-ls-remote).
"git <cmd> --git-completion-helper" could fail if the command checks for
a repo before parse_options(). If the result is cached, later on when
the user moves to a worktree with repo, tab completion will still fail.
Avoid this by detecting errors and not cache the completion output.
Running jgit on Fedora >= 30 results in an immediate failure¹:
$ jgit --version
/usr/bin/build-classpath: Could not find xz-java Java extension for this JVM
/usr/bin/build-classpath: error: Some specified jars were not found
Error: Could not find or load main class org.springframework.boot.loader.JarLauncher
Skip the jgit tests if 'jgit --version' fails. This way we'll begin
running them again once the issue is resolved -- without having to make
any further changes to the git package.
Also exclude jgit on i386 arch, as upstream eclipse has dropped support.
We could adjust the conditional to only exclude on Fedora >= 30 and
i386, but the added complexity is not worth the effort.
¹ jgit bug report: https://bugzilla.redhat.com/1709624
