One option is to actually build an image for a qemux86_64 machine with the items you need (or qemuarm64 if that's your build host), then use 'runqemu kvm' to get native execution speed in a fully virt

You need to rebuild the image: bitbake core-image-minimal Alex

#linux #warning #toolchain #bitbake #dunfell

The neat way would be to include appropriate configuration into the webserver recipe, e.g. a file installed in /etc/firewall.d/ that opens the port (and nothing else). Alex

It's hard to say what happens if we can't see your recipes. Can you publish them? Alex

Then you need to check the output of 'env' a) when you start the shell b) when you use oe-init-build-env and figure out how the incorrect variable gets into the environment. Are you using oe-init-buil

#bitbake

Hello, you probably need to exit the shell and then restart it and re-initialize your environment (with oe-init-build-env), as it contains the obsolete variable. Alex

#bitbake

You need to run runqemu inside a graphical X11 session (we do not support pure wayland yet). Alternatively, use 'publicvnc' parameter, and connect with a vnc client (e.g. tigervnc) to port 5900 on the

#yocto #linux #dunfell #qemu

I don't have a ready example, but you can start by reading meta/classes/insane.class - I think all of the things defined in it are extensible from a different class. Alex

A patch to address this would be appreciated. Alex

If you took go recipes from master, then try building mender from master as well, by setting up a master build. If that works fine, then you need to figure out how to backport mender as a whole, or ju

There's no way to build two versions of the same component, if the versions share the recipe name. You have to fix the application, or try to rename one set of the go recipes so it is separate from th

On Wed, 20 Jul 2022 at 17:46, Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail.com@...> wrote: Which I just resent. Now we have confirmation from Intel that nobody m

There has been a persistent stream of graphical failures on x32, and there is doubt about whether x32 is at all used by anyone nowadays - let's reduce the scope of x32 QA, and perhaps later drop it al

There's actually already a patch for that :) https://lists.yoctoproject.org/g/yocto/message/56880 Alex

This works as intended. So the problem is that when qemu runs from testimage it tries to open a graphical window using X and that for some reason fails. You can perhaps force a no-graphical execution

#linux #warning #toolchain #bitbake #dunfell

Can I also see the output of 'runqemu nographic' please? Alex

#linux #warning #toolchain #bitbake #dunfell

The fixing is often wrapped in target-specific conditionals, and so fixing one does not address the other, until the conditional is expanded with additional or statements, or checks are done from firs

Ok, let's ask Intel, specifically Anuj :-) Anuj, does Intel still care about x32, and would anyone notice if yocto drops x32 support from master branch? Alex

<richard.purdie@...> wrote: But then why not replace x32 with riscv32, which as well has 32 bit pointers but 64 bit integers and thus trips over the same type size issues? Alex

Note: this update fails on x32 with | configure: error: unrecognized GNU build triplet linux-gnux32 This time I want to put my foot down and suggest that we just drop the whole x32 variant from the au