linux/poky.git/bitbake/lib/bb/tinfoil.py, branch scarthgap-5.0.13

bitbake: cooker: Make cooker 'skiplist' per-multiconfig/mc

2025-01-24T15:59:38+00:00

Previously, the cooker skiplist was shared across multiconfigs (including default ''). If you had a recipe that was incompatible with several multiconfigs for different reasons, then the displayed reason (i.e. the "ERROR: Nothing PROVIDES" and "* was skipped" messages) might vary across invocations of bitbake. This was caused by the random order in which recipes are parsed under different multiconfig contexts, with each skip reason overwriting the previously assigned reason. I hit this specificially when using COMPATIBLE_MACHINE, but COMPATIBLE_HOST (or anything using bb.parse.SkipRecipe) would have done it too. (Bitbake rev: 7dde14582bfd104c6da26e3f5ecf2ef37a1494ce) Signed-off-by: Chris Laplante Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: tinfoil: Do not fail when logging is disabled and full config is used

2023-09-26T09:37:17+00:00

If Tinfoil is initialized with setup_logging = False and Tinfoil.prepare() is called with config_only = False, then it fails because self.localhandlers is only initialized when setup_logging = True. This is seen with, e.g., `bitbake-getvar -q -r busybox MACHINE`: Traceback (most recent call last): File ".../bitbake/bin/bitbake-getvar", line 41, in tinfoil.prepare(quiet=2) File ".../bitbake/lib/bb/tinfoil.py", line 390, in prepare for handler in self.localhandlers: AttributeError: 'Tinfoil' object has no attribute 'localhandlers'. Did you mean: 'oldhandlers'? (Bitbake rev: 616101ddb630e2c9975022068b52a87c4cf647f6) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bitbake: lib: Drop inotify support and replace with mtime checks

2023-09-18T10:35:05+00:00

With the flush in serverlog() removed and a memory resident bitbake with a 60s timeout, the following could fail in strange ways: rm bitbake-cookerdaemon.log bitbake-layers add-layer ../meta-virtualization/ bitbake-layers add-layer ../meta-openembedded/meta-oe/ bitbake -m specifically that it might error adding meta-oe with an error related to meta-virt. This clearly shows that whilst bblayers.conf was modified, bitbake was not recognising that. This would fit with the random autobuilder issues seen when the serverlog flush() call was removed. The issue appears to be that you have no way to "sync()" the inotify events with the command stream coming over the socket. There is no way to know if there are changes in the IO queue which bitbake needs to wait for before proceeding with the next command. I did experiment with os.sync() and fsync on the inotify fd, however nothing addressed the issue. Since it is extremely important we have accurate cache data, the only realistic thing to do is to switch to stat() calls and check mtime. For bitbake commands, this is straightforward since we can revalidate the cache upon new connections/commands. For tinfoil this is problematic and we need to introduce and explict command "revalidateCaches" that the code can use to force bitbake to re-check it's cache validity. I've exposed this through tinfoil with a new "modified_files" function. So, this patch: a) drops inotify support within bitbake's cooker/server and switch to using mtime b) requires a new function call in tinfoil when metadata has been modified (Bitbake rev: da3ec3801bdb80180b3f1ac24edb27a698415ff7) Signed-off-by: Richard Purdie

bitbake: tinfoil: Don't wait for events indefinitely

2023-01-11T23:14:48+00:00

If for some reason the bitbake server dies, we shouldn't loop indefinitely waiting for events within tinfoil. Add a ping test and exit if things have somehow failed. (Bitbake rev: 32da768ae67cfe0b2d154ce4667a7cfdfa5bf4b0) Signed-off-by: Richard Purdie

bitbake: tinfoil: Ensure CommandExit is handled

2022-12-29T12:49:54+00:00

By inspection, tinfoil handles two of the three command exit cases but one is missing. Add the CommandExit case in case this is the cause of one of our recipetool/devtool hangs. Regardless, the fix is necessary. (Bitbake rev: eadddd94835b6b6a8517dfed3d29e6dbb2d35988) Signed-off-by: Richard Purdie

bitbake: tinfoil: Allow run_command not to wait on events

2022-03-26T09:27:43+00:00

There are some commands where we want to see the events returned so allow the caller to request this. This also allows us to fix an infamous bug in the tinfoil testsuite in OE-Core. (Bitbake rev: 0e8421c41d97d5d50a553d70c8f775d521f1a199) Signed-off-by: Richard Purdie

bitbake: tinfoil: Fix typo "receive" and "something"

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

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

bitbake: tinfoil/data_smart: Allow variable history emit() to function remotely

2021-04-18T10:38:22+00:00

We can't access the emit() function of varhistory currently as the datastore parameter isn't handled correctly, nor is the output stream. Add a custom wrapper for this function which handles the two details correctly. (Bitbake rev: ba0fa084ccd2b1ade96425d158fd31e49e42f286) Signed-off-by: Richard Purdie

bitbake: tinfoil: Honor quiet when parsing recipes

2021-03-11T14:04:45+00:00

When using parse_recipes, honor quiet so that scripts and custom plugins for recipetool are able to mute progress bars from bitbake that would otherwise print to STDOUT. (Bitbake rev: ab9d26c4847a062cadaae5fb8caac0ead5f958db) Signed-off-by: Manuel Leonhardt Signed-off-by: Richard Purdie

bitbake: tinfoil: When sending commands we need to process events

2020-10-10T12:37:56+00:00

The server may be displaying useful information for the user through log messages so we should display anything that has been sent. Its either this or expecting every UI to implement this code around every command call which isn't good API. [YOCTO #14054] (Bitbake rev: 64ae9d7e2fad804dd9e12706c6d76b4b22f9586b) Signed-off-by: Richard Purdie