Tuesday, 2021-06-29

rinigustanriol:: 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 why05:48
rinigusIf someone with Xperia 10ii (aosp10 based port) can also confirm slow blinking of led on notification that would be helpful05:50
volcanosweetroll[m]I have Xperia 10ii with version and the notification led is a continuous blue color and not blinking06:51
dcalisteGood morning flypig, how are you ?06:56
flypigGood morning dcaliste. I'm very well thank you. And you? Preparing for your holidays I hope?06:56
dcalistePartially, indeed, but still at work for this week.06:58
dcalisteWould you mind discussing a bit the EXDATE mKCal specificity this morning, or do you prefer to wait for chriadam ?06:59
flypigI'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
flypigCan you point me at the relevant PR please?07:00
dcalisteOk, let's start with the broader look, https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Adcaliste+archived%3Afalse+org%3Asailfishos07:00
dcaliste- https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Adcaliste+archived%3Afalse+org%3Asailfishos07:01
dcalistesorry wrong link on first point...07:01
dcalisteso, 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
flypigOkay, I remember us discussing this previously. Were there already some PRs merged related to this?07:03
dcalisteI 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
flypigWas this one of the ones chriadam suggested he might merge?07:04
dcalisteKeeping the old reversing convention code should still work by doing nothing. Thus there is no need to a schedule transition for this.07:04
dcalisteI think he will merge this PR#1 soon indeed.07:04
flypigSo, the plan will be to merge this, following which some new clean-up PRs will follow.07:05
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
dcalisteI think chriadam also agreed on this one.07:08
flypigOkay. So for the mkcal#1 it looks like it could maybe do with some confirmation from Pekka or me.07:10
flypigBut chriadm already seems comfortable to merge nqpc#1.07:12
dcalisteSure, if you or pvuorela have time to give a look that's always better.07:13
dcalistenqpc ? Did you mean b uteo-sync-plugin-caldav ?07:13
flypigSorry, yes, that's what I meant: bspc#107:16
flypigchriadm mentioned that there were two PRs he was planning to merge. Presumably those two then.07:17
flypigI 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
dcalisteYeh, 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/107:20
dcalisteIt's a maintainance PR, updating upstream now that they are creating a pkgconfig. I think pvuorela should give his opinion on it.07:21
dcalisteSorry, not updating upstream, but updating *from* upstream !07:21
flypigOkay, makes sense :) So, there were a few changes to the patches. Is there anything substantive in there, or is it mostly rebasing?07:22
flypigOne patch removed.07:22
flypigThe other related to unit tests?07:23
dcalisteExact, 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
dcalisteThe removed patch is the purpose of this PR : upstream is now providing a pkgconfig file. So our patch is not needed anymore.07:24
flypigThat 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
dcalisteGreat thank you.07:27
flypigI've also pinged pvurela to ask for him to take a look to.07:27
dcalisteThanks. The two last PRs come together: https://github.com/sailfishos/mkcal/pull/2 and https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/307: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
dcalisteThe two PRs in mKCal and nemo-qml-plugin-calendar deal with the EXDATE handling in mKCal for exceptions.07:29
dcalisteKCalendarCore and the RFC are not enforcing exceptions to be in the EXDATE list of the parent.07:30
dcalisteBut 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
dcalisteI'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
dcalisteThe latter requires the EXDATE to contain the exception start date time to filter them out.07:32
dcalisteWhile the upstream iterator is calling instances() on the calendar to remove the exception occurrences from the parent occurrences.07:33
dcalisteI'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
dcalisteSince the iterator and rawExpandedEvents() don't use the same API, I needed to deprecate rawExapandedEvents() and create a rawExandedIncidences() instead.07:34
flypigI 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
flypigBut I don't recall looking at the mkcal PR in any detail yet.07:35
dcalisteIndeed, you were partially involved in this discussion previously.07:35
flypigThere was the issue of multiple exceptions for the same time.07:35
flypigLooking at the PR, you already made changes to address this.07:36
dcalisteExact, I added the instances() call there to recover the previous behaviour.07:36
flypigCan you explain to me about the retention of rawExpandedEvents() please.07:37
dcalisteSorry, what do you mean by retention ?07:37
flypigAfter MR#3 has been merged, would the plan be to remove rawExpandedEvents()?07:38
dcalisteThat something I would like to discuss in the regard of nemo-qml-plugin-calendar#3.07:39
dcalisteAs far as I know (and that should be checked carefully), this nemo plugin is the sole user of rawExpandedEvents().07:39
flypigWould you remove both rawExpandedEvents() *and* rawExpandedIncidences()?07:40
dcalisteI would be in favor to remove it completely actually and replace it with upstream OccurrenceIterator directly.07:40
dcalisteThere is no need in my opinion to keep a thin wrapper in mKCal that just create a list from the iterator.07:40
dcalisteBut that's open to discussion of course.07:41
flypigTo what extent is nqpc#3 dependent on mkcal#2?07:42
dcalisteActually, it is not.07:43
dcalisteUsing 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
dcalisteBut then mkcal#2 is bringing some additional changes in dissociateSingleOccurrence() not to add anymore the exception as EXDATE.07:44
flypigSorry, 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
dcalistethe 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
dcalisteIf you remove the call in nqpc, you don't need to add exception as EXDATE when you dissociate an occurrence.07:47
flypigSo, if mqpc#3 were merged, and assuming it's the only consumer of rawExpanded*, then could mkcal#2 be streamlined?07:47
flypigWould this be desirable?07:48
dcalisteWhat do you mean streamlined ?07:48
flypigIf 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
dcalisteI 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
dcalisteCurrently, nqpc#3 is doing this, but mkcal#2 is not yet removing the functions from the API.07:53
dcalisteI'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
dcalisteI 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
flypigWell, 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
flypigBut I can also see the value in 2.07:57
flypigSo, 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
flypigI can add a comment to the PRs and encourage chriadm and pvuorela to give their thoughts.08:00
dcalisteYes, let's do like that, thank you.08:01
flypigBut 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
flypigBut, if you're happy with this as a path forwards then we can do that.08:02
dcalisteIndeed, 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
flypigYes 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
flypigAre 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
dcalisteYes, 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
flypigYes, that makes sense.08:08
flypigDoes that cover what needs to be discussed for the timebeing in relation to your EXDATE PRs?08:11
dcalisteYes, thank you for the feedback on these PRs. We can continue the discussion and decide after my vacations with chriadam also.08:12
flypigOkay, great. Thank you. So, I have a summary of actions from what we discussed so far:08:14
flypig1. Organiser attendees: flypig/pvuorela to comment, chriadm to merge08:14
flypig2. Alarm duration: chriadm to merge08:14
flypig3. EXDATE changes: looks good, flypig to comment about removing rawExpanded*() completely.08:14
flypig4. Create bugzilla reference for upstream syncing of kf5-calendarcore08:14
flypigWe didn't discuss 4, but hopefully it's clear (that's a thing I need to do).08:14
flypigDid I mess anything? Sorry if it's a bit reductionist.08:15
dcalisteYes, it's clear. When you have a bug number, I can reword the commit to add the Contributes to JB# mention.08:15
dcalisteNo that's a good summary.08:15
flypigThank 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
flypigYou also have several PRs in the list unrelated to these. Are these things we should discuss too?08:17
dcalisteNot necessary. The two remaining PRs are dealing with modification to allow QML bindings to sync logs.08:18
dcalisteThey require in-depth review and discussion. I think we should dedicate one meeting for it.08:18
flypigThat's a topic I'm particularly interested in, but I've not looked at them so I agree with your proposal!08:19
flypigIf 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
flypigOh, 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
flypigHe 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
dcalisteI created in git.sailfishos.org a MR to be in line with upstream. I still need to migrate it to github.08:25
flypigOkay, I see it: https://git.sailfishos.org/mer-core/messagingframework/merge_requests/5908:26
flypigIt 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
dcalisteI need to correct one or two things with respect to chriadam analysis. So maybe not before the end of July.08:30
flypigOkay, 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
dcalisteNot a big issue, don't worry.08:34
dcalisteThe additional patch doesn't look too long. It will not be an issue.08:35
flypigThat's good to hear. Thank you.08:36
flypigPlease feel free to comment on the additional patch, as you prefer.08:36
flypigThat was the last point I was hoping to discuss with you I think.08:36
dcalisteOk, thank you.08:37
flypigWas there anything else you wanted to discuss?08:39
dcalisteNo that's all. Thanks once again for the discussion.08:40
dcalisteI think I proposed to chriadam to resume July 20th.08:40
flypigThen 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
flypigThank you for all of your contributions of course.08:42
rinigusvolcanosweetroll: 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
rinigusbut slowly blinking white led is replaced with solid white for new email for me.08:59
rinigusexcept when on charger - then new email triggers blinking white led.08:59
rinigusquestion is whether it is the same for xperia 10ii (aosp10 based) or not :)08:59
kimmolibreathing/blink is done by sw unless hw supports it, and correctly configured all around09:44
kimmoliand sw breathing works only when active (on charger)09:45
kimmolicheck the sys class leds is there blink?09:46
kimmolii have 10ii but it is at home09:46
riniguskimmoli: it has worked with aosp9-based port on the same hw. csd is also able to blink/breath white led.09:51
rinigusas 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 vibrator09: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 summary12:23
mighty17[m]cool, thanks13:25
mighty17[m]any good games in sfos? :D13:45
Nico[i]Or what it was called :313:49
mighty17[m]`Heebo - Google Fonts` :P13:49
IngvixI like sudoku, machines vs. machines and patience deck13:50
mighty17[m]umm how do i use spotify (not premium)18:16
*** attah_ is now known as attah22:08

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