I have the impression that the only binary vulkan-samples installs is /usr/bin/spirv-cross . Are there other packages that install more samples?

I suppose you need to look at compile and install logs for vulkan-samples. And how the installed items get split into packages. I’m short, inspect ${WORKDIR} for it. Alex

Hi Kuzemko Aleksandr, Maybe this has a broken autotools script, can you try to inherit autotools-brokensep instead of autotools? c.f.

Greetings, I see the libvulkan.so.* libs now, but I don't see any sample binaries that look like Vulkan. Is there a list somewhere for all the files in vulkan-samples? Regards

Hi All, QA for yocto-4.1_M3.rc2 is completed. You can find the full report of this release in the link below:

Hi...Quentin Schulz Thanks a lot! It's solved my issue Many thanks again :) Regards Mahendra

I am trying adapt fbi recipe. (https://github.com/Kuzma30/meta-myconf/blob/main/recipes-core/fbi/fbi_1.31.bb) When I run bitbake fbi I get NOTE: Executing Tasks ERROR: fbi-1.31-r0 do_compile:

If the samples don't link with libvulkan directly, it won't get pulled into the images. How are they loading that library, is it via dlopen() somewhere? Invisible dlopen() dependencies typically need

<quentin.schulz@...> wrote: Thanks for looking over this change. They appear to be: config is defined

Ok, so I switched to Kirkstone and added vulkan-samples to CORE_IMAGE_EXTRA_INSTALL. But no libvulkan.so in /usr/lib. Am I missing something?

You can start by adding vulkan-samples to the image - the recipe is in core. We do not test vulkan in qemu, because the software vulkan rendering is still under active development, and marked

Greetings, I'd like to test graphics rendering with Vulkan on an Aarch64 Yocto honister (qemu, host is x64). Can you tell me which parameters I need to add to local.conf to get all libs and headers

From: Peter Hoyes <Peter.Hoyes@...> The patch dtc.patch used by 2.7.3 has been accepted upstream, so it is now a Backport. Signed-off-by: Peter Hoyes <Peter.Hoyes@...> ---

From: Peter Hoyes <Peter.Hoyes@...> For a given release tag, ZEPHYR_MODULES is constant. It is therefore now populated by the generate-version.py script, the output of which is stored in the

From: Peter Hoyes <Peter.Hoyes@...> This commit uses the output of meta-zephyr-core/scripts/generate-version.py for both the 2.7.3 and 3.1.0 versions. Rename a patch for for v2.7.3 to match the

From: Peter Hoyes <Peter.Hoyes@...> Add a Python script which can be used to automatically generate configuration for new Zephyr versions. This script: * Takes the Zephyr version as a single

From: Peter Hoyes <Peter.Hoyes@...> This patch chain has been developed on top of the 2.7.3 upgrade patch. Add a script, generate-version.py, which can be used to automatically=20 generate

Hi John, meta layer is part of openembedded-core, so please re-send to the correct mailing list following the docs here https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Are

From: John Edward Broadbent <jebr@...> Git has removed support for "git submodule--helper list". https://github.com/git/git/commit/31955475d1c283120d5d84247eb3fd55d9f5fdd9 This change

There are some examples in metadata where we explicitly disable this download happening during do_configure step via FetchContent cmake module. Its better to club all downloads in do_fetch so fetcher