Was there a patch applied? Cheers, Richard

This has been talked about a lot but there is work to be done to get this into core. Not many people seem willing to step up and do that work so progress has been slow. The hardest part may be getting

Its the tun/tap device requirement that tends to be the pain point. Being able to ssh from the host OS into the qemu target image is a central requirement of oeqa. Everyone tells me it should use port

The autobuilder is setup for speed so there aren't VMs involved, its 'baremetal'. Containers would be possible but at that point the kernel isn't the distro kernel and you have permission issues with

I wanted to write down my findings on trying to getting and keeping stable branch builds working on the autobuilder. I also have a proposal in mind for moving this forward. Jeremy did good work in get

It comes down to the demand for it, whether there are people willing the maintain it, how much of the system its planned to support and so on. It has implications for the testing matrix for example. T

Hi, The YP TSC has been discussing the topic of future development directions for a while. We're written up a summary of those onto the wiki: https://wiki.yoctoproject.org/wiki/Future_Directions These

The OE TSC recognises there are issues related to inclusive language which the project needs to address and that we need a plan for doing so moving forward. It is unclear how much change the project m

Hi Paul, The OE TSC had a meeting today and discussed this, we agreed it seemed like a reasonable idea in principle and that you could go ahead and set it up as it should be better than the current ex

Yes, there are specific mailing lists and meetings the members have. Philip represents OE at those meetings. I believe this matter falls under the remit of the YP TSC. If the members want to represent

To be really clear, whilst you keep saying this, I have heard of no such plans from the LF and I have asked. Yes, the LF is a strong believer in diversity and does take these issues seriously but as I

Thanks for bringing this up and writing a summary. The OE and YP TSCs are aware of this and are starting to have discussions about it. I have also been looking at what other projects and the Linux Fou

The fetcher is strict about which branch the SHA1 is on. There were good reasons we started enforcing that, I have to admit I don't remember the reasons offhand. Its that which is tripping things up t

A number of upstream git repos we build from are transitioning "master" branches to "main" branches. They're doing this and removing the old name. The scale of the problem this causes us is only just

Presumable this would behave like ??= though (?= as implemented is fairly flawed but so is ??= today, sadly). I have to admit if I was implementing layers again, I'd want to ditch a load of the older

Yes, I think we're talking about the same thing, its just a different way of thinking about it. I'm adding the challenge of trying to figure out what changes to existing behaviour we could consider to

I agree, having +=/=+ and friends operating against the default value would in general be the behaviour most people want/expect. The change in behaviour would be that "=" would no longer wipe out prev

I'm growing increasingly concerned about default value assignments in OE. The basic problem is people don't understand the way default values work and the mechanisms we do have don't let people do all

Hi, Back in 2009, regex support was added in ASSUME_PROVIDED: https://git.openembedded.org/bitbake/commit/lib/bb/taskdata.py?id=efb0474231ed286073a5a5904094320da8cab28d Looking at this now, I'm thinki

I do not want or expect to see a lot of these requests. The TSC is there as a final decision making authority in general so I'm not sure we need to explicitly document that. Cheers, Richard