09:01:12 #startmeeting Sailfish OS CalDAV/CardDAV Contributors Meeting 09:01:12 Meeting started Mon Jul 3 09:01:12 2017 UTC. The chair is chriadam_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 09:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 09:01:30 The agenda for today's meeting can be found at: 09:01:33 #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#03.2F07.2F2017_Meeting 09:01:41 #topic Introductions 09:01:50 Please introduce yourself with #info nick/name 09:02:02 #info Chris Adams, developer at Jolla 09:02:16 #info Damien Caliste, community 09:02:34 hi dcaliste! glad you could make it! 09:02:50 we'll wait a few more minutes in case people are late, then get started on the rest of the agenda. 09:02:53 Hello chriadam_, yes, this time no public holiday in France ;) 09:03:13 dcaliste: btw we need to talk with abranson about the QMF PRs you have 09:03:52 Good, good, yes I have time this morning, that would be great. 09:03:55 yes this is as good a place as any. thanks for the mention 09:04:05 I spoke to mvogt and he is happy for them to go in, but isn't able to spend time merging / supporting them going forward. My understanding is that Pekka and Andrew are willing to help in that regard. 09:04:27 Anyway let's discuss that directly after this meeting, if that suits you both? 09:04:34 yep! 09:04:36 Yep for me 09:04:38 great 09:05:01 will wait a couple more minutes for latecomers, then will get started 09:05:33 * LarstiQ lurks as always 09:06:19 hi LarstiQ 09:06:31 hi ljo_ 09:06:49 hi, sorry for being late 09:06:56 no worries :-) 09:07:08 waiting another minute or so then we'll get started on the agenda proper 09:08:29 ok, let's continue: 09:08:37 #topic Follow-up items from last meeting 09:09:27 Biggest issue to follow up on is the JB#38601 testing - I posted to TJC and asked for community help in testing the new CalDAV package. While it doesn't resolve all of the issues which have been reported, it does fix the calendar duplication issue for most people who tested it 09:09:54 as such, unless someone here has an objection, I will merge the PR as it currently stands 09:10:00 (and try to get it into 2.1.1 but we'll see...) 09:10:11 I wanted to write a small shell script exporting non-private data from the calendar data-base. 09:10:21 Like UID and so on. 09:10:23 please go ahead 09:10:25 I haven't seen the duplication again since we last spoke, so I don't have anything to chase 09:10:57 So like that reporters can send the content of there local database for us to understand what can cause duplication. 09:11:03 dcaliste: makes sense 09:11:04 Only got one since you published the latest test build. 09:11:04 Do you think it can help ? 09:11:37 dcaliste: I think it could help. Instead of separate shell script, I would prefer the functionality got added either to icalconverter (from nemo-qml-plugin-calendar-tools) or the new cdavtool from carddav repo 09:12:01 but a shell script (which people can copy/paste and run from the wiki) would also be useful 09:12:32 chriadam_: ok for the C tool. A C script with a sqlite command can be quite simple also. 09:12:41 ljo_: so you still have seen a duplication with that new package? I think abranson saw one also, but not able to reproduce reliably. I guess there is an edge case which can still be triggered, but it is an improvement nonetheless? 09:12:57 Like that we should be able to replay locally the duplication, having the request and the database. 09:13:05 right 09:13:09 just to ask again - is there any way we can detect a caldav crash and remove the extra notebook? maybe log the current ones before it's launched, then remove any new ones created during a crashing run? 09:13:50 Definitely an improvement. :) 09:13:55 abranson: all things are possible. we could store a dirty flag in the cdav.ini file under privileged/Sync/ dir 09:13:55 i understand that the duplication happens because caldav always creates a new notebook with the remote calendar data locally for comparison, but usually cleans it up after sync if it's not crashed 09:14:39 I suppose in that case people would see their calendars go stale instead of duplicate 09:14:49 abranson: but that is in some respects a possible cause of problems (e.g., if the flag isn't cleared appropriately (perhaps due to a crash...) then we could delete the notebook even after the cycle completes successfully) 09:15:19 but yes, I think the chance of a crash in reading/writing a .ini is far less likely than a crash in network / calendar event manipulation code 09:15:57 abranson: I'll put it on the TODO list 09:16:15 any other items to follow up on since the last meeting? 09:16:17 And I may add about this, that this temporary notebook should be clean anyway. So if ini file contains a flag and the notebook exists it should be removed, no ? 09:16:32 we could even backup the db, then restore it if there's a crash. that would avoid even more data damage 09:17:05 abranson: unlikely to work correctly, because in Sailfish OS we unfortunately don't have single-process daemons to provide eg Calendar service 09:17:20 which means multiple processes can have the database open, which means sqlite will have lock files and journal files open 09:17:35 copying just the .db is unlikely to be enough. Perhaps sqlite gurus can correct me 09:17:55 Or use a separate db for temporary work… Stupid idea ? Or too much modifications to be done ? 09:18:04 does sqlite do snapshotting? 09:18:12 in the hopefully not too distant future, it'd be nice if we could rewrite our middleware to transition to a daemon-service architecture. but not today. 09:18:49 dcaliste: well, it's not "temporary" per se. The problem is that mkcal doesn't allow creating notebooks and editing events in notebooks within the same transaction (specifically, creating a notebook causes a transaction commit) 09:19:09 abranson: hrm, perhaps it does. actually, I'd be surprised if it didn't. Hopefully it is concurrence-safe also... but I'd have to check. 09:19:17 it's experimental: https://www.sqlite.org/c3ref/snapshot_get.html 09:19:32 hrm. 09:20:02 something to look into, perhaps. in the near future, a dirty flag in the caldav.ini is probably simpler. but let's investigate. 09:20:14 ok, continuing to next agenda item: 09:20:17 #topic JB#38601 - CalDAV plugin fails during sync of some "broken" events, resulting in duplications 09:20:26 Basically, this is just: should I merge that PR now? 09:20:34 from previous discussion I guess the answer is "yes" 09:20:38 at least no-one seemed to disagree ;-) 09:20:47 so, moving on to next topic: 09:20:56 oh, before I move on 09:20:58 #link https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/20/diffs 09:21:05 more reviewers welcome of course 09:21:14 #topic MER#1796 - local modification being reported erroneously to calendar events 09:21:37 Ok, next topic is: reported from a couple of people that repeated sync cycles with no changes either remotely or locally, result in a single local event being reported as modified 09:21:42 and upsynced due to that detection 09:21:51 I have been provided a sync log which clearly shows this issue 09:21:58 but I haven't yet had the chance to investigate why 09:22:24 (most likely I'll have to generate a custom package which provides more debug output, specifying precisely which field is comparing as different) 09:22:44 has anyone seen this with their own calendar / sync cycles? 09:23:02 is anyone willing to investigate this one? if not, I will try to investigate some time in the next couple of weeks. 09:23:06 no, haven't seen a server duplication of an event for years! 09:23:15 it's not a duplication 09:23:21 it's a spurious local modification 09:23:40 e.g., the local plugin looks at the local data and says "this event has changed since the last time I upsynced to the server! I'd better upsync it" 09:23:49 and the upsync works (basically a null-update) 09:24:05 but it happens on every single sync cycle (generating needless data usage, basically, although very small amount) 09:24:21 my gut feeling is that it might be related to the "alarms" / "reminders" 09:24:36 but it might be something else altogether 09:25:03 ok, I will try to investigate that, over the next couple of weeks :-) 09:25:12 #topic MER#1714 - isdn field added to phone numbers on upsync (investigation required) 09:25:33 This is still outstanding, seems like QtVersit prefers ISDN type for phone numbers which don't have a specific subtype set 09:25:57 If anyone wants to take this, they are more than welcome. I won't have time to investigate this issue for a while. 09:26:12 #topic MER#1751 - main issue resolved, but some minor tasks here remain (.eml suffixes) 09:26:27 Another good task for a new contributor: it seems Kerio servers can store contacts with .eml suffix instead of .vcf 09:26:45 Should be relatively simple to inspect the resource, determine if it's reported type is Contact, and if so, sync it 09:27:09 Again, I don't have time to look into this one, so if anyone wants to take it, that'd be cool. Low priority but good intro task I think. 09:27:19 #topic Any other business? 09:27:27 dcaliste: was there anything in particular you wanted to raise? 09:27:53 No, sorry, didn't add much time recently about CalDAV… 09:28:09 no worries at all :-) you've done a huge amount 09:28:13 s/add/have/… 09:28:29 ljo_: abranson: anything? 09:29:05 nope, will be away in us for work 5 weeks, so not much time either. 09:30:15 all good :-) 09:30:24 ok, that's all I had, so closing meeting in 3... 09:30:32 2... 09:30:39 i will try to trigger the duplication though. 09:30:54 yep, that'd definitely be useful, thanks 09:30:58 1... 09:31:05 #endmeeting