public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
* SSTATE cache not working for -native recipes due to unexpanded variable
@ 2023-10-03 13:30 Waltl, Jan
  2023-10-03 15:41 ` Uladzimir Bely
  0 siblings, 1 reply; 5+ messages in thread
From: Waltl, Jan @ 2023-10-03 13:30 UTC (permalink / raw)
  To: isar-users

Hello,

I noticed that for -native recipes, SSTATE_PKGARCH variable is not expanded in the .siginfo filename. On rebuild, SSTATE reports mismatches leading to rebuilds even though the recipe and the resulting stamps are exactly the same.

Reproduction steps:
1. Checkout ISAR next 216f0721265fcfe965ac48b51a0128d612d89bf4.
2. Run 'bitbake cowsay-native' from meta-isar layer  (I use KAS for setting up the bitbake directory)
4. Look into sstate directory, I see a files:
sstate-cache/31/1a/sstate:cowsay-native::git:r0::10:311a86032fcbd98d2343b40447e0558b5aae410ff64f727ae56aa2952167f05e_patch.tar.zst.siginfo
sstate-cache/3b/24/sstate:cowsay-native::git:r0::10:3b2452fa0b072ed1488aad9432257dff8bee324659b5f0738ab224d82b1de2fc_unpack.tar.zst.siginfo
sstate-cache/d6/ab/sstate:cowsay-native::git:r0::10:d6abcc3328b93b67b59ef9c0b21449188f1330bc76d6ee6372c76e94bec87756_fetch.tar.zst.siginfo
sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-isar:git:r0:${SSTATE_PKGARCH}:10:64de5a007fac75eebd427a2ea9156cf0142718f68362a06b51c65559fc8045b7_dpkg_build.tar.zst.siginfo'
sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-isar:git:r0::10:64de5a007fac75eebd427a2ea9156cf0142718f68362a06b51c65559fc8045b7_dpkg_build.tar.zst
sstate-cache/isarnative/aa/07/sstate:cowsay-native:amd64-isar:git:r0:${SSTATE_PKGARCH}:10:aa07cf2e6ff17f7004e6dc2b4e7a9a6123b127668c27d4c3cb29d0f7dc65ac5f_deploy_deb.tar.zst.siginfo'
sstate-cache/isarnative/c4/db/sstate:cowsay-native:amd64-isar:git:r0:${SSTATE_PKGARCH}:10:c4dbfbe1c1696f2b690f15cbd179a5795fe48f05a30a76d20783c98786af6d4a_adjust_git.tar.zst.siginfo'
sstate-cache/isarnative/d0/0c/sstate:cowsay-native:amd64-isar:git:r0:${SSTATE_PKGARCH}:10:d00c69fa102b131bc09fb27aa8259fcb447dbe5b51d5f6723d1e12ff43f92fee_transform_template.tar.zst.siginfo'
sstate-cache/isarnative/e7/94/sstate:cowsay-native:amd64-isar:git:r0:${SSTATE_PKGARCH}:10:e794e52fe10ccf60b559089c39eaf86a4990a81991c9b1b0b2672721878a1b8b_prepare_build.tar.zst.siginfo'

5. Remove stamps directory.
6. Build again - SSTATE should be used for the package but it is not and the tasks are run again.

I think it is related to https://github.com/ilbers/isar/blob/61086915e6c83fff22effa85cda64a2ac0c2f100/meta/classes/sstate.bbclass#L136 and BUILD_ARCH being empty according to 'bitbake -e'. 

I changed the line to HOST_ARCH (+expand=True) which seems to work but I do not have enough expertise to guess its correctness. Maybe the line in native.bbclass covers this "if statement" already?

How to best resolve this?


[This is my first message to this mailing list, please correct me if I am doing something wrong]


Kind Regards,
Jan Waltl

Siemens Mobility, s.r.o.
SMO RI LCE CZ SAF 1




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SSTATE cache not working for -native recipes due to unexpanded variable
  2023-10-03 13:30 SSTATE cache not working for -native recipes due to unexpanded variable Waltl, Jan
@ 2023-10-03 15:41 ` Uladzimir Bely
  2023-10-06  7:59   ` Waltl, Jan
  0 siblings, 1 reply; 5+ messages in thread
From: Uladzimir Bely @ 2023-10-03 15:41 UTC (permalink / raw)
  To: Waltl, Jan, isar-users

On Tue, 2023-10-03 at 13:30 +0000, 'Waltl, Jan' via isar-users wrote:
> Hello,
> 
> I noticed that for -native recipes, SSTATE_PKGARCH variable is not
> expanded in the .siginfo filename. On rebuild, SSTATE reports
> mismatches leading to rebuilds even though the recipe and the
> resulting stamps are exactly the same.
> 
> Reproduction steps:
> 1. Checkout ISAR next 216f0721265fcfe965ac48b51a0128d612d89bf4.
> 2. Run 'bitbake cowsay-native' from meta-isar layer  (I use KAS for
> setting up the bitbake directory)
> 4. Look into sstate directory, I see a files:
> sstate-cache/31/1a/sstate:cowsay-
> native::git:r0::10:311a86032fcbd98d2343b40447e0558b5aae410ff64f727ae5
> 6aa2952167f05e_patch.tar.zst.siginfo
> sstate-cache/3b/24/sstate:cowsay-
> native::git:r0::10:3b2452fa0b072ed1488aad9432257dff8bee324659b5f0738a
> b224d82b1de2fc_unpack.tar.zst.siginfo
> sstate-cache/d6/ab/sstate:cowsay-
> native::git:r0::10:d6abcc3328b93b67b59ef9c0b21449188f1330bc76d6ee6372
> c76e94bec87756_fetch.tar.zst.siginfo
> sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:64de5a007fac75eebd427a2ea9156cf01427
> 18f68362a06b51c65559fc8045b7_dpkg_build.tar.zst.siginfo'
> sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-
> isar:git:r0::10:64de5a007fac75eebd427a2ea9156cf0142718f68362a06b51c65
> 559fc8045b7_dpkg_build.tar.zst
> sstate-cache/isarnative/aa/07/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:aa07cf2e6ff17f7004e6dc2b4e7a9a6123b1
> 27668c27d4c3cb29d0f7dc65ac5f_deploy_deb.tar.zst.siginfo'
> sstate-cache/isarnative/c4/db/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:c4dbfbe1c1696f2b690f15cbd179a5795fe4
> 8f05a30a76d20783c98786af6d4a_adjust_git.tar.zst.siginfo'
> sstate-cache/isarnative/d0/0c/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:d00c69fa102b131bc09fb27aa8259fcb447d
> be5b51d5f6723d1e12ff43f92fee_transform_template.tar.zst.siginfo'
> sstate-cache/isarnative/e7/94/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:e794e52fe10ccf60b559089c39eaf86a4990
> a81991c9b1b0b2672721878a1b8b_prepare_build.tar.zst.siginfo'
> 
> 5. Remove stamps directory.
> 6. Build again - SSTATE should be used for the package but it is not
> and the tasks are run again.
> 
> I think it is related to
> https://github.com/ilbers/isar/blob/61086915e6c83fff22effa85cda64a2ac0c2f100/meta/classes/sstate.bbclass#L136
>  and BUILD_ARCH being empty according to 'bitbake -e'. 
> 
> I changed the line to HOST_ARCH (+expand=True) which seems to work
> but I do not have enough expertise to guess its correctness. Maybe
> the line in native.bbclass covers this "if statement" already?
> 
> How to best resolve this?
> 
> 
Hello, Jan.

I've tried to repeat your steps and reproduced the issue in case of
cross-building.

Changing the line to HOST_ARCH is techincally correct. But since we
don't like forking (sstate.bbclass is taken from some OE branch without
any changes), I think it would be better to just define BUILD_ARCH
somewhere else in Isar to the value of HOST_ARCH, for example:

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9eb93e2b..0d737b64 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -90,6 +90,7 @@ NATIVELSBSTRING ?= "isarnative"
 TARGET_VENDOR = ""
 TARGET_OS = "isar"
 PACKAGE_ARCH ?= "${DISTRO_ARCH}"
+BUILD_ARCH ?= "${HOST_ARCH}"
 
 # Isar apt repository paths
 REPO_ISAR_DIR = "${DEPLOY_DIR}/isar-apt/${DISTRO}-${DISTRO_ARCH}/apt"

This seems to work and doesn't fork sstate.bbclass, so it can be later
updated to some newer OE revision.

Unfortunately, HOST_ARCH has different meanings in Isar and Yocto...

> [This is my first message to this mailing list, please correct me if
> I am doing something wrong]
> 
> 
> Kind Regards,
> Jan Waltl
> 
> Siemens Mobility, s.r.o.
> SMO RI LCE CZ SAF 1
> 
> 
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: SSTATE cache not working for -native recipes due to unexpanded variable
  2023-10-03 15:41 ` Uladzimir Bely
@ 2023-10-06  7:59   ` Waltl, Jan
  2023-10-07  6:05     ` MOESSBAUER, Felix
  0 siblings, 1 reply; 5+ messages in thread
From: Waltl, Jan @ 2023-10-06  7:59 UTC (permalink / raw)
  To: Uladzimir Bely, isar-users

Hello Uladzimir,

Thank you very, the patch appears to fix the issue for caching of native builds for me - now SSTATE works with them.

Also, I see some related discussions on the mailing list I will try to follow.

Kind Regards
Jan Waltl

Siemens Mobility, s.r.o.
SMO RI LCE CZ SAF 1


-----Original Message-----
From: Uladzimir Bely <ubely@ilbers.de> 
Sent: Tuesday, October 3, 2023 5:41 PM
To: Waltl, Jan (SMO RI LCE CZ SAF 1) <jan.waltl@siemens.com>; isar-users@googlegroups.com
Subject: Re: SSTATE cache not working for -native recipes due to unexpanded variable

On Tue, 2023-10-03 at 13:30 +0000, 'Waltl, Jan' via isar-users wrote:
> Hello,
> 
> I noticed that for -native recipes, SSTATE_PKGARCH variable is not 
> expanded in the .siginfo filename. On rebuild, SSTATE reports 
> mismatches leading to rebuilds even though the recipe and the 
> resulting stamps are exactly the same.
> 
> Reproduction steps:
> 1. Checkout ISAR next 216f0721265fcfe965ac48b51a0128d612d89bf4.
> 2. Run 'bitbake cowsay-native' from meta-isar layer  (I use KAS for 
> setting up the bitbake directory) 4. Look into sstate directory, I see 
> a files:
> sstate-cache/31/1a/sstate:cowsay-
> native::git:r0::10:311a86032fcbd98d2343b40447e0558b5aae410ff64f727ae5
> 6aa2952167f05e_patch.tar.zst.siginfo
> sstate-cache/3b/24/sstate:cowsay-
> native::git:r0::10:3b2452fa0b072ed1488aad9432257dff8bee324659b5f0738a
> b224d82b1de2fc_unpack.tar.zst.siginfo
> sstate-cache/d6/ab/sstate:cowsay-
> native::git:r0::10:d6abcc3328b93b67b59ef9c0b21449188f1330bc76d6ee6372
> c76e94bec87756_fetch.tar.zst.siginfo
> sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:64de5a007fac75eebd427a2ea9156cf01427
> 18f68362a06b51c65559fc8045b7_dpkg_build.tar.zst.siginfo'
> sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-
> isar:git:r0::10:64de5a007fac75eebd427a2ea9156cf0142718f68362a06b51c65
> 559fc8045b7_dpkg_build.tar.zst
> sstate-cache/isarnative/aa/07/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:aa07cf2e6ff17f7004e6dc2b4e7a9a6123b1
> 27668c27d4c3cb29d0f7dc65ac5f_deploy_deb.tar.zst.siginfo'
> sstate-cache/isarnative/c4/db/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:c4dbfbe1c1696f2b690f15cbd179a5795fe4
> 8f05a30a76d20783c98786af6d4a_adjust_git.tar.zst.siginfo'
> sstate-cache/isarnative/d0/0c/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:d00c69fa102b131bc09fb27aa8259fcb447d
> be5b51d5f6723d1e12ff43f92fee_transform_template.tar.zst.siginfo'
> sstate-cache/isarnative/e7/94/sstate:cowsay-native:amd64-
> isar:git:r0:${SSTATE_PKGARCH}:10:e794e52fe10ccf60b559089c39eaf86a4990
> a81991c9b1b0b2672721878a1b8b_prepare_build.tar.zst.siginfo'
> 
> 5. Remove stamps directory.
> 6. Build again - SSTATE should be used for the package but it is not 
> and the tasks are run again.
> 
> I think it is related to
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Filbers%2Fisar%2Fblob%2F61086915e6c83fff22effa85cda64a2ac0c2f1
> 00%2Fmeta%2Fclasses%2Fsstate.bbclass%23L136&data=05%7C01%7Cjan.waltl%4
> 0siemens.com%7C8d77413c796a4920807b08dbc426e043%7C38ae3bcd95794fd4adda
> b42e1495d55a%7C1%7C0%7C638319443476294267%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=GrO630mertcLooKbWBUDIS57z7VppVi1ntvVyayCOs4%3D&reserved
> =0
>  and BUILD_ARCH being empty according to 'bitbake -e'. 
> 
> I changed the line to HOST_ARCH (+expand=True) which seems to work but 
> I do not have enough expertise to guess its correctness. Maybe the 
> line in native.bbclass covers this "if statement" already?
> 
> How to best resolve this?
> 
> 
Hello, Jan.

I've tried to repeat your steps and reproduced the issue in case of cross-building.

Changing the line to HOST_ARCH is techincally correct. But since we don't like forking (sstate.bbclass is taken from some OE branch without any changes), I think it would be better to just define BUILD_ARCH somewhere else in Isar to the value of HOST_ARCH, for example:

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 9eb93e2b..0d737b64 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -90,6 +90,7 @@ NATIVELSBSTRING ?= "isarnative"
 TARGET_VENDOR = ""
 TARGET_OS = "isar"
 PACKAGE_ARCH ?= "${DISTRO_ARCH}"
+BUILD_ARCH ?= "${HOST_ARCH}"
 
 # Isar apt repository paths
 REPO_ISAR_DIR = "${DEPLOY_DIR}/isar-apt/${DISTRO}-${DISTRO_ARCH}/apt"

This seems to work and doesn't fork sstate.bbclass, so it can be later updated to some newer OE revision.

Unfortunately, HOST_ARCH has different meanings in Isar and Yocto...

> [This is my first message to this mailing list, please correct me if I 
> am doing something wrong]
> 
> 
> Kind Regards,
> Jan Waltl
> 
> Siemens Mobility, s.r.o.
> SMO RI LCE CZ SAF 1
> 
> 
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SSTATE cache not working for -native recipes due to unexpanded variable
  2023-10-06  7:59   ` Waltl, Jan
@ 2023-10-07  6:05     ` MOESSBAUER, Felix
  2023-10-07  6:12       ` Jan Kiszka
  0 siblings, 1 reply; 5+ messages in thread
From: MOESSBAUER, Felix @ 2023-10-07  6:05 UTC (permalink / raw)
  To: Waltl, Jan, ubely, isar-users; +Cc: Schmidt, Adriaan

On Fri, 2023-10-06 at 07:59 +0000, 'Waltl, Jan' via isar-users wrote:
> Hello Uladzimir,
> 
> Thank you very, the patch appears to fix the issue for caching of
> native builds for me - now SSTATE works with them.
> 
> Also, I see some related discussions on the mailing list I will try
> to follow.

I guess this is actually related to the inverse meaning of HOST_ARCH
and DISTRO_ARCH in Yocto and GNU / ISAR. By that, I vote for the patch
proposed by Uladzimir.

@Jan: Could you please send this patch to the ML and put Adriaan in CC,
as he implemented most of the sstate parts for ISAR.

Felix


> 
> Kind Regards
> Jan Waltl
> 
> Siemens Mobility, s.r.o.
> SMO RI LCE CZ SAF 1
> 
> 
> -----Original Message-----
> From: Uladzimir Bely <ubely@ilbers.de> 
> Sent: Tuesday, October 3, 2023 5:41 PM
> To: Waltl, Jan (SMO RI LCE CZ SAF 1) <jan.waltl@siemens.com>;
> isar-users@googlegroups.com
> Subject: Re: SSTATE cache not working for -native recipes due to
> unexpanded variable
> 
> On Tue, 2023-10-03 at 13:30 +0000, 'Waltl, Jan' via isar-users wrote:
> > Hello,
> > 
> > I noticed that for -native recipes, SSTATE_PKGARCH variable is not 
> > expanded in the .siginfo filename. On rebuild, SSTATE reports 
> > mismatches leading to rebuilds even though the recipe and the 
> > resulting stamps are exactly the same.
> > 
> > Reproduction steps:
> > 1. Checkout ISAR next 216f0721265fcfe965ac48b51a0128d612d89bf4.
> > 2. Run 'bitbake cowsay-native' from meta-isar layer  (I use KAS for
> > setting up the bitbake directory) 4. Look into sstate directory, I
> > see 
> > a files:
> > sstate-cache/31/1a/sstate:cowsay-
> > native::git:r0::10:311a86032fcbd98d2343b40447e0558b5aae410ff64f727a
> > e5
> > 6aa2952167f05e_patch.tar.zst.siginfo
> > sstate-cache/3b/24/sstate:cowsay-
> > native::git:r0::10:3b2452fa0b072ed1488aad9432257dff8bee324659b5f073
> > 8a
> > b224d82b1de2fc_unpack.tar.zst.siginfo
> > sstate-cache/d6/ab/sstate:cowsay-
> > native::git:r0::10:d6abcc3328b93b67b59ef9c0b21449188f1330bc76d6ee63
> > 72
> > c76e94bec87756_fetch.tar.zst.siginfo
> > sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-
> > isar:git:r0:${SSTATE_PKGARCH}:10:64de5a007fac75eebd427a2ea9156cf014
> > 27
> > 18f68362a06b51c65559fc8045b7_dpkg_build.tar.zst.siginfo'
> > sstate-cache/isarnative/64/de/sstate:cowsay-native:amd64-
> > isar:git:r0::10:64de5a007fac75eebd427a2ea9156cf0142718f68362a06b51c
> > 65
> > 559fc8045b7_dpkg_build.tar.zst
> > sstate-cache/isarnative/aa/07/sstate:cowsay-native:amd64-
> > isar:git:r0:${SSTATE_PKGARCH}:10:aa07cf2e6ff17f7004e6dc2b4e7a9a6123
> > b1
> > 27668c27d4c3cb29d0f7dc65ac5f_deploy_deb.tar.zst.siginfo'
> > sstate-cache/isarnative/c4/db/sstate:cowsay-native:amd64-
> > isar:git:r0:${SSTATE_PKGARCH}:10:c4dbfbe1c1696f2b690f15cbd179a5795f
> > e4
> > 8f05a30a76d20783c98786af6d4a_adjust_git.tar.zst.siginfo'
> > sstate-cache/isarnative/d0/0c/sstate:cowsay-native:amd64-
> > isar:git:r0:${SSTATE_PKGARCH}:10:d00c69fa102b131bc09fb27aa8259fcb44
> > 7d
> > be5b51d5f6723d1e12ff43f92fee_transform_template.tar.zst.siginfo'
> > sstate-cache/isarnative/e7/94/sstate:cowsay-native:amd64-
> > isar:git:r0:${SSTATE_PKGARCH}:10:e794e52fe10ccf60b559089c39eaf86a49
> > 90
> > a81991c9b1b0b2672721878a1b8b_prepare_build.tar.zst.siginfo'
> > 
> > 5. Remove stamps directory.
> > 6. Build again - SSTATE should be used for the package but it is
> > not 
> > and the tasks are run again.
> > 
> > I think it is related to
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Filbers%2Fisar%2Fblob%2F61086915e6c83fff22effa85cda64a2ac0c
> > 2f1
> > 00%2Fmeta%2Fclasses%2Fsstate.bbclass%23L136&data=05%7C01%7Cjan.walt
> > l%4
> > 0siemens.com%7C8d77413c796a4920807b08dbc426e043%7C38ae3bcd95794fd4a
> > dda
> > b42e1495d55a%7C1%7C0%7C638319443476294267%7CUnknown%7CTWFpbGZsb3d8e
> > yJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > 00%
> > 7C%7C%7C&sdata=GrO630mertcLooKbWBUDIS57z7VppVi1ntvVyayCOs4%3D&reser
> > ved
> > =0
> >  and BUILD_ARCH being empty according to 'bitbake -e'. 
> > 
> > I changed the line to HOST_ARCH (+expand=True) which seems to work
> > but 
> > I do not have enough expertise to guess its correctness. Maybe the 
> > line in native.bbclass covers this "if statement" already?
> > 
> > How to best resolve this?
> > 
> > 
> Hello, Jan.
> 
> I've tried to repeat your steps and reproduced the issue in case of
> cross-building.
> 
> Changing the line to HOST_ARCH is techincally correct. But since we
> don't like forking (sstate.bbclass is taken from some OE branch
> without any changes), I think it would be better to just define
> BUILD_ARCH somewhere else in Isar to the value of HOST_ARCH, for
> example:
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index
> 9eb93e2b..0d737b64 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -90,6 +90,7 @@ NATIVELSBSTRING ?= "isarnative"
>  TARGET_VENDOR = ""
>  TARGET_OS = "isar"
>  PACKAGE_ARCH ?= "${DISTRO_ARCH}"
> +BUILD_ARCH ?= "${HOST_ARCH}"
>  
>  # Isar apt repository paths
>  REPO_ISAR_DIR = "${DEPLOY_DIR}/isar-apt/${DISTRO}-
> ${DISTRO_ARCH}/apt"
> 
> This seems to work and doesn't fork sstate.bbclass, so it can be
> later updated to some newer OE revision.
> 
> Unfortunately, HOST_ARCH has different meanings in Isar and Yocto...
> 
> > [This is my first message to this mailing list, please correct me
> > if I 
> > am doing something wrong]
> > 
> > 
> > Kind Regards,
> > Jan Waltl
> > 
> > Siemens Mobility, s.r.o.
> > SMO RI LCE CZ SAF 1
> > 
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SSTATE cache not working for -native recipes due to unexpanded variable
  2023-10-07  6:05     ` MOESSBAUER, Felix
@ 2023-10-07  6:12       ` Jan Kiszka
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2023-10-07  6:12 UTC (permalink / raw)
  To: MOESSBAUER, Felix, Waltl, Jan, ubely, isar-users; +Cc: Schmidt, Adriaan

On 07.10.23 08:05, 'MOESSBAUER, Felix' via isar-users wrote:
> On Fri, 2023-10-06 at 07:59 +0000, 'Waltl, Jan' via isar-users wrote:
>> Hello Uladzimir,
>>
>> Thank you very, the patch appears to fix the issue for caching of
>> native builds for me - now SSTATE works with them.
>>
>> Also, I see some related discussions on the mailing list I will try
>> to follow.
> 
> I guess this is actually related to the inverse meaning of HOST_ARCH
> and DISTRO_ARCH in Yocto and GNU / ISAR. By that, I vote for the patch
> proposed by Uladzimir.
> 
> @Jan: Could you please send this patch to the ML and put Adriaan in CC,
> as he implemented most of the sstate parts for ISAR.

Are you referring to
https://groups.google.com/d/msgid/isar-users/60dba7199afdc8b71494b55081b1193e091b9bde.1696606502.git.jan.kiszka%40siemens.com
?

Jan

-- 
Siemens AG, Technology
Linux Expert Center


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-10-07  6:12 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-03 13:30 SSTATE cache not working for -native recipes due to unexpanded variable Waltl, Jan
2023-10-03 15:41 ` Uladzimir Bely
2023-10-06  7:59   ` Waltl, Jan
2023-10-07  6:05     ` MOESSBAUER, Felix
2023-10-07  6:12       ` Jan Kiszka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox