linux/poky.git/meta/files, branch morty-16.0.3

kernel, license, sstate, rootfs.py: Remove deploy directory README

2017-08-29T22:43:50+00:00

It isn't clear that the README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt file in the deploy directory warrants the complexity it brings elsewhere. Let's just remove it entirely. In particular, if two do_image_complete tasks run in parallel they risk both trying to put their image into ${DEPLOY_DIR_IMAGE} at the same time. Both will contain a README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt file. In theory this should be safe because "cp -alf" will just cause one to overwrite the other. Unfortunately, coreutils cp also has a race[1] which means that if one copy creates the file at just the wrong point the other will fail with: cp: cannot create hard link ‘..../tmp-glibc/deploy/images/pantera/README_-_DO_NOT_DELETE_FILES_IN_THIS_D.txt’ to +‘..../tmp-glibc/work/rage_against-oe-linux-gnueabi/my-own-image/1.0-r0/deploy-my-own-image-complete/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt’: File exists [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25680 (From OE-Core rev: 71e9e88847d7000781642ea6187ebd8f40dfdcfe) (From OE-Core rev: 20c39fdbb25c1b1867709c5bfb3ae2baef249be9) Signed-off-by: Mike Crowe Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

sdk-installer: Fix unclear SDK installer message

2016-10-11T21:59:35+00:00

When the host and the SDK architectures are incompatible the SDK installer outputs an incomplete error message "Error: Installation machine not supported!". This commit adds a more verbose error message e.g "Error: Incompatible SDK installer! Your host is i686 and this SDK was built for x86_64 hosts." (From OE-Core rev: dc3964f1c3457cc1265d1ed0095c0c491a97b47f) Signed-off-by: Todor Minchev Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

toolchain-shar-relocate.sh: Fix typo

2016-09-23T17:06:08+00:00

(From OE-Core rev: 8d6ee36493800a30e9bd6eacb671fbafe5d61ad7) Signed-off-by: Richard Purdie

toolchain-shar-relocate.sh: Add error-handling

2016-09-22T10:13:24+00:00

The relocation script of the SDK doesn't have enough error handling when replacing host perl with SDK perl or changing the symlinks. This will add those checks along with a sanity check of xargs. [YOCTO #10114] (From OE-Core rev: c9982dab4cfdd5963d2c2dd4aab99dd6a27fcd1c) Signed-off-by: Mariano Lopez Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/populate_sdk_ext: drop duplicated error message

2016-08-17T09:35:41+00:00

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). (From OE-Core rev: 80dfaf40e087b34d6360188df372c1c3805a00bd) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/populate_sdk_ext: add some pre-install checks

2016-08-17T09:35:41+00:00

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]. (From OE-Core rev: 6e6999a920b913ad9fdd2751100219c07cd14e54) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

toolchain-shar-extract.sh: add option to list contents

2016-08-17T09:35:41+00:00

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. (From OE-Core rev: 1d3e874f191f011eb9d7b0e12e513433c126036e) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/populate_sdk_ext: show progress when preparing build system

2016-07-26T07:56:27+00:00

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]. (From OE-Core rev: 0f7cb880c934b7871f3b8432f4f02603300f6129) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/populate_sdk_ext: eliminate double execution on install

2016-07-08T08:57:23+00:00

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]. (From OE-Core rev: e1390c1ef85862b91b067ab24f3c06ca506155ad) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

toolchain-shar-extract.sh: allow TERM through into SDK installer env

2016-07-08T08:57:23+00:00

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]. (From OE-Core rev: a8f11bc5ce07114b9ec7da7ad48da62e2026cd74) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie