[oe] [oe-commits] Martin Jansa : midori: fix build with dirty vala

[Andreas Müller]

On Thursday, November 03, 2011 11:29:18 PM Martin Jansa wrote:
> On Thu, Nov 03, 2011 at 10:45:16PM +0100, Andreas Müller wrote:
> > On Thursday, November 03, 2011 01:52:48 AM Andreas Müller wrote:
> > > On Thursday, November 03, 2011 12:32:54 AM Martin Jansa wrote:
> > > > > Hm - I am afraid since this update midori never finishes
> > > > > configuring here. I waited for approximately 2 hours and stopped
> > > > > the process. The log file is attached ( a fresh retry creates
> > > > > similar log ). I commented out the whole
> > > > 
> > > > Have you tried to revert it to see that it's not caused ie by glib
> > > > changes or something? Because my vala detection change is already
> > > > finished before it writes this stuff and the tar in waf is compared
> > > > with hardcoded checksum, so it also could not change just by this
> > > > monster blob.
> > > 
> > > When sending previous mail I had two runs with and without your patch
> > > which gave me a clear picture. Now I have had some further rebuilds -
> > > seems sometimes it builds sometimes not! It's a bit late - tomorrow I
> > > would like to check further builds to see if I get a hang too with
> > > your patch reverted.
> > 
> > I created a simple script rebuilding midori again and again. I tested it
> > with your patch reverted -> I cannot tell when, but when I came back had
> > also hang on configure. So your patch is out of suspicion. For now my
> > strategy will be living with it.
> > 
> > > > Could you also check if there is something interesting in ps aux or
> > > > strace when it's "hanging"? On all 3 boxes I have tried this it
> > > > always worked as expected.
> > > > 
> > > > > | do_configure_prepend()
> > > > > 
> > > > > function, ran
> > > > > 
> > > > > | bitbake -ccleanall midori
> > > > > 
> > > > > and
> > > > > 
> > > > > | bitbake midori
> > > > > 
> > > > > without further issues in few minutes.
> > > > > 
> > > > > Maybe we should rethink this monster blob commit intended to fix a
> > > > > corner case...
> > > > 
> > > > Yes pity that this corner case is our only vala-native and I was
> > > > hopping that newer midori with newer waf-1.6 will be released soon
> > > > and this won't be needed anymore..
> > 
> > What I still do not unterstand: Since configure detetced vala correct
> > with patch reverted I ran
> > 
> > ~/tmp/oe-core-eglibc/sysroots/x86_64-linux/usr/bin/valac --version
> > 
> > I got
> > 
> > Vala 0.12.1
> > 
> > Why am I not dirty?
> 
> SHR buildhost with shr-chroot:
> OE @ ~ $ ~/shr-core/tmp/sysroots/x86_64-linux/usr/bin/valac --version
> Vala 0.12.1-dirty
> 
> my buildhost with shr-chroot:
> OE @ ~ $ ~/shr-core/tmp/sysroots/x86_64-linux/usr/bin/valac --version
> Vala 0.12.1
> 
> So right now only bad people are dirty and only sometimes.. see how they
> get dirty
:-))
> 
> vala/build-aux/git-version-gen
> ...
> # Don't declare a version "dirty" merely because a time stamp has changed.
> git status > /dev/null 2>&1
> 
> dirty=`sh -c 'git diff-index --name-only HEAD' 2>/dev/null` || dirty=
> case "$dirty" in
>     '') ;;
>     *) # Append the suffix only if there isn't one already.
>         case $v in
>           *-dirty) ;;
>           *) v="$v-dirty" ;;
>         esac ;;
> esac
> 
> shr buildhost:
> OE @ ~/shr-core/tmp/work/x86_64-linux $ git diff-index --name-only HEAD
> dev/.keep
> dev/null
> etc/group
> etc/hosts
> etc/localtime
> etc/passwd
> etc/resolv.conf
> proc/.keep
> sys/.keep
> var/cache/ldconfig/aux-cache
> var/run/utmp
> 
> and my buildhost:
> OE @ ~/shr-core/tmp/work/x86_64-linux $ git diff-index --name-only HEAD
> fatal: Not a git repository (or any parent up to mount parent
> /OE/shr-core/tmp) Stopping at filesystem boundary
> (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> 
> The difference is that my tmp/work dir is mount -o bind outside shr-chroot
> (which is itself git checkout).
This is not a corner case - sorry
> 
> So yes.. the detection in vala is not optimal and and causes false positive
> -dirty, but midori should be able to build even with really dirty
> vala_git.bb and newer waf is also fixing it like this.
agreed
> 
> If someone confirms that this patch is causing some problems I'll remove
> -dirty detection from vala completely so it will also report clean on
> really dirty vala_git.bb.
After my tests it is not modified waf causing the trouble.
> 
> Regards,
Thanks a lot for taking your time to clear up this one.

Andreas