[poky] Fetch problems with PREMIRRORS

[Richard Purdie]

On Thu, 2011-02-10 at 07:51 -0700, Gary Thomas wrote:
> > Try not setting that variable at all, not setting it false. I suspect
> > there are two issues here:
> >
> > a) BB_NO_NETWORK is having an effect but the log messages are being
> >     swallowed...
> > b) "false" handling for the variable might not be working properly so
> >     leave it unset.
> >
> > We can fix those things but I'd like to confirm these are the problems
> > first.
> 
> Correct, it does seem to be the case.  When BB_NO_NETWORK="0",
> the fetcher works properly.  When set to "1", it fails, but
> no explicit error about why is generated, neither on the console
> nor in the log.do_fetch file.
> 
> I made this small change to check it out:
> diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py
> index ef9d75f..57c4f20 100644
> --- a/bitbake/lib/bb/fetch2/__init__.py
> +++ b/bitbake/lib/bb/fetch2/__init__.py
> @@ -395,6 +395,7 @@ def check_network_access(d, info = ""):
>       log remote network access, and error if BB_NO_NETWORK is set
>       """
>       if bb.data.getVar("BB_NO_NETWORK", d, True) == "1":
> +        bb.error("BB_NO_NETWORK is set, but the fetcher code attempted network access with the command %s" % info)
>           raise FetchError("BB_NO_NETWORK is set, but the fetcher code attempted network access with the command %s" % inf
>       else:
>           logger.debug(1, "Fetcher accessed the network with the command %s" % info)
> 
> This shows that this _is_ the error case, with the messages making it to
> the console and log file.  I can see that this exception is being thrown
> on line 886, but the reason is lost in the exception data & I'm unclear
> how to retrieve it and present it to the user.

This should be at least partly addressed with some of the recent commits
such as:

http://git.pokylinux.org/cgit.cgi/poky/commit/?id=ea70c4362fdb81bc9467975c145c48196c45e3af

so the debug logs (with -D) at least show whats happening.

Not perfect but better at least...

Cheers,

Richard