whatever happened to a proposal for "read-only" sstate?

whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

  for purposes of teaching, i wanted to check into the feasibility of
having students take advantage of a single shared state cache, but
still have the option of building whatever source they needed in their
own *personal* sstate cache.

  i found this reference from 2014:

http://lists.openembedded.org/pipermail/openembedded-core/2014-August/096486.html

but it seems clear nothing became of it; there's certainly no .bbclass
file that matches that.

  what are the options for setting up something like this? or is that
already supported and i'm just not seeing it?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: whatever happened to a proposal for "read-only" sstate?

[Richard Purdie]

On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
>   for purposes of teaching, i wanted to check into the feasibility of
> having students take advantage of a single shared state cache, but
> still have the option of building whatever source they needed in
> their
> own *personal* sstate cache.
> 
>   i found this reference from 2014:
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> /096486.html
> 
> but it seems clear nothing became of it; there's certainly no
> .bbclass
> file that matches that.
> 
>   what are the options for setting up something like this? or is that
> already supported and i'm just not seeing it?

It was never merged as its not really necessary, you can do this with
existing functionality.

Just point SSTATE_MIRRORS at the common shared directory and SSTATE_DIR
at the directory you want to be the personal one.

Cheers,

Richard

Re: whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Fri, 3 Feb 2017, Richard Purdie wrote:

> On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
> >   for purposes of teaching, i wanted to check into the feasibility of
> > having students take advantage of a single shared state cache, but
> > still have the option of building whatever source they needed in
> > their
> > own *personal* sstate cache.
> >
> >   i found this reference from 2014:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> > /096486.html
> >
> > but it seems clear nothing became of it; there's certainly no
> > .bbclass
> > file that matches that.
> >
> >   what are the options for setting up something like this? or is that
> > already supported and i'm just not seeing it?
>
> It was never merged as its not really necessary, you can do this with
> existing functionality.
>
> Just point SSTATE_MIRRORS at the common shared directory and
> SSTATE_DIR at the directory you want to be the personal one.

  ah, and that solves my problem entirely. thanks.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Fri, 3 Feb 2017, Richard Purdie wrote:

> On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
> >   for purposes of teaching, i wanted to check into the feasibility of
> > having students take advantage of a single shared state cache, but
> > still have the option of building whatever source they needed in
> > their
> > own *personal* sstate cache.
> >
> >   i found this reference from 2014:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> > /096486.html
> >
> > but it seems clear nothing became of it; there's certainly no
> > .bbclass
> > file that matches that.
> >
> >   what are the options for setting up something like this? or is that
> > already supported and i'm just not seeing it?
>
> It was never merged as its not really necessary, you can do this with
> existing functionality.
>
> Just point SSTATE_MIRRORS at the common shared directory and SSTATE_DIR
> at the directory you want to be the personal one.

  is there a command that will tell you how much shared state info a
given build would be able to take advantage of?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: whatever happened to a proposal for "read-only" sstate?

[Patrick Ohly]

On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
>   is there a command that will tell you how much shared state info a
> given build would be able to take advantage of?

INHERIT += "buildstats-summary" in local.conf will print that
information after a build is done.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

On Fri, 3 Feb 2017, Patrick Ohly wrote:

> On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
> >   is there a command that will tell you how much shared state info a
> > given build would be able to take advantage of?
>
> INHERIT += "buildstats-summary" in local.conf will print that
> information after a build is done.

  but not before? ok, that will do for now.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: whatever happened to a proposal for "read-only" sstate?

[Patrick Ohly]

On Fri, 2017-02-03 at 16:24 -0500, Robert P. J. Day wrote:
> On Fri, 3 Feb 2017, Patrick Ohly wrote:
> 
> > On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
> > >   is there a command that will tell you how much shared state info a
> > > given build would be able to take advantage of?
> >
> > INHERIT += "buildstats-summary" in local.conf will print that
> > information after a build is done.
> 
>   but not before? ok, that will do for now.

It might do that also for a "bitbake --dry-run", but I am not sure, and
my build directory is currently busy, so I can't test it.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

On Fri, 3 Feb 2017, Richard Purdie wrote:

> On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
> >   for purposes of teaching, i wanted to check into the feasibility of
> > having students take advantage of a single shared state cache, but
> > still have the option of building whatever source they needed in
> > their
> > own *personal* sstate cache.
> >
> >   i found this reference from 2014:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> > /096486.html
> >
> > but it seems clear nothing became of it; there's certainly no
> > .bbclass
> > file that matches that.
> >
> >   what are the options for setting up something like this? or is that
> > already supported and i'm just not seeing it?
>
> It was never merged as its not really necessary, you can do this
> with existing functionality.
>
> Just point SSTATE_MIRRORS at the common shared directory and
> SSTATE_DIR at the directory you want to be the personal one.

  let me make sure i understand this so i don't screw it up and waste
time asking even dumber questions.

  imagine i want to teach a class where everyone is going to build
some image -- core-image-minimal, core-image-base, whatever -- for the
same target board. (i realize you don't *need* to share state just for
the same target board but, in my case, there will be a great deal of
commonality in the classroom so shared state will be particularly
useful.)

  first, i can configure and do a build for a fairly comprehensive
image (core-image-base, perhaps) -- the more comprehensive, the
better, to generate as much shared state as possible. so far, so good?

  first question -- once i do that, can i just copy the generated
sstate-cache/ directory to a publicly-accessible location so everyone
else can get to it? for now, i'll keep it read-only, which means that
if someone needs content that isn't in that shared state cache, they
will have to generate it locally.

  once i copy my sstate-cache/ directory as above, how would others
take advantage of it? i'm looking at the alleged explanation in
local.conf.sample:

# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"

  this explanation confuses me -- what does that "NOTE" mean? what
would be proper setting for SSTATE_MIRRORS to simply point at an
accessible shared state directory? (possibly NFS-mounted.)

  finally, for building local content, i presume that students would
simply leave SSTATE_DIR with its original value of

  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

i think that's all i want to clarify, thanks.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: whatever happened to a proposal for "read-only" sstate?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Fri, 3 Feb 2017, Richard Purdie wrote:

> On Fri, 2017-02-03 at 06:45 -0500, Robert P. J. Day wrote:
> >   for purposes of teaching, i wanted to check into the feasibility of
> > having students take advantage of a single shared state cache, but
> > still have the option of building whatever source they needed in
> > their
> > own *personal* sstate cache.
> >
> >   i found this reference from 2014:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2014-August
> > /096486.html
> >
> > but it seems clear nothing became of it; there's certainly no
> > .bbclass
> > file that matches that.
> >
> >   what are the options for setting up something like this? or is that
> > already supported and i'm just not seeing it?
>
> It was never merged as its not really necessary, you can do this
> with existing functionality.
>
> Just point SSTATE_MIRRORS at the common shared directory and
> SSTATE_DIR at the directory you want to be the personal one.

  wait, i just ran across this YP wiki page:

https://wiki.yoctoproject.org/wiki/Enable_sstate_cache

so as long as it's accurate, i'll just work off of that.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================