| *** SpeedEvil is now known as Guest54531 | 01:56 | |
| *** zbenjamin_ is now known as zbenjamin | 02:39 | |
| *** frinring_ is now known as frinring | 05:15 | |
| flypig | dcaliste, could we have a quick chat if you're available some time today? | 09:08 |
|---|---|---|
| dcaliste | flypig: sure, whenever you want. | 09:50 |
| dcaliste | (sorry, missed your ping before) | 09:50 |
| flypig | dcaliste, thanks, I got distracted myself too. | 10:11 |
| flypig | Now? | 10:11 |
| dcaliste | Yes, I've one hour before colleagues will ask to go to lunch ;) | 10:11 |
| flypig | Okay great, should be plenty :) | 10:13 |
| flypig | I did some work on folder sync to extend to EAS+Google. Would you be willing to review it? | 10:13 |
| dcaliste | flypig: yes, within a one week time frame though, because I don't much about this code. | 10:14 |
| dcaliste | I mean, no answer guaranteed before one week ;) | 10:14 |
| flypig | Ah, okay. I don't think that's going to be a problem. Let me check, one second... | 10:15 |
| flypig | Yes, that's no problem. | 10:18 |
| flypig | You have access to the internal repos, right? | 10:19 |
| flypig | But not the bug reports? | 10:19 |
| dcaliste | Ok, when your MRs are ready give me the URLs, but we need to ask jpetrell to give me read access on these repos first. | 10:19 |
| dcaliste | Right, I cannot read the bug reports. | 10:20 |
| flypig | Okay, I'll ask jpetrell about access to the repos. I don't think access to the bug report will help, but the repos are crucial (obviously!) | 10:21 |
| dcaliste | Indeed. I'll do my best to try to understand these parts and do the review thoroughly. | 10:23 |
| flypig | dcaliste, that part I'm not at all worried about :) I'd really appreciate your -- always helpful -- comments. | 10:24 |
| dcaliste | If I'm not anymore on IRC, I'll check on bitbucket to see when new repo appears in my panel and give a look to the pending MR to find yours. | 10:25 |
| flypig | If you can access this on bitbucket, then I'll add links to all the other repos there: jolla/ui-jolla-email/pull-requests/460/ | 10:26 |
| dcaliste | Yes, thanks, I can see this one. | 10:27 |
| dcaliste | Ok I've seen your list. I'm currently missing access to qmf-eas-plugin and base-sailfish-eas | 10:29 |
| dcaliste | It's ok for the account setting repo and the sailfishos ones (obviously). | 10:29 |
| flypig | Okay, I'll get your account set up to access those two as well. | 10:38 |
| flypig | dcaliste, I've asked for you to have access and will ping you to let you know when it's sorted. | 10:40 |
| dcaliste | Thanks flypig. | 10:41 |
| flypig | Thanks again with this. Concerning the caldav stuff, thanks for that ics file. | 10:41 |
| flypig | I've been trying it this morning. I may have questions, but I should check further about it now first. If you're around after lunch, I may query you if that's okay. | 10:42 |
| dcaliste | flypig, about that exdate issue I don't know if you see my comments a bit before https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/59#note_39186 | 10:42 |
| flypig | But hopefully I'll just be able to merge it today. | 10:42 |
| dcaliste | The last part about how upstream they are handling this. | 10:42 |
| flypig | Yes, I did read those. | 10:42 |
| dcaliste | I'm still wondering if we should patch caldav plugin, like I'm proposing in this MR. | 10:43 |
| dcaliste | Or go the upstream solution of relaxing the test in entry of dissociateSingleOccurrence in mkcal… | 10:43 |
| flypig | So the two approaches are: 1. fix up the ical data before it reaches mkcal; or 2. Relax the mkcal check. | 10:44 |
| dcaliste | Besides, no problem to ping me after lunch if you have questions. | 10:44 |
| flypig | In the case of 1, everything works correctly, but the data gets changed on the server. | 10:44 |
| dcaliste | Not exactly, the 1. solution is to fix the stored parent incidence to remove of offending EXDATE. | 10:45 |
| flypig | In the case of 2, no data is changed, but technically it may store non RFC-compliant data. | 10:45 |
| dcaliste | Exact for case 2. | 10:45 |
| flypig | So for case 1, what is the downside? | 10:45 |
| flypig | The result is basically the same, no? | 10:46 |
| flypig | (I mean, for the user) | 10:46 |
| dcaliste | The downside I see is additional code in caldav that is not strictly related too, and become useless if we move upstream to the new dissociate routine from kf5-kcalendarcore. | 10:46 |
| dcaliste | For the user, both are fine ;) | 10:46 |
| dcaliste | Hopefully. | 10:46 |
| flypig | Okay, so I agree that architecturally, and in the longterm, case 2 is nicer. | 10:47 |
| flypig | On the other hand, case 1 is working, offers limited scope for regression, and can be deployed more quickly. | 10:48 |
| dcaliste | I'm sorry, I need to leave for lunch. And I agree with your positive points for solution 1. | 10:48 |
| flypig | Okay, enjoy your lunch :) Hopefully I can catch you later. | 10:49 |
| dcaliste | Particularly, it has been "tested" by the reporter in TJC and he feels fine with it. | 10:49 |
| dcaliste | I'll keep my IRC window on during the afternoon. | 10:49 |
| dcaliste | See you. | 10:49 |
| flypig | Thanks :) Speak later then. | 10:49 |
| dcaliste | Hello again flypig, we can resume our discussion whenever you prefer. | 12:08 |
| flypig | Great, thanks. I hope you had a good lunch :) I do have more questions though I'm afraid. | 12:08 |
| dcaliste | So let's start. | 12:08 |
| flypig | Just to let you know, jpetrell has asked for you to have access, but has to check some licence-related issue for sailfish-eas. | 12:09 |
| flypig | So that may take a little longer. | 12:10 |
| dcaliste | Ok, no problem. Thanks for the info. | 12:10 |
| flypig | Concerning caldav, some things came to mind. | 12:10 |
| flypig | My feeling is that, it's probably better to get the fix in. Especially given the dissociate code is already "in the wrong place". | 12:11 |
| flypig | So this doesn't seem to be making it worse. | 12:12 |
| flypig | However, I'm still having trouble testing it. Can I ask how you got the ics file onto your phone? | 12:12 |
| dcaliste | I agree. I was undecided on the matter, and it was better to discussed it a bit. I agree with your conclusions. | 12:13 |
| flypig | My conclusions aren't by any means the final word. But if you're happy with that, then it seems Chris is too (from what he says on the bug). | 12:13 |
| dcaliste | For the ics, let me remember… | 12:14 |
| flypig | Sorry: when I say "what he says on the bug", I mean the "on the MR". | 12:15 |
| dcaliste | About the ICS, I can't find the exact way I tested it. I think I highjacked some of the ICS data in tests/noteboosyncagent/data/, let the test run and see the crash with the error message from the TJC logs. | 12:18 |
| flypig | Okay, that makes sense. I'm having trouble because Thunderbird refuses to import it. If there's no obviously 'natural' way to do it, I should also hack around a bit to make it happen. | 12:19 |
| flypig | However, when trying to import it, it raised the issue that this won't fix the problem for importing the file directly. | 12:20 |
| flypig | Do you have any thoughts about a solution for that, and whether it's worth worrying about. | 12:21 |
| dcaliste | Then, I figure out the issue was with this EXDATE defined in the parent event. I accidentaly change a earlier ignored error https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/commit/2692a7daf5698ed3759b032848bfd9a8beafebff#25b531d153d0472485d380353df2c41c0cb5532c_1058_988 (critical error flag is not set) into a failing error. | 12:22 |
| dcaliste | About your question: | 12:22 |
| dcaliste | I don't think it will becomes an issue during upsync, because all EXDATE for exceptions are removed before upsyncing (to respect RFC). | 12:23 |
| dcaliste | And because these EXDATEs are supposed to be added by us for mkcal own reasons. | 12:23 |
| dcaliste | The fact that the EXDATE already exists and will be removed during upload is a side effect. | 12:23 |
| flypig | But when the EXDATES are removed, that'll change the result, won't it? | 12:24 |
| dcaliste | The lines for the removal : https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/blob/master/src/incidencehandler.cpp#L371 | 12:25 |
| flypig | I'm unclear as to why it does that. | 12:25 |
| dcaliste | No, it should not change the result according to my understanding of the RFC. But it may change the server behaviour if it is expecting an EXDATE for an exception… | 12:25 |
| dcaliste | Ok, let's start from the beginning on EXDATEs (from my understanding): | 12:26 |
| flypig | Please! | 12:26 |
| dcaliste | - recurring events can have exceptions. | 12:26 |
| dcaliste | - a recurring event is defined by its recurring dates. | 12:26 |
| dcaliste | - you can define recurring dates by various means, including rules or explicit RDATEs. | 12:27 |
| dcaliste | - you can exclude some dates from the recurrence with rules or explicit EXDATEs. | 12:27 |
| flypig | Okay, all makes sense so far. | 12:28 |
| dcaliste | - at the end, you have a "parent" event that have occurrences on given dates. | 12:28 |
| flypig | One second, please: question | 12:28 |
| dcaliste | sure go ahead. | 12:29 |
| flypig | Does a defined EXDATE recur? | 12:29 |
| dcaliste | No but you can defined EXRULES. | 12:29 |
| flypig | Okay, that's what I thought. Thanks. | 12:29 |
| flypig | Please go ahead! | 12:29 |
| dcaliste | The RFC says then that you can defined exceptions, or let say modify a specific occurrence using a new event. | 12:31 |
| dcaliste | This event MUST define a RECURRENCE-ID entry with the DTSTART value of the occurrence it is made to replace. | 12:32 |
| dcaliste | Then, it can have various other value for new DTSTART, DTEND, SUMMARY… | 12:32 |
| flypig | Okay. | 12:33 |
| dcaliste | So if you want to define a week-day meeting, you create an event with a RRULE:byWeekDay | 12:33 |
| dcaliste | (I don't remember the excat syntax) | 12:33 |
| flypig | Sure, n.p. :) | 12:33 |
| dcaliste | Then, if one of the meeting is during a public holyday, you can remove this specific occurrence. | 12:34 |
| dcaliste | To do it, add an EXDATE in the parent incidence with the public holyday time stamp. | 12:34 |
| flypig | I can see how you do that using EXDATE. But can you do that using RECURRENCE-ID too? | 12:34 |
| dcaliste | This is what happens in the calendar app, when you remove an occurrence of a recurring event. | 12:35 |
| dcaliste | Indeed, you can also define another event with the same UID and a RECURRENCE-ID set for this public holyday. | 12:35 |
| flypig | But without any DTSTART/DTEND defined? | 12:36 |
| dcaliste | In that case, the RFC says that the original event of that holyday is _replaced_ by this new event. | 12:36 |
| dcaliste | I don't know if DTSTART is mandatory, I think so. | 12:36 |
| flypig | But replaced isn't the same as removed...? | 12:36 |
| dcaliste | Indeed. | 12:36 |
| dcaliste | To remove, you use EXDATE. | 12:36 |
| dcaliste | To modify locally, you use RECURRENCE-ID. | 12:37 |
| dcaliste | Then mKCal is arriving… | 12:37 |
| flypig | Okay, that all makes sense. | 12:37 |
| flypig | But, if EXDATE is the only way to remove a repeating occurrence, then it's necessary for some arrangeents? | 12:37 |
| flypig | *arrangements | 12:37 |
| dcaliste | … and by a clever idea is introducing a bit of confusion (no blame intended). | 12:37 |
| dcaliste | Sorry ? | 12:38 |
| flypig | Sorry, that's a sticking point for me. Can we hold the thought about clever ideas for a second. | 12:38 |
| dcaliste | Sure, of course. | 12:39 |
| dcaliste | An event with RECURRENCE-ID defined will replace its original occurrence, the original occurrence should not be visible on any calendar UI. | 12:39 |
| flypig | Suppose I have a recurring event every Friday. I want to remove it from Christmas Day 2020. Then an EXDATE is used for that. If the EXDATE is stripped on upload, then there's no way to represent this arrangement. | 12:40 |
| dcaliste | Ah, ok. | 12:40 |
| dcaliste | We're removing EXDATEs only for EXDATEs matching RECURRENCE-IDs, not the others. | 12:40 |
| dcaliste | So on upload in your case, the EXDATE is kept. | 12:41 |
| dcaliste | Your next question may be : but why do we have EXDATE for RECURRENCE-IDs in the database ? | 12:42 |
| flypig | Yes, that's a good question. Let's pretend I was going to ask that ;) | 12:42 |
| dcaliste | That's because of mKCal. | 12:42 |
| flypig | Are we back to the clever idea? | 12:43 |
| dcaliste | It's not present in kcalcore, current SFOS version or upstream. | 12:43 |
| dcaliste | Yes, it's the clever idea. | 12:43 |
| dcaliste | When you want to display your occurrences in a calendar UI, you need a function to expand your recurrences. | 12:43 |
| dcaliste | in mKCal, it's rawExpandedEvents(). | 12:44 |
| dcaliste | There is no one in current kcalcore. But they introduce a nice iterator in upstream for this. | 12:44 |
| dcaliste | kcalcore is providing functions to get list of occurrences from given recurrence rules and exceptions. | 12:45 |
| dcaliste | So in mKCal, we're building a list of occurrences from the list of incidences (recurring or not). | 12:46 |
| flypig | This is the function you recently refactored. | 12:47 |
| dcaliste | Indeed. | 12:47 |
| flypig | For the record, it made my head hurt. | 12:47 |
| flypig | (but the blame lies with the iCal format) | 12:47 |
| dcaliste | The initial thoughts of mKCal authors, I guess, was : "how to exclude all the RECURRING-IDS from this list ?" | 12:47 |
| flypig | Okay. | 12:48 |
| dcaliste | And, instead of doing it by hand, they suggest to use the EXDATEs ! | 12:48 |
| dcaliste | That's the clever idea. | 12:48 |
| dcaliste | So kcalcore will automatically remove the replaced occurrences. | 12:48 |
| flypig | I think I'm following, but let me check. | 12:49 |
| dcaliste | And the list will contain only the occurrences, not the replaced ones, and the replacing events. | 12:49 |
| flypig | Rather than removing items, they add exceptions. | 12:50 |
| dcaliste | That's it. | 12:50 |
| flypig | But kcalcore doesn't normalise this. | 12:50 |
| dcaliste | Exact. | 12:50 |
| dcaliste | mKCa is adding the exception when using the dissociateSingleOccurrence() rotuine. | 12:50 |
| dcaliste | See the end of the routine in extendedcalendar.cpp. | 12:51 |
| dcaliste | But of course, conversion to iCal format in kcalcore is not aware of this. | 12:51 |
| flypig | One second... | 12:51 |
| dcaliste | So every user of kcalcore exporter (plugins, calendar tool in nemo-qml-plugin-calendar) have to remove the offending EXDATEs. | 12:52 |
| dcaliste | Sure… | 12:52 |
| flypig | RECURRING-IDS can reference VEVENTS that contain complex exceptions. These can't always be translatable into EXDATEs. | 12:53 |
| flypig | So sometimes something will have to be added. | 12:54 |
| dcaliste | It can. a RECURRENCE-ID is the DTSTART of the replaced occurrence. So this DTSTART can always be used a EXDATE if one wants. | 12:54 |
| dcaliste | The EXRULEs and EXDATEs are used to create the occurrences list in addition to the RRULEs and RDATEs of course. For the parent event. | 12:55 |
| flypig | Okay, got it. And the DTSTART it replaces is only ever a single event. | 12:56 |
| dcaliste | You can defined for instance a recurrence that works every week day with the appropriated RRULE, then remove every Wednesday with a right EXRULE. | 12:56 |
| flypig | But you wouldn't create a child for that? | 12:57 |
| flypig | Just include it in the parent. | 12:57 |
| dcaliste | Right. | 12:57 |
| dcaliste | A child is to *modify* an occurrence. | 12:57 |
| dcaliste | Then, you can replace (or modify) any occurrence with as many new incidences with RECURRENCE-IDs. | 12:58 |
| dcaliste | But RECURRENCE-ID is unique per child and define a unique time stamp. | 12:58 |
| dcaliste | And mKCal is adding these unique tiestamps as EXDATEs. to the parent. | 12:58 |
| flypig | But I can see why they convert RECURRENCE-IDs into exclusions. Otherwise they might have to turn it into two separate RRULES with some complexity. | 12:58 |
| flypig | they = mkcal devs. | 12:59 |
| dcaliste | So the generation of the occurrence list is indeed *replacing* the exceptions | 12:59 |
| dcaliste | Without additional work on the occurrence list. | 12:59 |
| dcaliste | And yes, they can only use EXDATE because there is no pattern to the exceptions (they are created one by one in the UI by saying "modify just this event not the whole series"). | 13:00 |
| dcaliste | So, to summarise: | 13:01 |
| flypig | Okay, this all seems to makes sense. | 13:01 |
| dcaliste | - parent events can recur, with complex recurrence rules, there can be "removed" occurrence in the pattern, using EXRULE and EXDATE. | 13:02 |
| dcaliste | - some child events can be individually modified using the RECURRENCE-ID, the original occurrence should not appear then in a calendar UI. | 13:02 |
| dcaliste | - mKCal is adding EXDATEs for each RECURRENCE-ID to avoid the pain of removing the replaced occurrences in expandRawEvents(). | 13:03 |
| dcaliste | - these spurious EXDATEs must then be removed by hand befaore upload. | 13:03 |
| dcaliste | (in every client using the API…) | 13:04 |
| dcaliste | To come back to the bug at hand: | 13:04 |
| flypig | It seems to me that there's a mismatch between ical functionality and kcalcore functionality. | 13:04 |
| flypig | RECURRENCE-ID is redundant in the spec, and kcalcore doesn't support attaching exceptions to parents. | 13:05 |
| dcaliste | Why is it redundant ? | 13:05 |
| flypig | All it does is remove an event, and EXDATE does that already. There's no reason to tie an exception to a removal. | 13:06 |
| flypig | If I change an event, I actually don't care which particular piece I changed. It may as well be an EX with an R. | 13:06 |
| dcaliste | Ah, sorry a misunderstanding manybe : | 13:06 |
| dcaliste | RECURRENCE-ID is to be added in the child event. | 13:06 |
| flypig | Yes, but it could also be replaced by an EXDATE in the child event. I'm not sure I've ever seen a client that exposes the deleted event that it replaces. | 13:07 |
| flypig | (exposes to the user, that is) | 13:07 |
| flypig | The mkcal conversion is technically losing data. | 13:08 |
| dcaliste | No, the child event is not recurring, so cannot have an EXDATE. | 13:08 |
| flypig | Sorry, my mistake: the EXDATE could be in the parent. | 13:08 |
| dcaliste | Ah, ok. | 13:08 |
| flypig | Anyway, that's a digression. We should return to the bug in hand. | 13:09 |
| dcaliste | About the bug: | 13:10 |
| dcaliste | the coming ICS is faulty in my opinion because the parent is _not_ recurring on the date the child event is defined by its RECURRENCE-ID. | 13:10 |
| dcaliste | in the beginning of dissociateSingleOccurrence(à in mKCal, there is a test saying | 13:11 |
| dcaliste | "do the child event I'm receiving is happening at a recurring time of the parent?" | 13:11 |
| dcaliste | Since the EXDATE is set to the value of the RECURRENCE-ID, the answer to this questionis *no*. | 13:12 |
| dcaliste | Before my rework of the caldav incidence update code, this negative return was ignored. | 13:12 |
| dcaliste | But, I didn't notice that I changed the behaviour by making this negative return a fatal error in the plugin. | 13:13 |
| dcaliste | So a user with such a faulty event is seeing that before 3.2.1.20 it was syncing (ignoring the exception but syncing anyway), while now it refuses to sync. | 13:14 |
| flypig | Yes, this makes sense. Looking at the ical spec, this looks ambiguous as an error to me. | 13:14 |
| dcaliste | My suggestion in this MR, is to remove the offending EXDATE if I'm receiving a RECURRENCE-ID on a given EXDATE. | 13:15 |
| dcaliste | Now, the question is what happen on export ? | 13:15 |
| dcaliste | Before 3.2.1, the EXDATE was sent back, but not the exception (since it was ignored on importation). | 13:16 |
| dcaliste | With the MR, the EXDATE is removed and the exception is sent back. | 13:16 |
| dcaliste | So we're modifying the event with respect to what was sent initially. | 13:17 |
| dcaliste | But at least we're sending the exception back… | 13:17 |
| flypig | One second. | 13:19 |
| dcaliste | Sure… | 13:21 |
| flypig | It looks like there are three different approaches here: | 13:22 |
| flypig | 1. On import remove exception EXDATE if it matches a RECURRENCE-ID (new behaviour). | 13:22 |
| flypig | 2. On import ignore exception if EXDATE matches RECURRENCE-ID (old behaviour). | 13:22 |
| flypig | 3. On import/export, keep EXDATE and RECURRENCE-ID (non-destructive behaviour). | 13:22 |
| flypig | If this is correct, is it also correct to say that: 1 and 2 look different to the user (1. excepation retained vs. 2. excpeation lost). Whereas... | 13:23 |
| flypig | Both 1 and 3 looks the same to the user, but technically data is lost by 1? | 13:24 |
| dcaliste | I think you sumarize it in a nice and correct way. | 13:25 |
| dcaliste | I agree on all your points. | 13:25 |
| flypig | Great, then that's a good sign I'm following. | 13:25 |
| dcaliste | Solution 3 would be the best, but is "hard" to implement. | 13:26 |
| dcaliste | In the sense, that the way I can see is to add a flag 'keep my EXDATE please' to the child event. | 13:26 |
| dcaliste | On export, remove the EXDATEs for every children, except if they have the flag. (and then remove the flag also, otherwise it will be upsynced also). | 13:27 |
| dcaliste | This would add a lot of boiler plate code… But everything is kept in that case, which ensure less probability of bug or error on upsync. | 13:28 |
| flypig | On export, how does mkcal tie children to parents currently? | 13:28 |
| dcaliste | There is a kcalcore method called Calendar::instances(), which is returning all children of a given incidence. | 13:29 |
| dcaliste | Then, we're creating a memory calendar with the parent and all the instances. and export this memory calendar using the kcalcore ical formater. | 13:29 |
| flypig | So the RECURRENCE-ID can be reconstructed from this. | 13:30 |
| flypig | Presumably then kcalcore could filter out all events with RECURRENCE-IDs. | 13:30 |
| dcaliste | What do you mean ? | 13:31 |
| flypig | You mentioned above that mkcal adds an exception for every RECURRENCE-ID, yes? | 13:32 |
| dcaliste | Yes, it is adding to the parent an EXDATE for every RECURRENCE-ID of its children. | 13:32 |
| flypig | And the RECURRENCE-ID is what captures the child-parent relationship. | 13:33 |
| flypig | (in an ical file, that is). | 13:33 |
| dcaliste | Yes (for a given UID value). | 13:33 |
| flypig | So kcalcore could filter out both EXDATES *and* events that RECURRENCE-IDs refer to, just like the ical spec does. | 13:36 |
| dcaliste | Sure, that's what we're doing at the moment. | 13:37 |
| dcaliste | Or, I'm not understanding the *and* part… | 13:38 |
| dcaliste | Let's take an example: | 13:38 |
| flypig | I think I have the wrong component. I mean that this could happen in rawExpandedEvents() | 13:38 |
| flypig | Which is mkcal. | 13:39 |
| dcaliste | Ah, great indeed, that is my proposition ;) let me find it somewhere… | 13:39 |
| dcaliste | https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/58#note_39119 | 13:40 |
| dcaliste | Yes, that would solve our problem by isolating the issue in mKCal. | 13:40 |
| flypig | Okay, yes, makes sense. And then no data loss in either direction. | 13:41 |
| dcaliste | I need though to check that only expandRawEvents() is used with respect to this, or if there are other routine that needs filtering. | 13:41 |
| flypig | Yes, I can see it's not without risk. | 13:42 |
| dcaliste | If it is working, we would have something that is much closer to upstream and ical format, which is great in my opinion, and sorry for the clever idea… | 13:43 |
| flypig | :) Yes, that would be nice. | 13:43 |
| flypig | Presumably there's an argument that we should adopt the newer upstream, rather than fix old upstream. | 13:45 |
| dcaliste | Implementing this is creating a transition issue also because currently stored events have been poluted with a lot of EXDATEs. | 13:45 |
| dcaliste | Ah, but this is mKCal and we're upstream for this package… | 13:45 |
| flypig | Yes, good point. | 13:46 |
| flypig | I guess that pollution doesn't really do any harm to the user. | 13:47 |
| flypig | Even on transition. | 13:47 |
| flypig | Sorry: even after transition. | 13:47 |
| dcaliste | The point about being closer to upstream is standing though, because they have added in kf5-CalendarCore many functions from extendedcalendar in mKCal have been re-implemented, so when moving to kcalcore upstream, we will have to clean later on to transition to the new routines. | 13:48 |
| dcaliste | about the EXDATEs polution, yes, you're right, but the code to handle it on export will have to be kept eternally n every client… | 13:48 |
| flypig | Yes, the import code can go, but not the export code. I suppose there could be a one-pass fix-up of the database. | 13:49 |
| flypig | Send everything through the export code, then import it all back again ;) | 13:50 |
| dcaliste | That's true. We can figure out a oneshot for this. But when doing we'll have to be sure of ourselves, otherwise we will loot all user's databases… | 13:51 |
| flypig | Yes, it's easy to discuss it consequence-free in the abstract. | 13:52 |
| flypig | Okay, thank you for the in-depth explanations. That's really helpful, but... I think this shouldn't affect the merging of your MR!58 or MR!59.! | 13:53 |
| dcaliste | I agree. MR!58 and MR!59 are fixing two different bugs even if related to this annoying EXDATE list added by mKCal. | 13:54 |
| flypig | This also helps me better understand what I ought to be seeing when importing the example file. I'm afraid I still want to see it in action: your explanation makes perfect sense, but it's just a matter of due diligence on my part. | 13:56 |
| dcaliste | I fully agree. | 13:58 |
| flypig | Okay, thanks again dcaliste, that covers things for me. I'll let you know once the EAS repo is sorted out, but if you want to already comment on the rest of them, I'd be very pleased for your input. | 14:03 |
| dcaliste | I'll begin to review it and continue during the coming days and next week. | 14:03 |
| dcaliste | I'm adding at the moment the ICS data for the faulty case in the test to see if I can demonstrate it and check it properly. | 14:04 |
| dcaliste | Ah, I remember also now looking at the code, that I added a test (not from ICS data but from handly crafted events) in updateIncidence_data() in notebooksyncagent test. | 14:06 |
| flypig | Will you update the MR? | 14:06 |
| flypig | ... no need by the sound of it. | 14:06 |
| dcaliste | Depends, because the already added test is enough to test the behaviour. | 14:06 |
| dcaliste | But I would be glad to see the ICS data work also, just for confidence ! | 14:08 |
| flypig | It's fine either way by me then. However, would you mind updating the title to add "Contributes to JB#48484" and rebasing if necessary? | 14:08 |
| dcaliste | Sure, no problem. | 14:08 |
| flypig | Thank you: all your work is really very much appreciated. | 14:08 |
| dcaliste | flypig, ok, I've just force pushed a modified MR with the addition of the ICS data and a test to ensure that this kind of ICS is imported without issue. This test is failing with master branch. | 14:32 |
| flypig | dcaliste: great, thank you for doing that. Very nice :) | 15:01 |
| dcaliste | @flypig, you're welcome | 15:06 |
| zaggynl | Is there an official wireguard package for sailfish? I found https://together.jolla.com/question/182324/wish-wireguard/ but not sure if is proper way to install | 16:01 |
| x2s | doesn't look like there is any | 16:06 |
| enigma9o7 | I'm new to sfos so this may be a dumb question. How do i search packages to find which contains a file I want? | 18:01 |
| enigma9o7 | (specifically, I'm tryiing to make something that requires 'header files' and believe I need mmem.h) | 18:02 |
| r0kk3rz | enigma9o7: sounds like you need kernel sources, which im not sure are packaged | 21:47 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!