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