On Wed, 1 Apr 2015, Bruce Ashfield wrote: ... again, snip ...
> I completely agree .. better to sort this out sooner rather than > later, I'm just trying to narrow down on a configuration that allows > me to see the problem and poke at the smouldering pile. If git is > doing something different now, it won't be hard to fix, but hands > on, versus code inspection, is the real trick here. ok, now i'm confused about where i'm getting my kernel source from. with a fresh build for qemux86 and deliberately not using any of my local mirror content, i did: $ bitbake -c fetchall linux-yocto assuming the fetch would take a while due to, you know, git checkout. the first puzzler is that my downloads directory very quickly contained (among other things): -rw-rw-r--. 1 rpjday rpjday 81688872 Feb 8 22:20 linux-3.19.tar.xz should i have expected that? why do i suddenly have what looks like a stock linux-3.19 tarball when git should be used for this? and here's the salient bit from the fetch log file, clearly showing a sizable tarball being downloaded from downloads.yoctoproject.org: ///// START ///// DEBUG: For url git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/common-pc,meta;name=machine,meta returning http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz ... cut ... DEBUG: Fetching http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz using command '/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/rpjday/oe/builds/qemux86/downloads 'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz'' DEBUG: Fetcher accessed the network with the command /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/rpjday/oe/builds/qemux86/downloads 'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz' /// END /// that tarball is 927M as you can see here: http://downloads.yoctoproject.org/mirror/sources/ dated mar 24, so that's fairly new and makes me wonder if there's something weird/broken about it. waiting for wget to finish ... ok, done. now try to cuild: $ bitbake linux-yocto hmmmmmmm ... and it's already blown by the validate_branches task, so suddenly, no problem. weird. it is entirely possible that, because i was using a local mirror loaded with tarballs, an earlier kernel tarball was being picked up and wasn't compatible with later content. after dropping any reference to my local mirror, validate_branches appears to work. still curious as to the presence of the linux-3.19 xz tarball in my downloads directory. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto