openembedded-core.git/meta/files, branch uninative-1.4

toolchain-shar-relocate.sh: Fix typo

2016-09-23T17:05:44+00:00

Signed-off-by: Richard Purdie

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

2016-09-22T10:08:22+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]

Signed-off-by: Mariano Lopez 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: drop duplicated error message

2016-08-17T09:32:16+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).

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: add some pre-install checks

2016-08-17T09:32:15+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].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

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

2016-08-17T09:32:14+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.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: show progress when preparing build system

2016-07-25T22:46:58+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].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: eliminate double execution on install

2016-07-07T12:29:01+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].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

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

2016-07-07T12:29:01+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].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

scripts: Replace basestring -> str for python3

2016-06-02T07:10:03+00:00

Python 3 doesn't have basestring type as all string
are unicode strings.

Signed-off-by: Ed Bartosh

bitbake.conf/toolchain-shar-extract: Use en_US.UTF-8 as locale

2016-05-21T21:26:26+00:00

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