Hi All, We'd like to get the first 3.1 point release Dunfell LTS out soon. There is one issue we need to resolve first. meta-arm has recently been established and the hope is to avoid duplication of a

You can argue this both ways. I think these *should* be differentiated from "normal" layers in that they're specific shims designed with one specific purpose for one specific LTS. I'm not 100% sure th

Right, there are ways some of these could (and probably should) be avoided. I guess the question is whether there is some kind of syntax or bitbake functionality which could improve the situation. Nic

vialists.openembedded.org wrote: At a quick count, 64 usages in core sadly: meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb:PACKAGECONFIG_remove_libc-musl = "tcp-wrappers" meta/recipes-connecti

Back then, people were quite upset when changes made to the default DISTRO_FEATURES changed their builds in ways they didn't opt in to. The options were either a) never change DISTRO_FEATURES or b) ad

There was a little bad timing and after the TSC was asked to do this, Armin stepped forward to maintain dunfell but the TSC didn't realise. Thanks Armin! Cheers, Richard

The OE TSC would like to ask if there is anyone interested in stepping up to look after the dunfell branch of meta-openembedded? dunfell is an LTS release for Yocto Project and it would be good to hav

I agree we do need to do something and it was briefly discussed by the YP TSC who basically agreed we need to tweak things. Firstly though, we could do with digging out Ross' original emails and prope

lists.openembedded.org wrote: The project historically supports setting "libdir" and "base_libdir" to whatever the user sets it to. This includes the paths to the dynamic loaders. In the past, if base

Not that I see at the moment. Only for native/nativesdk/multiconfig (anything using the class extension code). Cheers, Richard

I think that is a sensible idea. The good news is we know roughly what the current needs look like, the code is in lib/oe/classextend.py: def extend_name(self, name): if name.startswith("kernel-") or

Right, mixing them definitely gives the worst possible behaviours. Sadly we have recipes doing this today, with unpredictable side effects. We have always said we don't support this but it does mostly

I'm a bit worried about some of the mulitlib issues we've seen recently. In particular we have a bug where license exclusion doesn't work properly in multilib builds, which is fairly serious. To dive

We still have one debian8 autobuilder worker: https://autobuilder.yoctoproject.org/typhoon/#/workers/9 and with buildtools tarball it works 'fine'. Cheers, Richard

Hi, I just wanted to mention that we now have the ability to wrap builds on specific workers with specific buildtools tarballs. Currently this functionality is in master, we do have the option of port

That isn't true. If you fix something yourself and hold the change you get to maintain it. If you work with upstream you can share the maintenance burden with the community going forward. That is a di

Its posted at: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ but I'll copy it below since this is an important announcement """ To fulfill the evolving requirements of its me

Hi Alex, Thanks for bringing this up. X.Org is definitely going to be shrinking market share going forwards. That said its going to take a few years for this to happen, its not going to be gone in 6 o

The trouble is I very much doubt anyone is going to setup a copy of the autobuilder to test community supported releases. This implies the community branches have to use the autobuilder to run the tes

The aim is to get to a point where changes merge regularly onto the stable branches in a matter of days in a similar way to the way master works (in theory anyway!). I'd also like to see the release p