09:00:04 #startmeeting Sailfish OS, open source, collaboration – 24th January 2019 09:00:04 Meeting started Thu Jan 24 09:00:04 2019 UTC. The chair is Jaymzz. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 09:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 09:00:07 #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2019-January/008535.html 09:00:17 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. 09:00:28 #topic Brief introduction (5 min). Please prefix your name/handle with # info 09:00:37 #info James Noori - sailor @ Jolla 09:00:57 #info Simonas Leleiva - privateer @ Jolla 09:01:07 #info Andrzej Lochowski = community member 09:01:10 #info Leszek Lesner - community & dev 09:01:12 #info Richard Booth - community 09:01:19 #info dr4Ke community member 09:01:24 #info Ville Nummela - sailor @ Jolla 09:01:34 #info eekkelund 09:03:44 #info Lewis Rockliffe - community 09:03:45 #info Pami Ketolainen - sailor @ Jolla 09:04:29 #info Simo Piiroinen - sailor at jolla 09:05:16 #info David Llewellyn-Jones - sailor @ Jolla 09:05:27 #topic Plans to extend Ambience capabilities (asked by atlochowski – 10 min) 09:05:40 #info Do you have any plans to extend Ambiences capabilities. For exaple vibration, to turn off/on interfaces. In 2014 your ex worker Jaakko Roppola said that you have plans to do that https://together.jolla.com/question/397/screenborder-swipe/?answer=9299#post-id-9299 . It's 5 year from that moment and you do almost nothing to implement this capabilities. From Sailfish 3 we have light Ambiences but we still can change vibration set 09:05:40 tings by Ambiences etc. If you have any plans to implement this do you have any ETA? At the MWC 2015 you presented devices with Sailfish 2 and it was possible to notice some options of Ambiences you never implemented in final release, for exmple this https://together.jolla.com/upfiles/1473418024193782.png 09:05:53 #link https://together.jolla.com/question/397/screenborder-swipe/?answer=9299#post-id-9299 09:06:03 #link https://together.jolla.com/upfiles/1473418024193782.png 09:06:17 #info David Greaves Mer guy and Sailor 09:06:42 #info Improving functionalities that ambiences provide is not high on our list of priorities. We've gotten mixed feedback on the whole concept and it need a rethought if we improve the current one or replace this with other solutions. 09:06:54 #info toxip - Sailfish OS Fan Club founder 09:07:41 atlochowski: Anything more on this? :) 09:07:43 you've gotten mixed feedback on the whole concept because in current form it's just some kind of profiles like in other OSes 09:07:59 there is no extra funcs in Ambiences 09:08:02 The wallpaper setting in ambiences is kind of annoying if you use landscape devices. Like it is randomly zooming into wallpaper and setting them. Would be nice if one could at least choose the area of an image to use as wallpaper 09:08:09 features like that is adequately covered by situations yeah? 09:08:36 Ambiences mixes with situation is something that people want 09:08:50 r0kk3rz: true. Situations is covering most of them. Would be nice to build that into the OS. Though I can understand it is a maintaining burden 09:09:29 its not just a maintaining burden, its also expending effort to screw over a third party developer for your system 09:09:39 of which there are few 09:10:02 so for now you don't have any plans to do anything wich Ambiences? 09:10:12 how is it screwing over third party devs? 09:10:17 ambiences the way they are now are a bit half baked and feel like half completeled or stopped middle in development. I think that is even worse than not having it at all. And this is of course giving mixed feedback. Or was the mixed feedback meant to be of a prototype offering the new features? 09:10:40 atlochowski: Not at the moment. As said, there are other priorities to be taken care of within the OS. 09:10:44 toxip: well, theres an app that add these features, if you make them native that persons app becomes somewhat useless 09:10:58 r0kk3rz: I don't think it is screwing over. It is a nice compliment to produce an idea so good that the OS is now implementing it directly 09:11:10 can Situations actually have the ambience switching as a trigger? 09:11:23 #info tadzik, Sailfish user and small-time developer 09:11:38 so I know everything I wanted, we can finish this topic or maybe someone else have other questions? 09:12:06 #info pisarz1958 - user & dev 09:12:09 We have 4 more minutes on this topics anyhow so feel free to discuss if there's anything :) 09:13:30 Can we at least get an API to query user-created ambiences? 09:13:42 Perhaps the need for ambience profiles has waned with the quick settings menu being so available... 09:13:55 tbf I'd rather have functionality in the core OS than needing to rely on apps to get it – just like I like that there's browsers in Store that aren't useless, but I'd still like the Sailfish Browser to not be forgotten and useless 09:14:27 thankfully we have a selection of not very good native browsers 09:14:36 I thought of an idea once were you could have like sort of "workspaces" in separate ambiances. An ambiance change would open a set of applications. 09:14:37 Does the existing ambience system provide suitable change notification (eg dbus) for Situations? 09:14:51 r0kk3rz: I would protest if you call my browser not very good :P 09:15:10 It's great that we are receiving feedback from the community right here, as it gives us an idea about what you guys want. That helps us decide better when it is actually time to bring the Ambiences up in the priority list. 09:15:10 leszek: you've done an amazing job with the limitations you have :) 09:15:55 Tim'es up for this one. Moving on :) 09:15:57 I'm wondering if it may be possible to dbus-publish information about an ambience change if that's not done already - but would that help ? 09:15:57 ambiences need some work that is true. But yeah it shouldn't be high on the priorities list when the browser situation is basically starting to burn SailfishOS to pieces 09:15:58 Jaymzz: I think given the scarce resources (iiuc), the nice compromise would be providing the app developers with adequate APIs so that they can fill in the blanks, possibly prototype the features for you :) 09:16:14 (see what I did there. Burning platform pun intended) 09:16:28 pisarz1958, could you elaborate on that API? 09:16:29 lbt: I think that'd be perfect for a "userspace" implementation for that kind of functionality (setting umbrellas) 09:16:30 tadzik: see my question ^^ 09:16:32 I know I'd use it :) 09:16:47 yeah - so maybe you could look and propose something more specific? 09:16:59 tadzik: Yes, that is a great idea :) I'm sure many other sailors see that as well ;) 09:17:02 (a settings umbrella, not the API itself) 09:17:15 that sounds easier for us to implement - a dbus event on change with useful info 09:17:16 I guess the Situations dev is the one to ask :) 09:17:19 ok seems like this topic needs a few more minutes, so not moving on yet. 09:17:40 tadzik: maybe you'd like to chase him/her? 09:17:47 lbt: can try 09:18:02 ty 09:18:11 lbt: who do I contact afterwards? 09:18:12 yes an api would be nice and offer the possibility to improve situations to do and test out the various crazy ideas we have 09:18:19 tadzik: bring it back here 09:18:29 okay :) 09:19:07 #info (to sailors) community wants an API to be made available for them. 09:19:27 Now we can move on :) 09:19:45 #topic: Mapping app situation (asked by ApBBB – 10 min) 09:19:58 #info The official maps app (here) on J1 sucks -is practically unmaintained and absent from newer phones- and we still don't have something native in the store while a solution developed by the community exists. When are we going to have a solution to that long standing issue. 09:20:19 And here comes the answer: 09:20:21 #info We are happy with the Here WeGo apk solution from our partner that is available from Jolla Store. We do at the same time acknowledge the need for fully native mapping app. However, it's quite big effort to implement fully native, fully featured solution, so we are not announcing any plans here today. In the meanwhile, there are community alternatives available and we hope that we could improve our harbour processes so that mor 09:20:21 e of them could be provided easily through Jolla Store. 09:20:41 ApBBB: What say you? :D 09:21:50 Jaymzz: you really need to work with rinigus to get pure maps into harbour, probably wont happen until after qt5.9 and new gcc, but any outstanding issues should be solved 09:22:01 the Here WeGo APK is proprietary? 09:22:19 being happy with here we go is one thing. (not a solution to me since i dont use android on my phone). there have been discussions about removing the blockers from the store so we can get the mapping solutions the community has in. however there was no progress to that. 09:22:25 r0kk3rz: That would be ideal! 09:22:28 kinda on topic: there's a basic, but competent Map component in QtLocation, perfectly usable by 3dparty apps. It's not however allowed in Harbour, as it's not an officially approved API. 09:22:45 I find it quite annoying that there's a readymade thing to use to make apps better, but Jolla goes "eh, no" when they see it 09:23:06 the Store version of my app just has a page that tells people to go and download the Storeman version if they want the proper experience, which is really stupid 09:23:07 Jaymzz: jolla has to help with getting pure maps in. 09:23:22 leszek: Unfortunately I don't know the answer to that :( 09:23:35 Maybe another sailor here knows? 09:23:58 Jaymzz: my contacts should be known and its easy to get in touch regarding technical problems 09:24:36 in short, qtlocation support is needed. ideally, with mapbox gl plugin enabled (needs newer gcc). 09:24:44 Jaymzz: is there at least a person in jolla rinigus can contact (or him contacting rinigus) so we can get this sorted out? 09:24:47 Unfortunately this is not the only case where great applications haven't made it to Jolla Store making Open Repos the go-to place for apps. But that's probably a topic for another time. 09:24:56 Essentially this is back to the limitations that harbour places on apps. Sadly there are good reasons for all of them. 09:25:33 #info (to sailors) we have an open opportunity to get in touch with rinigus (Pure Maps) after the needed assets from our side are in place. 09:25:55 if mapbox gl is not available, I can probably bundle mapbox gl qml plugin that I developed/ported from qtlocation. but the access to qtlocation is required 09:26:00 lbt: is there anyone that can help? 09:26:40 ApBBB: We have discussed it here and on tjc - there are often workarounds but we acknowledge they aren't ideal 09:26:44 as for offline maps, systemd activation (through libsystemd linking) is needed 09:27:40 there was discussion of dependencies before xmas - we probably should review that and keep tracking and pushing on it 09:27:59 hi 09:28:11 3 minutes to go 09:28:15 eg as rinigus points out - there was systemd activation included in that chat 09:28:22 lbt: can you get ti discuss it again with whoever responsible and bring us an update? 09:28:31 rinigus: So QtLocation is enough for online maps? libsystemd is needed only for offline maps? 09:28:39 lbt: great to hear. looking forward 09:29:01 ApBBB: yeah - it needs pulling back in as a topic and probably a *focused* thread on tjc 09:29:03 ;) 09:29:07 About the authorized Qt modules in harbour, we can hope that Jolla will reconsider the whilelist after 5.9 upgrade, so that we can use all the modules that will actually be available ? (Location, WebEngine, 3D, ...) 09:29:09 ViGe: yes. enough is a touch of a stretch, there is then still some work needed. 09:29:20 then pull in abranson etc 09:29:58 btw, to gain traction jolla must polish SDK (newer Qt and GCC, maybe also native SDK for linux host) and harbour (implement the missing pieces like reading comments on the web console, etc) 09:30:06 thebootroo: that has always been about Qt making it an official module 09:30:10 lbt: i'll open one. want me to make it be for mapping only or more general? 09:30:23 thebootroo: ping ViGe on SDK during general discussion 09:30:27 ... ideally, we should get mapbox gl plugin compiled in and then I should port pure maps to it from my custom plugin. latter part depends on me and would be of advantage in long term 09:30:37 ApBBB: I think it would be good to continue the pre-xmas discussion rather than a new one 09:31:08 then verify any solution is good enough to allow mapping 09:31:13 lbt: link to that? 09:31:19 rinigus: was the systemd lib use a workaround for not being allowed a systemd unit file? 09:31:25 thebootroo: why isn't maps an official module in Qt? 09:31:29 Time's up for this one. ApBBB How much extra time do you need? 09:31:38 maybe that's where some pressure should go? 09:31:56 Jaymzz: just a link to the disussion to bring it back and i am ok. 09:32:22 abranson: actually, making unit file is allowed as long as it is done in user space and users are notified about it. I need to have http activation and that required linking 09:32:47 JFYI: There are almost no new SailfishOS App Podcasts as mostly harbour has died out. Almost 0 new apps 09:32:57 rinigus: ah I see, thanks 09:33:13 lbt: it is, but in the current version jolla didn't allow it in harbour, dunno why 09:33:25 stuff is coming up on Warehouse though pretty strongly :) 09:33:27 ApBBB: the discussion was internal 09:33:31 thebootroo: oh - that's interesting 09:33:36 sledges: ok. 09:33:39 leszek: a good indication that harbour needs some löööve 09:33:54 I recently noticed some uni students publishing an app for diabetics. Looked neat, I wonder what stopped them from pushing it to Harbour... 09:34:00 i can't do muxh about it. if you or anyone feels like opening a TCJ thread be my guest 09:34:18 tadzik, Bluetooth is not allowed in Harbour. 09:34:42 Jaymzz: we can move on. 09:34:55 ApBBB: sure 09:34:55 aha. Not the first time it's stopping something useful from being officially accepted then :/ 09:35:12 #topic Fingerprint for ports (asked by piggz – optional: r0kk3rz – 15 min) 09:35:25 #info Porters would like to support the fingerprint sensors on their devices, but currently, the code is closed and device specific. If Jolla are unable to make it work generically, could they atleast provide template, bare-bones implementations / documentation on what porters need to develop to support this feature? 09:35:40 pisarz1958: oh, that's actually yours! :) Kickass 09:35:52 This answer has few parts. so hold on to your hats :P 09:36:00 #info Providing skeleton implementation + sufficient documentation to add meat to it = Bigger task than implementing a backend. Note that while related packages are device specific, the code within them is interface specific rather than device specific. So at least in theory, existing built-by-jolla binaries should/might work with porter devices too - provided that the device a) uses a supported interface (#1) , b) the implementatio 09:36:00 n of said interface is broken only in ways that can already be handled via quirk configuration (#2). 09:36:12 #info #1: 32 bit libhardware fp hal via libhybris, 64 bit libhardware fp hal via native android binary, binder ipc based fingerprint service 09:36:23 #info #2: We've not yet seen a fp implementation that would work "as expected", so *all* devices are probably going to need a quirk config. 09:36:38 piggz: Here you go :) the stage is yours 09:36:45 tadzik: thanks! 09:36:54 piggz isnt around, so i'll start talking 09:37:02 alright 09:37:20 from the porters perspective we dont need a perfect solution for all devices 09:37:41 we deal with all kinds of weird quirks all the time, so another one really isnt a big deal 09:38:10 we also do development on middleware, so once we understand the issues maybe we can get creative 09:39:12 these things look *really* quirky though :P 09:39:17 im sure 09:40:13 but personally i dont see any downsides to unleashing porters on it, even if the outcome is 'wow this stuff is impossible' 09:41:03 another one that has cropped up is also nfc support 09:41:08 Björn from Fan Club asks: Can the fp implementation be opened? 09:41:14 we need more bazaar and less of a jolla cathedral 09:41:27 but i see that the nfcd is open source on mer, so hopefully that is coming 09:42:12 r0kk3rz: the biggest problem is that fp stuff started off as closed source and open sourcing something that is closed involves all kinds of things 09:42:38 I was the person how asked. I think a open implementation would reduce the bourden for jolla and the commuity could improve it 09:42:47 Jolla should no better that starting projects as closed source is always the wrong way 09:42:56 at least by now they should know that 09:43:26 I love autocorrect :P *know 09:43:26 spiiroin: understood, at least thats an honest answer other than 'sorry, its too broken' 09:44:11 all i can say is help us to help you 09:44:25 If Jolla keeps doing the same mistakes in starting some closed source shit again and falling on its nose again I am out of here. Honestly that is soo stupid 09:44:39 leszek: some things need to be closed, this *used* to be such. but it also means the existing code base is closed 09:45:21 spiiroin: sorry this is bullshit. You decide if you want to do your code open source or closed 09:45:44 leszek: you are correct 09:45:53 provided it is your code to start with 09:46:06 leszek: not if you depend on other people (mfg oems base code from them etc) 09:46:14 5 min remaining 09:46:24 leszek: well, I'm not going to go into that 09:46:28 so the fp stuff is closed because of hardware vendor specific blobs 09:46:31 I remember the first fp support was on turing phone so being closed source was somehow related to that? 09:46:48 toxip: something like that 09:47:00 uff :( 09:47:09 the whole area we're in is on the border of open/closed and we try really hard to make stuff open 09:47:10 or did I just trigger a bunch of NDAs with this question 09:48:01 * abranson closes toxip's source 09:48:03 anyway, if somebody has a device where android has fp support, it might be possible to get it working in sfos 09:48:14 most likely it does require code tweaking 09:48:18 leszek: as individuals we argue internally to try to find workarounds - it's not always possible. But we keep trying and sometimes we get there even when we had to start in a closed place :) 09:48:36 * toxip is surprised pikachu 09:48:40 leszek: the backend of the android side is open source is on github 09:48:44 some of that can be analyzed / dealt with in irc 09:49:25 #info from spiiroin: if somebody has a device where android has fp support, it might be possible to get it working in sfos. most likely it does require code tweaking. some of that can be analyzed / dealt with in irc 09:49:27 I can imagine talking with ARM hardware vendors is some kind of limbo. They seem to be the devils of hardware keeping everything closed 09:49:40 yup - you have no idea :D :D 09:50:06 r0kk3rz: Anything else? time is almost up. 09:50:14 So conclusion we need to find some billionaires for Jolla to build their own hardware with open source drivers 09:50:28 spiiroin: is that an offer to help? 09:50:44 is vendor-sony-oss-fingerprint not the backend of the current fpd-slave? 09:50:59 leszek: we estimate 7-10 separate billionaires would be needed 09:51:01 r0kk3rz: it is, and has been given already earlier too 09:51:26 spiiroin: ok great, i'll see if i can find a victim, erm... a vollunteer 09:51:33 :D 09:52:10 Alright, I'm going to move on in a few seconds. 09:52:18 abranson: maybe even google solves this. I think they are trying to force devs to open source their drivers 09:52:33 leszek: that was for drm things 09:52:37 #topic Status of a bug in emails app. (asked by ApBBB – 5 min) 09:52:38 graphics 09:52:42 #link https://together.jolla.com/question/97109/email-imap-idle-doesnt-work-with-both-connections-active/ 09:52:46 treble definitely draws better lines 09:52:59 #info We've been doing many improvements to email with our partners over the past year, unfortunately the priority has been on features with exchage integration and we haven't had time to solve this issue. However, this issue might be on open source components of the email framework, so any help in debugging from community would be appreciated. 09:53:43 there has been "help" dcaliste did some and another guy in the comments of the TJC thread. 09:53:55 i can't help cause i cant code 09:54:15 and is an annoying issue. 2+ year old bug 09:54:35 has a tracked by jolla tag but no solution yet 09:55:09 ApBBB: True, and thanks for bringing it back to our attention. I'm sure this will accelerate the process of fixing the bug anyhow. 09:55:14 any comments from sailors? 09:56:13 Other comments from sailors? 09:57:27 It is indeed annoying. I was on the verge of writing my own email client as the current mail client is unusable for me. But I decided to not develop anything anymore for SailfishOS this year 09:57:50 if there is no comment from sailors we can move on. 09:58:17 I'll give it 1-2 minutes to see if anyone says anything. 09:58:20 has this not been investigated as suggested? 09:58:36 leszek: we need a chance to improve the current one. not rewrite everything. email should be an open app. 09:58:55 No that bug but other things like no embedded mail support or just idle for one folder 09:59:22 The email framework is quite open afaiui 09:59:52 its also a big thing for corporate clients that OMP might have, so i expect more improvements will come 09:59:54 lbt: has annoying layout issues. it works the opposite of every other app 10:00:01 ApBBB: how old is the email app. Plenty of time already ... :P Remember the UI improvements patch I did for it to make it look better? Nothing changed in the UI part. People are getting frustrated with the email app. I bet no sailor is using this as main mail mobile mail client as it is this shitty 10:00:45 ApBBB, what do you mean by "works the opposite"? 10:00:47 There is also a bug with it completely dying on longer threads, but I suppose that's more related to current browser situation on the platform. 10:01:14 and that is not the backend. The backend despite imap idle sometimes having issues. (Top Secret: syncing imap idle status is also struggeling issue on BB Hub and other famous mail clients) 10:01:20 flypig: to go to folders you swipe right to left 10:01:31 the backend is a good one 10:01:37 even though folders "include" the inbox 10:01:50 the UI is shit 10:01:59 leszek: and the backend is open - and isn't this bug a backend bug? 10:02:00 you should swipe "back" (left to right) 10:02:10 not to offend anyone who designed it. It needs a rework 10:02:27 ApBBB: Keep in mind that we are a few minutes over time. 10:02:30 lbt: yes its a backend bug and hard to fix. Imap Idle has issues on every mail client I know 10:02:58 OK - but we get a *lot* of pressure about opening things to fix bugs ... and yet... 10:02:59 ApBBB, thanks, that clarifies. I see what you mean :) 10:03:11 flypig: hope this is fixed also. 10:03:17 Jaymzz: we can move on. 10:03:24 alright, thanks 10:03:38 #topic Mer/Sailfish OS announcement from lbt 10:03:56 Ah yes ... 10:04:20 Happy New Year and welcome to 2019 and some changes in the Mer project 10:04:29 I am pleased to announce that once again the Mer Project has served its purpose and provided the foundation for a successful and open mobile operating system. 10:04:50 Last time this happened the Mer Project closed its doors and moved to supporting MeeGo 10:05:05 this time we're delighted that we're actually going to continue to operate. We'll be merging with SailfishOS.org :D 10:05:29 (I'll post a fuller announcement to TJC and the mailing lists soon.) 10:05:42 The main thing I need to sort out is handling the two sets of identities and I've been looking at ways to ensure that this is as smooth as possible. 10:05:53 We'll look at the services in Mer and which ones are used by the community - so please help by providing feedback on which of these you feel are valuable and why. 10:06:12 Announcement ends :) 10:06:35 So, on a high level, what will this cover in terms of currently Mer infra 10:06:44 mostly git, bugzilla, and obs 10:06:50 correct 10:07:08 git and obs will continue to operate 10:07:27 bugzilla needs a bit of a rethink 10:07:44 what about the merwiki? 10:07:57 we have tjc but that's not really a developer level tool 10:08:08 bugzilla hopefully not a tjc approach. That is ... a bit meh :/ 10:08:38 currently its quite annoying to see JB references in open components on mer, because i cant read the JB 10:08:42 we need a proper bugzilla. Gitlab hasn't a bug reporting thingy? 10:08:55 leszek: I personally favour a bugzilla but I also am not sure what useful stuff there is in the current one 10:09:12 there are gitlab issues, yes - that's a possibility 10:09:27 lbt: will there be something done about the Jolla Bugs in mer components? It would be great to see the refference to fixed bugs open. 10:09:55 r0kk3rz: as for the wiki - I'm not sure. It's not very well looked after nowadays 10:10:05 I've gone off wiki's :D 10:10:24 lbt: there are some pages that are used often 10:10:26 how will community contribute without a bugzilla if a strict requirement is to have "[tag] commit message MER#bugref"? 10:10:27 most is junk though 10:10:30 eg things like HADK should be written to be edited in git and then published 10:10:37 might be nice to see the ports list moved to the sfos wiki 10:10:58 abranson: I'd actually like to see a git->publish solution 10:11:01 abranson: sfos wiki is not editable by community 10:12:00 sledges: there should be some tag - and I really feel tjc is not right - but I think the 'sfos bug tracker' should be a community/jolla discussion 10:12:10 aye 10:12:15 yeah a community sailfishos wiki part would be nice. There are so many tips and tricks txt files I have on my Jolla device with small fixes and so on. Would be nice to have a central place with tips, howto and tricks that isn't also used for bug reportings and questions like tjc is 10:12:22 SF#12345 :D 10:12:42 Thaodan: I think your question is part of that bug tracker question - a very good part 10:12:56 the mer bz was the place to put open source bugs about open source code 10:13:15 test 10:13:33 it was the place to work in the open - I hope jolla will continue to do that (even more) with a new bz 10:13:38 lbt: yes it hides details to non jolla devs and makes it harder to get changes done by Jolla. Especially if you try to contribute to existing Jolla code. 10:14:22 wow, quite the news (he said having backlogged enough) 10:14:28 pketo: can probably help us get better open<>internal sync or integration for a bz solution 10:14:53 leszek: I have a git repo for that kind of stuff tbh 10:15:05 so is it correct to say that SailfishOS is the opensource project behind Jolla's product and Mer is now officially a part of it? 10:15:05 pisarz1958: link? 10:15:21 leszek: I'm really not sure about a wiki - take a look at the mer one sometime - really dig around in there 10:15:25 pisarz1958: maybe we can start something on our own if we have enough stuff and jolla needs to much time for this 10:15:44 lbt: Would be opening bugs in the mer/sfos bugtracker when they are specific to these components a way? 10:15:57 lbt: it needs someone responsible and working on improving and keeping stuff fresh for sure 10:15:58 lbt keep the time in mind too please. 15 min passed :) 10:16:06 wow - so soon! 10:16:15 yeah :D 10:16:16 it's basically a collection of bash scripts for fixing common issues, I'm pretty sure I linked you that. https://github.com/ksiazkowicz/sailfish-annoyances 10:16:21 leszek: a git repo with markdown would be a way (see worg orgmode wiki) 10:16:40 lbt: so not a here is a wiki do what you want approach. It needs moderators and people caring about it 10:16:45 Thaodan: I doubt we can open bugs - instead we can have a public bug tracker and encourage actual work to happen there and copy to internal for business tracking 10:16:55 Thaodan: also a nice idea 10:16:56 leszek: https://orgmode.org/worg/ 10:17:01 leszek: yep - I tried - it's too hard! 10:17:03 lbt: yep, some work has actually been made on improving that bz2bz sync stuff already but it has not been deployed as it is missing some bits that would make it usable in this case 10:17:10 Thaodan: that's what I kept telling people....!!!! 10:17:14 worg! 10:17:17 *sigh* 10:17:28 lbt: yes thats was saying. 10:17:41 was so bad about worg? 10:18:14 lets get the community to really discuss how to handle 'wiki' needs 10:18:36 I propose burning the mer wiki :D 10:18:52 the porters use their wiki area 10:18:54 lbt would it be okay to continue this on general discussion so I can change the topic? :) 10:18:58 nemomobile too(?) 10:19:00 lbt: like a wooden ship on a funeral? :D 10:19:02 it's also why we had to close down the user registration 10:19:09 there has been some resurgence in nemo using wiki, but im not sure it will stick 10:19:10 Thaodan: like a platform.... 10:19:20 Jaymzz: yes I think so - ty 10:19:30 #topic general discussion (15 min) 10:19:39 hmm 10:19:41 nemo might prefer to have their own wiki rather than use something with sailfish in the name 10:19:56 should probably have had an info about the mer merge... 10:20:04 nemo is running on open sfos core 10:20:19 #info I am pleased to announce that once again the Mer Project has served its purpose and provided the foundation for a successful and open mobile operating system. Last time this happened the Mer Project closed its doors and moved to supporting MeeGo - this time we're delighted that we're actually going to continue to operate. We'll be merging with SailfishOS.org :D 10:20:25 Jaymzz: any news on supporting a smaller device ?? 10:20:25 well. 'mer core' but yes 10:20:25 which mer will be renamed to iiuc 10:20:29 for wiki I would be also quite happy with some static pages thingie maintained in git 10:20:34 Jaymzz: my j1 is slowly dying 10:20:39 ApBBB: nothing on that sorry :( 10:21:00 * lbt notes that gitlab provided wikis 10:21:00 Jaymzz: :( 10:21:07 maybe I just find time to tryout this worg and git thingy 10:21:50 I've developed some scripts to build hardware adaptions, maybe someone could fine some use in them: https://gitlab.com/Thaodan/hadk_tools 10:22:19 ApBBB: sent you a PM 10:22:35 Jaymzz: got it 10:22:57 Thaodan: pisarz1958: maybe bring those git/notes things into the community space then? 10:23:17 sledges: is HADK in open git yet? 10:23:22 lbt: nope 10:23:25 why not? 10:23:37 time needed for licences 10:23:44 is git.sfos,org a good reason to get it there? 10:23:45 because its sledges precious 10:23:53 r0kk3rz: haha 10:23:57 What are the benefits of mer-sfos merge? What are the downsides? 10:24:18 eekkelund: interesting :) 10:24:40 benefits is mostly branding, its an reconciliation of something thats been true for a long time 10:24:59 ie. mer is run by jolla as an open source component for sfos 10:24:59 lbt: sure if I know where to push. Some input would help cleaning things up. It was first only made for my use 10:25:16 eekkelund: from a sfos point of view it's a much more obvious to customers that this is all one thing 10:25:40 lbt: the #1 question i get from outsiders is 'what even is mer' 10:25:44 from a mer PoV ... not a lot changes and we OSS people tend not to be hung up on brands 10:25:47 enables building the sony-nile image by simple hadk.build -f sony.$device.hadk 10:25:52 r0kk3rz: yes 10:26:12 to which i reply, 'think of it as an open source bucket for sailfish stuff' 10:26:17 Thaodan: I'd see some of those things as maybe in a hadk-extras git repo or something 10:26:40 lbt: yes please 10:26:42 lbt: it's really just a collection of scripts collected from TJC that I put in a repo for my use and convenience 10:26:42 r0kk3rz: so now it will be "it's where sfos is developed" 10:26:52 lbt, r0kk3rz: Understood and agree with both of you, thanks :) 10:27:51 5 min remains 10:27:53 people used to think sfos is all closed source, and mer (which is oss) is a separate thing, no matter how much we tell them sfos wasn't all closed 10:27:56 eekkelund: the only slight downside is that jolla will now control the whole thing - previously it was (essentially) just me 10:28:05 lbt: well, partially, i assume theres still going to be closed areas ;) 10:28:18 lbt: maybe that would reduce the stress on you. 10:28:27 yes the closed stuff will be in jolla systems 10:28:34 but we like having lbt fight for our corner 10:29:05 Thaodan: yeah - I haven't had enough time recently (2 yrs now) for Mer stuff so it has languished 10:29:12 r0kk3rz: I still fight :) 10:29:30 but tbh there's not *that* much to fight against 10:29:42 I really hope the community will push for a bugzilla 10:29:50 and make more use of the OBS 10:29:54 we have been pushing for one for years 10:30:04 the answer is always 'we're happy with tjc' 10:30:15 r0kk3rz: yes - but we've also had the mer bz 10:30:35 we need to push to say "tjc is not enough for devs working on mer-core" 10:30:41 yes 10:30:44 lbt: hopefully that is not real downside :) 10:31:09 eekkelund: I hope not .... you have to trust :) 10:31:09 * lpotter always hated tjc 10:31:11 although my personal interacting with the mer-bz is mostly to feed BOSS 10:31:50 I want to see jolla devs working on a public bug tracker for OSS code 10:31:58 +1 10:32:34 lbt: wasn't that the mer bugtracker basicly or are the oss components that dont belong to mer? 10:32:44 *are there 10:32:45 right now they work on an internal one - so if sfos really is the open heart then jolla has to push harder to work in the open - like we always badgered Intel to do! 10:33:15 Thaodan: the mer bz is for all open code 10:33:24 but it is not well structured any more 10:33:50 we've evolved a different solution internally which is less granular and more flexible 10:34:08 if you look through all the open components, theres JB references eeeeeeverywhere 10:34:10 and bz structures are hard to change because bugs last forever 10:34:30 r0kk3rz: yes - that's what I hope we'll move away from 10:34:36 good 10:34:40 I wonder what SF#1 will be.... 10:35:02 it should be sufficient to have a single deployment, but with public and private areas? 10:35:22 No that won't happen 10:35:23 lbt: update tjc? 10:35:32 Time's up for general discussion guys. 10:35:38 lbt: Make everything open source :D 10:35:45 abranson: yay!!! 10:35:57 Moving on 10:36:00 oh look, a flying piggz 10:36:11 #topic next meeting time and date 10:36:20 So FOSDEM is coming 10:36:33 Do we have a room? 10:36:39 and we will have - as usual - a meeting there. But this time it si a bit different 10:36:55 Thaodan: will be booked FOSDEM's Saturday morning when registration opens 10:37:15 We will hold the meeting at FOSDEM but won't include the usual IRC meeting 10:37:25 by a popular demand ^ 10:37:32 We have receved feedback from several people that it would be better that way 10:37:39 And that seems to be agreed between us as well. 10:38:12 So what we request from y'all is to propose topics for FOSDEM meeting on the usual spot (TJC's topic announcement page) 10:38:24 And we will discuss those topics with you over there 10:38:39 Now if you are proposing a topic, it requires you to be there 10:38:42 please choose topics that are good for BoF discussion:) 10:38:47 So keep that in mind. 10:38:55 could we ask that topics are to be raised by people attending the meeting? 10:39:12 *cough* bug tracking 10:39:18 last year we had topics, that literally nobody in the room cared about 10:39:22 which was kinda awkward 10:39:48 r0kk3rz: yeah that's important 10:40:15 I will inform you more about this on my email later on. I think ad-hoc topics could be appreciated :) But we can't promise to have all the answers in our pockets ;) 10:40:49 you coming Jaymzz? 10:41:30 r0kk3rz: doing my best. If my passport arrived before then, I'll see you there. If not, unfortunately I'll have to wait yet another year :( but I don'r have high hopes. 10:41:53 They said it'll take a month on January 9th... so yeah 10:42:02 It could happen though still :) 10:42:03 ah 10:42:14 just get someone to smuggle you 10:42:21 Jaymzz: is there no tempoary version? wish you look 10:43:17 Thaodan: as I'm not yet a citizen here, there is no temporary solution for me. I need a passport that's called "travel document" and that one is "in the making" right now 10:44:31 So anyhow, next meeting will be held during FOSDEM. And the one after that will be held on either February 7th or February 21st. 7th is too close to the event, that's why we could cancel that one 10:44:46 So who votes for 7th and who votes for 21st? hands up :D 10:45:11 +21 10:45:26 21 for me too 10:45:29 given the mer->sfos transition and fosdem not being irc.... 7th 10:45:36 is there an ical file for mer-meeting? 10:45:48 Thaodan: No 10:46:16 I hope to hear about fosdem BoF since I can't be there and I hope to have more discussion on SFOS progress 10:46:16 can someone log the results of fosdem for users that cant arrive? 10:46:20 Thaodan: first bit.ly link: https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/ 10:46:48 Thaodan: there will be live streaming at best 10:47:00 lbt we will have a discussion about that on the next irc meeting 10:47:21 so we have 2 votes for 21st and 1 vote for 7th. Anyone else? don't be afraid, it's free to vote 10:47:21 sledges: I now that link but thats no ical calendar 10:47:30 Thaodan: it's .ics 10:48:50 Alright seems like no one else if voting. So we will go with the current result of 2 to 1. and the next meeting on IRC will be held on 21st of February. 10:49:07 The meeting on 7th maybe used to report about FOSDEM instead of having questions as usual. 10:49:30 3 votes - all sailors.... :( 10:49:54 I mean for those not being able to move to Brussel. 10:49:56 dcaliste: we were thinking of having the FOSDEM report merged with an actual meeting with other topics. 10:49:57 sledges: where? I can find it. 10:50:04 Thaodan: "Add to calendar" 10:50:26 #info the next meeting on IRC will be held on Thursday 21st of February at 09:00 UTC 10:50:30 Jaymzz: i like dcaliste's idea of having a long "General (FOSDEM) discussion" only 7th 10:50:38 #undo 10:50:38 Removing item from minutes: 10:50:48 okay 10:51:22 #info Next meeting discussing FOSDEM will be held on Thursday, February 7th 2019 at 09:00 UTC 10:51:49 :) thanks ! 10:52:11 Thanks all for attending. I'm going to end the meeting now. Hopefully see you at FOSDEM if I make it :P 10:52:18 sledges: thanks not perfect but works. 10:52:23 #endmeeting