As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts
using glibc earlier than 2.27 won't be able to find any locales, so bitbake
won't start and Python can't use UTF-8.
So by default install all locales into the SDK. Special-case Extensible SDKs by
installing no locales as they ship glibc in a buildtools, and that will have the
locales.
Locale installation requires cross-localedef, so add that to DEPENDS.
Also remove the explicit en_US addition in buildtools-tarball as it is now
redundant.
(From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1)
(From OE-Core rev: af9eb2ef36cb5bfd87ea61ff3390949810097c9b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE and LIC_FILES_CHKSUM apply to the sources specified by SRC_URI,
not to the recipe itself. As such a license declaration for a source-less
recipe makes little sense. The LICENSE declaration is mandatory, but
LIC_FILES_CHKSUM can be removed in such cases.
Remove the LIC_FILES_CHKSUM declarations from all recipes that do not
need it.
CC: Paul Eggleton <paul.eggleton@linux.intel.com>
(From OE-Core rev: b18fa5f2f2f46afc6fdc58f4d29679dea9c36c43)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We still have problems where deploying SDKMACHINE=i686 can cause removal
of SDKMACHINE=x86_64 artefacts.
The reason is that x86_64 is a BUILD_ARCH as well as an SDK_ARCH and
the manifest namespaces overlap. To fix this, set PACKAGE_ARCH and
the stamp-extra-into to include SDK_OS. SDK_OS may not be entirely correct
but it is what sstate.bbclass uses for nativesdk and fixing that is
a separate issue.
This is confirmed to resolve artefact problems on the AB which have been
delaying a new uninative release.
(From OE-Core rev: 1dbc6ec4ca061570d2482c9abebcf720298db9b7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
buildtools-tarball shouldn't be regenerated when MACHINE changes,
nor should variants for other SDKMACHINE be removed from the deploy
directory when SDKMACHINE changes.
Remove target architecture dependencies so that deploy artefacts
can overlap.
(From OE-Core rev: b7d1a310f6b880e92b124a78af3c948abaab4236)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise the stamps for x86-64 and i686 uninative tarballs match
and we can't deploy both to the DEPLOYDIR.
(From OE-Core rev: fee426ae0c2b27925b05b856ada676958ee10869)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Firstly, these recipes are not target (MACHINE) specific so they should
by SDK_ARCH based, not PACKAGE_ARCH.
Also fix use of SDK_DEPLOY -> SDKDEPOLYDIR after other recent changes.
Together these fixes avoid various build failures and ensure the tarballs
only get built once rather than multiple times.
(From OE-Core rev: 894c9b6ded702897ae4084ef75959cdc8cc6f7a3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is required by python3's bitbake.
(From OE-Core rev: 342701f25db0943fb1038ac3741a1feaab8458fd)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 97b5b150b3d3e82a5a42c1ea4351eed60aba7906)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was added for testing, and not needed any more after:
4a8a74c62836a20610daf029d4cec0b3087758b2
Author: Robert Yang <liezhi.yang@windriver.com>
Date: Mon Mar 21 02:25:50 2016 -0700
gpg_sign.py: get rid of pexpect
So remove it.
(From OE-Core rev: 8ae1a5328e7ca820611fc1911195ebce6dc92237)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The recipe doesn't need any default deps.
(From OE-Core rev: 25f904b4f0f5a049ffabc7b3613d5902099d4ae0)
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>
Due to some logic within opkg, a package with the name matching a
dependency will always win over a package with that name in RPROVIDES -
even if there is an RCONFLICTS (which is silently ignored), higher feed
priority and version. The end result is that buildtools gets perl
installed instead of the nativesdk-buildtools-perl-dummy package and
that perl (with missing dependencies) gets used in preference to the
host one, which is precisely what we were trying to avoid.
This is almost certainly a bug in opkg, especially as the other
package's dependencies aren't properly installed under these
circumstances either. However, specifying RREPLACES works around this,
and with no apparent side-effects is probably the safest solution for
now.
At the same time I noticed that in prepending to SDK_PACKAGE_ARCHS we
were actually ending up with a low priority for the dummy package feed
rather than a high one, so change to append it instead. This has no
effect on the packages that get installed at the moment, but should be
done in case the package manager behaviour changes to factor in the feed
priority in future.
Fixes [YOCTO #9469].
(From OE-Core rev: b18134ddaf949b4f001a1613ab876aed6324040a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
run.create_sdk_files.45747: 131: [: =: unexpected operator
The SDKMACHINE is not set by default.
(From OE-Core rev: 528388c3cef027d436fc794c73d57a247521c238)
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>
buildtools-tarball doesn't need config site, set
TOOLCHAIN_NEED_CONFIGSITE_CACHE to null so that no target recipes will
be built when bitbake buildtools-tarball.
(From OE-Core rev: 1c187fd7f722b01e0284e4d368f6f9366e9c2f0b)
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>
Initially I was reluctant to do this however makeinfo is a dependency
of the buildsystem and only adds around 400kb to the buildtools-tarball
so it likely makes sense to add it. This allows people to use
the project on older environments.
Need to enable nativesdk-texinfo but this seems straightforward.
[YOCTO #8990]
(From OE-Core rev: 5e290201e13a685818ff03ad9cd6679977e560d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"pseudo" does not build 32 bit library by default on 64 bit host, but the
32 bit library is needed when using 32 bit development tools (buildtools-tarball)
running on a 64 bit host. Building of the library can be forced if the
environment variable NO32LIBS is set to "0".
Hence for 32 bit buildtools we export the environment variable NO32LIBS="0"
and NO32LIBS is also added into BB_ENV_EXTRAWHITE (if not already there).
[YOCTO#8581]
(From OE-Core rev: 1c20e66428df10000741c25dddb7a2b1fd55ba42)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The core class used to have this inherit but its being phased out, add
the inherit directly where we need it instead.
(From OE-Core rev: bdd546a8a492d386afdcc24e9540b0b88e9cd230)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Show a friendly title when running the SDK installer, so the user knows
what SDK they are installing. The title is controlled by the
SDK_INSTALLER_TITLE variable and includes the distro name and SDK
version by default.
(From OE-Core rev: 0af913887f4c0a79c6b950bd5d57c06333520a14)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the split out of git-perltools, some git tools (such as "git am",
"git send-email" and "git-submodule") have no longer been part of the
buildtools. We need these, so add them back in.
However, adding git-perltools to buildtools triggers perl itself being
brought into buildtools as well, and we don't want that; but we also
don't want to have to hack the git recipe or indeed anything else that
starts depending on perl. Thus, add a dummy package which gets installed
in its place, in a separate package architecture that is only enabled
for buildtools to ensure it doesn't start appearing in place of
nativesdk-perl anywhere else.
Fixes [YOCTO #7033].
(From OE-Core rev: 5b051d65e797624cca3a81fc6f5c924925f3493e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of cherry-picking pieces of Python to put into the buildtools tarball,
ship all of it. We can't predict what bits of Python will be needed in the
future.
(From OE-Core rev: 745dfbc869fd593d1b92e2bc9c01d589ab21ade3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
export GIT_SSL_CAINFO so git can find the certs
(From OE-Core rev: 260ea7b85ecacf2fcd4d09fa2f602d3e4368ef69)
Signed-off-by: Fahad Usman <fahad.usman@gmail.com>
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk-ca-certificates is needed in order to support oe/yocto builds with
buildtools-tarball on old hosts, as we provide libcurl, and that needs to be
able to find the certs, and there's no standard path or bundle path, so we
can't rely on the host.
(From OE-Core rev: 057954bcc4baf9194968169591537cd7584f8bcb)
Signed-off-by: Fahad Usman <fahad.usman@gmail.com>
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using the tar executable in the buildtools, tar will execute
gzip. If this happens before zlib-native is built, then the gzip
on the host will be used and can fail if the libz in the buildtools
is not compatible. Adding pigz to the build tools avoids this host
contamination.
(From OE-Core rev: af6424e8c2bf3a938fddabc669c0956d68964ed0)
Signed-off-by: Konrad Scherer <Konrad.Scherer@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed by some recently added automated QA tests so we should add it
to the buildtools tarball.
(From OE-Core rev: 7d93288117e7054472d8a01dde0b38bc0ff98c27)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building a qemu image inside the environment created by the
buildtools-tarball, the qemu image cannot be started, as the runqemu
script uses the tunctl binary which cannot be found inside the sysroot
directory of the buildtools-tarball.
The buildtools-tarball is inherently a tool set instead of a fully
functional SDK, so leaving the OECORE_NATIVE_SYSROOT variable in the
environment will mess things up.
However, we do need a line of 'OECORE_NATIVE_SYSROOT=xxx' in the environment
setup script so that the SDK can be extracted and relocated correctly.
Thus, instead of exporting OECORE_NATIVE_SYSROOT, we use a comment here.
[YOCTO #4939]
(From OE-Core rev: d4a4c764a844a7e61f866af9361f139684037336)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new testimage class needs the mmap python-module in the buildtools-tarball
on machines that use the tarball to provide the correct version of python.
(From OE-Core rev: 0b3574481cb8204513001570f5fa3cc8f50ba510)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-git is needed by buildhistory-diff and the OE layer index update
script, and on machines where buildtools-tarball is necessary given we
are providing python we must provide this module as well.
Fixes [YOCTO #4747].
(From OE-Core rev: d9bf76b4fafc0ddcb19bf393e5e22678e49367b3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recently it was discovered that many Fedora hosts have a broken version of
make 3.82. Add make to the buildtools-tarball, as well ad modify make to
support building a special nativesdk version.
(From OE-Core rev: ea972fc4ce2268f01be6beeafd27dd949d800f9d)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous method of shrinking down the scale of the environment-setup
file would not work properly when the target is configured with multilibs.
In addition, the configured machine name and similar settings could leak
into the SDK naming. This was resolved by clearing the SDK generated
files and generating our own custom files.
Note, the name of the environment-setup now is suffixed with the SDK_SYS.
(From OE-Core rev: 778cd8d2110ef2db5ff4ae4f0b55c52a8f1ea334)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've been seeing issues where some TERM values don't work well with the
tarball. These show up as escape codes coming from simple python calls such
as printing the python version. Adding the terminfo goes part way to addressing
the problem, the remainder is ensuring the relocation code correctly searches
the right path for it (which will be in a follow on patch).
(From OE-Core rev: 697e64c98affc4e0d8aa4828e74331c918b23a0e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Needed for the unittest part of bitbake-selftest can work correctly.
(From OE-Core rev: fe744381e8844ad17dcc6e036650a442dbc9575d)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need unittest so bitbake-selftest can work, tarfile from the compression module
for opkg-utils and json for webkit builds.
(From OE-Core rev: bbcb7329ca4340dbd3d529567dc6b605347e3368)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the DESCRIPTION for the recipe and add a SUMMMARY.
(From OE-Core rev: ecdccd0c19c1d27aee43a3cca8e4467f270d7f9c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The external-python-tarball was intended to provide python for those users who
didn't have python 2.6. It has been unloved for a while so this refreshes
it a bit. Specifically:
* Include git and tar since these can have version issues on some systems
* Rename to buildtools-tarball to better reflect its purpose
* Remove the site-config file from the tarball, its pointless
* Prune down the environment file to just cover PATH and OECORE_NATIVE
(which is needed to correctly install the tarball)
* Add missing grp module (used by do_package) from the unixadmin package
(From OE-Core rev: c8de009e96930709efe8f6aa4e65dd04a48081f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton
Olaf Mandel
Richard Purdie
Joshua Lock
Robert Yang
Paul Eggleton
Juro Bystricky
Alejandro Hernandez
Fahad Usman
Tudor Florea
Konrad Scherer
Chen Qi
Saul Wold
Mark Hatle