Re: [OE-core] [PATCH 0/7] kernel-yocto: consolidated pull request

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2022-07-01 at 10:57 -0400, Bruce Ashfield wrote:
> On Fri, Jul 1, 2022 at 10:49 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Fri, 2022-07-01 at 15:10 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Fri, 2022-07-01 at 13:52 +0100, Richard Purdie via
> > > lists.openembedded.org wrote:
> > > > On Fri, 2022-07-01 at 10:59 +0100, Richard Purdie via
> > > > lists.openembedded.org wrote:
> > > > > On Thu, 2022-06-30 at 15:16 -0400, bruce.ashfield@gmail.com wrote:
> > > > > > With conference travel and issues with meta-virtualization, I've been
> > > > > > behind in sending this out .. but I have been queueing changes, I just
> > > > > > wanted to be around in case something breaks.
> > > > > > 
> > > > > > Here are the -stable updates and the start of my efforts to bring
> > > > > > 5.19 in as the new reference kernel for the fall release.
> > > > > > 
> > > > > > lttng-modules needed it's normal tweaks to work against the 5.19 source,
> > > > > > but otherwise, nothing significant has popped up.  I have other parts
> > > > > > of that uprev under test (libc-headers, systemtap, etc).
> > > > > 
> > > > > Thanks Bruce!
> > > > > 
> > > > > Unfortunately there was one issue the autobuilder found, a
> > > > > reproducibility issue in perf:
> > > > > 
> > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20220630-53gdlqxv/packages/diff-html/
> > > > > 
> > > > > I've not looked into it other than looking at the above link but it
> > > > > seems some python paths are creeping into the binaries.
> > > > 
> > > > This looked a little suspicious to me:
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=18f2967418d031a390a5befe855dd0faa8af70b9
> > > 
> > > Confirmed that it is this change. Not sure why but at least we have an
> > > idea of where the isssue is.
> > > 
> > > I've also sent a patch to insane.bbclass to change WARN_QA such that we
> > > can detect this kind of issue much earlier in people's local builds. It
> > > may expose issues in other layers but those issues probably do need
> > > exposing at this point too...
> > 
> > This breaks:
> > 
> > override PYTHON := $(call get-executable-or-default,PYTHON,$(subst -config,,$(PYTHON_AUTO)))
> > 
> > as somehow PYTHON is expanded to a full path, yet:
> > 
> > override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON_AUTO))
> > 
> > this works and doesn't expand PYTHON. I have no idea why, it doesn't
> > make sense.
> > 
> 
> urk. I'm off today for a Stat holiday (and Monday as well), but will
> poke at this throughout the weekend to try and come up with ideas
> 
> first step, get geared up to test reproducibility locally, step 0,
> find my old notes on the subject :)

The insane.bbclass change helps as you don't need a full
reproducibility build test. It is basically looking for buildpaths
(TOPDIR) in the binaries.

In other words just do a "strings perf | grep python3" and if you see a
full build path there, there is a problem.

You can see if on the compile commandline with a -DPYTHON= definition
too. If it is a full path, it is broken.

Cheers,

Richard