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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
