**** BEGIN LOGGING AT Sat Apr 17 02:59:56 2010
Apr 17 05:35:13 <mickeyl> morning
Apr 17 05:37:19 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * r37e34401f384 10/fsogsmd/ (6 files in 2 dirs): fsogsmd: sms: honor the want_report condition when composing SMS
Apr 17 05:49:47 <spaetz> early riser... :-)
Apr 17 05:49:53 <spaetz> morning
Apr 17 05:53:04 <mickeyl> you too :)
Apr 17 06:12:44 <PaulFertser> DocScrutinizer: hey, how's your laptop cooler quest?
Apr 17 06:13:07 <PaulFertser> I'm going to try to find a semi-compatible cooler for my lappy now, the one i got is too damn noisy already.
Apr 17 06:19:22 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * rc660aea755ab 10/fsogsmd/src/lib/fsogsm3rdparty.vapi: fsogsmd: fsogsm3rdparty.vapi: add has_type_id to enums
Apr 17 06:19:49 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * r99ba30923f1b 10/fsogsmd/src/lib/atcommands.vala: fsogsmd: atcommands: add +CDS
Apr 17 06:20:19 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * r7b5fe769f619 10/fsogsmd/src/lib/atunsolicited.vala: fsogsmd: atunsolicited: handle +CDS
Apr 17 06:20:48 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * rf3a9a1b14350 10/fsogsmd/src/lib/ (atsms.vala sms.vala): fsogsmd: sms: add skeleton for handling incoming sms status reports
Apr 17 07:25:22 <graziano> how is it going the test with the new wifi manager?
Apr 17 07:26:00 <graziano> did someone make a recipe for it? Is it possible to install it in shr now?
Apr 17 07:40:58 <mrmoku> graziano: works great for me (with illume1)
Apr 17 07:41:07 <mrmoku> graziano: and I think it is not yet in the feed
Apr 17 07:41:19 <mrmoku> if you want to give it a spin there are packages floating around
Apr 17 07:42:08 <mrmoku> what is the IRC app of choice these days?
Apr 17 07:44:31 <graziano> mrmoku, I am using xchat and I feel good with it, other people use more geek tools such as irssi or emacs :)
Apr 17 07:44:46 <JaMa> its author had recipe, I've adjusted it a bit, but didn't push it yet
Apr 17 07:46:35 <mrmoku> graziano: ok... nothing changed then :)
Apr 17 07:46:49 <graziano> e.g. gnewsense has emacs preinstalled by default so many people prefer to use that as irc client
Apr 17 07:46:51 <graziano> mrmoku, ahahahhaha
Apr 17 07:47:00 * JaMa use irssi
Apr 17 07:47:05 * mrmoku build irssi
Apr 17 07:47:13 <mrmoku> graziano: I don't get warm with emacs
Apr 17 07:47:48 <mrmoku> graziano: was using xchat too for some time...
Apr 17 07:48:17 <graziano> mrmoku, what are you using right now?
Apr 17 07:49:02 <CIA-75> freesmartphone.org: 03mickey 07specs * r81cf7505db7f 10/ (3 files in 3 dirs): org.freesmartphone.GSM.SMS: add preliminary signal for incoming SMS status reports
Apr 17 07:49:07 <mrmoku> well... nothing that's why I asked. But as wifi works great with the new kernel I need something now :)
Apr 17 07:50:36 <CIA-75> freesmartphone.org: 03mickey 07specs * ra90d3778075e 10/html/index.html: link new device APIs for proximity and ambient light sensors
Apr 17 07:51:48 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * r5bf05b927571 10/fsogsmd/ (4 files in 2 dirs): fsogsmd: incoming status report signals are now working
Apr 17 07:52:23 <mickeyl> ok. whoever request status reports, here they are now
Apr 17 07:52:30 <mickeyl> note that the signature is not final yet
Apr 17 07:52:49 <mrmoku> mickeyl: great
Apr 17 07:53:23 * mrmoku wonders if that ambient light sensor might work on his new Dell notebook :P
Apr 17 07:53:32 <mickeyl> hehe, probably not
Apr 17 07:53:36 <mickeyl> there is no common interface for that
Apr 17 07:53:45 <mrmoku> heh
Apr 17 07:53:47 <mickeyl> i will create plugins for the palmpre over this weekend
Apr 17 07:53:48 <mrmoku> always the same thing
Apr 17 07:53:58 <mickeyl> yeah, we're really pioneering here
Apr 17 07:54:40 <mickeyl> and eventually, we probably see something slightly different from intel or nokia ;)
Apr 17 07:55:57 <mrmoku> what is Palms state btw. (the company not the pre)?
Apr 17 07:56:06 <mickeyl> bad
Apr 17 07:56:20 <mrmoku> heard that Lenovo might be interested :P
Apr 17 07:56:21 <mickeyl> basically they are looking for a buyer
Apr 17 07:56:32 <mickeyl> there are various rumors
Apr 17 07:56:39 <mickeyl> like lenovo or HTC
Apr 17 07:57:22 <mickeyl> however if one of those asian companies buy it, it's rather to aquire some patents than to continue developing the OS and hardware
Apr 17 07:57:40 <mickeyl> they're pretty much settled on android i think
Apr 17 07:59:59 * mickeyl goes to prepare breakfast for the misses
Apr 17 08:00:15 <mickey|breakfast> (who is still sleeping, if i may add...)
Apr 17 08:01:37 <mrmoku> :P
Apr 17 08:02:04 <mrmoku> mickey|breakfast: will give you a lot of plus points
Apr 17 08:02:20 <mrmoku> the misses will like that
Apr 17 08:10:49 <daniele_athome> JesusMcCloud, good morning
Apr 17 08:11:06 <graziano> true
Apr 17 08:11:06 <graziano> :)
Apr 17 08:17:26 <graziano> spaetz, when the new wifi manager is pushed to shr-u could you please make it available to shr-t too? Thanks
Apr 17 08:59:07 <daniele_athome> mrmoku, hi. yesterday you said that you have been using fsogsmd for quite some time
Apr 17 08:59:13 <daniele_athome> how do you start it? by init script?
Apr 17 09:00:49 <daniele_athome> mrmoku, never mind :)
Apr 17 09:00:54 <daniele_athome> http://build.shr-project.org/tests/mrmoku/fsogsmd/ :)
Apr 17 09:04:44 <mrmoku> daniele_athome: yep, started to play with dbus-activation though
Apr 17 09:04:56 <daniele_athome> mrmoku, is it convenient?
Apr 17 09:05:08 <daniele_athome> I mean, time needed to trigger the process etc.
Apr 17 09:05:26 <mrmoku> just call any method
Apr 17 09:05:54 <daniele_athome> mrmoku, i see you are using libfso-glib
Apr 17 09:06:10 <daniele_athome> are you about to drop libframeworkd-glib?
Apr 17 09:09:43 <mrmoku> not yet, as some things don't work with libfso-glib
Apr 17 09:10:10 <daniele_athome> not yet? so I assume frameworkd-glib will be abandoned?
Apr 17 09:11:57 <mrmoku> as soon as libfso-glib fullfills everything we need I will pass the lfg maintainer hat to you :-)
Apr 17 09:15:25 <daniele_athome> lol
Apr 17 09:15:56 <daniele_athome> mrmoku, i need fsogsmd compatibility, so I will start to adapt lfg to it right now :)
Apr 17 09:16:05 <daniele_athome> and then, we'll see...
Apr 17 09:16:10 <CIA-75> SHR: 03soltys 07shr-settings * rd40228ccc802 10/data/po/shr-settings.pot: shr-settings.pot regen
Apr 17 09:16:11 <CIA-75> SHR: 03soltys 07shr-settings * r9a7a28df1f25 10/data/po/pl/ (shr-settings.mo shr-settings.po): updated polish translation
Apr 17 09:17:38 <daniele_athome> mmm... set/get functionality is already there :D
Apr 17 09:31:47 <PaulFertser> ~seen DocScrutinizer 
Apr 17 09:31:49 <apt> docscrutinizer is currently on #maemo (4h 57m 44s) #meego (4h 57m 44s) #openmoko (4h 57m 44s) #infobot (4h 57m 44s) #openmoko-cdevel (4h 57m 44s), last said: 'alas even that won't add a 4th row'.
Apr 17 10:24:21 <mrmoku> mickeyl: I noticed you removed the sim-ready signal... Is that temporary or final?
Apr 17 10:25:31 <mrmoku> not that we would need it... just that if it's final I will remove the code for it
Apr 17 10:29:03 <mrmoku> playya_: time for a different libfso-glib problem? :)
Apr 17 10:39:27 <mickeyl> mrmoku: the sim-ready is gone for good.
Apr 17 10:39:44 <mickeyl> mrmoku: the new status signal has superseded it
Apr 17 10:46:11 <mrmoku> mickeyl: ok
Apr 17 10:47:00 <playya_> mrmoku, yes
Apr 17 10:47:12 <Heinervdm> mrmoku: how can i make nice input fields with elm?
Apr 17 10:48:54 <mrmoku> playya_: this time a signal handler :)
Apr 17 10:49:04 <playya_> ok
Apr 17 10:49:05 <mrmoku> [SIGNAL] org.freesmartphone.Preferences.Notify  /org/freesmartphone/Preferences  :1.22
Apr 17 10:49:09 <mrmoku> ( "default" )
Apr 17 10:49:10 <mrmoku> makes it go boom
Apr 17 10:49:17 <playya_> but the signal is emitted?
Apr 17 10:49:18 <mrmoku> before the signal handler is called
Apr 17 10:49:20 <mrmoku> yep
Apr 17 10:49:34 <playya_> huh
Apr 17 10:49:54 <mrmoku> first thing in my signal handler is a logger... don't have that
Apr 17 10:50:47 <playya_> are there any other handlers connected?
Apr 17 10:50:54 <mrmoku> to Preferences? no
Apr 17 10:51:59 <mrmoku> hmm
Apr 17 10:52:13 <mrmoku> maybe I just connected to the wrong thing...
Apr 17 10:52:30 <mrmoku> as there is Preferences/Service which has a notify too
Apr 17 10:52:37 <mrmoku> with a different signature
Apr 17 10:53:06 <playya_> yes
Apr 17 10:53:10 <PaulFertser> mickeyl: another traceback in ophoned: http://paste.debian.net/69363/ (if you do not want to tackle this, probably i'll try to understand a possible reason myself...)
Apr 17 10:53:49 <mrmoku> playya_: fso.preferences = free_smartphone_get_preferences_proxy(_dbus(), FSO_FRAMEWORK_PREFERENCES_ServiceDBusName, FSO_FRAMEWORK_PREFERENCES_ServicePathPrefix);
Apr 17 10:53:52 <mrmoku> looks correct though
Apr 17 10:54:24 <playya_> yes
Apr 17 10:55:00 <mrmoku> g_signal_connect(G_OBJECT(fso.preferences), "notify", G_CALLBACK(_profile_changed_handler), NULL);
Apr 17 10:55:06 <mrmoku> looks correct too...
Apr 17 10:55:10 <mickeyl> PaulFertser: i guess that bug has been in there from day 1 when charlie wrote that code
Apr 17 10:55:23 <mickeyl> PaulFertser: ophoned does not take into account that the incoming signal will be sent multiple times
Apr 17 10:55:27 <mickeyl> PaulFertser: two possible fixes
Apr 17 10:55:31 <mickeyl> PaulFertser: first, remember
Apr 17 10:55:46 <mickeyl> PaulFertser: or second, put try/error around the handler creation
Apr 17 10:57:07 <PaulFertser> mickeyl: with try/error it'll do useless dbus calls to realise it's already there, right?
Apr 17 10:58:33 <mickeyl> not necessarily
Apr 17 10:58:37 <mickeyl> depends on the bindings
Apr 17 10:58:45 <mickeyl> they might cache the results
Apr 17 11:04:17 <playya_> mrmoku, are there any other notify signals?
Apr 17 11:05:17 <playya_> maybe glib just mangles the notify signal with GObject notify signal?
Apr 17 11:06:10 <PaulFertser> mrmoku: what about incomplete sms messages? I'm not sure i want to have them on sim (without any easy way to read those). I want them in opimd too...
Apr 17 11:06:59 <mrmoku> playya_: that is an interesting theory too... no idea about aht one
Apr 17 11:07:18 <mrmoku> PaulFertser: that one you have to discuss with TAsn and mickeyl :)
Apr 17 11:07:23 <mrmoku> no idea for myself
Apr 17 11:07:49 <PaulFertser> Ok
Apr 17 11:07:49 <PaulFertser> :)
Apr 17 11:08:32 <mickeyl> i'm -1 on that
Apr 17 11:08:48 <mickeyl> but won't veto, if you really want that
Apr 17 11:09:03 <mickeyl> ah wait
Apr 17 11:09:25 <mickeyl> i guess the fsogsmd message book will give you access to those
Apr 17 11:09:32 <mickeyl> it will just not notify you on a new one
Apr 17 11:09:43 <PaulFertser> Yes, but shr lacks access through fsogsmd message book, only through opimd
Apr 17 11:10:02 <mrmoku> PaulFertser: you can find them in /tmp/fsogsmd...
Apr 17 11:10:12 <PaulFertser> And it's reasonable to expect that 1/4 parts of a message will be lost forever.
Apr 17 11:10:33 <PaulFertser> And moreover, what if my SIM storage overflows because of those?
Apr 17 11:10:38 <mickeyl> it won't
Apr 17 11:10:46 <mickeyl> your SIM storage will be emptied
Apr 17 11:10:52 <PaulFertser> That's even nastier!
Apr 17 11:11:09 <mickeyl> either we provide a high level access or a low level one
Apr 17 11:11:10 <PaulFertser> I use SIM to store messages that are important for my feelings ;)
Apr 17 11:11:12 <mickeyl> you can't have both ones
Apr 17 11:11:45 <mickeyl> fsogsmd needs to be able to delete at least one message from SIM to make room for new ones
Apr 17 11:11:58 <PaulFertser> I'm not proposing a solution, i rather complain about the situation. I'd never agree on anything deleting messages on SIM behind my back :(
Apr 17 11:12:22 <mickeyl> hmm
Apr 17 11:12:26 <mickeyl> then you might want to stay with ogsmd
Apr 17 11:12:33 <PaulFertser> And also not having messsages in the usual place just because one part got lost is unfun.
Apr 17 11:12:33 <mickeyl> which has full control over that
Apr 17 11:12:36 <mrmoku> playya_: how to find out if there is such a signal from glib?
Apr 17 11:12:45 <PaulFertser> mickeyl: no, i'll rather fork fsogsmd muhahaha
Apr 17 11:12:49 <mickeyl> uh oh 
Apr 17 11:12:50 <mickeyl> :D
Apr 17 11:12:57 <playya_> i know there's such a signal
Apr 17 11:13:10 * Kensan gets out the pitchforks an torches
Apr 17 11:13:16 <Kensan> What are we forking?
Apr 17 11:13:33 <playya_> it's for notification if a property changes
Apr 17 11:13:37 <mrmoku> playya_: ok, then we have to rename the fso one? or does it get automatically renamed maybe and I'm listening to the wrong one?
Apr 17 11:13:39 <PaulFertser> mickeyl: well, do not you agree sim storage is something private to user, so deleting anything from it is not exactly cool?
Apr 17 11:13:58 <mickeyl> not really, no
Apr 17 11:13:59 <mrmoku> or probably teach vala-dbus-binding-tool to rename it?
Apr 17 11:14:10 <mickeyl> at least not if it's backuped
Apr 17 11:14:50 <playya_> for the GObject one you use notify::property name
Apr 17 11:14:56 <mickeyl> or we defer the problem of not being able to receive SMS to the user
Apr 17 11:15:11 <Kensan> "Sorry, no storage on SIM" not an option?
Apr 17 11:15:17 <mrmoku> playya_: ?
Apr 17 11:15:28 <PaulFertser> Why use sim as a storage in the first place, why not read them immediately?
Apr 17 11:15:32 <mickeyl> Kensan: that sounds very hackish to me
Apr 17 11:15:58 <mickeyl> PaulFertser: using sim storage is better in several regards
Apr 17 11:16:07 <mickeyl> timing, reliability
Apr 17 11:16:22 <mickeyl> also simplifies the implementation
Apr 17 11:16:23 <Kensan> mickeyl: yeah, I am just throwing in random stuff :) I don't know the whole issue PaulFertser is trying to solve
Apr 17 11:16:24 <mickeyl> which is always a good thing
Apr 17 11:16:48 <mickeyl> i got rid of being able to chose between direct reception and reception via sim for a reason
Apr 17 11:17:01 <Kensan> mickeyl: but indicating to the user that sim storage is full might still be a good idea no?
Apr 17 11:17:11 <PaulFertser> Kensan: my issue is 1. reading incomplete messages using usual UI. 2. i do not like to have messages on sim silently deleted.
Apr 17 11:17:30 <Kensan> PaulFertser: yes, 2. sounds ... not so fun...
Apr 17 11:17:44 <mrmoku> playya_: you mean I have to register for 'notify::property' instead of 'notify' ?
Apr 17 11:18:10 <playya_> no. that's the property thingy by GObject
Apr 17 11:18:12 <Kensan> mickeyl: so if I understand correctly, you need storage on the SIM because received SMS are "automatically" stored on the sim?
Apr 17 11:18:28 <mrmoku> ahh, so we're back to the beginning? :P
Apr 17 11:18:46 <mickeyl> Kensan: correct
Apr 17 11:19:15 <mickeyl> Kensan: if we configure it like that, this will happen outside of our control
Apr 17 11:19:21 <mickeyl> and if the sim is full, it will not work
Apr 17 11:19:40 <PaulFertser> mickeyl: do you need only one free slot? Or do you need to keep all parts of a multi-part messages there until the final one is received?
Apr 17 11:19:52 <mickeyl> PaulFertser: one free slot is enough
Apr 17 11:20:02 <Kensan> mickeyl: hm, what is the reason that the storage backend for SMS *must* be SIM?
Apr 17 11:20:04 <mickeyl> composing is being done by us
Apr 17 11:20:09 <mickeyl> err, reassembling, that is
Apr 17 11:20:14 <mickeyl> Kensan: it's better
Apr 17 11:20:18 <mickeyl> <mickeyl> timing, reliability
Apr 17 11:20:18 <mickeyl> <mickeyl> also simplifies the implementation
Apr 17 11:21:03 <mickeyl> other implementations do that as well... not that this would be an argument, just to toss it into the discussion
Apr 17 11:21:15 <PaulFertser> mickeyl: if fsogsmd always removes messages it received from that slot it should be enough. The only problem if the user starts fsogsmd with a full sim -- then you give him a worning.
Apr 17 11:21:20 <Kensan> mickeyl: ok so it's better on receiption. What if you use a couple "slots" on the SIM as receiption buffer and move them to memory/flash 
Apr 17 11:21:32 <mrmoku> playya_: have to go for lunch now... bbl
Apr 17 11:21:34 <Kensan> if the user wants the SMS not to be stored on the SIM
Apr 17 11:22:06 <Kensan> mickeyl: basically what PaulFertser said :)
Apr 17 11:23:03 <Kensan> PaulFertser: yes, that's what I meant with indicating a full sim to the user.
Apr 17 11:23:35 <Kensan> Can one refuse to accept and SMS from the network?
Apr 17 11:24:07 <mickeyl> yes
Apr 17 11:24:16 <PaulFertser> Kensan: the modem'll do just that if it's configured to store on sim and it's full.
Apr 17 11:24:28 <PaulFertser> Kensan: and the network will resend the message later.
Apr 17 11:24:32 <PaulFertser> afaik
Apr 17 11:24:43 <Kensan> mickeyl: so in the case of a full sim we could refuse to accept SMS from the network assuming the network will try again to deliver the message
Apr 17 11:24:53 <Kensan> ok
Apr 17 11:25:35 <Kensan> so that would be ok imho, simply indicating to the user that sim is full and that he must delete at least n messages so SMS reception is possible again.
Apr 17 11:27:15 <mickeyl> that sounds so featurephonish :/
Apr 17 11:27:20 <mickeyl> and manual :/
Apr 17 11:27:35 <mickeyl> no modern phone requires you to delete messages manually to receive more SMS
Apr 17 11:28:02 <Kensan> ok, so can you block/reserve one sms slot on the sim?
Apr 17 11:28:11 <PaulFertser> If your sim has no messages, you'll never see that notification anyway.
Apr 17 11:28:24 <PaulFertser> And if you do it means you care about your sim messages -> care to do a manual step.
Apr 17 11:28:50 <Kensan> mickeyl: if one message slot is enough then we should be fine if we can guarantee that one is always available for the purpose of sms reception
Apr 17 11:29:25 <PaulFertser> I mean you can't ignore the underlying technology (sim sms slots) when the user is aware of it and purposedly uses it...
Apr 17 11:30:08 <Kensan> PaulFertser: yes, but going forward I see mickey's point that the user should not have to care about these details
Apr 17 11:30:43 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * rbd1e67d51dd6 10/fsodeviced/src/plugins/ambientlight_palmpre/plugin.vala: fsodeviced: ambientlight_palmpre: first sketch at plugin implementation
Apr 17 11:31:05 <PaulFertser> Kensan: if the user gets a new sim, it's blank, it has all slots free -> the user never sees the "full sim" notification.
Apr 17 11:31:56 <Kensan> PaulFertser: true, but shouldn't we try to find a "better" solution that avoids user intervention completely?
Apr 17 11:32:48 <PaulFertser> I guess that's impossible. Either you put user in control of it or you do deletion automatically. I prefer to be in control for obvious reasons.
Apr 17 11:33:27 <PaulFertser> Hell, i couldn't answer a single call for 2 days, and i use FR for 1.5 years as my single phone. I couldn't care less about one little notification.
Apr 17 11:33:51 <PaulFertser> Kensan: (that was after i upgraded to fsogsmd and everything latest-and-greatest to be on the edge)
Apr 17 11:36:17 <Kensan> PaulFertser: well if one SMS SIM slot is reserved for the purpose of SMS reception then there would be no need to delete arbitrary messages at all no?
Apr 17 11:36:47 <PaulFertser> Kensan: it can't be "reserved". If the user puts a full sim, it's already full, nothing can be done about it.
Apr 17 11:43:35 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * r61f8d1da7a20 10/fsodeviced/src/plugins/proximity_palmpre/plugin.vala: fsodeviced: proximity_palmpre: first sketch at plugin implementation
Apr 17 11:43:44 <PaulFertser> TAsn: where's opimd query documented? I hoped to find it in the official freesmartphone API docs...
Apr 17 11:46:03 <PaulFertser> TAsn: i also do not understand stripping + from phone numbers...
Apr 17 11:48:07 <PaulFertser> Hm, i wonder on what step they were actually stripped
Apr 17 11:48:47 <PaulFertser> fsogsmd returned me all my contacts with + when i asked it about my sim phonebook.
Apr 17 11:49:52 <PaulFertser> s/with/without/
Apr 17 11:49:53 <apt> PaulFertser meant: fsogsmd returned me all my contacts without + when i asked it about my sim phonebook.
Apr 17 12:02:03 <mrmoku> PaulFertser: I don't think the special query keywords are documented :/
Apr 17 12:02:30 <mrmoku> PaulFertser: and stripping + from numbers in SIM phonebook is a fsogsmd bug
Apr 17 12:03:18 <PaulFertser> mrmoku: ok, thanks
Apr 17 12:04:41 <mrmoku> PaulFertser: ahh... you already found the ticket :P
Apr 17 12:05:11 <soltys> ~nf
Apr 17 12:05:13 <apt> The #openmoko-cdevel Newsflash Bulletin Board. (continued at ~NF2. For help see ~NF-help)  - - - Recommended URLs and channels(chanlogs etc):see ~RL  - - -  NEWSFLASH [2010-03-28 21:09 UTC]:buildhost got rebooted... new RAM will arrive beginning of next week
Apr 17 12:06:49 <mrmoku> Weiss: I have lots of strange stuff in dmesg...
Apr 17 12:06:53 <mrmoku> [ 3066.520000] [glamo-drm] Fence seq#489 was not signalled
Apr 17 12:06:56 <mrmoku> [ 3066.560000] [glamo-drm] CmdQ decode failure.
Apr 17 12:07:35 <mrmoku> [ 3066.515000] WARNING: at kernel/irq/manage.c:274 __enable_irq+0x60/0x90()
Apr 17 12:07:38 <mrmoku> [ 3066.515000] Unbalanced enable for IRQ 64
Apr 17 12:07:44 <mrmoku> and system slows down to death
Apr 17 12:10:02 <leviathan> mickeyl, GNUtoo: A made a new agreement now, with my provider, Soon I will have UMTS flatrate on my dream
Apr 17 12:10:19 <mrmoku> Weiss: this is the complete kernel trace: http://shr.pastebin.com/84m2NmeH
Apr 17 12:10:32 <mickeyl> leviathan: awesome, that at least works :)
Apr 17 12:10:36 <mrmoku> leviathan: hehe, did that yesterday too :)
Apr 17 12:10:50 <leviathan> :)
Apr 17 12:10:53 <mickeyl> i'll add automatic data connectivity soon
Apr 17 12:11:04 <mickeyl> any time to work on BT?
Apr 17 12:11:26 <mickeyl> since GNUtoo is deep in suspend/resume, this, GPS, and camera are the only remaining major issues
Apr 17 12:12:02 <mrmoku> JesusMcCloud: do you get kernel traces when it eats your SDs?
Apr 17 12:14:45 <leviathan> mickeyl: uhm
Apr 17 12:15:09 <leviathan> ATM I'm on implementing the subpage size reading feature in the mtd driver
Apr 17 12:15:31 <mickeyl> ok, still on nand
Apr 17 12:15:37 <mickeyl> we need more developers...
Apr 17 12:18:00 <leviathan> mickeyl: YES
Apr 17 12:23:29 <mickeyl> PaulFertser: shall i secure the ophoned traceback w/ try/except or do you want to work on it?
Apr 17 12:23:44 <mickeyl> mrmoku: how can i reproduce the + problem?
Apr 17 12:24:10 <mrmoku> mickeyl: just take a look at the contacts in /tmp/fsogsmd
Apr 17 12:24:15 <mickeyl> k
Apr 17 12:24:49 <mrmoku> playya_: I tried the notify signal with a small test app... segfaults too
Apr 17 12:25:05 <mickeyl> mickey@andromeda:/tmp/fsogsmd/pb/262032310411788/SM_1_250$ cat 085 
Apr 17 12:25:05 <mickeyl> SOS-Service:+49177123410
Apr 17 12:25:08 <mickeyl> hmm#
Apr 17 12:26:29 <mrmoku> playya_: and the very useful bt goes like this: http://shr.pastebin.com/4D2R1ywG
Apr 17 12:26:34 <mrmoku> mickeyl: hmm
Apr 17 12:26:56 <PaulFertser> mickeyl: i'm not nearly confident in my python skills though i think i can manage this particular task. Assuming you can do that faster i wouldn't be against if you do it yourself ;)  
Apr 17 12:27:14 <mrmoku> mickeyl: I have them without + in there
Apr 17 12:27:15 <mickeyl> mrmoku: do you have anything that i can flash to my FR, then i would test there
Apr 17 12:27:17 <mrmoku> strange
Apr 17 12:27:24 <mickeyl> this is another modem
Apr 17 12:27:28 <mickeyl> perhaps something's different here
Apr 17 12:27:28 <mrmoku> ahh ok
Apr 17 12:27:41 <mrmoku> there is no ready to go image for fsogsmd
Apr 17 12:28:03 <mrmoku> you can flash the latest shr-u and disable ogsmd
Apr 17 12:28:09 <mrmoku> fsogsmd is in there
Apr 17 12:29:36 <mickeyl> ok, got an URI offhand?
Apr 17 12:30:11 <CIA-75> freesmartphone.org: 03mickey 07framework * r9430d6a68b59 10/framework/subsystems/ophoned/ (gsm.py ophoned.py protocol.py test.py): ophoned: add missing file headers
Apr 17 12:30:40 <mrmoku> mickeyl: http://build.shr-project.org/shr-unstable/images/om-gta02/shr-lite-eglibc-ipk--20100403-om-gta02.rootfs.tar.gz
Apr 17 12:30:45 <mrmoku> that is quite old though :/
Apr 17 12:30:52 <mrmoku> no idea what fsogsmd is in there
Apr 17 12:31:06 <mrmoku> let me try to build a ready-to-go image for you
Apr 17 12:31:58 <mrmoku> hmm... not sure if I can't do that
Apr 17 12:32:07 <mickeyl> don't bother
Apr 17 12:32:10 <mickeyl> i'll use forwarding
Apr 17 12:32:13 <mrmoku> without comitting stuff we do not want yet
Apr 17 12:32:14 <mickeyl> just need something that boots into a shell
Apr 17 12:32:23 <mrmoku> ok, then the image should be fine
Apr 17 12:32:25 <mickeyl> ok
Apr 17 12:32:52 <PaulFertser> Heh, i guess we should start to explicitly mention what device is used in FSO trac tickets :)
Apr 17 12:33:01 <PaulFertser> Finally
Apr 17 12:33:09 <mickeyl> yeah, definitely!
Apr 17 12:33:18 <mickeyl> there are major differences
Apr 17 12:36:34 <mickeyl> PaulFertser: hmm, could you have a look at the object tree when you call and not take the call?
Apr 17 12:36:37 <mickeyl> i think there is something else broken
Apr 17 12:36:48 <mickeyl> it looks like the ID is not correctly parsed
Apr 17 12:37:00 <mickeyl>  /org/freesmartphone/Phone/GSM/4 sounds bogus
Apr 17 12:37:36 <PaulFertser> mickeyl: Yes, indeed. What test exactly do you want me to perform? ;)
Apr 17 12:37:58 <mickeyl> PaulFertser: just introspect the object tree, i.e. mdbus2 org.freesmartphone.ophoned
Apr 17 12:38:01 <mickeyl> -s
Apr 17 12:38:08 <mickeyl> then attempt to call
Apr 17 12:38:18 <mickeyl> and repeatedly call the mdbus2 command
Apr 17 12:38:25 <mickeyl> to check how many new objects appear
Apr 17 12:38:37 <PaulFertser> I'd do it right away but i thought starting 200 opimd-cli instances in parallel was a nice idea...
Apr 17 12:38:46 <mickeyl> heh
Apr 17 12:38:57 <mickeyl> no hurry
Apr 17 12:39:02 <PaulFertser> :D
Apr 17 12:41:05 <PaulFertser> mickeyl: btw, if you by any chance know a nice and simple solution to "The received dbus object can be of any type and should be print'ed, if it's a string, assume it's unicode (and avoid 'ascii' codec can't encode lalala)", that'd help dos1 to fix his buggy tool ;)
Apr 17 12:42:44 * mwester 's grammar parser throws an exception on the quoted statement, and triggers "heuristic mode" in an attempt to make sense of the error message.
Apr 17 12:43:42 <PaulFertser> mwester: the error message itself is a standard indication python 2.x still doesn't fully use unicode by default.
Apr 17 12:47:55 <PaulFertser> mwester: opimd-cli tool receives fields values over dbus, sometimes numbers, sometimes unicode string. Simple python's print barks on strings. And .encode('utf-8') doesn't work on numbers.
Apr 17 12:48:28 <playya_> mrmoku, i wrote a dbus server which segfaults, too :/
Apr 17 12:48:39 <mrmoku> :/
Apr 17 12:49:55 <GNUtoo> leviathan, ok
Apr 17 12:50:14 <mrmoku> GNUtoo: just tried your remote gdb howto
Apr 17 12:50:20 <GNUtoo> ok
Apr 17 12:50:27 <GNUtoo> did it work fine?
Apr 17 12:50:30 <mrmoku> no :P
Apr 17 12:50:34 <GNUtoo> :(((
Apr 17 12:50:39 <GNUtoo> what was the issue?
Apr 17 12:50:41 <mrmoku> I get the same backtrace as on the neo
Apr 17 12:50:52 <GNUtoo> ah ok
Apr 17 12:50:54 <mrmoku> problem is missing symbols
Apr 17 12:51:01 <GNUtoo> ok
Apr 17 12:51:04 <mrmoku> ahh... and there is a -c missing
Apr 17 12:51:07 <mrmoku> for the ulimit call
Apr 17 12:51:25 <GNUtoo> ok,maybe busybox unlimit then
Apr 17 12:52:11 <mrmoku> hmm I think it is all ulimits...
Apr 17 12:52:13 <mrmoku> not sure though
Apr 17 12:52:14 <lindi-> busybox ulimit? ulimit is not a binary, it's builtin
Apr 17 12:52:29 <mrmoku> but -c for core dump limiting is what I know
Apr 17 12:53:47 <GNUtoo> mrmoku, I didn't include the -c because busybox's unlimit didn't have it
Apr 17 12:54:52 <lindi-> GNUtoo: what is this busybox's unlimit?
Apr 17 12:55:13 <GNUtoo> the one from ash I belive
Apr 17 12:55:38 <GNUtoo> but now it seem to have -c
Apr 17 12:58:09 <mickeyl> mrmoku: ok, confirmed, something wrong in my code
Apr 17 12:58:18 <mrmoku> :)
Apr 17 12:58:45 <mrmoku> mickeyl: and the image did boot your FR?
Apr 17 12:59:16 <mickeyl> no
Apr 17 12:59:19 <mrmoku> ohh
Apr 17 12:59:20 <mickeyl> i found an old FR prototype
Apr 17 12:59:26 <mickeyl> that boots into a shell
Apr 17 12:59:29 <mrmoku> ok
Apr 17 12:59:30 <mickeyl> and installed serial_forward
Apr 17 12:59:37 <mickeyl> i see the problem now
Apr 17 12:59:46 <mickeyl> the number transforming code is not getting called at all
Apr 17 12:59:47 <mickeyl> :)
Apr 17 12:59:54 <PaulFertser> mickeyl: 2010.04.17 16:58:36.816 ophoned              INFO     CallReleased (<ophoned.gsm.Call at /org/freesmartphone/Phone/GSM/0 at 0x5e8290>) but /org/freesmartphone/Phone/GSM/0 is still there
Apr 17 12:59:57 <mickeyl> the HTC Dream violates the spec
Apr 17 13:00:04 <mickeyl> by including the + for international numbers
Apr 17 13:00:10 <mickeyl> that's why i didn't notice it
Apr 17 13:00:12 <mrmoku> fun
Apr 17 13:00:18 <playya_> mrmoku, it seems to be the wrong name :/
Apr 17 13:00:21 <mickeyl> PaulFertser: that's what i suspected. 
Apr 17 13:00:31 <mickeyl> PaulFertser: so we have to check why the path is not being removed after the call ends
Apr 17 13:00:36 <mrmoku> playya_: I'm trying g_signal_query now
Apr 17 13:02:07 <playya_> i rename notify to notify2 and it works :/
Apr 17 13:02:35 <TAsn> PaulFertser, documentation: unfortunately nowhere, I wrote down what I added in a wiki page, but what was done before I touched opimd is not documented. Furthermore, fsogsmd is not me, so no idea about the stripping :P
Apr 17 13:02:58 <TAsn> PaulFertser, with that being said, it's pretty simple, so just ask whatever you need.
Apr 17 13:03:30 <PaulFertser> TAsn: i've already found a letter by dos1 and added a link to the "Opimd" wikipage.
Apr 17 13:03:34 <playya_> mrmoku, mickeyl, what about renaming Preferences.notify to changed?
Apr 17 13:04:12 <mickeyl> why?
Apr 17 13:04:19 <TAsn> PaulFertser, sweet :P I remembered I wasn't able to find anything, but if you found stuff, that's great.
Apr 17 13:04:35 <playya_> necause GObject already has a notfy signal :/
Apr 17 13:04:45 <mickeyl> ok
Apr 17 13:05:42 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * rb98228de97cb 10/fsogsmd/src/lib/atcommands.vala: fsogsmd: transform phone number and type into proper string. closes FSO #534
Apr 17 13:07:24 <TAsn> PaulFertser, just looked at that page (Opimd) and it's mostly outdated :P
Apr 17 13:07:34 <PaulFertser> TAsn: of course
Apr 17 13:07:43 <PaulFertser> TAsn: but it's the most likely candidate to be found
Apr 17 13:07:53 <TAsn> Yep.
Apr 17 13:07:55 <PaulFertser> TAsn: and dos1's letter looks not so outdated.
Apr 17 13:08:06 <TAsn> dos1's letter is mostly up to date
Apr 17 13:08:10 <TAsn> (lacking, but up to date)
Apr 17 13:08:50 <mickeyl> playya_: do you know the image target for the initramfs thing morphis builds?
Apr 17 13:10:56 <playya_> no
Apr 17 13:11:23 <mickeyl> k
Apr 17 13:11:29 * mickeyl trys fso-preview-image
Apr 17 13:12:24 <mrmoku> playya_: (process:901): GLib-GObject-WARNING **: gsignal.c:1149: unable to lookup signal "notify" for non instantiatable type `FreeSmartphonePreferences'
Apr 17 13:14:00 <PaulFertser> TAsn: is opimd supposed to be properly introspectable?
Apr 17 13:14:22 <mickeyl> opimd introspection is problematic since it uses fallback objects
Apr 17 13:14:42 <PaulFertser> Ok, so the answer is no :)
Apr 17 13:15:11 <mickeyl> yeah. fallback objects do not appear in introspection
Apr 17 13:15:22 <mickeyl> s/objects/paths/
Apr 17 13:15:22 <apt> mickeyl meant: yeah. fallback paths do not appear in introspection
Apr 17 13:15:28 <mickeyl> they can't -- by deisgn
Apr 17 13:16:18 <PaulFertser> mickeyl: heh, then mdbus2 shouldn't count on it that much, it doesn't allow me to remove contacts :)
Apr 17 13:16:36 <mickeyl> indeed
Apr 17 13:17:07 <playya_> which bitbake branch/version do you use for the pre?
Apr 17 13:17:08 <mickeyl> the reason for mdbus2 always relying on introspection is that i somewhat refuse to duplicate functionality that is in dbus but not exported to the public
Apr 17 13:17:27 <mickeyl> playya_: fso git, openembedded, master
Apr 17 13:17:56 <mickeyl> if libdbus would expose path and interface validation functions, i'd relax that
Apr 17 13:18:17 <mickeyl> i don't feel like writing these two functions
Apr 17 13:18:38 <PaulFertser> mickeyl: ok, sounds reasonable :) BTW, what about printing method's signature if i mistyped number of args? 
Apr 17 13:18:54 <mickeyl> then again, if we wait for the dbus folks, we wait until godoh
Apr 17 13:19:06 <mickeyl> PaulFertser: good idea
Apr 17 13:20:21 <PaulFertser> We're in a better position, at least we'd know exactly what we're waiting for.
Apr 17 13:20:59 <mickeyl> heh
Apr 17 13:22:23 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * r1613cf8ee09c 10/tools/mdbus2/src/main.vala: mdbus2: fix readline history name; this should close FSO #545
Apr 17 13:23:38 <mrmoku> ohh... fast man :9
Apr 17 13:24:58 <PaulFertser> Oh yeah, great timing :)
Apr 17 13:26:55 <Butch> hi
Apr 17 13:26:56 <PaulFertser> Hm, src/lib/atsms.vala:433.9-433.35: error: The name `incoming_message_report' does not exist in the context of `FreeSmartphone.GSM.SMS'
Apr 17 13:27:21 <CIA-75> freesmartphone.org: 03mickey 07cornucopia * re3f95d4a98f5 10/tools/mdbus2/src/main.vala: mdbus2: mention expected signature if argument count does not match; idea by Paul Fertser
Apr 17 13:27:40 <mickeyl> PaulFertser: rebuild specs and fso-glib
Apr 17 13:27:50 <mickeyl> ok, enough hacking for today
Apr 17 13:28:14 <PaulFertser> Yo, you're cool
Apr 17 13:28:15 <PaulFertser> :D
Apr 17 13:29:20 <mrmoku> playya_: do you rename or want me to rename it?
Apr 17 13:29:29 * mrmoku has to rebuild libfso-glib anyway now :)
Apr 17 13:29:42 <playya_> i can do it
Apr 17 13:29:55 <mrmoku> ok, waiting for your commit then :)
Apr 17 13:36:23 <PaulFertser> mrmoku: btw, did you agree on some sane way of handling speaker and mic controls during call? Or does shr just tweaks alsa settings directly?
Apr 17 13:37:27 <CIA-75> freesmartphone.org: 03Frederik.Sdun 07specs * r665093911b1e 10/ (3 files in 3 dirs): 
Apr 17 13:37:27 <CIA-75> freesmartphone.org: org.freesmartphone.Preferences: Rename Notify signal to Changed,
Apr 17 13:37:27 <CIA-75> freesmartphone.org:  because of name conflicts with GObject
Apr 17 13:39:46 <mrmoku> PaulFertser: I _think_ we are handling the controls directly... and then ask FSO to save the scenario
Apr 17 13:39:53 <mrmoku> but again... that's TAsn's domain :P
Apr 17 13:40:06 <PaulFertser> mrmoku: ok, thanks :D
Apr 17 13:41:54 <mrmoku> playya_: err = snd_hctl_elem_write(elem, control);
Apr 17 13:41:58 <mrmoku> ouch
Apr 17 13:42:02 <mrmoku> PaulFertser: ^
Apr 17 13:42:12 <mrmoku> so yes, alsa directly to set the volume (or mute)
Apr 17 13:42:33 <mrmoku> and then free_smartphone_device_audio_save_scenario
Apr 17 13:46:35 <PaulFertser> Hm, so what's the SMS on SIM behaviour right atm? What message will it delete when the storage is full? The last one received? Or the first on sim or which? Sometimes i do not like reading sources to find out the behaviour...
Apr 17 13:52:45 <mrmoku> eek... mickey|sports committed too much... git.fso.org is down :/
Apr 17 13:55:10 <spaetz> it ran hot?
Apr 17 13:55:28 <spaetz> or is it a windows box?
Apr 17 13:55:53 <mrmoku> no idea... but it's a good sign to stop hacking too for a bit :P
Apr 17 13:57:43 <spaetz> yep, enjpy the vulcan ashes outside a bit.
Apr 17 13:58:18 <mrmoku> unfortunatelly those are tooo high up to enjoy... kids are quite disappointed ;)
Apr 17 13:59:46 <mrmoku> shit... it's back
Apr 17 13:59:48 <mrmoku> :P
Apr 17 14:01:22 <mrmoku> hmm or not
Apr 17 14:33:22 <TAsn> PaulFertser, we teak also directly, though mickey|sports is working on API that will let us tweak it using fso, which will be nicer.
Apr 17 14:33:47 <TAsn> PaulFertser, We don't delete nothing from SIM, we don't even cache on sim.
Apr 17 14:34:24 <TAsn> Unless opimd too too long to answer modem, and in that case, it should be saved on sim for a sec, and then deleted when opimd reads it.
Apr 17 14:34:57 <PaulFertser> TAsn: _you_ do not, but fsogsmd does :(
Apr 17 14:35:12 <TAsn> oh, you are using fsogsmd
Apr 17 14:35:18 <TAsn> I was talking about ogsmd :P
Apr 17 14:38:13 <TAsn> PaulFertser, as for fsogsmd
Apr 17 14:38:17 <TAsn> It does cache on SIM
Apr 17 14:38:45 <TAsn> it saves, and then deletes (IIRC)
Apr 17 14:39:20 <TAsn> Anyhow, I'm pretty sure fsogsmd assumes there's room on the SIM
Apr 17 14:39:24 <TAsn> and doesn't delete anything.
Apr 17 14:40:08 <PaulFertser> TAsn: read scrollback :)
Apr 17 14:40:54 <TAsn> too tired :P
Apr 17 14:41:08 <TAsn> I'll just believe you I missed something important :P
Apr 17 14:58:39 <Weiss> mrmoku: what were you doing at the time?
Apr 17 14:59:09 <TAsn> <mrmoku> unfortunatelly those are tooo high up to enjoy... kids are quite disappointed ;)
Apr 17 14:59:31 <TAsn> mrmoku, my parents are abroad so they asked me to watch over my two brothers and their dog :|
Apr 17 14:59:38 <TAsn> mrmoku, And they are stuck in London
Apr 17 14:59:44 <mrmoku> Weiss: dunno... nothing special
Apr 17 14:59:49 <TAsn> mrmoku, which in turn means, I'm stuck with the dog/brothers :|
Apr 17 14:59:58 <mrmoku> TAsn: outch :|
Apr 17 15:00:03 <TAsn> damn volcano
Apr 17 15:00:06 <Weiss> mrmoku: X running I guess?
Apr 17 15:00:08 <TAsn> :)
Apr 17 15:00:08 <mrmoku> sure
Apr 17 15:01:05 <Weiss> looks like that latest patch to make sure the IRQ is enabled didn't help anything
Apr 17 15:01:18 <Weiss> but I don't know why people have suddenly started getting fence errors
Apr 17 15:01:57 <mrmoku> Weiss: probably I did something special... and just don't know and/or remember
Apr 17 15:04:12 <Weiss> "mobi phil" has exactly the same error..seemed to happen after the latest two patches
Apr 17 15:04:24 <Weiss> are you able to experiment a bit with reverting one or two of the latest patches?
Apr 17 15:05:15 <mrmoku> Weiss: which two patches are those?
Apr 17 15:05:36 <Weiss> http://git.bitwiz.org.uk/?p=kernel.git;a=commit;h=e49965464471cbbf2b8b5ff0883959961d06a8a6 and http://git.bitwiz.org.uk/?p=kernel.git;a=commit;h=ee53d975c157a9763b6f8637f1c47a3bc0671f77
Apr 17 15:06:03 <Weiss> the first of those shouldn't make a difference unless it already broke in exactly that way (the "fence not signalled" error).. the latter may be causing it somehow
Apr 17 15:06:30 <mrmoku> Weiss: ok, will build a kernel without that one
Apr 17 15:07:24 * Weiss tests also
Apr 17 15:08:21 <mrmoku> Weiss: I had a hard hang twice too... dunno if that is related as I could not check logs
Apr 17 15:08:59 <Weiss> how recently?
Apr 17 15:09:35 <mrmoku> today and yesterday
Apr 17 15:10:55 <Weiss> ok... looking a lot like one or both of those commits broke Stuff
Apr 17 15:11:11 <mrmoku> Weiss: and that WSOD I have... it is after a certain amount of time with backlight off
Apr 17 15:11:25 <mrmoku> no matter if I use fso API to turn it off, or XScreenSaver
Apr 17 15:11:47 <mrmoku> after around two minutes display will be white when re-enabling backlight
Apr 17 15:19:37 <mrmobil> wifi works excellent with radeks patches though
Apr 17 15:20:06 <mrmobil> (at least for what I was used to)
Apr 17 15:23:59 <mrmobil> if somebody would only fix vibr+leds :|
Apr 17 15:35:34 <TAsn> mrmoku, I have blackscreens of death.
Apr 17 15:35:41 <TAsn> with .29
Apr 17 15:35:43 <TAsn> once in a while
Apr 17 15:35:52 <mrmoku> Weiss: booted kernel without that patch... will ping you in case it re-happens
Apr 17 15:35:53 <TAsn> Didn't have time to debug
Apr 17 15:36:17 <mrmoku> TAsn: if only we had vibrators with the new kernel... we could immediately switch
Apr 17 15:36:48 <TAsn> That's the only thing missing? what about leds?
Apr 17 15:36:53 <TAsn> I remember those were missing two.
Apr 17 15:37:02 <mrmoku> vibrator... leds... all the same :P
Apr 17 15:37:09 <TAsn> BTW, what happened to the vibrator? FSO or kernel?
Apr 17 15:37:14 <mrmoku> kernel
Apr 17 15:37:18 <mrmoku> it's just not there
Apr 17 15:37:24 <TAsn> They don't work?
Apr 17 15:37:28 <TAsn> okie.
Apr 17 15:37:33 <TAsn> Anyone working on it?
Apr 17 15:38:02 <mrmoku> root@om-gta02 /sys/class/leds $ ls
Apr 17 15:38:02 <mrmoku> gta02:red:aux
Apr 17 15:38:04 <mrmoku> no idea
Apr 17 15:38:09 <mrmoku> I fear not so :/
Apr 17 15:38:23 <TAsn> With all the respect to myself, I'm not an experienced kernel hacker :P
Apr 17 15:40:12 <mrmoku> heh, yes
Apr 17 15:40:23 <mrmoku> there is one more thing I did not try yet with success
Apr 17 15:40:25 <mrmoku> GPS
Apr 17 15:42:17 * mrmoku turns GPS on and puts the thing outside
Apr 17 15:45:11 <lindi-> mrmoku: no need to put it outside if you are just testing kernel?
Apr 17 15:51:56 <mrmoku> lindi-: I want to see if it get's a fix... though shr-settings does not even show sattelites :/
Apr 17 15:52:04 <mrmoku> lindi-: how to check kernel side?
Apr 17 15:52:29 <lindi-> mrmoku: why would it not get a fix?
Apr 17 15:52:34 <lindi-> suspecting a hardware bug?
Apr 17 15:52:37 <mrmoku> no
Apr 17 16:00:45 <mrmoku> lindi-: a cat /dev/ttySAC1 shows nothing... does that say something?
Apr 17 16:02:01 <lindi-> mrmoku: use hexdump
Apr 17 16:02:24 <lindi-> mrmoku: lsof | grep ttySAC1
Apr 17 16:02:57 <lindi-> mrmoku: find /sys | grep power_on | grep pm-gps
Apr 17 16:02:57 <mrmoku> heh... no lsof
Apr 17 16:03:02 <lindi-> get a distro :P
Apr 17 16:03:06 <mrmoku> lindi-: the power node is there
Apr 17 16:03:08 <lindi-> (sorry, couldn't resist)
Apr 17 16:03:14 <lindi-> mrmoku: what does it read?
Apr 17 16:03:16 <mrmoku> root@om-gta02 /sys/devices/platform/gta02-pm-gps.0 $ 
Apr 17 16:03:23 <lindi-> and what's its path?
Apr 17 16:03:34 <mrmoku> root@om-gta02 /sys/devices/platform/gta02-pm-gps.0 $ cat power_on 
Apr 17 16:03:34 <mrmoku> 1
Apr 17 16:03:43 <lindi-> mrmoku: echo 0 > power_on; echo 1 > power_on?
Apr 17 16:04:06 <mrmoku> works without error
Apr 17 16:04:15 <lindi-> does hexdump /dev/ttySAC1 work now?
Apr 17 16:04:20 <mrmoku> shows nothing
Apr 17 16:04:54 <lindi-> mrmoku: ok, does energy consumption change between power_on == 0 and power_on == 1?
Apr 17 16:05:23 <mrmoku> moment
Apr 17 16:05:27 <lindi-> cat /sys/class/power_supply/battery/current_now (or om battery consumption)
Apr 17 16:07:41 <mrmoku> root@om-gta02 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/hdq.0/bq27000-battery.0/power_supply/battery $ cat current_now 
Apr 17 16:07:44 <mrmoku> -156375
Apr 17 16:07:46 <mrmoku> and it does not change
Apr 17 16:07:57 <lindi-> mrmoku: that shows that it is charging
Apr 17 16:08:05 <mrmoku> have to uncable?
Apr 17 16:08:22 <lindi-> mrmoku: you can disable charging with "om battery charger-limit 0"
Apr 17 16:08:37 <lindi-> that's  /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/chg_curlim I think
Apr 17 16:08:46 <mrmoku> lindi-: jama did not yet commit the recipe for it :/
Apr 17 16:09:14 <lindi-> mrmoku: and note that current_now has lags behind at least 15 seconds
Apr 17 16:09:19 <lindi-> mrmoku: you need to take multiple samples
Apr 17 16:09:28 <mrmoku> ok
Apr 17 16:10:07 <lindi-> om gps power 0; sleep 40; for i in `seq 1 40`; do om battery consumption; sleep 1; done; echo turning GPS on; om gps power 1; for i in `seq 1 40`; do om battery consumption; sleep 1; done; 
Apr 17 16:10:19 <lindi-> something like that
Apr 17 16:21:09 <mrmoku> lindi-: it goes up from 10875 to 32062
Apr 17 16:21:18 <mrmoku> so I guess something happened
Apr 17 16:21:36 <lindi-> mrmoku: 10 mA sounds way too low
Apr 17 16:21:59 <lindi-> mrmoku: ah yes. you disable battery charging but the system is still powering itself from usb
Apr 17 16:22:17 <lindi-> mrmoku: wrong option, my bad
Apr 17 16:22:34 <lindi-> mrmoku: you want "om usb charger-limit 0"
Apr 17 16:22:39 <mrmoku> lindi-: will retry without cable :)
Apr 17 16:22:50 <lindi-> mrmoku: which is /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim
Apr 17 16:23:14 <lindi-> mrmoku: that should work but make sure backlight stays constant
Apr 17 16:23:31 <mrmoku> ok
Apr 17 16:23:46 <mrmoku> running while changing the pampers :P
Apr 17 16:34:57 <mrmoku> lindi-: from 179437 to 233437
Apr 17 16:36:35 <lindi-> mrmoku: that looks about right, 54 mA
Apr 17 16:36:56 <lindi-> mrmoku: so power_on works
Apr 17 16:46:20 <JesusMcCloud> mrmoku, i did not get any special outputs when my sd was corrupted, only filesystem erros
Apr 17 17:18:08 <mrmoku> lindi-: sorry, had to run for dinner - family was waiting :/
Apr 17 17:25:09 <mrmoku> lindi-: I have the following in dmesg
Apr 17 17:25:11 <mrmoku> [    0.835000] s3c2440-uart.0: s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2440
Apr 17 17:25:14 <mrmoku> [    0.835000] s3c2440-uart.1: s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2440
Apr 17 17:25:17 <mrmoku> [    0.835000] s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440
Apr 17 18:14:32 <PaulFertser> LOL, libfso-glib bindings compilation requires ~300M, no wonder i couldn't do that without distcc help.
Apr 17 18:14:47 <PaulFertser> 300M of RAM
Apr 17 18:28:16 <mrmoku> PaulFertser: really?
Apr 17 18:28:18 <mrmoku> wow
Apr 17 18:29:57 <PaulFertser> mrmoku: yep, no idea why but freesmartphone-device.c takes like that
Apr 17 18:31:29 <mrmoku> PaulFertser: fun
Apr 17 19:02:19 <Martix_> where is some documentation about external GSM serial access through headphone jack debugging?
Apr 17 19:04:54 <Martix_> only mention about this is on http://wiki.openmoko.org/wiki/Gta02-core
Apr 17 19:04:59 <Martix_> and here: http://docs.openmoko.org/trac/ticket/2264
Apr 17 19:09:05 <PaulFertser> Martix_: well, what exactly do you need?
Apr 17 19:09:36 <PaulFertser> Martix_: there's a proprietary windows-only program to get additional debugging info from the modem via it.
Apr 17 19:09:47 <PaulFertser> Martix_: not freely distributable, it's under NDA.
Apr 17 19:09:58 <Martix_> only accurate information for my speak about Openmoko on Openmobility - www.openmobility.cz
Apr 17 19:10:15 <PaulFertser> Martix_: other than that, the debugging uart allows firmware flashing with "fluid".
Apr 17 19:10:20 <Martix_> oh, I see
Apr 17 19:10:35 <PaulFertser> So basically it's useless for normal (non OM-employees) users.
Apr 17 19:10:50 <lindi-> and prints crash messages
Apr 17 19:10:55 <PaulFertser> lindi-: indeed
Apr 17 19:11:07 <PaulFertser> But OM doesn't have full sources anyway, unfortunately.
Apr 17 19:11:11 <PaulFertser> So not much help.
Apr 17 19:12:06 <lindi-> waiting for osmocombb
Apr 17 19:12:44 <Martix_> I know about GSM flashing and I am looking forward on osmocombb :-)
Apr 17 19:12:45 <PaulFertser> lindi-: have you got a compatible device?
Apr 17 19:12:51 <PaulFertser> lindi-: ah :)
Apr 17 19:12:56 <PaulFertser> I got it :)
Apr 17 19:13:22 <lindi-> hoping fr will be
Apr 17 19:13:29 <Martix_> me too
Apr 17 19:14:01 <lindi-> not expecting calls but at least passive listening of network
Apr 17 19:14:12 * misc was wondering why belgium will invade france 
Apr 17 19:14:38 <misc> ( but maybe I am too tired to not recognize fr == freerunner and be != tld )
Apr 17 19:17:02 <Martix_> btw how much is openBTS usable?
Apr 17 19:18:57 <lindi-> Martix_: calls and sms work
Apr 17 19:19:07 <lindi-> not sure about gprs
Apr 17 19:21:45 <Martix_> nice, cells routing and some gateways (e.g. with SIP) as well?
Apr 17 19:24:01 <Martix_> I'm interested in deploying openBTS in local community network
Apr 17 19:24:39 <Martix_> I think, obtaining license from regulator will be hardest part
Apr 17 19:26:18 <misc> not sure, it was done for HAR and CCC
Apr 17 19:26:35 <PaulFertser> mrmoku: i'm not sure but the "+" issue seem to be not fixed for me.
Apr 17 19:26:51 <lindi-> Martix_: i don't think you can operate it just like that
Apr 17 19:34:43 <Artox> I just noticed that with a recent version of shr the modem of the freerunner does not seem to function. when it starts up I'm not prompted for a pin and the signal quality symbol in the top bar shows no connection. I thought maybe I need to upgrade my gsm firmware so I tried to check what version is inside my fr. Sadly  mdbus2 -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.GSM.Device.GetInfo
Apr 17 19:34:44 <Artox>   told me that the GSM resource was disabled. Can anyone tell me if this is a known problem? I noticed some messages in the mailinglist archives but there were no fixes, just messages that the problem solved itself
Apr 17 19:37:20 <Artox> my messages in fsodeviced.log are the same as the ones here: http://lists.shr-project.org/pipermail/shr-user/2010-April/004349.html
Apr 17 19:38:05 <Martix_> Artox: just restart frameworkd and phonefsod services
Apr 17 19:39:06 <Artox> so I will try that. I only tried restarting fsodeviced
Apr 17 19:41:53 <PaulFertser> lindi-: do you think depending on phone-utils library is a reasonable thing for emacs fso ui? Providing user with indication about chars used/left when composing an sms message can be easily done with http://git.shr-project.org/git/?p=libphone-utils.git;a=blob;f=src/phone-utils-gsm.c;h=cafec68897821879fa7806e9375680b988a9eada;hb=HEAD
Apr 17 19:43:29 <PaulFertser> I'm not sure if emacs supports dlopen
Apr 17 19:43:43 <Artox> nice thanks Martix_ it fixed it ^^
Apr 17 19:43:57 <Artox> but its bad that I have to restart the services so it works
Apr 17 19:50:55 <TAsn> <PaulFertser> lindi-: do you think depending on phone-utils library is a reasonable thing for emacs fso ui?
Apr 17 19:50:56 <TAsn> why not?
Apr 17 19:53:28 <TAsn> PaulFertser, btw, if you find for some reason choose not to use the lib, feel free to take whatever code you need, just let me know, and I'll dual-license that part to whatever license you want.
Apr 17 19:53:50 <PaulFertser> TAsn: i'm not sure but i do not know how to do that (dlopen a lib from elisp).
Apr 17 19:54:10 <TAsn> I don't do emacs, so believe me I have no idea as well.
Apr 17 19:54:46 <TAsn> it's probably possible though...
Apr 17 19:55:01 <PaulFertser> TAsn: and i guess if i just take your table and reimplement something lispy to get the same functionality, i won't be derivating strictly speaking.
Apr 17 19:55:35 <TAsn> PaulFertser, even if you do, I don't care, your got my permission.
Apr 17 19:55:44 <PaulFertser> TAsn: and i do not like number normalisation anyway, so i do not need that part ;)
Apr 17 19:55:48 <PaulFertser> TAsn: thanks! :D
Apr 17 19:55:52 <TAsn> np.
Apr 17 19:56:12 <TAsn> PaulFertser, what don't you like about the number normalization?
Apr 17 19:56:55 <PaulFertser> TAsn: the idea. I think every user should use a normalised number always :) There's a problem with stupid USA operators who doesn't follow standards though...
Apr 17 19:57:21 <Artox> force USA to follow standards xD
Apr 17 19:57:55 <Artox> many people would like that I think(except Americans)
Apr 17 19:59:15 <PaulFertser> Isn't including LGPL'd code in a GPL project legal?
Apr 17 19:59:30 <TAsn> No idea.
Apr 17 20:00:52 <mrmoku`> Weiss: ok, got it without that patch now :/
Apr 17 20:01:51 <mrmoku> Weiss: Apr 17 21:48:28 om-gta02 user.info kernel: [ 3055.860000] [drm] DAC-5: set mode 480x640 6
Apr 17 20:01:55 <mrmoku> Apr 17 21:58:49 om-gta02 user.err kernel: [ 3676.820000] [glamo-drm] Timeout!
Apr 17 20:01:59 <mrmoku> that's the start
Apr 17 20:02:25 <mrmoku> with more then ten fence kernel traces following
Apr 17 20:02:31 <mrmoku> s/then/than/
Apr 17 20:02:31 <apt> mrmoku meant: with more than ten fence kernel traces following
Apr 17 20:03:49 <mrmoku> Weiss: and after that SD is not accessible anymore
Apr 17 20:03:53 <mrmoku> have to pull the battery
Apr 17 20:05:07 <PaulFertser> mrmoku: or use watchdog :)
Apr 17 20:09:50 <mrmoku> PaulFertser: btw. I was verifying if + for SIM contacts works for me... before it went boom
Apr 17 20:10:24 <PaulFertser> mrmoku: ah :) Good thing i'm still on .29 without any tricks :)
Apr 17 20:11:13 <mrmoku> PaulFertser: there is some nice patch for the ar6000 that seems to make wifi more reliable
Apr 17 20:11:22 <mrmoku> it survives suspend even
Apr 17 20:12:45 <PaulFertser> mrmoku: in debug .29 it's reliable without this patch
Apr 17 20:12:53 <PaulFertser> mrmoku: and it does survive suspend :) 
Apr 17 20:13:56 <mrmoku> ohh
Apr 17 20:14:18 <mrmoku> did no know that... and IIRC for me it always disconnected on suspend
Apr 17 20:14:44 <mrmoku> PaulFertser: or do you mean it is still usable after suspend/resume?
Apr 17 20:14:47 <PaulFertser> mrmoku: it never did
Apr 17 20:14:54 <mrmoku> hmm
Apr 17 20:15:03 <PaulFertser> mrmoku: i mean it always disconnected, but wpa_supplicant automatically reconnects
Apr 17 20:15:19 <PaulFertser> :)
Apr 17 20:15:20 <mrmoku> it keeps connect with some patch from radekp
Apr 17 20:15:40 <mrmoku> you can have a ping running... suspend... resume... and it immediately continues to ping
Apr 17 20:15:45 <PaulFertser> mrmoku: are you sure you want that? And why? Reconnection takes ~1sec, why spend extra power in suspend?
Apr 17 20:16:01 <mrmoku> good question :)
Apr 17 20:16:18 <PaulFertser> mrmoku: there's no need for a patch to keep it powered, there's a sysfs part to enable S3C MCI device to "persist".
Apr 17 20:16:53 <mrmoku> I could argue that I turn it off if I want to save power... but probably my problems with wifi were more related to not correctly using wpa_supplicant then
Apr 17 20:26:50 <mrmoku> PaulFertser: ok, for me + is fixed
Apr 17 20:28:28 <PaulFertser> mrmoku: hmm, good.
Apr 17 20:28:43 <PaulFertser> mrmoku: probably i should have removed /tmp/fsogsmd/ first :)
Apr 17 20:29:26 <mrmoku> hmm... I did not remove it
Apr 17 20:30:09 <PaulFertser> mrmoku: looks like i compiled an old version for whatever reason :-O
Apr 17 20:30:43 <PaulFertser> Hm, no, it's not.
Apr 17 20:31:04 <mrmoku> 1:0.5.0+gitr21+e3f95d4a98f5ae1a99e2d3a0fa80d426faf86583-r2.0.4
Apr 17 20:31:09 <mrmoku> is what I have installed
Apr 17 20:31:49 <PaulFertser> That's one commit more but it's for mdbus2 anyway.
Apr 17 20:32:14 <PaulFertser> Wow, he implemented my idea about printing function signature, cool :D 
Apr 17 20:32:25 <mrmoku> yep, works nicely :)
Apr 17 20:34:42 <mrmoku> PaulFertser: I have them with + in /tmp/fsogsmd... and I have them with + in opimd after importing them with our SIM Manager
Apr 17 20:39:18 <PaulFertser> mrmoku: no idea why it doesn't work for me...
Apr 17 20:39:33 <[Rui]> is it predicted to be able to define a default or preffered phone for contacts?
Apr 17 20:39:34 <mrmoku> strange :/
Apr 17 20:40:01 <mrmoku> [Rui]: SHR phonestack?
Apr 17 20:40:10 <[Rui]> mrmoku: yeah
Apr 17 20:40:30 <mrmoku> [Rui]: it takes the first number it finds... until opimd offers something better :P
Apr 17 20:40:34 <[Rui]> mrmoku: now contacts is good enough so I can use it as a contacts app, I noticed this tiny problem with people with more than one...
Apr 17 20:40:49 <[Rui]> mrmoku: no, it displays an inwin asking me to choose which one to use
Apr 17 20:41:08 <mrmoku> [Rui]: I know.... thought you were talking about display... like in the list
Apr 17 20:41:08 <[Rui]> mrmoku: another issue is deleting messages...
Apr 17 20:41:28 <[Rui]> mrmoku: ah no... list could be better but it's ok for now :)
Apr 17 20:41:53 <[Rui]> I actually think you only really need to show a photo and a name, in the list
Apr 17 20:45:46 <[Rui]> mrmoku: I went to New York a couple of weeks ago and the Freerunner was the only phone I had that could operate there, so I put my work SIM in it.
Apr 17 20:45:51 <TAsn> [Rui], we want to redesign the whole thing.
Apr 17 20:45:55 <[Rui]> trouble is... I received a lot of messages...
Apr 17 20:46:12 <TAsn> (messages appliaction)
Apr 17 20:46:34 <[Rui]> TAsn: I understand. anyone knows if I can safely delete the messages from one table in the sqlite db, or if I need to take more care than that?
Apr 17 20:46:53 <[Rui]> I'd like to keep some, so just removing the file isn't a good option :)
Apr 17 20:47:04 <[Rui]> but congrats, it's way faster loading so many messages...
Apr 17 20:47:06 <TAsn> why don't you remove them from the GUI?
Apr 17 20:47:15 <TAsn> *using the GUI
Apr 17 20:47:28 <[Rui]> TAsn: let me see if I can count them...
Apr 17 20:47:35 <[Rui]> about 8 per day, 8 days...
Apr 17 20:47:36 <pespin> people, you should consider cleaning a bit the dir http://build.shr-project.org/shr-unstable/images/om-gta02/ :P
Apr 17 20:47:47 <TAsn> [Rui], as for structure of the database
Apr 17 20:47:52 <TAsn> tables:
Apr 17 20:48:04 <TAsn> messages: stores original ids
Apr 17 20:48:14 <TAsn> messages_TYPE
Apr 17 20:48:19 <TAsn> stores values of type TYPE
Apr 17 20:48:28 <PaulFertser> mrmoku: after deleting contents in /tmp it works for me too. I usually get warnings on start: [WARN]  fsogsmd : Can't write-open /tmp/fsogsmd/pb/250997500793162/UD_1_3/001: File exists
Apr 17 20:48:44 <TAsn> with two ids, messages_TYPE id and messages id
Apr 17 20:48:56 <TAsn> for deleting messages, remove the rows from messages
Apr 17 20:49:00 <TAsn> and remove from messages_*
Apr 17 20:49:04 <TAsn> all the messages with that type
Apr 17 20:49:10 <TAsn> *id
Apr 17 20:49:11 <mrmoku> PaulFertser: I have seen those warnings too... no idea why it worked for me without deleting then
Apr 17 20:49:15 <TAsn> all the rows with that message id
Apr 17 20:49:21 <TAsn> but I really think it's better to use the GUI.
Apr 17 20:49:22 <mrmoku> have seen them in the past... did not check now
Apr 17 20:49:43 <[Rui]> TAsn: it's quite some dozens of them... 
Apr 17 20:50:03 <TAsn> [Rui], so at least use opimd-utils
Apr 17 20:50:09 <TAsn> if you want "faster typing"
Apr 17 20:50:17 <TAsn> but messing with the database is always a bad idea :P
Apr 17 20:50:38 <TAsn> But again, just remove the rows you want from messages and the corresponding rows from messages_*
Apr 17 20:50:41 <TAsn> and you'll be just fine.
Apr 17 20:50:45 <playya_> hmm. maybe is should change the notify to changed in frameworkd, too.
Apr 17 20:50:56 <playya_> but this would break some apps
Apr 17 20:51:34 <Weiss> mrmoku: ok... so something's up with the fencing..
Apr 17 20:53:21 <[Rui]> ok, 85 messages, total
Apr 17 20:53:50 <[Rui]> TAsn: I guess I'll use opimd-cli unless you guys know anything against it
Apr 17 20:53:58 <TAsn> no, should be just fine.
Apr 17 20:54:02 <[Rui]> with over 90% to delete...
Apr 17 20:54:08 <TAsn> :)
Apr 17 20:54:58 <Weiss> mrmoku: ok, I can reproduce it at least as far as crashing the graphics.
Apr 17 20:55:31 <[Rui]> when I use opmid-cli messages delete ID... what is id?
Apr 17 20:55:48 <TAsn> EntryId
Apr 17 20:55:49 <[Rui]> EntryId: ?
Apr 17 20:55:50 <[Rui]> ok
Apr 17 20:55:53 <TAsn> yeah.
Apr 17 21:05:09 <[Rui]> grep -A 11 LPM sms.txt   | awk '/^  EntryId:/ { print $2 }'
Apr 17 21:06:08 <[Rui]> grep -A 11 LPM sms.txt   | awk '/^  EntryId:/ { print $2 }' | while read ID ; do opimd-cli messages delete $ID ; done
Apr 17 21:07:10 <Weiss> mrmoku: ok.. seems to be a problem with modesetting, not fencing
Apr 17 21:10:49 <TAsn> [Rui], :P
Apr 17 21:10:58 <[Rui]> done!
Apr 17 21:11:33 <[Rui]> hms... I knew 45 was a bit too few...
Apr 17 21:11:42 <[Rui]> don't know why but some have escaped.
Apr 17 21:11:48 <TAsn> Kill them.
Apr 17 21:12:55 <[Rui]> shit, some of them don't have entryid
Apr 17 21:13:04 <TAsn> Huh? really?
Apr 17 21:13:12 <TAsn> Not possible.
Apr 17 21:13:15 <wookey_> my rfcomm conenction says rfcomm0: 10:00:E8:AB:93:AB channel 1 closed 
Apr 17 21:13:17 <TAsn> It's a calculated field, not a real field.
Apr 17 21:13:24 <TAsn> [Rui], WAIT
Apr 17 21:13:29 <TAsn> whatever you do, please backup your db
Apr 17 21:13:36 <TAsn> so I will be able to beg for it
Apr 17 21:13:37 <wookey_> how do I get it to say 'clean', which I beleive is presrequisite for talking down /dev/rfcomm0?
Apr 17 21:13:43 <TAsn> at a later time to find the bug.
Apr 17 21:13:58 <TAsn> [Rui], do they have a Path variable?
Apr 17 21:13:59 <mrmoku> Weiss: good thing you can reproduce :D
Apr 17 21:14:56 <TAsn> [Rui], so that field message doesn't have 'Path' as well?
Apr 17 21:15:06 <[Rui]> TAsn: they have, but it appears they do have entryid, it's only coming up a few lines before rather than 11 lines after
Apr 17 21:15:25 <TAsn> That's fine.
Apr 17 21:15:32 <TAsn> opimd-utils doesn't sort the fields
Apr 17 21:15:40 <TAsn> it's random 
Apr 17 21:15:57 <[Rui]> http://pastebin.com/WZRFmBTz
Apr 17 21:16:02 <[Rui]> ah...
Apr 17 21:16:13 <[Rui]> I thought it did, because so many of them came up so nicely...
Apr 17 21:16:25 <TAsn> :P
Apr 17 21:16:46 <TAsn> just replace all \n's with ''
Apr 17 21:16:48 <TAsn> and then
Apr 17 21:16:59 <TAsn> replace "result nr *:" with \n
Apr 17 21:17:04 <TAsn> so you'll have everything in one line
Apr 17 21:17:18 <TAsn> so you'll be able to easily extract EntryId according to whatever parameter.
Apr 17 21:17:27 <TAsn> Btw, if you can do it automatically
Apr 17 21:17:28 <TAsn> just use
Apr 17 21:17:36 <[Rui]> so now it's grep -B 2 LPM :)
Apr 17 21:17:36 <TAsn> query with parameters
Apr 17 21:17:40 <TAsn> i.e
Apr 17 21:18:06 <TAsn> opimd-cli c query \$phonenumber +95423424
Apr 17 21:18:11 <TAsn> or whatever.
Apr 17 21:18:27 <Weiss> mrmoku: well... I can reproduce what I think is a version of "mobi phil"'s crash, which sounds very similar to yours..
Apr 17 21:20:08 <PaulFertser> mrmoku: do you by any chance know if oeventsd can notify me of new messages?
Apr 17 21:21:01 <TAsn> PaulFertser, what kind of notification do you need?
Apr 17 21:21:04 <TAsn> And yeah, it can do it.
Apr 17 21:21:08 <[Rui]> TAsn: well, they're all gone now, but nice tip, thanks.
Apr 17 21:21:10 <PaulFertser> TAsn: play a tone
Apr 17 21:21:25 <TAsn> PaulFertser, the shr rules.yaml plays a tone on an incoming message
Apr 17 21:21:29 <TAsn> and I think the default one as well.
Apr 17 21:21:35 <TAsn> [Rui], np :)
Apr 17 21:21:40 <PaulFertser> TAsn: UnreadMessagesTrigger ?
Apr 17 21:22:03 <TAsn>     trigger: IncomingMessage()
Apr 17 21:22:04 <TAsn>     actions: MessageTone(play)
Apr 17 21:22:14 <[Rui]> TAsn: it's some service the previous owner subscribed that I have no idea how to unsubscribe.
Apr 17 21:22:33 <TAsn> contact your provider
Apr 17 21:22:41 <PaulFertser> TAsn: that's for IncomingStoredMessage of org.freesmartphone.GSM.SIM
Apr 17 21:23:16 <TAsn> PaulFertser, It's for incoming messages, if you are using fsogsmd (which you are) you need to "fix" oevents to work with fsogsmd
Apr 17 21:23:45 <TAsn> The framework only works well with fso* that have been officially released/adopted by SHR
Apr 17 21:23:58 <TAsn> with the one exception of opimd
Apr 17 21:24:03 <TAsn> that works well with both fsogsmd and ogsmd
Apr 17 21:24:22 <PaulFertser> TAsn: yep, i see, fsogsmd doesn't emit that signal. But anyway, why do you count on non-opimd signal?
Apr 17 21:24:38 <TAsn> in oevents?
Apr 17 21:24:41 <TAsn> Stupidity
Apr 17 21:24:44 <TAsn> :)
Apr 17 21:24:51 <TAsn> j/k, it oevents
Apr 17 21:24:57 <TAsn> it should work without opimd
Apr 17 21:25:02 <TAsn> as people may not want to use opimd.
Apr 17 21:25:12 <TAsn> This is a design feature (not by me btw)
Apr 17 21:25:39 <PaulFertser> Ok, the signal is called IncomingMessage now (and not IncomingStoredMessage)
Apr 17 21:25:40 <mrmoku> PaulFertser: fsogsmd emits an IncomingTextMessage
Apr 17 21:25:49 <[Rui]> TAsn: since it's the company phone, I'm not the customer
Apr 17 21:25:57 <PaulFertser> mrmoku: i'd like to be notified when the first part comes.
Apr 17 21:26:15 <TAsn> PaulFertser, doesn't exists in fsogsmd
Apr 17 21:26:17 <mrmoku> PaulFertser: ok
Apr 17 21:26:23 <PaulFertser> TAsn: what doesn't exist?
Apr 17 21:26:29 <PaulFertser> IncomingMessage does
Apr 17 21:26:30 <TAsn> <PaulFertser> mrmoku: i'd like to be notified when the first part comes.
Apr 17 21:26:40 <TAsn> it doesn't exist in fsogsmd
Apr 17 21:26:43 <TAsn> (from what I remember)
Apr 17 21:26:52 <TAsn> You get the whole message or nothing at all.
Apr 17 21:27:06 <PaulFertser> Description: Sent, when a new message has been received and stored on the SIM card.
Apr 17 21:27:12 <TAsn> mickey|sports, can you confirm? (fsogsmd <TAsn> You get the whole message or nothing at all.)
Apr 17 21:27:16 <PaulFertser> TAsn: so you're wrong :P
Apr 17 21:27:21 <TAsn> PaulFertser, it doesn't exist in fsogsmd
Apr 17 21:27:23 <TAsn> ...
Apr 17 21:27:39 <TAsn> mickey|sports replaced it with IncomingTextMessage
Apr 17 21:27:53 <TAsn> Which includes the whole message.
Apr 17 21:27:59 <TAsn> which reminds me.
Apr 17 21:28:23 <PaulFertser> TAsn: hm, it exists in introspection but not used anyhow it seems :(
Apr 17 21:28:42 <PaulFertser> But i should know when a message comes even if partial.
Apr 17 21:29:01 <Martix_> Weiss: hello, how is it going with Glamo? AFAIK KMS, GEM, DRM/DRI2, EXA is working, but OpenGL ES and properly H263 video decode is missing? am I right?
Apr 17 21:29:20 <TAsn> PaulFertser, I agree.
Apr 17 21:29:25 <TAsn> PaulFertser, That's exactly what I said.
Apr 17 21:29:32 <PaulFertser> TAsn: or not _handleIncomingSmsReport
Apr 17 21:29:33 <TAsn> mickey is the man to discuss about it with.
Apr 17 21:29:50 <PaulFertser> TAsn: the code is there and it reports Oh...
Apr 17 21:29:54 <PaulFertser> I'm wrong again
Apr 17 21:29:57 <TAsn> :)
Apr 17 21:30:01 <PaulFertser> incoming_message_report
Apr 17 21:30:22 <TAsn> :)
Apr 17 21:30:49 <[Rui]> next step, joining all my vcfs into one file and trying out pisi
Apr 17 21:31:33 <Weiss> Martix_: yep, exactly right.. working on getting it all working nicely in 2.6.32 and stabilising xrandr at the moment
Apr 17 21:32:11 <Martix_> Weiss: thanks for your developing effort :-)
Apr 17 21:32:38 <Weiss> Martix_: thanks for the thanks :)... I'm crazily busy with daywork these days, and it's hard to find time.. but I still want to play with the 3D engine..
Apr 17 21:33:13 <TAsn> [Rui], :)
Apr 17 21:42:19 * Weiss wonders if volcanic ash caused recent KMS difficulties
Apr 17 21:44:11 <TAsn> :P
Apr 17 21:44:16 <Martix_> Weiss: could new DRI based implementation of H263 decoding increase video performance more than old MPlayer hack? or is it only about making proper implementation?
Apr 17 21:45:24 <Weiss> Martix_: only about a proper implementation which can cooperate with other accelerated programs, really. typically there are (slight) overheads associated with DRI compared to "just bossing Glamo around".. (although, bear in mind that the GPU now goes twice as fast thanks to that FIFO tweak)
Apr 17 21:45:58 <Martix_> ok :-)
Apr 17 21:46:53 * Weiss would definitely be interested in video decoding benchmarks before and after that tweak
Apr 17 21:50:07 <[Rui]> let's see how it'll work with 218 contacts
Apr 17 21:53:12 <PaulFertser> TAsn: if i restart only fsogsmd, will opimd still properly listen to its signals?
Apr 17 21:53:21 <TAsn> Yes.
Apr 17 21:53:38 <TAsn> dbus signals are dispatched from the dbus daemon
Apr 17 21:53:43 <TAsn> to all the clients
Apr 17 21:53:51 <TAsn> (even those who don't request them)
Apr 17 21:54:05 <TAsn> and it's the client's responsibility to filter them.
Apr 17 21:54:38 <TAsn> For instance, mdbus -l doesn't ask for all the signals, on the contrary, it "registers" to none, and listens to the signal queue.
Apr 17 21:54:46 <PaulFertser> TAsn: i'm trying to understand why sometimes receiving messages works and sometimes they never get in opimd...
Apr 17 21:54:52 <TAsn> Or something similar (but the way I described also works)
Apr 17 21:55:02 <TAsn> PaulFertser, are the signals dispatched?
Apr 17 21:55:11 <TAsn> what do the logs say?
Apr 17 21:55:16 <TAsn> (that's all there is to it)
Apr 17 21:55:16 <PaulFertser> TAsn: i need to try with -l to tell
Apr 17 21:55:21 <TAsn> please do.
Apr 17 21:55:36 <TAsn> Btw, concerning fsogsmd <-> opimd
Apr 17 21:55:41 <TAsn> I wrote it without proper testing.
Apr 17 21:55:49 <TAsn> I don't use fsogsmd and just added it for mrmoku :P
Apr 17 21:55:54 <TAsn> I only tested for regressions
Apr 17 21:55:58 <TAsn> nothing more than that.
Apr 17 21:56:19 <PaulFertser> TAsn: [SIGNAL] org.freesmartphone.GSM.SMS.IncomingTextMessage  /org/freesmartphone/GSM/Device  :1.144
Apr 17 21:56:19 <TAsn> So it may be buggy, especially in the part that parses the date :)
Apr 17 21:56:27 <lindi-> PaulFertser: can you take a look at http://docs.openmoko.org/trac/ticket/2309#comment:7 ?
Apr 17 21:56:29 <TAsn> PaulFertser, and nothing in opimd?
Apr 17 21:56:41 <TAsn> what date is sent?
Apr 17 21:56:42 <PaulFertser> TAsn: with loglevel=INFO, nothing
Apr 17 21:56:49 <PaulFertser> TAsn: ( "InternetSMS", "10/04/18,01:55:55+16", "test" )
Apr 17 21:56:54 <PaulFertser> lindi-: sure
Apr 17 21:57:01 <[Rui]> seems to be handling 'em contacts just fine! :)
Apr 17 21:57:03 <TAsn> ok, let me do a quick check.
Apr 17 21:57:09 <lindi-> PaulFertser: could some sort of RTC bug cause this behavior?
Apr 17 21:57:11 <TAsn> sec.
Apr 17 21:57:41 <PaulFertser> lindi-: wow, interesting pattern :-O
Apr 17 22:00:09 <TAsn> PaulFertser, an unrelated fix
Apr 17 22:00:34 <CIA-75> freesmartphone.org: 03tom 07framework * rfdc9e893f3ed 10/framework/subsystems/opimd/pimd_messages.py: Fixed a major bug with fsogsmd timestamp parsing with west to greenwich timezones. (i.e "negative" timezones).
Apr 17 22:00:34 <CIA-75> freesmartphone.org: 03tom 07framework * r6c9f2db3856c 10/framework/subsystems/ (9 files in 4 dirs): Merge branch 'master' of ssh://git.freesmartphone.org/framework
Apr 17 22:01:59 <PaulFertser> lindi-: i'm not sure it tries to access pcf50633 before at least restoring gpio states...
Apr 17 22:03:00 <TAsn> PaulFertser, ok, just checked
Apr 17 22:03:03 <TAsn> parsing should work
Apr 17 22:03:12 <PaulFertser> TAsn: cool, thanks.
Apr 17 22:03:15 <TAsn> PaulFertser, so no idea what's wrong, are you sure it's not in opimd?
Apr 17 22:03:30 <TAsn> I mean, are you sure the signal is emitted?
Apr 17 22:03:43 <PaulFertser> TAsn: you saw the signal
Apr 17 22:04:01 <PaulFertser> opimd-cli m query doesn't show the message
Apr 17 22:04:09 <TAsn> :(
Apr 17 22:05:49 <PaulFertser> TAsn: i have frameworkd started with -l, so i can try to gather more info but i've no idea how.
Apr 17 22:06:04 <TAsn> frameworkd? you mean mdbus?
Apr 17 22:06:04 <lindi-> PaulFertser: i'll set my clock to 2010-04-15 and hope this happens again
Apr 17 22:06:13 <PaulFertser> TAsn: no, frameworkd
Apr 17 22:06:20 <TAsn> what's -l there?
Apr 17 22:06:27 <PaulFertser> TAsn: uber-cool debugging interface
Apr 17 22:06:45 <TAsn> as you may have guessed
Apr 17 22:06:48 <TAsn> no idea :P
Apr 17 22:06:56 <TAsn> (no idea what to do with it)
Apr 17 22:07:00 <PaulFertser> TAsn: you know some python, come on :)
Apr 17 22:07:16 <TAsn> Yeah, but no idea what that is.
Apr 17 22:07:31 <PaulFertser> TAsn: it allows telnet connection and then i get python prompt and framework object and so on.
Apr 17 22:07:39 <TAsn> PaulFertser, sweet.
Apr 17 22:07:49 <TAsn> anyhow, I do 0 logic
Apr 17 22:08:06 <TAsn> when inserting from fsogsmd
Apr 17 22:08:13 <TAsn> I can only suspect one thing.
Apr 17 22:08:20 <TAsn> s/can //
Apr 17 22:08:36 <TAsn> Maybe (though I don't think so)
Apr 17 22:08:49 <TAsn> phone-utils crashes when getting "InternetSMS"
Apr 17 22:08:58 <TAsn> Though I really remember testing that specifically
Apr 17 22:09:18 <TAsn> (sms texts instead of numbers)
Apr 17 22:10:45 <TAsn> And that's not debug-able from python.
Apr 17 22:11:04 <TAsn> (from frameworkd python that is)
Apr 17 22:11:07 <TAsn> but it's easy to check.
Apr 17 22:11:24 <PaulFertser> TAsn: btw, in case you do not know yet, mdbus2 is really cool ;)
Apr 17 22:11:33 <TAsn> I do know it.
Apr 17 22:11:36 <TAsn> :)
Apr 17 22:11:40 <TAsn> Though it's lacking
Apr 17 22:11:40 <PaulFertser> TAsn: after restarting frameworkd it worked ok.
Apr 17 22:11:42 <TAsn> a{sv}
Apr 17 22:11:43 <TAsn> :|
Apr 17 22:11:47 <TAsn> PaulFertser, odd.
Apr 17 22:11:55 <TAsn> Oh, could happen
Apr 17 22:12:03 <TAsn> if frameworkd was started when fsogsmd was off
Apr 17 22:12:19 <TAsn> as register_signal might check for availability (although it doesn't have to)
Apr 17 22:12:23 <TAsn> though I really doubt that.
Apr 17 22:13:27 <TAsn> >>> phoneutils.normalize_number("InternetSMS")
Apr 17 22:13:27 <TAsn> 'InternetSMS'
Apr 17 22:13:32 <TAsn> ok, it's just fine :)
Apr 17 22:13:56 <TAsn> phone-utils: 1, InternetSMS: 0
Apr 17 22:17:27 <Weiss> mrmoku: was the display blanking/unblanking, switching mode (VGA/QVGA), X starting/exiting?
Apr 17 22:17:46 <Weiss> mrmoku: the common factor in all of these things is the mode setting..
Apr 17 22:19:27 <PaulFertser> TAsn: ok, it's easy, i have it working now, and i restart fsogsmd now to test again.
Apr 17 22:19:42 <TAsn> PaulFertser, I think it should only be broken
Apr 17 22:19:47 <TAsn> when you start frameworkd
Apr 17 22:19:49 <TAsn> while fsogsmd is off
Apr 17 22:22:55 <[Rui]> so how do I put a contact image?
Apr 17 22:23:10 <TAsn> [Rui], easily...
Apr 17 22:23:14 <TAsn> :)
Apr 17 22:23:21 <TAsn> Open the contact
Apr 17 22:23:24 <TAsn> Add new field
Apr 17 22:23:25 <TAsn> Photo
Apr 17 22:23:30 <[Rui]> path to a file?
Apr 17 22:23:57 <[Rui]> opening one contact is now a bit slow (with these > 200 contacts)...
Apr 17 22:24:13 <TAsn> [Rui], shouldn't be.
Apr 17 22:24:19 <TAsn> Something else is probably wrong.
Apr 17 22:24:33 <TAsn> Well, it can be.
Apr 17 22:24:33 <[Rui]> ah... file browser...
Apr 17 22:24:35 <TAsn> but sholudn't :P
Apr 17 22:24:38 <TAsn> [Rui], yeah :)
Apr 17 22:24:45 <TAsn> [Rui], without image preview though ;(
Apr 17 22:25:01 <TAsn> Will add it when I have time.
Apr 17 22:25:23 <[Rui]> nice... those paths with links... to bad anchors look real bad in the default theme
Apr 17 22:28:10 <TAsn> [Rui], I'll also change it to show something else instead of the path
Apr 17 22:28:20 <TAsn> actually, I want to sort all of that page
Apr 17 22:28:25 <TAsn> to have some fields in predefined places
Apr 17 22:28:30 <TAsn> (photo being the photo itself)
Apr 17 22:28:30 <[Rui]> TAsn: it's using too many buttons
Apr 17 22:28:35 <TAsn> what is?
Apr 17 22:28:40 <[Rui]> TAsn: the file browser
Apr 17 22:28:45 <mrmoku> Weiss: no switching of mode
Apr 17 22:28:47 <TAsn> scap please.
Apr 17 22:29:11 <[Rui]> TAsn: it's just as you see it, no need for scap, I think. but so many buttons just wast valuable screen area
Apr 17 22:29:34 <TAsn> sec, opening.
Apr 17 22:30:04 <mrmoku> Weiss: ahh... you mean blanking/unblanking is mode switching too?
Apr 17 22:30:38 <TAsn> [Rui], talking about up/home?
Apr 17 22:30:40 <Weiss> mrmoku: in this context, it's potentially relevant..
Apr 17 22:30:42 <TAsn> Hey are essential.
Apr 17 22:30:58 <Weiss> mrmoku: something seems to be up with the mode setting in edge cases
Apr 17 22:31:03 <TAsn> The only thing I considered removing is the house/name
Apr 17 22:31:09 <TAsn> photo/name
Apr 17 22:31:10 <mrmoku> Weiss: if there is something I can do to debug... I can reproduce the 'WSOD on unblank' reliably
Apr 17 22:31:23 <TAsn> but those are essential for people like me who are more forgetful than a goldfish
Apr 17 22:31:25 <Weiss> hmm.. how?
Apr 17 22:31:47 <mrmoku> Weiss: use FSO API to turn off backlight
Apr 17 22:32:00 <TAsn> [Rui], but I'm totally aware the screen is too small.
Apr 17 22:32:00 <mrmoku> wait for three mins... and turn it back on
Apr 17 22:32:11 <Weiss> mrmoku: ah.. the Xscrensaver thing?
Apr 17 22:32:31 <mrmoku> Weiss: does not matter if via XScreensaver or via the FSO API
Apr 17 22:32:40 <mrmoku> probably they do the same in the end
Apr 17 22:32:43 <mrmoku> (kernel wise)
Apr 17 22:32:58 <[Rui]> TAsn: maybe you should just use a big inwin for navigation
Apr 17 22:33:00 <Weiss> perhaps... there are KMS DPMS hooks which are quite tricky to use
Apr 17 22:33:29 <TAsn> [Rui], big inwin for navigation?
Apr 17 22:33:30 <mrmoku> Weiss: it is like in the beginning when I got my FR.... back then I had WSOD after resume when suspended for something between 2 and 3 mins
Apr 17 22:33:31 <TAsn> what do you mean?
Apr 17 22:33:40 <mrmoku> just back then it did never recover :P
Apr 17 22:34:12 <mrmoku> now it recovers if I turn off backlight and re-enable it after some secs
Apr 17 22:34:37 * Weiss thinks all the current KMS problems are manifestations of the same thing
Apr 17 22:34:39 <[Rui]> TAsn: yeah.
Apr 17 22:34:58 * mrmoku hopes Weiss is right and will find the real cause of trouble :)
Apr 17 22:35:07 <TAsn> Are you talking about embedding the file browser in an inwin?
Apr 17 22:35:19 <[Rui]> TAsn: yes
Apr 17 22:35:31 <TAsn> That's not what I wanted though.
Apr 17 22:35:38 <[Rui]> is the image stored inside the DB or just it's path?
Apr 17 22:35:50 <TAsn> I could have just done what I did in the first place.
Apr 17 22:35:52 <[Rui]> TAsn: I got that, I'm pretty certain you know about inwins :)
Apr 17 22:35:54 <TAsn> which is replacing the whole screen.
Apr 17 22:36:10 <[Rui]> TAsn: but in small screens it's frequently better to replace the whole screen
Apr 17 22:36:10 <TAsn> but I like seeing the name/photo
Apr 17 22:36:19 <TAsn> as my memory is bad :P
Apr 17 22:36:27 <TAsn> And I tend to forget the contact I'm editing :P
Apr 17 22:36:38 <TAsn> [Rui], just the path is stored.
Apr 17 22:36:49 <[Rui]> TAsn: yeah, it's a bit strange to me how they can show so much better web pages and other stuff on phones with less resolution
Apr 17 22:37:05 <[Rui]> feels like something's being wasted
Apr 17 22:37:09 <mrmoku> Weiss: good luck... I'm off to bed
Apr 17 22:37:10 <mrmoku> gnight all
Apr 17 22:37:12 <Weiss> thanks :D
Apr 17 22:37:27 <TAsn> mrmoku|away, night.
Apr 17 22:38:33 <[Rui]> mrmoku|away: night!
Apr 17 22:48:26 <[Rui]> hell yeah! pictures show up in list and when contact calls!
Apr 17 23:03:06 <TAsn> AMAZING!
Apr 17 23:03:07 <TAsn> :P
Apr 17 23:03:20 <TAsn> I wouldn't have guessed! :P
Apr 17 23:03:53 <TAsn> The main problem though, is that the FR doesn't have a camera
Apr 17 23:04:04 <TAsn> and I don't have a facebook account
Apr 17 23:04:12 <TAsn> so obtaining images is pretty annoying :P
Apr 17 23:07:27 <TAsn> [Rui], Have fun.
Apr 17 23:07:28 <TAsn> night all.
Apr 17 23:07:45 <[Rui]> TAsn: gnight!
Apr 17 23:08:59 <TAsn> Btw, I don't remember where I read that, but iirc it's true: finger-scrolling will soon be committed into webkit-efl :)
Apr 17 23:09:14 <TAsn> So finger scrolling will be nicer with ventura than it is now.
Apr 17 23:12:36 <sicu> [Rui]: still here?
Apr 17 23:12:51 <[Rui]> sicu: yeah!
Apr 17 23:12:54 <[Rui]> sicu: hi
Apr 17 23:13:38 <sicu> [Rui]: hey =] were you successful in getting pisi to import a contact with multiple phonenumbers into opim?
Apr 17 23:13:56 <[Rui]> sicu: yeah
Apr 17 23:14:11 <[Rui]> sicu: you're the pisi author?
Apr 17 23:14:27 <sicu> no no, but i'm having issues with it
Apr 17 23:14:34 <[Rui]> ah
Apr 17 23:14:43 <sicu> i can't get it to import multiple phonenumbers
Apr 17 23:15:10 <[Rui]> the story wasn't so nice on exporting back, though
Apr 17 23:16:53 <sicu> could you pastebin a multi-number-contact from your big vcf file pls, replacing personal numbers with random numbers ofcourse
Apr 17 23:17:33 <sicu> and any other sensitive data (name?)
Apr 17 23:17:54 <sicu> if you have time that is ... just want to compare to mine and see where it's going wrong
Apr 17 23:18:21 <[Rui]> well, I thought I did, but in fact the contacts are lost...
Apr 17 23:18:29 <[Rui]> only one number (but no errors, though)
Apr 17 23:18:43 <sicu> yeh,same here ... only one number, and no errors
Apr 17 23:32:09 <[Rui]> well, I'm off to bed
Apr 17 23:32:25 <[Rui]> sicu: even though it didn't bring all contacts in, I'm way happier tonight :)
Apr 17 23:36:05 <sicu> [Rui]: it brings them all in for me, but only one number per contact though
Apr 17 23:36:24 <sicu> [Rui]: but too tired to mess around with it now ... nn =]
Apr 17 23:37:00 <[Rui]> sicu: hey, I have been living with an empty contact list (save for the few that called me or I called which I added individually).
Apr 17 23:37:14 <[Rui]> sicu: I've got over 200 contacts, so I didn't want to do this every now and then :)
Apr 17 23:37:20 <[Rui]> bby!
Apr 18 00:02:50 <pabs3> could someone push intone from shr-u to shr-t? intone is currently completely broken in shr-t and the shr-u version fixes it: http://www.mail-archive.com/community@lists.openmoko.org/msg59011.html
Apr 18 00:51:02 <pabs3> so, which part of the stack causes WiFi on SHR-t to suck? hardware, firmware, kernel driver, connman or mokoconnect?
**** ENDING LOGGING AT Sun Apr 18 02:59:57 2010