09:00:04 <Jaymzz> #startmeeting Sailfish OS, open source, collaboration – 6th of February 2020 09:00:04 <merbot> Meeting started Thu Feb 6 09:00:04 2020 UTC. The chair is Jaymzz. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 09:00:04 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 09:00:14 <Jaymzz> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2020-February/009063.html 09:00:22 <Jaymzz> 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. 09:00:31 <Jaymzz> #topic Brief introduction (5 min). Please prefix your name/handle with # info 09:00:38 <Jaymzz> #info James Noori - sailor @ Jolla 09:01:07 <Nico[m]> #info Nico - community 09:01:26 <Thaodan> #info Björn Bidar - community developer 09:02:04 <flypig> #info David Llewellyn-Jones - sailor @ Jolla 09:02:37 <schmittlauch[m]> #info schmittlauch - community 09:02:43 <abranson> #info Andrew Branson - sailor 09:02:48 <ViGe> #info Ville Nummela - sailor @ Jolla (I might not be able to stay for the whole meeting) 09:04:12 <ExTechOp> #info Otto Mäkelä - communitu 09:04:36 <ExTechOp> *community, of course 09:05:01 <Thaodan> I think you have to add that to #info 09:05:25 <vknecht> #info Vincent Knecht - community dev 09:05:43 <ExTechOp> #info Otto Mäkelä - community 09:06:57 <Jaymzz> #topic Update on the fingerprint reader situation on community ported devices (Asked by ApBBB – 5 min) 09:07:05 <Jaymzz> #info As we know the fingerprint interface remains a closed component of SFOS and unavailable to community ported devices. On a previous topic jolla mentioned they need to look into it and discuss it. So. Give us an update of the situation. 09:07:35 <Jaymzz> Here comes a short answer to this one: 09:07:50 <Jaymzz> #info We have one possible solution, but it will need more testing internally. So stay tuned for this one! 09:08:01 <Jaymzz> ApBBB: You there? :) 09:08:24 <rinigus> morning! Jaymzz , that sounds promising 09:08:32 <Thaodan> Would it be ok to distrebute the existing fpd-slave binary if the device is compatible? 09:08:53 <schmittlauch[m]> if ApBBB is here, they're here undercover. 09:09:04 <Thaodan> Like for community ports of official devices or very similar devices like the XZ2 09:10:47 <rinigus> Thaodan, exactly. we also wonder whether sony devices can somehow use fingerprint implementation used sfos x 09:11:06 <vknecht> +1 09:11:36 <Jaymzz> Very good question there. I'm trying to get an answer for you. 09:11:44 <Thaodan> If I looked at everything in the correct way every device can as long as they use/provide the proper binder interface. 09:11:47 <lbt> #info David Greaves - Sailor and Mer guy 09:13:00 <Thaodan> But it doesn't only comes to non official ports, if I want to build the adaption of a jolla device which includes fpd I need to get the binder-slafe too or have to cut that feature 09:13:51 <abranson> Thaodan: it could work, but there are a lot of quirks that might need setting. fp is quite tempremental. 09:15:41 <schmittlauch[m]> There are 2 explanations for why the fpd depends on proprietary code: 1. The implementation is done by Jolla but they haven't opensourced it yet (y though?) 2. The specific implementations depend on vendor-provided proprietary code, so Jolla isn't free to allow us to redistribute it. 09:16:11 <piggz> #info piggz Community Porter 09:16:22 <Thaodan> More information on the innerworks of this would be great. 09:16:29 <piggz> jaymzz: if you n eed ported device testing .... ; 09:16:52 <Jaymzz> piggz would gladly take that ;) 09:17:13 <Jaymzz> I am giving this a few extra minutes since the discussion seems to go on 09:17:23 <piggz> can you say if the implementation will be specific to certain api levels? 09:17:35 <piggz> like, treble only, or work on older bases? 09:17:42 <abranson> some folks already have been trying it out with the binder slave i think? 09:18:06 <Thaodan> Jaymzz: Can we get better documentation on that system to have more public information what and how sailfish-fpd works? 09:20:07 <abranson> piggz: i don't think we can really share details until we have a solution. i'd say the binder one has more chance of being used in ports though. 09:20:23 <piggz> abranson: ok, id expect as much 09:20:36 <piggz> not sure how the mido 14.1 works 09:21:28 <Jaymzz> Thaodan: I will look into it :) 09:21:30 <abranson> out of interest, how many ported devices are out there with fp sensors? 09:21:40 <abranson> other than the xperias 09:21:42 <piggz> probably a few, ive 2 09:21:46 <piggz> mido, fxtec 09:21:55 <piggz> likely Mister_Magister will have a bunch 09:22:00 <Jaymzz> We are though way over time on this one guys. We need to move on 09:22:57 <abranson> think maybe ask the specific question about redistribution for the next meeting. needs some discussion internally 09:24:16 <Jaymzz> yeah let's have that as a new topic for the next meeting 09:24:17 <Jaymzz> moving on 09:24:25 <Mister_Magister> piggz: what me? 09:24:38 <Jaymzz> #topic Sailfish 3 ignoring X-Nemo-Single-Instance=no set by the app (Asked by rinigus – 10 min) 09:24:55 <Jaymzz> #info While we have 64bit kernels on Aarch64 devices, userspace is in 32bit. Would be great to get an ability of running AARCH64 applications, even without Qt stack. Usecase: Flatpak Aarch64 apps. Details at https://together.jolla.com/question/222109/aarch64-support/ 09:25:04 <Jaymzz> #link https://together.jolla.com/question/222109/aarch64-support/ 09:25:10 <Mister_Magister> piggz: answer is i have 2 + fxtec 09:25:26 <Thaodan> Wrong info for topic? 09:25:36 <rinigus> looks like it 09:25:42 <Jaymzz> wrong info sorry 09:25:43 <Thaodan> It was about the single-instance behaivior 09:25:49 <Jaymzz> #undo 09:25:49 <merbot> Removing item from minutes: <MeetBot.items.Link object at 0x22127d0> 09:25:56 <Jaymzz> #undo 09:25:56 <merbot> Removing item from minutes: <MeetBot.items.Info object at 0x2212090> 09:26:06 <abranson> ooh cool 09:26:41 <Jaymzz> #info For some reason, X-Nemo-Single-Instance=no is not respected by the current version of SFOS compositor. The bugfix is known and issues have been filed at TJC (https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ and https://together.jolla.com/question/221851/x-nemo-single-instanceno-is-not-respected/). Right now, it stands on the way of running multiple Flatpak a 09:26:41 <Jaymzz> pps, but there could be other issues caused by it as well. Please let us know what is stopping you from fixing it and making system comply with its own docs. 09:26:52 <Jaymzz> #link https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ and https://together.jolla.com/question/221851/x-nemo-single-instanceno-is-not-respected/ 09:27:01 <Jaymzz> damn 09:27:03 <Jaymzz> #undo 09:27:03 <merbot> Removing item from minutes: <MeetBot.items.Link object at 0x2212650> 09:27:16 <Jaymzz> #link https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ 09:27:23 <Jaymzz> #link https://together.jolla.com/question/221851/x-nemo-single-instanceno-is-not-respected/ 09:27:59 <Jaymzz> And here comes the answer, sorry for the mess up :) 09:28:06 <Jaymzz> #info X-nemo-single-instance does indeed seem to broken at the moment and needs fixing, but doing so would be an opportunity to make sure it does what you need it to do here i.e. launch each flatpak application once. For that it would need to be able to include the first argument in the identifier. Whether that should be done with extra values in single-instance or with a new property needs to be decided. 09:29:06 <rinigus> fixing it first according to the docs would be already great step. 09:29:27 <rinigus> and would be consistent with the docs. 09:29:48 <dcaliste> #info Damien Caliste, community 09:30:09 <rinigus> as for extra flatpak support, we can discuss it later. in particular there could be some cases which I don't foresee right now 09:31:04 <rinigus> however, usually flatpak ID is separately given in .desktop. that could be used for such single-instance launch 09:31:41 <rinigus> (replace usually with every time I looked) 09:32:15 <abranson> for the short term, I wonder if a flatpak launcher helper would be possible, associated with your runner 09:33:11 <abranson> think that would solve the python situation too - if you launch the .py file instead of python then the single-instance wouldn't be necessary 09:33:49 <piggz> that would invovle create a runner for each isntalled flatpak? 09:34:19 <rinigus> abranson: I am not sure I follow 09:35:07 <Jaymzz> 2 mins on this 09:35:08 <rinigus> for very short term, would be great to get single-instance=no respected. which, I think, should be done anyway 09:35:12 <Thaodan> abranson: if apps use the regular python3 distools that would happen anyway, only pyotherside apps use a cpp binary 09:35:57 <abranson> rinigus: yeah, but whatever happens changes won't be in release for a good while. a workaround would be best for now. 09:36:43 <dcaliste> rinigus or any sailors, do you know if this bug is lying in lipstick or lipstick-jolla-home ? 09:37:10 <rinigus> dcaliste: fix is known and available as a patch 09:37:23 <Jaymzz> 1 min over time. rinigus should I add more time? 09:37:42 <dcaliste> rinigus, ah, great, it is reference in the TJC question I guess (checking)… 09:37:46 <flypig> rinigus, dcaliste: in lipstick-joll-home, yes? 09:38:01 <rinigus> Jaymzz: I guess few minutes 09:38:03 <abranson> it's not really the right fix for the problem though 09:38:05 <Jaymzz> ok np 09:38:14 <abranson> just the closest thing to what's wanted 09:38:34 <rinigus> abranson: for single-instance=no problem? 09:38:42 <abranson> yeah 09:39:24 <rinigus> as far as I have seen, it did allow to launch apps. but whether its a correct way of doing it, no idea. 09:39:25 <abranson> you do still really want single instances of each flatpak app. the problem is that we don't have a way to identify one 09:39:59 <abranson> or rather, they're being misidentified 09:40:09 <rinigus> abranson: for flatpak - that's a separate issue I think from compliance with the docs - we can use X-Flatpak ID in .desktop 09:40:23 <piggz> if you take the case now without flatpak, you cant currnetly have multiple apps running tho 09:40:49 <piggz> so, rinigus is syaing that fix, while not 100% ideal for flatpak, fixes it a lot, and for current apps 09:41:02 <rinigus> piggz: exactly! 09:41:12 <abranson> rinigus: the docs could be changed if the property has been officially dropped. would have to see whether it's still needed, depending on how this issue is fixed 09:41:30 <abranson> does anything else actually use single-instance though? 09:41:58 <rinigus> abranson: I suspect its used by chroot environments as well 09:42:17 <dcaliste> For info, the patch is modifying /usr/share/lipstick-jolla-home-qt5/switcher/Switcher.qml 09:42:24 <r0kk3rz> abranson: seems like fixing it is pretty simple though 09:42:54 <rinigus> and people wishing to start something by python (see TJC links) 09:42:59 <piggz> abranson: saying you can fix it by chaning the docs sounds a little like a political answer ;) 09:43:01 <abranson> r0kk3rz: right, but I'd rather actually fix the issue 09:43:35 <abranson> piggz: depends why it's been dropped. clearly the docs are out of date, but what's the history? 09:44:08 <abranson> maybe we could add support for an x-flatpak-id. it wouldn't affect anything else 09:44:15 <rinigus> abranson: as the fix is simple and known, I would urge to keep the flexibility and allow developers to decide if they need that feature. not just drop it 09:44:53 <abranson> rinigus: if the fix really is that simple. might have other impact elsewhere. there might be a reason why it was dropped. 09:44:55 <rinigus> abranson: as for x-flatpak-id - please add. 09:45:01 <dcaliste> rinigus, I think it has been discussed already, but how is Android apps doing things ? 09:45:12 <Jaymzz> way over time guys :D 09:45:20 <dcaliste> They have also the X-Nemo-Single-Instance=no tag as far as I know. 09:45:26 <rinigus> (sorry for going overtime, didn't expect that its going to be so long) 09:45:43 <abranson> dcaliste: see in that qml - as android windows can be launched from other sources than desktop launchers, it has to check some wayland property instead. 09:45:47 <rinigus> abranson: maybe 09:45:48 <abranson> it's a special case 09:46:30 <rinigus> dcaliste: android apps are looking for an argument in cmd line to get id, as far as I could see 09:46:47 <rinigus> lipstick is looking for an argument 09:47:02 <Jaymzz> rinigus: how many more minutes you think? can we move this to general discussion? 09:47:05 <rinigus> Jaymzz: moving on? 09:47:11 <abranson> rinigus: what i'm saying that although that single-instance fix looks pretty easy, it would need some history checking and validation. and I think what you're doing is significant enough for us to support you a little bit if it means things will come out better. 09:47:22 <Jaymzz> rinigus: if you are done, yes 09:47:33 <abranson> rinigus: it is using the argument, but also that wayland className 09:47:42 <rinigus> abranson: we can discuss it then further on sfos channel 09:47:48 <rinigus> thanks! 09:47:56 <abranson> the argument tells it what's being launched, but to check against running apps it has to look elsewhere 09:48:10 <rinigus> Jaymzz: let's move on 09:48:17 <Jaymzz> moving on 09:48:18 <abranson> yep 09:48:44 <Jaymzz> #topic AARCH64 plans (asked by rinigus - 10 min) 09:48:58 <Jaymzz> #info While we have 64bit kernels on Aarch64 devices, userspace is in 32bit. Would be great to get an ability of running AARCH64 applications, even without Qt stack. Usecase: Flatpak Aarch64 apps. Details at https://together.jolla.com/question/222109/aarch64-support/ 09:49:05 <Jaymzz> #link https://together.jolla.com/question/222109/aarch64-support/ 09:49:11 <Jaymzz> answer coming up in a sec 09:49:28 <Thaodan> Add multiarch on top of that maybe 09:49:34 <Jaymzz> #info The upcoming toolchain updates will enable aarch64 building of all Sailfish packages, but we're not there yet. Stay tuned for more updates on this. You can bring it up again in another meeting after a while and check the status. 09:50:04 <rinigus> Jaymzz: thanks! 09:50:28 <rinigus> Thaodan: yes, that's exactly what's needed. in addition, we probably need libhybris in 64 bit 09:50:48 <Nico[m]> So there is progress being made on providing a newer gcc or is that a separate topic? 09:51:02 <r0kk3rz> in short yeah 09:51:12 <abranson> Nico[m]: https://git.sailfishos.org/mer-core/gcc/-/tags 09:51:14 <Nico[m]> Yay! 09:51:32 <Thaodan> rinigus: thats np as theirs already some libs that have to 64bit 09:51:37 <rinigus> abranson: nice! 09:51:49 <Nico[m]> Woah, looks nice, I'm eagerly waiting for gcc7+ :D 09:52:02 <piggz> rinigus: no need for 64bit hybris, hybris is dead, long live native sfos ;) 09:52:11 <piggz> Nico[m]: 8 actually :) 09:52:41 <rinigus> piggz: I am trying to stick to current device for some time... 09:52:59 <Nico[m]> Yes, but my dependencies only require at least 7, 8 is a nice cherry on top though! 09:53:29 <Thaodan> Cab I ask something related to thisr? 09:54:00 <schmittlauch[m]> As far as I know insalling aarch64 applications using the Nix package manager already works under Sailfish. 09:54:06 <rinigus> Thaodan: I wonder if it means that I can compile already aarch64 at obs? but libhybris will still have to support it as well, as I use it internally as GL extensions 09:55:03 <rinigus> schmittlauch: thanks! that's interesting and rather promising. I will have to look into it then 09:55:10 <Jaymzz> 4 min left on this 09:55:26 <schmittlauch[m]> But that's likely because Nix pulls *all* userland dependencies down to the libc itself and those are aarch64, so it kinds of builds its multi-arch infrastructure itself 09:55:41 <rinigus> Jaymzz: we can probably move on very soon 09:55:52 <abranson> rinigus: no, there's no aarch64 target yet 09:55:57 <Thaodan> rinigus: you could try to built ob obs, there's already a aarch64 target for mere 09:55:59 <rinigus> schmittlauch: but does it work also for GL? 09:55:59 <Thaodan> +mer 09:56:14 <rinigus> as flatpak also provides own libc 09:56:17 <schmittlauch[m]> rinigus: Well, as long as you have an aarch64 kernel and pull all the user land dependencies in aarch64 as well, thinks should work ;) 09:56:59 <schmittlauch[m]> rinigus: I haven't tried it myself, have heard from someone who uses it to run signal-desktop 09:57:01 <schmittlauch[m]> need to try it out myself 09:57:05 <rinigus> thanks! looks like I need to get more info regarding it and do some homework 09:57:22 <rinigus> on my account, we can moev on 09:58:30 <Jaymzz> alright 09:58:32 <schmittlauch[m]> rinigus: The person to ask regarding the Nix stuff is lzmartinico here on Freenode 09:58:57 <Jaymzz> #topic update on API requirements for approval in store (5 min by ViGe) 09:59:03 <rinigus> schmittlauch: thanks for a pointer 09:59:30 <ViGe> #info In January we promised to write a list of requirements that an API must fullfill in order to be accepted in harbour. 09:59:45 <ViGe> #info Today we have published the abovementioned list 09:59:55 <ViGe> #link https://sailfishos.org/wiki/API_Checklist 10:00:39 <ViGe> btw. Sorry this topic didn't quite make it to the agenda that Jaymzz sent earlier 10:00:55 <r0kk3rz> thanks ViGe 10:02:51 <vknecht> what about using the settings ones, eg. for storage, so an app can easily detect sdcard ? 10:03:07 <ViGe> <ApBBB> a qustion regarding apis. what is missing -related to systemd- 10:03:08 <ViGe> and stops poure maps from making it?? 10:03:32 <r0kk3rz> iirc it was some socket activation thing 10:03:41 <r0kk3rz> rinigus would know more 10:04:05 <rinigus> systemd socket activation is used by osm scout server. 10:04:05 <Thaodan> Support for pyqt would be great. 10:04:13 <rinigus> pure maps waits for qtlocation 10:04:45 <rinigus> (maybe something else as well, but don't remember now exactly) 10:05:14 <rinigus> which brings up a question: how far are we away from qt5.9/5.12? 10:05:31 <ViGe> May I suggest you ask your questions regarding specific apis as separate topics in future meetings - I don't really remember the details of each and every API by heart :/ 10:06:00 <Jaymzz> I agree with ViGe 10:06:21 <schmittlauch[m]> We might want to bring up the recent announcements regarding Qt LTS in the General Discussion rinigus 10:07:18 <abranson> I think the API checklist was a specific issue that needed tackling for harbour requirement. there are others, such as allowing socket activation. 10:09:39 <Jaymzz> Moving on :) 10:10:16 <Jaymzz> #topic general discussion (15 min) 10:10:46 <Nico[m]> So, the developer forum is on track and I didn't miss any announcements regarding that? 10:11:15 <ViGe> Nico[m]: Yes (it is on track) and No (you didn't miss anything) 10:11:25 <Nico[m]> Thanks :D 10:11:44 <schmittlauch[m]> Will the announced changes in Qt LTS support somehow affect Sailfish OS? 10:12:49 <schmittlauch[m]> TL;DR: LTS updates won't be released as Free Software anymore but only under proprietary licenses to Qt licensees. 10:14:04 <schmittlauch[m]> With the current speed of Qt updates in Sailfish that meant Jolla needed to get proprietary licenses for all officially supported devices, and community ports would get in trouble. 10:14:28 <schmittlauch[m]> Maybe this development changes the general strategy of how to upgrade Qt in Sailfish OS? 10:14:38 <Jaymzz> guys since we went over time on one of the topics and I need to leave soon I propose to end the meeting in a minute. I have a task I need to do before lunch and it's very close to lunch time in Sweden (already lunch time in Finland) 10:14:58 <Jaymzz> schmittlauch[m]: Can we take this as its own topic during the next meeting please? 10:15:20 <schmittlauch[m]> Jaymzz: fine for me 10:15:27 <abranson> schmittlauch[m]: wasn't it the case that only the extended support of lts releases is commercial only. for gpl it's just a normal release - there is no free lts. 10:15:44 <Jaymzz> schmittlauch[m]: alright great. Please add it to tjc page then, thanks! 10:15:51 <Jaymzz> Ending the meeting in a few seconds 10:15:56 <Jaymzz> or actually 10:16:13 <Jaymzz> #info Next meeting will be held on Feb 20th 2020 at 09:00 UTC 10:16:21 <Jaymzz> and now I can end the meeting 10:16:30 <schmittlauch[m]> If someone more involved with Qt wants to take this topic, I'm happy to give it away 10:16:31 <Jaymzz> minutes will be emailed as usual 10:16:45 <abranson> for reference, here's the blog post: https://www.qt.io/blog/qt-offering-changes-2020 10:16:46 <Jaymzz> schmittlauch[m]: write that on your topic annoncement on tjc too 10:17:07 <Jaymzz> ending the meeting :) talk to you all soon! 10:17:11 <Nico[m]> Thanks everyone for the meeting! 10:17:14 <Jaymzz> #endmeeting