| Age | Commit message (Collapse) | Author | Files |
|---|
|
When installing the esdk with INHERIT += "rm_work", the script complains
about do_rm_work as unexpected output from the bitbake run. This patch
ignores any output lines with do_rm_work and further refactors the
output comparison into its own function creates a new unit test to
verify the fix. The unit test can be run direct from the command line or
via oe-selftest.
[YOCTO #9019]
Signed-off-by: Bill Randle <william.c.randle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
It should be 0700 rather than 0755.
Reported-by: Charles Chan <charles.wh.chan@gmail.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This reverts commit eeae2ac4887298bcbab0e105798818414686dc97.
|
|
It should be 0700 rather than 0755.
Reported-by: Charles Chan <charles.wh.chan@gmail.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There appears to have been a lot of copy and pasting of the code
which prints tracebacks upon failure and limits the stack trace to
5 entries. This obscures the real error and is very confusing to the user
it look me an age to work out why some tracebacks weren't useful.
This patch removes the limit, making tracebacks much more useful for
debugging.
[YOCTO #9230]
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.
Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Instead of skipping the build system preparation step within the
extensible SDK install process when SDK_EXT_TYPE is "minimal", run
bitbake -p so that the cache is populated ready for the first time
devtool is run.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The ParaType Free Font License is used by various fonts, out of which a
recipe will be added to meta-openembedded for ttf-pt-sans.
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
directory as SDK script.
If SDK will be extracted in the same folder as sdk shar script.
The shar_relocate will substitute SDK.sh script SDKPATH with extract destination path.
After that operation no one will be able use this sdk script as paths in it will be different.
To fix this we need to filter out sdk script and relocate_sdk scripts from SDKPATH substitution
Signed-off-by: Krzysztof Zawadzki <krzysztof.zawadzki@nokia.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When installing the eSDK, if setscene task fail for some reason, the tests
would ignore this. This is bad since we assume they're working.
This adds some sanity test code which detects if setscene tasks are
needing to run and errors if there are any.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Extensible SDK needs to do network operations so add proxies to
environment.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
select one that exists.
Although the relocate_sdk.sh supports python3, fc23 does not symlink
/usr/bin/python3 to /usr/bin/python. Using exec instead of a call to
the correct interpreter causes a failure on fc23 when python2 is not
present. This uses 'which' to locate python, python2, then python3 and
uses the first one that's found.
Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
After the change to use --setscene-only when running bitbake to prepare
the SDK at the end of installation, add a check that the SDK got
prepared correctly by doing a dry-run and looking at the output for any
real tasks that we don't expect. In order to make this easier, the
preparation shell script was rewritten in python.
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
workarounds
Rather than horrible workarounds, use the new --setscene-only option
of bitbake to pre-populate the SDK structures.
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.
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.)
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: George Nita <george.nita@enea.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
In the case where many environment-setup-* files exist, the incorrect
filename might be lastly set in env_setup_script, which leads to
incorrect behaviour for the initialization of native_sysroot.
The scenario I had was that our custom meta-toolchain-*.bb, which
inherits populate_sdk, defined another environment-setup-* file to dump
variable information for qt-creator. The file is named like so in order
for the sdk shell script to pick it up and fix the SDK paths in the
file. Since it (coincidentally) alphabetically comes after ...-core2, it
was last set in env_setup_script and the grep OECORE_NATIVE_SYSROOT
would simply be blank. The apparent symptom was "...relocate_sdk.py:
Argument list too long" since the find command would not be searching in
the right path.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Print a line that's the full length of the title that it's underneath.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In order to prepare the build system within the extensible SDK, we
actually go ahead and build the targets specified by SDK_TARGETS (by
default the image the SDK was built for). Assuming that's an image, we
don't actually need to build the image itself - we just need to have
everything done up to the point before building the image, so that we
have everything needed in the sysroot.
In order to do this, create temporary bbappends for each of the targets
in the workspace layer that stub out do_rootfs and related tasks if they
exist. This is a little bit of a hack but is the least intrusive fix at
this point. To make things a bit tidier, I have split out the
preparation commands into a separate script so we can run that in the
appropriate environment rather than all the commands separately.
Fixes [YOCTO #7590].
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.
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
It seems that the GFDL 1.1 license file that was originally committed
was actually the 1.2 version. Replace it with the 1.1 version fetched
from http://www.gnu.org/licenses/old-licenses/fdl-1.1.txt.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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!
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Make the extrating faster by:
* Merge the two heavy "for .. find" loops into one
* Move the commands out of for loop rather than inside, this can reduce the
forking amount.
As a result, when install:
* buildtools-nativesdk-standalone: 14s -> 7s (50% saved)
* core-image-minimal-core2-64-toolchain: 56s -> 47s (17% saved)
[YOCTO #8404]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
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.
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).
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.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.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
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
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]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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]
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Add license file XFree86-1.0 which is needed by packages such as hwdata.
It is from:
http://www.x.org/archive/X11R7.5/doc/LICENSE.html#AEN28
And add 'XFree86-1.0' to SRC_DISTRIBUTE_LICENSES.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This reverts commit 9021ee03e0f9bd36b0ce63fa29dd010e07241fdb
|
|
Tell the user how to set up the SDK environment each time they want to
use it.
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #7539]
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some packages like toybox use it
Change-Id: I2ae4fd024e310bce644581e4c63ed2980ee1998f
Signed-off-by: Khem Raj <raj.khem@gmail.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.
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add a check to the SDK so that it only runs on systems with kernel versions
it supports.
[YOCTO #6856]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
environment setup file
When specify a target sdk dir that contains default install dir as
subdir,
target_sdk_dir=/opt/poky/$version/
custom_target_sdk_dir=/opt/poky/$version/some
The target_sdk_dir variable in environment-setup file is replaced twice
causes to point to wrong PATH.
In order to fix filter environment-setup file in second replacement.
[YOCTO #7032]
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This is used by debianutils.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
It only fixed the text files in native_sysroot, but there might be some
files in the top installed dir (whose var name is target_sdk_dir in the
code) which are also needed to be fixed.
It used "find $native_sysroot", now also "find $target_sdk_dir -maxdepth 1",
and split the long line into small ones.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The install script is sometimes called under POSIXLY_CORRECT. This
requires two fixes be made:
1. `find -perm /0000` is a gnuism; replace with an equivalent boolean
expression using `-perm -0000`.
2. POSIX grep requires that all options be passed on the command line
before all files; otherwise, the options must be parsed as filenames.
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
