Let me chime in. Nico, thank you so much for your leadership as the Yocto community manager and beyond. You certainly made sure that the community remained welcoming and supportive to new and current

On 3/22/23 10:56, Jose Quaresma wrote: Thank you. That did the trick. I should have known that. It's one of these days...

I have a vendor project which uses CMake FetchContent. It's simple to override FETCHCONTENT_FULLY_DISCONNECTED=ON which is set in the cmake class. However, that does not fix the issue since network is

Hello, PACKAGECONFIG is to enable/disable features for a particular software package on a per-recipe basis. Hence, by its nature, PACKAGECONFIG is a recipe local variable. If you want to set it in a g

Oh no, now the entire Yocto Project world knows about this hack. Now we need a sanity checker for this in the insane class. :)

To me this indicates that the maintainer of the layer has tested the compatibility of his layer with all of these releases of the Yocto Project. A maintainer of a layer should make a deliberate decisi

Ron, Welcome. When asking a question on a mailing list it is always advisable to put all relevant information pertaining to the question into the email and be specific about what you think the problem

I can confirm that updating kern-tools-native to 6a4752eb resolved the issue for me.

Thank you, Jose and Bruce. Much appreciated. Rudi

I am running into a bizarre problem with kernel configuration. I have an existing build environment that builds for an i.MX6ul machine. That works fine and the linux-fslc kernel 5.18 builds without an

Yes, I have. These are the libs: 0x0000000000000001 (NEEDED) Shared library: [libQt5Quick.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0000000000000001 (NEEDED) Shared library:

Yes, but that does not satisfy the dependency: ERROR: virtuoso-0.1-r0 do_package_qa: QA Issue: /opt/virtuoso/virtuoso contained in package virtuoso requires libGLESv2.so()(64bit), but no providers fou

Thanks, Khem. libGLESv2 in question on the target was built with YP: 0x000000000000000e (SONAME) Library soname: [libGLESv2.so.2] The SDK that builds the application was built with the same YP setup.

Thank you, Quentin. Yes, that is exactly the issue: 0x0000000000000001 (NEEDED) Shared library: [libQt5Quick.so.5] 0x0000000000000001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0000000000000001 (NEED

I am packaging a binary package that has been built with the SDK created with the exact same configuration. During do_package I am getting an error that a dependency on libGLESv2.so()(64bit) cannot be

It was definitely an architecture mismatch. I checked the architecture of the files with objdump. That is what threw me off in the first place. I simply checked the versions. They were off but I could

Thanks, Richard. I was sidetracked by other stuff, hence the delay. Please see below. That's the objdump on libc.so.6 on the target (aarch64, Honister): Version definitions: 1 0x01 0x0865f4e6 libc.so.

It's Yocto that creates the spec file for rpm. Apparently, besides relying on what is declared in RDEPENDS, it actually iterates over the files and appends the dependencies (and their versions). It re

Yes, thank you. ERROR: xxx-single-group-0.1-r0 do_package_qa: QA Issue: /opt/binstuf/linux-allwinneryocto-armle-opengles_2.0-obj/lib/libfbxsdk.so contained in package xxx-single-group requires libpthr

Not exactly as is because of customer names, but below is a sanitized version: SUMMARY = "Binary Stuff" LICENSE = "CLOSED" SRC_URI = "file://binary_installer.tgz \ " do_install() { install -d -m 0755