Bruce Ashfield <[email protected]> escreveu no dia quinta,
30/03/2023 à(s) 16:14:

> On Thu, Mar 30, 2023 at 10:41 AM Jose Quaresma <[email protected]>
> wrote:
> >
> > 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?
> >
>
> I'm not sure I follow which approach you are referring to ?
>
> Tweaking the busybox-initrd and adding your own compatibility tag to
> the meta-virt branch you are matching (in this case master) ?
>

Yes, this is the only thing that breaks the bitbake parsing when using the
meta-virt master branch with oe-core kirkstone.


>
> If it works, I don't see any issues with it. I wouldn't carry such a
> layerseries_compat update in the layer itself, since additional layers
> are required to make it work.
>

The layer compat is the tricky one but can be solved in any other global
config file.


>
> I'm also still willing to carry multiple versions of recipes in
> maintained release branches (and set the preferred version to be the
> existing recipe), if we need to get a newer version of a recipe in a
> release branch to match both security and golang requirements.
>

This with the meta-lts-mixins will add a lot of flexibility.
I will do that in meta-virt, backporting some recipes from master to
kirstone.

Jose


>
> Bruce
>
> > 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
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>


-- 
Best regards,

José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59568): https://lists.yoctoproject.org/g/yocto/message/59568
Mute This Topic: https://lists.yoctoproject.org/mt/97946990/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to