| Wizzup | freemangordon: can you look at this tomorrow? https://phoenix.maemo.org/job/hildon-input-method-configurator-binaries/architecture=amd64,label=amd64/16/console | 02:55 |
|---|---|---|
| Wizzup | looks like we have two hildon-im-protocol.h | 02:55 |
| Wizzup | In file included from /usr/include/hildon-input-method/hildon-im-ui.h:34, | 02:55 |
| Wizzup | from /usr/include/hildon-input-method/hildon-im-ui.h:26: | 02:55 |
| Wizzup | oh I suppose this just needs some ifdef guard | 02:55 |
| Wizzup | I'll look tomorrow | 02:57 |
| Wizzup | hm the error is not there on chimaera | 03:04 |
| Wizzup | I think | 03:04 |
| freemangordon | Wizzup: MAEMO_CHANGES is not defined | 08:28 |
| freemangordon | thats not good | 08:29 |
| freemangordon | fails in chimaera VM as well | 08:33 |
| freemangordon | MAEMO_CHANGES is defined by hildon-1.pc | 08:34 |
| freemangordon | but it is not used | 08:34 |
| freemangordon | https://github.com/maemo-leste/hildon-input-method-framework/commit/a38e68ad9933433b9d1baef266572f44ade26e5d | 08:35 |
| freemangordon | perhaps hildon-input-method-configurator was build before that patch | 08:36 |
| freemangordon | Wizzup: fixed | 09:20 |
| freemangordon | dsc_: so, on fremantle, it is /usr/share/telepathy/clients/NotificationUI.client that does the authorization requests | 09:21 |
| freemangordon | but, it takes care of everything, like incoming sms-es, chats, calls, whatnot | 09:22 |
| freemangordon | I am tempted to RE it though | 09:24 |
| freemangordon | hmm, I will have to | 09:39 |
| freemangordon | this is the one that shows call icon in the status menu | 09:39 |
| Wizzup | freemangordon: thx | 10:03 |
| Wizzup | freemangordon: we can show the call icon in the status menu, it's not that hard I think | 10:03 |
| freemangordon | Wizzup: who are 'we'? | 10:06 |
| freemangordon | I know we can, but we don;t | 10:07 |
| freemangordon | who will do that? sphone? conversations? | 10:07 |
| Wizzup | status applet? | 10:07 |
| freemangordon | that's what I am on | 10:07 |
| freemangordon | the one from fremantle that does it :) | 10:07 |
| Wizzup | can't it use connui-cellular to get call state, or monitor dbus mce call state change? | 10:07 |
| freemangordon | it can | 10:07 |
| Wizzup | ok, it seemed like you said you'd RE the other parts too | 10:08 |
| freemangordon | maybe I will | 10:08 |
| freemangordon | depends on what they do | 10:08 |
| freemangordon | BTW in fremantle it listens to TP for call state, iiuc | 10:08 |
| freemangordon | which makes sense | 10:09 |
| freemangordon | Wizzup: also, I think MFA belongs to the same plugin | 11:22 |
| Wizzup | I don't know if that is the case | 12:35 |
| freemangordon | what do you mean? | 12:39 |
| freemangordon | someone shall register with TP for MFA, no? | 12:39 |
| freemangordon | please elaborate, it is possible taht I am missing something | 12:40 |
| 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 | 12:55 |
| freemangordon | no, I mean that the same place we handle auth requests is good place to handle MFA as well | 12:55 |
| sicelo | mfa would be in whatever handles adding/registering the account | 12:55 |
| freemangordon | it does not work like that with TP | 12:56 |
| sicelo | oh | 12:56 |
| freemangordon | you should register some kind of agent to handle MFA and friends | 12:56 |
| freemangordon | in fremantle incoming friend requests are handled in rtcom-notifications-ui | 12:57 |
| freemangordon | it also handles call status icon | 12:57 |
| freemangordon | that's why I think it is also a good place to handle MFA etc | 12:58 |
| freemangordon | are there any issues with that? | 13:00 |
| sicelo | sounds unintuitive, but I guess that's due to lack of understanding of TP | 13:00 |
| sicelo | how does TP handle account password? e.g. Facebook | 13:01 |
| freemangordon | see https://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html | 13:03 |
| freemangordon | simple password is another story | 13:03 |
| 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." | 13:03 |
| freemangordon | so, someone shall handle Channel.Interface.SASLAuthentication | 13:04 |
| freemangordon | if we want to stay compliant ofc :) | 13:04 |
| freemangordon | otherwise everyone and her dog may implement whatever UI she likes, but I guess that's not teh point | 13:05 |
| sicelo | ah, I see | 13:07 |
| sicelo | looks like that can also work for e2e (matrix,telegram) | 13:09 |
| freemangordon | mhm | 13:09 |
| freemangordon | and it is better to be in a system-wide service | 13:10 |
| 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. | 13:10 |
| freemangordon | that way we do not depend on particular UI (call, chat, etc) | 13:10 |
| sicelo | so basically with TP, the MFA challenge is like chatting with a first friend ... | 13:15 |
| freemangordon | could be, I lack the details | 13:15 |
| Wizzup | 12:40 < freemangordon> please elaborate, it is possible taht I am missing something | 13:38 |
| Wizzup | I am not sure if that should be the status applet of conversations | 13:38 |
| Wizzup | maybe for login tokens it can be status | 13:38 |
| Wizzup | for friend auth requests it shouldn't be | 13:38 |
| Wizzup | I think? | 13:38 |
| Wizzup | conversations ought to handle those I think | 13:38 |
| freemangordon | Wizzup: why should conversations handle it? | 13:56 |
| freemangordon | like, how it is better if handled in conversations? | 13:57 |
| freemangordon | if we do chat/auth/mfa/etc notifications out of convaersations, this https://github.com/maemo-leste/conversations/tree/master/src/lib/libnotify-qt will be gone | 13:59 |
| freemangordon | I don;t think having libnotify-qt being a part of conversations is the best approach | 14:00 |
| Wizzup | that won't be hard I think | 14:25 |
| Wizzup | we can just package it | 14:25 |
| freemangordon | ok, but how it is better? | 14:26 |
| Wizzup | because conversations is the program that logs/writes chat messages, so it only makes sense to deal with ayth reqs | 14:26 |
| Wizzup | I didn't say mfa | 14:26 |
| freemangordon | ATM it is abopok that sends auth requests | 14:26 |
| freemangordon | *abook | 14:26 |
| freemangordon | shall we remove that as well? | 14:26 |
| Wizzup | I thought the auth reqs were part of the conversations dev tree currently, am I wrong? | 14:27 |
| freemangordon | you are | 14:27 |
| Wizzup | if it goes through abook then that's ok with me | 14:27 |
| Wizzup | doing -all- notifications throug the status menu (of chat messages) seems wrong to me | 14:27 |
| freemangordon | it is not only about chat | 14:27 |
| freemangordon | err... | 14:27 |
| Wizzup | then let's not make status do chat :) | 14:27 |
| freemangordon | it is not about chat | 14:28 |
| freemangordon | it is about auth | 14:28 |
| Wizzup | >if we do chat/auth/mfa/etc notifications out of convaersation | 14:28 |
| freemangordon | also, voice mail notification is there | 14:28 |
| Wizzup | You suggest here to do chat notificatios out of conversations | 14:28 |
| freemangordon | yes | 14:28 |
| Wizzup | and I'm saying I think that's not a good idea | 14:28 |
| freemangordon | that way *all* rtcom notifications will be in one place, IIUC | 14:29 |
| freemangordon | so call ui will not have to take care of missed calls etc | 14:29 |
| freemangordon | notifying that is | 14:29 |
| Wizzup | but, why? | 14:30 |
| Wizzup | we have it working now | 14:30 |
| Wizzup | why go through all the effort to make all the business logic in a status applet | 14:31 |
| freemangordon | we don; at least does not work properly | 14:31 |
| freemangordon | unless I am missing something | 14:31 |
| 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 | 14:33 |
| freemangordon | for now I will implement at least call status icon | 14:33 |
| freemangordon | ok? | 14:36 |
| Wizzup | sure | 14:36 |
| 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 | 14:37 |
| Wizzup | handling incoming auth requests/2fa is very different | 14:37 |
| freemangordon | right | 14:38 |
| freemangordon | so at least auth request shall go there IMO | 14:39 |
| freemangordon | incoming auth request handling that is | 14:39 |
| Wizzup | I am fine with that, I wonder what dsc thinks | 14:47 |
| Wizzup | I ma back to more daedalus today, hopefully make it so that things can boot with network working | 14:48 |
| freemangordon | I think he'll be fine with that | 14:48 |
| freemangordon | dsc_: ^^^ | 14:48 |
| sicelo | Wizzup: ah, that's why wlan doesn't want to connect on the L5, is it? | 14:58 |
| sicelo | seemed that icd2 segfaults or something (but it was late at night and i was exhausted.) | 15:05 |
| Wizzup | sicelo: yeah | 15:55 |
| Wizzup | probably | 15:55 |
| Wizzup | libwpa is an .a file | 15:55 |
| Wizzup | so we need to rebuild it | 15:55 |
| Wizzup | gimme a few hours | 15:55 |
| 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 | 16:44 |
| freemangordon | I thinkth it is tracker 3.x there | 16:53 |
| freemangordon | *think | 16:53 |
| freemangordon | which means I will have to port mafw stuff | 16:53 |
| freemangordon | and no, I think we shall not build our own tracker, we fixed bugs there, no? | 16:53 |
| Wizzup | I am not sure about the last statement | 16:56 |
| Wizzup | we definitely fixed bugs and/or cherry picked fixes | 16:56 |
| freemangordon | I meant: I don;t think we shall build our tracker fork, as it is 2.x | 16:58 |
| freemangordon | and we just fixed some bugs in it | 16:58 |
| freemangordon | daedalus comes with 3.x (if I saw that correctly yesterday doing dist-upgarde on sicelo's L5) | 16:59 |
| freemangordon | I assume the patches we cherry-picked in our tracer are already in 3.x | 16:59 |
| freemangordon | sounds sane? | 17:00 |
| Wizzup | yeah I think so | 17:00 |
| freemangordon | ok | 17:00 |
| Wizzup | and I think this means that mafw-tracker-source should not be build yet since it needs tracker 3+ | 17:00 |
| Wizzup | if I got this right? | 17:01 |
| freemangordon | most-probably you can;t build it | 17:02 |
| freemangordon | so yeah, do not try to | 17:03 |
| freemangordon | LMK when we are at it | 17:03 |
| freemangordon | I will port it | 17:03 |
| Wizzup | I can try to build it if you want, it's next up | 17:06 |
| Wizzup | but I can continue and ignore it for the time being, so it's not a blocker | 17:06 |
| Wizzup | fyi https://github.com/maemo-leste/bugtracker/issues/751 | 17:06 |
| freemangordon | not bad :) | 17:07 |
| Wizzup | I will make a lot more progress toda | 17:10 |
| Wizzup | y | 17:10 |
| freemangordon | mafw-upnp-source? did it ever compile? | 17:13 |
| Wizzup | probably not, I will check it later | 17:22 |
| Wizzup | I guess we need to sort out mesa too | 17:24 |
| Wizzup | maybe our chimaera mesa is newer than daedalus still | 17:24 |
| Wizzup | (since we have our own) | 17:25 |
| Wizzup | ah no, we're on 21.x and daedalus is 22.x | 17:26 |
| sicelo | :-) | 17:29 |
| sicelo | and that was the blocker for L5 all along | 17:29 |
| Wizzup | mesa? | 17:33 |
| Wizzup | not xorg? | 17:33 |
| sicelo | actually both | 17:33 |
| 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 | 17:34 |
| sicelo | or status menu showing up all black, until i press the buttons 'blind' | 17:35 |
| Wizzup | hmm, ok | 17:35 |
| Wizzup | I was hoping we wouldn't, but we will see :D | 17:35 |
| Wizzup | then we also need newer libdri, libglvd, libdrm, etc | 17:36 |
| Wizzup | but it's ok, we did that in the past oto, so | 17:36 |
| Wizzup | too, so | 17:36 |
| sicelo | yeah i'll test properly during course of the upcoming week. | 17:36 |
| Wizzup | freemangordon: do I still build libgofono for daedalus? | 17:43 |
| Wizzup | or do we not need it with the upcoming connui-cellular | 17:43 |
| Wizzup | iirc we don't, right? | 17:43 |
| freemangordon | we don;t, but icd plugin still requires it | 17:44 |
| Wizzup | oh? | 17:46 |
| Wizzup | ok | 17:46 |
| freemangordon | https://github.com/maemo-leste/libicd-network-ofono/blob/master/debian/control#L5 | 17:47 |
| Wizzup | yes I see | 17:50 |
| dsc_ | <freemangordon> I think he'll be fine with that | 22:39 |
| dsc_ | yes, as long as the UX is good, user should be #1 | 22:39 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!