This is unfortunately a known issue and is one reason I'd like to stop recipes downloading files to WORKDIR. Sadly changing that to fix this bug is very invasive and painful but I think we do need to

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

I don't know if there are any Yocto users of it who might notice. Instead of dropping the testing completely, may be we should switch to building/testing just the core-image-minimal image on

Hi Nicolas, I guess part of your problem is that DISTRO does not end up in any package grouping, unlike MACHINE and ARCH and so. So if OE/Yocto does The Right Thing, this means that it will have to

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

Reviewed-by: Michael Opdenacker <michael.opdenacker@...> Indeed, it should be applied right after the latest pull request from master-next is applied. Cheers Michael. -- Michael Opdenacker,

Build and test core-image-full-cmdline with the linux-yocto-rt kernel, adding the new rt test to verify that the kernel is actually the PREEMPT_RT version expected. Signed-off-by: Ross Burton

Hello Alexander I am putting some of lines of qemu output of nographic here . [ 0.053290] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) [ 0.053300] ACPI: INT_SRC_OVR (bus 0

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

Hi Poornesh This is not supported in Zeus, but otherwise you may be interested in the "overlay-etc"

Hi, This seems like a good use for overlayfs-etc IMAGE_FEATURES? c.f. https://docs.yoctoproject.org/ref-manual/features.html#image-features See

Hello Alexander Please find the output of 'env' below

Greetings ! I am working on NXP's i.MX6UL SoC and I have successfully built a Read-only Rootfile system through Yocto. Now I am having a requirement of making only "/etc" as Read & Writable . So , Can

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

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

Does the RISC-V ecosystem care about riscv32? The problem with Intel x32 is that very few people care, so we end up fixing upstream software. If RISC-V cares then we won’t be alone. Also, Intel

From: Michael Opdenacker <michael.opdenacker@...> From: Quentin Schulz <quentin.schulz@...> In order to maintain one less file, let's auto-generate the releases.rst file

<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

That amounts to dropping x32 support because as soon as we remove these tests, it will bitrot. There is still some value in the project being able to support different architectures and different

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