On Tue, 2022-08-30 at 15:27 -0400, Wes Lindauer wrote:
> I think I understand. I am sorry for the FAD. I was experiencing this
> sstate mismatch on the dunfell branch that does not contain the
> 'XZ_THREADS[vardepvalue] = "1"' change. This is probably why I
> attempted my change in the hash exclude
gt; > To: Quentin Schulz ; Wes Lindauer
> > ; openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core][PATCH] bitbake.conf: Add resource vars to hash
> > ignore list
> >
> > On Mon, 2022-08-22 at 11:28 +0200, Quentin Schulz wrote:
> > > Hi Wes,
&g
][PATCH] bitbake.conf: Add resource vars to hash
> ignore list
>
> On Mon, 2022-08-22 at 11:28 +0200, Quentin Schulz wrote:
> > Hi Wes,
> >
> > On 8/22/22 06:59, Wes Lindauer wrote:
> > > It should not matter what xz/zstd parallelism and resource usage is set to
&g
On Mon, 2022-08-22 at 11:28 +0200, Quentin Schulz wrote:
> Hi Wes,
>
> On 8/22/22 06:59, Wes Lindauer wrote:
> > It should not matter what xz/zstd parallelism and resource usage is set to
> > when determining hash signatures. This allows sharing more sstate across
> > host machines with different
Hi Wes,
On 8/22/22 06:59, Wes Lindauer wrote:
It should not matter what xz/zstd parallelism and resource usage is set to
when determining hash signatures. This allows sharing more sstate across
host machines with different CPU configurations.
It seems like it does matter in some ways, c.f.:
h
If you have a compressed initrd for example this could give you a surprise,
so I'm not 100% sure about this.
/Regards
Den mån 22 aug. 2022 kl 07:00 skrev Wes Lindauer :
> It should not matter what xz/zstd parallelism and resource usage is set to
> when determining hash signatures. This allows sh
It should not matter what xz/zstd parallelism and resource usage is set to
when determining hash signatures. This allows sharing more sstate across
host machines with different CPU configurations.
Signed-off-by: Wes Lindauer
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 de
