08:00:01 <sledges> #startmeeting Sailfish OS, open source, collaboration 19th April 2018
08:00:01 <merbot> Meeting started Thu Apr 19 08:00:01 2018 UTC.  The chair is sledges. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
08:00:01 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:14 <sledges> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2018-April/008363.html
08:00:21 <sledges> 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-have:]
08:00:25 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with # info
08:01:41 <r0kk3rz> #info Lewis Rockliffe - community
08:01:41 <lbt-> #info David Greaves, sailor and Mer guy
08:01:59 <abranson> #info Andrew Branson, Jolla dev
08:02:01 <ced117> #info Cedric Heintz, community member
08:02:15 <ljo> #info Leif-Jöran Olsson, community
08:02:49 <sledges> #info Simonas Leleiva, sailor'n'chair
08:02:59 <pketo> #info Pami Ketolainen, sailor @ Jolla
08:03:05 <chriadam__> #info Chris Adams, developer at Jolla
08:03:35 <veskuh> #info Vesa-Matti Hartikainen, Program Manager at Jolla
08:04:26 <eekkelund> #info eekkelund
08:06:14 <sledges> #topic Sailfish 3 introduction (5min - asked by Sanjeev/snj33v)
08:06:35 <sledges> Sanjeev/snj33v is not present, that's a pity, because one question wasn't clear
08:06:45 <sledges> #info can we get deeper preview of new APIs besides the one already mentioned in MWC?, will there be any sandboxing for the applications we develop?, how long we still need to rely on android support in jolla store?, willl keyboard finally support emojis?
08:07:20 <sledges> #info New APIs: Location, Camera, WebEngine, VPN, Crypto, Secrets; taken from:
08:07:25 <sledges> #link https://jolla.com/sailfish3/
08:07:28 <ApBBB> emojis are comming in 2.2 according to the strings we had to translate
08:07:30 <r0kk3rz> i guess i can paraphrase, is there anything that app developers need to know about for Sailfish 3?
08:07:44 <r0kk3rz> particularly things like app sandboxing
08:07:51 <sledges> r0kk3rz: one question amongst small ones
08:08:09 <sledges> #info app sandboxing: We are working on SELinux access control, but that won't land this year. App sandboxing is a bit different story.
08:08:29 <sledges> we didn't fully understand "How long we still need to rely on android support in jolla store?"
08:08:55 <r0kk3rz> yeah thats a bit vague...
08:08:58 <sledges> #info Emoji keyboard will already be in 2.2.0; color emojis come when we move to Qt 5.9.
08:09:00 <ApBBB> this is more likely  a when people will start developing apps for sfos :P
08:09:06 <ced117> right :/ that's a bit hard to understand
08:09:25 <ApBBB> sledges: any eta on 5.9?
08:09:38 <chriadam__> regarding Secrets+Crypto APIs, it's being fully developed in open, we would greatly appreciate feedback/testing (from developers and particularly crypto experts!) - see https://github.com/sailfishos/sailfish-secrets
08:09:43 <sledges> ApBBB: just been moved by couple of weeks since you asked ;)
08:10:07 <sledges> #info Facebook, Twitter, WhatsApp, etc. won't be making native Sailfish OS apps any time soon. so you will still have to rely on android support, if we understood your question correctly
08:10:21 <ApBBB> sledges: i'll ask each time we have a meeting to sabotage development :D
08:10:28 <sledges> :D
08:10:35 <r0kk3rz> twitter works fine in browser tbh
08:10:48 <sledges> #info regarding Secrets+Crypto APIs, it's being fully developed in open, we would greatly appreciate feedback/testing (from developers and particularly crypto experts!) - see https://github.com/sailfishos/sailfish-secrets
08:10:54 <sledges> #link https://github.com/sailfishos/sailfish-secrets
08:10:58 <ApBBB> there is also an app that is full featured i think
08:11:08 <r0kk3rz> theres a few, but they arent official
08:11:34 <sledges> if that app (sfos or android) uses push notifications, then we're soon out of luck; http://apps-of-a-feather.com/
08:11:49 <ced117> just use the browser for these social media thing or use some apps developed by the community
08:12:11 <ApBBB> as long as it works it doesn't have to be official. of couurse the APIs can change but yeah.
08:12:13 <sledges> ced117: the world sadly still rely their lives on WhatsApp :/
08:12:30 <sledges> only 5mins was allotted for this topic, author not present, let's move on
08:12:31 <r0kk3rz> ok back on topic, anything else you guys can tell us about sailifsh 3?
08:12:38 <sledges> r0kk3rz: gen disc ;)
08:12:49 <ced117> sledges: sadly :(
08:12:52 <sledges> #topic Community solutions to long standing problems (mapping and text
08:12:58 <sledges> #undo
08:12:58 <merbot> Removing item from minutes: <MeetBot.items.Topic object at 0x38696d0>
08:13:13 <sledges> #topic Community solutions to long standing problems (mapping and text prediction) and how to get them on all phone (10min - asked by ApBBB)
08:13:41 <sledges> #info The community has developed solutions for both mapping (which sucks) and text prediction (which isn't available to every language). And we need them on the store or integrated in the OS. So how the community can help speed things up and who from jolla has to get things moving.
08:13:56 <sledges> #info Developer offering will see many improvements in 2018-2019. We are planning to open Qt Location after Qt upgrade 5.9
08:14:32 <sledges> #info regarding WhoGo Maps to jolla store (https://github.com/sailfishos/sdk-harbour-rpmvalidator/issues/102#issuecomment-367373788) -- Some kind of background activity support is high on the list, but there are no exact schedule we could share
08:14:50 <sledges> #info Any newer news on "we are working contribution agreement template that would allow giving community developer access to the needed private repos, helping develop things like integrating different prediction engines to Sailfish OS keyboard"? Agreement has been drafted, currently in approval process
08:15:41 <ljo> +1
08:15:45 <r0kk3rz> i guess we can come up with some instructions to install the text prediction stuff to ported devices
08:15:57 <r0kk3rz> since they dont come with xt9
08:16:02 <ced117> right
08:16:32 <ApBBB> sledges: is it possible some components that are used by all mapping apps to be integrated in mer in some way.
08:16:36 <M4rtinK_phone_> sad the OSM Scout Server blocker has still not been resolved
08:16:49 <ced117> talking about mapping apps, poor maps is not bad.
08:17:13 <ApBBB> poor maps = who go
08:17:15 <sledges> #info to avoid misunderstanding in the orig topic info: The community has developed solutions for both mapping ([to replace Jolla's offering] which sucks) and text prediction ([to replace Jolla's offering] which isn't available to every language)
08:17:16 <ApBBB> more or less
08:17:27 <ced117> oow, the name has changed ?
08:17:33 <ljo> But the text prediction instructions are not different for ported devices compared to officially supported devices
08:17:36 <r0kk3rz> well. except they're different, but aaanyway
08:18:11 <r0kk3rz> ljo: no, but we can install it in the image
08:18:15 <M4rtinK_phone_> effectively ignoring the needs of likely the most active area of third party development, which is also implementing the most voted Together question, is really really bad
08:18:25 <ced117> will take a look later, thanks for the info ApBBB
08:18:33 <M4rtinK_phone_> we are now in November 2013 anymore...
08:18:38 <r0kk3rz> M4rtinK_phone_: whats the problem for OSM scout server?
08:19:29 <sledges> ApBBB: such as including OSM scout server to mer-core?
08:19:31 <r0kk3rz> ljo: do you have a link for the text prediction install?
08:19:32 <ljo> rOkk3rz: sure, imagewise,
08:19:53 <M4rtinK_phone_> can't link to systemd libs so can't do socket activation in Jolla Store
08:20:14 <sledges> #info WhoGo Maps is a continuation of Poor Maps (the latter is not actively developed anymore), so everyone's very welcome to test try WhoGo Maps from openrepos
08:20:17 <sledges> #link https://openrepos.net/content/otsaloma/whogo-maps
08:20:20 <ApBBB> sledges: something like that. its a dependency to many apps that use it AFAI understand
08:20:27 <M4rtinK_phone_> this was possible before for Store apps
08:21:08 <M4rtinK_phone_> of course works just fine if installed from OpenRepos/manually
08:21:27 <sledges> M4rtinK_phone_: we just answered the position on libsystemd; socket activation = background process (?)
08:21:27 <r0kk3rz> must've bricked some phones :)
08:21:30 <M4rtinK_phone_> r0kk3rz: ^
08:21:38 <ApBBB> the only problem is the whole manual and open repos situation
08:21:58 <ApBBB> all apps should be tap install on the store and use
08:22:27 <ApBBB> and it doesn't feel nice to have different stores.
08:22:29 <M4rtinK_phone_> sledges: I've read that and I'm saying that it's sad/bad/ridiculous ;-)
08:22:36 <ljo> r0kk3rz: go to any keyboard from https://openrepos.net/user/12231/programs
08:22:38 <sledges> ok, so we are on the same page now :D
08:22:59 <sledges> it's not safe to have arbitrary daemons running from store, also for performance footprint
08:23:07 <sledges> i can't imagine this has ever been allowed
08:23:11 <r0kk3rz> ljo: are they on obs?
08:23:22 <M4rtinK_phone_> if the likely most wanted app on your platform cant be in your official store, something is wrong :)
08:23:31 <sledges> but i do remember discussions about how to put this under control
08:23:57 <sledges> trying to explain what is wrong, need to address that
08:24:00 <M4rtinK_phone_> sledges: see the issue, it worked fine in the past & QA acked it
08:24:10 <r0kk3rz> well considering OSM scout server is used in more than one app :)
08:24:11 <M4rtinK_phone_> also, its not really a daemon
08:24:39 <sledges> then what is it?:)
08:24:45 <ljo> r0kk3rz: yes, in obs too,  but then I need to switch from phone to enter url
08:25:04 <r0kk3rz> ljo: its ok i'll find it
08:25:05 <sledges> something that runs in a background, was deemed impactful enough
08:25:11 <M4rtinK_phone_> and its not a real daemon - it shuts down after a short while if no requests come to the socket in a while
08:25:29 <sledges> how does it come back up then? invoked by its clients?
08:25:40 <lbt-> that's just an efficient daemon using modern socket activation to be sensible
08:26:01 <M4rtinK_phone_> sledges: I could say we had 5 years to come with a solution for this ;-)
08:26:02 <lbt-> inetd used to do the same things for inetd managed daemons :)
08:26:19 <sledges> so could we allow such modern daemons?
08:26:44 <r0kk3rz> well like everything in the store, it'll want to go through some QA to make sure its well behaved
08:26:45 <lbt-> It's worth discussing I think
08:26:59 <M4rtinK_phone_> also, do we have *any* information about OSM Scout Server causing issues due to socket activation ?
08:27:11 <M4rtinK_phone_> or are we just guessing ?
08:27:14 <lbt-> we need to review why it's a problem
08:27:30 <sledges> i think i seen complaints on jolla 1 - mapping+osm combo becomes too resource heacy
08:27:33 <sledges> *heavy
08:27:39 <lbt-> M4rtinK_phone_: it's more to do with managing OTA to be reliable
08:27:54 <sledges> OTA is now in privileged mode (after reboot)
08:27:55 <abranson> it can't be allowed just for one daemon. if the rules change then they change for everyone
08:28:04 <lbt-> abranson: why?
08:28:17 <r0kk3rz> yeah the whole apps break OTA situation is really bad
08:28:23 <M4rtinK_phone_> abranson: frankly, I would be fine with special casing in this case
08:28:26 <abranson> I mean it's not relevant if OSM Scout Server in particular causes issues
08:28:42 <M4rtinK_phone_> how does socket activation break OTA ?
08:28:46 <abranson> if we allow a mechanism for socket activated daemons, then it should be available for everyone
08:28:58 <lbt-> abranson: I was going to offer the suggestion that we could actually look at having some special cases. I doubt we have the resources to do it though
08:29:05 <M4rtinK_phone_> there are no scriptlets or DBUS service files involved
08:29:56 <ApBBB> another solution would be jolla to addopt whomaps officially. the rules dont apply on their own apps :P
08:30:15 <lbt-> abranson: it would put QA load on releases to validate apps which have exemptions to harbour rules
08:30:16 <abranson> also there are lots of daemons that need to run all the time - socket activation wouldn't be a good solution
08:30:28 <M4rtinK_phone_> lbt, abranson I would thing special case likely the most requested feature (mapping) of your platform would not be that hard, especially if the issues are mostly theoretical
08:30:29 <abranson> e.g. situations, which I think really deserves to be a daemon
08:30:48 <sledges> #info (discussing about allowing socket activated daemons, read full logs for that)
08:30:55 <lbt-> abranson: that's a design decision for the implementation
08:31:05 <lbt-> eg if the startup cost is high
08:31:34 <M4rtinK_phone_> abranson: can't we just allow socket activation first - thats enough for OSM Scout Server
08:31:36 <lbt-> I really think we need to review the original reasoning for banning this
08:31:53 <lbt-> then see if it still applies
08:32:07 <pketo> I'm not sure but I think the main issue is that problems in systemd units might lead to non booting device? I don't know if that would apply to socket activated things, or if there is a way to prevent bad unit from breaking everything
08:32:12 <M4rtinK_phone_> we should not lup it together with general daemlns or else it will never be done
08:32:32 <lbt-> we were a bit conservative - OTOH we also found some "OMG that's a good point that would kill OTA" things
08:32:51 <M4rtinK_phone_> pketo: how can socket activation break boot ?
08:33:02 <abranson> M4rtinK_phone_: I think the whole problem needs to be addressed together. It's not a simple topic, which is why it's taken so long. It also means it should be half-solved, or we might end up in a worse situation
08:33:09 <M4rtinK_phone_> unless a user start an app it will never be activated
08:33:19 <lbt-> M4rtinK_phone_: the point of this is to add a socket activated service that 'other' apps depend on ? yes?
08:33:21 <abranson> also don't forget that iOS didn't allow third party daemons for a very, very long time
08:33:35 <pketo> M4rtinK_phone_: you need a unit file describing the socket activated services, right?
08:33:41 <sledges> could also be that conventional daemons and socket activated ones need to depend on libsystemd, and atm there's no easy way to make such distinction
08:33:49 <sledges> (see the link above to github)
08:33:56 <M4rtinK_phone_> lbt-: yes - poor/whogo maps/modRana and some other maps
08:33:59 <lbt-> so now you have a shitload of issues caused by adding dependency into Harbour which we simply don't have and has massive issues for version control
08:34:31 <lbt-> we now have to QA all kinds of permutations of apps too
08:35:23 <Mister_Magister> um i would like to remind about blocking app modules in store
08:35:27 <lbt-> what if 2 apps need to be uploaded in lockstep
08:35:49 <Mister_Magister> like if some app have plugins… this was discussed long time ago
08:35:50 <lbt-> so dependency was a really really hard Harbour problem to solve
08:36:05 <lbt-> Mister_Magister: same dependency issue
08:36:11 <M4rtinK_phone_> isn't that a thin app authors should care about ?
08:36:15 <Mister_Magister> thats why im mentioning :)
08:36:31 <Mister_Magister> and also that you cant send plugin as app that does nothing
08:36:37 <lbt-> so just mentioning that this isn't a simple "we don't like daemons" thing
08:36:50 <M4rtinK_phone_> store QA should just care about the app starting up, not crashing and keeping by the rules
08:36:51 <abranson> If someone installs WhoGo from the store, should they be told it needs OSM Scout Server?
08:37:02 <Mister_Magister> no not really
08:37:06 <Mister_Magister> it can use internet for maps
08:37:17 <r0kk3rz> abranson: I dont think it *needs* it, just is enhanced by it
08:37:24 <sledges> for routing
08:37:29 <M4rtinK_phone_> modRana is in store and needs OSM Scout Server for most things
08:37:30 <Mister_Magister> like i plugin i was talking about
08:37:31 <abranson> it was an example of dependency handling by the store
08:37:40 <Mister_Magister> this was discussed already :P
08:38:13 <M4rtinK_phone_> but now I need to tell people - you need to go elsewhere or else all offline functionality will not work
08:38:21 <lbt-> nb .. this doesn't mean that a bundled whogo/OSM should not be allowed socket activation
08:38:31 <lbt-> they are different issues
08:38:32 <ApBBB> abranson: osm scout shoul be handles as a dep in any distro. hence it needs to be in mer
08:38:39 <ApBBB> or whereever appropriate
08:39:03 <r0kk3rz> it can be bundled
08:39:28 <M4rtinK_phone_> again I'm thinking we are blocking a simple solution (socket activation) by perfect (appbdepdendencies and full daemons) that will happen in thousand years if ever
08:39:37 <ApBBB> r0kk3rz: yeah but what if someone wants to use mod rana -or any other app using it. its a waste to be bundled in all apps
08:39:55 <abranson> M4rtinK_phone_: simple partial solutions often cause much bigger problems down the line though
08:39:58 <r0kk3rz> ApBBB: not a huge amount, who really needs multiple mapping apps?
08:40:03 <lbt-> ApBBB: apps aren't a distro :)
08:40:12 * M4rtinK_phone_ started working on getting OSM Scout Server packaged to Fedora
08:40:15 <abranson> r0kk3rz: i wonder that too - does it have to be a server?
08:40:19 <sledges> lbt-: containers have a different idea:))
08:40:31 <ApBBB> r0kk3rz: people are weird :P
08:40:39 <lbt-> sledges: our apps are more like containers indeed
08:40:59 <r0kk3rz> ApBBB: sure and they can do what they like, but having 2-3 copies of osm scout isnt super wasteful
08:41:08 <M4rtinK_phone_> abranson: again, do we have any concrete reported cases where OSM Scout Server socket activation caused issues ?
08:41:56 <abranson> M4rtinK_phone_: again, considering special cases like that isn't really useful. there are plenty of apps that would become the next critical special case.
08:41:58 <lbt-> r0kk3rz: it's also more reliable and allows independence
08:42:35 <lbt-> abranson: agreed - but I do wonder about special casing some things
08:42:39 <M4rtinK_phone_> r0kk3rz: don't forget OSMSS manages offline data & data updates - many many GBs
08:43:00 <sledges> #action Jolla to try and prioritise background services allowance in Harbour a tad more (considering decoupling daemons that feature socket activation)
08:43:03 <abranson> but personally, i think systemd's mechanisms for managing daemons is completely adequate - our problem is monitoring
08:43:09 <lbt-> M4rtinK_phone_: and what happens when OSMSS upgrades the API
08:43:09 <M4rtinK_phone_> r0kk3rz: so also data compatibility
08:43:10 <r0kk3rz> M4rtinK_phone_: block level dedup? :)
08:43:29 <lbt-> and you have one oldish app using the old one and a newer one using the new API
08:44:03 <lbt-> and the old one is good but no longer actively maintained - it's also not open source
08:44:06 <M4rtinK_phone_> not to mention OSM scout server is actuallynpretty big (map renderin libs and fonts, poi search libs, valhalla routing libs, etc)
08:44:18 <lbt-> dependency hurts
08:44:30 <M4rtinK_phone_> combined with bad rootfs size decisions on Sailfish X...
08:44:45 <sledges> sd card?
08:45:03 <r0kk3rz> all that stuff should go in abuser data anyway
08:45:05 <abranson> M4rtinK_phone_: apps really shouldn't be using rootfs in sailfish.
08:45:16 <M4rtinK_phone_> sledges: installing apps on sd card ? really ?
08:45:24 <sledges> M4rtinK_phone_: saving tiles, and what abranson said
08:46:18 <sledges> we've stolen quite a lot from general discussion, so let's move on
08:46:19 * abranson fondly remembers optification on maemon
08:46:28 <sledges> #topic General discussion (10mins)
08:46:53 <r0kk3rz> perhaps but that was a good discussion :)
08:47:07 <sledges> it was yes
08:47:11 <M4rtinK_phone_> I hope so :)
08:47:20 <ApBBB> i think i had put a note on that the topic might need more time :)
08:47:40 <M4rtinK_phone_> even better if it results in something soon ;-)
08:47:45 <abranson> yeah, it would be great to kickstart allowing daemons. esp now the phones have more RAM
08:47:46 <ApBBB> hopefully we'll get results soon and not have to wait for ages
08:47:46 <sledges> all good, general discussion was given 20mins originally;)
08:47:50 <r0kk3rz> SoonTM always
08:48:03 <sledges> jolla 1 deprecation? :(
08:48:12 <sledges> can't have it all:) i just know many still use it
08:48:13 <abranson> we can't be too hasty. hoom hom
08:48:25 <lbt-> if someone in the community wants to arrange an irc meeting about those issues then we can spend more time on it
08:48:29 <M4rtinK_phone_> I'm readdy to answer any questions related to this & rinigius (over email) is likely as well
08:48:34 <ApBBB> sledges: i don't mind j1 being deprecated. i hate the HW you choose after that :/
08:49:14 <lbt-> #info if someone in the community wants to arrange an irc meeting about the app/harbour issues then we can spend more time on it
08:49:35 <sledges> a nice support group idea!:))
08:50:50 <M4rtinK_phone_> any takers ? I can do that but would rather particape than organize the whole thing :)
08:51:13 <M4rtinK_phone_> *participate
08:51:41 <lbt-> we don't have to arrange it in this meeting (and we probably shouldn't) :)
08:51:42 <r0kk3rz> M4rtinK_phone_: you want it, so organise it :P
08:52:02 <lbt-> => #sailfishos ??
08:53:30 <M4rtinK_phone_> I guess we can talk later on and arrange a date
08:53:45 <sledges> M4rtinK_phone_ might feel a bit jaded on the subject after all these years:)
08:54:15 <M4rtinK_phone_> a bit ;-)
08:54:23 <ApBBB> i don't see why this can't be part of a normal meeting. more sailors attend i believe
08:55:16 <M4rtinK_phone_> I'm fine with that as well
08:55:57 <M4rtinK_phone_> the topic could be auto added until the issue is resolved o:-)
08:55:58 <lbt-> I was thinking we could spend a lot of time on it and then present the ideas in these meetings - the time in these meetings is quite short
08:56:24 <sledges> this one is to work on actual solution(s), those who know how harbour works internally and have immediate connection to its sailors (or are themselves)
08:57:01 <lbt-> and part of arranging it is to try and find time when sailors can attend
08:57:23 <lbt-> so not when I'm out at Salsa ...
08:57:26 <lbt-> :D
08:57:44 <sledges> #info community to try spinning off harbour background services allowance support group, to be continued on #sailfishos
08:57:58 <sledges> and we're up time-wise!
08:58:00 <sledges> AOB?
08:58:10 <sledges> (realquick)
08:58:34 <M4rtinK_phone_> so maybe a sailor should set the times ?
08:58:53 <M4rtinK_phone_> if it basically about internal developer availability
08:59:29 <sledges> trying to involve community and hear their voices more, after all it's them who write apps
08:59:36 <lbt-> *cough* community *cough* proactive *cough*
08:59:36 <sledges> #topic Next meeting date
09:01:45 <sledges> next week #fossnorth2018
09:02:00 <sledges> so perfect time to do it in another fortnight as per the usual
09:02:24 <sledges> 08:00 UTC 3rd May 2018
09:02:27 <sledges> +1?
09:03:04 <abranson> +1
09:03:06 <lbt-> +1
09:03:15 <ljo> +1
09:03:20 <r0kk3rz> make it so!
09:03:43 <sledges> #info Next meeting will be held on Thursday, 08:00 UTC 3rd May 2018
09:03:49 <sledges> thanks y'all!
09:03:51 <sledges> #endmeeting