[poky] Fetch problems with PREMIRRORS

[Richard Purdie]

On Wed, 2011-02-09 at 06:40 -0700, Gary Thomas wrote:
> Per Richard's suggestion, I have added this to my DISTRO.conf:
> 
> # Provide pre-staged sources
> PREMIRRORS = "\
> http://.*/.*   file:///work/misc/Poky/sources/ \n \
> https://.*/.*   file:///work/misc/Poky/sources/ \n \
> ftp://.*/.*   file:///work/misc/Poky/sources/ \n \
> bzr://.*/.*   file:///work/misc/Poky/sources/ \n \
> cvs://.*/.*   file:///work/misc/Poky/sources/ \n \
> git://.*/.*   file:///work/misc/Poky/sources/ \n \
> hg://.*/.*    file:///work/misc/Poky/sources/ \n \
> osc://.*/.*   file:///work/misc/Poky/sources/ \n \
> p4://.*/.*    file:///work/misc/Poky/sources/ \n \
> svk://.*/.*   file:///work/misc/Poky/sources/ \n \
> svn://.*/.*   file:///work/misc/Poky/sources/ \n"
> 
> The tree '/work/misc/Poky/sources' is a fully populated source
> cache.
> 
> This all works great as long as the needed sources are in
> the cache.  However, there seems to be no fallback if they
> are not present.  I get errors like this:
> | NOTE: fetch http://pokylinux.org/sources/git2_github.com.wrpseudo.pseudo.git.tar.gz
> | NOTE: fetch http://autobuilder.pokylinux.org/sources/git2_github.com.wrpseudo.pseudo.git.tar.gz
> | ERROR: Function 'Fetcher failure for URL: 'git://github.com/wrpseudo/pseudo.git;protocol=git'. Unable to fetch URL git://github.com/wrpseudo/pseudo.git;protocol=git from any 
> source.' failed
> NOTE: package pseudo-native-0.0+git1+5434325fc887817ebb2bad36313d8277992cef1d-r18: task Fetcher failure for URL: 'git://github.com/wrpseudo/pseudo.git;protocol=git'. Unable to 
> fetch URL git://github.com/wrpseudo/pseudo.git;protocol=git from any source.: Failed
> 
> In order to actually fetch, I have to remove the PREMIRRORS
> from my conf.
> 
> Is there some way to get it to use the source cache but
> still fetch when needed?
> 
> Thanks
> 
> Note: I also normally have BB_NO_NETWORK="1", but that is not
> applicable here (no message about it) and setting it false does
> not change the behaviour.

It is applicable.

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.

Cheers,

Richard