* use PACKAGECONFIG for various *spell implementations
* keep aspell enabled by default
* prevent hunspell/myspell being autodetected as reported in "bitbake world status" e-mails:
WARN: enchant: enchant rdepends on hunspell, but it isn't a build dependency?
(From OE-Core rev: d7df8092c2be4c984d9292749f6cfa7ce41cbb53)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The alleviates the need to use and maintain hand-written
assembly, just relying on the compiler to do the right
thing.
(From OE-Core rev: 0e683664dfbe2b71288445a86e31fbea062ed564)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Search rootfs in the following order:
- IMAGE_NAME*.FSTYPE
- IMAGE_LINK_NAME*.FSTYPE
* Search kernel in the following order:
- QB_DEFAULT_KERNEL
- KERNEL_IMAGETYPE
- KERNEL_IMAGETYPE*
* Search dtb in the following order:
- QB_DTB
- QB_DTB*
- *.dtb
* Fix DTB, it should only work with "-kernel" option.
[YOCTO #10265]
(From OE-Core rev: 32ff0974ed06f797c6b7d9092a8dc9ae50e9a572)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Package the carl9170 binary firmware separately because it is needed
by various usb dongles and installing whole linux-firmware is overkill.
carl9170 is an atheros-based firmware, the succesor of ar9170 which is
deprecated and its driver (ar9170) was removed from the kernel tree.
carl9170 comes both as a binary blob and also with free sources; the
sources are deleted in linux-firmware.bb to avoid depeding on bash/etc.
Also we should keep ar9170 as is because OOT drivers might still use it.
The license for carl9170 is GPLv2 (sources are beside the bin in the
linux-firmware git repo).
(From OE-Core rev: 907e6596275850cc31b143a4c3094029b0cd078e)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It creats /etc/runqemu-nosudo when creats taps, so should remove it when
remove taps.
(From OE-Core rev: 3d4bf5b0ea581e3e9b388328b086d03f9174fd61)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libidn recipe is now buildable in distros which blacklist
GPL-3.0 without needing to be explicitly whitelisted (since it
provides at least one non GPLv3 package).
(From OE-Core rev: 63d6d014a0a3da8bf5689b27d1155492e2fdb0f2)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pointer arithmatic results in implementation defined signed integer
type, so that 's - src' in strlcpy and others may trigger signed overflow.
In case of compilation by gcc or clang with -ftrapv option, the overflow
would lead to program abort.
Upstream-status: Submitted [https://bugzilla.mindrot.org/show_bug.cgi?id=2608]
(From OE-Core rev: 2ce02941300aa3e826df0c59fd8d4ce19950028e)
Signed-off-by: Yuanjie Huang <yuanjie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As parted is always used by wic it makes sense to make do_image_wic
dependent on parted-native:do_populate_sysroot. This should help
to avoid adding it to all wic image recipes.
(From OE-Core rev: c687c9fcc010947f52e1cd153ea74ae5f6343ca4)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
See commit message of patch added
(From OE-Core rev: bdfce776843bf4287251923c79bc15365c20b4a1)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on a discussion with IRC user: Ulfalizer
It was suggested that removing the diagnostic list, and replacing it with a
simple hint to what might be causing the problem was a better solution.
(From OE-Core rev: ca78313665b23bd7fee85f034acfe1eb1009bd65)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the debug before the error (as it can take many pages.) This makes it
much easier for the user to see the actual error message as it is still on
the screen.
(From OE-Core rev: d643fb2a9cb5bd0d8b0105e9d44b989a49ffa963)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the very first build, the DEPLOY_DIR_IMAGE
directory might not have been created yet, causing
the creation of the qemuboot.conf config file to
fail.
This is because write_qemuboot_conf() runs at
rootfs creation time, i.e. before deploy.
So let's create the directory if necessary before
trying to write the config file.
(From OE-Core rev: ee4697350a553a36ca17b9376911e56eee43a465)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To make sure changes to any source files are detected when externalsrc
is used, it sets BB_DONT_CACHE to force the recipe to be reparsed
every time. Previously, this was done conditionally based on whether
EXTERNALSRC was set. This worked fine for building the base recipe.
But if one tried to build, e.g., a native version of it (provided via
BBCLASSEXTEND), the recipe would not be reparsed as expected.
To solve the above problem, BB_DONT_CACHE is now set for the base
recipe if EXTERNALSRC is set for it or any of it derivatives.
(From OE-Core rev: 449a0b21255d895e8620383ce76a9d7ea41b5cc6)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default values for KERNEL_IMAGE_BASE_NAME and MODULE_IMAGE_BASE_NAME
are already assigned using ?= and anyone wanting to over-ride one is
likely to want to over-ride them all. Make the three consistent with
each other.
(From OE-Core rev: e30c6c93bb70d17244c90c2be12229148f8f6314)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dropbear will use system versions of libtommath and libtomcrypt if
available. To make builds deterministic, add a PACKAGECONFIG option
to choose system libs or force use of the bundled versions.
Note that currently there are no libtommath or libtomcrypt recipes
in oe-core, so default to using the bundled versions.
(From OE-Core rev: b7c2edd2d6ded287d8b34dd047ae84d3fd69d4c6)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To prevent build failures when using system libtom libraries and
linking with --as-needed, LIBTOM_LIBS should be in the order
-ltomcrypt -ltommath, not the other way around, ie libs should be
prepended to LIBTOM_LIBS as they are found, not appended.
Note that LIBTOM_LIBS is not used when linking with the bundled
libtom libs.
(From OE-Core rev: 62e96283fe77469e24e8df86c6c037c92009b00a)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no STAGING_DIR_NATIVE or bitbake in a extracted sdk,
so check OECORE_NATIVE_SYSROOT and use it.
(From OE-Core rev: 93649edc034f2540ff55dc9b41638797209cfb9c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A qemuboot conf file is a convenience but it should still be
possible to invoke runqemu without them, especially for examples
such as using the SDK with an extracted rootfs via NFS.
As read_qemuboot() is always called we need to be sure that function
can return cleanly, without throwing Exceptions, even if a qemuboot
conf file isn't found.
(From OE-Core rev: 3541c21f1976b517b79a19882240a8f36b970292)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel or rootfs names written to the qemuboot.conf can't
be found, try and find the symlinked variant of the filename.
This will help usability of runqemu, for example where a user
downloads an image and associated files as the symlinked names
yet the qemuboot.conf variables point to the full, non-linked,
file names.
(From OE-Core rev: ca5a686c6e165a51f95cb6a834cd53f6f66d42d4)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow runqemu to fall back to trying the link name when
a file matching the full name can't be found.
(From OE-Core rev: 3ccbaaad75f0a53d8bcf6a5c748ec80c96a383bd)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make it clearer that we are looking for a file which ends with
qemuboot.conf
(From OE-Core rev: 2579e05269a14b53a54232a8bf4414ac2dfe6472)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_IMAGETYPE gives the filename of a symlink to the kernel,
which may not be available i.e. if the user downloads some build
artefacts to run on a local machine. It's also possible that the
link will point to a newer kernel than was intended for use with
the rootfs in the qemuboot.conf.
It's much more reliable to read the name of the file
KERNEL_IMAGETYPE is linking to and assign the full filename to
QB_DEFAULT_KERNEL.
[YOCTO #10285]
(From OE-Core rev: d57bdacab13605ada4cd9e9159c18fdcd6eeacbc)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a required binary cannot be found print some guidance pointing
to using a sourced OE build environment or a qemuboot.conf file,
based on a similar message from the previous shell-based runqemu.
(From OE-Core rev: 87cfb5165490cd4e7a8c2570ef5a62898db8395e)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that recipeutils.validate_pn() properly validates characters used in
the name, we can drop this bit checking for '/' since that's not
permitted by validate_pn(). (The FIXME comment here - that I myself
apparently wrote - is questionable since that function was clearly never
intended to allow '/', perhaps I was misled because it was broken and
did so).
(From OE-Core rev: e010d9be3709cf3c607ffc03c3188abe4e1e9eb4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* validate_pn() is supposed to protect against invalid characters, fix
the function so that it actually does (unanchored regex strikes
again...)
* However, now that the function is enforcing the restrictions, we do
still want to allow + in recipe names (e.g. "gtk+")
(From OE-Core rev: c5d5a1baf98a11676537fb5e9f8ec4409e30c1fd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In keeping with making recipetool create / devtool add as easy to use as
possible, users shouldn't have to know how to reformat git short form ssh
URLs for consumption by BitBake's fetcher (for example
user@git.example.com:repo.git should be expressed as
git://user@git.example.com/repo.git;protocol=ssh ) - instead we should
just take care of that automatically. Add some logic in the appropriate
places to do that.
(From OE-Core rev: 78c672a72f49c4b6cfd8c247efcc676b0ba1681a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Filter out a plain "Licensed under the XXXX license" statement, as seen
in the capnproto project (and no doubt others).
(From OE-Core rev: ba4aa319fd49ee02ce2e30c2db0f3988c0e8833c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
AX_PKG_SWIG is not the only commonly-used macro for detecting swig -
there's also AC_PROG_SWIG. As per AX_PKG_SWIG, add swig-native to
DEPENDS if AC_PROG_SWIG is found in configure.ac.
(From OE-Core rev: 847a1aa7153fc8a7b820353283a6f1e51d64f8de)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If python is required then we need to inherit pythonnative (or
python3native) otherwise do_configure will probably fail since it won't
be able to find python.
(From OE-Core rev: 63234cc45aee91b031657971f36997e1443f80ee)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When creating a recipe for an existing local git clone, we attempt to
use the fetcher to determine if it supports the SRCREV variable.
Unfortunately running this code does a network check to get the latest
revision as a direct result of us using '${AUTOREV}' as a default value.
If you don't have a network connection this will of course fail. Rather
than have this block creating the recipe, catch the exception and just
guess from the URL.
Ultimately this should probably be fixed in the fetcher but for now this
will at least resolve the issue on this end.
(From OE-Core rev: f7e43f931d7d6019a3b2509b2b2635978fbbae36)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I ran into an example where recipetool was getting the name/version
completely wrong:
https://bitbucket.org/sortsmill/libunicodenames/downloads/libunicodenames-1.1.0_beta1.tar.xz
>From this it would create a libunicodenames-1.1.0-beta1_1.1.0-beta1.bb
file (likely because it couldn't split the file name and therefore took
all of it, then got the version from one of the files inside the
tarball). When this happens it's just irritating because you then have
to delete the recipe / run devtool reset and then run recipetool create
/ devtool add again and specify the version manually.
This patch is the result of systematically running the
determine_from_filename() function over the files on the Yocto Project
source mirror and my local downloads directory and fixing as many of the
generic issues as reasonably practical - it now gets the name and
version correct much more often. There are still cases where it won't,
but they are now in the minority.
(From OE-Core rev: 7b018b1d493a8d10fd02b8cc220990b191c87fe5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Try to ensure that for Apache, GPL and LGPL where the values extracted
from the "Classifiers" field may not be version-specific, if there is a
versioned license in the free-form license field then use that instead.
Also insert the free-form license field as a comment in the recipe for
the user's reference.
(From OE-Core rev: 237f66042eedd906f654827b53bf9269738267ab)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make use of the extravalues dict to send back other variable values from
the python handling plugin, and enable passing back PV and PN. This not
only places variable values in the final recipe a bit more consistently
with other types of source, it also allows the name and version to be
picked up fron a local source tree and not just when the recipe is
fetched from a remote URL that happens to have those in it.
(From OE-Core rev: 3e7029f28c6ea9bb1d283bcdc3fdfee11455af8e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The open(self.lock, 'w') may fail when the lock is created by other
users, return false for this case to let it try other devices.
Fixed:
runqemu - INFO - Running /sbin/ip link...
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock...
Traceback (most recent call last):
File "/buildarea/lyang1/poky/scripts/runqemu", line 972, in <module>
ret = main()
File "/buildarea/lyang1/poky/scripts/runqemu", line 963, in main
config.setup_network()
File "/buildarea/lyang1/poky/scripts/runqemu", line 810, in setup_network
self.setup_tap()
File "/buildarea/lyang1/poky/scripts/runqemu", line 761, in setup_tap
if self.acquire_lock():
File "/buildarea/lyang1/poky/scripts/runqemu", line 182, in acquire_lock
lock_descriptor = open(self.lock, 'w')
PermissionError: [Errno 13] Permission denied: '/tmp/qemu-tap-locks/tap0.lock'
(From OE-Core rev: f364f773a0381a75b5992c8c8a1d63a81dbd4422)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not ship /usr/bin/glilypond and related files such
as man file /usr/share/man/man1/glilypond.1 and other
three files related to glilypond under
/usr/lib/groff/glilypond in embedded system, it is because:
- Remove the confusion about glilypond fails to run
because it lacks dependency on File::HomeDir perl
module
- We don't often have need for sheet music conversion
in groff in embedded or IoT devices (glilypond
transforms sheet music written in the lilypond language
into the groff language using the .PSPIC request, such
that groff can transform it into a format that can be
displayed directly).
(From OE-Core rev: 9a0bf9567f80f06ea067189bf5c27bb5155a85b0)
Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change causes the licenses of the linux-firmware-*-license to be the license
that it contains instead of all the licenses of the linux-firmware package.
[YOCTO #10251]
(From OE-Core rev: 3b1423df3369e7239d1969b42e090278df8bbff2)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to the recipe now using variable IMGDEPLOYDIR instead of DEPLOY_DIR_IMAGE,
the final Build Appliance image ended up being created in a wrong location.
This patch assures the final ZIP image is created in identical location as before:
tmp/deploy/images/<machine>/Yocto_Build_Apliance.zip
[YOCTO#10274]
(From OE-Core rev: 5ac0604fdc7d5b783011c43d476210b427b5dae0)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Task name was incorrectly added to the targets that already
contained :task suffix and fired with BuildInit event. This
caused Toaster to create incorrect Target objects and show
them in UI.
[YOCTO #10221]
(Bitbake rev: b7faf1af3bd3110fba347fbe6e432fc4ee66590a)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Shell functions in bitbake are executed with /bin/sh so should be POSIX
compliant and not use Bash extensions, or at least only use extensions that are
implemented in both dash and ash (busybox).
This tool will extract all of the shell scripts from all recipes and run them
through checkbashisms (it assumes that checkbashisms is on $PATH).
There is a whitelist to filter out false-positives such as the use of $HOSTNAME
(a bashism) in functions where we have defined it, or using the 'type' builtin
which is supported by ash/dash.
[ YOCTO #8851 ]
(From OE-Core rev: d77fe838ab7631a19e90ff4226f0712e54aa4e22)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Split out the functionality doing configuration re-parse check into a
separate event handler that is hooked into ConfigParsed event. This will
make config re-parsing actually work. Re-parsing in bitbake is triggered
by setting BB_INVALIDCONF whose value is checked after configuration has
been parsed (after ConfigParsed event). However, previously
BB_INVALIDCONF was set in SanityCheck event handler which caused
re-parsing never to happen.
[YOCTO #10188]
(From OE-Core rev: 8fda70bb74f7c63d393d5424436d034d2cc6c05e)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The LICENSE file describes how the various pieces are licensed, so add it to the
checksum so we notice when it changes.
(From OE-Core rev: 3309007b423654c1b021d85205f81e68cbd84475)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, if the gshadow file did not exist in the sysroot when
perform_groupmems() was run, it would be temporarily created and
removed again afterwards. This was supposedly due to groupmems failing
if it does not exist.
However, based on empirical testing and examination of the source code
for groupmems, it should not fail if the gshadow file does not exist
when groupmems is started. But it WILL fail if the file is removed
sometime after its existence has been check at the beginning of the
execution, but before it needs to be modified. And this is exactly
what the previous code in perform_groupmems() could cause if multiple
tasks simultaneously modified users or groups. It could cause any of
the useradd, groupadd and groupmems commands to fail as long as at
least one other recipe invoked perform_groupmems().
(From OE-Core rev: 4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Disable building of mkfs.bfs, which is used to create
BFS file-systems used by SCO UnixWare. This is highly
unlikely to be utilized and there are otherwise no
references to 'bfs' throughout the rest of the tree.
(From OE-Core rev: 3226d89ff743c223181fda90f605c7579337941a)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Disable building of {mkfs,fsck}.minix, which are used
to support minix file-systems. Minix predates Linux and
support for its file-systems is unlikely to be needed.
No recipes otherwise reference minix, except in patches
to autotools configuration scripts, so there should be no
impact to other recipes.
(From OE-Core rev: fc66762d7c112fb798c2444dd902ce03baf975c4)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This causes the default timeout to be set to infinity, it will still report out
every 5000 milliseconds
(From OE-Core rev: fd9e1ba8f70402bd3c4b873d349057f96f5bcb19)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default cmake will auto-detect if a library is present on the host and if it
isn't present will use an internal fork. For some libraries using the internal
fork is preferable as it can be built with less dependencies, but for others
we're either already building it or the impact of building it is comparable to
internal build.
Continue to use the internal fork of libarchive as our libarchive-native has a
large number of build dependencies. Using the internal libarchive means that
system bzip2 and zlib must be used.
Explicitly use the internal fork of jsoncpp as we don't have this in oe-core.
Explicitly depend on curl-native, expat-native, and xz-native to ensure these
dependencies are not floating. curl-native is a non-trivial dependency but is
comparable to building the internal fork, so there's no reason to build it
twice.
Change bzip2-native to bzip2-replacement-native as bzip2-native is
ASSUME_PROVIDED.
[ YOCTO #9639 ]
(From OE-Core rev: f9366799aaf4ad2b98345743c7129fa94d092880)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa
André Draszik
Robert Yang
Ioan-Adrian Ratiu
Jackie Huang
Yuanjie Huang
Ed Bartosh
Mark Hatle
Peter Kjellerstedt
Andre McCurdy
Joshua Lock
Paul Eggleton
Mingli Yu
Saul Wold
Juro Bystricky
Markus Lehtonen
Ross Burton
Patrick Williams