On Thu, 31 Jan 2013, Martin Jansa wrote:
> On Thu, Jan 31, 2013 at 08:43:13AM -0500, Robert P. J. Day wrote:
> > On Thu, 31 Jan 2013, Martin Jansa wrote:
> >
> > ok, there's still an issue here that crops up during the *build*.
> > after i did all the SRCREV caching, i could "fetchall" without network
> > access so that part works fine. then i started the build -- again,
> > without network access since, theoretically, i don't need it, right?
> > however:
> >
> > ERROR: Function failed: Network access disabled through BB_NO_NETWORK
> > but access requested with command git ls-remote
> > git://arago-project.org/git/projects/linux-davinci.git
> > v2.6.37_DAVINCIPSP_03.21.00.04 (for url None)
> > ERROR: Logfile of failure stored in:
> > /home/rpjday/oe/builds/ti/am1808/tmp-eglibc/work/am180x_evm-oe-linux-gnueabi/linux-omapl138-psp/2.6.37-r0/temp/log.do_unpack.20808
> > ERROR: Task 631
> > (/home/rpjday/oe/dist/layers/meta-ti/recipes-kernel/linux/linux-omapl138-psp_2.6.37.bb,
> > do_unpack) failed with exit code '1'
>
> Have you tried to set
> BB_FETCH_PREMIRRORONLY
> ?
no, but before i randomly try that, why should it make a difference?
currently, i'm using the own-mirrors bbclass which defines:
PREMIRRORS() {
cvs://.*/.* ${SOURCE_MIRROR_URL}
svn://.*/.* ${SOURCE_MIRROR_URL}
git://.*/.* ${SOURCE_MIRROR_URL}
hg://.*/.* ${SOURCE_MIRROR_URL}
bzr://.*/.* ${SOURCE_MIRROR_URL}
svk://.*/.* ${SOURCE_MIRROR_URL}
p4://.*/.* ${SOURCE_MIRROR_URL}
osc://.*/.* ${SOURCE_MIRROR_URL}
https?$://.*/.* ${SOURCE_MIRROR_URL}
ftp://.*/.* ${SOURCE_MIRROR_URL}
}
so shouldn't i be using premirrors *automatically* for every type of
fetch? i just verified that i have the tarball:
git2_arago-project.org.git.projects.linux-davinci.git.tar.gz
in my tarballs directory, which should correspond to what should be
downloaded for that recipe. so, ok, i set BB_FETCH_PREMIRRORONLY and
run:
$ bitbake core-image-minimal
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.07 (for url None)
ERROR: Command execution failed: Exited with 1
$
so i open up net access, do a fetchall *and* SRCREV cache, shut down
net access, and (with BB_FETCH_PREMIRRORONLY still set to "1"):
$ bitbake core-image-minimal
... snip ...
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access requested with command git ls-remote
git://arago-project.org/git/projects/linux-davinci.git
v2.6.37_DAVINCIPSP_03.21.00.04 (for url None)
ERROR: Logfile of failure stored in:
/home/rpjday/oe/builds/ti/am1808/tmp-eglibc/work/am180x_evm-oe-linux-gnueabi/linux-omapl138-psp/2.6.37-r0/temp/log.do_unpack.6626
Log data follows:
| DEBUG: Executing python function do_unpack
| DEBUG: Executing python function base_do_unpack
| DEBUG: Python function base_do_unpack finished
| DEBUG: Python function do_unpack finished
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access requested with command git ls-remote
git://arago-project.org/git/projects/linux-davinci.git
v2.6.37_DAVINCIPSP_03.21.00.04 (for url None)
ERROR: Task 631
(/home/rpjday/oe/dist/layers/meta-ti/recipes-kernel/linux/linux-omapl138-psp_2.6.37.bb,
do_unpack) failed with exit code '1'
$
i'm confused. am i just being an idiot about something? to recap,
i want the ability to define a new build, do whatever it takes to
"fetchall" ***everything*** that will be eventually required by this
build (with, ideally, most of it coming from my own-mirrors tarballs
directory, which i've been doing for, like, months) then be able to
build with no further for net access. so far, no luck, and it's a
small number of meta-ti recipes that are causing grief.
two points:
1) as i mentioned, the offending meta-ti recipe appears to be the
only one that specifies a non-master branch. could that *possibly* be
causing grief with SRCREV caching?
2) i've already mentioned that extending an image using
EXTRA_IMAGEDEPENDS doesn't cause that to be fetched by fetchall -- i
consider that kind of a bug, especially since numerous recipes use
EXTRA_IMAGEDEPENDS to pull in u-boot.
apologies for dragging this out but, surely, this shouldn't be that
hard to resolve.
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
