On Thu, Oct 24, 2019 at 9:25 AM <[email protected]> wrote: > > On Thu, 2019-10-24 at 09:20 +0100, Khem Raj wrote: > > On Thu, Oct 24, 2019 at 9:15 AM <[email protected]> > > wrote: > > > On Wed, 2019-10-23 at 23:52 +0100, Khem Raj wrote: > > > > On Wed, Oct 23, 2019 at 8:31 PM Richard Purdie > > > > <[email protected]> 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 > > > > > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
