linux/poky.git/meta/classes/populate_sdk_ext.bbclass, branch rocko-next

populate_sdk: install UTF-8 locales in SDKs

2018-03-26T14:07:11+00:00

As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts using glibc earlier than 2.27 won't be able to find any locales, so bitbake won't start and Python can't use UTF-8. So by default install all locales into the SDK. Special-case Extensible SDKs by installing no locales as they ship glibc in a buildtools, and that will have the locales. Locale installation requires cross-localedef, so add that to DEPENDS. Also remove the explicit en_US addition in buildtools-tarball as it is now redundant. (From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1) (From OE-Core rev: 8327d50ef66c94592d76b42e147011daafc6a7c3) (From OE-Core rev: 8859d60d48918d763213470429288553adaa419c) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

populate_sdk_ext: Set cleandirs correctly

2018-01-22T10:40:15+00:00

The current conflicting use of SDKDEPLOYDIR causes a race between do_populate_sdk and do_populate_sdk_ext potentially causing the SDK to either go missing or the build to fail. (From OE-Core rev: 4de3daa129414d79e4a2a3d5f8da32e3b5b937c6) Signed-off-by: Richard Purdie

populate_sdk_ext: Use prebuilt uninative tarball

2017-12-11T21:47:41+00:00

For uninative to work, it relies on it being updated to new versions as newer glibcs are built. This means the uninative generated by the current build may not be as recent as the uninative that is being downloaded by uninative.bbclass. If this occurs, we can get symbol mismatch errors. Ultimately, the sstate and the uninative versions need to match so we should use the same tarball as uninative.bbclass is using, not the one we built. [YOCTO #12405] (From OE-Core rev: 39fc1150e74173fc6d73c464c141dba0b7ac2930) Signed-off-by: Richard Purdie

devtool: ensure recipes devtool is working on are unlocked within the eSDK

2017-09-18T10:07:29+00:00

Alongside reworking the way devtool extracts source, we now need to ensure that within the extensible SDK where task signatures are locked, the signatures of the tasks for the recipes being worked on get unlocked at the right time or otherwise we'll now get taskhash mismatches when running devtool modify on a recipe that was included in the eSDK such as the kernel (due to a separate bug). The existing mechanism for auto-unlocking recipes was a little weak and was happening too late, so I've reimplemented it so that: (a) it gets triggered immediately when the recipe/append is created (b) we avoid writing to the unlocked signatures file unnecessarily (since it's a global configuration file) and (c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES to avoid unnecessary reparses every time we perform one of the devtool operations that does need to change this list. Fixes [YOCTO #11883] (not the underlying cause, but this manifestation of the issue). (From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

populate_sdk_ext: Add BB_SERVER_TIMEOUT to SDK_LOCAL_CONF_BLACKLIST

2017-08-24T12:48:10+00:00

Whilst this should work we see failures in testsdkext at the moment when this is set. Add this to the blacklist for now until we can fix these issues meaning we can at least test BB_SERVER_TIMEOUT in other scenarios. Bug 119733 has been opened to track this. (From OE-Core rev: 88cb174680cd37b5afb2b79e8248979895c35312) Signed-off-by: Richard Purdie

populate_sdk_ext: Add variable to indicate running in eSDK

2017-07-21T21:51:37+00:00

This allows for other scripts to know that they are being executed in the context of the eSDK in order to provide different behaviour as needed. [YOCTO #11155] (From OE-Core rev: ebdd9b5a19eb6fb6c3249be4f0e2480a3de2aa8f) Signed-off-by: Saul Wold Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe-init-build-env-memres: Drop it

2017-07-21T07:44:25+00:00

With the new server structure we no longer need this separate environment init script. Just set BB_SERVER_TIMEOUT to be greater than zero and bitbake will remain in memory and the UI will auto-reconnect to it. Also clean out the old shutdown code from oe-init-build-env which also doesn't make sense now. (From OE-Core rev: a17724d687f9c04dc21f2f369da2b492f7119ba0) Signed-off-by: Richard Purdie

meta/classes/populate_sdk: Adds support for generating eSDK manifest files

2017-06-12T22:01:23+00:00

Add get_extra_sdk_info to reuse code in buildhistory The functionalities to generate SDK and eSDK manifest files are different, the SDK comes from package information and the eSDK comes from sstate artifacts. Only execute write_sdk_{host, target}_manifest when is on populate_sdk class. Adds new functions write_sdk{host, target}_ext_manifest to execute on postprocess in populate_sdk_ext because at the end we have all the sstate artifacts to generate the manifest. [YOCTO #9038] (From OE-Core rev: 25ad7ed6f7bb0c931b404bda09576323200d093d) Signed-off-by: Francisco Pedraza Signed-off-by: Aníbal Limón Signed-off-by: Richard Purdie

populate_sdk_ext: Avoid build failures where sstate was used

2017-05-16T13:08:28+00:00

If sstate was used to populate the build and one of the universal-4.8 or universal-4.9 mirror urls was used, the sstate checks during eSDK construction could fail as it would zero out the SSTATE_MIRRORs variable. Use the same mirrors variable setting as the eSDK would end up using to perform the checks to avoid this. (From OE-Core rev: 6b9e8b780dcd8d5ffba3df35cfe41674413ee26d) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: work around runqemu behaviour within the eSDK

2017-04-19T09:38:37+00:00

Currently, in order to figure out variable values when run within the eSDK, runqemu does not use the standard SDK method nor is it able to run bitbake (since the eSDK environment isn't initialised like the normal OE build environment). runqemu really ought to be fixed, but the quick workaround is to set DEPLOY_DIR_IMAGE in the environment so that runqemu can find image files. Fixes [YOCTO #10447]. (From OE-Core rev: 1ef833b6393366a10f4bb65df89725ad65761386) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie