linux/poky.git/meta/classes/populate_sdk_ext.bbclass, branch python3

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

uninative: Switch md5sum -> sha256

2016-03-31T08:15:03+00:00

There are various concerns about md5 so use sha256 instead. (From OE-Core rev: a88603cb2ffd4f995e16349a389902eb884252e5) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: parse metadata on minimal SDK install

2016-03-25T10:29:13+00:00

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

populate_sdk_ext: Correct commit 8b81bb56c69aabdea984352f8e267a9783c0bdbc

2016-03-09T22:33:40+00:00

Commit 8b81bb56c69aabdea984352f8e267a9783c0bdbc was accidentally merged. The DL_DIR piece was simply incorrect and should be removed. The patch commit message should have mentioned that the changes were to update populate_sdk_ext after the changes to uninative now the download is placed into a specific directory in DL_DIR. We also need to specify the uninative tarball checksum. (From OE-Core rev: be177739b46d3296c0c0c01310b499ffc6782d43) Signed-off-by: Richard Purdie