10:13:30 <Jaymzz1> #startmeeting
10:13:30 <merbot> Meeting started Thu Aug  9 10:13:30 2018 UTC.  The chair is Jaymzz1. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
10:13:30 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:13:42 <Jaymzz1> #info  Sailfish OS, open source, collaboration – August 9th 2018
10:13:51 <tortoisedoc> #into tortoisedoc sfos user & developer
10:13:53 <Jaymzz1> #info meeting information and agenda can be found here: http://lists.sailfishos.org/pipermail/devel/2018-August/008441.html
10:13:54 <tortoisedoc> argh
10:14:02 <Jaymzz1> tortoisedoc: wait for it :D
10:14:05 <tortoisedoc> ok
10:14:17 <Jaymzz1> 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.
10:14:26 <Jaymzz1> #topic Brief introduction (5 min)
10:14:42 <Jaymzz1> #info James Noori - late chair
10:15:04 <DylanVanAssche> #info Dylan Van Assche - developer & community member
10:15:04 <Jaymzz1> #info Please prefix your name/handle with # info
10:15:05 <tortoisedoc> #info tortoisedoc sfos user / qt developer
10:15:26 <flypig> #info David Llewellyn-Jones - dev in the community
10:15:32 <abranson> #info Andrew Branson - sailing by
10:15:36 <jpetrell> #info Joona Petrell - sailor @ Jolla
10:15:45 <lbt> #info David Greaves - Sailor and Mer guy
10:16:06 <Timmy_L> #info Timmy Larsson - sailor
10:16:27 <Sugash> #info Sugash sfos user
10:16:33 <M4rtinK_> #info Martin Kolman - modRana & community
10:16:36 <silver_hook> #info Matija Šuklje - ex- and hopefully soon again SailfishOS user (FOSS lawyer otherwise)
10:17:14 <tortoisedoc> oh man
10:17:20 <tortoisedoc> this is going to be aride
10:17:32 <pketo> #info Pami Ketolainen, developer @ Jolla
10:18:38 <Nokius> #info Nokius, community
10:20:05 <tortoisedoc> I guess we lost James?
10:20:13 <Jaymzz1> tortoisedoc: nope
10:20:16 <Jaymzz1> moving on in a sec
10:20:17 <tortoisedoc> ah
10:20:28 <tortoisedoc> timetables matter after all : )
10:20:28 <Jaymzz1> #topic freedesktop standards vs lipstick (15 min – asked by tortiosedoc )
10:20:43 <Jaymzz1> #info currently freedesktop standards is partially adhered to by lipstick. Mainly user-defined conifiguration is not prioritized over system defaults, as requested by the spec in an obscure way here ; in particular "The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS. ") is currently not adhered to by lipstick, which searches both locations (system & us
10:20:43 <Jaymzz1> er). The fix as such is "straightforward", but carries serious security implications with it. The idea is to brainstorm workarounds to harden the security of this "feature" and come up with a solution.
10:21:07 <Jaymzz1> #link https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html
10:21:46 <tortoisedoc> yes
10:22:02 <tortoisedoc> should I just go on?
10:22:17 <tortoisedoc> or do you want to add anything to it @Jaymzz1
10:22:34 <Jaymzz1> yes, 1 sec
10:22:38 <Jaymzz1> #info We try to align with freedesktop.org standards. Sometimes it is difficult since e.g. some conventions used in Linux Desktop environments conflict with modern UX requirements (performance, scalability, transitions).
10:23:11 <Mister_Magister> #info Mister_Magister late porter
10:23:55 <Jaymzz1> tortoisedoc: anything else? :)
10:24:10 <tortoisedoc> you mean from my side? :)
10:24:18 <Jaymzz1> yes
10:24:19 <jpetrell> these kind of directory conventions are the kind of technical depth we should do more, but that is hard to prioritise without paying customer
10:24:20 <tortoisedoc> yes
10:24:30 <tortoisedoc> there's two things here imo
10:24:38 <Jaymzz1> #info by jpetrell these kind of directory conventions are the kind of technical depth we should do more, but that is hard to prioritise without paying customer
10:24:39 <tortoisedoc> (and btw sorry for the wall of text on the post)
10:24:47 <tortoisedoc> one
10:24:52 <Jaymzz1> no worries, go ahead you have time :)
10:24:54 <tortoisedoc> (and perahps the least concerning one)
10:25:05 <tortoisedoc> is the fact that lipstick does not fully adhere to the standard
10:25:17 <tortoisedoc> and two
10:25:33 <tortoisedoc> (which in my opinion is more "worrying")
10:25:58 <tortoisedoc> is that it the way it currently handles user defined .desktop entries does not secure user's behaviour
10:26:20 <jpetrell> tortoisedoc: what do you mean?
10:26:24 <flypig> Could you please elaborate on the security implications?
10:27:08 <tortoisedoc> I mean, you will have duplicated app entries on the launcher pages, for example by copying over a simple .desktop file from the system /usr/shared/applications to .local/shared/applications
10:27:35 <tortoisedoc> lipstick as suck treats both as "applications", and does not differentiate between which one is user-generated and which is system-installed
10:27:39 <tortoisedoc> lipstick as suck treats both as "applications", and does not differentiate between which one is user-generated and which is system-installed
10:27:43 <flypig> You'd expect one to override the other instead?
10:27:47 <tortoisedoc> heh sorry too much use of slack :D
10:28:02 <tortoisedoc> that's where the consequences come into play
10:28:15 <tortoisedoc> and that's what the standard proposes
10:28:16 <tortoisedoc> but
10:28:37 <theresajayne5> Christel just posted this "denial" on the freenode blog https://freenode.net/news/spam-shake Why does this blog post mention "10.2 million" THREE times?
10:28:37 <theresajayne5> This blog is essentially an ad for the Handshake ICO scam with a one-line "denial" of involvement mixed in there. It's obviously very unethical of Christel to not mention her own involvement in the scam which the blog post promotes.
10:28:37 <theresajayne5> Consider Andrew Lee's involvement, Andrew Lee is Christel's boss at London Trust Media and he also controls the majority of freenode voting rights. Andrew Lee also heads the handshake ICO scam. Coincidence?
10:28:42 <tortoisedoc> it carries security issues, as any app can write (as it is) to .local/shared/applications
10:28:57 <tortoisedoc> so if you add this with the override possibility, you have a major security flaw right there
10:30:29 <tortoisedoc> so yes, definitely overriding by having user-defined entries; but how to guarantee that those are created only when the user / app has the right intentions
10:30:38 <tortoisedoc> is one
10:30:39 <jpetrell> we need more finegrained security model, this is one instance out of many of apps having access to too many things in home
10:30:59 <tortoisedoc> well one approach
10:31:06 <tortoisedoc> could be to rely on the groups / fs attributes
10:31:22 <tortoisedoc> following the good old "root is king" principle
10:31:43 <tortoisedoc> (and that if a malicious user compromises root, all bets are off anyways)
10:31:57 <Jaymzz1> 10 minutes gone tortoisedoc, let me know if you need extra time before it reaches the 15 min limit
10:32:05 <tortoisedoc> 15 mins will do thanks :)
10:32:40 <tortoisedoc> so the purpose of this topic in this meeting was to collect feedback on this possible solution from the jolla sailors
10:32:51 <tortoisedoc> someone else (probably me) can make a mr then
10:32:57 <tortoisedoc> to nemo lipstick
10:33:34 <tasse9> Christel just posted this "denial" on the freenode blog https://freenode.net/news/spam-shake Why does this blog post mention "10.2 million" THREE times?
10:33:34 <tasse9> This blog is essentially an ad for the Handshake ICO scam with a one-line "denial" of involvement mixed in there. It's obviously very unethical of Christel to not mention her own involvement in the scam which the blog post promotes.
10:33:44 <tortoisedoc> @jpetrell any opinions?
10:34:07 <lbt> It feels like we have 2 issues - 1) handling duplication and/or override  and 2) controlling access to the metadat in $home
10:34:16 <tortoisedoc> lbt : exactly
10:34:19 <lbt> 1 seems like a functional bug
10:34:23 <tortoisedoc> lbt : exactly :)
10:34:39 <lbt> 2 seems like a part of the security framework for apps
10:34:56 <lbt> splitting them would allow us to progress more on 1)
10:35:12 <tortoisedoc> but the problem is you cant have 1 without 2 (for security reasons)
10:35:16 <tortoisedoc> as in
10:35:19 <tortoisedoc> you need 2 before 1
10:35:22 <lbt> 2) is something we're all aware of but realistically isn't probably worth fixing in a bit-by-bit manner
10:36:42 <Jaymzz1> tortoisedoc: I guess extra minutes were needed ;)
10:37:01 <tortoisedoc> Jaymzz1 if you can drop in 5 more please go ahead :P
10:37:21 <Jaymzz1> #info 5 more minutes added to this topic
10:37:24 <tortoisedoc> +1
10:37:39 <tortoisedoc> tbh im surprised this seems to raise so few concern on the jolla side
10:37:47 <jpetrell> tortoisedoc: I don't have objections on improving system<->user heuristics or adding access control to user configuration, though not sure what the exact solutions should be
10:37:49 <lbt> jpetrell: any thoughts on 2) ?    I feel that there are likely other equivalent 'weaknesses'
10:37:52 <tortoisedoc> (not so much the standard problem, but the functional bug)
10:38:12 <tortoisedoc> (as well as the security implications)
10:39:08 <tortoisedoc> we'd need a spinner here :D
10:39:33 <jpetrell> we have been securing connectivity and sw management apis during past year or so, desktop manager hasn't seen much love yet
10:40:19 <Mister_Magister> slightly off topic but im kinda afraid that apps can gain root without my knowledge while on desktop there is always password prompt
10:40:23 <tortoisedoc> yes as lbt says this is definitely part of a bigger picture
10:40:51 <tortoisedoc> Mister_Magister : how would they do that?
10:41:18 <Mister_Magister> tortoisedoc: dunno but you can find many "start as root" apps at openrepos
10:41:22 <tortoisedoc> (considering harbour limitations I mean)
10:41:25 <lbt> as long as apps run in the same context as 'full user' then I think we're just putting on band-aids
10:41:39 <leszek> probably using policykit rules in those openrepos packages
10:41:48 <tortoisedoc> lbt : yes, but the app in question *is* root (lipstick)
10:42:48 <lbt> Oh for sure we need to ensure lipstick does not get fooled by desktop config stuff
10:42:51 <Jaymzz1> tortoisedoc: time is up mate, but I don't think you are done. Do you want to continue later at general discussion?
10:43:07 <tortoisedoc> we can if people are interested :)
10:43:17 <tortoisedoc> Jaymzz1 ^
10:43:18 * lbt is happy that community work can start on the functional side
10:43:21 <tortoisedoc> lbt : yes exactly
10:43:32 <Jaymzz1> I'm sure they are, sorry though we have to move on as we are both late and over time :)
10:43:40 <tortoisedoc> thats ok :)
10:43:46 <lbt> Jaymzz1: sec
10:43:49 <tortoisedoc> this is anyways an introduction meeting
10:43:52 <Jaymzz1> lbt okay
10:44:37 <tortoisedoc> perhaps the discussion could continue on the sfdev ml
10:44:38 <lbt> #info community can work on functional improvements to lipstick's handling of desktop metadata. Initially providing a proposal for heuristics
10:44:45 <lbt> done - ty
10:44:50 <Jaymzz1> cheers
10:44:53 <Jaymzz1> #topic QtWebengine status (20 min – asked by DylanVanAssche )
10:45:03 <Jaymzz1> #info The announcement on MWC told the community that some partners will port QtWebengine to Sailfish OS. This would be a huge improvement than the current state of webengines in Sailfish OS. Is there any news on that front? Is it possible for developers like me to have an early early preview? I would love to test the stuff and report any bugs I can find. Sailbook for example would profit a lot from QtWebengine.
10:45:21 <Jaymzz1> oops, I skipped a topic, didn't mean to
10:45:41 <Jaymzz1> will take ApBBB's topic after this one, sorry
10:45:52 <ApBBB> Jaymzz1: fine with me
10:45:54 <ApBBB> :)
10:45:56 <DylanVanAssche> Okay :)
10:46:28 <Jaymzz1> DylanVanAssche: So as far as I know this is pending a Qt upgrade, but let's see what the others have to say :)
10:46:31 <jpetrell> well IMO Gecko is in better shape on SFOS than WebEngine so not sure about huge improvement, also many things matter in what makes browser great
10:46:49 <jpetrell> yes allowing qtwebengine has mostly been lgpl3 issue
10:46:54 <leszek> compiling qtwebengine alone for SFOS is not enough. It needs a QML API. The one Qt provides is a joke in comparison to QtWebkit. So if Jolla does not put effort in doing that the QtWebEngine stuff for SFOS will be a nice gimmick no one can really use
10:47:21 <jpetrell> doesn't mean it will be awesome out-of-the-box without bug fixing
10:47:27 <jpetrell> yeah
10:47:37 <jpetrell> I wouldn't say gimmick, still okish
10:47:45 <leszek> thats what I fear aswell. Seeing in what bad shape qtwebkit is and jolla doesn't care about it anymore
10:47:45 <DylanVanAssche> True, Gecko might be in a better shape for SFOS but it's horrible out of date. I know it's hard to maintain the browser
10:48:22 <jpetrell> nobody wants to work on browser engine more than our team, but yeah it is not trivial investment
10:48:31 <tortoisedoc> so seems like both options suffer from a similar disease (age)
10:48:53 <leszek> Gecko prior Quantum for SFOS will be a joke aswell. We need something secure and current
10:49:11 <tortoisedoc> is quantum gecko "upgrade" not backwards compatible?
10:49:29 <leszek> Jolla worked on a webview for the gecko base. Maybe its time to make that work with QtWebengine instead
10:49:43 <DylanVanAssche> QtWebengine might be a better choice since it's updated by the Qt release
10:49:59 <tigermousr7> Christel just posted this "denial" on the freenode blog https://freenode.net/news/spam-shake Why does this blog post mention "10.2 million" THREE times?
10:50:05 <Mister_Magister> DylanVanAssche: whole sfos is out of date land :P
10:50:13 <DylanVanAssche> Still behind but doesn't requires the same effort as maintaining the Gecko engine
10:50:14 <leszek> true. So one only has to maintain the potential QML API for it from Jolla side of view
10:50:48 <tortoisedoc> but gecko is mantained by firefox?
10:51:00 <tortoisedoc> (or is it)
10:51:01 <leszek> tortoisedoc: gecko is dead
10:51:02 <DylanVanAssche> Yes, but the Qt port isn't.
10:51:13 <tortoisedoc> leszek : ah ok!
10:51:14 <DylanVanAssche> Jolla maintains it for them
10:51:16 <leszek> tortoisedoc: quantum is the current engine
10:51:33 <jpetrell> I wouldn't mind moving some of the maintenance burden to Qt, still switching engines is quite much more than switching engine behind QML API. browser e.g. requires custom graphics pipeline to secure performance
10:51:36 <tortoisedoc> so actually the right question here is quantum vs qtwebengine
10:51:41 <leszek> Jolla is not capable to upgrade to quantum as it seems. They did not even upgrade to Gecko 52.
10:51:42 <tortoisedoc> in both cases, you need a new api
10:51:45 <tortoisedoc> (qml)
10:51:49 <leszek> We are still using the outdated security nightmare Gecko 38
10:52:02 <DylanVanAssche> That's my concern too @leszek
10:52:12 <tortoisedoc> which one is the least work? quantum or qtwebengine?
10:52:52 <leszek> tortoisedoc: qtwebengine. Because you only need to base your work on what Qt does already and just ship a qml api for the existing C++ one
10:53:29 <leszek> qtmozembed needs a big rewrite for newer gecko/quantum engine
10:53:30 <DylanVanAssche> Adapting the Sailfish.Webview QML API (and extend it) to QtWebengine
10:53:33 <jpetrell> my gut says quantum would be less work since we have gecko with 100 use cases integrated
10:53:36 <tortoisedoc> leszek : I guess the qtwebengine might have a (somewhat limited) qml api?
10:53:42 <jpetrell> to os services, hw features, etc.
10:53:48 <flypig> Except QTWebEngine doesn't have the graphics pipeline stuff, if I understood.
10:54:05 <tortoisedoc> quantum would be tops
10:54:16 <leszek> tortoisedoc: yeah you can create a webview and load a site. Thats basically everything. No javascript, cookies, image loading and whatnot support
10:54:23 <DylanVanAssche> Yeah Quantum would be nice too
10:54:33 <tortoisedoc> (assuming it runs well on mobile, that is)=
10:54:41 <leszek> I highly doubt that quantum can be ported that easily
10:55:16 <jpetrell> e.g. even the old gecko has support for many web technologies (background services, camera, etc.), but they are disabled since the integration work has not been done.
10:55:19 <tortoisedoc> leszek: you mean to mobile?
10:55:42 <leszek> tortoisedoc: in general to the existing qtmozembed
10:55:47 <tortoisedoc> (I dont know if there's quantum mobile version)
10:55:53 <leszek> yes there is
10:56:00 <leszek> but mobile not mobile does not matter much
10:56:04 <Mister_Magister> why not both
10:56:09 <tortoisedoc> qtmozembed is the current wrapper for the gecko?
10:56:16 <leszek> afaik
10:57:08 <leszek> Mister_Magister: I doubt Jolla has the ressources. They did not have enough ressources to port newer gecko in the past.
10:57:19 <ApBBB> is there a chance for quatnum gecko in sfos?
10:57:27 <Mister_Magister> leszek: fair point
10:57:40 <jpetrell> we have updated the gecko engine couple times, and there is always proto version of the next update candidate
10:58:20 <DylanVanAssche> So there's a Gecko 4X variant alive some where?
10:58:21 <tortoisedoc> jpetrell : 100 cases as in testing?
10:58:21 <jpetrell> hiring is one bottleneck currently, we need to find good, resourceful embedded linux developers
10:58:28 <Mister_Magister> quantum really seems better option imo
10:58:30 <leszek> The problem I see currently if Jolla does not concentrate on one webengine being the default in SFOS 3 we will get a crappy 3.0 release with outdated browsing technology which will embarrass Jolla
10:58:36 <tortoisedoc> Mister_Magister : +1
10:58:45 <Mister_Magister> tortoisedoc: less ram usage xD
10:58:58 <tortoisedoc> Mister_Magister : m0ar cpu crunching :D
10:59:05 <DylanVanAssche> Leszek +1
10:59:08 <Mister_Magister> hmmmm xD
10:59:19 <leszek> quantum is not the better option as qtwebengine/blink is the defacto standard when it comes to webbrowsing as billions of android devices use it
10:59:26 <tortoisedoc> of course power might be an issue
10:59:35 <leszek> and even iOS uses webkit which is a cousin of blink
10:59:51 <Mister_Magister> leszek: the best thing about standards is that there are so many to choose from
10:59:52 <jpetrell> we have been working on deprecating the ancient qtwebkit, it is not far
11:00:01 <tortoisedoc> leszek does webkit feed qtwebengine ?
11:00:08 <tortoisedoc> (in upstreaming i mean)
11:00:25 <leszek> tortoisedoc: no
11:00:42 <DylanVanAssche> If QtWebkit is deprecated then it will be replaced I hope (for 3rd party devs) ?
11:00:49 <tortoisedoc> leszek : Its not much of an asset then :(
11:01:10 <jpetrell> I need to go, but thanks for the interesting talk :)
11:01:24 <tortoisedoc> eh the only jolla guy leaving? :P
11:01:35 <Jaymzz1> DylanVanAssche: Just keep in mind that there is 5 minutes left of the requested time :)
11:01:35 <leszek> So my guess if qtwebkit will be deprecated the oldish gecko with Sailfish.WebView component will be used. Not much of an upgrade then I would say
11:02:07 <DylanVanAssche> Jaymzz1: 5 minutes is fine
11:02:12 <Jaymzz1> good :)
11:02:22 <Mister_Magister> tortoisedoc: Jaymzz1 is jolla guy aswell xD
11:02:39 <tortoisedoc> Mister_Magister : and probably others too i hope :D
11:02:40 <DylanVanAssche> No not really an upgrade but Jolla should focus then: QtWebengine or Gecko
11:02:53 <leszek> Also keep in mind the security aspects. hardening lipstick is fine but when you ship an outdated webbrowser engine that every app should use with Sailfish.WebView then I am not sure this is the right way
11:03:12 <tortoisedoc> leszek : yes good point
11:03:19 <tortoisedoc> but there's one more dimension here then
11:03:23 <tortoisedoc> a) the stock browser
11:03:24 <Mister_Magister> leszek: +1
11:03:26 <tortoisedoc> b) the component
11:03:32 <DylanVanAssche> Browsers are pretty for attackers :)
11:03:34 <leszek> and I am beeing honest here. There must be a reason Jolla did not update gecko in the past
11:03:56 <tortoisedoc> ideally it should be the same, but can you guarantee compatibility with all the apps (whatever is going to be chosen)? I doubt
11:04:35 <DylanVanAssche> As soon as QtWebkit is deprecated, a lot of apps where a webview is used will be useless until the dev updates it
11:05:00 <Mister_Magister> tortoisedoc: if you make good enough api? why not
11:05:08 <leszek> Ideally when using Silicia.WebView they simply replace this with the gecko variant and no one needs updating :P
11:05:24 <leszek> though its a hit or miss
11:05:28 <tortoisedoc> Mister_Magister : lets stay in the land of the righteous, no hacks :P
11:05:41 <DylanVanAssche> Indeed, but that component isn't available though for devs (or difficult to get)
11:05:42 <Mister_Magister> tortoisedoc: hmm?
11:06:13 <tortoisedoc> how many apps use the Silicia.WebView
11:06:31 <DylanVanAssche> AFAIK 3rd party devs: none
11:06:43 <Jaymzz1> DylanVanAssche: you sure you don't ned more time? ;)
11:06:47 <Jaymzz1> need*
11:06:49 <tortoisedoc> thats (pardon my french) "good" news
11:06:53 <leszek> Anyway I find the lack of communication of Jolla in terms of security disturbing. The browser is one important component. And not communicating what actually is the plan for SFOS3 is something frightening
11:07:05 <tortoisedoc> leszek : yep
11:07:15 <DylanVanAssche> Jaymzz1: no, we should discuss this later
11:07:21 <Jaymzz1> alright then
11:07:24 <Jaymzz1> moving on
11:07:25 <leszek> tortoisedoc: webcat uses it, lls vplayer and some others
11:07:35 <Jaymzz1> #topic Long standing email bug status and solution (asked by ApBBB – 10 min)
11:07:42 <Jaymzz1> #link https://together.jolla.com/question/97109/email-imap-idle-doesnt-work-with-both-connections-active/
11:07:49 <Jaymzz1> #info A long standing bug that has been reported a long time ago and hasn't been resolved yet. Dcaliste was able to rep it and give info others did the same and no solution yet. Jolla needs to step in.
11:08:43 <Mister_Magister> psss: jolla doesnt care xD
11:08:47 <ApBBB> i have brought this thing up many times (in the last 3 years) and still no solution. many reproduced it dcaliste gave info no solution yet.
11:08:49 <Jaymzz1> ApBBB: this is AFAIK under investigation, but due to the amount of work we have had with paid customers, we haven't been able to move forward with it and execute a solution
11:09:16 <ApBBB> Jaymzz1: it affect all cutomers i believe.
11:09:29 <ApBBB> email is an important component
11:10:28 <tortoisedoc> you could almost say email is the only thing that can be used properly on the jolla (almost)
11:10:33 <Jaymzz1> I absolutely agree, but that's as far as I know and can comment. If any other sailor here wants to comment further, you are more than welcome! (ping jpetrell abranson lbt and others )
11:11:10 <flypig> Is anyone aware of what the root issue is (and, whether it's easy/hard to fix)?
11:11:48 <Mister_Magister> tortoisedoc: true
11:12:06 <ApBBB> flypig: you can find in the comments of the tjc thread
11:12:20 <tortoisedoc> the thing is, if jolla doesnt care, usually it can be taken care by the community; is this the case here?
11:12:34 <ApBBB> damien caliste investigated it but last time i asked him he was into other stuff (pgp etc)
11:12:44 <Mister_Magister> tortoisedoc: is email app opensource? i dont think so
11:12:51 <tortoisedoc> then the answer is not
11:12:54 <tortoisedoc> *no
11:13:08 * Mister_Magister what about opensourcing stuff hmm?
11:13:25 <ApBBB> i'd like to see the email app open sourced also
11:13:32 <ApBBB> but thats not the topic here
11:13:48 <Mister_Magister> sry :P
11:14:03 <flypig> Or, if not open sourced, could access be made available for others to fix, under NDA?
11:14:26 <tortoisedoc> +1 flypig
11:14:33 <tortoisedoc> free labor :P
11:14:46 <ApBBB> tortoisedoc: people that care
11:14:51 <flypig> Yes, but we'd benefit ourselves :)
11:14:57 <ApBBB> and not many companied have that
11:14:57 <tortoisedoc> flypig : +1
11:15:44 <ApBBB> Jaymzz1: you can move it on. if there are no people from jolla to comment there is not much else to be said
11:15:51 <tortoisedoc> I guess the only way this could work would be for jolla to have people come over to their offices, work supervised on given hw, and move out with nothing :D
11:16:04 <lbt> fwiw this isn't an area I know about
11:16:09 <Jaymzz1> I'll wait a couple of more minutes, if there were no comments, I'll move on to general discussion
11:16:15 <flypig> tortoisedoc, why not do it by contract?
11:16:27 <tortoisedoc> flypig : too much hassle to setup?
11:16:27 <jpetrell> we have nda for community contributors for giving access to e.g. email repo, all help is welcomed
11:16:51 <tortoisedoc> ApBBB did you hear now get to work :P
11:17:03 <flypig> jpetrell, could you provide a link, or quick explanation of how that works?
11:17:03 <ApBBB> tortoisedoc: i am no coder
11:17:16 <tortoisedoc> :(
11:17:25 <lbt> flypig: that may be a good question for another meeting
11:17:34 <ApBBB> if they need ui/ux work i am cheap :P
11:17:38 <flypig> lgt: agreed :)
11:17:45 <tortoisedoc> lbt, jpetrell that should be in the dev site
11:17:50 <tortoisedoc> (mentioned I mean)
11:17:54 <jpetrell> gecko upgrade, calligra upgrade, Bluetooth, Gallery albums support, new IM Messaging service integration, Calendar Agenda view, thread view for Mail app, etc. contact me if you are interested in helping :P :)
11:18:31 <tortoisedoc> jpetrell: I guess gecko upgrade (qtmozembed) is public ?
11:18:38 <ApBBB> we should also put this on TJC
11:18:45 <jpetrell> yes, even the UI part Browser app
11:19:27 <Jaymzz1> #info if any community member is interested in helping, please contact jpetrell
11:19:42 <Jaymzz1> ApBBB: shall we move on? :9
11:19:45 <Jaymzz1> :) *
11:19:49 <ApBBB> yes
11:19:53 <Jaymzz1> #topic general discussion (10 min)
11:20:25 <ApBBB> how is sfos3 comming along?
11:21:03 <tortoisedoc> +100
11:21:11 <Mister_Magister> i have seen python-solv updated in mercore but its not installable because of old libzypp. will python-solv make it to sfos 3?
11:21:16 <Mister_Magister> or next update?
11:22:37 * Mister_Magister sees dead people
11:22:48 <abranson> generally if you see things updated and tagged in the repos, they'll be coming in an upcoming release
11:23:08 <Jaymzz1> ApBBB: It's coming along well actually, can't say exactly what stage we are at of course but it's being worked on as we speak alongside the XA2 release
11:23:50 <Mister_Magister> abranson: but how can it come if its not installable
11:23:50 <ApBBB> i am waiting for a compact device. until then i hope my j1 wont die :/
11:23:51 <jpetrell> I was just testing device that was running qt 5.9 upgrade. we have feature branch for new UX features, which are actively worked on
11:23:59 <Mister_Magister> abranson: oh you updated it xd
11:24:12 <abranson> Mister_Magister: yeah there's a libzypp/zypper update pending too
11:24:38 <Mister_Magister> abranson: nice i was trying to compile scout today to have cnf
11:24:52 <Mister_Magister> abranson: what about adding cnf to mercore then?
11:24:53 <ApBBB> btw does anyone notice connection issues (4g) with the latest stable?
11:25:02 <Jaymzz1> ApBBB: I do too
11:25:31 <Mister_Magister> abranson: cnf would be super useful and its compiling already so i cant see reason why jolla counldnt maintain it
11:27:02 <Mister_Magister> abranson: what do you think about that?
11:27:06 <pketo> Mister_Magister: cnf?
11:27:16 <Mister_Magister> pketo: command-not-found
11:27:28 <Mister_Magister> you type cnf vi and know from what package it comes
11:27:45 <Mister_Magister> then you can install that package
11:28:14 <Mister_Magister> i mean i can compile it myslef (like i did) and put it on openrepos once update is out but there is really no point in that
11:28:17 <tortoisedoc> cool
11:28:20 <Mister_Magister> jolla could maintain it
11:28:31 <tortoisedoc> it should be in mer, its usefull
11:28:36 <Mister_Magister> yeah
11:29:07 <Mister_Magister> https://build.merproject.org/package/show/home:mister/scout it compiles already just requires new (incomming in next update) libzypp
11:29:14 <Guest85043> Christel just posted this "denial" on the freenode blog https://freenode.net/news/spam-shake Why does this blog post mention "10.2 million" THREE times?
11:29:17 <abranson> we generally don't carry cmdline utils things - e.g. bash completion scripts and man pages tend to get dropped during build. it's not the focus of a mobile os.
11:29:38 <Mister_Magister> abranson: cnf would be useful
11:29:39 <abranson> but it would be a great util to have installable from somewhere else
11:29:45 <abranson> yeah i'd use it
11:30:00 <Mister_Magister> abranson: can you ask jolla guys about adding it?
11:30:03 <tortoisedoc> it could be in mer-tools?
11:30:20 <abranson> well, that's what I mean. I think it would be a no for including in sfos.
11:30:31 <IntPtr17> Christel just posted this "denial" on the freenode blog https://freenode.net/news/spam-shake Why does this blog post mention "10.2 million" THREE times?
11:30:41 <Mister_Magister> abranson: could you ask anyway?
11:30:47 <Mister_Magister> pretty please?
11:30:48 <abranson> i think you just did :)
11:30:55 <Mister_Magister> abranson: well…
11:31:00 <Mister_Magister> i think it should be there
11:31:05 <Jaymzz1> time is up people, wrap up the conversation :)
11:31:09 <Mister_Magister> people sometimes need use terminal and it would be easy for newcomers
11:31:19 <Mister_Magister> Jaymzz1: i have no power here sadly
11:31:38 <Jaymzz1> I have the power, and I'll move on soon ;)
11:31:54 <Mister_Magister> Jaymzz1: and i have no power to make abranson's mind :P
11:31:59 <Mister_Magister> so yeah go ahead
11:32:04 <Jaymzz1> #topic next meeting time and date (5 min)
11:32:42 <Jaymzz1> So next meeting can potentially be held on August 23rd at 08:00 UTC but unfortunately I'm on vacation by then. So if we have someone that could chair, we will have the meeting, otherwise it'll be postponed.
11:32:57 <Mister_Magister> Jaymzz1: maybe sledges :P
11:33:13 <Mister_Magister> havent seen him in a while
11:33:18 <Jaymzz1> yeah if he is available by then, of course! I'll talk to him and will email you all.
11:33:41 <Jaymzz1> Mister_Magister: He's been on and off and very busy when on. I rarely contact him too because he's very busy
11:34:01 <Jaymzz1> Alright so we will say like this:
11:34:02 <Mister_Magister> Jaymzz1: dont even talk about very busy xD whole jolla is very busy all the time
11:34:18 <flypig> I prefer the later time, just in case you were thinking of sticking to it ;)
11:34:35 <Jaymzz1> #info next meeting will be held on August 23rg at 08:00 UTC if a suitable chair was found. If not, we will postpone it a bit.
11:34:39 <Mister_Magister> whatever +!
11:34:40 <Jaymzz1> flypig: is that so?
11:34:45 <Mister_Magister> +1*
11:34:50 <Jaymzz1> let me discuss this then
11:35:13 <Jaymzz1> but so far we can say like that, if anyone wants the new time to continue let me know as well
11:35:46 <Jaymzz1> but anyhow, thanks all for your contributions today, meeting minutes will be sent to you shortly!
11:35:50 <Jaymzz1> Bye :)
11:35:53 <Jaymzz1> #endmeeting