[OE-core] Mis-generation of shell script (run.do_install)?

[Richard Purdie]

On Wed, 2019-01-16 at 15:20 -0500, Jason Andryuk wrote:
> On Wed, Jan 16, 2019 at 9:02 AM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Wed, 2019-01-16 at 08:55 -0500, Jason Andryuk wrote:
> > > On Tue, Jan 8, 2019 at 1:26 PM <
> > > richard.purdie at linuxfoundation.org>
> > > wrote:
> > > OpenXT builds 8 or 9 different MACHINEs and images in sequence in
> > > the
> > > same build directory.  Maybe 6 are core2-32 and two are core2-64. 
> > > The
> > > 32bit ones run first.
> > 
> > The hash we don't have is from a core2-32 MACHINE. I'm wondering
> > which configurations you might have parsed for a core2-32 MACHINE
> > between October and December?
> 
> Which "configurations" are you asking about?

I mean the machine configurations. It sounds like it was just the
standard ones from OpenXT which most of your builds would loop through.
I did try and reproduce the hash using those but I could be missing
something.

> The standard OpenXT build loops through building all 8 images and
> packaging them up into an installer iso.  Often I run that build
> script, but sometimes I just build individual machines manually.
>
> I was mainly working on the core2-64 machines immediately prior to
> this event.  I was very surprised when it occured since 1) I didn't
> expect binutils to be re-built and 2) I wasn't working on the
> openxt-installer machine which failed.
> 
> > Was TMPDIR ever cleaned? If not, do you have the python-async
> > WORKDIR
> > for core2-32? The TMPDIR/logs directory may also have useful hints
> > about the configurations built...
> 
> Unfortunately, yes, I cleaned TMPDIR when I hit the build
> error.  Same with the sstate-cache.
> 
> In general, I don't see python-async in TMPDIR after running through
> the OpenXT build.  Would that be because an early machine builds
> python-async, but then it gets cleared out of TMPDIR when a later
> machine/image are built?
>
> > > 
[...]
> All the base OpenXT machines have "-mstackrealign" in their conf.  My
> new 64bit machines do not have it.  I don't recall working with
> core2-32 MACHINES at the time.  The new layer I pulled in only had a
> layer.conf and a 64bit machine.conf.
> 
> In my second container, I `rm -rf cache/ tmp-glibc/ sstate-cache/`.
> Running the build of the first OpenXT machine, bb_codeparse.dat gets
> populated with python-async:
> '3c6fe664c51d2f793f8fd0eb103d68cb': frozenset({'find', 'sed',
> 'install', 'mv', 'bbfatal_log', 'rmdir', '[', 'rm',
> '/home/build/openxt-compartments/build/tmp-glibc/work/core2-32-oe-
> linux/python-async/0.6.2-r0/recipe-sysroot-native/usr/bin/python-
> native/python',
> 'test'})
> 
> python-async is not in tmp-glibc/work and `grep -r tmp-glibc/log`
> doesn't turn up anything.  If I run `bitbake -g`, python-async
> doesn't
> appear in any of the output files.  Is bb_codeparser.data getting
> populated without building the recipe to be expected?

The data is in the codeparser cache which is first populated at parse
time so its enough just to parse the machine+recipe in question, not
build it. I think that explains the answer to a ew of your questions
above.

Sorry for asking so many questions btw, I'd just really love to be able
to reproduce this issue! Thanks for trying to help answer them too!

Is the bitbake-cookerdeamon.log file still there for this build (in the
top level build directory)?

Cheers,

Richard