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

[Martin Jansa]

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).

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.

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.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20111103/e68acd27/attachment-0002.sig>