Hi, I already did some tests using the meta-virt master branch with the oe-core kirkstone and this version of the meta-lts-mixins. Our stack on meta-virt is not very big but what I tested looks good.
On meta-virt I only need to add kirk compatibility: LAYERSERIES_COMPAT_virtualization-layer += "kirkstone" On meta-lts-mixins I need to change the meta-virt busybox oe-core tracked version: PV:pn-busybox-initrd = "1.35.0" But maybe I need to test this with a large set of recipes in the meta-virt master branch. I will add Bruce and I take the opportunity to ask him what he thinks of this approach? Jose Alexander Kanavin <[email protected]> escreveu no dia quinta, 30/03/2023 à(s) 14:42: > That may require an unknown amount of fixing in the recipes and > classes. Existing code is not designed for co-existing with a > different version of itself, and so everything needs to be versioned > and cleanly separated. But in theory it's possible. > > Alex > > On Thu, 30 Mar 2023 at 15:15, <[email protected]> wrote: > > > > Hi Alex, hi José > > > > The meta-lts-mixin layers for dunfell have a major disadvantage: > > Replacing the go tool-chain breaks more or less all recipes from meta- > > virtualization and potentially other layers. > > > > I think with go it should be possible to have a meta-lts-mixin layer > > which adds support for additional go versions instead of overriding the > > version provided by poky. That would potentially allow to use poky on > > the kirkstone branch and meta-virtualization on a newer branch on the > > long run. > > > > Would it be possible to add e.g. a copy of the go.bbclass as well as > > the go recipes from a recent poky version in a way it does not override > > the go stack provided by poky? > > As an example: Would it be possible to add a go1-19.bbclass to the > > meta-meta-lts-mixin layer? This would allow to add also a newer Docker > > recipe which inherits go1-19 instead of just go to the meta-lts-mixin > > layers without breaking anything from poky or meta-virtualization. > > > > I already tried to share my thoughts here: > > > https://lists.openembedded.org/g/openembedded-core/message/178146?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Cgolang%2C20%2C2%2C0%2C97444547 > > > > Best regards, > > Adrian > > > > > > On Thu, 2023-03-30 at 12:08 +0200, Alexander Kanavin wrote: > > > I think I pushed the work directly to the respecitve branches in > > > meta-lts-mixins. I'd suggest you send the patches here, and we'll > > > sort > > > out the technicalities (I can publish the branch on > > > git.yoctoproject.org, or maybe you'll be able to push directly as > > > well, provided you also send the patches here). There's no > > > autobuilder > > > testing; for mixin items the contributors are trusted :) > > > > > > Alex > > > > > > > > > On Thu, 30 Mar 2023 at 11:20, Jose Quaresma <[email protected]> > > > wrote: > > > > > > > > Hi, > > > > > > > > The golang version in kirkstone is the 1.17 and because of this is > > > > not possible to use some recent version of other projects like > > > > docker that requires a more recent version of the language. > > > > > > > > I have a kirkstone branch [1] available at Foundries.io with the > > > > golang backported from the oe-core master that I liked to submit to > > > > the meta-lts-mixins [2]. > > > > Alex is the maintainer of the dunfell golang backport and this > > > > kirkstone branch is based on that version. > > > > > > > > Would that be interesting for the project? How should I proceed? > > > > > > > > [1] > > > > https://github.com/foundriesio/meta-lts-mixins/tree/kirkstone/go > > > > [2] https://git.yoctoproject.org/meta-lts-mixins > > > > > > > > Jose > > > > > > > > -- > > > > Best regards, > > > > > > > > José Quaresma > > > > > > > > > > > > -- Best regards, José Quaresma
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#59551): https://lists.yoctoproject.org/g/yocto/message/59551 Mute This Topic: https://lists.yoctoproject.org/mt/97946990/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
