09:00:57 #startmeeting SailfishOS, Open Source, Collaboration 5th of September 2016 09:00:57 Meeting started Mon Sep 5 09:00:57 2016 UTC. The chair is Jaymzz. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 09:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 09:01:09 #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2016-September/007390.html 09:01:22 I am the meeting’s chairperson today and will be doing my best to keep time and order. Please behave, be gentle and show due respect. 09:01:37 We have 2 topics today to go through. Let’s keep it in time 09:01:50 #topic Brief introduction (5 minutes). Please prefix your name/handle with # info 09:02:10 #info James Noori, Community Manager 09:02:16 #info chriadam / Chris Adams / UI and middleware developer for Jolla 09:02:34 #info Lewis Rockliffe - Community 09:02:55 #info Simonas Leleiva, hw&l10n@jolla 09:03:01 #info schmittlauch, interested community member, probably just reading 09:03:05 #info Raine M�kel�inen, browser, ui, middleware developer for Jolla 09:03:21 #info Tommi Keisala, community 09:03:31 #info abranson / Andrew Branson / middleware dev for Jolla 09:03:31 #info Leif-Jöran Olsson, community 09:03:34 #info Pekka Vuorela, developer at Jolla 09:03:38 #info André Walker, community member 09:03:43 #info Vesa-Matti Hartikainen, Program Manager at Jolla. 09:04:20 #info Damien Caliste, community member 09:04:52 #info Pami Ketolainen, developer @ Jolla 09:05:06 #info Dylan Van Assche, SFOS developer 09:06:19 Alright, glad to see you all here! We shall now move on to the first topic of today: 09:06:40 could someone @op merbot ? Stskeeps ? 09:06:58 lbt: ^ 09:07:07 #topic CalDAV bugs - request for contributors (10-15 min, asked by chriadam) 09:07:22 nice timing! ^-^ 09:07:27 #info There are a variety of bugs in the CalDAV sync adapter (https://git.merproject.org/mer-core/buteo-sync-plugin-caldav) which are difficult for me to test and fix for a variety of reasons (access to servers of correct versions, different language issues, internal company prioritisation, etc), which I would love to see some community contributions for. The bug numbers are: MER#1500, MER#1569, MER#1623, MER#1624, MER#1625 (see e.g. 09:07:28 https://bugs.merproject.org/show_bug.cgi?id=1624). So, this topic is basically reaching out to the community to see if some person or persons would be willing to help investigate these issues and hopefully provide fixes. I can provide information on how to get started, how to get more debug output, and so on, to help reduce the learning curve as much as possible. Aside from fixing bugs directly, I'd really like to have unit tests added 09:07:28 which can test the discovery and xml parsing codepaths - so a series of "expected response for given request" xml files would be extremely useful. 09:07:28 Mer bug 1624 in buteo-sync-plugin-caldav "CalDAV sync with Synology can fail due to requiring discovery support" [Task,New] 09:07:42 Thanks Jaymzz 09:07:44 Hi everyone :-) 09:07:49 #link https://git.merproject.org/mer-core/buteo-sync-plugin-caldav 09:07:59 #link https://bugs.merproject.org/show_bug.cgi?id=1624 09:08:22 As per my intro, name is Chris, I'm one of the developers at Jolla dealing with UI and middleware components. 09:08:25 sledges: I waited on purpose :P Thanks! 09:08:31 chriadam: You're most welcome! 09:08:38 One of the areas to which I've contributed is the PIM synchronisation area. Unfortunately, despite the fact that it's such an important area, we at Jolla haven't been able to give it as much in the way of development and testing resources as we would like. 09:08:42 hello :) 09:09:05 hi SfietKonstantin :-) 09:09:11 With this in mind, I wanted to raise the topic of CalDAV (and CardDAV) in a community meeting, to try to encourage community members to contribute, and going forward, to try to lower the barrier-to-entry for contributors in this area. 09:09:34 My goal for this meeting is to: 1) describe the type of help we want, 2) arrange a further meeting for us to discuss the specifics, 3) determine who might be willing to help. 09:09:55 For 1) we would like both technical (code contributions to fix bugs, unit tests) and non-technical (access to a variety of test servers and/or test data XML) contributions. If we have time, I can go into these in more detail at the end of the meeting. 09:10:28 For 2) I can make myself available at this time (0900 UTC) on Monday (or perhaps a different day, if there is strong preference from willing contributors) if we want to organise a regular weekly meeting. Further, I'm always accessible via IRC or email, and I am willing to give extensive help / coaching on how to get started with development and testing. 09:10:29 How we can volunteer? 09:10:56 And that brings us to 3): are there any brave souls who might be willing to help, and if so, in what capacity? 09:11:15 I could provide access to a baikal 1 server for testing purposes 09:11:16 can you setup a wiki page as well for the list of bugs / the areas that contributors are wanted etc. 09:11:26 SfietKonstantin: I can definitely do that 09:11:38 an idea can also to do offline automatic testing 09:11:44 via a CI or something like that ? 09:11:53 to reproduce tricky issues 09:11:56 elfio: at this stage, I guess I want a list of names / irc nicks whom I can contact 09:12:11 then from there, will send some emails, and, if it's desired, we can set up a weekly meeting 09:12:15 (or bi-weekly) 09:12:22 I would shure like to contribute for some of the tasks, but time constraints will restrict it heavily. 09:13:01 M-schmittlauch: a range of different server types (owncloud, cozy, synology, baikal, etc etc) need to be tested, so if any community member can provide one of those, that's very much appreciated 09:13:02 chriadam: I imagine you don't remember but I have some troubles with my owncloud caldav account which remain unsolved. I'd like to offer as many logs as I can provide. I cannot offer for now any developer time :p 09:13:03 chriadam: add me, but more as a watcher at this time. I'm interested in this issue, but at the moment, quite busy 09:13:20 elfio: there are a variety of outstanding issues, unfortunately 09:13:28 e.g., the bug list from mer's bugzilla (one moment...) 09:13:50 https://bugs.merproject.org/buglist.cgi?quicksearch=caldav 09:14:16 #link https://bugs.merproject.org/buglist.cgi?quicksearch=caldav 09:14:30 chriadam: we could also list a variety of test scenarios, like different types of alarms, on the wiki page. 09:14:45 M-schmittlauch: yes, good point - I will add that to the wiki page. 09:15:09 I guess the first concrete step is: if you're able to help, please send an email to chris dot adams at jolla dot com with your irc nick + the manner in which you might be able ot help 09:15:24 chriadam: you can count with my logs. In the very near future if don't get any job I'll be willing to learn to dev this 09:15:36 elfio: logs and such are definitely helpful 09:15:40 Jaymzz: maybe an #action tag to be set ? 09:16:10 Jaymzz: also, don't forget to publicize chriadam's wiki page on twitter 09:16:14 chriadam: If you need logs I guess it's better to set up another instance of the servers for testing purposes, isn't it? 09:16:17 #action if you're able to help, please send an email to chris dot adams at jolla dot com with your irc nick + the manner in which you might be able ot help 09:16:21 The second concrete step (personal action point for me) is to create a page on the sailfishos wiki, specifically for this topic 09:16:31 Sfietkonstantin: Thanks, sure 09:16:45 thanks :) 09:17:08 M-schmittlauch: that would definitely be best, but I don't want to try to bite off more than we can chew. even increasing our test-server-set size by 3 would be a 100% improvement. 09:17:30 (currently we test against fruux, memotoo, and yahoo, which covers three of the largest CalDAV implementations, but leaves a lot untested) 09:17:59 Ok, that's about it for my topic. If peopel are still around after this meeting ends, we can discuss specifics if you'd like to 09:18:08 otherwise, please send me an email and I will take it from there :-) 09:18:37 Alright, thanks chriadam! 09:18:43 if owncloud could be polished that would be a nice improvement: owncloud is a popular demand 09:18:44 chriadam: I would like to help also, for instance on iCal parsing issues. 09:18:58 dcaliste: I will definitely take you up on that. 09:19:26 Let's move on to the next topic and get back to this (if necessary) on general discussions topic. 09:19:37 :-) Thanks Jaymzz 09:19:47 #topic Security and authorization on SFOS (30 min, asked by Lucien Xu / Sfiet_Konstantin / SfietKonstantinW ) 09:20:03 #info  At the moment, there is no security, nor authorization frameworks. However, security and privacy on mobile device is an important topic. The major OSes all implement sandboxes to prevent malicious applications to do unwanted things. I would like to explore how to enhance the situation on SFOS, and how to proceed. This topic would be a discussion and a brainstorming about what the technologies involved (SELinux ? Polkit ? etc) and 09:20:03 how to collaborate between the community and Jolla to make it happen. 09:20:12 chriadam: You're welcome :) 09:20:42 SfietKonstantin: Your time to shine :P 09:20:58 So, the idea is to raise this "issue" to both sailors and community member 09:21:09 SFOS have often been advertized as being secure 09:21:28 however it lacks some security issues, like sandboxing or an authorization system 09:21:59 I remember that there were work being done on a SELinux based solution, but nothing more 09:22:32 And outdated version of another packages 09:22:46 yeah, this too, but that's a bit offtopic 09:23:54 to sailors: how important is this topic for you / Jolla / the Sailfish alliance 09:23:55 ? 09:24:20 Security is big and important topic. We are addressing this from many fronts. 09:24:39 can you disclose how ? 09:24:47 At the moment most activity is around getting the stack more up-to-date 09:24:50 ah ! 09:25:14 Then we will be doing key security enablers like improved bootup security & flashing. 09:25:26 veskuh: is special still working on an app security framework? 09:25:33 #info At the moment most activity is around getting the stack more up-to-date (regarding security) 09:25:35 And as features file system encryption and vpn support are being worked on. 09:25:46 Can we help in some ways ? 09:25:48 #info Then we will be doing key security enablers like improved bootup security & flashing. 09:25:51 r0kk3rz: Not at the moment. 09:25:59 r0kk3rz: I would even ask: is there anyone working on app security frameork ? 09:26:02 #info And as features file system encryption and vpn support are being worked on. 09:26:12 (that is what I'm trying to push ?) 09:26:36 if not, would you accept a solution coming from the community ? 09:27:00 Dear developers, please check pull requests on mer-core/perl repo. 09:27:05 has any consideration been given to FlatPak? 09:27:14 OhDaeto: save it for general discussion 09:27:29 SfietKonstantin: We know that there is need, and we have some plans but it is not being actively developed in next months so any contributions are welcome 09:27:45 veskuh: ok thanks :) 09:27:56 r0kk3rz: I personally would like to investigate Flatpak, going forward. I spoke briefly to Alex Larsson about it, just to get a better understanding for myself about how it works, and I think it'd be a good fit going forward, personally. But I'm not a security expert. 09:28:18 #info any contributions from the community are welcome 09:28:25 for community members: at the moment I'm working on getting an upgrate of polkit in mer-core, as well as updating the sailfish-polkit-agent 09:28:25 chriadam: yes at a cursory glance it looks like a good fit 09:28:27 SfietKonstantin: veskuh: my opinion is that if it is standards based, that would be better than something hand-rolled. I mean, SELinux support would be nice. 09:28:40 chriadam: I'm thinking SELinux too 09:28:49 and Flatpak for similar reasons. Effort spent in that direction would be well-spent I think. 09:28:50 but don't have enough experience to roll it 09:28:57 r0kk3rz, chriadam: something container-based like that would be a good fit, and easier to manage 09:29:12 SELinux -> think twice before going that route (my 2 cents) 09:29:13 chriadam: yep 09:29:16 https://git.merproject.org/mer-core/polkit/merge_requests/2 09:29:47 For upgrading polit, mozjs is required (https://git.merproject.org/mer-core/mozjs/merge_requests/1) 09:29:56 tortoisedoc: out of interest, why do you say that? and which alternative do you prefer (smack/apparmour/grsec/something else?) 09:30:03 and the packaging is a pain. If there are some packagers around, can they take a look ? :) 09:30:09 #link https://git.merproject.org/mer-core/polkit/merge_requests/2 09:30:23 SfietKonstantin: what does polkit do for us? where do we use it in our stack currently? 09:30:23 chriadam : i talk about experience with SELinux, and its the only one ive used, and i hate it :) 09:30:34 chriadam: I will also think about flatpak 09:30:42 chriadam: polkit is about the authorization part 09:30:48 chriadam : too complicated, requires recompilation of policies etc 09:30:50 being able to ask the user for accessing stuff 09:30:58 tortoisedoc: from application developer POV, or from system maintenance / policy development point of view? 09:31:00 * SfietKonstantin think about contacts db, GPS etc 09:31:19 and it is what Desktop linuces uses so, pretty standard 09:31:55 SfietKonstantin: do you mean that polkit is the standard mechanism on SELinux-based systems whereby the user can be asked for permission to change a per-application policy? 09:31:57 chriadam : both i'd say; very cumbersome to have to compile policies in order to install them (iirc some policies actually have to be recompiled and cannot be precompiled) 09:32:21 SfietKonstantin: want help with mozjs? can also test how my suggestions work. 09:32:36 tortoisedoc: thanks for your insights 09:32:40 pvuorela: I really want to test your suggestions, but not time at the moment :( 09:32:54 chriadam: it is a bit orthogonal to SELinux. You would use polkit to have nicer user interaction, and SELinux to protect access to privileged resources 09:33:20 Hrm. I wonder if we couldn't just come up with a simpler DBus API to do the same thing rather than use polkit, though, if it's just a UI interaction flow. 09:33:29 chriadam: not really about changing policy (you cannot with SELinux, IIRC), but about accessing those stuff 09:33:42 chriadam: Polkit is about a simple DBus API 09:33:51 it is light enough, and is integrated with other components 09:33:56 (systemd, packagekit) 09:34:05 so, IMO, a good fit 09:34:27 i hope doesn't make simple things complicated 09:35:05 Many people complains about SFOS isn't quiet developer frinendly ( due lack of stack exchange IMHO ) 09:35:16 but can be seen a deterrent 09:35:19 SELinux +1, my 2cc 09:35:42 dr_gogeta86: what do you mean about simple thinkgs complicated ? for devs ? Like the aegis thing on N9 ? 09:35:45 I think selinux integration in first moment can be used as auditing 09:35:55 dr_gogeta86: yep, that was also my idea 09:37:02 should we setup a wiki page for this topic as well ? 09:37:04 but needed to be sold as path to gain more power on devices ... for example launch a debian or fedora container without devel-su tricks 09:37:12 SfietKonstantin, for sure 09:37:24 I don't have rights to the SFOS wiki though 09:37:31 containers would be nice, but without selinux they domt really contain 09:37:36 we can still use Mer 09:37:59 Is flatpak like appimage/snap? 09:38:02 what I feel about the containers is that it is just a fancy word without mandatory access control 09:38:09 Yaniel: yes, but by red had 09:38:40 there are some differences, but I don't know which ones 09:38:41 need to be rashaped for our purpose ihmo 09:38:47 *reshaped 09:39:07 just like polkit / selinux etc. 09:39:25 First audit then think 09:39:54 this leads to another question 09:40:07 is SELinux enabled in the kernels distributed with SFOS ? 09:40:21 in the SDK / Jolla 1 / Jolla tablet / Jolla C / Intex ? 09:40:35 with selinux containers have somekimd of MAC, dont they?:) 09:40:38 I guess in my mind (not knowing enough about SELinux) my questions would be: 1) what is required to enable it? do most vendors support SELinux in their supported kernels? 2) what is required from Sailfish OS side to enable it without breaking everything? 3) going forward, what work is required to ensure that policies are updated appropriately? 4) how do we manage user interaction flows - I guess this can come last. 09:40:47 SfietKonstantin: it has no constraints on selinux: https://github.com/lbt/mer-kernel-check/blob/master/mer_verify_kernel_config 09:41:00 sledges, even on boot part ? 09:41:04 chriadam: a big selinux thing is that android uses it 09:41:12 #link https://github.com/lbt/mer-kernel-check/blob/master/mer_verify_kernel_config 09:41:20 sledges, even some hwadaptation needed 09:41:25 Jaymzz: correct link (pls #undo :) https://github.com/lbt/mer-kernel-check/blob/master/mer_verify_kernel_config 09:41:30 so interaction with android emulation becomes "not impossible" (in theory) 09:41:35 #undo 09:41:35 Removing item from minutes: 09:41:36 lbt: +1 09:41:46 #link https://github.com/lbt/mer-kernel-check/blob/master/mer_verify_kernel_config 09:41:50 lg g3 hal need to neuter selinux code in order to boot sfos 09:42:12 dr_gogeta86: neuter = nuke ? 09:42:13 dr_gogeta86: yes - but that's because sfos doesn't use it 09:42:18 atm 09:42:30 also bacon ( oneplus one , on kernel side got problems ) 09:42:45 lbt: how hard it is to enable it ? 09:42:49 ghar! post-holiday state: Jaymzz: https://github.com/mer-hybris/mer-kernel-check/blob/master/mer_verify_kernel_config 09:42:54 soz x) 09:43:04 SfietKonstantin: easy - but then nothing works right ... so :) 09:43:12 #undo 09:43:12 Removing item from minutes: 09:43:15 lbt: what do you mean by ... right ? 09:43:25 #link https://github.com/mer-hybris/mer-kernel-check/blob/master/mer_verify_kernel_config 09:43:35 sledges: No probs :) 09:43:47 SfietKonstantin: the real question is "how hard is it to get an selinux policy that allows full functionality and provides meaningful security benefits" 09:44:03 and the answer is "we don't know but hard" 09:44:15 lbt: I see, but can't you just start by having a null policy, or a very simple one 09:44:20 yes 09:44:23 and start in audit mode ? 09:44:31 so minimum impact ? 09:44:33 that is exactly what needs doing 09:44:35 this is work which someone will have to do 09:44:52 but bear in mind we should have some criteria in place 09:44:53 * SfietKonstantin can dig into policies 09:44:54 I don't know much about SElinux, but for AppArmor there's a possibility to enable it and just let it run in background, logging events and breaches of policies. 09:45:20 they may well evolve as part of the comprehension that comes with auditing (and the research that inevitably will be needed) 09:45:35 Sfietkonstantin: 5 minutes left on your topic mate :) 09:45:36 lbt: we can discuss those criteria by mail, or in another meeting maybe 09:45:39 M-schmittlauch: yes - iirc audit mode is the same 09:46:13 #info the real question is "how hard is it to get an selinux policy that allows full functionality and provides meaningful security benefits" : and the answer is "we don't know but hard" 09:46:33 as I'm a real kernel noob, can someone provide a SELinux enabled kernel for the SDK ? 09:46:50 dr_gogeta86: SfietKonstantin: lbt: yep, it's switched off in kernel since 4.4 android bases ( https://sailfishos.org/hadk ) 09:47:04 the SDK can be bricked and is rather easy to work with, so it can be a good target for testing SELinux 09:47:13 section 9.2.1 09:47:21 sledges: ?? but is it enabled in standard 4.4 androids ? 09:47:36 android uses selinux 09:47:51 but we don't boot android fully; worth asking #sfdroid folk too 09:48:04 SfietKonstantin: add that (emulator selinux kernel) to the bug/task list 09:48:05 it'd be interesting to see how android builds on top of SELinux the permission frameworkl 09:48:23 sledges: I see 09:48:30 lbt: ok, will do 09:48:48 SfietKonstantin: 2 mins :) 09:48:48 lbt: is it ok to add it in mer bugtracker ? 09:49:18 SfietKonstantin: yes - do a top level bug (a story) and add it as a blocker task 09:49:31 sledges: ok, thanks for the info, so something to take into account 09:49:51 remember there was alternatives to selinux and apparmor 09:49:55 #action log a bug in the Mer bugtracker: enable SELinux for the SDK kernel 09:50:09 dr_gogeta86: all of them need kernel modules right ? 09:50:11 like the bad mantained and bit closed GrSecurity 09:50:19 SfietKonstantin: emulator kernel 09:50:22 you can compile it builtin 09:50:22 smack is used in Tizen 09:50:28 #undi 09:50:31 #undo 09:50:31 AppArmor in Ubuntu 09:50:37 hey ! 09:50:42 I can't undo: ping Jaymzz 09:50:50 we can start with SELinux and see how it behaves 09:50:54 #undo 09:50:54 Removing item from minutes: 09:50:55 * dr_gogeta86 think about a famous The prodigy song 09:50:59 +1 09:51:13 #action log a bug in the Mer bugtracker: enable SELinux for the emulator kernel 09:51:24 but I think SELinux is the best target to begin with, for a variety of reasons. 09:51:47 the complexity of SELinux frightens me a bit though 09:51:48 thanks for your initiative there, SfietKonstantin. If anyone can help him with the investigation, please comment on the Mer Bug 09:51:57 Alright folk, time's up on this one! We're moving to general discussion in seconds 09:51:57 thanks :) 09:52:12 #action If anyone can help him with the investigation, please comment on the Mer Bug 09:52:13 chriadam : one more tought, is there anything about SElinux in android world that is absolutely bad? 09:52:15 chriadam: can we provide some resource to support a regular selinux community meeting too :) 09:52:27 as per caldav one 09:52:41 sure, I can make myself available - but I'm not a security or kernel person 09:52:53 veskuh: ^^ 09:52:55 so not sure whether someone else (markolem probably) would be better 09:53:33 Moving on :) 09:53:35 #topic General discussion (15 minutes) 09:53:39 lbt: I’ll ping markolem IRL 09:53:58 Any news on harbour being available for ports? :) 09:53:59 in the meantime, we can use SFOS dev mailing list 09:54:05 elfio, +1 09:54:11 elfio, +10! 09:54:28 Jolla opensourced recently the webview from the sailfish browser as a plugin: https://github.com/sailfishos/sailfish-components-webview/tree/master/components 09:54:32 Ok. Dear developers, please check pull requests on mer-core/perl repo. 09:54:38 In the last meeting someone told here that it would be some advance in the near future iirc 09:54:47 someone who can put me on the right track to use it an app? 09:55:07 #link https://github.com/sailfishos/sailfish-components-webview/tree/master/components 09:55:11 pketo: ^-^ 09:55:22 modulebaan: that's still very much Work In Progress 09:55:54 pvuorela : https://bugs.merproject.org/show_bug.cgi?id=1645 09:55:54 Mer bug 1645 in libcontentaction "defaults.list always overrides default app for mimes" [Major,New] 09:55:57 modulebaan: we're working through a variety of issues (including crashes, etc) - so you're more than welcome to try it, but we're not supporting it at this stage. Going forward, we will - hopefully by the end of this month we will have all of the issues sorted out. 09:56:04 pvuorela: ? 09:56:21 oh ok :) if I'm not wrong, that webview is the same code as the one used in the Sailfish browser? 09:56:24 yes, I'm working on the store for ports enablers, but it has been delayed by other stuff 09:56:34 #link https://bugs.merproject.org/show_bug.cgi?id=1645 09:56:50 pketo: Ok. Thanks! Anyway community can help on this? 09:56:55 Is it easy to recompile the kernel for Jolla1? I'm having issues with tmux inside a systemd-nspawn container and I'm afraid it's a missing kernel option causing it. 09:57:19 modulebaan: correct, it uses the qtmozembed (gecko-based) renderer 09:57:20 M-schmittlauch: which kernel option? 09:57:30 tortoisedoc: some problem that triggers? 09:57:37 modulebaan: one sec, will pastebin some code to get you started 09:57:38 elfio: not really, as it is all in our closed store backend side 09:57:51 Sage: phew, it's been a while since i had a look into it. 09:57:51 chriadam: I tried to compily the Sailfish browser but I can't add the repo with new versions of those components... 09:58:01 pketo: ok! 09:58:04 pvuorela : any default set by the user (for example via xdg-mime for the notes app) is independently overridden by whats in the defaults.list 09:58:12 modulebaan, more alignments will be done so that we could share more code between SF browser and WebView 09:58:20 ill add a repro example 09:58:21 https://github.com/sailfishos/sailfish-browser/issues/478 09:58:28 pvuorela : ^ 09:58:40 OhDaeto_: perl, oh man :) i think it's those packages that trigger rebuilding everything so needs quite a lot of caution. should upgrade anyway sooner than later and preferably to even newer. 09:58:43 #link https://github.com/sailfishos/sailfish-browser/issues/478 09:58:55 #info General comment. lbt is working on getting mer-core updated (again/still). This should help with development on public OBS. 09:59:09 lbt : what's the chances to get the QtPurchasing in mer core? 09:59:23 lbt: \o/ 09:59:25 lbt : Ive got a building package (for sailfishos target) 09:59:28 tortoisedoc: feel free 09:59:57 lbt : its there, but how to "promote" it into mer-core? 10:00:00 we still have the (dead) chum stuff and sfos targets are up-to-date (I think .. sledges?) 10:00:07 (i pushed the "promote" button btw) 10:00:12 tortoisedoc: ah completely different question 10:00:18 modulebaan, need to check & update instructions. Also situ (community contributor) could probably help 10:00:24 Sage: I suspect it was something about /dev/pts 10:00:26 How many peoples here got jolla C / intex and wanna some toh or bumpers ? 10:00:46 lbt : tbh im not even sure "promotion" is the correct thing to do :P 10:01:06 lbt : so feel free to tell me no :D 10:01:34 rainemak: Thanks for the update :) I would like to use the code base for a webapp since it's much more fluent then the current SilicaWebview. Maybe I can help the begin of implenting HTML5 Notification support 10:01:53 if I can build it 10:01:55 tortoisedoc: mer core has always been a core for commercial vendors to build devices. Realistically that's now Jolla. So the package list is mainly down to Jolla wanting this in the core so essentially persuade them. 10:01:57 pvuorela: Great! Big thanks for answer! 10:02:14 lbt : okay, who do i need to talk to then? 10:02:24 modulebaan: pastebin.com/0LpAqLq2 10:02:30 for basic example 10:02:32 tortoisedoc: the jolla Qt team ... 10:02:38 but yeah, you'll need updated qtmozembed etc 10:02:39 tortoisedoc: see maintainers.yaml 10:02:52 M-schmittlauch: CONFIG_DEVPTS_MULTIPLE_INSTANCES maybe? 10:02:52 #link pastebin.com/0LpAqLq2 10:02:55 lbt : maintainers.yaml in mer-core? 10:03:13 5 minutes left guys! 10:03:22 tortoisedoc: https://git.merproject.org/mer-core/Maintainers/blob/master/maintainers.yaml#L366 10:03:26 so w00t :) 10:03:32 XD 10:03:41 but oh look ... chriadam is on there and in this meeting ... :) 10:03:51 #link https://git.merproject.org/mer-core/Maintainers/blob/master/maintainers.yaml#L366 10:03:51 * chriadam hides 10:04:10 Sage: Yes, I was suspecting that. That at least would fix apt complaining about a missing /dev/pts. Regarding tmux I have to take a deeper look. 10:04:11 :D 10:04:20 chriadam : https://git.merproject.org/tortoisedoc/qtpurchasing 10:04:21 :) 10:04:24 tortoisedoc: raise it at the next community meeting I think 10:04:26 this in mer. now :P 10:04:31 now is meeting time :P 10:04:33 #link https://git.merproject.org/tortoisedoc/qtpurchasing 10:04:49 (for at least 120 sec, that is) 10:04:55 tortoisedoc: yeah - but also about giving people time to prepare a response 10:05:00 ah sure :) 10:05:01 :P 10:05:11 chriadam: Thanks! As soon I have the right repo I can build this :) 10:05:13 (i was focussed on the raising only :D) 10:05:42 how is the QtPurchasing license atm? and doesn't it require some kind of backend? 10:05:48 lgpl3 10:06:10 3 min left filks :-) 10:06:11 before the meeting ends, one last reminder: please email chris dot adams at jolla dot com if you're interested in helping with CalDAV/CardDAV testing/fixing/etc. 10:06:13 also I was busy earlier when the CALDAV was on (sorry chriadam). I think we can provide disposable VMs on the Mer infra to run test servers for CALDAV projects which we can let trusted community members manage. 10:06:21 pketo : yes it requires a backend, that is true 10:06:25 lbt: that would be fantastic 10:06:30 #action please email chris dot adams at jolla dot com if you're interested in helping with CalDAV/CardDAV testing/fixing/etc. 10:06:48 pketo: it seems to use Google play or App store for in app purchasing 10:06:50 chriadam: I would love an egroupware one :D 10:07:00 * lbt hides 10:07:11 M-schmittlauch: https://github.com/systemd/systemd/commit/b52a4a3b05a2a0d69868d57fd54f6e4b8fa0e7ca feel free to submit update to https://github.com/mer-hybris/mer-kernel-check 10:07:20 lbt, if you need some help 10:07:22 SfietKonstantin, pketo : others can be added 10:07:22 just ask 10:07:25 M-schmittlauch: it is not enabled by default as the check doesn' notify aobut it. 10:07:31 #link https://github.com/systemd/systemd/commit/b52a4a3b05a2a0d69868d57fd54f6e4b8fa0e7ca 10:07:34 SfietKonstantin, pketo : (and should, especially generic ones) 10:07:40 #link https://github.com/mer-hybris/mer-kernel-check 10:07:43 tortoisedoc: yep, but there is nothing in SFOS side at the moment 10:07:48 M-schmittlauch: same for CONFIG_NET_NS actually 10:08:04 dr_gogeta86: OK - we need to see what's what but yep. I'll probably wait for the subject to come up at chriadam's meetings. 10:08:15 SfietKonstantin : qtpurchasing is only one piece of the puzzle 10:08:22 tortoisedoc: yep 10:08:24 :( 10:08:29 M-schmittlauch: we have much older systemd though than where that comment came in, however it doesn't mean it is not needed in our systemd version :) 10:08:40 Sage, better s 10:08:41 yeah, so it's not just about dropping that in 10:08:44 Sage, better so 10:08:50 Sage: Is it safe & easy to recompile the Jolla1 kernel with these options? (Jolla1 is still my main every-day device) 10:08:51 SfietKonstantin : enabling library would mean at least increase probability for paid apps support (even if not from jolla) 10:08:59 true 10:09:14 tortoisedoc, we need users 10:09:41 Alright guys, time's up! 10:09:54 dr_gogeta86: how do you solve chicken and egg problem? you get either alot of chickens and roosters, or you get alot of eggs :) 10:09:59 M-schmittlauch: not so simple or safe tbh, but doable yes. However if you do that patch to fix the kernel check we might apply it later to the default deliveries though anyway. Saying might as haven't looked further on it yet 10:10:06 I liked this meeting. Thanks everyone! 10:10:16 dr_gogeta86: ie you need to start :P 10:10:21 thanks everyone :-) 10:10:21 elfio: Indeed, a very productive one :) 10:10:25 thanks :) 10:10:29 Moving to the next one now 10:10:33 thanks :) 10:10:37 I'm starting helping people flashing sfos on their devices 10:10:41 #topic: Next meeting time and date 10:10:41 thanks! 10:11:16 I propose 3rd of October, same time (0900 UTC) 10:11:20 suggestions anyone? 10:11:20 Sage: So I shall just open a pull request out of suspicion? Can do that if I don't have to feel bad for nat having tested it :) 10:11:30 Jaymzz: I like the date 10:11:32 morning is so much better than afternoon 10:11:39 tortoisedoc: +1 10:11:46 ok to me 10:11:51 then again, morning is relative :D 10:11:55 tortoisedoc +1 :) 10:12:03 True! 10:12:07 well, this same time of the day 10:12:30 alright let's get 2 more votes :) 10:12:39 +1 10:12:43 +1 10:12:47 done! 10:12:59 Probably not ok for me, but I guess I'm fine with reading logs 10:13:15 thanks lbt! 10:13:22 #info Next meeting will be held on Monday, 3rd of October 2016 at 09:00 UTC 10:13:24 (for the help with qtpurchasing) 10:13:36 Thanks everyone for joining this meeting, have a nice week ahead! 10:13:44 #endmeeting