<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Maciej,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Sep 1, 2017 at 4:08 PM, Maciej Borzęcki <span dir="ltr"><<a href="mailto:maciej.borzecki@rndity.com" target="_blank">maciej.borzecki@rndity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-5228568782234999071gmail-">On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera <<a href="mailto:gizero@gmail.com" target="_blank">gizero@gmail.com</a>> wrote:<br>
</span><span class="m_-5228568782234999071gmail-">> Hi!<br>
><br>
> I was trying to share sstate between different hosts, but the consumer build<br>
> system seems to be unable to use re-use any sstate object. My scenario is<br>
> setup as follows:<br>
><br>
> * The cache was populated by a pristine qemux86 core-image-minimal build of<br>
> morty. This was done in a crops/poky container (running in docker on Mac)<br>
> * The cache was then served via HTTP<br>
<br>
</span>Make sure that you use a decent HTTP server. Simple `python3 -m<br>
http.server` will quickly choke when the mirror is being checked. Also<br>
running bitbake -DDD -v makes investigating this much easier.<br></blockquote><div><br></div><div>To be honest, the current server was indeed setup with python's SimpleHTTPServer... As you suggest, I checked the verbose debug log and noticed what's happening behind the apparently happy "Checking sstate mirror object availability" step. After a first "SState: Successful fetch test for" that I see correctly served with 200 on the server side, tests for any other sstate object suddenly and systematically fail with logs like this:</div><div><br></div><div><div>DEBUG: SState: Attempting to fetch file://7d/sstate:libxml2:i586-<wbr>poky-linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz</div><div>DEBUG: Searching for 7d/sstate:libxml2:i586-poky-<wbr>linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz in paths:</div><div> /home/vagrant/koan/morty/<wbr>build/sstate-cache</div><div>DEBUG: Defaulting to /home/vagrant/koan/morty/<wbr>build/sstate-cache/7d/sstate:<wbr>libxml2:i586-poky-linux:2.9.4:<wbr>r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz for 7d/sstate:libxml2:i586-poky-<wbr>linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23b</div><div>db86ac7ab32_package_qa.tgz</div><div>DEBUG: Testing URL file://7d/sstate:libxml2:i586-<wbr>poky-linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz</div><div>DEBUG: For url ['file', '', '7d/sstate:libxml2:i586-poky-<wbr>linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz', '', '', OrderedDict()] comparing ['file', '', '.*', '', '', OrderedDict()] to ['http', '<a href="http://192.168.33.1:8000" target="_blank">192.168.33.1:8000</a>', '</div><div>/sstate-cache/PATH', '', '', OrderedDict([('<wbr>downloadfilename', 'PATH')])]</div><div>DEBUG: For url file://7d/sstate:libxml2:i586-<wbr>poky-linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz returning <a href="http://192.168.33.1:8000/sstate-cache/7d/sstate%3Alibxml2%3Ai586-poky-linux%3A2.9.4%3Ar0%3Ai586%3A3%3A7da8fc" target="_blank">http://192.168.33.1:8000/<wbr>sstate-cache/7d/sstate%<wbr>3Alibxml2%3Ai586-poky-linux%<wbr>3A2.9.4%3Ar0%3Ai586%3A3%<wbr>3A7da8fc</a></div><div>3f7f5ed0102d23bdb86ac7ab32_<wbr>package_qa.tgz;<wbr>downloadfilename=7d/sstate:<wbr>libxml2:i586-poky-linux:2.9.4:<wbr>r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz</div><div>DEBUG: checkstatus: trying again</div><div>DEBUG: checkstatus() urlopen failed: <urlopen error [Errno 9] Bad file descriptor></div><div>DEBUG: SState: Unsuccessful fetch test for file://7d/sstate:libxml2:i586-<wbr>poky-linux:2.9.4:r0:i586:3:<wbr>7da8fc3f7f5ed0102d23bdb86ac7ab<wbr>32_package_qa.tgz</div></div><div><br></div><div>Nothing is reported server-side for any of these failures... As you recommend, I'll try to setup something more "decent" for the HTTP server and see if it helps. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="m_-5228568782234999071gmail-HOEnZb"><div class="m_-5228568782234999071gmail-h5"><br>
> * The second host is a VM running Ubuntu 16.04 where I set SSTATE_MIRRORS to<br>
> point to the hosted sstate cache like this:<br>
><br>
> SSTATE_MIRRORS ?= "\<br>
> file://.* <a href="http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=PATH" rel="noreferrer" target="_blank">http://192.168.33.1:8000/sstat<wbr>e-cache/PATH;downloadfilename=<wbr>PATH</a>"<br>
><br>
> * I checked with curl that the VM can successfully get sstate objects from<br>
> the server.<br>
> * Then I start a new build (same metadata revisions, default configuration<br>
> for core-image-minimal) and each and every task run from scratch with no<br>
> sstate cache re-use.<br>
><br>
> Here are the two configurations from bitbake and /etc/lsb-release files:<br>
><br>
> On the container used to seed sstate cache:<br>
><br>
> Build Configuration:<br>
> BB_VERSION = "1.32.0"<br>
> BUILD_SYS = "x86_64-linux"<br>
> NATIVELSBSTRING = "universal"<br>
> TARGET_SYS = "i586-poky-linux"<br>
> MACHINE = "qemux86"<br>
> DISTRO = "poky"<br>
> DISTRO_VERSION = "2.2.2"<br>
> TUNE_FEATURES = "m32 i586"<br>
> TARGET_FPU = ""<br>
> meta<br>
> meta-poky<br>
> meta-yocto-bsp = "morty:2a70e84643381eca0e7bf79<wbr>28d4a3d56f9651128"<br>
><br>
> $ cat /etc/lsb-release<br>
> DISTRIB_ID=Ubuntu<br>
> DISTRIB_RELEASE=16.04<br>
> DISTRIB_CODENAME=xenial<br>
> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"<br>
><br>
> On the VM that should consume the cache:<br>
><br>
> Build Configuration:<br>
> BB_VERSION = "1.32.0"<br>
> BUILD_SYS = "x86_64-linux"<br>
> NATIVELSBSTRING = "Ubuntu-16.04"<br>
> TARGET_SYS = "i586-poky-linux"<br>
> MACHINE = "qemux86"<br>
> DISTRO = "poky"<br>
> DISTRO_VERSION = "2.2.2"<br>
> TUNE_FEATURES = "m32 i586"<br>
> TARGET_FPU = ""<br>
> meta<br>
> meta-poky<br>
> meta-yocto-bsp = "morty:2a70e84643381eca0e7bf79<wbr>28d4a3d56f9651128"<br>
><br>
> $ cat /etc/lsb-release<br>
> DISTRIB_ID=Ubuntu<br>
> DISTRIB_RELEASE=16.04<br>
> DISTRIB_CODENAME=xenial<br>
> DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"<br>
><br>
><br>
> To me, the only differing bit that in my understanding can lead to sstate<br>
> cache objects invalidation is the value of NATIVELSBSTRING which is<br>
> "universal" inside the container and "Ubuntu-16.04". This sounds strange to<br>
> me, since both underlying systems are Ubuntu 16.04 (although not exactly the<br>
> same dot release) as confirmed by /etc/lsb-release contents.<br>
><br>
> Is the different NATIVELSBSTRING the root cause for everything being<br>
> re-built? If so, what's causing them being different in the end and what<br>
> does "universal" exactly mean (to me it looks like a more generic and<br>
> incluse term than any distro label, so I'm confused...)?<br>
><br>
><br>
</div></div><div class="m_-5228568782234999071gmail-HOEnZb"><div class="m_-5228568782234999071gmail-h5">> --<br>
> ______________________________<wbr>_________________<br>
> yocto mailing list<br>
> <a href="mailto:yocto@yoctoproject.org" target="_blank">yocto@yoctoproject.org</a><br>
> <a href="https://lists.yoctoproject.org/listinfo/yocto" rel="noreferrer" target="_blank">https://lists.yoctoproject.org<wbr>/listinfo/yocto</a><br>
><br>
<br>
<br>
<br>
</div></div><span class="m_-5228568782234999071gmail-HOEnZb"><font color="#888888">--<br>
Maciej Borzecki<br>
RnDity<br>
</font></span></blockquote></div><br></div></div>