08:00:02 <sledges> #startmeeting Sailfish OS, open source, collaboration – 13th June 2019
08:00:02 <merbot> Meeting started Thu Jun 13 08:00:02 2019 UTC.  The chair is sledges. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
08:00:02 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:08 <sledges> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2019-June/008640.html
08:00:19 <sledges> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please behave and respect the timingsies.
08:00:25 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with # info
08:00:32 <sledges> #info Simonas Leleiva - privateer for Jolla
08:00:49 <lbt> #info David Greaves; mer guy and sailor
08:01:54 <M4rtinK> #info Martin Kolman, community & modRana development
08:02:00 <flypig> #info David Llewellyn-Jones, sailor @ jolla
08:02:08 <ViGe> #info Ville Nummela - sailor @ jolla
08:02:52 <r0kk3rz> #info Lewis Rockliffe, community
08:04:39 <vknecht> #info Vincent Knecht, community
08:05:47 <sledges> ooh more visitors:)
08:06:06 <sledges> #topic Wireguard (VPN) support directly in the Settings  ( https://en.wikipedia.org/wiki/WireGuard ) (30min - asked by bionade24)
08:06:26 <sledges> bionade24 looks AWOL
08:06:36 <sledges> we'll just paste our answers for the record
08:06:42 <sledges> #link https://en.wikipedia.org/wiki/WireGuard
08:06:50 <sledges> We shall break it down question-by-question:
08:06:54 <sledges> #info "Which Userpace Implementation should we use?"
08:06:58 <sledges> #info Apologies, we are not sure
08:07:03 <sledges> #info "Which compiler is the right for Rust or Go?"
08:07:03 <sledges> #info Sorry, we cannot help here either
08:07:09 <sledges> #info "Could we use the QrCode feature in the UI?"
08:07:13 <sledges> #info Currently the VPN plugins for the settings app are implemented entirely in QML. They're essentially designed to send a dictionary of configuration options to connman, via VpnModel (see https://git.merproject.org/mer-core/nemo-qml-plugin-systemsettings/blob/master/src/vpnmodel.h). For an example, see the VPNC QML config UI elements in /usr/share/sailfish-vpn/vpnc on your device. You can pull in a
08:07:19 <sledges> plugin that...
08:07:38 <sledges> #info ...plugin that implements what you need (i.e. ZXing library) for scanning QrCodes by installing the shared libraries in /usr/lib/qt5/qml/Sailfish/. This won't get past harbour validation though.
08:07:52 <sledges> #link https://git.merproject.org/mer-core/nemo-qml-plugin-systemsettings/blob/master/src/vpnmodel.h
08:08:02 <sledges> #info Unless we're misunderstanding your plan here, to get all this to work seamlessly, you'll also need to create a connman plugin for Wireguard. Here's the code for the existing connman VPN plugins: https://git.merproject.org/mer-core/connman/tree/master/connman/vpn/plugins
08:08:18 <sledges> #link https://git.merproject.org/mer-core/connman/tree/master/connman/vpn/plugins
08:09:23 <sledges> we'll close this quickly, since the person who asked is not present
08:10:45 <r0kk3rz> the Go userspace would work i think
08:10:52 <r0kk3rz> rust maybe not
08:10:56 <vknecht> did you think about adding wireguard support in kernel for official devices (if it's not already; didn't check...) ?
08:11:06 <r0kk3rz> cant
08:11:09 <r0kk3rz> too new
08:11:30 <vknecht> or too conservative ? ;-)
08:11:47 <M4rtinK> is Wireguard even in mainline yet ?
08:11:51 <vknecht> just asking, seen a bunch of LOS port using it
08:12:14 <r0kk3rz> if you want to backport it to each kernel, then sure
08:13:39 <sledges> #info <r0kk3rz> the Go userspace would work i think, rust maybe not
08:13:57 <vknecht> it was getting close to be mainlined some months ago, maybe just a round or two yet
08:15:20 <M4rtinK> in any case there seems to be a lot happening aroud the Wireguard project
08:16:54 <sledges> more info from TJC from bionade24:
08:17:05 <sledges> #info Why using the kernel module is difficult: https://together.jolla.com/question/182324/wish-wireguard/
08:17:08 <r0kk3rz> in the past ive been able to throw on go arm binaries, and they just worked
08:17:13 <sledges> #link https://together.jolla.com/question/182324/wish-wireguard/
08:17:51 <sledges> thanks for the comments, let's hope the author or someone else picks this up again in two weeks
08:17:56 <sledges> #topic Scratchbox2 vs glibc; or, limitations of hooking of public api's; dockerization as a solution (30 min - asked by tortoisedoc)
08:18:18 * sledges looks around for tortoisedoc
08:18:52 <r0kk3rz> lol tdoc, i dont know what you think docker is
08:18:59 <r0kk3rz> but a scratchbox replacement it is not
08:19:48 <sledges> it's a relevant topic, so we'll see it through, yet rules state you should be present
08:20:11 <lbt> Shall I ?
08:20:15 <sledges> sec
08:20:34 <sledges> (i made an exception to bionade24 as they are a new person in community, tortoisedoc however isn't)
08:20:37 <sledges> #info What is the plan on the scratchbox2? Currently it is part of the official SDK, but it appears it's limits are starting to show (see for example problems with hooking "internal" api's of glibc, which causes some libraries / api's / apps not to work properly (spawn api, llvm amongst others); supporting those will need carefully evaluation of the consequences as it might require patching of glibc).
08:20:46 <sledges> #info Is docker considered a possible replacement? If so, is there a timeframe for it to land in the SDK?
08:20:56 <sledges> Here's Jolla's take on this question:
08:21:03 <sledges> #info This question needs a little more clarification. sb2 is used to to bypass qemu emulation of certain executables during non-native builds. Docker does not provide any functionality comparable to sb2. sb2 works very well and we will continue to use it in this role.
08:21:25 <sledges> #info Although it is mature, sb2 is a sophisticated tool and does interact deeply with the system (including glibc) so a degree of maintenance is required over time. This is by no means an undue burden given the benefits of the tool.
08:21:40 <sledges> #info Docker is a (relatively new, complex and constantly changing) container technology; this role is provided by the cross-platform Virtualbox in the SDK. The community has provided native linux solutions to contain the SDK (eg chroot) and these offer benefits (lower overheads for parallel builds) but also disadvantages (exposure to different kernel versions or host security policies like selinux).
08:21:56 <sledges> go ahead lbt:)
08:23:15 <lbt> not much to add - I think we're doing some docker experiments but the main issue is likely to be supporting it in the wild. VBox is really easy to support.
08:23:30 <M4rtinK> /me would suggest using podman instead of Docker if one wants to build a new container based something
08:24:02 <lbt> fwiw I personally found supporting docker on my local machine for my personal use to be so hard I stopped using it :D :D
08:24:26 <lbt> M4rtinK: ah - but buzzword...
08:24:44 <r0kk3rz> docker is good because everything supports it
08:25:29 <flypig> What's so painful about docker? I've not used it in earnest, but many people really swear by it.
08:25:33 <M4rtinK> its basically Red Hats sane reimplementation of Docker, without a carzy daemon & need to run it all under root
08:25:50 <M4rtinK> & its fully compatible with existing docker files
08:26:00 <r0kk3rz> 'sane reimplementation' ah so docker wasnt NIH compatible ;)
08:26:12 <lbt> there are a lot of issues - including networking and the bloody daemon
08:26:13 <M4rtinK> ;-)
08:26:43 <M4rtinK> at least that bloody daemon should not be there for podman AFAIK
08:26:49 <lbt> it's great for supporting lots of dynamic containers
08:27:21 <lbt> but what we want is a single, simple container ... a chroot basically
08:28:01 <flypig> a chroot that's compatible across all systems though.
08:28:06 <lbt> the main issue I see is that docker versions will vary so much over different distros and versions that support will be a killer
08:28:08 <flypig> Including Windows and MacOs
08:29:10 <M4rtinK> what about Mock then ? https://github.com/rpm-software-management/mock/wiki
08:29:14 <lbt> flypig: I hope we'd still support Vbox for those (and the 60% of linux that didn't work ;) )
08:29:43 <r0kk3rz> vbox is fine tbh
08:30:03 <lbt> r0kk3rz: it has issues with IO and poor cpu usage
08:30:19 <lbt> but I agree it does the job pretty well and with very little support cost
08:30:24 <M4rtinK> Mock is used for all regular Fedora/RHEL/Mageia package builds
08:30:49 <lbt> M4rtinK: yeah - it's similar to the OBS/osc 'build' I think
08:30:59 <M4rtinK> well, asside from that out of tree kernel module it needs...
08:31:04 <lbt> haha
08:31:09 <M4rtinK> lbt: yep, most likely similar
08:31:30 <lbt> I used to use osc to create a chroot and then use that for the Mer CLI SDK
08:31:45 <lbt> anyhow... rambling now ;)
08:33:27 <r0kk3rz> a jolla proided docker sdk would be nice though
08:33:39 <r0kk3rz> currently the community provides one
08:34:48 <vknecht> speaking of OBS/osc, "osc repourls" returns hardcoded http://download.opensuse.org it seems...
08:36:12 <sledges> 10min remaining and we're drifting away to OBS;) since neither tdoc is here nor there was an assigned substitute, let's make general discussion longer a tad
08:36:43 <sledges> #topic General discussion (25min)
08:36:58 <sledges> #info action points review: http://meetingwords.com/sailfishos-community-irc
08:37:01 <sledges> #link http://meetingwords.com/sailfishos-community-irc
08:37:16 <sledges> #info evaluate possibility to mark apps as experimental
08:37:23 <sledges> #info We have had some discussions about this internally. We might implement something like this in the future, but this is not considered a high priority as experimental apps can always use open repos. Instead, we plan on maturizing some APIs, which also means that it is possible for us to allow them in harbour.
08:38:49 <r0kk3rz> so, when sailfish X for pinephone? ;)
08:39:01 <M4rtinK> cheking what applications are popular on Open Repos & what APIs they are using could provide a good set
08:39:45 <sledges> speaking of APIs..
08:39:47 <sledges> #info evaluate possibility to allow systemd socket activation.
08:39:51 <sledges> #info We are planning to create an API for this kind of functionality, but it will take time.
08:40:29 <M4rtinK> and possibly even reaching out to the app authors to find out about the main Harbour pain point they have encountered & that prevented them from submitting their popular apps to the Jolla store
08:42:10 <M4rtinK> sledges: just allowing shipping the needed (IRRC) unit files is not good enough ?
08:42:28 <tortoisedoc> duh just missed it
08:42:41 <tortoisedoc> sorry guys
08:43:28 <ViGe> M4rtinK: allowing shipping the unit files opens too many ways to break the entire system
08:44:22 <M4rtinK> unit files are simple ini files, it should not be hard to scan them and allow that one option
08:44:24 <r0kk3rz> isnt that what QA is for?
08:44:35 <tortoisedoc> sledges : thanks for the info (saw from the logs); please be assured, I am trying to find a way forward to the limitations I faced when working on LLVM in mer
08:44:45 <tortoisedoc> im not saying SB2 is obsolete :)
08:45:10 <ViGe> M4rtinK: Yes, that is indeed one way to do it
08:45:21 <M4rtinK> not to mention maybe whiteliating that one most popular native app on the whole platform and review it by hand when its updated ~once a month
08:46:20 <r0kk3rz> pfft, who wants maps anyway
08:46:32 <tortoisedoc> sledges, lbt: thanks for clarifying about docker as well; what I can take from this is that SB2 is not going anywhere anytime soon
08:46:35 <M4rtinK> it really seems like this is taking much too long for the impact it has & further reinforces the general feeling of neglect for Jolla Store and native app developers in general...
08:46:52 <lbt> tortoisedoc: +1 :)
08:46:53 <tortoisedoc> so a solution for the hooking problems has to be (yet) found
08:47:47 <bionade24> sledges: Sorry, I have bad Internet connection and couldn't enter earlier. I saw the infos in the logs and will try to implement my wishes.
08:48:35 <flypig> M4rtinK, I agree about the timing, but if openrepos didn't exist, the priority would likely be higher.
08:48:39 <r0kk3rz> bionade24: if you want help, sing out in #sailfishos
08:49:04 <tortoisedoc> lbt, sledges : all in all, I think this narrows down the options on how to "fix" sb2 as well; either we patch glibc and replace internal api's with external counterparts (hairy and scary), or we handle hooking differently?
08:49:26 <tortoisedoc> (if possible at all, that is)
08:49:56 <lbt> tortoisedoc: I think we need to look at your specific problem in more detail
08:50:14 <M4rtinK> flypig: agreed, still a bit weird to see the official distribution channel being so neglected
08:50:27 <tortoisedoc> lbt : that'd be awesome; here's a detailed description with links to bug reports too : http://kastlunger.blogspot.com/2019/04/lets-do-time-warp-again-or-compile-llvm.html
08:50:34 <bionade24> r0kk3rz: Thanks, will do when necessary.
08:51:02 <lbt> tortoisedoc: we probably want a tjc entry - then we can link that to an internal bug
08:51:26 <lbt> have a word with James when he's around
08:51:34 <tortoisedoc> lbt : I did a bug report on the old mer bugzilla (see the post for the links), does that help?
08:51:41 <tortoisedoc> (a few reports actually)
08:51:55 <tortoisedoc> James Bond? :)
08:52:09 <lbt> it's good to have the info but the only links we can track are tjc
08:52:20 <tortoisedoc> okay
08:52:27 <tortoisedoc> more posts required
08:52:31 <tortoisedoc> got it
08:52:38 <lbt> Just one is fine
08:52:52 <lbt> make sure james links it to an internal bug is all
08:53:16 <tortoisedoc> okay
08:53:19 <lbt> all other stuff will not be tracked and only one tjc post - so ... keep it focuses
08:53:21 <flypig> M4rtinK, yes, true. But I don't think it should be seen as a reflecting the importance of native devs!
08:53:29 * sledges can do the same, James is too involved elsewhere these days
08:54:34 <pketo> lbt: mer bugs can be tracked
08:55:03 <sledges> 5mins remain
08:55:13 <sledges> pketo: but that is only one way street
08:55:35 <sledges> on TJC community can see its internal status
08:55:50 <r0kk3rz> you can?
08:56:05 <sledges> tracked by jolla -> released by jolla
08:56:19 <sledges> also appears in release notes then
08:56:54 <r0kk3rz> amazing
08:57:03 <r0kk3rz> never seen a 'released by jolla' sounds fancy
08:57:12 <pketo> well, ok :)
08:57:21 <vknecht> 3.1 news ? :-)
08:57:29 <sledges> https://together.jolla.com/question/190204/pulse-audio-12x-for-sailfish-x/
08:57:39 <sledges> Tracked by Jolla (In release)
08:57:44 <r0kk3rz> must be time for qt5.9 right?
08:58:02 <tortoisedoc> okay ill roll my sleeves up an get a post readyu
08:58:12 <sledges> vknecht: hints from new strings: https://twitter.com/JollaHQ/status/1138145981705441282
08:58:27 <lbt> you can link to the other resources - no need to make it massive
09:01:20 <sledges> alrighty, lunch for the Finns is approaching, moving on to next meeting time, thanks all for comments, please don't be late next time, or simply find a substitute not to be a lone wolf ;)
09:01:26 <sledges> #topic next meeting time and date
09:02:05 <flypig> Hmm. Isn't that today?
09:02:12 <sledges> #info Next meeting will be held on 27th June 2019 at 08:00 UTC
09:02:31 <sledges> flypig: it's merbots topic suffix for every #topic, not a next date:)
09:02:36 <flypig> Oh, sorry. Impatient.
09:02:42 <sledges> James will be back in action by then
09:02:53 <sledges> cheers and gone!
09:02:54 <sledges> #endmeeting