**** BEGIN LOGGING AT Thu Jan 13 02:59:59 2011
Jan 13 06:03:18 <denkenz> Jeevaka: Getting a sigsegv in phonesim after your latest changes
Jan 13 06:03:25 <denkenz> Program received signal SIGSEGV, Segmentation fault.
Jan 13 06:03:26 <denkenz> 0x0000000000439392 in HardwareManipulator::getSimAppsNameList (
Jan 13 06:03:26 <denkenz>     this=<value optimized out>) at src/hardwaremanipulator.cpp:316
Jan 13 06:03:27 <denkenz> 316	        nameList.append( simApps.at( i )->getName() );
Jan 13 06:03:27 <denkenz> (gdb) bt
Jan 13 06:03:27 <denkenz> #0  0x0000000000439392 in HardwareManipulator::getSimAppsNameList (
Jan 13 06:03:28 <denkenz>     this=<value optimized out>) at src/hardwaremanipulator.cpp:316
Jan 13 06:03:28 <denkenz> #1  0x000000000040d4cd in ControlWidget::handleNewApp (this=0x710140)
Jan 13 06:03:29 <denkenz>     at src/control.cpp:460
Jan 13 06:03:29 <denkenz> #2  0x0000000000428e99 in SimRules::destruct (this=0x70f2e0)
Jan 13 06:03:30 <denkenz>     at src/phonesim.cpp:855
Jan 13 06:03:30 <denkenz> #3  0x000000000047c9bc in SimRules::qt_metacall (this=0x70f2e0, 
Jan 13 06:03:30 <denkenz>     _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7fffffffcfd0)
Jan 13 06:03:31 <denkenz>     at src/moc_phonesim.cpp:320
Jan 13 07:27:34 <Jeevaka> denkenz: ping
Jan 13 07:38:55 <Jeevaka> denkenz: I took the latest phonesim and I dont see any sigsegv. may I know the case in which it is triggering
Jan 13 07:43:25 <akiniemi> denkenz: Get your kid an iPod touch if you're worried about accidental emergency calls :)
Jan 13 09:48:24 <Jeevaka> kvehmanen: ping
Jan 13 11:29:01 <kvehmanen> Jeevaka: pong
Jan 13 12:03:19 <Jeevaka> kvehmanen: about the CTM
Jan 13 12:04:31 <Jeevaka> kvehmanen: does your last mail state that separate internal api needed like ofono_voicecall_tty_notify or not?
Jan 13 12:06:35 <kvehmanen> Jeevaka: not sure about the internal API
Jan 13 12:07:26 <kvehmanen> Jeevaka: I mean I was just stating that a call may have CTM disabled even if CTM was attempted
Jan 13 12:07:40 <kvehmanen> Jeevaka: and the UI needs a way to observe this
Jan 13 12:10:10 <Jeevaka> ok, internal api is for informing the core that the MO originated TTY call is connected as normal voice call on the remote side
Jan 13 12:10:55 <kvehmanen> Jeevaka: yep, so in that sense yes, the internal API is needed
Jan 13 12:11:07 <Jeevaka> in infineon case, if the remote side accpts the TTY call as TTY call "CTM CALL" notification will be received
Jan 13 12:12:18 <kvehmanen> Jeevaka: yep, I'm still waiting for someone to confirm whether that maps to the 24.008 bearer capability flag
Jan 13 12:12:55 <Jeevaka> yes, it maps to the bearer capability flag
Jan 13 12:13:14 <kvehmanen> Jeevaka: aa, ok, thanks, so then it definitely makes sense and your patches seem right to me
Jan 13 12:14:07 <Jeevaka> ok, I need some information on the conference call you are facing with ifx
Jan 13 12:16:43 <Jeevaka> if you like, I can test the same use case and provide you with the logs
Jan 13 12:35:18 <kvehmanen> Jeevaka: ok, I'll send you a mail
Jan 13 12:39:37 <Jeevaka> ok
Jan 13 12:57:04 <kvehmanen> Jeevaka: just sent the mail
Jan 13 12:58:39 <akiniemi> pessi: pong
Jan 13 13:02:03 * kvehmanen grabs coffee, back in a few secs
Jan 13 13:15:57 <akiniemi> So what's the standard way to get notified when an EF's content changes?
Jan 13 13:16:45 <akiniemi> For instance, the PNN entries or SPN change via OTA update?
Jan 13 13:21:44 <Jeevaka> akiniemi: refresh proactive command ?
Jan 13 13:23:59 <akiniemi> Jeevaka: perhaps, is there a watch API for that available or in the works?
Jan 13 13:24:51 <Jeevaka> work ongoing
Jan 13 13:25:23 <Jeevaka> http://lists.ofono.org/pipermail/ofono/2011-January/007195.html
Jan 13 13:25:34 <Jeevaka> Andrzej is working on it
Jan 13 13:28:15 <akiniemi> Thanks, I'll check that out
Jan 13 13:29:50 <pessi> akiniemi: gisi-notify-fix patches
Jan 13 13:32:26 <akiniemi> pessi: looking at those
Jan 13 13:39:06 <zrafa> hello, I have a few questions about sim.c : does it just save on sim the "own_numbers" (SubscriberNumbers) ?.. Also I would like to understand own_numbers well, is it the list of numbers people could use to call you (from a user point of view). Could those own_numbers be set by user? (I see a readwrite property and I read set_own_numbers(), but it sounds strange for me if own_numbers are the numbers of the sim)
Jan 13 13:48:40 <pessi> zrafa: SubscriberNumbers (MSISDN) are just informational
Jan 13 13:49:30 <pessi> user can write them, if they are wrong, he just shoots himself in the foot
Jan 13 13:50:21 <Jeevaka> pessi: any reason why the EFmsisdn file is kept as writable??
Jan 13 13:51:43 <pessi> I suppose it is because network can send you an update?
Jan 13 13:52:13 <zrafa> pessi: ah.. okey, do those numbers sent as well? (to other phones/network)
Jan 13 13:53:03 <pessi> zrafa: nope
Jan 13 13:54:17 <zrafa> pessi: ah, I see. thanks for the info
Jan 13 14:55:53 <denkenz> Jeevaka: Happens when I Ctrl-C oFonod after running test/enable-modem but not activating a sim app
Jan 13 15:44:24 <Jeevaka> denkenz: I delivered a patch for the fault
Jan 13 15:45:15 <Jeevaka> denkenz: since I dont know the actual use case, I have delivered the patch under some assumption
Jan 13 15:45:28 <Jeevaka> I'll test the patch for this case
Jan 13 15:48:26 <denkenz> Jeevaka: Well I honestly got lost in that code ;)
Jan 13 15:56:21 <Jeevaka> denkenz: fix patch works for the segmentation fault as well
Jan 13 16:07:47 <denkenz> Jeevaka: Yep, fixes the segfault
Jan 13 16:10:23 <Jeevaka> denkenz: about the ctm call notification
Jan 13 16:13:41 <denkenz> yes?
Jan 13 16:14:10 <Jeevaka> ifx doesn't support TTY multiparty 
Jan 13 16:15:57 <Jeevaka> so, basically "CTM CALL" is applicable for the active call
Jan 13 16:17:12 <denkenz> I thought there was no network limitation of mixing tty and regular calls?
Jan 13 16:19:16 <Jeevaka> yes, there is no network limitation. I can see your point now
Jan 13 16:20:19 <Jeevaka> once I get the TTY device, Ill test different use cases.
Jan 13 18:11:16 <Jeevaka> denkenz: ping
Jan 13 18:11:36 <denkenz> Jeevaka: pong
Jan 13 18:12:54 <Jeevaka> do you know why the libcap-ng is not part of meego
Jan 13 18:19:57 <Jeevaka> or in other way may i know why we are having the lipcap-ng
Jan 13 18:25:15 <denkenz> Eventually we want to drop privileges for oFono
Jan 13 18:25:39 <denkenz> e.g. keep something like the net privileges, but drop all others
Jan 13 18:25:53 <denkenz> Why its not part of Meego I've no idea
Jan 13 18:29:06 <Jeevaka> ok
Jan 13 18:45:41 <zrafa> denkenz: I see for sim.c that set_own_numbers() is the only place which stores on sim a phone number. And it is validated against valid_phone_number_format().. Do you know if there are other functions storing numbers? I do not find other places. 
Jan 13 18:47:35 <denkenz> zrafa: message waiting for the MBDN number
Jan 13 18:48:24 <denkenz> And there are a few other places where we abuse valid_phone_number, like sms atom and stk atom
Jan 13 18:52:48 <zrafa> denkenz: if OFONO_MAX_PHONE_NUMBER_LENGTH = 80 those functions should manage the problem right?. I mean, do you have some suggestions/ideas for numbers written on sim if OFONO_MAX_PHONE_NUMBER_LENGTH = 80? (but without extension records).
Jan 13 19:09:30 <denkenz> a different function?
Jan 13 19:09:48 <denkenz> e.g. one that enforces the smaller length
Jan 13 19:09:55 <denkenz> You might also need one for SMS
Jan 13 19:15:51 <zrafa> denkenz: sounds okey
Jan 13 19:17:39 <akiniemi> denkenz: ping
Jan 13 19:17:49 <denkenz> akiniemi: pong
Jan 13 19:18:11 <akiniemi> denkenz: wondering about simfs and refreshes...
Jan 13 19:18:32 <denkenz> Don't, bad for your health ;)
Jan 13 19:18:40 <akiniemi> should we be able to mark some files so that they are always re-read on sim insert?
Jan 13 19:19:06 <denkenz> what for?
Jan 13 19:19:08 <akiniemi> There is a nasty scenario where the cache will fail
Jan 13 19:19:16 <denkenz> tell me then
Jan 13 19:19:54 <akiniemi> Take your sim to another phone. While there, the operator updates a file. Take it back to the first phone. Cache has wrong file and no refresh will ever come.
Jan 13 19:20:08 <akiniemi> s/updates/OTA updates
Jan 13 19:20:49 <denkenz> Then we might as well get rid of the cache
Jan 13 19:22:22 <akiniemi> My thinking as well, except maybe we can limit it to files we know aren't going to be updated
Jan 13 19:23:08 <akiniemi> Close to impossible to know for sure, though
Jan 13 19:23:45 <denkenz> It comes down to the likelyhood of such OTA updates
Jan 13 19:23:51 <denkenz> The cache provides a major speed boost
Jan 13 19:24:21 <denkenz> And the likely use of sim refresh is to switch between two sim apps
Jan 13 19:24:33 <denkenz> Not really do OTA updates
Jan 13 19:25:01 <akiniemi> We need to be able to handle that case as well. It's a requirement, and tested, too.
Jan 13 19:25:39 <akiniemi> PNN updates OTA, and also the CPHS customer service profile can be changed via sim app
Jan 13 19:27:01 <denkenz> So I don't disagree and the cache was done before we knew about STK
Jan 13 19:27:16 <denkenz> But on the flip side, it is a major speed boost
Jan 13 19:28:05 <denkenz> Question is, can we play any tricks to keep both happy
Jan 13 19:28:16 <akiniemi> Well these are *very* infrequent in real life
Jan 13 19:28:43 <akiniemi> And the test cases I know of aren't swapping sims, so we might be able to ignore this
Jan 13 19:29:10 <akiniemi> Problem is if this bug is found in the field it's going to be nasty to debug :)
Jan 13 19:30:05 <denkenz> So looking at EFcsp from CPHS, it is updateable by the user
Jan 13 19:30:13 <denkenz> Hence it won't be cached anyway
Jan 13 19:30:42 <akiniemi> Oh? I missed that. Do we cache PNNs?
Jan 13 19:31:36 <denkenz> EFpnn is a problem though
Jan 13 19:34:34 <denkenz> Btw, the distro should have some way to wiping settings, among those should be the EF cache
Jan 13 19:36:28 <akiniemi> True
Jan 13 19:36:49 <akiniemi> And a 'reload' for the upcoming main.conf update too
Jan 13 19:38:18 <akiniemi> That reminds me, would you object to a global main_opts that holds all the configuration options, à la bluez?
Jan 13 19:41:07 <denkenz> that sounds OK
Jan 13 19:41:37 <denkenz> But I never know until I see the code ;)
Jan 13 19:43:19 <akiniemi> Better check early and often for comments ;)
Jan 13 19:44:45 <denkenz> exactly, the open source way :)
Jan 13 19:48:57 <akiniemi> Avoids unnecessary sabre clashing, too
Jan 13 19:49:41 <akiniemi> Some sabre clashing is necessary might I add *cough* Originated property *cough* ;)
Jan 13 20:11:57 <akiniemi> denkenz: Are you tracking Andrzej's refresh patches?
Jan 13 20:12:17 <denkenz> I gave my comments on them yesterday
Jan 13 20:14:12 <akiniemi> Ok
Jan 13 20:14:37 <akiniemi> Trying to go through the list for any orphaned patches
Jan 13 20:14:44 <akiniemi> We really need some tracking system for them
Jan 13 20:19:30 <denkenz> since we only have 3 active commiters it might be too much overhead right now
Jan 13 20:20:19 <denkenz> If the patch is sitting a while then the submitter should resubmit or bug the maintainers on IRC / mailing list
Jan 13 21:41:22 <zrafa> denkenz: about the gps proposal review I am checking for similar examples. Do you know an example of an external clients which registers an Agent? 
Jan 13 21:48:26 <denkenz> plenty, see e.g. src/stkagent.[ch]
Jan 13 21:48:31 <denkenz> or src/smsagent.[ch]
Jan 13 21:48:46 <denkenz> zrafa: Or check out how fd passing is done between plugins/hfp.c and bluez
Jan 13 21:49:43 <zrafa> denkenz: ah great tip, thanks
Jan 13 22:51:50 <balrog-k1n> denkenz: with only one method at the moment would it be worth adding it on a new atom?
Jan 13 22:53:06 <denkenz> balrog-k1n: The thing is that CUAD is only useful for SIM authentication
Jan 13 22:53:29 <denkenz> balrog-k1n: So if we know we're going to add more methods there, then its fine starting small
Jan 13 22:54:03 <balrog-k1n> denkenz: but are we going to add more methods?
Jan 13 22:54:20 <denkenz> If we want to support SIM Auth, then yes
Jan 13 22:55:49 <balrog-k1n> denkenz: ah so do you think the list_apps call should be on the SimAuthentication atom?
Jan 13 22:55:55 <balrog-k1n> or a completely new atom?
Jan 13 22:56:07 <denkenz> I think it should be on the SimAuthentication atom
Jan 13 22:56:16 <denkenz> At least right now I've not heard of any other use of CUAD
Jan 13 22:56:29 <balrog-k1n> yeah, i haven't either
Jan 13 22:56:50 <balrog-k1n> though conceptually it would fit in SimManager
Jan 13 22:57:00 <balrog-k1n> or soemthing like a "sub-atom"
Jan 13 22:57:21 <denkenz> I'm hesitant to add anything more to the sim atom
Jan 13 22:57:24 <denkenz> It is already crazy
Jan 13 23:01:19 <balrog-k1n> pessi, denkenz: are you fine with me adding something like "include/sim-auth.h" (with just one method atm) and a all the associated structs and then drivers/atmodem/sim-auth.c and the associated changes?
Jan 13 23:02:40 <denkenz> I'm fine with that, in the meantime you can put the CUAD parser into simutil.c
Jan 13 23:03:29 <balrog-k1n> yeah, i was thinking it may be better in simutil.c,
Jan 13 23:03:59 <balrog-k1n> although most drivers will probably just parse EFdir, and CUAD is just EFdir with all the records concatenated
Jan 13 23:04:15 <balrog-k1n> with no information of the record length
Jan 13 23:05:05 <denkenz> I know, but at least MBM doesn't return CRSM for directories
Jan 13 23:05:13 <denkenz> So this might be a necessary evil
Jan 13 23:06:41 <balrog-k1n> EFdir is a record based file though?
Jan 13 23:06:49 <balrog-k1n> i haven't tried reading the contents of EFdir on my MBM but i tried reading the file info with CRSM and it worked
Jan 13 23:07:05 <denkenz> ah really?
Jan 13 23:07:23 <denkenz> Then maybe an actual method is not needed
Jan 13 23:07:28 <balrog-k1n> in fact i tried it on the Au vodafone card i have from you since it has an EFdir
Jan 13 23:07:30 <balrog-k1n> :)
Jan 13 23:07:58 <denkenz> I'm really fine either way, if you can reliably parse EFdir on both 3G and 2G sims I'm good
Jan 13 23:08:34 <holtmann> Can we ensure that all our modems will be able to get this done. Some of them do stupid filtering with CRSM, but might expose +CUAD.
Jan 13 23:08:46 <balrog-k1n> this one is 3G
Jan 13 23:09:51 <balrog-k1n> in the end we always need to support both types because some modems (the qcom msm7) don't have +CUAD
Jan 13 23:10:13 <denkenz> Then lets play it safe and use a dedicated method
Jan 13 23:10:19 <denkenz> worst case the driver can issue a CRSM
Jan 13 23:10:29 * balrog-k1n nods
Jan 13 23:10:44 <denkenz> besides, this is 27.007, so it makes sense anyway
**** ENDING LOGGING AT Fri Jan 14 02:59:58 2011