I'm starting a new thread/discussion on this with a new perspective. I did a little research myself on how these files are being used. My conclusion is that templateconf.cfg isn't really used by much

Someone needs to do the work involved and I guess that hasn't happened. It isn't entirely simple as this does still exist in the other releases. Could you open a bug please so we don't forget this. I

I need to read into the details but that looks like a great start and I'm happy to see the process being documented! Thanks for the link, I'll try and have a read. That makes sense, it is a tricky bal

I certainly love the goal. I presume you're going to share your review criteria somehow? There must be some further set of steps, documentation and results beyond what we're discussing here? I think t

I had a look at this and was a bit puzzled by some of it. I can see the issues you'd have if you want to separate the unpatched source from the patches and know which files had patches applied as that

I was asked about getting official support for the TOOLCHAIN variable in core. This is obviously late in the release cycle and after a bit of thought, the answer is no. I wanted to document why since

Hi Marius, Understandable, congratulations! :) This doesn't seem like a good direction to me. I have nothing against rust, I've spent the past couple of months trying to sort out rust support in OE-Co

lists.openembedded.org wrote: I've gone ahead and sent some patches for this for OE-Core and BitBake. There is more work to do so if anyone has a few minutes and wants to clean up a few more file head

lists.openembedded.org wrote: Some of this is autogenerated from the autobuilder and we can't simply remove it as it needs to stay for the older releases. We'll likely need to tweak the code to better

Keep in mind that the LTS are still comparatively new in the timescales people work within and that we have changed and defined a new policy comparatively recently. A large portion of this is a social

Taking something like Dunfell where it was originally for two years, then was extended you could end up with the date not agreeing with the reality in some checkouts if they weren't updated. There is

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 type

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

meta-gplv2 makes the TSCs very nervous (certainly YP and I believe OE TSC people too although it hasn't had an official discussion there). It has a load of old "pre GPLv3 license" versions of software

I've been thinking about this and also talking with Michael Halstead about what makes sense from a mirror/server perspective. Going forward we going to rename sstate.yoctoproject.org/dev/ to sstate.yo

It isn't that rare, there are 42 in OE-Core alone. I do think we should probably migrate away from those though. Cheers, Richard

The question is what level of changes are we prepared to accept to recipes? If we don't want to set S for git, where would we accept setting things? Or do we want to make it all "magic"? The one thing

I've gone around in circles on this for a long time. The background isn't obvious at first glance. "S" represents where our source is. There is code like do_unpack which wants to clean S before rerunn

I've been worrying about license and copyright information in our codebase for a while. We're slowly getting there with license info and scripts have good information now. We still need to work out li

I've been asked about my thoughts on the eSDK. I'm going to try and write down some of my ideas and thinking about it. I don't have a fully thought out plan to pull off the shelf but can at least shar