linux/poky.git/meta/classes/populate_sdk_ext.bbclass, branch 2.2_M1

classes/lib: Complete transition to python3

2016-06-02T07:24:01+00:00

This patch contains all the other misc pieces of the transition to python3 which didn't make sense to be broken into individual patches. (From OE-Core rev: fcd6b38bab8517d83e1ed48eef1bca9a9a190f57) Signed-off-by: Richard Purdie

classes/lib: Update to match python3 iter requirements

2016-06-02T07:24:00+00:00

python3 standardises its use of iteration operations. Update the code to match the for python3 requires. (From OE-Core rev: 2476bdcbef591e951d11d57d53f1315848758571) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: adjust variable blacklisting

2016-05-20T09:20:55+00:00

* Blacklist SSTATE_DIR, DL_DIR and TMPDIR by default to avoid problems such as the one mentioned in [YOCTO #9605]. * Blacklist BB_NUMBER_PARSE_THREADS since we already blacklist BB_NUMBER_THREADS and they may be set separately. Fixes [YOCTO #9605]. (From OE-Core rev: 3f2dcaaab0f5bc169086a8b6fd57c5606742cc4d) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

populate_sdk_ext: Change lockedsigs task mismatch to a warning

2016-05-11T09:33:42+00:00

It has been determined that it is highly likely that users might get signatures that don't match in an extensible sdk. This doesn't necessarily happen with oe-core, so we can set the mismatch to an error during testing if we like. However, for the case where users are creating their own sdks, we don't need an error halting their progress. locked-sigs will still function as it should. (From OE-Core rev: 6ba86d847275126bf435f144e7d029d10e7ab17d) Signed-off-by: Randy Witt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

populate_sdk_ext.bbclass : Show logfile in case the SDK EXT installation failed

2016-05-11T09:33:41+00:00

To avoid lots of output in the SDK EXT installation phase, system redirects it to a logfile ($target_sdk_dir/preparing_build_system.log) but in case of error, the contents should be shown so debugging could be faster. [YOCTO #9576] (From OE-Core rev: 227d2cbf9e0b8c35fa6644e3d72e0699db9607fa) Signed-off-by: Leonardo Sandoval Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: Create unlocked-sigs.inc containing items in the workspace

2016-04-09T22:00:43+00:00

When a recipe is added to the workspace, the signatures for the tasks will change. This means that bitbake must be told to allow the signatures to be different if they are in locked-sigs.inc. This is done by creating an unlocked-sigs.inc file which contains all the recipes in the workspace each time devtool reads the workspace. So not only will necessary things get added, previously added items will be removed by virtue of them no longer being in the workspace. This also makes sure that the extensible sdk picks up unlocked-sigs.inc as part of the configuration. [YOCTO #9195] (From OE-Core rev: 6b2b5ffdcb8bf885a1c756ea132e9d2c55e13dcd) Signed-off-by: Randy Witt Signed-off-by: Richard Purdie

populate_sdk_ext.bbclass: Enable locked sigs errors

2016-04-09T22:00:43+00:00

With the extensible sdk we want there to be an error if a task tries to run without signatures that match locked-sigs.inc. This patch enables that error. [YOCTO #9195] (From OE-Core rev: fad9bbba1154d68b5dc808d2976aa6484cd49c91) Signed-off-by: Randy Witt Signed-off-by: Richard Purdie

populate_sdk_ext: Exclude BBTASKDEPDATA from task signature

2016-04-03T14:51:37+00:00

Otherwise the task hash changes between server and worker context leading to changing task checksums. The dependency data here is tracked by other pieces of the signature. (From OE-Core rev: 1962571a7358fb9c9af2d6cfd1a01673b0d18193) Signed-off-by: Richard Purdie

oe-publish-sdk: exclude sstate-cache if publishing minimal SDK

2016-03-31T22:01:37+00:00

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 Signed-off-by: Richard Purdie

classes/populate_sdk_ext: support setting vars from environment at build time

2016-03-31T22:01:36+00:00

When running bitbake you may pass in values of variables from the external environment (making use of BB_ENV_EXTRAWHITE), and you may choose to do this when building the extensible SDK, for example: MACHINE=qemuarm bitbake -c populate_sdk_ext core-image-minimal You would naturally expect those settings to be reflected in the extensible SDK itself; however they were not, since we were only considering local.conf and auto.conf. Check the variables mentioned in BB_ENV_EXTRAWHITE to see if any are different than the values set in local.conf/auto.conf and add lines setting them in the SDK's local.conf if so. Fixes [YOCTO #9339]. (From OE-Core rev: 2bfed75c48a6f6596ded9cb64cb96f00510f914e) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie