linux/poky.git/bitbake/lib/bb/cookerdata.py, branch yocto-4.0.12

bitbake: cookerdata: Drop dubious exception handling code

2023-03-14T15:05:30+00:00

This code appears to be dangerous, it swallows exceptions, turning them into "handled" versions which then show no errors to the user. This is a pretty poor user experience and I can't see why this code should be swallowing such things. Drop the worst bits of code. (Bitbake rev: a29ffcc12df24737e702e198aeb8f6892884932b) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cookerdata: Improve early exception handling

2023-03-14T15:05:30+00:00

Martin Jansa reported that if you put a syntax error into an imported module such as qa.py in OE, no error is shown. Part of the issue appears to be that the catch_parse_error() decorator only catches certain exceptions and SyntaxError isn't one of them. As far as I can tell we should remove all the special cases and use the more advanced code in all cases, not just expansion errors. I confirmed this now prints a proper error message for a qa.py syntax error. (Bitbake rev: e66012bfda60ffe1658473e25879aa67909ae65f) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cookerdata: Remove incorrect SystemExit usage

2023-03-14T15:05:30+00:00

Calling SystemExit doesn't work well with server/client usage since the string isn't printed to the right place. Use bb.fatal() instead which prints the right log output and raises and handled exception which then shows correctly on the UI. (Bitbake rev: b9ae7164d9e744e8eb9aaff79218f57233a449b7) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: lib/bb: Replace "abort" usage in task handling

2022-02-21T23:37:26+00:00

In line with the inclusive language migration defined at: https://wiki.yoctoproject.org/wiki/Inclusive_language replace the use of "abort" with "halt" in code related to handling task failure. (Bitbake rev: 831fb7f2329a3cd95b71e9c85d7d7f0d717f947f) Signed-off-by: Scott Murray Signed-off-by: Richard Purdie

bitbake: data_smart: Add support to BB_RENAMED_VARIABLES for custom strings

2022-02-21T23:37:26+00:00

Add support for custom strings in BB_RENAMED_VARIABLES and use this to show that BB_STAMP_WHITELIST and BB_STAMP_POLICY are no longer supported. (Bitbake rev: 0914011f7647571ab125bbddcd7d68e3da47226a) Signed-off-by: Richard Purdie

bitbake: data_smart/cookerdata: Add variable remapping support

2022-02-21T23:37:26+00:00

This change adds support for improving the user experience when variables are renamed. This isn't as simple as it might first appear since some bitbake variables are used through the environment before the datastore exists, some are bitbake variables which we know about straight away and some are metadata defined which we don't know about until later. This patch adds support for handling these different cases, allowing a list of bitbake renamed variables to be defined in bitbake itself and allows this to be extended through the metadata using BB_RENAMED_VARIABLES. In order to give the best feedback to the user, we default to turning on variable history tracking in the base data store from knotty, which allows filename and line number information to be shown. (Bitbake rev: bd50a5d5e4b4fa90844464396887ebdff0d4e5f7) Signed-off-by: Richard Purdie

bitbake: cookerdata: Fix typo "normally"

2022-02-20T16:45:24+00:00

(Bitbake rev: d0b633256daf8d11f213a14fb44ebc6bc5d45f37) Signed-off-by: Zygmunt Krynicki Signed-off-by: Richard Purdie

bitbake: fetch2/cooker: Fix source revision handling with floating upstreams

2022-02-17T17:51:03+00:00

Where a git url uses a tag instead of a full source revision, breakage can currently occur in builds. Issues include: * the revision being looked up in multiple tasks (fetch and unpack) * the risk a different revision may be obtained in those tasks * that some tasks may not be allowed to access the network * that a revision may not be consistent throughout a given build * rerunning a specific task may given inconsistent results To fix this, stop the workers from cleaning out the source revision store. This should only be done in the cooker itself (based on current policy). Also, where the code "sees" an upstream access, mark the recipe as not to be cached. The reparse re-triggers the upstream lookup by the server. Add a test to ensure that if get_srcrev isn't called, the user is told they're using a configuration that is known to break. (Bitbake rev: 4b5eed1626709ef3dc06b32fd55d40a2a6edd179) Signed-off-by: Richard Purdie

bitbake: cookerdata: Set TOPDIR explicitly and fix broken findTopdir()

2021-11-15T11:03:25+00:00

TOPDIR is set internally deep within the parser to os.getcwd(). Rather than do that, set it explicitly if not set. Note that modern code will almost always have a bblayers.conf file which would have already set TOPDIR before this new code. Also fix findTopdir since the conf/bitbake.conf codepath is just plain incorrect, it would find build metadata, not the current build directory that bitbake would use. Again, the use of bblayers.conf means hitting the fallback code was unlikely. This change makes everything clear and explicit. (Bitbake rev: c03df5283408dfd089b6317677d2b7af6fa73936) Signed-off-by: Richard Purdie

bitbake: lib/bb: Clean up use of len()

2021-11-03T10:12:42+00:00

(Bitbake rev: bbbc843e86639604d00d76b1949b94a78cf1d95d) Signed-off-by: Richard Purdie