[OE-core] new meta-oe failures from master-next

Thu Oct 24 09:34:44 UTC 2019

On Thu, 2019-10-24 at 09:34 +0100, Khem Raj wrote:
> On Thu, Oct 24, 2019 at 9:25 AM <richard.purdie at linuxfoundation.org>
> wrote:
> > On Thu, 2019-10-24 at 09:20 +0100, Khem Raj wrote:
> > > On Thu, Oct 24, 2019 at 9:15 AM <
> > > richard.purdie at linuxfoundation.org>
> > > wrote:
> > > > On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote:
> > > > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie
> > > > > <richard.purdie at linuxfoundation.org> wrote:
> > > > > > On Wed, 2019-10-23 at 16:29 +0100, Ross Burton wrote:
> > > > > > > On 23/10/2019 14:03, Khem Raj wrote:
> > > > > > > > Hi Richard
> > > > > > > > 
> > > > > > > > New master-next I see these fails
> > > > > > > > 
> > > > > > > > https://errors.yoctoproject.org/Errors/Build/91645/
> > > > > > > > 
> > > > > > > > First two are important one's we already know why
> > > > > > > > ti-display-sharing-fw fails to fetch
> > > > > > > 
> > > > > > > ERROR: QA Issue: libiio: Files/directories were installed
> > > > > > > but
> > > > > > > not
> > > > > > > shipped in any package:
> > > > > > >    /usr/lib/python2.7
> > > > > > >    /usr/lib/python2.7/site-packages
> > > > > > >    /usr/lib/python2.7/site-packages/libiio-0.18-
> > > > > > > py2.7.egg-
> > > > > > > info
> > > > > > >    /usr/lib/python2.7/site-packages/iio.pyc
> > > > > > >    /usr/lib/python2.7/site-packages/iio.py
> > > > > > > 
> > > > > > > That may have been triggered by some change in oe-core
> > > > > > > but
> > > > > > > that's
> > > > > > > definitely an issue with libiio.
> > > > > > 
> > > > > > Its from this cmake change:
> > > > > > 
> > > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1
> > > > > > 
> > > > > 
> > > > > I think its causing more failures, where suddenly, the
> > > > > recipes
> > > > > are
> > > > > now
> > > > > resorting to native python, is this patch correct I wonder ?
> > > > > 
> > > > > see
> > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=5d02e814bc7d30f925b2eeec85eb053cec516f26
> > > > > 
> > > > > https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=3ab0af60e8512cbb718e8a0112d9c9aa98c620a4
> > > > 
> > > > The cmake change makes python visible from HOSTTOOLS. That
> > > > isn't
> > > > wrong
> > > > as such, it is a change in behaviour. If recipes don't set
> > > > python
> > > > enabled/disabled explicitly, there is some fallout from that.
> > > > I'd
> > > > say
> > > > that is a bug in those recipes which aren't giving explicit
> > > > configuration to dependencies though.
> > > > 
> > > 
> > > So now the behavior is interesting. It works fine if I build for
> > > a
> > > machine where host-arch = target-arch
> > > so if someone is building for x86_64 then they dont see the build
> > > failures. IMO thats worse.
> > 
> > That is a general problem with cross compiling and applies to any
> > automatically detected dependency from the host. Python is in an
> > odd
> > place here since we do need it on the host to run bitbake and there
> > are
> > places where we need that exposed to code (e.g. they have python
> > scripts), there are places where we don't want it exposed as host
> > contamination.
> > 
> > Have you looked at the buildhistory logs to see what changed in
> > meta-oe
> > as that would likely highlight the changes.
> 
> well nothing has changed in meta-oe as such to cause this issue.
> Since now we expand where all cmake can look for development headers
> and libraries, it happily finds then it native sysroot earlier it was
> guarded from looking into native sysroot. So its cmake not
> differentiating if its mixing two sysroots now, which is not new for
> cmake, it has to be given certain paths.

No, cmake has always looked in the native sysroot. What the patch
changes is whether HOSTTOOLS are seen or not. The exact change is:

-set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN})
+set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} ${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})

It already looks at native, cross and external tools, just not
HOSTTOOLS_DIR. This does look very much like an omission and would
break ASSUME_PROVIDED usage for example so it does fix a real world
issue I can imagine people running into.

> So yes when headers and libraries for python are set to point to
> target sysroot then you aid it to look
> into right sysroot but I think it might become a pain point in future
> where someone will test it on x86_64
> and think it builds and works where as it will be implicitly wrong.
> We can fix what we know but that is not all.

Agreed, but that is a problem we already have and is why we do ask
people test another arch. Its also why we ask people to list
dependencies and explicitly enable or disable them.

I do understand what you mean but I don't think it changes much as its
the same general problem the project has always faced and continues to
face.

If you want to propose the patch be reverted, you can however I'm not
really seeing a case for it myself.

Cheers,

Richard