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)
https://github.com/git/git/commit/ddddf8d7e2
² 3f018ec716 (fast-import: fix over-allocation of marks storage, 2020-10-15)
https://github.com/git/git/commit/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)
https://github.com/git/git/commit/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:
https://github.com/git/git/commit/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.
