I am not yet convinced why should we have such version specific patch

<quentin.schulz@...> wrote: once dot release is out then thats whats maintained not the original release since they are incremental. the anon python to apply a patch. Can you explain

<quentin.schulz@...> wrote: Patching piece below looks quite a bit. lets just fix v5.14.14 and dont worry about 3.4

Signed-off-by: Khem Raj <raj.khem@...> --- recipes-devtools/flex/flex_%.bbappend | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 recipes-devtools/flex/flex_%.bbappend diff --git a/rec

do you have stack trace ? that might give some more info on whats going on

#golang

Whatever you are setting for LICENSE Variable inside recipe there should be a file with same name stored inside One of LICENSE_PATH directories.

at one point, I had ppc64le working as SDKMACHINE target as well.

It’s also good to post your build configuration that bitbake prints at the beginning of build this could also be other policies like default libc being musl vs glibc is in play etc

OK, I think it will be a while before I can get to tip if dunfell though.

it was dunfell primarily

We have seen a lot of hung builds when we used this option internally on builders, Additionally some packages like bison started to fail intermittently which seemed like a parallel build issue but nev

Hi Jared Please see [1] usually sending to the right mailing list and CCing the maintainers is the usual way to send patches [1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-qt4/tree/README

This was enabling ssp support in glibc not only for other programs but also for rest of glibc components during compile and that resulted in duplicate symbols, IIRC thats why we disabled it, the error

seems fine. Please send a patch for enhancing it via docker.cfg

#meta-virtualization

you might want to use latest master, fix that you might find useful is https://git.openembedded.org/openembedded-core/commit/?id=7f577c10913104860121f682b9b3754870c4db23

So it seems your makefile is not respecting the LDFLAGS coming from the environment during linking. perhaps you should fix that in your linking rules. hardcoding hash style like this is not portable.

x86 is for 32 bit intel arch you won’t see It in pure 64bit machines

use of override here seems unnecessary > > > > >

yocto provides a layer to abstract native binaries on top of build host and thats what you are seeing. Its as designed. > > >

#toolchain #sdk #bitbake #native

look at meta-browser/meta-chromium as well.