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