On Mon, 28 Jan 2008 00:49:57 +0000 Richard Purdie <[EMAIL PROTECTED]> wrote:
> 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. Hm, will check. > > > 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"! Well, that's local debug message, please ignore ;-). I meant bb.fatal('Cannot fetch local file: %s, FILESPATH="%s", FILESDIR="%s"' % (url, filespath, filesdir)) > 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. Exactly. That's why I'm using .note() for local debug - because current loglevels are rather messy. Even having -D spams few thousand of terminal lines with completely uninteresting in this case messages about parsing/caching. I finally lost patience and did: --- lib/bb/cache.py (revision 1009) +++ lib/bb/cache.py (working copy) @@ -199,8 +199,8 @@ new_mtime = bb.parse.cached_mtime(f) if (new_mtime > old_mtime): - bb.msg.debug(2, bb.msg.domain.Cache, "Cache: %s's dependency %s changed" % (fn, f)) + bb.msg.debug(3, bb.msg.domain.Cache, "Cache: %s's dependency %s changed" % (fn, f)) return False bb.msg.debug(2, bb.msg.domain.Cache, "Depends Cache: %s is clean" % fn) Index: lib/bb/cooker.py =================================================================== --- lib/bb/cooker.py (revision 1009) +++ lib/bb/cooker.py (working copy) @@ -676,7 +676,7 @@ for i in xrange( len( filelist ) ): f = filelist[i] - bb.msg.debug(1, bb.msg.domain.Collection, "parsing %s" % f) + bb.msg.debug(3, bb.msg.domain.Collection, "parsing %s" % f) # read a file's metadata try: IMHO, the idea should be: messages during startup, and generally, about global bitbake's stuff should have lower level, and one directly pertinent to the package being built - higher. > > 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? Please see my latest OE commits for background. Quickly put, the path was: 1. bluez-cups-backend 3.23 failed on patching hciattach-ti-bts.patch 2. I knew that there's good 3.23 patch for bluez-utils. 3. Finally found that due to fact that package name is different from bluez-utils, it pulls from wrong override dir which happened to have old version of that patch. Bitbake didn't provide good diagnosis for this case, took patching it to figure out. Now fixed in OE. 4. Started to play with FILESPATH/FILESDIR, just to face error above. Again, no good diagnostics from BB. 5. Finally after more patching bitbake, figured that I did a thinko and put too little stuff into FILESPATH. I understand that such check can be likely done on OE level, but I put it into BB exactly for good context diagnostics, which probably would be harder/less clean on OE level. > > Cheers, > > Richard > > _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
