Re: Mis-generation of shell script (run.do_install)?

[richard.purdie@linuxfoundation.org]

On Fri, 2018-12-14 at 14:30 -0500, Jason Andryuk wrote:
> I wasn't sure how to tie into the pysh stuff, but that got me poking
> around in bitbake/lib/bb/codeparser.py .  Adding debug messages to
> parse_shell(), I see that do_install is found in the CodeParserCache,
> bb_codeparser.dat, but the returned `execs` do not include
> autotools_do_install.  Strangely, it includes a path to python -
> ...core2-32-oe-linux/python-async/0.6.2-r0/recipe-sysroot-
> native/usr/bin/python-native/python.
> It looks like `execs` could be for `distutils_do_install`.  And
> again,
> strangely, python-async is not in my tmp-glibc.  It must have been
> built at some point which left the entry in bb_codeparser.dat.
> 
> I built python-async, but its distutils_do_install hash value does
> not
> match the one in the cache.
> 
> Moving cache/bb_codeparser.dat out of the way, bitbake complains:
> ERROR: When reparsing
> /home/build/openxt/build/repos/openembedded-core/meta/recipes-
> devtools/binutils/binutils_2.28.bb.do_install,
> the basehash value changed from 80812e0772cf901b51790c205564070d to
> 493152cd3740c5420d0bf7a5d09df001. The metadata is not deterministic
> and this needs to be fixed.
> 
> `cleanall` does not clear out the message, but the package builds.

Its a little hard to make sense of this. If you move the cache out the
way it should simply get regenerated. It is long lived so things from
old builds in there is expected.

Were you able to isolate this into a smaller test case someone else
could reproduce?

Cheers,

Richard