08:00:01 <Jaymzz> #startmeeting Sailfish OS, open source, collaboration – May 31st 2017
08:00:01 <merbot> Meeting started Wed May 31 08:00:01 2017 UTC.  The chair is Jaymzz. 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:15 <Jaymzz> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2017-May/007902.html
08:00:26 <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.
08:00:40 <Jaymzz> #topic Brief introduction (5 min). Please prefix your name/handle with # info
08:00:55 <Jaymzz> #info James Noori, Community manager at Jolla
08:01:09 <r0kk3rz> #info Lewis Rockliffe, Community
08:01:20 <DylanVanAssche> #info DylanVanAssche, Sailfish app developer & community member
08:01:21 <kimmoli> #info Kimmo Lindholm, community et.al.
08:01:28 <lpr> #info lpr, user / community
08:01:30 <lbt> #info David Greaves, Sailor
08:01:39 <sledges> #info Simonas Leleiva, sailor @ Jolla
08:01:42 <stephg> #info Steph Gosling, community, porter
08:01:43 <dr4Ke> #info dr4Ke, User
08:01:49 <rainemak> #info Raine M�kel�inen, sailor @ Jolla
08:01:49 <jenix> #info Jens Mueller, User
08:01:50 <oniongarlic> #info Kaj-Michael Lang, app developer/community
08:01:52 <Ljp> #info Lorn Potter, Qt Sensors guy, ex privateer
08:01:54 <spiiroin> #info Simo Piiroinen, sailor @ jolla
08:02:04 <jpetrell> #info Joona Petrell, sailor @ Jolla
08:02:38 <bshah> #info bshah, Halium, Plasma Mobile, Community
08:03:52 <Max_Might> #info Kostadin Damyanov, app developer / community
08:04:28 <Jaymzz> So many sailors, so few community members! Come on, people :D
08:05:09 <maheart> #info maheart, community
08:05:09 <nh1402> #info nh1402, community member
08:05:10 <pketo> #info Pami Ketolainen, sailor @ Jolla
08:05:13 <urjaman> #info Urja Rannikko, community
08:05:33 <Jaymzz> First topic coming up...
08:05:41 <Jaymzz> #topic Fingerprint sensor API (15 min), asked by nh1402
08:05:55 <Jaymzz> #info I have plans to make an app that would make use of the fingerprint sensor, adding shortcuts via swipe gestures on the fingerprint sensor, but noticed that there doesn't seem to be any API for developers. Fingerprint sensor support in Alien Dalvik would also be nice.
08:06:24 <Jaymzz> nh1402: The stage is yours for 15 moinutes :)
08:06:28 <Jaymzz> minutes*
08:07:00 <nh1402> So yes, I would like to use the fingerprint sensor, not only for biometrics, but also as a mini-trackpad
08:07:40 <Ljp> I have thought about adding fingerprint sensor to QtSensors, but need more research of existing api. Sensor gestures are flexible enough I think. But research on my part is needed. That, and time
08:07:41 <nh1402> swiping left and right, up and down, depending on the location of the sensor, and if it supports it, and assigning shortcuts to these gestures
08:08:32 <nh1402> android apps are also starting to use fingerprint sensor for things, so adding support for that would also be nice.
08:09:14 <Ljp> And then sensor framework would also need to support it
08:09:37 <jpetrell> we have created fingerprint locking implementation for a product, but it is not enough to provide a stable platform API
08:09:56 <sledges> also because that product hasn't followed Android's open fp API
08:10:49 <nh1402> sledges: didn't realise that
08:11:20 <sledges> spiiroin: could any parts of the existing implementation be opened for community to take it from there (as Android API docs are open)
08:11:23 <sledges> ?
08:11:28 <Jaymzz> #info Our implementation of the fingerprint scanner is currently not enough to provide a stablt platform API
08:11:53 <sledges> i remember this topic in the past, we stopped at the necessity of "implement test_fingerprint" in libhybris
08:11:57 <sledges> to follow android api
08:12:37 <nh1402> I seemed to have misinterpreted your response.
08:12:41 <sledges> this can be done even without spiiroin's code snippets, so anyone from community please feel free to pick up on such first phase and let's do things together:)
08:12:57 <spiiroin> sledges: there is kind of internal divide between "could be public" and "closed" parts, but there is also the thing that the interfaces exposed at dbus reflect the custom api used in closed blobs
08:14:09 <spiiroin> so in a sense, the interfaces / even layering might need major changes to support android api / advanced features like gesture detection
08:14:53 <sledges> spiiroin: is guidance from Jolla (a document) needed for implementing phase 1 test_fingerprint in libhybris? or should it just map android's api for starters
08:14:54 <nh1402> sledges: I think I brought it up too, but this time I thought of using swipe gestures on the fingerprint sensors, since at least some of them seem to support gestures.
08:15:12 <sledges> nh1402: but first things first, isn't it :)
08:15:14 <Ljp> If this is commonly wanted, I can start looking into it . If Android supplies gesture recognition, all the better
08:15:37 <sledges> can't make omelette without breaking an egg:)
08:15:57 <Jaymzz> #info there might be the need of major changes in interfaces and layering in order to support Android API or advanced features like gesture control
08:16:50 <nh1402> Ljp: that's a bit iffy there. Google have added a gesture shortcut on their "Pixel" line of phones, but they didn't provide it for the Nexus line before it (6P), then I believe Motorola announced gesture support for one of their phones
08:17:01 <nh1402> so not sure if there is a public api for gestures on fingerprint sensors
08:17:19 <Ljp> Ya, it might turn out QtSensors won't be the best place, and need a separate api
08:17:19 <spiiroin> sledges: the big unknown to me atm is how to handle security/privacy requirements that the android api has and how that would affect the sw stack dealing with the fp sensor
08:17:36 <sledges> spiiroin: and the fragmentation amongst devices ^^
08:17:40 <Jaymzz> nh1402: Both Nexus 6p and 5x got those gestures in future updates (7.1.2 if I'm not mistaken)
08:18:28 <nh1402> at one point Google claimed that the 6P and 5X don't support it, and then the community made custom roms which supported it.
08:18:40 <nh1402> didn't realise they went back on their word and added it in the end.
08:19:33 <Jaymzz> nh1402: Yeah they said that especially 6p had hardware limitations, not sure how they added it but they did it. I don't have my 6p anymore but I can assure you that I had the feature on it befoe I sold it :)
08:20:14 <nh1402> a bit of research just now suggests it's a part of Android's Accessibility API
08:20:57 <Jaymzz> 5 minutes remaining. Let's begin to wrap things up :)
08:21:11 <Ljp> I need to drive home now, I will check back
08:22:08 <Jaymzz> nh1402: Anything more to add? :)
08:22:49 <nh1402> well at the moment I don't have a device that has a fingerprint sensor, but should be getting one at some point this year, and with other, more important things to work on, for me personally fingerprint sensor api support isn't needed at this time, but as long as an open api is under consideration for the future is enough for me.
08:23:03 <nh1402> not sure if others want to use it now though.
08:23:36 <leszek_> fingerprint sensor is in the xperia x isn't it?
08:23:36 <r0kk3rz> ghosalmartin was keen on FP support
08:23:38 <Jaymzz> I'm sure there will be many who would want to take advantage of it.
08:23:52 <Jaymzz> leszek_: No
08:24:08 <leszek_> Jaymzz: the us model did not have one
08:24:17 <leszek_> the european one has it
08:24:37 <nh1402> r0kk3rz: I think he just wanted the lockscreen fingerprint support
08:24:42 <Jaymzz> leszek_: Are you certain? Then I must be mistaken by that. I always thought the higher models have it.
08:25:05 <leszek_> Jaymzz: the Xperia X was the highest model two years ago
08:25:09 <nh1402> Jaymzz: I'm sure the Xperia X has it too, it's either disabled in the US or they removed it in the US
08:25:25 <leszek_> one year ago sorry.
08:25:29 <stephg> the european x compact has it certainly
08:25:56 <leszek_> Jaymzz: gsmarena lists it with fingerprint sensor: http://www.gsmarena.com/sony_xperia_x-7948.php
08:26:13 <Jaymzz> leszek_: Just checked, it has it. Thanks for correcting my mistake
08:26:51 <Jaymzz> It's just that the button does not look like a FP scanner really xD but I guess that's clever design
08:27:05 <Jaymzz> Alright nh1402 I'm moving on since the time is up :)
08:27:14 <nh1402> I'm fine with that
08:27:23 <Jaymzz> #topic QtLocation and QtWebEngine (15 min), asked by Nokius, TheBootroo
08:27:40 <Jaymzz> #info Are the Qt modules QtLocation and QtWebEngine available for developers in SailfishOS 2.1.1? This are needed cherries for application developers.
08:28:59 <Jaymzz> I would guess neither Nokius nor TheBootroo are present. But can we have an answer for them to read later?
08:29:32 <leszek_> In general I am all for a new browser engine support as QtWebkit is buggy and getting rapidly old (G+ blocks it for example, web.skype.com not working and WebRTC in general)
08:29:49 <DylanVanAssche> I'm interesting in this topic as well :)
08:29:57 <nh1402> well I was around during this discussion, TheBootroo was quite disappointed that QtWebEngine and QtLocation don't seem to be available
08:30:22 <DylanVanAssche> QTWebEngine would be nice for webbased applications like WebCat, Sailbook, ...
08:30:30 <r0kk3rz> webengine can probably be built though
08:30:36 <leszek_> Though from what I heard from KDE devs QtWebengine is a disaster in terms of API. There is basically nothing to control cookies, history or other stuff like downloads and such
08:31:20 <leszek_> so not sure if it can be very useful for webcat. I am also not sure if it brings improvements in terms of speed as without wayland optimization we have the same performance issues like we have currently with qtwebkit
08:31:55 <DylanVanAssche> For Sailbook it would be since it uses less of the API's then WebCat does
08:32:15 <DylanVanAssche> But no idea about the performace though
08:32:17 <leszek_> though it would be pretty useless with no hack for the device pixel ratio
08:32:20 <r0kk3rz> how is the embedlite component going anyway? since that is the sailfish alternative to webengine
08:32:35 <leszek_> and third party scripts aren't working too with QtWebEngine
08:33:01 <DylanVanAssche> Oh that's sad, the Sailfish alternative based on the browser would also be a solution
08:33:09 <leszek_> good question. embedlite seems to have an better api already
08:33:18 <jpetrell> we have been gradually working on migrating accounts and email side to gecko engine to avoid having to maintain two engines
08:33:34 <leszek_> yeah makes sense
08:33:48 <rainemak> r0kk3rz, Sailfish WebView (gecko based) is not read yet, work in progress
08:33:54 <maheart> Not to conflate topics, but there is also a QtWebKit "revival" effort, which involves porting QtWebKit to WebKitGTK+ (https://blogs.gnome.org/mcatanzaro/2017/02/08/an-update-on-webkit-security-updates/)
08:33:55 <rainemak> s/read/ready/
08:34:25 <Jaymzz> #link https://blogs.gnome.org/mcatanzaro/2017/02/08/an-update-on-webkit-security-updates/
08:34:26 <leszek_> maheart: yeah sounds interesting. From what I heard it is webkit1 only so far
08:34:34 <nh1402> also QtWebengine was only half of the topic, what about QtLocation
08:34:47 <Jaymzz> #info Sailfish WebView (gecko based) is not read yet, work in progress
08:34:53 <jpetrell> we cannot pre-install qtwebengine and qtlocation due to gpl3 , but should be possibly to make them available in package repos
08:34:57 <jpetrell> for 3rd party
08:35:13 <Jaymzz> #info we cannot pre-install qtwebengine and qtlocation due to gpl3 , but should be possibly to make them available in package repos for 3rd party
08:35:14 <DylanVanAssche> That would be good start :)
08:35:17 <nh1402> Jaymzz: there is a 'y' in ready ;)
08:35:49 <Jaymzz> nh1402: Sorry, copied it in a hurry
08:35:54 <rainemak> my bad...
08:36:01 <leszek_> jpetrell: yeah that would be cool. At least for alternative browser devs to poke around with. When I first started Webcat I also thought what a disaster but I somehow got it working properly for most tasks
08:36:13 <r0kk3rz> jpetrell: harbour support?
08:36:59 <oniongarlic> jpetrell: why is gpl3 an issue with these two? aren't most of qt5 gpl3 anyway or am I missing something here?
08:37:00 <jpetrell> r0kk3rz: should be possible
08:37:14 <leszek_> qt5 is lgpl
08:37:20 <r0kk3rz> oniongarlic: lgpl not full gpl
08:37:25 <jpetrell> oniongarlic: qt 5.6 isn't yet
08:37:34 <DylanVanAssche> Harbour for QTWebengine would be great since then I will try to make Sailbook harbour compatible
08:37:44 <nh1402> I was thinking of reviving the quicksilver effort that tworaz started, since Sailfish is now using Qt5.6 it should in theory be easier, but again there are bigger projects for me to work on.
08:38:08 <Jaymzz> 5 minutes remaining
08:38:10 <leszek_> nh1402: that would be awesome
08:38:16 <DylanVanAssche> That could be also a path we can take :)
08:38:52 <nh1402> I think that used the chromium sources for rendering
08:38:53 <leszek_> So if I had to choose what packages to land for jolla in the repo. I would vote for a working quicksilver
08:39:01 <leszek_> nh1402: exactly
08:39:38 <leszek_> and guessing from the short demo video I saw this one had awesome performance on the device and full html5 audio & video support without hacks and such
08:39:41 <DylanVanAssche> It would be easier to provide security updates and so on then QTWebEngine
08:40:09 <DylanVanAssche> leszek_: I tried it out a while back, indeed full support :)
08:40:11 <leszek_> that aswell as and it would provide more security features http/2 for example
08:40:15 <nh1402> leszek_: and from what I remember tworaz was saying it was pretty close to chromium sources, so updating wouldn't take that long.
08:40:54 <leszek_> nh1402: yep the sources are basically a small layer of sailfish stuff and api calling stuff and the rest was a full git copy of chromium as far as I remember
08:40:56 <Jaymzz> 2 min remaining. Please wrap up :)
08:41:23 <leszek_> nh1402: though I am not sure if it was blink based chromium or still old webkit based chromium back then
08:41:34 <leszek_> and lots of stuff changed in chromium since the demo back then
08:41:37 <nh1402> if anyone wants to revive quicksilver there are sources available on tworaz github page, and vgrade has a fork with some build instructions
08:42:01 <leszek_> can anyone build quicksilver on build service ?
08:42:17 <leszek_> or create an recipe there or something like this
08:42:42 <nh1402> back then patches to wayland were necessary for it to work since it needed Qt5.5 or newer to work
08:42:58 <leszek_> ah ok
08:43:02 <Jaymzz> nh1402: leszek_ Time is up guys
08:43:06 <nh1402> anyway, this can/should be discussed in general discussion
08:43:12 <leszek_> nh1402: link to vgrades fork ?
08:43:21 <Jaymzz> Will discuss it in general discussion then :)
08:43:28 <leszek_> :)
08:43:29 <nh1402> https://github.com/martinbrook/quicksilver
08:43:36 <leszek_> thx
08:43:44 <Jaymzz> #link https://github.com/martinbrook/quicksilver
08:43:46 <Jaymzz> Moving on
08:44:00 <Jaymzz> #topic Qt 5.9 adaptation in Sailfish OS (15 min), asked bt Nokius, TheBootroo
08:44:12 <Jaymzz> #info Qt 5.9 would bring features like better Qt3D, WebEngine, and almost stable speech. It's currently in RC and Qt 5.9 LTS Final is between end of May and mid-June.
08:44:12 <Jaymzz> What are the plans to adopt Qt 5.9 which is a LTS into SailfishOS. (https://blog.qt.io/blog/2017/05/11/introducing-long-term-support-qt-5-9/)
08:44:21 <Jaymzz> Again, same situation, others have to discuss this.
08:45:21 <rainemak> Jaymzz, original author: https://github.com/tworaz/quicksilver
08:45:42 <Jaymzz> rainema
08:45:52 <Jaymzz> rainemak: Thanks, I'll link that too
08:46:20 <Jaymzz> #link to the original author (see prev topic) https://github.com/tworaz/quicksilver
08:46:36 <Jaymzz> So anyone picking this topic up?
08:46:58 <M4rtinK_phone_> I think this can be seen as general question of Qt update policy
08:47:06 <leszek_> From what I know about Qt 5.8 and its problems with wayland support I would say wait until Qt 5.9 is out and others started building against it before deciding to switch to it directly. So wait until Qt 5.9.2 or something before making a decision. As Qt 5.6 is brand new on SailfishOS now I would stick to this LTS release a bit longer
08:47:43 <nh1402> well i was there during this discussion too, TheBootroo was saying we should be at the forefront, in order to entice developers to make apps for Sailfish, or have Qt apps from linux to work in Sailfish
08:47:49 <M4rtinK_phone_> for comparison desktop distros generally update Qt soon after new poont release
08:48:08 <leszek_> Also as a Qt switch brings in changes also for the devs (see the Qt 5.6 update) I would also rather from a developer perspective be more in favor of new 3.0 SailfishOS switching to the next big Qt version instead of a point release doing that
08:48:33 <M4rtinK_phone_> and on Android developers can pick almost any Qt version, including newest one
08:48:43 <leszek_> M4rtinK_phone_: though the ones that want to be stable stick to Qts LTS release which is currently 5.6
08:49:24 <nh1402> also the talk was not only about Jolla bringing Qt5.9 support, but for the community to help with this
08:49:49 <r0kk3rz> this is probably a bad idea, but is it possible to have an App Qt and a platform Qt? so you can roll the app runtime in with the latest
08:49:50 <jpetrell> we just updated to Qt 5.6, which is considerable effort, no short term plans to migrate to Qt 5.9
08:49:59 <r0kk3rz> but keep the stability for the os on 5.6
08:50:11 <leszek_> nh1402: I thought Qt will be build by build service. So it just needs the requirements to compile. The rest is closed source api adaptation if necessary on the silica side of things
08:50:17 <M4rtinK_phone_> well, its a LTS, so it could be like that
08:50:43 <Jaymzz> #info we just updated to Qt 5.6, which is considerable effort, no short term plans to migrate to Qt 5.9
08:50:47 <M4rtinK_phone_> r0kk3rz: +1
08:50:49 <leszek_> r0kk3rz: sounds like flatpak or snaps
08:50:52 <leszek_> or appimage
08:50:57 <r0kk3rz> something like that anyway
08:51:26 <nh1402> leszek_: not sure about that, TheBootroo was saying that it would be much faster to compile apps with Qt 5.9
08:51:27 <M4rtinK_phone_> that could be done by Flatpak runtimes
08:52:14 <leszek_> nh1402: new versions might have new better features or improvements. But remember it can break stuff badly aswell
08:52:17 <M4rtinK_phone_> sailfish 2/qt 5.6 vs sailfish 3/qt 5
08:52:25 <M4rtinK_phone_> *5.9
08:52:53 <jpetrell> that being said we should update to newer Qt releases on regular intervals, apparently "Qt 5.9 is a great improvement on Qt 5.6 (I expect around 15% on average when it is released) " http://blog.qt.io/blog/2017/04/27/performance-regression-testing-qt-quick/
08:53:06 <M4rtinK_phone_> and it should be possible to have multiple runtimes installed as well
08:53:19 <Jaymzz> #info that being said we should update to newer Qt releases on regular intervals, apparently "Qt 5.9 is a great improvement on Qt 5.6 (I expect around 15% on average when it is released) " http://blog.qt.io/blog/2017/04/27/performance-regression-testing-qt-quick/
08:53:29 <Jaymzz> #link http://blog.qt.io/blog/2017/04/27/performance-regression-testing-qt-quick/
08:53:31 <M4rtinK_phone_> and the system can use spmething completely separate
08:53:51 <leszek_> jpetrell: yep Qt 5.6 LTS runs until 2018 if I am not mistaken. So effort should be done end of this year to build Qt 5.9
08:54:12 <leszek_> starting end of this year I guess
08:55:00 <maheart> It's also worth noting that Qt 5.7+ changes licensing. "Qt 5.7 will not be available under LGPLv2.1 anymore." (http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/) "All Qt Essentials will from now on be licensed under LGPLv3, GPLv2 and commercial license terms." ... I wonder if this will affect app distribution
08:55:07 <leszek_> is there any CI system working with Build Service to constantly build new Qt 5 packages ? Would be perhaps a good thing to investigate some time in
08:56:19 <Jaymzz> 4 minutes remaining
08:56:33 <jpetrell> maheart: the new licensing should not affect apps that much, more the platform side
08:56:50 <oniongarlic> how much sfos specific customization is in the currently used qt 5.6 ?
08:57:26 <Jaymzz> #info Qt 5.7+ changes licensing, but it should not affect apps that much, it will rather affect the platform side.
08:57:39 <Jaymzz> #link http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
08:58:06 <jpetrell> oniongarlic: not much. we have an internal rule that all changes we make to Qt we also need to provide to upstream
08:58:30 <oniongarlic> ok, so the next question is how much of that is in 5.9 ?
2017-05-31 08:58:44-!- DylanVanAssche [5bb45464@gateway/web/freenode/ip.91.180.84.100] has quit [Ping timeout: 260 seconds] 
2017-05-31 09:00:52<@Jaymzz> Time is up for this topic. Is the last question going to be answered before I move on? 
2017-05-31 09:01:08-!- Netsplit *.net <-> *.split quits: abranson, Coolgeek, phlixi, stereo[m]1, cybette, cristi 
2017-05-31 09:01:08<@Jaymzz> jpetrell: ^ 
2017-05-31 09:01:23< jpetrell> I guess not, not sure I understand the question 
2017-05-31 09:01:45<@Jaymzz> Okay oniongarlic let's bring this back up during general discussion. I'm moving on 
2017-05-31 09:01:57<@Jaymzz> #topic implement fix for A-28759139 / BID 73286 in kernel-net-sockets (10 min) asked by lpr 
2017-05-31 09:02:25<@Jaymzz> #info https://together.jolla.com/question/161453/validate-the-range-we-feed-to-iov_iter_init-in-sys_sendtosys_recvfrom-in-kernel-net-cve-2015-2686-critical/ : fix for cve-2015-2686 (kernel 3.19 only) will fix A-28759139/BID 73286 on kernel before 3.19 (e.g. 3.4-jolla1, 3.10-jollac)
2017-05-31 09:02:52<@Jaymzz> Looks like meetbot didn't change the topic. We move on anyway :) 10 minutes for this as requested 
2017-05-31 09:02:53< lpr> seems to be de-rejected and in progress now 
2017-05-31 09:03:16-!- merbot [~supybot@phost1.merproject.org] has quit [Ping timeout: 260 seconds] 
2017-05-31 09:03:22< lpr> on tjc 
2017-05-31 09:03:43-!- lbt [~lbt@Maemo/community/contributor/lbt] has quit [Ping timeout: 246 seconds] 
2017-05-31 09:03:48 * coderus offtop 
2017-05-31 09:04:04< coderus> lpr: because you annoying :D 
2017-05-31 09:04:08 * coderus off 
2017-05-31 09:04:18<@Jaymzz> I personally do not understand this topic at all. So I'll leave it to the experts and will lurk for the next 10 minutes :D 
2017-05-31 09:04:48-!- lbt [~lbt@Maemo/community/contributor/lbt] has joined #mer-meeting 
2017-05-31 09:05:47< lpr> A-28759139 / BID 73286 is a Elevation of privilege vulnerability in kernel networking component 
2017-05-31 09:06:45<@Jaymzz> Anyone wana discuss this? xD it's been 5 minutes and lpr requested 10! 
2017-05-31 09:07:09-!- phlixi_o [~phlixi_o@pD9E99AC6.dip0.t-ipconnect.de] has joined #mer-meeting 
2017-05-31 09:07:27< M4rtinK_phone_> seems like something that should be fixed 
2017-05-31 09:07:31< urjaman> OT: merbot ping timeouted... (as in, note that the logs might not be that good...) 
2017-05-31 09:07:32< lpr> who changes "tracked by jolla (xxx)" in tjc? 
2017-05-31 09:07:33< leszek_> lpr: did you check that this affects the current kernels on current sailfishos devices ? From the tjc thread thats not clear to me 
2017-05-31 09:08:00-!- cristi [~majeru@131.228.216.132] has joined #mer-meeting 
2017-05-31 09:08:10< M4rtinK_phone_> no Sailfish OS kernel maintainers around ? ;-) 
2017-05-31 09:08:24< lpr> yes, android-3.10 kernel has same sockets.c as we have 
2017-05-31 09:08:38< lpr> but fixed 
2017-05-31 09:09:00-!- stereo[m]1 [stereognub@gateway/shell/matrix.org/x-jsoifjnpcqydlkuq] has joined #mer-meeting 
2017-05-31 09:09:04< jenix> well, i guess if jolla is tracking this we have to wait what they come up with 
2017-05-31 09:09:08< lpr> android-3.4 not fixed because it is unmaintained now 
2017-05-31 09:09:14< leszek_> lpr: still not clear to me then. Is it fixed in SailfishOS or not. If Android 3.10 kernel is what SailfishOS uses on current devices I don't see a problem 
2017-05-31 09:09:14-!- tg_ [6d00abb2@gateway/web/freenode/ip.109.0.171.178] has quit [Ping timeout: 260 seconds] 
2017-05-31 09:09:15< coderus> this bug affect only 3.19.0 3.19.1 and 3.19.2 kernels, it not affect Jolla kernels at all 
2017-05-31 09:09:35< nh1402> but Sailfish is on more than just Jolla devices 
2017-05-31 09:09:37< coderus> lpr doesnt understand this and dont want to understand 
2017-05-31 09:09:45< lpr> no, jolla1 has 3.4 
2017-05-31 09:09:54< coderus> nh1402: adapataions kernels are different tree and cant be fixed by sailors 
2017-05-31 09:10:12< leszek_> nh1402: yeah but they can use whatever kernel is provided by lineage or cm 
2017-05-31 09:10:14< coderus> nh1402: adaptations should be fixed by its devs 
2017-05-31 09:10:30< coderus> jolla can only fix official devices kernels 
2017-05-31 09:10:36<@Jaymzz> I guess I can give this 5 more minutes. Merbot is dead for now. Logs won't be proper anyway... 
2017-05-31 09:10:37< leszek_> yep 
2017-05-31 09:10:45< lpr> jolla1 is offical device 
2017-05-31 09:10:55< coderus> Jaymzz: just in time :D 
2017-05-31 09:10:58< nh1402> coderus: fair enough 
2017-05-31 09:10:59< lpr> and jollac too 
2017-05-31 09:11:01< leszek_> lpr: have you checked the sources as coderus states these kernels aren't affected 
2017-05-31 09:11:08< coderus> lpr: 3.4 kernel IS NOT AFFECTED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 
2017-05-31 09:11:18< lpr> lezek: yes 
2017-05-31 09:11:24< coderus> ONLY 3.19.0 3.19.1 and 3.19.2 ARE AFFECTED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111111111111 
2017-05-31 09:11:40<@Jaymzz> coderus: CHILL!!!!111one 
2017-05-31 09:11:49< coderus> THERE ARE NO JOLLA DEVICES RUNNING THESE KERNELS!!!!!!!!!!!!!!111111111111 
2017-05-31 09:11:52-!- Kaffeine [~Kaffeine@host-207-138.dialup.telecet.ru] has joined #mer-meeting 
2017-05-31 09:11:57<@Jaymzz> Why so angry? :D 
2017-05-31 09:12:02< coderus> Jaymzz: coz he dont want to understand, i have no idea how to explain 
2017-05-31 09:12:03< lpr> 3.4 and 3.10 
2017-05-31 09:12:28< lpr>  http://www.securityfocus.com/bid/73286 
2017-05-31 09:12:32<@Jaymzz> coderus: But keep it cool man! Caps locking won't solve anything :D 
2017-05-31 09:12:52< coderus> Jaymzz: i have no caps, its all shift down 
2017-05-31 09:13:18<@Jaymzz> Ah, same thing almost :D 
2017-05-31 09:13:23< coderus> see, lpr just dont want to understand, so lets move forward, it wont change 
2017-05-31 09:13:31< lpr> google didn't change affected kernels in original cve-2015-2686 
2017-05-31 09:13:45< coderus> lpr: google-shmoogle 
2017-05-31 09:13:45-!- merbot [~supybot@phost1.merproject.org] has joined #mer-meeting 
09:13:46 <pketo> I'm not expert, but What I understand, the bug does not directly affect the kernels in use, but we have now applied the patch and it should be in next update
09:14:04 <coderus> jolla kernel experts analyzed problem and told you its not affect jolla devices, so please
09:14:22 <lpr> 2 bugs -> one fix
09:14:28 <leszek_> yeah thats hard to tell without looking for myself. This are facts. So there can be either it is affected or not. But not both
09:14:40 <coderus> this patch will be applied to kernel just because you so annoying, not because there is any problem in kernel
09:14:45 <leszek_> *these
09:14:45 <Jaymzz> lpr you've got 1 minute (on your extra 5 minutes) since everyone is saying that Jolla devices are not affected, I guess we shall move on?
09:15:05 <lpr> cve-2015-2686 fix is for all kernels lower 3.19.3
09:15:08 <Jaymzz> And sorry to sound ignorant, I understand nothing when it comes to kernels...
09:15:09 <r0kk3rz> leszek_: its a quantum vulnerability, uncertainty principle applies :)
09:15:28 <leszek_> lpr: perhaps provide an exploit for existing devices then all will listen
09:15:52 <r0kk3rz> pketo says it was patched, what more do you want?
09:16:09 <lpr> then all is ok
09:16:10 <pketo> mkosola: ^ do you want to comment more on this?
09:16:11 <leszek_> if its patched then everything should be ok
09:16:39 <Jaymzz> I'll wait a moment if mkosola wants to comment, then will move on.
09:17:58 <lpr> any kernel-sailor?
09:18:31 <Jaymzz> Alright we are way over time. I declare this topic as answered for now. You can bring it up later if there was time. Moving on
09:18:35 <Jaymzz> #topic OTA via settings UI for ported devices (10 min) asked by nh1402
09:18:45 <Jaymzz> #info It would be nice to be able to update phones via a GUI in the settings. At the moment it's only possible via command-line arguments, which already should be the same across devices (I think).
09:18:49 <coderus> god thanks
09:19:07 <pavi[m]> @freenode_leszek_:matrix.org:  How about WebRTC support in the browser?
09:19:28 <r0kk3rz> pavi[m]: wait for general discussion please
09:20:16 <nh1402> It would be nice for ported devices to update the same place in settings as official devices, although updating slightly differently than the official ones.
09:21:32 <nh1402> rather than updating via command line arguments
09:21:36 <leszek_> nh1402: isn't that a simple configuration option for the ported devices ? So basically "downstream" has to configure that
09:21:57 <sledges> nh1402: ported devices usually are ready for it some time after update is publish
09:22:01 <sledges> *published
09:22:16 <pketo> At the moment we do not have resources to maintain community port update information on our store backend, which is used for checking the system updates
09:22:21 <sledges> so it can't use the same integral part of settings UI and logic
09:22:48 <mal> nh1402: there are two options one is easy and second is difficult, first one is making a separate update app for ported devices (I have a mostly working version already) or second option (requires help from jolla) is to somehow make store backend configurable
09:23:03 <Jaymzz> #info At the moment we do not have resources to maintain community port update information on our store backend, which is used for checking the system updates
09:23:37 <jenix> Even though I totally agre with you that this would be a great feature, I'd also say that this would be the responsibility of the maintainer for the port. Maybe Jolla can provide some knowledge how to adapt the update machanism or make it easier to change it ?
09:24:26 <mal> the update itself is easy but getting the system to know there is an update available is difficult
09:24:27 <pvuorela> should separate the os upgrade more away from jolla store, but let's see how that proceeds.
09:24:40 <Renault> or maybe have a server to put these updates from certified community developpers, without warranty come frome Jolla of course
09:25:18 <nh1402> mal: I suppose the two options for the system to know that there is an update, is to poll a server for the version, or a push notification
09:26:36 <leszek_> mal: if the first one is ready can't it just replace the default on in settings ? Not sure how this menu is generated. But replacing it should be possible for porters I guess
09:27:09 <nh1402> leszek_: that sounds like hacking qml of settings
09:27:49 <mal> afaik replacing parts of settings is not supported in any simple way, only by using hacks
09:27:58 <leszek_> uff thats not what I wanted. I hope the settings are generated not statically but dynamically. So replacing some .desktop file should be enough. But I did not take a look on how the menu is generated yet
09:28:12 <leszek_> mal: I see. Too bad
09:29:41 <Renault> leszek_: should be a security issue, if you change by one file the link to check updates availibility
09:30:01 <Jaymzz> Time is almost up for this guys, nh1402 shall we wrap up?
09:30:10 <leszek_> Renault: agree. But there are so many security issues when you start thinking this way already :P
09:30:37 <jenix> Renault: since you should authenticate the update seperately (otherweise, you could just redirect the update check as MITM) I beg to differ
09:31:00 <M4rtinK_phone_> well ports can change about anything anyway
09:31:20 <M4rtinK_phone_> so you already have to trust them
09:32:13 <Jaymzz> Alright
09:32:15 <M4rtinK_phone_> (and of course make sure the port is not MitMed)
09:32:27 <Jaymzz> Looks like we're done here with this topic. already over time
09:32:31 <Jaymzz> Moving on
09:32:34 <Jaymzz> #topic General discussion (15 min)
09:32:43 <Renault> jenix: but how to check the update signature if Jolla doesn't have these updates ?
09:32:43 <Jaymzz> Oh, merbot is back!
09:32:51 <jenix> Any news about Sailfish and Sonys Open DEvice Program?
09:33:06 <mal> pvuorela: sledges it would be nice to have maybe some private discussion about options related to updates for ported devices
09:33:09 <nh1402> leszek_: if you wanted to discuss quicksilver again, now's your chance
09:33:17 <leszek_> pavi[m]: regarding your question. As webat uses QtWebkit and it has no support for it I can't perform magic
09:33:26 <jenix> Renault: as port maintainer, you could simply use your own Signature keys and implement them into the port
09:33:41 <sledges> mal: including pketo
09:33:53 <mal> sledges: yes
09:34:11 <pketo> sure
09:34:17 <leszek_> nh1402: yeah It would be really awesome if someone with build service access could take a look at creating a recipe to build quicksilver
09:34:23 <Jaymzz> jenix: We are progressing with the Sony program. It is happening! We will have an announcement for you soon enough.
09:34:58 <sledges> leszek_: "recipe" already exists: https://github.com/tworaz/quicksilver/blob/master/rpm/quicksilver.spec
09:35:00 <leszek_> even quicksilver with chromium 44 or 45 base would be a good start as it would outperform qtwebkit already in many ways
09:35:09 <M4rtinK_phone_> Jaymzz: cool! :-)
09:35:11 <ApBBB> Jaymzz: tell vesku to get us a compact X in the store :P
09:35:12 <jenix> Jaymzz: Thanks, can oyu give us any estimation on when we will be able to run / test SFOS on sony devices?
09:36:03 <leszek_> sledges: great. Now it just needs someone to add it to build service so we can have a test rpm to tinker with
09:36:04 <M4rtinK_phone_> also any comments on the X series being discontinued by Sony in the future ?
09:36:07 <Jaymzz> ApBBB: Will do :D nothing is announced other than Xperia X yet but it isn't impossible to bring other phones in soon after we are done with X. We will see how it goes
09:36:08 <pketo> mal: but as pvuorela said, we would need to separate the system update check from store client. after that it would be easier for community to have their own solutions
09:36:23 <mal> pketo: true
09:36:49 <ApBBB> Jaymzz: i can't stand large phones.
09:37:17 <pketo> I think there has been some plans to do that, but I don't know what's the status on that
09:37:20 <Jaymzz> jenix: At this moment it is still unknown when exactly it will be available for testing. However, I know that it will be within this summer ;) (Not too distance future)
09:37:44 <Jaymzz> ApBBB: X isn't that big really! But I understand the frustration when you're forced to use 2 hands!
09:37:54 <jenix> Jaymzz: So you're currently working on SFOS für the X!? How does the fact that Sony accounced the end for their mid-range devices (including the X) affect your work?
09:38:17 <Tofe> FYI about Qt 5.9, I'll soon begin working on upgrading LuneOS to a newer Qt version (we're at 5.6 too today); so as we use a very similar stack as SFOS, you'll have a good status on what kind of mess it'll be :)
09:38:22 <r0kk3rz> two hands is better tha one anyway :P
09:38:31 <leszek_> jenix: no successor does not mean Xperia X devices will die out today
09:38:39 <r0kk3rz> Tofe: good luck!
09:38:53 <M4rtinK_phone_> Tofe: thanks in advance! :-)
09:39:00 <nh1402> leszek_: it won't work on the latest version, the patches to wayland and things would break things
09:39:08 <jenix> leszek_:  thats true, but on the other hand it may mean that it may get harder to be bale to purchase one
09:39:10 <nh1402> latest version of Sailfish that is
09:39:11 <Jaymzz> jenix: Yes the work is currently progressing on the X. It won't affect us yet since there still are a lot of devices out there. Although it may motivate us to move up to higher end devices sooner than expected. It isn't confirmed yet though.
09:40:03 <leszek_> nh1402: ah too bad. So it can't be build simply because of wayland and newer qt 5.6 then ?
09:41:18 <nh1402> leszek_: if you check the link I sent, the build instructions mentions patches
09:41:53 <nh1402> but this was for an old version of Sailfish, which should now match the requirements needed for newer versions of chromium
09:42:00 <jenix> Jaymzz: Thanks for the update. I have the impression there are many people on TJC which are eager to get some news about this topic (me included) :)
09:42:30 <tbr> Tofe: in my experience 5.8 wasn't a very big deal to get to work. I built it for my own Mer tests. Just qtwayland failed and I wasn't bothered to fix it as I was using a different qpa.
09:42:45 <Jaymzz> jenix: We are doing our best to bring a proper update/announcement to this project by the end of June.
09:42:54 <bshah> re qt
09:43:10 <bshah> if you are not using qtwayland its all "working" completely fine
09:43:16 <leszek_> nh1402: I see. Because patching Qt will not be an option for browser devs
09:43:35 <tbr> Tofe: feel free to poke me if you run into something weird. I've probably solved it for my 5.8 builds already.
09:43:43 <Jaymzz> 5 minutes left on this guys, keep it short
09:43:47 <nh1402> leszek_: https://bpaste.net/show/eb3059e7c0df
09:44:34 <leszek_> nh1402: yeah and thats old news. I guess with Qt 5.6 patching is then not necessary anymore.
09:44:58 <leszek_> thats why I asked someone to setup a build service build process so one can test if it builds against SFOS 2.1
09:45:54 <leszek_> gcc-4.8 is there , qt 5.6 is there. So basically only chromium patching is needed
09:46:56 <nh1402> in theory
09:47:13 <Jaymzz> Alright time is up. We shall move on. OK with you nh1402 and leszek_?
09:47:21 <leszek_> yep
09:47:37 <Jaymzz> #topic Next meeting’s time and date (5 min)
09:47:48 <Jaymzz> Proposal: Wednesday, 14th of June 2017 at 08:00 UTC. Any votes against?
09:48:35 <Jaymzz> Everyone seems okay with it
09:49:03 <Jaymzz> #info Next meeting will be held on Wednesday, 14th of June 2017 at 08:00 UTC, see you then
09:49:15 <Jaymzz> Thanks everyone for this rather productive meeting
09:49:20 <Jaymzz> Have a great day
09:49:23 <Jaymzz> #endmeeting