linux/poky.git/bitbake/lib/bblayers, branch scarthgap-5.0.15

bitbake: bblayers/query: Fix using "removeprefix" string method

2025-02-21T14:25:05+00:00

The minimum Python version required for Yocto 5.0 is 3.8 which causes failure in poky/bitbake/lib/bblayers/query.py when listing layers by using command "bitbake-layers show-recipes -f --bare --mc MC" for the given multiconfig MC. The reason for that failure is the use of "removeprefix" string method which got introduced in Python 3.9. This patch replaces the "removeprefix" method with an equivalent solution supported by Python 3.8. (Bitbake rev: f6635b32ab553e812fe7c05998ef05834fccd0f3) Signed-off-by: Joerg Schmidt Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

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: 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: bblayers/query: Add multiconfig support to `show-appends`

2023-08-16T08:43:49+00:00

Adds a --mc argument to `bitbake-layers show-appends` so that users can filter appends for a specific multiconfig (instead of always showing the default configuration) (Bitbake rev: f4dcbf114554c829467623b5587314d16ebdf3eb) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: action.py: add topdir in bblayers_conf path for remove-layer

2023-02-17T18:02:04+00:00

By including the full path to bblayers.conf the remove-layer command can be executed from any location, not only from the build directory. (Bitbake rev: 25cb4e17e8a4c0310df018b9df184b0155b267eb) Signed-off-by: Pedro Baptista Signed-off-by: Richard Purdie

bitbake: action.py: add topdir in bblayers_conf path for add-layer

2023-02-17T18:02:04+00:00

By including the full path to bblayers.conf the add-layer command can be executed from any location, not only from the build directory. (Bitbake rev: 77aa230bf2a053fc0941723a6abbc798ebe53a19) Signed-off-by: Pedro Baptista Signed-off-by: Richard Purdie

bitbake: bblayers/query: Adjust show-layers output layout

2023-02-04T17:03:15+00:00

Increase the `ljust` value for each column in show-layers output. This improves readability when long layer paths are included (Bitbake rev: a56cd53e0e67a368acace9dab184bd94b9b67b1b) Signed-off-by: Pedro Baptista Signed-off-by: Richard Purdie

bitbake: bblayers/query: Replace layer directory name with layer name for show-layers

2023-02-04T17:03:15+00:00

Replace the layer directory name with the name from BBFILE_COLLECTIONS which is useful when assigning a LAYERDEPENDS value (Bitbake rev: 517cc3f5aee2a7d6362ce0202d4ee709a5378096) Signed-off-by: Pedro Baptista Signed-off-by: Richard Purdie

bitbake: bitbake: bitbake-layers: checkout layer(s) branch when clone exists

2022-10-29T15:30:43+00:00

[YOCTO #7852] Fixes 'bitbake-layers layerindex-fetch --branch kirkstone meta-arm' not checking out the branch if the repo is already cloned and on a different branch. If a clone of a layer being added already exists check what branch it is on and if necessary attempt to switch to the given branch. If the switch fails to happen the git error will be reported. We also warn if there are uncommitted changes as the changes might go unnoticed and result in unexpected behaviors. (Bitbake rev: d2cb388f58a37db2149fad34e4572d954e6e5441) Signed-off-by: Mark Asselstine Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

bitbake: BBHandler/cooker: Implement recipe and global classes

2022-08-12T10:49:29+00:00

We have some confusion for users since some classes are meant to work in the configuration space (or "globally") and some are meant to be selected by recipes individually. The cleanest way I could find to clarify this is to create "classes-global" and "classes-recipe" directories which contain the approproate classes and have bitbake switch scope between them at the appropriate point during parsing. The existing "classes" directory is always searched as a fallback. Once a class is moved to a specific directory, it will no longer be found in the incorrect context. A good example from OE is that INHERIT += "testimage" will no longer work but IMAGE_CLASSES += "testimage" will, which makes the global scope cleaner by only including it where it is useful and intended to be used (images). (Bitbake rev: f33ce7e742f46635658c400b82558cf822690b5e) Signed-off-by: Richard Purdie