linux/poky.git/meta/classes/base.bbclass, branch 3.2_M2

multilib/recipes: Use new RecipePostKeyExpansion event

2020-05-27T09:47:05+00:00

There are issues with multilib due to the ordering of events where some functions see the remapped multilib dependencies and some do not. A significant problem is that the multilib class needs to make some changes before key expansion and some afterwards but by using existing event handlers, some code sees things in a partially translated state, leading to bugs. This patch changes things to use a new event handler from bitbake which makes the ordering of the changes explcit. The challenge in doing this is that it breaks some existing anonymous python and dyanmic assignments. In some cases these used to be translated and no longer are, meaning MLPREFIX has to be added. In some cases these are now translated and the MLPREFIX can be removed. This change does now make it very clear when MLPREFIX is required and when it is not, its just the migration path which is harder. The patch changes the small number of cases where fixes are needed. In particular, where a variable like RDEPENDS is conditionally extended (e.g. with an override), MLPREFIX is now required. This patch also reverts: base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION' This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes to multilib datastore handling mean its no longer necessary. (From OE-Core rev: b3fda056a674889cd9697e779de023d4f993d3ce) Signed-off-by: Richard Purdie

base/insane: Check pkgs lics are subset of recipe lics only once

2020-05-21T09:52:07+00:00

Move logic checking that all packages licenses are only a subset of recipe licenses from base.bbclass to the insane.bbclass so that it's evaluated only once, during do_package_qa. As explained in the linked bugzilla entry, if a package license is not part of the recipe license, the warning message gets shown an unreasonable amount of time because it's evaluated every time a recipe is parsed. [YOCTO #10130] This also makes it possible to silence this error with INSANE_SKIP. (From OE-Core rev: 852408ed4be1f64c57e196688728b7ed223d3493) Signed-off-by: Quentin Schulz Signed-off-by: Richard Purdie

base.bbclass: extend PACKAGECONFIG for conflict package configs

2020-03-12T12:46:08+00:00

There are mutually exclusive PACKAGECONFIGs in recipes. Though it declares that package configs are exclusive, it can't prevent users to set them at same time. Extend PACKAGECONFIG to support specifying conflicted package configs. (From OE-Core rev: 734475b3f86d88a548bc9eb91d836bd1b9335e9f) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie

distrodata/maintainers: Add PARSE_ALL_RECIPES flag to fix test issues

2020-01-27T16:48:10+00:00

Currently the test depends on which DISTRO_FEATURES and targets are selected. Similar to SOURCE_MIRROR_FETCH, add PARSE_ALL_RECIPES to allow the test to see a much wider range of them. This avoids issues added by the new ucontext musl specific recipe and allows the current whitelist to be cleared out a bit (more cleanup can follow). (From OE-Core rev: c139e058bb2df48c79784cf3fd701e51bbc68427) Signed-off-by: Richard Purdie

base.bbclass: clean up dead symlink when handling hosttools

2019-12-30T08:47:09+00:00

When some hosttool is a dead symlink, bitbake any recipe will fail with error like below. FileExistsError: [Errno 17] File exists: '/usr/bin/chrpath' -> '/path/to/builddir/tmp-glibc/hosttools/chrpath' So we remove dead symlink under hostools/ directory to avoid such error. (From OE-Core rev: b03577cf85784fc052b89083054d911816f8c6e1) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

base.bbclass: Report only the licenses that are incompatible for a package

2019-12-16T23:25:50+00:00

Instead of reporting ${LICENSE} when a package is identified as using an incompatible license, report the license(s) that are actually incompatible. (From OE-Core rev: fb3405fac7b933a3f9d23e5faf6a3cf2d1990982) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

base.bbclass: Simplify the check for whitelisted licenses

2019-12-16T23:25:50+00:00

After a number of rewrites, the code checking if a package has been whitelisted for an incompatible license was calculating the whitelisted packages twice (as 'whitelist' and as 'incompatwl'). (From OE-Core rev: 01dcc8c94b882d865fc72a067a90d9721ac5fea7) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

hosttools: no longer check for or provide host python 2 to builds

2019-12-09T10:21:51+00:00

(From OE-Core rev: 5f8f16b17f66966ae91aeabc23e97de5ecd17447) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

base.bbclass: Add python3-native to native paths for hg fetcher

2019-12-06T14:41:28+00:00

This helps fix an issue where python interpreter in hg script could overflow the BINPRM_BUF_SIZE which is 128 on most of systems, because interpreter is hardcoded and build paths can be deep. This patch helps, because now the absolute python interp path in hg can be replaced with '/usr/bin/env python3' and it will ensure that python3 from native install is used instead of the one on host. (From OE-Core rev: 3adaaab787bd105cc0049d36c7b8caeaa9b633e5) Signed-off-by: Khem Raj Cc: Christopher Larson Signed-off-by: Richard Purdie

base.bbclass: add dependency on pseudo from do_prepare_recipe_sysroot

2019-10-19T22:18:33+00:00

do_prepare_recipe_sysroot may perform groupadd, which requires pseudo. However, do_prepare_recipe_sysroot does not depend on pseudo explicitly, which sometimes causes a build error when building a recipe that adds groups. This issue only occurs when executing do_prepare_recipe_sysroot for a recipe that adds groups before finishing a task that depends on pseudo for a recipe that doesn't add groups. (From OE-Core rev: 427320d7621846d57649af46bf57c88f86cac612) Signed-off-by: Mattias Hansson Signed-off-by: Richard Purdie