Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Trying to use git w/o tab completion is especially annoying if
you are used to using it elsewhere -- "whatchanged" is simply
too annoying to type out in full more than once.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

These could be created from scratch from git itself, but it
requires asciidoc, xsltproc, python bits and too much other
baggage.  Since the git folks issue a tarball with the manpages
for each release, it is simpler to just go get that.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Fixed when MACHINE = qemux86-64 and libdir = /usr/lib64:
mv: cannot stat `/path/to/image/usr/lib64/perl-native/perl': No such file or directory

The perl-native files are always installed to /usr/lib on both 32/64
bits targets.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

Git perl tools such as add--interactive load the Git module at runtime.
A previous patch to eliminate a QA error by deleting it instead of
packaging it was incorrect.

    beaglebone[62]$ git add -i
    Can't locate Git.pm in @INC (you may need to install the Git module) (@INC contains: /usr/lib/perl/5.20.0 /prj/pab/Utils/lib/perl5/linux-arm/5.020000 /prj/pab/Utils/lib/perl5/ /prj/pab/Utils/lib/perl5/site_perl/linux-arm /prj/pab/Utils/lib/perl5/site_perl /etc/perl /usr/lib/perl/site_perl/5.20.0/ /usr/lib/perl/site_perl/5.20.0 /usr/lib/perl/vendor_perl/5.20.0/ /usr/lib/perl/vendor_perl/5.20.0 /usr/lib/perl/5.20.0/ /usr/local/lib/site_perl .) at /usr/lib/git/git-core/git-add--interactive line 7.
    BEGIN failed--compilation aborted at /usr/lib/git/git-core/git-add--interactive line 7.

[YOCTO#3780]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Also fetch source code from kernel.org. As per the Git release announcement, see
[1], Git source tarball are now located back on kernel.org, at [2].

[1] https://lkml.org/lkml/2014/6/25/760
[2] https://www.kernel.org/pub/software/scm/git/

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Hardcoded paths to perl don't make sense, use from the environment instead.

[Patch taken from meta-mentor by RP]

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

It seems that there are multiple problems with the upstream RUNTIME_PREFIX
mechanism at this time. It doesn't canonicalize argv[0] to an absolute path,
breaking calls via the PATH, for example. In addition, it doesn't seem to
locate template_dir via the runtime prefix even when specified as relative.

Revert this for now to the previous wrapper-based mechanism, but tweaked
slightly to avoid hardcoding the sysroot path into the wrapper (based on the
bits in the rpm recipe).

[YOCTO #6211]

[Pulled from meta-mentor by RP]

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

variable is called 'libexecdir', not 'libxecdir'.

Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

We need to pass CFLAGS and LDFLAGS to the makefile correctly so we
need to list them as part of EXTRA_OEMAKE.

We also have a problem where git hardlinks binaries in bindir with
those in its libexecdir. If we change the RPATH in one of them, it
breaks the other. We therefore set the no cross dir hardlinking flag
git already has for this kind of issue. This ensures the RPATHS for
the git-core binaries works correctly. Its pure luck this has
sometimes worked so far.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>