Now that we've switched to using wic for image layout, we can remove the unused recipes for proprietary vendor tools. Signed-off-by: Trevor Woerner <twoerner@...> ---

Hello community, I have noticed that do_kernel_metadata is always executed before do_patch. What is the reason for this ordering? In my setup, I have a patch that changes some options in the in-tree

heh ... i remember it took me a few reads once upon a time to finally grok the proper usage of a lot of docbook markup. in any event, i'm not pushing for a bunch of stuff to happen all at once,

Ok, I created a symbolic link with “ln -s /lib /lib64” and it seemed to work. Thanks a lot. Von: yocto@... <yocto@...>Im Auftrag von Alexander Kanavin Gesendet: Mittwoch, 12. Februar 2020

But this is exactly what happens: the kernel reads the dynamic loader/interpreter path from the binary (which is different than the list of dynamically linked libraries printed by ldd), isn't able to

I used the x86_64 variant from the layer (it only downloads the binaries and copies them). And I checked that with ldd, it seemed ok so

That layer does have the x86_64 variant as well, no? Is it not working? https://github.com/RDunkley/meta-dotnet-core/blob/master/recipes-runtime/dotnet-core/dotnet-core_3.1.1.inc The error you're

Hello Alex, Thanks for replying. Yes, I know that this isn’t the way it works on Yocto (and I told the managers it is a crappy idea to do that more than once). But they need .NET Core in that

Yocto generally does not support this use case. The binary was compiled in a different environment and expects things in different places, and probably being different versions too. I could point out

Hello, I’m trying to create a normal QEmu (x86-64) Image, which I can let run in Virtualbox. As a addition I deployed .NET Core, which I got from this

A build flagged for QA (yocto-3.0.2.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.0.2.rc2 Build hash information: bitbake:

Yocto is a community project. If you think such a tool is missing, patches are welcome. Talk to your employer about ability to contribute under your real name. Alex

Post/* all ( except Post/migrations/* , __init__.py and templatetags/* ) have some sort of MIT headers; adding SPDX header to make it obvious. project/* & test-data/* all ( except __init__.py ) have

Images are supposed to be all custom. It means if you cannot easily use one of the existing images, you create your own. There are ways to bbappend an existing image and mangle its content, but it's

was able to modify the vendor's machine/inc file to remove the offending package. Since the whole tree is in git now, I suppose that's OK, but I do wish yocto had better tools for managing inclusions

On 2/11/20 11:16 AM, rpjday@... wrote: Wrong ML. We have a docs@... with patchwork support. - armin

Minor fixes: - punctuation - capitalization - markup - wording Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git

You need to modify the image recipe so that those packagegroups are not pulled in. If you cannot do that because it's in a layer controlled by someone else etc, then make a new image recipe, and build

My vendor finally realized that I needed a full yocto release and not the eSDK. Anyway, I can build their image, but when I modify the kernel to remove CAN drivers I get the errors

From: Sergey 'Jin' Bostandzhyan <jin@...> Currently machine configs define the partition layout for each machine by setting the WKS_FILE variable. However, there are situations where it may