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 list and then tried to "port
> it forward to master". I appreciate everyone taking the time to
> explain. I am still a little confused why calculating every rpm task
> signature with a value of 1 is acceptable, but ignoring the variable
> in the signature is not. Are these not different implementations of
> the same thing?
> > XZ_THREADS ?= "${@oe.utils.cpu_count(at_least=2)}"
> > XZ_THREADS[vardepvalue] = "1"
Note we do *two* things, we set it to at least a count of 2 and give it
a known consistent value. It is the two things together than work out
ok.
If the user changes XZ_THREADS, as long as it is set to a value or 2 or
more it is still ok. If the user sets it to a value of 1, builds are
not reproducible.
You're right that we could have just ignored it, but this at least
gives a hint that a value of 2 or more should be used. Ideally we'd
have put a warning around a value of 1 but there are a lot of things
we'd do ideally and limited time...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170088):
https://lists.openembedded.org/g/openembedded-core/message/170088
Mute This Topic: https://lists.openembedded.org/mt/93175519/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
