I realize that HOSTTOOLS_NONFATAL += "getent" is set, but it doesn't help if meson is failing config. Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its

Thanks, this helps. The patch came through corrupted, and I fixed it up locally and then added your test summary to the commit. But it failed to build in my configuration: | Library xentoollog

Upgrade to release 6.2.0.156: - Improved CPU metric sampling - Improved memory metric sampling - Increased custom attribute limit from 64 to 128 - Fixed a TypeError with Uvicorn and unix sockets -

Upgrade to release 1.17.48: - api-change:lookoutequipment: [botocore] This release introduces support for Amazon Lookout for Equipment. - api-change:kinesis-video-archived-media: [botocore]

Upgrade to release 0.17.0: - Make dotenv get <key> only show the value, not key=value - Add --override/--no-override option to dotenv run Signed-off-by: Leon Anavi <leon.anavi@...> ---

Upgrade to release 1.8.7: - Decoding deflate-encoded responses now supports data which is packed in a zlib container as it is supposed to be. The old, non-standard behaviour is still

Upgrade to release 2.7.2: - Update our CI to catch issues with sdist generation, installation and testing. - Add missing test suite fixtures directory to MANIFEST.in, reinstating the ability to

We used to have multiple supported versions of openvswitch, and those were common files, hence in the .include. Over time, folks have forgotten that it was common and have clobbered the values. I'll

apart from the aforementioned oddity of appending to FILESEXTRAPATHS, i just noticed that openvswitch.bb, as its first line: require openvswitch.inc which, among other things, does this: SRC_URI

i'm more than happy to submit patches, after i've verified that i actually understand the problem and someone else verifies that there *is* a problem. patches forthcoming. rday

Great, we've found some issues but the real challenge is figuring out how  to improve things and move forward from here. If you really want to help, the work is just started. If all these unresolved

well, now that i've released the ferret into the henhouse, i see my work here is done. :-) rday

It gets worse unfortunately. See the code in classes/utils.bbclass which handles this and the magic __default: value :/. It is far from clear what is going on :( Cheers, Richard

Yes. I saw there were some ancient patches... OK. I did the testing with our libvirt testcase and ovs testcase. The summary is as follow: libvirt_test (keyword: ) test results: *1 Run libvirt_test

Thanks for reporting this, Martin. I need to look into this. I can see why this particular part of the tools build is not suitable for x86/32 but I don't think that it necessarily means that the

Thanks for the detailed description, it helps me understand how things are being used and gives me things to check before merging potential breakages. As it turns out, there was a yocto meeting today

This looks fine to me, But I'll wait to get Christopher's Ack before pulling it in. Bruce In message: [meta-virtualization][PATCH 1/2] dev86: upgrade to 0.16.21 and fix SRC_URI on 04/04/2021 Martin

merged Bruce In message: [meta-virtualization][PATCH 1/2] dev86: upgrade to 0.16.21 and fix SRC_URI on 04/04/2021 Martin Jansa wrote:

In message: [meta-virtualization][PATCH] libvirt: uprev v6.3 -> v7.2 on 02/04/2021 Xu, Yanfei wrote: We've tranditionally had runtime issues each time libvirt was uprev'd. Can you summarize the