Tuesday, 2020-08-18

*** frinring_ is now known as frinring00:40
Anaskomal, monich: I have run "devel-su journalctl -fa", have got the logs for Books' reproducible crash.01:38
*** zbenjamin_ is now known as zbenjamin01:39
AnaskoIssue has been filed: https://github.com/monich/harbour-books/issues/5802:52
*** nyov is now known as Guest5450403:26
*** Ischwitch is now known as Ingvix05:39
dcalisteHello chriadam, how are you ?07:03
chriadamhello dcaliste, I'm well thank you.  How are you?07:04
dcalisteI'm fine, thank you.07:04
dcalisteLast week, I've proposed the KCalendarCore patch about adding volatile with setNonKDECustomProperty() also, so mKCal could work without modification.07:05
dcalisteSee https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/707:06
dcalisteIt corresponds to the second commit in our kcalcore MR.07:07
chriadamI saw that flypig managed to review that one - seemed like all was good?07:07
chriadamand yes, you mentioned that you were going to propose that second change back upstream.  I hope it was received well?07:07
dcalisteI'm not sure it will be accepted by KDE, I tried to advocate it in length in the MR header. In case they disagree, I'll move the code to mKCal to differentiate between setCustomProperty() and setNonKDECustomProperty().07:08
chriadamah seems no comments or anything yet.  well, we'll see :-)07:08
dcalisteAt the moment, noone commented it yet.07:08
dcalisteExactly, let it time !07:08
chriadameither way the explanation is very clear, so if they disagree, their reasoning hopefully will be useful discussion input for us07:09
dcalisteYeh, and it's no problem to add an if in the mKCal where we read the properties from DB.07:09
chriadamthank you for doing that07:11
chriadamon the calendar side, MartinS said he provided some feedback on the calendar design for the error case one07:12
chriadamdid you see that, or did he not post that somewhere visible?07:12
dcalisteI've seen flypig reviewing the various MRs for the UI part. I didn't see anything from Martin, but I may have missed it.07:13
dcalisteAnyway, I'm glad he's fine with it.07:13
dcalisteAnd if he has some concern on some details, no problem to try to improve it.07:14
chriadamhe had some suggestions for the UI look and feel07:14
chriadamI just checked, it should be visible as a comment on jolla-calendar PR#26607:14
dcalisteAh, I see them now.07:15
dcalisteI didn't check this morning before the meeting.07:15
chriadampvuorela: did you have any chance to check those PRs also?  I unfortunately haven't07:15
chriadamdcaliste: I think he just uploaded it a moment ago ;-)07:15
dcalisteOk, I can make the proposed changes today or tomorrow, I think.07:18
chriadamno rush of course, thank you very much!07:18
dcalisteThanks for the feedback to all of you.07:18
pvuorelachriadam: unfortunately only superficially.07:19
chriadamno problem, maybe once dcaliste has made the changes Martin has suggested, we could set aside some time to review properly again07:20
chriadamI know flypig reviewed some of the other bits (nqpc + kcalcore) IIRC, so should be getting "close" IMO07:21
dcalistepvuorela, sure no problem (and thanks for the quick acceptance for the email patch). Indeed, let me implement the changes Martin suggested first this week.07:22
dcalistechriadam : I'm still working on the failure branch for CalDAV. But before it, may I request that when you will have time, could you make https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/71 enter first ? It requires to agree on this mKCal patch also : https://git.sailfishos.org/mer-core/mkcal/merge_requests/43 ?07:23
chriadamlet me check07:23
dcalisteThis would avoid me to create a specific branch to compile the CalDAV plugin, where I pile up everything for day to day testing.07:24
chriadamyes, I remember discussing those and it it seems Bea had no concerns.  but they need a TJC# or JB# in order ot pass CI07:25
chriadamI wonder if there's something appropriate?07:25
dcalisteNot really related, but maybe the one about adding task support ? After all, these simplification remotely help to get this in by simplifying the code and relying on KCalCore only where support is full ? A bit hairy though, I agree.07:27
chriadamI can add JB#, never mind07:28
chriadamwhat should the bug title be: "Avoid setting alarms twice for exception occurrences" or so?07:28
dcalisteMaybe orientate it toward the CalDAV thing, the other being a consequence : simplification of CalDAV handling, convergence with KCalendarCore.07:29
chriadamok, one sec07:30
chriadamcreated JB#50856 for this "Reduce code duplication in incidence handling between caldav and kcalcore"07:33
dcalisteGreat, I'm adding it in both places. Thanks.07:34
chriadamthank you07:34
chriadamI will merge those two tonight07:34
dcalisteGreat, done for mKCal...07:35
dcalisteAnd for CalDAV also.07:35
dcalisteLastly, I've begun to implement extend logging features for Buteo.07:36
chriadamone comment on the mkcal one - can you quickly check07:36
dcalisteAs discussed last week with flypig also, I'm proposing an extension to TargetResult class to hold per item information.07:36
dcalisteOk, looking at the mKCal comment...07:37
dcalistechriadam, I'm posting the answer. Do you agree with the reasoning, or do you have further concerns ?07:44
dcalisteI'm adding the comment in code, sure.07:45
chriadamthe reasoning makes sense, thank you.  a code comment would be useful for future analysis I think07:45
dcalistechriadam, ok, I've added the comment and pushed.07:49
chriadamthanks very much07:49
dcalisteJust to finish today, I've added some code to Buteo to extend logging capability of the TargetResult object.07:49
dcalisteSee https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/5107:50
dcalisteWith flypig, when you have time, could you give me your opinion on the API ?07:51
chriadamflypig is on vacation for 3 weeks unfortunately07:51
dcalisteOk, I hope he will enjoy then !07:51
dcalisteYou can find example of XML dumping and API usage in the added tests.07:52
chriadamfrom a quick look, api looks fine.  naming is hard (addLocalDetails -> maybe addLocalDatumDetails() ?)07:52
chriadamand maybe append instead of add.  hrm.07:53
chriadamanyway, that's just beside the point07:53
chriadamyeah, it looks good - thanks very much.  I guess these fine-grained result infos get cleaned up from db in the same way as normal results e.g. was it that it retains the last 5 results or so?07:54
dcalisteI put 'add' on purpose in fact, because internally, I would like to keep the possibility to switch from a QList to something smarter like QMap if needed.07:54
chriadamah, makes sense.07:54
dcalisteAbout the log, yes, they are transient. Only the 5 last are kept, so the file is never growing much.07:54
chriadamthinking about the pathological case here:07:55
chriadamsyncing a massive addressbook or calendar, you might have, I dunno 2000 entries?07:55
chriadamstored as XML, about how large would that be, on disk?07:55
dcalisteI plan not to log the first sync, because it make no sense to present to the user (these, these and that events were added) because he knows that all the events are new... About a massive addition later on during the life cycle of the calendar, well, one entry is something like 50 to 80 chars. So the file size would still be below the megabyte even for five syncs like this one.07:57
dcalisteThe issue in that case would be for the UI. But it would be easy in the code to come for the UI to resptrict the listed changes to 10 - 20 events.07:59
chriadamright, or filter just by failures etc07:59
chriadamwhich hopefully would be less than the successes haha07:59
dcalisteAfter, it makes no sense to look at them one by one anyway.07:59
dcalisteAbout the failures, yes it could be more space intensive in the worst case.08:00
chriadambut yes, I concur, sounds reasonable.  especially since it's "transient" info which will get deleted.08:00
chriadamand it's useful information08:00
dcalisteImagine we need to upload 2000 new events from device (very unlikely case, they are hard to get created not using the CLI), each of them is an upload, that may fail if the network go down during the process and all of them will get logged with the server reply.08:01
dcalisteIn that case we may reach the negabyte, but well...08:01
chriadambut yes, will discuss with blam and pvuorela over the coming weeks.  I am not sure when I'll have a chance to review properly, as porting the contact sync plugins to the updated QtPIM api stuff will take me some time over the next couple of weeks, unfortunately.08:02
dcalisteThe question about the API here also is to see if it's account agnostic. Will it be convenient or usefull for CardDAV also, or for Nextcloud, ahetever ?08:02
chriadamyeah, maybe importing from vcard?  but then it shouldn't get upsynced (well, in the future, once I've finished this porting..)08:02
chriadamI assume it will be useful for all accounts, yes08:03
dcalisteSure, but can a UID unique enough in one string can be forged for every use case ? I guess so, but it's the kind of question I'm wondering about.08:04
dcalisteFor mKCal it's obviously true, since the UID is already UNIQUE in the DB, even throughout notebooks (which was an issue per se!).08:05
chriadamfor the cases where it's not possible, I suspect that plugin/thing simply wouldn't provide per-item results (since it means that, effectively, it's not possible to uniquely distinguish between any two items it deals with)08:07
chriadambut instead would just provide the "overall" result08:07
chriadam-- so, as long as that's still possible (i.e. plugins don't HAVE to provide the per-datum results), then I think it's fine.  just in some cases, that "fine grained" info won't be available.08:08
chriadambut in general, I think it should be applicable in most cases08:08
dcalisteYeh, or fallback to the trick of agregating various source into one string.08:08
chriadamright, true08:10
chriadamone sec, will merge those two PRs now08:10
dcalisteThanks for the discussion, it's longer term changes anyway, and we can mature them for weeks.08:17
chriadamok, I've merged and tagged those for JB#50856.  tyvm!08:17
chriadamyes, the buteo one will take some discussion and iteration I am sure :-)08:17
dcalisteThank you for the merges also. I can rebase my failure branch on top.08:17
chriadamthanks as always for your efforts - greatly appreciated.08:17
dcalisteI'll create a MR for it soon, so it can go with th UI changes otherwise, there will be no provider for the failure information ;)08:18
dcalisteAs said, I would like to see if I can add unittesting for it, to check that failure during request is properly setting the failure info per event.08:19
chriadamindeed, sounds like a good idea :-)08:19
chriadamdid you ahve anything else to discuss tonight?08:19
dcalisteNo, it was nice already. Thank you for your time.08:20
chriadamthank you - have a great week!08:20
dcalisteYou too.08:20
*** BitEvil is now known as SpeedEvil08:31
*** leinir_ is now known as leinir11:08
AnaskoQuestion: Is there any way to get a core dump or backtrace, for a crashing application, on Sailfish OS 3? Crash is reproducible, I have already taken logs with devel-su journalctl -fa, but more information on the crash would be appreciated by the developer on whose Github I have filed the issue.23:53

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