| rinigus | tanriol:: yes, it is relevant. Thank you very much! For some reason, I don't have that it in new port, would have to figure out why | 05:48 |
|---|---|---|
| rinigus | If someone with Xperia 10ii (aosp10 based port) can also confirm slow blinking of led on notification that would be helpful | 05:50 |
| volcanosweetroll[m] | I have Xperia 10ii with version 4.1.0.24 and the notification led is a continuous blue color and not blinking | 06:51 |
| dcaliste | Good morning flypig, how are you ? | 06:56 |
| flypig | Good morning dcaliste. I'm very well thank you. And you? Preparing for your holidays I hope? | 06:56 |
| dcaliste | Partially, indeed, but still at work for this week. | 06:58 |
| dcaliste | Would you mind discussing a bit the EXDATE mKCal specificity this morning, or do you prefer to wait for chriadam ? | 06:59 |
| flypig | I'm very happy to go whichever direction you prefer. It would be good from my point of view also to recap on where things are at generally, but we can do that afterwards. | 06:59 |
| flypig | Can you point me at the relevant PR please? | 07:00 |
| dcaliste | Ok, let's start with the broader look, https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Adcaliste+archived%3Afalse+org%3Asailfishos | 07:00 |
| dcaliste | - https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Adcaliste+archived%3Afalse+org%3Asailfishos | 07:01 |
| dcaliste | https://github.com/sailfishos/mkcal/pull/1 | 07:01 |
| dcaliste | sorry wrong link on first point... | 07:01 |
| dcaliste | so, mKCal PR#1, the idea is to change the convention in mKCal about including or not the organizer as attendee. It seems to me that every of part of the stack is using the opposite convention to mKCal and thus adding various lines of code to reverse it. | 07:02 |
| flypig | Okay, I remember us discussing this previously. Were there already some PRs merged related to this? | 07:03 |
| dcaliste | I think chriadam agree on this one. After merged, some cleaning can be done in the sync plugin codes. But nothing has been prepared yet. | 07:03 |
| flypig | Was this one of the ones chriadam suggested he might merge? | 07:04 |
| dcaliste | Keeping the old reversing convention code should still work by doing nothing. Thus there is no need to a schedule transition for this. | 07:04 |
| dcaliste | I think he will merge this PR#1 soon indeed. | 07:04 |
| flypig | So, the plan will be to merge this, following which some new clean-up PRs will follow. | 07:05 |
| dcaliste | Exact. | 07:06 |
| dcaliste | - https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/1 is also a cleaning PR, removing some old code that was necessary when doing event comparison to ensure the best match possible. Since we're not doing any event comparison anymore, there is no point in keeping this code that modify the event on export. | 07:07 |
| dcaliste | I think chriadam also agreed on this one. | 07:08 |
| flypig | Okay. So for the mkcal#1 it looks like it could maybe do with some confirmation from Pekka or me. | 07:10 |
| flypig | But chriadm already seems comfortable to merge nqpc#1. | 07:12 |
| dcaliste | Sure, if you or pvuorela have time to give a look that's always better. | 07:13 |
| dcaliste | nqpc ? Did you mean b uteo-sync-plugin-caldav ? | 07:13 |
| flypig | Sorry, yes, that's what I meant: bspc#1 | 07:16 |
| flypig | chriadm mentioned that there were two PRs he was planning to merge. Presumably those two then. | 07:17 |
| flypig | I think now is the right time to merge the mkcal#1 PR, because even though it should be safe, it does touch several other components, and we still have some time to test this in devel. | 07:18 |
| dcaliste | Yeh, it's better to allow time for testing, these changing convention operations, even when looking safe could always raise unexpected troubles... | 07:19 |
| dcaliste | - there is also : https://github.com/sailfishos/kf5-calendarcore/pull/1 | 07:20 |
| dcaliste | It's a maintainance PR, updating upstream now that they are creating a pkgconfig. I think pvuorela should give his opinion on it. | 07:21 |
| dcaliste | Sorry, not updating upstream, but updating *from* upstream ! | 07:21 |
| flypig | Okay, makes sense :) So, there were a few changes to the patches. Is there anything substantive in there, or is it mostly rebasing? | 07:22 |
| flypig | One patch removed. | 07:22 |
| flypig | The other related to unit tests? | 07:23 |
| dcaliste | Exact, I've changed something upstream in one test (there was a mistake in the choice of testing timezone wrt. system timezone). The patch porting back to Qt5.6 touches lines in this test, that's why it required some update. | 07:24 |
| dcaliste | The removed patch is the purpose of this PR : upstream is now providing a pkgconfig file. So our patch is not needed anymore. | 07:24 |
| flypig | That all seems clear and straightforward. I didn't check the upstream changes, but will take a quick look and comment if I have anything useful to add. | 07:27 |
| dcaliste | Great thank you. | 07:27 |
| flypig | I've also pinged pvurela to ask for him to take a look to. | 07:27 |
| dcaliste | Thanks. The two last PRs come together: https://github.com/sailfishos/mkcal/pull/2 and https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/3 | 07:28 |
| dcaliste | (the other two PRs in buteo-syncfw and nemo-qml-plugin-calendar could be discuss later and require in-depth review) | 07:29 |
| dcaliste | The two PRs in mKCal and nemo-qml-plugin-calendar deal with the EXDATE handling in mKCal for exceptions. | 07:29 |
| dcaliste | KCalendarCore and the RFC are not enforcing exceptions to be in the EXDATE list of the parent. | 07:30 |
| dcaliste | But for various (convenient) reasons mKCal is doing it. This creates an additional burden in the rest of the stack to filter out or add these suprious EXDATEs. | 07:30 |
| dcaliste | I'm suggesting to change this by using the (new) KCalendarCore OccurrenceIterator that does not suffer from the same issue than rawExpandedEvents() from mKCal. | 07:31 |
| dcaliste | The latter requires the EXDATE to contain the exception start date time to filter them out. | 07:32 |
| dcaliste | While the upstream iterator is calling instances() on the calendar to remove the exception occurrences from the parent occurrences. | 07:33 |
| dcaliste | I've first submitted a PR in mKCal to change rawExpandedEvents() to use the iterator, and then change the code in dissociateSingleOccurrence() not to add anymore the start date in EXDATE of the parent. | 07:34 |
| dcaliste | Since the iterator and rawExpandedEvents() don't use the same API, I needed to deprecate rawExapandedEvents() and create a rawExandedIncidences() instead. | 07:34 |
| flypig | I seem to recall some discussion about this previously (I think I was looking at the google sync plugin to see whether it would be affected). | 07:34 |
| flypig | But I don't recall looking at the mkcal PR in any detail yet. | 07:35 |
| dcaliste | Indeed, you were partially involved in this discussion previously. | 07:35 |
| flypig | There was the issue of multiple exceptions for the same time. | 07:35 |
| dcaliste | Indeed. | 07:36 |
| flypig | Looking at the PR, you already made changes to address this. | 07:36 |
| dcaliste | Exact, I added the instances() call there to recover the previous behaviour. | 07:36 |
| flypig | Can you explain to me about the retention of rawExpandedEvents() please. | 07:37 |
| dcaliste | Sorry, what do you mean by retention ? | 07:37 |
| flypig | After MR#3 has been merged, would the plan be to remove rawExpandedEvents()? | 07:38 |
| dcaliste | That something I would like to discuss in the regard of nemo-qml-plugin-calendar#3. | 07:39 |
| dcaliste | As far as I know (and that should be checked carefully), this nemo plugin is the sole user of rawExpandedEvents(). | 07:39 |
| flypig | Would you remove both rawExpandedEvents() *and* rawExpandedIncidences()? | 07:40 |
| dcaliste | I would be in favor to remove it completely actually and replace it with upstream OccurrenceIterator directly. | 07:40 |
| dcaliste | There is no need in my opinion to keep a thin wrapper in mKCal that just create a list from the iterator. | 07:40 |
| dcaliste | But that's open to discussion of course. | 07:41 |
| flypig | To what extent is nqpc#3 dependent on mkcal#2? | 07:42 |
| dcaliste | Actually, it is not. | 07:43 |
| dcaliste | Using nqpc#3 will already raise the necessity to have exception as EXDATE, as long as it is the unique place where rawExpandedEvents() is used. | 07:44 |
| dcaliste | But then mkcal#2 is bringing some additional changes in dissociateSingleOccurrence() not to add anymore the exception as EXDATE. | 07:44 |
| flypig | Sorry, I'm not quite following you here: "Using nqpc#3 will already raise the necessity to have exception as EXDATE", could you elaborate for me please? | 07:45 |
| dcaliste | the problem of having exception as EXDATE in the parent is solely due to how rawExpandedEvents() is written. If you use the OccurrenceIterator from upstream you don't need this assumption. | 07:46 |
| dcaliste | If you remove the call in nqpc, you don't need to add exception as EXDATE when you dissociate an occurrence. | 07:47 |
| flypig | So, if mqpc#3 were merged, and assuming it's the only consumer of rawExpanded*, then could mkcal#2 be streamlined? | 07:47 |
| flypig | Would this be desirable? | 07:48 |
| dcaliste | What do you mean streamlined ? | 07:48 |
| flypig | If rawExpanded* were then the only place needing the EXDATE exceptions, would it make sense not to introduce rawExpandedIncidences() at all? Or is this a useful method to have anyway? | 07:49 |
| flypig | (I'm not making a judgement on the matter, just exploring the space) | 07:50 |
| dcaliste | I see three possibilities we have to choose from: | 07:51 |
| dcaliste | - be very conservative and don't touch anything (it's working after all), | 07:51 |
| dcaliste | - be a bit conservative and modify internally mKCal to use the OccurrenceIterator but keep the API (or at least introduce a rawExpandedIncidences()), even if the functions are now only thin wrappers, | 07:52 |
| dcaliste | - be a bit adventurous and remove from the mKCal API the rawExpanded*() functions so the stack will use directly the OccurrenceIterator from upstream. | 07:53 |
| dcaliste | Currently, nqpc#3 is doing this, but mkcal#2 is not yet removing the functions from the API. | 07:53 |
| dcaliste | I'm myself in favour of option 3, but I would like to have your opinion. Your but maybe also the one of chriadam and pvuorela. | 07:54 |
| dcaliste | I think it's a good direction to remove as much as we can from mKCal that is not strictly dealing with the SQlite storage and be as much as we can compatible with KCalendarCore for incidence handling. | 07:55 |
| flypig | Well, from my point of view, without detailed checking of the code nqpc#3 looks like the easier change. Then once that's integrated, keeping the rawExpanded* methods doesn't have the same importance, which would lead me to 3. | 07:57 |
| flypig | But I can also see the value in 2. | 07:57 |
| flypig | So, I think I'd favour option 3, but I'd sequence it as nqpc#3 first, followed by mkcal#2 afterwards, to make the discussion easier. That's just my opinion. | 07:59 |
| flypig | I can add a comment to the PRs and encourage chriadm and pvuorela to give their thoughts. | 08:00 |
| dcaliste | Yes, let's do like that, thank you. | 08:01 |
| flypig | But the change seems good to me. It's just one of those changes where potential consequences are hard to judge (for me at least), because again it potentially touches many things. | 08:01 |
| flypig | But, if you're happy with this as a path forwards then we can do that. | 08:02 |
| dcaliste | Indeed, I agree that it has a good potential for trouble this one... But if it succeeds, it will clean the code in a nice way, boh in mKCal, but also in the sync plugin, where we can remove half of the boiling plate that add or remove EXDATEs. | 08:04 |
| flypig | Yes inedeed, that'll be really nice from a code point of view, but also make things easier in the future by matching with the standard approach for exceptions. It's really nice. | 08:05 |
| flypig | Are these the only two PRs needed for the EXDATE changes right now? Other than the follow-up clean-up changes to the sync plugins. | 08:06 |
| dcaliste | Yes, there is no cleaning PRs yet submitted in the sync plugins. I was waiting for the changes in mKCal and or nqpc to settle down first. | 08:07 |
| flypig | Yes, that makes sense. | 08:08 |
| flypig | Does that cover what needs to be discussed for the timebeing in relation to your EXDATE PRs? | 08:11 |
| dcaliste | Yes, thank you for the feedback on these PRs. We can continue the discussion and decide after my vacations with chriadam also. | 08:12 |
| flypig | Okay, great. Thank you. So, I have a summary of actions from what we discussed so far: | 08:14 |
| flypig | 1. Organiser attendees: flypig/pvuorela to comment, chriadm to merge | 08:14 |
| flypig | 2. Alarm duration: chriadm to merge | 08:14 |
| flypig | 3. EXDATE changes: looks good, flypig to comment about removing rawExpanded*() completely. | 08:14 |
| flypig | 4. Create bugzilla reference for upstream syncing of kf5-calendarcore | 08:14 |
| flypig | We didn't discuss 4, but hopefully it's clear (that's a thing I need to do). | 08:14 |
| flypig | Did I mess anything? Sorry if it's a bit reductionist. | 08:15 |
| dcaliste | Yes, it's clear. When you have a bug number, I can reword the commit to add the Contributes to JB# mention. | 08:15 |
| dcaliste | No that's a good summary. | 08:15 |
| flypig | Thank you. You're always working on many interesting things, but it's hard for me to keep it all in my mind without simplifying. | 08:16 |
| flypig | You also have several PRs in the list unrelated to these. Are these things we should discuss too? | 08:17 |
| dcaliste | Not necessary. The two remaining PRs are dealing with modification to allow QML bindings to sync logs. | 08:18 |
| dcaliste | They require in-depth review and discussion. I think we should dedicate one meeting for it. | 08:18 |
| flypig | That's a topic I'm particularly interested in, but I've not looked at them so I agree with your proposal! | 08:19 |
| flypig | If there aren't other technical matters to discuss, can I also think you for your excellent article. Really nice, and I'm looking forward to it going out. | 08:20 |
| flypig | *thank* you for. | 08:21 |
| flypig | Oh, sorry, I do also have one other issue I was hoping to discuss with you: pvuorela was asking about syncing qmf with upstream. Is this something that you've looked at? | 08:23 |
| flypig | He was thinking that it would be better to sync before integrating https://github.com/sailfishos/messagingframework/pull/1 and also wondering whether you yourself had thoughts on that PR. | 08:24 |
| dcaliste | I created in git.sailfishos.org a MR to be in line with upstream. I still need to migrate it to github. | 08:25 |
| flypig | Okay, I see it: https://git.sailfishos.org/mer-core/messagingframework/merge_requests/59 | 08:26 |
| flypig | It looks like there's still a bit more discussion with chriadm to resolve before it can be merged. How close would you say it is? | 08:28 |
| dcaliste | I need to correct one or two things with respect to chriadam analysis. So maybe not before the end of July. | 08:30 |
| flypig | Okay, that's useful to know, just to have an idea. Thank you. I think it's likely qmf#1 will need to be merged in before this, but that will make things a little harder for you I'm afraid. | 08:31 |
| dcaliste | Not a big issue, don't worry. | 08:34 |
| dcaliste | The additional patch doesn't look too long. It will not be an issue. | 08:35 |
| flypig | That's good to hear. Thank you. | 08:36 |
| flypig | Please feel free to comment on the additional patch, as you prefer. | 08:36 |
| flypig | That was the last point I was hoping to discuss with you I think. | 08:36 |
| dcaliste | Ok, thank you. | 08:37 |
| flypig | Was there anything else you wanted to discuss? | 08:39 |
| dcaliste | No that's all. Thanks once again for the discussion. | 08:40 |
| dcaliste | I think I proposed to chriadam to resume July 20th. | 08:40 |
| flypig | Then I wish you a very good vacation, until then, and hopefully we can continue to progress things in the meantime by merging your PRs. | 08:42 |
| flypig | Thank you for all of your contributions of course. | 08:42 |
| rinigus | volcanosweetroll: thanks! I had to specify better: looking for new email notification pattern with led. solid blue should correspond to new message; solid green to missed call - those work for me as expected. | 08:58 |
| rinigus | but slowly blinking white led is replaced with solid white for new email for me. | 08:59 |
| rinigus | except when on charger - then new email triggers blinking white led. | 08:59 |
| rinigus | question is whether it is the same for xperia 10ii (aosp10 based) or not :) | 08:59 |
| kimmoli | breathing/blink is done by sw unless hw supports it, and correctly configured all around | 09:44 |
| kimmoli | and sw breathing works only when active (on charger) | 09:45 |
| kimmoli | check the sys class leds is there blink? | 09:46 |
| kimmoli | i have 10ii but it is at home | 09:46 |
| rinigus | kimmoli: it has worked with aosp9-based port on the same hw. csd is also able to blink/breath white led. | 09:51 |
| rinigus | as for /sys/class/leds, I have blue green led:flash_0 led:flash_1 led:switch_0 led:switch_2 led:torch_0 led:torch_1 mmc0:: red vibrator | 09:52 |
| mighty17[m] | Hello, any new updates in the community meetings? | 11:31 |
| Nico[i] | mighty17: Logs were posted in the forum, if you want to read up, including a summary | 12:23 |
| mighty17[m] | cool, thanks | 13:25 |
| mighty17[m] | any good games in sfos? :D | 13:45 |
| Nico[i] | Heebo | 13:49 |
| Nico[i] | Or what it was called :3 | 13:49 |
| mighty17[m] | `Heebo - Google Fonts` :P | 13:49 |
| Ingvix | I like sudoku, machines vs. machines and patience deck | 13:50 |
| mighty17[m] | umm how do i use spotify (not premium) | 18:16 |
| *** attah_ is now known as attah | 22:08 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!