| *** frinring_ is now known as frinring | 00:40 | |
| Anasko | mal, monich: I have run "devel-su journalctl -fa", have got the logs for Books' reproducible crash. | 01:38 |
|---|---|---|
| *** zbenjamin_ is now known as zbenjamin | 01:39 | |
| Anasko | Issue has been filed: https://github.com/monich/harbour-books/issues/58 | 02:52 |
| *** nyov is now known as Guest54504 | 03:26 | |
| *** Ischwitch is now known as Ingvix | 05:39 | |
| dcaliste | Hello chriadam, how are you ? | 07:03 |
| chriadam | hello dcaliste, I'm well thank you. How are you? | 07:04 |
| dcaliste | I'm fine, thank you. | 07:04 |
| dcaliste | Last week, I've proposed the KCalendarCore patch about adding volatile with setNonKDECustomProperty() also, so mKCal could work without modification. | 07:05 |
| dcaliste | See https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/7 | 07:06 |
| dcaliste | It corresponds to the second commit in our kcalcore MR. | 07:07 |
| chriadam | I saw that flypig managed to review that one - seemed like all was good? | 07:07 |
| chriadam | and yes, you mentioned that you were going to propose that second change back upstream. I hope it was received well? | 07:07 |
| dcaliste | I'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 |
| chriadam | ah seems no comments or anything yet. well, we'll see :-) | 07:08 |
| dcaliste | At the moment, noone commented it yet. | 07:08 |
| dcaliste | Exactly, let it time ! | 07:08 |
| chriadam | either way the explanation is very clear, so if they disagree, their reasoning hopefully will be useful discussion input for us | 07:09 |
| dcaliste | Yeh, and it's no problem to add an if in the mKCal where we read the properties from DB. | 07:09 |
| chriadam | cool | 07:11 |
| chriadam | thank you for doing that | 07:11 |
| chriadam | on the calendar side, MartinS said he provided some feedback on the calendar design for the error case one | 07:12 |
| chriadam | did you see that, or did he not post that somewhere visible? | 07:12 |
| dcaliste | I'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 |
| dcaliste | Anyway, I'm glad he's fine with it. | 07:13 |
| dcaliste | And if he has some concern on some details, no problem to try to improve it. | 07:14 |
| chriadam | he had some suggestions for the UI look and feel | 07:14 |
| chriadam | I just checked, it should be visible as a comment on jolla-calendar PR#266 | 07:14 |
| dcaliste | Ah, I see them now. | 07:15 |
| dcaliste | I didn't check this morning before the meeting. | 07:15 |
| chriadam | pvuorela: did you have any chance to check those PRs also? I unfortunately haven't | 07:15 |
| chriadam | dcaliste: I think he just uploaded it a moment ago ;-) | 07:15 |
| dcaliste | Ok, I can make the proposed changes today or tomorrow, I think. | 07:18 |
| chriadam | no rush of course, thank you very much! | 07:18 |
| dcaliste | Thanks for the feedback to all of you. | 07:18 |
| pvuorela | chriadam: unfortunately only superficially. | 07:19 |
| chriadam | no problem, maybe once dcaliste has made the changes Martin has suggested, we could set aside some time to review properly again | 07:20 |
| chriadam | I know flypig reviewed some of the other bits (nqpc + kcalcore) IIRC, so should be getting "close" IMO | 07:21 |
| dcaliste | pvuorela, 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 |
| dcaliste | chriadam : 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 |
| chriadam | let me check | 07:23 |
| dcaliste | This 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 |
| chriadam | yes, I remember discussing those and it it seems Bea had no concerns. but they need a TJC# or JB# in order ot pass CI | 07:25 |
| chriadam | I wonder if there's something appropriate? | 07:25 |
| dcaliste | Not 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 |
| chriadam | I can add JB#, never mind | 07:28 |
| chriadam | what should the bug title be: "Avoid setting alarms twice for exception occurrences" or so? | 07:28 |
| dcaliste | Maybe orientate it toward the CalDAV thing, the other being a consequence : simplification of CalDAV handling, convergence with KCalendarCore. | 07:29 |
| chriadam | ok, one sec | 07:30 |
| chriadam | created JB#50856 for this "Reduce code duplication in incidence handling between caldav and kcalcore" | 07:33 |
| dcaliste | Great, I'm adding it in both places. Thanks. | 07:34 |
| chriadam | thank you | 07:34 |
| chriadam | I will merge those two tonight | 07:34 |
| dcaliste | Great, done for mKCal... | 07:35 |
| dcaliste | And for CalDAV also. | 07:35 |
| dcaliste | Lastly, I've begun to implement extend logging features for Buteo. | 07:36 |
| chriadam | one comment on the mkcal one - can you quickly check | 07:36 |
| dcaliste | As discussed last week with flypig also, I'm proposing an extension to TargetResult class to hold per item information. | 07:36 |
| dcaliste | Ok, looking at the mKCal comment... | 07:37 |
| dcaliste | chriadam, I'm posting the answer. Do you agree with the reasoning, or do you have further concerns ? | 07:44 |
| dcaliste | I'm adding the comment in code, sure. | 07:45 |
| chriadam | the reasoning makes sense, thank you. a code comment would be useful for future analysis I think | 07:45 |
| dcaliste | chriadam, ok, I've added the comment and pushed. | 07:49 |
| chriadam | thanks very much | 07:49 |
| dcaliste | Just to finish today, I've added some code to Buteo to extend logging capability of the TargetResult object. | 07:49 |
| dcaliste | See https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/51 | 07:50 |
| dcaliste | With flypig, when you have time, could you give me your opinion on the API ? | 07:51 |
| chriadam | flypig is on vacation for 3 weeks unfortunately | 07:51 |
| dcaliste | Ok, I hope he will enjoy then ! | 07:51 |
| dcaliste | You can find example of XML dumping and API usage in the added tests. | 07:52 |
| chriadam | from a quick look, api looks fine. naming is hard (addLocalDetails -> maybe addLocalDatumDetails() ?) | 07:52 |
| chriadam | and maybe append instead of add. hrm. | 07:53 |
| chriadam | anyway, that's just beside the point | 07:53 |
| chriadam | yeah, 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 |
| dcaliste | I 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 |
| chriadam | ah, makes sense. | 07:54 |
| dcaliste | About the log, yes, they are transient. Only the 5 last are kept, so the file is never growing much. | 07:54 |
| chriadam | thinking about the pathological case here: | 07:55 |
| chriadam | syncing a massive addressbook or calendar, you might have, I dunno 2000 entries? | 07:55 |
| chriadam | stored as XML, about how large would that be, on disk? | 07:55 |
| dcaliste | I 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 |
| dcaliste | The 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 |
| chriadam | right, or filter just by failures etc | 07:59 |
| chriadam | which hopefully would be less than the successes haha | 07:59 |
| dcaliste | After, it makes no sense to look at them one by one anyway. | 07:59 |
| dcaliste | About the failures, yes it could be more space intensive in the worst case. | 08:00 |
| chriadam | but yes, I concur, sounds reasonable. especially since it's "transient" info which will get deleted. | 08:00 |
| chriadam | and it's useful information | 08:00 |
| dcaliste | Imagine 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 |
| dcaliste | In that case we may reach the negabyte, but well... | 08:01 |
| chriadam | but 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 |
| dcaliste | The 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 |
| chriadam | yeah, maybe importing from vcard? but then it shouldn't get upsynced (well, in the future, once I've finished this porting..) | 08:02 |
| chriadam | I assume it will be useful for all accounts, yes | 08:03 |
| dcaliste | Sure, 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 |
| dcaliste | For 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 |
| chriadam | for 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 |
| chriadam | but instead would just provide the "overall" result | 08: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 |
| chriadam | but in general, I think it should be applicable in most cases | 08:08 |
| dcaliste | Yeh, or fallback to the trick of agregating various source into one string. | 08:08 |
| chriadam | right, true | 08:10 |
| chriadam | one sec, will merge those two PRs now | 08:10 |
| dcaliste | Thanks for the discussion, it's longer term changes anyway, and we can mature them for weeks. | 08:17 |
| chriadam | ok, I've merged and tagged those for JB#50856. tyvm! | 08:17 |
| chriadam | yes, the buteo one will take some discussion and iteration I am sure :-) | 08:17 |
| dcaliste | Thank you for the merges also. I can rebase my failure branch on top. | 08:17 |
| chriadam | thanks as always for your efforts - greatly appreciated. | 08:17 |
| dcaliste | I'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 |
| dcaliste | As 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 |
| chriadam | indeed, sounds like a good idea :-) | 08:19 |
| chriadam | did you ahve anything else to discuss tonight? | 08:19 |
| dcaliste | No, it was nice already. Thank you for your time. | 08:20 |
| chriadam | thank you - have a great week! | 08:20 |
| dcaliste | You too. | 08:20 |
| chriadam | gnight! | 08:20 |
| *** BitEvil is now known as SpeedEvil | 08:31 | |
| *** leinir_ is now known as leinir | 11:08 | |
| Anasko | Question: 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/!