[meta-virtualization][PATCH] classes/image-oci: Map x86_64 -> amd64

[meta-virtualization][PATCH] classes/image-oci: Map x86_64 -> amd64

[Joshua Watt]

OCI requires that the architecture [1] be a valid GOARCH [2]. "x86_64"
is not a valid GOARCH so map it to the correct "amd64" value.

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>

[1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties
[2]: https://go.dev/doc/install/source#environment

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
 classes/image-oci.bbclass | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
index 9ddb88b..3370f86 100644
--- a/classes/image-oci.bbclass
+++ b/classes/image-oci.bbclass
@@ -52,7 +52,7 @@ OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
 OCI_IMAGE_TAG ?= "latest"
 OCI_IMAGE_RUNTIME_UID ?= ""
 
-OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
+OCI_IMAGE_ARCH ?= "${@oci_map_arch(d.getVar('TARGET_ARCH'))}"
 OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
 
 OCI_IMAGE_ENTRYPOINT ?= "sh"
@@ -74,6 +74,13 @@ OCI_IMAGE_ENV_VARS ?= ""
 # bundled into a tarball.
 OCI_IMAGE_TAR_OUTPUT ?= "true"
 
+# Map architectures to a valid container arch. Note that the container archs
+# should be a valid GOARCH
+def oci_map_arch(a):
+    if a == "x86_64":
+        return "amd64"
+    return a
+
 # Generate a subarch that is appropriate to OCI image
 # types. This is typically only ARM architectures at the
 # moment.
-- 
2.34.1

Re: [meta-virtualization][PATCH] classes/image-oci: Map x86_64 -> amd64

[Bruce Ashfield]

On Mon, Oct 16, 2023 at 5:26 PM Joshua Watt <JPEWhacker@gmail.com> wrote:
>
> OCI requires that the architecture [1] be a valid GOARCH [2]. "x86_64"
> is not a valid GOARCH so map it to the correct "amd64" value.
>

It may require it, but I've never had any issues with a container running.

Are you seeing a warning or something else ?

> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
>
> [1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties
> [2]: https://go.dev/doc/install/source#environment
>
> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> ---
>  classes/image-oci.bbclass | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
> index 9ddb88b..3370f86 100644
> --- a/classes/image-oci.bbclass
> +++ b/classes/image-oci.bbclass
> @@ -52,7 +52,7 @@ OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
>  OCI_IMAGE_TAG ?= "latest"
>  OCI_IMAGE_RUNTIME_UID ?= ""
>
> -OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
> +OCI_IMAGE_ARCH ?= "${@oci_map_arch(d.getVar('TARGET_ARCH'))}"
>  OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
>
>  OCI_IMAGE_ENTRYPOINT ?= "sh"
> @@ -74,6 +74,13 @@ OCI_IMAGE_ENV_VARS ?= ""
>  # bundled into a tarball.
>  OCI_IMAGE_TAR_OUTPUT ?= "true"
>
> +# Map architectures to a valid container arch. Note that the container archs
> +# should be a valid GOARCH
> +def oci_map_arch(a):
> +    if a == "x86_64":
> +        return "amd64"
> +    return a

If it is supposed to match to the goarch, why wouldn't we just use the
goarch.bbclass mapping ?

Bruce

> +
>  # Generate a subarch that is appropriate to OCI image
>  # types. This is typically only ARM architectures at the
>  # moment.
> --
> 2.34.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#8376): https://lists.yoctoproject.org/g/meta-virtualization/message/8376
> Mute This Topic: https://lists.yoctoproject.org/mt/102006091/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization][PATCH] classes/image-oci: Map x86_64 -> amd64

[Joshua Watt]

On Mon, Oct 16, 2023 at 7:35 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Mon, Oct 16, 2023 at 5:26 PM Joshua Watt <JPEWhacker@gmail.com> wrote:
> >
> > OCI requires that the architecture [1] be a valid GOARCH [2]. "x86_64"
> > is not a valid GOARCH so map it to the correct "amd64" value.
> >
>
> It may require it, but I've never had any issues with a container running.
>
> Are you seeing a warning or something else ?

I haven't, but I noticed it was wrong

>
> > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> >
> > [1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties
> > [2]: https://go.dev/doc/install/source#environment
> >
> > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > ---
> >  classes/image-oci.bbclass | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
> > index 9ddb88b..3370f86 100644
> > --- a/classes/image-oci.bbclass
> > +++ b/classes/image-oci.bbclass
> > @@ -52,7 +52,7 @@ OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
> >  OCI_IMAGE_TAG ?= "latest"
> >  OCI_IMAGE_RUNTIME_UID ?= ""
> >
> > -OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
> > +OCI_IMAGE_ARCH ?= "${@oci_map_arch(d.getVar('TARGET_ARCH'))}"
> >  OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
> >
> >  OCI_IMAGE_ENTRYPOINT ?= "sh"
> > @@ -74,6 +74,13 @@ OCI_IMAGE_ENV_VARS ?= ""
> >  # bundled into a tarball.
> >  OCI_IMAGE_TAR_OUTPUT ?= "true"
> >
> > +# Map architectures to a valid container arch. Note that the container archs
> > +# should be a valid GOARCH
> > +def oci_map_arch(a):
> > +    if a == "x86_64":
> > +        return "amd64"
> > +    return a
>
> If it is supposed to match to the goarch, why wouldn't we just use the
> goarch.bbclass mapping ?

Ah, that's a good idea. I think I'll move those functions to library
code though so that they can be used without the bbclass.

Thanks

>
> Bruce
>
> > +
> >  # Generate a subarch that is appropriate to OCI image
> >  # types. This is typically only ARM architectures at the
> >  # moment.
> > --
> > 2.34.1
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#8378): https://lists.yoctoproject.org/g/meta-virtualization/message/8378
> Mute This Topic: https://lists.yoctoproject.org/mt/102006091/3616693
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/leave/12677403/3616693/1765413136/xyzzy [JPEWhacker@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [meta-virtualization][PATCH] classes/image-oci: Map x86_64 -> amd64

[Bruce Ashfield]

On Tue, Oct 17, 2023 at 9:46 AM Joshua Watt <jpewhacker@gmail.com> wrote:
>
> On Mon, Oct 16, 2023 at 7:35 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >
> > On Mon, Oct 16, 2023 at 5:26 PM Joshua Watt <JPEWhacker@gmail.com> wrote:
> > >
> > > OCI requires that the architecture [1] be a valid GOARCH [2]. "x86_64"
> > > is not a valid GOARCH so map it to the correct "amd64" value.
> > >
> >
> > It may require it, but I've never had any issues with a container running.
> >
> > Are you seeing a warning or something else ?
>
> I haven't, but I noticed it was wrong

Fair enough. I just always want to document any runtime issues that
were seen, since if for example, you weren't able to launch on x86-64
or were getting a runtime warning ... I wonder why I didn't pick it up
in my testing.

>
> >
> > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > >
> > > [1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties
> > > [2]: https://go.dev/doc/install/source#environment
> > >
> > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > > ---
> > >  classes/image-oci.bbclass | 9 ++++++++-
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
> > > index 9ddb88b..3370f86 100644
> > > --- a/classes/image-oci.bbclass
> > > +++ b/classes/image-oci.bbclass
> > > @@ -52,7 +52,7 @@ OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
> > >  OCI_IMAGE_TAG ?= "latest"
> > >  OCI_IMAGE_RUNTIME_UID ?= ""
> > >
> > > -OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
> > > +OCI_IMAGE_ARCH ?= "${@oci_map_arch(d.getVar('TARGET_ARCH'))}"
> > >  OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
> > >
> > >  OCI_IMAGE_ENTRYPOINT ?= "sh"
> > > @@ -74,6 +74,13 @@ OCI_IMAGE_ENV_VARS ?= ""
> > >  # bundled into a tarball.
> > >  OCI_IMAGE_TAR_OUTPUT ?= "true"
> > >
> > > +# Map architectures to a valid container arch. Note that the container archs
> > > +# should be a valid GOARCH
> > > +def oci_map_arch(a):
> > > +    if a == "x86_64":
> > > +        return "amd64"
> > > +    return a
> >
> > If it is supposed to match to the goarch, why wouldn't we just use the
> > goarch.bbclass mapping ?
>
> Ah, that's a good idea. I think I'll move those functions to library
> code though so that they can be used without the bbclass.
>

perfect. I'll wait for v2, and ponder the other pending patches in the meantime.

Bruce

> Thanks
>
> >
> > Bruce
> >
> > > +
> > >  # Generate a subarch that is appropriate to OCI image
> > >  # types. This is typically only ARM architectures at the
> > >  # moment.
> > > --
> > > 2.34.1
> > >
> > >
> > >
> > >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#8378): https://lists.yoctoproject.org/g/meta-virtualization/message/8378
> > Mute This Topic: https://lists.yoctoproject.org/mt/102006091/3616693
> > Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> > Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/leave/12677403/3616693/1765413136/xyzzy [JPEWhacker@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

[meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Joshua Watt]

OCI requires that the architecture [1] be a valid GOARCH [2]. To
correctly perform this mapping, use the go library code from OE core.

[1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties
[2]: https://go.dev/doc/install/source#environment

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
 classes/image-oci.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
index 9ddb88b..0ec5c48 100644
--- a/classes/image-oci.bbclass
+++ b/classes/image-oci.bbclass
@@ -52,7 +52,7 @@ OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
 OCI_IMAGE_TAG ?= "latest"
 OCI_IMAGE_RUNTIME_UID ?= ""
 
-OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
+OCI_IMAGE_ARCH ?= "${@oe.go.map_arch(d.getVar('TARGET_ARCH'))}"
 OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
 
 OCI_IMAGE_ENTRYPOINT ?= "sh"
-- 
2.34.1

Re: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Bruce Ashfield]

merged to master-next

With any luck, I'll complete my release testing and master-next
will become master shortly

Bruce

In message: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly
on 30/10/2023 Joshua Watt wrote:

> OCI requires that the architecture [1] be a valid GOARCH [2]. To
> correctly perform this mapping, use the go library code from OE core.
> 
> [1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties
> [2]: https://go.dev/doc/install/source#environment
> 
> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> ---
>  classes/image-oci.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
> index 9ddb88b..0ec5c48 100644
> --- a/classes/image-oci.bbclass
> +++ b/classes/image-oci.bbclass
> @@ -52,7 +52,7 @@ OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
>  OCI_IMAGE_TAG ?= "latest"
>  OCI_IMAGE_RUNTIME_UID ?= ""
>  
> -OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
> +OCI_IMAGE_ARCH ?= "${@oe.go.map_arch(d.getVar('TARGET_ARCH'))}"
>  OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
>  
>  OCI_IMAGE_ENTRYPOINT ?= "sh"
> -- 
> 2.34.1
> 

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#8408): https://lists.yoctoproject.org/g/meta-virtualization/message/8408
> Mute This Topic: https://lists.yoctoproject.org/mt/102282594/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Ross Burton]

This patch depends on changes in oe-core master, but as there is no nanbield branch of meta-virtualisation at present it’s not possible to use meta-virt with nanbield anymore.

Can this either be reverted, or a branch created?

Ross

Re: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Bruce Ashfield]

I'll do both: branch and revert there.

But to anyone reading this .. the release of meta-virtualization
against nanbeild is still weeks away, there will be changes and a few
more upgrades in that branch yet.

I mistakenly assumed the mapping change had made it into nanbield.

Bruce

On Tue, Nov 7, 2023 at 5:37 AM Ross Burton <Ross.Burton@arm.com> wrote:
>
> This patch depends on changes in oe-core master, but as there is no nanbield branch of meta-virtualisation at present it’s not possible to use meta-virt with nanbield anymore.
>
> Can this either be reverted, or a branch created?
>
> Ross



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Ross Burton]

On 7 Nov 2023, at 13:00, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> 
> I'll do both: branch and revert there.

Sounds sensible, thanks.

Ross

Re: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Bruce Ashfield]

On Tue, Nov 7, 2023 at 9:51 AM Ross Burton <Ross.Burton@arm.com> wrote:
>
> On 7 Nov 2023, at 13:00, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >
> > I'll do both: branch and revert there.
>
> Sounds sensible, thanks.
>

As it turned out, reverting would of course leave the issue unfixed
that Joshua was addressing.

So I copied the mapping routine into the class and did a nanbield
specific commit.

Bruce

> Ross



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization][PATCH v2] classes/image-oci: Map image architecture correctly

[Joshua Watt]

On Tue, Nov 7, 2023 at 8:31 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Tue, Nov 7, 2023 at 9:51 AM Ross Burton <Ross.Burton@arm.com> wrote:
> >
> > On 7 Nov 2023, at 13:00, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > >
> > > I'll do both: branch and revert there.
> >
> > Sounds sensible, thanks.
> >
>
> As it turned out, reverting would of course leave the issue unfixed
> that Joshua was addressing.
>
> So I copied the mapping routine into the class and did a nanbield
> specific commit.

Thanks Bruce!

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