08:00:55 <chriadam__> #startmeeting Sailfish OS CalDAV/CardDAV contributors meeting
08:00:55 <merbot`> Meeting started Mon Feb  5 08:00:55 2018 UTC.  The chair is chriadam__. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
08:00:55 <merbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:01:03 <chriadam__> #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#05.2F02.2F2017_Meeting
08:01:29 <chriadam__> Firstly, welcome back everyone for 2018, I hope everyone had a great christmas and new year etc
08:01:58 <chriadam__> Secondly, dcaliste isn't able to make the meeting today as he has a prior commitment, so this might be a quick meeting ;-)
08:02:28 <dcaliste> In fact, I just arrived from the station in Switzerland and I can attent the meeting.
08:02:30 <chriadam__> The agenda is available at the link above, I'll cover the current status and plan going forward for this month, so that it's logged and folks can read it offline :-)
08:02:35 <chriadam__> oh welcome!
08:02:47 <dcaliste> Thanks!
08:03:06 <chriadam__> Ok, let's get started with agenda:
08:03:07 <chriadam__> #topic Introductions
08:03:17 <chriadam__> Please introduce yourself with #info name/nick
08:03:21 <chriadam__> #info Chris Adams, developer at Jolla
08:03:25 <dcaliste> #info Damien Caliste, community
08:03:37 <chriadam__> abranson: ping are you available today?
08:04:00 <abranson> chriadam__: yep, got back last night!
08:04:05 <chriadam__> great!  how was fosdem?
08:04:09 <abranson> #info Andrew Branson, dev @ Jolla
08:04:18 <abranson> really great, i'll be going again for sure
08:04:21 <chriadam__> nice one
08:04:25 <abranson> thanks for the ping
08:04:28 <chriadam__> ;-)
08:04:49 <chriadam__> ok, let's start the rest of the agenda :-)
08:04:54 <chriadam__> #topic Follow-up Agenda Items From Last Meeting
08:05:00 <chriadam__> I tested, created fix, and merged/tagged the fix for MER#1822.  Should be in the next release.
08:05:07 <chriadam__> dcaliste mentioned an issue affecting his date-range PR (radicale doesn't return the correct output), so more investigation required there
08:05:17 <chriadam__> is there any outstanding action point for me there, at the moment?
08:05:36 <dcaliste> I've finished the initial version of WebDAV.
08:05:51 <chriadam__> fantastic!
08:05:57 <chriadam__> so I need to add the UI bits etc I guess
08:06:18 <dcaliste> Yeh, when yyou have time of course ;)
08:06:25 <chriadam__> time is short at the moment :-(  but will try
08:06:30 <abranson> really great news!
08:06:46 <chriadam__> abranson: is that one building in mer:contrib OBS too?  what are steps I need to take on device to pull that one in?
08:06:47 <dcaliste> I've added a small cli tool to add accounts.
08:07:53 <dcaliste> Cli tool is based on cdavtool, one can add a new account, modify password or host server and delete account.
08:08:48 <chriadam__> dcaliste: I still haven't looked at it in detail, does it synchronise some specific folder between local device and remote server?  is the local folder parametrised e.g. account setting?  is the remote folder a parameter too?
08:09:03 <dcaliste> Yes too all!
08:09:23 <chriadam__> cool :-)
08:09:24 <abranson> chriadam__: checking if it's on OBS - I think I did that
08:09:36 <abranson> though we had problems with the webhooks triggering
08:09:40 <dcaliste> Yes, it's in OBS in mer-core-contrib
08:10:15 <abranson> so you'd just need to add the repo to SSU, the URL of which I'll look up now
08:10:40 <abranson> http://repo.merproject.org/obs/mer:/core:/contrib:/webdav/armv7hl/
08:10:48 <chriadam__> great, thanks
08:11:01 <chriadam__> so, something like: ssu ar mer-contrib http://repo.merproject.org/obs/mer:/core:/contrib:/webdav/armv7hl/
08:11:03 <abranson> (or i486)
08:11:04 <chriadam__> on device?
08:11:08 <abranson> yep
08:11:11 <chriadam__> sweet
08:11:12 <chriadam__> thanks
08:11:17 <abranson> really accessible I think
08:11:23 <chriadam__> ok, did I miss anythign else from last year's last meeting?
08:11:48 <abranson> i'm trying to separate each 'feature' so people can add them individually
08:11:56 <dcaliste> Thank you for the inclusion of all CalDAV MRs.
08:12:13 <dcaliste> Before your holidays.
08:12:22 <chriadam__> dcaliste: thank you for your hard work as always
08:12:27 <chriadam__> if I forgot any PR ping me
08:12:31 <chriadam__> ok, let's continue with agenda:
08:12:32 <chriadam__> #topic Open MER bugs
08:12:39 <chriadam__> MER#1751 - path discovery issue - most of this was fixed, but one issue remains (related to MER#1863, really).
08:12:48 <chriadam__> MER#1863 - contact resources ignored if they don't end in .vcf.  dcaliste had some feedback, and I need to check my SDK to see if the private headers are really required
08:12:56 <chriadam__> so that one, I might generalise a bit more as per dcaliste's feedback
08:13:07 <chriadam__> MER#1836 - reminders/alarms for all-day events don't work.  has this been fixed?  need to check
08:13:35 <chriadam__> are there any other open mer bugs which need attention?  there are two TJC issues which need mer bugs created for them, but I'll discuss those next
08:14:47 <abranson> someone asked me about a vcard date format. i think that has a JB already
08:14:56 <abranson> is that one of the TJC ones?
08:14:59 <chriadam__> yes
08:15:07 <chriadam__> ok, let's discuss those two:
08:15:08 <chriadam__> #topic Issues noted from TJC (birthday format, double slash in path, ...)
08:15:14 <chriadam__> one issue with birthday format not being RFC compliant
08:15:20 <chriadam__> fix should be simple: https://git.merproject.org/mer-core/qtpim/blob/mer-master-on-5.6/src/versit/qversitcontactexporter_p.cpp#L502
08:15:25 <chriadam__> one issue with double-slash in path causing issues with some servers.
08:15:31 <chriadam__> fix should be simple: carddav.cpp#L1092 appends a / unconditionally to the PUT URL, but if it already ends with a / then that results in a double-slash.
08:15:51 <chriadam__> I haven't had time to create MER# bugs or fixes, but should be straightforward once I get a chance
08:16:09 <chriadam__> if any new contributors read this log and want to help, please feel free to grab those and submit fixes!
08:16:19 <chriadam__> also there is a pending fix to carddav which needs a unit test but aside from that is good to go
08:16:36 <chriadam__> is there anything else from TJC which needs attention?
08:17:10 <dcaliste> There is a TJC about birthday without year
08:17:20 <dcaliste> Related to vCard format 4
08:17:25 <chriadam__> ah
08:17:38 <chriadam__> interesting
08:17:50 <dcaliste> (looking for link)...
08:18:10 <chriadam__> I can't remember how fully QVersit supports vcard 4, hopefully it's a simple matter to add support for that... hrm.  I wonder if QDate supports that... hrm...
08:18:51 <dcaliste> https://together.jolla.com/question/36685/allow-unknown-birth-year-for-contacts-in-calendar
08:18:55 <chriadam__> thanks
08:19:06 <chriadam__> ok, I will create a MER bug about that one too
08:19:23 <chriadam__> not sure when I'll get around to investigating though, probably considered quite low priority I guess
08:19:30 <abranson> ah, for the discreet gentleman :D
08:19:32 <dcaliste> Oh, did it already, see https://together.jolla.com/question/36685/allow-unknown-birth-year-for-contacts-in-calendar
08:19:39 <dcaliste> Sorry wrong link
08:19:47 <dcaliste> https://together.jolla.com/question/36685/allow-unknown-birth-year-for-contacts-in-calendar
08:19:51 <dcaliste> Arg
08:19:54 <dcaliste> https://bugs.merproject.org/show_bug.cgi?id=1872
08:19:55 <merbot`> Mer bug 1872 in buteo-sync-plugin-carddav "Allow unknown year for birthday date" [Task,New]
08:20:00 <abranson> https://bugs.merproject.org/show_bug.cgi?id=1872
08:20:00 <chriadam__> ah
08:20:07 <abranson> sorry! too late!
08:20:29 <chriadam__> weird that one didn't show up in my bugs list
08:20:31 <chriadam__> I will add myself to cc
08:20:57 <chriadam__> hrm, I'm in the cc list
08:21:01 <chriadam__> my filter must be brokne
08:21:19 <chriadam__> interesting point about the upsync
08:21:22 <dcaliste> There is this question on TJC https://together.jolla.com/question/178570/caldav-with-mailfence
08:21:34 <dcaliste> But didn't have time to investigate yet.
08:22:51 <chriadam__> I just took a quick look at the log: there are 5 events at least which were synced
08:23:07 <chriadam__> this isn't the initial sync log, since some .ics were already previously synced
08:23:20 <chriadam__> hrm, I guess we need the "initial" sync log to know what might be synced and what not
08:23:36 <chriadam__> oh whoa
08:23:39 <chriadam__> and more ...
08:23:40 <chriadam__> urgh
08:23:49 <chriadam__> yeah, I will analyse the rest of that log file some other time
08:24:15 <abranson> chriadam__: did you see that data loss one that came in via Jolla yesterday?
08:24:18 <dcaliste> Thank you. I'll have time this week to also look at it I guess.
08:24:44 <chriadam__> abranson: yes, I saw it... I don't know what to say other than "we need to upgrade QtPIM, and update our sync plugins to use properly-separated-addressbooks"
08:24:51 <abranson> :/
08:25:31 <chriadam__> we know that contact sync semantics are broken because of ancient decisions, and can't fix it until we require that contact additions/edits are placed into a specific addressbook by the user as part of the UI flow
08:25:48 <chriadam__> (and support specific addressbooks in the backend).  technically we could  hack it with synctarget, but I'd prefer to do it properly.
08:26:35 <abranson> definitely. is that something community can do? it doesn't affect the UI much, does it?
08:26:57 <abranson> people were asking for possible tasks in a recent mer meeting
08:27:24 <chriadam__> There is UI involved (e.g. when user edits or adds a contact in People app, have an intermezzo dialog asking which addressbook to place the contact in)
08:27:31 <chriadam__> but the majority of it is non-UI, open-source
08:27:55 <chriadam__> I will send you a link in a bit (on internal irc) with the details.  we can pry out the OSS side from that.
08:28:04 <chriadam__> definitely would appreciate help with it from community.
08:28:19 <abranson> yeah that should be a minor part, and easily doable around the contrib. so it wouldn't require a huge rewrite of all the queries for the new version then?
08:28:35 <dcaliste> As a related thought, I'm wondering for a while if we should do this also for calendars?
08:29:13 <abranson> that's related to the duplicate calendar on crash iirc?
08:29:47 <dcaliste> I'm thinking about this to have calendars that are not priviledged.
08:30:05 <dcaliste> So Store app can interact with them.
08:30:51 <dcaliste> The example would be the todos for instance.
08:31:28 <dcaliste> Adding Todos through calendar UI, and having specilized app managing todo lists that can interact with the same data.
08:32:27 <abranson> per-app calendars is a good idea
08:33:00 <abranson> e.g. web ics calendars
08:33:11 <abranson> such as airbnb provides
08:33:13 <chriadam__> we should indeed have daemons which provide API via IPC, which can be properly access-controlled, etc.  and would also allow per-app storages etc.
08:33:36 <chriadam__> but that's something which needs to be discussed in context of security (SELinux / flatpak etc) and is a bigger / different piece of work IMO
08:33:40 <chriadam__> abranson: I just sent you an email
08:33:44 <abranson> thx
08:34:07 <chriadam__> anyway, let's come back to this at next meeting, I think, once abranson has had a chance to digest that email and we can plan going forward
08:34:23 <dcaliste> Yeh, sure.
08:34:27 <chriadam__> #topic Is the workaround still required to build with the Application SDK (martyone said it should be fixed / no longer necessary)
08:34:52 <chriadam__> dcaliste: martyone asked me to ask you this: apparently the instructions on the wiki page include a workaround for some permissions or something
08:35:07 <chriadam__> he asked me to ask you if that was still required, as he believes that it should not be required any more (the issue was apparently fixed)
08:35:25 <chriadam__> are you able to comment on whether that has been fixed or is still required?
08:35:39 <dcaliste> I don't remember about this. let me read again the wiki.
08:36:48 <chriadam__> (I'm not 100% sure what he was referring to, maybe the execute permission bit not being set on the build artifacts?  or?)
08:37:33 <chriadam__> although that limitation would seem to me to be a VirtualBox limitation rather than something we could fix in the Application SDK, so not sure
08:37:47 <dcaliste> Is it the fact that I adviced to copy the source to /home/deploy because /home/mersdk/share does not handle the execute bit properly?
08:38:10 <abranson> ah because it's an encrypted home?
08:38:19 <dcaliste> No, not necessary.
08:38:50 <chriadam__> which line(s) should I delete or change in the wiki?
08:39:04 <dcaliste> When I first used SDK some years ago, the shared home has some issue the excutable bit was not set by make.
08:39:31 <dcaliste> I found out at that time that the mount made by VirtualBox did not handle the execute properly
08:39:47 <dcaliste> A bit like when mounting a FAT tree under Linux.
08:39:53 <chriadam__> right
08:40:09 <dcaliste> Maybe now, it's fine. I didn't try it again and I'm always building in /home/deploy
08:40:29 <dcaliste> Or maybe at that time I was wrong also ;)
08:40:43 <chriadam__> I'm sure you were right, as martyone said that something there had been fixed
08:41:01 <chriadam__> but I don't use the application sdk so I wasn't sure what precisely had been broken in the past, and then fixed
08:41:27 <chriadam__> ok, so I think I'll update the wiki to remove that line about the execute permissions not being set, and then add a note to say "if you have issues with the execute permission bit, you can try copying ..." etc
08:41:29 <dcaliste> I'll try this evening to build in /home/mersdk/share directly and report tomorrow.
08:41:39 <chriadam__> that'd be great, thanks.  no rush of course.
08:42:11 <chriadam__> ok, next agenda topic:
08:42:12 <chriadam__> #topic Any Other Business?
08:42:35 <chriadam__> Nothing else from me, except that I will again have limited availability for carddav/caldav development this month.  secrets/crypto taking most of my time.
08:42:54 <dcaliste> I'm testing the issue when pushing changes to recurring event.
08:43:00 <chriadam__> (on that note, I haven't yet had a chance to add the API you asked me about, regarding generating and storing a key from a user-supplied-passphrase)
08:43:09 <dcaliste> I'll push a MR soon where we can discuss the design choices.
08:43:12 <chriadam__> great
08:43:14 <chriadam__> thanks
08:43:32 <dcaliste> (Thanks anyway for the secret work, I'm waiting)
08:43:44 <dcaliste> And monitoring the PR in Github.
08:44:11 <chriadam__> :-)
08:44:22 <chriadam__> abranson: anything else to discuss that you can think of?
08:44:44 <abranson> no I think that's everything. still reading your email ;)
08:45:00 <abranson> oh, though the ICS thing has me thinking
08:45:49 <abranson> could that be a nice and easy community calendar add-on?
08:46:48 <dcaliste> Yes, I agree. One should discuss though where to put it, in which component.
08:47:10 <chriadam__> this is "not sync, but display" ?
08:47:13 <chriadam__> or?
08:47:23 <abranson> yep. read-only calendar synced from a URL
08:47:44 <dcaliste> Oh, I forgot, besides, I'm rewriting part of CalDAV to put everything related to ICS handling into one class separated from notebooksyncagent.
08:47:45 <abranson> i would have thought it would be done through accounts
08:48:06 <abranson> dcaliste: that sounds like a step towards that then!
08:48:17 <dcaliste> abranson: or a bit like with email calendar invitation.
08:48:41 <abranson> ah you mean when you find them with the browser? could be
08:48:44 <dcaliste> This rework is in my tidy branch if you want to give a look.
08:49:13 <dcaliste> I'm going to make a MR in the coming weeks, I was waiting for bug stabilisation first.
08:49:24 <dcaliste> abranson: yes indeed.
08:49:26 <chriadam__> definitely sounds like a good idea.  unfortunately I don't have time to review it thoroughly just now :-(
08:49:51 <dcaliste> I still need to test it intensively though, so you have time.
08:50:00 <abranson> i suppose it'd be two separate parts - one that fetched an ics file and saved it to an existing calendar, and another that uses a remote ICS file to sync a local read-only calendar. for some reason i only had the second one in mind.
08:50:26 <abranson> but the first would be really similar to email invite yeah
08:50:54 <chriadam__> I think we'd need to consider carefully how we intend to do that for email invites in the qmf/caldav case
08:51:05 <chriadam__> and unify the approach for web-browser case also
08:51:06 <dcaliste> Oh, now I understans your second point and why you pointed it to account, indeed.
08:51:52 <dcaliste> chriadam__: I'm afraid currently ICS importation is done by dedicated code in nemo-qml-plugin-emqail
08:51:58 <chriadam__> ah
08:52:27 <chriadam__> I guess we do somethign similar as for bluetooth import or some such
08:52:30 <chriadam__> shrug
08:52:34 <chriadam__> need to fix it some day
08:52:42 <dcaliste> Which bring me back to my earlier point of having a small lib for ICS handling.
08:52:56 <dcaliste> Doing all the dirty work for all day events...
08:53:23 <chriadam__> would be handy, to unify our handling
08:53:41 <chriadam__> well, let's discuss that another time I guess, we have more than enough on our plates for the moment :-)
08:53:48 <chriadam__> quick wrap up of action points:
08:54:09 <chriadam__> 1) I need to create the mer bugs about those two TJC issues
08:54:21 <chriadam__> 2) preferably I should also fix those two ;-)
08:54:40 <chriadam__> 3) dcaliste will investigate the mailfence caldav log
08:55:09 <chriadam__> 4) chriadam to take a look at the webdav sync stuff and being implementing the UI bits
08:55:29 <chriadam__> 5) dcaliste will test the application SDK build artifact permission bits
08:55:43 <chriadam__> 6) abranson will consider the email and come up with a plan for community contribution to QtContacts etc
08:56:10 <chriadam__> 7) dcaliste is working on a variety of things including a refactor of the caldav ICS handling etc
08:56:14 <chriadam__> did I miss anything?
08:57:09 <dcaliste> 8) dcaliste push a fix for the issue when sending mods to a recurring event.
08:57:33 <chriadam__> yep, thanks
08:57:43 <chriadam__> I think that about covers it!
08:57:48 <dcaliste> Otherwise, nice list.
08:57:58 <chriadam__> huge thanks once again for your effort and help with this domain, dcaliste!
08:58:01 <chriadam__> and you too abranson :-)
08:58:08 <chriadam__> if nothing else, ending meeting in 5...
08:58:15 <chriadam__> 4...
08:58:18 <dcaliste> Well, it's fun. thank you two also.
08:58:19 <chriadam__> 3...
08:58:23 <chriadam__> 2...
08:58:26 <abranson> thanks chris and damien!
08:58:26 <chriadam__> 1...
08:58:29 <chriadam__> #endmeeting