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

[Khem Raj]

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.

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.

>
> Cheers,
>
> Richard
>
>
>
>
>
>