It's possible, when using file:// uris in SSTATE_MIRRORS, to see dumps of fetch errors with a dump of the FILESPATH it was searching, for example: ERROR: Fetcher failure: Unable to find file file://Ubuntu-12.04/f0/sstate-quilt-native-x86_64-linux-0.60-r0-x86_64-3-f0a7abcdce876cacbbaa33fadfd49ea6_populate-lic.tgz.siginfo anywhere. The paths that were searched were: /scratch/test/poky/meta/recipes-devtools/quilt/quilt-0.60/x86-64 /scratch/test/poky/meta/recipes-devtools/quilt/quilt-0.60/armv7a /scratch/test/poky/meta/recipes-devtools/quilt/quilt-0.60/marzenh1 /scratch/test/poky/meta/recipes-devtools/quilt/quilt-0.60/mel /scratch/test/poky/meta/recipes-devtools/quilt/quilt-0.60/ /scratch/test/poky/meta/recipes-devtools/quilt/quilt/x86-64 /scratch/test/poky/meta/recipes-devtools/quilt/quilt/armv7a /scratch/test/poky/meta/recipes-devtools/quilt/quilt/marzenh1 /scratch/test/poky/meta/recipes-devtools/quilt/quilt/mel /scratch/test/poky/meta/recipes-devtools/quilt/quilt/ /scratch/test/poky/meta/recipes-devtools/quilt/files/x86-64 /scratch/test/poky/meta/recipes-devtools/quilt/files/armv7a /scratch/test/poky/meta/recipes-devtools/quilt/files/marzenh1 /scratch/test/poky/meta/recipes-devtools/quilt/files/mel /scratch/test/poky/meta/recipes-devtools/quilt/files/ /scratch/test/build/cached-binaries Clearly this isn't something the user needs to see or is ever likely to care about, as the failure mode just results in rebuilding something if the sstate archive and corresponding siginfo weren't available. It does seem that I see this more often with the siginfo than the sstates for some reason, but I think we need to rethink the fetchers print of log messages at all in this case, and instead let it pass off the print of the message to the caller.
Aside: we may also want to think about emptying the default FILESPATH when fetching sstates, as I doubt we care about the standard search paths in that case :)
Are working this one?
Perhaps. We can implement a hacky workaround: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?h=dylan&id=277d52a or we can fix it more properly, changing how fetch2 handles errors, but that would require coordination between the bitbake change and the change to uses of fetch2 in oe-core. fetch2 is Richard's baby, so I'd be curious to hear his opinion on this before beginning further work on the ideal fix, but barring any objections I'll submit the workaround to oe-core as a temporary measure.
Ideally we should fix this properly, I'm quite happy to have the fetcher beaten into submission to fix this kind of issue properly. We can handle sync between bitbake and OE-Core at this point in the release cycle, obviously in a month or two, it will be more problematic. Can you confirm the workaround does work ok with bitbake master after the bitbake-worker changes. Initially I didn't think it would but now I look at it again, it should be fine so we probably could merge that. It is a bit of a hack though :/.
The workaround definitely still works, but I'm hoping to find the time soon to look at a better fix in fetch2.
I think this may be gone when using downloadfilename=PATH. Will re-open if it comes back.