f_ has quit [Read error: Connection reset by peer]
f_ has joined #maemo-leste
elastic_dog has joined #maemo-leste
lexik has quit [Ping timeout: 252 seconds]
lexik has joined #maemo-leste
CynicalDebian has joined #maemo-leste
CynicalDebian is now known as mqlnv
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
fab_ has joined #maemo-leste
mdz has joined #maemo-leste
akossh has joined #maemo-leste
Pali has joined #maemo-leste
Pali has quit [Quit: Pali]
uvos__ has joined #maemo-leste
<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
<uvos__>
maybe we can create a notification but not log the call as missed or something
<uvos__>
needs sphone internal module api changes
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
<freemangordon>
uvos__: I think the proper way to do it is to log it ass rejected call
<freemangordon>
*as
<freemangordon>
and to mark it as such in the UI
<freemangordon>
uvos__: also, did you see the issue I found with the sound driver?
<freemangordon>
Wizzup: I wonder isn't it better to get rid of glibofono in connui-cell
<Wizzup>
freemangordon: ok
<Wizzup>
freemangordon: because of the sync issues, or?
<freemangordon>
because they expose almost no method
<freemangordon>
besides modem methiods, there is nothing else
<freemangordon>
to me it is easier do generate our gdbus wrappers than to make MRs to SF
<freemangordon>
*to
<freemangordon>
esp when our api is expected to be synchronous
<uvos__>
freemangordon: no what issue in the sound driver
<uvos__>
i noticed that since we updated pa
<uvos__>
the volumes stopped restoreing
<freemangordon>
so you think it is PA issue?
<uvos__>
i dont know what issue you are talking about
<uvos__>
i noticed that the volumes no longer restore
<freemangordon>
sec
<uvos__>
but maybe thats just because we changed pa to run as user
<uvos__>
and some file on my system is now owned by root
<uvos__>
and it cant update it
<uvos__>
or something
<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
<Wizzup>
freemangordon: fine by me
<uvos__>
ok
<uvos__>
well the driver dose some really hacky stuff when a call is started
<freemangordon>
uvos__: to me it seems there is some race or other issue in the driver
<uvos__>
iirc the driver just clobbers some registers
<uvos__>
that subsiquently the alsa framework dosent know about
<uvos__>
should restore them after the call however
<freemangordon>
so I commented out enabling modem dai on incomming call (but before it is accepted) and the issue is gone
<freemangordon>
but thta'
<freemangordon>
...
<freemangordon>
but that's just a hack
<uvos__>
yeah the modem dai is not used in a call
freemangordon has quit [Quit: Leaving.]
<uvos__>
its just for recording audio
<uvos__>
the whole thing is a huge hack
<uvos__>
(voice call on mapphones)
freemangordon has joined #maemo-leste
<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
<freemangordon>
sorry, gnome crashed
<freemangordon>
so, what needs to be done here?
<freemangordon>
*there
<freemangordon>
we use ucm, right?
<uvos__>
yes
<freemangordon>
don;t we have the proper controls exported?
<uvos__>
but this isent about that
<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
<uvos__>
or at least we dont know how this is supposed to fit in
<uvos__>
tmlind did in the past, to not that mutch sucess iirc, but yeah we could try again
<freemangordon>
we'd better do, as now it is very buggy
<freemangordon>
tmlind: could you point me to ^^^
<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
<uvos__>
but dont qoute me on that
<uvos__>
the volumes def also stoped restoreing (on boot and on hp plug) thats def a pa bug we also have
arno11 has joined #maemo-leste
<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 !)
<arno11>
it happens when i connect a FB account
<Wizzup>
ok, there's been a pretty big rework so it might be solved by now
<arno11>
ok
<arno11>
otherwise it works very well with almost no cpu usage or ram
<Wizzup>
do you know if you do anything in particular?
<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
<arno11>
Wizzup: apparently not
<Wizzup>
arno11: ok, well I want to make a few more changes/checks but then I will cut a release
<Wizzup>
there's still abook integration to be done
<Wizzup>
but there are a lot of rtcom logging improvements
<arno11>
ok cool
<Wizzup>
and yes, then we will have to hunt for memory issues
<Wizzup>
for it to work well you might have ot nuke the existing rtcom db
<Wizzup>
I'm making some more logging changes to make it (fully) compatible with fremantle
sch has quit [Ping timeout: 256 seconds]
sch has joined #maemo-leste
<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
<Wizzup>
for irc it is just the nickname
<Wizzup>
I guess irc isn't federated and jabber is, so that makes some sense then
<arno11>
you mean the nicknames shown in conversation windows ?
<Wizzup>
arno11: nah just sql logging
<arno11>
ah ok
arno11 has left #maemo-leste [#maemo-leste]
Daanct12 has quit [Quit: WeeChat 4.1.2]
<Wizzup>
ok, figured it out I think
fab_ has quit [Ping timeout: 245 seconds]
joerg is now known as DocScrutinizer
DocScrutinizer is now known as joerg
arno11 has joined #maemo-leste
<arno11>
Wizzup: btw do you have an idea why some services show proper nicknames and not others ?
<Wizzup>
what do they show if not the nickname?
<Wizzup>
I see '(No name)' in contacts, but I presume you are referring to something else
<arno11>
for example irc (and irc through bitlbee/conversations) and skype show proper nicknames in chat windows
<arno11>
not working for sip or FB
<arno11>
SIP shows full address and FB showa an 'ID' number
<arno11>
*shows
<arno11>
instead of nicknames/names
<Wizzup>
hm, right
<Wizzup>
so this is complicated, but this is what I am working on now, now that I think the logging is fixed
<Wizzup>
there is a nickname property for some of these, but for the actual logging we want to set the id
<Wizzup>
and what we need to do is to log the nickname in remote_name and the id in remote_uid
<arno11>
ok
<Wizzup>
and then optionally also use abook to resolve the remote ids to contacts
<Wizzup>
at least that is what I am thinking right now
<Wizzup>
I need to fix two regressions in conversations and then it can go to -devel I think
<arno11>
ok :)
<Wizzup>
as far as the mem usage goes, let's debug that soon too
<Wizzup>
I haven't paid too much attention to this but for the qt part I think it should just be ok
<Wizzup>
was the memory usage you saw in tp-haze or conversations\
<Wizzup>
(or both)
<arno11>
only with conversations
<arno11>
tp haze increase cpu and ram only for few sec when connecting
<Wizzup>
ok
<arno11>
btw how can i disable the --background option ? (just to test if there is a diff)
sch has quit [Remote host closed the connection]
<Wizzup>
arno11: I don't think you need to test this
<Wizzup>
but background is only default in dsme
<arno11>
yeah ok
<Wizzup>
ok yeah now I remember, for mapping im usernames to their display name I have to map a Telepathy::Account to TpAccount*
<freemangordon>
not sure how to deal with upstream
<freemangordon>
add commits as patches?
<Wizzup>
freemangordon: don't really care tbh
<Wizzup>
I suspect we'd become upstream eventually
<freemangordon>
Wizzup: hmm, your sip address is missing sip://
<Wizzup>
let me see, I might not be passing the right info then
<freemangordon>
there is a bug in abook, but still
<uvos__>
honestly the storage format is also just bad
<uvos__>
im not sure keeping absolute fremantle compatability is a good idea
<uvos__>
like the fact that tel is just randomly not a url is pretty dumb
<uvos__>
as is the almost random fromat of some other fields
<uvos__>
like the local/remote ids
<freemangordon>
remote id is EDS uid if available
<freemangordon>
which is, in most cases
<freemangordon>
unless I am missing something
<Wizzup>
what storage format?
<freemangordon>
Wizzup: re haze - it is about debian packaging
<freemangordon>
I am not sure what is better
<Wizzup>
freemangordon: yeah, have no strong preference, I would just add them as commits and cut some small minor release for us for now
<Wizzup>
I don't expect upstream to do anything
<Wizzup>
there is no maintainer afaict
<Wizzup>
uvos__: actually I'm starting to like the rtcom format, it makes a lot more sense once you grok it
<Wizzup>
freemangordon: I don't think patches vs commits matters
<freemangordon>
bot are not fine, because I used upstream code, not debian one
<freemangordon>
and they differ
<freemangordon>
but ok, will just impland debian dir
<Wizzup>
what did debian change
<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
<freemangordon>
nothing, they are just few commits behind
<uvos__>
and creates headaches
<Wizzup>
conversations should (in my branch) deal with it well atm
<Wizzup>
for sip, sms, tel, etc
<Wizzup>
there are some oddities I would agree, like the group_uid for smses
<freemangordon>
Wizzup: please make user you have master contact id logged properly
<Wizzup>
freemangordon: can't parse
<freemangordon>
*make sure
<Wizzup>
do you mean the osso_abook_id ?
<freemangordon>
yes
<Wizzup>
well, I can't do that part yet until I have the conversion to TpAccount
<freemangordon>
this is basically EDS master contact UID
<Wizzup>
but apart from this, everything else seems to be alright now
<Wizzup>
there is some code to clean up too I suppose
<freemangordon>
ok
<freemangordon>
I am just reminding :)
<Wizzup>
is it necessary for the abook api to get a TpAccount* ?
<Wizzup>
can't we just give it a string describing where to find the account?
<Wizzup>
in any case does abook need any of the tp properties, or is it just going to extract the backend name
<Wizzup>
and local_uid
<freemangordon>
no, it needs it to find the master contact
<freemangordon>
not only the backend
<freemangordon>
see osso_abook_aggregator_find_contacts_full()
<Wizzup>
sorry I still don't really understand what the 'master contact' is
<freemangordon>
lemme try to explain
<freemangordon>
for each person in your abook, you have one *master* contact and zero or more *roster* contacts
<freemangordon>
master contact is there no matter online/offline etc
<freemangordon>
so, in your abook, my master contact contains my tel, email, nickname etc
<Wizzup>
mhm
<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
<freemangordon>
and when you merge contacts (from jabber, for example), you attach my jabber username to my master contact
<freemangordon>
sicelo: just a sec please
<freemangordon>
and that way jabber actions appear when you click on 'ivo' in the abook
<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?
<freemangordon>
Wizzup: is it cleraere now?
<freemangordon>
*clearer
<Wizzup>
yes, but not why you need a TpAccount for it
<Wizzup>
this is what is stored in the rtcom db as remote_uid
<Wizzup>
well, wait
<Wizzup>
local_uid in this case
<Wizzup>
what I mean to say is what TpAccount* to my knowledge doesn't contain anything special here
<Wizzup>
what you do to match TpAccount* to eds can be done without the Tpaccount*, you just need specific info
<Wizzup>
but it seems like it's easier if I just add a third accountmanager to conversations ;)
<freemangordon>
Wizzup: this is just the API that's exported
<freemangordon>
see osso_abook_aggregator_find_contacts_full
<freemangordon>
you can use it directly
<Wizzup>
I don't know what it does and what a OssoABookContactPredicate is :)