08:00:01 <sledges> #startmeeting Sailfish OS, open source, collaboration -- 29th October 2020
08:00:01 <sailbot> Meeting started Thu Oct 29 08:00:01 2020 UTC. The chair is sledges. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:01 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:16 <sledges> #info Meeting information and agenda can be found here:
08:00:20 <sledges> #link https://forum.sailfishos.org/t/community-meeting-on-irc-29th-oct-2020/2899
08:00:25 <sledges> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please behave, respect timing and peers.
08:00:28 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with #info
08:00:32 <sledges> #info Simonas Leleiva - privateer for Jolla
08:00:51 <chriadam> #info Chris Adams - privateer for Jolla
08:01:06 <ggabriel> #info ggabriel - community
08:01:08 <ViGe> #info Ville Nummela - sailor @ Jolla
08:01:15 <Flohack> #info Florian Leeber - member of BoD UBports Foundation (Ubuntu Touch)
08:01:15 <gmc> #info gmc - community
08:01:26 <Thaodan> #info Björn Bidar - sailor @ Jolla
08:01:31 <flypig> #info David Llewellyn-Jones sailor @ Jolla
08:01:49 <karry_> #info Lukas Karas - developer, community member
08:02:06 <ljo_> #info  Leif-Jöran Olsson, community member
08:02:28 <thigg[m]> #info Thilo, community
08:02:49 <fridl> #info fridl, community
08:03:07 <abranson> #info Andrew Branson, sailing @ Jolla
08:03:51 <ahappyhuman> #info Chris, community
08:04:04 <flypig> Great that you could join us Florian.
08:04:38 <gmc> (i have a hard stop at 09:00 UTC, $dayjob)
08:04:57 <Flohack> flypig: It is a pleasure
08:04:58 <sledges> no worries gmc, your topic is early on
08:05:39 <sledges> speaking of topics...
08:05:39 <sledges> #topic That Qt update question again (5 min -- asked by rinigus)
08:05:43 <sledges> #info <rinigus> Any progress regarding Qt update?
08:05:49 <sledges> #info <rinigus> While it is old topic and nobody probably has high hopes regarding it, I would like to raise it to stimulate the internal discussion at Jolla.
08:05:58 <sledges> #info <rinigus> Ancient Qt does hinder SFOS progress and makes it impossible to collaborate with other mobile Linux platforms (Plasma Mobile in particular) on the development of applications.
08:06:09 <sledges> And for the answer:
08:06:18 <sledges> #info <Jolla> As stated also before, this is something we constantly evaluate. The current plan is still to proceed step by step, but we are not announcing any schedule for the update.
08:06:53 <rinigus1> thanks! do you plan to announce which step-by-step do you plan to take?
08:07:13 <sledges> without chair hat on, i could say that ESR52,60 progresses on the browser front, qt should hopefully kick in too
08:07:40 <Flohack> Just my 2 cents, UBports is doing now 5.12 upgrade, 5.15 was not working for us directly, kinda broke a lot of stuff
08:07:49 <ApBBB> it is one of the most needed updates the community needs :/  and yeah your clients might not need it but everyone can benefit from what the community does
08:08:03 <sledges> i think it was meant that version bumps will be incremental (probably merge current effort that's in the branched, and take it from there)
08:08:03 <thigg[m]> do I understand correctly, that the current problem is the license and the only possible way currently know of, is to buy the enterprise license by qt?
08:08:29 <rinigus1> Flohack: pity that 5.15 didn't work out. any main break points?
08:09:05 <Flohack> rinigus1: I dont have the details but plz feel free to ping me later
08:09:06 <rinigus1> sledges: so, 5.9 first then
08:09:23 <rinigus1> Flohack: will do, on UT channels then
08:09:23 <sledges> just speculating
08:09:44 <Flohack> thigg: The LTS is still free for OS projects I think. But that can have a lot of changes
08:10:00 <rinigus1> I wonder whether we should make /opt/qt then and test with non-silica apps
08:10:49 <sledges> if you got more specific questions, raise them during next meeting. constant poking is good :D
08:10:59 <thigg[m]> rinigus: that would solve the problem for the community then I guess?
08:11:24 <ApBBB> if possible moving to something that will solve the waylans issues we have would be much better
08:11:35 <thigg[m]> is anything preventing that? (asides from the burden of having multiple qt versions on the device?)
08:11:39 <rinigus1> thilo: solve is too bold word, as silica apps will be no go. also not sure how to make keyboard happy with it...
08:11:53 <thigg[m]> rinigus: i see
08:11:54 <rinigus1> thilo: mainly time investment and testing
08:12:09 <rinigus1> sledges: thanks, we will keep poking
08:12:32 <sledges> rinigus1: thank you for potential /opt smoke tests
08:12:36 <thigg[m]> hm so that could be something the community could try out maybe?
08:13:21 <rinigus1> sledges: I will think about it.
08:13:34 <rinigus1> as obs is running, shouldn't be too hard
08:13:40 <sledges> ;)
08:13:45 <sledges> perhaps re-using 5.9 effort branches
08:14:01 <sledges> let's move ahead
08:14:03 <sledges> #topic strategy regarding the other linux phone OS’s (10 min -- thigg)
08:14:13 <sledges> #info <thigg> The other linux phone os’s which are gathering around the pinephone have some attention and see development (manjaro, postmarket, ubports). Is any kind of collaboration with these platforms planned?
08:14:28 <sledges> #info <thigg> Is jolla having plans to encourage app developers to create apps which run on sailfishos and these platforms? How is the strategy regarding the pinephone. Is supporting it officially a priority of jolla?
08:14:54 <sledges> Answering:
08:14:56 <sledges> #info <Jolla> There are lot of mutual interests with this group, therefore it is evident that we are open for collaboration for defined targets that benefit the parties involved - and of course also the users of the platforms.
08:15:13 <sledges> #info <Jolla> We do keep close contact with members of these groups in all levels of process, from SW development to business development.
08:15:23 <sledges> (i'll mention your sidenote later on)
08:15:41 <rinigus1> 5.9 is so outdated that you cannot really collaborate in app development anyway. plamo is building regularly on 5.14-5.15 range, so I would be more interested in targeting that
08:16:01 <rinigus1> (linking qt and this topic together)
08:16:21 <thigg[m]> thank you, this looks good. Can you give any specifics about already happening collaboration or is this purely theoretical?
08:16:28 <Flohack> Well app development has a lot of roadblocks when it comes to cross-platform. Qt is one of them, but also data exchange between apps, access storage, access sensors & hardware... its done differently on every OS I would say
08:16:53 <Flohack> We had same question last Q&A: Can we avoid fragmentation in the App space? And the answer was probably not
08:16:57 <flypig> There's plenty of shared library usage, of course.
08:17:09 <chriadam> mardy from ubports has been very collaborative with various parts of our stack, e.g. contacts backend and accounts framework
08:17:10 <rinigus1> Flohack: from my experience, I would say that only UT does data access differently when you compare to other linuxes
08:17:22 <Flohack> Yeah we are sharing a lot of low-end code. And we wanted to get VoLTE flying :P
08:18:07 <Flohack> rinigus1: Yeah might be my limited view outside of our box. But we think a confinement model for Apps is really needed to make it ready for daily use of non-techs
08:18:27 <gmc> Wondering about UI aspects as well, 'foreign' apps will always look different from the ones targetting silica, ux paradigms might differ etc
08:18:30 <sledges> rinigus1: wouldn't a step-by-step testing require less delta each time (and reduce complexity), e.g. to first test other OSS components that might break against 5.9, then increment?
08:18:50 <flypig> Everyone would like to see VoLTE progress (and I know UBports has made progress there).
08:18:53 <rinigus1> it does take some effort to cover all main linux distros, but it is not too bad. mainly have to use some qml glue
08:19:03 <sledges> thigg[m]: this is as informative answer as i could get at this point:)
08:19:38 <Flohack> We also tried a bit to use Kirigami for example
08:19:49 <thigg[m]> are there any ideas about standardizing an api for sensor access?
08:19:57 <Flohack> That would work given no version conrflicts, but it looks kinda strange compared to other apps
08:20:15 <rinigus1> sledges: step-by-step - hard to say. unless 5.14 or .15 work perfectly in a go. but it will be impossible for us to test with silica
08:20:35 <Thaodan> I tried Kirigami too and for Android/iOS  its fine but for everything else no thanks.
08:20:36 <Flohack> thigg: Well for us its still QtSensor stuff or whats the common namespace. Thats I think ok
08:20:43 <ApBBB> working with silica would require NDAs right??
08:20:46 <ApBBB> from jolla
08:20:48 <sledges> rinigus1: i understand, silica will be an internal effort for sure
08:20:55 <Thaodan> Qt Quick Controls 2 helps far more
08:21:10 <rinigus1> Flohack: I think Kirigami could work fine for UT and SFOS (it has been developed a lot recently). "just" would have to style it accordingly for Silica and UT apps.
08:21:13 <Flohack> QQC2 would be fine for us too
08:21:32 <rinigus1> QQC2 does not have pagestack which is swipable. as far as I know
08:21:36 <Flohack> Yeah Kirigami is "technically" in but not form a UX standpoint
08:21:48 <sledges> ApBBB: we already have our seasoned community contributors working with closed source components (via NDA)
08:22:09 <sledges> like Damien (dcaliste), contrib champion he is:)
08:23:01 <ApBBB> speaking of damiens work -and unrelated to the question- someone has to give an update on what happened to the pgp stuff
08:23:19 <ApBBB> there was supposed to be ablog post or something
08:23:24 <sledges> post a topic:)
08:23:30 <sledges> for the next meeting
08:23:31 <rinigus1> Flohack: main app flow from developer POV is similar for silica, kirigami, ut. kirigami has a menu, which somehow has to be killed, but otherwise it can be styled to fit SFOS and UT quite well, I think. as the app logic is rather close
08:24:04 <rinigus1> same styling is needed for QQC2 as well
08:24:39 <Flohack> rinigus1: agreed, but I think first we would need to see other aspects like packaging format and confinement, Qt or Kirigami is not the real issue for us
08:24:43 <ApBBB> sledges most likely i will :)
08:25:20 <Flohack> What also will happen in 2021 is upgrading to Ubuntu 20.04, and that will bring us on par with a few more things
08:25:25 <rinigus1> Flohack: I though you are happy with your packaging at UT. or do you plan to change it?
08:26:00 <Flohack> rinigus1: Well if community and devs think we should collaborate more on cross-platform stuff this needs to be revisited. Currently we are happy yes
08:26:55 <ApBBB> moving everything to a single app package format would surely help with collaboration
08:26:57 <rinigus1> again, from personal experience: porting app to UT is relatively simple as soon as you get someone to package it for you :) . someone who knows how it works on UT side of things
08:27:16 <Thaodan> offtopic?
08:27:21 <rinigus1> ApBBB: I don't see it happening - moving all to clickable
08:27:43 <ApBBB> there was a discussion a looooooooooooooong time ago  in a meeting about flatpacks in sfos
08:27:59 <sledges> #info Chatting about what UBports is using, discussing frameworks' portability like Kirigami (read full logs)
08:27:59 <gmc> rinigus1: perhaps some general guidelines on how to write apps that are easy to port between platforms would be useful?
08:28:05 <rinigus1> those have their own flaws
08:28:27 <gmc> rinigus1: so that if i am writing a sailfish app, i can keep certain things in mind already to help me port it to ubports later on
08:28:46 <gmc> (but i guess good programming practices of seperating models, views etc already help a great deal)
08:29:26 <flypig> Yeah, something like that would be good, gmc.
08:29:27 <sledges> right after rinigus1 comments on appportingguide, we'll move on:)
08:29:33 <Flohack> I wonder if we could achieve a thing like having a Qt wrapper that abstracts things that are different. Like interacting with push notifications etc.
08:30:03 <rinigus1> gmc: yeah, pretty much. you can look into pure maps "qml/platform*" for example. that code has been spinned off as well, but I don't know how far it is now
08:30:09 <flypig> Even documenting it would be a good start, as a precursor to a wrapper.
08:30:51 <Flohack> flypig: True, we lack docs a lot, that makes us so slow sometimes. Also for device enablement, porting guides are rearely up2date
08:31:21 <gmc> we all like writing code, documentation not so much :)
08:31:27 <flypig> Yes, it's not easy of course. Lots of work keeping things up-to-date.
08:32:01 <Thaodan> Languages that want you to use inline documentation are pretty nice
08:32:02 <sledges> #info appportingguide across platforms would be nice, but while doc may take a while to write (and read), here's some platform.* dirs to look at
08:32:05 <sledges> #link https://github.com/rinigus/pure-maps/tree/master/qml
08:32:15 <Thaodan> Makes writing docs easier
08:32:22 <rinigus1> issue at pure maps https://github.com/rinigus/pure-maps/issues/330
08:32:37 <rinigus1> spin-off: https://gitlab.com/dylanvanassche/convergence-components
08:32:52 <sledges> #info and related issue:
08:32:54 <sledges> #link https://github.com/rinigus/pure-maps/issues/330
08:32:56 <sledges> ok time to move on
08:33:03 <sledges> #topic strategy regarding the other linux phone OS’s (10 min -- thigg)
08:33:05 <Flohack> rinigus1: BTW PureMaps is on a good way to at least be a bit cross-platform right
08:33:14 <sledges> #undo
08:33:14 <sailbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f3d289ef588>
08:33:18 <sledges> #topic storing app credentials on sailfish os (10 min -- asked by gmc)
08:33:25 <sledges> #info <gmc> Apps may use credentials to log in to external services, and need to do so in a secure way - the sailfish-secrets library / daemon provides a solution, however it is not allowed to use it when publishing an app to the jolla store.
08:33:45 <sledges> #info <gmc> What is the recommended way for an app to securely store credentials and be publishable in the jolla store? Are there plans to allow the sailfishsecrets service to the list of allowed packages to depend on? Sailfishsecrets seems to be pretty stable (according to the commit history):
08:33:50 <rinigus1> Flohack: trying to. in the end it helps as you can develop just on desktop :)
08:33:52 <sledges> #link https://github.com/sailfishos/sailfish-secrets/commits/master
08:34:29 <sledges> #info <Jolla> Even though it is an extensible framework in a source and binary compatible way, we may still alter other aspects, which might break stored data consistency. Hence why it's still not in the Harbour.
08:35:53 <gmc> So, sailfishsecrets seems like a good way to store credentials, as it is managed by the os and only the app that stores a secret is allowed to retrieve it. Something like that is really needed.
08:36:15 <ahappyhuman> Is Sailfish Secrets comparable to Gnome Keyring and KWallet?
08:36:17 <gmc> I want to use as many native apps as possible, but I see apps that are in the jolla store with disclaimers 'credentials are stored in plaintext'.
08:36:55 <gmc> So this pushes secure apps out of the harbour, and into third-party app stores. The whole app store situation was quite confusing to me when I first got into sailfish, and I think I now have 5 appstores and no clue anymore what app comes from what store
08:37:30 <ahappyhuman> 5 appstores? Is that including or excluding the android appstores?
08:37:33 <ggabriel> gmc: I agree that this is a really nice thing to have; however, if the worry is using apps, encrypting your home partition would mitigate some (but not all) security aspects
08:37:35 <chriadam> ahappyhuman: somewhat.  it has support for different collections of secrets, for example.  it also supports a variety of cryptographic operations (via backend plugins, e.g. openssl) etc.
08:37:48 <gmc> ahappyhuman: i think 3 native ones, 3 android ones (so that's 6 :)
08:38:12 <ApBBB> is anything else than the official and openrepos??
08:38:14 <gmc> ggabriel: that would not really mitigate the concern at all, since any other app will still be able to access the credentials, right?
08:38:26 <ahappyhuman> chriadam: ah, okay.
08:38:30 <KeeperoftheKeys> encrypting the home won't do anything if there is a browser exploit or a bad app running since home is not encrypted while you are running stuff
08:38:42 <ggabriel> gmc: I did say "some (but not all)" - we should never install dodgy apps anyway ;)
08:38:51 <chriadam> fwiw: this is my personal opinion only:
08:39:07 <thigg[m]> hard to tell from the outside if an app is dodgy
08:39:09 <chriadam> the API of sailfish-secrets is nice.  but the implementation has NOT been properly reviewed by a domain expert (crypto expert)
08:39:11 <gmc> ggabriel: that's the problem, harbour would presumably not allow dodgy apps, openrepos does not have any quality gates does it?
08:39:20 <chriadam> so relying on it to be secure, at this stage, is ... optimistic.
08:39:24 <ggabriel> gmc: correct
08:39:30 <sledges> there are some apps that encrypt their keys with a non-stored password key (like foilauth), but this would mean every app reinventing the wheel, right?
08:39:54 <KeeperoftheKeys> yes
08:39:59 <thigg[m]> optimistic security ;)
08:40:21 <KeeperoftheKeys> having a keyring that an app can only retrieve it's own data from is far better
08:40:25 <gmc> chriadam: ok, that is good to know, so probably it would be good to get some hackers / crypto nerds to take a good look at it.. i could probably rally some
08:40:31 <chriadam> please do
08:40:34 <chriadam> very much please
08:40:38 <Thaodan> I think implementing org.Freedesktop.Secretstorage woild help on cross platform api usage
08:40:44 <KeeperoftheKeys> if the OS is truly capable to guarantee that the app only accesses its' own stuff
08:40:56 <thigg[m]> thaodan: +1
08:41:03 <gmc> sledges: having to enter an unlock key in every app imho is a ux disaster.. having the os handle it is much better imho
08:41:22 <flypig> chriadam, that doesn't mean it's not worth using, if the API stays the same and the backend can be fixed if there's an issue.
08:41:27 <gmc> chriadam: ok, I will make a note and ask some friends
08:42:39 <chriadam> flypig: yes, I agree.  but we might not be able to guarantee that the data will remain .. e.g. if the bookkeeping database is removed, because it proves completely insecure.
08:42:54 <chriadam> so, you can use the api, but your data stored in it might vanish at some point if it proves insecure...
08:42:57 <chriadam> I mean...
08:43:02 <flypig> Hmm. That's a good point, yes.
08:43:27 <gmc> chriadam: i wouldn't be bothered with that, if it's announced properly.. i can re-enter my credentials.. not sure what others think
08:43:56 <ahappyhuman> Thaodan: that sounds nice. I'm looking into making a cross-platform app which needs to store login tokens, but having to deal with KWallet, Gnome Keyring and Sailfish Secrets myself kinda would be suboptimal
08:44:16 <flypig> With some things (e.g. 2FA tokens) they may not be so easy to reenter.
08:44:36 <Thaodan> ahappyhuman: KWallet doesn't implemented the SecretStorage api either but this would be the best start I think.
08:44:52 <gmc> org.Freedesktop.Secretstorage only stores secrets right? sailfishsecrets also provides encryption/decryption of bulk data if i'm not mistaken
08:45:08 <Thaodan> Yes
08:45:21 <gmc> which is convenient for storing private data (like VTODO items in my case) in a sqlite db
08:45:29 <KeeperoftheKeys> If it is known ahead of time you can either re-enter or maybe even export/import to the new more secure setup
08:45:41 <Thaodan> But as the question was about storing secrets and not en-/descryption
08:45:54 <Thaodan> *decryption
08:45:56 <gmc> Thaodan: fair point :)
08:47:01 <gmc> anyway, wrapping up, apart from a security audit, what would be required to get sailfishsecrets accepted in harbour? or is a rewrite of a completely new thing required?
08:47:07 <gmc> (ie org.Freedesktop.Secretstorage)
08:47:13 <flypig> KeeperoftheKeys, yeah, true. As gmc says, it just needs some advance notice.
08:47:36 <KeeperoftheKeys> it could even be done automagically (or attempted)
08:48:03 <chriadam> can expose data stored in screts via org.fd.ss and vice versa.  same as dcaliste's plugins for gpg
08:48:30 <chriadam> actually org.fd.ss was one of the things we looked at when doing the api study, so there are many isomorphic concepts.
08:48:34 <chriadam> so should be straightforward.
08:50:23 <dcaliste> chriadam: I can give a look, but I guess org.Freedesktop.Secretstorage is more of an API than a backend, right ?
08:50:32 <chriadam> ah, right
08:50:53 <chriadam> I guess I mean: data stored in sailfish-secrets could be exposed via that interface
08:50:54 <dcaliste> What I've done with the GnuPG plugin was to expose the GnuPG backend through the Sceret API.
08:50:55 <chriadam> if needed
08:51:31 <chriadam> but I personally don't see too much value there
08:51:37 <dcaliste> But I agree, that implementing the Freedesktop API (if it's the case) with the Secret backend should be quite easy.
08:52:07 <chriadam> I mean, if someone is targeting Sailfish OS then they should use the secrets API, IMO (eventually, once we get it properly reviewed etc).
08:52:30 <sledges> so, these are the states we have at the moment, and a regular reminder about needed things should be able to bubble up into priorities
08:52:48 <sledges> but as you should already know, no promises or timelines at this point:)
08:52:57 <sledges> let's move it the next one
08:53:01 <gmc> well, I have an action item to rally some crypto-nerds for a review, hoping that that would help things along
08:53:11 <sledges> thanks very much indeed on that
08:53:12 <chriadam> that would be a huge help, gmc.
08:53:15 <chriadam> ty
08:53:16 <flypig> gmc, can you give an update next meeting?
08:53:40 <gmc> flypig: yes, that is possible (depending on the time and my $dayjob commitments at that time)
08:53:53 <sledges> you can leave/writeup in the forum announcement
08:54:03 <chriadam> no rush.
08:54:15 <flypig> gmc, of course. No obligation, but it would be good to know.
08:54:30 <dcaliste> Thank you gmc for this, indeed !
08:54:30 <sledges> #action gmc to rally some crypto-nerds to do security audit on sailfish-secrets framework, if and when they have time
08:54:46 <sledges> let's go:)
08:54:46 <sledges> #topic General Discussion (30 min)
08:54:49 <sledges> time to answer since it was posted
08:54:56 <sledges> whoops
08:55:01 <sledges> ahappyhuman: your topic will be moved to next meeting as we haven't had enough time to answer since it was posted
08:55:04 <Flohack> UBports would be interested on the outcome, we have an accounts backend, but idk how well designed it is.
08:55:10 <sledges> #link https://forum.sailfishos.org/t/community-meeting-on-irc-29th-oct-2020/2899/7
08:55:28 <dcaliste> gmc, the doxygen documentation of the package when built, can give a good overview in my opinion, to know where to look at first.
08:55:33 <ApBBB> are there any cool things comming in the next SFOS release??
08:55:53 <rinigus1> chriadam: if possible, we should write apps that can be ported from SFOS easily. hence it makes sense to use universal APIs
08:55:56 <ahappyhuman> sledges: no problem
08:56:01 <sledges> ApBBB esr60 should :)
08:56:29 <ApBBB> sledges nice. is there a plan to follow the esrs up to latest??
08:56:30 <gmc> dcaliste: thanks, will keep that in mind
08:56:40 <chriadam> rinigus1: that's a valid perspective.  I just think that abstractions have costs (both to the app developer, and to the platform developers who maintain those abstractions)
08:56:58 <chriadam> you know my mantra: reduce platform surface, reduce external dependencies ;-)
08:57:09 <rinigus1> :)
08:57:33 <ApBBB> chriadam the main problem is that the distro model linux follows is deeply flawed.
08:57:35 <KeeperoftheKeys> sledges: both SSL libraries on SFOS are severly outdated
08:57:49 <sledges> KeeperoftheKeys: see my answer in the forum
08:57:57 <sledges> it's being updated
08:58:26 <KeeperoftheKeys> great :)
08:58:31 <sledges> aye :)
08:58:34 <Thaodan> KeeperoftheKeys: thats not true well at least not anymore as the next release will have OpenSSL 1.1.1h
08:58:44 <KeeperoftheKeys> In the mean time I'll tell our users to download before listening
08:59:12 <thigg[m]> KeeperoftheKeys: just schedule download and the autoplayback
08:59:24 <thigg[m]> would be a cool feature anyways
08:59:30 <thigg[m]> *then
08:59:32 <KeeperoftheKeys> Thaodan: next release is great, but currently in the wild SSL support on SFOS is at ~2016 levels
09:00:01 <Thaodan> We use the latest version of OpenSSL 1.0 that was supported until recently
09:00:27 <thigg[m]> Btw is the bluez thing fixed in the next release of SFOS?
09:00:33 <thigg[m]> or was it even vulnerable?
09:00:37 <ApBBB> other that qt are there other parts of SFOS that need to be updated to become more "modern" (package wise)
09:01:30 <rinigus1> ApBBB: good question!
09:01:35 <KeeperoftheKeys> Thaodan: it may have been supported until recently but it lacked support for the "latest and greatest" in the field ie. TLS 1.3
09:02:08 <KeeperoftheKeys> ApBBB: the kernel :)
09:02:52 <ApBBB> upper in the stack i mean. in an ideal world we would be able to run out devices with mainline
09:03:02 <Nico[m]> OpenSSL 1.1 would be nice, I need some functions from it :D
09:03:08 <ApBBB> but we don't live in an ideal world
09:03:31 <sledges> you can see new package versions coming in constantly: https://git.sailfishos.org/explore
09:03:52 <ViGe> KeeperoftheKeys: There is no "the kernel" as there are several kernel versions used by different devices...
09:04:27 <KeeperoftheKeys> I know which is very sad :/ I would love to have a more up to date kernel both on my JP1 and my Xperia X
09:04:46 <rinigus1> related to kernel - sony open devices folks are working on mainlining rather intensively. don't know what is the current status with it though (there will be a talk about it)
09:04:46 <ahappyhuman> I was looking into implementing some kind of nightmode into Sailfish OS. Most Linux desktop environments seem to do it by the compositor poking the Linux DRM for some form of gamma correction. I'm not familiar with the lower level graphical stack on Linux and Sailfish OS, but does Sailfish OS use Linux's DRM on hybris adaptations?
09:04:47 <KeeperoftheKeys> but all the binary blobs don't make it easy
09:05:22 <flypig> ahappyhuman, that'd be a neat feature to have.
09:06:07 <ApBBB> rinigus1 isnt the problem that the blobs are compiled for android (hence libhybris) and you cant get blobs compiled with gcc
09:06:10 <ApBBB> ?
09:06:12 <fridl> Is there some progress in libhybris to support Android 10 devices? Or at least a timeframe to do so?
09:06:21 <KeeperoftheKeys> at least for the Xperia X we could have a fairly up to date kernel together with the XA2 and 10 (according to opendevices the can all be at kernel 4.9
09:06:22 <sledges> very soon
09:06:28 <chriadam> ahappyhuman: denexter or frajo or abranson might be best to answer
09:06:45 <Thaodan> AppBBB: even then the kernel is stuck on an old version
09:07:06 <ViGe> android is moving towards having a common kernel for all devices - I hope this will make things easier for us as well
09:07:55 <Thaodan> I think its similar to  trebble: what helps them to use upstream/less changes helps us
09:08:17 <abranson> chriadam: I'm not sure how it should be done, but I think coderus had an app that did that. it was one of the ones that got broken by the overlay breakage
09:08:37 <KeeperoftheKeys> when they decide phones are just computers and users should have access and choice of OS that will be good times
09:08:56 <rinigus1> ApBBB: don't know much about blobs. so, no comment in this respect
09:09:54 <KeeperoftheKeys> Doesn't the UX design of native SFOS apps obviate the need for a nightmode? there's almost never white on the screen except for webpaes etc
09:10:08 <fridl> And was there any plan for today to discuss the VoLTE things with the Ubports people?
09:10:32 <ahappyhuman> abranson: yes, he had an application that worked by creating an overlay window. I was interested in bringing it into the compositor, like kwin does. That would give more "natural" looking results and if it can be achieved by setting the gamma correction on the GPU, the night mode shouldn't be visible in screenshots.
09:10:38 <ApBBB> KeeperoftheKeys light/dark ambiances??
09:11:57 <thigg[m]> sledges: regarding my sidenote, is it planned to post something like the minutes of this meeting to the blog?
09:12:10 <KeeperoftheKeys> ApBBB: yes but ambiance is the choice of the user, maybe we could have an option to allow switch in ambiance based on time of day
09:12:10 <ApBBB> speaking of UX/UI there are many areas that need to be taken care of (use, looks and performace) and it doesn't seem to be much progress :/
09:12:28 <abranson> ahappyhuman: yeah, no idea about that sorry. might be a good question for the next meeting so it can gather some internal opinions from gfx sailors
09:12:43 <ahappyhuman> I'll submit it then.
09:13:18 <ahappyhuman> I also want to note that I'm not a gfx expert myself :)
09:13:29 <ApBBB> BTW i noticed Adam pigg on twitter has support for mouse on sfos on pine tablet. is this work public??
09:13:37 <sledges> fridl: there wasn't such topic announced for today
09:13:43 <sledges> thigg[m]: sorry forgot about that
09:14:13 <sledges> #info forgotten bit from thigg's topic earlier:
09:14:14 <sledges> #info <thigg> Sidenote: the UBPorts forum is publishing the results of their Q&A streams to the blog, which looks quite good, because you get some biweekly information there. Maybe it would be a good idea to publich the minutes of the community meetings in a separate section in the blog?
09:14:31 <fridl> sledges I just thought as Florian is around it could be worth ;-)
09:15:09 <thigg[m]> I thought it would make activity a bit more visible
09:15:48 <sledges> #info <Jolla> the current primary community communications platform is the forum, where these minutes can be found easily in the first (Announcements) section; more visibility would be to promote forum in general
09:16:22 <flypig> thigg[m], do you have a link? Is this what you mean? https://ubports.com/blog/ubport-blogs-news-1/post/ubuntu-touch-q-a-86-3725
09:16:22 <sledges> fridl: but monich is not around ;) hence a topic would've been better
09:16:35 <thigg[m]> yes
09:17:27 <thigg[m]> Its just my userstory: if I want to know whats going on, I look at the blog of the project. so i looked at: https://ubports.com/blog/ and, well, it looks quite alive, just because of these
09:18:09 <gmc> KeeperoftheKeys: i saw an app somewhere that switches the ambiance on a schedule
09:18:13 <Nico[m]> Agreed, the jolla blog can look quite empty
09:18:41 <thigg[m]> maybe just add a widget of the anouncement section of the forum?
09:19:26 <Flohack> Guys was a pleasure, have to leave for dayjob ^^
09:19:31 <flypig> Yeah, it's a good point. The jolla blog is quite low traffic by design though. It would perhaps be good to make the forum more prominent on the jolla.com though. (just my opinion!)
09:19:39 <chriadam> goodbye Flohack, thanks for joining
09:19:43 <flypig> Thanks for joining us Flohack.
09:19:59 <Flohack> Sure ^^ thanks for inviting me
09:20:11 <ahappyhuman> Goodbye!
09:20:41 <gmc> KeeperoftheKeys: https://openrepos.net/content/schturman/auto-ambience-changer (quite old, and a bit cumbersome)
09:20:48 <sledges> 4 more minutes
09:21:06 <gmc> would be nice if an ambiance could also configure silent mode and vibration btw, on a tangent
09:21:49 <ApBBB> i'll ask it here since there are more devs around. is there a correct way to set up a kbd switch shortcut on SFOS (with a normal keyboard)
09:21:54 <ggabriel> I used to have a silent ambience, doesn't that work any more?
09:22:31 <Thaodan> gmc: Situations maybe?
09:22:31 <Thaodan> Flohack: Did you have some overview on the VoLTE progress?
09:22:31 <Thaodan> like links of something
09:22:31 <Thaodan> *or something
09:22:33 <thigg[m]> KeeperoftheKeys: OT, regarding gpodder: should I move forward implementing random stuff that comes to my mind, or do you have suggestions on what to do?
09:22:41 <ggabriel> gmc: you can definitely set the volume (or rid of all tones/alerts); vibration is another thing though
09:23:09 <flypig> ApBBB, I'm not sure what you mean by that. Do you mean a physical keyboard?
09:23:13 <gmc> ggabriel: true
09:23:36 <KeeperoftheKeys> thigg[m]: Next week I'm on vacation and going to give gPodder some TLC
09:23:49 <ggabriel> gmc: but have a look at situations, like Thaodan says
09:23:59 <flypig> Thaodan, +1 situations is worth looking at for that kind of thing.
09:25:28 <sledges> ApBBB: Venemo is the best man to answer
09:25:38 <thigg[m]> KeeperoftheKeys: nice!
09:25:43 <sledges> (he implemented the side-swipe kbd switch)
09:26:12 <Venemo> sorry guys I'm late to the party, what was the question?
09:26:23 <sledges> Venemo: "is there a correct way to set up a kbd switch shortcut on SFOS (with a normal keyboard)"
09:26:33 <Venemo> what is a kbd switch shortcut?
09:26:58 <sledges> keyboard layout switch "button(?)"
09:27:12 <thigg[m]> KeeperoftheKeys: just ping me, if you have something in your mind that should be done. Otherwise I will just do things that I'm missing... like scheduled updates...
09:27:36 <Venemo> I don't understand the question. There is a button, you tap it, choose your layout and it switches.
09:27:58 <sledges> i think he wants a dedicated button
09:28:03 <sledges> to e.g. always go to one particular layout
09:28:40 <flypig> In an app? For example, adding a button to an app to switch keyboards maybe?
09:28:52 <Venemo> ApBBB: please clarify your question
09:28:59 <sledges> during the next meeting ;)
09:29:05 <sledges> #topic Next meeting time and date (5 min)
09:29:08 <sledges> Proposing 12th November at 8am UTC
09:29:32 * ggabriel ayes
09:29:50 <gmc> works for me
09:29:56 <flypig> It's a Thursday. It's in two weeks. It's at the same time. Sounds good to me :)
09:30:03 <gmc> ggabriel: i have situations installed indeed :)
09:30:36 <chriadam> +1
09:30:49 <chriadam> thanks all, /me heads home, gnight.
09:30:59 <sledges> and no national holidays or plannings planned:)
09:31:00 <sledges> #info Next meeting will be held on Thursday 12th November 2020 at 8:00am UTC:  2020-11-12T08Z
09:31:07 <sledges> thanks y'all!
09:31:09 <sledges> #endmeeting