07:00:13 <flypig> #startmeeting Sailfish OS, open source, collaboration -- 4th August 2022
07:00:13 <sailbot> Meeting started Thu Aug  4 07:00:13 2022 UTC. The chair is flypig. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:13 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:00:18 <flypig> #info Meeting information and agenda can be found here:
07:00:23 <flypig> #link https://forum.sailfishos.org/t/community-meeting-on-irc-4th-august-2022/12456
07:00:30 <flypig> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and the laws of physics.
07:00:48 <flypig> Apologies for the lack of meeting two weeks ago. We have a bumper set of questions this week though.
07:00:52 <flypig> #topic Brief introduction (5 min). Please prefix your name/handle with #info
07:01:17 <attah_work> But flying pigs are excempt?
07:01:49 <fridl> #info fridlmue - community
07:01:50 <abr> #info Andrew Branson - sailor
07:01:55 <ExTechOp> Otto Mäkelä - community
07:02:02 <flypig> Haha. I guess they probably are attah_work :)
07:02:04 <ExTechOp> #info Otto Mäkelä - community
07:02:04 <attah_work> #info Anton Thomasson - community, partly paricipating
07:02:22 <flypig> #info David Llewellyn-Jones - sailor @ Jolla
07:02:23 <sledges> #info Simonas Leleiva - privateer for Jolla
07:03:06 <Thaodan> #info  Björn Bidar - sailor @ Jolla
07:05:06 <flypig> Almost even today; nice. Last chance to admit your presence...
07:05:14 <piggz> #info piggz, community
07:05:23 <flypig> Now we're even!
07:05:53 <flypig> We have many questions so let's move on to the first.
07:06:00 <flypig> #topic 5G support (5 mins -- asked by cquence)
07:06:08 <flypig> #info <cquence> I'd like to inquire about the plans to enable 5G connectivity in 10III. Are there any plans to enable 5G?
07:06:15 <flypig> #info <cquence> If so any rough timeframes (1,2,3 releases away or similar) you can possibly share?
07:06:46 <flypig> I guess cquence isn't here today? Nevertheless, here's our prepared response.
07:06:49 <flypig> #info <Jolla> Supporting 5G requires a broad set of changes at various OS levels. These include adaptation support, ofono support and ofono plugin support.
07:06:57 <flypig> #info <Jolla> Right now our focus is on refining the breadth and depth of our VoLTE implementation.
07:07:04 <flypig> #info <Jolla> For future 5G developments, our suggestion is to keep an eye on the relevant repositories, or Damien's Repository Roundup in the newsletter.
07:07:42 <flypig> A short answer. But we have a few minutes and it would be interesting to know what others are thinking about the importance of 5G.
07:08:25 <ExTechOp> Well, it's obviously the way the industry is going, so unless it is made to work, SFOS will be treading water :-/
07:09:57 <attah_work> It's not as clear as with the LTE roll-out that it was deployed with 100% overlap... 5G can well be deployed were nothing else covers, but that will be super rare for years to come
07:10:24 <Thaodan> There are two points of interest here. First the hybris way of doing this: we have ofono-binder-plugin which talks to the Qti blob and thous only needs to implement the IRadio interfaces and react to the new interfaces.
07:10:48 <Thaodan> So far we have IRadio 1.4 iirc.
07:11:08 <Thaodan> Higher IRadio versions would be needed.
07:12:50 <attah_work> 1.6 it seems
07:13:08 <Thaodan> For adaptations that don't use the binder plugin and thus directly talk to the modem the situation is different it depends on how far ofono is in talking to the modem. E.g. QMI in terms of Qti.
07:13:10 <flypig> Are we talking about this? https://source.android.com/devices/tech/connect/5g-slicing
07:14:09 <Thaodan> That is one piece, however the docs aren't that descriptive. they don't tell much on what is exactly needed.
07:15:23 <flypig> I'll just stick this in the minutes for future reference.
07:15:25 <flypig> #info <Thaodan> There are two points of interest here. First the hybris way of doing this: we have ofono-binder-plugin which talks to the Qti blob and thous only needs to implement the IRadio interfaces and react to the new interfaces.
07:15:37 <flypig> #info So far we have IRadio 1.4, we would need 1.6
07:15:52 <flypig> #info <Thaodan> For adaptations that don't use the binder plugin and thus directly talk to the modem the situation is different it depends on how far ofono is in talking to the modem. E.g. QMI in terms of Qt
07:16:24 <Thaodan> IRadio 1.5 also mentions 5G
07:16:58 <Thaodan> argh emacs crashed,  looks like emacs natively on wayland isn't there yet
07:17:08 <flypig> I'm afraid we only had a few mins on this topic and have hit time, so we should move on to the next topic, but the discussion can continue in General at the end if there's more to say on it.
07:17:23 <flypig> Unless you want more now?
07:17:42 <Thaodan> I can only say what I think,  slava or mal would now  better
07:17:42 <ExTechOp> I guess there isn't much more to say, if you cannot even divulge a planned schedule?
07:17:59 <Thaodan> I think we said everything we know so far
07:18:02 <flypig> Yeah, I'm afraid that's the case ExTechOp.
07:18:07 <flypig> Okay, next up...
07:18:10 <flypig> #topic OAuth2 support in Microsoft Exchange commercial plug-in (5 mins -- asked by DrYak)
07:18:16 <DrYak> Hi!
07:18:16 <flypig> #info <DrYak> Do we have a status update for the support of OAuth2 in the Microsoft Exchange?
07:18:23 <flypig> Ah, good that you're here DrYak.
07:18:27 <flypig> #info <DrYak> After Alien-Dalvik, getting support for my employer's e-mail servers is the second most important reason for buying the licence to Sailfish X.
07:18:32 <flypig> #info See the following forum links for more info.
07:18:37 <flypig> #link https://forum.sailfishos.org/t/modern-authentication-oauth-support-for-the-microsoft-exchange-activesync-e-mail-contacts-calendar/5237
07:18:41 <flypig> #link https://forum.sailfishos.org/t/basic-authentication-deprecated-by-microsoft/2905/14
07:18:45 <Thaodan> I would suggest to talk on #sailfishos-porters and see what we can work on together
07:19:11 <flypig> Here's our prepared answer DrYak, after which we can discuss further.
07:19:16 <flypig> #info <Jolla> Thanks for your question Ivan, and also for buying a Sailfish X licence.
07:19:23 <flypig> #info <Jolla> You'll already be aware of the details, but for the benefit of others, this relates to the Exchange Active Sync (EAS) support on Sailfish OS for syncing emails, calendars and contacts with Exchange services such as Office365.
07:19:32 <flypig> #info <Jolla> Microsoft have said they plan to disable password authentication in October 2022 (there may be some exceptions), after which it will be necessary to authenticate using OAtuh, which the sailfish-eas daemon doesn't currently support.
07:19:41 <flypig> #link https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-deprecation-in-exchange-online-may-2022/ba-p/
07:19:45 <flypig> #info <Jolla> As is already stated on the forum thread we do have an internal task covering this, and there has been some work undertaken on an implementation.
07:19:54 <flypig> #info <Jolla> However, unfortunately it's not possible to give further details about the likelihood or timescales for a solution at this point.
07:20:02 <flypig> #info <Jolla> We aim to report progress back to the tracked forum topic. The need for the functionality is reinforced by both the discussion on the forum and the fact you've raised it here today, so the input is useful to us.
07:20:29 <flypig> That's the answer. Again, sorry there's no specific timescale DrYak. Obviously the October deadline is approaching.
07:20:44 <ExTechOp> Just out of curiosity, does the Microsoft oauth system have any commonalities with the Google authentication which works?
07:20:46 <DrYak> And in some organisation the switching away is already hapenning.
07:20:56 <attah_work> We have had it required for years now
07:21:21 <DrYak> In our case, users as switched to the new authentication in batches and my account got a few weeks back. So I am currently unable to access my calendar.
07:21:38 <attah_work> So, fwiw, Evolution already handles it great - if one needs inspiration
07:22:06 <DrYak> ExTechOp: AFAIK (not my expertise) OAuth2 is a standard.
07:22:13 <Thaodan> I would say oauth is oauth, it depends on how Microsoft diverges from the standard.
07:22:22 <flypig> ExTechOp, if I understand your question correctly Google auth (TOTP) requires user intervention, whereas OAuth doesn't, so the latter is important for things like background email access.
07:23:04 <DrYak> attah_work: in Thunderbird world, this is supported with TbSync + EAS-4-TbSync (both opensource) which work even with the latest Office 365 (like my employer uses).
07:23:39 <flypig> We have many services that already support OAuth, but not EAS unfortunately.
07:23:59 <Thaodan> The issue will be how to integrate that inside the qmf.
07:24:03 <DrYak> flypig: Microsoft Office 365 also has 2FA, and in some organisation it is mandatroy (my employer uses TOTP, other can use FIDO such as YubiKeys - which btw already works nicely in Sailfish Browser)
07:24:44 <flypig> DrYak, that isn't an issue though, if I understand your question correctly?
07:25:02 <flypig> The outstanding issue here is just OAuth.
07:25:39 <Thaodan> flypig: if oauth works 2fa work's
07:25:42 <DrYak> flypig: yes, password are disabled for me, I need OAuth2. (And I 2FA is enforced)
07:26:00 <Thaodan> because password based login doesn't support 2fa
07:26:20 <DrYak> Thaodan: exactly.
07:28:00 <flypig> Anything to add to the minutes on this? Can we move on to the next question?
07:28:07 <DrYak> Also in general, if I understand the official answer, it means that OAuth2+Microsoft isn't there yet, and I need to find some workaround way until it's there (e.g.: Office to CalDEV forwareder).
07:28:26 <DrYak> There isn't some beta version to be tested, yet.
07:29:02 <flypig> DrYak, nothing available publicly, so yes, you'd need a workaround for the time being.
07:29:21 <Thaodan> flypig: No there isn't anything else, unfurtonatly part of this has to happen the closed source part
07:29:22 <DrYak> Thank you very much for taking time to answer this topic.
07:29:56 <flypig> You're welcome, and thanks for asking it DrYak. As the answer hints, being asked about this stuff is a good motivator.
07:30:12 <flypig> Okay, next question.
07:30:14 <flypig> #topic Future plans for SailJail (10 mins -- asked by attah)
07:30:22 <flypig> #info <attah> This springs from discussions about Storeman, but applies to all third-party apps.
07:30:28 <flypig> #info <attah> What are Jolla's long term goals for GUI apps in the Jolla Store ("harbour") and outside of it (e.g., at OpenRepos or SailfishOS:Chum) WRT SailJail.
07:30:41 <flypig> #info <attah> Do you plan to either enforce a proper SailJail configuration sooner or later, or to keep it optional forever (by simply deploying a [X-Sailjail] Sandboxing=Disabled in an app's .desktop file), or to take an intermediate route, e.g., by alerting users when installing apps which have opted out of sandboxing?
07:31:05 <flypig> Our prepared answer:
07:31:08 <flypig> #info <Jolla> First a quick recap of the current situation. Sandboxing was turned on by default for all apps in Sailfish OS 4.4.0. This means that:
07:31:16 <flypig> #info <Jolla> 1. Apps with permissions specified in the desktop file are granted only those permissions.
07:31:20 <flypig> #info <Jolla> 1. Apps with permissions specified in the desktop file are granted only those permissions.
07:31:25 <flypig> #info <Jolla> 3. Apps can have sandboxing explicitly disabled to run in the same way they would have done before sandboxing was introduced.
07:31:32 <flypig> #info <Jolla> The roadmap that brought us here was posted on the Jolla blog last year:
07:31:37 <flypig> #link https://blog.jolla.com/whats-up-with-sandboxing/
07:31:44 <flypig> #info <Jolla> Due to the summer vacations I wasn't able to get a definitive answer, but my understanding is that there are no immediate plans for any changes to this, or for changes to the harbour requirements in relation to sandboxing.
07:31:46 <DrYak> There an error: 2. is missing, 1. got duplicated.
07:31:58 <flypig> Ah, thank you, that's my copy-paste error.
07:32:22 <flypig> I'm not going to undo it all, I think it should make sense:
07:32:28 <flypig> #info Correction:
07:32:29 <flypig> #info <Jolla> 2. Apps without any permissions specified are granted a default set of permissions which are shown to the user.
07:32:53 <flypig> #info <Jolla> This doesn't mean there won't be changes in the future, but that's my understanding of the current situation.
07:33:01 <flypig> #info <Jolla> There may be changes to the permissions that are available (for example changes were made to allow access to the compass) or to the scope of the default sandboxing profile.
07:33:17 <attah_work> Would you agree with my assessment that implementation of SailJail is "done" to the extent that was planned?
07:33:22 <flypig> #info <Jolla> We have some improvements to the sandboxing documentation in the pipeline.
07:33:26 <flypig> #ink https://github.com/sailfishos/docs.sailfishos.org/pull/93
07:33:54 <flypig> Yes, I think that's a correct assessment attah_work, at least as far as I was able to find out.
07:34:05 <attah_work> I.e. as opposed to that current implementation does not fulfill the goals as presented e.g. in that blog post
07:34:35 <flypig> You mean the goal that "all apps will be sandboxed".
07:34:44 <flypig> ?
07:34:53 <attah_work> Primarily
07:35:29 <flypig> The implication there was that all apps would be sandboxed by default if they don't specify any sandboxing in the .desktop file.
07:35:40 <flypig> That's my understanding at least, and that's now the case.
07:36:06 <flypig> It was suggesting that developers need to prepare for this situation.
07:36:09 <attah_work> Right, but Olf id worried that Sandboxing=Disabled would go away
07:36:33 <attah_work> But my impression is that "all apps from trusted sources" qualifies as "all" in that statement, and others can keep using that as they please
07:36:35 <abr> oof no. there are system apps that need that. i don't think it'll go away
07:36:44 <attah_work> :)
07:36:55 <abr> maybe one day there'll be a warning for apps that have sandboxing disabled
07:37:34 <attah_work> excellent
07:37:54 <Thaodan> I think one has to consider how sandboxing works in Sailfish OS: If an app is started through lipstick it will be started through Sailjail unless it is disabled.
07:38:09 <Thaodan> If an pp is started anyhow else there's no sandboxing.
07:38:19 <flypig> attah_work, is that your/olf's preference then? For the option to remain, but with a warning to the user?
07:38:49 <attah_work> I certainly prefer that
07:38:57 <abr> another alternative is to create your own permission file if there's stuff you need access to that isn't covered by another permission
07:39:01 <flypig> Okay, good to be aware, thanks.
07:39:32 <flypig> abr, that wouldn't currently be allowed in harbour though, would it?
07:39:35 <ExTechOp> "do you wish to install this application, which will run without sandboxing" seems like a nice additional feature?
07:39:50 <attah_work> Olf has doubts about whether the option remaining makes the other hardening valid, and would like to not have users warned about e.g. storeman
07:40:03 <abr> flypig: no, but then neither is disabled sandboxing, is it?
07:40:32 <Thaodan> I don't think it is really valid that user brings up his points without talking himselves, I can't assume what a person thinks.
07:40:35 <flypig> abr, I think we currently allow disabled sandboxing.
07:40:47 <Thaodan> If there's a point he should bring it up.
07:41:02 <abr> really? maybe we should indicate that on the store page too then, before they install
07:41:03 <Thaodan> In a voice that isn't so imperative.
07:41:15 <attah_work> My view is that as long as one can install custom profiles, the option should remain, because neither is "more secure" than the other
07:41:24 <flypig> abr, I could be wrong. I should double check.
07:41:37 <attah_work> ...and i like the level of security just the way it is (+/- the warning discussed)
07:41:47 <abr> there are several apps that need it, or custom permissions. i'd prefer the latter tbh
07:42:09 <Thaodan> I agree too
07:42:18 <DrYak> are there people fluent with "custom persmissions" that can assist in writing thos?
07:42:20 <Thaodan> It is commen to create extra permissions.
07:42:32 <attah_work> Sure, custom profiles are a bit nicer, but it is not like normal users would read them
07:42:39 <Thaodan> The issue is in allowing those extra permissions.
07:42:53 <Thaodan> there isn't such a thing as custom profiles
07:43:13 <attah_work> firejail profiles - oh for sure there are
07:43:29 <Thaodan> an app requests a permission and that permissions is cannonicly difened in sailjail-profiles.
07:43:40 <DrYak> (My personnal example: I've quickly adapter kimmoli 's chargemon to Xperia 10iii, but that needs read access to stuff in `/sys/`. I don't know what to put in the custom profile to allow for that)
07:44:04 <attah_work> ...and can ship a firejail spec or whatever they are called
07:44:07 <abr> yeah, they'd be a bit opaque though. adding as a permission means the user sees it in the sailjail permission prompt
07:44:08 <Thaodan> firejail profiles for sure however those aren't directly used
07:44:45 <flypig> We are over time I'm afraid, have to move on. Anything to add to the minutes?
07:45:01 <abr> DrYak: have a look in the other permissions for examples, though there are some paths that firejail never allows
07:45:09 <attah_work> I'm good - thanks for the answer
07:45:24 <flypig> Thanks attah_work for the question.
07:45:30 <flypig> #topic Harbor API progress (in special QtLocation) (10 mins -- asked by fridlmue)
07:45:34 <Thaodan> In the end we need to avoid workarounds because of firejail issues.
07:45:49 <flypig> Let's pick this up again in General.
07:45:49 <flypig> #info <fridlmue> There have always been some discussions about Harbour-allowed APIs in the past, recently also some changes.
07:45:55 <flypig> #info <fridlmue> Also there has been a poll from Jolla some time ago.
07:46:00 <flypig> #link https://forum.sailfishos.org/t/api-priority-poll-take-ii/4159
07:46:03 <flypig> #info <fridlmue> Can Jolla perhaps give a short update, if they are working actively on some of these points? (Of course those who have not been tackled yet.)
07:46:12 <flypig> #info <fridlmue> My question originates from the need of implementing some relatively simple "map" view in a app showing some shapes in colors and the current position.
07:46:20 <flypig> #info <fridlmue> I would love to have it Harbour-compliant and most native, but in case there will be no solution in the foreseeable time, I would need to tackle it by a leaflet in a web view or something like that (which I really don't prefer...). Interaction with the app itself will then be another challenge.
07:46:27 <flypig> #info <fridlmue> On the other hand, if there is something in the pipeline (like QtLocation), it would be a wast of effort and I would wait...
07:46:38 <flypig> Here's the prepared response.
07:46:39 <flypig> #info <Jolla> You're correct that there have been some changes in the relatively recent past to support more APIs in harbour. The poll was useful for prioritisation and we are also always looking at ways to support more capabilities.
07:46:45 <flypig> #info <Jolla> As it stands though, it's not possible to announce any plans in relation to future harbour APIs.
07:46:52 <flypig> #info <Jolla> In particular in relation to QtLocation, we would recommend using an alternative mapping approach if you're planning to submit your app to the Jolla Store in the near future.
07:47:00 <flypig> #info <Jolla> If this situation changes we will of course make a clear announcement in the forum.
07:47:03 <flypig> #info <Jolla> We also look forward to receiving your app (maybe you could share some more details?).
07:47:34 <fridl> Thanks for the Answer.
07:47:48 <flypig> You're welcome. I realise it's probably not the answer you were hoping for.
07:47:58 <fridl> It is only about that I'm thinking about how to proceed with my avaRisk app.
07:48:08 <flypig> Ah, yes, nice app.
07:48:18 <abr> risk as in the board game?
07:48:42 <fridl> No, its about Avalanche (Risk) Bulletins. So for Winter Outdoor sports.
07:48:42 <flypig> Real world physical risk!
07:49:25 <abr> ah. needing a real map to play Risk would have been slightly weird but awesome
07:49:37 <flypig> It's a nice idea abr :)
07:50:05 <abr> but avalanches are probably higher priority!
07:50:45 <flypig> Well, hopefully not for me right now, but in general I'd agree!
07:50:48 <abr> it'd be lovely to have an OSM map ui control in sfos somehow
07:50:53 <DrYak> Speaking of the prompt: it would be good if it also mentions existence of custom profile. (e.g.: WhisperFish uses one, but it's not mentioned in the warning prompt).
07:51:05 <flypig> fridl, it'd be really interesting to know how you eventually decide to approach this.
07:52:10 <dryak_> (^--: sorry for the out-of-sync message. lag...)
07:52:37 <fridl> flypig: Probably I'll start a forum topic about it. At the moment I think about loading a leaflet in a webview, but (as I didn't check details) I have no Idea how to get information (like clicking into a region) can be fetched pack from the SFOS side.
07:52:44 <flypig> No worries dryak_
07:53:13 <fridl> Maybe there are standard ways to do so, i have to read about that. Good Reads or Keywords for a search are always welcome, however.
07:53:42 <flypig> I'll try to follow along with the forum topic. It sounds like an interesting exercise.
07:54:04 <flypig> Two more mins on this.
07:54:22 <fridl> IMHO we can go on. Thanks!
07:54:36 <flypig> Okay, great. Thank you fridl.
07:54:43 <flypig> #topic Open PR discussion (10 mins -- asked by jolla)
07:54:49 <flypig> #info <jolla> Any open PRs to discuss or promote?
07:54:53 <flypig> #link https://github.com/pulls?q=is%3Aopen+is%3Apr+org%3Asailfishos
07:55:12 <flypig> This is a bit open ended here, as we didn't have any raised in advance.
07:57:13 <fridl> I have only seen some open pr's in the mer-hybris project. I think some are not special SFOS PRs, so I think the people are not aware of the Meeting here ;-).
07:58:09 <flypig> I guess this would be the equivalent search for mer-hybris.
07:58:11 <flypig> #link https://github.com/pulls?q=is%3Aopen+is%3Apr+org%3Amer-hybris
07:58:22 <fridl> However, there seems not be be a urgent need for quick reply or merge...
07:58:40 <flypig> Thanks for checking that fridl.
08:00:04 <Thaodan> https://github.com/mer-hybris/droid-hal-device/pull/311 is open and required for local builds to work with newer droidmedia and no minisf start in servicemanager.rc
08:00:43 <Thaodan> We disabled the start of minisf in servicemanager.rc in recent hybris-patches.
08:01:08 <flypig> Thaodan, would it help for someone from the community to review that?
08:01:36 <Thaodan> flypig: not exactly but since it needs to be approved by sailors.
08:02:00 <Thaodan> But it is good to raise in case a community member faces issues.
08:02:12 <abr> yeah, all reviews are welcome
08:02:43 <abr> but the rule is every PR needs approval from two sailors before it gets merged
08:03:40 <flypig> #info Thaodan noted the following PR which may address some issues faced by community members.
08:03:42 <flypig> #link https://github.com/mer-hybris/droid-hal-device/pull/311
08:04:41 <flypig> One more minute on this.
08:05:34 <flypig> Alright, time to move on to the next then. Thanks for flagging that Thaodan.
08:05:38 <flypig> #topic Untracked bug reports (10 mins -- asked by pherjung)
08:05:44 <flypig> #info <pherjung> On bug 10926, his SD card is invisible for the default (and hidden) file browser.
08:05:52 <flypig> #info <pherjung> What should modified to get more logs from native file browser?
08:05:56 <flypig> #info <pherjung> This section could be used to complete the official documentation.
08:05:59 <flypig> #link https://forum.sailfishos.org/t/unencrypted-fat-sdcard-doesnt-properly-mount-via-gui/10926
08:06:02 <flypig> #link https://docs.sailfishos.org/Reference/Sailfish_OS_Cheat_Sheet/
08:06:23 <flypig> This was in relation to the Bug Coordination Team's work, so I included the bug summary in the prepared answer.
08:06:26 <flypig> #info <Jolla> The Community Bug Coordination Team have done a superb job once again over the last four weeks. Here are the usual stats from their work:
08:06:32 <flypig> #info <Jolla> - 13 high quality bug reports now recorded internally and tagged as "tracked".
08:06:34 <flypig> #info <Jolla> - 2 bug reports marked as "pending" more info.
08:06:37 <flypig> #info <Jolla> - 4 bug reports tagged as "fixed".
08:06:40 <flypig> #info <Jolla> - 3 marked as duplicates and closed.
08:06:44 <flypig> #info <Jolla> To move on to the question about SD card logging.
08:06:49 <flypig> #info <Jolla> The code that handles enumeration of the different partitions can be found in nemo-qml-plugin-systemsettings.
08:06:53 <flypig> #link https://github.com/sailfishos/nemo-qml-plugin-systemsettings/blob/master/src/partitionmodel.cpp
08:07:01 <flypig> #info <Jolla> The debug output there uses the lcMemoryCardLog logging category, which resolves to "org.sailfishos.settings.memorycard"
08:07:05 <flypig> #link https://github.com/sailfishos/nemo-qml-plugin-systemsettings/blob/1d7164f1b0eb7e6696f614eb93e29b067d4677fc/src/logging.cpp
08:07:08 <flypig> #info <Jolla> So to get more output you can activate this logging category as follows for the Settings app and hidden file browser respectively.
08:07:11 <flypig> #info <Jolla> QT_LOGGING_RULES="org.sailfishos.settings.memorycard=true" sailfish-filemanager
08:07:13 <flypig> #info <Jolla> QT_LOGGING_RULES="org.sailfishos.settings.memorycard=true" devel-su -p jolla-settings
08:07:17 <flypig> #info <Jolla> Hopefully the output from this may help the user get to the bottom of the issue.
08:07:55 <flypig> If anyone else has suggestions for how to debug SD card issues, than it would be good to know.
08:08:40 <Thaodan> one can run jolla-settings in gdb
08:08:59 <Thaodan> make sure to install debug symbols for nemo-qml-plugin-settings.
08:09:18 <flypig> Could you elaborate Thaodan? What would you look for? Or step through?
08:11:08 <abr> you can also add that logging to /usr/share/qt5/qtlogging.ini
08:11:37 <flypig> I think these deserve to go in the minutes.
08:11:40 <Thaodan> the file you linked above and https://github.com/sailfishos/nemo-qml-plugin-systemsettings/blob/master/src/udisks2monitor.cpp#L740
08:11:52 <flypig> #info <Thaodan> one can run jolla-settings in gdb. make sure to install debug symbols for nemo-qml-plugin-settings.
08:11:54 <Thaodan> abr: Just use export
08:11:57 <Thaodan> that's easier
08:12:27 <abr> i disagree. with qtlogging it affect the whole system, so you can use the launchers
08:12:34 <flypig> #info Thaodan suggested to step through the methods in https://github.com/sailfishos/nemo-qml-plugin-systemsettings/blob/master/src/udisks2monitor.cpp#L74
08:12:46 <flypig> #info <abr> you can also add that logging to /usr/share/qt5/qtlogging.ini
08:12:46 <abr> editing a text file is pretty easy ;)
08:12:57 <Thaodan> I implemented the refactored udisks2 support together with raine doing some refactorring on top.
08:13:28 <abr> one thing - i've always appended .debug to those logging rules, which enables the QCDebug output. I didn't know it worked without that
08:13:32 <Thaodan> abr: the issue is that in journal the messages will be lost if not making jour to only log jolla-settings.
08:13:38 <Thaodan> e.g.
08:13:49 <Thaodan> journalctl -f /usr/bin/jolla-settings
08:13:51 <abr> you can filter
08:14:13 <Thaodan> abr: That's what I said
08:15:01 <flypig> abr, it seems the .debug isn't needed, as long as you don't want to change the verbosity.
08:15:31 <abr> ok, so all logging is disabled in the settings app, and that rule enables up to warnings?
08:15:59 <flypig> abr, not for everything: only for memory card related output.
08:16:10 <abr> ok cool
08:16:13 <Thaodan> those are mostly debug stuff
08:16:20 <Thaodan> udisks2 can be quite verbose
08:17:36 <flypig> Hopefully this discussion will be useful for pherjung/kan_ibal when they look at the log. But time to move to general now.
08:17:40 <flypig> #topic General discussion (10 min)
08:17:48 <ExTechOp> Anyone else seen this happen: 10III crashes with beep when plugged into docking station https://forum.sailfishos.org/t/10iii-crashes-with-beep-when-plugged-into-docking-station/12481
08:17:53 <Thaodan> (ok it's warning but most stuff is more debug output)
08:18:00 <flypig> Note: OOnly 10 mins on general because we had a lot of questions
08:18:59 <piggz> general q ....  can porters get the 10ii volte rpm's for testing on ports?
08:19:01 <flypig> ExTechOp, that sounds dramatic. I've not experienced that.
08:19:44 <flypig> ExTechOp, so the defining factor that the docking station is attached to a display?
08:20:37 <Thaodan> piggz: I think those packages could be moved to hw-common and than used by porters
08:20:37 <abr> piggz: not officially right now. it'd be nice to get it in hw-common at some point when it's stable.
08:20:50 <ExTechOp> flypig As noted, it seems to depend on having a display connected to the docking station, and having had a computer use that display. If you unplug the display and/or have power cycled the docking station nothing happens and the phone happily charges from the USB-C.
08:20:51 <Thaodan> However I'm not the one who decides that
08:21:04 <Thaodan> tecnially there's no issue there from my pov.
08:21:32 <ExTechOp> So there is some kind of state information about the display mode or something like that stored in the docking station.
08:22:09 <ExTechOp> And this also seems to apply to displays with power delivery available.
08:22:24 <abr> usb seems to be a bit crashy on the sonys. do usb keyboards still cause a similar reaction?
08:23:18 <abr> would be good to see if it happens with sony aosp too - then it could be reported upstream?
08:23:20 <ExTechOp> abr No. It does seem take a surprisingly long time before the keyboard is detected by SFOS, like several seconds.
08:23:38 <abr> or was it when the keyboard was unplugged?
08:25:37 <attah_work> Keyboard unplug used to crash... doesn't on the latest model(s)
08:26:09 <Thaodan> I think that was any issue on the Xperia 10.
08:26:40 <Thaodan> I had the same issue every time I removed my usb-otg device while refacotring the exernal storage ui..
08:27:11 <ExTechOp> I've tested this mostly on my the typical "work from home" setup where I have the docking station with hardware attached (power, display, ethernet, USB devices like keyboard, mouse, camera) and a spot on the table for a laptop.
08:27:11 <ExTechOp> It's also a convenient location to charge a phone when I don't have the laptop there, and has worked fine for the Xperia 10II, but occasionally crashes the 10III.
08:27:28 <piggz> abr: part of making "stable" would be testing on other device right?
08:27:39 <Thaodan> It sounds like a kernel issues.
08:28:11 <ExTechOp> The Drama is great when the phone dies screaming :-D
08:28:26 <Thaodan> piggz: Yes I would say so. Other Sony's work without modifications, only newer devices could be an issue.
08:28:26 <flypig> We're hitting time here I'm afraid. Anything to add to the minutes on these topics?
08:28:48 <abr> piggz: eventually :)
08:28:53 <Thaodan> flypig, piggz: volte to hw-common maybe?
08:28:57 <ExTechOp> Another one is a small ActiveSync issue: https://forum.sailfishos.org/t/activesync-produces-incorrectly-timed-events-due-to-winter-summer-time-setting/12483/5
08:29:44 <abr> might be better to make the packages a bit more generic before they're moved. maybe merge the activation logic together in one.
08:29:44 <flypig> #info piggz requested that 10ii VoLTE rpms be moved to hw-common for use by porters.
08:30:24 <Thaodan> flypig: I wouldn't say just 10II, 10 III would make sense to
08:30:32 <flypig> ExTechOp, it's possible we have an internal report about that. I'll check and tie them together if we do.
08:30:46 <ExTechOp> flypig Thanks!
08:31:29 <flypig> #info Thaodan noted that this should be considered for the 10 III rpms too.
08:31:55 <flypig> #action flypig to check internal bug reports for https://forum.sailfishos.org/t/activesync-produces-incorrectly-timed-events-due-to-winter-summer-time-setting/12483
08:32:05 <flypig> Alright, it's time to wrap up I'm afraid.
08:32:19 <flypig> #topic Next meeting time and date (5 min)
08:32:24 <flypig> Proposing Thursday 18th August at 07:00am UTC
08:32:36 <piggz> my anniversary, and holiday time :D
08:32:47 <piggz> ill be in majorca
08:32:56 <flypig> Big celebrations in the piggz camp :D Congratulations in advance :)
08:32:59 <ExTechOp> Have fun, but this date does work for me.
08:33:07 <dryak_> Enjoy the holiday!
08:33:37 <fridl> Thanks to all!
08:33:43 <flypig> Alright, let's go with that (sorry piggz, but I'm sure you'll be thinking about other things!)
08:33:45 <flypig> #info Next meeting will be held on Thursday 18th August 2022 at 07:00am UTC: 2022-08-18T0700Z
08:34:01 <abr> he'll be logging in from the beach :)
08:34:16 <flypig> We'll have to make a note if he does!
08:34:27 <flypig> Thanks all for the nice meeting discussion.
08:34:28 <flypig> #endmeeting