On 03/08/2021 02:09 PM, Chen Qi wrote: > On 03/08/2021 10:30 AM, Chen Qi wrote: >> On 03/06/2021 07:29 AM, Richard Purdie wrote: >>> On Fri, 2021-03-05 at 18:10 +0800, Chen Qi wrote: >>>> As we delete the .git/ directory, it's impossible to get METADATA_REVISION >>>> inside eSDK. Because of this, we meet the following warning when installing eSDK. >>>> >>>> WARNING: The base-files:do_install sig is computed to be 16b9d96148d45de183cc94667aae016ec7d102d48255456381e718cd4bbd0aa0, \ >>>> but the sig is locked to 6eb0dcaed504282becee94662481d79264db920dee1f7deda18230133fff8f36 in SIGGEN_LOCKEDSIGS_t-qemux86-64 >>>> >>>> So we record METADATA_REVISION in eSDK generation time to fix this problem. >>>> >>>> Signed-off-by: Chen Qi >>>> --- >>>> meta/classes/populate_sdk_ext.bbclass | 3 +++ >>>> 1 file changed, 3 insertions(+) >>> I have to wonder why base-files is depending on the metadata-revision? That >>> implies that base-files and hence anything that depends upon it would rebuild >>> each time you update to a new revision. Is that really what you want? >>> >>> Cheers, >>> >>> Richard >>> >>> >>> >>> >> Hi Richard, >> >> I tested it on pure yocto project. No extra layer or configuration. >> I'm also wondering why base-files do_install depends on >> METADATA_REVISION. The strange thing is that things do not rebuild at >> eSDK installation time. There's only a warning about base-files >> do_install signature. >> > > Just found answer for the above problem. > A previous commit changes poky.conf to make DISTRO_VERSION contain > METADATA_REVISION. > """ > poky.conf: do not write current date into distro version, use git hash instead > > """ > > I also confirmed that merely updating the git revision will result in > a rebuild of base-files. > Rebuild of base-files does not result in rebuild of other recipes > because we have 'base-files' in SIGGEN_EXCLUDERECIPES_ABISAFE. > > For the problem below, I haven't found the root cause, still working > on it. > > Best Regards, > Chen Qi > >> In fact, this is a problem I found when I was dealing with another >> problem with eSDK. >> *Yocto's current eSDK cannot be successfully installed on a different >> distro.* For example, you build esdk on ubunt18 and install the esdk >> on ubuntu20, then you'll get an error of pseudo do_fetch task re-run >> unexpectedly. >> I think it might be related to NATIVELSBSTRING, but I haven't found >> out why. >> Manually setting NATIVELSBSTRING to some fixed string such as 'Linux' >> will solve the above problem. >> >> I'm still checking the codes. If you have some idea/suggestion, >> please let me know. >> I think I've found the problem. """ commit 3ecf5d9692fec97b37af6a4e6c747a4e2c2ca292 Author: Richard Purdie Date: Sat Nov 21 16:16:40 2020 +0000 uninative: Don't use single sstate for pseudo-native pseudo-native is a bit special. It conditionally compiles in support for xattr, statx and statvfs amongst other options. If a pseudo-native binary is used on a system where these functions are present but it wasn't compiled in we see hard to debug permissions problems. [snip] """ This commit effectively says that the pseudo-native's sstate cache should not be shared among hosts with different distros, as it's appending ${ORIGLSBSTRING} to SSTATE_PKGARCH for pseudo-native. I'm not familiar with the pseudo's codes. But I'm wondering if it's possible for pseudo to always build in attr support and behave differently on different hosts/filesystems. Best Regards, Chen Qi >> Best Regards, >> Chen Qi >> >> >> > > > > >