Flohack | Good Morning!" | 07:44 |
---|---|---|
gmc | Morning! | 07:52 |
chriadam | gmorning | 07:55 |
sledges | #startmeeting Sailfish OS, open source, collaboration -- 29th October 2020 | 08:00 |
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 |
sailbot | Useful Commands: #action #agreed #help #info #idea #link #topic. | 08:00 |
*** sailbot changes topic to " (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:00 | |
sledges | #info Meeting information and agenda can be found here: | 08:00 |
sledges | #link https://forum.sailfishos.org/t/community-meeting-on-irc-29th-oct-2020/2899 | 08:00 |
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 |
sledges | #topic Brief introduction (5 min). Please prefix your name/handle with #info | 08:00 |
*** sailbot changes topic to "Brief introduction (5 min). Please prefix your name/handle with #info (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:00 | |
sledges | #info Simonas Leleiva - privateer for Jolla | 08:00 |
chriadam | #info Chris Adams - privateer for Jolla | 08:00 |
ggabriel | #info ggabriel - community | 08:01 |
ViGe | #info Ville Nummela - sailor @ Jolla | 08:01 |
Flohack | #info Florian Leeber - member of BoD UBports Foundation (Ubuntu Touch) | 08:01 |
gmc | #info gmc - community | 08:01 |
Thaodan | #info Björn Bidar - sailor @ Jolla | 08:01 |
flypig | #info David Llewellyn-Jones sailor @ Jolla | 08:01 |
karry_ | #info Lukas Karas - developer, community member | 08:01 |
ljo_ | #info Leif-Jöran Olsson, community member | 08:02 |
thigg[m] | #info Thilo, community | 08:02 |
fridl | #info fridl, community | 08:02 |
abranson | #info Andrew Branson, sailing @ Jolla | 08:03 |
ahappyhuman | #info Chris, community | 08:03 |
flypig | Great that you could join us Florian. | 08:04 |
gmc | (i have a hard stop at 09:00 UTC, $dayjob) | 08:04 |
Flohack | flypig: It is a pleasure | 08:04 |
sledges | no worries gmc, your topic is early on | 08:04 |
sledges | speaking of topics... | 08:05 |
sledges | #topic That Qt update question again (5 min -- asked by rinigus) | 08:05 |
*** sailbot changes topic to "That Qt update question again (5 min -- asked by rinigus) (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:05 | |
sledges | #info <rinigus> Any progress regarding Qt update? | 08:05 |
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 |
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:05 |
sledges | And for the answer: | 08:06 |
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 |
rinigus1 | thanks! do you plan to announce which step-by-step do you plan to take? | 08:06 |
sledges | without chair hat on, i could say that ESR52,60 progresses on the browser front, qt should hopefully kick in too | 08:07 |
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 |
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:07 |
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 |
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 |
rinigus1 | Flohack: pity that 5.15 didn't work out. any main break points? | 08:08 |
Flohack | rinigus1: I dont have the details but plz feel free to ping me later | 08:09 |
rinigus1 | sledges: so, 5.9 first then | 08:09 |
rinigus1 | Flohack: will do, on UT channels then | 08:09 |
sledges | just speculating | 08:09 |
Flohack | thigg: The LTS is still free for OS projects I think. But that can have a lot of changes | 08:09 |
rinigus1 | I wonder whether we should make /opt/qt then and test with non-silica apps | 08:10 |
sledges | if you got more specific questions, raise them during next meeting. constant poking is good :D | 08:10 |
thigg[m] | rinigus: that would solve the problem for the community then I guess? | 08:10 |
ApBBB | if possible moving to something that will solve the waylans issues we have would be much better | 08:11 |
thigg[m] | is anything preventing that? (asides from the burden of having multiple qt versions on the device?) | 08:11 |
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 |
thigg[m] | rinigus: i see | 08:11 |
rinigus1 | thilo: mainly time investment and testing | 08:11 |
rinigus1 | sledges: thanks, we will keep poking | 08:12 |
sledges | rinigus1: thank you for potential /opt smoke tests | 08:12 |
thigg[m] | hm so that could be something the community could try out maybe? | 08:12 |
rinigus1 | sledges: I will think about it. | 08:13 |
rinigus1 | as obs is running, shouldn't be too hard | 08:13 |
sledges | ;) | 08:13 |
sledges | perhaps re-using 5.9 effort branches | 08:13 |
sledges | let's move ahead | 08:14 |
sledges | #topic strategy regarding the other linux phone OS’s (10 min -- thigg) | 08:14 |
*** sailbot changes topic to "strategy regarding the other linux phone OS’s (10 min -- thigg) (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:14 | |
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 |
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 |
sledges | Answering: | 08:14 |
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:14 |
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 |
sledges | (i'll mention your sidenote later on) | 08:15 |
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:15 |
rinigus1 | (linking qt and this topic together) | 08:16 |
thigg[m] | thank you, this looks good. Can you give any specifics about already happening collaboration or is this purely theoretical? | 08:16 |
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 |
Flohack | We had same question last Q&A: Can we avoid fragmentation in the App space? And the answer was probably not | 08:16 |
flypig | There's plenty of shared library usage, of course. | 08:16 |
chriadam | mardy from ubports has been very collaborative with various parts of our stack, e.g. contacts backend and accounts framework | 08:17 |
rinigus1 | Flohack: from my experience, I would say that only UT does data access differently when you compare to other linuxes | 08:17 |
Flohack | Yeah we are sharing a lot of low-end code. And we wanted to get VoLTE flying :P | 08:17 |
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 |
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 |
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 |
flypig | Everyone would like to see VoLTE progress (and I know UBports has made progress there). | 08:18 |
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:18 |
sledges | thigg[m]: this is as informative answer as i could get at this point:) | 08:19 |
Flohack | We also tried a bit to use Kirigami for example | 08:19 |
thigg[m] | are there any ideas about standardizing an api for sensor access? | 08:19 |
Flohack | That would work given no version conrflicts, but it looks kinda strange compared to other apps | 08:19 |
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 |
Thaodan | I tried Kirigami too and for Android/iOS its fine but for everything else no thanks. | 08:20 |
Flohack | thigg: Well for us its still QtSensor stuff or whats the common namespace. Thats I think ok | 08:20 |
ApBBB | working with silica would require NDAs right?? | 08:20 |
ApBBB | from jolla | 08:20 |
sledges | rinigus1: i understand, silica will be an internal effort for sure | 08:20 |
Thaodan | Qt Quick Controls 2 helps far more | 08:20 |
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 |
Flohack | QQC2 would be fine for us too | 08:21 |
rinigus1 | QQC2 does not have pagestack which is swipable. as far as I know | 08:21 |
Flohack | Yeah Kirigami is "technically" in but not form a UX standpoint | 08:21 |
sledges | ApBBB: we already have our seasoned community contributors working with closed source components (via NDA) | 08:21 |
sledges | like Damien (dcaliste), contrib champion he is:) | 08:22 |
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 |
ApBBB | there was supposed to be ablog post or something | 08:23 |
sledges | post a topic:) | 08:23 |
sledges | for the next meeting | 08:23 |
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:23 |
rinigus1 | same styling is needed for QQC2 as well | 08:24 |
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 |
ApBBB | sledges most likely i will :) | 08:24 |
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 |
rinigus1 | Flohack: I though you are happy with your packaging at UT. or do you plan to change it? | 08:25 |
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 |
ApBBB | moving everything to a single app package format would surely help with collaboration | 08:26 |
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:26 |
Thaodan | offtopic? | 08:27 |
rinigus1 | ApBBB: I don't see it happening - moving all to clickable | 08:27 |
ApBBB | there was a discussion a looooooooooooooong time ago in a meeting about flatpacks in sfos | 08:27 |
sledges | #info Chatting about what UBports is using, discussing frameworks' portability like Kirigami (read full logs) | 08:27 |
gmc | rinigus1: perhaps some general guidelines on how to write apps that are easy to port between platforms would be useful? | 08:27 |
rinigus1 | those have their own flaws | 08:28 |
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 |
gmc | (but i guess good programming practices of seperating models, views etc already help a great deal) | 08:28 |
flypig | Yeah, something like that would be good, gmc. | 08:29 |
sledges | right after rinigus1 comments on appportingguide, we'll move on:) | 08:29 |
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:29 |
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 |
flypig | Even documenting it would be a good start, as a precursor to a wrapper. | 08:30 |
Flohack | flypig: True, we lack docs a lot, that makes us so slow sometimes. Also for device enablement, porting guides are rearely up2date | 08:30 |
gmc | we all like writing code, documentation not so much :) | 08:31 |
flypig | Yes, it's not easy of course. Lots of work keeping things up-to-date. | 08:31 |
Thaodan | Languages that want you to use inline documentation are pretty nice | 08:32 |
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 |
sledges | #link https://github.com/rinigus/pure-maps/tree/master/qml | 08:32 |
Thaodan | Makes writing docs easier | 08:32 |
rinigus1 | issue at pure maps https://github.com/rinigus/pure-maps/issues/330 | 08:32 |
rinigus1 | spin-off: https://gitlab.com/dylanvanassche/convergence-components | 08:32 |
sledges | #info and related issue: | 08:32 |
sledges | #link https://github.com/rinigus/pure-maps/issues/330 | 08:32 |
sledges | ok time to move on | 08:32 |
sledges | #topic strategy regarding the other linux phone OS’s (10 min -- thigg) | 08:33 |
*** sailbot changes topic to "strategy regarding the other linux phone OS’s (10 min -- thigg) (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:33 | |
Flohack | rinigus1: BTW PureMaps is on a good way to at least be a bit cross-platform right | 08:33 |
sledges | #undo | 08:33 |
sailbot | Removing item from minutes: <MeetBot.items.Topic object at 0x7f3d289ef588> | 08:33 |
sledges | #topic storing app credentials on sailfish os (10 min -- asked by gmc) | 08:33 |
*** sailbot changes topic to "storing app credentials on sailfish os (10 min -- asked by gmc) (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:33 | |
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 |
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 |
rinigus1 | Flohack: trying to. in the end it helps as you can develop just on desktop :) | 08:33 |
sledges | #link https://github.com/sailfishos/sailfish-secrets/commits/master | 08:33 |
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:34 |
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:35 |
ahappyhuman | Is Sailfish Secrets comparable to Gnome Keyring and KWallet? | 08:36 |
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 |
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:36 |
ahappyhuman | 5 appstores? Is that including or excluding the android appstores? | 08:37 |
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 |
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 |
gmc | ahappyhuman: i think 3 native ones, 3 android ones (so that's 6 :) | 08:37 |
ApBBB | is anything else than the official and openrepos?? | 08:38 |
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 |
ahappyhuman | chriadam: ah, okay. | 08:38 |
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 |
ggabriel | gmc: I did say "some (but not all)" - we should never install dodgy apps anyway ;) | 08:38 |
chriadam | fwiw: this is my personal opinion only: | 08:38 |
thigg[m] | hard to tell from the outside if an app is dodgy | 08:39 |
chriadam | the API of sailfish-secrets is nice. but the implementation has NOT been properly reviewed by a domain expert (crypto expert) | 08:39 |
gmc | ggabriel: that's the problem, harbour would presumably not allow dodgy apps, openrepos does not have any quality gates does it? | 08:39 |
chriadam | so relying on it to be secure, at this stage, is ... optimistic. | 08:39 |
ggabriel | gmc: correct | 08:39 |
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 |
KeeperoftheKeys | yes | 08:39 |
thigg[m] | optimistic security ;) | 08:39 |
KeeperoftheKeys | having a keyring that an app can only retrieve it's own data from is far better | 08:40 |
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 |
chriadam | please do | 08:40 |
chriadam | very much please | 08:40 |
Thaodan | I think implementing org.Freedesktop.Secretstorage woild help on cross platform api usage | 08:40 |
KeeperoftheKeys | if the OS is truly capable to guarantee that the app only accesses its' own stuff | 08:40 |
thigg[m] | thaodan: +1 | 08:40 |
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 |
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 |
gmc | chriadam: ok, I will make a note and ask some friends | 08:41 |
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 |
chriadam | so, you can use the api, but your data stored in it might vanish at some point if it proves insecure... | 08:42 |
chriadam | I mean... | 08:42 |
flypig | Hmm. That's a good point, yes. | 08:43 |
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 |
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:43 |
flypig | With some things (e.g. 2FA tokens) they may not be so easy to reenter. | 08:44 |
Thaodan | ahappyhuman: KWallet doesn't implemented the SecretStorage api either but this would be the best start I think. | 08:44 |
gmc | org.Freedesktop.Secretstorage only stores secrets right? sailfishsecrets also provides encryption/decryption of bulk data if i'm not mistaken | 08:44 |
Thaodan | Yes | 08:45 |
gmc | which is convenient for storing private data (like VTODO items in my case) in a sqlite db | 08:45 |
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 |
Thaodan | But as the question was about storing secrets and not en-/descryption | 08:45 |
Thaodan | *decryption | 08:45 |
gmc | Thaodan: fair point :) | 08:45 |
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 |
gmc | (ie org.Freedesktop.Secretstorage) | 08:47 |
flypig | KeeperoftheKeys, yeah, true. As gmc says, it just needs some advance notice. | 08:47 |
KeeperoftheKeys | it could even be done automagically (or attempted) | 08:47 |
chriadam | can expose data stored in screts via org.fd.ss and vice versa. same as dcaliste's plugins for gpg | 08:48 |
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 |
chriadam | so should be straightforward. | 08:48 |
dcaliste | chriadam: I can give a look, but I guess org.Freedesktop.Secretstorage is more of an API than a backend, right ? | 08:50 |
chriadam | ah, right | 08:50 |
chriadam | I guess I mean: data stored in sailfish-secrets could be exposed via that interface | 08:50 |
dcaliste | What I've done with the GnuPG plugin was to expose the GnuPG backend through the Sceret API. | 08:50 |
chriadam | if needed | 08:50 |
chriadam | but I personally don't see too much value there | 08:51 |
dcaliste | But I agree, that implementing the Freedesktop API (if it's the case) with the Secret backend should be quite easy. | 08:51 |
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 |
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 |
sledges | but as you should already know, no promises or timelines at this point:) | 08:52 |
sledges | let's move it the next one | 08:52 |
gmc | well, I have an action item to rally some crypto-nerds for a review, hoping that that would help things along | 08:53 |
sledges | thanks very much indeed on that | 08:53 |
chriadam | that would be a huge help, gmc. | 08:53 |
chriadam | ty | 08:53 |
flypig | gmc, can you give an update next meeting? | 08:53 |
gmc | flypig: yes, that is possible (depending on the time and my $dayjob commitments at that time) | 08:53 |
sledges | you can leave/writeup in the forum announcement | 08:53 |
chriadam | no rush. | 08:54 |
flypig | gmc, of course. No obligation, but it would be good to know. | 08:54 |
dcaliste | Thank you gmc for this, indeed ! | 08:54 |
sledges | #action gmc to rally some crypto-nerds to do security audit on sailfish-secrets framework, if and when they have time | 08:54 |
sledges | let's go:) | 08:54 |
sledges | #topic General Discussion (30 min) | 08:54 |
*** sailbot changes topic to "General Discussion (30 min) (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 08:54 | |
sledges | time to answer since it was posted | 08:54 |
sledges | whoops | 08:54 |
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 |
Flohack | UBports would be interested on the outcome, we have an accounts backend, but idk how well designed it is. | 08:55 |
sledges | #link https://forum.sailfishos.org/t/community-meeting-on-irc-29th-oct-2020/2899/7 | 08:55 |
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 |
ApBBB | are there any cool things comming in the next SFOS release?? | 08:55 |
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 |
ahappyhuman | sledges: no problem | 08:55 |
sledges | ApBBB esr60 should :) | 08:56 |
ApBBB | sledges nice. is there a plan to follow the esrs up to latest?? | 08:56 |
gmc | dcaliste: thanks, will keep that in mind | 08:56 |
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 |
chriadam | you know my mantra: reduce platform surface, reduce external dependencies ;-) | 08:56 |
rinigus1 | :) | 08:57 |
ApBBB | chriadam the main problem is that the distro model linux follows is deeply flawed. | 08:57 |
KeeperoftheKeys | sledges: both SSL libraries on SFOS are severly outdated | 08:57 |
sledges | KeeperoftheKeys: see my answer in the forum | 08:57 |
sledges | it's being updated | 08:57 |
KeeperoftheKeys | great :) | 08:58 |
sledges | aye :) | 08:58 |
Thaodan | KeeperoftheKeys: thats not true well at least not anymore as the next release will have OpenSSL 1.1.1h | 08:58 |
KeeperoftheKeys | In the mean time I'll tell our users to download before listening | 08:58 |
thigg[m] | KeeperoftheKeys: just schedule download and the autoplayback | 08:59 |
thigg[m] | would be a cool feature anyways | 08:59 |
thigg[m] | *then | 08:59 |
KeeperoftheKeys | Thaodan: next release is great, but currently in the wild SSL support on SFOS is at ~2016 levels | 08:59 |
Thaodan | We use the latest version of OpenSSL 1.0 that was supported until recently | 09:00 |
thigg[m] | Btw is the bluez thing fixed in the next release of SFOS? | 09:00 |
thigg[m] | or was it even vulnerable? | 09:00 |
ApBBB | other that qt are there other parts of SFOS that need to be updated to become more "modern" (package wise) | 09:00 |
rinigus1 | ApBBB: good question! | 09:01 |
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:01 |
KeeperoftheKeys | ApBBB: the kernel :) | 09:02 |
ApBBB | upper in the stack i mean. in an ideal world we would be able to run out devices with mainline | 09:02 |
Nico[m] | OpenSSL 1.1 would be nice, I need some functions from it :D | 09:03 |
ApBBB | but we don't live in an ideal world | 09:03 |
sledges | you can see new package versions coming in constantly: https://git.sailfishos.org/explore | 09:03 |
ViGe | KeeperoftheKeys: There is no "the kernel" as there are several kernel versions used by different devices... | 09:03 |
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 |
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 |
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 |
KeeperoftheKeys | but all the binary blobs don't make it easy | 09:04 |
flypig | ahappyhuman, that'd be a neat feature to have. | 09:05 |
ApBBB | rinigus1 isnt the problem that the blobs are compiled for android (hence libhybris) and you cant get blobs compiled with gcc | 09:06 |
ApBBB | ? | 09:06 |
fridl | Is there some progress in libhybris to support Android 10 devices? Or at least a timeframe to do so? | 09:06 |
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 |
sledges | very soon | 09:06 |
chriadam | ahappyhuman: denexter or frajo or abranson might be best to answer | 09:06 |
Thaodan | AppBBB: even then the kernel is stuck on an old version | 09: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 |
Thaodan | I think its similar to trebble: what helps them to use upstream/less changes helps us | 09:07 |
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 |
KeeperoftheKeys | when they decide phones are just computers and users should have access and choice of OS that will be good times | 09:08 |
rinigus1 | ApBBB: don't know much about blobs. so, no comment in this respect | 09:08 |
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:09 |
fridl | And was there any plan for today to discuss the VoLTE things with the Ubports people? | 09:10 |
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 |
ApBBB | KeeperoftheKeys light/dark ambiances?? | 09:10 |
thigg[m] | sledges: regarding my sidenote, is it planned to post something like the minutes of this meeting to the blog? | 09:11 |
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 |
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 |
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 |
ahappyhuman | I'll submit it then. | 09:12 |
ahappyhuman | I also want to note that I'm not a gfx expert myself :) | 09:13 |
ApBBB | BTW i noticed Adam pigg on twitter has support for mouse on sfos on pine tablet. is this work public?? | 09:13 |
sledges | fridl: there wasn't such topic announced for today | 09:13 |
sledges | thigg[m]: sorry forgot about that | 09:13 |
sledges | #info forgotten bit from thigg's topic earlier: | 09: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 |
fridl | sledges I just thought as Florian is around it could be worth ;-) | 09:14 |
thigg[m] | I thought it would make activity a bit more visible | 09:15 |
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:15 |
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 |
sledges | fridl: but monich is not around ;) hence a topic would've been better | 09:16 |
thigg[m] | yes | 09:16 |
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:17 |
gmc | KeeperoftheKeys: i saw an app somewhere that switches the ambiance on a schedule | 09:18 |
Nico[m] | Agreed, the jolla blog can look quite empty | 09:18 |
thigg[m] | maybe just add a widget of the anouncement section of the forum? | 09:18 |
Flohack | Guys was a pleasure, have to leave for dayjob ^^ | 09:19 |
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 |
chriadam | goodbye Flohack, thanks for joining | 09:19 |
flypig | Thanks for joining us Flohack. | 09:19 |
Flohack | Sure ^^ thanks for inviting me | 09:19 |
ahappyhuman | Goodbye! | 09:20 |
gmc | KeeperoftheKeys: https://openrepos.net/content/schturman/auto-ambience-changer (quite old, and a bit cumbersome) | 09:20 |
sledges | 4 more minutes | 09:20 |
gmc | would be nice if an ambiance could also configure silent mode and vibration btw, on a tangent | 09:21 |
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 |
ggabriel | I used to have a silent ambience, doesn't that work any more? | 09:21 |
Thaodan | gmc: Situations maybe? | 09:22 |
Thaodan | Flohack: Did you have some overview on the VoLTE progress? | 09:22 |
Thaodan | like links of something | 09:22 |
Thaodan | *or something | 09:22 |
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 |
ggabriel | gmc: you can definitely set the volume (or rid of all tones/alerts); vibration is another thing though | 09:22 |
flypig | ApBBB, I'm not sure what you mean by that. Do you mean a physical keyboard? | 09:23 |
gmc | ggabriel: true | 09:23 |
KeeperoftheKeys | thigg[m]: Next week I'm on vacation and going to give gPodder some TLC | 09:23 |
ggabriel | gmc: but have a look at situations, like Thaodan says | 09:23 |
flypig | Thaodan, +1 situations is worth looking at for that kind of thing. | 09:23 |
sledges | ApBBB: Venemo is the best man to answer | 09:25 |
thigg[m] | KeeperoftheKeys: nice! | 09:25 |
sledges | (he implemented the side-swipe kbd switch) | 09:25 |
Venemo | sorry guys I'm late to the party, what was the question? | 09:26 |
sledges | Venemo: "is there a correct way to set up a kbd switch shortcut on SFOS (with a normal keyboard)" | 09:26 |
Venemo | what is a kbd switch shortcut? | 09:26 |
sledges | keyboard layout switch "button(?)" | 09:26 |
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 |
Venemo | I don't understand the question. There is a button, you tap it, choose your layout and it switches. | 09:27 |
sledges | i think he wants a dedicated button | 09:27 |
sledges | to e.g. always go to one particular layout | 09:28 |
flypig | In an app? For example, adding a button to an app to switch keyboards maybe? | 09:28 |
Venemo | ApBBB: please clarify your question | 09:28 |
sledges | during the next meeting ;) | 09:28 |
sledges | #topic Next meeting time and date (5 min) | 09:29 |
*** sailbot changes topic to "Next meeting time and date (5 min) (Meeting topic: Sailfish OS, open source, collaboration -- 29th October 2020)" | 09:29 | |
sledges | Proposing 12th November at 8am UTC | 09:29 |
* ggabriel ayes | 09:29 | |
gmc | works for me | 09:29 |
flypig | It's a Thursday. It's in two weeks. It's at the same time. Sounds good to me :) | 09:29 |
gmc | ggabriel: i have situations installed indeed :) | 09:30 |
chriadam | +1 | 09:30 |
chriadam | thanks all, /me heads home, gnight. | 09:30 |
sledges | and no national holidays or plannings planned:) | 09:30 |
sledges | #info Next meeting will be held on Thursday 12th November 2020 at 8:00am UTC: 2020-11-12T08Z | 09:31 |
sledges | thanks y'all! | 09:31 |
sledges | #endmeeting | 09:31 |
sailbot | Meeting ended Thu Oct 29 09:31:09 2020 UTC. | 09:31 |
sailbot | Minutes: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-10-29-08.00.html | 09:31 |
sailbot | Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-10-29-08.00.txt | 09:31 |
sailbot | Log: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-10-29-08.00.log.html | 09:31 |
*** sailbot changes topic to "Next meeting will be held on Thursday 29th of October 2020 at 8:00am UTC. Topics can be created here: https://forum.sailfishos.org/t/community-meeting-on-irc-29th-oct-2020/2899" | 09:31 | |
ggabriel | thx sledges, | 09:31 |
Nico[m] | Thanks everyone :3 | 09:31 |
flypig | +1 thanks sledges, everyone. | 09:31 |
ggabriel | ...for charing, I was meant to write; and everyone indeed | 09:31 |
ggabriel | chairing* | 09:32 |
ApBBB | Venemo like you use alt shift on your normal PC | 09:32 |
KeeperoftheKeys | thanks | 09:32 |
thigg[m] | ty | 09:32 |
thigg[m] | or more thank you all ;) | 09:32 |
Venemo | ApBBB: sorry but are you talking about physical keyboard or the virtual one? | 09:32 |
ApBBB | Venemo physical | 09:33 |
ApBBB | pluged into a sfos device with usb | 09:33 |
Venemo | ah ok. I don't know anything about that, don't have a device with a physical keyboard | 09:33 |
flypig | Venemo, is there a dbus interface or anything like that to switch keyboards programmatically? | 09:35 |
Venemo | there is a dconf (I think) setting which you can use which can change the virtual keyboard layout | 09:35 |
Venemo | I haven't a clue about physical. maybe pvuorela is our guy on that front? | 09:36 |
*** ChanServ changes topic to "Thursday 12th Nov 2020 at 08:00am UTC. Topics can be created here: https://forum.sailfishos.org/t/community-meeting-on-irc-12th-nov-2020/3272" | 09:36 | |
flypig | Oh, nice. It can be controlled by dconf. | 09:43 |
flypig | dconf write /sailfish/text_input/active_layout '"en.qml"' | 09:43 |
flypig | dconf write /sailfish/text_input/active_layout '"ro.qml"' | 09:43 |
flypig | etc. | 09:43 |
Venemo | you should even get the animation if the vkb is visible when that happens | 09:44 |
flypig | Yeah, it's very slick :) | 09:44 |
Thaodan | It could be useful even for physical keyboards when setting a keyboard that empty to just show word predictions | 09:45 |
flypig | Thaodan, we don't have that feature, but it would be good indeed. There's some discussion about it on the forum too@ https://forum.sailfishos.org/t/add-virtual-suggestions-bar-to-predictive-input-for-physical-keyboard/3190 | 09:47 |
Thaodan | I know but that's a way how it could be done | 09:47 |
Thaodan | Its maybe a customer might want | 09:48 |
flypig | Yes, agreed. It's a shame not to have suggestions for English, but in Chinese it's pretty much essential. | 09:48 |
flypig | (I'm guessing). | 09:48 |
Thaodan | I think its similar for Japanese | 09:48 |
rinzep | rinigus1 hi, you mentioned in the meeting that a talk about sony mainlining efforts is upcoming. could you give me a link? | 14:56 |
rinigus1 | rinzep: sure. here is the message from sfos-porters channel | 15:20 |
rinigus1 | there will be a talk by Sony Open Devices folks on mainlining Sony devices at https://www.openalt.cz/2020/program.php . it will be in English (in contrast to the most talks). looks like it is 8 nov at 10:00 (CZ timezone, aka Central European Standard Time). Talk by Martin Botka, AngeloGioacchino Del Regno, Konrad Dybcio: Qualcomm SoC upstreaming (ad)ventures in 2020. | 15:20 |
rinigus1 | rinzep ^ | 15:20 |
rinzep | rinigus1 awesome, thank you! | 15:20 |
mal | related to mainlining of qcom devices, I got sfos UI up with patched 5.9 kernel on fp2, it's not very stable because of some driver bug but it's a start | 17:11 |
Nico[m] | That's pretty awesome! | 17:14 |
mal | also things like wlan, bt and modem are working | 17:16 |
Nico[m] | That's almost better than on my laptop :D | 17:16 |
mal | audio will be a bit of a problem on fp2 because it's missing audio driver, it's possible but just quite much work, the other similar qcom audio drivers are about 5000 lines of code | 17:21 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!