How much difference is there between x32 and riscv32 in upstreams? As they would trip on the same issues, one would assume that if the issue is fixed for one, it gets fixed for the other too. But

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

<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

Kas certainly does. Ross

We do both: "fixes" layer(s) with bbappends for stuff that can be done that way, and a local mirror of the upstream repo where we backport patches that can't be done with the "fixes" layers. The

You can also maintain an extra layer that handles the changes you are interested in. And even if that is not possible, in my experience, maintaining a fork is less headache than maintaining custom

Hi all,

Hi Philip, Very interesting and confirming my thoughts. Thank you -- Marco

Thanks to everyone that replies and especially to people helping get answers from outside our developer bubble. See the attached pdf. Philip

reuse compatibility would be pretty useful and we can give in this way an example for community layers. Andrei

FWIW, I fully agree that meta-gplv2 should be retired. It is fairly easy to build images without any GPLv3 binaries but have package repository with ptests, bash, development and debugging tools etc

Busybox bash or even dash perhaps could be a replacement after all Ubuntu defaults shell to dash these days so it must carry some distance. We have bash hard dependency mostly in ptests and perhaps we

I agree also, there are better alternative approaches now. -- Christopher Larson chris_larson@..., chris.larson@..., kergoth@... Principal Software Engineer, Embedded Linux Solutions, Siemens Digital

<richard.purdie@...> wrote: For bash, I wanted to play with busybox's replacement for it, and see if it's feasible to set up as alternative, or even default. Too pressed for time

In particular, it doesn't work with ptests or anything needing bash :( Cheers, Richard

But we do: https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py#n128 Anything in particular missing there? Alex