08:00:21 #startmeeting Sailfish OS, open source, collaboration – April 19th 2017 08:00:21 Meeting started Wed Apr 19 08:00:21 2017 UTC. The chair is Jaymzz_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 08:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:00:30 #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2017-April/007852.html 08:00:38 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:51 #topic Brief introduction (5 min). Please prefix your name/handle with # info 08:01:04 #info Aleksi Suomalainen, SailfishOS community, porter, Nemo enthusiast/master 08:01:06 #info James Noori, Community Manager and Chairperson for this meeting 08:01:22 #info Lewis Rockliffe,community member 08:01:27 #info Chris Adams, developer at Jolla 08:01:35 #info Bhushan Shah, KDE developer and Plasma Mobile maintainer 08:01:37 #info Carsten Munk, crazy person 08:01:43 #info Marko Saukko, Sailor @ Jolla 08:01:47 #info Martin Kolman, community member and modRana developer 08:01:50 Stskeeps: lol :D 08:01:52 #info Jonatan Walck, Community member and home-developer 08:01:52 #info eekkelund, Maemo Community Council, community dev 08:01:55 #info pavi, community 08:02:00 #info PureTryOut, community 08:02:02 #info Kostadin Damyanov, community 08:02:10 #info Vesa-Matti Hartikainen, Program Manager at Jolla 08:02:13 #info Andrew Branson, sailor at Jolla 08:02:23 #info Adam Pigg, Sailfish OS Community Porter, KDE Developer 08:02:28 #info Christophe Chapuis, community, also LuneOS developer 08:02:30 #info Simonas Leleiva, l10n'n'hw at Jolla 08:02:30 #info Pami Ketolainen, backend developer @ Jolla 08:02:45 #info m2ko, community 08:02:48 #info Kaj-Michael Lang, community 08:02:52 #info pasko user 08:02:54 #info Thomas Ruecker, a mer community member 08:03:38 #info Wouter van Heijst, infra at Jolla 08:03:45 #info Hongwei Ge, sailor@Jolla 08:03:53 #info Steph Gosling, community, porter 08:04:18 #info Rodolphe Sequeira, community 08:04:38 #info Martin Ebnoether, Community Member 08:05:13 Wow, we are so many today! Welcome everyone :) 08:05:35 #info juiceme, general hacker 08:06:25 #info Fabio Isgrò, Community Member 08:06:40 #topic Sailfish Browser /servo (revisit) asked by nh1402 (20 min) 08:06:41 #info Federico_III, software designer, python samurai, C 08:06:52 #info tadzik, community, app developer 08:07:06 #info Servo components are slowly being added to Firefox, WebRender, Quantum etc. on target to be added some point this year. I think we should jump straight to these components once they are stable enough, and bypass these old versions of embedlite/firefox. 08:07:14 #info Raine M�kel�inen, developer @ Jolla 08:07:33 #info Julius Enriquez, Community member, Android and Linux power user, technology enthusiast, curious person 08:07:33 Is nh1402 here today? Didn't see him in the intro section 08:08:53 OK seems like he's not here this time either, in which case I'm probably going to pass on this topic and postpone it to either later in the meeting when he arrives or next meeting 08:08:58 !seen nh1402 08:08:58 hge: nh1402 was last seen in #mer-meeting 1 week, 6 days, 21 hours, 56 minutes, and 51 seconds ago: fine by me 08:09:12 any comment rainemak? for the logs 08:09:53 Nope, only thing that I can think of is setting up Servo project to 08:09:57 rkz: We did discuss this last week for about 20 minutes or so, there are logs available on it already. 08:10:01 I guess this is mainly about shipping something in Rust by default, right ? 08:10:01 for Sailfish 08:10:10 Jaymzz_: i was getting a sense of dejavu :D 08:10:26 Are we setup to do that ? 08:10:35 yes, and as nh1402 is not present I'd continue to next topic 08:10:41 rkz: Yepp :D This was a revisit since nh1402 wasn't available last time either and said that he will be available this time 08:10:51 rainemak: Yes, will do 08:10:58 Moving on 08:11:03 cheers 08:11:12 #topic Possibility to enable 802.11r support in wpa_supplicant, asked by pasko (10 min) 08:11:15 #info Nokius community sailfishos-porter 08:11:25 #info Support for 802.11r is disabled at compilation time in package wpa_supplicant. As explained in https://together.jolla.com/question/154955/80211r-roaming-implemented/ it is relatively easy to enable this feature. I've been using it for the last weeks and didn't notice any abnormal behaviour. 08:11:32 #link https://together.jolla.com/question/154955/80211r-roaming-implemented/ 08:12:22 hi. Just wanna say I think it would.be easy.to enable this.feature 08:13:01 Do you think it would be possible? 08:13:04 Sage-: ^ What do you think? 08:13:05 pasko_: I can't think currently any reason why it could not be enabled other than testing and making sure nothing breaks if it is enabled. 08:13:53 pasko_: so maybe do PR to https://git.merproject.org/mer-core/wpa_supplicant/blob/master/rpm/build-config that enables that and lets see what comes on reviews 08:13:56 I,ve ben using it for weeks in Jolla1 and JollaC 08:14:06 #link https://git.merproject.org/mer-core/wpa_supplicant/blob/master/rpm/build-config 08:14:59 Problem is I,m not familiar with PR. :P 08:15:00 #info sage thinks that there is no reason why it could not be enabled other than testing and making sure nothing breaks if it is enabled. 08:15:16 But will try it anyway. :) 08:16:05 pasko_: you can ask for help in #mer 08:16:09 #action pasko_ to PR merproject (https://git.merproject.org/mer-core/wpa_supplicant/blob/master/rpm/build-config ) and see what comes on reviews 08:16:21 pasko_: https://www.youtube.com/watch?v=xtcEQNOKbg8 maybe helps :) 08:17:16 Ok. Will check it later. Thank you. 08:17:29 #link to help with the process in case someone else is going to use it: https://www.youtube.com/watch?v=xtcEQNOKbg8 08:17:50 pasko_: Shall we move on then? :) 08:18:04 Sure! 08:18:10 Alright thank you! 08:18:22 #topic Project Halium, collaboration on common android base, by bshah, toxip, mariogrip (15 min) 08:18:35 #info Description: Currently Ubuntu Touch, SailfishOS/Mer, Plasma Mobile and others have different android source trees and methods on how our stacks are built even though much of the underlying technologies are the same. There is a lot of unneeded fragmentation. Project Halium aims solve this by the having common android base and perhaps common middleware between different projects so that we could collaborate and distribute each 08:18:35 of our resources more efficiently. More details about this project was sent to sailfishos devel list: http://lists.sailfishos.org/pipermail/devel/2017-April/007842.html 08:18:43 #link http://lists.sailfishos.org/pipermail/devel/2017-April/007842.html 08:19:23 Hello everyone, so, sadly currently toxip and mariogrip are not available here (timezones heh) 08:19:29 But I will explain this 08:19:45 I thought about this and the clearest solution would be if all could just use mer as their base. 08:20:08 let him explain first juiceme :P 08:20:13 sure :) 08:20:27 So, currently for android devices we 3 sub communities are using seperate base for android and different methods of starting android 08:20:44 say, droid-hal-init v/s lxc container etc.. 08:21:12 each method have their own pro/cons, I am not saying that any base is 100% perfect 08:21:46 but project halium aims to collaborate on common android base (not userspace) so we could each benifit from porting efforts 08:22:18 we have draft document prepared explaining it and I had sent it to sailfishos devel list earlier 08:23:06 so yeah, any thoughts? 08:23:11 this will also cover areas that currently Mer does not, its adaptations are typically based upon the now defunked cyanogenmod project 08:23:52 https://xkcd.com/927/ ? this remind me of this 08:23:59 instead, if we had a cut down android build expressly for libhybris it would make the end port a bit thinner (as all the cm parts are still there) 08:24:00 rkz: well, community adaptation are based but generally it is not hardcoded there. It is just the most commonly used base and easiest to start with but you can use also AOSP or codeaurora as a base 08:24:05 I agree with juiceme - seems like a good opportunity to expand Mer 08:24:20 than to start something completely new 08:24:29 Coolgeek: thing is there is no standard at all about mer 08:24:32 "Why not Mer"? well, different people want to do different things and Mer doesnt help them get there 08:24:39 err.. s/mer/android base/ 08:24:43 +1 juiceme M4rtinK_phone_ 08:24:49 I quickly check the document and did couple of comments but didn't have time to go through the whole thing in details also there are lost of new comments also there. 08:24:51 Stskeeps: ^ What are your thoughts on this approach? 08:24:51 if you want to use debs, mer doesnt help. if you want bleeding edge Qt mer doesnt help either 08:25:24 veskuh: i don't have any thoughts right now, sorry - i think it only makes sense to focus on how the android part is encapsulated 08:25:37 rkz, please explain "different things" not possible with mer? 08:25:49 in my humble opinion it should be all fairly abstractable 08:25:51 We need to remember here one important thing, what works with the ODM's? It does not really matter what we think is the best if it doesn't work with the ODM's. 08:25:57 and possible to share certain parts 08:26:25 tbr: exactly, the parts we are all shackled to are the android bits 08:26:25 Sage-: exactly 08:27:11 juiceme: if someone wants to say use ubuntu rootfs, its not impossible but hard with mer, unless you fork and adapt 08:27:13 juiceme: see above, for instance the plasma mobile guys need qt 5.7, mer doesnt give you that 08:27:24 start with Android base, don't choose AOSP as mainly google devices work only, don't choose CAF as only 1-2 device will work per selected CAF tag; use LineageOS (new hadk will have links updated) 08:27:31 rkz: in theory, obs supports deb builds from .spec. Not sure how painful 08:27:37 but all in all, it is a good thing to study; to this I agree. 08:27:43 * pavi[m] wishes that in future all the platforms share same Qt version and enable porting apps. 08:27:45 juiceme: typically, for LuneOS, changing the whole infrastructure isn't worth it. And we're using a patched Qt, too. and the list goes on... 08:27:49 also things like merging to same codebase things like kernel or drivers or using same caf tag is basically going back to MeeGo times and the issues that were already existing there that we have been working quite hard to get working with Sailfish OS and our ODM partners. 08:27:51 at #sailfishos-porters there are many cases of trying out new android base - so one will try out a halium android base similarly 08:27:54 pavi[m]: keep dreaming :) 08:28:53 Other parts to share, particularly for smaller projects like plasma and Lune OS, to reuse adaptations that our guys make for sailfish easily 08:29:21 i see no reason why qt5.7 and plasma mobile UI coulndt be built on mer? 08:29:25 aren't the Android bits way down below Qt and packaging ? 08:29:56 that seems something that should be possible to share and co-maintain 08:29:58 piggz: sure it can be built, but it comes down to choice and skills of developers as well 08:30:06 sledges: Lineage can still use CAF though right, so which way would best CAF based or no CAF? 08:30:19 way below, old architecture picture of sailfish os https://sailfishos.org/wp-content/uploads/2016/02/Sailfish_Architecture.jpg 08:30:24 bshah: It would be great to have plasma mobile running on Mer. 08:30:27 M4rtinK_phone_: yeah, theres a couple of things that punch heigher like ofono, systemd, media stuff 08:30:44 #link https://sailfishos.org/wp-content/uploads/2016/02/Sailfish_Architecture.jpg 08:30:49 bshah: i have already built 20 or so KF5 frameworks on the mer OBS btw to support Kexi development 08:31:15 nh1402: just use CM's approach (that LineageOS is reusing) - local_manifest, and it won't matter if certaing things are caf or not - it will be decided by device 08:31:27 piggz: sure, kf5 itself is not issue, issue is kwin_wayland 08:32:26 as aI understand it Halium is about unifying the bits that are close to the hardware, the rest is up to the distros to decide, so it has nothing to do with Qt, pulseaudio and the rest of the userland for that matter, is that correct? 08:32:38 Max-Might: exactly 08:32:39 I think we are mixing here now multiple things. One is the adaptation then other things is higher level stuff like Qt and UI. Also someone mentioned the plasma guys not able to use what is in mer because e.g. qt5.6, is there list of things that are the main pain points in general? 08:32:56 Just for the record: I'm giving more time to this topic because the previous ones were shortened and also this topic seems to be hot. 08:33:08 Jaymzz_: yey. :p 08:33:43 Sage-: ignore the higher level stuff, its just a retort to the common question of "why not mer" this is about android stuff and adaptations 08:33:46 there already has been successful collaboration within HW adaptation projects: pulseaudio-modules-droid, qpa plugin, ... 08:34:26 Which will the relation between libhybris and halium? 08:34:34 #info Topias Vainio, Sailfish OS Fan Club founder (sorry I overslept) 08:34:55 halium's scope is the android base *used by* libhybris 08:35:14 sledges: with the say SFOS handles init, if you could do it all over would you attempt some of the other methods like using containers or chroots? 08:35:23 s/say/way 08:35:26 as one that hasn't tinkered with the low level android bits this was a bit confusing so yes, focusing on just the topic at hand will help me grasp this:) 08:35:50 JFTR I have Qt 5.8 building fine on Mer 08:36:12 I could use some help with it, but that's off-topic. 08:36:57 rkz: it's very involved process, and if i knew how containers work (or someone could explain) pros+cons it's always good to consider new ways 08:37:26 sledges: nice to hear 08:37:32 some containers at least require kernel level changes I think. 08:37:53 we haven't documented pros/cons in much more details in document, but I guess we can improve it 08:38:04 sledges: this is one of the key learning areas imo. everyone does things slightly differently so which way is the least worst? 08:38:05 which in some cases are only available on certain kernel versions 08:38:05 I remember a friend running the systemd/cgroups container stuff on a stock jolla phone years ago 08:38:28 by containerizing the init are you suggesting that any adaptation running in it would run on top of an existing android layer? 08:38:29 indeed, IIRC some of the kernel level APIs are just not there in the outdated Android kernels 08:38:47 we're back to the ODM support question, then 08:38:55 bshah: can't spread ourselves too thin: i suggest to babystep and firsly to see if a common android base can be achieved - then see the first port of sfos,p:a,ubiports,luneos on it using their own porting ways 08:38:57 well, also systemd imposes a minimum version on the kernel 08:39:18 tbr: the kernel needs adjustemts for the systemd container 08:39:22 sledges: great, yes, we ourself need to babystep first 08:39:31 if that succeeds, then future is brighter:) 08:39:52 and that success would also mean - less fragmentation of hybris patches on android base 08:39:55 already 08:40:03 agreed 08:40:05 I think we should focus on spelling out the common/shared things and look at those 08:40:20 tbr: +1 08:40:28 and you'll also meet the challenges on the way - one android base even LineageOS won't be able to rule all (most devices) 08:40:28 and then see how far up the stack we can go before things start to diverge 08:40:37 Would it be possible to patch the kernel for systemd during installation? 08:41:06 tbr: well said. 08:41:14 from sfos porters experience i remember many porters coming with quite mainstream devices, but those not having cm ports, and yet being ported, by choosing other bases.. 08:41:21 from a birds perspective, if any two projects start sharing the android base we go from x different bases to x-1, which is progress. if this is general enough another os/project can use it and we have x-2! if we actually all want the same base in the end there will be only 1. 08:41:32 and having the possibility to modify kernel defconfig is pretty much required 08:41:58 I dont know the details so can't speak for one approach or the other, but this way we don't start with x+1 and hope that'll reach 1 over time 08:42:31 jwalck: jep.. totally agree 08:42:38 jwalck: sure, but before that happens we're engaging different libhybris projects to make sure this is something they could be interested in 08:42:42 jwalck: the containers could help with that, so that different versions of android bases could be separate entities which provide libhybris with compatible apis 08:42:59 tbr: this is all open source stuff, the kernel will probably still be built by the distro; but that's the sort of things halium would need to solve 08:43:10 Tofe: yes 08:43:19 rkz: *nodnod* think I grasp the concepts here even tho this isn't parts I've worked with 08:43:27 surely, it's not limited to community's skunkworks and curiosity to e.g. slap sfos on container, and show everyone how to do it :) in the meantime 08:43:33 I can see halium as a common toolset to produce the output that then gets ingested and formed into packages 08:43:49 but that i suggest to be a less steered effort for the moment, and priorities considered 08:43:55 some devices still need custom android bases like the custom aosp for fp2 08:43:59 I personally don't see a reason to discuss containers at this point, yet 08:44:08 locusf_: check, that's another place in the stack to converge through! 08:44:16 go up the stack, find common grounds 08:44:44 sure 08:44:58 Tofe: tbr: kernel is per device not per distro on these devices unfortunately. Thus also mer core doesn't have kernel. :) 08:45:31 at this point our stage 0 development plan is to basically have a rootfs which is able to run libhybris tests 08:45:45 bshah: 25 minutes gone, maybe time to wrap up slowly :) 08:45:47 Sage-: I know, but Mer core isn't the distro, it's the infrastructure of the distro 08:45:57 Jaymzz_: *nod* 08:46:18 so yes, before we wrap up, any final comments? 08:46:23 what are the concrete actions? and who are those actions for? I'm a bit lost in this discussion. 08:46:24 Tofe: mainly saying that you are asking for a trouble if you aim to have one kernel for your distro :) 08:46:28 lots of stuff to #info 08:47:32 So Jolla is potentially interested but not able to invest effort in this at this time? 08:47:44 isn't dtree solved one kernel / device ? 08:48:22 chriadam: plan is, we start with android source tree with libhybris patches, -> bring CI system up to build images -> and adapt rootfs for libhybris tests (that is pretty much stage 0) 08:49:11 after that this android base can be used to start plasma mobile, utouch, sfos and see how it goes 08:49:15 chriadam: first thing on Halium side at least is to build a proof-of-concept and get ubports, plasma mobile and sailfish os running on top of that 08:49:40 agreed 08:50:15 (we should add #info points and move on to next topic perhaps) 08:50:16 bshah, toxip: check. now the fog is lifting! sounds like the right place to start.:) 08:50:30 #action myself to finally release the long-overdue HADK v2 to bring 64bit ports to-date (apologies, been carried away with xperia stuff), in turn to make sfos porting even more easier <- do own housekeeping first :) 08:51:06 +1 08:51:13 gogo sledges :) 08:51:13 sledges, i like the idea to "slap" sfos into into a container 08:51:37 dr_gogeta86: i'm very interested in pros+cons, from someone who already did that (ubports?) 08:51:37 the problem are the ancient kernels out there 08:51:45 #info Just a summary of what went on in the beginning, sage- said: We need to remember here one important thing, what works with the ODM's? It does not really matter what we think is the best if it doesn't work with the ODM's. Also things like merging to same codebase things like kernel or drivers or using same caf tag is basically going back to MeeGo times and the issues that were already existing there that we have been working 08:51:45 quite hard to get working with Sailfish OS and our ODM partners. 08:52:03 sledges: we (at LuneOS) did that too 08:52:11 dr_gogeta86: Me also. SFOS in a container is tempting. ;) 08:52:22 isn't tempting ... is the way to go 08:52:36 sledges: but it's Android init, which is in a container, not the rest 08:52:39 #info This was a pretty long topic with a LOT of information crammed into it. I suggest going back and reading the logs in case you need to revisit something. 08:53:06 bshah: half an hour passed, shall we move on to general discussion? :) 08:53:12 Jaymzz_: sure 08:53:14 fine with me 08:53:27 once again thanks for your time and interest people 08:53:34 Alright, thanks for this productive topic guys! Moving on 08:53:39 also, 08:53:40 #info for anyone interested please join #halium on freenode 08:53:56 Oh and btw, let's anticipate this next time and give our topics a bit more time than needed. It won't hurt ;) 08:54:17 good topic, thanks bshah et al 08:54:19 sorry -ETOOMANYCHANNELS for the busy levels atm:)) but i'll be following the googledoc 08:54:27 chriadam: +1 08:54:39 we will be doing formal announcement of this project soon, can we add in annoucement that sailfishos people are also "part" of this effort? 08:54:39 #topic General discussion (15 min) 08:56:00 sledges: how goes the sony open devices? 08:56:08 bshah: It’s too early to say that, at least officially from Jolla. 08:56:24 as a general question, just an additional topic I wanted to ask about; is it expected that bluez5 would be supported on Jolla sbj1 at least unofficially? 08:56:29 my interest is mainly in getting btle to work a bit more reliably than currently, as it needs a fair amount of hacking t 08:56:32 o be usable. 08:56:33 veskuh: then maybe mer community? 08:56:36 bshah: but i hope porters community will try the halium common base, help tidying it up 08:57:17 sledges, I hope it can be an useful base also for sfdroid ... 08:57:19 rkz: steady progress; and to add to halium topic: xperia open devices will be yet another base to add to the heap: so lineageos, aosp of fp2, and aosp of xperias <- bshah that's the first challenge to solve:) 08:58:19 bshah: and don't forget nemomobile! 08:58:28 they revived recently ^-^ 08:58:43 with some awesome graphics from a new contributor:) 08:58:57 bshah: At least looks here that there are interested mer community members 08:58:57 juiceme: currently the first target is Jolla C for that and then we extend. Of course if community can help on testing it on other devices such testing is welcome. 08:59:08 #info Sony Open Devices project with Xperia X is progressing steadily. 08:59:19 Sage-, thanks 08:59:23 Sage-, is possible to create a custom btrfs free version for jolla1 08:59:28 Sage-: isn't bluez5 on sbj blocked by re-certification? 08:59:47 sledges: does steady progress involve some more details or timeline? or just that you'll keep us posted when it's time? 08:59:48 dr_gogeta86: with sfdroid, since the whole CM rom was flashed, that was used and slightly modified in order to work, this Halium stuff aims to get rid of the whole rom and only keep the specific needed bits. 09:00:00 hmm 09:00:05 guys I will have to leave in 5 minutes.. sorry 09:00:08 Nemo as Halium reference UI? 09:00:15 unexpected appointment 09:00:25 jwalck: hopefully some good news for porters 09:00:29 Jaymzz_, can we revive the first topic ... now nh1402 is here 09:00:40 locusf: :) 09:00:57 I'm interested in bluez5 / BTLE too - and have a jolla c to test on when I know what to test! 09:01:10 dr_gogeta86: topic is shelved 09:01:13 as for next meeting, would you guys mind if we halium team show up here and present some updates next week? 09:01:19 dr_gogeta86: I chatted with him and he said that he will revisit the topic when he can confirm that servo works on Wayland and ARM 09:01:28 ok 09:01:30 dr_gogeta86: in theory it could, but in practice it is harder thing as it requires quite a bit changes. So can't promise such image currently. 09:01:39 Niccco of Sailfish OS fan Club (Telegram) asks "There has been no updates on the Fairphone side. I know that the porting work has been basically completed, but no official support has been added. Is there any update on that side? " 09:01:40 bshah: Please do so! :) 09:01:54 okay.. leaving now then.. 09:01:57 see ya o/ 09:02:12 bshah: Thanks again, cheers. 09:02:14 bshah: meeting is in 2 weeks 09:02:41 Yes, it'll be emailed as well as announced on TJC :) bshah 09:03:09 pavi[m]: talk to fairphone :) 09:03:15 dr_gogeta86: also now there is anbox, and I would say to push forward with that 09:04:02 jwalck: test bluez5 on jolla c with as many different profiles (devices) as you can, am I right Sage- ? :) or forgot something 09:04:23 rkz: Will relay this answer to telegram group. :) 09:04:41 5 minutes remaining of general discussion 09:05:00 jwalck: sledges: The aim is to have bluez5 enabled on next Jolla C release after 2.1.0.x the schedule is still open though. 09:05:27 sledges: check! I'll try prodding my pebble 2 with a sailfish stick and see if it screams:) 09:05:41 hehe, abranson will be pleased :D 09:05:45 veskuh: Any updates on xperia camera? I hope the software can handle all the propreitary stuff like Android. 09:06:18 jwalck: even then it's not a given. pebble wrote their own protocol to communicate with their watches over BTLE 09:06:22 sledges: is the xperia stuff going to use libhybris or the mainline kernel? 09:06:23 pavi[m]: +1 - it would be good to finally have a usable camera on Sailfish OS 09:06:37 pavi[m]: veskuh had to leave about 5 minutes ago, please ask him during the next meeting. 09:06:48 my guess is the former. 09:06:50 nh1402: are there glibc graphics drivers and such? suspect no 09:06:55 even aosp doesn't have full camera support 09:07:02 for sony 09:07:03 Jaymzz_: Its ok. I asked him before also ;) 09:07:03 nh1402: and are there modem graphics too? 09:07:29 abranson: I know. I've been prodding in it from my laptop and it's a sad state of affairs really! 09:07:30 ¯\_(ツ)_/¯ 09:07:31 hmm, actually there is freedreno 09:07:39 2 minutes remaining guys. 09:07:39 you're the one in talks with sony 09:07:49 but there might still be some level of binary stuff 09:07:55 locusf: well aosp is most of the time considered a watered-down version, even google's devices look "empty" with aosp flashed (all main apps are not maintained for years:) since google moved on to closed source main apps) 09:07:59 ofc if sony could provide them for glibc 09:08:21 ah indeed sledges 09:08:31 is the kalman filter going to be fixed? 09:08:32 nh1402: mainline is a long long long way from being fully working 09:08:36 jpetrell: ^ 09:08:39 it's still a huge problem on Jolla C 09:08:40 emphasis on the long 09:08:41 (re kalman filter) 09:09:10 or veskuh ^^ 09:09:13 even though it was marked as fixed on the release notes (kinda concerned about that) 09:09:22 toxip: also +1, it's indeed pretty annoying on the Jolla C 09:09:24 toxip: do we have a TJC bug where it states that it breaks for all devices? or only certain? 09:09:38 toxip: main issue reported and what we saw was related to edge gesture reliability, and it is much better now 09:10:15 I filed a bug on tjc about it 09:10:24 the issue I would like to see fixed is related to unreliability with accepting/dismissing alarm-type dialogs (calls, timers, calendar alarms, etc.) 09:10:26 about jolla c problems 09:10:56 https://together.jolla.com/question/156475/2109-swipes-lag-behind-on-jolla-c-aqua-fish/?sort=votes&page=1 09:10:59 jpetrell: that one seems better, no longer takes 3 times to dismiss alarm for me 09:11:13 rkz: cool 09:11:25 I'm giving an extra 5 mins to this. 09:11:30 working more on touch is on our backlog, its not forgotten 09:11:35 toxip: the reproduce pattern on that TJC is rather amazing how you found it (pressing Q on keyboard myriad of times and then going for edge swipe quickly) cc jpetrell 09:11:49 jpetrell: i'm certain we need to put "Tracked by Jolla" on that question.. 09:12:00 sledges: hehe, thanks 09:12:05 jpetrell: I can confirm this as well - it's a little better now, but generally still needs ~3 tries to silence an alarm 09:12:20 toxip_: is it for all devices? or are there exceptions (which would be worrying, meaning some ts hw bits) 09:12:21 one thing that I wasn't able to reproduce 09:12:31 it seems to be only Jolla C 09:12:38 toxip_: but all Jolla Cs? 09:13:22 hmm, I think some claimed it wasn't a problem for them but quite many have it 09:13:29 need to investigate more 09:13:37 ok, 48 upvotes are quite a number.. 09:13:40 thanks! 09:13:45 at least there has never been any problems like that with sbj1 09:14:10 one thing I wasn't able to reproduce was that sometimes a quick edge swipe gets interpreted as touch hold 09:14:41 Alright moving on in a minute, toxip_let's wrap up 09:14:53 the one I had as screenshot where a button on keyboard looks like it's pressed even though I'm not touching the screen 09:15:16 I'll ask around from the community and see how many people have this 09:15:33 to cover the extent of this problem. Thanks guys 09:15:44 Thanks toxip_ :) 09:15:55 #topic Next meeting time and date (5 min) 09:16:16 bye :) 09:16:36 So, since this has turned back into a bi-weekly meeting, what do you guys say if the next meeting is on Wednesday, 3rd of May 2017, 08:00 UTC? 09:16:50 Give me votes and we'll call it a meeting :) 09:17:03 +1 09:17:06 +1 09:17:09 +1 09:17:25 +1 :P 09:17:34 +1 09:17:42 +1 09:17:47 Alright 09:17:50 +1 09:17:54 make it so 09:18:10 #info Next meeting will be held on Wednesday, 3rd of May 2017 at 08:00 UTC 09:18:11 +1 09:18:29 +1 09:18:37 Thanks guys for this meeting! Awesome as always. Meeting minutes will be sent to you shortly. Cheers! 09:18:44 #endmeeting