**** BEGIN LOGGING AT Sun May 17 02:59:57 2009
May 17 06:34:09 <PaulFertser> ptitjes|party: Still partying? ;) Hey, i've finally tried to build OE and i have the same error as mrmoku|a` and dent . I've built vala-bootstrap-native 0.7.2 (confirmed with running valac --version from staging dir).
May 17 07:00:28 <PaulFertser> ptitjes|party: i tried building from both pending-upstream-move and mickey/0.7/posix with the same result. Probably vala-bootstrap 0.7.2 is too old but where am i supposed to get a newer version, it's the latest released binary :)
May 17 07:21:20 <rhkfin> mickey|zzZZzz & others who've contributed: Want to thank for great work on fso-gps, agps integration and autostart are c00000l!!
May 17 07:25:29 <rhkfin> An interesting article I just started to read: http://aseigo.blogspot.com/2009/01/building-community-around-your-foss.html
May 17 07:40:45 <sylar911> hi, with the latest shr unstable I get a lot of glamo errors and the sd isn't recognised: any solution?
May 17 08:23:43 <BluesLee> how is the wlan status on shr?
May 17 08:25:07 <BluesLee> i read there are some issues with newer kernels
May 17 08:36:55 <SHR-WugBranler`> tracfeed: Ticket #200 ([Illume-keyboard] The numeric keyboard should only contain numbers) updated <http://trac.shr-project.org/trac/ticket/200#comment:8>
May 17 10:27:22 <PaulFertser> ptitjes|party: Hm, weird: i tried to compile vala-native from master branch but still failed. Then i tried to substitute compiler/valac by a pre-built (by vala-bootstrap-native (which i tweaked to build 0.9.2) valac and it successfully compiled.
May 17 10:43:57 <mrmoku> PaulFertser: hmm, interesting
May 17 10:46:03 <PaulFertser> mrmoku: do you understand vala building process? what is compiler/valac? A git valac version built by bootstrap compiler? Does it mean that current git versions can't build itself?
May 17 10:46:48 <mrmoku> PaulFertser: not very much... I just know that compiling valac from git needs some pre-installed (or pre-built via bootstrap) valac to compile itself
May 17 10:47:13 <mrmoku> why it builds something in compiler/valac that then does not work... no idea
May 17 11:24:57 <Mark_> hi
May 17 11:26:51 <DocScrutinizer> moin
May 17 11:27:51 <khiraly1> PaulFertser: I corrected the Who is Who page (charlie, alphaone - left openmoko, added mirko-paroli and nytowl to it). Anybody knows anything else?
May 17 11:29:39 <khiraly1> http://wiki.openmoko.org/wiki/Who_is_Who#Officials_members_of_the_Openmoko_Team
May 17 11:34:37 <DocScrutinizer> khiraly1: I think the "" (Left Openmoko. Here for archives.)"" is missing at a *lot* of entries there
May 17 11:36:58 <DocScrutinizer> roh left, michelShilo left, a lot of the thaiwanese staff left as well
May 17 11:47:30 <Marcello9001> ops some problem also from IRC client :-(
May 17 11:49:09 <DocScrutinizer> khiraly1: btw you should as WolfgandSpraul if you can catch him one of the rare occasions he's dropping by here. he's the only one who can tell for sure and knows *all* the details
May 17 11:49:31 <DocScrutinizer> s/as/ask/
May 17 11:49:31 <bzzbot> DocScrutinizer meant: khiraly1: btw you should ask WolfgandSpraul if you can catch him one of the rare occasions he's dropping by here. he's the only one who can tell for sure and knows *all* the details
May 17 11:53:24 <ptitjes|party> PaulFertser: hello
May 17 11:53:41 <ptitjes|party> I don't what to say OE builds it correctly here
May 17 11:53:50 <PaulFertser> ptitjes|party: :)
May 17 11:54:59 <PaulFertser> ptitjes|party: btw, since vala-native requires vala-bootstrap-native anyway, wouldn't it be good to have vala-bootstrap-native to install to a different location so that if one builds vala-native and then does -c clean he won't lose what vala-bootstrap-native built?
May 17 11:55:58 <ptitjes|party> PaulFertser: will this not make that we everytime have a doubt on which one is launched ?
May 17 11:56:13 <ptitjes|party> PaulFertser: this should be suggested to mickey|zzZZzz 
May 17 11:56:26 <ptitjes|party> PaulFertser: I think he is the author of this recipe
May 17 11:56:50 <Marcello9001> for backing up rootfs .... http://wiki.openmoko.org/wiki/NeoTool#Optional   maybe the reason of "connection refused" is a problem with keys?
May 17 11:56:50 <PaulFertser> ptitjes|party: you'll pass to vala-native's configure a good path to ensure it uses a bootstrap version. And this path won't be a regular one, so other packages won't find it there anyway.
May 17 11:57:00 <mrmoku> PaulFertser: mickey|zzZZzz said this problem comes from us (or better openmoko) using packaged-staging in OE
May 17 11:57:15 <mrmoku> and would go away if not using it
May 17 11:57:21 <ptitjes|party> PaulFertser: hum nice idea
May 17 11:57:27 <mrmoku> still have to understand what it means...
May 17 11:57:36 <PaulFertser> Marcello9001: try to check that you can ssh to FR without problems first (then use scp instead of gui apps ;) )
May 17 11:57:55 <ptitjes|party> mrmoku: why does it builds for me ?
May 17 11:57:57 <Marcello9001> mmm. ok
May 17 11:58:00 <PaulFertser> mrmoku: ah, i saw that. I thought you've disabled packaged-staging already.
May 17 11:58:11 <Marcello9001> TNKS
May 17 11:58:53 <ptitjes|party> mrmoku: Did you see RP's comment on #oe
May 17 11:59:11 <ptitjes|party> RP>
May 17 11:59:12 <ptitjes|party> ptitjes|party: I had a further look at the gobject stuff and its a world of pain :(
May 17 12:00:16 <PaulFertser> ptitjes: So, can you comment on that strange compiler/valac thing? ;)
May 17 12:01:26 <ptitjes> PaulFertser: yep puting bootstrap in its own place would be a good idea
May 17 12:01:40 <ptitjes> (hum this may not be the comment you waited for :()
May 17 12:01:41 <Marcello9001> bye see you next time :)
May 17 12:01:50 <ptitjes> (sorry I'm just awake...
May 17 12:02:10 <mrmoku> ptitjes: if I understand the error correctly... it is the valac built inside compiler causing that error...
May 17 12:02:16 <PaulFertser> ptitjes: "last time i was sober, man i felt bad; worst hangover that i ever had" :p
May 17 12:02:55 <ptitjes> mrmoku: the problem is that I never had that error
May 17 12:03:29 <mrmoku> ptitjes: well... I don't care if you have that error ;)
May 17 12:03:34 <mrmoku> lots of people have it...
May 17 12:03:37 <ptitjes> mrmoku: can you paste the error my backlog is not long enough
May 17 12:03:48 <ptitjes> (and my brains neither yet :))
May 17 12:04:17 <ptitjes> mrmoku: I did not say I don't want to help
May 17 12:04:21 <ptitjes> but I don't know how
May 17 12:04:34 <ptitjes> sure I want you to have valac
May 17 12:04:34 <PaulFertser> ptitjes: something like symbol lookup error vala_code_context_set_profile
May 17 12:05:00 <mrmoku> ptitjes: nah... did not want to accuse you to not wanting to help :)
May 17 12:05:05 <ptitjes> PaulFertser: oh yes this comes back to my mind
May 17 12:05:24 <dos1|neo> mrmoku: what about sms recipes?
May 17 12:05:28 <dos1|neo> ;)
May 17 12:05:50 <ptitjes> PaulFertser: mrmoku : IIRC set_profile() is a recent addition to add posix ground swapable with the glib one
May 17 12:06:17 <ptitjes> mrmoku: I would think that the version of the bootstrap is not recent enough
May 17 12:06:21 <mrmoku> compiler/.libs/lt-valac: undefined symbol: vala_code_context_set_profile
May 17 12:06:24 <ptitjes> that would be my first bet
May 17 12:06:41 <mrmoku> ptitjes: well it is 0.7.2... there is nothing more recent
May 17 12:07:23 <mrmoku> and doing something like bootstrap1 and bootstrap2 to build some little bit older vala but new enough to build current vala... quite suboptimal :P
May 17 12:07:36 <PaulFertser> ptitjes: i told you, i tried bootstrap 0.7.2, it didn't work. And in fact this error is reported by valac that is inside compiler directory in the git sources!
May 17 12:08:09 <PaulFertser> ptitjes: and the same file (and the whole vala stuff) was built successfully when i substituted bootstrap valac in place of compiler/valac.
May 17 12:08:10 <ptitjes> could you try with master branch
May 17 12:08:15 <PaulFertser> ptitjes: i did!
May 17 12:08:16 <ptitjes> ?
May 17 12:08:28 <PaulFertser> ptitjes: i tried master branch and it failed with the same error.
May 17 12:08:28 <ptitjes> PaulFertser: so with master it does not fail ?
May 17 12:08:33 <ptitjes> ah ok
May 17 12:08:34 <ptitjes> good
May 17 12:08:51 <PaulFertser> ptitjes: and it was built with bootstrap valac ok, but compiler/valac inside the sources failed ;)
May 17 12:08:54 <ptitjes> I mean better I had a little fear
May 17 12:09:33 <ptitjes> PaulFertser: so I have to compile a vala thing to see it right ?
May 17 12:10:26 <ptitjes> sorry if I don't understand everything...
May 17 12:10:39 <ptitjes> trying to bitbake libfso-glib to see
May 17 12:10:41 <PaulFertser> ptitjes: this error was seen while i tried to compile vala-native. It compiles its own (minimal?) compiler first (using bootstrap) and then compiles everything else using that. 
May 17 12:11:26 <ptitjes> PaulFertser: in fact the only difference is that C sources are delivered with the releases (which is what bootstrap uses)
May 17 12:12:14 <DocScrutinizer> PaulFertser: silly prode of compiler-coders always need to build their compiler by itself
May 17 12:12:27 <DocScrutinizer> s/pro/pri/
May 17 12:12:27 <bzzbot> DocScrutinizer meant: PaulFertser: silly pride of compiler-coders always need to build their compiler by itself
May 17 12:13:17 <PaulFertser> DocScrutinizer: Nice explanation ;) 
May 17 12:13:33 <TAsn> hallo there.
May 17 12:14:05 <PaulFertser> ptitjes: i understand that. Still you see that it seems that vala-native from git uses two-stage process, first it compiles its own valac, then it compiles the rest using it.
May 17 12:14:51 * DocScrutinizer wonders if all assemblers are coded in assembler as well
May 17 12:15:38 <DocScrutinizer> probably lisp and prolog are coded in lisp and prolog rsp
May 17 12:16:08 <ptitjes> PaulFertser: nah the rest is compiled with the bootstrap vala too
May 17 12:16:17 <ptitjes> PaulFertser: there is no two phases
May 17 12:16:37 <PaulFertser> ptitjes: well, what's compiler/valac then?
May 17 12:16:49 <ptitjes> PaulFertser: everything in vala-native should be compiled with vala-bootstrap, as vala-native is not yet installed
May 17 12:17:14 <TAsn> hey everyone
May 17 12:17:16 <TAsn> http://openbossa.indt.org/canola2/using.html
May 17 12:17:20 <ptitjes> everything in vala-native should be compiled with the valac produce by vala-bootstrap
May 17 12:17:28 <ptitjes> (said it better I think)
May 17 12:17:38 <DocScrutinizer> ptitjes: for vala it was particularly silly otherwise, as vala is a crosscompiler to C anyway
May 17 12:18:10 <ptitjes> I'm sorry about that
May 17 12:18:21 <PaulFertser> ptitjes: well, this one looks like what i saw. And valac produced by vala-bootstrap failed to compile vala-native while valac from bootstrap itself compiled it successfully.
May 17 12:18:26 <ptitjes> We won't have those problems when all my patches will have been upstream
May 17 12:18:39 <ptitjes> you have those problems by my fault :(
May 17 12:19:40 <DocScrutinizer> hey, so this suggests today is "ptitjes'-fault-day"? ;-)
May 17 12:19:47 <ptitjes> meh
May 17 12:20:05 <PaulFertser> ptitjes: no need to sorry, just fix the problem in SHR ;)
May 17 12:20:15 <ptitjes> I  would like
May 17 12:20:17 <PaulFertser> ptitjes: btw, are you done with your exams?
May 17 12:20:30 * mrmoku going to parents and have some coffee... bbl
May 17 12:20:31 <DocScrutinizer> we should elect fault-taker of the day every 24h ;-D
May 17 12:20:48 <ptitjes> PaulFertser: I didn't have exams since 7 or 8 years ;)
May 17 12:20:57 <ptitjes> mrmoku|away: cu
May 17 12:21:34 <ptitjes> PaulFertser: I'm sound engineer this might explain my silly up times
May 17 12:21:53 <ptitjes> PaulFertser: I work when nobody work :)
May 17 12:21:56 <PaulFertser> ptitjes: Oh, good for you, it's always an unpleasant thing no matter on which side of the table you're ;)
May 17 12:22:05 <ptitjes> héhé
May 17 12:22:48 <ptitjes> PaulFertser: my OE went for 552 packages to build
May 17 12:22:52 <PaulFertser> ptitjes: sound engineer? Woohoo. Are you using Ardour or some proprietary stuff like Samplitude, Cubase?
May 17 12:23:13 <ptitjes> PaulFertser: I work on the live side of things (aka concerts)
May 17 12:23:27 <ptitjes> PaulFertser: but I use Ardour from time to time
May 17 12:23:38 <ptitjes> PaulFertser: for personal stuff
May 17 12:23:44 <PaulFertser> ptitjes: :D
May 17 12:24:20 <ptitjes> PaulFertser: I love it - it is far more well-integrated than Protools
May 17 12:24:25 <ptitjes> but this is my view
May 17 12:24:42 <ptitjes> I might understand some prefer Protools by habbit
May 17 12:25:44 <ptitjes> PaulFertser: could you pastebin the complete buildlog of bootstrap and native please ?
May 17 12:25:59 <Sup3rkiddo> guys, is git.fso.org down?
May 17 12:26:47 <DocScrutinizer> lemme see
May 17 12:27:01 <Sup3rkiddo> okie
May 17 12:27:13 <DocScrutinizer> oops, fso, NIH ;-)
May 17 12:27:32 <DocScrutinizer> i.e. have to access to FSO
May 17 12:28:09 <Sup3rkiddo> whats NIH :D
May 17 12:28:15 <PaulFertser> ptitjes: bootstrap log is available, native was erased, it will take some time to regenerate it.
May 17 12:28:23 <alphaone> DocScrutinizer: nih?
May 17 12:28:34 <Sup3rkiddo> DocScrutinizer, am not able to access the gitweb as well
May 17 12:28:43 <DocScrutinizer> nah, I'm in wakeup process
May 17 12:28:55 <Sup3rkiddo> tubes must be full with LOLCATS.. pretty slow
May 17 12:28:56 <DocScrutinizer> alphaone: nevemind
May 17 12:28:56 <alphaone> usually not invented here, but doesn't make sense in this context?
May 17 12:28:57 <PaulFertser> ptitjes: bootstrap compile log is here: http://rafb.net/p/Gbvsqv72.html
May 17 12:29:04 <alphaone> DocScrutinizer: k :-)
May 17 12:29:13 <ptitjes> PaulFertser: isn't that the contrary ?
May 17 12:29:25 <PaulFertser> ptitjes: i managed to build native after all ;)
May 17 12:29:44 <PaulFertser> ptitjes: so i have no log of failure, it was erased by -c clean.
May 17 12:29:46 <ptitjes> PaulFertser: so you have it in fact ?
May 17 12:29:49 <DocScrutinizer> PING git.freesmartphone.org (134.169.172.109) 56(84) bytes of data.
May 17 12:29:50 <DocScrutinizer> 64 bytes from a109.apm.etc.tu-bs.de (134.169.172.109): icmp_seq=1 ttl=52 time=80.9 ms
May 17 12:30:03 <DocScrutinizer> nothing more I could do for git.FSO
May 17 12:30:11 <PaulFertser> ptitjes: after tricking native to built _everything_ using bootstrap valac i managed to build it, yes
May 17 12:30:12 <ptitjes> PaulFertser: can you devshell and valac -version and valac --help
May 17 12:30:16 <ptitjes> please ?
May 17 12:30:49 <ptitjes> PaulFertser: could you detail how you managed to do this ?
May 17 12:31:05 <PaulFertser> ptitjes: well shr-unstable/tmp/staging/i686-linux/usr/bin/valac --version says 0.7.3 because i built master after my trick.
May 17 12:31:14 <PaulFertser> ptitjes: before that it was 0.7.2
May 17 12:31:17 <ptitjes> PaulFertser: ok --help please
May 17 12:31:21 <PaulFertser> (from bootstrap)
May 17 12:31:27 <ptitjes> PaulFertser: I need to know if --gir option is there
May 17 12:31:49 <ptitjes> if yes then this is the correct stuff from branch pending-upstream-move
May 17 12:31:52 <PaulFertser> ptitjes: no, it's from master branch from fso.org repo
May 17 12:32:00 <alphaone> Sup3rkiddo: What problem do you have with git.fso?
May 17 12:32:11 <PaulFertser> ptitjes: i told you several times that i built the master branch after all my troubles ;)
May 17 12:32:39 <ptitjes> PaulFertser: so this is a problem of what we have in git ?
May 17 12:32:48 <ptitjes> grrr
May 17 12:33:01 <Sup3rkiddo> alphaone, timing out... git pull... visiting http://git.fso.org in firefox
May 17 12:33:50 <PaulFertser> ptitjes: I suspect this but can't prove.
May 17 12:34:07 <ptitjes> PaulFertser: could you retry with pending-upstream-move please ?
May 17 12:34:21 <PaulFertser> ptitjes: probably recipe is using some incompatible parameters. Yes, trying pending-upstream-move atm.
May 17 12:34:23 <ptitjes> so that I can have a log
May 17 12:34:32 <ptitjes> thanks
May 17 12:35:11 <ptitjes> PaulFertser: anyway bootstrap seems ok no valac call inside
May 17 12:35:15 <alphaone> Sup3rkiddo: works here, but I'm within apm.etc.tu-bs.de so I wouldn't notice any problems on the outside
May 17 12:35:43 <ptitjes> PaulFertser: I will retry it on my side asap
May 17 12:35:48 <Sup3rkiddo> alphaone, hmm, wogay... wikipedia is timing out.. must be my ISP.. :( thanks
May 17 12:35:58 <alphaone> np
May 17 12:36:06 <PaulFertser> ptitjes: bootstrap built fine for me, both 0.7.1 and then 0.7.2 when i tried it.
May 17 12:36:28 <ptitjes> yep it is only C files so there is no reason it fail :)
May 17 12:41:57 <ptitjes> PaulFertser: my do_compile.log for vala-native_git http://pastebin.com/d253eb996
May 17 12:42:24 <ptitjes> :(
May 17 12:43:41 <ptitjes> PaulFertser: I keep it under my arm to compare with the one you will provide me
May 17 12:43:58 <PaulFertser> ptitjes: well, i can confirm that pending-upstream-move (that has gir option) was built successfully with 0.7.3 from master used as bootstrap. 
May 17 12:44:18 <ptitjes> ha
May 17 12:44:25 <ptitjes> this is better than nothing
May 17 12:44:32 <ptitjes> this means that it can build :)
May 17 12:44:53 <PaulFertser> ptitjes: do you need a build log of this?
May 17 12:44:58 <ptitjes> yep
May 17 12:45:03 <khiraly1> (13.36.58) DocScrutinizer: roh left, michelShilo left, a lot of the thaiwanese staff left as well  <-- ok. Corrected (roh, micheal shiloh)
May 17 12:45:11 <ptitjes> but it might look like the one I have show you :)
May 17 12:45:16 <ptitjes> as it does not fail :)
May 17 12:46:24 <ptitjes> PaulFertser: /home/didier/SHR/shr-unstable/tmp/staging/x86_64-linux/usr/bin/valac is used here to compile native
May 17 12:46:43 <ptitjes> PaulFertser: which seems to be correct (that is it is not my host valac)
May 17 12:46:53 <ptitjes> right ?
May 17 12:47:32 <PaulFertser> ptitjes: to compile "compiler" part yes, it's used. http://rafb.net/p/cabK2726.html for the other parts ../compiler/valac is used. Now i'll produce you a failing log.
May 17 12:47:58 <DocScrutinizer> alphaone: 13. a109.apm.etc.tu-bs.de                               60.9%    70   80.2  80.9  80.2  84.7   0.9
May 17 12:48:21 <alphaone> DocScrutinizer: ups
May 17 12:48:35 <DocScrutinizer> (mtr)
May 17 12:50:53 <ptitjes> PaulFertser: hum ../compiler/valac is only used to compile vapigen and vapicheck at the end of the build
May 17 12:51:07 <ptitjes> PaulFertser: this might not be a problem I think
May 17 12:51:10 <alphaone> DocScrutinizer: Are you flooding it?
May 17 12:51:23 <DocScrutinizer> alphaone: mtr
May 17 12:51:38 <DocScrutinizer> gues 1packet/s
May 17 12:52:06 <alphaone> Really, that is strange
May 17 12:52:41 <alphaone> ping -An works here
May 17 12:52:41 <DocScrutinizer> could repeat with plain old ping if you like
May 17 12:52:52 <alphaone> 64 bytes from 134.169.172.109: icmp_seq=2702 ttl=63 time=1.09 ms^C
May 17 12:52:52 <alphaone> --- trac.freesmartphone.org ping statistics ---
May 17 12:52:52 <alphaone> 2702 packets transmitted, 2702 received, 0% packet loss, time 5283ms
May 17 12:52:52 <alphaone> rtt min/avg/max/mdev = 1.047/1.231/12.671/0.463 ms, pipe 2, ipg/ewma 1.956/1.119 ms
May 17 12:54:08 <alphaone> And from the fso server at least heise is reachable..
May 17 12:54:09 <alphaone> 64 bytes from 193.99.144.80: icmp_seq=630 ttl=246 time=17.0 ms
May 17 12:54:10 <alphaone> --- heise.de ping statistics ---
May 17 12:54:10 <alphaone> 631 packets transmitted, 630 received, 0% packet loss, time 10789ms
May 17 12:54:10 <alphaone> rtt min/avg/max/mdev = 16.025/16.715/18.183/0.325 ms, pipe 2, ipg/ewma 17.126/16.773 ms
May 17 12:54:21 <DocScrutinizer> 21 packets transmitted, 21 received, 0% packet loss, time 20073ms
May 17 12:54:23 <DocScrutinizer> rtt min/avg/max/mdev = 79.885/81.195/82.437/0.687 ms
May 17 12:54:32 <DocScrutinizer> halley:~ # ping a109.apm.etc.tu-bs.de
May 17 12:54:42 <alphaone> try -An
May 17 12:54:45 <DocScrutinizer> anyway, mrt borks
May 17 12:54:50 <PaulFertser> ptitjes: but it is ;)
May 17 12:55:06 <alphaone> -A is adaptive, sends another request as soon as the reply is there
May 17 12:55:11 <DocScrutinizer> 83 packets transmitted, 82 received, 1% packet loss, time 6676ms
May 17 12:55:13 <DocScrutinizer> rtt min/avg/max/mdev = 80.318/81.247/82.178/0.479 ms, ipg/ewma 81.425/81.290 ms
May 17 12:55:22 <alphaone> k
May 17 12:55:26 <alphaone> looks okay to me
May 17 12:56:09 <ptitjes> PaulFertser: here is what "git diff recipes/vala" outputs here: http://pastebin.com/d530f6288
May 17 12:56:41 <ptitjes> PaulFertser: and also "git diff" in the shr-overlay: http://pastebin.com/d67368359
May 17 12:56:53 <ptitjes> PaulFertser: tell me if you have any different ?
May 17 12:57:07 <DocScrutinizer> alphaone: mtr seems broken somehow
May 17 12:57:12 <DocScrutinizer> halley:~ # mtr git.freesmartphone.org
May 17 12:57:18 <DocScrutinizer> 13. a109.apm.etc.tu-bs.de                               80.0%    41   80.7  80.8  80.4  81.9   0.5
May 17 12:57:29 <alphaone> DocScrutinizer: Well, it tries to guess stuff a different way iirc
May 17 12:57:47 <alphaone> Not sure if "modern" firewalls and iptables rules screw that up somehow
May 17 12:57:56 <DocScrutinizer> UDP vs TCP?
May 17 12:58:02 <DocScrutinizer> or ICMP
May 17 12:58:28 <DocScrutinizer> let me test another IP
May 17 12:58:52 <alphaone> DocScrutinizer: mtr seems to test the ttl exceeded answers while ping uses icmp
May 17 12:58:58 <alphaone> Not sure what mtr sends
May 17 12:59:31 <DocScrutinizer> well anyway heise.de behaves
May 17 12:59:36 <DocScrutinizer> no idea
May 17 12:59:39 <alphaone> from the manpage
May 17 12:59:40 <alphaone> BUGS
May 17 12:59:41 <alphaone>        Some modern routers give a lower priority to ICMP ECHO packets than to other network traffic.  Consequently, the reliability of these routers reported  by
May 17 12:59:41 <alphaone>        mtr will be significantly lower than the actual reliability of these routers.
May 17 13:00:02 <DocScrutinizer> yup
May 17 13:00:40 <DocScrutinizer> so this means a109.apm.etc.tu-bs.de is dropping ICMP echo 
May 17 13:01:02 <alphaone> Not sure if or why
May 17 13:01:09 <alphaone> direct ping is working..
May 17 13:01:28 <alphaone> I mean ping -An is
May 17 13:02:30 <DocScrutinizer> anyway, seems not really down :-)
May 17 13:02:48 <PaulFertser> ptitjes: tada, failing log: http://rafb.net/p/LzvD5t28.html (trying to build pending-upstream-move with 0.7.1 bootstrap).
May 17 13:02:49 <DocScrutinizer> though you might check config eventually
May 17 13:03:13 <ptitjes> PaulFertser: did you compare your with my diffs ?
May 17 13:03:18 * DocScrutinizer away
May 17 13:05:11 <ptitjes> PaulFertser: why is it vala-native-0.7.1-fso1-gitr2766+9f435508c571b9b60d4bdd57863f37644d1eecdf-r0 ?
May 17 13:05:13 <PaulFertser> ptitjes: doing that atm. I guess git url in vala-native_git.bb is irrelevant as it builds from autorev url anyway.
May 17 13:05:26 <PaulFertser> ptitjes: this is because of your second diff.
May 17 13:05:35 <PaulFertser> ptitjes: i don't have any modifications to shr.
May 17 13:05:57 <DocScrutinizer> alphaone: each 3rd traceroute in quick sequence seems to slightly fail as well
May 17 13:06:07 <ptitjes> PaulFertser: so don't you use 0.7.1 instead of 0.7.2 ?
May 17 13:06:32 <DocScrutinizer> 13  a109.apm.etc.tu-bs.de (134.169.172.109)  81.651 ms   81.067 ms *
May 17 13:06:53 <ptitjes> PaulFertser: you would have to change the autorev in shr/openembedded/conf/distro/include/shr-unstable-autorev
May 17 13:06:58 <ptitjes> or the like
May 17 13:07:11 <ptitjes> shr-autorev-unstable
May 17 13:07:57 <PaulFertser> ptitjes: how is that name makes any difference at all? It gets HEAD of git branch anyway.
May 17 13:08:14 <ptitjes> PaulFertser: whether it rebuils it or not ?
May 17 13:08:41 <ptitjes> PaulFertser: can't it uses an older already built version because of this name ?
May 17 13:08:49 <DocScrutinizer> alphaone: `halley:~ # traceroute git.freesmartphone.org;traceroute git.freesmartphone.org;traceroute git.freesmartphone.org;` fails on #2 and #3
May 17 13:09:21 <DocScrutinizer> alphaone: load balancer or FW issue
May 17 13:09:24 <ptitjes> PaulFertser: remember I don't know much to OE :)
May 17 13:09:45 <PaulFertser> ptitjes: well, to produce a failing log i first did -c clean for both vala-bootstrap-native and vala-native. Then built vala-bootstrap-native, it built 0.7.1 (because there's only a recipe for that, when i tried earlier to copy recipies i was able to build 0.7.2), it got installed to the staging location where it was later picked up and used for bootstrapping.
May 17 13:09:49 <ptitjes> I changed that because I felt it was not good to let 0.7.1
May 17 13:09:51 <ptitjes> :)
May 17 13:09:51 <alphaone> DocScrutinizer: I've seen that on quit some machines
May 17 13:10:04 <alphaone> DocScrutinizer: Not sure where that happens, though
May 17 13:10:17 <alphaone> Standart linux router /server do that
May 17 13:10:49 <ptitjes> PaulFertser: oh yes it is not visible in my first diff
May 17 13:10:50 <DocScrutinizer> also might be a problem of my local NAT
May 17 13:10:59 <PaulFertser> ptitjes: so, before bitbaking vala-native i ensured that the valac it found (with configure script) was 0.7.1.
May 17 13:11:00 <ptitjes> PaulFertser: but I renamed everything to 0.7.2
May 17 13:11:19 <ptitjes> it has to be 07.2
May 17 13:11:21 <PaulFertser> ptitjes: well, i could do that too and use 0.7.2 as bootstrap, the error was the same.
May 17 13:11:36 <DocScrutinizer> alphaone: let me check from a hosted box
May 17 13:11:41 <alphaone> DocScrutinizer: okay
May 17 13:11:57 <alphaone> But I have frequently seen this with our atekon routers
May 17 13:12:20 <ptitjes> PaulFertser: in fact, I noticed in the past that vala from master git has to be built with the release that occured just before
May 17 13:12:31 <ptitjes> thus now bootstrap HAS to be 0.7.2
May 17 13:12:43 <PaulFertser> ptitjes: Ok, let me do that ;)
May 17 13:12:58 <ptitjes> PaulFertser: yeah every reference to 0.7.1 as 0.7.2
May 17 13:13:22 <ptitjes> PaulFertser: and there is reference to it inside vala-native_git.bb also
May 17 13:13:53 <PaulFertser> ptitjes: so, i did cp vala-bootstrap-native_0.7.1.bb vala-bootstrap-native_0.7.2.bb; cp vala_0.7.1.bb vala_0.7.2.bb; rebuilding bootstrap atm.
May 17 13:14:09 <ptitjes> PaulFertser: and change inside the files too!!!
May 17 13:14:12 <DocScrutinizer> alphaone: somewhat related to my internet-connection
May 17 13:14:19 <alphaone> hmm
May 17 13:14:40 <PaulFertser> ptitjes: vala-native_git.bb uses old PV that can't be found anyway.
May 17 13:14:45 <DocScrutinizer> alphaone: maybe NAT losing ICMP replies
May 17 13:14:54 <PaulFertser> ptitjes: those files i copied don't require any changes to build 0.7.2
May 17 13:15:00 <ptitjes> yes
May 17 13:15:01 <DocScrutinizer> on UDP ping
May 17 13:15:15 <DocScrutinizer> seen this frequently
May 17 13:15:18 <alphaone> hmm
May 17 13:15:25 <PaulFertser> ptitjes: probably only PV should be set to r1 (from r2) but it's irrelevant i guess.
May 17 13:15:38 <ptitjes> PaulFertser: this is my vala-native_git.bb: http://pastebin.com/m4f728b79
May 17 13:15:55 <alphaone> Here it usually happens on my router or the atekon router if I mtr hosts behind that.
May 17 13:16:04 <ptitjes> PaulFertser: this has to be same PV as in shr-autorev-unstable
May 17 13:16:15 <ptitjes> see line 7
May 17 13:16:16 <alphaone> It looked like they were ratelimiting the ttl exceeded message
May 17 13:16:25 <PaulFertser> ptitjes: if it's not, then shr-autorev-unstable is getting used, it seems.
May 17 13:17:30 <ptitjes> PaulFertser: you mean PV = "r1-gitr${SRCREV}" ?
May 17 13:18:08 <PaulFertser> ptitjes: i guess yes, i have PV = "0.6.0-fso1-gitr${SRCREV}" and it's simply ignored.
May 17 13:18:16 <DocScrutinizer> alphaone: probably to counteract ttl-icmp infinite bounce DOS
May 17 13:18:21 <ptitjes> hum
May 17 13:18:24 <alphaone> DocScrutinizer: yeah
May 17 13:18:45 <PaulFertser> ptitjes: well, now my /home/pavel/SHR/shr-unstable/tmp/staging/i686-linux/usr/bin/valac --version gives 0.7.2.
May 17 13:18:51 <ptitjes> PaulFertser: I would change that (because I don't trust OE as I don't know well its way to work)
May 17 13:19:14 <ptitjes> so this is a correct bootstrap
May 17 13:19:49 <ptitjes> PaulFertser: this can be used to build from git
May 17 13:20:07 <PaulFertser> ptitjes: in theory ;)
May 17 13:20:39 * ptitjes wonders why its OE rebuilds gcc and glibc, version bumped ?
May 17 13:20:48 <ptitjes> PaulFertser: héhéhé
May 17 13:21:03 <ptitjes> PaulFertser: let's see if it does practically :)
May 17 13:21:57 <DocScrutinizer> alphaone: roh might explain, I'm a network noob ;-)
May 17 13:22:06 <ptitjes> PaulFertser: I wonder who we could ask to update the recipes in fso/m5.5, or whether we should add it our overlay...
May 17 13:22:34 <alphaone> :-)
May 17 13:22:47 <PaulFertser> ptitjes: you gotta wait, i think 0.7.2 will fail the same way 0.7.1 failed.
May 17 13:23:11 <PaulFertser> ptitjes: we should ask nytowl for that (updating bootstrap to 0.7.2), i guess.
May 17 13:23:27 <ptitjes> oh yeah you are right
May 17 13:23:37 <ptitjes> nytowl: ping
May 17 13:27:09 <PaulFertser> ptitjes: here's a log of failing to build pending-upstream-move with 0.7.2 as bootstrap http://rafb.net/p/L6UBrf96.html
May 17 13:27:20 <ptitjes> frrr
May 17 13:27:44 <ptitjes> still this is vala-native-0.7.1-fso1-gitr2766+9f435508c571b9b60d4bdd57863f37644d1eecdf-r0
May 17 13:28:28 <DocScrutinizer> alphaone: anyway I know ICMP handling is rather tricky for a NAT
May 17 13:28:31 <PaulFertser> ptitjes: how can i convince you that this is just a name and in fact it's HEAD of pending-upstream-move branch?
May 17 13:28:44 <ptitjes> arf ok
May 17 13:29:03 <ptitjes> but this is the only difference I see with what I have here
May 17 13:29:05 <ptitjes> :(
May 17 13:29:38 <PaulFertser> ptitjes: http://git.freesmartphone.org/?p=vala-lang.git;a=commit;h=9f435508c571b9b60d4bdd57863f37644d1eecdf
May 17 13:30:01 <ptitjes> yep this is HEAD
May 17 13:30:06 <PaulFertser> ptitjes: most probably you use 0.7.3 as bootstrap and it worked for me btw.
May 17 13:30:26 <ptitjes> there is an official 0.7.3?
May 17 13:30:39 <ptitjes> nah
May 17 13:30:42 <PaulFertser> ptitjes: no, it worked after i compiled it using the trick.
May 17 13:30:56 <DocScrutinizer> alphaone: and I got zyxel P660 here which is known to be fubar by design
May 17 13:31:06 <PaulFertser> ptitjes: the trick to substitute 0.7.2 instead of ../compiler/valac.
May 17 13:33:43 <ptitjes> PaulFertser: I'm wondering whether the posix profile stuff broke the bootstraping...
May 17 13:33:49 <ptitjes> PaulFertser: asking upstream
May 17 13:34:03 <ptitjes> PaulFertser: that would mean they need to make a release
May 17 13:34:19 <PaulFertser> ptitjes: probably...
May 17 13:34:45 <ptitjes> PaulFertser: or this is truly a bug in the valac build system and the last part (vapigen|check) should use stock valac too
May 17 13:34:51 <PaulFertser> ptitjes: i wonder why you can't reproduce it though (on your host without OE)
May 17 13:35:01 <ptitjes> yep very strange
May 17 13:35:36 <ptitjes> PaulFertser: I'll check in devshell.
May 17 13:35:50 <ptitjes> (when glibc will have finished to build :))
May 17 13:36:00 <PaulFertser> ptitjes: btw, compiler/valac is a bash script while valac from bootstrap is ELF.
May 17 13:36:20 <ptitjes> oh
May 17 13:37:04 <PaulFertser> ptitjes: and i wonder why you just can't make sense from the error log as you should know what's going on there under the hood ;)
May 17 13:37:49 <PaulFertser> ptitjes: probably some paths issue?
May 17 13:37:59 <DocScrutinizer> alphaone: as I mentioned above: from a decent "backbone-connected" box there seem to be no issues whatsoever (alas no mtr there)
May 17 13:38:07 <ptitjes> PaulFertser: yep the 0.7.1 stuff still
May 17 13:38:32 <ptitjes> PaulFertser: line 861
May 17 13:38:38 <ptitjes> of your build log
May 17 13:39:32 <alphaone> DocScrutinizer: okay
May 17 13:39:34 <ptitjes> lt-valac here is an old vala lib because it does not contain post 0.7.2 changes
May 17 13:41:03 <PaulFertser> ptitjes: well, just now i tried to continue compilation. in compile/.libs there were both lt-valac and valac. both are 0.7.3. I substituted lt-valac by 0.7.2 binary from bootstrap and voila, compilation worked.
May 17 13:43:24 <ptitjes> PaulFertser: so there is a collapse because the git version overwrites the bootstrap one ?
May 17 13:43:25 <PaulFertser> ptitjes: line 861 of my build log starts with /home/pavel/SHR/shr-unstable/tmp/work/i686-linux/vala-native-0.7.1-fso1-gitr2766+9f435508c571b9b60d4bdd57863f37644d1eecdf-r0/git/compiler/.libs/lt-valac: , why do you say it's 0.7.1?
May 17 13:44:00 <PaulFertser> ptitjes: no, it's just that when lt-valac is 0.7.3 it fails to build and with 0.7.2 it works.
May 17 13:44:13 <ptitjes> PaulFertser: juergbi says it "looks like a non-clean build for whatever reason"
May 17 13:45:07 <DocScrutinizer> alphaone: WTF? no traceroute on varaha
May 17 13:45:20 <PaulFertser> ptitjes: well, probably i'm stupid... I told you all the steps. Trying to build vala-native with 0.7.1 bootstrap, failed, then copied two files to get 0.7.2 bootstrap, failed again... 
May 17 13:46:15 <PaulFertser> ptitjes: did -c clean for vala-native before the second try...
May 17 13:46:44 <khiraly1> freesmartphone.org has a mailing list?
May 17 13:51:09 <ptitjes> PaulFertser: does the produced compiler works ?
May 17 13:51:48 <PaulFertser> ptitjes: how can i check?
May 17 13:52:21 <PaulFertser> ptitjes: well, i git-cloned from master (from vala repo) building without OE now, will report.
May 17 13:52:25 <ptitjes> PaulFertser: a test file:
May 17 13:53:18 <ptitjes> http://pastebin.com/d13260edb
May 17 13:53:33 <ptitjes> valac test.vala
May 17 13:53:54 <PaulFertser> ptitjes: i'm using the produced compiler (0.7.3 with gir option) to build vala from git without OE.
May 17 13:54:26 <ptitjes> ok
May 17 14:00:48 <PaulFertser> ptitjes: well, it worked...
May 17 14:01:22 <ptitjes> ?
May 17 14:02:14 <ptitjes> PaulFertser: what worked ?
May 17 14:02:15 <ptitjes> :)
May 17 14:02:38 <PaulFertser> ptitjes: not exactly. I'm trying to build vala from master (official), using 0.7.3 as bootstrap without OE. Make worked without errors, but vapigen wasn't built.
May 17 14:03:11 <ptitjes> PaulFertser: manually ?
May 17 14:03:20 <ptitjes> you have to --enable-vapigen
May 17 14:03:27 <PaulFertser> ptitjes: after that i cd gobject-introspection and did make there, after that i cd vapigen and make worked there. So yes, can't reproduce yet.
May 17 14:04:20 <ptitjes> I don't get why it built correctly here
May 17 14:04:29 <PaulFertser> And here
May 17 14:04:32 <ptitjes> PaulFertser: I retry
May 17 14:05:34 <PaulFertser> ptitjes: i'm retrying too. To build vala manually using 0.7.2 as bootstrap.
May 17 14:05:35 <ptitjes> one OE question ?
May 17 14:06:14 <ptitjes> what does do_configure() normally (when not overiden in a recipe) ?
May 17 14:06:36 <ptitjes> libfso-glib fails on the ./autogen.sh call
May 17 14:06:49 <ptitjes> it says it can't run programs produced by cc
May 17 14:06:55 <ptitjes> it should have --host=
May 17 14:10:15 <PaulFertser> ptitjes: don't think i know the answer, i've never really used OE. :)
May 17 14:10:27 <ptitjes> oki :)
May 17 14:13:04 <khiraly1> can somebody help me with rules.yaml?
May 17 14:13:13 <khiraly1> what are the "while: " rule
May 17 14:13:20 <khiraly1>     while: CallListContains("incoming")
May 17 14:13:59 <khiraly1> when this CallListContains class gets initialized, and how many are of them?
May 17 14:14:46 <khiraly1> in fact some doc about this rules.yaml and frameworkd would suffice
May 17 14:17:17 <khiraly1> and would be nice some doc a calling process
May 17 14:17:28 <ptitjes> hello dos1|neo 
May 17 14:17:53 <dos1|neo> ptitjes: hello
May 17 14:19:02 <ptitjes> PaulFertser: succeed again :( http://pastebin.com/d5a178e6d
May 17 14:19:48 <ptitjes> PaulFertser: could you compare with your output ?
May 17 14:19:51 <PaulFertser> ptitjes: heh :)
May 17 14:20:08 <dos1|neo> mrmoku|away: why are you away? ;p
May 17 14:20:14 <ptitjes> héhéhé
May 17 14:20:43 <ptitjes> dos1|neo: sunday is family day :)
May 17 14:21:38 <dos1|neo> ptitjes: heh. i'm extremely bored, cause i'm ill...
May 17 14:22:02 <PaulFertser> ptitjes: for me it fails somehow. You can ask other OE users to reproduce. I just tried to build SHR yesterday (from scratch) and today morning saw this vala issues...
May 17 14:22:06 <ptitjes> heh what happened, took cold ?
May 17 14:22:26 <dos1|neo> and extremely tired too, without doing anything ;x
May 17 14:22:36 <dos1|neo> ptitjes: flu i think
May 17 14:22:41 <ptitjes> PaulFertser: would that be because I have valac installed on host ?
May 17 14:22:58 <PaulFertser> ptitjes: i can't reproduce problems here with building official git version with 0.7.2 the manual way (without OE).
May 17 14:23:11 <PaulFertser> ptitjes: and i don't have valac installed on host.
May 17 14:23:32 <ptitjes> let me uninstall it and retry
May 17 14:23:45 <ptitjes> grr will have to bootstrap it again after :(
May 17 14:24:45 <ptitjes> oh no just install :)
May 17 14:25:03 <ptitjes> PaulFertser: recleaning and start again
May 17 14:25:33 <ptitjes> dent: did you succeed with vala ?
May 17 14:26:08 <ptitjes> or BillK ?
May 17 14:32:34 <ptitjes> PaulFertser: the same with no valac on host
May 17 14:32:59 <PaulFertser> ptitjes: same for me. Only OE build fails.
May 17 14:34:01 <ptitjes> PaulFertser: grrr. why does OE builds it correctly for me and not for you...
May 17 14:34:31 <PaulFertser> ptitjes: and not for mrmoku|away and dent and some other folks..
May 17 14:35:05 <ptitjes> PaulFertser: the only thing I see is that I tweaked the versions numbers
May 17 14:35:28 <PaulFertser> ptitjes: probably if you try to revert all you local changes you'll see. Probably the numbers are somehow relevant though i fail to understand how it can work..
May 17 14:35:57 <ptitjes> could you try to change them and see ?
May 17 14:36:57 <PaulFertser> ptitjes: i'm sorry i think i want to take a nap now.
May 17 14:37:26 <ptitjes> PaulFertser: cu
May 17 14:37:33 <ptitjes> enjoy
May 17 14:37:56 <ptitjes> playya: hello
May 17 14:38:09 <playya> hi ptitjes 
May 17 14:39:12 <ptitjes> playya: did you try to build vala with OE ?
May 17 14:39:29 <ptitjes> playya: branch pending-upstream-move from fso repo ?
May 17 14:39:46 <playya> nope
May 17 14:40:06 <playya> i don't have OE on my laptop
May 17 14:43:14 <ptitjes> oki
May 17 15:00:17 <CIA-75> freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * rc76734979b32 10/po/Makefile.in.in: 
May 17 15:00:17 <CIA-75> freesmartphone.org: Fix intl files
May 17 15:00:17 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 17 15:05:27 <CIA-75> freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * r1125aa2ee5e5 10/COPYING: 
May 17 15:05:27 <CIA-75> freesmartphone.org: Fix licence
May 17 15:05:27 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 17 15:22:52 <pbaxter> i love shr
May 17 15:24:08 <ptitjes> :D
May 17 15:24:47 <ptitjes> pbaxter: what version are you using ?
May 17 15:26:03 <pbaxter> i can't manage to use the 9/May unstable, so i've flashad my testing of 16 april and now,after changing repositories to unstable ones, i've given the 'opkg upgrade' command
May 17 15:28:09 <CIA-75> freesmartphone.org: 03dos 07framework * r8af8ff0b212b 10/framework/subsystems/opimd/pimd_contacts.py: opimd: Contacts: remove unnecesary variable
May 17 15:28:09 <CIA-75> freesmartphone.org: 03dos 07framework * r52deccf9bcbf 10/framework/subsystems/opimd/pimd_messages.py: opimd: Messages: implement merging Messages from different backends and duplicates
May 17 15:29:34 <vininim> upgraded unstable running smooth here (fsvo smooth)
May 17 15:30:43 <vininim> had to do some manual erase/install though
May 17 15:44:53 * von_fritz wonders whi vala-native does not want to be born :)
May 17 15:48:09 <Ainulindale> Bleeeeh.
May 17 15:51:37 <DocScrutinizer> Ainulindale: well?
May 17 16:09:43 <CIA-75> freesmartphone.org: 03dos 07framework * r08d9e12fc0d3 10/framework/subsystems/opimd/pimb_sim_messages_fso.py: opimd: SIM_Messages_FSO: combine spliten messages
May 17 16:18:14 * [Rui] waves hi
May 17 16:18:27 <[Rui]> I don't understand how to use org.freesmartphone.Device.Display
May 17 16:18:45 <[Rui]> not with libframeworkd-glib
May 17 16:20:48 <mrmoku> [Rui]: what part?
May 17 16:21:17 <[Rui]> mrmoku: I'm trying to make omnewrotate work with brightness when rotating
May 17 16:22:24 <[Rui]> and since frameworkd is getting a hold of the brightness, I should use it to modify it during the rotation
May 17 16:23:24 <mrmoku> [Rui]: ahh... understand your problem... Device.Display is not implemented in libframeworkd-glib :P
May 17 16:23:33 <[Rui]> yeah, seems like it
May 17 16:23:50 <mrmoku> [Rui]: can do that... have to eat before though
May 17 16:24:34 <[Rui]> mrmoku: lol
May 17 16:25:25 <[Rui]> mrmoku: I don't know if I could use it, though, without breaking the phone funcionality... for me the FreeRunner is my main phone
May 17 16:25:36 <dos1|neo> mrmoku: hey
May 17 16:25:45 <mrmoku> [Rui]: ??? why that?
May 17 16:25:47 <[Rui]> but I could use normal glib to interacti with it, right?
May 17 16:25:48 <mrmoku> dos1|neo: hey
May 17 16:25:54 <dos1|neo> mrmoku: merging long messages is now in opimd
May 17 16:26:08 <dos1|neo> mrmoku: duplicating is also fixed
May 17 16:26:12 <mrmoku> [Rui]: you can use normal glib dbus stuff yeah... is a pain though
May 17 16:26:20 <[Rui]> mrmoku: well, I'd need to recompile libframeworkd-glib and if there's any problem, I quite fear a lot of trouble... :(
May 17 16:26:21 <mrmoku> dos1|neo: great
May 17 16:26:30 <dos1|neo> mrmoku: can you rebuild frameworkd and shr-settings?
May 17 16:26:35 <mrmoku> [Rui]: what distro are you using?
May 17 16:26:41 <[Rui]> mrmoku: shr, right now
May 17 16:26:52 <mrmoku> [Rui]: which one? unstable or testing? and from when?
May 17 16:27:15 <[Rui]> testing, early this month, I guess
May 17 16:28:25 <mrmoku> dos1|neo: building now
May 17 16:28:34 <mrmoku> [Rui]: hmm. ok.
May 17 16:32:07 * mwester agrees with Ainulindale's observation on life.
May 17 16:49:18 <PaulFertser> ptitjes: WTF: error: D-Bus methods must almost throw DBus.Error ?
May 17 16:49:43 <mickeyl> yep
May 17 16:50:08 <PaulFertser> mickeyl: almost?
May 17 16:50:22 <PaulFertser> :)
May 17 16:50:27 <mickeyl> ah, hehe
May 17 16:50:31 <mickeyl> that should read always
May 17 16:50:35 <mickeyl> typo i suppose
May 17 16:51:30 <TAsn> dos1|neo, btw, did opkg upgrade, and pimm-gui is working great. ;]
May 17 16:51:52 <PaulFertser> mickeyl: probably you have a clue about recent vala building problems?
May 17 16:52:12 <TAsn> and now after I patched text wrap issues, that's also the right width... ;]
May 17 16:52:28 <mickeyl> PaulFertser: in OE or on your host?
May 17 16:52:39 <TAsn> mrmoku, compile evas, please ;]
May 17 16:53:13 <Onen_away> Deubeuliou: ping
May 17 16:54:16 <PaulFertser> mickeyl: btw, whom should i report breakage of dbus-hlid (that have a missing throw in line public string[]? ListBusNames())
May 17 16:54:18 <ptitjes> mickeyl: I should say always ?
May 17 16:54:48 <ptitjes> mickeyl: I put almost because you can also have additional errors
May 17 16:54:55 <PaulFertser> mickeyl: i'm doing an OE build from scratch (started yesterday). And couldn't properly easily build vala. Discussed with ptitjes in details.
May 17 16:55:38 <PaulFertser> ptitjes: it should be "must always throw at least" i guess.
May 17 16:55:39 <mickeyl> ptitjes: put it like "should at least"
May 17 16:55:51 <mickeyl> or "must throw at least", ya
May 17 16:55:52 <ptitjes> oki thanks
May 17 16:55:59 <ptitjes> I'll change that
May 17 16:56:05 <mickeyl> PaulFertser: i can fix that
May 17 16:56:12 <PaulFertser> Yeah, when something is a must, always is redudant.
May 17 16:56:13 <mickeyl> (dbus-hlid)
May 17 16:56:31 <PaulFertser> mickeyl: well, it's src/obj.vala, line 94 fix is trivial.
May 17 16:56:31 <onen|openBmap> mickeyl: ptitjes hi. I did yesterday a git-pull from fso specs, and a top make now crashes... is it working for you?
May 17 16:56:34 <mickeyl> let me rebuild vala from scratch in my oe build
May 17 16:56:49 <mickeyl> builds fine here on my host
May 17 16:56:49 <ptitjes> onen|openBmap: do make xml
May 17 16:56:54 <mickeyl> oh specs...
May 17 16:57:06 <ptitjes> onen|openBmap: the make doc fails
May 17 16:57:13 <ptitjes> so just make xml
May 17 16:57:26 <PaulFertser> mickeyl: as to the inability to build... First, ptitjes says that 0.7.2 must be used as a bootstrap and only 0.7.1 is available atm.
May 17 16:57:35 <onen|openBmap> ptitjes: ok. I could build the html by goind down in tree, and 'make' there
May 17 16:57:40 <ptitjes> mickeyl: it does for me too, but it seems dent, BillK and PaulFertser have a problem
May 17 16:57:54 <ptitjes> onen|openBmap: you need the doc ?
May 17 16:58:07 <PaulFertser> ptitjes: mrmoku also
May 17 16:58:20 <onen|openBmap> ptitjes: if I want to modify it for submitting patch, I want to check how the html will look
May 17 16:58:38 <mickeyl> PaulFertser: ah, well
May 17 16:58:41 <mickeyl> my tree contains 0.7.2
May 17 16:58:48 <mickeyl> sorry, i don't commit to OE for the time being
May 17 16:58:53 <PaulFertser> mickeyl: i know
May 17 16:59:36 <mickeyl> hmm
May 17 16:59:39 <mickeyl> line 94?
May 17 16:59:41 <PaulFertser> mickeyl: but even after i did "cp" for two files needed to build bootstrap and i had 0.7.2 as a bootstrap it still failed to build vala-native (couldn't reproduce it without OE)
May 17 16:59:44 <mickeyl> are you sure you build head?
May 17 16:59:58 <Sup3rkiddo> mickeyl, hi, finished onetworkd
May 17 17:00:00 <mickeyl> (vala) launching a fresh build to check
May 17 17:00:02 <mickeyl> Sup3rkiddo: cool
May 17 17:00:17 <Sup3rkiddo> mickeyl, but my ISP is sucky today, couldn't connect 
May 17 17:00:18 <Sup3rkiddo> :(
May 17 17:00:26 <PaulFertser> mickeyl: line 94 was "public string[]? ListBusNames() " here, it's what is built for shr-image.
May 17 17:00:32 <Sup3rkiddo> wikipedia, fso, google.. etc
May 17 17:01:11 <PaulFertser> mickeyl: head of what? Vala? I tried pending-upstream-move, master and mickey-0.7/posix, all failed to build with mysterious message in vapigen.
May 17 17:01:23 <Sup3rkiddo> mickeyl, so please standby..:D
May 17 17:01:25 <mickey|dinner> PaulFertser: sounds like dbus-hlid needs to be bumped, i don't see any missing throws here
May 17 17:01:27 <mickey|dinner> Sup3rkiddo: hehe, ok
May 17 17:01:31 <mickey|dinner> bbiab, dinner
May 17 17:01:38 <Sup3rkiddo> bon appetit
May 17 17:01:46 <onen|openBmap> ptitjes: last time I played with specs, the make was running fine. any hint?
May 17 17:02:13 <ptitjes> onen|openBmap: that is the addition of org.freesmartphone.xml by mickey|dinner 
May 17 17:02:38 <ptitjes> onen|openBmap: you could make doc for the other individual directories I suppose
May 17 17:03:03 <ptitjes> onen|openBmap: I personaly don't do doc but generate libfso-glib to see if the information is correct
May 17 17:03:23 <Deubeuliou> onen|openBmap: pong
May 17 17:03:29 <onen|openBmap> ptitjes: as I said, I could build the html for what I was targetting, by running make lower in tree. but I was wondering if people were aware it was broken, or if this was supposed to be this way for the moment
May 17 17:03:57 <ptitjes> onen|openBmap: mickey|dinner knows it :)
May 17 17:04:32 <onen|openBmap> ptitjes: ok thanks.
May 17 17:05:13 <onen|openBmap> ptitjes: other topic. I have now a nice little dbus service you can ask you GPS position by providing GSM data :-) ologicd will probably like it :-)
May 17 17:05:45 <ptitjes> wow excelent
May 17 17:05:51 <ptitjes> :D
May 17 17:06:13 <ptitjes> onen|openBmap: sure it will like it :)
May 17 17:06:29 <ptitjes> onen|openBmap: shouldn't this be integrated to frameworkd to provide better first fix ?
May 17 17:06:49 <ptitjes> onen|openBmap: anyway that is very cool thank you
May 17 17:07:42 <mrmoku> TAsn: have to update first I guess?
May 17 17:08:10 <ptitjes> mrmoku!
May 17 17:08:13 <TAsn> I guess.
May 17 17:08:18 <TAsn> rev 2.4
May 17 17:08:23 <mrmoku> dos1|neo: frameworkd and shr-settings is there now
May 17 17:08:28 <mrmoku> TAsn: ok
May 17 17:08:37 <ptitjes> mrmoku: do you know if I could add vala recipes to the shr overlay ?
May 17 17:08:45 <TAsn> btw, I'm not sure whether it's because I opkg upgraded
May 17 17:08:48 <TAsn> though for a week now
May 17 17:08:54 <TAsn> suspend at demand doesn't work
May 17 17:08:57 <ptitjes> mrmoku: also I am working on vala-dbus-binding-tool and libfso-glib
May 17 17:09:00 <TAsn> and breaks the phone
May 17 17:09:02 <onen|openBmap> ptitjes: I don't publicly talk about this for now, because next week will be the time for face to face talk about integration :-)
May 17 17:09:04 <TAsn> (kill the framework)
May 17 17:09:14 <TAsn> s/ll/lls/
May 17 17:09:14 <bzzbot_> TAsn meant: (kills the framework)
May 17 17:09:15 <ptitjes> mrmoku: I thought dependencies were determined by OE automatically
May 17 17:09:20 <mrmoku> ptitjes: I updated it localy to 0.7.2
May 17 17:09:20 <ptitjes> mrmoku: am I wrong ?
May 17 17:09:34 <ptitjes> mrmoku: yeah the same
May 17 17:09:34 <mrmoku> ptitjes: think you're wrong
May 17 17:09:42 <TAsn> ptitjes, I think you auto get
May 17 17:09:46 <TAsn> what's auto tools use
May 17 17:09:52 <ptitjes> mrmoku: ok so I try to add deps with DEPENDS += ""
May 17 17:09:53 <TAsn> what*
May 17 17:10:08 <TAsn> ptitjes, depends is for while building deps
May 17 17:10:14 <TAsn> package deps is rdepends
May 17 17:10:34 <ptitjes> TAsn: yep but it seems it does not change anything
May 17 17:10:50 <ptitjes> configure complains to not have libxml2
May 17 17:11:03 <TAsn> add libxml2 to depends
May 17 17:11:11 <ptitjes> and I added RDEPENDS += " libxml2-native" without any success
May 17 17:11:23 <TAsn> no
May 17 17:11:27 <TAsn> if configure complains
May 17 17:11:31 <TAsn> you must add it to depends
May 17 17:11:56 <TAsn> DEPENDS = build dependencies, RDEPENDS = package dependencies
May 17 17:12:06 <ptitjes> TAsn: should I touch local.conf everytime so that it updates the cached recipes ?
May 17 17:12:06 <TAsn> (or at least this is how I understand it)
May 17 17:12:12 <TAsn> no idea.
May 17 17:12:16 <TAsn> I'm really no expert.
May 17 17:12:20 <tonyg> ptitjes, no need to do that
May 17 17:12:26 <ptitjes> TAsn: thanks for your answer anyway :)
May 17 17:12:28 <tonyg> it will rescan just the changed one itself
May 17 17:12:39 <TAsn> np.
May 17 17:13:23 <ptitjes> ok it seems to work :)
May 17 17:13:25 <ptitjes> thanks
May 17 17:15:51 <PaulFertser> mrmoku: build shows that dbus-hlid specified in sane-srcrevs.inc can't be built with recent vala. What should be done now?
May 17 17:16:01 <PaulFertser> mrmoku: (i mean not to build but to fix)
May 17 17:16:39 <ptitjes> PaulFertser: hum then that should be overrided in shr-autorev-unstable
May 17 17:17:04 <mrmoku> PaulFertser: have to read good night story now... bbiab to discuss...
May 17 17:17:06 <PaulFertser> ptitjes: why not drop it altogether from sane-srcrevs?
May 17 17:17:10 <PaulFertser> mrmoku: :)
May 17 17:17:12 <mrmoku> TAsn: evas is building
May 17 17:17:30 <PaulFertser> mrmoku: retell it us later when you return, should be more interesting than building OE 
May 17 17:18:01 <ptitjes> :)
May 17 17:18:30 <TAsn> mrmoku, great ;] thanks.
May 17 17:22:47 <onen|openBmap> shoragan: ping
May 17 17:24:28 <ptitjes> \o/ I got vala-dbus-binding-tool to build correctly
May 17 17:33:30 <rhkfin> onen|openBmap: hey openbmap installs nice on OM2009 - but I really don't like the registratin thing.. I'm willing to contribute but I really don't see the reason to register (in the web?) to be able to submit data. How about using IMEI or something as an identifier?
May 17 17:35:20 <onen|openBmap> rhkfin: hi
May 17 17:36:03 <onen|openBmap> rhkfin: the question is the sth ;-) let me explain
May 17 17:36:27 <onen|openBmap> rhkfin: people asked for an anonymous account, or an open one, which puts data into domain public
May 17 17:36:43 <onen|openBmap> rhkfin: the problem with all of this, is the attribution of the license of data
May 17 17:36:48 <lindi-> rhkfin: registration is probably there so that if somebody starts to send wrong data it can be removed later
May 17 17:37:02 <onen|openBmap> rhkfin: indeed.
May 17 17:37:18 <lindi-> either accidentally or intentionally
May 17 17:37:52 <onen|openBmap> rhkfin: imagine we change the license (what could happen, if we follow the OSM move), you have to get the right from every contributor for what it has contributed
May 17 17:37:57 <mrmoku> PaulFertser: want to hear about the smurfs?
May 17 17:38:30 <onen|openBmap> lindi-: he he, you see bad intention everywhere ;-) but yes, that is precisely the purpose of it
May 17 17:39:09 <onen|openBmap> rhkfin: so first did I convince you that login is needed?
May 17 17:40:06 <mrmoku> TAsn: evas is there now
May 17 17:40:18 <TAsn> cool, thanks. ;]
May 17 17:40:42 <TAsn> (I already got a local build, but just wanted others to have it as well..) ;]
May 17 17:41:35 <ptitjes> hum mrmoku 
May 17 17:41:54 <mrmoku> ptitjes: tell me
May 17 17:42:16 <ptitjes> what do you think of this: http://pastebin.com/d4861f729 ?
May 17 17:43:06 * PaulFertser is lucky, shr-image was built without any problems except vala and trivial dbus-hild fix.
May 17 17:43:32 <PaulFertser> mrmoku: sure
May 17 17:45:30 <mrmoku> PaulFertser: :) about how smurfette felt treated badly by the other smurfs
May 17 17:45:38 <onen|openBmap> rhkfin: still here?
May 17 17:45:43 <PaulFertser> mrmoku: wow, rude smurfs
May 17 17:45:57 <mrmoku> writing a good-by letter and hiding 
May 17 17:46:23 <rhkfin> onen|openBmap: oops, yes, still here.
May 17 17:46:37 <mrmoku> and Gargamel catching all smurfs apart smurfette... and her saving all of them :P
May 17 17:47:00 <PaulFertser> mrmoku: Oooh, what a great heart.
May 17 17:47:41 <mrmoku> PaulFertser: though I guess smurfette won't save us from our build problems :(
May 17 17:47:53 <rhkfin> onen|openBmap: Hmm.. ok, so login is needed. Then next step: would it be possible to add an easy registration form in the client..?
May 17 17:48:20 <rhkfin> (or on the other words: does anyone know any clients to submit stuff to opencellid with no hassle..)
May 17 17:48:35 <PaulFertser> mrmoku: you see, we don't have any :) Except vala and dbus-hild, that's not much :)
May 17 17:48:37 <rhkfin> onen|openBmap: need to go but I'll read the backlog a bit later.. 
May 17 17:49:27 <PaulFertser> mrmoku: so what about dbus-hild? sane-srcrev is not sane enough and specifies a version months old, incompatible with recent vala.
May 17 17:49:28 <onen|openBmap> rhkfin: this is on todo list. but I am not sure what would bring a registration form in the client in addition to the one on the website?
May 17 17:50:06 <rhkfin> onen|openBmap: ... not needing to go to the website to register....??
May 17 17:50:07 <mrmoku> PaulFertser: for SHR we can override that in our autorev file
May 17 17:50:21 * mrmoku checks dbus-hlid
May 17 17:50:30 <PaulFertser> mrmoku: sure but probably we'd better ask nytowl to just remove it from sane-srcrevs?
May 17 17:51:07 <onen|openBmap> rhkfin: if you want to submit data to opencellid, please note that you will lose the extra quality details we log (otherwise we would not need to keep goind with openBmap). opencellid did not respond to collaboration and improved quality question from various people
May 17 17:51:30 <[Rui]> So, is this a good start? org.freesmartphone.Device.Display => http://pastebin.com/d62002567
May 17 17:52:03 <onen|openBmap> rhkfin: the licences are compatible, so opencellid could download and include our data if he wants to (we are working on the download of raw data from our site)
May 17 17:52:03 <mrmoku> PaulFertser: dbus-hlid is on AUTOREV in fso-autorev.inc (which we don't include IIRC)
May 17 17:52:34 <mrmoku> PaulFertser: don't think nytowl wants to mess around with vala short before getting a stable thing out :P
May 17 17:52:59 <onen|openBmap> rhkfin: otherwise, cellhunter guy said he would upload on regular basis, to opencellid. but he does not know when
May 17 17:53:03 <pbaxter> excuse me the disturb...does someone know how to make the ssh go on the 9may unstable image?
May 17 17:53:04 <mrmoku> PaulFertser: so setting it to AUTOREV for SHR and try it might be a good first step
May 17 17:53:34 <mrmoku> pbaxter: should work out of the box (via usb)
May 17 17:53:50 <mrmoku> pbaxter: if you want to do ssh via wifi you have to adjust /etc/default/dropbear
May 17 17:54:07 <ptitjes> gtg
May 17 17:54:13 <ptitjes> cu guys
May 17 17:54:18 <pbaxter> the thing is it doesn't work with usb
May 17 17:54:23 <pbaxter> and i can't manage to make it work
May 17 17:54:25 <onen|openBmap> rhkfin: but again: cellhuner and opencellid have ignored every propostion of collaboration on code, or taking into account our arguments about quality. So I recommend to contribute to openBmap. You will fill a database with more data, and opencellid can get the subset of it it supports
May 17 17:54:53 <mrmoku> ptitjes: cu
May 17 17:55:06 <mrmoku> pbaxter: can you ping 192.168.0.202
May 17 17:55:17 <ptitjes> mrmoku: did you finally succeed with vala ?
May 17 17:55:27 <mrmoku> ptitjes: nah... no
May 17 17:55:39 <PaulFertser> mrmoku: that's not about vala, that's about obsolete dbus-hild.
May 17 17:55:40 <mrmoku> got back to my computer now... had not much time during day today
May 17 17:55:43 <onen|openBmap> rhkfin: if you have a form in the client to register, you need to be connected to the web. So I don't think it is a big advantage. But I agree that this is a plus, for sure.
May 17 17:56:00 <mrmoku> PaulFertser: yeah, understood
May 17 17:56:00 <pbaxter> now i'm reflashing the 9may unstable image...mrmoku i tried to put the testing, change repo to unstable, then make opkg upgrade but i can't manage with this method too
May 17 17:56:11 <mrmoku> PaulFertser: vala will be the next problem :P
May 17 17:56:12 <ptitjes> PaulFertser: did you try vala with the 0.7.2-* names ?
May 17 17:56:32 <mrmoku> ptitjes: I tried that... von_fritz tried that and I guess PaulFertser tried it too
May 17 17:56:41 <PaulFertser> mrmoku: i don't have troubles to build, i'm concerned that this issue is forgotten and newcomers will have build failures (as i had today).
May 17 17:57:10 <ptitjes> mrmoku: it runs here in OE, and I think this is due to the fact I changed all the names to 0.7.2 (including the references to it vala-native_git.bb and shr-autorev-unstable
May 17 17:57:45 <mrmoku> ptitjes: I think I did that too... will recheck now
May 17 17:57:55 <ptitjes> mrmoku: version for dbus-hlid should be autored in shr-unstable
May 17 17:58:05 <mrmoku> ptitjes: yeah
May 17 17:58:08 <ptitjes> mrmoku: that would fix PaulFertser's problem
May 17 17:58:17 <mrmoku> ptitjes: btw. you know something about marshalling?
May 17 17:58:28 <ptitjes> mrmoku: related to glib ?
May 17 17:58:31 <mrmoku> ptitjes: yep
May 17 17:58:34 <ptitjes> nah
May 17 17:58:46 <mrmoku> hmm.. have it segfaulting :(
May 17 17:58:50 <onen|openBmap> rhkfin: ok. without your counter arguments it is only a monologue. So I stop here. Feel free to get in touch again, if you want to discuss this more!
May 17 17:58:58 <ptitjes> mrmoku: the gen_marshalling stuff ?
May 17 17:59:15 <ptitjes> mrmoku: I wanted to remove that from ophonekitd as I don't know what it did
May 17 17:59:20 <mrmoku> #0  0x40068244 in marshal_variant () from /usr/lib/libdbus-glib-1.so.2
May 17 17:59:20 <mrmoku> #1  0x40066e74 in _dbus_gvalue_marshal () from /usr/lib/libdbus-glib-1.so.2
May 17 17:59:23 <mrmoku> #2  0x400670ec in marshal_map_entry () from /usr/lib/libdbus-glib-1.so.2
May 17 17:59:26 <mrmoku> #3  0x4006bdec in hashtable_foreach_with_values () from /usr/lib/libdbus-glib-1.so.2
May 17 17:59:27 <ptitjes> mrmoku: I don't have it in libfso-glib for sure
May 17 17:59:48 <ptitjes> mrmoku: next symbol outside dbus ?
May 17 18:00:18 <mrmoku> #12 0x400462dc in ogsmd_sms_send_message () from /usr/lib/libframeworkd-glib.so.0
May 17 18:00:41 <mrmoku> ptitjes: thing is... that worked before... with an empty hashtable
May 17 18:01:06 <ptitjes> hum
May 17 18:01:14 <mrmoku> I'm implementing message receipts while sending sms... so now the properties hashtable has something in it
May 17 18:01:18 <mrmoku> and now it segfaults...
May 17 18:01:27 * mrmoku has NO idea about marshaling stuff...
May 17 18:01:41 <ptitjes> mrmoku: you should use dbus directly
May 17 18:01:49 <ptitjes> mrmoku: dbus-glib sucks IMHO
May 17 18:02:07 <mrmoku> ptitjes: hell... I won't do that ;)
May 17 18:02:14 <ptitjes> :)
May 17 18:02:24 <mrmoku> hope to abandon libframeworkd-glib and switch to libfso-glib
May 17 18:02:25 <ptitjes> mrmoku: use libfso-glib :)
May 17 18:02:31 <ptitjes> héhéhé
May 17 18:02:32 <ptitjes> :D
May 17 18:02:41 <mrmoku> ptitjes: I'm talking about a feature for our stable release...
May 17 18:02:49 <mrmoku> have to go with libframeworkd-glib for that
May 17 18:03:14 <ptitjes> yep yep  know :)
May 17 18:03:18 <ptitjes> was kidding
May 17 18:03:26 <mrmoku> :)
May 17 18:03:42 <mrmoku> don't think it is some grave problem... just I'm incompetent :P
May 17 18:04:43 * [Rui] grumbles... so now it's fso-glib?
May 17 18:05:35 <ptitjes> mrmoku: this may be related to http://git.freesmartphone.org/?p=libframeworkd-glib.git;a=blob;f=src/Makefile.am;hb=HEAD#l14
May 17 18:05:56 <ptitjes> [Rui]: libfso-glib is just a rewrite
May 17 18:06:12 <ptitjes> [Rui]: it is Vala generated from fso specs
May 17 18:06:19 <[Rui]> ptitjes: yeah, so I guess I should not *waste* my time on the other one, is it?
May 17 18:06:35 <ptitjes> [Rui]: "waste your time" ?
May 17 18:06:43 <ptitjes> [Rui]: it depends what you do .
May 17 18:06:45 <ptitjes> ?
May 17 18:06:51 <[Rui]> ptitjes: is it going to replace libframeworkd-glib?
May 17 18:06:58 <ptitjes> [Rui]: in the end yes
May 17 18:07:08 <ptitjes> [Rui]: but it won't happens tomorow
May 17 18:07:11 <ptitjes> :)
May 17 18:07:17 <[Rui]> ptitjes: I wanted to make omnewrotate make screen black and back on rotation :)
May 17 18:07:26 <mrmoku> ptitjes: yeah I tried to add something to the marshal list... 
May 17 18:07:34 <mrmoku> did not help though...
May 17 18:07:37 <[Rui]> and for it to work on fso distributions it needs to interacti with frameworkd
May 17 18:08:08 <ptitjes> [Rui]: if you have no reference to libframeworkd-glib yet, then yes I would suggest to use libfso-glib
May 17 18:08:20 <ptitjes> [Rui]: but be adviced it is alpha software
May 17 18:08:25 <ptitjes> still
May 17 18:08:27 <[Rui]> ptitjes: but that will mean I have to loose yet more time learning vala
May 17 18:08:38 <ptitjes> [Rui]: nah
May 17 18:08:48 <ptitjes> [Rui]: you can use it in C
May 17 18:09:02 <[Rui]> ptitjes: looks like it since there's no org.freesmartphone.Device.Display in fsoglib :)
May 17 18:09:04 <mrmoku> brb... if some dbus-glib expert passes... stay here :)
May 17 18:09:10 <ptitjes> [Rui]: valac generates C code
May 17 18:09:33 <[Rui]> ptitjes: yeah, but I was trying to hack libframeworkd-glib into supporting Display
May 17 18:09:47 <ptitjes> [Rui]: then modify the specs
May 17 18:09:57 <ptitjes> [Rui]: and re-make libfso-glib
May 17 18:10:07 <ptitjes> you'll have the new bindings in it :)
May 17 18:10:23 <ptitjes> as they are generated
May 17 18:10:47 <ptitjes> mrmoku: maybe you should try asking on #dbus ?
May 17 18:10:48 <[Rui]> ok there is org.freesmartphone.Device.Display in fso-glib!
May 17 18:11:01 <[Rui]> but where's the code?
May 17 18:11:18 <dos1|neo> [Rui]: don't listen ptitjes! his work is voodoo!
May 17 18:11:21 <dos1|neo> ;D
May 17 18:11:21 <ptitjes> [Rui]: what code ?
May 17 18:11:30 <ptitjes> [Rui]: C code ?
May 17 18:11:31 <[Rui]> ptitjes: that will actually do anything?
May 17 18:11:46 <ptitjes> [Rui]: just make libfso-glib
May 17 18:12:16 <ptitjes> [Rui]: it will generate C code, make that a library, and publish the .h file in includes dir
May 17 18:12:25 <ptitjes> include that .h
May 17 18:12:27 <[Rui]> ptitjes: and will the sysfs paths for brightness be guessed out of osmosis?
May 17 18:12:44 <ptitjes> I don't get you
May 17 18:12:51 <ptitjes> sorry [Rui] I must go
May 17 18:12:59 <ptitjes> my friends wait for me to move
May 17 18:13:02 <dos1|neo> [Rui]: frameworkd is handling sys paths
May 17 18:13:04 <ptitjes> cu
May 17 18:13:12 <[Rui]> ptitjes: no problem, maybe I'm not understanding the logic at all
May 17 18:13:13 <dos1|neo> [Rui]: i don't get you too ;p
May 17 18:14:15 <[Rui]> dos1|neo: I don't get the point of complicating what should be simple
May 17 18:14:43 <dos1|neo> [Rui]: you are tring to complicate
May 17 18:14:47 <dos1|neo> trying*
May 17 18:15:05 <[Rui]> dos1|neo: hardly, since I don't see how this does anything
May 17 18:15:11 <[Rui]> and it's adding steps to this ladder
May 17 18:15:27 <dos1|neo> libfso-glib is generated from xml spec files
May 17 18:16:04 <dos1|neo> (if i understand it correctly)
May 17 18:16:24 <dos1|neo> but i'm sure it is generated
May 17 18:16:34 <dos1|neo> so noone have to do code
May 17 18:16:44 <dos1|neo> just provide specs
May 17 18:17:02 <dos1|neo> mrmoku: ping
May 17 18:17:06 <[Rui]> dos1|neo: I suppose that the sysfs paths for setting and getting brightness are drawn from thin air, then
May 17 18:17:23 <[Rui]> ok rm -rf libfso-glib/
May 17 18:17:31 <dos1|neo> [Rui]: WTF?
May 17 18:17:37 <[Rui]> back to trying to extend libframeworkd-glib
May 17 18:17:42 <dos1|neo> sysfs paths in bindings?
May 17 18:17:49 <dos1|neo> are you crazy? ;p
May 17 18:18:16 <dos1|neo> [Rui]: sysfs paths are in frameworkd
May 17 18:18:52 <dos1|neo> [Rui]: if you will commit sysfs paths in libframeworkd-glib, i will instantly revert it ;p
May 17 18:19:07 <[Rui]> dos1|neo: no, I most certainly am not. I see lots of currently useless pieces
May 17 18:19:13 <TAsn> mrmoku, what about the gtk theme and intone? what are the decisions?
May 17 18:19:18 <[Rui]> all I want is to set and get current brightness levels
May 17 18:19:50 <dos1|neo> [Rui]: so implement Device interface from FSO
May 17 18:20:07 <dos1|neo> [Rui]: don't touch sysfs nodes from bindings!
May 17 18:20:19 <[Rui]> and while a certain level of complexity should be expected because of having a central process do things, this is a lot of nodes doing nothing between theends
May 17 18:20:22 <dos1|neo> [Rui]: fso is doing all that job for you
May 17 18:20:41 <[Rui]> dos1|neo: I'm trying to understand what the definition of "implement" is in here
May 17 18:20:55 <[Rui]> because .h files do not fit my definition
May 17 18:21:17 <dos1|neo> [Rui]: there are only .h files
May 17 18:21:20 <[Rui]> while writing a frameworkd-glib-odeviced-display.c would :)
May 17 18:21:31 <dos1|neo> [Rui]: what do you expect?
May 17 18:21:40 <PaulFertser> ptitjes|dinner: hey, do you like this better? http://rafb.net/p/LixlOe33.html
May 17 18:21:48 <PaulFertser> ptitjes|dinner: basically same shit
May 17 18:22:04 <dos1|neo> [Rui]: do you know what "bindings" mean?
May 17 18:22:24 <[Rui]> dos1|neo: really? dbus_call("org.freesmartphone.Device.Display.GetBrightness", &int_var)
May 17 18:22:47 <TAsn> hm... I'm posting a bug concerning the current battery gadget theme, it sucks, and it's pretty critical because it's hard to know what the current battery level is without actually clicking on it, which sucks.
May 17 18:22:54 <[Rui]> dos1|neo: maybe I have another understanding of that they mean
May 17 18:22:56 <dos1|neo> [Rui]: that's only thing you need
May 17 18:23:09 <[Rui]> dos1|neo: apparently not since there is nothing
May 17 18:23:21 <mrmoku> dos1|neo: pong
May 17 18:23:31 <mrmoku> TAsn: any new mails about it?
May 17 18:23:32 <dos1|neo> [Rui]: there is everything
May 17 18:23:42 <TAsn> mrmoku, not that I have seen.
May 17 18:23:46 <[Rui]> dos1|neo: right....
May 17 18:24:11 <dos1|neo> mrmoku: what about receipts? ;)
May 17 18:25:01 <[Rui]> step1: dbus-binding-tool  --mode=glib-client display.xml > display.h [v]
May 17 18:25:02 <dos1|neo> TAsn: hmm... it's getting less fileled when capacity goeas down, and it changes color
May 17 18:25:11 <dos1|neo> TAsn: for me it's good
May 17 18:25:12 <SHR-WugBranler`> tracfeed: Ticket #446 (Change the battery gadget's theme) created <http://trac.shr-project.org/trac/ticket/446>
May 17 18:25:35 <TAsn> dos1|neo, but 40-90% looks roughly the same
May 17 18:25:51 <TAsn> below 30% (or even less?) it changes color
May 17 18:26:04 <TAsn> but usually I'd like to know the state before it's too late.
May 17 18:26:18 <dos1|neo> TAsn: but it's less filled
May 17 18:26:24 <mrmoku> dos1|neo: well... implemented everything
May 17 18:26:26 <dos1|neo> and easy to see
May 17 18:26:28 <mrmoku> segfaults though
May 17 18:26:33 <TAsn> dos1|neo, not for me it isn't.
May 17 18:26:36 <TAsn> and it's also ugly.
May 17 18:26:37 <mrmoku> in dbus-glib marshaling code
May 17 18:26:43 <TAsn> anyhow, that's my bug report ;]
May 17 18:26:44 <TAsn> I gtg.
May 17 18:27:18 <dos1|neo> TAsn: then just change value when it changes color
May 17 18:27:19 <SHR-WugBranler`> tracfeed: Ticket #446 (Change the battery gadget's theme) updated <http://trac.shr-project.org/trac/ticket/446#comment:1>
May 17 18:27:29 <dos1|neo> but for me it's ok as is
May 17 18:27:52 <TAsn> dos1|neo, I would like to clearly see different levels, many levels
May 17 18:28:01 <TAsn> and it's also ugly.
May 17 18:28:10 <TAsn> anyhow, I'm off...
May 17 18:28:11 <TAsn> cya.
May 17 18:28:11 <dos1|neo> and i can see
May 17 18:28:20 <TAsn> if you think I'm wrong, please rely to the bug report.
May 17 18:28:23 <TAsn> ciao.
May 17 18:28:31 <dos1|neo> dunno what's wrong with your eyes ;)
May 17 18:29:38 <mrmoku> Ainulindale: ping
May 17 18:30:04 <mrmoku> dos1|neo: btw.... implemented also message splitting of too long messages
May 17 18:30:05 <PaulFertser> ptitjes|dinner: i told you 0.7.1-0.7.2 naming change is purely cosmetic and doesn't matter ;)
May 17 18:30:39 <dos1|neo> mrmoku: fine :)
May 17 18:33:27 <PaulFertser> mrmoku: /me getting envy, wants to see SHR on Debian
May 17 18:35:08 <mrmoku> PaulFertser: :)
May 17 18:35:08 <CIA-75> SHR: 03mok 07shr-overlay * r6d85b94fad94 10/ (3 files in 2 dirs): update vala to 0.7.2
May 17 18:35:16 * mrmoku wants to see SHR *everywhere* :P
May 17 18:35:18 <CIA-75> SHR: 03mok 07shr-overlay * rd94baaee9e2e 10/openembedded/conf/distro/include/shr-autorev-unstable.inc: autorev: set dbus-hlid to AUTOREV
May 17 18:37:30 <PaulFertser> mrmoku: so, back to the vala stuff. Do you still have problem building? 
May 17 18:37:44 <mrmoku> PaulFertser: yes
May 17 18:37:49 <PaulFertser> mrmoku: so do i
May 17 18:40:12 <PaulFertser> mrmoku: why 0.7.2 is r2 already?
May 17 18:42:53 <mrmoku> PaulFertser: hmm... don't think that matters... might have bumped it for a local rebuild... don't remember
May 17 18:42:55 <PaulFertser> mrmoku: and... why include version name in PV_pn-vala-native at all? It's autorev'd so it can be any version. In fact it was almost 0.7.3 but still labeled as 0.7.1. Isn't it better to drop version (and leave only git hash) to avoid confusion?
May 17 18:43:36 <mrmoku> PaulFertser: have to take that up with mickey|dinner I think... he did the vala recipes
May 17 18:44:08 <PaulFertser> mrmoku: it's not about recipe, it's about PV_pn-vala-native.
May 17 18:44:27 <PaulFertser> mrmoku: recipe doesn't specify any version, it just fetches HEAD.
May 17 18:45:20 <mrmoku> PaulFertser: hmm... I just built vala-bootstrap-native
May 17 18:45:22 <mrmoku> 0002 mok@mrdenker[pts/2]:~/src/other/openmoko/shrbuild/dev/shr-unstable->  tmp/staging/x86_64-linux/usr/bin/valac --version
May 17 18:45:26 <mrmoku> Vala 0.7.1
May 17 18:45:31 <mrmoku> and it is 0.7.1
May 17 18:45:46 <PaulFertser> mrmoku: no, that's impossible ;)
May 17 18:46:28 <mrmoku> PaulFertser: nvm... I'm stupid :)
May 17 18:46:49 * mrmoku actually applies his patch and rebuilds :P
May 17 18:51:09 <TAsn> how's the notifier app? should I install it?
May 17 18:51:58 <mrmoku> TAsn: install it... test it... and tell us :P
May 17 18:52:07 <TAsn> mrmoku, do you use it? ;]
May 17 18:52:40 <TAsn> mrmoku, btw, adding a notifier to phonegui-efl
May 17 18:52:43 <TAsn> shouldn't be that hard.
May 17 18:52:46 <mrmoku> TAsn: installed it once... and lost it due to a reflash short after :)
May 17 18:53:05 <TAsn> mrmoku, when will be the next image generation?
May 17 18:53:09 <TAsn> (unstable)
May 17 18:53:16 <mrmoku> TAsn: whenever vala-native builds again :(
May 17 18:53:22 <TAsn> and when is the next unstable -> testing ?
May 17 18:53:26 <TAsn> (same answer?)
May 17 18:53:28 <dos1|neo> mrmoku, TAsn: i removed messages part of notifier and now i really like it ;)
May 17 18:53:36 <mrmoku> and then I might as well rebuild it from scratch with shr.conf
May 17 18:53:51 <TAsn> dos1|neo, exactly what I'm about to do.
May 17 18:53:58 <TAsn> oh yeah I saw this post
May 17 18:54:03 <TAsn> please do.
May 17 18:55:11 <mrmoku> PaulFertser: ok... 0.7.2 now :)
May 17 18:55:24 * mrmoku tries to build vala-native... and expects it to fail like always ;)
May 17 18:56:57 <PaulFertser> mrmoku: yep, it failed for me
May 17 18:57:44 <dos1|neo> mrmoku: in some recipes there are openmoko APPEND lines... will they be included with shr.conf?
May 17 18:58:59 <mrmoku> dos1|neo: good question... don't think so
May 17 18:59:00 <SHR-WugBranler`> tracfeed: Ticket #447 (Add a notifier like view for phonegui-efl) created <http://trac.shr-project.org/trac/ticket/447>
May 17 18:59:42 <TAsn> oh sweet, it launches the phonelog app ;]
May 17 19:01:15 <mrmoku> dos1|neo: which ones? can't find any
May 17 19:02:01 <dos1|neo> mrmoku: e-wm, xserver-common... (not sure about x)
May 17 19:02:29 <dos1|neo> but some x recipe has openmoko in it
May 17 19:03:23 <von_fritz> same error here :(
May 17 19:05:35 <SHR-WugBranler`> tracfeed: Ticket #409 (autoload log on lost calls) closed <http://trac.shr-project.org/trac/ticket/409#comment:2>
May 17 19:06:30 * [Rui] shakes head. libframeworkd-glib is very badly licensed, probably basing on old errors never corrected by others...
May 17 19:07:04 <[Rui]> GNU Public License (doesn't exist), GNU Lesser Public License (doesn't exist)
May 17 19:07:17 <dos1|neo> [Rui]: libframeworkd-glib is going to death anyway
May 17 19:07:32 <dos1|neo> replaced by libfso-glib
May 17 19:07:36 <[Rui]> dos1|neo: that problem is quite probably on others
May 17 19:07:55 <[Rui]> dos1|neo: yeah, keep adding obtuse layers 
May 17 19:09:07 <dos1|neo> [Rui]: libframeworkd-glib is obtuse layer
May 17 19:09:29 <[Rui]> dos1|neo: what I saw of libfso-glib it was even worse
May 17 19:09:42 <dos1|neo> [Rui]: why should we develop something, when it can be automated?
May 17 19:09:50 <[Rui]> dos1|neo: it has zero code
May 17 19:09:59 <dos1|neo> [Rui]: as it should
May 17 19:10:16 <dos1|neo> [Rui]: bindings aren't for code
May 17 19:10:34 <dos1|neo> [Rui]: bindings are to connect to some other code
May 17 19:10:38 <[Rui]> dos1|neo: which makes it abnout as useless as a 100 € bill in the bottom of st. andreas fauolt
May 17 19:11:13 <Ainulindale> mrmoku: pong
May 17 19:11:18 <dos1|neo> [Rui]: you don't understand what "bindings" means ;p
May 17 19:11:23 <mrmoku> Ainulindale: hey... need your help
May 17 19:11:39 <mrmoku> Ainulindale: I'm sure you're a very experienced marshaller ;)
May 17 19:11:41 <[Rui]> dos1|neo: I don't understand how libfso-glib will replace libframeworkd-glib when it does another thing entirely
May 17 19:12:07 <Ainulindale> mrmoku: not that much but I can help
May 17 19:12:14 <[Rui]> dos1|neo: where should the code go, then?
May 17 19:12:19 <mrmoku> Ainulindale: I implemented SMS receipts and splitting long messages...
May 17 19:12:25 <Ainulindale> Yes?
May 17 19:12:32 <dos1|neo> [Rui]: when you was talking about sysfs paths, you showed that you don't know about what are you talking
May 17 19:12:32 <mrmoku> and no the lfg function segfaults somewehere in glib marshaller code
May 17 19:12:37 <mrmoku> s/no/now/
May 17 19:12:38 <bzzbot_> mrmoku meant: and now the lfg function segfaults somewehere in glib marshaller code
May 17 19:12:59 <dos1|neo> [Rui]: in frameworkd. as it is.
May 17 19:13:00 <Ainulindale> well wait until my girlfriend is gone and I'll help you
May 17 19:13:06 <dos1|neo> now.
May 17 19:13:13 <mrmoku> Ainulindale: send her away NOW ;)
May 17 19:13:35 <dos1|neo> [Rui]: do you think libframeworkd-glib contacts with modem to make calls?
May 17 19:13:38 <[Rui]> dos1|neo: well, I could say that you don't have a connection with people who want to program for this, but I'd rather not even think that.
May 17 19:13:44 * mrmoku is just kidding... and has already problems with dos' girlfriend... no need for problems with another :)
May 17 19:14:23 <[Rui]> dos1|neo: well, blame everyone who told me that I should use libframeworkd-glib for setting and getting brightness
May 17 19:14:30 <Ainulindale> [Rui]: you can
May 17 19:14:43 <[Rui]> Ainulindale: yeah, I'm trying to write the code for it since it has none :(
May 17 19:14:50 <mrmoku> Ainulindale: not yet implemented in lfg
May 17 19:14:57 <Ainulindale> Well ti's easy it's just mostly sed exprs
May 17 19:15:03 <Ainulindale> At least that's what I was doing myself :-)
May 17 19:15:16 <[Rui]> but now I'm reading it's all work for nothing since it'll be replaced by libfso-glib and looking at that it seems even worthless
May 17 19:15:16 <Ainulindale> (that and marshalling)
May 17 19:15:32 <[Rui]> Ainulindale: I already wrote a display.xml and generated display.h
May 17 19:15:34 <Ainulindale> [Rui]: it won't necessarily be for nothing as libfso-glib isn't used yet
May 17 19:15:50 <dos1|neo> [Rui]: you can use it
May 17 19:15:53 <Ainulindale> (at least in the packages we ship)
May 17 19:15:55 <[Rui]> Ainulindale: now I was adapting *-audio.[ch] into *-display.[ch]
May 17 19:16:31 <mrmoku> [Rui]: I spent quite some time in libframeworkd-glib... even knowing it will be obsoleted... not much of a problem I think
May 17 19:16:52 <mrmoku> [Rui]: and I offered you to do it... btw.
May 17 19:17:22 <[Rui]> mrmoku: yeah, but I thought I was also learning something usefull since I don't see why I should demand it from you :)
May 17 19:17:24 <mrmoku> [Rui]: but you said you need your phone as daily phone and don't want to risk stability
May 17 19:17:30 <Ainulindale> [Rui]: It's not worthless, doing that, as we'll have to test libfso-glib anyway
May 17 19:18:01 <[Rui]> mrmoku: yeah, but this would mean I have until tonight to hack and then reflash :)
May 17 19:18:13 <[Rui]> mrmoku: they wait for next weekend, and so forth
May 17 19:18:37 <mrmoku> Ainulindale: girlfriend gone? :P
May 17 19:18:48 * [Rui] should probably buy a second phone but... €€€€ :)
May 17 19:19:01 <Ainulindale> mrmoku: nah she's cleaning the dishes
May 17 19:19:08 * [Rui] meant a second OM phone :)
May 17 19:19:33 <mrmoku> Ainulindale: wow... educated her well ;)
May 17 19:20:11 <PaulFertser> Ainulindale: btw, do you think dishes should be cleaned before or after the meal?
May 17 19:21:26 <Ainulindale> PaulFertser: ahem. Why that question? :è)
May 17 19:21:47 <Ainulindale> PaulFertser: she just laughed at that
May 17 19:21:56 <Ainulindale> (she told me that before :-) )
May 17 19:22:25 <Ainulindale> PaulFertser: As for myself I think that the dishes should be washed when the dishwasher is full
May 17 19:22:38 <Ainulindale> But that's only my humble opinion
May 17 19:24:01 * [Rui] will be making dinner real soon now, as well.
May 17 19:24:46 <PaulFertser> Ainulindale: because i think that the best method is to fill dishes with water after the meal and wash them right before the next. I think that's the most efficient technology of hand-washing. But everybody i asked (esp. my parents) disagreed.
May 17 19:25:48 <Ainulindale> PaulFertser: she just asked whether you were married :-)
May 17 19:26:01 <Ainulindale> (Inducing that you were a lonesome cowboy)
May 17 19:26:11 <Ainulindale> (Trying desperately to keep your dishes as far from as you possible)
May 17 19:26:17 <Ainulindale> (Or at least washing them)
May 17 19:26:39 <Ainulindale> quoting
May 17 19:26:44 <Ainulindale> "meeeeen"
May 17 19:26:46 <[Rui]> PaulFertser: nothing beats having a dish washing "robot". period.
May 17 19:27:02 <Ainulindale> [Rui]: you mean a girlfriend right?
May 17 19:27:26 <[Rui]> Ainulindale: nopes, what is commonly  known as dish washing machine :)
May 17 19:27:40 <[Rui]> I'm using "robot" in the same lax sense that "roomba" is a robot.
May 17 19:27:45 * mrmoku does not care if his wife washes dishes by hand or with a robot ;)
May 17 19:28:39 <PaulFertser> Ainulindale: but it's logical, isn't it obvious? I can't understand why people wash dishes after the meal, when motivation is especially low and laziness is especially high. OTOH just before the meal you just have to wash it. Motivation is high and because there was water in it for a long enough time washing is easy.
May 17 19:29:24 <Ainulindale> PaulFertser: Genia is sighing :-)
May 17 19:29:35 <Ainulindale> (you're a russian that's for sure)
May 17 19:29:57 * mrmoku has to admit that PaulFertser's arguments are very logical :)
May 17 19:30:23 <PaulFertser> Ainulindale: i'm a geek, that's for sure ;)
May 17 19:30:29 <Ainulindale> Meh :-)
May 17 19:30:30 <[Rui]> PaulFertser: two reasons come to mind: bacteria and nostrils :)
May 17 19:30:39 <CIA-75> freesmartphone.org: 03mickey 07framework * rd188328e6a58 10/framework/ (patterns/dbuscache.py subsystems/oeventsd/leds_actions.py): 
May 17 19:30:39 <CIA-75> freesmartphone.org: dbuscachepy: use lazy lookup by default. NOTE: This means you can never assume that a dbus object is actually
May 17 19:30:39 <CIA-75> freesmartphone.org: present by the time you want to call it. You need to be prepared for errors.
May 17 19:30:40 <CIA-75> freesmartphone.org: 03mickey 07framework * r8eee6529de1e 10/framework/subsystems/ (ophoned/gsm.py ophoned/ophoned.py otimed/otimed.py): ophoned|otimed: use dbuscache
May 17 19:30:43 <CIA-75> freesmartphone.org: 03mickey 07framework * r471e7a6ab6ee 10/framework/subsystems/ousaged/generic.py: ousaged: trigger idlenotifier's busy state after waking up. Closes FSO #410
May 17 19:30:52 <Ainulindale> PaulFertser: By the way she cooked some russian meal reaally really good yesterday
May 17 19:31:05 <Ainulindale> PaulFertser: some kind of dough wrapped around meat, onions & potatoes
May 17 19:31:10 <mrmoku> uhh... have to rebuild frameworkd again :D
May 17 19:31:11 <Ainulindale> Cooked in the oven
May 17 19:31:17 <Ainulindale> I just exploded my stomach with it
May 17 19:32:09 <PaulFertser> [Rui]: bacteria is not an issue, you eat at least once a day anyway.
May 17 19:32:31 <PaulFertser> Ainulindale: I can't guess what is that, i'm not into tasty food at all, especially that contains meat.
May 17 19:32:40 <mrmoku> PaulFertser: problematic might be if you have more then three plates though :P
May 17 19:32:46 <mrmoku> s/then/than/
May 17 19:32:48 <bzzbot_> mrmoku meant: PaulFertser: problematic might be if you have more than three plates though :P
May 17 19:32:56 * Sharwin_F solved today the problem with his buildhost and is building abiword right now to make the packages available on a public repo :D
May 17 19:33:11 <PaulFertser> mrmoku: spartans don't have too much plates :)
May 17 19:33:32 <mrmoku> PaulFertser: which saves a lot of space in the kitchen too :D
May 17 19:34:16 <Ainulindale> ?????? <= PaulFertser 
May 17 19:34:21 <Ainulindale> that, according to her
May 17 19:34:33 * DocScrutinizer solves all this by eating out or not at all
May 17 19:34:49 <Ainulindale> Meh :-)
May 17 19:34:52 <PaulFertser> Ainulindale: sorry, can't read utf-8 on irc, still using an obsolete koi8-r codepage on desktop.
May 17 19:35:07 <Ainulindale> beliachi
May 17 19:35:15 <Ainulindale> (in my own phonetic crap)
May 17 19:35:27 <PaulFertser> Ainulindale: Ah, yes
May 17 19:36:27 * DocScrutinizer heading out to get some food finally, and to forget about useless working therapy projects that won't buy im any of such food
May 17 19:38:25 <CIA-75> freesmartphone.org: 03mickey 07framework * r706b56ccfc95 10/framework/subsystems/ogsmd/gsm/channel.py: ogsmd: channel.py: relaunch processing the queue after handling a timeout. Closes FSO #414.
May 17 19:42:51 <wpwrak> [Rui]: i willingly let robots rule my domestic affairs as well ;-)
May 17 19:44:52 <rhkfin> Onen_away: Thanks for the information.. I haven't followed the discussion very closely but I've seen some mails about oencellid/cellhunter/openbmap. 1) there has to be a reason to collect the information. For cellhunter it seemed like a game that really didn't work. AFAIK both Opencellid and openbmap are targeting for reusage of the data which sound's good to me. But then again if no co-operation can be made something must be wrong and one or more proj
May 17 19:45:20 <cyberalex> hi, there is a way to change the default profile at boot on shr?
May 17 19:46:46 <rhkfin> Onen_away: btw. how about using OpenID on the web site?
May 17 19:47:40 <PaulFertser> (working therapy projects) nice euphemism :)
May 17 19:52:40 <Ainulindale> mrmoku: back & available
May 17 19:52:51 <mrmoku> Ainulindale: ok :)
May 17 19:53:11 <mrmoku>                 ogsmd_sms_send_message(number, data->content, options, NULL, NULL);
May 17 19:53:18 <wpwrak> PaulFertser: often enough, the jobs will eventually find you if you're doing something interesting :)
May 17 19:53:25 <mrmoku> works fine, when options (GHashTable) is empty
May 17 19:53:41 <mrmoku> if I add values to it... it segfaults somehwere in marshalling code
May 17 19:55:00 <Ainulindale> mrmoku: could you give me the links to the prototypes of the dbus specs? as well as to the marshalling definition?
May 17 19:55:12 <PaulFertser> wpwrak: it was the case with me (i wasn't doing anything particularly interesting though). I suddenly realised i can built some device using a uC. So i studied a bit and did it. Half a year later a job found me.
May 17 19:55:16 <mrmoku> moment
May 17 19:56:21 <mrmoku> Ainulindale: the spec: http://git.freesmartphone.org/?p=libframeworkd-glib.git;a=blob;f=src/ogsmd/dbus/sms.xml;h=fe0f63377c4271aadd21cad03b28dc2f624d524e;hb=abfe3711bbfcdecfe1368ca21ce414dfb99c2aee
May 17 19:56:34 <wpwrak> PaulFertser: yup, much more fun than anxiously searching for work
May 17 19:57:22 <PaulFertser> wpwrak: but really, i can't see too how OM BOM can give anything. When anyone needs it he will just ask about particular component and someone with access will tell him.
May 17 19:57:23 <Ainulindale> hmmm a simple a{sv} should aready be handled
May 17 19:57:29 <Ainulindale> s/are/alre/
May 17 19:57:29 <bzzbot_> Ainulindale meant: hmmm a simple a{sv} should already be handled
May 17 19:57:59 <PaulFertser> wpwrak: you explained it two times, i failed to understand :)
May 17 19:58:08 <mrmoku> Ainulindale: does it matter would v I add to the hashtable?
May 17 19:58:20 <wpwrak> PaulFertser: sure, that's how we're handling it now anyway. but it's a) cleaner of the BOM is officially published, and b) it removes the gatekeeper role
May 17 19:58:31 <khiraly1> mickey|dinner: are you there?
May 17 19:58:37 <Ainulindale> mrmoku: what?
May 17 19:58:44 <Ainulindale> (listcalls is already handling that)
May 17 19:59:00 <Ainulindale> as well as callstatus
May 17 19:59:10 <Ainulindale> So I'm not sure the marshalling is failing here
May 17 19:59:25 <mrmoku> Ainulindale: I mean I add ints and strings... that should be fine, no?
May 17 19:59:32 <wpwrak> PaulFertser: i.e., you're more likely to check a component if you have the BOM already than if you first have to ask someone, then that person has to do to the searching and eventually gets back with the result.
May 17 19:59:53 <Ainulindale> mrmoku: logically yes
May 17 20:00:27 <Ainulindale> could you give me the full error log?
May 17 20:00:37 <Ainulindale> Optionally a bt with info?
May 17 20:01:14 <mrmoku> Ainulindale: bt: http://pastebin.com/d38a7a4d8
May 17 20:01:17 <wpwrak> PaulFertser: i think it's always good if i can make myself replaceable in a project :) this means that i get to play with the new and interesting things, and won't be bogged down with boring routine tasks
May 17 20:01:26 <PaulFertser> wpwrak: I guess gta02-core is a nice project to explore how well KiCAD and community-driven approach works. But i'd hope too to see something more interesting than gta02 come from it; probably it's methodologically wrong but it'd be cool to see a more interesting device developed in a way like that. Probably i'm hopelessly wrong here.
May 17 20:01:44 <Ainulindale> mrmoku: did you try without int? 
May 17 20:01:56 <Ainulindale> or with an empty but not null hashtable?
May 17 20:02:16 <wpwrak> PaulFertser: gta02-core is just the first step. the idea is to scavange as much as possible from openmoko to keep the engineering effort and the cost down.
May 17 20:02:19 <Ainulindale> and is the error on a signal or on a method?
May 17 20:02:32 <Ainulindale> (said nothing, saw my answer)
May 17 20:02:36 <mrmoku> Ainulindale: you mean hashtable with g_str_hash, g_str_equal... but nothing in it?
May 17 20:02:41 <Ainulindale> yes
May 17 20:02:56 <mrmoku> did not try that, no
May 17 20:03:00 <Ainulindale> Could you try?
May 17 20:03:02 <wpwrak> PaulFertser: once this is done, we can apply the same process to more exciting things. and we're also more likely to find sponsors.
May 17 20:03:02 <mrmoku> yep
May 17 20:03:10 <PaulFertser> wpwrak: hm, wasn't it the case with OM itself? I don't think we like the result of such "engineering". 
May 17 20:03:10 <wpwrak> PaulFertser: (or so i hope :)
May 17 20:03:11 <Ainulindale> Then could you try with different types of variant?
May 17 20:03:14 <Ainulindale> Only str, then only int
May 17 20:03:15 <Ainulindale> Then both
May 17 20:04:16 <PaulFertser> wpwrak: i mean taking so much from previous designs (done by some incompetent EE), then hiring the same EE's to continue the development etc.
May 17 20:04:32 <mrmoku> Ainulindale: building with an empty one now
May 17 20:05:00 <wpwrak> PaulFertser: well, i'm not saying that we should use the gta02 design beyond gta02-core. it's just that almost all the trainblazing has been done by openmoko already, so what gta02-core does is bring the hw development and prototyping process out into the open.
May 17 20:05:20 <wpwrak> PaulFertser: yes, but we know gta02 pretty well now, don't we ? :)
May 17 20:06:19 <Ainulindale> DocScrutinizer: hey o/
May 17 20:06:27 <PaulFertser> wpwrak: I'm you know what you're doing :) Even if i fail to understand/like it ;) I guess i'm just trying to explain why Joerg is frustrated with gta02-core.
May 17 20:06:53 <PaulFertser> s/I'm/I'm sure/
May 17 20:06:53 <bzzbot_> PaulFertser meant: wpwrak: I'm sure you know what you're doing :) Even if i fail to understand/like it ;) I guess i'm just trying to explain why Joerg is frustrated with gta02-core.
May 17 20:07:48 <wpwrak> PaulFertser: i think he's generally a bit frustrated :-( and i think he doesn't see this as a useful step towards getting something real done.
May 17 20:08:27 <wpwrak> PaulFertser: maybe he also doesn't quite see that the goal of gta02-core isn't really the device but the process
May 17 20:08:51 <onen|openBmap> rhkfin: ping
May 17 20:09:06 <PaulFertser> wpwrak: i guess he just had too many pains with gta02 and any reminder of it hurts.
May 17 20:09:10 <Ainulindale> onen|openBmap: hey you
May 17 20:09:25 <Ainulindale> onen|openBmap: still ok to take your car?
May 17 20:09:46 <onen|openBmap> rhkfin: 1. there has to be reason to collect information. My point of view is, we can collect almost everything, as raw data. afterwards anybody can do anything (game, location, innovative things) with it
May 17 20:09:50 <wpwrak> PaulFertser: once we have the process in place (and the people, company contacts, etc.), it's much easier to do something more demanding. and you won't stumble over small details all the time, because you've already solved them in gta02-core.
May 17 20:09:53 <onen|openBmap> rhkfin: so better to log too much
May 17 20:10:29 <onen|openBmap> rhkfin: openstreetmaps (opencellid guy always give them as an exmaple) allows to put *any* tag. so far opencellid refuesed to modify anything to his database
May 17 20:10:36 <wpwrak> PaulFertser: (gta02) oh, i'll be happy enough if gta02-core boots and can show the gui in all its glory and _speed_ ;-)
May 17 20:10:43 <rhkfin> onen|openBmap: ping
May 17 20:10:47 <rhkfin> pong..
May 17 20:11:27 <PaulFertser> wpwrak: btw, forgot to ask you, probably you have a minute to explain it: what was the story about glamoectomy? Did sd-multiplexer misbehave or what?
May 17 20:11:40 <rhkfin> I see and understand (I've contributed to openstreetmap myself too..). 
May 17 20:11:40 <PaulFertser> wpwrak: or was it already told elsewhere?
May 17 20:11:52 <onen|openBmap> rhkfin: we proposed back in january to put our data in opencellid db, and merge our project with it. no response (see ML archive)
May 17 20:11:53 <rhkfin> onen|openBmap: so I see your point (see ^)..
May 17 20:12:07 <wpwrak> PaulFertser: you mean "how will gta02-core connect wlan" ?
May 17 20:12:09 <rhkfin> I hope things start working.. Sorry, need to go again :(
May 17 20:12:11 <onen|openBmap> rhkfin: for openid
May 17 20:12:20 <onen|openBmap> rhkfin: I like very much the idea
May 17 20:12:29 <onen|openBmap> definitely this lays now on todo list
May 17 20:12:39 <PaulFertser> wpwrak: I meant i know you spent considerable time to rip out glamo from gta02 when it was still possible before MP.
May 17 20:12:55 <onen|openBmap> rhkfin: but know that I am taking care of the client side. Nick the server side. And I think he has even less time than I have
May 17 20:13:02 <PaulFertser> wpwrak: i've read gta02-core will connect by SPI.
May 17 20:13:34 <onen|openBmap> Ainulindale: yes. but we are lacking driver to replace me when me takes a nap ;-)
May 17 20:13:55 <onen|openBmap> Ainulindale: I talk to Deubeuliou about the car sharing
May 17 20:14:06 <Ainulindale> Well I can drive it's just a matter of insurance
May 17 20:14:20 <onen|openBmap> Ainulindale: he needs a ride with us, and prefers leaving on friday morning
May 17 20:14:50 <onen|openBmap> Ainulindale: yep, I looked at it: 3 x "franchise" when driver under 3 years experience, + 3 years assured
May 17 20:15:07 <Ainulindale> so?
May 17 20:15:12 <Ainulindale> Do you really think I'll crash your car? :- )
May 17 20:15:33 <Ainulindale> Because I can try to change my license plates & carte grise by wednesday
May 17 20:15:36 <Ainulindale> but it's a bit short
May 17 20:16:11 <wpwrak> PaulFertser: (mp) no, that was after mp. a bit after gta02 mp started, there was the idea to make a new device ("gta03") with a 2442, edge, no glamo, no case, etc. unfortunately, that project had a completely unrealistic schedule and was cancelled around august 2008
May 17 20:16:12 <Deubeuliou> hi everyone
May 17 20:16:18 <onen|openBmap> rhkfin: I have prepared a proof of concept to use our data. a d bus service to wich you provide your gsm data, and it gives you your location. I will show it at FSOSHRUDCON
May 17 20:17:17 <wpwrak> PaulFertser: i only then proposed to make a gta02 without glamo, very similar to what's now gta02-core. in particular, it would have used the same case, because that part of engineering worked particularly badly.
May 17 20:17:50 <wpwrak> PaulFertser: or perhaps i should say "coordination between design and engineering". in fact, design is a lot more to blame than engineering.
May 17 20:17:59 <onen|openBmap> Ainulindale: that's the point. especially to drive on highway, there is not much risk. (is it? ;-) )
May 17 20:18:04 <PaulFertser> (designe to blame) no wonder :-/
May 17 20:18:10 <onen|openBmap> Ainulindale: so I am ok if you drive while I sleep
May 17 20:18:20 <mrmoku> Ainulindale: ok... empty hashtable works
May 17 20:18:26 <Ainulindale> onen|openBmap: ok then it's good :-)
May 17 20:18:29 <Ainulindale> mrmoku: ah good news then
May 17 20:18:41 <mrmoku> Ainulindale: why?
May 17 20:18:44 <onen|openBmap> Ainulindale: but I thought you would prefer to travel with ptitjes|dinner, or does he already get on your nerves ?
May 17 20:18:56 <Ainulindale> mrmoku: well it might just be a poorly defined marshalling and/or hashtable
May 17 20:19:11 <mrmoku> Ainulindale: shall I try with one int now?
May 17 20:19:21 <Ainulindale> mrmoku: yep :-)
May 17 20:19:25 <wpwrak> PaulFertser: alas, that gta02-reduced was rejected and only gta03-6410 was made. (i made the gta02-redux proposal after gta03-6410 had already started)
May 17 20:19:26 <mrmoku> ok :)
May 17 20:19:41 <onen|openBmap> Ainulindale: did you decide if we leaves thursday evening, or friday morning?
May 17 20:19:46 <Ainulindale> friday 
May 17 20:19:55 <Ainulindale> at least I'm leaving friday
May 17 20:20:06 <onen|openBmap> Ainulindale: good. I and Deubeuliou prefer this too.
May 17 20:20:22 <wpwrak> PaulFertser: now, the wlan attachment. we discussed this in the beginning of gta03-2442. hw suggested a muxer. sw was horrified by the idea. (ask mwester about muxers ;-)
May 17 20:20:24 <Ainulindale> Good :-)
May 17 20:20:40 <onen|openBmap> I send you an email with my phone number
May 17 20:21:15 <wpwrak> PaulFertser: then hw looked for a chip that would connect to the bus and implement sd/mmc. they found some chips, but none of them worked with a 1.8 V bus voltage.
May 17 20:22:09 <Ainulindale> good
May 17 20:22:15 <Ainulindale> mine is everywhere on the net
May 17 20:23:06 <wpwrak> PaulFertser: and putting an extra chip on the bus wouldn't have been nice anyway. so i investigated if it would be possible in principle to use the ar6001 with spi. eventually, atheros admitted that there was a bug that would greatly complicate "native spi", but that "sdio in spi mode" would work, although slowly.
May 17 20:23:58 <wpwrak> PaulFertser: then i implemented that, first replacing the sdio stack and then chasing interesting bugs in the s3c spi and sdio drivers.
May 17 20:24:17 <mrmoku> argghh
May 17 20:24:25 * mrmoku hates when his laptop freezes :(
May 17 20:25:16 <wpwrak> PaulFertser: in the end, i got fairly reasonable performance, with some ideas how it could be made even a bit faster.
May 17 20:26:34 <wpwrak> PaulFertser: at that time, all 2442-centric plans had been buried, so from then on i worked only on the sdio side and fixes to the wlan driver, dropping spi.
May 17 20:26:51 <Deubeuliou> Ainulindale: mrmoku: bitbake still creates an empty package from my vala code
May 17 20:27:00 <wpwrak> PaulFertser: but spi would be easy to bring back.
May 17 20:27:10 <PaulFertser> wpwrak: thanks for amazing story-telling (and for your work again), now we know a bit more of OM history and what Sean told about various devices on various levels of readiness (And about atheros).
May 17 20:27:58 <wpwrak> PaulFertser: yeah, that gta03-2442 was a sad story. there were also two (!) gta04 projects that died in their infancy.
May 17 20:28:22 <onen|openBmap> Ainulindale: does your number end by 24?
May 17 20:28:24 <Ainulindale> Deubeuliou: full bitbake log and recipe please
May 17 20:28:27 <Ainulindale> onen|openBmap: yes
May 17 20:28:41 <Ainulindale> and starts with 06 20 :-)
May 17 20:28:43 <wpwrak> PaulFertser: one around april 2008, which involved a lot of discussions about mcu, also publicly, and that was dropped because there was just too much chaos.
May 17 20:29:07 <onen|openBmap> Ainulindale: ok. my number is an email I just sent to ptitjes|dinner. He will forward it to you.
May 17 20:29:57 <wpwrak> PaulFertser: and the, about at the time when gta03-6410 started, there was the idea that we don't need hw engineers and can just outsource all that stuff. joerg would have been in charge of this one, perhaps a consolation price for andy getting the much more exciting gta03-6410.
May 17 20:30:16 <wpwrak> s/a con/as a con/
May 17 20:30:17 <bzzbot_> wpwrak meant: PaulFertser: and the, about at the time when gta03-6410 started, there was the idea that we don't need hw engineers and can just outsource all that stuff. joerg would have been in charge of this one, perhaps as a consolation price for andy getting the muc...
May 17 20:32:02 <wpwrak> PaulFertser: gta04 died the day openmoko got a quote from the outsourcing firm. they either wanted to do the design with the chips they were familiar with (stuff that wouldn't meet our openness goals), or charge a prohibitively high price.
May 17 20:32:41 <PaulFertser> wpwrak: cruel world :(
May 17 20:33:34 <Deubeuliou> Ainulindale: http://pastebin.com/d200938bc
May 17 20:33:47 <wpwrak> PaulFertser: well, not that anyone in engineering was really surprised :) "we can just outsource your work and it will be such much better and cheaper" rarely works, and if it does, few engineers would admit it anyway ;-)
May 17 20:34:05 <Ainulindale> No wonder it won't work Deubeuliou 
May 17 20:34:12 <Ainulindale> inherit autotools please :-)
May 17 20:34:25 <Ainulindale> else it won't ./configure & make
May 17 20:34:40 <cyberalex> i have other problems with phonelog on shr..
May 17 20:35:02 <Ainulindale> onen|openBmap: marf :-)
May 17 20:35:13 <Deubeuliou> Ainulindale: with that, it fails at do_install
May 17 20:35:15 <cyberalex> i just upgraded it and now there are no way to start it..
May 17 20:35:24 <Ainulindale> Deubeuliou: then show me the log with it :-)
May 17 20:35:32 <Deubeuliou> plus, the .ipk package that it created is empty
May 17 20:35:33 <Deubeuliou> 'k
May 17 20:35:35 <cyberalex> (shr testing)
May 17 20:35:43 <Ainulindale> if it fails at do_install it doesn't create an IPK
May 17 20:36:09 <PaulFertser> wpwrak: judging by community ML there was a considerable demand for a caseless device, and gta03-2442 from your description looks exactly like what was needed. Being targeted at developers it probably couldn't have much problems with OM design and PR departments; also being based on 2442 it shouldn't be too hard to implement based on existing gta02 experience; what was the problem with it then?
May 17 20:36:56 <wpwrak> PaulFertser: the problem was that gta03-2442 wasn't caseless ...
May 17 20:37:13 <Deubeuliou> Ainulindale: http://pastebin.com/d2c907caf
May 17 20:37:18 <PaulFertser> wpwrak: "to make a new device ("gta03") with a 2442, edge, no glamo, no case, etc."
May 17 20:37:34 <Ainulindale> Deubeuliou: inherit autotools does the ./configure job by the way
May 17 20:37:54 <Ainulindale> Do you have a install rule in your autotools thingy?
May 17 20:38:11 <wpwrak> PaulFertser: the design of the new case was outsourced to an apparently quite famous designer, who created a demanding design and didn't communicate well with engineering. plus, all this was on a rather capricious schedule.
May 17 20:38:22 <wpwrak> PaulFertser: oh sorry, that should have been "new".
May 17 20:38:54 <PaulFertser> wpwrak: ah... I thought it was quite reasonable to assume that OM had a caseless device in developing targeted at embedded market.
May 17 20:39:29 <wpwrak> PaulFertser: also, openmoko didn't actually have a mechanical engineer until fairly late. so there wasn't really anyone in openmoko that designer could talk to for mechanical issues.
May 17 20:40:02 <wpwrak> PaulFertser: the caseless device only came up fairly recently, about end 2008/beginning 2009
May 17 20:40:25 <mrmoku> Ainulindale: ok... just adding one int to the hashtable makes it segfault
May 17 20:40:32 <wpwrak> PaulFertser: of course, the case is very cheap to make, so if you just want the pcb, those few dollars for the case don't matter
May 17 20:40:38 <Ainulindale> mrmoku: but not one str right?
May 17 20:41:07 <mrmoku> Ainulindale: no str... just added
May 17 20:41:07 <mrmoku>         g_hash_table_insert(options, "status-report-request", 1);
May 17 20:41:22 <Ainulindale> it's segfault only in the send right?
May 17 20:41:39 <Deubeuliou> Ainulindale: yes, it should have ... as long as my local Makefile has. I'll try to find the sources fetched by bitbake
May 17 20:41:40 <wpwrak> PaulFertser: but most potential customers for a bare board would have wanted some modifications. and openmoko had a hard enough time to make one variant, so that would have needed a completely different engineering team. (bigger, more experienced, etc.)
May 17 20:41:40 <mrmoku> yeah, when sending... not when adding the int
May 17 20:41:43 <PaulFertser> wpwrak: apparently it matters for development, so between choosing to not have any device at all and to have a caseless device (when the case is not needed anyway).
May 17 20:41:56 <PaulFertser> wpwrak: ah, i see now.
May 17 20:42:01 <Ainulindale> Deubeuliou: bitbake -c devshell
May 17 20:42:38 <Deubeuliou> Ainulindale: in shr-unstable/tmp/work/armv4t-angstrom-linux-gnueabi/libframeworkd-phonegui-gtk2-0.0.1+gitr3+69af8dd79a6a9e4223a11c4ad33ff54c
May 17 20:42:41 <Deubeuliou> 1dbf8f37-r0/git
May 17 20:43:02 <Deubeuliou> there is no Makefile, but onlya Makefile.am .. seems like it doesn't do the ./autogen
May 17 20:43:17 <Ainulindale> Wrong S maybe?
May 17 20:43:53 <wpwrak> PaulFertser: in fact, i think the best approach for "bare boards" would be to just let the customers make their own changes. a lot of them apparently had access to a strong EE team (or at least that's what they said)
May 17 20:44:04 <Deubeuliou> Ainulindale: ah, maybe
May 17 20:44:25 <khiraly1> wpwrak: so there were a completely new case design for gta03 too?
May 17 20:44:38 <wpwrak> PaulFertser: but then openmoko never got to licensing the complete design. also, even then, there would have been support issues that would probably have overwhelmed openmoko's hw team.
May 17 20:44:42 <Ainulindale> Deubeuliou: is the configure part quick?
May 17 20:45:15 <mrmoku> TAsn: doing hw or do you have a moment?
May 17 20:45:16 <PaulFertser> wpwrak: why was it that hard to build a good hw team for OM? 
May 17 20:45:18 <wpwrak> PaulFertser: (extrapolating from how well the issues with gta02 were handled ;-)
May 17 20:45:25 <mrmoku> TAsn: http://rafb.net/p/Vvep8E37.html
May 17 20:45:45 <TAsn> mrmoku, doing h.w and have a moment.
May 17 20:45:46 <TAsn> sec.
May 17 20:46:13 <TAsn> please check you ~/.phonelog.conf
May 17 20:46:14 <Deubeuliou> Ainulindale: everything is quick
May 17 20:46:23 <Ainulindale> Then wrong workdir
May 17 20:46:24 <wpwrak> khiraly1: yes, a pretty nice one actually. nice in the sense of good-looking. alas, it was also very hard to make. but yes, i think there are two "almost done" prototypes now :)
May 17 20:46:25 <TAsn> seems like it's set to use the custom daemon.
May 17 20:46:29 <Deubeuliou> I'll try /git instead of ${PN}
May 17 20:46:45 <Deubeuliou> and if it doesn't help, ${PN}/git
May 17 20:46:47 <mrmoku> TAsn: what is that?
May 17 20:46:47 <Ainulindale> considering your S, yes, your workdir is wrong
May 17 20:46:48 <TAsn> mrmoku, actually
May 17 20:46:51 <TAsn> Can't Find /var/db/phonelog.db Falling back to the daemon
May 17 20:46:55 <Ainulindale> err, SRC_URI I meant
May 17 20:47:00 <TAsn> mrmoku, what I had before the shr phonelog ;]
May 17 20:47:05 <Ainulindale> Deubeuliou: easy to check
May 17 20:47:09 <TAsn> do you have /var/db/phonelog.db?
May 17 20:47:14 <cyberalex> TAsn: how to restore it?
May 17 20:47:14 <Ainulindale> check where your sources are
May 17 20:47:21 <Ainulindale> then modify S accordingly
May 17 20:47:23 <khiraly1> wpwrak: but only prototypes. So no molding case (what is really expensive in this process)
May 17 20:47:25 <TAsn> cyberalex, oh, it's your issue?
May 17 20:47:29 <TAsn> not mrmoku's?
May 17 20:47:30 <cyberalex> yep
May 17 20:47:39 <TAsn> ophonekitd should have created it
May 17 20:47:42 <mrmoku> TAsn: I don't have a phonelog... nobody is calling me :P
May 17 20:47:48 <TAsn> it's an ophonekitd issue... ;]
May 17 20:47:54 <cyberalex> ah..
May 17 20:47:55 <TAsn> mrmoku, then put your sim in, duh...
May 17 20:48:05 <TAsn> mrmoku, it's an ophonekitd issue.
May 17 20:48:12 <wpwrak> PaulFertser: good question. one thing is that openmoko started with a lot of horrible people from FIC. they were eventually dumped in a great purge in mid-2008 after gta03-2442 was cancelled. i didn't like that timing, because the couldn't have saved gta03-2442 anyway, but the performance of the hw team improved after these layoffs.
May 17 20:48:13 <TAsn> check why it's not creating the db.
May 17 20:48:16 <mrmoku> TAsn: ahh... thought that would not be necessary with an opensource phone ;)
May 17 20:48:16 <cyberalex> i already restarted ophonekitd..
May 17 20:48:28 <TAsn> mrmoku, ;]
May 17 20:48:35 <TAsn> cyberalex, and it still haven't created it?
May 17 20:48:41 <cyberalex> yes
May 17 20:48:42 <wpwrak> khiraly1: no, no mold yet. also no complete mechanical testing (drop etc.)
May 17 20:48:44 <TAsn> hm... what version of shr are you using?
May 17 20:48:47 <cyberalex> it haven't
May 17 20:48:53 <cyberalex> testing
May 17 20:48:55 <TAsn> cyberalex, sure? (check manually please)
May 17 20:49:03 <cyberalex> sure sure..
May 17 20:49:15 <TAsn> (I meant check manually if the file exists)
May 17 20:50:05 <cyberalex> ok
May 17 20:50:37 <cyberalex> ho..
May 17 20:50:41 <cyberalex> my excuses
May 17 20:50:45 <PaulFertser> wpwrak: it's like a night on insights for us (general public) today, so many information made open (to -cdevel inhabitants). Thanks a lot!
May 17 20:50:48 <khiraly1> wpwrak: What Im really wondering, is what this mysterious project C is, which does only involve a few people, and apparently some opengl developers. I really hope is not a video card;)
May 17 20:51:24 <wpwrak> PaulFertser: most of the remaining people didn't have a lot of experience and had absorbed some bad habits from FIC (e.g., that it's a crime for a hw engineer to know anything about sw, and vice versa), so the team still wasn't as good as it could have been. they got better since then, though.
May 17 20:51:38 <cyberalex> i restarted ophonekitd another time and now phonelog.db exists
May 17 20:51:53 <TAsn> cyberalex, ok
May 17 20:51:56 <TAsn> now run phonelog
May 17 20:51:57 <wpwrak> PaulFertser: and finally openmoko also hired a few new people for the hw team, who are very experienced and really good.
May 17 20:52:17 <wpwrak> PaulFertser: but that happened quite recently
May 17 20:52:26 <PaulFertser> wpwrak: and a good news at the end, amazing night! :)
May 17 20:52:49 <wpwrak> PaulFertser: heh, i wonder if sean would wring my neck if he knew :)
May 17 20:52:59 <TAsn> cyberalex, does it work?
May 17 20:53:18 <khiraly1> wpwrak: are these people listed on who is who page? (the hw guys coming from FIC, and the newly hired hw people)
May 17 20:53:48 <PaulFertser> wpwrak: I think people in here know that they shouldn't talk about sensitive matters publicly, so that should be ok :) 
May 17 20:54:04 <wpwrak> khiraly1: you mean project B or C ? i don't know much about project C. they kept is secret even from me ;-)
May 17 20:54:13 <wpwrak> s/is/it/
May 17 20:54:13 <bzzbot_> wpwrak meant: khiraly1: you mean project B or C ? i don't know much about project C. they kept it secret even from me ;-)
May 17 20:54:42 <khiraly1> wpwrak: hehe. I meant project B. Is it even project C too?
May 17 20:54:47 <khiraly1> ;)
May 17 20:54:51 <wpwrak> khiraly1: hmm, which who is who page ?
May 17 20:55:03 <khiraly1> http://wiki.openmoko.org/wiki/Who_is_Who
May 17 20:55:12 <dos1|neo> project X
May 17 20:55:32 <cyberalex> TAsn: whit the "fix" i made yes, now i'm trying it with the default script
May 17 20:55:44 <TAsn> what fix did you make?
May 17 20:55:45 <dos1|neo> hmm... X is already owned ;x
May 17 20:55:48 <wpwrak> PaulFertser: good :) i think everyone has already figured out that there were some problems in openmoko, but it may still embarrass some
May 17 20:55:56 <khiraly1> dos1|neo: project X, is just means the "last person leaving the office switch off the light" ;))
May 17 20:56:09 <cyberalex> do you remember my duplicate ticket?
May 17 20:56:43 <wpwrak> khiraly1: ah, project B ... well, it is indeed much simpler than gta02 or gta03.
May 17 20:56:51 <dos1|neo> khiraly1: hahaha ;D
May 17 20:57:19 <TAsn> cyberalex, what fix?
May 17 20:57:26 <dos1|neo> wpwrak: we know what project b is
May 17 20:57:43 <dos1|neo> wpwrak: it's open toaster
May 17 20:57:55 <dos1|neo> ;)
May 17 20:57:56 <mrmoku> Ainulindale: any idea what I can do?
May 17 20:58:16 <TAsn> dos1|neo, I actually need one of those
May 17 20:58:23 <Ainulindale> mrmoku: hmmm sadly no :-/
May 17 20:58:25 <TAsn> my toaster doesn't behave like I want it to.
May 17 20:58:29 <CIA-75> SHR: 03deubeuliou 07libframeworkd-phonegui-gtk2 * rdcf7953c3f49 10/po/Makefile.in.in: added missing po/Makefile.in.in
May 17 20:58:45 <dos1|neo> TAsn: that's why project B won't fail
May 17 20:58:47 <cyberalex> not a real fix
May 17 20:58:49 <dos1|neo> ;)
May 17 20:58:50 <cyberalex> http://shr-project.org/trac/ticket/441
May 17 20:58:50 <TAsn> dos1|neo, ;]
May 17 20:58:53 <Ainulindale> my marshalling expert was mw
May 17 20:58:57 <wpwrak> dos1|neo: yup. no telephony needed for that ;-)
May 17 20:58:58 <khiraly1> wpwrak: I only read back there were some opengl developer hiring at OM recently. And Steve has some video card background. I only hope is not a video card development....
May 17 20:59:08 <khiraly1> wpwrak: or even a glamo-successor! ;-D
May 17 20:59:23 <PaulFertser> khiraly1: that was probably related to the plans on using 6410 integrated graphics.
May 17 20:59:29 <TAsn> cyberalex, what about it?
May 17 20:59:37 <Sharwin_F> some help with this? any idea of what to try?
May 17 20:59:38 <Sharwin_F> ERROR: QA Issue with staging: gnet-2.0.pc failed sanity test (tmpdir) in path /var/OE/tmp/staging/armv4t-angstrom-linux-gnueabi/usr/lib/pkgconfig
May 17 20:59:42 <dos1|neo> openglamo
May 17 20:59:48 <dos1|neo> strange
May 17 20:59:48 <TAsn> oh, it's not correct
May 17 20:59:49 <dos1|neo> ;)
May 17 20:59:50 <TAsn> (the fix)
May 17 20:59:55 <TAsn> I can actually make it fix correctly
May 17 21:00:04 <TAsn> though I don't want to spend even a minute on something like that
May 17 21:00:06 <PaulFertser> dos1|neo: i'm afraid to see any kind of glamo in my night dreams.
May 17 21:00:08 <TAsn> since in a week time
May 17 21:00:15 <TAsn> everyone will reflash anyway.
May 17 21:00:26 <wpwrak> khiraly1: i think i shouldn't deny or confirm anything about the feature set of that device, but i think the opengl developers vanished with the last round of layoffs
May 17 21:00:52 <khiraly1> PaulFertser: its nice to fix the *worst* part in the system. Its like an engineering challenge, shoing to the world: We can!!!
May 17 21:01:06 <wpwrak> khiraly1: hehe, yeah an openmoko asic that's bigger, buggier, and slower than the glamo would be something :)
May 17 21:01:21 <PaulFertser> khiraly1: btw, it was told openly that plan B won't run Linux, so judge for yourself.
May 17 21:01:34 <dos1|neo> PaulFertser: THE ARMY OF GLAMOS!
May 17 21:01:47 <wpwrak> PaulFertser: that would fit the glamo theory :)
May 17 21:01:48 <PaulFertser> wpwrak: soviet ICs are the biggest ICs in the world
May 17 21:01:55 <Weiss> yep, one of the old OM opengl people told me they both weren't working for OM any more
May 17 21:02:12 <PaulFertser> dos1|neo: screw you, i'm going to sleep soon and you keep talking about that ;)
May 17 21:02:13 <wpwrak> PaulFertser: hah, i would think the biggest one were made in texas ? :)
May 17 21:02:15 <khiraly1> PaulFertser: yepp no telephony, no linux. Only a bunch of people required. I dont have that big of imagination
May 17 21:02:23 <dos1|neo> wpwrak: Toasters theory too
May 17 21:02:24 <dos1|neo> ;)
May 17 21:03:17 <wpwrak> khiraly1: fixing the glamo is easy. all it takes is a bit of mercy killing :)
May 17 21:03:28 <PaulFertser> wpwrak: I've seen they (USAers) made some huge 3-wheel bikes with V8 but i'm yet to hear anything about ICs from Texas ;)
May 17 21:03:55 <wpwrak> PaulFertser: like Texas Instruments ? ;_)
May 17 21:04:04 <lindi-> openmoko inc. should have started with car phones that are so large that it is possible to have socketed components that can be replaced .)
May 17 21:04:11 <wpwrak> PaulFertser: proud creators of the Calypso
May 17 21:04:28 <rhkfin> onen|openBmap: I can't wait to see the app showing my location based on the GSM info, nice, nice :)
May 17 21:04:35 <PaulFertser> wpwrak: :)
May 17 21:04:41 <PaulFertser> lindi-: in DIP
May 17 21:04:56 <wpwrak> lindi-: yeah, nothing like a 332-DIP case with 100 mil pitch ;-))
May 17 21:05:01 <khiraly1> what I was wondering (and asked about the pcb traces on the mailing list), is can be just removed the glamo and connecting the appropriate legs together. Its reuired to see the actual traces to see how feasable is it.
May 17 21:05:38 <wpwrak> khiraly1: you still need to connect LCM and SDIO somewhere
May 17 21:05:46 <dos1|neo> khiraly1: then you have to choose: sd reader or wifi
May 17 21:06:21 <khiraly1> hehh, right. So not s simple rerouting the pcb traces in the area were glamo was
May 17 21:06:55 <onen|openBmap> rhkfin: I don't remember if I told you I have a protype of a dbus service to get your position. Now I lack time to put this as a source of position for another app, let's say tangogps?)
May 17 21:07:04 <wpwrak> khiraly1: alas, no. but if you have the full set of EDA files, it's a simple enough change
May 17 21:07:22 <dos1|neo> khiraly1: you would read about people doing that if it would be easy ;)
May 17 21:07:54 <khiraly1> dos1|neo: I read between the lines, its not the actual change is hard, but putting the new board into mass produce
May 17 21:08:22 <dos1|neo> khiraly1: both are hard
May 17 21:08:36 <wpwrak> dos1|neo: just read the gta03 list and about the gta02-core project :)
May 17 21:08:53 <dos1|neo> hmm
May 17 21:08:56 <TAsn> lindi-, here?
May 17 21:09:00 <lindi-> TAsn: yep
May 17 21:09:10 * dos1|neo is searching
May 17 21:09:27 <khiraly1> dos1|neo: yepp its hard *now*, because they have the crazy idea to recreate the whole design from scratch. Its take time and passion
May 17 21:09:27 <TAsn> I want to open a ticket in the shr trac concerning the switch to Xorg, mind helping me with pros and cons?
May 17 21:09:46 <wpwrak> dos1|neo: alas, no plans for mass production in that. well, if someone came and gave us some money, i wouldn't argue against MP
May 17 21:10:13 <wpwrak> khiraly1: (crazy) that's what they always say until you do it ;-)
May 17 21:10:42 <lindi-> TAsn: oh well, both fail before we can use KMS :)
May 17 21:10:59 <TAsn> is that a pro or a con? ;]
May 17 21:11:43 <Deubeuliou> mrmoku: I get this error when bitbake tries do_compile:
May 17 21:11:44 <Deubeuliou> /home/deubeuliou/dev/openmoko/shr-unstable/tmp/staging/i686-linux/usr/bin/valac -C --vapidir vapi --pkg vala-1.0 --pkg dbus-glib-1 --pkg freesmartphone-1.0 --pkg libxml-2.0 --pkg gtk+-2.0 --library libframeworkd-phonegui-gtk2 --basedir . phonegui-dialer.c phonegui-numpad.c phonegui.c phonegui-dialer.h phonegui-numpad.h phonegui.h
May 17 21:11:49 <Deubeuliou> error: freesmartphone-1.0 not found in specified Vala API directories
May 17 21:12:03 <Deubeuliou> I ahve a freesmartphone-1.0.vapi
May 17 21:12:12 <Deubeuliou> there:
May 17 21:12:14 <Deubeuliou> ./tmp/work/armv4t-angstrom-linux-gnueabi/libfso-glib-0.0.1-gitrLOCAL-r0/libfso-glib/src/freesmartphone-1.0.vapi
May 17 21:12:33 <mrmoku> --vapidir vapi
May 17 21:12:43 <lindi-> TAsn: well, at least Xorg is actively developed
May 17 21:13:03 <TAsn> and iirc the glamo driver is better, right?
May 17 21:13:03 <mrmoku> Deubeuliou: that is the source code...
May 17 21:14:06 <TAsn> and kdrive isn't.
May 17 21:14:12 <khiraly11> -history
May 17 21:14:15 <TAsn> (actively developed, right?)
May 17 21:14:26 <TAsn> and btw, isn't kdrive more memory+cpu efficient?
May 17 21:14:58 <mrmoku> Deubeuliou: won't find that there
May 17 21:15:01 <cyberalex> TAsn: phonelog is empty..i made some calls but they are not displayed..
May 17 21:15:08 <Deubeuliou> I remove that line ?
May 17 21:15:15 <TAsn> cyberalex, ;\
May 17 21:15:19 <mrmoku> Deubeuliou: no
May 17 21:15:19 <Deubeuliou> sorry, I didn't realise
May 17 21:15:20 <TAsn> please try rebooting the device
May 17 21:15:24 <khiraly11> btw, any ETA of announcing this mysterious project B? August?
May 17 21:15:28 <TAsn> as I said, it seems like a ophonekitd issue.
May 17 21:15:37 <mrmoku> Deubeuliou: you should have freesmartphone-1.0.vapi somewhere in tmp/staging
May 17 21:15:37 <cyberalex> ok
May 17 21:16:00 <cyberalex> maybe is better if i switch to unstable X)
May 17 21:16:06 <Deubeuliou> so ... that means libfso-glib's staging wasn't successful ?
May 17 21:16:20 <mrmoku> Deubeuliou: yeah ... guess so
May 17 21:16:48 <mrmoku> Deubeuliou: why are you doing a local build of libfso-glib btw.?
May 17 21:17:16 <Deubeuliou> that's a good question
May 17 21:17:37 <TAsn> lindi-, according to your benchmarks, would you conclude Xorg runes better than kdrive?
May 17 21:17:57 <Deubeuliou> --vapidir vapi  <-- that line should stay as is, right ?
May 17 21:18:55 <lindi-> TAsn: at least it's not noticeably slower in any specific area and it is faster in some (in xvkbd at least)
May 17 21:19:03 <mrmoku> Deubeuliou: don't know... it specifies where to look for vapi files... I think
May 17 21:19:37 <PaulFertser> dos1|neo: btw, i thing Poland is part of Schengen space, do you have any problems crossing the border?
May 17 21:19:44 <TAsn> lindi-, got the link to your test results? (I want to attach it to the ticket)
May 17 21:20:22 <Weiss> ah, lindi- :D
May 17 21:20:37 <dos1|neo> PaulFertser: in eu? i shouldn't have
May 17 21:20:44 <Weiss> lindi-: do i take from a recent commit to xf86-video-glamo that your bug has been fixed, or was that something different?
May 17 21:20:52 <lindi-> Weiss: different
May 17 21:21:00 <Weiss> aww :(
May 17 21:21:02 <lindi-> Weiss: the fundamental issue still stands
May 17 21:21:03 <PaulFertser> dos1|neo: so why don't you come to S9C? 
May 17 21:21:27 <lindi-> TAsn: iki.fi/lindi/openmoko/xf86-video-glamo/x11perf1.txt
May 17 21:21:35 <dos1|neo> PaulFertser: S9C?
May 17 21:21:35 <TAsn> thanks.
May 17 21:21:36 <PaulFertser> dos1|neo: i thought you just can't cross the border legally without some paper tuff.
May 17 21:21:45 <PaulFertser> dos1|neo: yes, FSOSHRUDEVCON i meant
May 17 21:21:50 <dos1|neo> oh
May 17 21:22:37 <TAsn> lindi-, cool, added.
May 17 21:22:38 <SHR-WugBranler`> tracfeed: Ticket #448 (Consider switching to Xorg.) created <http://trac.shr-project.org/trac/ticket/448>
May 17 21:22:39 <TAsn> thanks.
May 17 21:22:47 <lindi-> Weiss: i haven't signed the nda so it's bit difficult for me to get the real picture though
May 17 21:23:13 <dos1|neo> PaulFertser: school, parents, and days. If it would be in summer vacations, i would have more chances to come
May 17 21:23:17 <lindi-> Weiss: would be nice if you and lars could go through all the glamo I/O in kernel and Xorg and figure out which ones still can crash the system if the system is too slow to respond
May 17 21:23:34 <PaulFertser> dos1|neo: do you really have problems to skip 2 days in school in Poland? O_o
May 17 21:23:45 <TAsn> lindi-, one last thing
May 17 21:23:50 <TAsn> I want to test it on my moko
May 17 21:23:55 <TAsn> which version do you suggest?
May 17 21:23:56 <TAsn> cvs?
May 17 21:24:08 <TAsn> 1.5.3? (latest stable in OE)
May 17 21:24:16 <dos1|neo> PaulFertser: now - yes. ending of year.
May 17 21:24:22 <lindi-> TAsn: it's in git
May 17 21:24:22 <Weiss> lindi-: i suspect some nasty interaction between the MMC kernel code and other things - perhaps a little locking is needed. i'm having a thesis "sprint" at the moment, though..
May 17 21:24:37 <TAsn> xserver-xorg_cvs.bb ;\
May 17 21:24:44 <TAsn> kdrive does show like in git
May 17 21:25:07 <lindi-> Weiss: ok. i guess what i am trying to say here is that we should have a stable and clean version before moving to performance optimizations
May 17 21:25:14 <Weiss> yes, of course
May 17 21:25:29 <lindi-> TAsn: ah, I have Xorg 1.6
May 17 21:25:36 <lindi-> TAsn: the one from debian
May 17 21:25:43 <Weiss> the fact that i can make it crash as well indicates that it's nothing at all to do with the command queue or 2D handling...
May 17 21:25:48 <TAsn> lindi-, I use shr
May 17 21:25:49 <Weiss> unless by some very obscure interaction
May 17 21:26:07 <lindi-> Weiss: ok
May 17 21:26:43 <Weiss> (since in my version the command queue and 2D engine is handled in the kernel and unchanged across Xorg start/stop)
May 17 21:26:53 <PaulFertser> dos1|neo: ok, i really hope you'll be more free next time :)
May 17 21:27:32 <dos1|neo> PaulFertser: i hope that too :)
May 17 21:37:38 <dos1|neo> yay
May 17 21:37:47 <dos1|neo> busy on resume :)
May 17 21:37:52 <dos1|neo> mrmoku: ping
May 17 21:38:08 <dos1|neo> mrmoku: regenerate frameworkd please :)
May 17 21:39:48 <mrmoku> dos1|neo: again?
May 17 21:40:07 <mrmoku> you did not commit anything and I rebuilt after mickeys updates
May 17 21:40:21 * Sharwin_F compiled successfully abiword and installing now.
May 17 21:40:28 * Sharwin_F wishes his server connection was faster... xD
May 17 21:41:58 <mickey|dinner> fyi: try http://git.freesmartphone.org/?p=openembedded.git;a=commitdiff;h=65c212dd12f9eaa02079fcd74203d425d129a1f4
May 17 21:42:03 <mickey|dinner> should fix the vala problem
May 17 21:42:05 <mickey|dinner> g'night
May 17 21:42:39 <dos1|neo> mmrmoku: oh, ok then
May 17 21:42:49 <dos1|neo> mrmoku: i thought commits were after build
May 17 21:43:45 <mrmoku> dos1|neo: :)
May 17 21:44:21 <mrmoku> mickey|zzZZzz: thanks
May 17 21:48:02 <Deubeuliou> mrmoku: does libfso-glib compile on your side ?
May 17 21:48:18 <Deubeuliou> I realised that bitbake -b libfso-glib was doing nothing
May 17 21:48:23 <Deubeuliou> so I make update'd
May 17 21:48:38 <Deubeuliou> and now, I got an error message I saw before:
May 17 21:48:53 <Deubeuliou> checking whether the C compiler works... configure: error: cannot run C compiled programs.
May 17 21:48:57 <Deubeuliou> If you meant to cross compile, use `--host'.
May 17 21:49:10 <Deubeuliou> Do I have to build vala again ?
May 17 21:51:54 <mrmoku> Deubeuliou: can't even try... because vala-native does not build... though I'll push mickey|zzZZzz's patch now
May 17 21:52:17 <Deubeuliou> aha, ok
May 17 21:56:50 <CIA-75> SHR: 03mok 07shr-overlay * rf131c6227107 10/patches/vala/0001-update-vala-to-0.7.2.patch: patches: add fixed vala 0.7.2 update
May 17 21:57:33 <Deubeuliou> (the process is bitbaking vala and then vala-bootstrap-native ?)
May 17 21:57:56 <mrmoku> Deubeuliou: for now you have to *first* clean vala-bootstrap-native and vala-native
May 17 21:57:59 <mrmoku> and then build vala-native
May 17 21:58:08 <Deubeuliou> ok, wrong one
May 17 21:58:16 <TAsn> mrmoku, does this mean you'll be regenerating an image soon?
May 17 21:58:36 <TAsn> :)
May 17 21:58:42 <mrmoku> TAsn: testing it now... if it builds yep
May 17 21:58:43 <dos1|neo> mrmoku: +1 for question above?
May 17 21:58:55 <dos1|neo> ok :)
May 17 21:58:56 <TAsn> mrmoku, cool! :)
May 17 21:59:07 * mrmoku wanted to go to bed... just one second before mickey|zzZZzz posted the vala fix :(
May 17 21:59:11 <TAsn> mrmoku, use shr.conf, check that as well.
May 17 21:59:23 <mrmoku> TAsn: I'm testing locally with shr.conf
May 17 21:59:25 <TAsn> mrmoku, let it build. (overnight)
May 17 21:59:45 <TAsn> do whatever you please ;]
May 17 22:00:01 <TAsn> just regenerate an image when you have the time.
May 17 22:01:13 <mrmoku> TAsn: yeah... will trigger the build from scratch before going to bed :P
May 17 22:01:29 <PaulFertser> mrmoku: cleaning vala-native should be enough judging by the patch
May 17 22:01:40 <TAsn> cool, I think I'll reflash tomorrow then. ;]
May 17 22:01:46 <TAsn> I have an issue I hope is related to opkg upgrade
May 17 22:02:09 <dos1|neo> TAsn: which issue?
May 17 22:02:15 <TAsn> suspending
May 17 22:02:28 <TAsn> when I suspend on demand (power press/e menu)
May 17 22:02:37 <TAsn> it doesn't suspend and crash frameword
May 17 22:02:50 <dos1|neo> TAsn: unstable?
May 17 22:02:58 <dos1|neo> latest?
May 17 22:03:00 <TAsn> btw, mrmoku what about restoring the power button's behavior
May 17 22:03:03 <TAsn> dos1|neo, unstable
May 17 22:03:08 <TAsn> latest after opkg upgrade
May 17 22:03:18 <mrmoku> TAsn: already restored... have to rm -rf .e to get it ;)
May 17 22:03:25 <mrmoku> and vala-native does not build for me :(
May 17 22:03:32 <TAsn> happened to me in last weeks upgrade
May 17 22:05:17 <mrmoku> hmm... triggered the shr.conf rebuild anyway :P
May 17 22:05:30 <mrmoku> at least the lite image should hopefully build...
May 17 22:05:42 <TAsn> mrmoku, great, I use the lite image.
May 17 22:05:43 <TAsn> ;]
May 17 22:06:02 <mrmoku> anyway... off to bed now :D
May 17 22:06:06 <TAsn> same here
May 17 22:06:06 <mrmoku> good night all
May 17 22:06:08 <TAsn> already 1am ;\
May 17 22:06:09 <TAsn> night.
May 17 22:06:27 <TAsn> will give Xorg a try tomorrow.
May 17 22:13:48 <Deubeuliou> gnight
May 17 22:18:37 <DocScrutinizer> wpwrak: PaulFertser: just for the records: GTA04-II wasn't a consolation price or less interesting than the (in the end quite boring and conservative) GTA03-III. It was a quite demanding project, alas the negotiations failed because of hw-noobs asking for a quotation from business-guys without real hw-background, for a product either of them had any idea what it should be in the end, and none was used to the vocabulary of the other. 
May 17 22:18:38 <DocScrutinizer> Probably if Wolfgang had invited me to these negotiations, or at least would have listened to my suggestions how to proceed, thing went diffenetly :-(
May 17 22:20:14 <DocScrutinizer> *differently
May 17 22:22:04 <DocScrutinizer> wpwrak: but, remembering your heartly wishes back when for the whole project to fail boldly, I don't expect you agree with me here
May 17 22:32:46 <wpwrak> DocScrutinizer: okay, the consolation price was just my impression. and yes, i remember that they basically kept you on standby all the time, without involving you
May 17 22:35:05 <wpwrak> DocScrutinizer: regarding wishing it to fail, well i didn't expect the concept to work. also with some other experience we had with outsourcing to china. so i was afraid that this project would in fact keep openmoko from strengthtening the taipei team.
May 17 22:36:04 <DocScrutinizer> heh, this strengthening panned out excellently in the end, no?
May 17 22:39:01 <wpwrak> DocScrutinizer: in fact, it did. the hardware team has gotten much better - most of the "old" engineers were working more efficiently and more carefully, and several new and very experienced people have been added.
May 17 22:39:47 <DocScrutinizer> muahahaha
May 17 22:40:12 <wpwrak> DocScrutinizer: i don't think you've even met them ;-)
May 17 22:40:43 <DocScrutinizer> sure, most likely as a direct result of asking them to do GTA04 inhouse even
May 17 22:41:47 <DocScrutinizer> (not met them) aaah, so all those brilliant new EE were hired 2009, right???
May 17 22:42:29 <wpwrak> DocScrutinizer: by the way, do you really believe you would have been given enough autonomy to run gta04 they way you felt was right ? just see how gta03 went under andy.
May 17 22:42:51 <DocScrutinizer> so now I finally get the idea of cancelling GTA03, we need all resources for GTA04 now
May 17 22:43:02 <wpwrak> ;-))
May 17 22:43:57 <wpwrak> DocScrutinizer: (hired) i'm talking about adam, ivorin, and ruby. adam joined late 2008, i think. don't remember when ivorin joined. ruby joined when i was there. so yes, all recent hires.
May 17 22:44:15 <DocScrutinizer> nah, sorry. /me away before I start to wonder how much of mobbing actualy is hidden in this conversation
May 17 22:44:34 <wpwrak> DocScrutinizer: no mobbing 
May 17 22:53:48 <DocScrutinizer> (autonomy) I don't think Steve and me are easy to take over. Especially if we both agree on how things should be done. We even were half way to killing very last restriction imposed to our project, which was "use gta02 case, though you may massively modify". Nah this was messed prenatal by management
May 17 22:55:07 <DocScrutinizer> otherwise by now we might have a really geeky device
May 17 22:56:06 <wpwrak> DocScrutinizer: hmm, again, just think of what happened with gta03. steve+andy couldn't protect it from random changes either.
May 17 22:56:23 <wpwrak> DocScrutinizer: but indeed, you never had a chance with gta04
May 17 22:57:07 <DocScrutinizer> werner, you had no complete picture, and you don't have today, wrt 04. autonomy was the headline
May 17 23:00:37 <DocScrutinizer> autonomy here means Steve and Me are in charge from MRD to product spec, to EE, stoping at marketing
May 17 23:01:00 <DocScrutinizer> except case
May 17 23:01:14 <DocScrutinizer> and that was dieing as well
May 17 23:03:20 <DocScrutinizer> autonomy meant as well we mustn't distract any manpower from gta03
May 17 23:04:34 <DocScrutinizer> so your rationale GTA04-II might have delayed/hindered TPE EE augentation, is not applicable
May 17 23:05:50 <wpwrak> DocScrutinizer: I meant that it would have created the impression that it wasn't necessary to improve the TPE team
May 17 23:06:51 <DocScrutinizer> our (Steve&joerg) "contract" was we're completely free to choose CPU any type, hw-specs as we see fit, no limits at all. And Steve promised to not say asingle word ;-)
May 17 23:07:41 <DocScrutinizer> how should it? TPE was more than busy with Gta03, and Wolfgang was hiring as hell already
May 17 23:10:20 <wpwrak> DocScrutinizer: (steve not saying a word) hehe :) well, i think the autonomy would have ended when gta03 hit the first snag. then gta04 would all of a sudden have become the project that must not fail, and you would have had to deal with interventions. of course, this is just my conjecture, based on how i've seen people reason and behave.
May 17 23:10:47 <DocScrutinizer> well, never mind - though it's hard to forget "I hope the whole thing will fail"
May 17 23:11:09 <DocScrutinizer> duh, sorry :-//
May 17 23:11:12 <wpwrak> DocScrutinizer: that wasn't meant to be against you
May 17 23:11:15 <DocScrutinizer> s/steve/sean/
May 17 23:14:31 <DocScrutinizer> (must not fail) this was the idea from beginning. We didn't publish it even internally to not discourrage tpe team by giving them a feeling of "maybe you fail" and thus discourrage anybody. So gta04-III was semi-secret
May 17 23:15:04 <wpwrak> DocScrutinizer: in fact, i felt you had been given a lemon. i don't think you would have succeeded in getting that company to implement what you wanted. they would just have ignored you.
May 17 23:15:39 <DocScrutinizer> never try, never know
May 17 23:15:59 <DocScrutinizer> I planned to get a chair in their EE department
May 17 23:16:04 <wpwrak> DocScrutinizer: that's of course true
May 17 23:20:13 <wpwrak> DocScrutinizer: okay, 24/7 surveillance may have helped :)
May 17 23:20:30 <DocScrutinizer> that's been the plan
May 17 23:21:45 <DocScrutinizer> honnestly I'm rather glad it never happened, given the 75% employment contact with OM ;-)
May 17 23:22:02 <DocScrutinizer> contRact
May 17 23:22:35 <wpwrak> DocScrutinizer: it would have been more like a 150% project ;-)
May 17 23:22:46 <DocScrutinizer> minimum
May 18 00:25:48 <viq> $ ffalarms 
May 18 00:25:48 <viq> Traceback (most recent call last):
May 18 00:25:48 <viq>   File "/usr/bin/ffalarms", line 6, in <module>
May 18 00:25:48 <viq>     main()
May 18 00:25:48 <viq>   File "/usr/lib/python2.6/site-packages/ffalarms/ffalarms.py", line 656, in main
May 18 00:25:51 <viq>     if ecore.evas.engine_type_supported_get('software_x11_16'):
May 18 00:25:54 <viq>   File "ecore.evas.c_ecore_evas.pyx", line 115, in ecore.evas.c_ecore_evas.engine_type_supported_get (ecore/evas/ecore.evas.c_ecore_evas.c:1978)
May 18 00:25:57 <viq>   File "ecore.evas.c_ecore_evas.pyx", line 88, in ecore.evas.c_ecore_evas.engine_type_from_name (ecore/evas/ecore.evas.c_ecore_evas.c:1782)
May 18 00:26:00 <viq> ValueError: Ecore_Evas_Engine_Type changed and bindings are now invalid, position 180 is now NULL!
May 18 00:26:06 <viq> Same error happens with omoney. Ideas?
**** ENDING LOGGING AT Mon May 18 02:59:57 2009