With the recent change that drops apr-util-bdb build require, in
favor of httpd, t5540 started failing on tests using git-httpd-push.
This patch sets DavLockDBType to sdbm, fixing these failures.
Move %rcpath definition added d050347 (use tilde versioning for release
candidates, 2023-05-12) after %real_version. Otherwise, it is not
parsed correctly.
(I'm pretty sure it worked in the past, but it certainly doesn't now.)
From the release notes for 2.30.8¹:
* CVE-2023-22490:
Using a specially-crafted repository, Git can be tricked into using
its local clone optimization even when using a non-local transport.
Though Git will abort local clones whose source $GIT_DIR/objects
directory contains symbolic links (c.f., CVE-2022-39253), the objects
directory itself may still be a symbolic link.
These two may be combined to include arbitrary files based on known
paths on the victim's filesystem within the malicious repository's
working copy, allowing for data exfiltration in a similar manner as
CVE-2022-39253.
* CVE-2023-23946:
By feeding a crafted input to "git apply", a path outside the
working tree can be overwritten as the user who is running "git
apply".
* A mismatched type in `attr.c::read_attr_from_index()` which could
cause Git to errantly reject attributes on Windows and 32-bit Linux
has been corrected.
Credit for finding CVE-2023-22490 goes to yvvdwf, and the fix was
developed by Taylor Blau, with additional help from others on the
Git security mailing list.
Credit for finding CVE-2023-23946 goes to Joern Schneeweisz, and the
fix was developed by Patrick Steinhardt.
¹ https://github.com/git/git/raw/v2.39.2/Documentation/RelNotes/2.30.8.txt
The git send-email command uses Email::Valid to check addresses. If
Email::Valid is not present, it falls back to a more basic regex match
(which is not nearly as thorough as the checks Email::Valid performs).
While Fedora (and EPEL 7/8 provide perl-Email-Valid, RHEL does not and
does not wish to add the dependency. Make it easier for RHEL to fork &
sync from us by making the dependency conditional.
References:
https://bugzilla.redhat.com/2020487https://bugzilla.redhat.com/2046203http://public-inbox.org/git/20220620004427.3586240-1-trawets@amazon.com/T/#u4414f61 (add more git-email perl dependencies, 2021-11-13)
From the release notes for 2.30.7¹:
* CVE-2022-41903:
git log has the ability to display commits using an arbitrary
format with its --format specifiers. This functionality is also
exposed to git archive via the export-subst gitattribute.
When processing the padding operators (e.g., %<(, %<|(, %>(,
%>>(, or %><( ), an integer overflow can occur in
pretty.c::format_and_pad_commit() where a size_t is improperly
stored as an int, and then added as an offset to a subsequent
memcpy() call.
This overflow can be triggered directly by a user running a
command which invokes the commit formatting machinery (e.g., git
log --format=...). It may also be triggered indirectly through
git archive via the export-subst mechanism, which expands format
specifiers inside of files within the repository during a git
archive.
This integer overflow can result in arbitrary heap writes, which
may result in remote code execution.
* CVE-2022-23521:
gitattributes are a mechanism to allow defining attributes for
paths. These attributes can be defined by adding a `.gitattributes`
file to the repository, which contains a set of file patterns and
the attributes that should be set for paths matching this pattern.
When parsing gitattributes, multiple integer overflows can occur
when there is a huge number of path patterns, a huge number of
attributes for a single pattern, or when the declared attribute
names are huge.
These overflows can be triggered via a crafted `.gitattributes` file
that may be part of the commit history. Git silently splits lines
longer than 2KB when parsing gitattributes from a file, but not when
parsing them from the index. Consequentially, the failure mode
depends on whether the file exists in the working tree, the index or
both.
This integer overflow can result in arbitrary heap reads and writes,
which may result in remote code execution.
Credit for finding CVE-2022-41903 goes to Joern Schneeweisz of GitLab.
An initial fix was authored by Markus Vervier of X41 D-Sec. Credit for
finding CVE-2022-23521 goes to Markus Vervier and Eric Sesterhenn of X41
D-Sec. This work was sponsored by OSTIF.
The proposed fixes have been polished and extended to cover additional
findings by Patrick Steinhardt of GitLab, with help from others on the
Git security mailing list.
¹ https://github.com/git/git/raw/v2.39.1/Documentation/RelNotes/2.30.7.txt
ce294ea (Remove perl(MODULE_COMPAT), it will be replaced by generators,
2023-01-13) removed the `Requires: perl(:MODULE_COMPAT_*)` entirely.
This is not suitable for merging to older Fedora or RHEL releases. Make
the requirement conditional.
When a build fails, the contents of t/test-results and the trash
directories can be quite useful for debugging. This is particularly
true when the failures occur only in Koji, where we can't get a shell
and poke around.
Create a compressed tarball and encode it with base64 to allow it to be
output along with the normal build output. Include instruction on how
to extract the base64-encoded content from the build log inline.
The tar archive is compressed with zstd which provides a good balance of
speed and size. The compression level of 17 was chosen after a number
of tests against real test failures, as opposed to entirely random
selection. ;)
Add mod_http2 BuildRequires for t5559-http-fetch-smart-http2; skip it on
EL7, which lacks it. Ignore the expected 'missing HTTP2' output from
t5551-http-fetch-smart. Use a strict pattern to avoid unintended
matches.
Sadly, we must also disable t5559 for now. It fails very often across
all architectures. The most common failure is "large fetch-pack
requests can be sent using chunked encoding" (t5559.30), but earlier
tests have also failed. Until these failures are understood and
resolved, the entire test is disabled globally. (It's also disabled for
EL-7, which is redundant now but won't be after we re-enable the test
globally in the near future.)
We can't simply skip the mod_http2 dependency here because we set
GIT_TEST_HTTPD=true. Per upstream 73c49a4474 (t: run t5551 tests with
both HTTP and HTTP/2, 2022-11-11):
If HTTP/2 isn't supported on a given platform, then t5559 should
bail during the webserver setup, and gracefully skip all tests
(unless GIT_TEST_HTTPD has been changed from "auto" to "yes", where
the point is to complain when webserver setup fails).
Also ignore the 'missing BUILTIN_TXT_$builtin' output which comes from
upstream a0c3244796 (doc SYNOPSIS & -h: use "-" to separate words in
labels, not "_", 2022-10-13). We may want to loosen this in the future,
but for now ignore it because it doesn't help us identify missing test
dependencies.
Release notes:
https://github.com/git/git/raw/v2.39.0-rc0/Documentation/RelNotes/2.39.0.txt
The license data was gathered from the 2.38.1 tarball. The licensecheck
tool was run:
find -type f -regextype egrep ! -regex '^(Documentation/.*\.txt$|(t/(chainlint|perf/p[0-9]{4}|t[0-9]{4}).*))' \
-exec licensecheck --shortname-scheme spdx {} + | LANG=C sort >licensecheck
The contents were reviewed, removing files which are not shipped or were
UNKNOWN to licensecheck. Of the UNKNOWN files, most lacked a specific
license header and are thus treated as GPL-2.0-only. The code in
reftable/ is licensed as BSD 3-Clause per reftable/LICENSE.
This is Go source code which requires compilation to be used. It is
licensed differently than git; shipping it changes the License tag.
Let's avoid it for now. If it turns out to be widely used, we can
restore it later (and ship it in binary form).
From the release notes for 2.30.6¹
* CVE-2022-39253:
When relying on the `--local` clone optimization, Git dereferences
symbolic links in the source repository before creating hardlinks
(or copies) of the dereferenced link in the destination repository.
This can lead to surprising behavior where arbitrary files are
present in a repository's `$GIT_DIR` when cloning from a malicious
repository.
Git will no longer dereference symbolic links via the `--local`
clone mechanism, and will instead refuse to clone repositories that
have symbolic links present in the `$GIT_DIR/objects` directory.
Additionally, the value of `protocol.file.allow` is changed to be
"user" by default.
* CVE-2022-39260:
An overly-long command string given to `git shell` can result in
overflow in `split_cmdline()`, leading to arbitrary heap writes and
remote code execution when `git shell` is exposed and the directory
`$HOME/git-shell-commands` exists.
`git shell` is taught to refuse interactive commands that are
longer than 4MiB in size. `split_cmdline()` is hardened to reject
inputs larger than 2GiB.
Credit for finding CVE-2022-39253 goes to Cory Snider of Mirantis. The
fix was authored by Taylor Blau, with help from Johannes Schindelin.
Credit for finding CVE-2022-39260 goes to Kevin Backhouse of GitHub.
The fix was authored by Kevin Backhouse, Jeff King, and Taylor Blau.
¹ https://github.com/git/git/raw/v2.38.1/Documentation/RelNotes/2.30.6.txt
Newer rpmlint rightly points out this minor gitweb issue.
Fixing it is a low priority as we need to arrange the change only for
newer releases, keeping the old layout on existing systems. This is
tracked in bug 479613.
We removed '%{_emacs_version}' in 3395646 (remove --with/--without emacs
build conditional, 2022-06-13). Drop the unnecessary filter from the
rpmlint config.
Add filters for several new checks in rpmlint 2.x: files-duplicate;
package-with-huge-docs; and potential-bashisms.
Also ignore unused-direct-shlib-dependency for libpcre2. While this
is accurate, the additional linking would be tricky to remove from the
upstream Makefile. It would almost certainly not be worth the effort.
Lastly (even though it's the first line in the file), drop the unneeded
'from Config import *' directive. The rpmlint config is no longer
loaded directly as python code (yay!).
In 986b772 (Split 'git subtree' into a separate package, 2018-02-07), I
mistakenly created the package as arch-specific. It should have been
noarch; it is merely a shell script.
Adjust number of t5541 "push 2000 tags over http" test, which we skip on
aarch64 and ppc64le arches. It was shifted from 36 to 37 by upstream
b0c4adcdd7 (remote-curl: send Accept-Language header to server,
2022-07-11).
Release notes:
https://github.com/git/git/raw/v2.38.0-rc0/Documentation/RelNotes/2.38.0.txt
When running multiple builds, we frequently see failures due to port
conflicts, particularly with httpd tests. Retry with a different port
when the test function start_httpd() fails to reduce these spurious
failures.
We should not need to skip t9115-git-svn-dcommit-funky-renames as a
result. Remove it from GIT_SKIP_TESTS.
Similarly, adjust the git-daemon and svnserve start functions.
We have not shipped git-archimport since 3f0dc97 (Drop git-arch on
fedora >= 16, 2011-07-26). Replace the scattered references to it in
the spec file with a small group of commands in %prep to remove it
entirely.
The `BuildRequires: systemd` was added in d7389e7 (use systemd instead
of xinetd (bz 737183), 2013-04-30). Since then, the systemd macros have
been split into a subpackage¹. Adjust our BuildRequires (with an
exception for EL-7).
Replace `Requires*: systemd` in git-daemon with %{?systemd_requires}.
¹ https://src.fedoraproject.org/rpms/systemd/c/c9030f0 (Split out the
rpm macros into systemd-rpm-macros subpackage, 2018-11-02),
From the release notes for 2.30.5¹:
This release contains minor fix-ups for the changes that went into
Git 2.30.3 and 2.30.4, addressing CVE-2022-29187.
* The safety check that verifies a safe ownership of the Git
worktree is now extended to also cover the ownership of the Git
directory (and the `.git` file, if there is any).
Carlo Marcelo Arenas Belón (1):
setup: tighten ownership checks post CVE-2022-24765
Additionally, from the release notes for 2.37.1²:
* Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
correctly record a removed file to the index, which is an old
regression but has become widely known because the C version has
become the default in the latest release.
¹ https://github.com/git/git/raw/v2.37.1/Documentation/RelNotes/2.30.5.txt
² https://github.com/git/git/raw/v2.37.1/Documentation/RelNotes/2.37.1.txt
The emacs bcond support was added cdea01a (drop emacs-git stub for
fedora >= 34 (#1882360), 2020-10-10). Now that Fedora 34 is EOL, we no
longer need the conditional.
The GIT_SKIP_TESTS variable does not support brace expansion. It was my
mistake thinking that it did. List the tests to skip properly.
If we had a longer list and *really* wanted to use brace expansion, we
could do something like this:
GIT_SKIP_TESTS="$GIT_SKIP_TESTS $(echo t5300.{10,12,14} t5303.{5,7,11} t6300.{35,91,92})"
In this case, that's more characters _and_ more complexity, so it makes
no sense to use it. (Even if it were shorter, it doesn't necessarily
justify the extra complexity.)
Expand the list of tests to skip to cover those which fail due to the
earlier skipped tests.
Additionally, GIT_SKIP_TESTS is (unintentionally) set on systems other
than EL8. Fix the conditional to only skip these tests on s390x on EL8.
Per the release announcement¹, these patches...
address usability issues in the recent releases 'v2.35.2',
'v2.34.2', 'v2.33.2', 'v2.32.1', 'v2.31.2', and 'v2.30.3', where
each "safe" directory has to be listed on the safe.directory
configuration variables. A broader escape hatch has been added so
that the value '*' can be used to declare "my colleagues and their
repositories I may ever visit are all trustworthy".
¹ https://lore.kernel.org/git/xmqq1qy04iqa.fsf@gitster.g/
These tests fail on s390x, but only with EL8. They succeed on Fedora
and EL9. This suggests the issue is not with git. Skip them to avoid
blocking the Fedora releases which we care most about while still
allowing builds in COPR and elsewhere for all Fedora/EPEL releases.
Regarding CVE-2022-24765, the release announcement says:
On multi-user machines, Git users might find themselves
unexpectedly in a Git worktree, e.g. when another user created a
repository in `C:\.git`, in a mounted network drive or in a
scratch space. Merely having a Git-aware prompt that runs `git
status` (or `git diff`) and navigating to a directory which is
supposedly not a Git worktree, or opening such a directory in an
editor or IDE such as VS Code or Atom, will potentially run
commands defined by that other user.
The new `safe.directory` setting may be used in either the system or
global configuration to list directories which git should consider safe
even if they are owned by someone other than the current user.
Release notes:
https://github.com/git/git/raw/v2.36.0-rc2/Documentation/RelNotes/2.36.0.txt
The httpd package was slimmed down per rhbz#2070517. Use the new
httpd-core package for the test suite requirements on F37+.
While here, adjust a nearby '# endif' comment to match reality.
The %_package_note_file definition added in 1dc07e7 (set path to linker
script in %_package_note_file, 2022-01-24) does not support release
candidates. Fix it.
Add 'fsmonitor--daemon is not supported on this platform' and 'missing
!REFFILES' to git.skip-test-patterns to match new test prerequisites
which are not relevant for our builds.
Adjust number of t5541 "push 2000 tags over http" test. It was shifted
from 35 to 36 by upstream c36c62859a (tests: use "test_hook" for misc
"mkdir -p" and "chmod" cases, 2022-03-17).
Replace `%__make test` with `%__make -C t all` to avoid re-compiling in
%check. This is an issue I have yet to fully diagnose. I suspect that
it is related to the nice work Ævar Arnfjörð Bjarmason has done upstream
to improve the efficiency and correctness of the build process. Work
around it for the moment.
Release notes:
https://github.com/git/git/raw/v2.36.0-rc0/Documentation/RelNotes/2.36.0.txt
The package-notes feature¹ creates a linker script in %{buildsubdir}.
Unfortunately, %{buildsubdir} is not set in %prep, leaving us with an
incorrect path to the linker script. The build then fails with:
/usr/bin/ld: cannot open linker script file
/builddir/build/BUILD/.package_note-git-2.35.0-0.2.rc2.fc36.3.x86_64.ld:
No such file or directory
Set the path to the linker script via %_package_note_file, per
suggestion by Zbigniew Jędrzejewski-Szmek².
References:
¹ https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
² https://bugzilla.redhat.com/2044028#c10
The scalar command is being worked on incrementally upstream.
As it matures, we may consider building and distributing it. Whether
that will happen before it graduates from contrib or not is anyone's
guess.
For the moment, remove it to avoid cruft in git-core-doc.
Git now requires C99 support and a zlib with uncompress2 by default.
On EL7, gcc-4.8.5 requires a flag to enable C99 support.
Compilation also fails without -fPIC on EL7, for reasons of which I am
not entirely clear. (I do not like making a change I cannot justify or
explain properly, but it is better than dropping EL7 support until I
have time to learn the reason(s).)
Update the %build_cflags macro when building on EL7 to enable C99
support and set -fPIC.
Define NO_UNCOMPRESS2 to use compat/zlib-uncompress2.c.
The git checkout command crashes when run multiple times, if
`.git/refs/remotes/origin/HEAD` is manually copied into
`.git/refs/heads/$branch-name`.
Strictly, this is repository corruption, but it has been silently
tolerated until upstream 9081a421 (checkout: fix "branch info" memory
leaks, 2021-11-16), which added some sanity checking of the data.
Loosen the check via Junio's upstream commit 519947b69a (checkout: avoid
BUG() when hitting a broken repository, 2022-01-21).
Add openssh-clients BuildRequires, for ssh-add. Upstream 350a2518c8
(ssh signing: support non ssh-* keytypes, 2021-11-19), added `ssh-add`
as a requirement of t7528-signed-commit-ssh's "sign commits using
literal public keys with ssh-agent" test.
Replace the openssh BR added in e8896ce (update to 2.34.0, 2021-11-15)
with openssh-clients. The latter requires the former.
Apply Taylor Blau's patch to fix a use-after-free bug in fmt-merge-msg¹.
Add `missing !LONG_IS_64BIT,EXPENSIVE` to git.skip-test-patterns. It is
used in t1051-large-conversion after upstream 596b5e77c9 (clean/smudge:
allow clean filters to process extremely large files, 2021-11-02).
Release notes:
https://github.com/git/git/raw/v2.35.0-rc0/Documentation/RelNotes/2.35.0.txt
¹ https://lore.kernel.org/git/CAHk-=whXPxWL7z3GiPkaDt+yygrRmagrYUnib7Lx=Vvrqx2ufg@mail.gmail.com/
The output of gpgsm changed slightly in gnupg-2.3, causing the git tests
for x509 signatures to be skipped. Update the tests to use the
machine-parseable --with-colons output.
It also appears that we need to reload the gpg-agent in order to pick up
the changes the test library makes to the trustlist.txt file. It might
be better to store that file with the other gpg files in the test suite
rather than generating it.
While we're at it, reload all the gpg components rather than just
gpg-agent. Adjust the earlier gpgconf kill to use the 'all' keyword as
well.
Next up, gpgsm removed a debug line from it's output which exposes a
problem in git's gpg-interface code. The git code presumes that the
'[GNUPG:] SIG_CREATED' line will follow a newline. That is no longer
true. The debug line was removed from GnuPG in a6d2f3133 (sm: Replace
some debug message by log_error or log_info, 2020-04-21).
Finally, a minor bug in gpgsm causes the error message returned when a
certificate is not found to differ from previous versions¹. Extend the
grep pattern in the test suite to catch both error messages.
¹ https://lists.gnupg.org/pipermail/gnupg-devel/2021-November/034991.html
Release notes:
https://github.com/git/git/raw/v2.34.0/Documentation/RelNotes/2.34.0.txt
Add `BuildRequires: openssh` for the `ssh-keygen` command; it is needed
to test the newly-added ssh signing support¹. Refer to the `gpg.format`
and `gpg.ssh.*` variables in git-config(1) for details.
[Unfortunately, openssh-8.7 has a bug in the requisite `ssh-keygen -Y
find-principals` command, which will limit the usefulness of this
feature on Fedora 35/36 until openssh is either rebased to 8.8 or the
patch² is backported. The git testsuite has been taught to skip the
tests when this bug is present, in upstream ca7a5bf4bd (t/lib-gpg: avoid
broken versions of ssh-keygen, 2021-11-10), but that won't help users
who try out this new feature. Hopefully we can get openssh-8.7 in
Fedora 35 & 36 patched or updated before too long.]
We have `Requires: openssh-clients` in git-core already. The
openssh-clients package requires openssh so we don't _need_ to add an
install-time requirement to ensure the `ssh-keygen` command is
available.
Ignore RUNTIME_PREFIX and SYMLINKS_WINDOWS test prerequisites when
looking for missing test suite BuildRequires³.
The RUNTIME_PREFIX prerequisite was added in b7d11a0f5d (tests: exercise
the RUNTIME_PREFIX feature, 2021-07-24)⁴. It is used to build binaries
which can be easily relocated, which we don't need in our builds.
The SYMLINKS_WINDOWS prerequisite was added in 3e7d4888e5 (mingw: align
symlinks-related rmdir() behavior with Linux, 2021-08-02)⁵. It is, as
the name implies, Windows-specific.
¹ b5726a5d9c (ssh signing: preliminary
refactoring and clean-up, 2021-09-10) and the commits which follow.
² ca0e455b93,
4afe431da9, and
https://www.mail-archive.com/source-changes@openbsd.org/msg127496.html
(plus the replies, which point out the typo in the first patch)
³ fa92661 (Add grep patterns for checking skipped tests, 2019-02-02)
⁴ b7d11a0f5d
⁵ 3e7d4888e5
There were a few dependencies missing prior to the change in git-2.33
which Ondřej fixed in the previous commit.
Of the few dependencies being added, only Email::Address and
Sys::Hostname weren't already pulled in by other dependencies when
installing git-email. They each have fallback options, so they aren't
critical to the function of the application. (We could use Recommends
here, if we wanted -- though neither pull in any additional packages at
this time.)
Resolves: rhbz#2020487
In git version 2.33.0, git-send-email.perl has optimized modules
loading[1]. This resulted in perl.req not detecting requires properly,
because it doesn't detect requires that are not at the start of new line.
This commit adds explicit Requires into the spec file.
[1]f4dc9432fd
contrib/hooks/multimail is no longer distributed with git
The multimail hook was removed from the git contrib tree. From the
upstream commit f74d11471f (multimail: stop shipping a copy,
2021-06-10):
The multimail project is developed independently and has its own project
page. Traditionally, we shipped a copy in contrib/.
However, such a copy is prone to become stale, and users are much better
served to be directed to the actual project instead.
Upstream commit 3b072c577b (tests: replace test_tristate with "git
env--helper", 2019-06-21) semi-broke the git-svn tests which require
httpd. This was subsequently fixed in upstream commit 6a20b62d7e
(t/lib-git-svn.sh: check GIT_TEST_SVN_HTTPD when running SVN HTTP tests,
2019-09-06).
The upstream fix also adjusted the variable name to follow the preferred
naming scheme, i.e. GIT_SVN_TEST_ -> GIT_TEST_SVN_. Fix the variable in
%check to indicate that we want those tests to run.
We were still running the tests because we had all the necessary
dependencies. But we want to ensure that we don't skip them
opportunistically if those dependencies ever change.
Update comment which suggest a method for (manually) checking such
variables in the test suite.
The Documentation/cmd-list.perl script requires File::Compare to
generate various cmds-$area.txt file which are included in the main git
help. This has been broken since File::Compare was split from the main
perl package in 3b63b8c (Subpackage File::Compare, 2020-01-06)¹.
The result is a broken git man/html page. In git(1), the output is:
HIGH-LEVEL COMMANDS (PORCELAIN)
We separate the porcelain commands into the main commands
and some ancillary user utilities.
Main porcelain commands
Unresolved directive in git.txt -
include::cmds-mainporcelain.txt[]
Ancillary Commands
Manipulators:
Unresolved directive in git.txt -
include::cmds-ancillarymanipulators.txt[]
Interrogators:
Unresolved directive in git.txt -
include::cmds-ancillaryinterrogators.txt[]
...
This is logged during the build:
make[1]: Entering directory '/builddir/build/BUILD/git-2.32.0.rc3/Documentation'
rm -f cmd-list.made && \
/usr/bin/perl ./cmd-list.perl ../command-list.txt cmds-ancillaryinterrogators.txt cmds-ancillarymanipulators.txt cmds-mainporcelain.txt cmds-plumbinginterrogators.txt cmds-plumbingmanipulators.txt cmds-synchingrepositories.txt cmds-synchelpers.txt cmds-guide.txt cmds-purehelpers.txt cmds-foreignscminterface.txt && \
date >cmd-list.made
Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ./cmd-list.perl line 3.
BEGIN failed--compilation aborted at ./cmd-list.perl line 3.
make[1]: Leaving directory '/builddir/build/BUILD/git-2.32.0.rc3/Documentation'
This should probably cause a make error rather than generating
incomplete documentation. I'll try to report this upstream (ideally
with a patch to resolve it). It's also worth remembering to search the
build logs for such failures. "Can't locate .* in @INC" and "BEGIN
failed" are good strings to search.
¹ https://src.fedoraproject.org/rpms/perl/c/3b63b8c
With the impending removal of a large chunk of the Java package set,
jgit will become unavailable as a BuildRequires in Fedora soon. Remove
the build dependency on Fedora >= 35.
As noted in 8faf622 (drop jgit BR on Fedora > 30, 2019-07-29), this
affects 3 tests, 2 for packfile format (t5310-pack-bitmaps) and
1 of ls-remote (t5512-ls-remote).
The NEEDS_CRYPTO_WITH_SSL Makefile knob was added in 7878348 (Update to
git-1.7.0 - Link imap-send with libcrypto (#565147) - Disable building
of unused python remote helper libs, 2010-02-15). It is no longer
needed.
I'm not sure when it stopped being necessary, though I am sure I tried
removing once before in the 11 years since it was added.
Builds on Fedora and EL7/EL8 all properly pick up the -lssl -lcrypto
flags when compiling git-imap-send.
Incidentally, git-imap-send has used libcurl for handling IMAP rather
than low-level OpenSSL-based functions on Fedora since upstream commit
dbba42bb32 (imap-send: use curl by default when possible, 2017-09-14).
This applies to EL8 as well. On EL7, libcurl is too old (>= 7.34.0 is
required).
The git-p4 subpackage has been disabled in Fedora 30 via a4b4f7c (Add
support for disabling python2, 2018-03-28). Git 2.17.0 was the current
release at that time. The git-p4 script subsequently gained python3
support which was released in Git 2.27.0 (2020-05-31).
Adjust the python2/python3 conditionals and re-enable git-p4 when either
of them are available. Put python3 first in the various conditionals,
as that is our primary supported python. We only include python2 to aid
in building for EL7.
While here, remove the "# endif" comments within the config.mak output.
We're unlikely to provide the 'WINDOWS' prerequisite in our builds. Nor
are we likely to care about the tests which are skipped as a result.
(Also, 'missing WINDOWS' is not a phrase I thought I'd ever write.)
Remove all conditionals for EL-6; it is EOL as of November 2020.
Replace a number of `EL > 7` with `EL >= 8` to make the intention
clearer. The next version of RHEL is no longer shrouded in mystery.
Drop conditionals which apply only to long-obsolete Fedora releases.
All %defattr macros were removed in ff200ca (Remove obsolete %defattr,
2018-02-07). Two were subsequently added in f8a83b9 (Move instaweb to a
subpackage, 2018-09-06) and 9d91bab (split libsecret credential helper
into a subpackage (#1804741), 2020-02-19).
Remove both entries and (hopefully) avoid adding new entries in the
future.
As git bisect was migrated from shell to C, the bisect_state conversion
lost the ability to handle annotated tags. This was not intentional.
It is fixed in upstream commit 7730f85594 (bisect: peel annotated tags
to commits, 2021-03-16).
References:
https://lore.kernel.org/git/878s6nz1sg.fsf@igel.home/7730f85594.patch
The UTF8_NFD_TO_NFC prereq was added to t0021-conversion and
t2006-checkout-index-basic in upstream commit 684dd4c2b4 (checkout: fix
bug that makes checkout follow symlinks in leading path, 2020-12-10), to
test the fixes for CVE-2021-21300.
Fedora's supported systems do not appear to "convert decomposed utf-8
(nfd) to precomposed utf-8 (nfc)" which is what the prereq covers.
Ignore the skipped tests which use the UTF8_NFD_TO_NFC prereq when
looking for missing test dependencies and/or incorrectly skipped tests.
This release includes a fix for CVE-2021-21300¹ in addition to the other
changes along the path to the final 2.31.0 release.
Release notes:
https://github.com/git/git/raw/v2.31.0-rc2/Documentation/RelNotes/2.31.0.txt
¹ Per the 2.17.6 release notes on CVE-2021-21300:
On case-insensitive file systems with support for symbolic links, if
Git is configured globally to apply delay-capable clean/smudge
filters (such as Git LFS), Git could be fooled into running remote
code during a clone.
Use %{gpgverify} macro to verify tarball signature. The macro is now
available for all supported Fedora and EPEL releases. (It is presumed
that EL-9 will include %{gpgverify} as it will be branched from F-34.
If that turns out to be false, we will adjust later.)
The Packaging Guidelines require the use of the %{gpgverify} macro:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures
Add a BuildRequires for xz as well, since we use it explicitly in %prep.
Renumber Junio's GPG key from Source9 to Source2 so the %{gpgverify}
calls follow the typical pattern. It (mildly) lessens cognitive load
for anyone reviewing the spec file.
While here, remove a stale comment about leaving a blank line after
%autosetup to work around a bug on EL6.
We disabled t7812's 'PCRE v2: grep non-ASCII from invalid UTF-8 data'
test in 33ecb78 (skip failing test in t7812-grep-icase-non-ascii on
s390x, 2019-10-24).
It was subsequently fixed upstream in e714b898c6 (t7812: expect failure
for grep -i with invalid UTF-8 data, 2019-11-29) and more recently
improved with a4fea08b6e (grep/pcre2 tests: don't rely on invalid UTF-8
data test, 2021-01-24).
Don't skip the test any longer.
The key used to sign git releases expired in July 2020. While this
doesn't strictly affect us because use gpgv to verify the releases
against a known key file, it is worth updating to make it clear that
we're using the correct signing key.
Refer to 7c95c76 (Update Junio's GPG key, 2017-09-16) for a previous
update of the key, including the process used.
Here is a diff of the key file before and after the update:
$ diff -u <(gpg gpgkey-junio.asc.old 2>/dev/null) <(gpg gpgkey-junio.asc 2>/dev/null)
--- /dev/fd/63 2021-01-25 11:57:17.367151191 -0500
+++ /dev/fd/62 2021-01-25 11:57:17.368151229 -0500
@@ -3,6 +3,6 @@
uid Junio C Hamano <gitster@pobox.com>
uid Junio C Hamano <junio@pobox.com>
uid Junio C Hamano <jch@google.com>
-sub rsa4096/B0B5E88696AFE6CB 2011-10-03 [S] [expired: 2020-07-26]
+sub rsa4096/B0B5E88696AFE6CB 2011-10-03 [S] [expires: 2028-01-11]
sub rsa4096/86B76D5D833262C4 2011-10-01 [E]
-sub rsa4096/7594EEC7B3F7CAC9 2014-09-20 [S] [expired: 2020-07-26]
+sub rsa4096/7594EEC7B3F7CAC9 2014-09-20 [S] [expires: 2028-01-11]
This thread on the git list is where the question was raised and Junio
confirmed he'd extended the expiration of his signing key:
https://lore.kernel.org/git/B6DFB74D-A722-4DBD-A4B2-562604B21CCB@alchemists.io/T/#u
Making the main package noarch is not trivial since we have
arch-specific subpackages. (I'm not sure it's even possible.)
As noted in 5c331b2 (fix/quiet rpmlint issues from libsecret split,
2020-04-05), when libsecret was split into a subpackage in 9d91bab
(split libsecret credential helper into a subpackage (#1804741),
2020-02-19), it removed the only remaining binary from the main package.
The `git difftool` command was converted to a builtin in git-2.12.0
(from 2017). We don't need to split it out of git-core.
This was missed in cb7fab7 (Move commands which no longer require perl
into git-core, 2017-11-10) and d56cfc6 (Use symlinks instead of
hardlinks for installed binaries, 2018-03-15). Better late than never.
We intend to support building on all supported Fedora and EPEL releases
from the Rawhide branch. On EL-7, the %build_cflags and %build_ldflags
macros are not present without installing epel-rpm-macros. Add a build
requirement to ensure these macros are available when building on EL-7.
A change in git-2.27.0¹ caused fast-import to leak memory and crash in
some cases. Apply the upstream fix², which didn't quite make it into
git-2.29.0.
¹ ddddf8d7e2 (fast-import: permit reading multiple marks files, 2020-02-22)
ddddf8d7e2
² 3f018ec716 (fast-import: fix over-allocation of marks storage, 2020-10-15)
3f018ec716
A change in git-2.24.0¹ resulted in a segfault when combining the
incompatible (and nonsensical) --follow and -L git log options. (These
options were used by the GitLens plugin for VS Code until recently².)
The upstream fix returns an error when these options are combined rather
than a segfault.
¹ a2bb801f6a (line-log: avoid unnecessary full tree diffs, 2019-08-21)
a2bb801f6a
² Fixed in GitLens >= 10.2.3
https://github.com/eamodio/vscode-gitlens/issues/1139
Quoting from Jeff King's commit message:
Commit e8cbe2118a (am: stop exporting GIT_COMMITTER_DATE, 2020-08-17)
rewrote the code for setting the committer date to use fmt_ident(),
rather than setting an environment variable and letting commit_tree()
handle it. But it introduced two bugs:
- we use the author email string instead of the committer email
- when parsing the committer ident, we used the wrong variable to
compute the length of the email, resulting in it always being a
zero-length string
The regression affected both am and rebase. Apply the upstream fixes.
References:
https://lore.kernel.org/git/20201023070747.GA2198273@coredump.intra.peff.net/
The update to 2.29.1 is pointless on its own¹, but a subsequent commit
will add some additional post-release fixes for 2.29. Once we're
pushing an update, we might as well pick up the latest point release to
avoid anyone wondering why we've skipped an update.
Release notes:
https://github.com/git/git/raw/v2.29.1/Documentation/RelNotes/2.29.1.txt
¹ The only change in 2.29.1 is a Makefile fix for users of the
non-default SKIP_DASHED_BUILT_INS installation option.
The hg-to-git.py script in contrib grew python3 support in upstream
commit d17ae00c97 (hg-to-git: make it compatible with both python3 and
python2, 2019-09-18), which was released in git-2.24.0. Move it from
the python2-only conditionals.
(This leaves contrib/fast-import/import-zips.py as the sole python
script which is _not_ python3-compatible. It seems to need only minimal
fixes for python2/python3 compatibility -- per some light testing.)
Since git-2.18.0, the emacs files shipped in git have been stub files
which merely point users to better options. Stop shipping these stubs
with Fedora 34 and later.
Drop the emacs BuildRequires on Fedora >= 34. Elsewhere, replace it
with emacs-common. We need macros.emacs for %{_emacs_sitelispdir}
anywhere we ship the stub .el files¹.
The full emacs BR _was_ necessary prior to git-2.18.0, as /usr/bin/emacs
was used to byte compile the .el files. It traces all the way back to
e46bac5 (Add emacs-git package from Ville (#235431), 2007-06-22).
¹ It might be nice if there were an emacs-rpm-macros for this. But
emacs-common is a lot lighter than emacs, so it's still a nice
improvement. Per `dnf install` in a current f33 container image:
$ dnf install emacs
...
Install 193 Packages
Total download size: 164 M
Installed size: 544 M
$ dnf install emacs-common
...
Install 7 Packages
Total download size: 36 M
Installed size: 89 M
Release notes:
https://github.com/git/git/raw/v2.28.0-rc0/Documentation/RelNotes/2.28.0.txt
Update git.skip-test-patterns to catch the 2GB clone test. The output
of the skipped test was changed (for the better) in upstream commit
d63ae31962 (t5608: avoid say() and use "skip_all" instead for
consistency, 2020-05-22).
From the upstream release notes¹:
With a crafted URL that contains a newline or empty host, or lacks
a scheme, the credential helper machinery can be fooled into
providing credential information that is not appropriate for the
protocol in use and host being contacted.
Unlike the vulnerability CVE-2020-5260 fixed in v2.17.4, the
credentials are not for a host of the attacker's choosing; instead,
they are for some unspecified host (based on how the configured
credential helper handles an absent "host" parameter).
The attack has been made impossible by refusing to work with
under-specified credential patterns.
¹ https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.17.5.txt
From the upstream release notes¹:
With a crafted URL that contains a newline in it, the credential
helper machinery can be fooled to give credential information for
a wrong host. The attack has been made impossible by forbidding
a newline character in any value passed via the credential
protocol.
¹ https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.17.4.txt
When the libsecret credential helper was split out in 9d91bab (split
libsecret credential helper into a subpackage (#1804741), 2020-02-19), a
few rpmlint errors & warnings crept in.
Update the rpmlintrc file to ignore the no-documentation warning for the
libsecret subpackage (replacing the gnome-keyring entry which is no
longer needed). Fix an errant tab added to the spec file.
Moving the libsecret credential helper to a subpackage left no binaries
in the main git package, so rpmlint complains. Fixing this requires a
bit more investigation and care.
Quoting from the upstream patch:
Jan Alexander Steffens reported that when `rebase.abbreviateCommands'
is set, the merge backend fails to fast forward. This is because the
backend generates a todo list with only a `noop', and since this
command has no abbreviated form, it is replaced by a comment mark.
The sequencer then interprets it as if there is nothing to do, and
fails.
References:
68e7090f31https://lore.kernel.org/git/9b4bc756764d87c9f34c11e6ec2fc6482f531805.camel@gmail.com/
The workaround added in 9a7edd4 (work around issue on s390x with gcc10
(#1799408), 2020-02-22) is no loner needed. The issue is fixed in
gcc-10.0.1-0.9.
A recent change to the perl packaging split many modules from the base
perl-interpreter package. Add the missing test dependencies.
A few non-perl packages are also added, as they are no longer pulled
into the buildroot automatically, but were not properly required.
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
The git-gui Makefile does not follow the INSTALL_SYMLINKS setting.
Until it does, manually symlink git-citool to git-gui.
Test that the files are identical before linking, to avoid issues if
they begin to differ in the future.
The documentation tools respect these variables when generating dates in
the man and html docs. This is a small step toward making the package
builds reproducible.
An alternate method to set SOURCE_DATE_EPOCH would be to set the rpm
%source_date_epoch_from_changelog macro. Using the version file from
the tarball is a little nicer as the date is printed in the man pages.
We'd still need to set TZ anyway, as the html documentation sets the
'last updated' footer entry based on the timestamp of the corresponding
txt file.
[Note: It is possible to avoid the 'last updated' footer entirely by
setting the asciidoc footer-style attribute to none. This would need to
be done via sed or a patch, as there's not currently a way to set this
in config.mak -- but perhaps there should be.]
Reference: https://reproducible-builds.org/specs/source-date-epoch/
TEST_SHELL_PATH was added in 62f562d ("Use 'prove' as test harness,
enable shell tracing", 2018-01-18). Shortly afterward, upstream commit
a5bf824f3b ("t: prevent '-x' tracing from interfering with test helpers'
stderr", 2018-02-25)¹ removed the need to use bash to get the benefits of
running the test suite with '-x' tracing.
¹ a5bf824f3b
The Makefiles for contrib/{contacts,subtree} don't include various
asciidoc, docbook, and xmlto options which are added to docs built from
the Documentation dir. Without these options the man page generated
for git-contacts has formatting issues.
Move the contrib/{contacts,subtree} docs to the Documentation dir to be
built along with the other doc files.
It is useful to check the output of the test suite for skipped tests.
This reveals tests which may have missing BuildRequires or other issues.
Doing so can be tedious due to the many legitimate tests we skip. Keep
a list of patterns matching tests we skip intentionally.
To use this list to process a build.log, run something like the
following:
$ egrep '# SKIP|skipped:' build.log | egrep -v -f git.skip-test-patterns
There should be no output. Any output should be checked and the tests
fixed or added to the skip patterns file.
Now that Fedora 30 defaults to gnupg2 as /bin/gpg we don't need to
install gnupg for the test suite. We already require gnupg2 to verify
the source files.
Having the output of the config.mak file in the build output is very
convenient, particularly when building in koji or copr where it is not
possible to directly access the buildroot.
GnuPG2 requires gpg-agent and tries to start it on demand. The agent
uses a socket for communication and the path to this socket must be
shorter than sun_path [108 characters, per unix(7)].
Adjust the location of the temporary directories used by the test suite
by passing the --root option via GIT_TEST_OPTS.
One potential downside to this is that we use mktemp to create the
directory and this will differ between builds. If/when we want to make
our builds entirely reproducible we will need to revisit this. With
luck, gnupg will be better behaved by that time¹.
An alternate solution I tested was to rename the two problematic tests
(t5573 and t7612). This is a brittle solution as new tests may be added
which cause the same path length issue for gpg-agent.
Also drop the redundant killing of gpg-agent. This doesn't break
anything but it can only slow the test suite (however slightly).
¹ A ticket was filed to improve gpg-agent's handling of long paths in
GNUPGHOME (but it's nearly 2 years old): https://dev.gnupg.org/T2964.
In addition to the gnupg2-smime BR, patch an issue which prevents the
gpgsm tests from running. Only include gpgsm on Fedora and RHEL > 8.
On RHEL < 8 the gnupg2-smime package is too old to run the tests.
Drop the subshell used to create the string of dashes (and rename the
variable to "sep" at the same time). Replace $(cat file) with the
equivalent but faster $(< file).
The test suite uses is_IS.UTF-8 and is_IS.ISO8859-1 (via the
GETTEXT_LOCALE and GETTEXT_ISO_LOCALE prereq's. Ensure these locales
are available. Installing glibc-langpack-is is insufficient as it does
not provide is_IS.ISO8859-1, glibc-all-langpacks is also needed.
Now that we're installing additional langpacks, update the macro name
which was added in a6a24cf ("Add glibc-langpack-en BuildRequires for
en_US.UTF-8 locale", 2018-11-05).
The pcre BR was added in 6dc6285 ("Improve test suite coverage",
2017-11-10), which seems to have been an oversight. The test suite
improvements were worked on over a long period of time. It is quite
likely that the pcre BR was needed before 6dc6285 was finalized.
Regardless, we began building against pcre2 in 595b682 ("Use pcre2
library", 2017-07-22).
Note that pcre remains in the minimal buildroot due to dependencies in
glib2 and grep.
When preparing the srpm in mock or other minimal environments, the use
of %{_emacs_version} causes a spurious warning:
Possible unexpanded macro in: Requires: emacs-filesystem >= %{_emacs_version}
Prevent the warning with a check that the macro is defined before use.
(There is another use of %{_emacs_version}, but it only applies to EL-6
where the warning is not present. Just ignore it.)
Make it easier to tell what %if conditions are being ended. This is
particularly useful with nested conditions since we lack any indentation
to visually denote the conditional blocks.
The %{without ...} macro is easier to read than '! %{with ...}', use it
consistently.
(Note that using %without_* and %_without_* macros is still not
advised.)
The verification was simplified slightly in 903d8f3 ("Remove EL-5 and
old Fedora conditionals", 2017-07-22).
Further simplifications:
- do away with unneeded variables
- drop '--batch' and '>/dev/null' from gpg2 --dearmor
- check tarball signature via stdin
The "noisy output from GnuPG 2.0" alluded to on EL <= 7 is no longer
present. This has been tested in mock for el6, el7, and fedora
releases.
The chroot is a bit quicker to create and slightly smaller when building
'--without tests' if the BuildRequires needed to run the tests are
skipped.
Add pod2man dependency when documentation is enabled (the default).
Since git-2.17.0, pod2man is needed to build Git.3pm. The pod2man
command is in perl-podlators on Fedora and EL >= 7, but in perl on EL-6.
Use %{_bindir}/pod2man to ensure the dependency is found regardless of
what package provides it.
The dependency is only missed when building without the test deps, as
the many perl requirements pulled in for the test suite bring in
pod2man.
From the upstream release announcement:
These releases fix a security flaw (CVE-2018-17456), which allowed an
attacker to execute arbitrary code by crafting a malicious .gitmodules
file in a project cloned with --recurse-submodules.
When running "git clone --recurse-submodules", Git parses the supplied
.gitmodules file for a URL field and blindly passes it as an argument
to a "git clone" subprocess. If the URL field is set to a string that
begins with a dash, this "git clone" subprocess interprets the URL as
an option. This can lead to executing an arbitrary script shipped in
the superproject as the user who ran "git clone".
In addition to fixing the security issue for the user running "clone",
the 2.17.2, 2.18.1 and 2.19.1 releases have an "fsck" check which can
be used to detect such malicious repository content when fetching or
accepting a push. See "transfer.fsckObjects" in git-config(1).
Credit for finding and fixing this vulnerability goes to joernchen
and Jeff King, respectively.
References:
https://public-inbox.org/git/xmqqy3bcuy3l.fsf@gitster-ct.c.googlers.com/
While rpmbuild and mock have --nocheck to disable the %check section,
'fedpkg mockbuild' lacks this convenient option.
Add %bcond_without tests to allow 'fedpkg mockbuild --without tests' to
not run the test suite. Disabling the test suite cuts the build time by
approximately 60%, which is very useful while working on changes to the
packaging.
With curl-7.61.1 cookies are sorted by creation-time¹. Sort the output
used in the 'cookies stored in http.cookiefile when http.savecookies
set' test before comparing it to the expected cookies.
¹ e2ef8d6fa ("cookies: support
creation-time attribute for cookies", 2018-08-28)
When building with options "--without docs --without p4 --without cvs"
the build fails with the following errors:
error: Installed (but unpackaged) file(s) found:
/usr/share/doc/git/git-cvsexportcommit.txt
/usr/share/doc/git/git-cvsimport.txt
/usr/share/doc/git/git-cvsserver.txt
/usr/share/doc/git/git-p4.txt
Installed (but unpackaged) file(s) found:
/usr/share/doc/git/git-cvsexportcommit.txt
/usr/share/doc/git/git-cvsimport.txt
/usr/share/doc/git/git-cvsserver.txt
/usr/share/doc/git/git-p4.txt
The .txt files were not caught by the %files entry in the main git
package when cvs/p4 were disabled -- from 9cd8ee7 ("Disable CVS support
on EL > 7", 2018-03-14. Those only applied when documentation was not
disabled.
Remove git-cvs* and git-p4* files from Documentation as well as the
%{buildroot}. Simplify the find path by dropping %{_bindir} and
%{gitexecdir}. Tighten the git-p4 glob to avoid unintended matches.
Drop the conditional inclusion of cvs/p4 docs in the main git package in
favor of removing the files entirely.
Gives possibility to add dependencies for git-instaweb http daemon,
without having to install all dependencies at each git install.
Currently, lighttpd is required by the git-instaweb package.
The git-instaweb script supports other httpd daemons (httpd, mongoose,
plackup [in perl(Plack)], and webrick [in rub-libs]). lighttpd is the
default, works without any configuration, and is only ~1M installed.
Add a conditional to allow merging from master to f29. The obsoletes
should be removed when f29 is EOL. It was added in 2d1c8b1 ("Remove
obsolete gnome-keyring credential helper", 2018-01-09). The comment was
improved in 4a06e99 ("clarify comment for obsolete git-gnome-keyring",
2018-09-04).
Avoid shipping scripts which require python2 when building without
python2. The following scripts/directories are removed:
contrib/fast-import/import-zips.py
contrib/hg-to-git
contrib/svn-fe
A future release of git will likely remove contrib/svn-fe and
git-remote-testsvn¹. The git-remote-testsvn binary is the only noarch
file in the git-svn package. Seeing that it's utility is very
questionable, remove it so git-svn can return to a noarch package.
¹ https://public-inbox.org/git/20180817190310.GA5360@sigill.intra.peff.net/
9125e65 ("Use new INSTALL_SYMLINKS setting", 2018-05-30) broke builds
using --without cvs. /usr/libexec/git-core/git-cvsserver became a
symlink instead of hardlink. Adapt the find command used to exclude
'git-cvs*' files to detect symlinks as well.
We want to build all documentation in the %build phase rather than
falling through to the %install phase and building it as a dependency of
install-doc.
The git-contacts script was added to SubmittingPatches recently. Make
it easier for users who read about it in the documentation to make use
of the command.
The default target in contrib/credential/netrc/Makefile is, and has
always been, test. Running 'make -C contrib/credential/netrc/' in
%build is not needed.
Additionally, the tests recently were changed and require perl-Git to be
installed before running. The tests also exit cleanly regardless of any
failures encountered, which makes them unreliable. A fix for these
issues will be submitted upstream, but rather than apply it here, simply
drop the unneeded 'make' call.
Ideally, the tests will be run in %check once fixed. This does present
a small wrinkle due to the deletion of contrib/credential in %install.
Cross that bridge when we get there. :)
Replace NO_CROSS_DIRECTORY_HARDLINKS and NO_INSTALL_HARDLINKS with
INSTALL_SYMLINKS. The result is slightly improved; all symlinks will
point directly to the target rather than via multiple levels of
symlinks.
The rationale was covered in slightly more detail in d56cfc6 ("Use
symlinks instead of hardlinks for installed binaries", 2018-03-15).
Adjust the dangling-relative-symlink filter in the rpmlint config for
the new target of the git-difftool symlink.
The USE_LIBPCRE setting now defaults to pcre2; use it. It's still
valid to set USE_LIBPCRE2, but using the default should be cleaner in
the long-run.
The (long-unmaintained) emacs support has been dropped upstream in favor
of better alternatives. From the upstream commit¹:
The git-blame.el mode has been superseded by Emacs's own
vc-annotate (invoked by C-x v g). Users of the git.el mode are now
much better off using either Magit or the Git backend for Emacs's own
VC mode.
These modes were added over 10 years ago when Emacs's own Git support
was much less mature, and there weren't other mature modes in the wild
or shipped with Emacs itself.
These days these modes have few if any users, and users of git aren't
well served by us shipping these (some OS's install them alongside git
by default, which is confusing and leads users astray).
¹ 6d5ed4836d ("git{,-blame}.el: remove old bitrotting Emacs code", 2018-04-11)
https://git.kernel.org/pub/scm/git/git.git/commit/?id=6d5ed4836d
Also drop DESTDIR and INSTALL from config.mak; they are both handled via
%make_install.
Remove the rpmlint filter for %buildroot usage which was only needed due
to DESTDIR's use in config.mak.
Specifically, t5512-ls-remote.sh has a test which starts a jgit daemon.
This has failed to exit on a number of occasions, only on s390x. We
could disable just that test with "GIT_SKIP_TESTS=t5512.28", but the
test number can and does change as more ls-remote tests are added.
Dropping the jgit BuildRequires is cleaner and only causes 3 tests to be
skipped, the offending t5512 test and two others in t5310-pack-bitmaps.
Access to s390x might help better debug this, but it does not occur
consistently and may be limited to koji. The issue could be a problem
in jgit as well. While looking at a hung build, Kevin Fenzi found a few
errors in t5512-ls-remote.out:
/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
Unfortunately, it appears we need to carry this patch longer than
expected. Return to using %autosetup so other patches are easier to
manage. Use %apply_patch to manually apply the zlib patch only on
aarch64, as that is the only arch where it is required at this time.
A recent zlib build with optimization for ARM exposed an issue in git's
packfile handling.
Thanks to Pavel Cahyna for the initial report and debugging and Jeremy
Linton for further diagnosis and the subsequent patch.
The patch is currently being discussed upstream¹. Until it is accepted,
apply it only on aarch64 to avoid any unexpected issues with other
arches.
¹ https://public-inbox.org/git/20180525231713.23047-1-lintonrjeremy@gmail.com/T/#u
Fixes two security issues, described in the 2.13.7 release notes¹:
* Submodule "names" come from the untrusted .gitmodules file, but we
blindly append them to $GIT_DIR/modules to create our on-disk repo
paths. This means you can do bad things by putting "../" into the
name. We now enforce some rules for submodule names which will cause
Git to ignore these malicious names (CVE-2018-11235).
Credit for finding this vulnerability and the proof of concept from
which the test script was adapted goes to Etienne Stalmans.
* It was possible to trick the code that sanity-checks paths on NTFS
into reading random piece of memory (CVE-2018-11233).
¹ https://mirrors.edge.kernel.org/pub/software/scm/git/docs/RelNotes/2.13.7.txt
If 'make test' fails before running any tests, the debug output from
print-failed-test-output is confusing:
+ ./print-failed-test-output
cat: t/test-results/*.exit: No such file or directory
./print-failed-test-output: line 6: [: : integer expression expected
--------------------------------------------------------------------------------
t/test-results/*.out
--------------------------------------------------------------------------------
cat: t/test-results/*.out: No such file or directory
Use the bash failglob option to imrpve the output:
+ ./print-failed-test-output
./print-failed-test-output: line 12: no match: t/test-results/*.exit
The unknown, but temporary, breakage in fedora-28-x86_64 buildroots
appears to be resolved.
The test was disabled in a998227 ("Disable t5000-tar-tree.sh on x86 in
f28", 2018-01-18).
The spec file is a bit easier to read with as few conditional blocks as
required. Use %bcond_(with|without) to allow easier toggling of the
link checking.
Using stderr rather than syslog should be a mild improvement with the
systemd journal. The reasons are detailed in the upstream commit
0c591cacba ("daemon: add --log-destination=(stderr|syslog|none)",
2018-02-04)¹:
The combination of --inetd with --log-destination=stderr is useful, for
instance, when running `git daemon` as an instanced systemd service
(with associated socket unit). In this case, log messages sent via
syslog are received by the journal daemon, but run the risk of being
processed at a time when the `git daemon` process has already exited
(especially if the process was very short-lived, e.g. due to client
error), so that the journal daemon can no longer read its cgroup and
attach the message to the correct systemd unit (see systemd/systemd#2913
[1]). Logging to stderr instead can solve this problem, because systemd
can connect stderr directly to the journal daemon, which then already
knows which unit is associated with this stream.
[1]: https://github.com/systemd/systemd/issues/2913
While here, wrap the git-daemon command line to improve readability.
¹ 0c591cacba
Move all Requires to their own lines for better readability.
We can safely drop the 'perl(Git)' requires from the cvs and email
packages because the perl rpm dependency generator already add it.
We can also drop 'perl-Git = %{version}-%{release}' from the email
package because it requires 'git = %{version}-%{release}' which in turn
requires the matching 'perl-Git' package.
Git tries very hard to rely on as few non-core modules as possible. The
few that it does (currently Error and Mail::Address) are bundled. We've
disabled such bundling since it became an option in 2.17.0.
Go a step further and remove the Git::LoadCPAN wrapper. This allows
rpm's automatic dependency generator to find and add the needed
requirements.
With this change we can remove the manual 'Requires:' for perl(Error)
and perl(Mail::Address).
'Requires: perl(Error)' in the main git package has been unneeded for
many years. It was added in edddb83 ("Update to latest upstream
release. Fix some bugs at the same time", 2007-11-27), which was
git-1.5.3.6. It was needed for 'git svn' and 'git remote'. 'git svn'
requires perl(Git), which in turn requires perl(Error).
In git-1.5.5, 'git remote' was converted to a builtin command in C
rather than perl, removing the perl(Error) dependency.
Lastly, move the 'BuildRequires: perl(Error)' from perl-Git to the main
list of BuildRequires.
The bare p4 entry was a bit concerning; it's easy to imagine false
positives from such a short string. Remove git-remote-(bzr|hg) from the
pattern. The scripts and placeholders were removed in git-2.0.0.
While here, group all the git-* patterns and be more explicit with the
svn files.
Python 2 end of life is approaching, prepare for dropping it
along with all python2 scripts and subpackages requiring it.
Helped-by: Sebastian Kisela <skisela@redhat.com>
Helped-by: Pavel Cahyna <pcahyna@redhat.com>
The previous commit disabled the cvs subpackage on EL > 7. Convert to
the %bcond_with(out) macro to allow the subpackage to be toggled easily
via a --with/--without option at build time.
When setting NO_PERL_CPAN_FALLBACKS to avoid bundled perl modules, we
must take care to ensure the dependencies are required. The code which
handles modules via Git::LoadCPAN prevents the normal perl dependency
generator from identifying them. Thankfully, there should not be many
modules loaded this way.
Prior to 2.17.0 and NO_PERL_CPAN_FALLBACKS we were falling back to not
using Mail::Address, which is partly why the lack of the dependency
wasn't spotted with rpmdiff with and without NO_PERL_CPAN_FALLBACKS.
Using a simple glob in contrib/hooks/* to match contributed hook scripts
was valid when it was added in 762cf11 ("Update to git-1.6.3.3 - Move
contributed hooks to %{_datadir}/git-core/contrib/hooks (bug 500137)",
2009-06-28). With the addition of the multimail directory in git-1.8.4
it was no longer doing what was intended.
However, the scripts in contrib/hooks all ship with the execute bit set,
making the "chmod +x" unnecessary. If we did descend into the multimail
directory with a chmod (whether via "chmod -R" or "find | xargs ..."),
we would need to exclude the non-script files within that directory.
Fedora 28 prints a deprecation notice if /usr/bin/python is called in an
rpm build¹, which is done by default when byte-compiling python files
outside of %{_libdir}/pythonX.X.
Avoid the issue by dropping the .py extension from the multimail hook
script. The hook script is not used as a module and therefore has no
need to use the extension or be byte-compiled.
¹ https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build
Ensure find and xargs are required. While findutils is currently in the
default buildroot, we should still be explicit about the requirement.
Also improve the 'find | xargs' calls to handle files which may contain
spaces, quotes, or other characters which might cause spurious failures.
The gitweb httpd config file was added long before git gained support
for smart http, in c97cf8e ("Add git-daemon and gitweb packages",
2007-08-04).
Now, users who want to enable git's smart http support with apache will
often want to use /etc/httpd/conf.d/git.conf as the path.
Make this easier by giving the gitweb httpd config file a more logical
name going forward. Keep the current config file name in previous
releases.
The perl install process was updated to remove the need for
ExtUtils::MakeMaker. The main change for us is setting perllibdir to
keep the files installed in %{perl_vendorlib}.
Manpages for non-public portions of the Git perl modules are no longer
built. Anyone who wishes to make use of these modules can read the
source files or use pod2man.
Set NO_PERL_CPAN_FALLBACKS to ensure we don't package the bundled
fallback modules.
Also drop now-unneeded commands to remove *.bs, .packlist, and
perllocal.pod files. The new install method does not produce these
artifacts.
A recent discussion on the git list¹ suggested that using symlinks
should be clearer and have no drawbacks (except on filesystems where
symlinks are not well supported, e.g. on Windows).
This shrinks the git-core package by nearly 25% and saves almost 6MB in
the debuginfo package.
See also 6ef5f1f ("Disable cross-directory hardlinks", 2017-11-10).
¹ https://public-inbox.org/git/87y3iwp2z0.fsf@evledraar.gmail.com/#t
Ensure all binaries are hardened when building on EL-6 & EL-7. On EL-7
use the %{_hardened_build} macro. On EL-6 update %{optflags} and set
%{__global_ldflags}.
For EL-7 this could also be put in the existing Fedora and EL >= 7
condition, e.g.: %{!?_hardened_build: %global _hardened_build 1}. I
think this is a bit uglier than needed and is better in an %if condition
which only applied to EL-7.
The guidelines require all required packages to be explicitly listed.
This list may not be complete, but it's a start.
Additionally, a proposed change for Fedora 29 removes gcc from the
default BuildRoot.
While at it, sort a few BuildRequires in alphabetical order.
The use of %defattr has been unneeded since rpm-4.4. It was removed
from the guidelines 6 years ago¹. It was kept to allow builds on EL-5,
which has been EOL since March of last year.
¹ https://pagure.io/packaging-committee/issue/77
%defattr is no longer needed in Fedora
Re-enable t9128, t9141, and t9167 which were disabled due to these
random segfaults. The bug has also been reported against the subversion
perl bindings in Debian¹. Hopefully this will reach upstream subversion
if a fix is made to subversion.
¹ https://bugs.debian.org/888791
Move contrib/hooks/multimail from git-core to git and use python3 rather
than python2.
We still use python2 as the default PYTHON_PATH because not all of the
python scripts in git support python3. None of the other scripts are
included in git-core though.
Primarily, python2 is used by git-p4 and contrib/svn-fe/svnrdump_sim.py
(which is used by t9020-remote-svn.sh). Converting git-p4 to python3 is
not a trivial matter of fixing a few print statements. A simple
conversion using python3's 2to3 tool results in a large number of test
failures.
Add a python3-devel BuildRequires for %{__python3} and add python2-devel
to the tests section since t9020-remote-svn.sh uses python2. (We
already BR python2-devel in git-p4, but having it in the tests section
ensures we don't remove it if/when git-p4 supports python3.)
This release fixes an issue which only affects users on case-insensitive
file systems and repositories which contain paths that differ only in
case. Such circumstances result in a segmentation fault in various git
commands.
This test was passing as recently as last week. Something seems to have
changed or broken in the x86 arch of f28 since then. Disable the test
until the issue is determined and resolved.
With 'prove' as the test harness the tests can be run in parallel on
EPEL as well as Fedora targets.
Move GIT_TEST_OPTS to config.mak along with the new test options and
enable shell tracing (-x). The output from failures when tracing is
enabled should allow us to more easily diagnose test failures.
Explicitly use /bin/bash as the shell for the test suite; it allows
using "-x" reliably across the whole test suite. This is made possible
by changes included in 2.16.0 thanks to Jeff King¹, particularly:
3f824e91c8 t/Makefile: introduce TEST_SHELL_PATH
f5ba2de6bc test-lib: make "-x" work with "--verbose-log"
90c8a1db9d test-lib: silence "-x" cleanup under bash
¹ https://github.com/gitster/git/tree/jk/test-suite-tracing
The paths don't change often, but if they do this is one less place
which will need to be updated. It also makes it easier for anyone
rebuilding the packages to change the defaults.
Use a single macro rather than testing for %{fedora} and %{rhel}
versions repeatedly. The "dist" logic is best kept at the start of the
spec file (as much as possible).
Cleanup a few comments related to "dist" checks while we're at it.
The acl and perl(HTTP::Date) requirements are pulled in by other
packages on Fedora so they were not noticed when the test requirements
were updated in 6dc6285 ("Improve test suite coverage", 2017-11-10).
The highlight package is available in EPEL for EL-6 (on all supported
architectures). Extend the conditional to only exclude it on ppc64 for
EL-7.
The gnome-keyring credential helper was removed in Fedora 26, but
remained in builds for older Fedora and EL-7 releases. No official
release has shipped the gnome-keyring subpackage since 2.11.1-3.
Obsolete it to ensure a clean upgrade path for any users who have it
installed. The Obsoletes can be removed after rawhide is branched for
Fedora 29.
Starting with rpm-build-4.13.0 (in F-22), brp-python-bytecompile
excludes files under /usr/share/doc by default. Restrict the %files
%exclude to EL <= 7 to avoid spurious 'File not found' warnings from
rpm-build.
Ensure these tests are not skipped if some dependency or other condition
is not met. We prefer to see the failure(s) in order to fix the
underlying issue(s).
Disable t9115-git-svn-dcommit-funky-renames on ppc-arches because it
frequently fails. The port it uses (9115) is already in use. It is unclear if
this is due to an issue in the test suite or a conflict with some other
process on the build host.
Add mod_dav_svn BuildRequires for t9115-git-svn-dcommit-funky-renames
(GIT_SVN_TEST_HTTPD).
When building release candidates the path to the perl requires filter
script is wrong. Correct it.
It's tempting to use the output of `pwd` to avoid future changes to the
build dir breaking it, but the call occurs prior to unpacking and thus
`pwd` is not suitable.
The tests appear to work reliably now, after a number of test builds. If
not, this is easily reverted. (The newly added test output may also
help determine the root cause.)
All tests which call 'git svn branch' fail intermittently with SIGSEGV
in the subversion bindings. The failures are not remotely consistent.
Until we can enable shell tracing (-x) in the test suite by default to
attempt to further debug the failure, disable these tests.
An option to enable parallel test runs was added in 6dc6285 ("Improve
test suite coverage", 2017-11-10). After further improvements it seems
to be reliable for use in koji builds.
It is still disabled for EPEL builds because make lacks support for the
-O (--output-sync) option. Without this option the output is much less
readable.
In the future we may be able to move to using 'prove' as the default
test harness which might allow us to run in parallel without requiring
the -O option.
Setting SVNSERVE_PORT enables several tests which require a local
svnserve daemon to be run (in t9113 & t9126). The tests share setup of
the local svnserve via `start_svnserve()`. The function uses svnserve's
`--listen-once` option, which causes svnserve to accept one connection
on the port, serve it, and exit. When running the tests in parallel
this fails if one test tries to start svnserve while the other is still
running.
Use the test number as the svnserve port (similar to httpd tests) to
avoid port conflicts. Set GIT_TEST_SVNSERVE to enable these tests.
The change should make it into 2.16 or 2.17. Until then, setting
GIT_TEST_SVNSERVE will disable the svnserve tests. There are only a few
tests affected and this allows more testing with parallel test runs, so
it's a reasonable trade. Once an upstream release with these changes
arrives, we'll begin running these tests without any further changes.
In c3202fd ("Use prebuilt documentation on EL-5, where asciidoc is too
old", 2013-01-04) the make targets to build and install the
documentation were split into separate make calls to handle prebuilt
docs on EL-5 where asciidoc was too old to build the documentation.
Support for EL-5 was removed in 903d8f3 ("Remove EL-5 and old Fedora
conditionals", 2017-07-22), making the separate make calls unneeded.
Using %autosetup frees us from having to manage %patch entries. It does
require that all patches use the same strip level (-p1 in our case).
There is also a mildly annoying bug in EL-6¹ which chokes on the patch
invocation if a blank line doesn't follow %autosetup. A comment should
prevent any problems.
The %autosetup -S option is deliberately avoided, to prevent needless
bootstrapping problems.
¹ https://bugzilla.redhat.com/1310704
When building in koji or copr and a test fails, the verbose output from
the tests can be very useful in determining the cause. Print the output
from failing tests, borrowing heavily from the upstream code¹ used when
running tests in Travis CI².
This could be done inline in %check rather than in a separate script.
The downside is that rpm would include each command invocation of the
loop in the output, which adds a lot of useless text to the already
copious build output.
¹ https://git.kernel.org/pub/scm/git/git.git/plain/ci/print-test-failures.sh
² https://travis-ci.org/git/git
We used to remove the contrib/credential tree from the build dir to
avoid binaries and other cruft from ending up in the doc dir. Doing so
prevented debuginfo from being generated for the credential helpers we
install. The following warnings were printed during the debuginfo
extraction:
cpio: git-2.15.1/contrib/credential/gnome-keyring: Cannot stat: No such file or directory
cpio: git-2.15.1/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c: Cannot stat: No such file or directory
cpio: git-2.15.1/contrib/credential/libsecret: Cannot stat: No such file or directory
cpio: git-2.15.1/contrib/credential/libsecret/git-credential-libsecret.c: Cannot stat: No such file or directory
Keep contrib/credential in the build dir; remove it from the buildroot
instead.
Building release candidates helps test the upstream code before it's
final. Make it easier to create such builds by defining an rcrev macro,
which is commented out by default.
The git-gui build tries to use tclsh to generate an index file. It
falls back to a static list, which is why this wasn't noticed before.
It's not a real problem, but git may soon also try to test that wish is
installed before building and installing git-gui and gitk, so this helps
prepare for that future.
The code to filter the spurious YAML::Any requires was removed in
903d8f3 (Remove EL-5 and old Fedora conditionals, 2017-07-22). The
comment was simply missed.
In older versions of git, the bash-completion script began with a
needless #!bash, which we removed before installation.
This and other unneeded shebangs were removed upstream in 1.9.0,
11d62145b9 (remove #!interpreter line from shell libraries, 2013-11-25).
3041eeb (Run git test suite, 2016-12-16) enabled the test suite, but
many of the tests were skipped due to missing requirements. Improve the
test suite coverage by ensuring as many requirements are present as
possible.
Also add an option to run the test suite with multiple jobs using the
%{?_smp_mflags} macro. This cut the test suite run time roughly in
half in local testing. The -O option to 'make' helps ensure the output
of each job is collected together rather than interspersed with output
from other jobs. Sadly, the tests fail when run in parallel in koji, so
this is disabled by default. It is included to speed up local builds.
To enable in rpmbuild and mock, use either "--with parallel_tests" or
"--define 'parallel_tests 1'" arguments. This is only supported on
Fedora, as it requires make >= 4.0, which neither EL6 nor EL7 satisfy.
Disable 2 failing tests which run with a limited stack on aarch64, arm*,
and ppc* architectures. Some debugging with the affected hardware is
needed.
Similarly, disable "git svn branch tests" globally for both
t9128-git-svn-cmd-branch and t9167-git-svn-cmd-branch-subproject because
they fail randomly. The bug seems likely to be in the subversion perl
bindings, but requires more testing. The failure output from a manual
run (./t9128-git-svn-cmd-branch.sh -v -x -d):
++ git svn branch a
Copying file:///home/tmz/rpmbuild/BUILD/git-2.14.2/t/trash%20directory.t9128-git-svn-cmd-branch/svnrepo/trunk at r2 to file:///home/tmz/rpmbuild/BUILD/git-2.14.2/t/trash%20directory.t9128-git-svn-cmd-branch/svnrepo/branches/a...
Found possible branch point: file:///home/tmz/rpmbuild/BUILD/git-2.14.2/t/trash%20directory.t9128-git-svn-cmd-branch/svnrepo/trunk => file:///home/tmz/rpmbuild/BUILD/git-2.14.2/t/trash%20directory.t9128-git-svn-cmd-branch/svnrepo/branches/a, 2
Found branch parent: (refs/remotes/origin/a) bb43a88ce94511096d7d774f4d5feae281603eb0
Following parent with do_switch
Successfully followed parent
r3 = 2e27ee45dadc098239114bc13a6ae6cf6122d16f (refs/remotes/origin/a)
error: git-svn died of signal 11
+ test_eval_ret_=139
+ want_trace
+ test t = t
+ test t = t
+ set +x
error: last command exited with $?=139
not ok 3 - git svn branch tests
The failure in t9167-git-svn-cmd-branch-subproject is similar.
A change to the git filter-branch command in git-2.15 added a perl
dependency, bd2c79fbfe (filter-branch: stash away ref map in a branch,
2017-09-21)¹.
This dependency is only present when using the option --state-branch,
which means many users of filter-branch will never notice the perl
dependency.
However, without moving the tool from git-core to git, any users running
filter-branch with the --state-branch option might find that the command
fails badly, potentially leaving their repository in a broken state.
This is not an acceptable trade-off, in my opinion.
I'm not sure if it's worthwhile to suggest a patch upstream to better
handle users running with the --state-branch option when perl is not
installed, allowing us to safely ship git filter-branch in git-core for
use on systems without perl.
¹ bd2c79fbfe
Commands which required perl were moved from git-core to git in 6fdc5e5
(new subpackage git-core, which is perl-less and part of original git
rpm, 2015-06-03). This was with git-2.4.2. Since then, a number of
commands have been partially or entirely rewritten upstream and no
longer require perl. Move them back to git-core.
- git-am was converted to a builtin in 2.6.0, 783d7e865e (builtin-am:
remove redirection to git-am.sh, 2015-08-04)
- git-submodule's dependence on perl was removed in 2.10.0, 74703a1e4d
(submodule: rewrite `module_list` shell function in C, 2015-09-02)
- git-relink was removed in 2.12.0, ed21e30fef (relink: retire the
command, 2017-01-25)
Additionally, two sample hooks (pre-rebase and prepare-commit-msg) were
intended to be excluded from git-core due to their perl dependencies,
but were included due to the way the exclusion via %files lists are
created. List them explicitly in the git %files section and exclude
them from git-core.
Using the same variable make it clearer that we're referring to the same
thing as upstream when the Makefile uses gitexecdir.
Remove a stale conditional in git-cvs for handling the case where git's
binaries are stored in %{_bindir}. This support was dropped after
EL-5's support ended. Most similar conditionals were removed in 903d8f3
(Remove EL-5 and old Fedora conditionals, 2017-07-22).
Also remove the conditional setting of 'gitexecdir = %{_bindir}' which
was only used on EL-5 to prevent moving the git binaries during the
update to git-1.6.
After this change, the only rpmlint issues are incorrect-fsf-address
errors:
git-gui.noarch: E: incorrect-fsf-address /usr/libexec/git-core/git-gui
git-gui.noarch: E: incorrect-fsf-address /usr/libexec/git-core/git-citool
git.x86_64: E: incorrect-fsf-address /usr/share/emacs/site-lisp/git/git.el
git-core-doc.x86_64: E: incorrect-fsf-address /usr/share/doc/git/contrib/hg-to-git/hg-to-git.py
git-core-doc.x86_64: E: incorrect-fsf-address /usr/share/doc/git/contrib/emacs/git.el
git-core-doc.x86_64: E: incorrect-fsf-address /usr/share/doc/git/contrib/fast-import/import-directories.perl
git-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/git-2.15.0/trace.c
These issues will be fixed in the next upstream release, with the
following commits:
484257925f63100874c1
In ef7ac1a (git-p4: adjust python2 shebang manually, 2017-08-03) we
dropped PYTHON_PATH due to failures in t9020-remote-svn.
Digging deeper, the issue appears to be caused by the test calling a
script which has a hard-coded #!/usr/bin/python shebang. On newer
fedora releases, /usr/bin/python is python3.
Replacing the shebang in contrib/svn-fe/svnrdump_sim.py (the script the
test calls) with #!%{__python2} allows the test to succeed while setting
PYTHON_PATH in config.mak, as desired.
Use '%{summary}.' as the %description for all subpackages where the
summary and description matched. This is one less place to change
if/when we update a summary/description in the future.
While looking at rpmlint complaints, gitk had a spelling warning because
the summary/description used the British English spelling of
"visualiser." Rather than simply change that to the American English
spelling, change the summary/description to match the gitk
documentation. Do the same for git-gui.
Using %summary fixes the %description for perl-Git-SVN, which previously
used the %description from perl-Git mistakenly.
Also improve/clarify the summary of git-gnome-keyring, git-send-email,
and git-svn.
The git-all subpackage added an obsoletes for older git packages in
0c4a11c (git 1.5.4.3 and include krh's change to rename git-core to git,
2008-02-23).
The git-arch subpackage was obsoleted many years ago in 3f997b4
(Obsolete git-arch as needed, 2011-08-05).
We don't need to carry either of these obsoletes any longer.
We cannot be sure that users installing the git package have not mounted
the git bin and lib dirs on different file systems. The cost is a small
amount of extra disk space (1.25M in the current build).