**** BEGIN LOGGING AT Thu Nov 05 02:59:56 2009
Nov 05 03:01:11 <DocScrutinizer> so, as it seems nobody is tempted to answer to my nonsense.... see ya in another few weeks
Nov 05 03:02:33 <juri_> doc: hmm?
Nov 05 03:02:46 <juri_> he can't reproduce my problem, because its gta01 specific.
Nov 05 03:02:52 <juri_> so... ;)
Nov 05 03:04:10 <DocScrutinizer> juri_: can you elaborate on your problem, in a concise and precise way?
Nov 05 03:04:41 <DocScrutinizer> juri_: I have ONE ghta01 here
Nov 05 03:06:08 <DocScrutinizer> juri_: please keep in mind I'm mainly a hw-guy ;)
Nov 05 03:06:38 <juri_> doc: its been 8 or 9 months since i reported it. ;)
Nov 05 03:06:43 <DocScrutinizer> though I managed quite some sw-projects
Nov 05 03:06:50 <juri_> http://trac.shr-project.org/trac/ticket/318
Nov 05 03:06:56 <DocScrutinizer> mompl
Nov 05 03:07:27 <juri_> basically, when the power managment functions for the gsm were touched, the gsm daemon died.
Nov 05 03:08:05 <juri_> mrmoku's last comment leads me to believe he wants to close the bug, as 'not reproduceable' due to him not having an 01.
Nov 05 03:11:40 <DocScrutinizer> juri_: TAsn is on crack. Sorry
Nov 05 03:15:38 <DocScrutinizer> it's plain ridiculous to state "we can't reproduce because of no more hw, so closing as 'invalid' "
Nov 05 03:17:38 <DocScrutinizer> juri_: probably you should talk to mwester, PaulFertser, lindi-, and whoever else has the oldy-but-goody gta01 hw here
Nov 05 03:18:48 <DocScrutinizer> good night. see ya next year
Nov 05 03:23:30 <DocScrutinizer> btw: seen Ainulindales comment on this ticket?
Nov 05 03:29:32 <DocScrutinizer> fucking netsplit!
Nov 05 03:31:05 <DocScrutinizer> 102 now
Nov 05 03:32:03 <DocScrutinizer> I can afford and dare to get banned ;-)
Nov 05 03:32:07 <DocScrutinizer> so...
Nov 05 03:32:32 <DocScrutinizer> [2009-11-05 04:02:44] <juri_> he can't reproduce my problem, because its gta01 specific.
Nov 05 03:32:34 <DocScrutinizer> [2009-11-05 04:02:50] <juri_> so... ;)
Nov 05 03:32:35 <DocScrutinizer> [2009-11-05 04:04:08] <DocScrutinizer> juri_: can you elaborate on your problem, in a concise and precise way?
Nov 05 03:32:37 <DocScrutinizer> [2009-11-05 04:04:38] <DocScrutinizer> juri_: I have ONE ghta01 here
Nov 05 03:32:38 <DocScrutinizer> [2009-11-05 04:06:06] <DocScrutinizer> juri_: please keep in mind I'm mainly a hw-guy ;)
Nov 05 03:32:40 <DocScrutinizer> [2009-11-05 04:06:36] <juri_> doc: its been 8 or 9 months since i reported it. ;)
Nov 05 03:32:42 <DocScrutinizer> [2009-11-05 04:06:40] <DocScrutinizer> though I managed quite some sw-projects
Nov 05 03:32:44 <DocScrutinizer> [2009-11-05 04:06:48] <juri_> http://trac.shr-project.org/trac/ticket/318
Nov 05 03:32:46 <DocScrutinizer> [2009-11-05 04:06:53] <DocScrutinizer> mompl
Nov 05 03:32:48 <DocScrutinizer> [2009-11-05 04:07:25] <juri_> basically, when the power managment functions for the gsm were touched, the gsm daemon died.
Nov 05 03:32:51 <DocScrutinizer> [2009-11-05 04:08:03] <juri_> mrmoku's last comment leads me to believe he wants to close the bug, as 'not reproduceable' due to him not having an 01.
Nov 05 03:32:54 <DocScrutinizer> [2009-11-05 04:11:38] <DocScrutinizer> juri_: TAsn is on crack. Sorry
Nov 05 03:32:56 <DocScrutinizer> [2009-11-05 04:15:36] <DocScrutinizer> it's plain ridiculous to state "we can't reproduce because of no more hw, so closing as 'invalid' "
Nov 05 03:32:59 <DocScrutinizer> [2009-11-05 04:17:36] <DocScrutinizer> juri_: probably you should talk to mwester, PaulFertser, lindi-, and whoever else has the oldy-but-goody gta01 hw here
Nov 05 03:33:02 <DocScrutinizer> [2009-11-05 04:18:46] <DocScrutinizer> good night. see ya next year
Nov 05 03:33:06 <DocScrutinizer> [2009-11-05 04:23:28] <DocScrutinizer> btw: seen Ainulindales comment on this ticket?
Nov 05 03:33:08 <DocScrutinizer> [2009-11-05 04:26:52] * DocScrutinizer going to close bugs as "not reproduceable" in VAX, OS390 hw, and S7 uControler.... I don't have any of those
Nov 05 03:33:51 <DocScrutinizer> ~ping
Nov 05 03:33:52 <apt> ~pong
Nov 05 03:34:03 <DocScrutinizer> :-))
Nov 05 03:37:51 <DocScrutinizer> juri_: night!
Nov 05 04:15:25 <juri_> oh. ;)
Nov 05 04:15:28 <juri_> hi there. :)
Nov 05 04:33:01 <PaulFertser> juri_: hey
Nov 05 04:33:57 <PaulFertser> juri_: do you know we have a bugtracker for system-level stuff? http://docs.openmoko.org , set component to "System Software" (mandatory, else nobody will see and think about the ticket).
Nov 05 04:35:26 <PaulFertser> juri_: (gsm pm) currently it works like this: userspace (still) fails to turn the modem off before rebooting/powering off the device. So the modem works but only after real (unplug/plug the battery) cold boot.
Nov 05 04:41:44 <juri_> cute.
Nov 05 06:30:17 <TAsn> DocScrutinizer, so what if I'm on crack? :)
Nov 05 06:32:06 <TAsn> juri_, what I meant there, is that if people won't answer us, we'll have to close it. We can't debug it without a gta01, so we need your answers, but no one answered us,  so we were just left in the dark, with an open bug we can't solve because neither of us has a gta01 and no one else is willing to help.
Nov 05 06:32:12 <TAsn> or even confirm.
Nov 05 06:32:14 <TAsn> cio.
Nov 05 06:32:15 <TAsn> ciao.
Nov 05 06:43:02 <blindcoder> mornin'
Nov 05 06:56:44 <PaulFertser> TAsn: if frameworkd is actually able to turn off the modem with AT@POFF or not is quite easy to determine even without a gta01: just comment out "echo 0 > power_on" in the framework and see if the modem is still accessible after you release GSM or not.
Nov 05 07:04:08 <spaetz> TAsn: it seems a bit random whether oss or alsa is used.
Nov 05 07:04:31 <spaetz> in my case no OSS module was loaded, but not all necessary snd modules were loaded either.
Nov 05 07:04:40 <spaetz> A simple modprobe snd-soc-neo1973-gta02-wm8753 fixed sound for me...
Nov 05 07:05:01 <spaetz> morning people, btw :)
Nov 05 07:05:19 <rebelThor> mornin` spaetz :) still at the same level as last day ? ;)
Nov 05 07:05:44 <spaetz> rebelThor: no, I didn't try to fix sound yesterday. But fixed it during commuting to work :)
Nov 05 07:05:50 <spaetz> so its better today :)
Nov 05 07:06:16 <spaetz> I always carry a box of matches with me around now, so I can type on the FR :)
Nov 05 07:06:21 <rebelThor> hehe
Nov 05 07:06:28 <rebelThor> are you a smoker ?
Nov 05 07:06:31 <spaetz> no :)
Nov 05 07:09:18 <spaetz> ohh, we even have GTA03 prepared in OE: CONFIG_NAME_om-gta03 = "gta03_defconfig"
Nov 05 07:09:24 <spaetz> optimistic...
Nov 05 07:14:02 <spaetz> compiling fails today.
Nov 05 07:14:07 <spaetz> mickey|zzZZzz: !!!
Nov 05 07:14:30 <spaetz> does FSO* need stock vala-0.7.8 now or a fso specific one again?
Nov 05 07:14:44 <spaetz> fso* needs vala 0.7.8 but we only have 0.7.7
Nov 05 07:32:37 <JaMa|Zzzzz> spaetz: probably my fault with kernel compile..
Nov 05 07:32:43 <JaMa> moin
Nov 05 07:35:06 <spaetz> JaMa: kernel compile? no some fso* stuff was failing
Nov 05 07:35:15 <spaetz> as vala was not new enough...
Nov 05 07:36:06 <JaMa> ah, kernel failed for me.. so i was thinking its related to CONFIG_NAME_om-gta03 before..
Nov 05 07:36:27 <spaetz> nono, just noticed there were references to gta03, nothing has changed there, I believe
Nov 05 07:51:51 <JaMa> updated feed-failed list ERROR: '/home/projects/OE/dev/recipes/classpath/classpath-native_0.97.2.bb' failed
Nov 05 07:51:54 <JaMa> ERROR: '/home/projects/OE/dev/recipes/tracker/tracker_0.5.4.bb' failed
Nov 05 07:51:56 <JaMa> shit
Nov 05 07:51:59 <JaMa> ERROR: '/home/projects/OE/dev/recipes/gnome/libunique_1.1.2.bb' failed
Nov 05 07:52:00 <JaMa> http://pastebin.ca/1658048
Nov 05 07:52:31 <rebelThor> Requested 'vala-1.0 >= 0.7.8' but version of Vala is 0.7.7+fso5 :D
Nov 05 07:52:43 <rebelThor> looks like we need to bump vala?
Nov 05 07:52:47 <JaMa> rebelThor: spaetz pushed 0.7.8 .. update
Nov 05 07:53:00 <JaMa> rebelThor: and start reading git-commits :)
Nov 05 07:53:12 <rebelThor> JaMa: yeah, I probably should ;)
Nov 05 07:55:11 <spaetz> rebelThor: update
Nov 05 07:55:21 <spaetz> hehe
Nov 05 07:55:43 <rebelThor> spaetz: yep, noticed the last commits now :) 
Nov 05 07:55:48 <spaetz> now that we got it to compile, mickey just bumps the version requirements, so it fails :)
Nov 05 07:56:23 <rebelThor> heh
Nov 05 07:56:37 <rebelThor> well, are we at least in line with OE atm ?
Nov 05 07:57:32 <spaetz> pretty much, I believe JaMa synced yesterday with the dev branch
Nov 05 07:58:14 <spaetz> still lots of stuff in our shr/merge branch though which is not upstream
Nov 05 07:58:24 <rebelThor> so it's a on-demand sync? won't that mean we'll have to fix a lot each time we sync ?
Nov 05 07:58:52 <spaetz> we have to fix whenever we diverge from upstream (otherwise it merges stuff automatically)
Nov 05 07:59:12 <spaetz> so we have an incentive to get as close to upstream as possible to prevent merge conflicts.
Nov 05 07:59:21 <spaetz> and eventually get rid of shr/merge completely
Nov 05 07:59:40 <spaetz> ?e just need to present our changes in small acceptable patches.
Nov 05 08:00:45 <rebelThor> mrmoku: any news on the http://build.shr-project.org/shr-unstable/ update, or are we still waiting to get it more usable ?
Nov 05 08:01:22 <mrmoku> spaetz: /etc/modutils/snd-soc-neo1973-gta02-wm8753 is missing
Nov 05 08:01:45 <mrmoku> rebelThor: sound out of the box would be something to have before ;)
Nov 05 08:02:21 <rebelThor> true :)
Nov 05 08:02:48 <mrmoku> spaetz: even after loading that module I still have no sound
Nov 05 08:03:07 <mrmoku> (and no oss module either)
Nov 05 08:03:14 <spaetz> mrmoku: linux-openmoko.inc:module_autoload_snd-soc-neo1973-gta02-wm8753 = "snd-soc-neo1973-gta02-wm8753"
Nov 05 08:03:19 <spaetz> is that not used?
Nov 05 08:03:35 <spaetz> mrmoku: I fixed it this morning...
Nov 05 08:03:50 <spaetz> by modprobing this
Nov 05 08:04:11 <spaetz> I don't get oss modules loaded on my FR at all
Nov 05 08:04:27 <spaetz> let me reboot, and check what fixed it
Nov 05 08:04:31 <mrmoku> spaetz: all is working, just have no audible sound
Nov 05 08:04:38 <spaetz> mrmoku: ok, that's easy
Nov 05 08:04:39 <mrmoku> before loading that module aplay was complaining
Nov 05 08:04:47 <mrmoku> now it justs plays and is silent :)
Nov 05 08:04:47 <spaetz> right, exactly same here
Nov 05 08:05:01 <rebelThor> TAsn gave me a command that bumped up the volume yesterday
Nov 05 08:05:03 <spaetz> alsactl -f /usr/share/shr/scenarios/streroout.... restore
Nov 05 08:05:08 <spaetz> fixes that
Nov 05 08:05:14 <spaetz> works fine afterwards
Nov 05 08:05:45 <mrmoku> uhh... stupid me
Nov 05 08:05:51 <spaetz> I guess frameworkd tries to load that but the module is still missing
Nov 05 08:05:58 <mrmoku> tried different scenarii... just not the stereout
Nov 05 08:05:59 <spaetz> or something....
Nov 05 08:06:02 <mrmoku> yep
Nov 05 08:06:05 <spaetz> hehe
Nov 05 08:06:28 <rebelThor> spaetz: any change you got a bit of time to check out the "alarms" app? it segfaults for me
Nov 05 08:06:37 <rebelThor> I mean, reproduce the segfault so I know it's not my fault
Nov 05 08:06:52 <spaetz> so again, I wonder why this doesn't work: linux-openmoko.inc:module_autoload_snd-soc-neo1973-gta02-wm8753 = "snd-soc-neo1973-gta02-wm8753"
Nov 05 08:07:14 <spaetz> and I have a different opinion than Tasn, I think in our kernel config we just disable oss completetly
Nov 05 08:07:31 <spaetz> even debian wants to disable it in their next release, and we don't use it at all
Nov 05 08:09:10 <spaetz> rebelThor: sorry, no time at all today
Nov 05 08:09:23 <rebelThor> spaetz: np
Nov 05 08:09:30 <spaetz> I just fixed vala so shr-lite compiles again. That was my contribution for today :)
Nov 05 08:09:33 <spaetz> daywork...
Nov 05 08:09:53 <mrmoku> hmm... ffalarms segfaults
Nov 05 08:10:47 <JaMa> rebelThor: we hope to recive a lot of fixes by syncing :)
Nov 05 08:11:19 <spaetz> mrmoku: strace:
Nov 05 08:11:22 <spaetz> access("/usr/share/zoneinfo/zone.tab", R_OK) = -1 ENOENT (No such file or directory)
Nov 05 08:11:25 <spaetz> access("/usr/lib/zoneinfo/zone.tab", R_OK) = -1 ENOENT (No such file or directory)
Nov 05 08:11:28 <spaetz> access("/etc/zoneinfo/zone.tab", R_OK)  = -1 ENOENT (No such file or directory)
Nov 05 08:11:32 <spaetz> access("/usr/share/lib/zoneinfo/zone.tab", R_OK) = -1 ENOENT (No such file or directory)
Nov 05 08:11:35 <spaetz> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Nov 05 08:11:36 <spaetz> same as previously on connman, segfaults when accessing a non-existing file
Nov 05 08:11:54 <JaMa> you mean dbus no?
Nov 05 08:11:54 <mrmoku> hmm
Nov 05 08:11:56 <spaetz> so I guess we have one issue of the underlying glibc crash left
Nov 05 08:11:59 <spaetz> JaMa: no connman
Nov 05 08:12:15 <mrmoku> JaMa: or ffalarms if you try to add an alarm
Nov 05 08:12:15 <spaetz> it segfaulted when trying to access nonexisting /dev/rfkill
Nov 05 08:12:37 <spaetz> but I guess dbus also used to segfault when trying to open a non-existing file, right
Nov 05 08:13:25 <JaMa> spaetz: yes first I've seen it in dbus-daemon when using <include ignore_missing="yes">system-local.conf</include> in system.conf
Nov 05 08:14:24 <spaetz> JaMa: can you do some glibc grepping to look for occurences of the offending assembly? the non-interworking safe stuff?
Nov 05 08:14:24 * JaMa is thinking about dropping mplayer-glamo patch and creating vdpau_glamo.so :)
Nov 05 08:14:39 <spaetz> I don't really know what I talk about there, so I can't help ;)
Nov 05 08:16:45 <spaetz> TAsn: phoneui volume sliders are still all set to 0 on incoming call, but I can talk and hear just fine :)
Nov 05 08:33:48 <rebelThor> mrmoku: should notifier and shr-today co-exist? shouldn't notifier be removed from the default image ?
Nov 05 08:36:24 <spaetz> btw, default image. I really think we should include the gry theme by default (and if possible even preselect it as default)
Nov 05 08:36:36 <spaetz> it is so much faster and looks *very* similar
Nov 05 08:36:52 <spaetz> besides the frames in shr-settings which look a bit awkward
Nov 05 08:37:16 <rebelThor> spaetz: we should also use the splash-logo by default, which is strangely not used atm :D
Nov 05 08:37:35 <spaetz> I always get the tux logo, you got a different one, right?
Nov 05 08:37:41 <spaetz> so it seems kind of random :)
Nov 05 08:37:48 <rebelThor> spaetz: nope, I got tux on my last build
Nov 05 08:38:12 <spaetz> hehe
Nov 05 08:38:15 <spaetz> ok
Nov 05 08:38:28 <rebelThor> i wonder if they are all installed
Nov 05 08:38:47 <rebelThor> because if they are, it's just a matter of who writes the last in that /usr/share/theme file
Nov 05 08:38:52 <rebelThor> or whatever it's called
Nov 05 08:39:31 <rebelThor> which is actually a symlink, but you got the point
Nov 05 08:39:50 <JaMa|Wrk> that's why update-alternative has preference :)
Nov 05 08:45:12 <spaetz> rebelThor: no, they are not installed by default. At least not in the .lite image
Nov 05 08:45:34 <rebelThor> let me fetch my FR and check my image, as I have the full one
Nov 05 08:45:34 <spaetz> but especially the -lite image should have a small fast theme by default...
Nov 05 08:46:19 <JaMa|Wrk> omgps failing probably because of new linux-libc-headers :/
Nov 05 08:47:29 <spaetz> defaulting to gry theme is a matter of installing it and setting this ENV VAR: ELM_THEME=gry
Nov 05 08:47:50 <spaetz> which could be done globally...
Nov 05 08:49:02 <JaMa|Wrk> there should be meta package for it shr-theme-gry.bb but its not ye.. 
Nov 05 08:49:42 <spaetz> JaMa|Wrk: why, because it's a elementary theme plus an enlightenment theme?
Nov 05 08:50:14 <spaetz> I see shr-settings sets ELM_THEME in /etc/profile.d/elementary.sh
Nov 05 08:52:12 <JaMa|Wrk> spaetz: yes.. because othere themes have it.. so its easy to remember to install shr-theme-THEMENAME :)
Nov 05 08:52:35 <spaetz> yep
Nov 05 08:52:42 <spaetz> agree
Nov 05 08:52:58 <spaetz> but independent of how its done, we should use a different theme by default :)
Nov 05 08:53:24 <JaMa|Wrk> +1
Nov 05 08:54:27 <rebelThor> there's no shr-splash-theme-logo.bb or am I just blind ?
Nov 05 08:54:42 <spaetz> and somebody find out why avahi is on the FR and started on every boot. It's plain stupid.
Nov 05 08:54:48 <JaMa|Wrk> rebelThor: shr-splash-theme-logo_git.bb
Nov 05 08:55:05 <rebelThor> wait, I was in the wrong folder...
Nov 05 08:55:15 <rebelThor> the wrong openembedded folder that is
Nov 05 08:57:10 <rebelThor> shouldn't there be a dependency in the shr-splash_git.bb for shr-splash-theme-logo_git.bb or similar? how would it know to use that one? :)
Nov 05 08:57:56 <raster> boo
Nov 05 08:58:57 <PaulFertser> moo
Nov 05 09:00:39 <spaetz> meeeh
Nov 05 09:01:16 <raster> burrp
Nov 05 09:01:24 <raster> almsot got coords mapping to maps
Nov 05 09:01:47 <spaetz> rebelThor: by recommending virtual/shr-splash-theme I assume
Nov 05 09:02:30 <rebelThor> spaetz: virtual/shr-splash-theme is defined in shr-splash-theme.inc ? i see that RPROVIDES_${PN} = "virtual/shr-splash-theme"
Nov 05 09:07:26 <Heinervdm> JaMa|Wrk: The XORG_FONT_MACROS are the bad guys in the font packages
Nov 05 09:08:01 <rebelThor> i'm thinking shr-splash_git.bb is missing a RREQUIRES_${PN} += "shr-splash-theme-logo" ? 
Nov 05 09:10:23 <mrmoku> rebelThor: PREFERRED_PROVIDER_virtual/shr-splash-theme = "shr-splash-theme-logo"
Nov 05 09:10:36 <mrmoku> that is how it should work... somehow does not though
Nov 05 09:10:37 <rebelThor> mrmoku: where is that defined ?
Nov 05 09:10:40 <mrmoku> shr.conf
Nov 05 09:12:10 <rebelThor> hmm, i got it in my shr.conf file... maybe the file is not included somehow?
Nov 05 09:12:39 <JaMa|Wrk> Heinervdm: today it build ok.. only one font failed.. :/
Nov 05 09:13:32 <JaMa|Wrk> rebelThor: hehe.. no .. its included for sure
Nov 05 09:13:48 <rebelThor> JaMa|Wrk: then it's out of my league :D
Nov 05 09:14:11 <JaMa|Wrk> rebelThor: shr.conf is sort of most important include :)
Nov 05 09:15:46 <rebelThor> hmm, the tux theme is the only one that does not have a line like ALTERNATIVE_PRIORITY = 2
Nov 05 09:15:48 <rebelThor> maybe that's the issue ?
Nov 05 09:15:50 <Heinervdm> JaMa|Wrk: but the autoconf macros are still bad, they are accessing hosts pkg-config and using hosts map files
Nov 05 09:16:37 <Heinervdm> the problem with shr-splash-theme-* is the update-alternatives in OE, the solution for this in OE is not goood
Nov 05 09:17:11 <Heinervdm> or not bitbake, it's opkg
Nov 05 09:17:18 * JaMa|Wrk had some fixes for update-alternatives in shr/import..
Nov 05 09:19:46 <JaMa|Wrk> update-alternatives.use.last.patch 
Nov 05 09:20:14 <mrmoku> JaMa|Wrk: those module_autoloads for the sound driver should move into the machine configs, no?
Nov 05 09:20:19 <JaMa|Wrk> with it it will use last alternative installed if it has the same preference as remaining alternatives before
Nov 05 09:21:02 <rebelThor> JaMa|Wrk: this means we need to modify the alternative priority for our theme bb files?
Nov 05 09:21:21 <JaMa|Wrk> mrmoku: no idea, are they different for gta01/gta02? but probably better to have some duplicity then modprobing wrong sound card in future shr-supported devices :)
Nov 05 09:21:40 <Heinervdm> rebelThor: no! then the one with the highest priority will ever be used
Nov 05 09:21:56 <spaetz> JaMa|Wrk: modules loaded differ certainly on gta1 and gta2
Nov 05 09:22:05 <rebelThor> Heinervdm: hmm, logo has the highest one now
Nov 05 09:22:17 <mrmoku> JaMa|Wrk: they are different even
Nov 05 09:22:25 <mrmoku> # audio (GTA01)
Nov 05 09:22:25 <mrmoku> module_autoload_snd-soc-neo1973-wm8753 = "snd-soc-neo1973-wm8753"
Nov 05 09:22:25 <mrmoku> # audio (GTA02)
Nov 05 09:22:25 <mrmoku> module_autoload_snd-soc-neo1973-gta02-wm8753 = "snd-soc-neo1973-gta02-wm8753"
Nov 05 09:22:36 <mrmoku> is what we have in linux-openmoko.inc
Nov 05 09:22:49 <mrmoku> additionaly an empty one for GTA03 which is causing the problems
Nov 05 09:23:11 <JaMa|Wrk> ah ok, then move it
Nov 05 09:23:17 <mrmoku> ok
Nov 05 09:24:58 <JaMa|Wrk> mrmoku: hmm but how to handle changed module name with different kernel?
Nov 05 09:25:15 <JaMa|Wrk> mrmoku: maybe its right to be in kernel recipe..
Nov 05 09:25:48 <JaMa|Wrk> mrmoku: 2.6.31 is almost there imho... and config looks really different than with old kernel..
Nov 05 09:25:58 <mrmoku> ouch
Nov 05 09:26:08 <mrmoku> just pushed :)
Nov 05 09:26:42 <Weiss> JaMa|Wrk: what's left to make 2.6.31 work?
Nov 05 09:26:59 <mrmoku> JaMa|Wrk: ok, let's change it again when the new kernel hits us
Nov 05 09:27:09 <mrmoku> or should I revert immediately
Nov 05 09:27:11 <mrmoku> hmm
Nov 05 09:27:49 <JaMa|Wrk> Weiss: it works ok already..
Nov 05 09:28:04 * JaMa|Wrk is using 2.6.31 in shr/merge image
Nov 05 09:28:29 <Heinervdm> spaetz: i think for packages from GNOME server it's better to use ${GNOME_MIRROR}
Nov 05 09:28:31 <mrmoku> JaMa|Wrk: hmm... though linux-openmoko.inc isn't kernel version specific either
Nov 05 09:28:37 <JaMa|Wrk> mrmoku: 2.6.31 is in OE already :)
Nov 05 09:29:10 <mrmoku> JaMa|Wrk: and the sound module is named differently?
Nov 05 09:29:45 <spaetz> didn't know there are GNOME_MIRROs
Nov 05 09:29:54 <spaetz> Heinervdm: care to send a patch?
Nov 05 09:30:11 <spaetz> or, I'll do it myself
Nov 05 09:30:16 <Heinervdm> spaetz: i don't think it's important
Nov 05 09:30:32 <spaetz> but thanks for letting my know about GNOME_MIRROR
Nov 05 09:30:32 <Weiss> JaMa|Wrk: including GSM, backlight, touchscreen etc? (things that weren't working a couple of weeks ago)
Nov 05 09:30:38 <spaetz> will use it in the future
Nov 05 09:30:44 <Heinervdm> there will come a vala-0.7.8-fso* for sure :D
Nov 05 09:30:52 <spaetz> hehe
Nov 05 09:30:54 <spaetz> I bet
Nov 05 09:33:04 <mrmoku> JaMa|Wrk: OE is sensible when renaming the toplevel dir, right? anything one can do to make it work?
Nov 05 09:34:12 <Heinervdm> mrmoku: the path is in a lot of files in staging
Nov 05 09:34:28 <mrmoku> Heinervdm: hmm... have to rebuild from scratch again on the buildhost then
Nov 05 09:34:29 <Heinervdm> a lot of .la files and .pc files are having it
Nov 05 09:34:44 <mrmoku> ok
Nov 05 09:35:06 <Heinervdm> mrmoku: you can try to replace it with sed
Nov 05 09:35:38 <mrmoku> hmm... will  just rebuild... guess we still need the day today to fix the small remaining issues
Nov 05 09:35:47 <mrmoku> and until tomorrow it should have finished to rebuild
Nov 05 09:36:03 <Heinervdm> it's the better way :)
Nov 05 09:36:06 <spaetz> Heinervdm: fixed in dev branch http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=56b84b4f4c4bbdbaac646222a09630fc5542eaf7
Nov 05 09:36:09 <spaetz> thanks
Nov 05 09:39:21 <rebelThor> sketchbook also fails with some missing file errors (i.e. /usr/share/gpe/pixmaps/gpe-logo.png )
Nov 05 09:41:48 <Heinervdm> rebelThor: then fix the recipe ;)
Nov 05 09:47:25 <spaetz> mrmoku: send another mail to the SHR mailing lists
Nov 05 09:47:32 <spaetz> to keep our community informed :)
Nov 05 09:47:38 <spaetz> s/send/sent/
Nov 05 09:47:56 <spaetz> back to dayjob
Nov 05 09:52:07 <mrmoku> spaetz: good thanks :)
Nov 05 10:04:20 <spaetz> mrmoku: tinderbox doesn't show any build stats for buildhost
Nov 05 10:04:25 <spaetz> is anything going on there?
Nov 05 10:04:34 <spaetz> well, it does show build stats
Nov 05 10:04:40 <spaetz> but no running ones :)
Nov 05 10:05:06 <mrmoku> hmm
Nov 05 10:07:29 <mrmoku> spaetz: forgot to adjust config... did that and restarted building
Nov 05 10:15:14 <Arigead> ping spaetz
Nov 05 10:34:19 <JaMa|Wrk> mrmoku: the path is stored in topdir IRC..
Nov 05 10:34:56 <mrmoku> JaMa|Wrk: yeah, but as Heinervdm libs in staging have that in too
Nov 05 10:34:56 <JaMa|Wrk> mrmoku: tmpdir-dev-shr/saved_tmpdir
Nov 05 10:36:56 <JaMa|Wrk> mrmoku: ah right :(
Nov 05 10:37:09 <JaMa|Wrk> mrmoku: but you can make symlink in old location..
Nov 05 10:37:26 <JaMa|Wrk> mrmoku: thats how I do it when I need to move it.. or better hardlink
Nov 05 10:37:45 <spaetz> mrmoku: ok cool
Nov 05 10:37:47 <spaetz> Arigead: pong
Nov 05 10:39:04 <spaetz> is the feed building now? Heinervdm or JaMa|Wrk looked into this, right?
Nov 05 10:39:33 <Heinervdm> spaetz: there are some app's that are unbuildable
Nov 05 10:39:47 <Heinervdm> like libefso
Nov 05 10:40:09 <Heinervdm> and we have to include matchbox-keyboard-im again
Nov 05 10:40:12 <spaetz> so should we kick those out of the feed for now?
Nov 05 10:40:21 <spaetz> to make the feed compile?
Nov 05 10:40:32 <Heinervdm> spaetz: we can build with -k
Nov 05 10:40:34 * spaetz has no clue what libefso does
Nov 05 10:41:26 <spaetz> Heinervdm: true
Nov 05 10:41:42 <spaetz> (-k)
Nov 05 10:42:59 <JaMa|Wrk> ./e17/essential-dialer_svn.bb:DEPENDS = "ecore edbus elementary libefso"
Nov 05 10:43:02 <JaMa|Wrk> ./e17/elementary-sms_svn.bb:DEPENDS = "ecore edbus elementary libefso"
Nov 05 10:43:04 <JaMa|Wrk> ./images/illume-image.bb:   libefso \
Nov 05 10:43:30 <Heinervdm> we need none of them
Nov 05 10:43:38 <spaetz> right.
Nov 05 10:43:42 <JaMa|Wrk> drop essential-dialer?
Nov 05 10:43:46 <spaetz> yes
Nov 05 10:43:53 <spaetz> we have a better one :)
Nov 05 10:45:35 <JaMa|Wrk> pushed
Nov 05 10:45:40 * spaetz removes essential-dialer from feed if nobody complains in the next few secs
Nov 05 10:45:45 * spaetz is too late :)
Nov 05 10:47:13 <Heinervdm> i will try to patch matchbox-keyboard-im then we can include that again
Nov 05 10:47:27 <rebelThor> how come we don't ship any games in the default full image? :D (mokomaze :P )
Nov 05 10:47:50 <spaetz> rebelThor: we don't? I remember a poll and the majority was for mokomaze in the full image
Nov 05 10:48:12 <rebelThor> just a sec, let me confirm
Nov 05 10:48:30 <spaetz> it's not in there. it seems
Nov 05 10:48:37 <rebelThor> nope, it's not
Nov 05 10:49:47 <spaetz> it should be. Does it compile?
Nov 05 10:50:06 <JaMa|Wrk> also sad that i think quite popular apps like omgps elmdentica e-tasks fail now in feed..
Nov 05 10:50:27 <JaMa|Wrk> should be fixed soon.. no time here today ...
Nov 05 10:52:00 <Heinervdm> [Rui] is active, so i think he will fix elmdentica soon
Nov 05 10:58:21 <TAsn> spaetz, both or just mic volume?
Nov 05 10:58:27 <TAsn> btw, sorry, but surf is up again :)
Nov 05 11:01:50 <TAsn> spaetz, I meant just speaker volume.
Nov 05 11:01:55 <TAsn> if only speaker it's a known issue.
Nov 05 11:02:20 <TAsn> it's a race condition (that we mostly loose in) that occurs because I haven't had the time to finish implementing volume controls
Nov 05 11:02:31 <TAsn> though I made huge progress, there's only one small thing needed to be added.
Nov 05 11:02:37 <rebelThor> spaetz: mokomaze compiles fine
Nov 05 11:03:35 <rebelThor> i think it might just be excluded from shr-image somehow
Nov 05 11:04:24 <mrmoku> TAsn: liar... you promissed there won't be anymore waves ;)
Nov 05 11:05:03 <TAsn> mrmoku, I thought
Nov 05 11:05:09 <TAsn> here in israel we usually don't have waves
Nov 05 11:05:11 <TAsn> but for some reason
Nov 05 11:05:15 <TAsn> the surf report this morning
Nov 05 11:05:24 <TAsn> said that today there are the best waves seen in a long time.
Nov 05 11:05:24 <TAsn> :|
Nov 05 11:05:27 <Heinervdm>  /home/thomas/SHR/SHR/shr-oemerge/tmp/staging/armv4t-oe-linux-gnueabi/usr/include/glib-2.0/glib/gthread.h:344: error: dereferencing pointer 'value_location.1' does break strict-aliasing rules
Nov 05 11:08:43 <Heinervdm> playya: http://pastebin.com/f7429b125 have you solved this?
Nov 05 11:24:56 <spaetz> TAsn: both sliders are set to 0
Nov 05 11:25:03 <spaetz> but sounds comes/goes through just fine
Nov 05 11:25:18 <TAsn> spaetz, what about changing the volume?
Nov 05 11:25:22 <TAsn> does that work?
Nov 05 11:25:52 <spaetz> haven't really checked yet, daywork. But I did modprobe the sound module after phoneuid was started, can that affect sth?
Nov 05 11:26:04 <TAsn> yes.
Nov 05 11:26:05 <spaetz> I will retry with the sliders and see if they have any effect
Nov 05 11:26:10 <TAsn> just
Nov 05 11:26:15 <TAsn> killall phoneuid
Nov 05 11:26:25 <TAsn> /etc/X11/Xsession.d/80phoneuid
Nov 05 11:26:25 <spaetz> ok, doing that now
Nov 05 11:26:31 <TAsn> and you'll have working sliders
Nov 05 11:26:43 <TAsn> (though speaker slider will probably init as zero, but it DOES affect sound)
Nov 05 11:26:48 <JaMa|Wrk> Heinervdm: it should be fixed by removing -Werror
Nov 05 11:27:00 <JaMa|Wrk> Heinervdm: it did the same for me.. so I applied that patch from playya 
Nov 05 11:27:23 <Heinervdm> JaMa|Wrk: and how can i do it?
Nov 05 11:27:29 <spaetz> rebooting with autoloading sound module now. then testing
Nov 05 11:27:41 <Heinervdm> JaMa|Wrk: i can't find -Werror in Makefile
Nov 05 11:27:49 <JaMa|Wrk> Heinervdm: its in shr/merge already..
Nov 05 11:28:02 <JaMa|Wrk> file://remove-werror.patch;patch=1" in gypsy_svn.bb
Nov 05 11:28:24 <Heinervdm> JaMa|Wrk: ah ok, i'm not building gypsy ;)
Nov 05 11:30:18 <Heinervdm> JaMa|Wrk: no CFLAGS defined in matchbox-panel-2, so that won't work
Nov 05 11:33:53 * spaetz thinks frameworkd does call fsousage in a wrong fashion, it is not always autostarted...
Nov 05 11:35:39 <JaMa|Wrk> Heinervdm: ah, but that pastebin is from there.., co you can add Wno-error, I think that Werror is now default..
Nov 05 11:36:44 <Heinervdm> gnome bugzilla search function is a pain
Nov 05 11:43:07 <spaetz> mrmoku: can it be that if phonefsod is started before dbus is ready, that it never succeeds in starting the fsousaged process?
Nov 05 11:43:37 <spaetz> on boot, I sometimes/often get phonefsod error loops like:
Nov 05 11:43:37 <spaetz> 2009.11.05 11:40:20.505550 [phonefsod]	 fso_list_resources()
Nov 05 11:43:38 <spaetz> 2009.11.05 11:40:21.154349 [phonefsod]	 list_resources_callback()
Nov 05 11:43:38 <spaetz> 2009.11.05 11:40:21.155426 [phonefsod]	   error: (-2) Message did not receive a reply (timeout by message bus)
Nov 05 11:43:51 <mrmoku> but it will retry then, no?
Nov 05 11:43:58 <spaetz> but fsousaged is not started (it will be started if I access it with mdbus)
Nov 05 11:44:17 <spaetz> mrmoku: it will retry but perhaps it tries to use the previous bus object (which is not there?)
Nov 05 11:44:27 <mrmoku> fsousaged should be started by frameworkd (via dbus activation)
Nov 05 11:44:31 <spaetz> just speculating. I just see that error loop
Nov 05 11:44:45 <spaetz> and no fsousaged. but when I use mdbus fsousaged gets started jsut fine.
Nov 05 11:45:20 <spaetz> mmh, no fsousaged is actually running
Nov 05 11:45:30 <spaetz> started at the same time as phonefsod started
Nov 05 11:45:32 <spaetz> weird
Nov 05 11:45:51 <BillK> mrmoku ping
Nov 05 11:45:58 <spaetz> then either fsousaged or dbus is broken
Nov 05 11:46:05 <mrmoku> BillK: pong
Nov 05 11:46:21 <mrmoku> spaetz: problem with sim auth?
Nov 05 11:46:38 <spaetz> mrmoku: BTW, it will retry, but I always get the timeout msg above
Nov 05 11:46:49 <spaetz> In these cases it does not ask me for SIM PIN
Nov 05 11:47:17 <BillK> mrmoku: hi, ~14 hrs ago you changed the shr makefile - I am getting :
Nov 05 11:47:17 <BillK> Initialized empty Git repository in /home/moko/SHR/common/.git/
Nov 05 11:47:18 <BillK> fatal: The remote end hung up unexpectedly
Nov 05 11:47:20 <BillK> make: *** [setup-common] Error 128
Nov 05 11:47:25 <BillK> is it related ?
Nov 05 11:47:42 <spaetz> just retry.
Nov 05 11:47:44 <mrmoku> BillK: hmm
Nov 05 11:47:49 <mrmoku> spaetz: that is our repo ;)
Nov 05 11:47:52 <spaetz> ahh
Nov 05 11:47:56 <spaetz> oh, right :)
Nov 05 11:48:11 <mrmoku> BillK: it works for me though...
Nov 05 11:48:28 <mrmoku> BillK: you're doing setup from scratch?
Nov 05 11:48:34 <CIA-52> freesmartphone.org: 03mickey 07cornucopia * r0db10fd75c6f 10/ (11 files in 11 dirs): all: bump Vala requirement and enable silent automake rules, if available
Nov 05 11:48:57 <spaetz> mickey|zzZZzz: do you recommend switching to more fso components already?
Nov 05 11:49:00 <BillK> yes, rm -rf'd everything cept downloads as merge womt build (eglibc)
Nov 05 11:49:07 <mrmoku> spaetz: I have that error too... for two minutes
Nov 05 11:49:11 <CIA-52> freesmartphone.org: 03mickey 07fso-abyss * r7f271311e2e0 10/configure.ac: enable silent rules, if available
Nov 05 11:49:17 <CIA-52> freesmartphone.org: 03mickey 07libgsm0710 * rcd564c8782f0 10/configure.ac: enable silent rules, if available
Nov 05 11:49:20 <mrmoku> spaetz: then it continues though
Nov 05 11:49:27 <spaetz> mrmoku: I never get asked for SIM PIN ATM
Nov 05 11:49:29 <CIA-52> freesmartphone.org: 03mickey 07libgsm0710mux * re81ed512ec86 10/configure.ac: enable silent rules, if available
Nov 05 11:49:30 <BillK> Ive had error for around an hour or more ...
Nov 05 11:49:41 <spaetz> mrmoku: ahh the remote end error?
Nov 05 11:49:43 <CIA-52> freesmartphone.org: 03mickey 07fso-gpsd * r39e810899110 10/configure.ac: enable silent rules, if available
Nov 05 11:49:43 <spaetz> ok
Nov 05 11:49:44 <mrmoku> BillK: let me try
Nov 05 11:49:54 <mrmoku> 2009.11.05 11:25:12.710477 [phonefsod]     error: (-2) Message did not receive a reply (timeout by message bus)
Nov 05 11:49:57 <CIA-52> freesmartphone.org: 03mickey 07fso-monitord * rb4ae1e9b10e7 10/configure.ac: enable silent rules, if available
Nov 05 11:49:59 <mrmoku> for two minutes
Nov 05 11:50:03 <mrmoku> and then it continues fine
Nov 05 11:50:10 <mrmoku> just... no sim auth for me too :P
Nov 05 11:50:17 <CIA-52> freesmartphone.org: 03mickey 07libeflvala * rd07db4fbd24c 10/configure.ac: enable silent rules, if available
Nov 05 11:50:51 <CIA-52> freesmartphone.org: 03mickey 07libfso-glib * r3630315a498f 10/configure.ac: enable silent rules, if available
Nov 05 11:51:04 <CIA-52> freesmartphone.org: 03mickey 07fso-term * raa0b9c26dee3 10/configure.ac: enable silent rules, if available
Nov 05 11:51:09 <mrmoku> BillK: yes, have that too now
Nov 05 11:51:10 <mrmoku> hmm
Nov 05 11:51:23 <CIA-52> freesmartphone.org: 03mickey 07vala-dbus-binding-tool * r324a78c0cab4 10/configure.ac: enable silent rules, if available
Nov 05 11:51:32 <CIA-52> freesmartphone.org: 03mickey 07vala-terminal * r932285d72e26 10/configure.ac: enable silent rules, if available
Nov 05 11:52:26 <spaetz> mrmoku: restarting frameworkd, it now asks me for SIM PIN
Nov 05 11:52:38 <spaetz> ?
Nov 05 11:52:43 <spaetz> weird
Nov 05 11:52:52 <mrmoku> BillK: ooohh, know why
Nov 05 11:52:55 * mrmoku stupid noob
Nov 05 11:54:12 <mickey|office> spaetz: i think there is something broken wrt. autostart
Nov 05 11:54:14 <CIA-52> SHR: 03mok 07shr-makefile * r26d810bc0030 10/Makefile: makefile: fix URL for make file repo
Nov 05 11:54:15 <mrmoku> BillK: ok, should work after an update now
Nov 05 11:54:18 <mickey|office> which dbus are you using?
Nov 05 11:54:37 <BillK> mrmoku: ok tkx
Nov 05 11:55:02 <spaetz> TAsn: slidersD-Bus Message Bus Daemon 1.3.0
Nov 05 11:55:09 <spaetz> TAsn: sliders seems to work
Nov 05 11:55:23 <mickey|office> might be a regression since 1.2.x
Nov 05 11:55:29 <mickey|office> can you retry w/ 1.2.x?
Nov 05 11:55:38 <mickey|office> i.e. the chatty one ;)
Nov 05 11:56:10 <spaetz> mickey|office: have you seen my pm from yesterday? Does frameworkd probably use paths like ":1.54" rather than "org.freesmartphone.ousaged" to access ousaged?
Nov 05 11:56:22 <spaetz> which then causes fsousaged to not be started?
Nov 05 11:56:27 <mickey|office> no
Nov 05 11:56:43 <mickey|office> these names are almost random
Nov 05 11:56:45 <spaetz> ok, because I had errors like these in my frameworkd.log
Nov 05 11:57:13 <mickey|office> plus, everything worked fine until recently
Nov 05 11:57:27 <mickey|office> so i rather think dbus autoactivation has a regression
Nov 05 11:57:32 <spaetz> mmh
Nov 05 11:57:43 <mickey|office> fwiw, i can also see this problem on my host
Nov 05 11:57:54 <spaetz> ok :(
Nov 05 11:57:58 <mickey|office> then again, it _might_ be a vala thing
Nov 05 11:58:14 <mickey|office> that's why i'd love someone to dig deeper
Nov 05 11:58:25 <mickey|office> i'm leaving for OEDEM tomorrow, so won't have time until next week
Nov 05 11:58:29 <spaetz> k
Nov 05 11:58:41 <Heinervdm> mrmoku: cookie for matchbox-panel-2 at patchwork, with that we can include matchbox-keyboard-im again
Nov 05 11:59:49 <spaetz> It's easier to debug these things now that I have a working image again. But then all those new phone* apps :)
Nov 05 12:02:19 <mickey|office> *nod*
Nov 05 12:10:54 <mrmoku> Heinervdm: applied
Nov 05 12:30:24 <Heinervdm> can't solve buildproblems for omgps
Nov 05 12:30:31 <Heinervdm> filed a bug...
Nov 05 12:42:09 <mrmoku> mickey|office: diff between old system.conf and new one:
Nov 05 12:42:11 <mrmoku> -    <deny send_type="method_call"/>
Nov 05 12:42:11 <mrmoku> +    <allow send_type="method_call" log="true"/>
Nov 05 12:42:26 <mrmoku> can that be related?
Nov 05 12:43:28 * mrmoku tries :)
Nov 05 12:45:19 <blindcoder> can someone help me with a bitbake recipe?
Nov 05 12:45:34 <mrmoku> we can try :)
Nov 05 12:45:37 <blindcoder> I have a file on a webserver that changes daily but without a name change
Nov 05 12:45:41 <spaetz> mrmoku: don't think it should make a difference
Nov 05 12:45:56 <blindcoder> how would I add a file like that to FILES so that it will be redownloaded every day?
Nov 05 12:46:06 <spaetz> blindcoder: sounds like a job for a cron job :)
Nov 05 12:46:14 <blindcoder> say, as <file>-${PR}
Nov 05 12:46:47 <blindcoder> spaetz: sure, I could also just delete the file before I do a bitbake -b, but that's not really a nice solution
Nov 05 12:48:07 <spaetz> someth like do_fetch_append()= wget blahfile -O outname....
Nov 05 12:48:11 <spaetz> ?
Nov 05 12:48:16 <spaetz> no expert here either
Nov 05 12:52:42 <Heinervdm> where does @SQLITE_CFLAGS@ in Makefile.am comes from?
Nov 05 12:59:58 <mrmoku> Heinervdm: AC_SUBST(SQLITE_CFLAGS) in configure.ac me thinks
Nov 05 13:00:37 <Heinervdm> mrmoku: i mean: how is it set from recipe?
Nov 05 13:00:59 <mrmoku> via pkgconfig probably
Nov 05 13:01:41 <mrmoku> spaetz: just stuffing fsousaged & before starting frameworkd in /etc/init.d/frameworkd makes all work
Nov 05 13:02:24 <spaetz> mrmoku: so for whatever reasons frameworkd doesn't manage to autostart fsousaged in time...
Nov 05 13:02:42 <mrmoku> or it starts but ignores the first resource register
Nov 05 13:02:44 <spaetz> mickey suspects dbus autostart failure, I suspect frameworkd :)
Nov 05 13:03:03 * mrmoku thinks mickey is right ;)
Nov 05 13:03:12 <spaetz> hehe
Nov 05 13:03:30 <spaetz> I said "for whatever reasons" :)
Nov 05 13:03:36 <spaetz> so I just don't know
Nov 05 13:04:05 <spaetz> mrmoku: I don't think it's it starts on first call but doesn't reply
Nov 05 13:04:32 <spaetz> I have seen cases where it wasn't started or was started only at the time when phonefsod accesses the path
Nov 05 13:05:27 <spaetz> but it always starts and works first time when I try it with mdbus
Nov 05 13:05:47 <spaetz> so either dbus isn't ready yet, or whatever.
Nov 05 13:10:02 <PaulFertser> spaetz: have you tried dbus-monitor or other dbus tools to trace the calls?
Nov 05 13:16:31 <Heinervdm> Filed a bug for elmdentica, when it's included it will compile again
Nov 05 13:18:34 <Heinervdm> ~seen [Rui]
Nov 05 13:18:38 <apt> [rui] <n=Rui@81.84.169.253> was last seen on IRC in channel #openmoko-cdevel, 17h 29m 25s ago, saying: 'is armv6 compatible with armv4? I wonder if I can run SHR on my SmartQ7...'.
Nov 05 13:18:59 <spaetz> PaulFertser: no. 1) I didn't have time 2) that happens on the FR before I can log on and do anything
Nov 05 13:21:28 <JaMa|Wrk> Heinervdm: pushed :)
Nov 05 13:29:22 <blindcoder> spaetz: tried running dbus-monitor >/tmp/log.dbus 2>&1 from an initscript?
Nov 05 13:30:28 <blindcoder> anyone care for a drink? http://pallas.crash-override.net/~blindcoder/fltkcocktailbar2.png
Nov 05 13:37:06 <blindcoder> haven't tried it on the FR yet because it's got no internet connection, but it should be fine
Nov 05 14:56:51 <dos1> TAsn: blipomoko is now in tests/mrmoku/unstable, i used the same trick for sliding window in bottom toolbar
Nov 05 14:57:01 <dos1> TAsn: and i have more ideas for edje hacking in this app ;)
Nov 05 14:57:14 <soltys> ;)
Nov 05 15:03:42 <CIA-52> freesmartphone.org: 03mickey 07cornucopia * raf5003242527 10/libfsobasics/fsobasics/smartkeyfile.vala: libfsobasics: debug--
Nov 05 15:14:34 * spaetz just had the stitches from his leg operation removed. OUtch, that hurts!!!
Nov 05 15:14:53 <spaetz> successfully made a real world phone call with shr/merge
Nov 05 15:15:08 <juri_> mrmoku: ping?
Nov 05 15:16:19 <wookey_> hello people, I've picked my openmoko up for first time in months. I'm stcuk because screen is locked after first un-sleep by gpe screenlock
Nov 05 15:16:34 <wookey_> and I've fogotten how to get in over cdc_ether or serial
Nov 05 15:16:46 <wookey_> I've got Debian/emdebian on it
Nov 05 15:17:27 <wookey_> Does it have a default IP on usb0? DHCP doesn;t seem to be working as if it was it would be 10.0.0.2 and ther is no response there
Nov 05 15:17:56 <wookey_> I thought modprobe g_serial would give me an ACM0 interface but I get no such module?
Nov 05 15:20:52 <mickey|office> yo wookey_, no idea about emdebian, but our distros usually use 192.168.0.202
Nov 05 15:21:09 <mickey|office> if you have a debug board, you can always get in via serial though
Nov 05 15:21:39 <wookey_> Ah - yes I do have one of those at home. I've not even tried to use that yet. I guess that's for when you've screwed things up
Nov 05 15:21:47 <mickey|office> yeah
Nov 05 15:21:49 <wookey_> ah - is cdc_acm what I want?
Nov 05 15:21:50 <mickey|office> or debugging startup
Nov 05 15:22:13 <mickey|office> iirc we're using g_ether
Nov 05 15:22:40 <wookey_> (Hi mikey BTW) :-)
Nov 05 15:24:40 <wookey_> And whilst I'm here given that I want to use this for a navigation device for the next month or so (australia), should I persevere with debian+tangoGPS (so far I've had no indication that the GPS is actually being read), or is it easier/better to just install some known-to-work image. I have about 2 evenings worth of dicking-about time to spend...
Nov 05 15:25:47 <wookey_> I put GPE on here but it's not much use (buttons too small/at edge). What is favoured finger-friendly UI?
Nov 05 15:26:40 <wookey_> Don't care if phone works or not (might be nice). 
Nov 05 15:27:24 <mrmoku> juri_: pong :)
Nov 05 15:27:56 <juri_> mrmoku: can you look at ticket #318? ;)
Nov 05 15:28:10 <jm3474> hi, I am unable to build shr-unstable at this time, I always get "ERROR: '/home/jmichel/workspace/shr/shr-unstable/openembedded/recipes/libgee/libgee-native_git.bb' failed". Any ideas?
Nov 05 15:28:42 <juri_> TAsn is threatening to close my ticket, because of not enough GTA01s to go around.
Nov 05 15:28:50 <TAsn> juri_, no
Nov 05 15:28:55 <TAsn> you just got me wrong.
Nov 05 15:29:03 <spaetz> jm3474: any more detailed error msgs?
Nov 05 15:29:07 <TAsn> and I also tried to re explain
Nov 05 15:29:10 <juri_> oh, good. :)
Nov 05 15:29:23 <juri_> sorry, my virtual host got rebooted; missed your reply.
Nov 05 15:29:36 <TAsn> spaetz, great ;)
Nov 05 15:29:44 <TAsn> dos1, great :) waiting to see that in libphone-ui
Nov 05 15:29:48 <TAsn> juri_, what I said is
Nov 05 15:30:04 <TAsn> that we don't have a gta01, so we can't reproduce it ourselves
Nov 05 15:30:09 <TAsn> and we really need someone with a gta01
Nov 05 15:30:10 <TAsn> to help.
Nov 05 15:30:21 <TAsn> or at least reply to our questions in that ticket.
Nov 05 15:30:35 <juri_> TAsn: well, you got a response from me. ;P
Nov 05 15:30:41 <juri_> mind you, i'm *buried*.
Nov 05 15:30:46 <TAsn> :)
Nov 05 15:31:36 <juri_> but, if it helps, either i can set some time aside for another round of GTA01 testing, OR i can ship a GTA01 to a party of your choice. i have three now.
Nov 05 15:32:16 <jm3474> spaetz: I included the content of the libgee-native-0.3.0+gitr174+c21925bf1b714a2aa395192f7adbaeecf7a0e146-r0/temp/log.do_compile.16129 file in http://pastebin.ca/1658458
Nov 05 15:35:09 <mrmoku> PaulFertser: what is your opinion on #318 (GetPowerStatus on gta01)?
Nov 05 15:36:48 <jm3474> Is there a way to remove this package from the build. it could be easier than to try to resolve the problem?
Nov 05 15:37:35 <mrmoku> spaetz: btw... do you have correct time with shr/merge image?
Nov 05 15:40:09 <mrmoku> jm3474: libgee-native is very much needed
Nov 05 15:42:08 <Heinervdm> i think that error comes from vala version bump
Nov 05 15:42:13 <dos1> juri_: if you want, you can send one to me ;)
Nov 05 15:43:52 <dos1> juri_: i always wanted to check how shr-settings behave on gta01
Nov 05 15:44:23 <spaetz> mrmoku: off by 1 hour
Nov 05 15:44:34 <dos1> at begining one of shr-settings developers had gta01, but he is MIA for quite long time :x
Nov 05 15:44:57 <spaetz> mrmoku: has phonefsod an ophonekitd-like about requesting/releasing the GSM resource?
Nov 05 15:44:59 <dos1> and now there is no gta01 owner in SHR development ;x
Nov 05 15:45:16 <spaetz> I am looking at shr-settings GSM Antenna settings
Nov 05 15:45:38 <jm3474> Heinervdm: Do you mean a new version of Vala was just made available in SHR? Any suggestion to correct that issue?
Nov 05 15:45:41 <spaetz> and wonder what the correct way is to enable/disable GSM (besides SetAntennaPower())
Nov 05 15:45:42 <soltys> dos1: when you'll be ready to synce feeds and want to test gta01 image ping me ;)
Nov 05 15:46:05 <soltys> if gta01 on my desk still is ok I'll test it ;)
Nov 05 15:46:08 <dos1> spaetz: it's shr-settings problem, i'll fix that as soon as i'll get phonefsod working here
Nov 05 15:46:19 <dos1> soltys: oh, right, i forgot you got gta01 recently :x
Nov 05 15:46:23 <soltys> ;)
Nov 05 15:46:25 <Heinervdm> jm3474: just wait, upstream will fix it
Nov 05 15:46:29 <mickey|office> wookey_: i'd give SHR a try, this is the best maintained distro atm.
Nov 05 15:46:29 <spaetz> dos1: oh, I know. I am looking at the shr-settings code right now
Nov 05 15:46:34 <spaetz> I want to fix it
Nov 05 15:46:40 <soltys> yeap but I don't know it it work correctly ;P
Nov 05 15:46:54 <dos1> soltys: send it to me ;D
Nov 05 15:47:03 <spaetz> dos1: but I am wondering what the *correct* DBUS way is now to enable/disable GSM
Nov 05 15:47:12 <soltys> dos1: it's not fully mine I only borowed it ;)
Nov 05 15:47:20 <Heinervdm> mickey|office: is libgee unbuildable with vala-0.7.8?
Nov 05 15:47:21 <juri_> dos1: if i send you one, will you promise to work on bug #318 for me? ;)
Nov 05 15:47:21 <spaetz> perhaps org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.Resource.Disable ???
Nov 05 15:47:33 <mickey|office> Heinervdm: i hope not. let me try
Nov 05 15:47:43 <spaetz> I'm building libgee atm
Nov 05 15:47:46 <spaetz> with vala 0.7.8
Nov 05 15:47:47 <dos1> soltys: and say to hrw that UFO stole it :P
Nov 05 15:48:18 <soltys> dos1: hmm I'm not shure that he'll belive in that bulshit ;)
Nov 05 15:48:22 <dos1> juri_: firstly i have to check what #318 is, but that's after dinner ;)
Nov 05 15:48:29 <soltys> ;)
Nov 05 15:48:39 <spaetz> dos1: perhaps SetResourcePolicy would be the right action on the GSM on/off toggle?
Nov 05 15:48:53 * soltys bbl
Nov 05 15:48:54 <spaetz> ideall we'd need a 3-state toggle
Nov 05 15:49:00 <spaetz> on/auto/off
Nov 05 15:49:18 <mickey|office> libgee builds fine here w/ 078
Nov 05 15:49:38 <Heinervdm> spaetz: i just flashed shr/merge for me usb0 is up
Nov 05 15:49:48 <spaetz> Heinervdm: yep, that works :)
Nov 05 15:49:58 <jm3474> Heinervdm: When can I know it is fixed? do I need to try "make image" again or I need to update something?
Nov 05 15:50:14 <spaetz> jm3474: perhaps some locally installed vala interferring?
Nov 05 15:50:50 <jm3474> spaetz: I have valac installed locally should I remove it ?
Nov 05 15:51:16 <spaetz> it should not, but it has happened that sometimes a local package was picked up
Nov 05 15:51:26 <spaetz> jm3474: when have you last updated the tree?
Nov 05 15:51:27 <mrmoku> spaetz: one hour off for me too...
Nov 05 15:51:52 <jm3474> spaetz: yesterday
Nov 05 15:51:52 <Heinervdm> mrmoku: for me too, it seems it's set to UTC
Nov 05 15:51:58 <mrmoku> dos1: phonefsod should work... even with pin... as long as you enter the correct one on first try :P
Nov 05 15:52:01 <spaetz> mrmoku: ok. interestingly it's not even summer time. it's 1 h wrong the other way
Nov 05 15:52:06 <spaetz> ahh, utc, right
Nov 05 15:52:12 <Heinervdm> jm3474: then update now again
Nov 05 15:52:25 <spaetz> jm3474: yesterday is too early.
Nov 05 15:52:32 <spaetz> update again
Nov 05 15:52:38 <mrmoku> mickey|office: is GetPowerStatus on gta01 supposed to exist?
Nov 05 15:52:39 <jm3474> Do you mean by doing "make update-shr "
Nov 05 15:52:48 <spaetz> lots has changed since then, for example the vala version.
Nov 05 15:53:00 <Heinervdm> jm3474: make update-common; make update
Nov 05 15:53:04 <spaetz> jm3474: I always "make update"
Nov 05 15:53:06 <mickey|office> mrmoku: which object which interface?
Nov 05 15:53:19 <spaetz> Heinervdm: make update implies update-common
Nov 05 15:53:33 <jm3474> I'm trying right now thanks
Nov 05 15:53:44 <Heinervdm> spaetz: yes, but then you have to run make update twice
Nov 05 15:53:50 <mrmoku> mickey|office: moment
Nov 05 15:54:07 <spaetz> Heinervdm: I don't think so. but I haven't really checked
Nov 05 15:54:26 <Heinervdm> spaetz: first run to update makefile, and a second one to use the updated makefile
Nov 05 15:55:07 <mrmoku> mickey|office: org.freesmartphone.Device.PowerSupply
Nov 05 15:55:34 <spaetz> Heinervdm: ahh ok, right
Nov 05 15:55:45 <spaetz> but it aborts if the makefile was updated anyway.
Nov 05 15:55:55 <spaetz> But, yes you are right
Nov 05 15:56:12 <spaetz> jm3474: libgee-native compiles fine
Nov 05 15:56:38 <Heinervdm> hmm ok :)
Nov 05 15:57:21 <mrmoku> mickey|office: http://trac.shr-project.org/trac/ticket/318
Nov 05 15:57:23 <mickey|office> mrmoku: (assuming you are using fsodeviced) if the kernel creates a power supply, then yes, this should be supported. on fsodeviced, I'd only use the aggregated power supply though which should be living at /org/freesmartphone/Device/PowerSupply/
Nov 05 15:57:36 <mrmoku> mickey|office: no, not fsodeviced
Nov 05 15:57:51 <mickey|office> oh
Nov 05 15:57:53 <mrmoku> good old odeviced :)
Nov 05 15:57:55 <mickey|office> hmm
Nov 05 15:58:12 <CIA-52> SHR: 03Sebastian 07shr-settings * rf2c9c7ed22e4 10/shr_settings_modules/shr_gsm.py: shr_gsm: Remove ophonekitd way to enable/disable the GSM
Nov 05 15:58:16 <spaetz> dos1: I just pushed a fix for the GSM on/off
Nov 05 15:58:37 <mrmoku> we do GetPowerState in ophonekitd in idle notify handler to see if it is connected to power
Nov 05 15:58:39 <spaetz> It just toggles AntennaPower() for now
Nov 05 15:58:41 <mrmoku> and then suspend or not
Nov 05 15:58:48 <mrmoku> and that segfaults on gta01
Nov 05 15:58:57 <mrmoku> juri_: when was the last time you tried it?
Nov 05 15:59:11 <spaetz> mickey|office: is fsodeviced ready for consumption?
Nov 05 15:59:29 <mickey|office> mrmoku: if -- by accidant -- the ApmPowerSupply is being instanciated, then this might explain things
Nov 05 15:59:33 <mickey|office> spaetz: IMO yes
Nov 05 15:59:45 <spaetz> ahh, cool.
Nov 05 15:59:46 <mickey|office> spaetz: but of course i did not do many integration tests
Nov 05 15:59:50 <spaetz> mmh
Nov 05 15:59:51 <dos1> mrmoku: i already described you this bug ages ago
Nov 05 15:59:52 <mrmoku> mickey|office: I tried fsodeviced the other day... and had missing sound
Nov 05 15:59:54 <mickey|office> so i'd love you to start using it
Nov 05 15:59:56 <mrmoku> might just be missing deps though
Nov 05 16:00:01 <mrmoku> or wrong config
Nov 05 16:00:01 <mickey|office> and we can find out what needs to be fixed
Nov 05 16:00:04 <dos1> mrmoku: it's different dbus path
Nov 05 16:00:08 <mrmoku> orientationn worked great though :)
Nov 05 16:00:14 <spaetz> There was a mail describing how to use it, right?
Nov 05 16:00:17 <mickey|office> mrmoku: fso-alsa-data installed?
Nov 05 16:00:45 <mrmoku> mickey|office: probably that was the problem... shouldn't it be installed via dep?
Nov 05 16:01:06 <mickey|office> iirc it's an RRECOMMENDS
Nov 05 16:01:22 <mickey|office> which is ok, since it's actually optional for fsodeviced as a while
Nov 05 16:01:24 <mickey|office> whole, even
Nov 05 16:01:44 <mrmoku> mickey|office: ok will retry with it installed then
Nov 05 16:02:00 <juri_> mrmoku: forever ago.
Nov 05 16:02:10 <mrmoku> mickey|office: so... the problem on gta01 will be solved by using fsodeviced then...
Nov 05 16:02:26 <dos1> mrmoku: btw, i really, really don't like suspend handling by ophonekitd...
Nov 05 16:02:35 <mrmoku> as for odeviced it seems to be different bus paths... between gta01/02
Nov 05 16:02:50 <mrmoku> dos1: that would be another solution ;)
Nov 05 16:03:07 <spaetz> dos1: shr-today locks the screen while I am on a phone call. known?
Nov 05 16:03:11 <juri_> I'll give it another go sometime soon.. but i'm *superburied* under my other two projects.
Nov 05 16:03:29 <dos1> juri_: well, if you'll send me gta01, i'll work on having working phone on it :P
Nov 05 16:03:34 <mickey|office> mrmoku: yeah, odeviced had support for APM 
Nov 05 16:03:59 <juri_> dos1: if i can't find OM hacking time in a week, i'll send ya one. ;)
Nov 05 16:04:06 <dos1> spaetz: why it shouldn't? i'm always locking screen while on call ;x
Nov 05 16:04:20 <spaetz> dos1: I can't quickly hang up the call
Nov 05 16:04:22 <spaetz> !!!
Nov 05 16:04:31 <spaetz> I need to unock first and then hang up
Nov 05 16:04:31 <dos1> spaetz: so maybe conf option will be suitable
Nov 05 16:04:33 <dos1> :P
Nov 05 16:04:37 <spaetz> :)
Nov 05 16:04:49 <spaetz> nahh, then not. i prefer simplicity over too tweakable
Nov 05 16:04:53 <spaetz> ;)
Nov 05 16:05:01 <spaetz> did I really say this?
Nov 05 16:05:06 <CIA-52> freesmartphone.org: 03mickey 07cornucopia * rc11d416fb949 10/fsogsmd/src/3rdparty/smsutil.c: fsogsmd: 3rdparty: sanitize sms_text_prepare() by creating structures on the heap
Nov 05 16:05:08 <CIA-52> freesmartphone.org: 03mickey 07cornucopia * r6259faf55cfb 10/fsogsmd/src/3rdparty/smsutil.c: 
Nov 05 16:05:08 <CIA-52> freesmartphone.org: Revert "fsogsmd: 3rdparty: sanitize sms_text_prepare() by creating structures on the heap"
Nov 05 16:05:08 <CIA-52> freesmartphone.org: This reverts commit 939cc6abf46c485cad7104b9d49b59b029e4a394.
Nov 05 16:05:10 <CIA-52> freesmartphone.org: 03mickey 07cornucopia * r48726ef22a0c 10/fsogsmd/ (6 files in 3 dirs): fsogsmd: add unit tests for encoding SMSes
Nov 05 16:05:21 <mickey|office> later
Nov 05 16:05:52 * mrmoku wonders if spaetz is a gnome user ;)
Nov 05 16:07:19 <mrmoku> dos1: what is the problem with suspend handling in ophonekitd?
Nov 05 16:07:28 <mrmoku> what would you prefer?
Nov 05 16:07:46 <dos1> mrmoku: requesting CPU resource in oeventsd
Nov 05 16:07:59 <dos1> mrmoku: it's already there :P
Nov 05 16:09:41 <mrmoku> dos1: for active calls too I guess?
Nov 05 16:09:47 <dos1> mrmoku: yup
Nov 05 16:10:30 <mrmoku> Ainulindale: why was suspend handling necessary inside ophonekitd? remeber something? :P
Nov 05 16:11:13 <spaetz> mrmoku: yes :) But I own a Moko, that makes up for it
Nov 05 16:11:22 <mrmoku> :P
Nov 05 16:11:24 <mrmoku> got you ;)
Nov 05 16:12:21 <spaetz> we had the whole resource handling in ophonekitd for the sole reason to make it easier to ReQuest Release a resource with mdbus dbus-send
Nov 05 16:12:33 <spaetz> but with fsoraw this reason has really gone away
Nov 05 16:14:12 <mrmoku> so.... remove all resource handling (aka the Usage interface) from phonfsod? including suspend?
Nov 05 16:14:42 <spaetz> YES please
Nov 05 16:14:51 <spaetz> I never liked it there
Nov 05 16:15:34 <mrmoku> dos1: did entering a wrong PIN work correctly in old ophonekitd images? could you try that?
Nov 05 16:15:43 <spaetz> Ainulindale wanted to develop it into a hub where one user could request/release resources of other processes with a permission system etc AFAIK
Nov 05 16:15:44 <dos1> mrmoku: yup, it worked
Nov 05 16:15:51 <dos1> mrmoku: but now i have some strange thing ;x
Nov 05 16:16:08 <spaetz> so shr-settings was allowed to Release phonefsod GSM resource, etc...
Nov 05 16:16:08 <dos1> mrmoku: after playing with phonefsod, ophonekitd is always asking me for PUK
Nov 05 16:16:25 <dos1> mrmoku: mdbus -s -l doesn't say anything about PUK...
Nov 05 16:17:19 <spaetz> weird, it does ask me for my PIN and accepts it
Nov 05 16:17:23 <PaulFertser> mrmoku: funny thing, i switch to my browser and suddenly realised i have that ticket opened on the current tab.
Nov 05 16:17:28 <spaetz> simple 4 digit PIN
Nov 05 16:18:22 <TAsn> btw I had an issues I haven't had time to fully check yet.
Nov 05 16:18:30 <TAsn> but after X time of running the phone
Nov 05 16:18:42 <TAsn> (maybe after X calls, X resumes, no idea, really...)
Nov 05 16:18:50 <TAsn> phone doesn't suspend and shows an error message.
Nov 05 16:19:02 <TAsn> which I don't remember atm.
Nov 05 16:19:27 <PaulFertser> mrmoku: is the problem actually with FSO not exposing GetPowerStatus on org.freesmartphone.Device.PowerSupply interface? How in the hell is it SHR's problem?
Nov 05 16:20:14 <mrmoku> PaulFertser: I opened the tab for you :P
Nov 05 16:20:23 <mrmoku> PaulFertser: google makes it possible ;)
Nov 05 16:21:40 <mrmoku> PaulFertser: hopefully we can close that ticket by switching to fsodeviced or eliminating power handling in phonefsod or both :)
Nov 05 16:22:06 <spaetz> any clue as to how to try fsodeviced?
Nov 05 16:22:10 <mrmoku> dos1: does mdbus -s -l say something about PIM?
Nov 05 16:22:16 <mrmoku> err PIN
Nov 05 16:22:17 <mrmoku> :)
Nov 05 16:22:21 <TAsn> NOTE: Running task 28 of 3288 (ID: 329, /home/tom/projects/openmoko/oe/shr-unstable/openembedded/recipes/coreutils/coreutils-native_7.2.bb, do_fetch)
Nov 05 16:22:27 <spaetz> compiling fails as it doesn't have fsoframework which is new enough apparently...
Nov 05 16:22:31 * TAsn is going to sleep and wake up in a couple of days .;]
Nov 05 16:22:31 <PaulFertser> mrmoku: i wonder which object path is that
Nov 05 16:23:44 <PaulFertser> Gnutoo: you should have simply attached the patch
Nov 05 16:24:48 <mrmoku> PaulFertser: #define DEVICE_POWER_SUPPLY_BUS_PATH            "/org/freesmartphone/Device/PowerSupply/battery"
Nov 05 16:24:56 <dos1> mrmoku: yup, just typical AuthStatus about PIN needed
Nov 05 16:25:05 <Gnutoo> PaulFertser, ouch sorry the conventions differs from mailing list to mailing lists
Nov 05 16:25:37 <PaulFertser> juri_: (shr #318) when you'll be able please explore your running system with mdbus -s , especially mdbus -s odeviced.freesmartphone.org /org/freesmartphone/Device/PowerSupply/
Nov 05 16:26:29 <PaulFertser> juri_: also when reporting frameworkd-related problems (and this one is apparently frameworkd problem, i guess it doesn't have anything to do with SHR even) please provide the relevant parts of the frameworkd log.
Nov 05 16:28:33 <spaetz> mickey|zzZZzz: ping?!
Nov 05 16:28:44 <PaulFertser> Gnutoo: i think any sane MUA can show attached patches in a convenient enough way, quoting it shouldn't be a problem either. How exactly does git send-email fail for you? BTW, you can just use git format-patch, add a To: header and send it with /usr/sbin/sendmail -oi -t < mycool.patch (or the like)
Nov 05 16:28:51 <spaetz> libfsoramework provides 0.2.3 but fsodeviced requires 0.2.3.1
Nov 05 16:29:08 <spaetz> so you need to fixup http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=libfsoframework/configure.ac;h=3c17640185cfb059525c6097ed7a9adaedcc3646;hb=48726ef22a0ce916ec0905d773e17c165ac54502
Nov 05 16:29:20 <spaetz> to actually provide the version number of your release, right?
Nov 05 16:32:39 <spaetz> mmh, no. You DID bump it. So why am I seeing an old version
Nov 05 16:32:46 <spaetz> cleaning....
Nov 05 16:32:51 <mrmoku> ok... family and dinner time... bbl
Nov 05 16:33:16 <spaetz> same here
Nov 05 16:38:14 <Gnutoo> PaulFertser, I'll have to go...ok I knew there was an option but didn't know the convention...for instance SHR ml has inline patches
Nov 05 16:42:48 <spaetz> SHR ml does whatever git send-mail does :)
Nov 05 16:48:10 <TAsn> mrmoku|away,what's fsodeviced's status?
Nov 05 16:49:15 <spaetz> TAsn: it currently fails to compile as it requires libfsoframework >= 0.2.3.1 and mickey has in his release of 0.2.3.1 *reduced* the version number to 0.2.3
Nov 05 16:49:26 <spaetz> so the requirements are not met
Nov 05 16:49:31 <TAsn> i c.
Nov 05 16:49:35 <TAsn> but what about it?
Nov 05 16:49:38 <spaetz> TAsn: and mickey thinks fsodeviced is ready for production
Nov 05 16:49:39 <TAsn> I mean, is it usable already?
Nov 05 16:49:44 <TAsn> cool :)
Nov 05 16:49:47 <TAsn> that's what I wanted to know.
Nov 05 16:49:52 <TAsn> ok, I don't mind being a beta tester. ;)
Nov 05 16:49:54 <spaetz> but he hasn't done many integration tests with python frameworkd
Nov 05 16:49:58 <TAsn> we should probably give it a go.
Nov 05 16:50:02 <spaetz> I asked him the same question today .O
Nov 05 16:50:05 <spaetz> :)
Nov 05 16:50:07 <TAsn> cool. :)
Nov 05 16:50:12 <TAsn> I'm off again, ciao.
Nov 05 16:50:14 <spaetz> ciao
Nov 05 17:24:57 <CIA-52> freesmartphone.org: 03mickey 07cornucopia * rb73e92d51341 10/libfsoframework/configure.ac: libfsoframework: d'oh! 0.2.3 is actually a smaller number than 0.2.3.1
Nov 05 18:08:36 <Ainulindale> mrmoku|away: suspend handling into ophonekitd
Nov 05 18:08:44 <Ainulindale> Reason is that it wasn't properly working initially
Nov 05 18:08:53 <Ainulindale> it was suspending while calling
Nov 05 18:08:58 <Ainulindale> It just stayed there
Nov 05 18:31:43 <spaetz> yay, mickey fixed libfsoframework version numbr
Nov 05 18:31:47 <TAsn> Ainulindale, so it should be removed?
Nov 05 18:31:52 * spaetz compiles
Nov 05 18:31:58 <TAsn> :)
Nov 05 18:32:25 <spaetz> YES, REMOVE +1 ;)
Nov 05 18:32:50 <TAsn> :)
Nov 05 18:34:20 <dos1> at least, i was already for removing it ages ago :P
Nov 05 18:35:56 <Sharwin_F> TAsn, hey, a while ago I called someone and no one answered and the "call box" (how is it called in english? xD) appeared, so I closed the GUI using Illume bar... and it seems the call (the GUI yes) didn't close, as the other part is telling me now that he has a long message recorded
Nov 05 18:36:21 <TAsn> yes.
Nov 05 18:36:26 <TAsn> Sharwin_F, please open a bug. :)
Nov 05 18:36:32 <TAsn> it's a known issue though
Nov 05 18:36:34 <spaetz> Sharwin_F, there is an existing bug on that
Nov 05 18:36:39 <TAsn> even better :)
Nov 05 18:36:44 <TAsn> closing the screen doesn't hang up
Nov 05 18:37:00 <TAsn> as it shouldn't, we should just *not* allow closing the screen.
Nov 05 18:37:01 <spaetz> file against the old phone app, of course
Nov 05 18:37:12 <Sharwin_F> it's ma known issue but there's no bug in trac about it?
Nov 05 18:37:13 <spaetz> TAsn, disagree.
Nov 05 18:37:25 <TAsn> Sharwin_F, spaetz says there is.
Nov 05 18:37:26 <spaetz> closing wn should be possible
Nov 05 18:37:29 <TAsn> spaetz, no.
Nov 05 18:37:34 <Sharwin_F> I'm using new phone stack
Nov 05 18:37:36 <spaetz> and just  hang up
Nov 05 18:37:41 <TAsn> as people will close it by accident.
Nov 05 18:38:02 <spaetz> TAsn, nah, if you close a win you closeit
Nov 05 18:38:10 <TAsn> for instance, you want to close the working app and a new call pops in.
Nov 05 18:38:18 <PaulFertser> TAsn: since you're testing latest software on gta02 currently can you please do one thing?
Nov 05 18:38:19 <Sharwin_F> and what about hanging up when the GUI it's closed by illume?
Nov 05 18:38:22 <Sharwin_F> doesn't it send a signal?
Nov 05 18:38:24 <spaetz> or you have to remove the 'release' button too ;)
Nov 05 18:39:06 <TAsn> PaulFertser, ?
Nov 05 18:39:17 <PaulFertser> TAsn: disable "echo 0 > power_on" in the frameworkd and release the GSM resource. After that request it again and look for the logs to confirm the modem was still turned off.
Nov 05 18:40:13 <TAsn> PaulFertser, you wan to disable turning on of modem from frameworkd
Nov 05 18:40:14 <TAsn> ?
Nov 05 18:41:08 <PaulFertser> TAsn: not exactly, but some sort of. gta02 has a way to turn the modem off in hardware. But the idea is to ensure that software way (i.e. sending AT@POFF) works too.
Nov 05 18:42:06 <spaetz> people could also just press the screen part where the 'release' button is, when a new call comes  in. 
Nov 05 18:42:08 <TAsn> PaulFertser, anyhow, I'm too tired to do anything atm (to be honest I barely get what you want me to do) I think I'll go get some sleep and ping you tomorrow ;)
Nov 05 18:42:20 <TAsn> spaetz, which is also an issue.
Nov 05 18:42:26 <spaetz> yep
Nov 05 18:42:32 <PaulFertser> TAsn: i got some sleep already :P
Nov 05 18:42:34 <TAsn> spaetz, hanging up all the calls is easy.
Nov 05 18:42:42 <TAsn> spaetz, if you want, send me a patch ;]
Nov 05 18:42:51 <PaulFertser> My proposal is open for other team members as well. spaetz ? ;)
Nov 05 18:44:33 <PaulFertser> Come on guys, it was broken for so long time it's not funny anymore.
Nov 05 18:45:19 <TAsn> lol. :)
Nov 05 18:46:16 <TAsn> spaetz, it's just amazing, more waves tomorrow, they just keep on coming. :|
Nov 05 18:53:08 <spaetz> PaulFertser, sorry visitors at home, no time atm
Nov 05 18:53:20 * spaetz hates waves ;)
Nov 05 18:53:29 <spaetz> tomorrow
Nov 05 18:53:56 <PaulFertser> spaetz: ok, enjoy your visitors :)
Nov 05 19:39:38 <PaulFertser> wpwrak: Hi, Werner :)
Nov 05 19:40:05 <PaulFertser> wpwrak: we'd like to hear your opinion on PM kernel interfaces
Nov 05 19:40:34 <PaulFertser> wpwrak: some not exactly fruitful discussion is here: http://pastebin.com/m6561f388
Nov 05 20:04:23 <alexxy> mrmoku|away: TAsn : can you add reiserfsprogs to feed
Nov 05 20:04:25 <alexxy> ?
Nov 05 20:05:06 <TAsn> alexxy, please open a bug and assign to mrmoku ;)
Nov 05 20:07:24 <max_posedon> phonefsod.log full of
Nov 05 20:07:26 <max_posedon> 2009.11.05 20:47:13.961699 [phonefsod]   Unknown signal 1075461824 received => {Ignored}
Nov 05 20:07:30 <max_posedon> is it ok?
Nov 05 20:07:54 <wpwrak> PaulFertser: in general, i think pm can be implicit if it's trivial but it should be explicit if it's not
Nov 05 20:08:16 <wpwrak> PaulFertser: otherwise, you end up with the kernel handling some common cases and user space second-guessing it for the more complex cases
Nov 05 20:09:13 <wpwrak> PaulFertser: if in doubt, perhaps an optional implicit mechanism could be implemented. if user space has no special plans, let the kernel do whatever it feels is right, otherwise, get out of the way
Nov 05 20:09:23 <PaulFertser> wpwrak: have you read script of our talk with larsc? I think you can give some specific examples based on that ;)
Nov 05 20:10:11 <wpwrak> PaulFertser: of course, this can easily add unnecessary complexity. in the long run, i think a close cooperation with user space would make the most sense. i.e., implement a driver with the basic on/off functionality, then leave it to fso to do the power management
Nov 05 20:11:30 <PaulFertser> wpwrak: that's something along the lines i propose. But what's more interesting is your opinion about rfkill, especially given its limitations i outlined.
Nov 05 20:11:43 <wpwrak> PaulFertser: (examples) well, there are lots of things where you don't really know when it's okay to turn something off, unless you know what the user/application is doing. e.g., networking.
Nov 05 20:12:03 <alexxy> TAsn / mrmoku|away:  ticket #698
Nov 05 20:12:45 <wpwrak> PaulFertser: (rfkill) tricky ... if you can map the semantics exactly, it's nice if you can reuse the existing interface. if not, it's likely to cause confusion.
Nov 05 20:12:46 <TAsn> alexxy, thanks. ;)
Nov 05 20:13:01 <PaulFertser> wpwrak: :D
Nov 05 20:13:42 <wpwrak> PaulFertser: (bt fw) yes, i think asking the demon for a new download would make sense if you really do a full shutdown
Nov 05 20:14:02 <alexxy> TAsn: so reiserfs is better for sd card because it doesnt have hardcodded inode number like ext[234]
Nov 05 20:14:11 <wpwrak> PaulFertser: of course, rfkill should probably not do something that makes the chip lose its firmware
Nov 05 20:14:12 <PaulFertser> wpwrak: the question is whether bluetoothd should consider rfkill event as "the device was powered off" event or not.
Nov 05 20:14:16 <TAsn> alexxy, whatever. ;)
Nov 05 20:14:19 <TAsn> ciao.
Nov 05 20:14:21 <TAsn> again.
Nov 05 20:14:37 <wpwrak> PaulFertser: i think it should just kill the RF, not the logic :)
Nov 05 20:14:57 <PaulFertser> wpwrak: i think the same as you might have noticed ;)
Nov 05 20:15:12 <wpwrak> PaulFertser: what btd does would then depend on what the driver needs
Nov 05 20:16:05 <wpwrak> PaulFertser: yup, i think we're on the same page. in my opinion, it's almost always better if you implement anything that looks remotely like policy out of the kernel.
Nov 05 20:18:01 <wpwrak> PaulFertser: there's a certain "kernel machismo" where people feel happy if they have managed to implement something in the kernel. i don't follow that fashion ;-)
Nov 05 20:19:23 <wpwrak> PaulFertser: it's a bit like the use of magic if you're trying to write a fantasy story. it allows you to do creative things, but if you use it all the time, your work becomes dull and unconvincing.
Nov 05 20:25:55 <PaulFertser> wpwrak: i like how you put it
Nov 05 20:25:56 <PaulFertser> :)
Nov 05 20:26:23 <PaulFertser> wpwrak: thanks a lot for your time
Nov 05 20:26:57 * PaulFertser hopes larsc still has some strong points to discuss with wpwrak to come to the decision everybody'll like
Nov 05 20:29:22 <larsc> well, it's stupid not to reduce power usage on an device where power is one of it's limited resources if you now it's safe to do so
Nov 05 20:30:31 <wpwrak> larsc: there's nothing that prevents you from doing just that :)
Nov 05 20:31:53 <larsc> indeed
Nov 05 20:33:38 <wpwrak> anyway, gotta leave my lair for a bit. back in a few hours ...
Nov 05 20:34:51 <larsc> btw. talking about not solving problems in kernel. regulators and gpios are already exported via sysfs, so you could do without any kernel driver at all
Nov 05 20:36:21 <larsc> and suddnly everything gets turns amazingly simpleh
Nov 05 20:36:29 <larsc> -h
Nov 05 20:41:47 * rebelThor waves hello
Nov 05 20:42:15 <dos1> i updated SHR project info on ohloh
Nov 05 20:42:19 <dos1> added logo, new repositiories...
Nov 05 20:42:27 <dos1> statistics should be updated soon ;)
Nov 05 20:42:54 <larsc> PaulFertser: I vote for going completly userspace for gsm and gps
Nov 05 20:44:22 <larsc> you could even emulate the kernel drivers by using fuse ;)
Nov 05 20:44:34 <juri_> i vote for maximum separation of mechanism from policy. ;)
Nov 05 20:45:06 <PaulFertser> juri_++
Nov 05 20:46:08 <juri_> of course, my project is still recovering from kicking things into userspace...
Nov 05 20:47:06 <juri_> so, i guess i'm saying as manpower allows.
Nov 05 20:47:26 <PaulFertser> juri_: have you seen my suggestion about your bugreport?
Nov 05 20:47:48 <rebelThor> hey guys, what's the current status of the shr/merge image, what still doesn't work properly/
Nov 05 20:49:33 <larsc> juri_: what things?
Nov 05 20:52:09 <rebelThor> shouldn't http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/tasks/task-shr.bb?h=shr/merge also include mokomaze ?
Nov 05 20:53:13 <juri_> larsc: in my case, its cluster scheduling algorithms.
Nov 05 20:53:47 <juri_> theres no reason those should be in the kernel, because theres more than one way to do it, and no dependancies on anything in-kernel.
Nov 05 20:54:26 <larsc> ah ok, thought it was openmoko related
Nov 05 20:54:32 <larsc> which confused me
Nov 05 20:54:38 <juri_> nopenope. i'm way too busy already. :/
Nov 05 20:55:04 <juri_> (i need my own support team, i swear..)
Nov 05 20:56:50 <larsc> PaulFertser: from your (non) response i guess you don't like that idea either?
Nov 05 20:57:18 <PaulFertser> larsc: i thought you meant it in ironic and rhetoric way 
Nov 05 20:57:36 <PaulFertser> larsc: :)
Nov 05 20:57:43 <larsc> no
Nov 05 20:57:50 <PaulFertser> larsc: and yes, i do not quite like toggling regulators and gpios from userspace.
Nov 05 20:58:32 <larsc> if you think about it, it's currently no different.
Nov 05 21:02:09 <PaulFertser> larsc: the way it currently is sucks, so what?
Nov 05 21:03:43 <larsc> if there is no kernel driver it's no longer my problem ;)
Nov 05 21:03:49 <juri_> there have been many debates regarding seperation of policy from mechanism in the linux kernel. i suggest reading. ;)
Nov 05 21:04:10 <larsc> PaulFertser: just i case. above comment was ironic
Nov 05 21:04:38 <PaulFertser> You never know if larsc's comment is ironic or not. ;)
Nov 05 21:04:50 <PaulFertser> So thanks for explicitly mentioning it ;)
Nov 05 21:06:56 <larsc> currently there is no generic interface to deal with what we need. and the openmoko specific implementation sucks. so imo providing no interface is better the providing an broken interface
Nov 05 21:08:42 <larsc> in the later case people will complain if you introduce a new sane interface, in the fromer case they will joy if you do
Nov 05 21:09:31 <juri_> so, you're already providing an interface, its just a de-facto one with no real 'standardization' to it.
Nov 05 21:09:53 <larsc> i do not
Nov 05 21:09:58 <juri_> the interface is "don't touch except in this special way!", right?
Nov 05 21:10:05 <PaulFertser> larsc: i must admit that sounds reasonable
Nov 05 21:10:32 <Heinervdm> TAsn: http://trac.shr-project.org/trac/ticket/617 ;)
Nov 05 21:10:39 <PaulFertser> larsc: just that in the former case they will complain constantly until you do provide a new sane interface
Nov 05 21:12:53 <larsc> i'm not to sure about that
Nov 05 21:18:40 <larsc> implementing a fso resource provider using sysfs gpio and regulators should be reasonable simple
Nov 05 22:34:46 * Weiss growls at Glamo burst commands, and wonders what snippet of information the docs aren't giving him
**** ENDING LOGGING AT Thu Nov 05 22:35:36 2009

**** BEGIN LOGGING AT Thu Nov 05 22:46:16 2009
Nov 05 22:46:36 <wpwrak> larsc: dunno how far you get with fuse. but yes, it can probably solve a lot of such issues as well.
Nov 05 22:47:18 <wpwrak> microkernel, here we come ;-)
Nov 05 22:47:38 <larsc> I was thinking the same just a few seconds ago :)
Nov 05 22:49:32 <wpwrak> great minds think alike ;-)
Nov 05 23:01:55 <larsc> wpwrak: ah now i know what you meant by "i2s may be worth considering". The kernel has a standard interface to control gpio pins and regulators. So you don't have to do direct hw access. Otherwise I wouldn't have suggested driving gsm and gps from userspace.
Nov 05 23:03:50 <wpwrak> that was i2c :) (pmu)
Nov 05 23:03:58 <larsc> right
Nov 05 23:04:30 <wpwrak> (gsm, gps) so /dev/tty* then, with all the brains in user space. that's pretty much what we already do :)
Nov 05 23:04:51 <larsc> exactly.
Nov 05 23:15:10 <CIA-52> freesmartphone.org: 03mickey 07phonesim * rfb11aa7e9b12 10/modems/generic.xml: add mandatory \r\n before sending continuation characters '> '
Nov 06 00:08:13 <pwgen> does someone know where i can find documentation for the bluz-dbus interface ( bluez4 ) ?
Nov 06 00:08:30 <pwgen> i can find only outdated stuff
**** ENDING LOGGING AT Fri Nov 06 02:59:57 2009