Have a look at using:
BB_NO_NETWORK = "1"
in your local.conf. This will deny bitbake all access to the network and
will effectively freeze your build.
However, issuing a bitbake command usually won't fetch new sources
unless the underlying recipes have changed; so this should really be
what you try to tackle; the BB_NO_NETWORK is a bit of a workaround which
isn't really designed for this purpose.
Cheers,
Jack.
On 28/06/2013 19:21, Charles Nicholson wrote:
Hi all,
First off, thanks a lot for the Angstrom effort, it's a great distro and
we're committing to use it on BeagleBone Blacks to manage our automated
test rack at work.
We are trying to figure out the best way to capture a full Angstrom
codebase snapshot so that we can iterate locally on it and make private
changes. I see that invoking "bitbake virtual/kernel" performs an update
before doing a build, so our current strategy is failing.
My naive first attempt to capture Angstrom was to pull it down and do a
full build as per the instructions on the Angstrom site. After confirming
that this gave me a good output image, I deleted the entire /build
directory, and then recursively deleted the .git metadata ("find . -type d
-name ".git" -exec rm -rf {}\;"). I committed the results to our local
private git repository.
When our build slave machine tries to sync and build, it gives us this:
MACHINE=beaglebone ./oebb.sh bitbake console-image
col: write error
grotty:<standard input> (<standard input>):25092:fatal error: output error
WARNING!!!!
WARNING: bitbake is using a different uri
'g...@git.mycompany.com:hardware/bbb-angstrom.git' than configured in
layers.txt 'git://github.com/openembedded/bitbake.git'
WARNING: Changing uri to: 'git://github.com/openembedded/bitbake.git'
WARNING!!!!
Fetching origin
This makes sense, because the conf/layers.txt file references all of
the subprojects on the public github.
Can I tell bitbake to use the local versions? Do I need to host each
subproject on our internal git and point layers.txt towards that? Is
what I'm doing sensible? :)
All advice, comments, flames welcome, and thanks for taking the time
to read this.
Best Regards,
Charles Nicholson
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
