09:00:39 <sledges> #startmeeting Sailfish OS, open source, collaboration – 4th April 2019
09:00:39 <merbot> Meeting started Thu Apr  4 09:00:39 2019 UTC.  The chair is sledges. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:39 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:00:45 <sledges> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2019-April/008573.html
09:00:51 <sledges> I am the meeting's chairperson today, and will be doing my best to keep in time and in order. Please behave, respect the timings and behave gently.
09:00:58 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with # info
09:01:18 <schmittlauch[m]> #info schmittlauch, community member
09:01:31 <sledges> #info Simonas Leleiva - privateer for Jolla
09:01:36 <Coolgeek> #info Coolgeek, community member
09:02:00 <ViGe> #info Ville Nummela - sailor@Jolla
09:02:02 <chriadam> #info Chris Adams, developer at Jolla
09:02:05 <birdzhang> #info BirdZhang, community member
09:02:07 <flypig> #info David Llewellyn-Jones, sailor @ Jolla
09:02:10 <ced117> #info Cedric Heintz, community member
09:02:16 <kimmoli> #info Kimmo Lindholm - community
09:02:23 <dcaliste_> #info Damien Caliste, community
09:02:36 <lbt> #info David Greaves, Sailor and the Mer guy (for a little longer anyway!)
09:02:51 <M4rtinK> #info Martin Kolman - community & modRana
09:03:05 <lpotter> #info Lorn Potter, ex-privateer lurker
09:03:37 <jvd_> #info Tommi Keisala - community
09:03:39 <veskuh> #info Vesa-Matti Hartikainen, program manager at Jolla
09:04:00 <pketo> #info Pami Ketolainen, sailor @ Jolla
09:05:16 <karry_> #info Lukas Karras, community, developer
09:05:48 <sledges> nice lot today!
09:05:49 <sledges> #topic Security plan for native and android apps (15 min - asked by Coolgeek)
09:05:54 <sledges> #info Is there any plan to provide some permission system for native and android apps?
09:06:12 <sledges> #info Answer from Jolla: As communicated in our Sailfish 3 plans, we've been working on a new security architecture. In this work we've done studies on the architecture and technology choices.
09:06:24 <sledges> #info We've continued on this work on several tracks and we've been working with SELinux to provide necessary enablers to have a more fine grained security for the system. This is the work that is continuing and could be one of the building blocks needed for us in future to build a permission system for the native apps.
09:06:25 <taupan1> #info Friedrich Delgado, not sure if I belong here ;)
09:06:48 <sledges> #info For Android apps our new runtime will be giving user more control on the permissions of the apps and the use of Linux containers allows us to better control Android runtime. This is a big topic and there is a lot of work for us to do, so we can't go too much into details yet as a lot of it is still being designed.
09:06:49 <chriadam> welcome :-)
09:08:03 <sledges> Coolgeek: are you happy with the current answer or have more questions?:)
09:08:22 <Coolgeek> will this be in all realease or only for XA2 ?
09:08:26 <Coolgeek> (native and android)
09:08:45 <schmittlauch[m]> If looking at what's going on in Mer GitLab, SELinux integration of the native Sailfish OS system is being worked on https://git.merproject.org/mer-core/mapplauncherd/merge_requests/11
09:09:07 <schmittlauch[m]> although it looks like progress, at least the public parts, has stalled a bit
09:09:08 <M4rtinK> it seems to me that for native apps the Flatpak permission model could be a good start
09:09:25 <veskuh> M4rtinK: That idea is being considered
09:09:40 <M4rtinK> rather than reinventing a new thing
09:09:47 <M4rtinK> veskuh: cool!
09:09:58 <schmittlauch[m]> And securing apps and services is only a precondition for implementing a permission model on top
09:10:56 <veskuh> Coolgeek: For native we’ll be pushing is as much devices as possible, for some kernel version might be issue but too early to say.
09:11:02 <schmittlauch[m]> M4rtinK: AFAIK the sandboxing possibilities provided by Flatpak are rather sparse and primitive
09:12:00 <schmittlauch[m]> I'm not really convinced that they're a good choice for such an integrated system like Sailfish OS.
09:12:09 <M4rtinK> schmittlauch[m]: sure, though I think its continuously being improved
09:12:34 <Coolgeek> is there a roadmap for this ?
09:12:39 <flypig> schmittlauch[m], there are snaps and other similar approaches too.
09:12:40 <schmittlauch[m]> But I could also be missing the possibilities for extending Flatpak or integrating new portals there.
09:12:51 <M4rtinK> schmittlauch[m]: and multiple companies and Linux distros are working on Flatpak
09:13:33 <schmittlauch[m]> flypig: snaps rely on AppArmor, which is currently not a viable choice for Sailfish as it conflicts with SELinux used in the Android base system
09:13:42 <M4rtinK> it simply seems unlikely to me Jolla can pull of  "better Fkatpak" by themselves
09:14:25 <r0kk3rz> we usually disable selinux
09:14:32 <sledges> flatpaks would certainly have to be installed under /home, and not under / :)
09:14:46 <flypig> schmittlauch[m], that's interesting to know, thanks. I thought snaps relied on SELinux though.
09:15:11 <M4rtinK> extending Flatpak with the necessary enhancements for Sailfish OS seems like a good idea to me & thats how FOSS collaboration is supposed to work :)
09:15:12 <schmittlauch[m]> M4rtinK: While desktop linux distros and Sailfish share many similarities, they also have a different profile of requirements
09:15:17 <veskuh> Coolgeek: We haven’t announced roadmap, like mentioned in the answer this is a big topic and a lot of it still needs designing.
09:15:29 <chriadam> flypig: read that doc which was pasted in the etherpad.  schmittlauch[m] did a large amount of research which is hopefully going to inform our roadmap
09:15:31 <Coolgeek> thought so, btw thanks for the answer :)
09:16:01 <schmittlauch[m]> r0kk3rz: Yes, for now. But (see the MR I linked to) SELinux is going to be active in the future
09:16:04 <flypig> chriadam, schmittlauch[m], thanks, will do!
09:16:12 <dcaliste_> chriadam: can you remind here the etherpad uri ?
09:16:20 <chriadam> dcaliste_: internal sorry
09:16:25 <dcaliste_> Ah ;)
09:16:38 <M4rtinK> schmittlauch[m]: I *think* the Librem people are also considering Flatpak (if their device ever gets released is another question)
09:16:57 <schmittlauch[m]> If folks are interested, I got a public version of my work I did for Jolla and could publish that.
09:17:02 <lbt> chriadam: I can't easily see a link to that doc
09:17:12 <lbt> ah
09:17:16 <sledges> 3 more minutes
09:17:24 <schmittlauch[m]> But it is just basic research of ideas and architecture options, no concrete choices.
09:17:40 <r0kk3rz> schmittlauch[m]: could be an interesting read
09:17:44 <dcaliste_> schmittlauch[m]: if it's possible to have it public, yes why not.
09:17:58 <dcaliste_> Not really my topic, but interesting to learn new things.
09:18:14 <dcaliste_> Particularly if they come one day on device...
09:18:30 <schmittlauch[m]> M4rtinK: first of all, FlatPak is a packaging format. Sandboxing is integrated but may not have received the highest attention so far. chriadam had some nice ideas for permission management though.
09:19:17 <M4rtinK> schmittlauch[m]: thats indeed correct :)
09:19:51 <schmittlauch[m]> But I'm confident that sailors will make a good decision when evaluating Flatpak
09:20:04 <M4rtinK> (and the packaging/runtime bits is what I personally see as the biggest benefit Flatpak can provide to Sailfish OS)
09:20:51 <sledges> time to move on
09:21:27 <sledges> #topic Sailfish OS/Mer merger (answered by lbt - 30min)
09:21:43 <sledges> #info Discussing the merger that is happening between Sailfish OS and Mer.
09:22:25 <sledges> #link https://blog.jolla.com/message-in-a-bottle/
09:22:37 <lbt> So I hope you have all seen https://blog.jolla.com/message-in-a-bottle/ and the follow up on tjc:  https://together.jolla.com/question/203114/discussion-thread-merging-mer-and-sailfish-os/
09:22:43 * sledges can't help but singing the Police song
09:22:49 <lbt> haha
09:22:53 <m4g0g> lol
09:22:53 <sledges> #link https://together.jolla.com/question/203114/discussion-thread-merging-mer-and-sailfish-os/
09:23:46 <schmittlauch[m]> #info (for previous topic): Here's the public version of my study on SELinux and MAC I did for Jolla last year https://files.orlives.de/pub/PublicpartofSELinuxMACresearch.pdf
09:24:08 <sledges> #info (link to previous topic, sorry):
09:24:11 <sledges> #link https://files.orlives.de/pub/PublicpartofSELinuxMACresearch.pdf
09:24:25 <sledges> (pls continue that in generic discussion)
09:25:07 <lbt> So I hope there's plenty of information in the announcements
09:25:25 <lbt> and some expanding in the TJC replies/comments too
09:26:16 <schmittlauch[m]> Is it planned to integrate non-middleware projects (like Sailfish-office and the browser) into the new OpenSailfish – or however it is going to be named – or will that remain just the middleware like mer was?
09:26:17 <r0kk3rz> any more announcements about infra?
09:26:18 <lbt> Something I think I could have emphasised more is that this also brings the 'source-y' part of SailfishOS more into the community
09:26:28 <r0kk3rz> what of mer obs?
09:26:47 <M4rtinK> r0kk3rz: +1
09:27:12 <lbt> schmittlauch[m]: there is no  new OpenSailfish :) Sailfish OS is the same and the open packages will (we expect) continue to grow
09:27:39 <lbt> infra...
09:27:43 <ApBBB> lbt: what packages are you expected to be opened?
09:27:47 <mal> r0kk3rz: if you have checked it was rebranded already
09:28:01 <schmittlauch[m]> lbt: well, no name change then. I just remember the discussions about how to name it back then (:
09:28:20 <lbt> The infra isn't being changed significantly - some redundant things will go away (like the wiki)
09:28:45 <lbt> and we'll probably get rid of the image builder which hasn't really been used since 2012
09:29:03 <lbt> the obs is still there - you may have noticed the front page has changed
09:29:09 <schmittlauch[m]> Were there some other companies building upon Mer and how have they reacted to this?
09:29:19 <lbt> and so has the favicon (wooo- I'm a graphic designer now!)
09:29:19 <r0kk3rz> ok, so obs remains obs, good :)
09:29:48 <schmittlauch[m]> While Jolla has been the main contributor and sponsor for a while, this could still be seen as tighter company control.
09:29:53 <lbt> ApBBB: this change doesn't affect our ongoing (slow) open-sourcing
09:30:31 <r0kk3rz> schmittlauch[m]: i dont see how, all people with any influence in the project are all jolla employees
09:30:33 <schmittlauch[m]> lbt: Tell me more about whether there's something ongoing :D (in General discussions)
09:30:34 <ApBBB> schmittlauch[m]: anyone can fork.
09:30:46 <lbt> schmittlauch[m]: I'm not aware of any other companies using Mer over the past several years
09:31:23 <schmittlauch[m]> lbt: AsteroidOS and the Plasma folks had some small companies behind them
09:31:40 <r0kk3rz> asteroid doeant use mer
09:31:45 <dcaliste_> lbt: as schmittlauch[m] mentioned, if git.merproject.org becomes git.sailfishos.org, will you move all sailfishos from github.com to this gitlab ? It would make sense.
09:31:49 <r0kk3rz> neither does plasma mobile
09:32:21 * lbt sees the question seems answered :)
09:32:27 <schmittlauch[m]> r0kk3rz: Plasma active/ mobile once did. Aout Asteroid I might be wrong though.
09:32:30 <m4g0g> There is info about plasma and mer in wiki
09:32:41 <M4rtinK> it seems to me that both Nemo and Mer never did enough time and money investment to get going enough by themselves, so no self sustaining community ever formed & it was not interesting for others to build on top of
09:33:01 <lbt> M4rtinK: well I'm not sure I'd agree
09:33:05 <m4g0g> https://en.wikipedia.org/wiki/Mer_(software_distribution)#Products_based_on_Mer
09:33:17 <schmittlauch[m]> my question is answered then
09:33:29 <lbt> for a few years there was enough interest to make Mer a sane standalone project
09:33:34 <M4rtinK> which is unfortunate, as all looked quite nice back in early 2013 with lots of Jolla developers participating
09:33:47 <lbt> however we've all moved on and evolution has worked it's magic
09:33:58 <M4rtinK> but thats off topic I guess :)
09:34:43 <lbt> I think Mer has succeeded incredibly well and has enabled an alternate commercially succesful and viable OS
09:34:44 <schmittlauch[m]> Some years ago there was an initiative among all libhybris based mobile distros to build a common hardware abstraction base. Does anyone remember the name? Because if that's still alive, I wonder whether it can be relevant for Sailfish
09:34:46 <ApBBB> if you dont control the HW any attempt in mobile isn't going to be top notch.
09:35:03 <sledges> schmittlauch[m]: Halium
09:35:36 <lbt> dcaliste_: github repos...
09:35:51 <lbt> so this merge in itself doesn't impact the github repos
09:36:14 <schmittlauch[m]> sledges: Ah, yes. From their website: "Mer should be adaptable to use Halium."
09:36:15 <M4rtinK> ApBBB: at least more hardware is supported by upstream kernel these days, making the situation somewhat better
09:36:16 <lbt> now that we have git.sailfishos.org then it may be seen as a suitable home - it may not
09:37:27 <schmittlauch[m]> lbt: Was there some form of community steering in Mer? If yes, will there be something like this as well in the new merger or is the answer against company-only control "just fork it"?
09:37:27 <lbt> dcaliste_: which were you thinking of?
09:37:30 <ApBBB> M4rtinK: modem drivers and GPUs are the main issue. There have been some stuff in mesa lately but i doubt those are going to be used in SFOS or any other mobile os.
09:37:57 <schmittlauch[m]> Don't have any strong opinions on it, but just remember similar things in other projects.
09:38:09 <dcaliste_> lbt: https://github.com/sailfishos contains a lot of FOSS parts for SailfishOS.
09:38:16 <lbt> schmittlauch[m]: many years ago we tried to setup a meritocratic steering group for Mer. In the end it all fell to me and stskeeps. Nowadays I'm the caretaker
09:38:32 <lbt> What we do have is clarity around the code maintainers
09:38:50 <M4rtinK> yeah, Fedora has some FESCO and other distros similar things
09:38:51 <lbt> and we have got non-jolla people (or maybe person?) in there
09:39:00 <schmittlauch[m]> Can only sailors become maintainers?
09:39:16 <lbt> schmittlauch[m]: so ... no :)
09:39:40 <r0kk3rz> theres me, and dcaliste_ in the maintainers.yaml
09:39:42 <lbt> although I'm not sure if we ended up hiring them ... so be careful if you start maintaining some code :D :D
09:39:52 <lbt> r0kk3rz: ty
09:39:56 * M4rtinK thinks he.might be maintaining Python due to Pyoterhside being in the same maintainer group :)
09:40:01 <abranson> r0kk3rz: M4rtinK in python too
09:40:03 <sledges> isn't M4rtinK there too for Python?
09:40:10 <abranson> https://git.merproject.org/mer-core/Maintainers/blob/master/maintainers.yaml
09:40:23 <r0kk3rz> there you go, 3 non jolla people
09:41:11 <lbt> dcaliste_: yes https://github.com/sailfishos has no Maintainers file so it could be better. Personally I'd move it all to one place but we need to justify the effort
09:41:53 <dcaliste_> lbt: it's really important indeed, just avoid to have two places to check for code.
09:41:58 <schmittlauch[m]> dcaliste_, lbt: but I guess libhybris will stay separate, right?
09:42:40 <lbt> yeah - we may clone it but we work on that a lot directly
09:42:56 <lbt> dcaliste_: a topic for another meeting? (srsly)
09:43:01 <r0kk3rz> what about mer-hybris github repo?
09:44:20 <dcaliste_> lbt: why not. I can propose (but not for next time, won't be available in 15 days).
09:44:27 <lbt> r0kk3rz: so that's part of the sailfish porters effort which is quite well established. There are pros and cons to moving it so I doubt it will happen
09:44:48 <lbt> dcaliste_: please do
09:45:35 <sledges> 5more mins
09:45:52 <lbt> another area that we should *start* to think about is bug tracking
09:45:56 * lbt ducks
09:46:05 <dcaliste_> lbt: I'm putting a reminder to myself for next-next meeting.
09:46:05 <sledges> (me 60more minutes)
09:46:15 <lbt> sledges: ha ha
09:46:19 <ApBBB> lbt: make the internal bug tracker public?
09:46:38 <lbt> There will be a discussion thread starting in tjc about it and I hope lots of discussion in a future meeting
09:46:40 <r0kk3rz> lbt: havent we discussed the options here already?
09:46:46 <lbt> ApBBB: that won't happen :)
09:46:55 <abranson> there was a lot of discussion about it at fosdem
09:47:02 <lbt> r0kk3rz: we have begun discussions
09:47:04 <ApBBB> lbt: i expected that :D
09:47:11 <schmittlauch[m]> AFAIK Jolla Bugzilla already has different visibilities for internal and customers. So sailors are at least used to taking care of visibility
09:47:24 <lbt> now the Mer bug tracker is being retired there is no open code bug tracker
09:47:32 <sledges> #info The merger brings the 'source-y' part of SailfishOS more into the community
09:47:35 <sledges> #info The infra isn't being changed significantly - some redundant things will go away (like the wiki)
09:47:38 <lbt> schmittlauch[m]: too risky - won't happen
09:47:44 <sledges> #info we'll probably get rid of the image builder which hasn't really been used since 2012
09:47:44 <schmittlauch[m]> but yeah, please provide a powerful bug tracker for devs and tech-savy people
09:47:57 <sledges> #info the OBS is still there - you may have noticed the front page has changed
09:48:07 <lbt> schmittlauch[m]: so I commented in tjc about my feelings on that
09:48:11 <abranson> schmittlauch[m]: open bug trackers need to be open from the start - it's impossible to verify tens of thousands of bugs to check which ones can be made public or not
09:48:16 <r0kk3rz> idk, maybe i didnt look hard enough but i dont think mer bz was being effectively used
09:48:40 <lbt> ie use bz .. but it's complex due to the need to interact with internal bz and not add overhead to sailors day-2-day lives
09:48:52 <lbt> r0kk3rz: mer bz was never used very well
09:48:58 <schmittlauch[m]> lbt: K, your decision. I can understand that you want to keep the DB and software separated
09:49:08 <sledges> #info Whether to move github.com/sailfishos/* to git.sailfishos.org is a debate for next next time (dcaliste will post a question in 4 weeks time)
09:49:13 <M4rtinK> abranson: just mark all bigs as private before you open your Bugzilla instance
09:49:20 <r0kk3rz> lbt: yeah, so i dont think its going to be missed, aside from BOSS stuff for updating packages
09:49:20 <abranson> one possibility might be to mirror externally visible bugs from a launch date forward, keeping the bug numbers the same?
09:49:23 <lbt> M4rtinK: it won't happen :D
09:49:39 <lbt> abranson: indeed - that kind of thing
09:49:42 <abranson> M4rtinK: that would destroy with the internal visibility
09:50:07 <lbt> but we do acknowledge that we need to talk about this ..,
09:50:22 <m4g0g> Time to general discussion?
09:50:29 <M4rtinK> jolla employee group will of course see private bugs
09:50:32 <lbt> I have no idea if we'll end up with a bug tracker or just develop tjc...
09:50:38 <lbt> so lets talk :)
09:50:51 <M4rtinK> so I dont really see an issue really :)
09:51:07 <schmittlauch[m]> lbt: Let's look at how well you managed to update askbot to a recent version 0:)
09:51:22 <r0kk3rz> burn tjc for the plague pit that it is :)
09:51:23 <M4rtinK> schmittlauch[m]: +1
09:51:24 <lbt> M4rtinK: risk and other stuff will stop it
09:51:35 <sledges> lbt: external contributors should have a bugref in commit message, but if mer bz goes away, the only way to do this is for the maintainer to put an annotated tag with internal JB#...
09:51:36 <abranson> M4rtinK: the internal bug tracker has more than just jolla employees in, and uses visibility settings to manage that
09:51:46 <lpotter> r0kk3rz: +1
09:51:53 <mal> M4rtinK: it's too easy to make simple mistake in visibility and show some confidential information to the whole world
09:52:18 <lbt> and those mistakes can be made by partners who would blame Jolla... so ... not going to happen
09:52:25 <mal> yep
09:52:27 <schmittlauch[m]> I think it indeed makes sense to differentiate between interested non-techy end users (TJC) and devs or techies (bugtracker). Mixing both will hurt both groups.
09:52:40 <lbt> schmittlauch[m]: I agree
09:52:41 <dcaliste_> sledges: that's a good point. Some time I was using TJC#123456
09:52:51 <ApBBB> TBH as long as bugs reported on TJC are fixed quickly i don't mind whatever the solution is
09:52:52 <lbt> I think we'll have an invite-only tracker to start
09:52:55 <schmittlauch[m]> Easy interfacing between those two (eg the TJC-JollaBZ importer) are nice though
09:53:04 <M4rtinK> I can assure you there is much more criticsl data in bugzilla.redhat.com and it has been shared with Fedora just fine for more than a decade
09:53:09 <abranson> yeah, most public bugtrackers don't have many non-technical contributors
09:53:19 <M4rtinK> so I don't really take this :)
09:53:37 <schmittlauch[m]> M4rtinK: nice point
09:53:47 <m4g0g> Hi all, I am working now on google photo jolla account extenstion plugin and I want to find some connection points with jolla developers to integrate my work into google account in future. And I am interested in adding album selection for photo-sharing accounts(vk, google). How I can find this connections points or how I can create PR for this?
09:53:50 <sledges> dcaliste_: yep, TJC# is another option...
09:54:06 <sledges> m4g0g: please wait for general discussion
09:54:25 <sledges> M4rtinK: our parters will take such leaks seriously however, and would pull the plug in worst case
09:54:30 <abranson> M4rtinK: so partners never enter bugs with the wrong visibility, or reference them?
09:55:11 * sledges gives 5more minutes
09:55:22 <M4rtinK> there are of course also partner bugs and groups in bugzilla.redhat.com - again, don't know about any issues in practice
09:55:46 <M4rtinK> abranson: don't remember any such cases
09:56:25 <M4rtinK> I thin their accout simply creates them private and visible only to their group and redhat
09:56:30 <M4rtinK> by default
09:57:41 <sledges> another downside of mer bz going down is that all existing MER# refs will be lost
09:57:59 <lbt> sledges: I don't think it's going away
09:58:05 <sledges> then i misread
09:58:07 <abranson> M4rtinK: maybe the difference is that the redhat tracker had been open since the start. I can see it being easier to bring people into an existing open tracker than make a closed one open.
09:58:25 <lbt> it may be closed for new bugs but the VM and url will stay around
09:58:42 <M4rtinK> also comments can be set to private and only visible to redhat group, so you can comment on public/partner bugs for other developers with possibly internal stuff if needed
09:58:47 <sledges> thanks understood the "retired" part:)
09:58:58 <dcaliste_> lbt: cool
09:59:15 <M4rtinK> abranson: yep, thats the only thing I see as different
09:59:15 <sledges> M4rtinK: still too thin an ice in Jolla's use cases
09:59:17 <schmittlauch[m]> lbt: I hope someone will take care of still updating the VM
09:59:20 <lbt> same goes for git.merproject.org - dual access
09:59:36 <lbt> schmittlauch[m]: err, of course ...
09:59:44 <schmittlauch[m]> just saying
09:59:46 <M4rtinK> but I wonder if it still validates all the pain and friction of the current system :)
09:59:59 <sledges> ok, let's move it:)
10:00:06 <abranson> M4rtinK: yes, and I think it's the real sticking point. you can't force customers to accept something like that
10:00:07 <sledges> #topic General discussion (10 mins due to overtime;)
10:00:07 <M4rtinK> yep
10:00:09 * schmittlauch[m] really needs to bite his tongue about a joke on Russian partners and thin ice
10:00:34 <sledges> m4g0g, go!:)
10:00:37 <m4g0g> Hi all, I am working now on google photo jolla account extenstion plugin and I want to find some connection points with jolla developers to integrate my work into google account in future. And I am interested in adding album selection for photo-sharing accounts(vk, google). How I can find this connections points or how I can create PR for this?
10:01:09 <sledges> chriadam perhaps? ^
10:01:35 <dcaliste_> m4g0g: contact jpetrell on IRC or by email, explaining your project.
10:01:59 <chriadam> 1) in jolla-settings-accounts we have setup for which scopes are requested during account sign in.  presumably you'd need to add scopes there
10:01:59 <dcaliste_> He may propose you to sign an NDA to access the closed source parts.
10:02:22 <chriadam> 2) in jolla-gallery there are some extension plugins e.g. for facebook / vk currently.  can add one for gphotos
10:02:39 <m4g0g> dcaliste_ I have done this 2 weeks ago and haven't got any answer
10:02:41 <chriadam> 3) as dcaliste said, will need NDA/contributor agreement for access to those currently closed source components
10:02:46 <chriadam> so need to ask jpetrell.
10:02:59 <dcaliste_> lbt: sorry one question about previous topic, should we change remotes now in git to point to git.sailfishos.org?
10:03:03 * lbt suggests that maybe this is a topic by itself for a future meeting? That way sailors would have time to find an answer.
10:03:13 <lbt> dcaliste_: both work
10:03:36 <dcaliste_> m4g0g: be patient it sometimes takes time ;)
10:03:38 <lbt> there may be issues with webhooks not being set up though
10:03:54 <schmittlauch[m]> regarding "closed parts": Is there anything new to report regarding the "slow further open-sourcing" lbt just mentioned, especially since the efforts from last year?
10:04:12 <M4rtinK> schmittlauch[m]: +1000
10:04:31 <M4rtinK> anything, even for show ;-)
10:04:31 <chriadam> veskuh: ^
10:04:33 * lbt goes to make coffee
10:04:45 <ApBBB> any updates on allowing what is needed so we can have pure maps in the store?
10:05:04 <schmittlauch[m]> to veskuh: I mean the efforts from January 2018, if you know what I mean
10:05:05 <ApBBB> this fragmentation in store/openrepos is bad
10:05:05 <m4g0g> chriadam I know how to do this all but I interesting in itegration with jolla instead of creating separate package with google photo account. There is template for picasa in google account but it doesn't work
10:05:27 <M4rtinK> ApBBB: +milion
10:06:07 <chriadam> m4g0g: yep, need access to the internal repos to do it properly I think.  as mentioned, speak to jpetrell.  once you have access, speak to me if anything is unclear.
10:06:40 <m4g0g> Thank you. Will wait answer from jpetrell
10:07:02 <chriadam> schmittlauch[m]: from my perspective, not much progress has been made on the open-sourcing front, unfortunately.  I personally hope that the branding change will open up the path for open sourcing more components, but that remains to be seen.
10:07:02 <ApBBB> or nay progress to the dreaded email connection bug?
10:07:27 <ApBBB> opening the email would be nice
10:07:29 <m4g0g> or any progress on updating ALL fodler in imap
10:07:30 <chriadam> ApBBB: flypig, dcaliste_ and pvuorela investigated and fixed recently
10:07:39 <dcaliste_> ApBBB, flypig fixed it.
10:07:47 <ApBBB> chriadam 3.0.4???
10:07:54 <ApBBB> hopefully?
10:07:58 <chriadam> yes, should be 3.0.4
10:08:01 <dcaliste_> m4g0g: I'm partly on it
10:08:02 <chriadam> I believe
10:08:03 <ApBBB> weeeeeeeeeeeeeeeeeeeeeeeeeeeee
10:08:15 <schmittlauch[m]> I also hope that Jolla's customers finally make up their mind about GPLv3, not only for Qt but also for gpg and coreutils' sake.
10:08:18 * ApBBB gives flypig a cookie
10:08:29 <flypig> Thanks ApBBB :)
10:08:41 <lbt> schmittlauch[m]: questions generally get a better answer if pre-proposed (hint!)
10:08:44 <ApBBB> flypig: internet cookie so you have to accept and stuff :P
10:09:01 <flypig> Ha ha. I'd prefer a real one, but okay :)
10:09:04 <chriadam> and you can track his movements in the future :-P
10:09:07 <M4rtinK> schmittlauch[m]: yeah, I don't think a GPLv2 userspace is really maintainable any longer
10:09:51 <schmittlauch[m]> lbt: I DMed james about it whether it even makes sense to ask. You know, confidential knowledge from my Sailor time. But got no response, and lbt brought this up today
10:10:00 <M4rtinK> with upstreams often no long supporting the outdated GPLv2 versions
10:10:17 <m4g0g> dcaliste_ it's perfect. 6 years waiting for this =)
10:10:31 <ApBBB> BTW any talks for supporting other Xperia devices (hint smaller)
10:10:47 <dcaliste_> Well, not done yet ;)
10:10:57 <schmittlauch[m]> If someone wants to have nightmares, look at the gpg version used in Sailfish and think about the implications of exposing it to arbitrary input due to planned mail client integration.
10:10:59 * schmittlauch[m] shudders
10:11:17 <sledges> ApBBB: community can incorporate another xperia themselves following https://sailfishos.org/wiki/DRAFT-Sailfish_X_Xperia_XA2_Build_and_Flash
10:11:25 <dcaliste_> m4g0g: But I pushed some weeks ago a MR in nemo-qml-plugin-email to clean code for it.
10:11:34 <dcaliste_> I need to propose a UI to Jolla for this now.
10:11:48 <r0kk3rz> someone was looking into xz2 compact
10:12:12 <ApBBB> sledges: the thing is that a not officially supported device is a no go for me.
10:12:16 <schmittlauch[m]> lbt: But if you think it makes sense, I can propose a GPLv3 discussion for a next meeting
10:12:32 <lbt> that's another topic too
10:12:42 <sledges> ApBBB: there was a very successful attempt by heroic_1 on porters, if it is properly integrated (with LVM etc), such similar could become a candidate for officialising
10:13:06 <ApBBB> i am not skillfull when it comes to code and if the dev behind the port changes priorities you end up with problems?
10:13:07 <sledges> things taken into account would be the adoption rate (how many users would actually buy a device)
10:13:32 <ApBBB> sledges: which device did heroic ported to?? xz2C??
10:14:39 <ApBBB> dcaliste is it possible to also
10:14:43 <schmittlauch[m]> I know there's nothing official from Jolla about it, but are some community folks around here interested in the new fxtec slider phone as well?
10:14:48 <ApBBB> aww
10:15:31 <m4g0g> Why jolla doesn't want opensourcing or publish exmaples of accounts? It is potentially can dramatically improve socializing this OS
10:15:51 <sledges> ApBBB: Xperia X performance, XZ, and XZs: https://github.com/marina-bay/droid-config-sony-tone/tree/sfos-3.0.1.11-android-8.1/rpm
10:16:14 <sledges> ok, please convert unanswered questions into topics for next meeting:
10:16:15 <sledges> #topic Next meeting time'n'date (short)
10:16:22 <r0kk3rz> m4g0g: probably accounts running under root or something like that
10:16:36 <sledges> next meeting 08:00 UTC 18th April 2019, yay or nay? :)
10:16:48 <r0kk3rz> sledges: i say nay!
10:17:03 <sledges> ok, 10 more minutes to find a yay ;P
10:17:07 <lbt> yay
10:17:33 <sledges> that's a yay from me
10:18:04 <sledges> any more naysayers? ;)
10:18:23 <schmittlauch[m]> ok-yay
10:18:28 <m4g0g> r0kk3rz no. Only one problem - strange way to store keys which can be added only by hand, as I understand all right
10:18:50 <sledges> #info Next meeting: 08:00 UTC Thursday 18th April 2019
10:19:17 <sledges> thanks all, now let's let our Finnish and other same-timezone peeps to have their missed lunch:)
10:19:20 <sledges> #endmeeting