> I have kind of noticed this and agree its something we should fix.
> Thanks for digging into it. I think a long time ago we tried the above change
> and it does cause a problem, perhaps fetching during parsing which is bad.
>
> Have you been able to figure out what changes in the data store for the cache
> to be invalidated? I think whitelisting something may be the best solution,
> or perhaps only activating certain changes in the build code > paths after
> parsing in all cases.
>
Yes absolutely the variables and content diff is as follow:
830c830
< ('NATIVELSBSTRING', 'neon-16.04')
---
> ('NATIVELSBSTRING', 'universal')
1447c1447,1449
< ('SSTATEPOSTUNPACKFUNCS', 'sstate_hardcode_path_unpack')
---
> ('SSTATEPOSTUNPACKFUNCS', 'sstate_hardcode_path_unpack
> uninative_changeinterp')
> ('SSTATEPOSTUNPACKFUNCS[_append]', [[' uninative_changeinterp', None]])
> ('SSTATEPOSTUNPACKFUNCS[vardepvalueexclude]', '| uninative_changeinterp')
I did a PR (PATCH) for the 1st alternative (fetching earlier) here:
https://patchwork.openembedded.org/series/11369/
But I need to do a v2 to fix the short description to make shorter. if you ever
decided that it could be way to go. (FWIW I did test it on our setup and yes it
is fetching the uninative binaries early on or maybe during the parsing, see
output bellow):
cbugot@neon:~/devs/yocto/build$ bitbake some-image
--2018-03-13 18:25:36--
http://build-cache-server/cache//downloads/x86_64-nativesdk-libc.tar.bz2
Resolving build-cache-server (build-cache-server)... 10.41.51.220
Connecting to build-cache-server
(build-cache-server)|10.41.51.220|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2286285 (2.2M) [application/x-bzip2]
Saving to:
‘/home/cbugot/devs/unity/build/downloads/uninative/ed033c868b87852b07957a4400f3b744c00aef5d6470346ea1a59b6d3e03075e/x86_64-nativesdk-libc.tar.bz2’
2018-03-13 18:25:36 (11.2 MB/s) -
‘/home/cbugot/devs/unity/build/downloads/uninative/ed033c868b87852b07957a4400f3b744c00aef5d6470346ea1a59b6d3e03075e/x86_64-nativesdk-libc.tar.bz2’
saved [2286285/2286285]
NOTE: Fetching uninative binary shim from
http://downloads.yoctoproject.org/releases/uninative/1.7/x86_64-nativesdk-libc.tar.bz2;sha256sum=ed033c868b87852b07957a4400f3b744c00aef5d6470346ea1a59b6d3e03075e
Parsing recipes: 37%
|#######################################################################################
| ETA:
0:06:30
However, if you think putting the two variables (NATIVELSBSTRING,
SSTATEPOSTUNPACKFUNCS) in BB_HASHCONFIG_WHITELIST is better/safer, I can also
submit a PATCH request for that alternative.
Personally I do not have enough yocto experience to decide which one would be
the best (just inferred that WHITELIST could lead to weird behavior if someone
ever depended on one of this variable in his recipe); so I would be happy
either way 😊.
Cheers,
Cuero
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
