09:00:05 <chriadam_> #startmeeting Sailfish OS CalDAV/CardDAV Contributors meeting
09:00:05 <merbot> Meeting started Mon Aug  7 09:00:05 2017 UTC.  The chair is chriadam_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:05 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:00:12 <chriadam_> #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#07.2F08.2F2017_Meeting
09:00:54 <chriadam_> I forgot to remind everyone about the meeting on the mailinglist until earlier today, so I suspect that no-one else will be attending.  My apologies, but hopefully the meeting log is useful anyway.
09:01:00 <chriadam_> #topic Introductions
09:01:02 <dcaliste> Hello chriadam_
09:01:10 <chriadam_> #info Chris Adams, developer at Jolla
09:01:12 * larstiq_ lurks as usual
09:01:22 <chriadam_> dcaliste: hi!  great you could make it, I forgot to send the reminder email so wasn't sure
09:01:57 <dcaliste> #info Damien Caliste, community
09:02:06 <chriadam_> abranson: we also need to discuss with dcaliste about the qmf etc PRs considering the response we got from jpetrell about the UI changes process (after this meeting I guess)
09:02:17 <chriadam_> hi larstiq_ :-)
09:03:22 <dcaliste> chriadam_: not traveling today, and no work meeting at the same time, and I've seen your mailing announce just on time waking up this morning.
09:03:34 <chriadam_> good timing ;-)
09:03:54 <chriadam_> we'll wait another 6 mins or so for any latecomers, before continuing with the agenda.
09:04:31 <dcaliste> Sure, no problem.
09:09:32 <chriadam_> Ok, let's get started.  Will be a short meeting probably, since I didn't get a chance to investigate MER#1796 yet
09:09:39 <chriadam_> #topic Follow-up Agenda Items From Last Meeting
09:10:05 <chriadam_> the various CalDAV changes discussed from the last meeting were cherry picked for upgrade 2.1.1
09:10:25 <chriadam_> which is good - if anyone sees any calendar duplications, please try to get sync logs (and preferably a repro test account which I can use!)
09:10:55 <chriadam_> I know that at least one duplication exists with the current code, but wasn't about to repro that one myself, so a test account which shows the issue would be necessary for further investigation, really.
09:11:15 <chriadam_> dcaliste: did you have anything else to follow up on from the last meeting?
09:12:06 <dcaliste> No, sorry, I was on vacation all July… Besides, I'm trying in my few spare time to set up a Radicale server on my home network only, to serve my private cal data.
09:12:28 <chriadam_> no apology required, of course
09:12:32 <chriadam_> ok, let's continue:
09:12:37 <dcaliste> Hopefully, when up and running, I may reproduce the "no server" bug seen by members on TJC.
09:12:50 <chriadam_> ah!  that'd be great
09:12:53 <chriadam_> #topic MER#1796 - local modification being reported erroneously to calendar events
09:12:54 <dcaliste> And some duplication maybe.
09:13:20 <chriadam_> I didn't get a chance to investigate this one.  I don't know when I will get a chance to do so.  If anyone is able to investigate, let me know - I believe it might be related to alarms/reminders but not 100% sure
09:13:54 <chriadam_> hopefully I'll get a chance to investigate it, but we'll see
09:13:56 <dcaliste> About alarms, I've seen something that I may call strange :
09:14:14 <chriadam_> oh?
09:14:28 <dcaliste> the db contains almost all alarms with action id 0 (no action, or unkniown)
09:14:37 <dcaliste> But some alarms are action 1.
09:14:43 <chriadam_> which db?  calendar db, or the timed events data?
09:14:53 <dcaliste> Yes, the calendar db.
09:15:17 <chriadam_> ok.  what does action 1 mean?  send email / notify / etc?
09:15:28 <dcaliste> All entries are local entries created on phone.
09:15:35 <dcaliste> Action 1 is display.
09:16:30 <dcaliste> I've seen this last week and didn't had time to investigate since to see if the entries with action 1 shres a partern.
09:16:50 <dcaliste> You mention alarms, so it makes a bell ring, but maybe it's not related.
09:17:17 <chriadam_> it could very well be
09:17:36 <chriadam_> I must admit that my understanding of how those fields map to the timed event / alarm struct, is lacking
09:17:54 <dcaliste> Maybe a recent change in code is creating action 1 alarms now ?
09:18:58 <chriadam_> perhaps, yes.  In the MER#1796 case, the change is being reported on every sync cycle, so perhaps that issue is somewhat orthogonal to that, but could be related.
09:19:43 <dcaliste> Yes, I see, you're right, making it triggering on every sync is a different behaviour.
09:20:15 <chriadam_> (unless timed somehow sets it back to 1 after the alarm is shown?  or...?  again, not sure of how timed interacts with mkcal, currently)
09:20:47 <chriadam_> anyway, good that there's a possibility for someone to investigate.  and potentially a separate problem which needs ot be fixed.
09:20:59 <dcaliste> I'll give further look, and try to understand which events have alarm action 1 and which have alarm action 0.
09:21:04 <chriadam_> that'd be great, thanks
09:21:08 <chriadam_> ok, continuing to next topic:
09:21:11 <chriadam_> #topic MER#1714 - isdn field added to phone numbers on upsync (investigation required)
09:21:18 <dcaliste> I'll report during next meeting.
09:22:02 <chriadam_> MER1714 is a low priority but annoying issue.  If anyone gets a chance to investigate, it'd be appreciated.  Get in contact with me if you're interested - basically I believe the issue is in QtVersit choosing ISDN as a default if no tel type data is provided by the plugin
09:22:17 <chriadam_> we shoudl either fix QtVersit or ensure that the plugin passes Landline as a default tel type
09:22:47 <chriadam_> but I cannot spare time to investigate this one properly, unfortunately
09:22:58 <chriadam_> continuing to next topic:
09:23:04 <chriadam_> #topic MER#1751 - main issue resolved, but some minor tasks here remain.
09:23:21 <chriadam_> the issue remaining is that Kerio can store contacts as .eml rather than .vcf, even though they contain vCard data
09:23:42 <chriadam_> if someone wants to modify the plugin so that we "allow" resources of type=contact but with file extension .eml, that'd be great
09:24:26 <chriadam_> this is a good task for a new contributor, if you're wanting to get involved but not sure where to start.  it's not very invasive / can't cause many problems, and nicely self contained task.  contact me if you're interested!
09:24:34 <chriadam_> continuing to next topic:
09:24:37 <chriadam_> #topic Any Other Business?
09:25:01 <chriadam_> nothing from me except to say that I again can't commit much time this month for CalDAV/CardDAV, as far as I know.
09:25:10 <dcaliste> I've pushed a minor modification to icalconverter.
09:25:28 <dcaliste> This allows to choose the notebook to export by its UID.
09:25:31 <chriadam_> oh, needs review?
09:25:43 <dcaliste> It modify the argument parsing to use QCommandLineParser also.
09:25:49 <chriadam_> sure
09:26:01 <dcaliste> There is a MR in nemo-qml-plugi-calendar.
09:27:01 <dcaliste> By the way, the generated ICS contains "ACTION:<void>"  for alarms with action 0 as id, wich may or may not be valid. I need to check.
09:27:13 <dcaliste> But this is the fault (if any) ok kcalcore.
09:27:53 <dcaliste> In icalformat_p.cpp#1071.
09:28:01 <chriadam_> aha
09:28:04 <dcaliste> "s/ok/of"
09:28:10 <chriadam_> definitely sounds problematic
09:28:58 <dcaliste> If the generated s not parsable by let say Radicale, or another, I'll make a MR on kcalcore, not to emit the ACTION entry if action id is 0.
09:29:20 <dcaliste> If ACTION is mandatory, then I'll read the spec to see which value is default.
09:29:26 <chriadam_> that'd be great, thanks very much
09:29:43 <chriadam_> also, just added a comment to that icalconverter MR - please add Contributes to MER#1800 to the summary line
09:30:10 <dcaliste> chriadam_, ok for the MER bug mention. I'll do after meeting.
09:30:21 <chriadam_> no rush :-) I'll review the change properly tomorrow too
09:30:26 <chriadam_> anything else?
09:30:48 <r0kk3rz> chriadam_: any word about unidirectional sync from the ui?
09:31:25 <dcaliste> Just one last word maybe to say, that there will be a need to add an option in icalconverter to export the list of notebooks and their UID.
09:32:03 <chriadam_> r0kk3rz: I have created a PR, it was reviewed, I forgot to merge/tag it.  Will do so tomorrow.  One "wrinkle" is that it currently applies to both CalDAV and CardDAV, not separately... need to consider how to do that, because currently those two profiles share their sync settings between them, so separating them requires a bit of refactoring unfortunately.
09:32:29 <dcaliste> Currently, I find the notebook UID I want to export from the output of the verbose output of the --export option, which is not very convenient !
09:32:44 <chriadam_> r0kk3rz: the real issue (separated addressbooks with separated sync semantics) has been discussed more internally, and we're trying to develop a plan to address the issue and resource it properly.  no promises yet, however..
09:32:54 <r0kk3rz> chriadam_: an improvement at least, thanks :)
09:33:16 <chriadam_> dcaliste: ah, true.  it could certainly be made more user friendly
09:33:59 <dcaliste> With the new QCommandLineParser stuff it's easy to add options and action to the tool anyway.
09:34:49 <chriadam_> yep
09:35:07 <chriadam_> feel free to add a commit to do that, and include in the other MR
09:35:55 <chriadam_> anything else from anyone?  if not, thanks to everyone for their input and help as always, will close the meeting
09:36:01 <dcaliste> I will, but if it's not tomorrow, it will be in two weeks.
09:36:06 <chriadam_> no rush
09:36:45 <dcaliste> Yeh, don't worry, just to let you now the planning :)
09:36:59 <chriadam_> :-)
09:37:06 <chriadam_> ok, closing meeting in 5...
09:37:13 <chriadam_> 4 ...
09:37:20 <chriadam_> 3 ...
09:37:27 <chriadam_> 2 ...
09:37:36 <chriadam_> 1 ...
09:37:39 <chriadam_> #endmeeting