On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
> On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
> > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> > > Right, so the next step would be looking for the hash for
> > > python-native.do_populate_sysroot in conf/locked_sigs.inc within the
> > > failed SDK install directory and then looking for that in both the sstate-
> > > cache directory within the failed SDK and then in the sstate-cache
> > > directory of the build that built it. I suspect it may not be there, but
> > > let me know what you find.
> > 
> > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
> > sstate-cache do include any python-native signature or object... Only
> > python3-native stuff is there. Weird! As said, SDKs from the same build
> > directory, used to work since a few weeks ago. May any recent change in
> > poky master have caused this while periodically upgrading without
> > regenerating the sstate-cache?
> No, I can't see any added references to python-native anywhere in the last 
> few 
> weeks. If you do bitbake -c clean python-native and then rebuild the SDK does 
> the issue go away?

Actually scratch that, that's not going to help. The question is where is
this dependency coming from and why isn't it properly picked up such
that it gets included. bitbake -g -c populate_sdk_ext your-image might be 
useful in determining that.



Paul Eggleton
Intel Open Source Technology Centre
yocto mailing list

Reply via email to