On Fri, Sep 1, 2017 at 3:57 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> Why do you use: > > ";downloadfilename=PATH > <http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=PATH>" > > ? > Most likely because I copy/pasted from local.conf comments. I see the same syntax on both "morty" [1] and "current" documentation. Shouldn't this be part of the "keep the same two-character subdirectories layout of the mirror" thing? [1] http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-SSTATE_MIRRORS > On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera <giz...@gmail.com> wrote: > >> Hi! >> >> I was trying to share sstate between different hosts, but the consumer >> build system seems to be unable to use re-use any sstate object. My >> scenario is setup as follows: >> >> * The cache was populated by a pristine qemux86 core-image-minimal build >> of morty. This was done in a crops/poky container (running in docker on Mac) >> * The cache was then served via HTTP >> * The second host is a VM running Ubuntu 16.04 where I set SSTATE_MIRRORS >> to point to the hosted sstate cache like this: >> >> SSTATE_MIRRORS ?= "\ >> file://.* http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename= >> PATH" >> >> * I checked with curl that the VM can successfully get sstate objects >> from the server. >> * Then I start a new build (same metadata revisions, default >> configuration for core-image-minimal) and each and every task run from >> scratch with no sstate cache re-use. >> >> Here are the two configurations from bitbake and /etc/lsb-release files: >> >> On the container used to seed sstate cache: >> >> Build Configuration: >> BB_VERSION = "1.32.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "universal" >> TARGET_SYS = "i586-poky-linux" >> MACHINE = "qemux86" >> DISTRO = "poky" >> DISTRO_VERSION = "2.2.2" >> TUNE_FEATURES = "m32 i586" >> TARGET_FPU = "" >> meta >> meta-poky >> meta-yocto-bsp = "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128" >> >> $ cat /etc/lsb-release >> DISTRIB_ID=Ubuntu >> DISTRIB_RELEASE=16.04 >> DISTRIB_CODENAME=xenial >> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" >> >> On the VM that should consume the cache: >> >> Build Configuration: >> BB_VERSION = "1.32.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "Ubuntu-16.04" >> TARGET_SYS = "i586-poky-linux" >> MACHINE = "qemux86" >> DISTRO = "poky" >> DISTRO_VERSION = "2.2.2" >> TUNE_FEATURES = "m32 i586" >> TARGET_FPU = "" >> meta >> meta-poky >> meta-yocto-bsp = "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128" >> >> $ cat /etc/lsb-release >> DISTRIB_ID=Ubuntu >> DISTRIB_RELEASE=16.04 >> DISTRIB_CODENAME=xenial >> DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS" >> >> >> To me, the only differing bit that in my understanding can lead to sstate >> cache objects invalidation is the value of NATIVELSBSTRING which is >> "universal" inside the container and "Ubuntu-16.04". This sounds strange to >> me, since both underlying systems are Ubuntu 16.04 (although not exactly >> the same dot release) as confirmed by /etc/lsb-release contents. >> >> Is the different NATIVELSBSTRING the root cause for everything being >> re-built? If so, what's causing them being different in the end and what >> does "universal" exactly mean (to me it looks like a more generic and >> incluse term than any distro label, so I'm confused...)? >> >> >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto