The use of $libdir/$BPN as libexecdir is contrary to all other mainstream
distributions (which either use $prefix/libexec or $libdir), and the GNU Coding
Standards[1] which suggests $prefix/libexec and notes that any package-specific
nesting should be done by the package itself. Finally, having libexecdir change
between recipes makes it very difficult for different recipes to invoke binaries
that have been installed into libexecdir. The File System Hierarchy[2] now
recognises the use of $prefix/libexec/, giving distributions the choice of
$prefix/lib or $prefix/libexec without breaking FHS.
Change bitbake.conf to use $prefix/libexec for libexecdir, so that the binaries
are separated from the libraries. This should avoid complications with multilib
configurations.
[1] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
[ YOCTO #6398 ]
(From OE-Core rev: e7270e331560546d3805cd66ed14afcbc96b6d89)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We used to need these hacks to make things work. Rework the variables to
remove the horrible hacks and make things slightly less ugly. This does
mean PE and PRAUTO are given default empty values but this is preferred
to the other ugliness.
(From OE-Core rev: f37af830448794d3941aca9ab4b2bfa9d8358694)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in native.bbclass adds -native suffix to the package
names that don't have it.
Renamed python-native-runtime -> hostpython-runtime-native to avoid
mangling it and to conform with the naming convetion for native
packages.
(From OE-Core rev: 8a474057d86b3ebf6271656d6b9adf384ea9ad6d)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in native.bbclass adds -native suffix to the package
names that don't have it. perl-native-runtime becomes
perl-native-runtime-native because of this.
Renamed perl-native-runtime -> hostperl-runtime-native to avoid
mangling it and to conform with the naming convetion for native
packages.
(From OE-Core rev: f4dade8e765a8c7bfd131728b9e0a34631e24950)
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>
It's possible for a native recipe to have virtual/libiconv-native as a build
dependency, but as we expect that the host provides that add it to
ASSUME_PROVIDED.
(From OE-Core rev: a5e6f5939c0ee4280eabd7cfc01131052040bc81)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is mainly a performance optimisation. Since we added these flags
to functions, the system spends a lot of time trying to expand these
flags. The values don't really influence checksums and don't need to
be included since if the function content changes, that is will be
detected regardless and is the key detail we care about.
Therefore exclude these from the checksums and gain a signficiant
chunk of parsing speed back.
(From OE-Core rev: 2a1edfd9cfa16ec334c0758b47677d4fee5e79a8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the autodebug package generation logic, specifically setting FILES_${PN}-dbg
isn't needed in most cases, we can remove them.
(From OE-Core rev: 3ab59d49dd7c18e194b58d1248b4b87709b5a738)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
archive.apache.org does not contain current releases, only historical ones,
so upstream checks aren't accurate. It's replaced with official mirrors
containing current versions.
(From OE-Core rev: e9c85489ae354f52ff5b78f4d7fb6fafd0050522)
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>
Various key parts of the core classes (for example, do_package and
do_populate_sysroot) currently require file. As it's not possible to build a
file-native without invoking do_populate_sysroot mark file-native as
ASSUME_PROVIDED and expect to use the host's binary.
(From OE-Core rev: d92a29bf279d3e96aa6cebf88a8fd94b52fc59eb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was making deploy tasks MACHINE specific since they place output
into DEPLOY_DIR_IMAGE which contains MACHINE. On the plus side, this
was accidentally ensuring the output was placed for each machine,
on the downside it was triggering a rebuild every time for the different
checksum.
There is a better way to handle this which avoids the rebuild, see
the following tweak to do_deploy to mark it as MACHINE specific
in a different way.
(From OE-Core rev: 59800189690f887e6f3e8c3139fa6a404b76ac71)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes to what mirror we happen to fetch from shouldn't cause rebuilds.
(From OE-Core rev: 168f3d71bcfc9daa2984c21f35e2a2fdf754c57c)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Automatically spawning a devshell, rather than doing so on demand, is
questionable default behavior, and is potentially problematic in headless
builds. Further, there are problems with the patch resolver today. Default to
noop, and the user can always opt-in to use of the patch resolver by setting
PATCHRESOLVE to user.
(From OE-Core rev: 7964936dd1fb202373e58048c19a91d4b27cdfd6)
(From OE-Core rev: 4d8b993851d28909333d04166df592c8adc451aa)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If our libc doesn't support locales, we don't need gettext nls bits enabled.
(From OE-Core rev: f1bc8afa6ee584a81fb65bcf77e5ae1a8889f47c)
(From OE-Core rev: 8144069cd295fae67a7007a984e285c1a2a320e5)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The user's shell shouldn't be allowed to affect the build (and it can break
the flock command and possibly more, if the user's shell isn't POSIX
compliant).
(From OE-Core rev: fc5e1cfcc3ab7acfb6e7e12cb2cf7fa4699ae7b3)
(From OE-Core rev: 43a2baf26dad4b7b2f0e4c6af3ea4a611cee7ad5)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using OE-Core only we miss this define and its now used in recipes
like os-release, which goes undefined and when booting we see messages
like
Welcome to ${DISTRO_NAME} nodistro.0!
This would change to
Welcome to OpenEmbedded nodistro.0!
Remove all trailing whitespaces while touching this file
(From OE-Core rev: cf2383a63975ac7a51729a313fe0a52b559d2c61)
(From OE-Core rev: 394f0d61d1211a0562a3b4d9d78e8984abd3b28f)
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>
OLDEST_KERNEL is invalid for aarch64, it didn't exist
back in our current version. Use a more recent version
for aarch64 to allow user mode qemu to work correctly.
(From OE-Core rev: 27149fb98fd9d5bba4e07d256a6a0b4921cf00a9)
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As Chris Larson points out in the bug, "BUILD_ARCH changing doesn't change
native/cross sstate checksums, because its calculated in ${@}, so just its
unexpanded form is in the signature. But BUILD_ARCH ends up included in the
sstate filenames, so changes to BUILD_ARCH will result in rebuilds of
native/cross but not rebuilds of the target recipes which depend on
them, which is just what we want."
However it does mean we can't easily test 32 and 64 bit signatures. In order
to make the tests work, we need to add BUILD_ARCH to the HASHBASE whitelist.
BUILD_ARCH is used in the workdir paths and so on so changing it does still
rebuild when we need it to.
With improvements to function dependency tracking, a dependency on SSTATE_PKGARCH
was also introduced causing problems for 32/64 bit build signature equivalence.
Since this is reflected in the sstate filenames, we can safely whitelist this too.
[YOCTO #5970]
(From OE-Core rev: 4f6636be97e654c7f3d58e2649328b1dde8ef696)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than just use d.getVar(X), use the more explict d.getVar(X, False)
since at some point in the future, having the default of expansion would
be nice. This is the first step towards that.
This patch was mostly made using the command:
sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *`
(From OE-Core rev: ab7c1d239b122c8e549e8112c88fd46c9e2b061b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use immediate expansion for BUILD_ARCH and BUILD_OS since there is no
point in repeatedly calling os.uname() throughout parsing. This is
worth around 2% of parsing time, small but measurable.
(From OE-Core rev: 03482382b797f3501c3fb0df0fe12bd4e5e51a39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of hard-coding the set of features that can be considered in
COMBINED_FEATURES, simply generate the intersection of DISTRO_FEATURES and
MACHINE_FEATURES.
(From OE-Core rev: a66f812d4395dc27e22d0c99568aed0a6493df12)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PRINC is no longer needed since we have the PR service instead
which people should be using. Drop the PRINC code.
This has been deprecated with a warning and then an error for quite some
time so we can remove it now.
(From OE-Core rev: a4d530bcf55f03258078c10a123e2717444e1060)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If bluez4 is not explicitly passed as a
distro feature, bluez5 should be used as
the default, so backfill it.
(From OE-Core rev: ae2d2fbafab638fa6c2496a836c8d00529a40d83)
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to build sed for the host, however now:
ERROR: Nothing RPROVIDES 'sed-native' (but virtual:native:/OE/sources/openembedded-core/meta/recipes-extended/groff/groff_1.22.2.bb RDEPENDS on or otherwise requires it)
(From OE-Core rev: 5111407cfe59bd368e2528d953282b74d78057ed)
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The past few weeks ftp://ftp.gnu.org has been intermittently giving errors like this:
WARNING: Failed to fetch URL ftp://ftp.gnu.org/gnu/emacs/emacs-23.4.tar.gz;name=tarball, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 4, output:
Cannot parse PASV response.
accept: Connection timed out
Cannot parse PASV response.
Error in server response, closing control connection.
Which is annoying because binutils lives there. Using http://ftp.gnu.org hasn't given any problems so far.
(From OE-Core rev: 25fe8d95298a457e828190412d7148470edc5592)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add BBLAYERS_LAYERINDEX_URL variable that bitbake-layers can use to find layer index.
Add BBLAYERS_FETCH_DIR variable that bitbake-layers can use to specify fetch directory.
[YOCTO #5348]
(From OE-Core rev: ae585a7d2744222606aeb533815d22ade8e10097)
Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA
postfunc re-executing, so changing a QA test results in a complete rebuild.
This is just too much and the lesser evil of needing to do a full rebuild to
verify changed QA flags is preferable to an enforced full rebuild.
This reverts commit daecfc3438122b5d146a59a5053e57006d55ccc4.
(From OE-Core rev: 4c5895da16de6f00148a0755b421f07223083d09)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changing WARN_QA and ERROR_QA should cause do_package_qa to re-execute, so
removing them from the sstate hashes is harmful.
They were added back when sanity testing was part of packaging and this was the
lesser evil, compared to changing sanity tests causing a re-package of
everything.
(From OE-Core rev: daecfc3438122b5d146a59a5053e57006d55ccc4)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In meta/conf/bitbake.conf, PKGDATA_DIR is default to:
PKGDATA_DIR = "${STAGING_DIR_HOST}/pkgdata"
But in meta/conf/multilib.conf, PKGDATA_DIR is set as:
PKGDATA_DIR = "${STAGING_DIR}/${MACHINE}/pkgdata"
When multilib enabled, linux-libc-headers cache will be machine
specific:
$ bitbake-diffsigs sstate-cache/1a/sstate:linux-libc-headers:ppce6500-poky-linux:3.17.7:r0:ppce6500:3:1a0c3934d91479fd7242a5b1d407d155_package.tgz.siginfo sstate-cache/28/sstate:linux-libc-headers:ppce6500-poky-linux:3.17.7:r0:ppce6500:3:28c918e8f9f4a4cfceb3a38b258f7501_package.tgz.siginfo
basehash changed from 8d3158bbddcee612fa30badd05f47b8e to 68ac258fc6c8e489f360fde3123a5894
Variable MACHINE value changed from 'b4420qds' to 'b4860qds'
(From OE-Core rev: c511f65a3ccfcbaabd2ba1d1c89be81498240a2b)
Signed-off-by: Ting Liu <ting.liu@freescale.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #7230]
In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.
This will cause SDKs to fail to generate properly.
Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXTENSION, which causes the OVERRIDES to pick it up
as well. This effectively defines a new class of overrides for the 'n32'.
The side effect is that we need to duplicate some mips64 overrides, and
redefine others that were previously 'n32' or 'mips64' exclusive to have
the correct semantics.
(From OE-Core rev: 4b3a2b703b20583bd107f00a297d972e9bfb514a)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
commit 3b3f7e785e279 [kernel: Rearrange for 1.8] began the process of
moving the kernel source and build artefacts out of sstate control and
into a shared location.
This changed triggered some workflow issues, as well as bugs related
to the kernel source containing build output, and hence being dirty and
breaking kernel rebuilds.
To solve these issues, and to make it clear that the kernel is not under
sstate control, we move the source and build outputs to:
work-shared/MACHINE/kernel-source
work-shared/MACHINE/kernel-build-artifacts
Where kernel-build-artifacts is the kernel build output and
kernel-source is kept "pristine". The build-artifacts contain everything
that is required to build external modules against the kernel source,
and includes the defconfig, the kernel-abiversion, System.map files and
output from "make scripts".
External module builds should either pass O= on the command line, or
set KBUILD_OUTPUT to point to the build-artifacts. module-base.bbclass
takes care of setting KBUILD_OUTPUT, so most existing external module
recipes are transparently adapted to the new source/build layout.
recipes that depend on the kernel source must have a depedency on the
do_shared_workdir task:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
With this dependency added, the STAGING_KERNEL_DIR will be populated and
available to the rest of the build.
(From OE-Core rev: 6a1ff0e7eacef595738f2fed086986fd622ec32a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As the code that uses BB_SIGNATURE_EXCLUDE_FLAGS uses d.getVarFlags() so doesn't
get to see the internal flags, remove _append and _prepend. Also defaultval is
now _defaultval and thus internal, so remove that too.
(From OE-Core rev: b53e06c8fc4a8183a2f8232c13931a39b1ca0e23)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipe packaging for the target requires permissions that are consistent
with meta/files/fs-perms.txt which specifies certain user and group
names. In the early parts of a target build base-passwd is not yet
available to provide the target /etc files used for user/group lookup.
Allow pseudo to fall-back to the last-resort files it installs if the
target ones aren't there yet.
(From OE-Core rev: 071d364b7a758ba5e546bb18c5816ac4c2e6747c)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of replicating the logic for the host compiler naming from bitbake.conf,
use the BUILD_* variables directly.
Also change BUILD_CPP to use gcc -E (which native.bbclass previously used), as
some recipes (e.g. grub-efi) use ${CPP} with multiple input files, which gcc -E
can handle but cpp can't.
(From OE-Core rev: 9237d18964ff0bf76f5c37fca21ab3974d81d0d2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, when building core-image-minimal, the rootfs size would
default to 64M because we use '?=' in bitbake.conf and also '?=' in
core-image-minimal.bb.
The thing is, we'd like to have a default value for all images set
in bitbake.conf but still allow each image recipe to set its own default
value which could be overridden by users in local.conf.
(From OE-Core rev: 18f499df6bcbf79d7bd0a99c4c8693268683485f)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
glibc 2.20+ wont support any older than that
(From OE-Core rev: 32b3a9ca554d9ff8f3b9c2ff62cc66ee865c61bf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Might as well move this default to the class which uses it allowing
for easier reading/understanding of the class.
(From OE-Core rev: 177aec177306e68bcd822dee6b29a7efbd558a91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently its near impossible for other classes to sanely override
this value with their own default. By setting a weak default we can
allow other classes to change the default and allow end recipes to
again override this.
As far as I can tell, there shouldn't be any regressions from this
change.
(From OE-Core rev: 12b2a73d336d66596939eae5c9947d4054c0316e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A few native scipts requires bash-native, and we don't build
bash-native, so add it to ASSUME_PROVIDED.
(From OE-Core rev: 283a418a838ef285988a5ffc3888501ca7de63f1)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When adding patches or config files from bbappend files, it requires
the use of FILESEXTRAPATHS, which has been an issue and failure point
for people starting to work with bitbake and oe-core.
We add checking to standardize how to use FILESEXTRAPATHS. Only the
format of:
FILESEXTRAPATHS_append := ":${THISDIR}/Your_Files_Path" or
FILESEXTRAPATHS_prepend := "${THISDIR}/Your_Files_Path:"
is acceptable.
[YOCTO #5412]
(From OE-Core rev: 69e083237e632f7d84a7b218dd12d1a5ad95a229)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, BB_NUMBER_THREADS and PARALLEL_MAKE default to unset and
are set in local.conf. Now that we have the automatic probing,
the default values can be set in bitbake.conf and an example of
explicitly defining how many tasks to run can be moved to
local.conf.sample.extended.
[YOCTO #6217]
Signed-off-by: Roxana Ciobanu <roxana.ciobanu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Check the rootfs size against IMAGE_ROOTFS_MAXSIZE (if set)
* Add comments for IMAGE_ROOTFS_SIZE to not confuse with IMAGE_ROOTFS_MAXSIZE
[YOCTO #2610]
(From OE-Core rev: 6acd4fc8d5e642b5c6c75fcc40dd8f37caf7ddcf)
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>
pkglibexecdir is a fairly common location for package-specific binaries (in
automake this is $libexecdir/$PACKAGE), and binaries in there are already
installed to FILES_PN, so add the corresponding .debug directory to
FILES_PN-dbg.
(From OE-Core rev: 4d3ffde4649ed116a1c21afef41f71bfe1d471de)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For most users this commit will have no effect. But if you come across the idea of giving
different names for paths, you'll get some troubles.
When a recipe inherit native, properly define bindir, sbindir, includedir, sysconfdir, datadir
(using xxxdir_native definitions from meta/conf/bitbake.conf).
For example, edit "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/quilt-native/temp/log.do_configure"
and see what are the arguments given by oe_runconf.
Notice that ${docdir}, ${mandir}, ${infodir}, ${localstatedir} have no associated _native definition.
(From OE-Core rev: 15345ddd4be6a0b041b3d6caaad48d46b22142e9)
Signed-off-by: Matthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The QEMU_OPTIONS variables belong in qemu.bbclass so move them there. The
only users of them inherit qemu.bbclass. There is no point in pushing
these into every recipe.
(From OE-Core rev: 5824293de37919e89f60192836997281933e23d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, qemuppc prints warnings about gdk-pixbuf postinstalls
not working due to illegal instructions. This is due to qemu
running with the wrong cpu type. Add an option for ppc7400 so
that qemuppc works correctly.
(From OE-Core rev: 5995fdbe81799f1ecf5de722cb2eb95ccb2aa860)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To unpack that to more than a single line: -native and -cross recipes are made
to use the dummy Texinfo utilities provided by texinfo-dummy-native if they
invoke those utilities at build time. The target-architecture (cross-compiled)
recipes still use the genuine Texinfo utilites. Right now, they still use
the host system's Texinfo utilities, but could be made to use the
texinfo-native recipe we already ship with some config file changes.
(From OE-Core rev: 160087f754eabf5da90fb51997e19d2e585aac4a)
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
