10:00:20 #startmeeting Sailfish OS, open source, collaboration – August 21st 2020 10:00:20 Meeting started Fri Aug 21 10:00:20 2020 UTC. The chair is Jaymzz. Information about MeetBot at http://wiki.debian.org/MeetBot. 10:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 10:00:30 #info Meeting information and agenda can be found here: https://forum.sailfishos.org/t/community-meeting-on-irc-21st-aug-2020/1596 10:00:37 I am the meeting’s chairperson today, and will be doing my best to keep time and order. Please behave, respect the timings and be gentle. 10:01:03 #topic Brief introduction (5 min). Please prefix your name/handle with # info 10:01:20 #info James Noori - Community 10:01:33 #info Andrew Branson - sailor @ Jolla 10:01:41 #info Sefriol - Community 10:02:01 #info Leszek Lesner - Community + Dev 10:02:06 #info fridlmue - Community 10:02:23 #info Jussi Maaniitty - sailor @ Jolla 10:02:36 #info Karry - Community, developer 10:02:48 #info David Llewellyn-Jones - sailor @ Jolla 10:03:01 #info nekron - DevOp 10:03:17 #info Pami Ketolainen - sailor @ Jolla 10:03:23 #info Björn Bidar - sailor @ Jolla 10:03:40 #info Santhosh - Community 10:05:42 first topic coming up 10:05:48 #topic AOSP10 based ports (20 min by rinigus) 10:05:59 #info From looking at https://github.com/libhybris/libhybris 4 and Android Q PR specifically, it seems that there is not much activity on development of Android 10 support. I wonder what is the current status of AOSP10 support (in case if it is not all published). If work has not started on it by Jolla developers, whether it is planned and, if it is, when do you plan to work on it. 10:06:04 #link https://github.com/libhybris/libhybris 10:06:22 #info Leif-Jöran Olsson, community member 10:07:27 Amswer: 10:07:32 #info Android 10 support is on the roadmap, but there is no schedule available that we could commit to at this point. 10:08:12 Jaymzz: is anyone working on it or started to work on it? 10:09:11 maajussi: ^^ 10:09:49 I'm sure we have had progress on this. 10:09:57 Thaodan attempted it for community port 10:10:24 as such, it is good to know that it is in the roadmap and we don't fully switch to linux-phones yet 10:10:40 It is also partly related to availability of devices. We've had difficulties mainly due to Covid-19. 10:11:26 maajussi: indeed, sony dev support for aosp10 was somewhat delayed, it seems. as far as I know it is there on android side now 10:11:44 As well as people can not be at office, sharing devices - it creates a more difficult environment to work on this topic. 10:11:58 Yes I was working on it but had other matters to work on . 10:12:21 Also I had a device specific blocker and had no intent to work on other devices 10:12:43 Thaodan: do you have aosp10 on your agenda? 10:12:55 (i.e. have you managed to fix the blocker?) 10:13:49 I don't managed to fix it at the moment but I'm working on it 10:14:25 anything else specific to add regarding aosp10? sailors support 10:15:29 clean up modules that depend on it before more changes are coming specific to Android 10 10:16:27 Thaodan: which modules? 10:16:56 everything that's involved with the build system of Android 10:17:18 like hybris boot (PRs for that already exist) 10:18:07 looking forward 10:18:37 I think I've got my reply, thank you! please feel free to move on. 10:20:55 Alright moving on then 10:21:15 #topic E2E testing in Sailfish (by sefriol – 10 min) 10:23:12 Jaymzz died mid sentence 10:24:23 :( 10:25:40 I suspect he is running a test 10:26:16 > all tests passed 10:26:27 :D 10:26:42 I'm back :D sorry guys my network failed 10:26:52 where were we? how many messages did you get? 10:26:58 topic was the last one 10:27:03 alright 10:27:17 #info E2E testing is one of the key aspects to make reliable and tested software, most popular (or atleast user friendly) webapp testers being Cypress.io 1. There seems to be little to no E2E testing capabilities provided as a base line or atleast the documentation is very limited. I stumbled upon https://www.researchgate.net/publication/320649391_Method_and_tools_for_automated_end-to-end_testing_of_applications_for_sailfish_ 10:27:17 OS 2 and https://bitbucket.org/yarfruct/sailfish-os-qml-test-runner/src/default/ which provide some solutions. Is there anything that Jolla uses internally? I would assume that e2e frameworks would also be useful for porters who could more rapidly test out that certain functions do work when porting OS to another SoC or phone. 10:27:26 #link https://www.researchgate.net/publication/320649391_Method_and_tools_for_automated_end-to-end_testing_of_applications_for_sailfish_OS 10:27:34 #link https://bitbucket.org/yarfruct/sailfish-os-qml-test-runner/src/default/ 10:27:48 Answer: 10:27:52 #info We are using internally qmltestrunner for testing QML components. That tool is available for all (https://git.sailfishos.org/mer-core/qtdeclarative/tree/mer-5.6/tools/qmltestrunner and qt5-qtdeclarative-devel-tools package in our repositories) and community can use it for testing own applications. For HW testing we are using CSD tools and porters should use that for verifying functionality of different HW features. 10:27:59 #link https://git.sailfishos.org/mer-core/qtdeclarative/tree/mer-5.6/tools/qmltestrunner 10:28:55 https://bitbucket.org/yarfruct/sailfish-os-qml-test-runner is not public 10:30:09 birdzhang, I don't think it's that it's not pugli 10:30:17 Ah, sorry, mistyped. 10:30:43 I get "Bitbucket no longer supports Mercurial repositories" so maybe it's just a configuration issue. 10:32:23 Sefriol: anything to add? 10:32:40 Probably need to digest this information :) 10:32:47 But nothing specific for the moment 10:33:36 Sefriol: ok maybe we can move on and you can discuss this further (if anything) during general discussion 10:33:40 The bitbucket code is from the paper, so contacting one of the authors might help. 10:34:42 (I'm sending them an email and will post a link next meeting if I hear back). 10:35:49 flypig: thanks for that 10:36:02 Sefriol: I'll move on in a minute if that's ok with you 10:36:06 Generally the code was not in the place stated in the paper 10:36:12 I just happened to find it 10:36:19 Yes, let's move on 10:36:28 alright 10:36:38 #topic Native Banking Apps for SailfishOS (by sefriol – 10 min) 10:36:46 #info Currently, you are pretty much required to have a second device if your bank only allows SafetyNet passing devices to run as credential client. VTB24 seems to have an closed source banking app for AuroraOS 2. Any insight from Jolla’s side if there is any posssible progress in bringing native banking apps to Sailfish. https://together.jolla.com/question/11734/mobilebanking/ 10:36:55 #link https://together.jolla.com/question/11734/mobilebanking/ 10:37:06 answer: 10:37:07 #info It would be valuable to understand if there are particular enabling technologies that banks require and which should be provided at OS level - without which banking apps won't work. If the enablers (API) are public, the community could provide apps for individual banks/countries. 10:38:25 Some of the APIs are public (Nordea as a Finnish example) 10:38:33 a proper browser would -in many cases- solve the issue of native bank apps. most banks have a nice web interface. 10:38:37 correct me if I am wrong but banks use proprietary ios or google play services 10:38:43 But they do require license to be operational 10:38:53 if the bank doesn't want to bring an app to SFOS there is nothing jolla can do 10:39:22 ApBBB: Jolla could get an Play Services license eventually 10:39:34 that would make bank apps run via AD at least 10:39:38 Sefriol, I'm using one of the Nordea apps on dalvik and it works well. 10:39:55 Thats kinda a strange joke leszek3 10:40:00 European Banking directive pretty much enables many bank operations through public API 10:40:01 for Revolut there is unofficial NodeJS app which provides most of functions mobile app has 10:40:14 leszek3 the goal should be to end the android crap at some point. 10:40:37 You need to pass verifaction on android side to run some android apps 10:40:40 But usually to use these APIs in production, you need a valid EU license for that 10:41:13 ApBBB: I don't see how when banks don't even want to support Huaweis HMS 10:41:17 Sefriol And that costs a lot of money... 10:41:19 Did anyone try the MicroG's SafetyNet/DroidGuard feature? 10:41:44 Wunderfitz No idea. I did not look into it. 10:41:56 In Germany HBCI/FinTS works very good and we already have an app for that from Wunderfitz called Zaster 10:41:57 Wunderfitz in the area of what is that cost?? 10:42:05 Sefriol Well, I did when I was writing Zaster Banker. ;) 10:42:14 4 minutes left on this 10:42:22 Is Zaster Banker still working nicely for German banks? 10:42:24 Wunderfitz Ah, nice :D 10:42:37 ApBBB 5 digit Euros at least 10:42:40 flypig: last time I tried yes 10:42:40 How much is "a lot" in this case? 10:42:42 Other european banks also have apis but no as standardized 10:43:10 Afaik those apis allow you to see your bank status but not allow for bank transfers 10:43:18 https://crosskey.io/stores/s-pankki/apis 10:43:32 leszek3: HBCI/FinTS does allow that 10:43:58 I think basically it is hard to talk abotu "banks" in general. Not every app depends on SafetyNet or even GMS, maybe it would benefit to have a whitelist of working apps 10:44:01 This one also: https://crosskey.io/stores/s-pankki/apis/7b01242e-83be-4c42-b986-0d183ab35280 10:44:03 Thaodan: really? Uff. I never saw an app really allowing me to transfer money 10:44:12 Wunderfitz thats not bad 10:44:15 leszek3: aqbanking 10:44:19 maybe my bank does not like it 10:44:20 FinTS is a terrible protocol though and our banks don't hand out test accounts. However, it works at least smoothly here 10:44:55 Next time, I'd probably use the library behind aqbanking and live with the downsides of it 10:44:57 i mean if you can make a bussiness case out of it. ie write a lib that everyone can use and charge for the use of it. 10:45:05 Many banking apps use it for themselfs so thats why we can use it pretty freely but they don't like to tell you that 10:45:41 Wunderfitz, how easy would it be to extend Zaster Banker for other protocols? If I were interested in creating an app for a particular bank, would that be a good place to start? 10:45:55 Those are nice finds Thaodan. 10:46:09 I wonder if it would be easier to provide credit/debit card nfc payment in SFOS 10:46:55 flypig Currently, it's more or less bound to the flow and the status handling of FinTS (yes, this f***ing protocol is NOT stateless), so it might be quite some effort 10:47:25 Money transfer is probably bank by bank basis 10:47:46 But for many Finnish banks that I looked into, money transfer is also possible through API 10:47:47 time is up for this one guys, try to wrap it up please :) 10:47:50 Wunderfitz, thanks, that's too bad, but I'm not so surprised these things are hard to abstract. At least the protocol exists. 10:49:34 Sefriol: I have to move on to the next one. We don't have more time on this :) 10:49:42 Sure 10:49:43 #topic Separating QML components from closed source and publishing them to git (by sefriol – 5 min) 10:49:51 #info This has come up before. Currently, if community sees a bug or wants to propose a change in core app’s UI, the source is only available within the phone / emulator / SDK. Is there a problem with separating these components from the closed source repositories and publishing them in gitso that community could do pull requests on them? 10:49:54 answer: 10:50:01 #info This is something that could be made possible, by for example mirroring the QML code in git. We would need to alter the licence and hold the copyright for all contributions, but the possibility to do this exists. Action taken to study this further. 10:52:05 Speaking personally, I think this would be a great idea. 10:52:52 Yeah, community wants to help, but if suggestions for changes are done through TJC / email they are never going to happen 10:53:49 Right, it's about offering a process people can use. 10:54:23 resolving stuff is an ongoing problem 10:54:38 Depending on how it's structured, QML components could be put into a git submodule as well? 10:54:55 ApBBB, what do you mean? (sorry, I'm not fully understanding). 10:55:09 So it's easy to integrade changes done by the community without need for separate repos for Jolla 10:55:22 I agree, this would be something that we need to dig into. I need to collect more information inside Jolla what this requires, but I fully agree on the proposal. 10:55:23 suggestions made by PRs are not guaranteed to happen either, btw. it is largely depending on current Jolla priorities 10:55:44 In general I am for this. But would it not create problems with the apps not being fully open source? Like conflicts between new backend features (proprietary) and frontend commits 10:55:59 #action maajussi is going to dig more on this topic and get back to the community 10:56:15 But atleast there are PRs where people can have disccussion and suggest changes 10:56:37 flypig not ongoing. long stanging. my mistake 10:57:17 leszek3, I think it it was a mirror of the latest release, that wouldn't be a problem. 10:57:42 flypig what i meant is that stuff proposed or bugs or whatever takes a long time to get fixed and sometimes never does. 10:58:03 flypig a great example of this is the maps situation. 10:58:04 ApBBB, okay, I get you. Yes, I see what you mean. This wouldn't be a magical fix for that, but might help. 10:58:12 we are over time on this right now. let's try and wrap up 10:59:16 Sefriol: I will move on now :) 10:59:33 #topic Multiple 2+ cameras support (by Mister_Magister – 15 min) 10:59:43 #info Lately i’ve successfully created initial support of multi-camera. On some devices auxiliary cameras are provided same way as other 2 but sfos is based around front and back camera while we need to support camera id 2 and higher. My initial changes are nowhere near merging, but it’s something jolla should start think about regarding jolla-camera ui. 10:59:56 answer: 11:00:00 #info It seems multiple cameras are in common place for the device category we have been supporting in co-operation with Sony Open Devices. It is likely that we will support this in future. 11:00:11 Mister_Magister: you there? :) 11:00:37 Pinging 11:00:48 yeah pinging him on telegram 11:00:51 Kudos to Mister Magister for getting something working. 11:02:06 Can anyone share which devices he's working with? 11:02:17 Asus Zenfone 5z 11:02:31 I donated money he can port SFOS on it 11:02:59 Nice. 11:03:45 seems like he isn't in the chat. But he has asked on his topic for others to discuss it if they have anything to add. 11:03:57 Pro1 of recent community ports also has multiple camera, but it seems to be not exposed the same way as on 5z 11:04:20 Mister_Magister here 11:04:27 aye im here 11:04:28 he is joining now 11:04:33 there he is 11:04:35 Some like the Xperia XA2 Ultra expose the two cameras as one 11:05:06 TheKit: yeah pro1 won't work cvause second camera is for bokmeh effect but if you have wide angle it should work 11:05:18 i have built packages so community can test 11:06:14 Anyone knows how the second camera on the xperia 10 plus is exposed? Also as one camera or two cameras? 11:06:31 Mister_Magister, could you provide a link please? 11:06:35 afaik the second cam is a zoom one 11:06:38 but if my PR gets merged then there won't be camera primary and secondary there will be 0,1,2,3 etc and each with info if its backwards or front facing. it needs to be implemented in jolla-camera and given thought by designers 11:06:56 leszek3: you can check if there are more than 2 cameras using droid-camres 11:07:23 flypig: literally PR in gstdroid and qtmultimedia 11:07:32 how exactly though? 11:07:34 and packages are on obs somwhere 11:07:46 leszek3: droid-camres will display you resolutions for all cameras 11:08:04 Jaymzz: the long message above is for you 11:08:33 noted 11:09:59 shall we move on Mister_Magister? 11:10:06 Just for the log: 11:10:06 https://git.sailfishos.org/mer-core/qtmultimedia/merge_requests/34 11:10:12 https://github.com/sailfishos/gst-droid/pull/56 11:10:43 thanks flypig i barely woke up. I'm working with abranson on fixing those patches but it will take a awhile for me 11:10:55 if jolla or community wants to help, welcome 11:11:20 Jaymzz: we can now 11:11:35 #topic general discussion (15 min) 11:13:12 *rolling tumbleweed* 11:13:15 Are there any plans of Jolla stepping up with Pine64 to make a "community edition" of Pine Phone with SailfishOS/Jolla? Would love buying that. 11:13:33 so I worked on some qtmultimedia patches: https://git.sailfishos.org/mer-core/qtmultimedia/merge_requests/35 11:13:42 Sefriol, just from earlier, nice finds with those E2E testing links. That paper is interesting. 11:13:59 maajussi: so what is behind OBS and git.sailfishos.org? 11:14:00 problem is they are backports from newer qt versions. And that leads to licensing issues apparently 11:14:11 any news regarding the wayland xdg protocol in Sailfish ??? 11:14:14 fridlmue: not that I know of at least. maybe maajussi has more info :) 11:14:14 That is a big issue I think 11:14:15 leszek3, great! 11:14:30 leszek3, ah, not so great. 11:14:47 also gstreamer broke 11:14:59 leszek3, the patches are GPLv3? 11:15:09 eglGetCurrentDisplay doesn't work apparently 11:15:25 I wonder if someone knowledgable with licensing can take a look at it again. I mean otherwise we end up with a almost unusable streaming experience for sfos 11:15:44 leszek3: works for me! 11:15:48 ApBBB: what would that need? 11:15:56 fridlmue No news on pinephone. We have couple of devices in the group, but there is no official commitment to establish a project on them. 11:16:02 other problem is /maybe/ being fixed by mal 11:16:09 Mister_Magister: ? 11:16:17 mal: changing video format 11:16:21 flypig: from my side whatever you want them to be. As for qt5 probably 11:16:37 mal its old and keeps things back in community stuff. like flatpack 11:16:39 gstdroid cannot reconfigure video if it was already configured 11:16:45 leszek3, can you usefully separate your own changes out? 11:16:49 and that breaks DASH 11:16:52 Pardon me if this is not the right place, but since it's now general discussion, asking just in case: are there any chance Jolla will support this in Lipstick one day? This is HDMI out on a port for a device that has the hardware for it: https://github.com/elros34/qt5-qpa-hwcomposer-plugin/commit/6a6022bbc15b6d2e346930573dfe4ee553883140 It's been shown to work, would be great to have it for other phones that have the hardware 11:16:55 ie gtk wont work with it 11:17:03 ApBBB: so does it need something for qtwayland? our wayland is quite new 11:17:16 @maajussi Jaymzz Thank you for the info. I think this could be worth it. Could also generate more Community and Developers. 11:17:24 mal: needs newer qtwayland 11:17:36 mal its a compositor issue as far as i understand 11:17:41 TheKit: which version brings that? 11:17:57 flypig: I linked to the originally patches. You can see that some are modified as the filename changed or is not the same or the function names are different 11:18:13 5.10 5.12 was the version but abranson said they can work around it i think 11:18:14 Kabouik_, this is a perfectly good place to ask :) I'm not sure of the answer though. 11:18:57 leszek3, okay, so it's all changes to existing patches? I think that's still an issue then, from a licencing perspective, unfortunately. 11:19:06 Some of the patches are really trivial like the play when buffer is full patch 11:19:13 mal: 5.9 brings basic support, 5.12 is better 11:19:33 leszek3, yeah, that's a real problem though. If the copyright belongs elsewhere, then the licence sticks to it. 11:19:42 leszek3, even for very small changes. 11:19:43 rinigus the git and OBS changes is part of making everything (hopefully) more simplified and easy. It is not an easy question, or an easy decision, lot of different things that impact. Cost, naming, required effort vs gain... 11:19:45 I suppose. 11:20:50 Sorry, my "I suppose" was in reply to myself, not in reply to maajussi. 11:20:55 ApBBB: no, I didn't say that :) 11:20:56 mal: newer protocols in compositor support by qtwayland will allow to handle gtk apps in flatpak-runner (wrapper compositor used by flatpak apps) 11:21:07 flypig: this is totally ridiculous. So adding a comment or a variable name in a patch under a different license and no one can ever use this variable name 11:21:30 maajussi: killing OBS does not like it is going to make it easy for us. 11:21:47 abranson ok i don't remember exactly how you worded it but you said something like it is doable to have a later xdg without a qt update. i don't remember exactly 11:21:52 maajussi: but probably this information and discussion should be continued in the forum 11:21:59 leszek3, well, obviously it's not quite that straightforward, but these are legal matters. 11:21:59 If I may add to what rinigus just said, I've also seen non-SFOS developers being discouraged from porting their Wayland apps to SFOS just because they realized they had to add code for deprecated protocols (wlseats, xdg) 11:23:10 currently sailfishos-porters-ci can already build rootfs image for ports. I think extending GitLab CI configs to build adaptation packages instead of OBS is possible, but certainly doesn't make life easier 11:23:27 maajussi: while replying to the reasons regarding killing OBS, please be specific. as I said in the forum, it is one of the services that makes development easier 11:23:34 rinigus yes we should, and I know that everyone agrees on your statement. If we would not have OBS - if it comes to that ... we need to find a way to do this, that wouldnt require extra effort. 11:23:37 I meant wl_shell in fact, now deprecated and replaced by xdg_wm_base 11:23:44 flypig: its really a bummer that trivial technical solutions for issues are blocked by stupid licensing rules 11:24:32 leszek3, I totally agree. I mean, really. 11:24:53 leszek3, but this is not just a sailfish thing. It's pretty much universal as far as I can tell. 11:25:21 maajussi: do I read you correctly - is it mainly admin and breaking hardware costs? 11:25:33 guys, time is up, I see there still is a lot of active discussions. So I give it a few more mins but please try to wrap it up 11:26:06 (re OBS: let's continue in the forum) 11:26:31 rinigus lot of it is about cost for sure, but that is not the only driver. 11:26:46 Let's continue and elaborate in forum! 11:26:53 maajussi: looking forward for it 11:27:07 leszek3, just to say, thanks for that patch. 11:27:39 Any answer to the hdmi-out question above? A patch has already been shown to work years ago on a device port, would be great to have it included in Lipstick for other devices now, which are getting more common with hardware support for this feature 11:28:10 Kabouik_: not sure how much changes it would need to lipstick 11:28:15 what? u removing obs? 11:28:58 Mister_Magister: https://forum.sailfishos.org/t/changes-needed-to-merge-the-project-names-to-sailfish-os/1672 11:29:30 well you coould switch to upstream and build on opensuse obs with all new shiny packages basing on leap but who i am to dream 11:29:36 Kabouik_, I'll create an internal issue for it, but that doesn't guarantee any progress of course. 11:29:40 flypig: yeah hopefully the licensing issues will be solved soon with newer Qt version. I think when Qt 5.9 or 5.12 is coming some of those patches are still valid 11:30:09 leszek3, it seems that would solve the issue, nevertheless it's a shame it can't be merged now. 11:30:10 especially the memory leak ones make improve battery life if I see it correctly 11:30:23 Of course flypig, but thank you, that is already something 11:30:26 and streaming of course 11:30:50 Alright people, wrap it up already! Moving on in a few moments 11:31:11 So what's the status with Qt? ;) 11:31:15 :D 11:31:32 mal: how are devs supposed to make ota? host it themselfs? 11:31:58 Sefriol: whats status with throwing away money because of keeping packages closed source? :D 11:32:46 #topic next meeting time and date (5 min) 11:32:52 Qt Upgrade develops to a never ending story 11:32:52 +1 11:33:08 Alright so we will go back to the normal schedule from the next meeting, every two weeks on thursdays. 11:33:14 leszek3: same as opensourceing. we are getting nowhere and no effor is being put into it 11:33:19 #info Next meeting will be held on September 3rd 2020 at 08:00 UTC 11:33:44 jolla should also fire their android designers 11:34:00 Mister_Magister: https://github.com/mer-hybris/droid-hal-configs/pull/181 11:34:02 what android designers? 11:34:06 Need to end the meeting guys. Have other things to do :) you can continue the discussion if you like :) 11:34:15 #endmeeting