**** BEGIN LOGGING AT Sun Nov 27 02:59:57 2011
Nov 27 06:11:13 <PaulFertser> antrik: if one can specify EBNF right in the source code and an appropriate parser will be generated for him, i fail to see how this is not truely high-level.
Nov 27 07:24:16 <DocScrutinizer> yacc?
Nov 27 07:24:52 <DocScrutinizer> ooh c++
Nov 27 10:31:59 <CIA-38> SHR: 03Martin.Jansa 07shr-chroot * r4aaec5db7eb7 10/ (87 files in 18 dirs): system upgrade
Nov 27 10:38:00 <CIA-38> SHR: 03Martin.Jansa 07shr-chroot * r0f493a5b417f 10/ (29 files in 9 dirs): bitbake upgrade
Nov 27 12:03:54 <nschle85> JaMa|Off: hello if you have time can you please have a look at: http://norman-schleicher.de/jenkins/job/shr-core-n900-2/12/console
Nov 27 12:05:32 <GNUtoo> nschle85, maybe ask morphis instead?
Nov 27 12:05:33 <nschle85> JaMa|Off: next problem at home is: Log data follows: | ERROR: Function 'do_install' failed (see /home/nschle85/build-core-shr/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/phonet-utils-0.0.0+gitr1+4acfa720fd37d178a048fc2be17180137d4a70ea-r0/temp/log.do_install.3336 for further information) | + cd /home/nschle85/build-core-shr/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/ph
Nov 27 12:06:35 <nschle85> http://pastebin.com/FTfDibtk
Nov 27 12:08:02 <GNUtoo> for the second problem try to look at the Makefile
Nov 27 12:08:12 <GNUtoo> and look if you can pass it ${D}
Nov 27 12:16:13 <nschle85> GNUtoo: strange, do_install () {     DESTDIR=${D} oe_runmake install }
Nov 27 12:16:46 <nschle85> that should work but doesnt
Nov 27 12:16:49 <GNUtoo> nschle85, try to debug it
Nov 27 12:22:59 <GNUtoo> for instance try to rerun  temp/run.do_install
Nov 27 12:23:03 <GNUtoo> and look what happens
Nov 27 12:23:19 <GNUtoo> nschle85, do you want me to build an image for n900?
Nov 27 12:23:33 <JaMa|Off> and for ffalarms we probably need to patch it for newer vala
Nov 27 12:24:02 <JaMa|Off> we can try to do something similar to what morphis did in all cornucopia projects
Nov 27 12:24:06 <PaulFertser> nschle85: yes, the second problem seem to be that "/usr/sbin/$f" is probably hardcoded in the phonet-utils Makefile.
Nov 27 12:24:15 <JaMa|Off> or bug lukas to fix it
Nov 27 12:25:27 <PaulFertser> JaMa|Off: i think valac producing critical assertions is wrong anyway and if that's a reasonably new version it worth reporting, no?
Nov 27 12:27:15 <GNUtoo> nschle85, pastebin your Makefile
Nov 27 12:27:20 <GNUtoo> mine seem different
Nov 27 12:27:52 <GNUtoo>                 $(INSTALL) -D -m 0755 "$$f" "$(DESTDIR)$(sbindir)/$$f" || exit $$? ; \
Nov 27 12:27:59 <GNUtoo> that's what I have
Nov 27 12:28:05 <nschle85> Makefile http://pastebin.com/EpJLWd65
Nov 27 12:28:17 <PaulFertser> JaMa|Off: or is it possible it's host's valac being run with custom VAPIDIR?
Nov 27 12:28:37 <JaMa|Off> PaulFertser: yes, but iirc morphis said that newer vala doesn't support dbus-glib anymore and that's what's used in ffalarms
Nov 27 12:28:49 <GNUtoo> /usr/sbin not found in your Makefile
Nov 27 12:28:57 <PaulFertser> JaMa|Off: it shouldn't produce critical assertions anyway :) 
Nov 27 12:29:14 <JaMa|Off> agreed on this part
Nov 27 12:29:14 <GNUtoo> maybe a problem with DESTDIR then
Nov 27 12:29:39 <GNUtoo> did you already tried cleansstate and rebuild phonet-utils?
Nov 27 12:30:30 <nschle85> GNUtoo: yes
Nov 27 12:31:42 <GNUtoo> try to see what's in ${D}
Nov 27 12:31:45 <GNUtoo> with bitbake -e
Nov 27 12:31:55 <PaulFertser> nschle85: you won't be able to compile ffalarms without modifications with this vala version anyway, so remove it from the build i'd say.
Nov 27 12:31:59 <GNUtoo> like bitbake -e phonet-utils > file.txt
Nov 27 12:35:45 <nschle85> http://pastebin.com/cBCgTm2i is that enough or should i upload the whole file ?
Nov 27 12:36:32 <GNUtoo> ket me look
Nov 27 12:36:44 <GNUtoo> I'm looking for ${D}
Nov 27 12:36:52 <GNUtoo> or D_${PN}
Nov 27 12:37:00 <GNUtoo> or something like that
Nov 27 12:37:17 <GNUtoo> altough I don't think D_${PN} exists
Nov 27 12:41:24 <nschle85> http://pastebin.com/RQ9HuDj5 the whole output, i cannot find ${D}
Nov 27 12:44:01 <GNUtoo> D="/home/nschle85/build-core-shr/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/phonet-utils-0.0.0+gitr1+4acfa720fd37d178a048fc2be17180137d4a70ea-r0/image"
Nov 27 12:44:05 <GNUtoo> # D=${WORKDIR}/image
Nov 27 12:44:28 <GNUtoo> also look do_install() {
Nov 27 12:44:50 <GNUtoo> it's indeed passed
Nov 27 12:55:17 <nschle85> GNUtoo: doing this on commandline works: http://pastebin.com/RJ1kZBq2
Nov 27 12:56:05 <nschle85> and this is the recipe: http://cgit.openembedded.org/meta-openembedded-contrib/tree/meta-oe/recipes-connectivity/phonet-utils/phonet-utils_git.bb?h=shr
Nov 27 12:57:07 <GNUtoo> wait a second....
Nov 27 12:58:19 <GNUtoo> hmmm
Nov 27 12:58:31 <GNUtoo> you must find a way to pass it ${D}
Nov 27 12:59:02 <nschle85> is the install line in the recipe wrong ?
Nov 27 13:00:13 <GNUtoo> no idea
Nov 27 13:00:25 <GNUtoo> if you want I can try to reproduce
Nov 27 13:00:36 <GNUtoo> but....
Nov 27 13:00:37 <GNUtoo> NOTE: package shr-lite-image-2.0-r18: task do_rootfs: Started
Nov 27 13:00:43 <GNUtoo> so for me it worked
Nov 27 13:01:56 <nschle85> but i have it also installed on my host 
Nov 27 13:02:05 <nschle85> that may be the difference
Nov 27 13:02:33 <GNUtoo> ok
Nov 27 13:02:39 <GNUtoo> try to remove on your host
Nov 27 13:02:42 <GNUtoo> and retry
Nov 27 13:03:02 <GNUtoo> if it works at least we know the cause and can tell in the commit message
Nov 27 13:03:21 <angelox|laptop> good morning guys
Nov 27 13:04:03 <nschle85> angelox|laptop: hello , today is formula 1 day :-)
Nov 27 13:05:59 <nschle85> GNUtoo: same effect
Nov 27 13:07:25 <nschle85> GNUtoo: ahhhhhhhhhhh
Nov 27 13:07:38 <nschle85> i updated also my computer and now i have dash 
Nov 27 13:07:51 <nschle85> ill revert to bash
Nov 27 13:08:30 <mrmoku> PaulFertser: do you know of any toolkit bindings being done in a boost-like manner?
Nov 27 13:12:27 <nschle85> sorry guys for taken your time: NOTE: package phonet-utils-0.0.0+gitr1+4acfa720fd37d178a048fc2be17180137d4a70ea-r0: task do_install: Succeeded
Nov 27 13:12:59 <nschle85> the build doues not work with dash
Nov 27 13:13:18 <angelox|laptop> nschle85: :) but unfortunately my little brother watches woody woodpecker all the day on TV :S
Nov 27 13:18:52 <nschle85> so now i have to go bye...
Nov 27 13:18:57 <nschle85> thank you
Nov 27 13:28:29 <antrik> PaulFertser: so, C++ has one specific language feature that can be (ab)used to do some serious metaprogramming in a weird backwards kind of fashion if you get a hang on it (and your compiler can cope), which some wizards used to create a few useful libraries
Nov 27 13:30:29 <antrik> compare that to D for example, where *all* language features can be used for compile-time metaprogramming as well as at runtime; or Lisp, which also has compile-time and run-time evaluation, along with two extremely levels of extremely powerful macro systems; or Haskell, which doesn't have macros (and thus a more rigid syntax), but an extremely powerful type system, lazy evaluation, and all sorts of complex reductions done by the co
Nov 27 13:31:14 <antrik> yes, it *is* impressive what can be squeezed out of C++ if you try hard enough -- but it really doesn't compare to true high-level languages
Nov 27 13:31:34 <GNUtoo> like C?
Nov 27 13:31:44 <GNUtoo> (joking)
Nov 27 13:31:53 <GNUtoo> C is high level
Nov 27 14:28:52 <PaulFertser> antrik: very good and sound reasoning indeed.
Nov 27 14:30:20 <PaulFertser> antrik: but does this weird unexpectedly powerful feature make C++ more flexible and more high-level comparing to, say, Java? Or Vala?
Nov 27 15:18:17 <antrik> let's not talk about Java here. it's clear that C++ is superior to Java in most regards :-)
Nov 27 15:19:40 <antrik> I'm not familiar enough with Vala to make a good judgement; but from what I know so far, my *guess* is that it's much more convenient for using high-level constructs
Nov 27 15:21:05 <antrik> (and at any rate, it probably doesn't have the syntax uglyness introduced by C++ :-P )
Nov 27 15:22:32 * angelox|laptop agrees that C++ is much more superior than Java :)
Nov 27 15:52:52 <PaulFertser> antrik: my local C++ guru says that ``Tough Siberian guys said "yep" and resumed coding C++''
Nov 27 15:55:25 <PaulFertser> (Using C++ in production you get more guarantees of stability; and also more "understanding" from the technical management folks; it's also easier to find someone who's already familiar with the job)
Nov 27 15:56:28 <antrik> and less enthusiastic programmers :-P
Nov 27 15:56:41 <PaulFertser> That too...
Nov 27 15:56:54 <antrik> I probably haven't bookmarked it; but there is a very nice article why using a fringe language can actually be a *smart* business decision...
Nov 27 19:15:00 <nschle85> can anybody bums srcrev of ffalarms please ? i cheked, that this version compiles. http://pastebin.com/JS0MdQFY
Nov 27 19:15:09 <nschle85> bump
Nov 27 19:15:38 <GNUtoo> nschle85, hi
Nov 27 19:16:00 <GNUtoo> nschle85, is ffalarms autorev?
Nov 27 19:16:36 <nschle85> what does it mean ?
Nov 27 19:16:44 <GNUtoo> let me look then
Nov 27 19:16:56 <GNUtoo> some stuff is in shr-autorev.inc
Nov 27 19:17:23 <GNUtoo> so if you include shr-autorev.inc the stuff that is inside go fetch and build the last version instead of the revision that is in the recipe
Nov 27 19:18:01 <mrmoku> GNUtoo: it needs bumping nevertheless
Nov 27 19:18:16 <GNUtoo> ok
Nov 27 19:18:37 <nschle85> see pastebin
Nov 27 19:18:40 <GNUtoo> mrmoku, can you bump it then?
Nov 27 19:18:51 <mrmoku> not now... later
Nov 27 19:18:56 <GNUtoo> ok
Nov 27 19:19:07 <GNUtoo> nschle85, could you send a patch rather?
Nov 27 19:19:16 <GNUtoo> so you have your name etc... inside
Nov 27 19:20:19 <nschle85> how to send the patch ? i think i am not a member of the mailing list
Nov 27 19:20:49 <nschle85> but its not necessary to add my name its a simple srcbump
Nov 27 19:21:01 <nschle85> now intelligent behind
Nov 27 19:21:28 <GNUtoo> if you want I can push for you
Nov 27 19:21:37 <nschle85> yes please
Nov 27 19:21:46 <GNUtoo> but that won't include your name as author
Nov 27 19:21:56 <GNUtoo> I'll mention you in the commit message tough
Nov 27 19:21:57 <nschle85> it does not matter, 
Nov 27 19:22:13 <GNUtoo> ok
Nov 27 19:22:14 <nschle85> GNUtoo: its only a newer hash sum :-)
Nov 27 19:22:48 <nschle85> the main work as done in ffalarms but that was not my work
Nov 27 19:25:05 <pespin> mrmoku, expect more eflvala breakage in near future ;)
Nov 27 19:25:20 <pespin> I just catched a new api change (homogenous -> homogeneous)
Nov 27 19:25:34 <pespin> which makes current eflvala in svn not compile
Nov 27 19:25:50 <pespin> I'm working together with zub in a new eflvala which is now in gitorious
Nov 27 19:25:57 <pespin> as we'll need to change how it's used
Nov 27 19:26:26 <pespin> basically, no more constructors for widgets -> elm_*_add() returns unowned objects
Nov 27 19:26:46 <pespin> that will probably break old apps though ;)
Nov 27 19:29:13 <GNUtoo> ok testing the chenage
Nov 27 19:29:15 <GNUtoo> *change
Nov 27 19:44:07 <mrmoku> pespin: np, over the years I got used to things breaking apart ;)
Nov 27 19:45:24 <pespin> mrmoku, hopefully once we are done with this work it will be a lot easier to write in EFL + vala :)
Nov 27 19:45:56 <mrmoku> :)
Nov 27 19:46:19 * mrmoku is still undecided what to use for his tp app ...
Nov 27 19:46:32 <mrmoku> wanted to take a look at the e c++ bindings ;)
Nov 27 19:47:44 <GNUtoo> it's recompiling the toolchain...
Nov 27 19:48:10 <pespin> Now I can't continue with my etalk app as complex genlists are currently unusable from the vapi arch we have right now
Nov 27 19:51:22 <nschle85> mrmoku: what is a "tp app" ?
Nov 27 19:54:40 <mrmoku> nschle85: telepathy
Nov 27 19:55:00 <mrmoku> nschle85: I want to do a telepathy telephony app
Nov 27 19:55:19 <mrmoku> to be usable on my desktop _and_ my phone
Nov 27 19:56:57 <nschle85> empathy is no option ?
Nov 27 19:58:33 <mrmoku> I'm using empathy right now... but it sucks for telephony
Nov 27 19:59:00 <nschle85> ok i understand
Nov 27 20:13:47 <GNUtoo> nschle85, ok I'll push as soon as it finishes all the builds
Nov 27 20:13:51 <GNUtoo> NOTE: package ffalarms-0.4+gitr3+afe78a44dd164c6083d79981211e80e96bfe1914-r1: task do_package_write_ipk: Started => it builds fine
Nov 27 20:27:24 <nschle85> ok thank you
Nov 27 20:27:58 <GNUtoo> mrmoku, there is no PR in ffalarms
Nov 27 20:28:06 <GNUtoo> should I add PR="r1"
Nov 27 20:28:24 <GNUtoo> or did something change with git versions + version count
Nov 27 20:29:09 <GNUtoo> mrmoku, ping
Nov 27 20:29:13 <GNUtoo> I want to push soon
Nov 27 20:29:35 <mrmoku> GNUtoo: with git SRCREV bump changing PR is not needed I think
Nov 27 20:29:43 <mrmoku> won't harm though
Nov 27 20:29:54 <GNUtoo> ok
Nov 27 20:30:03 <GNUtoo> I tought it was not needed only for svn
Nov 27 20:30:11 <GNUtoo> because git is not sortable
Nov 27 20:30:30 <mrmoku> but it adds gitrX in front
Nov 27 20:30:38 <mrmoku> and the PR comes after the git hash anyway
Nov 27 20:30:41 <GNUtoo> that's when you use autorev
Nov 27 20:30:43 <GNUtoo> right?
Nov 27 20:30:48 <GNUtoo> yes it comes after
Nov 27 20:31:06 <GNUtoo> but how is gitX generated
Nov 27 20:31:09 <mrmoku> only for autorev?
Nov 27 20:31:11 <mrmoku> hmm
Nov 27 20:31:15 <GNUtoo> I mean take the case where you have 2 builders
Nov 27 20:31:18 <GNUtoo> not using autorev
Nov 27 20:31:26 <GNUtoo> will they get the same gitrX?
Nov 27 20:31:39 <mrmoku> what ffalarms package do we have in the feed?
Nov 27 20:31:44 <GNUtoo> the ruls is that they should get the same gitrX
Nov 27 20:31:47 <GNUtoo> no idea
Nov 27 20:33:44 <mrmoku> it has gitr2 in front
Nov 27 20:33:50 <mrmoku> all fine :)
Nov 27 20:33:53 <mrmoku> no PR needed
Nov 27 20:33:59 <mrmoku> when SRCREV changes
Nov 27 20:35:29 <GNUtoo> ok
Nov 27 20:35:41 <GNUtoo> but will 2 different build host get gitr2?
Nov 27 20:36:01 <GNUtoo> like if you build one from scratch and one with already 10 different revision built
Nov 27 20:36:09 <GNUtoo> JaMa|Off, ^^^
Nov 27 20:36:30 <mrmoku> no
Nov 27 20:37:01 <mrmoku> they won't get the same gitr
Nov 27 20:37:07 <GNUtoo> so that's a problem
Nov 27 20:37:09 <mrmoku> if they don't share the cache
Nov 27 20:37:14 <GNUtoo> indeed 
Nov 27 20:37:15 <mrmoku> why?
Nov 27 20:37:23 <mrmoku> it is like that for a long time now
Nov 27 20:37:30 <GNUtoo> it may be fine for SHR but not for angstrom
Nov 27 20:37:46 <GNUtoo> and machine repos are in angstrom
Nov 27 20:37:51 <GNUtoo> so we might get in trouble 
Nov 27 20:38:03 <mrmoku> ?
Nov 27 20:38:39 <GNUtoo> meta-openmoko, meta-nokia etc... are used by angstrom
Nov 27 20:39:00 <mrmoku> ok, but the only solution for angstrom is to share the data between multiple buildhosts
Nov 27 20:39:08 <GNUtoo> with autorev?
Nov 27 20:39:12 <GNUtoo> do they use autorev?
Nov 27 20:39:19 <mrmoku> whatever... JaMa|Off for sure knows more about that
Nov 27 20:39:30 <GNUtoo> anyway there is an easy fix:
Nov 27 20:39:43 * mrmoku has to fix his e ... as working on a pure console is unsufficient
Nov 27 20:39:47 <GNUtoo> PV = "0.4+gitr${SRCPV}"
Nov 27 20:40:01 <GNUtoo> let's just change that?
Nov 27 20:40:27 <GNUtoo> like PV= "0.4-${PR}+gitr${SRCPV}"
Nov 27 20:40:41 <GNUtoo> or I bump and jama will fix
Nov 27 20:41:07 <nschle85> GNUtoo: how are the bumps done before ?
Nov 27 20:41:34 <GNUtoo> mrmoku, did a bump without PR before
Nov 27 20:42:27 <GNUtoo> but not JaMa
Nov 27 20:42:39 <mrmoku> that's what JaMa|Off told me once... bumping SRCREV does not require PR bump
Nov 27 20:42:43 <mrmoku> but do whatever you want
Nov 27 20:42:51 * mrmoku wants his desktop back
Nov 27 20:43:05 <GNUtoo> but with svn or git?
Nov 27 20:43:28 <antrik> GNUtoo: you can always set --author by hand...
Nov 27 20:43:58 <GNUtoo> yes but what would I put inside etc...
Nov 27 20:44:05 <nschle85> GNUtoo: http://git.shr-project.org/git/?p=meta-smartphone.git;a=blobdiff;f=meta-shr/recipes-shr/3rdparty/ffalarms_git.bb;h=afb37600bb2a579b63e7f132641b23572803a03f;hp=d43e72826b5569a1bd6d3e554334908a7fbbb81c;hb=71612da602f83b941c5891a1475c41415e0a5667;hpb=11883c7175fa44f76d69046eea31065ab5fd29d5
Nov 27 20:44:18 <nschle85> jama did remove PR
Nov 27 20:44:48 <GNUtoo> ok
Nov 27 20:48:49 <CIA-38> SHR: 03GNUtoo 07meta-smartphone * ra11089c4a2b0 10/meta-shr/recipes-shr/3rdparty/ffalarms_git.bb: meta-smartphone: meta-shr: ffalarms: bump SRCREV
Nov 27 20:49:51 <nschle85> GNUtoo: thank you, 
Nov 27 20:50:25 <GNUtoo> np
Nov 27 21:20:31 <taruti> what is the status of xrandr -o 1?
Nov 27 21:32:07 <pespin> nice, I'm moving etalk to the new vapi and seems genlists do work as expected now :D
Nov 27 21:34:54 <pespin> so new etalk + new vapi can be used for chatting in 1to1 conversations now  ;)
Nov 27 21:36:36 <pespin> GNUtoo, little git question for a git noob -> if I created a new branch in my etalk git repo locally, and I do "git push", the branch will be created in origin too (gitorious) and changes pushed in that branch?
Nov 27 21:44:10 <GNUtoo> git push origin local_branch:remote_branch
Nov 27 21:44:38 <PaulFertser> pespin: yes, i think git push will not by default create new branches.
Nov 27 21:45:01 <PaulFertser> pespin: but if you already have a local and remote branch named the same way, git push without extra parameters will push all the "matching" branches.
Nov 27 21:45:19 <pespin> PaulFertser, how to create a new branch in gitorious then?
Nov 27 21:45:32 <PaulFertser> pespin: just specify it explicitely, like GNUtoo said.
Nov 27 21:45:37 <GNUtoo> seem that telephony is broken
Nov 27 21:45:39 <pespin> ok thanks :)
Nov 27 21:46:09 <GNUtoo> and I need telephony for tomorrow
Nov 27 21:46:43 <GNUtoo> 2011-11-27T06:05:57.557095Z [ERROR] DBusServiceDevice <>: Can't open modem
Nov 27 21:49:37 <GNUtoo> and could someone fix ffalarms at runtime
Nov 27 21:58:21 <GNUtoo> mrmoku, telephony is broken
Nov 27 21:58:30 <GNUtoo> mrmoku, and I need it for tomorrow
**** ENDING LOGGING AT Mon Nov 28 02:59:56 2011