Tuesday, 2019-04-02

OksanaAnybody wants to buy a Jolla from Germany? Problem with LCD display, despite protective glass being fine. https://www.ebay.com.au/itm/Jolla-Phone-Sailfish-OS/323759146719 No battery, no back-cover, though.00:32
*** zbenjamin is now known as Guest326301:20
*** zbenjamin_ is now known as zbenjamin01:20
*** feodoran_ is now known as feodoran02:33
dcalisteHello chriadam and jpetrell, we have switched last week-end to the summer time in France, are you ok to have the meeting now, or do you prefer to keep 8am UTC?06:44
chriadamcan have meeting whenever you like, but not sure if jpetrell is in the office yet06:44
dcalisteIf you agree let's start with CalDAV then ;)06:45
chriadamsounds good :-)06:45
dcalisteThis reports highlighted two issues: https://together.jolla.com/question/201611/caldav-calendar-msyncd-fails-when-updating-event-with-exceptions/06:45
dcalisteOne with the fact that the detached-and-synced flag introduced last time to avoid having spurious local modification because of down-synced exceptions was not correctly handled in case of update of an existing exception.06:46
dcalistehttps://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/40 should solve it.06:47
dcalisteThe second bug was from the server side, I've filled a bug report in Open-xchange bug tracker and three to four days later it was fixed upstream.06:48
chriadamah nice they fixed that?  great06:48
dcalisteThe deployment of the new version will depend on provider of course.06:48
dcalisteBut the fix in MR!40 should mitigate its effects.06:49
dcalisteYes, open-xchange guys were very fast, two days after submission, they acknowledge the bug and two days later, it was marked as fixed and scheduled for next minor update. Very nice from their side.06:49
dcalisteSebastian Maus who reported the initial issue on TJC then showcase me some other issues than I was able to easy reproduce on my device, it's MER#2032.06:51
dcalisteThe problem was about the listing of modified and deleted event on device as reported from mkcal.06:52
chriadamdid you fix something in mkcal side, which allowed PR41?06:53
dcalisteAs explained in a comment at the beginning of calculateDelta(), there is an issue with mkcal that report events only when created date is before the last sync date.06:53
dcalisteI'm proposing to allow to set the dateCreated field also on insert, not only on update.06:54
dcalisteIt completely solve MER#2032 without changing anything on caldav plugin.06:54
chriadamthat PR LGTM, although I haven't built/tested on device06:54
dcalisteIn fact MR!41 is just some polishing.06:54
dcalisteI've added a test in mkcal and in caldav plugin to ensure that dateCreated field can be set.06:55
dcalisteCurrently, it was able to set it only on update, which was complicated to handle: you create the event and then you update it to set the createdDate to the right upstream value…06:55
dcalisteSince we are upstream of mkcal, I think it's not a big deal to change this as in MR!13.06:56
chriadamgreat work06:56
dcalisteThe insetr without created date set will put the current time, while any other case will put the created date of the event.06:57
dcalisteOk, good we agree ;)06:57
chriadamone line patch with such big implication for code quality in caldav ;-)06:57
chriadamnice one06:57
chriadamI will review and test both of those PRs later this week.  I guess there's no simple way to try to reproduce the problem without having access to specific type of server, but oh well.06:58
dcalisteNow that the test suite of caldav has grown to a reasonable size, I've rebased my writing of notebooksyncagent to create a CalDAVIncidence class that hide the nasty changes between mkcal and ics data.06:58
dcalisteI'm going to create a MR for this soon I guess.06:59
dcalisteAbout reproduction, MER#2032 can be reproduced with any server.06:59
chriadamah ok, great06:59
chriadamthat makes things simpler :-)06:59
dcalisteCreate an event upstream, then sync.06:59
dcalisteDelete it on device, wait for two to three minutes, it is here again.06:59
dcalisteafter mkcal:MR!13, it should work.07:00
dcalistecaldav:MR!41 is just polishing on top of mkcal MR!13.07:00
dcalisteTo test caldav MR!40, you don't need a specific server neither:07:01
dcaliste- create upstream a recursive event with exception (different start time for instance)07:01
dcaliste- sync on device to get the events07:01
dcaliste- modify one exception upstream and sync again.07:02
dcaliste- log the next sync, you'll see that the recursive event is then written as a local modification.07:02
dcalisteMR!40 should solve this faulty behaviour.07:02
chriadamgreat.  thanks very much, I will test later this week.07:02
dcalisteGood, goos, thank you.07:03
dcalisteI have one question, if you don't mind:07:03
dcalisteWhere is the code that detect a change on calendar and trigger an upsync when the always up to date flag is set ?07:03
dcalisteIt should be in a daemon, but I can't find it…07:04
dcalisteI've looked in AccountSyncManager but it's mainly for QML…07:04
chriadamjolla-calendar, synchelper.h/cpp07:04
chriadamit should be in a daemon, and we should daemonise the calendar API (and the contacts API etc)07:05
dcalisteThe reasoning, is that when a change is made, all profiles are upstreaming their changes…07:05
chriadambut we sadly did not choose such architecture during the early days07:05
dcalisteNot only the one that received the changes.07:05
chriadamyeah :-(  all of the sync-on-change handling is pretty hacky at the moment, sadly.07:06
dcalisteDo you think I be allowed to access these sources on bitbucket ?07:06
chriadamwould have to ask jpetrell07:06
chriadamif there is some concrete feature or bug you wish to work on, I don't see why not :-)07:06
jpetrelldcaliste: I probably can get you access. what repository?07:07
dcalisteI think he arrived already, jpetrell, I would like to look at the fact that a change on one profile in calendar trigger an up-sync to all registered profiles.07:07
dcalisteAh, thanks jpetrell :)07:07
dcalisteThis is a bit annoying because any change to my private calendar trigger for instance a sync of my Google calendar, that I would like to keep as minimal traffic as I can…07:08
chriadamprobably similar issue for contact sync triggered by contactsd tbh.07:08
dcalisteAh, possible, I think that looking into contacts sync will be for next year from my side ;) Too many things already started at the same time…07:09
jpetrelldcaliste: you should have access now07:10
chriadamI'm hoping that I will get the chance to significantly refactor the contacts domain over the next 6 months, but let's see.07:10
dcalisteAbout having the sync on change triggering something, I think it should go into buteo, but it should be done through plugin because buteo don't care about mkcal…07:11
dcalistejpetrell: indeed thank you.07:11
chriadamI think buteo already has some hooks for this sort of thing, but requires the appropriate Storage Plugin to be utilised.07:12
chriadamit would probably be good if we could implement appropriate buteo storage plugin (for calendar as well as contacts) and do things "properly" from buteo architecture POV07:13
chriadamoriginally we did not because of reasons I don't really remember, but probably related to wanting to keep complexity low due to my own lack of experience with sync at that point in time07:13
chriadambut some work is required to investigate that I guess07:13
dcalistechriadam: very interesting, I'll first look into jolla-calendar and see if there is a reasonable fix for the upstreaming of every profiles, and then try to look into buteo to see if we can schedule sync on event declared by plugins..07:13
chriadamsounds good :-)  thanks07:17
dcalisteOk, I think that's all about CalDAV news for now.07:18
dcalisteOn the email front, I've addressed pvuorela remarks in nemo-qml-plugin-email by adding a autoVerifySignature property to email to be able to trigger signature checking on demand instead of automatically.07:19
dcalisteI've slightly updated the jolla-email UI part to reflect the changes.07:20
chriadamhopefully pvuorela gets a chance to review those again soon.  then hopefully I can merge/tag everything :-)07:20
dcalisteOne thing remains is the [=]() on lambda declaration.07:20
dcalisteI'm not familliar with, and copied it from secret code.07:20
chriadamlazy code style by me :-/07:21
chriadambasically, just references all local-scope variables.07:21
dcalisteReading documentation afterwards, it seems that this is then passed to the callback, but it's not sured that it still exists if the email is destroyed before the callback.07:21
pvuorelamy comment wasn't there wasn't about [=] but missing the context parameter for connection.07:22
dcalisteBut, in my opinion, the callback will be removed when this is destroyed.07:22
dcalistepvuorela, ah great, sorry I misunderstood your remark.07:22
dcalisteMay you explain it further, I'm lacking much knowledge on that part, sorry.07:23
pvuorela[=] -> "this, [=]"07:23
pvuorelaso when 'this' gets destroyed, the connection gets deleted. otherwise nothing does that and callback will then call the lambda with references to a deleted instance.07:24
dcalisteAh, I see, indeed I was looking at the wrong place. I totally miss the fact that I forgot this and was thinking that indeed the connection will be removed when this get destroyed, but obviously cannot because this was not there…07:25
dcalisteSorry guys. Got it ;)07:25
dcalisteOk, fixed and pushed.07:27
pvuorelanice, that was fast :)07:27
dcalisteIf you include the comprehension time, not really!07:29
pvuorelanah :)07:30
dcalisteOne question remains on this topic: should I include a switch button in the email setting page for this setting ?07:30
dcalisteThe way I did it for the rest of signature stuff: with a loader that may fail if file is not present.07:31
pvuorelawhat kind of setting?07:31
dcalisteThe auto verify signature thing.07:31
pvuorelawas thinking should it autoverify if we know signature things are set up.07:32
dcalisteSee https://bitbucket.org/jolla/ui-jolla-email/pull-requests/418/jolla-email-add-pgp-signature-status-and/activity#comment-9673310407:32
pvuorelaand otherwise not.07:32
dcalisteCurrently it is auto verifying if every bits are in place.07:32
dcalisteBut I can introduce a dconf key to switch this off if some people think that it's too much CPU agressive…07:33
dcaliste(Or too buggy…)07:33
chriadamonly if a key for the associated email address is installed?07:34
pvuorelathink auto verification is ok if there are no side-effects for cases when there is no signature support installed or enabled.07:34
chriadamI'd just autoverify all the time, honestly, since it should only verify for email addresses for which you have a key installed.07:34
pvuorelathink there was some side-effect of triggering attachment downloads, at least earlier?07:35
chriadamah, interesting07:36
dcalisteYes, indeed, autoverification is triggerring the download of the full email.07:36
dcalisteBecause all bits are needed for the verification.07:36
chriadamhrm.  even so, I would just enable it for now.  we can revisit later if necessary IMO.07:36
pvuoreladcaliste: did that affect the file attachments?07:37
pvuorelaforgot already.07:38
chriadamyes, I guess all parts get downloaded for verification07:38
chriadambut only in the "have key for email address" case, I guess?  or am I wrong about that?07:39
pvuorelahm, that sounds bad if it means downloading some random 10 megabyte document automatically.07:39
dcalisteYes, attachments are signed, they are downloaded automatically.07:40
pvuorelawould some heuristic work? no file attachments -> autoverify, otherwise ask?07:42
dcalisteSadly, how it is implemented now, the download is done before checking that we have the key…07:42
dcalistepvuorela: good point.07:43
dcalistein emailmessage.qml to EmailMessage {autoVerifySignature: !hasAttachment}07:43
pvuoreladunno about html emails, though.07:43
chriadamdcaliste: we certainly shouldn't download attachment if we have no key for that email address, IMO.  not sure if that would be simple to change, or not?07:44
dcalistehtml is downloaded anyway already since it's the body part.07:44
dcalistechriadam: yes it's possible I think but it requires major changes in nemo-qml-plugin-email part.07:44
dcalisteTo do it:07:45
dcaliste- check first.07:45
dcaliste- catch SignatureMissing error.07:45
dcaliste- if not, trigger download and retrigger check after download.07:45
dcalisteMaybe as a later MR ;) ?07:46
chriadammaybe it's not a problem if we only autoverify emails without attachments07:46
dcalisteYes I think it's a good first approach.07:47
dcalisteI'm going to update jolla-email with it, as mentioned before.07:47
dcalisteWe've already missed the 3.0.3 window I'm afraid, haven't we ?07:48
chriadamyes :-(07:48
dcalisteOk, so plan is:07:50
dcaliste- pvuorela is rechecking nemo-qml-plugin-email (one last time?),07:50
dcaliste- I'm adding the auto verification only for emails without attachment and check that the UI trigger is still working in the case of attachments.07:51
chriadamthen when everything has been approved, I will merge/tag.07:52
chriadamI've said this a lot recently, but "hopefully this week!" ;-)07:53
dcalisteOk, cross fingers ;)07:53
dcalisteWhat about https://together.jolla.com/question/201406/community-contributions-for-personnal-key-management/ ?07:53
dcalisteShould we profit of a peacefull time in-between release on TJC to make it public ?07:54
dcalisteShould I change some more things in it ?07:54
chriadamnot sure what jpetrell wants to do there.  I think it is useful to get user feedback to ensure that our eventual UI captures the required flows appropriately07:54
dcalistechriadam: you mentioned last time, I remember now, to screenshot the current secret UI and show it as work in progress, waiting for people to suggest improvements or blockers.07:56
dcalistejpetrell do you agree if I add such a section ?07:56
chriadamdefinitely a possibility, but might also be a good idea to get "blank slate" suggestions07:56
dcalisteYes, both are good. The sensitive question here is to show or not the current state of secret UI, it's on repos, so anyone can get it but it's still WIP so I don't know if you people in Jolla would agree to show it on TJC.07:58
chriadameh, I don't think there's any reason to hide it per-se, I just wonder what would be most useful in terms of getting useful feedback going forward07:59
chriadambut maybe jpetrell has a different opinion07:59
chriadam? ^07:59
chriadammust have stepped out of office for lunch or so?08:02
chriadamor in meeting with martin I guess08:02
pvuorelayea, joona and martin have been discussing here for a while.08:03
dcalisteok, we can discuss this next time he's here, it's not very urgent anyway.08:04
chriadamsounds good08:04
chriadamdcaliste: so action points for me:08:04
chriadam1) caldav MR testing08:04
chriadam2) merge/tag gpg PRs once they are approved08:04
chriadamwas there anything I'm forgetting?08:04
jpetrellsorry we are having customer visit today08:05
dcalisteNo, that's it (CalDAV *+ mkcal*).08:05
chriadamah yes and mkcal08:05
chriadamjpetrell: oh that's right.  hope the discussions are very productive08:05
dcalistejpetrell: no problem, as said before we can discuss TJC post about key UI later when you have time for it. That's fine.08:06
dcalistechriadam: I've seen you're remarks in MRs and I'm reviewing them.08:06
jpetrelldcaliste: maybe we should arrange telco or IRC discussion about the key management for some day to get everybody on the same page08:07
chriadamsounds like a good idea.  can we discuss that at the next meeting perhaps, and organise a date/time then?08:09
jpetrellthat works,08:10
jpetrellthat works08:11
dcalisteYes, we can plan for a dedicated date/time slot (if not now). My agenda is quite flexible, you can propose some date/time at your convenience and I will tell you which one is compatible for me.08:11
chriadamsounds good, thanks08:14
chriadamok, if there's nothing else, I will head home for the evening.  thanks very much again for your hard work and help.08:14
jpetrellyeah progressing these important areas is awesome08:14
chriadam:-)  have a great week!08:16
dcalistejpetrell, chriadam and whoever can be involved (venemo?) we can setup a date/time slot by email and then meet on IRC or by video (IRC is simpler for me, but I can handle video or phone call also).08:16
dcalisteHave a nice evening chriadam.08:17
chriadamcan do that also08:17
* chriadam -> away08:17
*** frinring_ is now known as frinring08:25
albertuxchriadam: I've high-drain-battery problem yet, problem with contasctd again... Bug?09:37
albertuxchriadam: Drain is havy.... 100% to 10% in abuout 6 hours  ---->devìce unusable I must recharge it with power bank three times/day09:41
albertuxchriadam: ohps, You're away...09:44
r0kk3rzsomeone was looking into that recently i think09:45
*** Oksana_ is now known as Oksana11:36
*** SpeedEvil is now known as Guest7533317:25
*** feodoran_ is now known as feodoran20:11
*** BitEvil is now known as SpeedEvil23:37

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