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
On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day rpj...@crashcourse.cawrote:
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...
On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson clar...@kergoth.com wrote:
On Wed, Jan 30, 2013 at 1:27 PM, Robert P. J. Day
rpj...@crashcourse.cawrote:
On Tue, 29 Jan 2013, Martin Jansa wrote:
... snip ...
It would be better to change SRCREV to hash corresponding to that
tag and move
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
On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day rpj...@crashcourse.cawrote:
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
On Jan 30, 2013, at 3:34 PM, Chris Larson clar...@kergoth.com wrote:
On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson clar...@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
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
--
On Wed, Jan 30, 2013 at 1:49 PM, Harvey Chapman hchapman-oec...@3gfp.comwrote:
On Jan 30, 2013, at 3:34 PM, Chris Larson clar...@kergoth.com wrote:
On Wed, Jan 30, 2013 at 1:34 PM, Chris Larson clar...@kergoth.com wrote:
It's worth bringing up the SRCREV_POLICY variable, which lets you
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
On Wed, 30 Jan 2013, Chris Larson wrote:
On Wed, Jan 30, 2013 at 1:37 PM, Robert P. J. Day rpj...@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
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
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
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
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
14 matches
Mail list logo
