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.
¹ https://github.com/git/git/commit/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.
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).
From the release announcement¹
A malicious third-party can give a crafted "ssh://..." URL to an
unsuspecting victim, and an attempt to visit the URL can result in
any program that exists on the victim's machine being executed.
Such a URL could be placed in the .gitmodules file of a malicious
project, and an unsuspecting victim could be tricked into running
"git clone --recurse-submodules" to trigger the vulnerability.
Credits to find and fix the issue go to Brian Neel at GitLab, Joern
Schneeweisz of Recurity Labs and Jeff King at GitHub.
¹ https://public-inbox.org/git/xmqqh8xf482j.fsf@gitster.mtv.corp.google.com/
Setting 'PYTHON_PATH = %{__python2}' in config.mak should work, but
doing so causes the remote svn tests in t9020 (which use a python script
to similate svnrdump) to fail. Just fix the git-p4 shebang until the
svn test failures can be resolved.
The pcre1 library is only maintained for serious bugs and
vulnerabilities at this point. Further improvements are happening in
pcre2. In a future release git will make this the default library for
pcre support.
EL-5 has been EOL for several months now. We can drop all the
conditionals needed to build there, as well as some conditionals for
long-expired Fedora releases.
Without EL-5 we also no longer use the prebuilt documentation. Remove
these sources and simplify the gpg check for the remaining source.
Links in docfiles are now automatically checked for correct paths
by linkchecker. The test is available only for Fedora 25+ system,
because the utility is not available for RHEL.
We have not supported git-archimport in many years and have removed the
files from the documentation. Removing it from the command list ensures
that git will not generate a link to the command in the documentation.
This avoids leaving a broken link in the html docs.
Move documentation files from all subpackages into the %{_pkgdocdir}
directory, so links inside doc and man files are correct
Resolves: #1357438
- excluded *py[co] files from doc/* subdirectories, as these files
are not expected to be executed (thanks tmz)
The grep tests succeed and fail intermittently on s390x. Until that
arch is more established and works (or fails) consistently, skip these
tests rather than let s390x hold back ever other arch.
Upstream changed the default SHA1 implementation in 2.13.0 to one which
detects collisions¹. It may be slightly slower than BLK_SHA1 in some
cases, but the added safety it provides in the face of the SHAttered²
attack should be worth the cost.
We overrode the default SHA1 implementation in b796934 (Update to
git-1.6.5.rc2 - Enable Linus' block-sha1 implementation.) The main
reason was to avoid linking against openssl's libcrypto for most
binaries, which saved a measurable amount of space. Using the new
DC_SHA1 default provides the same benefit.
¹ https://github.com/git/git/commit/e6b07da278
² https://shattered.io/
Since the libsecret replaces the libgnome-keyring,
the libgnome-keyring is not necessary to keep it in the git package.
In addition, gnome-keyring is deprecated and according to people
from GNOME, they do not expect that anyone would want to use the old
library when libsecret is installed. So drop credentials for
libgnome-keyring.
However, I keep that credential in spec for older systems where it
has been originally, but it is split into the separate rpm, so at
least it will not be required by the git package. It can be removed
later.
Usually in Fedora this change will not change paths in current
packages, because both macros has same value now (/var). However,
the first one is "more recommended", because some build environments
redefine path in this macro for own purposes, in contrast with
%{_var} which is usually kept as it is.
- missing libcurl requirement for git-core
- git-email & git-cvs should require 'perl(Git)' according
to guidelines
- perl-generators are required during build only for Fedora 21+
From the upstream commit message which added the helper¹:
This is based on the existing gnome-keyring helper, but instead of
libgnome-keyring (which was specific to GNOME and is deprecated), it
uses libsecret which can support other implementations of XDG Secret
Service API.
¹ 87d1353 (contrib: add credential helper for libsecret, 2016-10-09)
We can avoid pulling in libgnome-keyring for git-core installs.
Presumably, those who want a minimal git install won't miss a
credentials helper which is only useful with a graphical desktop.
It is also worth noting that libgnome-keyring is deprecated in favor of
libsecret. A credential helper based on libsecret is included in git
2.11.0 but is not shipped in our packages (yet).
Nothing in git-core requires rsync. Upstream, only git-archimport.perl
still requires rsync, which we have not provided since 3f0dc97 (Drop
git-arch on fedora >= 16, 2011-07-26).
Building on EL was unintentionally broken by 58fa169 (Set LDFLAGS for
hardened builds (#1289728), 2016-04-11).
Thanks to Dimitry Andric for reporting this issue.
This form handles changing package names better. If a module is moved
into or out of core perl, for example, the requirement can still be
found if it uses perl(MOD::NAME).
This was brought up in 1337137.
I updated my vim spec file plugin which improves %changelog generation
and didn't notice that my 'spec_chglog_format' config (which included a
trailing '-') caused a duplicate '-'.
Many years ago, the GPG signature file was included in the source list¹.
A compromise at kernel.org caused the tarballs to move to googlecode.com
for a number of releases and the signatures were not provided in an
easily downloaded format². When the source location was moved back to
kernel.org, the signature file had already been removed from the spec
file and was not re-added³.
There is an effort underway to make GPG signature verification a
requirement when upstream provides signatures⁴. Regardless of whether
this becomes a requirement in the packaging guidelines, verification of
upstream signatures makes good sense. It also makes the process easier
for git package maintainers, who are (or should be ;) doing this
manually for each upstream git release.
While adding the signatures to the source list, all non-upstream source
files were moved to Source10 and above. This should make it easier to
add new upstream source files in the future, avoiding the need for
tedious (and error-prone) renumbering of existing sources.
Remove the unused entry for Patch14 also.
¹ ea3f253 Include gpg signature for tarball in SRPM (2011-08-26)
² c57f383 Update to 1.7.9.1 (2012-02-15)
³ b741f45 Change source URLs, as googlecode doesn't have up-to-date
tarballs (2014-06-10)
⁴ https://fedorahosted.org/fpc/ticket/610https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatureshttps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2TBK4LLNRH73QJQSXWFPCQYHGTSJ3C7P/
Using https URL's for source files provides a little more security for
those downloading the code. Packagers, of course, should be verifying
the GPG signature files before pushing new releases to Fedora's source
cache¹.
While we're changing the source URL's, we might as well use the smaller
tar.xz files which upstream provides. (This requires minor adjustments
to the unpacking of prebuilt html and man tarballs; tar on el5 does not
know how to automatically filter via xz.)
¹ Replace .xz with .sign for the signatures, which are made against the
uncompressed tarballs.
Workaround missing git subtree documentation in prebuilt docs, dropping
a redundant listing of Documentation/docbook-xsl.css,
Only add git-cvsserver binary once if the core dir matches the
bin dir as it does on el5.
Signed-off-by: Konrad Scherer <Konrad.Scherer@windriver.com>
Using pkg-config for the bash-completion path isn't an option on older
EL systems. To allow rebuilding of current git on those systems, the
bash-completion pkg-config bits are conditionalized similar to other
areas where Fedora and older EL differ.
An updated file package fixes the issues that caused the git-svn script
to not be properly parsed for perl requirements. This was fixed as part
of #1051598.
Rather than maintaining the same list if 3 different places, use a
single exclude_re variable for the files we want to exclude from the
main package file list.
Upstream took great care to make use of YAML::Any optional¹. It's fine
to pull it in on Fedora and EL >= 6, but it's not available for EL-5 so
we'll just filter it from the requirements.
¹ git-svn: use YAML format for mergeinfo cache when possible
https://github.com/git/git/commit/68f532f4b
When building packages, we install to DESTDIR but we don't want this to
end up hard-coded in the scripts.
This needs discussed upstream to find a proper solution.
For now, this just gets the file from contrib installed. If there are
enough tcsh users that want it to be more automated, that can come
later. For now, the directions in the file must be followed to enable
tcsh completion.
Since git-1.7.12, asciidoc >= 8.4.1 is a requirement to build the
documentation. Update the build requires to reflect this. Note that
this means that EL-5 can no longer build documentation as asciidoc-8.1.0
is the latest in EPEL. (It might be worth adding support for using the
prebuilt documentation files to enable EL-5 builds to continue working.)
- include git-credential-gnome-keyring helper in git pkg
- 0001-cvsimport-strip-all-inappropriate-tag-strings.patch was merged
Signed-off-by: Adam Tkac <atkac@redhat.com>
With git-1.7.12, __git_ps1 has moved to a separate script. This is to
accommodate newer bash-completion which allows for dynamic loading of
completion files.
Having git-prompt.sh in profile.d ensures that the functions needed for
git in the prompt are present regardless of whether bash-completion is
installed or loaded.
Upstream split some of the bits from git-svn.perl into separate files
for ease of maintenance. We don't want to package these in the main
perl-Git package, as it causes core git to grow an unwanted dependency
on subversion.
While we don't push these packages to EPEL regularly, making sure they
continue to build for when we do update is convenient. It also allows
people running EL systems to easily stay up to date.
Use git-core.googlecode.com for source URL, as that's where Junio is
posting official tarballs now. The gpg signatures are now available on
that site in the comments for each tarball. For example, the signature
for 1.7.9.1 and download link can be found at:
http://code.google.com/p/git-core/downloads/detail?name=git-1.7.9.1.tar.gz&can=2&q=
This update fixes an incompatibility caused by the git push --quiet fix¹
included in 1.7.6.1. Unfortunately, the "fix" was reverted. A proper
fix for git push --quiet is being worked on for a future release.
Also worthy of note is that the source tarball for 1.7.6.2 is not
available due to the recent intrusion at kernel.org. Instead, the
tarball was generated using 'make dist' from the git tree. The v1.7.6.2
tag was verified using Junio's GPG key and compared against the 1.7.6.1
tarball to verify the diff.
¹ http://thread.gmane.org/gmane.comp.version-control.git/180652
