| uvos__ | sicelo: yeah i gues thats true, this isent an oversight tho, i want some sort of notification when you dont accept a call as a reminder to call the other party back later, using the missed call machinery was simply eaiyest | 09:39 |
|---|---|---|
| uvos__ | maybe we can create a notification but not log the call as missed or something | 09:42 |
| uvos__ | needs sphone internal module api changes | 09:42 |
| freemangordon | uvos__: I think the proper way to do it is to log it ass rejected call | 11:17 |
| freemangordon | *as | 11:17 |
| freemangordon | and to mark it as such in the UI | 11:17 |
| freemangordon | uvos__: also, did you see the issue I found with the sound driver? | 11:18 |
| freemangordon | Wizzup: I wonder isn't it better to get rid of glibofono in connui-cell | 11:19 |
| Wizzup | freemangordon: ok | 11:23 |
| Wizzup | freemangordon: because of the sync issues, or? | 11:23 |
| freemangordon | because they expose almost no method | 11:24 |
| freemangordon | besides modem methiods, there is nothing else | 11:25 |
| freemangordon | to me it is easier do generate our gdbus wrappers than to make MRs to SF | 11:25 |
| freemangordon | *to | 11:26 |
| freemangordon | esp when our api is expected to be synchronous | 11:27 |
| uvos__ | freemangordon: no what issue in the sound driver | 11:28 |
| uvos__ | i noticed that since we updated pa | 11:28 |
| uvos__ | the volumes stopped restoreing | 11:28 |
| freemangordon | so you think it is PA issue? | 11:28 |
| uvos__ | i dont know what issue you are talking about | 11:29 |
| uvos__ | i noticed that the volumes no longer restore | 11:29 |
| freemangordon | sec | 11:29 |
| uvos__ | but maybe thats just because we changed pa to run as user | 11:29 |
| uvos__ | and some file on my system is now owned by root | 11:29 |
| uvos__ | and it cant update it | 11:29 |
| uvos__ | or something | 11:29 |
| freemangordon | if you reject the incomming call, no notification sound is played and basically sounds do not work for few minutes or until PA is restarted | 11:30 |
| Wizzup | freemangordon: fine by me | 11:30 |
| uvos__ | ok | 11:30 |
| uvos__ | well the driver dose some really hacky stuff when a call is started | 11:30 |
| freemangordon | uvos__: to me it seems there is some race or other issue in the driver | 11:31 |
| uvos__ | iirc the driver just clobbers some registers | 11:31 |
| uvos__ | that subsiquently the alsa framework dosent know about | 11:31 |
| uvos__ | should restore them after the call however | 11:31 |
| freemangordon | so I commented out enabling modem dai on incomming call (but before it is accepted) and the issue is gone | 11:31 |
| freemangordon | but thta' | 11:31 |
| freemangordon | ... | 11:31 |
| freemangordon | but that's just a hack | 11:31 |
| uvos__ | yeah the modem dai is not used in a call | 11:32 |
| uvos__ | its just for recording audio | 11:32 |
| uvos__ | the whole thing is a huge hack | 11:32 |
| uvos__ | (voice call on mapphones) | 11:32 |
| uvos__ | nothing is correctly implemented here, as i say the driver just overwrites a buntch of registers that the alsa framework expects to control via its controls | 11:33 |
| freemangordon | sorry, gnome crashed | 11:33 |
| freemangordon | so, what needs to be done here? | 11:33 |
| freemangordon | *there | 11:34 |
| freemangordon | we use ucm, right? | 11:34 |
| uvos__ | yes | 11:34 |
| freemangordon | don;t we have the proper controls exported? | 11:34 |
| uvos__ | but this isent about that | 11:34 |
| uvos__ | the problem is that the snd-soc framwork dosent seam to support audio going coming from a 3rd party device without passing though any dai the kernel controls, but still needing setup/ routing in the analog amps etc that the audio devices the kernel dose control contain | 11:36 |
| uvos__ | or at least we dont know how this is supposed to fit in | 11:36 |
| freemangordon | with this https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1.y/sound/soc/codecs/motmdm.c#L549 commented out it is ok | 11:36 |
| freemangordon | I see | 11:36 |
| freemangordon | ok, why not ask on the ML? | 11:36 |
| uvos__ | tmlind did in the past, to not that mutch sucess iirc, but yeah we could try again | 11:37 |
| freemangordon | we'd better do, as now it is very buggy | 11:37 |
| freemangordon | tmlind: could you point me to ^^^ | 11:38 |
| uvos__ | irrc the discussion last time surfced the idea of having a dummy dai, that pretends to be the source of the audio and is active when the modem controls the audio devices | 11:39 |
| uvos__ | but dont qoute me on that | 11:39 |
| uvos__ | the volumes def also stoped restoreing (on boot and on hp plug) thats def a pa bug we also have | 11:56 |
| arno11 | Wizzup: freemangordon: i've got a (huge) memory leak with conversations/tp-haze/FB plugin. not sure what's going on but pkilling conversations solves the issue (otherwise it uses 100% cpu, the entire RAM and more than 500MB of swap !) | 12:34 |
| arno11 | it happens when i connect a FB account | 12:34 |
| Wizzup | ok, there's been a pretty big rework so it might be solved by now | 12:41 |
| arno11 | ok | 12:41 |
| arno11 | otherwise it works very well with almost no cpu usage or ram | 12:42 |
| Wizzup | do you know if you do anything in particular? | 12:48 |
| Wizzup | freemangordon: btw if we can get tp haze with channels in -devel or os that would be nice, then I can make sure we also deal with say slack channels well | 12:49 |
| arno11 | Wizzup: apparently not | 12:53 |
| Wizzup | arno11: ok, well I want to make a few more changes/checks but then I will cut a release | 12:53 |
| Wizzup | there's still abook integration to be done | 12:53 |
| Wizzup | but there are a lot of rtcom logging improvements | 12:54 |
| arno11 | ok cool | 12:54 |
| Wizzup | and yes, then we will have to hunt for memory issues | 12:54 |
| Wizzup | for it to work well you might have ot nuke the existing rtcom db | 12:55 |
| Wizzup | I'm making some more logging changes to make it (fully) compatible with fremantle | 12:58 |
| Wizzup | the last thing I have to figure out is why the 'remote uid' for a message that we send to a channel is <channel id>@conference.../jabberid@jabberserver.domain | 13:15 |
| Wizzup | for irc it is just the nickname | 13:15 |
| Wizzup | I guess irc isn't federated and jabber is, so that makes some sense then | 13:16 |
| arno11 | you mean the nicknames shown in conversation windows ? | 13:39 |
| Wizzup | arno11: nah just sql logging | 13:47 |
| arno11 | ah ok | 13:47 |
| Wizzup | ok, figured it out I think | 14:46 |
| arno11 | Wizzup: btw do you have an idea why some services show proper nicknames and not others ? | 15:19 |
| Wizzup | what do they show if not the nickname? | 15:19 |
| Wizzup | I see '(No name)' in contacts, but I presume you are referring to something else | 15:20 |
| arno11 | for example irc (and irc through bitlbee/conversations) and skype show proper nicknames in chat windows | 15:20 |
| arno11 | not working for sip or FB | 15:20 |
| arno11 | SIP shows full address and FB showa an 'ID' number | 15:21 |
| arno11 | *shows | 15:22 |
| arno11 | instead of nicknames/names | 15:22 |
| Wizzup | hm, right | 15:23 |
| Wizzup | so this is complicated, but this is what I am working on now, now that I think the logging is fixed | 15:23 |
| Wizzup | there is a nickname property for some of these, but for the actual logging we want to set the id | 15:23 |
| Wizzup | and what we need to do is to log the nickname in remote_name and the id in remote_uid | 15:24 |
| arno11 | ok | 15:24 |
| Wizzup | and then optionally also use abook to resolve the remote ids to contacts | 15:24 |
| Wizzup | at least that is what I am thinking right now | 15:24 |
| Wizzup | I need to fix two regressions in conversations and then it can go to -devel I think | 15:24 |
| arno11 | ok :) | 15:24 |
| Wizzup | as far as the mem usage goes, let's debug that soon too | 15:26 |
| Wizzup | I haven't paid too much attention to this but for the qt part I think it should just be ok | 15:26 |
| Wizzup | was the memory usage you saw in tp-haze or conversations\ | 15:26 |
| Wizzup | (or both) | 15:26 |
| arno11 | only with conversations | 15:26 |
| arno11 | tp haze increase cpu and ram only for few sec when connecting | 15:27 |
| Wizzup | ok | 15:28 |
| arno11 | btw how can i disable the --background option ? (just to test if there is a diff) | 15:30 |
| Wizzup | arno11: I don't think you need to test this | 15:37 |
| Wizzup | but background is only default in dsme | 15:37 |
| arno11 | yeah ok | 15:38 |
| Wizzup | ok yeah now I remember, for mapping im usernames to their display name I have to map a Telepathy::Account to TpAccount* | 15:39 |
| arno11 | ok cool | 15:39 |
| Wizzup | https://telepathy.freedesktop.org/spec/Connection_Interface_Aliasing.html | 15:42 |
| Wizzup | I think I can add this for everything that we don't have a contact for | 15:42 |
| Wizzup | Probably shouldn't test in this channel :p | 15:50 |
| arno11 | :) | 15:50 |
| Wizzup | freemangordon: do you want me to build a new haze version? | 15:57 |
| Wizzup | freemangordon: the sip lookup segfaults in strlen() https://paste.villavu.com/raw/8fPhvnewILtf2zfoQX3gmsUJKz52NeUN4g4EBymC/ | 16:09 |
| freemangordon | will look at it | 16:32 |
| freemangordon | Wizzup: new haze? why not | 16:33 |
| freemangordon | lemme push to github | 16:34 |
| freemangordon | Wizzup: hmm, actually... | 16:36 |
| freemangordon | not sure how to deal with upstream | 16:36 |
| freemangordon | add commits as patches? | 16:36 |
| Wizzup | freemangordon: don't really care tbh | 16:40 |
| Wizzup | I suspect we'd become upstream eventually | 16:40 |
| freemangordon | Wizzup: hmm, your sip address is missing sip:// | 16:40 |
| Wizzup | let me see, I might not be passing the right info then | 16:40 |
| freemangordon | there is a bug in abook, but still | 16:40 |
| uvos__ | honestly the storage format is also just bad | 16:44 |
| uvos__ | im not sure keeping absolute fremantle compatability is a good idea | 16:45 |
| uvos__ | like the fact that tel is just randomly not a url is pretty dumb | 16:45 |
| uvos__ | as is the almost random fromat of some other fields | 16:45 |
| uvos__ | like the local/remote ids | 16:46 |
| freemangordon | remote id is EDS uid if available | 16:48 |
| freemangordon | which is, in most cases | 16:48 |
| freemangordon | unless I am missing something | 16:50 |
| Wizzup | what storage format? | 16:50 |
| freemangordon | Wizzup: re haze - it is about debian packaging | 16:51 |
| freemangordon | I am not sure what is better | 16:51 |
| Wizzup | freemangordon: yeah, have no strong preference, I would just add them as commits and cut some small minor release for us for now | 16:51 |
| Wizzup | I don't expect upstream to do anything | 16:51 |
| Wizzup | there is no maintainer afaict | 16:51 |
| Wizzup | uvos__: actually I'm starting to like the rtcom format, it makes a lot more sense once you grok it | 16:52 |
| Wizzup | freemangordon: I don't think patches vs commits matters | 16:53 |
| freemangordon | bot are not fine, because I used upstream code, not debian one | 16:53 |
| freemangordon | and they differ | 16:53 |
| freemangordon | but ok, will just impland debian dir | 16:54 |
| Wizzup | what did debian change | 16:54 |
| uvos__ | maybe, but the fact that sms, tel and messages and all kinds of ip voice are seperate things with different field meansings seams pointless to me | 16:54 |
| freemangordon | nothing, they are just few commits behind | 16:54 |
| uvos__ | and creates headaches | 16:54 |
| Wizzup | conversations should (in my branch) deal with it well atm | 16:54 |
| Wizzup | for sip, sms, tel, etc | 16:54 |
| Wizzup | there are some oddities I would agree, like the group_uid for smses | 16:55 |
| freemangordon | Wizzup: please make user you have master contact id logged properly | 16:55 |
| Wizzup | freemangordon: can't parse | 16:55 |
| freemangordon | *make sure | 16:55 |
| Wizzup | do you mean the osso_abook_id ? | 16:55 |
| freemangordon | yes | 16:55 |
| Wizzup | well, I can't do that part yet until I have the conversion to TpAccount | 16:56 |
| freemangordon | this is basically EDS master contact UID | 16:56 |
| Wizzup | but apart from this, everything else seems to be alright now | 16:56 |
| Wizzup | there is some code to clean up too I suppose | 16:56 |
| freemangordon | ok | 16:56 |
| freemangordon | I am just reminding :) | 16:56 |
| Wizzup | is it necessary for the abook api to get a TpAccount* ? | 16:56 |
| Wizzup | can't we just give it a string describing where to find the account? | 16:56 |
| freemangordon | no | 16:56 |
| Wizzup | that would make my life much easier | 16:57 |
| freemangordon | which api do you mean? | 16:57 |
| Wizzup | https://github.com/maemo-leste/osso-abook/blob/master/lib/osso-abook-aggregator.h#L145 | 16:57 |
| Wizzup | clearly it needs to know the context for this im | 16:57 |
| Wizzup | but does it have to be a TpAccount* | 16:57 |
| Wizzup | as opposed to just say sofiasip/sip/NICKNAME@sip.antisip.com or something like that | 16:58 |
| Wizzup | or sofiasip/sip/NICKNAME_40sip_2eantisip_2ecom0 | 16:58 |
| freemangordon | why not just create TpAccount? | 16:58 |
| freemangordon | it should be easy | 16:58 |
| Wizzup | I am not sure it is | 16:58 |
| Wizzup | I mean, yes, I can make another accountmanager, this time in glib, next to the one we have already in a book | 16:59 |
| Wizzup | s/a book/abook/ | 16:59 |
| Wizzup | (and next to the qt one that we have) | 16:59 |
| freemangordon | You should be able to ask tpqt to give you the object path | 17:00 |
| freemangordon | and that's all you need | 17:00 |
| Wizzup | sure objectPath is easy | 17:00 |
| Wizzup | but then what? | 17:00 |
| Wizzup | https://telepathy.freedesktop.org/doc/telepathy-glib-0.24.x/telepathy-glib-account.html#tp-account-parse-object-path ? | 17:00 |
| freemangordon | gimme a minute | 17:01 |
| Wizzup | meant to link to tp_account_new | 17:01 |
| Wizzup | in any case does abook need any of the tp properties, or is it just going to extract the backend name | 17:02 |
| Wizzup | and local_uid | 17:02 |
| freemangordon | no, it needs it to find the master contact | 17:02 |
| freemangordon | not only the backend | 17:02 |
| freemangordon | see osso_abook_aggregator_find_contacts_full() | 17:02 |
| Wizzup | sorry I still don't really understand what the 'master contact' is | 17:02 |
| freemangordon | lemme try to explain | 17:03 |
| freemangordon | for each person in your abook, you have one *master* contact and zero or more *roster* contacts | 17:03 |
| freemangordon | master contact is there no matter online/offline etc | 17:04 |
| freemangordon | so, in your abook, my master contact contains my tel, email, nickname etc | 17:04 |
| Wizzup | mhm | 17:05 |
| sicelo | Wizzup: freemangordon ... regarding TP, I *think* Ubuntu Touch are also using it. Not sure if there'd be a chance/benefit to collaborate with them | 17:05 |
| freemangordon | and when you merge contacts (from jabber, for example), you attach my jabber username to my master contact | 17:05 |
| freemangordon | sicelo: just a sec please | 17:05 |
| freemangordon | and that way jabber actions appear when you click on 'ivo' in the abook | 17:05 |
| freemangordon | now, when you want to look at the history of your comunications with 'ivo' you want p[hone calls, sms*es, ims, everything, no? | 17:06 |
| freemangordon | Wizzup: is it cleraere now? | 17:07 |
| freemangordon | *clearer | 17:07 |
| Wizzup | yes, but not why you need a TpAccount for it | 17:07 |
| Wizzup | this is what is stored in the rtcom db as remote_uid | 17:08 |
| Wizzup | well, wait | 17:08 |
| Wizzup | local_uid in this case | 17:08 |
| Wizzup | what I mean to say is what TpAccount* to my knowledge doesn't contain anything special here | 17:09 |
| Wizzup | what you do to match TpAccount* to eds can be done without the Tpaccount*, you just need specific info | 17:09 |
| Wizzup | but it seems like it's easier if I just add a third accountmanager to conversations ;) | 17:09 |
| freemangordon | Wizzup: this is just the API that's exported | 17:09 |
| freemangordon | see osso_abook_aggregator_find_contacts_full | 17:10 |
| freemangordon | you can use it directly | 17:10 |
| Wizzup | I don't know what it does and what a OssoABookContactPredicate is :) | 17:10 |
| Wizzup | ah it is defined above | 17:11 |
| freemangordon | http://maemo.org/api_refs/5.0/5.0-final/libosso-abook/OssoABookAggregator.html#osso-abook-aggregator-find-contacts-full | 17:11 |
| freemangordon | or you can use osso_abook_aggregator_find_contacts | 17:11 |
| Wizzup | looks like fremantle used the missioncontrol account, did that contain the same data generally speaking? | 17:13 |
| freemangordon | it is the *same* | 17:14 |
| Wizzup | ok | 17:14 |
| freemangordon | McAccount is TpAccount | 17:14 |
| freemangordon | more or less | 17:14 |
| freemangordon | osso_abook_aggregator_find_contacts_for_im_contact() can get NULL for TpAccount | 17:14 |
| Wizzup | oh | 17:14 |
| freemangordon | see http://maemo.org/api_refs/5.0/5.0-final/libosso-abook/OssoABookAggregator.html#osso-abook-aggregator-find-contacts-for-im-contact | 17:15 |
| freemangordon | so you only need the username | 17:15 |
| Wizzup | we probably need to look into generating these docs for us too | 17:16 |
| freemangordon | yes | 17:16 |
| freemangordon | I need a volunteer to copy-paste them :) | 17:17 |
| Wizzup | didn't spinal wrote code to auto do this? | 17:17 |
| Wizzup | s/wrote/write/ | 17:17 |
| freemangordon | could be | 17:17 |
| freemangordon | Wizzup: also, keep in mind OssoABookContact is EContact | 17:18 |
| Wizzup | sent myself a single message and immediately the remote_name updated in the UI with the name set in my contacts app :) | 17:18 |
| freemangordon | Wizzup: a good test is to open abook | 17:19 |
| Wizzup | now we just need to master id lookup I guess | 17:19 |
| Wizzup | freemangordon: I already changed the nickname in abook | 17:19 |
| freemangordon | no, select "Recent" from the menu | 17:19 |
| Wizzup | yes, it's fine there too | 17:19 |
| Wizzup | conversations reads from the same db | 17:19 |
| freemangordon | not really, if you don;t log the uid | 17:20 |
| freemangordon | abook has fallback, but that will take time on big db | 17:20 |
| Wizzup | ok, so this id is just a property I imagine? | 17:20 |
| Wizzup | just like name is osso_abook_contact_get_display_name | 17:21 |
| Wizzup | osso_abook_contact_get_master_uids ? | 17:21 |
| freemangordon | https://github.com/maemo-leste/osso-abook/blob/master/lib/osso-abook-contact.h#L281 | 17:22 |
| freemangordon | I think this | 17:22 |
| Wizzup | ok | 17:22 |
| freemangordon | as I said, E_CONTACT_UID | 17:22 |
| freemangordon | AFAIK | 17:22 |
| freemangordon | maybe check fremantle db | 17:22 |
| Wizzup | sometimes I do wish that C supported multi-value return so I didn't have to invent a struct :) | 17:22 |
| Wizzup | freemangordon: what do you want from fremantle db? | 17:22 |
| freemangordon | I want nothing :) | 17:23 |
| freemangordon | just check if abook id there matches E_CONTACT uid | 17:23 |
| freemangordon | unless we have help on rtcom db explicitly saying that | 17:24 |
| Wizzup | CREATE TABLE Remotes (local_uid TEXT NOT NULL,remote_uid TEXT NOT NULL,remote_name TEXT,abook_uid TEXT,UNIQUE(local_uid,remote_uid)); | 17:24 |
| freemangordon | abook_uid | 17:24 |
| Wizzup | if you just set remote_name (which I already do) it will auto get added to the remotes table | 17:24 |
| Wizzup | I suspect the same is true for abook_uid | 17:24 |
| Wizzup | auto get added = rtcom-eventlogger library does this | 17:24 |
| freemangordon | no, abook uid should already exists | 17:24 |
| freemangordon | IIUC | 17:25 |
| freemangordon | this is EDS UID | 17:25 |
| Wizzup | ok, so | 17:25 |
| Wizzup | events is a table of all the events | 17:25 |
| freemangordon | mhm | 17:25 |
| Wizzup | remotes is a table that maps a remote_uid to a remote_name and abook_uid | 17:25 |
| freemangordon | ah | 17:25 |
| Wizzup | not every event remote_uid is presented here | 17:25 |
| Wizzup | so I think if I just log abook_uid together with remote_name, we're ok | 17:25 |
| freemangordon | right | 17:25 |
| Wizzup | I'll do this in a moment and report back | 17:26 |
| Wizzup | then it's probably good if you can look at some of my code and comment on it later today (once I clean up and push) | 17:26 |
| Wizzup | there is one regression that I need to fix, that might actually not be present on our devices | 17:26 |
| Wizzup | then I'll release 0.6.0 to devel | 17:27 |
| freemangordon | ok, lemme see how to release haze | 17:27 |
| freemangordon | Wizzup: btw, segfault in abook should be fixed | 17:28 |
| Wizzup | saw that, ty | 17:31 |
| Wizzup | btw, this tpaccount*, do I need to dispose of it? doc says it's owned by aggregator | 17:35 |
| Wizzup | s/tpaccount/OssoABookContact/ | 17:38 |
| freemangordon | no | 17:41 |
| freemangordon | just the list | 17:41 |
| Wizzup | ok | 17:41 |
| freemangordon | "...but the list itself must be freed with g_list_free(). " | 17:41 |
| Wizzup | I saw that | 17:43 |
| Wizzup | sqlite> select abook_uid from remotes where remote_uid='merlijn-fremantle@xmpp.wajer.org'; | 17:43 |
| Wizzup | pas-id-2dca35db338ead7ac0e3a720079deff6bb8901d6 | 17:43 |
| Wizzup | this was NULL until just now | 17:43 |
| Wizzup | does that seem sensible do you? | 17:43 |
| Wizzup | to you* | 17:44 |
| freemangordon | no idea | 17:44 |
| Wizzup | :) | 17:44 |
| Wizzup | it was mostly integers in fremantle fwiw | 17:44 |
| freemangordon | check with EDS | 17:44 |
| Wizzup | ah that is not true, not just ints | 17:45 |
| Wizzup | I have no idea how to check with eds | 17:45 |
| freemangordon | sec | 17:45 |
| Wizzup | but I used: | 17:45 |
| Wizzup | RTCOM_EL_EVENT_SET_FIELD(ev, remote_ebook_uid, g_strdup(abook_uid)); | 17:45 |
| Wizzup | and | 17:45 |
| Wizzup | abook_uid = osso_abook_contact_get_uid(tmpcontact); | 17:45 |
| freemangordon | g_strdup(abook_uid)?!? | 17:46 |
| Wizzup | for rtcom-eventlogger | 17:46 |
| freemangordon | it will free it? | 17:46 |
| Wizzup | yes | 17:46 |
| freemangordon | ok | 17:46 |
| freemangordon | looks ok | 17:47 |
| Wizzup | *shrug* | 17:47 |
| freemangordon | lemme try to start EDS | 17:47 |
| Wizzup | abook ui still looks the same,but it already did the right thing earlier I think | 17:47 |
| freemangordon | yeah | 17:47 |
| freemangordon | Wizzup: check the contents of /home/user/.local/share/evolution/addressbook/system | 17:55 |
| freemangordon | I am using mcview for that | 17:55 |
| Wizzup | ok,sec | 17:55 |
| Wizzup | looks ok | 18:10 |
| freemangordon | Wizzup: tp-haze is in -devel repo | 18:18 |
| Wizzup | great, ty | 18:19 |
| Wizzup | hm | 18:21 |
| Wizzup | # G_MESSAGES_DEBUG=all HAZE_PERSIST=1 HAZE_DEBUG=all /usr/lib/telepathy/telepathy-haze | 18:21 |
| Wizzup | /usr/lib/telepathy/telepathy-haze: error while loading shared libraries: libpurple.so.0: failed to map segment from shared object | 18:21 |
| freemangordon | what? | 18:22 |
| Wizzup | well, that is not supposed to happen right | 18:22 |
| freemangordon | no | 18:22 |
| freemangordon | lermme upgrade here | 18:23 |
| freemangordon | bbl 15 miunutes | 18:23 |
| Wizzup | works on on armhf it seems | 18:26 |
| Wizzup | freemangordon: maybe I start it wrong somehow | 18:36 |
| Wizzup | freemangordon: yes, nevermind | 18:36 |
| freemangordon | is it ok? | 18:39 |
| Wizzup | yes | 18:40 |
| Wizzup | I was starting it as root somehow | 18:40 |
| Wizzup | btw, how do you set purple specific params through mc-tool | 18:40 |
| Wizzup | like, some of these: https://github.com/dylex/slack-libpurple#configuration-options | 18:41 |
| freemangordon | why not use accounts-ui? | 18:41 |
| Wizzup | well, I am still working on the accounts-ui | 18:41 |
| freemangordon | ah | 18:41 |
| freemangordon | I used empathy | 18:41 |
| freemangordon | you just have to start it with SW GL | 18:41 |
| freemangordon | on d4 that is | 18:41 |
| Wizzup | hum | 18:42 |
| Wizzup | ok | 18:42 |
| Wizzup | I'll go and make some dinner and try thislater | 18:42 |
| freemangordon | you should be able to do it with mc-tool as well | 18:42 |
| Wizzup | mc-tool update: Protocol 'slack' does not have parameter 'enable_avatar_download' | 18:43 |
| freemangordon | no idea then | 18:44 |
| Wizzup | urgh empathy pulls modemmanager | 19:25 |
| freemangordon | so? | 19:35 |
| freemangordon | I don't have it installed here | 19:35 |
| Wizzup | I removed it again | 19:36 |
| Wizzup | some recommended thing in debian I guess | 19:36 |
| freemangordon | are you sure it is pulled and not recommends: ? | 19:36 |
| freemangordon | Wizzup: when you use mc-tool, you should provide correct parameter type | 19:37 |
| freemangordon | like bool:enable_avatar_download=true | 19:37 |
| Wizzup | freemangordon: probably recommends | 20:03 |
| Wizzup | freemangordon: I did that @ type | 20:04 |
| Wizzup | hm, it looks like slack-libpurple maps channels to ... people? | 20:08 |
| freemangordon | check in pidgin | 20:27 |
| Wizzup | well: Your "open" channels (on the slack bar) are mapped to the buddy list: joining a channel is equivalent to creating a buddy; | 20:34 |
| Wizzup | that is insane :D | 20:34 |
| freemangordon | in pidgin as well? | 20:37 |
| Wizzup | I need to test | 20:39 |
| freemangordon | yes, check with pidgin | 20:39 |
| Wizzup | it's ok in pidgin | 20:41 |
| Wizzup | at least there is a multi person icon | 20:42 |
| Wizzup | and I can see the participants | 20:42 |
| freemangordon | well, how do you know it is single person th TP then? | 20:45 |
| freemangordon | keep in mind I havent' implemented full room support in haze | 20:45 |
| Wizzup | sry phone call | 20:45 |
| freemangordon | just multi-channel supprot | 20:45 |
| freemangordon | umm... multi-user channel | 20:46 |
| freemangordon | before that only person-to-person chats worked | 20:46 |
| freemangordon | so there is lot more to implement | 20:46 |
| Wizzup | ok | 20:47 |
| freemangordon | also, how do you know it it is group chat or not? | 20:48 |
| freemangordon | in TP that is | 20:48 |
| freemangordon | you check the handle type? | 20:48 |
| Wizzup | sec :) | 20:48 |
| Wizzup | freemangordon: so in slack there are channels, multi user chats and single direct chats | 21:15 |
| Wizzup | the things I am talking about are channels in slack for sure, but maybe in pidgin not, if that was your question | 21:15 |
| Wizzup | in any case it could very well be some missing parts in haze as you mentioned | 21:15 |
| Wizzup | it was just interesting that I did get the messages in conversations, just not as part of a channel in tp it looked like | 21:16 |
| Wizzup | but maybe conversations doesn't handle multi user chats well yet :) | 21:16 |
| freemangordon | Wizzup: the question is: how conversations knows if it is multi-user chat or not? | 21:26 |
| freemangordon | because I think there is a difference between room and multi-user chat | 21:26 |
| freemangordon | my understanding is that rooms have separate handle type | 21:27 |
| freemangordon | while multi-user chat handle has 'groups' interface | 21:27 |
| freemangordon | but that's my understanding which is no necessarily correct | 21:28 |
| freemangordon | *not | 21:28 |
| Wizzup | freemangordon: I think it doesn't yet, because I also do not know how it works yet | 21:28 |
| Wizzup | fdo.org is slow agai | 21:29 |
| Wizzup | freemangordon: I think the groups interface is also for a channel | 21:30 |
| Wizzup | HandleTypeContact | 21:31 |
| Wizzup | A contact | 21:31 |
| Wizzup | HandleTypeRoom | 21:31 |
| Wizzup | A chat room | 21:31 |
| Wizzup | HandleTypeList | 21:31 |
| Wizzup | A server-generated contact list (see Channel.Interface.Group) | 21:31 |
| Wizzup | HandleTypeGroup | 21:31 |
| Wizzup | A user-defined contact list (see Channel.Interface.Group) | 21:31 |
| Wizzup | I think there's a lot about opaque identifiers and whatnot | 21:33 |
| Wizzup | https://web.archive.org/web/20231116152329/https://telepathy.freedesktop.org/spec/Channel_Interface_Room.html | 21:34 |
| freemangordon | so, to me at least multi-user chat Channel.Interface.Group | 21:35 |
| freemangordon | but again, that's my understanding | 21:35 |
| freemangordon | yet again, maybe I shall provide room handle for multi-user chats | 21:37 |
| Wizzup | I don't think it is that interface | 21:37 |
| Wizzup | that is the general interface for requesting users on rooms | 21:37 |
| Wizzup | I would find some more links but it's frustrating to navigate fdo when it's down | 21:38 |
| freemangordon | hmm... https://github.com/maemo-leste-upstream-forks/telepathy-haze/blob/maemo/chimaera-devel/src/mu-channel.c#L141 | 21:38 |
| Wizzup | in any case conversations assumes that anything is a room as long as: | 21:38 |
| Wizzup | if (channel->targetHandleType() == Tp::HandleTypeContact) | 21:38 |
| Wizzup | as not* | 21:38 |
| freemangordon | see the link ^^^ | 21:38 |
| Wizzup | I think everything is a room | 21:39 |
| freemangordon | ok, so seems I am doing proper thing | 21:39 |
| Wizzup | did you check: https://web.archive.org/web/20231116152329/https://telepathy.freedesktop.org/spec/Channel_Interface_Room.html | 21:39 |
| freemangordon | yes | 21:39 |
| Wizzup | ok | 21:39 |
| Wizzup | the way I see it there's no real difference in interface, just in some room properties | 21:42 |
| Wizzup | btw, the 'No name' bug is quite annoying | 21:43 |
| freemangordon | hmm, maybe I am not detecting properly what purple plugin implements | 21:45 |
| Wizzup | msgid "addr_li_unnamed_contact" | 21:46 |
| Wizzup | msgstr "No name" | 21:46 |
| freemangordon | hmm https://github.com/maemo-leste-upstream-forks/telepathy-haze/blob/maemo/chimaera-devel/src/connection.c#L600 | 21:47 |
| freemangordon | Wizzup: this is eds tp plugin thing | 21:47 |
| Wizzup | are you sure? | 21:48 |
| freemangordon | yes, names come from adress book, whick is created by eds tp plugin | 21:48 |
| Wizzup | I think some protocols maybe do not provide a nickname but only a targetid | 21:48 |
| Wizzup | ok, well, this string appears in osso-abook 3 times | 21:48 |
| Wizzup | $ grep -r addr_li_unnamed_contact lib/*.c | 21:49 |
| Wizzup | lib/osso-abook-contact.c: name = g_dgettext("osso-addressbook", "addr_li_unnamed_contact"); | 21:49 |
| Wizzup | lib/osso-abook-filter-model.c: gchar *unnamed_fold = g_utf8_casefold(_("addr_li_unnamed_contact"), -1); | 21:49 |
| freemangordon | well, if there is no name and nick, I don;t see what abook is supposed to do | 21:49 |
| Wizzup | lib/osso-abook-tree-view.c: contact_name = _("addr_li_unnamed_contact"); | 21:49 |
| Wizzup | targetid seems sensible | 21:49 |
| freemangordon | what is this? | 21:49 |
| Wizzup | persistent handle of the user on the protocol | 21:49 |
| freemangordon | in terms of vcard/eds? | 21:49 |
| freemangordon | heh | 21:49 |
| Wizzup | I mean, literally my entire xmpp address book is No name | 21:50 |
| freemangordon | abook uses EContact, which is EVCard as well | 21:50 |
| Wizzup | as well as the slack ones | 21:50 |
| Wizzup | and now I got a message from someone and remote_name because 'No name' :) | 21:50 |
| Wizzup | in this case the jabber address (somename@foo.org) would be better than 'No name', no? | 21:50 |
| freemangordon | could be, but that's not abook | 21:51 |
| freemangordon | again, it is eds tp plugin | 21:51 |
| freemangordon | abook uses vcards | 21:51 |
| freemangordon | motre or less | 21:51 |
| freemangordon | *more | 21:51 |
| freemangordon | bbl | 21:51 |
| Wizzup | I am looking at the plugin | 21:51 |
| Wizzup | freemangordon: regarding your link, yes, it seems like that would be good @ target handles | 21:52 |
| Wizzup | freemangordon: the funniest thing is that if you click on a No name contact, it will show the network handle | 22:02 |
| Wizzup | so clearly it knows and gets the info somehow | 22:02 |
| freemangordon | Wizzup: does it have proper names in fremantle? | 22:11 |
| freemangordon | https://github.com/maemo-leste/eds-backend-telepathy/blob/master/src/e-book-backend-tp-contact.c#L248 | 22:12 |
| freemangordon | :p | 22:12 |
| Wizzup | yes | 22:14 |
| freemangordon | in abook? | 22:15 |
| freemangordon | hmm | 22:15 |
| freemangordon | maybe abook in fremantle is doing something more | 22:17 |
| Wizzup | my yes was @ your link | 22:17 |
| Wizzup | not @ fremantle | 22:17 |
| Wizzup | I will have to check in fremantle | 22:17 |
| freemangordon | have to go now, will check tomorrow if I have missed somethiong in abook | 22:18 |
| freemangordon | please verify in fremantle in the meanwhile | 22:18 |
| freemangordon | if possibl | 22:18 |
| freemangordon | e | 22:18 |
| Wizzup | I have never seen it there but will check | 22:27 |
| freemangordon | Wizzup: maybe debug through osso_abook_contact_get_name_components() to see why it fails | 22:58 |
| freemangordon | or register an account for me to test | 22:58 |
| Wizzup | freemangordon: do you have any xmpp account? | 23:05 |
| Wizzup | freemangordon: but yes, I will register you one with me (didn't I already? I forgot) | 23:05 |
| freemangordon | lemme check | 23:05 |
| freemangordon | no, I don;t have any xmpp account | 23:06 |
| freemangordon | ok, I am online there, but I see no contacts | 23:09 |
| freemangordon | so maybe the sever does not provide contact list | 23:10 |
| * enyc meows :O | 23:11 | |
| enyc | no news for a while? hrrm | 23:11 |
| Wizzup | freemangordon: do you have any contacts? | 23:13 |
| freemangordon | no | 23:13 |
| Wizzup | brb 2mins | 23:13 |
| freemangordon | lets continue tomorrow | 23:13 |
| Wizzup | ok | 23:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!