[OE-core] Shortened git hashes causing pain
Gary Thomas
gary at mlbassoc.com
Thu May 23 23:04:11 UTC 2013
On 2013-05-23 09:28, Gary Thomas wrote:
> The shortening of the git hashes in this commit
> commit 77fc40a0f843e2488b356d90b64ef436c11c9973
> Author: Richard Purdie <richard.purdie at linuxfoundation.org>
> Date: Sun May 19 13:21:55 2013 +0300
> bitbake: fetch2: Shorten long srcrevs
> is causing some problems.
>
> I have a simple .bbappend for gtk-sato-engine (attached) which
> just applies a one-line patch. When I build this recipe, I
> get two different work trees (this is from scratch):
> $ ls -l tmp/work/cobra4430p82-amltd-linux-gnueabi/gtk-sato-engine
> total 8
> drwxrwxr-x 3 gthomas gthomas 4096 May 23 09:12 0.3.3+gitAUTOINC+4740ad8d53aba4368ce3e03b06cfdc69eb86dcdc-r0
> drwxrwxr-x 11 gthomas gthomas 4096 May 23 09:13 0.3.3+gitAUTOINC+4740ad8d53-r0
>
> Note: it doesn't seem to happen for the virgin gtk-sato-engine
> recipe, only when my patch is applied.
>
> I discovered this when I tried building in an existing tree which
> had been built before the mentioned change to the fetch code. There
> were sstate files that used the long hash that the build seemed to
> want to use but got terribly confused and ended up creating empty
> packages, breaking my build. Trying to run 'cleansstate' on the
> failing packages did nothing as the code only cleans up based on
> the new hash and left the old files still there...
>
BTW, this caused such a mess in my build tree that I nearly had to
start completely from scratch. I was able to recover only by very
drastic measures - the following steps were used on more than a dozen
packages that got confused:
find sstate-cache -name "*${PKG}*" -exec rm -fr \{} \;
rm -fr tmp/stamps/*/${PKG}
bitbake ${PKG} -c cleansstate
rm -fr tmp/work/*/${PKG}
Anything less that this giant sledge-hammer and the confusion only
continued. At least now I can build my images again...
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
More information about the Openembedded-core
mailing list