Drop 0001-Drop-ar-u-argument.patch
(upstream resolved the issue).
Replace forced perl settings with an after-the-fact sed hack
(upstream added more checks to ensure there are no 'tricks' and
I don't want to fight with that).
(From OE-Core rev: b98328a6ff07119e7ba4f1072090d789e69edef8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch is specific to how oe-core runs autotools-generated tests:
by cherry-picking needed bits from builddir and srcdir, then hacking
Makefile with sed until it runs.
As GNU is not interested in installable tests, they wouldn't be
interested in this patch either; and if they become interested,
it's probably going to be done in a whole different way.
(From OE-Core rev: dd13c29bee330d381e1e574351348e526500e396)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add check_PROGRAMS as a dependency of buildtest-TESTS target.
This is required because according to the official automake
documentation [1]:
* TESTS: contains all the tests files
* check_PROGRAMS: contains the programs used by the tests
* check_PROGRAMS is not automatically added to TESTS
So, by using only TESTS as a dependency for buildtest-TESTS we may end
up having runtime errors because of missing program required by the
tests.
[1]: https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html
(From OE-Core rev: ee3e2af4f8ed95b4fd0f7cec52ae4e169401b719)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch;
upstream has fixed the issue.
(From OE-Core rev: 88778afc693d824cc637011e91d4727f8e8c2de4)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While native building, there is a parallel failure
[snip]
|: && mkdir -p doc && ./pre-inst-env /usr/bin/env perl
../automake-1.16.1/doc/help2man --output=doc/aclocal-1.16.1
aclocal-1.16
|help2man: can't get `--help' info from aclocal-1.16
|Try `--no-discard-stderr' if option outputs to stderr
Makefile:3693: recipe for target 'doc/aclocal-1.16.1' failed
[snip]
Correct Makefile rule to fix the issue
(From OE-Core rev: ef4907f311e3ddedfa3eb8a111cc1d146c19851a)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: d29d95e627b2303b835a705cb7d55d1e41ddb0a7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is highlighted when CC is passing flags like -fPIE
which are stripped by libtool when building shared libs
and replaced with -fPIC, this actually results in CC
not matching the CC computed from cmdline created for
compiling and as a result libtool heuristic to compute
tags auotmatically fails.
(From OE-Core rev: 519c34adeb0735f6ff606addd00a7bbe19f4b15c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport 13f00eb4493c "automake: port to Perl 5.22 and later"
from automake upstream to fix build with perl 5.22 .
(From OE-Core rev: 7fa044e799db651d45e4732e2527acfc2bc7cd47)
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Ross Burton <ross.burton@intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If build host perl (and other tools) is old and we use some kind
of toolchain to provide recent perl/python/etc to the OE build
we still locked to use build host perl due to hardcoded shebang
lines in automake scripts.
Behaviour was observed with Enterprise Linux 6 and devtoolset
toolchain from SCL (Software Collections) used to provide recent
version of perl (not provided with default buildtools-tarball).
Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
for class-native and class-nativesdk. Use patch to automake to replace
-w option in shebang line with modern way to enable warnings on perl
(i.e. "use warnings").
Also add nativesdk-autoconf to RDEPENDS to bring runtime dependencies
inline with other targets.
Note that ac_cv_path_PERL must be valid perl interpreter path
since configure will check perl version and Flock implementation.
It is not possible currently to use nativeperl from native
sysroot because automake does not DEPENDS on perl-native (and
doing so fails due to circular dependencies). Only possible
solution is to overwrite shebangs with nativeperl somewhere at
do_install() and update RDEPENDS for class-native. Or add perl
symlinks to nativeperl in sysroot.
For now it seems good to use perl found by /usr/bin/env from
automake-native.
Cc: XE-Linux <xe-linux-external@cisco.com>
(From OE-Core rev: 3b7111b30dbd9a4cdd141b594164da18c15ae970)
Signed-off-by: Serhii Popovych <spopovyc@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python.m4 has python scriptlets that determine where the system's library
directory is. For Python 2.x distutils.sysconfig is used (which works because
we patch it), for Python 3.x plain sysconfig is used (which doesn't work
for example on x32). There is also a hardcoded fallback if the scriptlets fail.
This commit removes the scriptlets altogether and just uses the hardcoded path always,
due to above mentioned issues with x32.
(From OE-Core rev: 0c856653ce65403791e1e5c78229820ff794bae3)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch being removed in this commit removes *.pyc files from being
compiled. This dose not allow a user to select which files are included
in the image. Since optimization is no longer the default for python
we should have the ability to choose what is included in the image.
(From OE-Core rev: bee0f633f0b5ef2439b8e5d54cbfc7bc1f17f47e)
Signed-off-by: Joseph A. Lutz <joseph.lutz@novatechweb.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
automake offers auxiliary tools and is capable to install and prepare the setup for those.
test-driver, a log driver used by parallel testsuite harness in ptests, is one of those tools.
By default it looks that automake prepare environment for testing relative $top_srcdir.
But in Yocto following changed:
- build folder was separated
- $top_srcdir is not anymore defined as relative path, now can be relative or absolute
So now in Yocto the Makefile from src/tests contains absolute path of $top_srcdir for test-driver
which is an unexisting path at runtime.
We need to have relative path for test-driver in Makefile to work on target. $top_builddir
can guarantee this path.
Originally submitted by Adrian Calianu <adrian.calianu@enea.com>
(From OE-Core rev: e9db0ae11d95f3c375b27d5c10606efd8b568fbf)
Signed-off-by: Martin Borg <martin.borg@enea.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default automake puts "sleep 1" into the start of configure scripts
which adds pointless delays to them. Rather than do this, lets just assume
our systems are sane.
Since this means our patches touch m4 files, we need to stop automake running
autoreconf so we tweak the do_configure to avoid this.
(From OE-Core rev: 25eca6793cd4ad7af7e23669ed4f47d075ec696d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade from 1.13.4 to 1.14:
- Remove the PATHFIXPATCH variable and path_prog_fixes.patch since the
problem can be fixed by the do_install_append().
- Remove prefer-cpio-over-pax-for-ustar-archives.patch since it have
been fixed by the upgrade.
(From OE-Core rev: a223d646de4074ec792b879b8d21497c58c7bd4a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-libdir.patch and py-compile-only-optimized-byte-code.patch
updated to apply to new codebase.
(From OE-Core rev: f2a530be5941ddf708720b920d0213d7d3928cd1)
Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch creates a new distro feature "ptest", which creates -ptest
packages containing the test suite of the package for running on the
target. Test files are installed in /usr/lib/<pkg>/ptest.
The patch also includes a change to automake, splitting the "make check"
target into separate steps for building and running the tests.
(From OE-Core rev: 6f92e7f8891008dd3c89325d3fbe2da853372326)
Signed-off-by: Björn Stenberg <bjst@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed already upstream patch:
automake/automake_1.11.2_fix_for_pkglibexec_SCRIPTS.patch
Rebased these patches to the newer code:
automake/prefer-cpio-over-pax-for-ustar-archives.patch
automake/python-libdir.patch
Changed the tarball name from bz2 to gz, as the bz2 tar ball
is not published for the 1.11.3 version.
[RP: Fix python.m4 to preserve the tweaks that allow us to build python modules]
(From OE-Core rev: 94bf72aeae035ffade75bd9343937888bbb09c82)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* On install, automake calls py-compile, which previously
compiled python source code to pyc and pyo, which both
got packaged.
* The python interpreter in OE contains patches to enable
optimization (pyo) by default:
04-default-is-optimized.patch
99-ignore-optimization-flag.patch
* automake created pyc files by calling py_compile.compile()
and adding the c suffix manually, resulting in identical
byte code for both pyc and pyo files.
* py-compile-compile-only-optimized-byte-code.patch
applies to automake 1.11 and automake master, but older
versions require a slightly modified patch. However,
older versions are only pinned by chinook-compat and
nylon, so I left them untouched.
(From OE-Core rev: 40ccf816c597e7eed5243fb4b4e9473d2b58afaa)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The patch was imported from the OpenEmbedded git server
(git://git.openembedded.org/openembedded) as of commit id
aa4585c5065e05c759f16e1e8623fc7f40640f1b.
Modified to apply to automake version 1.11.2 and to
include a patch header. Also renamed the patch.
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
automake-1.11.2 made variable libexec_SCRIPTS valid while
pkglibexec_SCRIPTS invalid. Both should be either allowed
or not allowed. This issue is fixed in the automake
developement branch, and now backported into our automake
1.11.2 recipe.
(From OE-Core rev: 4482675d3e3df3bcbedcf74eeeaec8bbc2af225a)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As we tweak libdir we need python libs that utilize configure to respect
it setting. By updating the python.m4 template, when we regen automake
files they will than respect the setting of libdir which is standard for
any autotools based recipe.
(From OE-Core rev: d300cfe603b00fc963f7ed874563016fcbcc47a8)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a fixup for trying to create ustar archives when the users
UID or GID is larger than the format allows.
(From OE-Core rev: 7a092818f901c5c860e82f573534cd505d9fb959)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python: update upstream-status for patches
binutils: update upstream-status for patches
gcc 4.5.1 4.6.0: update upstream-status for patches
autoconf: update upstream-status for patches
automake: update upstream-status for patches
bison: update upstream-status for patches
distcc: update upstream-status of patches
fstests: update upstream-status for patches
gdb: update upstream-status of patches
intltool: update upstream-status of patches
libtool: update upstream status of patches
linux-libc-headers: update upstream-status for patches
make: update upstream-status for patches
perl: update upstream-status for patches
python-pycurl: update upstream-status for patches
python-pygobject: update upstream status for patches
python-pyrex: update upstream-status for patches
quilt: update upstream-status of patches
tcl: update upstream-status for patches
gnu-config: update upstream-status for patches
gmp: update upstream-status for patches
(From OE-Core rev: a62fa9b213b09bf48c48499d2e3c66a9ee306deb)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having one monolithic packages directory makes it hard to find things
and is generally overwhelming. This commit splits it into several
logical sections roughly based on function, recipes.txt gives more
information about the classifications used.
The opportunity is also used to switch from "packages" to "recipes"
as used in OpenEmbedded as the term "packages" can be confusing to
people and has many different meanings.
Not all recipes have been classified yet, this is just a first pass
at separating things out. Some packages are moved to meta-extras as
they're no longer actively used or maintained.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
