**** BEGIN LOGGING AT Mon Nov 29 02:59:57 2010
Nov 29 14:10:01 <Jeevaka> denkenz: ping
Nov 29 14:15:15 <pessi> Jeevaka: would the efcfis and efcphs properties be more useful in sim interface?
Nov 29 14:22:45 <Jeevaka> As its more to do with call forwarding, thought that call forwarding is more appropriate than the sim atom.
Nov 29 14:31:23 <denkenz> Jeevaka: pong
Nov 29 14:32:21 <Jeevaka> I have fix for the 10381 bug
Nov 29 14:34:28 <Jeevaka> need to discuss about the fix
Nov 29 14:34:46 <denkenz> what is 10381?
Nov 29 14:35:21 <balrog-k1n> denkenz: guillaume's patches both look correct
Nov 29 14:35:32 <Jeevaka> bug id  http://bugs.meego.com/show_bug.cgi?
Nov 29 14:36:08 <balrog-k1n> i don't know that use of "default:" in a switch is what your holtmann recommended (i simply don't remember what the rule was)
Nov 29 14:37:19 <balrog-k1n> *you or holtmann
Nov 29 14:38:04 <denkenz> The preference is not to use default since the compiler will warn when new enums are added
Nov 29 14:38:52 <denkenz> Jeevaka: And why do you care about 10381? That bug is invalid in my eyes
Nov 29 14:39:14 <Jeevaka> may I know why is it invalid?
Nov 29 14:39:47 <denkenz> First it is phonesim, that allows calls without being online
Nov 29 14:40:15 <denkenz> second, Andras' emergency mode patches should fix this part of this anyway
Nov 29 14:41:26 <Jeevaka> I found an issue in ofono on this
Nov 29 14:41:39 <denkenz> oh?
Nov 29 14:42:03 <Jeevaka> currently, we are reading the EFest based on the availability of SIM_UST_SERVICE_ENABLED_SERVICE_TABLE service
Nov 29 14:43:00 <Jeevaka> as per the specification, EFest shall be present if service 2 or 6 or 35 is available
Nov 29 14:47:32 <holtmann> balrog-k1n: Mainly if it is own our enums defined inside and for oFono, no default statement please. If they are external enums, then default is fine.
Nov 29 14:47:59 <holtmann> balrog-k1n: There will be always an exception to the rule. For example in case they represent values from a binary wire protocol.
Nov 29 14:48:24 <denkenz> Jeevaka: yes, so far we're golden no?
Nov 29 14:49:29 <Jeevaka> not able to get you
Nov 29 14:51:36 <denkenz> Jeevaka: What's the problem? :)
Nov 29 14:51:50 <denkenz> balrog-k1n: Anyway, in this case I think it is fine
Nov 29 14:52:02 <denkenz> balrog-k1n: However, do any other proactive commands need to handle Busy?
Nov 29 14:53:24 <denkenz> balrog-k1n: Also, do we need to allow the busy error if the urgent flag is set?
Nov 29 14:53:33 <Jeevaka> denkenz: my proposal is to check for any one of the services(FDN or BDN or EST) availability before issuing EFest read
Nov 29 14:53:58 <Jeevaka> denkenz: currently, we are checking only EFest.
Nov 29 14:54:41 <denkenz> The spec basically mandates that EFest is there if EFbdn, EFfdn or the third file are present
Nov 29 14:54:59 <Jeevaka> yep
Nov 29 14:55:10 <denkenz> So what is the problem with simply checking for EFest?
Nov 29 14:55:19 <denkenz> Are you wanting to optimize the 'third file' case?
Nov 29 14:55:51 <Jeevaka> incase of FDN is present but EFest is not present, then we wont read EFest
Nov 29 14:56:09 <Jeevaka> let me rephrase it
Nov 29 14:56:30 <Jeevaka> incase of FDN service is available but EST is not present, then we wont read EFest
Nov 29 14:56:44 <denkenz> Doesn't that mean that the SIM provider needs to be shot?
Nov 29 14:57:27 <Jeevaka> wired case but if it happens aren't we supposed to handle that as well
Nov 29 14:57:44 <denkenz> I don't see how
Nov 29 14:57:55 <denkenz> We can't check for FDN enabled / disabled status without EFest
Nov 29 14:58:15 <Jeevaka> let me send you the patch then it will be clear
Nov 29 15:00:32 <Jeevaka> I have sent the patch
Nov 29 15:02:14 <denkenz> Ok, so you're saying EFest is present, but it hasn't been marked so in EFust
Nov 29 15:02:32 <denkenz> Do you actually have a SIM like that or you're just being paranoid?
Nov 29 15:03:04 <Jeevaka> just paranoid :-)
Nov 29 15:03:40 <denkenz> Then add a comment to that effect
Nov 29 15:03:49 <denkenz> And I'm fine applying it
Nov 29 15:06:38 <Jeevaka> comment in the code?
Nov 29 15:08:42 <denkenz> Yeah, basically say something like "31.102 section so and so requires so and so.  We're being extra paranoid and check for presence of so an so"
Nov 29 18:02:18 <sameo> denkenz: Have we ever tried to detect Nokia phones through their USB interface ?
Nov 29 18:02:29 <sameo> denkenz: as modems, I mean.
Nov 29 18:03:00 <denkenz> Should work AFAIK, but Nokia guys know more
Nov 29 18:03:03 <holtmann> sabotage: If they are ISI, then yes, that should work.
Nov 29 18:03:26 <holtmann> sabotage: Wrong nick ;)
Nov 29 18:03:56 <holtmann> sameo: It does work. I have used this. However there are limits on how useful this is.
Nov 29 18:06:48 <sameo> holtmann: ok, good to know you tried. I've plugged some S60 phone into my machine running the latest ofonod, and it didnt seem to detect it. I'll try to gather more info once I get this phone back.
Nov 29 18:07:25 <holtmann> I tested it on Fedora. Maybe the Debian/Ubuntu udev rules are broken. Aki had some issues there as well.
Nov 29 18:08:12 <sameo> ok, will check more. It seemed to detect the removal part only.
Nov 29 18:54:33 <Jeevaka> sameo: I have some answers for your problem
Nov 29 18:56:18 <Jeevaka> sameo: I have used with E63 with the latest ofonod and it works.
Nov 29 19:41:30 <padovan> denkenz: any comments on my patches?
Nov 29 19:47:06 <sameo> Jeevaka: thx
Nov 29 19:56:52 <darasd> denkenz: Hi, I am working with Lei and preparing a cdma voicecall todo patch for review. Are you happy if i add it as a whole new section "CDMA-VOICECALL" at the end of the current TODO file?
Nov 29 20:01:07 <denkenz> padovan: I'm down with the flu, so only doing mindless things today
Nov 29 20:01:18 <denkenz> darasd: That is fine, but don't use all caps please
Nov 29 20:02:00 <darasd> ok great, thanks!
Nov 29 20:04:40 <Jeevaka> 21:48 < darasd> denkenz: Hi, I am working with Lei and preparing a cdma
Nov 29 20:04:40 <Jeevaka>                 voicecall todo patch for review. Are you happy if i add it as a
Nov 29 20:04:40 <Jeevaka>                 whole new section "CDMA-VOICECALL" at the end of the current
Nov 29 20:04:40 <Jeevaka>                 TODO file?
Nov 29 20:04:40 <Jeevaka> 21:52 < denkenz> padovan: I'm down with the flu, so only doing mindless things
Nov 29 20:04:43 <Jeevaka>                  today
Nov 29 20:04:45 <Jeevaka> 21:53 < denkenz> darasd: That is fine, but don't use all caps please
Nov 29 20:04:48 <Jeevaka> 21:53 < darasd> ok great, thanks!
Nov 29 20:05:19 <Jeevaka> sorry, ignore the previous message
Nov 29 20:12:27 <Jeevaka> holtmann, denkenz: are there any plans to support class c proactive command?
Nov 29 20:12:44 <denkenz> Nope
Nov 29 20:12:59 <denkenz> At least it is not on the TODO
Nov 29 20:14:52 <Jeevaka> currently, we are testing all the sat commands using the ofono test script. I dont know how we can test launch browser without the ui support!!
Nov 29 20:19:41 <denkenz> Well since there's no launch browser, testing is a bridge still in the future ;)
Nov 29 20:21:18 <Jeevaka> ok, then launch browser is the next task that i'll look into
Nov 29 20:37:02 <balrog-k1n> denkenz: only Display Text and Display MMS (which isn't handled) use that response
Nov 29 20:37:24 <balrog-k1n> i think it is ok to allow it for urgent messages, there can always be something more urgent on the screen
Nov 29 20:40:43 <balrog-k1n> i think it would be totally ok to allow it for all the other agent calls too since all of the commands allow a "Terminal currently unable to process command" response
Nov 29 20:41:19 <balrog-k1n> they just leave the "additional info" part up to the terminal
Nov 29 20:52:37 <denkenz> balrog-k1n: Fair enough, do you want to treat screen busy and terminal currently unable to process command separately?
Nov 29 20:54:36 <balrog-k1n> denkenz: screen busy is just a "Terminal currently unable to process command" with additional info, i don't think we need a generic "Terminal currently unable to process command" on the dbus interface
Nov 29 20:55:13 <balrog-k1n> hmm i think Dbus has a predefined "busy" response too
Nov 29 21:10:23 <denkenz> balrog-k1n: So I don't see the screen busy additional info in that patch
Nov 29 21:15:12 <denkenz> balrog-k1n: Can you check that for me and comment on the patch to the ML?
Nov 29 21:16:17 <balrog-k1n> denkenz: oh yeah, i must be blind...
Nov 29 21:21:52 <denkenz> balrog-k1n: Ok, please comment on it, I've already marked it as read and no way I find it again ;)
Nov 29 21:23:24 <padovan> denkenz: Ideas for the DBus name for CNAP? NameIndentification? NamePresentation?
Nov 29 21:23:54 <denkenz> padovan: On call-settings or on voicecall
Nov 29 21:23:55 <denkenz> ?
Nov 29 21:24:19 <padovan> voicecall
Nov 29 21:25:05 <padovan> CLIP uses LineIdentification, the similar would be NameIdentification.
Nov 29 21:25:54 <denkenz> Yeah except LI actually stands for LineIdentification
Nov 29 21:26:38 <balrog-k1n> denkenz: heh i know what you mean
Nov 29 21:28:01 <denkenz> padovan: Go with simply Name
Nov 29 21:28:16 <padovan> Great.
Nov 29 21:37:04 <Jeevaka> denkenz, balrog-k1n
Nov 29 21:38:41 <Jeevaka> denkenz, balrog-k1n: regarding the display text with high priority text
Nov 29 21:41:38 <Jeevaka> screen busy response is applicable
Nov 29 21:50:58 <denkenz> nod, 102.223 hints this as well
Nov 29 22:01:03 <Jeevaka> yep
Nov 29 23:19:55 <demarchi> denkenz: what python version do you have?
Nov 29 23:20:30 <demarchi> denkenz: or... what python version the test scripts need to be compatible?
Nov 29 23:30:24 <balrog-k1n> they all work with 2.6 for me
Nov 29 23:30:33 <balrog-k1n> they do not work with 3.1
Nov 29 23:34:13 <demarchi> for most of the scripts, compatibility with 3.1 is simple a matter of turning print "bla" into print("bla")
Nov 29 23:34:39 <demarchi> so, if we have to be compatible  with >= 2.6, it think it's fine doing the change
**** ENDING LOGGING AT Tue Nov 30 02:59:57 2010