| dcaliste | Hello chriadam, how are you ? | 07:57 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thank you | 07:57 |
| chriadam | how are you? | 07:57 |
| dcaliste | I'm ok. Happy new year to you and your family ! | 07:58 |
| chriadam | thank you - and the same to you! | 07:58 |
| chriadam | 2022 is off to an interesting start, with omicron spreading so quickly ... well. we live in interesting times. | 07:58 |
| chriadam | First important thing we need to discuss: | 07:59 |
| chriadam | I 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 |
| pvuorela | hey guys | 08:01 |
| chriadam | hi pvuorela :-) | 08:01 |
| flypig | Greetings all. I'm also just tagging along. | 08:01 |
| chriadam | dcaliste: 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 |
| chriadam | Hopefully that will continue into the future :-) | 08:02 |
| dcaliste | Ah 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 |
| chriadam | Thanks :-) | 08:02 |
| dcaliste | Hello pvuorela and flypig, greetings to you too. | 08:03 |
| chriadam | With 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 |
| dcaliste | Yes, 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 |
| dcaliste | The 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 |
| dcaliste | No one commented on it upstream yet though. | 08:05 |
| dcaliste | The cancelled exceptions are filtered out by the occurrence iterator, but not the plain non recurring events. | 08:05 |
| chriadam | Right. I agree that we shouldn't push deletions of those cancelled events. I guess upstream people might still be on vacation etc. | 08:07 |
| dcaliste | But 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 |
| pvuorela | not entirely sure about filtering cancelled events, but looks like the existing filtering is quite old already. | 08:07 |
| dcaliste | Yes, 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 |
| dcaliste | What 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 |
| chriadam | Perhaps 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 |
| pvuorela | on a quick glance the pr seems good. wonder what's the part now needing calendarcore changes. | 08:12 |
| dcaliste | Previous 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 |
| dcaliste | Instead of remoteDeletion bucketing. | 08:13 |
| dcaliste | Because 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 |
| dcaliste | The 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 |
| dcaliste | I'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 |
| chriadam | ah, I see... | 08:17 |
| chriadam | so, 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 |
| pvuorela | the 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 |
| dcaliste | Ok, 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 |
| dcaliste | Which brings me to the second CalDAV pending PR : https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/10 | 08:26 |
| dcaliste | I've added the overwrite device or server version, as pvuorela you suggested. | 08:26 |
| dcaliste | I've seen that jpetrell commented on the corresponding jolla-calendar PR yesterday. I thank him. | 08:27 |
| dcaliste | I'll respond there in the coming days. | 08:27 |
| dcaliste | Corresponding PRs are https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/16 and jolla-calendar#312 | 08:28 |
| chriadam | yeah, 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 important | 08:28 |
| chriadam | the specifics of the PR need to be reviewed carefully, since it affects the delta calculation | 08:30 |
| chriadam | but the general approach seems fine to me | 08:30 |
| chriadam | pvuorela: do you agree | 08:30 |
| dcaliste | Yes, even if most unrecoevrable errors needing this user intervention are usually due to bugs (hopefully decreasing with time). | 08:30 |
| dcaliste | For the delta, I agree. During testing I got some bad cases were all my hundred of events were seen as modified... | 08:30 |
| pvuorela | mostly 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 |
| dcaliste | It should be in a better shape now. | 08:31 |
| dcaliste | pvuorela, 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 |
| dcaliste | Last week, I also gave a look to the directory/inode issue in email application : https://github.com/sailfishos/nemo-qml-plugin-email/pull/6 | 08:34 |
| pvuorela | thanks. i'll need to check that. | 08:35 |
| dcaliste | When 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 |
| dcaliste | I've detailed the root of the problem in the PR. | 08:35 |
| dcaliste | It'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 |
| dcaliste | I'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 |
| pvuorela | as 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 |
| dcaliste | But maybe not, in case the user manually delete the file on disk while viewing the attachment list... | 08:38 |
| dcaliste | About attachment rework, I agree. | 08:38 |
| dcaliste | I've started a patch in QMF to get the filenaming scheme from there and not reproduce it in nemo bindings. | 08:39 |
| dcaliste | But 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 |
| dcaliste | Claws 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 |
| chriadam | Yeah :-/ | 08:41 |
| dcaliste | pvuorela, at least the PR is avoiding the directory/inode issue and the overall rework can be done in a sperate one. | 08:42 |
| pvuorela | dcaliste: yes indeed. | 08:42 |
| pvuorela | the 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 |
| pvuorela | but then we should have both options offered by the ui. | 08:44 |
| dcaliste | pvuorela : 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 |
| dcaliste | Another topic : playing with GPG signature, I noticed that secret is using an old version of SQlite. | 08:48 |
| pvuorela | dcaliste: 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 |
| dcaliste | pvuorela, sure ;) | 08:48 |
| dcaliste | So I upgraded SQLcypher, see https://github.com/sailfishos/sqlcipher/pull/4 | 08:49 |
| dcaliste | But this is pushing new parameters for the cypher and tables should be migrated (or not). | 08:49 |
| dcaliste | This is a PR in secret https://github.com/sailfishos/sailfish-secrets/pull/184 not to update the tables. | 08:49 |
| dcaliste | This is less safe than parameters for version 4 but not worst than before, and at least underlying sqlite is up to date. | 08:50 |
| pvuorela | if it's not officially used, thinking if we shouldn't bother too much with the migrations. | 08:51 |
| pvuorela | but need to check more. | 08:51 |
| pvuorela | speaking of secrets etc. i had that one email app pr. | 08:53 |
| dcaliste | Ah, 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_collation | 08:55 |
| dcaliste | in file database.cpp | 08:55 |
| chriadam | there was related PR from mardy about ICU collation support in qtcontacts-sqlite | 08:55 |
| dcaliste | Yes, 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 |
| chriadam | for 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 |
| dcaliste | So compiling email app in sdk cannot be used on my device at the moment. | 08:56 |
| pvuorela | if no objections, i could also just merge the email app thing when someone approves it. | 08:57 |
| dcaliste | chriadam, 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 |
| pvuorela | it's anyhow then always checking the status when asked instead of relying some context property set at the beginning. | 08:57 |
| flypig | If it's just the gecko lib, could we provide you with some rpms? | 08:57 |
| chriadam | dcaliste: makes sense, I guess they hook internal stuff to ensure entire pages are encrypted etc. | 08:58 |
| dcaliste | flypig, 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 |
| flypig | Yes, 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 |
| dcaliste | So maybe a libxulrunner-devel, but I don't know which are its dependencies. | 09:00 |
| flypig | Yes, I suppose libxulrunner-devel would have to be built in the 4.3 SDK. That may not be viable. | 09:01 |
| dcaliste | Well, 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 |
| chriadam | thanks | 09:02 |
| chriadam | yeah. | 09:02 |
| dcaliste | And 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 |
| chriadam | uh oh, let me check | 09:03 |
| dcaliste | I investigated yesterday and found that it's the JS conversion of a Date that is failing. | 09:04 |
| dcaliste | To 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 |
| dcaliste | I 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:07 | 09:08 |
| chriadam | horrifying ... 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 |
| dcaliste | I tried to find in qtdeclarative source where the conversion is done, but didn't find it. | 09:08 |
| dcaliste | It's the case only for Dublin time zone. | 09:09 |
| chriadam | ... so strange! | 09:09 |
| dcaliste | I 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 |
| chriadam | curious. well, there are V8 constructors for Date types which might be involved. | 09:10 |
| dcaliste | For instance Portugal timezone is defining half a year GMT+1 and half a year GMT+0 and no DST. | 09:10 |
| chriadam | wait, I don't recall whether Qt 5.6 still used V8 or not. | 09:11 |
| chriadam | but, 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 |
| chriadam | Pekka or Joona would presumably be the appropriate people to look into that one, now. | 09:13 |
| dcaliste | Yes, that's my guess. But grepping here and there in qtdeclarative I didn't find where a QDateTime is converted into something. | 09:14 |
| pvuorela | yep. quite interesting issue there. thanks for raising it. | 09:14 |
| dcaliste | Yes, it's fun to try to find where it fails. | 09:14 |
| chriadam | Ok, I guess that was the last thing on the list for today's meeting? Or is there something else to discuss also? | 09:17 |
| dcaliste | No that's all. jpetrell commented on the DST indicator PR in jolla-calendar. I'll respond to him there. | 09:18 |
| chriadam | great :-) | 09:18 |
| chriadam | In that case, let's close the meeting. Thanks again for your contributions and effort, it's greatly appreciated! | 09:18 |
| chriadam | And hopefully I will be back on board in a few months' time :-) | 09:18 |
| chriadam | Good night! | 09:19 |
| dcaliste | Thanks to you guys also to take time to interact with me also. | 09:19 |
| dcaliste | Good night. | 09:19 |
| flypig | Good night. | 09:19 |
| pvuorela | night! | 09:20 |
| dcaliste | pvuorela, 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 |
| dcaliste | Or I'll continue to grep here and there ! | 09:21 |
| pvuorela | no immediate idea. | 09:21 |
| dcaliste | Ok, no problem. | 09:23 |
| dcaliste | Ah, my grep fu was weak yesterday : the conversion is done in qtdeclarative/src/qml/jsruntime/qv4dateobject.cpp#631 | 09:31 |
| dcaliste | I'll start from there and see if I can find something. | 09:31 |
| poetaster | dcaliste, re: javascript date and locale, when developing harbour-dwd, I turned to a custom solution since I was having issues in Germany | 11:52 |
| poetaster | https://github.com/poetaster/harbour-dwd/blob/main/qml/js/locales.js | 11:54 |
| poetaster | dcaliste, but why I had needed it to determine the name of the zone, I no longer recall. | 11:56 |
| poetaster | dcaliste, it's used here: https://github.com/poetaster/harbour-dwd/blob/main/qml/pages/OverviewPage.qml | 11:56 |
| poetaster | dcaliste, for some reason I had been unable to get toLocaleDateString on dates working and substituted a custom solution | 12:02 |
| dcaliste | hello 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 |
| dcaliste | After some investigation this morning, I found the culprit in qtdeclarative. | 12:36 |
| dcaliste | It is hardcoded there that the DST shift is +1 hour. But for Ireland, it is -1 hour. | 12:37 |
| dcaliste | I'm trying to compile qtdeclarative in SDK to see if my fix would work. | 12:37 |
| dcaliste | I'm facing issues at the moment with the build system though :( | 12:38 |
| poetaster | dcaliste, was that in: /qv4dateobject.cpp looked a bit messy | 14:29 |
| dcaliste | Yes, the "fix" I'm proposing is https://github.com/sailfishos/qtdeclarative/pull/3 | 14:30 |
| poetaster | cool. geography is hard ;) | 14:31 |
| poetaster | I have to try to find out what my issue was. My js hack felt, well, hacky. | 14:32 |
| piggz | poetaster: after doing amazfish ... time is hard! | 14:59 |
| poetaster | piggz: yeah, time is THE hard one. I say, MS exchange! | 16:27 |
| hnj | https://github.com/kdeldycke/awesome-falsehood#dates-and-time | 19:03 |
| lolek | rinigus: 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 other | 21:26 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!