Tuesday, 2022-01-11

dcalisteHello chriadam, how are you ?07:57
chriadamhi dcaliste, I'm well thank you07:57
chriadamhow are you?07:57
dcalisteI'm ok. Happy new year to you and your family !07:58
chriadamthank you - and the same to you!07:58
chriadam2022 is off to an interesting start, with omicron spreading so quickly ... well.  we live in interesting times.07:58
chriadamFirst important thing we need to discuss:07:59
chriadamI will be shifting to work on other client projects for a few months, unfortunately.  Hopefully I'll be back working on Jolla projects in Q2, but in the meantime, pvuorela and/or flypig will be attending these meetings instead of me, and will be the primary contact points for reviewing PRs etc.08:00
pvuorelahey guys08:01
chriadamhi pvuorela :-)08:01
flypigGreetings all. I'm also just tagging along.08:01
chriadamdcaliste: also, I want to say: it has been extremely rewarding and enjoyable for me, to be able to collaborate with a community member as proactive and willing to put in lots of effort, as you have been!08:02
chriadamHopefully that will continue into the future :-)08:02
dcalisteAh sure. Good luck with your other projects. I'll be happy to discuss again with you when you come back to work on Sailfish projects.08:02
chriadamThanks :-)08:02
dcalisteHello pvuorela and flypig, greetings to you too.08:03
chriadamWith that out of the way, I guess we can get onto the usual topics.  I've mostly forgotten what stage various PRs were in, so if you could provide a summary of the current open PRs and their status for pvuorela and flypig, that might be a good kick-off point.08:03
dcalisteYes, let's review what is in the waiting queue :08:04
dcaliste- https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/9 about not deleting cancelled event on sync.08:04
dcalisteThe out come for this one is not clear yet though, as mentioned in the comments, there is an inconsistentcy on cancelled events in KCalendarCore.08:05
dcalisteNo one commented on it upstream yet though.08:05
dcalisteThe cancelled exceptions are filtered out by the occurrence iterator, but not the plain non recurring events.08:05
chriadamRight. I agree that we shouldn't push deletions of those cancelled events.  I guess upstream people might still be on vacation etc.08:07
dcalisteBut to come back to the PR, it should go in in its current form (possible regression on plain cancelled events) or by still deleting cancelled events (fixing the current bug and keeping the current behaviour)08:07
pvuorelanot entirely sure about filtering cancelled events, but looks like the existing filtering is quite old already.08:07
dcalisteYes, looking at the blame, it was introduced in the occurrence iterator to fix an issue, but it was not a proper fix and was not reverted then.08:08
dcalisteWhat do you prefer for the current caldav issue (wrong bucketting from my part for cancelled events, so they are not deleted anymore and are creating spurious upstream modifications at each sync) ?08:09
chriadamPerhaps I'm misunderstanding, but it seems correct to not push a deletion, but instead just update the status to cancelled.  why is it being updated during each sync, rather than just the first, though?08:12
pvuorelaon a quick glance the pr seems good. wonder what's the part now needing calendarcore changes.08:12
dcalistePrevious case before I messed up the bucketing : cancelled events were deleted (so user don't see them anymore). Then, I put the cancelled events in localDeletion bucketing in the update() routine.08:13
dcalisteInstead of remoteDeletion bucketing.08:13
dcalisteBecause of that, the etag of the cancelled event from upstream is not updated and at each sync the evet is seen as modified ustream...08:14
dcalisteThe question is should we go back to previous situation : cancelled events are deleted (by correcting the bucketing) and wait for upstream to settle the visibility case of cancelled events, not just recurring ones, or should we affect the status to cancelled on sync (current PR) and risk regression since the UI is not yet handling this status ?08:16
dcalisteI've prepared (not pushed) PRs to support the status for an event in QML, but I'm waiting for upstream to see if they prefer to filter them out in the occurrence iterator.08:17
chriadamah, I see...08:17
chriadamso, I guess best is to wait for upstream to respond, then we can decide.  I suspect that exposing the status to QML and rendering the text with strikethrough if it's cancelled, is a good idea.08:18
pvuorelathe small ui difference for cancelled events we should do regardless of sync or kf5-calendarcore details. be it strikethrough or faded out coloring.08:19
dcalisteOk, so I'll push the QML PR to expose the status and prepare the UI changes. I need to patch upstream for the time being though not to filter cancelled exceptions in the occurrence iterator...08:25
dcalisteWhich brings me to the second CalDAV pending PR : https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/1008:26
dcalisteI've added the overwrite device or server version, as pvuorela you suggested.08:26
dcalisteI've seen that jpetrell commented on the corresponding jolla-calendar PR yesterday. I thank him.08:27
dcalisteI'll respond there in the coming days.08:27
dcalisteCorresponding PRs are https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/16 and jolla-calendar#31208:28
chriadamyeah, in general, having some way for the user to specify a "solution" for sync errors from the UI, and have that selection respected at sync time, is important08:28
chriadamthe specifics of the PR need to be reviewed carefully, since it affects the delta calculation08:30
chriadambut the general approach seems fine to me08:30
chriadampvuorela: do you agree08:30
dcalisteYes, even if most unrecoevrable errors needing this user intervention are usually due to bugs (hopefully decreasing with time).08:30
dcalisteFor the delta, I agree. During testing I got some bad cases were all my hundred of events were seen as modified...08:30
pvuorelamostly do. commonly nice if the user wouldn't need to be bothered with the sync and it would just work, but if that cannot be avoided...08:31
dcalisteIt should be in a better shape now.08:31
dcalistepvuorela, indeed, it's for the cases where the user is bothered by recurring issues with sync. For the other cases, either errors are transient and will solved themselves at next proper network connection, or there is no error at all !08:32
dcalisteLast week, I also gave a look to the directory/inode issue in email application : https://github.com/sailfishos/nemo-qml-plugin-email/pull/608:34
pvuorelathanks. i'll need to check that.08:35
dcalisteWhen you have several attachments, on the first opening, you can only open one. Then the others are generating a notification about directory/inode.08:35
dcalisteI've detailed the root of the problem in the PR.08:35
dcalisteIt's due to the fact that we're using a slot for the agent signal in a callback of a file watcher, without ensuring the same context (a non null path).08:36
dcalisteI'm wondering if we could just get rid of the file watcher, because the email agent is supposed to signal when the file is available.08:37
pvuorelaas side-note we should at some point revisit the whole attachment handling. now it's creating an interesting directory structure for the saved files.08:37
dcalisteBut maybe not, in case the user manually delete the file on disk while viewing the attachment list...08:38
dcalisteAbout attachment rework, I agree.08:38
dcalisteI've started a patch in QMF to get the filenaming scheme from there and not reproduce it in nemo bindings.08:39
dcalisteBut the unicity is still an issue. Not on creation, but on reading, when the agent would like to know if the file already exist on disk.08:39
dcalisteClaws mail is not bothering with this for instance and is creating temporary file each time one tap on an attachment. But then it means that you need to actually save them as if you want to have them in the user folders. Which is not very convenient neither.08:41
chriadamYeah :-/08:41
dcalistepvuorela, at least the PR is avoiding the directory/inode issue and the overall rework can be done in a sperate one.08:42
pvuoreladcaliste: yes indeed.08:42
pvuorelathe rework will need some thinking and it will affect more places. but thinking if we should anyhow go to similar direction, just opening file saving it as temporary.08:43
pvuorelabut then we should have both options offered by the ui.08:44
dcalistepvuorela : this can create issues also, for instance with a PDF that may be save temporarily outside the jail, or otherwise an issue with the user wondering why the PDF he just viewed yesterday by taping in the email is not in the document list anymore.08:45
dcalisteAnother topic : playing with GPG signature, I noticed that secret is using an old version of SQlite.08:48
pvuoreladcaliste: might be somehow surprising no matter how it goes. the user could wonder why the pdf pollutes the file list when it was just temporarily opened from an attachment :)08:48
dcalistepvuorela, sure ;)08:48
dcalisteSo I upgraded SQLcypher, see https://github.com/sailfishos/sqlcipher/pull/408:49
dcalisteBut this is pushing new parameters for the cypher and tables should be migrated (or not).08:49
dcalisteThis is a PR in secret https://github.com/sailfishos/sailfish-secrets/pull/184 not to update the tables.08:49
dcalisteThis is less safe than parameters for version 4 but not worst than before, and at least underlying sqlite is up to date.08:50
pvuorelaif it's not officially used, thinking if we shouldn't bother too much with the migrations.08:51
pvuorelabut need to check more.08:51
pvuorelaspeaking of secrets etc. i had that one email app pr.08:53
dcalisteAh, I forgot I compiled ICU support also in SQLcypher. So there is not more icu error on databse opening and locale language search are then possible, see icu_load_collation08:55
dcalistein file database.cpp08:55
chriadamthere was related PR from mardy about ICU collation support in qtcontacts-sqlite08:55
dcalisteYes, pvuorela, thanks for the signeton. It looks good, but I cannot test at the moment, since there is no SDK for 4.4 and the gecko lib is different from 4.3.08:55
chriadamfor SQLCipher I wonder if it's possible to use the system sqlite rather than an amalgamated one?  if not, all good.  was just thinking that might reduce ongoing maintenance burden (since we know the system one will be updated frequently)08:56
dcalisteSo compiling email app in sdk cannot be used on my device at the moment.08:56
pvuorelaif no objections, i could also just merge the email app thing when someone approves it.08:57
dcalistechriadam, I'm not at all fluent about SQLcypher, but I don't think one can rely on an external SQLite library, it seems to me that it rely on sources themselves.08:57
pvuorelait's anyhow then always checking the status when asked instead of relying some context property set at the beginning.08:57
flypigIf it's just the gecko lib, could we provide you with some rpms?08:57
chriadamdcaliste: makes sense, I guess they hook internal stuff to ensure entire pages are encrypted etc.08:58
dcalisteflypig, its in the sdk, the email app is linking with libXUL.so.x from 4.3. Library that is not available anymore on device with 4.4.08:59
flypigYes, I was thinking if we provide you with just the latest gecko development lib to install inside your target. It may be more complicated than I think it is though.08:59
dcalisteSo maybe a libxulrunner-devel, but I don't know which are its dependencies.09:00
flypigYes, I suppose libxulrunner-devel would have to be built in the 4.3 SDK. That may not be viable.09:01
dcalisteWell, I've looked at the PR from pvuorela from a code point of view and every thing looks fine. The fact that the file is checked at each access is not really an issue I guess. I think it can go in like that and be amended later if another issue arise. ANyway it won't be in 4.4.09:01
dcalisteAnd last but not least, I don't know if you noticed https://forum.sailfishos.org/t/ireland-timezone/9904 but there is a severe issue with the Ireland timezone.09:03
chriadamuh oh, let me check09:03
dcalisteI investigated yesterday and found that it's the JS conversion of a Date that is failing.09:04
dcalisteTo see it in it's full uglyness :09:04
dcaliste- go to the setting and choose manual timezone for date and time.09:04
dcaliste- choose the Dublin timezone.09:04
dcaliste- notice that the time is right, and tap to change the time : the display time in the wheel are shifted with respect to what was displayed.09:05
dcalisteI try to debug it a bit :09:05
dcaliste- in the Dublin time zone, the time in shell is correct (`date -R` returns the right time).09:06
dcaliste- time in Qt is fine (QDateTime::currentLocalTime() is correct).09:06
dcaliste- even when returned in UTC, in Qt, time is correct.09:06
dcaliste- but in QML `Date()` is returning the right hours and minutes but with a wrong UTC offset, so the display time is wrong.09:07
dcaliste- a conversion from a right Qt QDateTime (for instance 10:07 GMT) is displayed in QML as 10:07 UTC+2, thus the wheel is printing 12:0709:08
chriadamhorrifying ... because I suspect this isn't specific to Ireland, right?  (Or at least, I assume it affects any timezone which is UTC in summer but GMT+1 in winter?)09:08
dcalisteI tried to find in qtdeclarative source where the conversion is done, but didn't find it.09:08
dcalisteIt's the case only for Dublin time zone.09:09
chriadam... so strange!09:09
dcalisteI guess it's like that because it's the only timezone define as full year offset GMT+1 and a DST in GMT for a part of the year.09:09
chriadamcurious.  well, there are V8 constructors for Date types which might be involved.09:10
dcalisteFor instance Portugal timezone is defining half a year GMT+1 and half a year GMT+0 and no DST.09:10
chriadamwait, I don't recall whether Qt 5.6 still used V8 or not.09:11
chriadambut, yeah, the fix will require digging into the JS engine internals, I suspect, and ensuring that the tz offset applied matches the required semantics, during construction of a Date object, I suspect.09:12
chriadamPekka or Joona would presumably be the appropriate people to look into that one, now.09:13
dcalisteYes, that's my guess. But grepping here and there in qtdeclarative I didn't find where a QDateTime is converted into something.09:14
pvuorelayep. quite interesting issue there. thanks for raising it.09:14
dcalisteYes, it's fun to try to find where it fails.09:14
chriadamOk, I guess that was the last thing on the list for today's meeting?  Or is there something else to discuss also?09:17
dcalisteNo that's all. jpetrell commented on the DST indicator PR in jolla-calendar. I'll respond to him there.09:18
chriadamgreat :-)09:18
chriadamIn that case, let's close the meeting.  Thanks again for your contributions and effort, it's greatly appreciated!09:18
chriadamAnd hopefully I will be back on board in a few months' time :-)09:18
chriadamGood night!09:19
dcalisteThanks to you guys also to take time to interact with me also.09:19
dcalisteGood night.09:19
flypigGood night.09:19
dcalistepvuorela, if you have an idea where the conversion is done from a QDateTime property to a JS object, I can continue looking at this tz issue.09:21
dcalisteOr I'll continue to grep here and there !09:21
pvuorelano immediate idea.09:21
dcalisteOk, no problem.09:23
dcalisteAh, my grep fu was weak yesterday : the conversion is done in qtdeclarative/src/qml/jsruntime/qv4dateobject.cpp#63109:31
dcalisteI'll start from there and see if I can find something.09:31
poetasterdcaliste, re: javascript date and locale, when developing harbour-dwd, I turned to a custom solution since I was having issues in Germany11:52
poetasterdcaliste, but why I had needed it to determine the name of the zone, I no longer recall.11:56
poetasterdcaliste, it's used here: https://github.com/poetaster/harbour-dwd/blob/main/qml/pages/OverviewPage.qml11:56
poetasterdcaliste, for some reason I had been unable to get toLocaleDateString on dates working and substituted a custom solution12:02
dcalistehello poetaster, Maybe it's related, but the problem with the Ireland time zone is that the current time in JS is shifted forward of 2 hours during DST.12:36
dcalisteAfter some investigation this morning, I found the culprit in qtdeclarative.12:36
dcalisteIt is hardcoded there that the DST shift is +1 hour. But for Ireland, it is -1 hour.12:37
dcalisteI'm trying to compile qtdeclarative in SDK to see if my fix would work.12:37
dcalisteI'm facing issues at the moment with the build system though :(12:38
poetasterdcaliste, was that in: /qv4dateobject.cpp looked a bit messy14:29
dcalisteYes, the "fix" I'm proposing is https://github.com/sailfishos/qtdeclarative/pull/314:30
poetastercool. geography is hard ;)14:31
poetasterI have to try to find out what my issue was. My js hack felt, well, hacky.14:32
piggzpoetaster: after doing amazfish ... time is hard!14:59
poetasterpiggz: yeah, time is THE hard one. I say, MS exchange!16:27
lolekrinigus: hi, remember when I asked you about limited instruction from valhalla for voice guidance? Finally I've been able to play with it and it seems there's not much to be changed in the puremaps valhalla already returns almost what's needed. If I understand properly puremaps right now it's using the "instruction" key from the json returned from valhalla, but there are also other21:26

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