I test the results by running bitbake core-image-sato. If it builds successsfully, then I assume that it is fine, Please what method do you recommend I use to test the results.

It depends on how you're testing the end result. I don't mind improving the scripts but what we don't really want are patches made by just doing what that tool says without the result being

Okay thank you what about Using $(...) notation instead of legacy backticked `...`. base=`basename $0`, changing it to base=$(basename $0) Should I commence those changes? I'm seeing that based om

I want to suggest a little bit of caution with the direction these changes are going. Showing the user a clear error if that have spaces in a build path is a good thing. Making oe-init-build-env

I meant to say globbing sorry. I will remove the quotes from the subject. If quotes are not needed in the file=$1, does that means the first patch is fine?

hi Mike, I have sent a patch that has the changes from your review. cheers.

Signed-off-by: Abongwa Bonalais Amahnui <abongwabonalais@...> --- scripts/bitbake-prserv-tool | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git

Signed-off-by: Abongwa Bonalais Amahnui <abongwabonalais@...> --- scripts/autobuilder-worker-prereq-tests | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

See comment below (our mail server injects signatures, sorry for that) Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ

Signed-off-by: Abongwa Bonalais Amahnui <abongwabonalais@...> --- scripts/bitbake-prserv-tool | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git

Hello Alex, "Alex Kiernan" <alex.kiernan@...> ha scritto: This patch has [meta-oe] in the subject line but it is indeed for oe-core. No need to resend it, I've taken it for autobuilders

Hi, Am 11.04.2022 um 09:17 schrieb Stefan Herbrechtsmeier via lists.openembedded.org: I have open an issue: https://github.com/bluez/bluez/issues/329 I will post a patch when we come to a

Hi Richard, Thanks a lot for the explanation! I might come back to this at a more relaxed period with the suggested improvements. regards, Claudius

There were a few things which concern me. It is late in the release cycle for this to make it into kirkstone so I was deferring it until 4.1 and the next development cycle. I was worried that it

Hi, This patch was on master-next for a short while, any feedback on it? In the cover letter I stated the only downside of this solution is, that in case of package based updating, it would require

If libcap is compiled with pam in PACKAGECONFIG one additional license text becomes effective, add that as a conditional Signed-off-by: Konrad Weihmann <kweihmann@...> --- v2: - use spaces

Perhaps sign_package_feed.bbclass needs something like: PACKAGEINDEXDEPS += "gnupg-native:do_populate_sysroot" I'm not sure why/how it works in the rpm case but it does seem like the dependency is

Hi Richard,

Hello, I believe this has introduced a race condition and is the cause of those two