Hello all, I just read this article, called "Supporting Linux kernel development in Rust" https://lwn.net/Articles/829858/ and it looks like the future is set, and particularly the Yocto project

Ah, OK. Yes, we're using "user" networking not tap. Sorry, what I meant by hand-crafted is that for it to work for older installs, you have to have this particular dance to provide various

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

Which issues do you run in to with qemu networking? I honestly don't know if the U-Boot networking tests we run via qemu under Docker are more or less complex than what you're running in to. The

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

Excuse what may be a dumb question, but why are we not just building pyro for example in a Ubuntu 16.04 or centos7 (or anything else with official containers available) ? Is the performance hit too

Hello all, Em seg., 7 de set. de 2020 às 13:14, Richard Purdie <richard.purdie@...> escreveu: I second this and at least at O.S. Systems we've been using Docker containers to keep

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

Devuan has also been testing in support of multiple init systems, which should improve upstream package readiness. So far they have: - sysvinit - openrc -

<richard.purdie@...> wrote: init systems are quite taxing and intrusive to implement and hence I agree with testing complexity increase and in general higher maintenance work.

<richard.purdie@...> wrote: This does exist in https://github.com/jsbronder/meta-openrc, I haven't tested it myself though. -- Paul Barker Konsulko Group

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

Hi, Currently we have the option to choose either sysvinit or systemd . Would, at some point, openrc be included in this list of options to choose from? Jagdish

Just a reminder about our upcoming OpenEmbedded Happy Hour on July 29 for Oceania/Asia timezones @ 2100/9pm UTC (5pm

Thanks for making this available! Would backward compatibility (e.g. via buildtools-extended-tarball) be covered by the "Other future topics" section on multiple toolchains? Is it worth adding

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 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

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

Relevant discussion from #oe I forgot to include: [2020-07-20 18:22:44] <khem> paulbarker: why do you want to lockdown gh pulls ? is there a better way [2020-07-20 18:23:18] <khem> often times people

Hi folks, I took a look at our mirrored repositories on GitHub under https://github.com/openembedded and considered the experience of new potential contributors and others from outside our project