07:00:08 <rainemak> #startmeeting Sailfish OS, open source, collaboration -- 3rd October 2024
07:00:08 <sailbot> Meeting started Thu Oct  3 07:00:08 2024 UTC. The chair is rainemak. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:08 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:00:18 <rainemak> #info Meeting information and agenda can be found here:
07:00:18 <rainemak> #link https://forum.sailfishos.org/t/community-meeting-on-3rd-october-2024/20027
07:00:18 <rainemak> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and bee-hive.
07:00:18 <rainemak> #topic Brief introduction (5 min). Please prefix your name/handle with #info
07:00:24 <ExTechOp> #info Otto Mäkelä, community
07:00:58 <dcaliste> #info Damien Caliste, community
07:01:21 <rainemak> #info Raine Mäkeläinen, Jolla
07:01:29 <Crabster> #info Crabster - lurker
07:01:37 <pvuorela> #info Pekka Vuorela, Jolla
07:01:46 <direc85> #info Matti Viljanen, Jolla
07:02:42 <piggz[m]> #info piggz community
07:05:01 <rainemak> One today
07:05:14 <rainemak> #topic rewriting of QtMobility plugin providing an engine for QtOrganizer based on mKCal (15 mins -- asked by dcaliste)
07:05:25 <rainemak> #info <dcaliste> Like QtContacts used in Sailifsh OS, QtPim (long heir of
07:05:25 <rainemak> #info <dcaliste> QtMobility) provides a module to deal with events and todos :
07:05:25 <rainemak> #info <dcaliste> QtOrganizer. It provides an API and QML bindings to handle
07:05:25 <rainemak> #info <dcaliste> calendar items. It can use several backends for storage. Old
07:05:25 <rainemak> #info <dcaliste> sources from QtMobility dated from Qt4.x era still have a plugin
07:05:26 <rainemak> #info <dcaliste> based on mKCal (the SQLite backend for calendar event used in
07:05:28 <rainemak> #info <dcaliste> Sailfish OS). But these sources are really out-dated, both mKCal
07:05:30 <rainemak> #info <dcaliste> and QtOrganizer have largely changed API since Qt4.x era. I’ve
07:05:32 <rainemak> #info <dcaliste> decided to rewrite the plugin, so current (or future) code using
07:05:36 <rainemak> #info <dcaliste> QtPim/QtOrganizer can have a well debugged SQLite backend, or
07:05:38 <rainemak> #info <dcaliste> even share data with an application based on
07:05:40 <rainemak> #info <dcaliste> nemo-qml-plugin-calendar (like the calendar application). The new
07:05:42 <rainemak> #info <dcaliste> implementation can be found in this git repository 2. The main
07:05:44 <rainemak> #info <dcaliste> point of this topic is to announce the existence of this new
07:05:46 <rainemak> #info <dcaliste> possibility to handle calendar events and todos. While I’m still
07:05:48 <rainemak> #info <dcaliste> preferring to base new developments on the couple KCalendarCore/
07:05:50 <rainemak> #info <dcaliste> mKCal, the community meeting may be the place to discuss the pros
07:05:52 <rainemak> #info <dcaliste> and cons of this new possibility based on QtPim.
07:06:22 <rainemak> #info <Jolla> Like dcaliste said in the forum, 5 to 15 minutes, depending if there
07:06:22 <rainemak> #info <Jolla> is interest to discuss the topic, or if the announcement is just
07:06:22 <rainemak> #info <Jolla> enough. This is a good discussion topic for a community meeting.
07:06:22 <rainemak> #info <Jolla> Let's see how lively discussion we get.
07:07:02 <rainemak> Shall I open discussion
07:07:11 <dcaliste> Sure !
07:07:13 <rainemak> Do you have an idea how widely QtOrganizer is used? Would that help application porters?
07:07:42 <sebix[m]> #info sebix, community
07:07:54 <dcaliste> Thank you rainemak for the introduction. I can add that this work was started because UBports would like to move away from Evolution Data Server and use Buteo / mKCal and friends instead.
07:08:20 <dcaliste> To ease their migration, they wanted to keep their UI, and it was based on QtOrganizer.
07:08:53 <dcaliste> So, rainemak, to answer your question, at least Ubuntu Touch is using QtOrganizer.
07:08:58 <rainemak> So, there's at least one QtOrganizer user
07:09:32 <dcaliste> Yeah, seems so ;)
07:09:33 <pvuorela> that's interesting. though wonder if it's just for easing the migration or do they plan to keep on using qtorganizer
07:10:21 <pvuorela> if it's good enough for them, suppose it can easily just stick around.
07:10:35 <dcaliste> As far as I know, the first step is to migrate from EDS. I don't know if they plan to rewrite their UI to use KCalendarCore directly once it's done.
07:11:00 <dcaliste> If QtOrganizer suits their needs, I guess they will stay with it.
07:11:03 <rainemak> I'm a bit worry that sticking with QtOrganizer may lead to unmaintained component
07:11:19 <dcaliste> But it's a good opportunity for us to widen the usage of mKCal (at least).
07:11:36 <rainemak> Widening mKCal use I like
07:11:53 <pvuorela> that is nice indeed
07:12:08 <dcaliste> Yeah, it means more testing, feedback and maybe code contribution.
07:12:22 <pvuorela> and that's already good reason for the qtorganizer backend project to exist.
07:12:28 <dcaliste> rainemak, what do you mean about the unmaintained components in QtOrganizer ?
07:13:07 <pvuorela> though for sailfish context i'm not entirely sure how much we should be adopting it. so far we haven't used qtorganizer.
07:13:47 <dcaliste> My opinion for Sailfish is to stick with KCalendarCore, it removes one layer wrt. using QtOrganizer + mKCal.
07:14:12 <dcaliste> KCalendarCore is (very) active with KDE, so I think it's a better choice.
07:14:36 <rainemak> dcaliste, will QtOrganizer itself stay maintained
07:14:47 <dcaliste> But for codes that are already based on QtOrganizer, it helps to stay with a somehow laively backend.
07:14:56 <rainemak> that's true
07:15:59 <dcaliste> rainemak, ah this question about QtOrganizer. Yeah, good point. Since it's still under QtProject, I guess it will continue to be alive under a strictly minimal maintainance upgrade, from community help…
07:16:43 <piggz[m]> Where os it maintained? The only code i saw was from 10 years ago, presume its not that :)
07:17:37 <rainemak> and yeah, Sailfish OS to stick with KCalendarCore is the way I think
07:17:54 <dcaliste> piggz[m], let me find again…
07:18:31 <dcaliste> piggz[m], it's https://codereview.qt-project.org/admin/repos/qt/qtpim,general
07:18:58 <dcaliste> Latest commit from 2021. Not _that_ bad.
07:19:12 <rainemak> 1 min left, should we extend by 5mins
07:20:00 <rainemak> extending, topic ending in 5mins
07:21:25 <dcaliste> rainemak, for me it's fine, I guess I explained the purpose of the project. I've got already one user : Lionel Duboeuf from UBports ! Hopefully, if it's usefull for someone else for Sailfish OS, he or she may find the discussion here.
07:21:57 <rainemak> I very much like this kind of community meeting topics
07:22:20 <rainemak> and pleased to see constructing discussion
07:23:25 <dcaliste> Yeah, I'm happy too. Thank you for the discussions and the questions.
07:23:26 <rainemak> dcaliste, well prepared topic and explained the purpose
07:24:29 <rainemak> also getting more use Buteo/mkCal is good
07:24:40 <rainemak> for Buteo/mkCal
07:24:49 <rainemak> alright, let's move on
07:25:01 <rainemak> #topic Open PR discussion (5 mins -- asked by Jolla)
07:25:05 <dcaliste> Indeed, I forgot about Buteo, but yes, it also means more tests and usage for the CalDAV plugin for instance.
07:25:25 <rainemak> thumbs up
07:26:03 <dcaliste> While we are talking about mKCal, pvuorela, do you think we could restart the rework of it, with https://github.com/sailfishos/mkcal/pull/60 for instance ?
07:26:59 <pvuorela> dcaliste: definitely.
07:27:09 <dcaliste> (still with UBports, they may move to using timed for alarms too)
07:27:25 <dcaliste> pvuorela, good, good. Thanks !
07:27:52 <pvuorela> dcaliste: for one i was thinking of checking the qmf thing first as that's in a bit fresher memory still.
07:28:41 <rainemak> btw, here's a shortcut for open & review required PRs: https://github.com/search?q=org%3Asailfishos+is%3Apr+is%3Aopen++review%3Arequired+&type=pullrequests
07:28:42 <dcaliste> pvuorela, yes, good point. And it may be usefull to get (Microsoft) IMAP to use OAuth2 for authentication.
07:29:05 <pvuorela> yes.
07:29:31 <pvuorela> at the moment those should be the only things in my review queue even if both a bit bigger ones.
07:30:17 <dcaliste> I need to see where I left my investigations when moving the existing sso plugins (password and oauth2) to the new credential API.
07:31:16 <dcaliste> Because as far as I remember, the opened PR only create the new credential plugin API, and provide a simple implementation for passwords, but not for oauth2.
07:31:42 <rainemak> extra 3mins
07:31:55 <dcaliste> But I've got on my machine some attempts to create a unified sso plugin for both password and oauth2 using the new credential API.
07:32:31 <pvuorela> at least there's the separate oauth2 plugin thing that needs updating.
07:33:44 <dcaliste> When looking at what it needs, it's almost copy-pasting from the password implementation. That's why I think, one can go for a unified credential plugin based on SSO (treating both password and oauth2 cases, and maybe all others supported by SSO itself).
07:35:03 <rainemak> time to move on
07:35:06 <rainemak> #topic General discussion (10 mins)
07:35:06 <piggz[m]> Not sure if its relevant, but there is a qtnetworkauth module specifically for doing oauth type stuff
07:35:48 <piggz[m]> For general, could i ask if there is any progress on the obs/sb2 issues ove been hitting
07:36:24 <pvuorela> on this we case we have the oauth stuff but the apis for secrets and password are just changed and the different components need to adapt.
07:37:12 <dcaliste> piggz[m], interesting. Actually, as far as I understand, it's SSO that's doing all the network job behind the scene. The credential plugin in QMF just need to talk to SSO. As pvuorela mentioned, we're here changing the QMF APIs so it's not depending on SSO.
07:37:14 <rainemak> #info There was a great Sailathon organized in Prague last week! Big hand to participants and to karry who afaik mostly organized it
07:38:14 <direc85> Thank you from me as well!
07:38:35 <rainemak> if you're testing Xperia 10 IV and 10 V, please use feedback topics in forum
07:38:45 <rainemak> #link https://forum.sailfishos.org/t/feedback-on-xperia-10-iv/20113
07:38:53 <rainemak> #link https://forum.sailfishos.org/t/feedback-on-xperia-10-v/20114
07:39:14 <rainemak> There are known issues https://forum.sailfishos.org/t/release-notes-sauna-4-6-0-15/19740#new-devices-4
07:39:18 <rainemak> #link https://forum.sailfishos.org/t/release-notes-sauna-4-6-0-15/19740#new-devices-4
07:40:58 <rainemak> 5mins left
07:42:19 <rinigus> piggz: judging from silence, I guess nobody had time to look into sb2 and obs troubles with compilation of qt6 on aarch64 (summary of troubles)
07:42:38 <piggz[m]> Thx
07:43:13 <piggz[m]> Worried it may cause you additional trouble, as seems quite low level, and surprised its not been hit before
07:44:57 <rinigus> I also wonder how frequently Jolla is internally hit by sb2 bugs. or is it just us able to hit them first?
07:45:06 <rainemak> if you're testing esr91, please provide feedback to https://github.com/sailfishos/sailfish-browser/issues
07:45:43 <rainemak> let's move on
07:45:56 <rainemak> #topic Next meeting time and date (5 mins)
07:46:01 <rainemak> Proposing Thursday 17th October at 07:00am UTC
07:46:08 <rainemak> Usual biweekly schedule
07:46:45 <ExTechOp> Works4me.
07:48:03 <rainemak> I guess that the usual biweekly then
07:48:08 <Nico> I wonder, is anybody using sailfish with nextcloud with 2fa enabled? I created an app password and it seems like everything works but only the backup upload does not. Has anyone run that setup as well and noticed the same issue or is that a problem with my nextcloud? :D
07:48:09 <rainemak> Thank you everybody!!
07:48:12 <dcaliste> That's ok for me also.
07:48:37 <rainemak> #info Next meeting will be held on Thursday 17thd October 2024 at 07:00am UTC: 2024-10-17T0700Z
07:48:45 <rainemak> #endmeeting