| rinigus | HengYeDev: chum is designed for publishing. chum:testing is for last check before publishing to see if it compiles at all covered versions and doesn't break anything else. | 06:14 |
|---|---|---|
| rinigus | For development, use your home project at OBS. That's what is it for | 06:15 |
| rinigus | You could also have home subprojects to organize your work. Such as putting dependencies and apps together | 06:16 |
| dcaliste | Hello chriadam, sorry to be late today... | 07:12 |
| chriadam | hi dcaliste, no problem at all! I am sorry for missing the meeting last week - I have no excuse, I simply forgot | 07:13 |
| chriadam | Pekka is back in the office now, I have asked him to join, but he's still setting up the new oftc connection etc | 07:13 |
| dcaliste | No problem of course for last week.. | 07:14 |
| dcaliste | Good morning pvuorela. | 07:14 |
| pvuorela | good morning! | 07:14 |
| chriadam | great that you could join pvuorela | 07:14 |
| dcaliste | Indeed, thank you. | 07:15 |
| chriadam | so, quick summary of my understanding of PRs which are "outstanding" from a while ago: | 07:15 |
| chriadam | - buteo sync log ones: - but cannot merge just yet, some comments from Pekka. | 07:15 |
| chriadam | - https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/2 | 07:15 |
| chriadam | - https://github.com/sailfishos/buteo-syncfw/pull/1 | 07:15 |
| chriadam | - organizer attendees: - Pekka is still uneasy about this one | 07:15 |
| chriadam | - https://github.com/sailfishos/mkcal/pull/1 | 07:15 |
| chriadam | - exdate changes: - Pekka wants a change made (remove the API if we don't use it) | 07:15 |
| chriadam | - https://github.com/sailfishos/mkcal/pull/2 | 07:15 |
| chriadam | - https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/3 | 07:15 |
| pvuorela | sure. though have to confess i didn't have yet time to check the PR side much for the past month :) | 07:16 |
| chriadam | then there is a QMF change which I think is good now (thanks for fixing the unit test issues there, dcaliste) | 07:16 |
| pvuorela | good list there, thanks | 07:16 |
| chriadam | then, I saw that there are some new PRs in mkcal and also jolla-calendar | 07:16 |
| chriadam | which I haven't had time to check yet | 07:16 |
| dcaliste | Thank you chriadam for the summary. I added indeed some new ones last week. | 07:17 |
| chriadam | finally, dcaliste has created a harbour app to test the buteo sync log things, which I need to mention to Joona | 07:17 |
| dcaliste | We can quickly review the old and maybe the new today. So you can have an overview. | 07:17 |
| chriadam | that'd be great, where would you like to start from? | 07:17 |
| dcaliste | Yes, the harbour app has the purpose to demonstrate the capabilities and evaluate the advantage of having this kind of logging UI. | 07:19 |
| dcaliste | We can start from your list actually. | 07:19 |
| dcaliste | The nemo-qml-plugin-calendar #2 is adding a list model, like the agenda one, but for a list of given incidence instance. | 07:20 |
| dcaliste | This list is given as a QStringList and can handle natively the single events and the exception of recurring ones. | 07:21 |
| chriadam | so I guess the first one to look at is the buteo-syncfw one, actually | 07:21 |
| *** karry_ is now known as karry | 07:21 | |
| chriadam | pvuorela: you had some comments there, which I think dcaliste has fixed or followed up on. | 07:21 |
| dcaliste | The buteo-syncfw is indeed the main part of it. | 07:21 |
| chriadam | there is an open question about API break for days, I think? | 07:22 |
| dcaliste | It contains new QML bindings for Profile and SyncProfile and a list model also to expose logs from several profiles or from a single one. | 07:22 |
| dcaliste | Indeed, pvuorela suggested to change one API about set of days to avoid having to create specific accessors for QML. | 07:23 |
| dcaliste | I've left it like that with two accessors at the moment, because I was not sure of the direction pvuorela suggested: API break or not. | 07:23 |
| dcaliste | I commented in the PR. | 07:24 |
| chriadam | Yep. Once that buteo-syncfw one is merged, I think that https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/2 can be merged, I don't think anyone has raised any issues with it. | 07:25 |
| chriadam | so it's more about getting the buteo one right | 07:25 |
| pvuorela | don't remember quickly was i thinking of replacing also the old DaySet getter but perhaps it was not much used and could also just have the flag thing. | 07:26 |
| chriadam | pvuorela: more generally, do you have an issue with us merging these "enabler" things, even though we don't (yet) have UI in our settings app which uses it? | 07:28 |
| chriadam | I personally think it's a step in the direction to getting there, especially with dcaliste's demo app, reducing friction / effort required to get there... so I think it's a good thing ot merge them | 07:28 |
| chriadam | but maybe I'm wrong | 07:28 |
| dcaliste | pvuorela, indeed, I copied in comment https://github.com/sailfishos/buteo-syncfw/pull/1#discussion_r681506749 how it is done in nemo-qml-plugin-calendar and we can transition to this kind of API in Buteo also. If I have your green flag to remove the DaySet typedef and getter, I can make a separe PR with this change first. It may have some consequences in sailfish-components-accounts. | 07:30 |
| pvuorela | chriadam: in a way i like the less buteo has, but didn't seem too bad having these. | 07:30 |
| dcaliste | pvuorela, it is adding QML bindings in a separated lib. The only burden it is adding would be its maintainance. It is making an internal change though to enable simple QML bindings : the SyncLog instead of being a pointer to the object is now an instance which is then passed by copy instead of being passed by pointer value. | 07:33 |
| pvuorela | dcaliste: indeed components-accounts has setRushDays() usage, converting flag values to qset :) | 07:34 |
| pvuorela | dcaliste: well, one option could be to just add the new thing while still keeping the old. | 07:35 |
| dcaliste | Well, this one I can create a PR also, I've access to it. Hopefully there is not much more usage of it somewhere I don't know about... | 07:35 |
| dcaliste | As you prefer. at the moment I can change the current buteo PR to expose flags to QML instead of a QVariantList. | 07:36 |
| pvuorela | started grep to find out if there's anything else using the rush day thing | 07:36 |
| pvuorela | if only components-accounts then could just migrate all to the flag api | 07:37 |
| chriadam | yeah. | 07:39 |
| chriadam | ok, shall we move onto the next old one? https://github.com/sailfishos/mkcal/pull/1 dcaliste has added a comprehensive explanation to that one | 07:39 |
| dcaliste | Ok, I'm find like that. If it's only these two (or some other repos I have access to), I can create separated PRs for them a change this API and rebase the buteo QML one on top. | 07:39 |
| dcaliste | chriadam, about mkcal#1, indeed, I tried to find reasons to support the PR. Since we have broken schema and already partial data for existing incidences, we need to choose one convention or the other to restore missing information. | 07:42 |
| dcaliste | Even when doing a migration, we'll have to choose a convention or the other. | 07:43 |
| dcaliste | I think the convention not including the organizer would save code actually in various sync plugins, without breaking things. But there's always a risk when changing things… | 07:44 |
| chriadam | I think we should just do it, personally.. | 07:45 |
| chriadam | but maybe pvuorela could check your comment in that PR and then respond in the PR, and we can go from there | 07:45 |
| dcaliste | I agree. | 07:46 |
| pvuorela | i'd like to push a bit for that schema change. once we have a mechanism for doing it we can start using it on other places where the current schema is just broken. | 07:46 |
| pvuorela | it's been always adding a bit more special casing because it's been convenient. | 07:47 |
| pvuorela | btw, didn't find other setRushDays() outside buteo-syncfw except that one component-accounts case. | 07:48 |
| dcaliste | Ok, for the DaySet deprecation, I'm going to prepare two PR to address the migration. | 07:49 |
| dcaliste | About the migration issue of mKCal database, as I mentioned at the end of my comment in the mKCal PR, we need to choose a convention on how to restore lost information. | 07:49 |
| dcaliste | The current convention is not convenient because it represent only a small minority of the use cases, while the other convention bring by the PR is making the majority the normal cases &allowing to remove bloat code from buteo sync plugins. | 07:51 |
| dcaliste | I mean, we need to choose the convention *even_* if we do a migration. | 07:51 |
| pvuorela | at least for one we should be able to get rid the migration code or handling old style data after a stop release. | 07:52 |
| pvuorela | so any bloat doesn't need to stay there forever. | 07:52 |
| dcaliste | My point is that when we will handle the old style data, if we keep the current convention that is always adding the organizer as an attendee, then we will need to keep the bloat code. | 07:54 |
| dcaliste | Let me explain : | 07:54 |
| dcaliste | - organizer as an attendee is a special case where you want the organizer to also receive an invitation. | 07:55 |
| dcaliste | - organizer *not* as an attendee is the most current case where the organizer can participate to the meeting, but won't be sent an invitiation. | 07:55 |
| dcaliste | Currently in the sync plugin, to avoid being in the first case and receive a lot of bug report saying that one receives an invitation for a meeting one has scheduled, we *always* remove the organizer from the attendee list. | 07:56 |
| pvuorela | if we can rely that everything uses it one way, guess the migration could change the convention. | 07:56 |
| dcaliste | Ineed ;) And I'm even proposing to change the convention now, so we can test its effect before the migration ! | 07:57 |
| dcaliste | All that being said, I'm fine if you prefer to delay the convention change for the migration, as long as we don't keep the current convention sooner or later. | 08:00 |
| chriadam | maybe we can continue that discussion in the PR | 08:01 |
| chriadam | can we discuss this one next? https://github.com/sailfishos/mkcal/pull/2 | 08:01 |
| chriadam | I think that one is in good state now, if pvuorela agrees? | 08:01 |
| pvuorela | seemed all good. will check in more detail later. | 08:02 |
| chriadam | thanks | 08:02 |
| chriadam | and related: https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/3 | 08:02 |
| dcaliste | Thanks, as I mentioned, this is linked to nemo-qml-plugin-calendar#3 also. | 08:03 |
| dcaliste | ;) | 08:03 |
| dcaliste | In this #3 PR, I'm removing the call to expandedRawEvent() to directly use the OccurrenceIterator from upstream. | 08:03 |
| chriadam | finally, from the old PR list, there's https://github.com/sailfishos/messagingframework/pull/2 | 08:04 |
| chriadam | which I think is good now | 08:04 |
| chriadam | dcaliste: do you quickly want to describe the new PRs? mkcal + jolla-calendar? | 08:06 |
| dcaliste | Just to mention an old one that we seem to agree on : https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/1 | 08:07 |
| dcaliste | About the new ones, let's start with mKCal one : https://github.com/sailfishos/mkcal/pull/4 | 08:08 |
| chriadam | oh I forgot that caldav one, let me add it to my list | 08:09 |
| chriadam | ty | 08:09 |
| dcaliste | I noticed I created an issue with a change upstream I pushed that is calling clearNotebookAssociation() in the close() method of the MemoryCalendar. | 08:09 |
| dcaliste | I still think this was the right thing to do upstream, but it has the side effect of breaking my loose implementation of deleteAllIncidence() in ExtendedCalendar. | 08:10 |
| dcaliste | The later is not an API inherited from KCalendarCore, it's a specific API from mKCal. | 08:10 |
| dcaliste | The idea was not to loop over all incidences and delete them one by one. | 08:11 |
| dcaliste | To do this quickly it is calling close() inside, which does the job of clearing all internal tables. | 08:11 |
| dcaliste | But also the notebook association one now :( | 08:11 |
| dcaliste | And in mKCal, now that we're verifying that all incidence belongs to a notebook, the deletion are actually failing. | 08:12 |
| dcaliste | The fix is simple in my opinion : don't validate the incidence on deletion, but only when adding one in the db. | 08:12 |
| dcaliste | That's the first commit of mKCal#4. | 08:13 |
| dcaliste | The second commit is a patch for a deficiency of some web resource, providing iCal data without UIDs for events… | 08:13 |
| dcaliste | At the moment, mKCal is generating a UID on database save is the UID doesnot exist. I'm proposing in addition to generate one on calendar insertion. | 08:14 |
| chriadam | I'm a bit worried about pushing to 4.2.0 | 08:16 |
| dcaliste | Like that when parsing an iCal resource, we avoid to insert in hashtables incidence with null UIDs and ending up in one incidence only.. | 08:18 |
| dcaliste | First commit is fixing a blocking issue for webcal in every case. | 08:18 |
| dcaliste | I can separate the two commits to help. | 08:19 |
| chriadam | pvuorela: what are your thoughts? | 08:21 |
| chriadam | dcaliste: did something regress in 4.2.0 due to the upstream changes? | 08:21 |
| chriadam | or am I misunderstanding? | 08:21 |
| pvuorela | also not sure about 4.2.0 at this point. though not checking notebook on deletion wouldn't sound much. | 08:21 |
| dcaliste | chriadam: yes, webcal is broken in 4.2.0 because of this change I pushed upstream to clear notebook assication in memorycalendar in close(). | 08:21 |
| dcaliste | Yes, the change to fix this is just to validate on insertion and modification only. Not on deletion. Before a recent commit we were not validating at all anyway. | 08:22 |
| dcaliste | I can separate the two commits to make this clear. | 08:23 |
| chriadam | well, I will discuss with pvuorela more about this. 4.2.0 is ... getting pretty late | 08:25 |
| dcaliste | Ok, thanks. | 08:25 |
| chriadam | thank you, of course | 08:26 |
| chriadam | and finally, the jolla-calendar one? | 08:26 |
| dcaliste | Before, I still have : | 08:26 |
| dcaliste | https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/2 | 08:26 |
| dcaliste | Which is pending on acceptance of nemo-qml-plugin-calendar#3. | 08:27 |
| dcaliste | The one that use the upstream OccurrenceIterator instead of mKCal call to expand events. | 08:27 |
| dcaliste | There is this one also for Google sync : https://github.com/sailfishos/buteo-sync-plugins-social/pull/1 | 08:28 |
| dcaliste | The two PRs in sync plugins remove code that were adding exception recurrenceId as EXDATE values. | 08:28 |
| dcaliste | After the nemo-qml-plugin PR, it is not required anymore since the iterator is removing the exception by itself when listing events. | 08:29 |
| chriadam | Thank you very much | 08:33 |
| chriadam | I've added those all to my list | 08:33 |
| chriadam | finally the jolla-calendar one? | 08:33 |
| dcaliste | A tniy one just before ;) https://github.com/sailfishos/buteo-sync-plugin-webcal/pull/1 | 08:33 |
| dcaliste | Nothing very interesting, but related to the logging UI. | 08:34 |
| dcaliste | There is no point in using the notebook UID there. | 08:34 |
| dcaliste | About jolla-calendar, I've got two: | 08:35 |
| dcaliste | - #304 is a bug fix. | 08:35 |
| dcaliste | - #303 is a proposition to move some part from the app to the components. | 08:36 |
| dcaliste | The former is about the possibility to change the event.uniqueId value of the EventViewPage.qml, as done for instance by the DBus viewEvent() method. | 08:36 |
| dcaliste | When doing so, the event.data is changed to null by nemo-qml-plugin-calendar, during the time of the fetch in the database. | 08:37 |
| dcaliste | This is confusing the signal handler in the EventViewPage that react on the value change to null, making it think that the event has been deleted and thus popping the page. | 08:38 |
| chriadam | right | 08:39 |
| chriadam | transientily | 08:39 |
| chriadam | I see | 08:39 |
| dcaliste | My proposition is to drop the page popping completely. There is a placeholder for the case that the event is null and will stay null because of database error. | 08:39 |
| chriadam | pvuorela: ^ | 08:40 |
| dcaliste | So in the case the user is viewing the page and the event is deleted because of sync action or a DBus call to delete the event from CLI or whatever, instead of popping the page, the placeholder saying that the event daoenot exist anymore will be displayed. | 08:40 |
| dcaliste | And this will fix the accidental popping on transient change. | 08:41 |
| dcaliste | If you have a better idea, it's fine also. | 08:41 |
| chriadam | I don't know that code well enough. I wonder what reason the page pop behaviour was there for | 08:42 |
| chriadam | I mean, is there some flow where that one is necessary to handle something properly (e.g. deleting an existing event manually from UI, or?) | 08:42 |
| dcaliste | From the commit message it was to handle remote deletion case. | 08:42 |
| chriadam | remote deletion.. | 08:42 |
| chriadam | i.e. this case | 08:42 |
| chriadam | sync | 08:42 |
| chriadam | yeah, showing the doesn't exist case seems fine, rather than popping, I think | 08:43 |
| dcaliste | In my opinion it's better to display a placeholder explaining what happen than to pop the page without warning while viewing it. | 08:43 |
| chriadam | yeah | 08:43 |
| chriadam | I agree, actually | 08:43 |
| chriadam | and the 303 one - moving some part to components, is that to enable the buteo sync log view thing? | 08:44 |
| dcaliste | Yes, it's to avoid to copy QML parts or to reinvent a UI to display a list of events, like in the month view. | 08:45 |
| chriadam | again, would be good if pvuorela could take a look at that one, also, and maybe jpetrell | 08:45 |
| chriadam | conceptually, I think it's a good idea | 08:46 |
| dcaliste | It's not mandatory of course, it will depend on the final design of how to view logs, but it makes sense in my opinion since nemo-qml-plugin-calendar is exposing listmodel of events to provide a component delegate to display element of these list. | 08:46 |
| chriadam | I worry that we might not want to provide stability guarantees if third parties can use the components, but maybe we don't allow those for harbour currently anyway | 08:46 |
| dcaliste | Indeed, it's not for harbour ;) | 08:46 |
| chriadam | great | 08:46 |
| chriadam | then I see no problem, personally | 08:46 |
| chriadam | ok, well, you've done a huge amount of work - thank you very much | 08:47 |
| dcaliste | I named the demo app like that, but it's using a lot of things that are not allowed at the moment. | 08:47 |
| chriadam | we need to start work on our side, reviewing and merging and progressing things here. | 08:47 |
| dcaliste | Like sailjail to access the privileged calendar data. | 08:47 |
| chriadam | I hope that we will make good progress this week, now that most people are back from vacations etc | 08:47 |
| chriadam | ah yes, sailjail etc.. | 08:47 |
| chriadam | pvuorela: flypig: dcaliste: any final things to cover before we end the meeting? | 08:48 |
| dcaliste | nothing additional from my side, beside a huge thanks to all of you for reviews and discussions. | 08:48 |
| chriadam | :-) well, let's end the meeting for tonight. thanks again! I'll create summary internally and we'll try to get started on the reviews etc asap | 08:50 |
| pvuorela | i'm good. thanks! | 08:50 |
| * chriadam -> away, gnight | 08:50 | |
| dcaliste | Good night chriadam. | 08:50 |
| dcaliste | Thank you pvuorela, have a nice day. | 08:51 |
| *** teve_ is now known as teve | 12:11 | |
| rinigus | poetaster, piggz: -simplecrop turned out to still have some libs in the source as a part of PIL. we would have to get rid of those, ideally by packaging PIL separately | 12:21 |
| rinigus | I wonder whether anyone has seen Fedora or Suse packages for PIL? couldn't find them during short search at fedora sources | 12:22 |
| rinigus | piggz: I have disabled failing builds in chum:testing for those inserted SFOS versions. would have to do the same when promoted to chum | 12:26 |
| bionade24__ | Hello, I get “Your device is corrupt. It can’t be trusted and won’t boot.” after reflashing my XA2. | 12:28 |
| bionade24__ | How can I fix this? | 12:28 |
| ilpianista | <attah> "ilpianista: about that nice..." <- sorry for the late reply. I'm missing a GitLab, Lemmy, syncthing, wireguard client | 12:45 |
| ilpianista | I'm writing the syncthing client myself, but unfortunately my phone doesn't charge anymore. sigh. | 12:46 |
| rinigus | poetaster: moving discussion over here... can you send link to FSO thread? | 13:08 |
| HengYeDev[m]1 | QFilterProxyModel is causing SlicaListView to scroll to the top every time an item is updated. Is there a way to avoid this behavior? | 14:20 |
| Nico | HengYeDev[m]1: Yes, set the currentIndex explicitly | 14:22 |
| Nico | https://nheko.im/nheko-reborn/konheko/-/blob/master/qml/pages/MainView.qml#L34 | 14:23 |
| HengYeDev[m]1 | hrmm..same is still happening for me. on 3.4 emulator | 14:25 |
| fridlmue | rinigus: arent that one the 'PIL' packages (since some time pillow?) | 14:25 |
| fridlmue | https://build.opensuse.org/package/show/openSUSE:Factory/python-Pillow | 14:25 |
| fridlmue | (btw, please ping me when someone converted sucessfully a suse python spec file into one fitting the sfos obs needs! :-) ) | 14:26 |
| rinigus | fridlmue: maybe fedora packaging guide for python libs makes more sense to use | 14:28 |
| rinigus | see https://forum.sailfishos.org/t/application-sdk-bash-sdk-deploy-rpm-command-not-found/5743/40 | 14:28 |
| fridlmue | rinigus: Ah, ok. First of all I just wanted to share the Link you asked for (the pil pakcages) :-) But I'll follow that thread and observe where poetasters research lead. ;-) | 14:36 |
| attah | ilpianista: sounds as complete as i thought then... but i'm probably blind to many use cases. Sounds like you picked the most interesting one | 18:15 |
| attah | what phone might that be? | 18:15 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!