Tuesday, 2019-09-03

*** zbenjamin_ is now known as zbenjamin01:12
Mister_Magisterhow can i depend my app on sailfishos version? Like Rquires=sailfishos >=
ViGeWhy would you want to do that?06:17
Mister_Magisterbecause i want to do that06:18
Mister_Magistermy app could require some sfos version and above06:18
Mister_Magisterbecasue of the new feature or libs06:18
ViGeThen wouldn't it be better to require those?06:18
Mister_Magisteryou can't require then06:19
Mister_Magisterm'kay did this using sailfishsilica-qt5 dep06:34
dcalisteHello chriadam, how are you ?07:06
chriadamhi dcaliste, I'm well thanks07:07
chriadamhow are you?  sorry I missed the meeting last Tuesday, I was out of the office that day and forgot :-(07:07
chriadamI hope that your vacation was nice (I believe you were on vacation the week before?  or am I misremembering)07:07
dcalisteNo problem, I had one week vacation before indeed.07:08
dcalisteMany things on the fxing front last weeks. We may do a review:07:10
dcaliste- kcalcore, https://git.sailfishos.org/mer-core/kcalcore/merge_requests/10, not a real issue, except for the icalconverter export tool.07:10
chriadamlet me check07:11
dcalisteI've exported my full calendar to import it on a openxchange server online, a notice that some events were generated with an invalid DTEND.07:11
dcalisteThis was due to setDtEnd(QDateTime()) in incidencehandler that didn't remove the dt end but was setting at an invalid date time.07:12
chriadamLGTM also, I wonder if flypig has time to merge and tag that one today?  otherwise I will do so tomorrow07:12
dcalisteOk, thanks.07:13
dcalisteLet's move up-stack…07:13
dcaliste- mkcal, https://git.sailfishos.org/mer-core/mkcal/merge_requests/25 about not setting the lastModified field automatically.07:14
dcalistepvuorela suggested to use the same scheme as for dateCreated, if set use it, if not set set it at current.07:15
dcalisteI think it's a good idea to keep the same behaviour than current. I can make the change if you agree also.07:15
chriadamlet me check07:17
chriadamso with the behaviour Pekka is suggesting, how does the user set a last modified time?  just set it to a non-invalid dt?07:22
chriadamotherwise the backend will automatically set one if the lastModified time is currently invalid dt?07:22
chriadamok, sounds like a good compromise to me too07:22
dcalisteIf the event is already in a calendar, the callback from the calendar will update the lastModified value at each modification, like setSummary().07:23
chriadami.e. manually / explicitly?07:23
dcalisteFor new event, the lastModified field is set automatically if not set, otherwise the user value is iused.07:23
dcalisteFor calendar event, this is done automatically by a listener created in the ExtendedCalendar object.07:24
dcalistecode path:07:24
dcalistesetSumarry() will call updated().07:24
dcalisteupdated() will call incidenceUpdated() for each observers (the ExtendedCalendar is a CalendarObserver).07:25
dcalisteand incidenceUpdated() in ExtendedCalendar is calling setLastModified(currentDateTime()).07:25
chriadamI guess that makes sense for any explicit user modification.07:26
chriadamjust doesn't make sense to do it for automatic updates like syncs etc.07:26
chriadamwhich your PR will fix07:26
dcalisteSo yes, any call to set*() methods will change the lastModification date time. The change is that the storage will _not_ change it on save, as it is done now, _except_ if the event does not have a valid lastModfied field yet.07:27
dcalisteYes, this MR is to remove the check for spurious modification due to etag changes in caldav.07:27
chriadamso we just need to make sure that when the user explicitly modifies an event (e.g. in the calendar application) that we explicitly modify lastModification date prior to calling save?07:29
chriadamor maybe it already does that, if I remember correctly?07:29
dcalisteNo probelm for existing workflow in calendar app (I've tested it btw), it's handled by the observer stuff. And for new event, it will be handled by pvuorela modification.07:30
dcalisteGreat, so I'll ping later when I've done suggested modifications.07:33
dcaliste- mkcal, https://git.sailfishos.org/mer-core/mkcal/merge_requests/24 about the issue with all day event when changing time zone.07:33
dcalisteIt's an ugly patch, but it's supposed to do the job.07:34
chriadamlast comment suggests that there is some issue with nemo calendar - can you elaborate?07:35
dcalisteI think the question of pvuorela was about the case when having an exception given without time zone. (this is not possible to be done currently in ui because all date time are always with a tz, the local one).07:39
chriadamI see. can a synced exception occurrence event have this clocktime timespec?07:40
dcalisteIn that case, the test to detect if all day (see the changes) will indeed not work but the date time will be in that case exactly what it will be transformed into if detected as all day…07:42
dcalisteSo clock time spec with 00:00 time should work, in my opinion.07:42
dcalisteEven when coming from sync.07:42
chriadammy original opinion was that we should merge that change, so I have no issues with that still07:43
chriadamI see flypig also approved07:43
dcalisteOk, thanks.07:43
chriadamI will merge and tag tomorrow unless flypig has time to do so today07:44
dcaliste- buteo caldav, https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/50 some correction to issue due to early save to storage for etags.07:45
dcalisteThe notebook pointers are not safe because any modification to the storage is creating new pointers to notebooks, even for unchanged ones.07:46
dcalisteSo, when using a notebook pointer to change it, we get it from storage first.07:46
chriadamLGTM too, I checked that one last week but forgot to merge tag07:47
chriadamagain, will do so tomorrow07:47
chriadamsorry for being the bottleneck here!07:47
dcaliste- buteo caldav, https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/49 some issue fixed with HTML entites from SoGo servers.07:48
chriadamah we discussed this last time IIRC.  I was meant to merge that one too07:48
chriadamalso #4307:49
chriadamthat one also requires the settings-accounts PR IIRC07:49
chriadamwill merge those two tomorrow also.07:50
chriadamdid Jaymzz contact you about the blog post yet?  I haven't heard anything more from him since two weeks ago actually07:50
chriadamwhen he said it might be delayed, presumably due to his vacation or whatever07:51
dcalisteGreat for #43, it would be a nice addition (not just bug correction) ! It requires a patch in sailfish settings indeed.07:51
dcalisteAbout the blog post, yes Jaymzz contacted me and I provided him with a bio. I guess that it's going on, he will send proofs when ready.07:52
dcalisteHe told me that you indicated to him how to enable (install) on device, so nice.07:52
chriadamhopefully that doesn't take much longer to be published, then07:54
chriadamdid you have anything else to discuss?07:55
dcalisteI didn't have time to update the email folder sync proposal after discussion with pvuorela. About caldav, I still have https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/45 that should be tested more before accepting it.07:57
dcalisteAnd also, hopefully we can reach an agreement on https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/2707:58
chriadamoh let me check that one07:58
dcalisteAbout !45 in caldav, I'll rebase it when all other MR discussed will land, because it is containing some changes that have been included into more urgent MR like !50.08:00
chriadamok, great.  I will merge/tag those other ones tomorrow, so hopefully e.g. thursday you should be able to rebase cleanly08:01
chriadamfor the syncfw one, I will defer to slava and pekka08:01
chriadamonce they're happy, I am happy to merge/tag.  I definitely agree that the bug needs to be fixed, so we should be pragmatic.08:01
dcalisteIndeed, last proposition is representing really minimal changes to existing code, and it's not waking me up in the night anymore ;)08:03
*** frinring_ is now known as frinring08:03
dcalisteBesides, thanks to pvuorela for accepting jolla-calendar patch to sync on update only modified calendar.08:03
dcalisteWe can continue to discuss remaining MRs next week otherwise. Thank you for taking time to review.08:04
dcalisteAh, forgot, there is this one also : https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/47 but definitely, we can discuss about it next week. Not in a hurry.08:05
dcaliste(implement sync direction for caldav plugin).08:05
chriadamsync direction08:09
chriadamyes we should fix that08:09
chriadambut maybe we can discuss it next week08:09
chriadamdcaliste: thanks again for your hard work.  sorry that I've been letting the ball drop a bit on these things in the last couple of weeks.  should be back to normal next week with luck.  I will merge those PRs we discussed tomorrow.08:10
dcalisteNo problem, anyway 3.1.1 is not freezed as far as I know, so it's fine. Let's see next week what remains on the board.08:11
chriadamyep, have another week afaik for it.08:11
chriadamsounds good - have a great week!08:11
dcalisteThanks, have a good night.08:11
*** Renault_ is now known as Renault08:47
attah /poke flypig18:19
attahPython sharing plugins, could that be a thing?19:24

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