all_proxy is referred to by oe-git-proxy so ensure it is allowed through
into the installer environment in case the extensible SDK install
process needs to query a remote git repository.
(From OE-Core rev: 65efec4cca9926b217b07c429a130088a9b8e2f6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SDK_EXT_TYPE is set to "minimal" then the SDK won't contain many
sstate artifacts, and you're required to set up an sstate mirror in this
case anyway so there's no point publishing the "stub" sstate-cache
directory from within the SDK since it won't be useful for update
purposes and may be confused with the real sstate-cache.
There is however a possibility that people might publish the real
sstate-cache directory under the same output directory provided to
oe-publish-sdk, thus deleting it after extracting (as we were doing with
other files we wanted to clean up at the end) would be problematic,
besides which extracting it and then deleting it is wasteful. Thus,
introduce a "-p" command line option to the SDK installer that we can
use to tell tar not to extract the items we don't want when publishing.
This has the added benefit of mostly keeping references to these in the
place they belong i.e. in populate_sdk_ext.bbclass.
(From OE-Core rev: 774b85d42db1d81936d4e4af4f6fb2c57cb51d2c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check the length for target_sdk_dir to ensure the relocation
behaviour in relocate_sdk.py is correct.
(From OE-Core rev: 2145bd0d188158c2db85b583b4d7f3ad4612593b)
Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extensible SDK needs to do network operations so add proxies to
environment.
(From OE-Core rev: 6d65712660a314916ebee5abc9990404216dbe00)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if xz isn't installed when installing the SDK you get an error
from tar and then the SDK installation continues, cascading into a load
of other failures since files are missing. Add a check to see if xz can
be run and error out if it can't, and also exit if tar fails.
(From OE-Core rev: 176e2bddb45b417b0bfbcdcd95bd5e81505e1e5b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xz gives *much* faster decompression times for the SDK which in itself
is a good reason to use it. It also gives better compression.
One downside is its slower but we care about the end user case
first, build performance secondary.
It also assumes the SDK user has a tar capable of understanding a xz
compressed file but that should be common enough now.
(From OE-Core rev: 193086137b899a0a4e774ffc337ed0da9947fd4f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a second regression in the extensible SDK installation caused by
OE-Core revision 6d2074d477596971dc52027dd87b02af7f39138d - the HOME
environment variable was being cleared, thus using ~/ in the install
path (which is in the default path for the extensible SDK) resulted in a
directory named '~' being created in the current directory.
(From OE-Core rev: 18dcf8acc9a918d00c3525e9af5f64d237f74bdb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE-Core revision 6d2074d477596971dc52027dd87b02af7f39138d we added a
line which re-executes the script with a cleaned environment using
env -i; unfortunately that caused a regression in the extensible SDK on
Ubuntu 14.04 - strangely, there it seems that the value you get for PATH
under env -i contains '.' which triggers a sanity check failure when
preparing the build system. Do a belt-and-braces fix - source
/etc/environment if it exists (so you get a more complete PATH value)
and then filter any nastiness out of PATH for good measure. (Ubuntu
15.04 doesn't seem to suffer from the same problem.)
(From OE-Core rev: 5175d9a6955c1783fc35ab6832b6be4cbb9fc01b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
buildtools-tarball uses a custom env setup script, which isn't named the
same as the default; thus unfortunately OE-Core revision
a36469c97c9cb335de1e95dea5141038f337df95 broke installation of
buildtools-tarball. Revert that and implement a more robust mechanism.
(From OE-Core rev: 00e081b81ba8118959b724269ba9d18d42aba8a4)
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>
Fixes [YOCTO #8698] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=8698
If prior to running the toolchain installation script a toolchain
environment script is sourced then the toolchain installation will
fail. This because the environment is now set for the sourced toolchain
and doesn't suit the installation. In particular PATH points to the
toolchain executables.
The fix makes the script recursively call itself a second time with a
clean environment.
Tested by sourcing a previous successfully installed environment, erasing the
previous installation directory and then reinstalling in the same directory.
(From OE-Core rev: 6d2074d477596971dc52027dd87b02af7f39138d)
Signed-off-by: George Nita <george.nita@enea.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you put an $ character in the path, SDK installation fails during the
preparation stage, so add this to the disallowed characters.
Fixes [YOCTO #8625].
(From OE-Core rev: 654f4785f719552f4e78e14a5a901c07d00ce68d)
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>
Print a line that's the full length of the title that it's underneath.
(From OE-Core rev: 83729437c584fc74577a2b15dbb2ae094788339d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The toolchain install script suggest the user to source env_setup_script
from wrong path now. eg:
" Each time you wish to use the SDK in a new shell session, you need to
source the environment setup script e.g.
$ . /opt/poky/2.0//opt/poky/2.0/environment-setup-armv5e-poky-linux-gnueabi
"
fix it.
(From OE-Core rev: b388468deda8d81df80d1509226196a5390183a8)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently a lib32-core-image-* SDK prints an incorrect environment-setup-*
file name when installing the SDK. Instead of printing the wrong thing, list
the environment setup files present in the SDK.
As it happens this fixes the message printed with buildtools-tarball too
which someone reported to me about the same time as I finished this patch!
(From OE-Core rev: c2fa59f46bbc86985e6c8e4d5d514a07a9ade884)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed when sh is bash:
$ sh ./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-1.8+snapshot.sh
Poky (Yocto Project Reference Distro) SDK installer version 1.8+snapshot
===========================================================
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-1.8+snapshot.sh: 77: read: Illegal option -e
You are about to install the SDK to "/opt/poky/1.8+snapshot". Proceed[Y/n]? ../SDK2
Installation aborted!
There is ony one bashism "read -e" in toolchain-shar-extract.sh, but
'-e' is useless here, so remove it and use /bin/sh.
(From OE-Core rev: e951e20c4ef6a3f003f84e8f1bea568d1b7ef541)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tar has supported a --checkpoint option since version 1.15.91, so it
should be safe to use here to print dots showing that it's still doing
something (technically it's not really progress unless you know how many
dots it's going to print, which even it doesn't know at the start, but
it's better than nothing).
(From OE-Core rev: ee4aadd179be8141536f2fae16482683855a9a37)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When publishing SDK, what we want is basically its metadata and sstate
cache objects. We don't want the SDK to be prepared with running bitbake
as it takes time which reproduces meaningless output for the published SDK.
So this patch adds an option to allow for SDK to be extracted without
preparing the build system.
(From OE-Core rev: 7511862faad1c28804e2410ff42747c8706c5207)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extensible SDK cannot be installed as root so by default offer to install it in
user's home directory under distro/distro_version replacing the normal SDK
version '+' char with a '_' as that's a restricted character for bitbake
(From OE-Core rev: 5486e76cd8abb946b81cff78719d67cfb87cddc6)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are some characters that cannot appear in the installation path, so we
need to check for these
(From OE-Core rev: 5aa9314c342004797e96c87868c5491ad70c13f9)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For a clear look when input.
[YOCTO #8089]
(From OE-Core rev: 973a169a35caa4e603fe5abf9ad661f5206a7f07)
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>
Since the extensible sdk uses bitbake, which can't run as root, the sdk
shouldn't be installed as root.
Previously it would error out late into setup when bitbake errored
saying not to run bitbake as root.
Now the script errors with a message saying the extensible sdk can't be
installed as root.
[Yocto #7545]
(From OE-Core rev: 309e8f4e536148056223f50637ed291c48d148ca)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tell the user how to set up the SDK environment each time they want to
use it.
(From OE-Core rev: 617225af7a7cc9cb038fb1e6466af03867482032)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
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>
If the buildsystem is copied into the sdk and its toolchain is to
be used, then the relocation provided in toolchain-shar-template.sh
isn't needed and will actually fail.
So break the relocation aspect out and essentially make it another
SDK_POST_INSTALL_COMMAND script.
(From OE-Core rev: 9721378688a05cd8d8443c6ee4be823e5c0688f6)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton
Wenlin Kang
Aníbal Limón
Richard Purdie
George Nita
Maxin B. John
Robert Yang
Qi.Chen@windriver.com
Brendan Le Foll
Randy Witt