Hi Paul, On Mon, 2008-01-28 at 01:41 +0200, Paul Sokolovsky wrote: > It seems that Local fetcher in bitbake doesn't bother to check for file > existence under some conditions. This will result in obscure build > failures, like: > > NOTE: package bluez-cups-backend-3.23-r0: task do_unpack: started > NOTE: Unpacking /usr/portage/distfiles/bluez-utils-3.23.tar.gz > to > /home/pfalcon/linux-ppc/build-oe-angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/bluez-cups-backend-3.23-r0/ > NOTE: > Unpacking > /home/pfalcon/linux-ppc/build-oe-angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/bluez-cups-backend-3.23-r0 > to > /home/pfalcon/linux-ppc/build-oe-angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/bluez-cups-backend-3.23-r0/ > cp: cannot copy a directory, > `/home/pfalcon/linux-ppc/build-oe-angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/bluez-cups-backend-3.23-r0', > into itself, > `/home/pfalcon/linux-ppc/build-oe-angstrom/tmp/work/armv5te-angstrom-linux-gnueabi/bluez-cups-backend-3.23-r0/./bluez-cups-backend-3.23-r0' > NOTE: Task failed: NOTE: package bluez-cups-backend-3.23-r0: task > do_unpack: failed > > (Here Local.localpath() returned ""). > > I made a patch to catch this. It really needs more testing (who knows, > maybe lack of validation is by design, and it should be put > elsewhere ;-) ), so here's for review.
I haven't verified this but I'm fairly sure this breaks at least one existing use case where you specify a patch to apply from some other url e.g.: SRC_URI = "http://somewhere/some_tarball_containing_patch.tgz \ file://patch_from_tarball.patch;patch=1" This happens to be really handy for applying tarballs of patches which are released by upstreams such as LTTng. > Note the relevant context dumped > in error - it's very important to improve bitbake's diagnostics which > is by now mostly useless from outsider's point of view (and for > non-outsiders it may take hours to debug a problem), if we want to bring > more people to OE. As per the last bitbake release announcement, this is an intention however we can be more informative than "fetching stuff in %s"! Also, we need to start caring about the loglevels these messages use. In the case of that message, note is inappropriate, it should be debug since its not useful for the user to see it in normal use. As for the underlying problem here, I think we need to give it more thought. Can you describe the problem which caused the error above please? Cheers, Richard _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
