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.
¹ https://github.com/git/git/commit/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
