| *** frinring_ is now known as frinring | 04:02 | |
| dcaliste | Hello chriadam, sorry to be late, so long lines on the motorway this morning… | 07:15 |
|---|---|---|
| chriadam | hi dcaliste, no problem at all | 07:15 |
| chriadam | I hope you had a good week | 07:15 |
| dcaliste | Yes, was fine, thank you. I've just seen, you're pushing some fixup in caldav ? I wanted to ask, indeed: | 07:16 |
| dcaliste | I didn't see caldav plugin being mentioned in the 3.2.0.2 changelog. | 07:16 |
| chriadam | yes, sorry about that :-( I only just noticed that the 0.1.51 tag failed integration | 07:16 |
| chriadam | so 0.1.50 was the last one which was accepted. dunno how I didn't see that | 07:17 |
| chriadam | so 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 unfortunately | 07:17 |
| dcaliste | Ok, I was wondering! Do you think it will be included in later iteration of the 3.2.0 series ? | 07:17 |
| chriadam | but will be in the next one (3.2.1) | 07:17 |
| dcaliste | Ah, ok. | 07:17 |
| chriadam | on 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 there | 07:18 |
| dcaliste | Great news! I'll try to be responsive if she has some issues. | 07:19 |
| chriadam | thank you | 07:20 |
| chriadam | where are we with mkcal MR#17? | 07:21 |
| dcaliste | Looking at the diff, it's strange I didn't see the packaging issue with the missing cdata test file… | 07:21 |
| dcaliste | Ah, about mkcal#17… | 07:21 |
| chriadam | dcaliste: it's weird, my local mb2 builds never failed | 07:22 |
| dcaliste | Yeh, the same for me. Usually a mssing file in package is reported as an error. | 07:22 |
| dcaliste | No 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 |
| chriadam | in 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 |
| chriadam | so some specific flags seem necessary to "carry along" with every QDateTime to mark whether it's actually clocktime and/or dateonly | 07:30 |
| dcaliste | To conclude, we've got 8 points here that makes the problem a nightmare. | 07:30 |
| chriadam | indeed | 07:30 |
| dcaliste | For the issue to-come, this flag already exists, it's the full day flag of every incidence. | 07:30 |
| chriadam | I am surprised that modern QDateTime doesn't include a ClockTime tz spec | 07:30 |
| dcaliste | In 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 |
| dcaliste | I've checked that modern kcalcore is consistently using the full day flag everytime a dayOnly bit was used before. | 07:32 |
| dcaliste | It's quite clean. | 07:32 |
| dcaliste | Now, 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 |
| chriadam | I'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 |
| dcaliste | So like that, we'll be future ready. | 07:33 |
| dcaliste | Ah, right for Christmas lunch… | 07:33 |
| dcaliste | In my opinion, this information cannot be represented by itself in a QDateTime… | 07:34 |
| chriadam | or new years eve is at 23:59:59 on 31st Dec regardless of your tz | 07:34 |
| chriadam | dang. maybe I should mention that to Thiago, although I assume he had good reasons to omit it | 07:34 |
| dcaliste | time spec: https://doc.qt.io/qt-5/qt.html#TimeSpec-enum | 07:35 |
| dcaliste | Maybe there's something I misunderstood… | 07:36 |
| chriadam | probably 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 obsoleted | 07:36 |
| dcaliste | Well, 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 |
| dcaliste | Of course being strict will break existing full day events and compatibility tricks for some servers or "common" practices. | 07:40 |
| chriadam | if we could quantify which servers that's likely to cause issue with, I'd be more comfortable trying to make a judgement call | 07:41 |
| chriadam | as it is, I have no idea | 07:41 |
| dcaliste | Me 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 |
| chriadam | no rush | 07:43 |
| chriadam | was just wondering if there was current action points on our side there | 07:43 |
| dcaliste | At least, trying to keep the current behaviour and fix the issue of time 0 event with a time zone. | 07:44 |
| chriadam | fwiw 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 |
| chriadam | yes, I agree that goal is good one | 07:44 |
| dcaliste | chriadam: 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 |
| chriadam | it will in the nearish future | 07:47 |
| dcaliste | see https://bitbucket.org/jolla/ui-jolla-settings-accounts/branch/jb46973-nextcloud-ui | 07:47 |
| dcaliste | It was setting accounts, not component-accounts… | 07:48 |
| chriadam | we're currently working on nextcloud support, but only a subset of features (i.e. not including generic file sync) | 07:48 |
| chriadam | the generic file sync will be investigated in the nearish future (i.e. within a couple of months i guess) | 07:48 |
| chriadam | not 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) etc | 07:49 |
| chriadam | we 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 etc | 07:49 |
| dcaliste | Good, 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 |
| chriadam | yep, saw that one | 07:50 |
| chriadam | had remembered it from a while ago ;-) | 07:50 |
| dcaliste | It was using the same approach than for calDAV but with files, using delta calculation and etags. | 07:50 |
| chriadam | nice one | 07:50 |
| dcaliste | The 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 |
| chriadam | maybe 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 |
| chriadam | oh 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 |
| dcaliste | The idea was to keep a subdirectory structure in sync with a distant one, both ways or one direction only. | 07:52 |
| dcaliste | Yes, buteo has the stuff for connectivity selection. | 07:52 |
| chriadam | yeah, although not sure that we report it appropriate to buteo, so that it can tell the plugins ;-) | 07:52 |
| dcaliste | But I didn't implement it in the plugin. Can add it later I guess. | 07:53 |
| chriadam | will have to check that. maybe it's reported from QNetworkSession, but maybe it needs something from connman? not sure. | 07:53 |
| dcaliste | No it's already present in Buteo. | 07:53 |
| chriadam | ah, it detects it properly? | 07:53 |
| dcaliste | Yes, I think so. | 07:53 |
| chriadam | great | 07:53 |
| dcaliste | When running msyncd in debug mode, we often see the connectivity events. | 07:54 |
| dcaliste | Changing with network type. | 07:54 |
| dcaliste | Let me find it in the source… | 07:54 |
| dcaliste | There is a connectivityStateChanged virtual func to be implemented in plugins. | 07:54 |
| dcaliste | With a Sync::ConnectivityType argument. | 07:55 |
| dcaliste | See libbuteosyncfw/common/SyncCommonDefs.h | 07:56 |
| dcaliste | There is this InternetConnectionType enum that can be polled from somewhere I guess. | 07:57 |
| chriadam | yep, 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 |
| chriadam | but assuming it does it already, using the appropriate API, then all is well :-) | 07:57 |
| dcaliste | Ah, I see, sorry. | 07:57 |
| chriadam | I just wasn't clear ;-) | 07:59 |
| chriadam | were there any other action points for me, this week? | 08:00 |
| dcaliste | Looking at the spec, buteo is not depending on conman, so I guess it's based only on QNetworkSession. | 08:00 |
| chriadam | or anything you'd like me to poke pvuorela or flypig about? | 08:00 |
| dcaliste | no it's fine, I would like to ask pvuorela or sage to review python | 08:00 |
| dcaliste | python3!11 | 08:01 |
| dcaliste | I'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 |
| chriadam | sounds good, thanks, I will | 08:02 |
| dcaliste | Of course, when they have time ;) | 08:03 |
| chriadam | indeed, hopefully soon | 08:03 |
| dcaliste | When 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 |
| chriadam | ah, nice | 08:05 |
| chriadam | I haven't been following that one, but I have pinged pekka in an internal chat channel, hopefully he will check soon. | 08:05 |
| dcaliste | Thanks, some people will be happy to have the ncurse module back then! | 08:06 |
| chriadam | no doubt | 08:07 |
| chriadam | was there anything else to discuss? | 08:07 |
| dcaliste | No, it's ok. I'll look at mkcal#17 in the coming days and report in Gitlab. | 08:08 |
| dcaliste | Thank you chriadam and have a nice evening. | 08:08 |
| chriadam | thank you again for your time and effort | 08:09 |
| chriadam | have a great week! | 08:09 |
| adisbladis | TheKit: Jolla finally provided a 3.0.3.10 image and that worked | 14:18 |
| *** SpeedEvil is now known as Guest50531 | 18:49 | |
| *** BitEvil_ is now known as SpeedEvil | 18:59 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!