Tuesday, 2021-08-10

rinigusHengYeDev: 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
rinigusFor development, use your home project at OBS. That's what is it for06:15
rinigusYou could also have home subprojects to organize your work. Such as putting dependencies and apps together06:16
dcalisteHello chriadam, sorry to be late today...07:12
chriadamhi dcaliste, no problem at all!  I am sorry for missing the meeting last week - I have no excuse, I simply forgot07:13
chriadamPekka is back in the office now, I have asked him to join, but he's still setting up the new oftc connection etc07:13
dcalisteNo problem of course for last week..07:14
dcalisteGood morning pvuorela.07:14
pvuorelagood morning!07:14
chriadamgreat that you could join pvuorela07:14
dcalisteIndeed, thank you.07:15
chriadamso, 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/207:15
chriadam        - https://github.com/sailfishos/buteo-syncfw/pull/107:15
chriadam    - organizer attendees: - Pekka is still uneasy about this one07:15
chriadam        - https://github.com/sailfishos/mkcal/pull/107: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/207:15
chriadam        - https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/307:15
pvuorelasure. though have to confess i didn't have yet time to check the PR side much for the past month :)07:16
chriadamthen there is a QMF change which I think is good now (thanks for fixing the unit test issues there, dcaliste)07:16
pvuorelagood list there, thanks07:16
chriadamthen, I saw that there are some new PRs in mkcal and also jolla-calendar07:16
chriadamwhich I haven't had time to check yet07:16
dcalisteThank you chriadam for the summary. I added indeed some new ones last week.07:17
chriadamfinally, dcaliste has created a harbour app to test the buteo sync log things, which I need to mention to Joona07:17
dcalisteWe can quickly review the old and maybe the new today. So you can have an overview.07:17
chriadamthat'd be great, where would you like to start from?07:17
dcalisteYes, the harbour app has the purpose to demonstrate the capabilities and evaluate the advantage of having this kind of logging UI.07:19
dcalisteWe can start from your list actually.07:19
dcalisteThe nemo-qml-plugin-calendar #2 is adding a list model, like the agenda one, but for a list of given incidence instance.07:20
dcalisteThis list is given as a QStringList and can handle natively the single events and the exception of recurring ones.07:21
chriadamso I guess the first one to look at is the buteo-syncfw one, actually07:21
*** karry_ is now known as karry07:21
chriadampvuorela: you had some comments there, which I think dcaliste has fixed or followed up on.07:21
dcalisteThe buteo-syncfw is indeed the main part of it.07:21
chriadamthere is an open question about API break for days, I think?07:22
dcalisteIt 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
dcalisteIndeed, pvuorela suggested to change one API about set of days to avoid having to create specific accessors for QML.07:23
dcalisteI'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
dcalisteI commented in the PR.07:24
chriadamYep.  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
chriadamso it's more about getting the buteo one right07:25
pvuoreladon'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
chriadampvuorela: 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
chriadamI 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 them07:28
chriadambut maybe I'm wrong07:28
dcalistepvuorela, 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
pvuorelachriadam: in a way i like the less buteo has, but didn't seem too bad having these.07:30
dcalistepvuorela, 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
pvuoreladcaliste: indeed components-accounts has setRushDays() usage, converting flag values to qset :)07:34
pvuoreladcaliste: well, one option could be to just add the new thing while still keeping the old.07:35
dcalisteWell, 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
dcalisteAs you prefer. at the moment I can change the current buteo PR to expose flags to QML instead of a QVariantList.07:36
pvuorelastarted grep to find out if there's anything else using the rush day thing07:36
pvuorelaif only components-accounts then could just migrate all to the flag api07:37
chriadamok, shall we move onto the next old one?  https://github.com/sailfishos/mkcal/pull/1 dcaliste has added a comprehensive explanation to that one07:39
dcalisteOk, 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
dcalistechriadam, 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
dcalisteEven when doing a migration, we'll have to choose a convention or the other.07:43
dcalisteI 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
chriadamI think we should just do it, personally..07:45
chriadambut maybe pvuorela could check your comment in that PR and then respond in the PR, and we can go from there07:45
dcalisteI agree.07:46
pvuorelai'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
pvuorelait's been always adding a bit more special casing because it's been convenient.07:47
pvuorelabtw, didn't find other setRushDays() outside buteo-syncfw except that one component-accounts case.07:48
dcalisteOk, for the DaySet deprecation, I'm going to prepare two PR to address the migration.07:49
dcalisteAbout 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
dcalisteThe 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
dcalisteI mean, we need to choose the convention *even_* if we do a migration.07:51
pvuorelaat least for one we should be able to get rid the migration code or handling old style data after a stop release.07:52
pvuorelaso any bloat doesn't need to stay there forever.07:52
dcalisteMy 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
dcalisteLet 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
dcalisteCurrently 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
pvuorelaif we can rely that everything uses it one way, guess the migration could change the convention.07:56
dcalisteIneed ;) And I'm even proposing to change the convention now, so we can test its effect before the migration !07:57
dcalisteAll 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
chriadammaybe we can continue that discussion in the PR08:01
chriadamcan we discuss this one next? https://github.com/sailfishos/mkcal/pull/208:01
chriadamI think that one is in good state now, if pvuorela agrees?08:01
pvuorelaseemed all good. will check in more detail later.08:02
chriadamand related: https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/308:02
dcalisteThanks, as I mentioned, this is linked to nemo-qml-plugin-calendar#3 also.08:03
dcalisteIn this #3 PR, I'm removing the call to expandedRawEvent() to directly use the OccurrenceIterator from upstream.08:03
chriadamfinally, from the old PR list, there's https://github.com/sailfishos/messagingframework/pull/208:04
chriadamwhich I think is good now08:04
chriadamdcaliste: do you quickly want to describe the new PRs?  mkcal + jolla-calendar?08:06
dcalisteJust to mention an old one that we seem to agree on : https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/108:07
dcalisteAbout the new ones, let's start with mKCal one : https://github.com/sailfishos/mkcal/pull/408:08
chriadamoh I forgot that caldav one, let me add it to my list08:09
dcalisteI noticed I created an issue with a change upstream I pushed that is calling clearNotebookAssociation() in the close() method of the MemoryCalendar.08:09
dcalisteI 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
dcalisteThe later is not an API inherited from KCalendarCore, it's a specific API from mKCal.08:10
dcalisteThe idea was not to loop over all incidences and delete them one by one.08:11
dcalisteTo do this quickly it is calling close() inside, which does the job of clearing all internal tables.08:11
dcalisteBut also the notebook association one now :(08:11
dcalisteAnd in mKCal, now that we're verifying that all incidence belongs to a notebook, the deletion are actually failing.08:12
dcalisteThe fix is simple in my opinion : don't validate the incidence on deletion, but only when adding one in the db.08:12
dcalisteThat's the first commit of mKCal#4.08:13
dcalisteThe second commit is a patch for a deficiency of some web resource, providing iCal data without UIDs for events…08:13
dcalisteAt 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
chriadamI'm a bit worried about pushing to 4.2.008:16
dcalisteLike 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
dcalisteFirst commit is fixing a blocking issue for webcal in every case.08:18
dcalisteI can separate the two commits to help.08:19
chriadampvuorela: what are your thoughts?08:21
chriadamdcaliste: did something regress in 4.2.0 due to the upstream changes?08:21
chriadamor am I misunderstanding?08:21
pvuorelaalso not sure about 4.2.0 at this point. though not checking notebook on deletion wouldn't sound much.08:21
dcalistechriadam: 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
dcalisteYes, 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
dcalisteI can separate the two commits to make this clear.08:23
chriadamwell, I will discuss with pvuorela more about this.  4.2.0 is ... getting pretty late08:25
dcalisteOk, thanks.08:25
chriadamthank you, of course08:26
chriadamand finally, the jolla-calendar one?08:26
dcalisteBefore, I still have :08:26
dcalisteWhich is pending on acceptance of nemo-qml-plugin-calendar#3.08:27
dcalisteThe one that use the upstream OccurrenceIterator instead of mKCal call to expand events.08:27
dcalisteThere is this one also for Google sync : https://github.com/sailfishos/buteo-sync-plugins-social/pull/108:28
dcalisteThe two PRs in sync plugins remove code that were adding exception recurrenceId as EXDATE values.08:28
dcalisteAfter the nemo-qml-plugin PR, it is not required anymore since the iterator is removing the exception by itself when listing events.08:29
chriadamThank you very much08:33
chriadamI've added those all to my list08:33
chriadamfinally the jolla-calendar one?08:33
dcalisteA tniy one just before ;) https://github.com/sailfishos/buteo-sync-plugin-webcal/pull/108:33
dcalisteNothing very interesting, but related to the logging UI.08:34
dcalisteThere is no point in using the notebook UID there.08:34
dcalisteAbout 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
dcalisteThe 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
dcalisteWhen 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
dcalisteThis 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
chriadamI see08:39
dcalisteMy 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
chriadampvuorela: ^08:40
dcalisteSo 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
dcalisteAnd this will fix the accidental popping on transient change.08:41
dcalisteIf you have a better idea, it's fine also.08:41
chriadamI don't know that code well enough.  I wonder what reason the page pop behaviour was there for08:42
chriadamI 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
dcalisteFrom the commit message it was to handle remote deletion case.08:42
chriadamremote deletion..08:42
chriadami.e. this case08:42
chriadamyeah, showing the doesn't exist case seems fine, rather than popping, I think08:43
dcalisteIn my opinion it's better to display a placeholder explaining what happen than to pop the page without warning while viewing it.08:43
chriadamI agree, actually08:43
chriadamand the 303 one - moving some part to components, is that to enable the buteo sync log view thing?08:44
dcalisteYes, 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
chriadamagain, would be good if pvuorela could take a look at that one, also, and maybe jpetrell08:45
chriadamconceptually, I think it's a good idea08:46
dcalisteIt'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
chriadamI 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 anyway08:46
dcalisteIndeed, it's not for harbour ;)08:46
chriadamthen I see no problem, personally08:46
chriadamok, well, you've done a huge amount of work - thank you very much08:47
dcalisteI named the demo app like that, but it's using a lot of things that are not allowed at the moment.08:47
chriadamwe need to start work on our side, reviewing and merging and progressing things here.08:47
dcalisteLike sailjail to access the privileged calendar data.08:47
chriadamI hope that we will make good progress this week, now that most people are back from vacations etc08:47
chriadamah yes, sailjail etc..08:47
chriadampvuorela: flypig: dcaliste: any final things to cover before we end the meeting?08:48
dcalistenothing 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 asap08:50
pvuorelai'm good. thanks!08:50
* chriadam -> away, gnight08:50
dcalisteGood night chriadam.08:50
dcalisteThank you pvuorela, have a nice day.08:51
*** teve_ is now known as teve12:11
riniguspoetaster, 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 separately12:21
rinigusI wonder whether anyone has seen Fedora or Suse packages for PIL? couldn't find them during short search at fedora sources12:22
riniguspiggz: I have disabled failing builds in chum:testing for those inserted SFOS versions. would have to do the same when promoted to chum12: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 client12:45
ilpianistaI'm writing the syncthing client myself, but unfortunately my phone doesn't charge anymore. sigh.12:46
riniguspoetaster: moving discussion over here... can you send link to FSO thread?13:08
HengYeDev[m]1QFilterProxyModel is causing SlicaListView to scroll to the top every time an item is updated. Is there a way to avoid this behavior?14:20
NicoHengYeDev[m]1: Yes, set the currentIndex explicitly14:22
HengYeDev[m]1hrmm..same is still happening for me. on 3.4 emulator14:25
fridlmuerinigus: arent that one the 'PIL' packages (since some time 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
rinigusfridlmue: maybe fedora packaging guide for python libs makes more sense to use14:28
rinigussee https://forum.sailfishos.org/t/application-sdk-bash-sdk-deploy-rpm-command-not-found/5743/4014:28
fridlmuerinigus: 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
attahilpianista: sounds as complete as i thought then... but i'm probably blind to many use cases. Sounds like you picked the most interesting one18:15
attahwhat phone might that be?18:15

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