08:00:21 <Jaymzz_> #startmeeting Sailfish OS, open source, collaboration – April 19th 2017
08:00:21 <merbot> 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 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:30 <Jaymzz_> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2017-April/007852.html
08:00:38 <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:51 <Jaymzz_> #topic Brief introduction (5 min). Please prefix your name/handle with # info
08:01:04 <locusf> #info Aleksi Suomalainen, SailfishOS community, porter, Nemo enthusiast/master
08:01:06 <Jaymzz_> #info James Noori, Community Manager and Chairperson for this meeting
08:01:22 <rkz> #info Lewis Rockliffe,community member
08:01:27 <chriadam> #info Chris Adams, developer at Jolla
08:01:35 <bshah> #info Bhushan Shah, KDE developer and Plasma Mobile maintainer
08:01:37 <Stskeeps> #info Carsten Munk, crazy person
08:01:43 <Sage___> #info Marko Saukko, Sailor @ Jolla
08:01:47 <M4rtinK_phone_> #info Martin Kolman, community member and modRana developer
08:01:50 <Jaymzz_> Stskeeps: lol :D
08:01:52 <jwalck> #info Jonatan Walck, Community member and home-developer
08:01:52 <eekkelund> #info eekkelund, Maemo Community Council, community dev
08:01:55 <pavi[m]> #info pavi, community
08:02:00 <PureTryOut[m]> #info PureTryOut, community
08:02:02 <Max-Might> #info Kostadin Damyanov, community
08:02:10 <veskuh> #info Vesa-Matti Hartikainen, Program Manager at Jolla
08:02:13 <abranson> #info Andrew Branson, sailor at Jolla
08:02:23 <piggz> #info Adam Pigg, Sailfish OS Community Porter, KDE Developer
08:02:28 <Tofe> #info Christophe Chapuis, community, also LuneOS developer
08:02:30 <sledges> #info Simonas Leleiva, l10n'n'hw at Jolla
08:02:30 <pketo> #info Pami Ketolainen, backend developer @ Jolla
08:02:45 <m2ko> #info m2ko, community
08:02:48 <oniongarlic> #info Kaj-Michael Lang, community
08:02:52 <pasko_> #info pasko user
08:02:54 <tbr> #info Thomas Ruecker, a mer community member
08:03:38 <LarstiQ> #info Wouter van Heijst, infra at Jolla
08:03:45 <hge> #info Hongwei Ge, sailor@Jolla
08:03:53 <stephg> #info Steph Gosling, community, porter
08:04:18 <RodSeq> #info Rodolphe Sequeira, community
08:04:38 <Venty> #info Martin Ebnoether, Community Member
08:05:13 <Jaymzz_> Wow, we are so many today! Welcome everyone :)
08:05:35 <juiceme> #info juiceme, general hacker
08:06:25 <dr_gogeta86> #info Fabio Isgrò, Community Member
08:06:40 <Jaymzz_> #topic Sailfish Browser /servo (revisit) asked by nh1402 (20 min)
08:06:41 <Federico_III> #info Federico_III, software designer, python samurai, C
08:06:52 <tadzik> #info tadzik, community, app developer
08:07:06 <Jaymzz_> #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 <rainemak> #info Raine M�kel�inen, developer @ Jolla
08:07:33 <linux_unix-10> #info Julius Enriquez, Community member, Android and Linux power user, technology enthusiast, curious person
08:07:33 <Jaymzz_> Is nh1402 here today? Didn't see him in the intro section
08:08:53 <Jaymzz_> 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 <hge> !seen nh1402
08:08:58 <merbot> hge: nh1402 was last seen in #mer-meeting 1 week, 6 days, 21 hours, 56 minutes, and 51 seconds ago: <nh1402> fine by me
08:09:12 <rkz> any comment rainemak? for the logs
08:09:53 <rainemak> Nope, only thing that I can think of is setting up Servo project to
08:09:57 <Jaymzz_> rkz: We did discuss this last week for about 20 minutes or so, there are logs available on it already.
08:10:01 <M4rtinK_phone_> I guess this is mainly about shipping something in Rust by default, right ?
08:10:01 <rainemak> for Sailfish
08:10:10 <rkz> Jaymzz_: i was getting a sense of dejavu :D
08:10:26 <M4rtinK_phone_> Are we setup to do that ?
08:10:35 <rainemak> yes, and as nh1402 is not present I'd continue to next topic
08:10:41 <Jaymzz_> 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 <Jaymzz_> rainemak: Yes, will do
08:10:58 <Jaymzz_> Moving on
08:11:03 <rainemak> cheers
08:11:12 <Jaymzz_> #topic Possibility to enable 802.11r support in wpa_supplicant, asked by pasko (10 min)
08:11:15 <Nokius> #info Nokius community sailfishos-porter
08:11:25 <Jaymzz_> #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 <Jaymzz_> #link https://together.jolla.com/question/154955/80211r-roaming-implemented/
08:12:22 <pasko_> hi. Just wanna say I think it would.be easy.to enable this.feature
08:13:01 <pasko_> Do you think it would be possible?
08:13:04 <veskuh> Sage-: ^ What do you think?
08:13:05 <Sage-> 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 <Sage-> 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 <pasko_> I,ve ben using it for weeks in Jolla1 and JollaC
08:14:06 <Jaymzz_> #link https://git.merproject.org/mer-core/wpa_supplicant/blob/master/rpm/build-config
08:14:59 <pasko_> Problem is I,m not familiar with PR. :P
08:15:00 <Jaymzz_> #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 <pasko_> But will try it anyway. :)
08:16:05 <LarstiQ> pasko_: you can ask for help in #mer
08:16:09 <Jaymzz_> #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 <Sage-> pasko_: https://www.youtube.com/watch?v=xtcEQNOKbg8 maybe helps :)
08:17:16 <pasko_> Ok. Will check it later. Thank you.
08:17:29 <Jaymzz_> #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 <Jaymzz_> pasko_: Shall we move on then? :)
08:18:04 <pasko_> Sure!
08:18:10 <Jaymzz_> Alright thank you!
08:18:22 <Jaymzz_> #topic Project Halium, collaboration on common android base, by bshah, toxip, mariogrip (15 min)
08:18:35 <Jaymzz_> #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 <Jaymzz_> 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 <Jaymzz_> #link http://lists.sailfishos.org/pipermail/devel/2017-April/007842.html
08:19:23 <bshah> Hello everyone, so, sadly currently toxip and mariogrip are not available here (timezones heh)
08:19:29 <bshah> But I will explain this
08:19:45 <juiceme> I thought about this and the clearest solution would be if all could just use mer as their base.
08:20:08 <rkz> let him explain first juiceme :P
08:20:13 <juiceme> sure :)
08:20:27 <bshah> So, currently for android devices we 3 sub communities are using seperate base for android and different methods of starting android
08:20:44 <bshah> say, droid-hal-init v/s lxc container etc..
08:21:12 <bshah> each method have their own pro/cons, I am not saying that any base is 100% perfect
08:21:46 <bshah> but project halium aims to collaborate on common android base (not userspace) so we could each benifit from porting efforts
08:22:18 <bshah> we have draft document prepared explaining it and I had sent it to sailfishos devel list earlier
08:23:06 <bshah> so yeah, any thoughts?
08:23:11 <rkz> this will also cover areas that currently Mer does not, its adaptations are typically based upon the now defunked cyanogenmod project
08:23:52 <Coolgeek> https://xkcd.com/927/ ? this remind me of this
08:23:59 <rkz> 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 <Sage-> 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 <M4rtinK_phone_> I agree with juiceme - seems like a good opportunity to expand Mer
08:24:20 <M4rtinK_phone_> than to start something completely new
08:24:29 <bshah> Coolgeek: thing is there is no standard at all about mer
08:24:32 <rkz> "Why not Mer"? well, different people want to do different things and Mer doesnt help them get there
08:24:39 <bshah> err.. s/mer/android base/
08:24:43 <Nokius> +1 juiceme M4rtinK_phone_
08:24:49 <Sage-> 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 <veskuh> Stskeeps: ^ What are your thoughts on this approach?
08:24:51 <rkz> if you want to use debs, mer doesnt help. if you want bleeding edge Qt mer doesnt help either
08:25:24 <Stskeeps> 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 <juiceme> rkz, please explain "different things" not possible with mer?
08:25:49 <tbr> in my humble opinion it should be all fairly abstractable
08:25:51 <Sage-> 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 <tbr> and possible to share certain parts
08:26:25 <rkz> tbr: exactly, the parts we are all shackled to are the android bits
08:26:25 <Nokius> Sage-: exactly
08:27:11 <bshah> juiceme: if someone wants to say use ubuntu rootfs, its not impossible but hard with mer, unless you fork and adapt
08:27:13 <rkz> juiceme: see above, for instance the plasma mobile guys need qt 5.7, mer doesnt give you that
08:27:24 <sledges> 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 <LarstiQ> rkz: in theory, obs supports deb builds from .spec. Not sure how painful
08:27:37 <juiceme> 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 <Tofe> 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 <Sage-> 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 <sledges> 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 <rkz> pavi[m]: keep dreaming :)
08:28:53 <rkz> 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 <piggz> i see no reason why qt5.7 and plasma mobile UI coulndt be built on mer?
08:29:25 <M4rtinK_phone_> aren't the Android bits way down below Qt and packaging ?
08:29:56 <M4rtinK_phone_> that seems something that should be possible to share and co-maintain
08:29:58 <bshah> piggz: sure it can be built, but it comes down to choice and skills of developers as well
08:30:06 <nh1402> sledges: Lineage can still use CAF though right, so which way would best CAF based or no CAF?
08:30:19 <Sage-> way below, old architecture picture of sailfish os https://sailfishos.org/wp-content/uploads/2016/02/Sailfish_Architecture.jpg
08:30:24 <pavi[m]> bshah:  It would be great to have plasma mobile running on Mer.
08:30:27 <rkz> M4rtinK_phone_: yeah, theres a couple of things that punch heigher like ofono, systemd, media stuff
08:30:44 <Jaymzz_> #link https://sailfishos.org/wp-content/uploads/2016/02/Sailfish_Architecture.jpg
08:30:49 <piggz> bshah: i have already built 20 or so KF5 frameworks on the mer OBS btw to support Kexi development
08:31:15 <sledges> 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 <bshah> piggz: sure, kf5 itself is not issue, issue is kwin_wayland
08:32:26 <Max-Might> 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 <bshah> Max-Might: exactly
08:32:39 <Sage-> 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 <Jaymzz_> 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 <bshah> Jaymzz_: yey. :p
08:33:43 <rkz> 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 <sledges> there already has been successful collaboration within HW adaptation projects: pulseaudio-modules-droid, qpa plugin, ...
08:34:26 <niqt> Which will the relation between libhybris and halium?
08:34:34 <toxip> #info Topias Vainio, Sailfish OS Fan Club founder (sorry I overslept)
08:34:55 <Tofe> halium's scope is the android base *used by* libhybris
08:35:14 <rkz> 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 <rkz> s/say/way
08:35:26 <jwalck> 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 <tbr> JFTR I have Qt 5.8 building fine on Mer
08:36:12 <tbr> I could use some help with it, but that's off-topic.
08:36:57 <sledges> 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 <bshah> sledges: nice to hear
08:37:32 <nh1402> some containers at least require kernel level changes I think.
08:37:53 <bshah> we haven't documented pros/cons in much more details in document, but I guess we can improve it
08:38:04 <rkz> 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 <nh1402> which in some cases are only available on certain kernel versions
08:38:05 <tbr> I remember a friend running the systemd/cgroups container stuff on a stock jolla phone years ago
08:38:28 <juiceme> 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 <M4rtinK_phone_> indeed, IIRC some of the kernel level APIs are just not there in the outdated Android kernels
08:38:47 <chriadam> we're back to the ODM support question, then
08:38:55 <sledges> 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 <tbr> well, also systemd imposes a minimum version on the kernel
08:39:18 <Nokius> tbr: the kernel needs adjustemts for the systemd container
08:39:22 <bshah> sledges: great, yes, we ourself need to babystep first
08:39:31 <sledges> if that succeeds, then future is brighter:)
08:39:52 <sledges> and that success would also mean - less fragmentation of hybris patches on android base
08:39:55 <sledges> already
08:40:03 <rkz> agreed
08:40:05 <tbr> I think we should focus on spelling out the common/shared things and look at those
08:40:20 <M4rtinK_phone_> tbr: +1
08:40:28 <sledges> 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 <tbr> and then see how far up the stack we can go before things start to diverge
08:40:37 <linux_unix-10> Would it be possible to patch the kernel for systemd during installation?
08:41:06 <pavi[m]> tbr:  well said.
08:41:14 <sledges> 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 <jwalck> 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 <tbr> and having the possibility to modify kernel defconfig is pretty much required
08:41:58 <jwalck> 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 <bshah> jwalck: jep.. totally agree
08:42:38 <rkz> 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 <locusf_> 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 <Tofe> 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 <tbr> Tofe: yes
08:43:19 <jwalck> rkz: *nodnod* think I grasp the concepts here even tho this isn't parts I've worked with
08:43:27 <sledges> 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 <tbr> I can see halium as a common toolset to produce the output that then gets ingested and formed into packages
08:43:49 <sledges> but that i suggest to be a less steered effort for the moment, and priorities considered
08:43:55 <mal> some devices still need custom android bases like the custom aosp for fp2
08:43:59 <tbr> I personally don't see a reason to discuss containers at this point, yet
08:44:08 <jwalck> locusf_: check, that's another place in the stack to converge through!
08:44:16 <tbr> go up the stack, find common grounds
08:44:44 <locusf_> sure
08:44:58 <Sage-> Tofe: tbr: kernel is per device not per distro on these devices unfortunately. Thus also mer core doesn't have kernel. :)
08:45:31 <bshah> at this point our stage 0 development plan is to basically have a rootfs which is able to run libhybris tests
08:45:45 <Jaymzz_> bshah: 25 minutes gone, maybe time to wrap up slowly :)
08:45:47 <Tofe> Sage-: I know, but Mer core isn't the distro, it's the infrastructure of the distro
08:45:57 <bshah> Jaymzz_: *nod*
08:46:18 <bshah> so yes, before we wrap up, any final comments?
08:46:23 <chriadam> what are the concrete actions?  and who are those actions for?  I'm a bit lost in this discussion.
08:46:24 <Sage-> Tofe: mainly saying that you are asking for a trouble if you aim to have one kernel for your distro :)
08:46:28 <locusf_> lots of stuff to #info
08:47:32 <toxip> So Jolla is potentially interested but not able to invest effort in this at this time?
08:47:44 <Coolgeek> isn't dtree solved one kernel / device ?
08:48:22 <bshah> 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 <bshah> after that this android base can be used to start plasma mobile, utouch, sfos and see how it goes
08:49:15 <toxip> 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 <Tofe> agreed
08:50:15 <bshah> (we should add #info points and move on to next topic perhaps)
08:50:16 <jwalck> bshah, toxip: check. now the fog is lifting! sounds like the right place to start.:)
08:50:30 <sledges> #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 <Nokius> +1
08:51:13 <rkz> gogo sledges :)
08:51:13 <dr_gogeta86> sledges, i like the idea to "slap" sfos into into a container
08:51:37 <sledges> dr_gogeta86: i'm very interested in pros+cons, from someone who already did that (ubports?)
08:51:37 <dr_gogeta86> the problem are the ancient kernels out there
08:51:45 <Jaymzz_> #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 <Jaymzz_> quite hard to get working with Sailfish OS and our ODM partners.
08:52:03 <Tofe> sledges: we (at LuneOS) did that too
08:52:11 <pavi[m]> dr_gogeta86:  Me also. SFOS in a container is tempting. ;)
08:52:22 <dr_gogeta86> isn't tempting ... is the way to go
08:52:36 <Tofe> sledges: but it's Android init, which is in a container, not the rest
08:52:39 <Jaymzz_> #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 <Jaymzz_> bshah: half an hour passed, shall we move on to general discussion? :)
08:53:12 <bshah> Jaymzz_: sure
08:53:14 <bshah> fine with me
08:53:27 <bshah> once again thanks for your time and interest people
08:53:34 <Jaymzz_> Alright, thanks for this productive topic guys! Moving on
08:53:39 <bshah> also,
08:53:40 <rkz> #info for anyone interested please join #halium on freenode
08:53:56 <Jaymzz_> 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 <chriadam> good topic, thanks bshah et al
08:54:19 <sledges> sorry -ETOOMANYCHANNELS for the busy levels atm:)) but i'll be following the googledoc
08:54:27 <veskuh> chriadam: +1
08:54:39 <bshah> 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 <Jaymzz_> #topic General discussion (15 min)
08:56:00 <rkz> sledges: how goes the sony open devices?
08:56:08 <veskuh> bshah: It’s too early to say that, at least officially from Jolla.
08:56:24 <juiceme> 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 <juiceme> 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 <juiceme> o be usable.
08:56:33 <bshah> veskuh: then maybe mer community?
08:56:36 <sledges> bshah: but i hope porters community will try the halium common base, help tidying it up
08:57:17 <dr_gogeta86> sledges, I hope it can be an useful base also for sfdroid ...
08:57:19 <sledges> 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 <sledges> bshah: and don't forget nemomobile!
08:58:28 <sledges> they revived recently ^-^
08:58:43 <sledges> with some awesome graphics from a new contributor:)
08:58:57 <veskuh> bshah: At least looks here that there are interested mer community members
08:58:57 <Sage-> 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 <Jaymzz_> #info Sony Open Devices project with Xperia X is progressing steadily.
08:59:19 <juiceme> Sage-, thanks
08:59:23 <dr_gogeta86> Sage-, is possible to create a custom btrfs free version for jolla1
08:59:28 <sledges> Sage-: isn't bluez5 on sbj blocked by re-certification?
08:59:47 <jwalck> 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 <nh1402> 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 <locusf> hmm
09:00:05 <bshah> guys I will have to leave in 5 minutes.. sorry
09:00:08 <locusf> Nemo as Halium reference UI?
09:00:15 <bshah> unexpected appointment
09:00:25 <sledges> jwalck: hopefully some good news for porters
09:00:29 <dr_gogeta86> Jaymzz_,  can we revive the first topic ... now nh1402 is here
09:00:40 <Nokius> locusf: :)
09:00:57 <jwalck> I'm interested in bluez5 / BTLE too - and have a jolla c to test on when I know what to test!
09:01:10 <nh1402> dr_gogeta86: topic is shelved
09:01:13 <bshah> as for next meeting, would you guys mind if we halium team show up here and present some updates next week?
09:01:19 <Jaymzz_> 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 <dr_gogeta86> ok
09:01:30 <Sage-> 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 <pavi[m]> 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 <Jaymzz_> bshah: Please do so! :)
09:01:54 <bshah> okay.. leaving now then..
09:01:57 <bshah> see ya o/
09:02:12 <Jaymzz_> bshah: Thanks again, cheers.
09:02:14 <sledges> bshah: meeting is in 2 weeks
09:02:41 <Jaymzz_> Yes, it'll be emailed as well as announced on TJC :) bshah
09:03:09 <rkz> pavi[m]: talk to fairphone :)
09:03:15 <nh1402> dr_gogeta86: also now there is anbox, and I would say to push forward with that
09:04:02 <sledges> 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 <pavi[m]> rkz:  Will relay this answer to telegram group. :)
09:04:41 <Jaymzz_> 5 minutes remaining of general discussion
09:05:00 <Sage-> 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 <jwalck> sledges: check! I'll try prodding my pebble 2 with a sailfish stick and see if it screams:)
09:05:41 <sledges> hehe, abranson will be pleased :D
09:05:45 <pavi[m]> veskuh:  Any updates on xperia camera? I hope the software can handle all the propreitary stuff like Android.
09:06:18 <abranson> jwalck: even then it's not a given. pebble wrote their own protocol to communicate with their watches over BTLE
09:06:22 <nh1402> sledges: is the xperia stuff going to use libhybris or the mainline kernel?
09:06:23 <M4rtinK> pavi[m]: +1 - it would be good to finally have a usable camera on Sailfish OS
09:06:37 <Jaymzz_> pavi[m]: veskuh had to leave about 5 minutes ago, please ask him during the next meeting.
09:06:48 <nh1402> my guess is the former.
09:06:50 <tbr> nh1402: are there glibc graphics drivers and such? suspect no
09:06:55 <locusf> even aosp doesn't have full camera support
09:07:02 <locusf> for sony
09:07:03 <pavi[m]> Jaymzz_:  Its ok. I asked him before also ;)
09:07:03 <sledges> nh1402: and are there modem graphics too?
09:07:29 <jwalck> abranson: I know. I've been prodding in it from my laptop and it's a sad state of affairs really!
09:07:30 <nh1402> ¯\_(ツ)_/¯
09:07:31 <tbr> hmm, actually there is freedreno
09:07:39 <Jaymzz_> 2 minutes remaining guys.
09:07:39 <nh1402> you're the one in talks with sony
09:07:49 <tbr> but there might still be some level of binary stuff
09:07:55 <sledges> 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 <tbr> ofc if sony could provide them for glibc
09:08:21 <locusf> ah indeed sledges
09:08:31 <toxip> is the kalman filter going to be fixed?
09:08:32 <rkz> nh1402: mainline is a long long long way from being fully working
09:08:36 <sledges> jpetrell: ^
09:08:39 <toxip> it's still a huge problem on Jolla C
09:08:40 <rkz> emphasis on the long
09:08:41 <sledges> (re kalman filter)
09:09:10 <sledges> or veskuh ^^
09:09:13 <toxip> even though it was marked as fixed on the release notes (kinda concerned about that)
09:09:22 <M4rtinK> toxip: also +1, it's indeed pretty annoying on the Jolla C
09:09:24 <sledges> toxip: do we have a TJC bug where it states that it breaks for all devices? or only certain?
09:09:38 <jpetrell> toxip: main issue reported and what we saw was related to edge gesture reliability, and it is much better now
09:10:15 <toxip_> I filed a bug on tjc about it
09:10:24 <jpetrell> 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 <toxip_> about jolla c problems
09:10:56 <toxip_> https://together.jolla.com/question/156475/2109-swipes-lag-behind-on-jolla-c-aqua-fish/?sort=votes&page=1
09:10:59 <rkz> jpetrell: that one seems better, no longer takes 3 times to dismiss alarm for me
09:11:13 <jpetrell> rkz: cool
09:11:25 <Jaymzz_> I'm giving an extra 5 mins to this.
09:11:30 <jpetrell> working more on touch is on our backlog, its not forgotten
09:11:35 <sledges> 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 <sledges> jpetrell: i'm certain we need to put "Tracked by Jolla" on that question..
09:12:00 <toxip_> sledges: hehe, thanks
09:12:05 <M4rtinK> 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 <sledges> toxip_: is it for all devices? or are there exceptions (which would be worrying, meaning some ts hw bits)
09:12:21 <toxip_> one thing that I wasn't able to reproduce
09:12:31 <toxip_> it seems to be only Jolla C
09:12:38 <sledges> toxip_: but all Jolla Cs?
09:13:22 <toxip_> hmm, I think some claimed it wasn't a problem for them but quite many have it
09:13:29 <toxip_> need to investigate more
09:13:37 <sledges> ok, 48 upvotes are quite a number..
09:13:40 <sledges> thanks!
09:13:45 <juiceme> at least there has never been any problems like that with sbj1
09:14:10 <toxip_> one thing I wasn't able to reproduce was that sometimes a quick edge swipe gets interpreted as touch hold
09:14:41 <Jaymzz_> Alright moving on in a minute, toxip_let's wrap up
09:14:53 <toxip_> 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 <toxip_> I'll ask around from the community and see how many people have this
09:15:33 <toxip_> to cover the extent of this problem. Thanks guys
09:15:44 <Jaymzz_> Thanks toxip_ :)
09:15:55 <Jaymzz_> #topic Next meeting time and date (5 min)
09:16:16 <juiceme> bye :)
09:16:36 <Jaymzz_> 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 <Jaymzz_> Give me votes and we'll call it a meeting :)
09:17:03 <stephg> +1
09:17:06 <dr_gogeta86> +1
09:17:09 <locusf> +1
09:17:25 <Jaymzz_> +1 :P
09:17:34 <nh1402> +1
09:17:42 <juiceme> +1
09:17:47 <Jaymzz_> Alright
09:17:50 <Venty> +1
09:17:54 <rkz> make it so
09:18:10 <Jaymzz_> #info Next meeting will be held on Wednesday, 3rd of May 2017 at 08:00 UTC
09:18:11 <RodSeq> +1
09:18:29 <jwalck> +1
09:18:37 <Jaymzz_> Thanks guys for this meeting! Awesome as always. Meeting minutes will be sent to you shortly. Cheers!
09:18:44 <Jaymzz_> #endmeeting