**** BEGIN LOGGING AT Thu Feb 03 02:59:57 2011
Feb 03 03:42:29 <denkenz> sabotage: pong
Feb 03 04:10:48 <sabotage> I'll have to ping again tomorrow, not in front of the system I'm trying to debug
Feb 03 04:11:16 <sabotage> short story is that no modem is being found at all (IFX)
Feb 03 04:12:25 <sabotage> 0.38 ofono, nothing changed except the platform firmware, so wondering if there are known issues on nCDK's with certain FW versions
Feb 03 04:12:54 <sabotage> oh, and getting udev event timeouts related to rfkill
Feb 03 04:13:03 <sabotage> I'll ping again in the morning
**** ENDING LOGGING AT Thu Feb 03 08:26:13 2011

**** BEGIN LOGGING AT Thu Feb 03 08:30:17 2011
Feb 03 13:49:02 <demarchi> holtmann: do the canceled messages need another status in history?
Feb 03 13:50:09 <demarchi> i.e. do i really need to create a OFONO_HISTORY_SMS_STATUS_SUBMIT_CANCELED or i can use the _FAILED one?
Feb 03 15:49:33 <denkenz> demarchi: Submit canceled is fine
Feb 03 15:59:00 <fdanis> denkenz: did you take a look to the v4 of bluetooth server support patch ?
Feb 03 16:05:26 <denkenz> padovan and you need to agree first ;)
Feb 03 16:05:59 <denkenz> I have half a mind to accept padovan's series, and then fix it up 
Feb 03 16:06:12 <denkenz> so you can submit your patches on top of his
Feb 03 16:31:49 <padovan> fdanis: Actually that Bluetooth code need a lot of fixes.
Feb 03 16:33:08 <padovan> We need to get rid of btio stuff inside oFono, and write a proper APIfor Server linsten in BlueZ.
Feb 03 16:33:26 <padovan> That is my thought on this at the moment.
Feb 03 16:35:32 <denkenz> So how hard is it to fix up the current series?
Feb 03 16:36:28 <denkenz> Are the patches from fdanis already taking care of these cases?
Feb 03 16:36:48 <padovan> I will just add the per adapter structure, to avoid the leaking that fdanis reported.
Feb 03 16:36:50 <fdanis> padovan: I try to avoid those problems in patch I sent
Feb 03 16:37:00 <padovan> Let me see your patch.
Feb 03 16:51:35 <fdanis> oui, il semblerait que le CE France est pas mal, mais ça se met doucement en place
Feb 03 16:51:58 <fdanis> ils ont l'air d'avoir des prix sur pas mal de choses
Feb 03 16:52:46 <fdanis> sorry, I made a mistake
Feb 03 17:02:26 <padovan> fdanis patches seems to solve the issue
Feb 03 17:02:43 <padovan> fdanis: have you tested that with my DUN patches on top?
Feb 03 17:03:01 <fdanis> padovan: no
Feb 03 17:03:48 <fdanis> padovan: how do you perform your test ?
Feb 03 17:04:26 <padovan> fdanis: maybe we can use your bluetooth patches and mine DUN server patches.
Feb 03 17:05:05 <padovan> fdanis: bind the listening channel to a dev/rfcomm and then use gsmdial on it.
Feb 03 17:05:33 <padovan> +#define TIMEOUT (60*1000) /* Timeout for user response (milliseconds) */
Feb 03 17:05:39 <fdanis> padovan: we test it with a simple plugin only logging strings received from the remote device
Feb 03 17:05:44 <padovan> fdanis: it should be 60 only.
Feb 03 17:05:59 <fdanis> ok
Feb 03 17:06:57 <fdanis> is the TIMEOUT in second ?
Feb 03 17:09:15 <denkenz> balrog-k1n: here?
Feb 03 17:09:44 <padovan> in this case yes, we do the *1000 inside bluetooth_send_
Feb 03 17:13:06 <fdanis> ok, thanks
Feb 03 17:13:37 <balrog-k1n> denkenz: yes
Feb 03 17:13:59 <denkenz> balrog-k1n: question
Feb 03 17:14:01 <denkenz> +       sim_fs_op_cache_fileinfo(fs, error, length, structure, record_length,
Feb 03 17:14:01 <denkenz> +                                       access, file_status);
Feb 03 17:14:02 <denkenz> +
Feb 03 17:14:02 <denkenz>         if (structure != op->structure) {
Feb 03 17:14:02 <denkenz>                 ofono_error("Requested file structure differs from SIM: %x",
Feb 03 17:14:03 <denkenz>                                 op->id);
Feb 03 17:14:14 <denkenz> Should sim_fs_op_cache_fileinfo be moved below the if there?
Feb 03 17:14:37 <denkenz> Otherwise if the file requests a structure that doesn't match, we don't have the entire file cached
Feb 03 17:15:07 <balrog-k1n> denkenz: iirc i moved it above it because the fileinfo won't change next time,
Feb 03 17:15:12 <balrog-k1n> so there's no point re-reading it
Feb 03 17:15:32 <denkenz> Yes, but we have to be careful of e.g. EFecc style files
Feb 03 17:15:38 <denkenz> we request two different structures
Feb 03 17:16:00 <denkenz> so you cache the info but the structure doesn't match
Feb 03 17:16:04 <denkenz> so you don't cache the contents
Feb 03 17:16:14 <denkenz> the next time around you get the right structure, but no contents
Feb 03 17:16:14 <balrog-k1n> that's one of the use cases i think.. we would read the file info twice otherwise
Feb 03 17:16:42 <balrog-k1n> once we read the contents, we cache them
Feb 03 17:17:02 <balrog-k1n> at the first try we just cache the fileinfo
Feb 03 17:17:13 <denkenz> yeah, but if the structure doesn't match on the first request, we don't read the contents
Feb 03 17:17:24 <balrog-k1n> right
Feb 03 17:18:00 <balrog-k1n> so until now, as i see it, the order was: read fileinfo (dtructure doesn't match), re-read fileinfo (match), read contents
Feb 03 17:18:21 <balrog-k1n> with the patch we read fileinfo and cache it, the second time we jsut read the contents
Feb 03 17:18:58 <denkenz> what about the actual blocks / records of the EF?
Feb 03 17:19:27 <balrog-k1n> we read them when the structure matches on the second try?
Feb 03 17:20:09 <balrog-k1n> my intent was that there's no functionality change
Feb 03 17:20:18 <balrog-k1n> we just avoid re-reading the fileinfo/header
Feb 03 17:20:25 <denkenz> hmm, *checks*
Feb 03 17:20:40 <denkenz> so it looks like this will work
Feb 03 17:20:51 <denkenz> read a file -> cache info
Feb 03 17:20:56 <denkenz> structure doesn't match
Feb 03 17:21:04 <denkenz> read a file -> get cache
Feb 03 17:21:11 <denkenz> read record -> fail
Feb 03 17:21:13 <denkenz> go to the sim
Feb 03 17:21:22 <padovan> fdanis: you registering twowatches to the same io channel, use somthing like the the pending_auth I did in my patches.
Feb 03 17:21:33 <balrog-k1n> we already did that anyway, for block files
Feb 03 17:21:39 <denkenz> sim_fs_op_read_record and sim_fs_op_read_block are handling this right?
Feb 03 17:21:50 <balrog-k1n> we cached only the blocks that we had read so far
Feb 03 17:23:38 <denkenz> Ok, looks like we indeed do this right, nice
Feb 03 17:27:20 <fdanis> padovan: yes, to change the callback
Feb 03 17:27:29 <fdanis> padovan: is there any problem ?
Feb 03 17:29:04 <Jeevaka> denkenz, balrog-k1n
Feb 03 17:29:07 <Jeevaka> ping
Feb 03 17:29:42 <Jeevaka> denkenz, balrog-k1n: ping
Feb 03 17:30:00 <denkenz> yes?
Feb 03 17:31:34 <Jeevaka> http://pastebin.com/u13TPx5r
Feb 03 17:31:54 <Jeevaka> thats the one i'm preparing now, is it ok?
Feb 03 17:32:39 <denkenz> balrog-k1n: Can you resubmit patch 5 real quick?
Feb 03 17:32:40 <denkenz> Applying: Implement ofono_sim_context api.
Feb 03 17:32:41 <denkenz>   	if (op->current < total) {
Feb 03 17:32:41 <denkenz> fatal: 1 line adds whitespace errors.
Feb 03 17:33:32 <denkenz> Jeevaka: That looks sweet
Feb 03 17:35:13 <Jeevaka> will continue with the work and send it to you and balrog-k1n to verify the content
Feb 03 17:41:52 <padovan> fdanis: you are leaking one
Feb 03 17:45:20 <fdanis> padovan: which one ? auth_watch or client_event related one ? sorry I do not see it
Feb 03 17:47:51 <fdanis> is it the client_data structure in auth_cb() ?
Feb 03 17:50:39 <balrog-k1n> denkenz: do you still need me to resubmit (was away for a moment)
Feb 03 17:50:48 <denkenz> yes
Feb 03 17:50:56 <balrog-k1n> ok
Feb 03 17:50:58 <denkenz> it does not apply even with whitespace amending
Feb 03 17:51:46 <denkenz> also, please submit this one as a separate patch:
Feb 03 17:51:47 <denkenz> -	if (cf->ussd_watch)
Feb 03 17:51:47 <denkenz> +	if (cf->ussd_watch) {
Feb 03 17:51:47 <denkenz>  		__ofono_modem_remove_atom_watch(modem, cf->ussd_watch);
Feb 03 17:51:48 <denkenz> +		cf->ussd_watch = 0;
Feb 03 17:51:48 <denkenz> +	}
Feb 03 17:55:54 <balrog-k1n> i'll just skip it since it doesn't make practical difference
Feb 03 17:57:24 <denkenz> ok
Feb 03 18:00:22 <balrog-k1n> oops, i'll resend again, i forgot to check what the whitespace issue was
Feb 03 18:02:03 <fdanis> padovan: ping
Feb 03 18:03:07 <padovan> fdanis: pong
Feb 03 18:03:24 <padovan> fdanis: you add a watch to client_event, and never remove it.
Feb 03 18:05:06 <fdanis> padovan: it will be automatically removed by glib when the callback client_event will return false
Feb 03 18:05:20 <denkenz> balrog-k1n: 2nd version still doesn't apply
Feb 03 18:05:48 <fdanis> padovan: do you know how to use phonesim in GPRS mode to perform the test ?
Feb 03 18:06:32 <padovan> fdanis: yeah, but then we will have to call to callbacks in the watch
Feb 03 18:06:45 <padovan> client_event and auth_watch
Feb 03 18:07:17 <fdanis> padovan: ?
Feb 03 18:07:49 <fdanis> padovan: I am not sure to understand how you want I perform the test
Feb 03 18:08:02 <padovan> s/call to/call two/
Feb 03 18:09:13 <padovan> see what I did in my patches, there is a pending_auth to workaround this.
Feb 03 18:09:59 <padovan> fdanis: suppose you are listening on <bd_addr> then
Feb 03 18:10:24 <padovan> then "rfcomm -i hci1 0 <bd_addr> 1
Feb 03 18:10:38 <padovan> gsmdial -b -n /dev/rfcomm0
Feb 03 18:11:27 <padovan>         while (server->client_list) {
Feb 03 18:11:27 <padovan>                 g_source_remove((guint) server->client_list->data);
Feb 03 18:11:39 <padovan> fdanis: this seem wrong, what are you removing here?
Feb 03 18:12:10 <fdanis> padovan: where ?
Feb 03 18:12:40 <fdanis> sorry, I found it
Feb 03 18:14:08 <padovan> fdanis: check for msg ==NULL in cancel_authorization(struct cb_data *user_data)
Feb 03 18:14:35 <fdanis> I remove the clients io channels connected to the server
Feb 03 18:16:30 <fdanis> padovan: about auth_cb and client_event, the source using auth_cb is removed before creating the one using client_event, I do not think there is a problem here
Feb 03 18:17:42 <padovan> I don't like the idea of readding the watch.
Feb 03 18:17:56 <fdanis> client_event will be called (so related source will be removed) when remote disconnects
Feb 03 18:19:17 <fdanis> ok, so I will change this to only use one watch and one callback
Feb 03 18:19:38 <padovan> Ok, good.
Feb 03 18:20:56 <fdanis> padovan: we are trying to test it with fdalleau, but we do not know how to set phonesim in GPRS mode to be able to use the dun_gw
Feb 03 18:21:05 <fdanis> do you know how to do this ?
Feb 03 18:23:14 <denkenz> test/enable-modem test/online-modem should be enough
Feb 03 18:23:22 <padovan> yeah
Feb 03 18:23:25 <balrog-k1n> denkenz: it applies here
Feb 03 18:23:34 <balrog-k1n> well, the third version
Feb 03 18:23:48 <padovan> fdanis: or you have connman running and it does the work to online the modem to you. ;)
Feb 03 18:25:05 <denkenz> balrog-k1n: Yeah, tried all of them by now
Feb 03 18:25:06 <denkenz> Applying: ofono_sim_context api header changes.
Feb 03 18:25:06 <denkenz> Applying: Implement ofono_sim_context api.
Feb 03 18:25:07 <denkenz> error: patch failed: src/simfs.c:474
Feb 03 18:25:07 <denkenz> error: src/simfs.c: patch does not apply
Feb 03 18:25:07 <denkenz> Patch failed at 0002 Implement ofono_sim_context api.
Feb 03 18:30:15 <balrog-k1n> indeed, i'll re-rebase
Feb 03 18:30:43 <balrog-k1n> must be a conflict with soem change made today
Feb 03 18:31:11 <fdanis> padovan: test seems to work for Bluetooth side (connection and authorization), but I got a crash in PPP session
Feb 03 18:32:45 <padovan> which crash?
Feb 03 18:34:42 <fdanis> padovan: io is NULL in g_at_io_write() called by can_write_data()
Feb 03 18:34:42 <fdanis> latest trace are :
Feb 03 18:34:42 <fdanis> PPP: lcp: pppcp_this_layer_finished: current state 2:CLOSED
Feb 03 18:34:42 <fdanis> Entering new phase: 0
Feb 03 18:36:28 <padovan> fdanis: do you have tun/tap enabled in your kernel?
Feb 03 18:37:21 <balrog-k1n> denkenz: i sent another version, sorry for the errors
Feb 03 18:37:39 <fdanis> padovan: standard ubuntu with VPN, so I think yes
Feb 03 18:40:10 <fdanis> padovan: do this needs ofono to be started as root ?
Feb 03 18:43:58 <denkenz> yes
Feb 03 18:44:13 <padovan> surely yes.
Feb 03 18:44:52 <fdanis> works better
Feb 03 18:45:37 <fdanis> I will update my patches tomorrow
Feb 03 18:47:30 <fdanis> padovan, denkenz: do you want I integrate your patches with them ?
Feb 03 18:51:54 <padovan> fdanis: just send your bluetooth patches, my DUN Server should work fine if your patches are ok.
Feb 03 18:52:00 <padovan> But test will be needed.
Feb 03 18:52:14 <fdanis> padovan: ok
Feb 03 18:59:45 <denkenz> padovan: I can always merge the latest ones from fdanis if they are closer
Feb 03 19:01:49 <padovan> denkenz: they are, but sitll need fixing. If you want go ahead, the Frederic send delta patches.
Feb 03 19:02:17 <denkenz> Do those work with your emulator stuff?
Feb 03 19:04:15 <padovan> I think so, I can test them now.
Feb 03 19:06:51 <denkenz> then lets do that
Feb 03 19:09:25 <padovan> denkenz: fdanis patches doesnt build
Feb 03 19:09:34 <denkenz> hah
Feb 03 19:15:02 <fdanis> padovan: what is the problem ?
Feb 03 19:16:13 <padovan> fdanis: use --enable-maintainer-mode in ./configure and you'll see.
Feb 03 19:16:20 <fdanis> ok
Feb 03 19:18:50 <denkenz> plugins/bluetooth.c: In function ‘server_stop’:
Feb 03 19:18:50 <denkenz> plugins/bluetooth.c:464: error: cast from pointer to integer of different size
Feb 03 19:18:51 <denkenz> plugins/bluetooth.c: In function ‘client_event’:
Feb 03 19:18:51 <denkenz> plugins/bluetooth.c:494: error: cast to pointer from integer of different size
Feb 03 19:18:51 <denkenz> plugins/bluetooth.c: In function ‘auth_cb’:
Feb 03 19:18:52 <denkenz> plugins/bluetooth.c:553: error: cast to pointer from integer of different size
Feb 03 19:18:59 <denkenz> and another 8-10 the same
Feb 03 19:19:25 <denkenz> Please use G_POINTER_TO_UINT for this
Feb 03 19:19:26 <fdanis> padovan:  I just do make distclean, ./bootstrap-configure and make : no problem
Feb 03 19:19:42 <fdanis> denkenz: ok
Feb 03 19:20:06 <denkenz> GPOINTER_TO_UINT and GUINT_TO_POINTER
Feb 03 19:20:21 <fdanis> denkenz: but I do not get those errors
Feb 03 19:20:25 <denkenz> and get a 64 bit machine since you will get this wrong as some point ;)
Feb 03 19:20:44 <denkenz> yes, it breaks on 64 bit because uint is 4 bytes, while pointer is 8
Feb 03 19:20:52 <fdanis> denkenz: ok, I am currently on 32 bits ubuntu
Feb 03 19:23:34 <denkenz> are those the only problem? Since I can fix this up quickly
Feb 03 19:24:11 <denkenz> Or I go on to something else and let you guys figure this out ;)
Feb 03 19:28:44 <fdanis> denkenz: sorry, but I have to go, I will only be able to update the patches tomorrow, or send patches to fix what Padovan founds
Feb 03 21:56:47 <anandx_> hello Marcel
Feb 03 22:01:25 <anandx> Hi Marcel, do u have a min?
Feb 03 22:01:57 <anandx> Hi holtmann, do u have a min?
Feb 03 22:07:47 <Jeevaka> denkenz:ping
Feb 03 22:10:29 <denkenz> Jeevaka: pong
Feb 03 22:11:27 <Jeevaka> in outlook, table alignment is crappy
Feb 03 22:12:17 <Jeevaka> do you see in proper formatting when you apply patch?
Feb 03 22:17:15 <denkenz> Jeevaka: It looks fine, but you have spaces and tabs mixed so it shows a bunch of red for me
Feb 03 22:18:49 <Jeevaka> will fix thepaces to tabs
Feb 03 22:20:04 <denkenz> highlight RedundantWhitespace ctermbg=red guibg=red
Feb 03 22:20:04 <denkenz> match RedundantWhitespace /\s\+$\|\t\+\ze \+[^*]\| \+\ze\t/
Feb 03 22:20:07 <denkenz> If you use vim
Feb 03 22:22:34 <Jeevaka> ok, thanks for the tips
Feb 03 23:05:01 <demarchi> Jeevaka: you might want to use a macro like this in your $HOME/.vimrc too: http://codepad.org/5mVl4Eli
Feb 03 23:06:13 <Jeevaka> demarchi: thanks.
**** ENDING LOGGING AT Fri Feb 04 02:59:57 2011