[yocto] Strange sstate problem

[Robert Berger]

Hi,

On 06/10/2015 10:58 PM, Gary Thomas wrote:
> I'm building for two similar targets and sharing sstate between
> them.  Actually, I build for target A and use that sstate cache
> in my SSTATE_MIRRORS for target B.

If I understand correctly what should happen, then SSTATE_MIRRORS should
point to some build machine, which populates SSTATE and other machines
pull from it.

something like:

SSTATE_MIRRORS ?= "file:///nfs/mount/sstate/PATH"

where PATH will be substituted.

So it looks like you do the right thing.

Is the sequence you do the following?

1) Build for target A (which is the SSTATE_MIRROR for target B)
2) After the build finished you build for target B using the shared
sstate from target A

> 
> If I try to build target B from scratch, i.e. wipe out most
> everything from my build tree:
>   % mv cache sstate-cache tmp old2; rm -fr old&
> I also have a PR server for each target - in local.conf:
>   PRSERV_HOST = "localhost:0"

I think that if you use a shared sstate whoever populates the sstate
should also use a central pr server.

something like:

bitbake-prserv --host <server_ip> --port <port> --start on one machine
and instead of localhost:0 the <server_ip>:<port>

In your case it should not matter, since only target A populates the
shared sstate, but you can give it a try.


> 
> When I build in target B, I'm getting a ton of QA errors, basically
> one for every package selected, e.g.
>   ERROR: QA Issue: Package version for package fsl-alsa-plugins went
> backwards which would break package feeds from (0:1.0.25-r0.2 to
> 0:1.0.25-r0.0) [version-going-backwards]
> 
> What could be going on here?
> 
> n.b. I'm using a fairly recent Poky/Yocto master
> (a05663bfa10352fd5af6ca9a9d7b323c1c099f35)
> 

Regards,

Robert

..."Software is getting slower more rapidly than hardware becomes
faster." - Niklaus Wirth, who attributed it to Martin Reiser.

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1