Tuesday, 2019-09-24

*** frinring_ is now known as frinring04:02
dcalisteHello chriadam, sorry to be late, so long lines on the motorway this morning…07:15
chriadamhi dcaliste, no problem at all07:15
chriadamI hope you had a good week07:15
dcalisteYes, was fine, thank you. I've just seen, you're pushing some fixup in caldav ? I wanted to ask, indeed:07:16
dcalisteI didn't see caldav plugin being mentioned in the changelog.07:16
chriadamyes, sorry about that :-(  I only just noticed that the 0.1.51 tag failed integration07:16
chriadamso 0.1.50 was the last one which was accepted.  dunno how I didn't see that07:17
chriadamso I did some packaging fixes and did the CI dance.  a few tags later, 0.1.54 contains the fixes (and was accepted by CI) but won't be in the upcoming release unfortunately07:17
dcalisteOk, I was wondering! Do you think it will be included in later iteration of the 3.2.0 series ?07:17
chriadambut will be in the next one (3.2.1)07:17
dcalisteAh, ok.07:17
chriadamon the bright side, bree has agreed to do some in-depth testing of your outstanding PRs, either this week or next.  I will merge those as soon as she provides her feedback there07:18
dcalisteGreat news! I'll try to be responsive if she has some issues.07:19
chriadamthank you07:20
chriadamwhere are we with mkcal MR#17?07:21
dcalisteLooking at the diff, it's strange I didn't see the packaging issue with the missing cdata test file…07:21
dcalisteAh, about mkcal#17…07:21
chriadamdcaliste: it's weird, my local mb2 builds never failed07:22
dcalisteYeh, the same for me. Usually a mssing file in package is reported as an error.07:22
dcalisteNo further study on #17, let's summarize the topic:07:23
dcaliste- all day is not a field in iCal format.07:23
dcaliste- starting points (and ending ones) can be specified as date only, which is the closest approximation to an all day event.07:24
chriadamin which case they will be clock-time since a date-only cannot include tzid?07:24
dcaliste- libical is reporting if a startdt is given as a date only. Current kcalcore is setting the day only bit of KDateTime then.07:25
dcaliste- but next kcalcore is using QDateTime whichj does not have this bit. In that case, recent kcalcore is setting the full day flag of the incidence.07:25
dcaliste- current implementation is relying on the day only bit of KDateTime _and_ sometimes on the full day flag of the incidence.07:26
dcaliste- in addition, servers are not dealing with full day events all the same way: as shown by flypig tests with Thunderbird, some incidence with with 0 time are considered as full day (which is the case currently also for mkcal).07:27
dcaliste- to complexify the issue, the time 0 definition is not clear, because it depends if it is clock time or a tz time and in which tz we are currently.07:28
dcaliste- to finally make the camel back break, QDateTime which will be in use in modern kcalcore, there is no clock time spec, all times are given with a tz, local, UTC or another.07:29
chriadamso some specific flags seem necessary to "carry along" with every QDateTime to mark whether it's actually clocktime and/or dateonly07:30
dcalisteTo conclude, we've got 8 points here that makes the problem a nightmare.07:30
dcalisteFor the issue to-come, this flag already exists, it's the full day flag of every incidence.07:30
chriadamI am surprised that modern QDateTime doesn't include a ClockTime tz spec07:30
dcalisteIn fact, QDateTime doesnot have a clock time spec, because it has no sense. The date is superfluous and one should use QTime only for that matter. I guess.07:31
dcalisteI've checked that modern kcalcore is consistently using the full day flag everytime a dayOnly bit was used before.07:32
dcalisteIt's quite clean.07:32
dcalisteNow, in mkcal, we're using the dayonly bit only in two places and I would like to change it for the incidence full day flag.07:32
chriadamI'm not sure I'm following regarding QDateTime and clocktime spec - isn't it needed for things like: "Christmas Lunch is at 12:00 on 25 Dec regardless of your timezone" etc?07:33
dcalisteSo like that, we'll be future ready.07:33
dcalisteAh, right for Christmas lunch…07:33
dcalisteIn my opinion, this information cannot be represented by itself in a QDateTime…07:34
chriadamor new years eve is at 23:59:59 on 31st Dec regardless of your tz07:34
chriadamdang.  maybe I should mention that to Thiago, although I assume he had good reasons to omit it07:34
dcalistetime spec: https://doc.qt.io/qt-5/qt.html#TimeSpec-enum07:35
dcalisteMaybe there's something I misunderstood…07:36
chriadamprobably not, it's probably just an omission.  just a surprising one, as I thought John Layt was trying to make QDateTime support everything which KDateTime provided so that KDateTime could be obsoleted07:36
dcalisteWell, to go back to our #17, here is the blocking issues I'm facing:07:37
dcaliste- don't use the day only flag of KDateTime (I'm sure it's a good idea, but I'm not convinced it will not have some unexpected effects).07:38
dcaliste- how to treat 0 time events (keep the old behaviour with tricks or be strict with the date only iCal specs).07:39
dcalisteOf course being strict will break existing full day events and compatibility tricks for some servers or "common" practices.07:40
chriadamif we could quantify which servers that's likely to cause issue with, I'd be more comfortable trying to make a judgement call07:41
chriadamas it is, I have no idea07:41
dcalisteMe neither :( Besides, looking again at #17, it is a bit more restricted than trying to solve for good every full day issues. I can review it again this week to the light of today discussion and amend it or comment in Gitlab.07:43
chriadamno rush07:43
chriadamwas just wondering if there was current action points on our side there07:43
dcalisteAt least, trying to keep the current behaviour and fix the issue of time 0 event with a time zone.07:44
chriadamfwiw we're going to be busy this week + next doing final polish + fixes for the release.  after that we will all have a bit more availability I think.07:44
chriadamyes, I agree that goal is good one07:44
dcalistechriadam: I've seen Bea Lam (or someone else, don't remember) doing some modifications in sailfish-component-accounts on the DAV services to be a bit more generic (i.e. webDAV). Does it make sense to resurrect my old attempt to have a webDAV sync plugin ?07:47
chriadamit will in the nearish future07:47
dcalistesee https://bitbucket.org/jolla/ui-jolla-settings-accounts/branch/jb46973-nextcloud-ui07:47
dcalisteIt was setting accounts, not component-accounts…07:48
chriadamwe're currently working on nextcloud support, but only a subset of features (i.e. not including generic file sync)07:48
chriadamthe generic file sync will be investigated in the nearish future (i.e. within a couple of months i guess)07:48
chriadamnot sure what the thinking is there (do we want to do some form of lightweight overlay, e.g. sync the metadata but not the files, and only sync the file content when the user attempts to access/open specific file) etc07:49
chriadamwe need to do some thinking / investigation / etc there.  also - how is the content exposed in the UI?  and how does it play with e.g. tracker / indexing / thumbnailer etc07:49
dcalisteGood, if you need some help or testing, that's interesting. You can look at https://git.merproject.org/dcaliste/buteo-sync-plugin-webdav for the sync part (webDAV based).07:50
chriadamyep, saw that one07:50
chriadamhad remembered it from a while ago ;-)07:50
dcalisteIt was using the same approach than for calDAV but with files, using delta calculation and etags.07:50
chriadamnice one07:50
dcalisteThe main issue I guess was the time for transfer which may be an issue with respect to buteo sync daemon (killing plugin after a while).07:51
chriadammaybe can somehow combine that with whatever overlay / lightweight mechanism we come up with, and use that plugin to sync the file data when required (i.e. pass in some list of paths to sync vs not sync).07:51
chriadamoh ouch.  I guess buteo has some edge things like timeouts we need to consider. also connectivity type (e.g. do file sync over wifi only, etc)07:52
dcalisteThe idea was to keep a subdirectory structure in sync with a distant one, both ways or one direction only.07:52
dcalisteYes, buteo has the stuff for connectivity selection.07:52
chriadamyeah, although not sure that we report it appropriate to buteo, so that it can tell the plugins ;-)07:52
dcalisteBut I didn't implement it in the plugin. Can add it later I guess.07:53
chriadamwill have to check that.  maybe it's reported from QNetworkSession, but maybe it needs something from connman? not sure.07:53
dcalisteNo it's already present in Buteo.07:53
chriadamah, it detects it properly?07:53
dcalisteYes, I think so.07:53
dcalisteWhen running msyncd in debug mode, we often see the connectivity events.07:54
dcalisteChanging with network type.07:54
dcalisteLet me find it in the source…07:54
dcalisteThere is a connectivityStateChanged virtual func to be implemented in plugins.07:54
dcalisteWith a Sync::ConnectivityType argument.07:55
dcalisteSee libbuteosyncfw/common/SyncCommonDefs.h07:56
dcalisteThere is this InternetConnectionType enum that can be polled from somewhere I guess.07:57
chriadamyep, I know the signal exists.  was just wondering how buteo detected which underlying connectivity type is used (wifi vs cellular).  it'd either be reported from Qt (e.g. via Bearer API or something) or from connman itself.07:57
chriadambut assuming it does it already, using the appropriate API, then all is well :-)07:57
dcalisteAh, I see, sorry.07:57
chriadamI just wasn't clear ;-)07:59
chriadamwere there any other action points for me, this week?08:00
dcalisteLooking at the spec, buteo is not depending on conman, so I guess it's based only on QNetworkSession.08:00
chriadamor anything you'd like me to poke pvuorela or flypig about?08:00
dcalisteno it's fine, I would like to ask pvuorela or sage to review python08:00
dcalisteI've followed sage suggestion to add a new spec file to package no necessary modules separately and have python3-base having minimal dependencies.08:01
chriadamsounds good, thanks, I will08:02
dcalisteOf course, when they have time ;)08:03
chriadamindeed, hopefully soon08:03
dcalisteWhen having these two specs, there are new possibilities to move some modules from base to extra (the new spec) so the bootstrap dependencies can be even more reduced.08:04
chriadamah, nice08:05
chriadamI haven't been following that one, but I have pinged pekka in an internal chat channel, hopefully he will check soon.08:05
dcalisteThanks, some people will be happy to have the ncurse module back then!08:06
chriadamno doubt08:07
chriadamwas there anything else to discuss?08:07
dcalisteNo, it's ok. I'll look at mkcal#17 in the coming days and report in Gitlab.08:08
dcalisteThank you chriadam and have a nice evening.08:08
chriadamthank you again for your time and effort08:09
chriadamhave a great week!08:09
adisbladisTheKit: Jolla finally provided a image and that worked14:18
*** SpeedEvil is now known as Guest5053118:49
*** BitEvil_ is now known as SpeedEvil18:59

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