<freemangordon>
perhaps hildon-input-method-configurator was build before that patch
<freemangordon>
Wizzup: fixed
<freemangordon>
dsc_: so, on fremantle, it is /usr/share/telepathy/clients/NotificationUI.client that does the authorization requests
<freemangordon>
but, it takes care of everything, like incoming sms-es, chats, calls, whatnot
<freemangordon>
I am tempted to RE it though
<freemangordon>
hmm, I will have to
<freemangordon>
this is the one that shows call icon in the status menu
<Wizzup>
freemangordon: thx
xmn has quit [Quit: ZZZzzz…]
<Wizzup>
freemangordon: we can show the call icon in the status menu, it's not that hard I think
xmn has joined #maemo-leste
<freemangordon>
Wizzup: who are 'we'?
<freemangordon>
I know we can, but we don;t
<freemangordon>
who will do that? sphone? conversations?
<Wizzup>
status applet?
<freemangordon>
that's what I am on
<freemangordon>
the one from fremantle that does it :)
<Wizzup>
can't it use connui-cellular to get call state, or monitor dbus mce call state change?
<freemangordon>
it can
<Wizzup>
ok, it seemed like you said you'd RE the other parts too
<freemangordon>
maybe I will
<freemangordon>
depends on what they do
<freemangordon>
BTW in fremantle it listens to TP for call state, iiuc
<freemangordon>
which makes sense
Anasko has joined #maemo-leste
Twig has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
Livio has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<freemangordon>
Wizzup: also, I think MFA belongs to the same plugin
xmn has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Daanct12 has quit [Quit: WeeChat 4.4.3]
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
Livio has quit [Ping timeout: 260 seconds]
<Wizzup>
I don't know if that is the case
akossh has joined #maemo-leste
<freemangordon>
what do you mean?
<freemangordon>
someone shall register with TP for MFA, no?
<freemangordon>
please elaborate, it is possible taht I am missing something
<sicelo>
MFA ... multi factor auth? What authorization requests did you mean? if incoming friend requests, then MFA doesn't sound like a good fit for that
<freemangordon>
no, I mean that the same place we handle auth requests is good place to handle MFA as well
<sicelo>
mfa would be in whatever handles adding/registering the account
<freemangordon>
it does not work like that with TP
<sicelo>
oh
<freemangordon>
you should register some kind of agent to handle MFA and friends
<freemangordon>
in fremantle incoming friend requests are handled in rtcom-notifications-ui
<freemangordon>
it also handles call status icon
<freemangordon>
that's why I think it is also a good place to handle MFA etc
<freemangordon>
are there any issues with that?
<sicelo>
sounds unintuitive, but I guess that's due to lack of understanding of TP
<sicelo>
how does TP handle account password? e.g. Facebook
<freemangordon>
"This can be used to connect to protocols that may require a password, without requiring that the password is saved in the Account.Parameters."
<freemangordon>
so, someone shall handle Channel.Interface.SASLAuthentication
<freemangordon>
if we want to stay compliant ofc :)
<freemangordon>
otherwise everyone and her dog may implement whatever UI she likes, but I guess that's not teh point
<sicelo>
ah, I see
<sicelo>
looks like that can also work for e2e (matrix,telegram)
<freemangordon>
mhm
<freemangordon>
and it is better to be in a system-wide service
<sicelo>
. In future, it could also be used to authenticate with secondary services, or even to authenticate end-to-end connections with contacts. As a result, this interface does not REQUIRE ServerAuthentication to allow for a potential future Channel.Type.PeerAuthentication interface.
<freemangordon>
that way we do not depend on particular UI (call, chat, etc)
<sicelo>
so basically with TP, the MFA challenge is like chatting with a first friend ...
<freemangordon>
could be, I lack the details
<Wizzup>
12:40 < freemangordon> please elaborate, it is possible taht I am missing something
<Wizzup>
I am not sure if that should be the status applet of conversations
<Wizzup>
maybe for login tokens it can be status
<Wizzup>
for friend auth requests it shouldn't be
<Wizzup>
I think?
<Wizzup>
conversations ought to handle those I think
Livio has joined #maemo-leste
<freemangordon>
Wizzup: why should conversations handle it?
<freemangordon>
like, how it is better if handled in conversations?
<freemangordon>
I don;t think having libnotify-qt being a part of conversations is the best approach
<Wizzup>
that won't be hard I think
<Wizzup>
we can just package it
<freemangordon>
ok, but how it is better?
<Wizzup>
because conversations is the program that logs/writes chat messages, so it only makes sense to deal with ayth reqs
<Wizzup>
I didn't say mfa
<freemangordon>
ATM it is abopok that sends auth requests
<freemangordon>
*abook
<freemangordon>
shall we remove that as well?
<Wizzup>
I thought the auth reqs were part of the conversations dev tree currently, am I wrong?
<freemangordon>
you are
<Wizzup>
if it goes through abook then that's ok with me
<Wizzup>
doing -all- notifications throug the status menu (of chat messages) seems wrong to me
<freemangordon>
it is not only about chat
<freemangordon>
err...
<Wizzup>
then let's not make status do chat :)
<freemangordon>
it is not about chat
<freemangordon>
it is about auth
<Wizzup>
>if we do chat/auth/mfa/etc notifications out of convaersation
<freemangordon>
also, voice mail notification is there
<Wizzup>
You suggest here to do chat notificatios out of conversations
<freemangordon>
yes
<Wizzup>
and I'm saying I think that's not a good idea
<freemangordon>
that way *all* rtcom notifications will be in one place, IIUC
<freemangordon>
so call ui will not have to take care of missed calls etc
<freemangordon>
notifying that is
<Wizzup>
but, why?
<Wizzup>
we have it working now
<Wizzup>
why go through all the effort to make all the business logic in a status applet
<freemangordon>
we don; at least does not work properly
<freemangordon>
unless I am missing something
<freemangordon>
ok, let me gain a better understanding of what this notifications-ui is doing. I will explain in details and will have another discussion then
<freemangordon>
for now I will implement at least call status icon
<freemangordon>
ok?
<Wizzup>
sure
<Wizzup>
I'd just hate for us to have re-do all the work we put in conversations and rtcom logging of all the messages + notifications
<Wizzup>
handling incoming auth requests/2fa is very different
<freemangordon>
right
<freemangordon>
so at least auth request shall go there IMO
<freemangordon>
incoming auth request handling that is
<Wizzup>
I am fine with that, I wonder what dsc thinks
<Wizzup>
I ma back to more daedalus today, hopefully make it so that things can boot with network working
<freemangordon>
I think he'll be fine with that
<freemangordon>
dsc_: ^^^
<sicelo>
Wizzup: ah, that's why wlan doesn't want to connect on the L5, is it?
<sicelo>
seemed that icd2 segfaults or something (but it was late at night and i was exhausted.)
Livio has quit [Ping timeout: 260 seconds]
akossh has quit [Quit: Leaving.]
<Wizzup>
sicelo: yeah
<Wizzup>
probably
<Wizzup>
libwpa is an .a file
<Wizzup>
so we need to rebuild it
<Wizzup>
gimme a few hours
pere has quit [Ping timeout: 260 seconds]
<Wizzup>
freemangordon: I haven't looked at daedalus and gnome tracker, do we want to build our own tracker forks for now? I don't think we have to worry about this now necessarily, just wondering
pere has joined #maemo-leste
<freemangordon>
I thinkth it is tracker 3.x there
<freemangordon>
*think
<freemangordon>
which means I will have to port mafw stuff
<freemangordon>
and no, I think we shall not build our own tracker, we fixed bugs there, no?
<Wizzup>
I am not sure about the last statement
<Wizzup>
we definitely fixed bugs and/or cherry picked fixes
<freemangordon>
I meant: I don;t think we shall build our tracker fork, as it is 2.x
<freemangordon>
and we just fixed some bugs in it
<freemangordon>
daedalus comes with 3.x (if I saw that correctly yesterday doing dist-upgarde on sicelo's L5)
<freemangordon>
I assume the patches we cherry-picked in our tracer are already in 3.x
<freemangordon>
sounds sane?
<Wizzup>
yeah I think so
<freemangordon>
ok
<Wizzup>
and I think this means that mafw-tracker-source should not be build yet since it needs tracker 3+
<Wizzup>
if I got this right?
<freemangordon>
most-probably you can;t build it
<freemangordon>
so yeah, do not try to
<freemangordon>
LMK when we are at it
<freemangordon>
I will port it
<Wizzup>
I can try to build it if you want, it's next up
<Wizzup>
but I can continue and ignore it for the time being, so it's not a blocker
<freemangordon>
mafw-upnp-source? did it ever compile?
<Wizzup>
probably not, I will check it later
<Wizzup>
I guess we need to sort out mesa too
<Wizzup>
maybe our chimaera mesa is newer than daedalus still
<Wizzup>
(since we have our own)
<Wizzup>
ah no, we're on 21.x and daedalus is 22.x
<sicelo>
:-)
<sicelo>
and that was the blocker for L5 all along
<Wizzup>
mesa?
<Wizzup>
not xorg?
<sicelo>
actually both
<sicelo>
in fact we may need an even newer mesa than what's in daedalus. i still had stuff not redrawing, e.g. vkb all black, and letters appear only when i touch them
<sicelo>
or status menu showing up all black, until i press the buttons 'blind'
<Wizzup>
hmm, ok
<Wizzup>
I was hoping we wouldn't, but we will see :D
<Wizzup>
then we also need newer libdri, libglvd, libdrm, etc
<Wizzup>
but it's ok, we did that in the past oto, so
<Wizzup>
too, so
<sicelo>
yeah i'll test properly during course of the upcoming week.
<Wizzup>
freemangordon: do I still build libgofono for daedalus?
<Wizzup>
or do we not need it with the upcoming connui-cellular
<Wizzup>
iirc we don't, right?
<freemangordon>
we don;t, but icd plugin still requires it