BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Robert P. J. Day]

  not sure if this is expected behaviour, but i'm using the meta-ti
layer to build a core-image-minimal for a am180x-evm.  i'm using
"own-mirrors" to use my own premirrors directory and i've collected
all of the necessary tarballs and actually completed the build, after
which i make sure i have saved all of the tarballs so i don't need
to download anything for a subsequent build.

  as a test, i totally delete my build and start over, but this time
with

  BB_NO_NETWORK = "1"

which i assumed would still work.  instead, i almost immediately got
this:

$ bitbake -c fetch core-image-minimal
Pseudo is not present but is required, building this first before the
main build
ERROR: ExpansionError during parsing
/home/rpjday/oe/dist/layers/meta-ti/recipes-bsp/u-boot/u-boot_2013.01.bb:
Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess:
Network access disabled through BB_NO_NETWORK but access requested
with command git ls-remote
git://arago-project.org/git/projects/u-boot-keystone.git
DEV.MCSDK-03.00.00.06 (for url None)
ERROR: Command execution failed: Exited with 1

  that's not even the version of u-boot that's going to be used, as
"bitbake -s" shows:

u-boot  :2009.11+r68+gitr5f16b8551b125f16cd8d58f278cb25b94272fd9f-r68

so i'm guessing that what's happening here is that even though the
u-boot recipe file u-boot_2013.01.bb will contribute nothing to this
build, its parsing alone requires network access, which makes the
usage of BB_NO_NETWORK = "1" somewhat useless in this context.

  am i misreading something?  thoughts?

rday

-- 

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

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

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Martin Jansa]

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

On Tue, Jan 29, 2013 at 04:08:10AM -0500, Robert P. J. Day wrote:
> 
>   not sure if this is expected behaviour, but i'm using the meta-ti
> layer to build a core-image-minimal for a am180x-evm.  i'm using
> "own-mirrors" to use my own premirrors directory and i've collected
> all of the necessary tarballs and actually completed the build, after
> which i make sure i have saved all of the tarballs so i don't need
> to download anything for a subsequent build.
> 
>   as a test, i totally delete my build and start over, but this time
> with
> 
>   BB_NO_NETWORK = "1"
> 
> which i assumed would still work.  instead, i almost immediately got
> this:
> 
> $ bitbake -c fetch core-image-minimal
> Pseudo is not present but is required, building this first before the
> main build
> ERROR: ExpansionError during parsing
> /home/rpjday/oe/dist/layers/meta-ti/recipes-bsp/u-boot/u-boot_2013.01.bb:
> Failure expanding variable SRCPV, expression was
> ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess:
> Network access disabled through BB_NO_NETWORK but access requested
> with command git ls-remote
> git://arago-project.org/git/projects/u-boot-keystone.git
> DEV.MCSDK-03.00.00.06 (for url None)
> ERROR: Command execution failed: Exited with 1

It's using tag instead of hash in SRCREV, so it behaves the same as
SRC_URI = "git://.*;tag=foo" and tries to access upstream repo to
convert tag name to hash (or check if it's still the same hash as when
you've built it last time.

Cheers,

>   that's not even the version of u-boot that's going to be used, as
> "bitbake -s" shows:
> 
> u-boot  :2009.11+r68+gitr5f16b8551b125f16cd8d58f278cb25b94272fd9f-r68
> 
> so i'm guessing that what's happening here is that even though the
> u-boot recipe file u-boot_2013.01.bb will contribute nothing to this
> build, its parsing alone requires network access, which makes the
> usage of BB_NO_NETWORK = "1" somewhat useless in this context.
> 
>   am i misreading something?  thoughts?
> 
> rday
> 
> -- 
> 
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Robert P. J. Day]

On Tue, 29 Jan 2013, Martin Jansa wrote:

> On Tue, Jan 29, 2013 at 04:08:10AM -0500, Robert P. J. Day wrote:
> >
> >   not sure if this is expected behaviour, but i'm using the meta-ti
> > layer to build a core-image-minimal for a am180x-evm.  i'm using
> > "own-mirrors" to use my own premirrors directory and i've collected
> > all of the necessary tarballs and actually completed the build, after
> > which i make sure i have saved all of the tarballs so i don't need
> > to download anything for a subsequent build.
> >
> >   as a test, i totally delete my build and start over, but this time
> > with
> >
> >   BB_NO_NETWORK = "1"
> >
> > which i assumed would still work.  instead, i almost immediately got
> > this:
> >
> > $ bitbake -c fetch core-image-minimal
> > Pseudo is not present but is required, building this first before the
> > main build
> > ERROR: ExpansionError during parsing
> > /home/rpjday/oe/dist/layers/meta-ti/recipes-bsp/u-boot/u-boot_2013.01.bb:
> > Failure expanding variable SRCPV, expression was
> > ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess:
> > Network access disabled through BB_NO_NETWORK but access requested
> > with command git ls-remote
> > git://arago-project.org/git/projects/u-boot-keystone.git
> > DEV.MCSDK-03.00.00.06 (for url None)
> > ERROR: Command execution failed: Exited with 1
>
> It's using tag instead of hash in SRCREV, so it behaves the same as
> SRC_URI = "git://.*;tag=foo" and tries to access upstream repo to
> convert tag name to hash (or check if it's still the same hash as when
> you've built it last time.

  ah ... so as a cheap hack to get around this, as long as i don't
need that recipe, i guess i could just BBMASK it out.  is that the
easiest solution?  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: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Martin Jansa]

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

On Tue, Jan 29, 2013 at 04:54:30AM -0500, Robert P. J. Day wrote:
> On Tue, 29 Jan 2013, Martin Jansa wrote:
> 
> > On Tue, Jan 29, 2013 at 04:08:10AM -0500, Robert P. J. Day wrote:
> > >
> > >   not sure if this is expected behaviour, but i'm using the meta-ti
> > > layer to build a core-image-minimal for a am180x-evm.  i'm using
> > > "own-mirrors" to use my own premirrors directory and i've collected
> > > all of the necessary tarballs and actually completed the build, after
> > > which i make sure i have saved all of the tarballs so i don't need
> > > to download anything for a subsequent build.
> > >
> > >   as a test, i totally delete my build and start over, but this time
> > > with
> > >
> > >   BB_NO_NETWORK = "1"
> > >
> > > which i assumed would still work.  instead, i almost immediately got
> > > this:
> > >
> > > $ bitbake -c fetch core-image-minimal
> > > Pseudo is not present but is required, building this first before the
> > > main build
> > > ERROR: ExpansionError during parsing
> > > /home/rpjday/oe/dist/layers/meta-ti/recipes-bsp/u-boot/u-boot_2013.01.bb:
> > > Failure expanding variable SRCPV, expression was
> > > ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess:
> > > Network access disabled through BB_NO_NETWORK but access requested
> > > with command git ls-remote
> > > git://arago-project.org/git/projects/u-boot-keystone.git
> > > DEV.MCSDK-03.00.00.06 (for url None)
> > > ERROR: Command execution failed: Exited with 1
> >
> > It's using tag instead of hash in SRCREV, so it behaves the same as
> > SRC_URI = "git://.*;tag=foo" and tries to access upstream repo to
> > convert tag name to hash (or check if it's still the same hash as when
> > you've built it last time.
> 
>   ah ... so as a cheap hack to get around this, as long as i don't
> need that recipe, i guess i could just BBMASK it out.  is that the
> easiest solution?  thanks.

It would be better to change SRCREV to hash corresponding to that tag
and move tag only to comment above SRCREV. Such patch could be applied
in upstream...

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Robert P. J. Day]

On Tue, 29 Jan 2013, Martin Jansa wrote:

... snip ...

> It would be better to change SRCREV to hash corresponding to that
> tag and move tag only to comment above SRCREV. Such patch could be
> applied in upstream...

  which brings up a larger issue ... what is the *preferred* way of
doing this if one was writing a style guide?  i understand developers
might like to set git SRCREV variables to meaningful tag names but, as
i've learned, that really screws up the possibility of building with
no network.  as it is, quite a few recipes set SRCREV to a hash ID for
*precisely* that reason and, in a short comment above (as you say),
mention the tag it corresponds to.

  which brings me to what caused this annoyance in the first place --
the meta-ti layer, which has only four recipes that use

  SRCREV = <tag name>

so it wouldn't be that hard to submit a patch to adjust those, but
then there's this in
meta-ti/recipes-kernel/linux/linux-keystone_3.6.6.bb:

# The tree tends to rebase, use literal stable tags
SRCREV = "DEV.MCSDK-03.06.06.07"

  uh ... correct me if i'm wrong but isn't it in unspeakably bad taste
to rebase commits that have already been published?

  in any event, can it be considered bad form to set SRCREV to git tag
names?  thoughts?

rday

-- 

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

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

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Chris Larson]

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

On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:

> On Tue, 29 Jan 2013, Martin Jansa wrote:
>
> ... snip ...
>
> > It would be better to change SRCREV to hash corresponding to that
> > tag and move tag only to comment above SRCREV. Such patch could be
> > applied in upstream...
>
>   which brings up a larger issue ... what is the *preferred* way of
> doing this if one was writing a style guide?  i understand developers
> might like to set git SRCREV variables to meaningful tag names but, as
> i've learned, that really screws up the possibility of building with
> no network.  as it is, quite a few recipes set SRCREV to a hash ID for
> *precisely* that reason and, in a short comment above (as you say),
> mention the tag it corresponds to.
>
>   which brings me to what caused this annoyance in the first place --
> the meta-ti layer, which has only four recipes that use
>
>   SRCREV = <tag name>
>
> so it wouldn't be that hard to submit a patch to adjust those, but
> then there's this in
> meta-ti/recipes-kernel/linux/linux-keystone_3.6.6.bb:
>
> # The tree tends to rebase, use literal stable tags
> SRCREV = "DEV.MCSDK-03.06.06.07"
>
>   uh ... correct me if i'm wrong but isn't it in unspeakably bad taste
> to rebase commits that have already been published?
>
>   in any event, can it be considered bad form to set SRCREV to git tag
> names?  thoughts?
>

It's worth bringing up the SRCREV_POLICY variable, which lets you control
how bitbake handles caching of srcrevs. By default, it figures it needs to
get the mapping every time (value == clear, or unset), which can make sense
in certain cases. But you can tell it to go ahead and use the values it has
cached from a previous run, as well (value == cache). This can be useful if
you know you're moving into an offline state and want to prepare for it
above and beyond the -c fetchall.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2563 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Chris Larson]

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

On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <clarson@kergoth.com> wrote:

>
> On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:
>
>> On Tue, 29 Jan 2013, Martin Jansa wrote:
>>
>> ... snip ...
>>
>> > It would be better to change SRCREV to hash corresponding to that
>> > tag and move tag only to comment above SRCREV. Such patch could be
>> > applied in upstream...
>>
>>   which brings up a larger issue ... what is the *preferred* way of
>> doing this if one was writing a style guide?  i understand developers
>> might like to set git SRCREV variables to meaningful tag names but, as
>> i've learned, that really screws up the possibility of building with
>> no network.  as it is, quite a few recipes set SRCREV to a hash ID for
>> *precisely* that reason and, in a short comment above (as you say),
>> mention the tag it corresponds to.
>>
>>   which brings me to what caused this annoyance in the first place --
>> the meta-ti layer, which has only four recipes that use
>>
>>   SRCREV = <tag name>
>>
>> so it wouldn't be that hard to submit a patch to adjust those, but
>> then there's this in
>> meta-ti/recipes-kernel/linux/linux-keystone_3.6.6.bb:
>>
>> # The tree tends to rebase, use literal stable tags
>> SRCREV = "DEV.MCSDK-03.06.06.07"
>>
>>   uh ... correct me if i'm wrong but isn't it in unspeakably bad taste
>> to rebase commits that have already been published?
>>
>>   in any event, can it be considered bad form to set SRCREV to git tag
>> names?  thoughts?
>>
>
> It's worth bringing up the SRCREV_POLICY variable, which lets you control
> how bitbake handles caching of srcrevs. By default, it figures it needs to
> get the mapping every time (value == clear, or unset), which can make sense
> in certain cases. But you can tell it to go ahead and use the values it has
> cached from a previous run, as well (value == cache). This can be useful if
> you know you're moving into an offline state and want to prepare for it
> above and beyond the -c fetchall.


Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2895 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Harvey Chapman]

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

On Jan 30, 2013, at 3:34 PM, Chris Larson <clarson@kergoth.com> wrote:

> On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <clarson@kergoth.com> wrote:
> 
> It's worth bringing up the SRCREV_POLICY variable, which lets you control how bitbake handles caching of srcrevs. By default, it figures it needs to get the mapping every time (value == clear, or unset), which can make sense in certain cases. But you can tell it to go ahead and use the values it has cached from a previous run, as well (value == cache). This can be useful if you know you're moving into an offline state and want to prepare for it above and beyond the -c fetchall.
> 
> Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/

So, should BB_NO_NETWORK=1 automatically set BB_SRCREV_POLICY=cache because the former implies the latter?


[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Robert P. J. Day]

On Wed, 30 Jan 2013, Harvey Chapman wrote:

> So, should BB_NO_NETWORK=1 automatically set BB_SRCREV_POLICY=cache
> because the former implies the latter?

  how would that have any useful effect?  by the time you set
BB_NO_NETWORK=1, you better have all those SRCREVs cached already.

rday

-- 

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

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

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Chris Larson]

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

On Wed, Jan 30, 2013 at 1:49 PM, Harvey Chapman <hchapman-oecore@3gfp.com>wrote:

> On Jan 30, 2013, at 3:34 PM, Chris Larson <clarson@kergoth.com> wrote:
>
> On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson <clarson@kergoth.com> wrote:
>
>>
>> It's worth bringing up the SRCREV_POLICY variable, which lets you control
>> how bitbake handles caching of srcrevs. By default, it figures it needs to
>> get the mapping every time (value == clear, or unset), which can make sense
>> in certain cases. But you can tell it to go ahead and use the values it has
>> cached from a previous run, as well (value == cache). This can be useful if
>> you know you're moving into an offline state and want to prepare for it
>> above and beyond the -c fetchall.
>
>
> Erm, s/SRCREV_POLICY/BB_SRCREV_POLICY/
>
>
> So, should BB_NO_NETWORK=1 automatically set BB_SRCREV_POLICY=cache
> because the former implies the latter?
>

The latter only works if you've already done a build in that tmpdir and
therefore got the cache prepopulated. So no, it should only be enabled
explicitly, indicating the user has at least considered the implications.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 2060 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Robert P. J. Day]

On Wed, 30 Jan 2013, Chris Larson wrote:

> It's worth bringing up the SRCREV_POLICY variable, which lets you
> control how bitbake handles caching of srcrevs. By default, it
> figures it needs to get the mapping every time (value == clear, or
> unset), which can make sense in certain cases. But you can tell it
> to go ahead and use the values it has cached from a previous run, as
> well (value == cache). This can be useful if you know you're moving
> into an offline state and want to prepare for it above and beyond
> the -c fetchall.

  i'm not in the least embarrassed to admit i didn't even know that
variable existed.  and, yes, that pretty much solves the problem.

  i'm still creeped out by that comment of using the tag name to deal
with rebasing a public commit, though.  :-P

rday

-- 

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

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

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Chris Larson]

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

On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:

> On Wed, 30 Jan 2013, Chris Larson wrote:
>
> > It's worth bringing up the SRCREV_POLICY variable, which lets you
> > control how bitbake handles caching of srcrevs. By default, it
> > figures it needs to get the mapping every time (value == clear, or
> > unset), which can make sense in certain cases. But you can tell it
> > to go ahead and use the values it has cached from a previous run, as
> > well (value == cache). This can be useful if you know you're moving
> > into an offline state and want to prepare for it above and beyond
> > the -c fetchall.
>
>   i'm not in the least embarrassed to admit i didn't even know that
> variable existed.  and, yes, that pretty much solves the problem.
>

Keep in mind, though, it stores it in the persist_data cache, which by
default lives inside of TMPDIR. So if you're going to set it to cache, best
move the persist dir outside of tmpdir, or just make sure you keep the
TMPDIR around.

The only reason I know the variable exists is I had to deal with this for
the Mentor Embedded Linux product releases. We wanted our engineers to be
able to point at branches, but we also wanted our customers to be able to
build without network (we ship the DL_DIR).

What we ended up doing was having our release archival process capture the
srcrev map from the persist data cache into a standalone db, ship that, and
added a class which restored that into the persist data db at the start of
a build in a new TMPDIR.  Not ideal, but got the job done for that
particular use case. For reference,
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/restore-dumped-headrevs.bbclass
does
the save/restore of the headrev map, and then we adjust our local.conf
sample we ship to set BB_SRCREV_POLICY to cache. Probably more detail than
anyone cares to know, but I'm sure we aren't the only ones that ran into
this sort of a problem, so perhaps it may be of interest.

  i'm still creeped out by that comment of using the tag name to deal
> with rebasing a public commit, though.  :-P


It depends.  There are cases where it makes sense, such as in sharing of
work which is pending upstream merge, where you might rebase each time you
submit, as long as the people cloning it are aware of the behavior of the
branch.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 3282 bytes --]

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2314 bytes --]

On Wed, 30 Jan 2013, Chris Larson wrote:

> On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Wed, 30 Jan 2013, Chris Larson wrote:
>
>       > It's worth bringing up the SRCREV_POLICY variable, which lets you
>       > control how bitbake handles caching of srcrevs. By default, it
>       > figures it needs to get the mapping every time (value == clear, or
>       > unset), which can make sense in certain cases. But you can tell it
>       > to go ahead and use the values it has cached from a previous run, as
>       > well (value == cache). This can be useful if you know you're moving
>       > into an offline state and want to prepare for it above and beyond
>       > the -c fetchall.
>
>   i'm not in the least embarrassed to admit i didn't even know that
> variable existed.  and, yes, that pretty much solves the problem.
>
> Keep in mind, though, it stores it in the persist_data cache, which
> by default lives inside of TMPDIR. So if you're going to set it to
> cache, best move the persist dir outside of tmpdir, or just make
> sure you keep the TMPDIR around.

  which is why, while these are useful features, they require
foresight and planning, and still won't do me any good if i neglect to
take advantage of them and suddenly, without warning, find myself
lacking net access.

  it's definitely frustrating to know i have all the necessary
tarballs for a build, but a fresh build will fail because some recipes
can't be parsed, especially when (i hope i'm getting this right) some
of those recipes won't even be involved in the construction of the
final image (*all* available recipes are parsed, correct?  not just
the ones that will be used to build the image.)

  so, from my perspective, it would still be good coding style to
avoid using tags as SRCREV values, period.

rday

-- 

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

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

Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing

[Martin Jansa]

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

On Wed, Jan 30, 2013 at 03:37:45PM -0500, Robert P. J. Day wrote:
> On Wed, 30 Jan 2013, Chris Larson wrote:
> 
> > It's worth bringing up the SRCREV_POLICY variable, which lets you
> > control how bitbake handles caching of srcrevs. By default, it
> > figures it needs to get the mapping every time (value == clear, or
> > unset), which can make sense in certain cases. But you can tell it
> > to go ahead and use the values it has cached from a previous run, as
> > well (value == cache). This can be useful if you know you're moving
> > into an offline state and want to prepare for it above and beyond
> > the -c fetchall.
> 
>   i'm not in the least embarrassed to admit i didn't even know that
> variable existed.  and, yes, that pretty much solves the problem.
> 
>   i'm still creeped out by that comment of using the tag name to deal
> with rebasing a public commit, though.  :-P

There is also rebaseable parameter for git:// fetcher to generate
versioned snapshot from repository and reuse that in future build
(like fetcher1 did, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=1511).

That should be used in that SRC_URI.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]