Tuesday, 2019-04-09

*** keithzg__ is now known as keithzg_00:01
*** zbenjamin is now known as Guest7612501:16
*** zbenjamin_ is now known as zbenjamin01:16
dcalisteHello chriadam, how are you ?06:45
chriadamhi dcaliste, I'm well thanks!06:45
chriadamhow are you?06:45
dcalisteFine also thanks. I've looked at the upsyncing on change in jolla-calendar.06:46
chriadamah nice, hopefully simple solution?06:47
chriadamseems fairly simple.  the fact that it requests the profiles from the buteo profile manager, based on the accountId filter is interesting - I hope we set the accountId appropriately in all sync profiles06:52
chriadamthanks very much for doing that work.  I don't think I'll get a chance to test it this week, but hopefully next week.06:52
dcalisteSorry, got interrupted by a collegue in the lab…06:54
dcalistewell, see https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/22806:54
dcalisteThe trick, was that only the notebook id is available at nemo-qml-plugin-calendar, not the account id.06:55
dcalisteSo, I gather all the calendar ids, and accumulate them during the last ten seconds, like you did for changes.06:55
dcalisteAnd, when it's time to sync, I use some mKCal calls to get the account id from notebook ids.06:56
dcalisteThat's a simple patch on existing solution.06:56
dcalisteTo put it in Buteo, I've looked at it closely last week.06:56
dcalisteIt's missing some bits in the current API, in my opinion.06:56
dcalisteAs far as I can see, it's not used at the moment at all. It's implemented for hcontacts scheme only, but there is no plugin installed on device.06:58
dcalisteI can extend it for hcalendars, and create a plugin.06:58
dcalisteThis plugin will trigger changed() on every change in the mKCal database, without specifying from which notebook, and thus from which account it is originating.06:59
chriadamlet's ignore it for now.  in future, I really want to refactor buteo altogether06:59
chriadamand when we do that, we can make sure the interfaces allow the granularity we want06:59
dcalisteThe idea is to add the accountId in the changed() signal.06:59
chriadambuteo makes me cringe whenever i look at it.  architecture is quite good, IMO, but the implementation leaves a lot to be desired.06:59
dcalisteAh, we can post pone also ;)06:59
dcalisteExactly my feeling !07:00
dcalisteI like the general idea, but graps my hair when looking at some implementation details.07:00
chriadamyeah.  and we have just hacked stuff on top to get things working, which no doubt made the situation worse.07:01
dcalisteDo you think it's a waste of time to change the API of the SyncOnChange part ?07:01
dcalisteIt would be nicer to have the sync on change bits in the daemon than in the app, no ?07:01
chriadamyes I completely agree.07:01
chriadambut there are some complexities07:02
chriadame.g. in the future, we want to daemonise different APIs (e.g. contacts, calendar, accounts, etc)07:02
chriadamwhen we do that, each API will have an associated daemon07:02
chriadamand all client API calls will be via IPC (e.g. p2p dbus perhaps)07:02
chriadamso once we move to that architecture, it makes more sense to have e.g. the calendar daemon "listen" for changes and trigger appropriate syncs07:03
chriadamrather than msyncd itself07:03
chriadam(for access control reasons, we want to limit what msyncd could access, etc)07:03
dcalisteOk, at least with the patch in calendar, Google won't sync when I modify some other calendar…07:04
chriadamindeed ;-)07:04
dcalisteTell me when this work is started from Jolla side, I will be able to assist.07:04
chriadamunfortunately I don't expect that work to begin in the near future07:05
chriadambut will definitely keep you in the loop07:05
dcalisteThanks. In the meantime, I can continue to separate mKCal backend from syncing logic in caldav plugin ;)07:06
dcaliste(And add task handling…)07:06
chriadamtask handling?  oh is this ToDo support?07:07
dcalisteWith the refactoring that will land as a MR shortly now, the code should be able to sync todos also.07:07
chriadambtw I merged the mkcal + caldav changes - thanks for that.  I will ask one of the testers if they can help me test those more thoroughly later in the week also.07:07
chriadamah great!  thanks07:08
chriadamon the gpg signature side, I was hoping to merge those last week, but noticed that there are still some discussion items open with pvuorela on the jolla-email PR07:08
dcalisteYes, thanks for merging. I'll send the mKCal package to Maus who reported the upsync bug, I guess he will be eager to test also.07:08
chriadamtrue, thanks07:09
dcalisteAbout the discussions, you mean the naming convention of the new signal in nemo-qml-plugin-email ?07:09
chriadamno, there was a question about adding a dconf key: autoVerifySignature, and then a Loader07:10
chriadamI think pvuorela didn't have a chance yet to respond to that question07:10
dcalisteAh, yes. This in m opinion, can be added on top later if decided so.07:10
dcalisteBut we can also wait for pvuorela to have time to respond of course ;)07:11
dcalisteThe question was about to create such a key and make it apparent in UI.07:11
chriadamI pinged him about it earlier today so hopefully by tonight.  I'm itching to get it all integrated honestly, it's been too long in queue.07:11
dcalisteThis, I think, was becoming more important with a remark from schmittm during the last community meeting.07:12
dcalisteHe mentioned that we're using ancient GnuPG stack because of licencing issue.07:13
dcalisteAnd auto verification of emails may lead to a threat with random bits from the Internet.07:13
dcalisteSo the auto verification dconf key makes sense to avoid software reading random data everytime there's supposed to be a signature.07:14
dcalisteThe user can verify key for selected emails that looks originating from a trusted person.07:14
dcalisteThe other solution I see is to package a GnuPG-latest but not distributing it.07:15
dcalisteLike that user would cares can pkcon install email-pgp-plugins + gnupg-latest.07:15
chriadamregarding the former: maybe we should turn off auto-verification by default?07:15
chriadamregarding the latter: that sounds like a good idea, maybe we should ask lbt about that?  but hopefully some gplv3 discussions are reaching their conclusion shortly anyway..?07:16
dcalisteIndeed, and let the user turn it on or off we a dconf key, or a UI setting.07:16
chriadamright.  first version: dconf key is fine.  eventually, definitely need a UI setting, but not necessary for first version IMO07:17
chriadamsince some command line stuff (e.g. manually installing appropriate packages) is required anyway07:17
chriadamand importing some keys07:17
dcalisteOk for the dconf key, will add it later today. Last week, we decided also that I need to implement something like autoVerifySignature: numberOfAttachments == 007:18
dcalisteBut, after rying to do it, it's not doable in the current implementation.07:18
dcalisteIndeed, for POP, everything is downloaded already.07:18
chriadamoh wow07:19
chriadamthat I didn't know07:19
dcalisteAnd for IMAP, I need to rewrite the download part.07:19
dcalisteCurrently, since, I need the pristine data, I start the download anyway of the full part in QMF directly.07:19
dcalisteI'm thinking how to improve this and reconstruct pristine data after user downloaded by hand the various parts.07:20
dcalisteBut it requires quite a work.07:20
dcalisteBecause I need to save the pristine headers for each part and then reconstruct all.07:20
chriadamwhat's the current alternative?  either never auto verify, or always auto verify (requiring full download)?  eh, that seems ok for now.07:21
dcalisteWhile now, I'm saving the full part anyway, which is simpler as a first approach.07:21
dcalisteNo, in fact, it has no relation to autoverification.07:21
dcalisteThe bits are downloaded anyway currently when the messageserver see that the email is a signed one and save all bits on disk.07:21
chriadamah, it downloads everything regardless?07:21
dcalisteThen, depending on verification policy, the qml-plugin verifies or not the data.07:22
chriadamthat's suboptimal :-/  does that "when messageserver see the email is a signed one" behaviour only occur if the appropriate packages are installed?  or does it happen regardless?07:22
dcalisteThe idea for the future is not to download data uniformally, but to download just the pristine headers and reconstruct the pristine part from headers and downloaded data from user actions.07:23
dcalisteThe behaviour of the messageserver depends on the installation of plugin indeed.07:23
chriadamin that case, sounds fine to me.  if we can improve things in the future, great, but shouldn't block things for now IMO07:24
chriadamhopefully pvuorela agrees07:24
dcalisteThe logic is only the plugins can say which parts should be pristine for verification, even if the message server knows without plugin that a message is signed or not.07:25
dcalisteThe RFC about MIME and multipart emails just say that the mail is multipart::signed but not how to verify.07:25
dcalisteThe plugins implementing PGP or S/MIME add the information which part should have pristine data for verification.07:26
dcalisteThe "problem" in the RFC (but it's logical) is that the headers are also required to check the signature, not just raw data of the attached file for instance, which makes the data retrieval and save disk a critical part if bits in the headers are changed or not saved pristine.07:27
dcalisteThis has never been an issue with POP, since the full email is always downloaded. But IMAP is another story…07:28
dcalisteHeaders can be retrieved separately, but was never saved pristine in the old QMF, now we can save then, but to simplify the first implementation, I decided to download the signed part at once, even if this part contains sub-parts or several attachments.07:29
dcalisteIt's on my todo list, but I'm waiting for first adoption and first feedback about current implementation and UI flow.07:30
chriadamno worries, thanks for the explanation07:32
dcalisteHopefully we'll have git-hosted static pages in sailfishos.org to document all of this ;)07:33
chriadamare you thinking some markdown style wiki or?07:33
dcalisteI'm eager to explain how things works in QMF or higher in the stack, so others can learn from that.07:34
chriadamif you send me some text, I can add it to the sailfishos wiki, but it's currently not git hosted / modifiable by non-internals07:34
chriadamalso it's likely to go out of date quickly if we don't remember to keep updating that wiki ;-)07:35
dcalisteWhatever, but something like the old sailfishos.ork wiki where the architectural parts are explained.07:35
chriadamwrong copy paste sorry07:35
dcalistelbt was speaking of this kind of upgrade for the merge between sailfishos and merproject. So people can participate to the technical documentation and it can be reviewed by sailor.07:36
chriadamthat would definitely be good07:36
chriadamhaven't heard about that, internally, yet07:36
dcalisteAh, maybe it was just an idea on IRC at one point ;)07:37
dcalisteI can write some more text for the Email wiki page though and send it to you later.07:37
chriadamor maybe I haven't been paying attention enough to the plans discussed in internal ops calls / meetings ;-)07:37
chriadambut yeah, that'd be great also07:37
dcalisteYes, at work we're also migrating from wiki to git-hosted documentation written in markdown, we find it simpler to interact or review changes.07:38
albertuxchriadam: Hello chriadam, I'm draining battery problem with contactsd yet....it's a problem I must travel with BIG power bank....07:40
chriadamalbertux: I recall the conversation, I don't recall the outcome07:52
chriadamalbertux: ISTR that you have various XMPP accounts?  roster changes can trigger activity, which could cause some of it07:53
chriadambut most likely the cause is bad sync cycles between the privileged and non-privileged databases.07:53
chriadamwe should get rid of the non-privileged database altogether, IMO07:53
chriadambut that's something which needs addressing later on, e.g. after daemonising the contacts API access07:54
albertuxchriadam: Ok, wil you solve the problem with next release?07:54
chriadamalbertux: highly unlikely07:55
albertuxchriadam: The terminal is now pretty unusable...07:55
chriadamif you disable your XMPP accounts, does the situation improve?07:56
albertux100% to 10% battery in about 4 hours..07:56
albertuxno, the situation remain equal07:57
chriadamalbertux: in that case, must be something messed up with non-privileged <-> privileged contacts database sync, unfortunately.07:58
chriadamlet me quickly check something07:58
*** Piece_Maker is now known as Acou_Bass07:58
albertuxA friend of mine, skilled on Linux, have tried to cancel the old database.... and automatically lhe sustem created a new one, with same problems.. :)07:58
albertuxit is NOT a good news.... :(07:59
dcalistechriadam: sorry to interrupt, I'll need to attent a lab meeting now. To summarize: I'll add later today the dconf entry for autoSignatureVerification and propose a UI setting based on loader in the existing separated package for signature. I'll send the new mKCal package to Maus for testing.08:01
chriadamdcaliste: thanks very much08:01
chriadamhave a great week!  hopefully we get the signature PRs merged this week... fingers crossed...08:01
chriadamalbertux: can you try:08:02
dcalisteWe can also continue the discussion in bitbucket with pvuorela about the up-sync on change in calendar app. See you later and have a nice evening.08:02
chriadamalbertux: `devel-su dconf write /org/nemomobile/contacts/export/disabled true`08:02
chriadamerr. actually, `devel-su -p dconf write /org/nemomobile/contacts/export/disabled true`08:03
chriadamalbertux: and similarly `devel-su -p dconf write /org/nemomobile/contacts/export/import false`08:04
chriadamdoes that make any difference to contactsd activity?08:08
albertuxchriadam: done...now reboot08:10
albertuxcontactsd raise to 60% cpu in 3min... :(08:12
albertuxchriadam: ohps..... now I must go away......I return in the afternoon, are you still here?08:13
chriadamalbertux: no, about to head home08:14
chriadamit's late here in .au08:14
chriadamping me tomorrow, I will investigate.  very curious08:14
albertuxbye, see you!08:14
chriadamgood night!08:14
*** frinring_ is now known as frinring08:42
attah_mobileIs Harbour QA on vacation?12:53
malwhy do you think that?12:57
attah_mobileSubmitted 2 days ago and not a word. Has always been taken care of by lunch the following work day...13:00
attah_mobile(which is excellent)13:02
*** kaol_ is now known as kaol14:48
*** frinring_ is now known as frinring16:56
*** outside is now known as grumplestiltzkin18:27
Almindorwhat would be the appropriate notification category to use for an incoming audio/video call (think skype)?20:27
AlmindorI can't see any call related categories defined in /usr/share/lipstick except for missed call for some reason20:28
Almindoranyone knows how to access the proximity sensor (the "phone is on ear" detection one)?21:51
malvia Qt sensors (or directly via sensorfwd)21:59
malAlmindor: why do you ask?21:59
AlmindorI need to "enable" the "shut down screen when on ear" mode from my app22:03
Almindorunless it's done in some sort of generic way with mce?22:03
malyes, mce handles that usually22:23
Almindormal: how do you enable it tho? I can't find anything related to proximity mode in https://git.merproject.org/mer-core/mce-dev/blob/master/include/mce/dbus-names.h22:56
r0kk3rzim not sure you need to enable it at all22:59
r0kk3rzgenerally prox blocks touch22:59
r0kk3rzas for the notifications, im not sure there is an appropriate system call for that type of thing23:00
r0kk3rzit would be nice to be able to hook into the call ui23:00
malAlmindor: I think that feature might not be available to apps, but I haven't looked into that23:02

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!