| Oksana | Anybody 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 Guest3263 | 01:20 | |
| *** zbenjamin_ is now known as zbenjamin | 01:20 | |
| *** feodoran_ is now known as feodoran | 02:33 | |
| dcaliste | Hello 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 |
| chriadam | can have meeting whenever you like, but not sure if jpetrell is in the office yet | 06:44 |
| dcaliste | If you agree let's start with CalDAV then ;) | 06:45 |
| chriadam | sounds good :-) | 06:45 |
| dcaliste | This reports highlighted two issues: https://together.jolla.com/question/201611/caldav-calendar-msyncd-fails-when-updating-event-with-exceptions/ | 06:45 |
| dcaliste | One 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 |
| dcaliste | https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/40 should solve it. | 06:47 |
| dcaliste | The 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 |
| chriadam | ah nice they fixed that? great | 06:48 |
| dcaliste | The deployment of the new version will depend on provider of course. | 06:48 |
| chriadam | indeed | 06:48 |
| dcaliste | But the fix in MR!40 should mitigate its effects. | 06:49 |
| dcaliste | Yes, 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 |
| chriadam | fantastic | 06:50 |
| dcaliste | Sebastian 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 |
| dcaliste | The problem was about the listing of modified and deleted event on device as reported from mkcal. | 06:52 |
| chriadam | did you fix something in mkcal side, which allowed PR41? | 06:53 |
| dcaliste | As 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 |
| dcaliste | https://git.merproject.org/mer-core/mkcal/merge_requests/13 | 06:53 |
| dcaliste | I'm proposing to allow to set the dateCreated field also on insert, not only on update. | 06:54 |
| chriadam | excellent. | 06:54 |
| dcaliste | It completely solve MER#2032 without changing anything on caldav plugin. | 06:54 |
| chriadam | that PR LGTM, although I haven't built/tested on device | 06:54 |
| dcaliste | In fact MR!41 is just some polishing. | 06:54 |
| dcaliste | I've added a test in mkcal and in caldav plugin to ensure that dateCreated field can be set. | 06:55 |
| dcaliste | Currently, 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 |
| dcaliste | Since we are upstream of mkcal, I think it's not a big deal to change this as in MR!13. | 06:56 |
| chriadam | definitely | 06:56 |
| chriadam | great work | 06:56 |
| dcaliste | The insetr without created date set will put the current time, while any other case will put the created date of the event. | 06:57 |
| dcaliste | Ok, good we agree ;) | 06:57 |
| chriadam | one line patch with such big implication for code quality in caldav ;-) | 06:57 |
| chriadam | nice one | 06:57 |
| chriadam | I 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 |
| dcaliste | Now 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 |
| dcaliste | I'm going to create a MR for this soon I guess. | 06:59 |
| chriadam | cool | 06:59 |
| dcaliste | About reproduction, MER#2032 can be reproduced with any server. | 06:59 |
| chriadam | ah ok, great | 06:59 |
| chriadam | that makes things simpler :-) | 06:59 |
| dcaliste | Create an event upstream, then sync. | 06:59 |
| dcaliste | Delete it on device, wait for two to three minutes, it is here again. | 06:59 |
| dcaliste | after mkcal:MR!13, it should work. | 07:00 |
| dcaliste | caldav:MR!41 is just polishing on top of mkcal MR!13. | 07:00 |
| dcaliste | To 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 events | 07: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 |
| dcaliste | MR!40 should solve this faulty behaviour. | 07:02 |
| chriadam | great. thanks very much, I will test later this week. | 07:02 |
| dcaliste | Good, goos, thank you. | 07:03 |
| dcaliste | s/goos/good/ | 07:03 |
| dcaliste | I have one question, if you don't mind: | 07:03 |
| chriadam | certainly | 07:03 |
| dcaliste | Where is the code that detect a change on calendar and trigger an upsync when the always up to date flag is set ? | 07:03 |
| dcaliste | It should be in a daemon, but I can't find it… | 07:04 |
| dcaliste | I've looked in AccountSyncManager but it's mainly for QML… | 07:04 |
| chriadam | jolla-calendar, synchelper.h/cpp | 07:04 |
| chriadam | it should be in a daemon, and we should daemonise the calendar API (and the contacts API etc) | 07:05 |
| dcaliste | The reasoning, is that when a change is made, all profiles are upstreaming their changes… | 07:05 |
| chriadam | but we sadly did not choose such architecture during the early days | 07:05 |
| dcaliste | Not only the one that received the changes. | 07:05 |
| chriadam | yeah :-( all of the sync-on-change handling is pretty hacky at the moment, sadly. | 07:06 |
| dcaliste | Do you think I be allowed to access these sources on bitbucket ? | 07:06 |
| chriadam | would have to ask jpetrell | 07:06 |
| chriadam | if there is some concrete feature or bug you wish to work on, I don't see why not :-) | 07:06 |
| jpetrell | dcaliste: I probably can get you access. what repository? | 07:07 |
| chriadam | jolla-calendar | 07:07 |
| dcaliste | I 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 |
| dcaliste | Ah, thanks jpetrell :) | 07:07 |
| dcaliste | This 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 |
| chriadam | probably similar issue for contact sync triggered by contactsd tbh. | 07:08 |
| dcaliste | Ah, 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 |
| jpetrell | dcaliste: you should have access now | 07:10 |
| chriadam | I'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 |
| dcaliste | About 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 |
| dcaliste | jpetrell: indeed thank you. | 07:11 |
| chriadam | I think buteo already has some hooks for this sort of thing, but requires the appropriate Storage Plugin to be utilised. | 07:12 |
| chriadam | it 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 POV | 07:13 |
| chriadam | originally 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 time | 07:13 |
| chriadam | but some work is required to investigate that I guess | 07:13 |
| dcaliste | chriadam: 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 |
| chriadam | sounds good :-) thanks | 07:17 |
| dcaliste | Ok, I think that's all about CalDAV news for now. | 07:18 |
| dcaliste | On 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 |
| dcaliste | I've slightly updated the jolla-email UI part to reflect the changes. | 07:20 |
| chriadam | great | 07:20 |
| chriadam | hopefully pvuorela gets a chance to review those again soon. then hopefully I can merge/tag everything :-) | 07:20 |
| dcaliste | One thing remains is the [=]() on lambda declaration. | 07:20 |
| dcaliste | I'm not familliar with, and copied it from secret code. | 07:20 |
| chriadam | lazy code style by me :-/ | 07:21 |
| chriadam | basically, just references all local-scope variables. | 07:21 |
| dcaliste | Reading 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 |
| pvuorela | my comment wasn't there wasn't about [=] but missing the context parameter for connection. | 07:22 |
| dcaliste | But, in my opinion, the callback will be removed when this is destroyed. | 07:22 |
| dcaliste | pvuorela, ah great, sorry I misunderstood your remark. | 07:22 |
| dcaliste | May you explain it further, I'm lacking much knowledge on that part, sorry. | 07:23 |
| pvuorela | [=] -> "this, [=]" | 07:23 |
| pvuorela | so 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 |
| chriadam | https://doc.qt.io/Qt-5/qobject.html#connect-5 | 07:24 |
| dcaliste | Ah, 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 |
| dcaliste | Sorry guys. Got it ;) | 07:25 |
| chriadam | :-) | 07:26 |
| dcaliste | Ok, fixed and pushed. | 07:27 |
| pvuorela | nice, that was fast :) | 07:27 |
| dcaliste | If you include the comprehension time, not really! | 07:29 |
| pvuorela | nah :) | 07:30 |
| dcaliste | One question remains on this topic: should I include a switch button in the email setting page for this setting ? | 07:30 |
| dcaliste | The way I did it for the rest of signature stuff: with a loader that may fail if file is not present. | 07:31 |
| pvuorela | what kind of setting? | 07:31 |
| dcaliste | The auto verify signature thing. | 07:31 |
| pvuorela | was thinking should it autoverify if we know signature things are set up. | 07:32 |
| dcaliste | See https://bitbucket.org/jolla/ui-jolla-email/pull-requests/418/jolla-email-add-pgp-signature-status-and/activity#comment-96733104 | 07:32 |
| pvuorela | and otherwise not. | 07:32 |
| dcaliste | Currently it is auto verifying if every bits are in place. | 07:32 |
| dcaliste | But 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 |
| chriadam | only if a key for the associated email address is installed? | 07:34 |
| pvuorela | think auto verification is ok if there are no side-effects for cases when there is no signature support installed or enabled. | 07:34 |
| chriadam | I'd just autoverify all the time, honestly, since it should only verify for email addresses for which you have a key installed. | 07:34 |
| pvuorela | think there was some side-effect of triggering attachment downloads, at least earlier? | 07:35 |
| chriadam | ah, interesting | 07:36 |
| dcaliste | Yes, indeed, autoverification is triggerring the download of the full email. | 07:36 |
| dcaliste | Because all bits are needed for the verification. | 07:36 |
| chriadam | hrm. even so, I would just enable it for now. we can revisit later if necessary IMO. | 07:36 |
| pvuorela | dcaliste: did that affect the file attachments? | 07:37 |
| pvuorela | forgot already. | 07:38 |
| chriadam | yes, I guess all parts get downloaded for verification | 07:38 |
| chriadam | but only in the "have key for email address" case, I guess? or am I wrong about that? | 07:39 |
| pvuorela | hm, that sounds bad if it means downloading some random 10 megabyte document automatically. | 07:39 |
| dcaliste | Yes, attachments are signed, they are downloaded automatically. | 07:40 |
| pvuorela | would some heuristic work? no file attachments -> autoverify, otherwise ask? | 07:42 |
| dcaliste | Sadly, how it is implemented now, the download is done before checking that we have the key… | 07:42 |
| dcaliste | pvuorela: good point. | 07:43 |
| dcaliste | in emailmessage.qml to EmailMessage {autoVerifySignature: !hasAttachment} | 07:43 |
| pvuorela | dunno about html emails, though. | 07:43 |
| chriadam | dcaliste: 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 |
| dcaliste | html is downloaded anyway already since it's the body part. | 07:44 |
| dcaliste | chriadam: yes it's possible I think but it requires major changes in nemo-qml-plugin-email part. | 07:44 |
| dcaliste | To 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 |
| dcaliste | Maybe as a later MR ;) ? | 07:46 |
| chriadam | maybe it's not a problem if we only autoverify emails without attachments | 07:46 |
| dcaliste | Yes I think it's a good first approach. | 07:47 |
| dcaliste | I'm going to update jolla-email with it, as mentioned before. | 07:47 |
| dcaliste | We've already missed the 3.0.3 window I'm afraid, haven't we ? | 07:48 |
| chriadam | yes :-( | 07:48 |
| dcaliste | Ok, 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 |
| chriadam | then when everything has been approved, I will merge/tag. | 07:52 |
| chriadam | I've said this a lot recently, but "hopefully this week!" ;-) | 07:53 |
| dcaliste | Ok, cross fingers ;) | 07:53 |
| dcaliste | What about https://together.jolla.com/question/201406/community-contributions-for-personnal-key-management/ ? | 07:53 |
| dcaliste | Should we profit of a peacefull time in-between release on TJC to make it public ? | 07:54 |
| dcaliste | Should I change some more things in it ? | 07:54 |
| chriadam | not 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 appropriately | 07:54 |
| dcaliste | chriadam: 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 |
| dcaliste | jpetrell do you agree if I add such a section ? | 07:56 |
| chriadam | definitely a possibility, but might also be a good idea to get "blank slate" suggestions | 07:56 |
| dcaliste | Yes, 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 |
| chriadam | eh, 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 forward | 07:59 |
| chriadam | but maybe jpetrell has a different opinion | 07:59 |
| chriadam | ? ^ | 07:59 |
| chriadam | must have stepped out of office for lunch or so? | 08:02 |
| chriadam | or in meeting with martin I guess | 08:02 |
| pvuorela | yea, joona and martin have been discussing here for a while. | 08:03 |
| dcaliste | ok, we can discuss this next time he's here, it's not very urgent anyway. | 08:04 |
| chriadam | sounds good | 08:04 |
| chriadam | dcaliste: so action points for me: | 08:04 |
| chriadam | 1) caldav MR testing | 08:04 |
| chriadam | 2) merge/tag gpg PRs once they are approved | 08:04 |
| chriadam | was there anything I'm forgetting? | 08:04 |
| jpetrell | sorry we are having customer visit today | 08:05 |
| dcaliste | No, that's it (CalDAV *+ mkcal*). | 08:05 |
| chriadam | ah yes and mkcal | 08:05 |
| chriadam | jpetrell: oh that's right. hope the discussions are very productive | 08:05 |
| dcaliste | jpetrell: 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 |
| dcaliste | chriadam: I've seen you're remarks in MRs and I'm reviewing them. | 08:06 |
| jpetrell | dcaliste: maybe we should arrange telco or IRC discussion about the key management for some day to get everybody on the same page | 08:07 |
| chriadam | sounds like a good idea. can we discuss that at the next meeting perhaps, and organise a date/time then? | 08:09 |
| jpetrell | that works, | 08:10 |
| jpetrell | that works | 08:11 |
| dcaliste | Yes, 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 |
| chriadam | sounds good, thanks | 08:14 |
| chriadam | ok, if there's nothing else, I will head home for the evening. thanks very much again for your hard work and help. | 08:14 |
| jpetrell | yeah progressing these important areas is awesome | 08:14 |
| chriadam | :-) have a great week! | 08:16 |
| dcaliste | jpetrell, 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 |
| dcaliste | Have a nice evening chriadam. | 08:17 |
| chriadam | can do that also | 08:17 |
| * chriadam -> away | 08:17 | |
| *** frinring_ is now known as frinring | 08:25 | |
| albertux | chriadam: I've high-drain-battery problem yet, problem with contasctd again... Bug? | 09:37 |
| albertux | chriadam: Drain is havy.... 100% to 10% in abuout 6 hours ---->devìce unusable I must recharge it with power bank three times/day | 09:41 |
| albertux | chriadam: ohps, You're away... | 09:44 |
| r0kk3rz | someone was looking into that recently i think | 09:45 |
| *** Oksana_ is now known as Oksana | 11:36 | |
| *** SpeedEvil is now known as Guest75333 | 17:25 | |
| *** feodoran_ is now known as feodoran | 20:11 | |
| *** BitEvil is now known as SpeedEvil | 23:37 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!