|
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?
|
|
|
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
toggle quoted message
Show quoted text
On Thu, 30 Mar 2023 at 11:20, Jose Quaresma <quaresma.jose@...> 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
|
|
|
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%2C97444547Best 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 <quaresma.jose@...>
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
|
|
|
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
toggle quoted message
Show quoted text
On Thu, 30 Mar 2023 at 15:15, <adrian.freihofer@...> 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 <quaresma.jose@...>
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
|
|
|
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 < alex.kanavin@...> 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, <adrian.freihofer@...> 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 <quaresma.jose@...>
> > 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
|
|
|
On Thu, Mar 30, 2023 at 10:41 AM Jose Quaresma <quaresma.jose@...> 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) ? 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. 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. Bruce Jose
Alexander Kanavin <alex.kanavin@...> 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, <adrian.freihofer@...> 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 <quaresma.jose@...>
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
|
|
|
On Thu, Mar 30, 2023 at 10:41 AM Jose Quaresma <quaresma.jose@...> 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 <alex.kanavin@...> 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, <adrian.freihofer@...> 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 <quaresma.jose@...>
>> > > 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
|
|
|
Alexander Kanavin < alex.kanavin@...> escreveu no dia quinta, 30/03/2023 à(s) 11:08:
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 <quaresma.jose@...> 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
|
|
|
toggle quoted message
Show quoted text
On Fri, 31 Mar 2023 at 18:15, Jose Quaresma <quaresma.jose@...> wrote:
Hi Alex,
I don't have any account/keys that allow me to push directly git.yoctoproject.org
maybe I need to setup my keys somewhere like with poky-contrib [1]
I will send all the patches to the yocto mailing list as recommended.
[1] https://wiki.yoctoproject.org/wiki/Poky_Contributions
Jose
Alexander Kanavin <alex.kanavin@...> escreveu no dia quinta, 30/03/2023 à(s) 11:08:
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 <quaresma.jose@...> 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
|
|
|
Alexander Kanavin < alex.kanavin@...> escreveu no dia sexta, 31/03/2023 à(s) 18:49:
You need to send your public ssh key to Michael (cc) and explain what
access should be granted with that (which repo, which branch(es)).
In this case,
https://git.yoctoproject.org/meta-lts-mixins/
kirkstone/go
Alex
On Fri, 31 Mar 2023 at 18:15, Jose Quaresma <quaresma.jose@...> wrote:
>
> Hi Alex,
>
> I don't have any account/keys that allow me to push directly git.yoctoproject.org
> maybe I need to setup my keys somewhere like with poky-contrib [1]
>
> I will send all the patches to the yocto mailing list as recommended.
>
> [1] https://wiki.yoctoproject.org/wiki/Poky_Contributions
>
> Jose
>
> Alexander Kanavin <alex.kanavin@...> escreveu no dia quinta, 30/03/2023 à(s) 11:08:
>>
>> 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 <quaresma.jose@...> 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
-- Best regards,
José Quaresma
|
|
|
