summaryrefslogtreecommitdiff
path: root/meta/files
AgeCommit message (Collapse)AuthorFiles
2016-08-17classes/populate_sdk_ext: drop duplicated error messagePaul Eggleton1
The preparation script itself prints out an error on failure, and we aren't redirecting its output anymore, so we no longer need to print out a message here when it fails. At the same time, make the message printed out by the script a little clearer - we're just writing the log out to the file, we shouldn't give the user an expectation that there will be extra details in there (other than the output produced by oe-init-build-env there won't be). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-08-17classes/populate_sdk_ext: add some pre-install checksPaul Eggleton1
Check a number of things as early as possible in the eSDK installer script so that the user gets an error up front rather than waiting for the build system to be extracted and then have the error produced: * Check for missing utilities specified in SANITY_REQUIRED_UTILITIES (along with gcc and g++), taking into account that some of these are satisfied by buildtools which ships as part of the SDK. We use the newly added capability to list an SDK's contents to allow us to see exactly which binaries are inside the buildtools installer. * Check that Python is available (since the buildtools installer's relocate script is written in Python). * Check that locale value set by the script is actually available * Check that the install path is not on NFS This does duplicate some of the checks in sanity.bbclass but it's difficult to avoid that given that here they have to be written in shell and there they are written in Python, as well as the fact that we only need to run some of the checks here and not all (i.e. the ones that relate to the host system or install path, and not those that check the configuration or metadata). Given those issues and the fact that the amount of code is fairly small I elected to just re-implement the checks here. Fixes [YOCTO #8657]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-08-17toolchain-shar-extract.sh: add option to list contentsPaul Eggleton1
Add a -l command-line option for SDK installers to get a list of files that will be extracted by the SDK - internally this just runs "tar tv" on the embedded tarball. This can be used to look at which files the SDK provides without actually installing it. The initial user of this is the extensible SDK build process which needs to know what binaries are going to be installed by the buildtools installer without installing it. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-25classes/populate_sdk_ext: show progress when preparing build systemPaul Eggleton1
During the extensible SDK installation process the final step is to prepare the internal copy of the build system. This can take some time, especially if you have SDK_EXT_TYPE set to "minimal" (downloading sstate artifacts) and SDK_INCLUDE_PKGDATA set to "1" (restoring pkgdata for world). To make this a bit less painful, use BitBake's new quiet mode to display status during this operation so you have some idea of how it's progressing; instead of redirecting the output to preparing_build_system.log we grab the last console log and append it instead. One result of this change is that you get the errors printed on the console during normal output rather than this going to the preparing_build_system.log file first. In OE-Core revision 227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the contents of preparing_build_system.log on failure, but now at least the error contents of that log is duplicated. Besides, I intentionally didn't print out the contents of that log during normal usage because it's quite verbose - the bug that we were attempting to fix was about not getting this information when seeing failures in the automated tests, thus I've moved printing the log to the test handling code instead. Part of the implementation for [YOCTO #9613]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-07classes/populate_sdk_ext: eliminate double execution on installPaul Eggleton1
Use the new BB_SETSCENE_ENFORCE functionality to avoid having to run bitbake twice on installing the extensible SDK - we can now do it all in one invocation which not only takes less time, but we should also get more meaningful errors for some types of failure, in particular where downloading from an sstate mirror fails. One result of this change is that you get the errors printed on the console during normal output rather than this going to the preparing_build_system.log file first. In OE-Core revision 227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the contents of preparing_build_system.log on failure, but now at least the error contents of that log is duplicated. Besides, I intentionally didn't print out the contents of that log during normal usage because it's quite verbose - the bug that we were attempting to fix was about not getting this information when seeing failures in the automated tests, thus I've moved printing the log to the test handling code instead. Part of the implementation of [YOCTO #9367]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-07-07toolchain-shar-extract.sh: allow TERM through into SDK installer envPaul Eggleton1
In order to show the task progress during the extensible SDK installation, knotty needs to know it is using a terminal it can support the "interactive" mode on (i.e. ncurses can be used), which means it needs access to the TERM variable value, so allow that through into the cleaned environment within the SDK installation script. Part of the implementation for [YOCTO #9613]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02scripts: Replace basestring -> str for python3Ed Bartosh1
Python 3 doesn't have basestring type as all string are unicode strings. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
2016-05-21bitbake.conf/toolchain-shar-extract: Use en_US.UTF-8 as localeRichard Purdie1
Under python 3, if we spawn python processes, we need to have a UTF-8 locale, else python's file access methods will use ascii. You can't change that mode once the interpreter is started so we have to ensure a locale is set. Ideally we'd use C.UTF-8 since OE already forces the C locale but not all distros support that and we need to set something so en_US.UTF-8 seems as standard we we can get. This matches the change in bitbake revision 8902c29638411d312e6fc4a197707e5742652e15 Also set this into the environment used when installing SDKs since python can be run and we need to ensure we use a standardised locale which is available from things like buildtools-tarball. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-18ext-sdk-prepare.py: exclude do_rm_work from unexpected output; create unit testBill Randle1
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>
2016-04-15fs-perms.txt: fix ROOT_HOME's permissionRobert Yang1
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>
2016-04-15Revert "fs-perms.txt: fix ROOT_HOME's permission"Ross Burton1
This reverts commit eeae2ac4887298bcbab0e105798818414686dc97.
2016-04-14fs-perms.txt: fix ROOT_HOME's permissionRobert Yang1
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>
2016-03-31toolchain-shar-extract.sh: ensure all_proxy is allowed throughPaul Eggleton1
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>
2016-03-31oe-publish-sdk: exclude sstate-cache if publishing minimal SDKPaul Eggleton1
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>
2016-03-31scripts, lib: Don't limit traceback lengths to arbitrary valuesRichard Purdie1
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>
2016-03-28toolchain-shar-extract.sh: check the length for target_sdk_dirWenlin Kang1
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>
2016-03-23classes/populate_sdk_ext: parse metadata on minimal SDK installPaul Eggleton1
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>
2016-03-20ParaTypeFFL-1.3: Add license fileIoan-Adrian Ratiu1
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>
2016-03-11meta: toolchain-shar-relocate.sh: Fix for extracting SDK in the same ↵Zawadzki, Krzysztof (Nokia - PL/Wroclaw)1
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>
2016-03-06ext-sdk-prepare: Catch setscene tasks which should have run but didn'tRichard Purdie1
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>
2016-02-10toolchain-shar-extract.sh: Add proxy variable to new env.Aníbal Limón1
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>
2016-01-22toolchain-shar-extract.sh: improve behaviour when xz is not installedPaul Eggleton1
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>
2016-01-22meta/files/toolchain-shar-relocate.sh: Detect different python binaries and ↵Liam R. Howlett1
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>
2016-01-13classes/populate_sdk_ext: check that extensible SDK prepared correctlyPaul Eggleton2
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>
2016-01-11populate_sdk: Switch from bzip2 to xzRichard Purdie1
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>
2016-01-11populate_sdk_ext: Use new --setscene-only option to bitbake instead of ↵Richard Purdie1
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>
2015-12-11toolchain-shar-extract.sh: fix ~ not working in pathPaul Eggleton1
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>
2015-12-08toolchain-shar-extract.sh: ensure cleaned environment will work for ext SDKPaul Eggleton1
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>
2015-12-08toolchain-shar-extract.sh: proper fix for additional env setup scriptsPaul Eggleton2
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>
2015-12-01toolchain-shar-extract.sh: Ensure it's ran in clean environmentGeorge Nita1
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>
2015-12-01toolchain-shar-extract.sh: do not allow $ in paths for ext SDKPaul Eggleton1
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>
2015-12-01toolchain-shar-relocate: don't assume last state of env_setup_script is goodJean-Francois Dagenais1
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>
2015-10-20toolchain-shar-extract.sh: print full-length title underlinePaul Eggleton1
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>
2015-10-20classes/populate_sdk_ext: prevent image construction from executing on installPaul Eggleton1
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>
2015-10-19toolchain-shar-extract.sh: provide proper path for env_setup_scriptMaxin B. John1
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>
2015-10-19common-licenses: use correct GFDL-1.1 license textPaul Eggleton1
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>
2015-09-29toolchain-shar-extract: Correct environment-setup script names for multilibRichard Purdie1
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>
2015-09-29toolchain-shar-relocate.sh: make it fasterRobert Yang1
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>
2015-09-24toolchain-shar-extract.sh: remove checkbashismRobert Yang1
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>
2015-09-22toolchain-shar-extract.sh: show progress when extracting SDKPaul Eggleton1
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>
2015-09-07Extensible SDK: allow for installation without preparing build systemQi.Chen@windriver.com1
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>
2015-09-07toolchain-shar-extract.sh: explain why we cannot use sudo in extensible SDKBrendan Le Foll1
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-07toolchain-shar-extract.sh: better default install path for extensible SDKBrendan Le Foll1
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>
2015-09-07toolchain-shar-extract.sh: ensure extensible SDK install path obeys restrictionsBrendan Le Foll1
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>
2015-08-19toolchain-shar-extract.sh: add a space in the endRobert Yang1
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>
2015-07-20extensible sdk: Error when trying to install as root.Randy Witt1
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>
2015-06-11Add license file XFree86-1.0Kai Kang1
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>
2015-04-30Revert "common-licenses: Add common license files for linux-firmware"Jackie Huang36
This reverts commit 9021ee03e0f9bd36b0ce63fa29dd010e07241fdb
2015-04-24toolchain-shar-extract.sh: mention how to set up the SDK environmentPaul Eggleton1
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>
2015-04-24classes/populate_sdk_base: Show title in SDK installerPaul Eggleton1
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>