Strange sstate problem

Strange sstate problem

[Gary Thomas]

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 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"

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)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: 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

Re: Strange sstate problem

[Gary Thomas]

On 2015-06-10 13:58, 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 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"
>
> 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)
>

I discovered what was causing these errors - I have buildhistory
enabled for target B.  Periodically I rebuild target A from scratch
and this gives buildhistory on target B fits.  For now, I'll just
disable buildhistory...

BTW, except for the buildhistory "errors", using sstate like
this does help quite a lot.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Strange sstate problem

[Paul Eggleton]

On Sunday 14 June 2015 14:31:34 Gary Thomas wrote:
> On 2015-06-10 13:58, 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 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"
> > 
> > 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)
>
> I discovered what was causing these errors - I have buildhistory
> enabled for target B.  Periodically I rebuild target A from scratch
> and this gives buildhistory on target B fits.  For now, I'll just
> disable buildhistory...
> 
> BTW, except for the buildhistory "errors", using sstate like
> this does help quite a lot.

FWIW buildhistory is only trying to help preserve the ability to do upgrades 
from your feeds here - if you don't care to see such errors you can remove 
"version-going-backwards" from your ERROR_QA value.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre