linux/poky.git/bitbake, branch master-uninative

bitbake: knotty.py: Show elapsed time also for tasks with progress bars

2022-04-05T09:50:08+00:00

While the progress bar is good at conveying information about how much of a task has executed, the elapsed time of the task is still very much relevant to show. (Bitbake rev: 41eeb4f34fb2306303f7688ec5e0ae965a573aa4) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bitbake: data: Fix accidentally added parameter

2022-04-04T09:59:56+00:00

This was only meant to be added for the handle_contains function in a previous commit, fix it. (Bitbake rev: 7399be398df39bc29e1b5eaac23b29cfae017abd) Signed-off-by: Richard Purdie

bitbake: pyinotify: Handle potential latent bug

2022-04-03T16:51:26+00:00

The kernel inotify code can set more than one of the bits in the mask, fsnotify_change() in linux/fsnotify.h is quite clear that IN_ATTRIB, IN_MODIFY and IN_ACCESS can arrive together. We don't care about two of these from a bitbake perspective but it probably explains why in real world builds, we've seen: pyinotify.ProcessEventError: Unknown mask 0x00000006 This module code assumes only one mask bit can be present. Since we don't care about two of these events, just mask them out for now. The "upstream" code is unmainained since 2015. (Bitbake rev: 7fb93c2ce6dacd9b53fc3a227133a3493e6a6a1d) Signed-off-by: Richard Purdie

bitbake: cooker: Reset and rebuild inotify watches

2022-04-03T16:51:26+00:00

The recent inotify changes can cause entire build trees to be monitored which is suboptimal for performance. Rather than trying increasingly convoluted tricks to try and handle add/removed directories, rebuild the inotify watch when we reparse the configuration or metadata. (Bitbake rev: 3df322a200c28b45af1f2c92478c85eb7d20c38b) Signed-off-by: Richard Purdie

bitbake: server/process: Disable gc around critical section

2022-04-03T16:51:26+00:00

The python gc can trigger whilst we're holding the event stream lock and when cleaning up objects, they can trigger warnings. This translates into a new event which would then need the lock and we can deadlock. Disable gc whilst we hold that lock to avoid this unfortunate and problematic situation. (Bitbake rev: 96a6303949cefd469bcf5ed250ff512271354357) Signed-off-by: Richard Purdie

bitbake: data: Ensure vardepsexclude or BB_BASEHASH_IGNORE_VARS covers contains items

2022-04-03T16:51:26+00:00

Adding bb.utils.filter('WARN_QA', 'patch-fuzz', d) when WARN_QA is in BB_BASEHASH_IGNORE_VARS or in vardepsexclude should not add a dependency on WARN_QA. Fix it and add some tests. (Bitbake rev: 6aecc2fe51a52020f6f13be08449e18d42e7a6b5) Signed-off-by: Richard Purdie

bitbake: parse: Ensure any existing siggen is closed down first

2022-04-03T16:51:26+00:00

We're still seeing issues with unclosed asyncio event loops. At the init site, make sure any existing one is closed first to try and avoid this. (Bitbake rev: 78dee3c03c75a27531fcff26f9298fce2519bdde) Signed-off-by: Richard Purdie

bitbake: cooker: Avoid error if siggen wasn't setup

2022-04-01T22:14:01+00:00

In some cases we'd never have setup a siggen so don't error in that case. (Bitbake rev: bbaaf2cf7b5a9339d3790610e622020c19d52f5a) Signed-off-by: Richard Purdie

bitbake: cooker: Ensure any existing hashserv connection is closed

2022-04-01T22:14:01+00:00

Ensure any exiting hash server connection is terminated before we start a new bitbake session. This avoids errors seen with memory resident bitbake when the asyncio event loop isn't closed correctly. (Bitbake rev: 42ff9de77f24e2a0bec48a14b64c4b538e00b4af) Signed-off-by: Richard Purdie

bitbake: cooker: Restore sys.path and sys.modules between parses

2022-04-01T22:14:01+00:00

When memory resident bitbake is active and we re-parse, the old module configuration is present which can lead to strange errors. Reset this when reparsing so the state is consistent. This fixes memory resident bitbake errors. (Bitbake rev: 951942c3c284ec2c62e730e145688033190af9b2) Signed-off-by: Richard Purdie