4499 2013-05-15 20:29:47 +0000 sstate archive/siginfo fetch can display errors to the user on fetch failure 2014-10-27 18:09:24 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED INVALID Medium normal 1.7 1 kergoth kergoth jessica.zhang poky.bs.watcher poky.watcher richard.purdie sgw --- --- Don't know oldest_to_newest 33099 0 kergoth 2013-05-15 20:29:47 +0000 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. 33100 1 kergoth 2013-05-15 20:30:41 +0000 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 :) 33105 2 sgw 2013-05-16 06:58:26 +0000 Are working this one? 33119 3 kergoth 2013-05-16 14:13:34 +0000 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. 34139 4 richard.purdie 2013-06-25 22:42:54 +0000 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 :/. 39878 5 kergoth 2014-01-16 18:42:06 +0000 The workaround definitely still works, but I'm hoping to find the time soon to look at a better fix in fetch2. 46599 6 kergoth 2014-10-27 18:09:24 +0000 I think this may be gone when using downloadfilename=PATH. Will re-open if it comes back.