08:00:23 <sledges> #startmeeting Sailfish OS, open source, collaboration -- 17th December 2020
08:00:23 <sailbot> Meeting started Thu Dec 17 08:00:23 2020 UTC. The chair is sledges. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:23 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:27 <sledges> #info Meeting information and agenda can be found here:
08:00:39 <sledges> #link https://forum.sailfishos.org/t/community-meeting-on-irc-17th-dec-2020/3499
08:00:46 <sledges> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please behave Austin, and respect timing.
08:00:51 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with #info
08:01:07 <sledges> #info Simonas Leleiva - privateer for Jolla
08:01:32 <ViGe> #info Ville Nummela - sailor@Jolla
08:01:39 <abranson> #info Andrew Branson - another privateer for Jolla
08:01:50 <Thaodan> #info Björn Bidar - sailor @ Jolla
08:02:08 <veskuh> #info Vesa-Matti Hartikainen - sailor @ Jolla
08:02:16 <sledges> sailors 5:0 community :)
08:02:55 <chriadam> #info Chris Adams - privateer for Jolla
08:02:56 <rubdos> #info Ruben De Smet - developer of Whisperfish and Rust User Group Belgium person.
08:03:08 <rubdos> sailors 6:1 community ;-)
08:03:21 <karry_> #info Lukas Karas - community, developer
08:03:23 <flypig> I'm loving your Whisperfish development rubdos
08:03:29 <flypig> #info David Llewellyn-Jones - sailor @ Jolla
08:04:20 <rubdos> Thanks!  Good to have some love from a Jolla sailor :-)
08:06:37 <piggz> #info piggz community porter
08:08:04 <cartron> hello!
08:08:09 * sledges (in the voice of a UK football commentator:)): closing in at sailors 7, community ... three
08:08:30 <sledges> hi cartron, you had a chance of last goal with your #info :)
08:08:51 <takimata70> #info : takimata - user/dev
08:09:07 <cartron> #info: ncartron - user
08:09:20 <cartron> #info: cartron - user
08:09:28 * sledges referee whistles 3 times, 7:5, close but no cigar:))
08:09:29 <sledges> #topic State of the Jolla Store (10 min -- asked by thigg)
08:09:35 <sledges> #info <thigg> Many apps in the store are outdated/not maintained. Is there a strategy for obsolete/unmaintained apps? What are the priorities of Jolla in the store? What are the strategies to progress towards these priorities? Is it important for Jolla to make it easy for developers to publish in the store (compared to openrepos)? This is only a small part of this thread:
08:10:04 <sledges> #link https://forum.sailfishos.org/t/jolla-store-what-is-the-plan/2691/15
08:10:17 <sledges> do we have thigg or sailr in spirit?
08:11:14 <ApBBB> you can answer it without them. it is one of the big problems we have.
08:11:18 <sledges> ok, here comes the answer:
08:11:18 <sledges> #info <Jolla> Harbour rules have been strict historically, and we have been gradually working on making it easier to publish apps to Jolla Store. Progress in developer offering has often been dependent on customer projects, but we are planning to open up more APIs to make it possible to publish more apps in Jolla Store that are now only available in OpenRepos.
08:11:38 <sledges> #info <Jolla> In general, apps need good quality APIs in both OpenRepos and Jolla Store that stay working between the releases, e.g. there are issues in already allowed libraries like Camera API that should also be fixed.
08:11:57 <sledges> #info <Jolla> There will be some polls in the Forum in the near future to help us define the priorities in improving the Jolla Store.
08:13:41 <ApBBB> sledges is it possible for jolla to bend the rules a bit for really nice apps ?
08:14:17 <takimata70> Are you considering some kind of "OpenSea" store (in addition to the Harbour) which is less strict than Harbour but has at least more quality assurance procedures than OpenRepos?
08:14:41 <flypig> "OpenSee", nice :)
08:14:42 <sledges> ApBBB: unfortunately what usually happens in such case, other devs might be furious about discrimination
08:14:48 <flypig> *OpenSea
08:14:50 <takimata70> e.g., some kind of rolling release store
08:14:51 <karry_> it is planned to allow to install background systemd services in harbour?
08:15:31 <gmc> #info: gmc - community
08:15:33 <Thaodan> takimata70: That is what OpenRepos already is
08:15:47 <sledges> karry_: this has been talked many times, but i don't think anyone ever mentioned the hazard that comes from it: slowed down performance due to many daemons (feel free to discuss if that can be mitigated)
08:16:20 <rubdos> A rule against "crappy daemons" would be something, I suppose.
08:16:55 <rubdos> Not sure whether many processes is a big problem an-sich, but feel free to correct me there.
08:16:56 <sledges> but if a user is an "app collector", even many background processes would accumulate to a overall performance hit
08:16:57 <ViGe> sledges: That's not even the biggest hazard. Think about autostarting services which blank the screen at startup...
08:17:05 <jpetrell> especially if you write that daemon with Qt C++ the daemon can take many megabytes from memory pool used to run apps
08:17:08 <veskuh> takimata70, It's been discussed that we could have stable/experimental separation where more would be allowed for "experimental" apps. That being said, not really fully analyzed if we can do it.
08:17:25 <ApBBB> sledges this is a user problem. of he is a hoarder its his problem
08:17:33 <Thaodan> About background services: Currently there is no way to see/stop/disable background services per app, I do't think that something like this will be allowed until there is something for that.
08:17:37 <rubdos> fair point wrt. app-collectors. Maybe an
08:17:42 <sledges> ApBBB: jpetrell's point about memory footprint is part of the same hazard
08:18:15 <flypig> iOS will kill background tasks that eat too many cycles. It might be better to allow daemons with restrictions than no daemons at all.
08:18:27 <ApBBB> sledges i get that you like to keep things slim but phones these days are beasts
08:18:39 <karry_> well, I understand troubles that daemons may bring, but many applications (chat clients, battery monitor, gps trackers) have to be openned whole time...
08:18:53 <sledges> ApBBB: but linux is multitasking as is (android just suspends apps, that's why it feels 'performant')
08:19:41 <sledges> ViGe: services blanking the screen would add to a rule of "crappy daemons" that rubdos mentioned, however it does look a whole new rulebook yet to be written
08:20:31 <rubdos> I think any prospect on getting services approved would be good, sledges, so take your time to write a nice rulebook for us!
08:20:47 <sledges> another point of pure discussion by sailr:
08:20:50 <sledges> #info <sailr> What if Jolla would start an open accessible version control hosting for the jolla store - like github/gitlab/gitea - so that people can send pull requests for the listed apps and the developer just needs to approve them. Furthermore you could see the source code you are running on your device.
08:21:40 <sledges> but would app devs like to keep their src code elsewhere than under their own user? preferences to gitlab/hub/... also spring to mind
08:22:23 <rubdos> If Jolla could provide us with a Gitlab Ultimate, that would be very nice of course ;-)
08:22:26 <abranson> I think a lot of apps have this anyway, with an e.g. github url in their app description. might be nice to have that as a distinct field though?
08:22:27 <gmc> personally, i keep my projects on my self-hosted gitlab instance, and would be hesistant to use anything I do not control.. i never know when an externally hosted service is going to disappear
08:22:45 <takimata70> If it would be a gitlab instance; I would use it (but still mirroring the code elsewhere)
08:23:47 <ApBBB> sledges the question is though do we need to have such strict rules to the store. Given that your clients are going to use the phone is a restricted way -controlled by the admins of the company.
08:23:49 <sledges> gmc: and keeping two copies of your code would also be a maintenance burden? however "Issues" page would be more centralised and get more eyes on than separate home repos
08:24:00 <piggz> re services, both amazfish and taskswitcher of mine have bacjground services, and allow control via their respective ui
08:24:40 <flypig> Providing app upload from sfdk might achieve something similar (hook the app upload to the store into the CI)
08:25:16 <ViGe> flypig: Now that's an interesting idea!
08:25:21 <sledges> ApBBB: like said in the answer, we've plans to improve developer offering
08:25:33 <karry_> Not sure what problem want sailr to solve...? Unmaintained applications maybe?
08:26:47 <sledges> karry_: centralised source repo (and bug tracking), also addresses unmaintained apps indeed
08:27:50 <Thaodan> Also re services: I think many come from android where you need background services compared to sailfish os where you don't need them unless the app does its just mostly in the background like amazfish from pigzz
08:27:55 <gmc> sledges: well yes, i develop these apps in my free time, so anything that distracts me from actually developing i try to avoid
08:28:02 <abranson> does it though? having the source code anywhere else is going to do the same. if the app is unmaintained then there's no-one to accept the PRS, no matter where it's hosted
08:28:29 <gmc> sledges: i do see the advantage of having a central point, and I can probably set up some scripts to sync between the two
08:28:45 <rubdos> The problem is about humans, not about systems, afaict.
08:28:54 <abranson> exactly
08:29:08 <sledges> #info Allowing background services to Jolla Store needs many aspects addressed firmly, including but not limited to: a rulebook what a daemon can or cannot do: more indepth (not automated) analysis of its src code, implement framework for user to choose which background services allowed
08:29:22 <gmc> Thaodan: why do you not need background services in sailfish? is there some mechanism by which I can for eg periodically sync tasks with nextcloud in my tasks app without a background process/daemon?
08:29:41 <gmc> (ie other than requiring the user to keep the app open)
08:30:18 <ViGe> Starting that series of polls which was mentioned in the answer: https://forum.sailfishos.org/t/what-apis-are-missing-from-harbour/4017
08:30:21 <sledges> i think instant messenger such as Sailfish OS Telegram apps would also benefit from a background notifications service at startup
08:30:22 <gmc> abranson: well, if you can have some 'adoption' mechanism, where an unmaintained project can be taken over by someone else, that would solve that
08:30:43 <jpetrell> yeah since we don't have push notifications background services are needed by communications apps for notifying user of arriving messages
08:30:48 <karry_> to unmaintained applications, forks on VCS (Github) may solve it, but would be great to allow team accounts in Harbour...
08:31:19 <rubdos> adoption rules ++, the bug tracker location is not really relevant if you can "adopt" them on harbour, I'd think.
08:31:19 <chriadam> forced adoption might open a can of legal worms / require a copyright assignment agreement etc... I am not a lawyer, but seems like a tricky thing to me.
08:31:27 <Thaodan> gmc: I was talking about user facing apps like chat clients. But I undestand that sync apps need background services. But you could reuse existing frameworks that already run in the background
08:31:30 <abranson> gmc: that's not a source code problem though, that's about who owns the app in the store. I think we've had a couple of handovers over the years. They get assessed on a case-by-case basis.
08:31:37 <rinigus> Thaodan: example of service is osm scout server for offline maps. It was even in the store until API changed and I refused to link systemd lib and provide it as a incorporated lib as a part of package
08:32:21 <Thaodan> rinigus: That is why I said: *except apps that do their job mostly in background*
08:32:27 <flypig> Adoption may be tricky, but team accounts is a nice idea karry_.
08:32:46 <Thaodan> +1
08:33:09 <sledges> #info <ViGe> Starting that series of polls which was mentioned in the answer:
08:33:12 <sledges> #link https://forum.sailfishos.org/t/what-apis-are-missing-from-harbour/4017
08:34:04 <gmc> abranson: true, good point
08:34:14 <rinigus> Thaodan: right.
08:34:27 <sledges> #info Teams accounts on Jolla Store proposed as a good idea to address unmaintained apps
08:34:30 <sledges> and we went into overtime with this one;) let's move on
08:34:32 <sledges> #topic Bi-weekly / monthly community updates (10 min -- asked by Nico[m])
08:34:41 <sledges> #info <Nico[m]> Quite a few projects give regular community updates. One popular example is Matrix with "This week in matrix":
08:34:45 <sledges> #link https://matrix.org/blog/category/this-week-in-matrix/
08:34:48 <sledges> #info <Nico[m]> another one is Nate Graham from KDE:
08:34:51 <sledges> #link https://pointieststick.com/
08:34:54 <sledges> #info and UBPorts seems to have something similar. Such updates give developers and users a way to see, what others are doing, what is currently happening, discover new projects and a goal to have something presentable every few weeks. This usually takes the form of developers submitting updates on Friday (or so) and then a member collecting those updates and posting them as a blog post.
08:35:12 <sledges> #info <Nico[m]> I wanted to discuss this idea, if others are interested in such a thing and if Jolla would be willing to post those updates on their blog and maybe even chair the submission process.
08:35:22 <sledges> #info <Nico[m]> (Note that this would not replace community meeting, but rather extend them to less developer minded people.)
08:35:33 <sledges> #info <Jolla> Thank you for such suggestion, it would certainly be beneficial for community members to know what others are up to. We are going to discuss this further after the festive period.
08:35:45 <rubdos> This-Week-In-Rust is also a nice one. They use #twir as hashtag on Twitter. Many people read that, and it's just a simple blog-based thing like Matrix.
08:36:13 <sledges> such updates would be technical/developer-oriented, so forum would be preferred instead of the blog
08:36:41 <takimata70> forum would also be fine i think
08:36:42 <chriadam> people who are interested in contributing to Sailfish OS are more than welcome to join dcaliste and I for our weekly discussions, on Tuesdays.  Once we are finished with our weekly agenda, I am open to discussing other things with other folks.
08:36:43 <gmc> but does the forum have an rss feed that i can use to just pull in that blog-like form thread?
08:36:54 <rubdos> nice thing about a blog-like thing is RSS, but the forum is a nice place too I suppose.
08:36:56 <sledges> (in the light of what Jolla posts in the blog)
08:37:02 <dcaliste> #info Damien, community, very late
08:37:14 <abranson> Blogs are definitely more visible
08:37:25 <ApBBB> since many stuff for sfos are developed in the open (git) isn't this duplication in a way.
08:37:33 <piggz> abranson: not my blog, its very well hidden!
08:37:36 <gmc> possibly create a community blog seperate from the corporate blog, if jolla doesn't want to mix the two?
08:37:44 <sledges> ViGe: is RSS a possibility in the forum?:)
08:37:52 <sledges> abranson: +1
08:38:05 <abranson> piggz: you have a blog?  ;)
08:38:07 <gmc> ApBBB: not really, a blog with more prose-like summaries of what's happening is much more accesible than a bunch of forum posts and git commit messages
08:38:23 <piggz> abranson: you wouldnt know!
08:38:29 <rubdos> What TWIR does: they have a Jekyll-like thing that the community can send PRs to during the week, and in the end they merge to master and it gets public.
08:38:29 <rinigus> I would expect forum would be fine. You could also advertise posts on twitter if needed
08:38:32 <gmc> plus, a blog can summarize things that are *not yet* being developed
08:38:37 <sledges> who remembers the "planet" thing? ;)
08:38:40 <abranson> Tweeting the forum post would be even more visible
08:38:50 <piggz> i still subscribe to "planets" :)
08:38:53 <dcaliste> ApBBB, reading the activity page on git.sailfishos.org is nice to be kept about latest development, but having a simple digest for everyone would be nice
08:38:58 <ViGe> sledges: Just add .rss to any URL in the forum
08:39:12 <dcaliste> It could be taken by community to write these digests, though
08:39:12 <sledges> rubdos: ^
08:39:26 <sledges> err
08:39:27 <sledges> gmc ^^
08:40:11 <sledges> #info one can add .rss to any URL in the forum to just pull in that blog-like form thread
08:40:38 <gmc> ok, so that would be one specific forum thread, that we can publish the rss url for, and that is somehow redacted to only contain the weekly updates as posts?
08:40:45 <chriadam> it would be a lot of work.  and is a fairly long-term commitment, or it wouldn't be valuable.  if anyone is willing to do it, that's fantastic, but .. it's not a small thing to try to summarise all ongoing development efforts across Sailfish OS and who the contributors are, every 2 weeks...
08:41:01 <rubdos> doesn't have to be weekly, monthly would also be very nice
08:41:12 <gmc> could be a rotating job among those who are interested in this?
08:41:14 <rubdos> the pace of projects like Rust is very high, so weekly makes sense there
08:41:52 <gmc> and i like that twir idea of having pr's from the actual devs, or at least the concept of it not having to be 1 person doing all the work
08:42:02 <sledges> dcaliste: ApBBB: this topic is about community updates, not Jolla's
08:42:12 <sledges> what app developers are up to etc
08:42:30 <rubdos> if you can do it by PR+review, it's almost no work for the responsible person
08:42:31 <piggz> may be wise for people to submit topics .. thats how some weekly news podcasts work, listeners submit topics, then theya re chosen on the show, similar idea would make it so it wasnt enscessary for one person to find out everything going on
08:42:32 <dcaliste> Oh, sorry misunderstood !
08:42:34 <gmc> not only app developers, but a more newspaper-like report of these meetings as well for eg
08:42:46 <chriadam> some script to inspect all PRs (both merged and open) in the time period, extract the changelog entries and authors, would probably be a good first step which is automatable I guess
08:42:50 <flypig> rubdos, I like that PR+review idea.
08:43:00 <flypig> That really could cut down the effort.
08:43:28 <abranson> piggz: and also very similar to how these meetings work
08:43:36 <flypig> Have some markdown in a repo, then transfer it to the forum every fortnight or something.
08:44:04 <rubdos> ah right, you can just make it Jekyll-style pull requests and have CI move them to the forum
08:44:15 <Thaodan> flypig: Or pelican and run a ci job to generate the HTML
08:44:18 <karry_> I like the idea of aggregated changelogs from newly releases :-)
08:44:37 <sledges> i find out about new or improved apps made by community only from twitter at the moment. and most of the time only when Jolla retweets them
08:44:47 <flypig> rubdos, Thaodan, yes, nice.
08:44:48 <Thaodan> I use pelican for my homepage (thaodan.de) and it works quite well
08:45:09 <chriadam> karry_: changelogs for releases are available already, right?
08:45:10 <gmc> yeah pelican is great :)
08:45:14 <cartron> sledges I have a #SailfishOS column in my tweetdeck to track that :)
08:45:15 <Thaodan> Even works with org-mode which is the better markdown imho.
08:45:16 <gmc> sledges: and not everyone is on twitter......
08:45:22 <sledges> exactly
08:45:40 <gmc> especially the people I know who use sailfish, they tend to not be on twitter :)
08:45:41 <Thaodan> Also twitter is a single point of failure which can break.
08:46:07 <chriadam> karry_: at least, we used to publish those, e.g. https://together.jolla.com/question/191507/changelog-300-lemmenjoki/
08:46:13 <abranson> we also have other SoMe channels
08:46:24 <sledges> chriadam: we still publish changelog on forum
08:46:37 <chriadam> great
08:47:22 <karry_> chriadam: I have community applications in my mind
08:47:32 <chriadam> oh I see
08:47:33 <sledges> abranson: i've not seen e.g. Fernschreiber post when i looked at Jolla's facebook once, but it was on twitter, that's about it. so a newspaper-like all-round community+jolla digest is certainly needed
08:48:25 <sledges> thanks all, will amalgamate ideas and see what comes out of them:)
08:48:32 <sledges> #topic The state of Rust as (application) programming language for Sailfish OS (10 min -- asked by rubdos)
08:49:28 <sledges> #info <rubdos> Sailfish OS 3.4 introduced Rust support. I and others:
08:49:31 <sledges> #link https://forum.sailfishos.org/t/rust-howto-request/3187/22
08:49:33 <sledges> #info <rubdos> would like to know whether Jolla and the community see Rust as a potential programming language, both in general and specifically for application writing. I will join the conversation from the Whisperfish perspective, having done Rust for Sailfish application writing before 3.4.
08:49:41 <sledges> #link https://gitlab.com/rubdos/whisperfish/-/merge_requests/5
08:50:14 <sledges> #info <Jolla> Sailfish OS apps (focus of the SDK offering, platform apps, etc.) are still mainly developed with Qt C++ and QML, but as general mobile operating system new languages and technologies are welcomed in the ecosystem.
08:50:27 <sledges> #info <Jolla> Rust specifically has a lot of potential, and while most of our focus is in improving C++ and QML support, we will also improve Rust support.
08:50:59 <rubdos> I suppose that mostly answers the question indeed.
08:51:21 <rubdos> There are quite a few practical problems with using Rust from the application perspective.
08:51:48 <flypig> Could you briefly explain how you use rust to build your applications at the moment rubdos?
08:51:53 <rubdos> I think there are two main places for Rust: things with a GUI and things without a GUI. The latter are "easy" (just compile them), the former are quite hard.
08:52:15 <rubdos> Indeed, flypig, I think the answer to your question is "no", because "briefly" wouldn't really cut it.
08:52:30 <flypig> :)
08:53:02 <rubdos> I've spent quite a lot of time a year ago to figure out *whether* and *how* it's possible.  I currently build using the Arch-Linux cross compiler, and setting a sh*tt*n* of -rpath flags to the respective /srv/mer directories
08:53:12 <rubdos> this process also works using Debian as a host
08:53:17 <chriadam> I've built rust apps for the phone using static linkage with musl and cross build.  works great.  of course, as soon as you have external dependencies e.g. for UI it doesn't work any more ;-)
08:53:38 <rubdos> Fedora, notably running on my home server, doesn't have a complete-enough cross compilation environment for it to work.
08:53:58 <rubdos> Indeed, chriadam, without UI components it's very easy :-)
08:54:04 <rubdos> or easy-enough :P
08:54:31 <ViGe> rubdos: Have you tried compiling your stuff with the Sailfish SDK?
08:54:34 <rubdos> I haven't tried hard enough yet to get Whisperfish building in the new Mer SDK, since 3.4 it should be possible
08:54:37 <rubdos> I've given it a shot
08:54:47 <rubdos> but haven't tried for long enough, and I don't really recall what went wrong...
08:55:11 <rubdos> (haven't had time lately, had too much other work on my head...)
08:55:43 <rubdos> Interest in contributing to Whisperfish is getting higher, and the compilation process is a showstopper: https://gitlab.com/rubdos/whisperfish/-/merge_requests/64
08:56:13 <ViGe> rubdos: Please, whenever you have time, try. And report on the problems. I don't have any illusions that it would just work out of the box, but it's hard to fix issues if we don't hear about them...
08:56:38 <rubdos> I will report back on compile issues, for sure. Any specific place where you want them reported?
08:57:29 <rubdos> Also, I had another very specific issue in Whisperfish that would need Jolla's feedback, because it's very Sailfish-Rust specific. Some place where I should contact you for that?
08:57:30 <karry_> It should be possible to build shared library in rust, expose C-ABI api a then write thin layer in C++ that interacts with UI... Firefox do that this way, right?
08:57:32 <ViGe> There's the Bug Reports category in the forum :) Or Applications -category if the issue is not clearly a bug in the SDK.
08:58:37 <rubdos> OK, that's for the SDK-related bugs, I presume. For Rust-SailfishOS GUI interfaces (the API that karry_ talks about, basically), I have another issue related to ambience changes.  I think I maybe need a specific chat with someone knowledgeable in that area to get that kind of thing resolved.
08:59:06 <rubdos> I've been diving way too deep in the Qt source for my own mental sanity before giving up on that :'-)
08:59:18 <sledges> #info (discussing about adventures when building sfos apps with rust, also via sdk, using Whisperfish as reference)
08:59:20 <rubdos> (basically, an ambience change in the system doesn't trigger a font color change in-app)
09:00:14 <sledges> time's up, good talk indeed, will continue via forum's bug reports:)
09:00:17 <sledges> #topic reappearing calenders after each sync (5 min -- asked by apozaf)
09:00:25 <sledges> #info any news or fix? Why is that [bug still] in 3.4?
09:00:29 <sledges> #link https://forum.sailfishos.org/t/calendar-bug-for-disabled-calendars-in-3-4-ea/2563
09:00:47 <sledges> #info <Jolla> Yes, we do have a fix, courtesy of our non-resident calendar expert dcaliste. It didn't make it into 3.4 unfortunately, but will be in the next public release. The fix is in an internal repository, so we can't share a link I'm afraid.
09:01:00 <cartron> "our non-resident calendar expert" ^^
09:01:20 <chriadam> rubdos: pvuorela might be the person to talk to about ambience changes, or denexter but you won't find him on IRC I think.
09:01:36 <cartron> I believe it also fixes deletion of a recurring event which is still displayed, as stated by flypig ?
09:01:37 <chriadam> cartron: dcaliste is a community member, not sailor or privateer, but he knows more about the calendar framework than I do at this point.
09:01:55 <cartron> chriadam I know :)
09:01:55 <rubdos> chriadam: thanks, I'll note that in my bug tracker.
09:02:34 <flypig> cartron, yes, it's a different bug/fix, but that should get fixed as well.
09:02:51 <dcaliste> I must mentioned that flypig contributed also for the fix and he did all the work on Google plugin.
09:03:19 <sledges> #info <chriadam> people who are interested in contributing to Sailfish OS are more than welcome to join dcaliste and I for our weekly discussions, Tuesdays on #sailfishos channel. Once we are finished with our weekly agenda, I am open to discussing other things with other folks.
09:03:34 <cartron> thanks flypig and dcaliste !
09:04:21 <sledges> thanks chriadam !
09:04:34 <sledges> 5mins gon, let's move on
09:04:38 <sledges> #topic Silica components license and source code (15 min -- asked by Karry)
09:04:49 <sledges> #info <Karry> QML part of Silica components have BSD license, headers from `sailfishsilica-qt5-devel` package have LGPL license. But sources are not publicly available.
09:04:59 <sledges> #info <Karry> What is the license of native part of the components? It is really proprietary? Is Jolla aware of the fact that Silica cannot be used with GPL applications? Is there any plan to change it and publish sources with some OSS license?
09:05:09 <sledges> #info Long version:
09:05:10 <sledges> #link https://forum.sailfishos.org/t/silica-components-license-and-source-code/3561
09:05:37 <sledges> #info <Jolla> Official decision to publish C++ part of Silica under LGPL has unfortunately not been made. We will clean up the headers.
09:06:44 <karry_> The biggest issue that I see here is the unclear situation now...
09:07:43 <karry_> So, when it is was not decided, you are saying that it is proprietary, right?
09:07:43 <dcaliste> sledges, what do you mean clean up the header ? Relicence to a proprietray one for the versions to come ?
09:08:02 <sledges> dcaliste: i believe it referred to sailfishsilica-qt5-devel
09:08:13 <rinigus> karry_: do I understand you right that we cannot use silica in gpl apps?
09:08:26 <flypig> karry_, yes, the licence is proprietary.
09:08:37 <rubdos> We can link to Silica, no?
09:08:43 <piggz> rinigus: that would surely be unfortunate :D
09:09:09 <gmc> i guess it depends on whether the app is a derivative work of silica?
09:09:17 <gmc> but oh my, gpl legal arguments
09:09:20 <rubdos> It would be very unfortunate.  Not only Whisperfish is (A)GPL... and that cannot be changed because of libsignal.
09:09:21 <abranson> it's the other way around, isn't it? you're restricted on linking gpl libs in proprietary apps. not the other way around.
09:09:33 <karry_> rinigus, my understand to GPL is, that you cannot link (share address space) GPL and proprietary code in one process
09:09:33 <ViGe> https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
09:09:57 <abranson> there are gpl apps for windows...
09:10:34 <piggz> ViGe: yeah, that seems to clear it up
09:10:37 <flypig> ViGe, that's really helpful.
09:10:40 <rubdos> IANAL. You can make your own work GPL and link to proprietary stuff.  It wouldn't really make sense if it couldn't. It's just unfortunate that your free software depends on something proprietary.
09:11:18 <rinigus> ViGe thanks!
09:12:06 <dcaliste> sledges, sorry I may misunderstand again, but I think the question was about publishing the QML files of silica that are up-to-now published under LGPL, wasn't it ?
09:12:59 <dcaliste> Eh sorry BSD, not LGPL.
09:13:10 <rinigus> From this Jolla statement we can conclude that no Silica opening up is coming.
09:13:16 <rinigus> Right?
09:15:28 <jpetrell> dcaliste: clean up means updating the source code headers, silica C++ bits are still proprietary
09:16:10 <karry_> Thanks ViGe to link that exception. So, the trick is to call Silica "system library"...
09:16:15 <dcaliste> Yes, I know for the C++ parts, I was just wondering about the QML parts that were previously under BSD if this will change in future versions ?
09:17:29 <dcaliste> Oh, I see now, it's about the headres, sorry.
09:17:30 <jpetrell> dcaliste: I don't think that will change
09:18:30 <dcaliste> jpetrell, yeh, thanks. I mixed up I think with  a previous discussion some weeks ago, when someone questioned the possibility or not to publish in a public repo the BSD parts. Sorry for my confusion.
09:18:34 <chriadam> veskuh should probably field this question more comprehensively, I think
09:18:57 <ViGe> karry_: There's a bit more in the trick than that, as "system library" is defined in GPL. Unfortunately it's written in legalese.
09:20:02 <veskuh> Unfortunately, I lost internet for awhile on key momenent on this topic
09:20:45 <sledges> veskuh: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-12-17-08.00.log.txt
09:20:59 <veskuh> sledges, thanks
09:22:18 <piggz> there is some wording here..... the GPL says that libraries can only qualify as System Libraries as long as they're not distributed with the program itself
09:22:30 <piggz> https://www.gnu.org/licenses/gpl-faq.en.html#WindowsRuntimeAndGPL
09:22:47 <veskuh> Right, so our original plan was to publish these with mixed license. That never happened, and licenses are now incorrecly marked on some of the silica packages.
09:23:33 <veskuh> We are in process of marking correct licenses on any packages where we know there is an error
09:24:18 <sledges> #info <veskuh> Right, so our original plan was to publish these with mixed license. That never happened, and licenses are now incorrecly marked on some of the silica packages.
09:24:25 <sledges> #info <veskuh> We are in process of marking correct licenses on any packages where we know there is an error
09:25:00 <sledges> well, silica is certainly not distributed with an app itself, so it'd qualify as System Library
09:25:18 <piggz> sure
09:25:19 <karry_> Thanks. That anvers my question :-) And thanks that clarification of usage GPL code with proprietary system libraries...
09:26:08 <sledges> #info <community> you can link a GPL app to Silica, because Silica qualifies as System Library
09:26:11 <sledges> #link veskuh> We are in process of marking correct licenses on any packages where we know there is an error
09:26:14 <sledges> #undo
09:26:14 <sailbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f3d2750a8d0>
09:26:16 <sledges> #link https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
09:26:20 <sledges> #link https://www.gnu.org/licenses/gpl-faq.en.html#WindowsRuntimeAndGPL
09:26:30 <sledges> dem click paste:)
09:26:39 <sledges> thank you all for putting this together, moving on
09:26:47 <piggz> and the actual GPLv2 words it like this:
09:26:49 <piggz> However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
09:26:57 <sledges> #info <sailr> My [wired] headphones have media buttons (play/pause, volume up, volume down), and they work great with the standard SFOS media player app.
09:27:01 <sledges> #undo
09:27:01 <sailbot> Removing item from minutes: <MeetBot.items.Info object at 0x7f3d288260f0>
09:27:03 <sledges> #topic Wired headset media buttons don't work with Android apps (10 min -- asked by sailr)
09:27:11 <sledges> #link https://forum.sailfishos.org/t/headset-media-buttons-dont-work-with-android-apps/2428
09:27:17 <sledges> #info <sailr> My [wired] headphones have media buttons (play/pause, volume up, volume down), and they work great with the standard SFOS media player app.
09:27:21 <sledges> #info <sailr> However, I want to use them with Android apps such as Spotify, but they don't seem to work.
09:27:26 <sledges> #info <sailr> Play/pause button: Does not work at all, including double-press to skip current song and triple-press to rewind. Everything works fine with SFOS media player.
09:27:32 <sledges> #info <sailr> Volume up & volume down: Only works when device is "awake" (I have to press the power button to turn on the screen); when playing from the SFOS media player I can also change volume when the device is locked (screen completely off), which is very comfortable.
09:27:39 <sledges> #info <sailr> I can't do that when playing media from an Android app, instead I always have to "wake up" the device.
09:27:49 <sledges> #info <Jolla> The task for this to work would be to rewrite Sailfish.Media's MediaKeys functionality to MPRIS, that will then also work for Android App Support.
09:28:17 <sledges> the old TJC issue has a tracking indicator, meaning we are aware of this, and abranson has been an avid advocate for switching over to MPRIS
09:28:39 <sledges> i even found him mentioning it on #mer once:))
09:29:57 <sledges> but i'm not sure on the scope of this task as of yet
09:32:29 <sledges> let's move to general discussion in case there still are comments to the points above
09:32:32 <sledges> #topic General Discussion (10 min)
09:33:04 <ApBBB> SOOOOO. whats comming for SFOS 4. can we have a sneak preview??
09:33:50 <fridl> #info fridl - community
09:33:52 <piggz> sledges: while your attention is here, i wouldnt mind some feedback on the idea here, which would allow you to get rid of all the other hybris-boot mountpoint pr's https://github.com/mer-hybris/hybris-boot/pull/189
09:34:17 <piggz> fridl: just made it for the general discussion :D
09:34:31 <ViGe> ApBBB: Nice try ;)
09:35:05 <chriadam> I mean, most stuff is done in public repositories
09:35:06 <ApBBB> ViGe a christmas gift of some sort. we 've been nice all year :P
09:35:14 <sledges> piggz: nice idea, but i can't see this working on an OBS though
09:35:15 <fridl> piggz: I have been watching, but did not want to disturb as I missed the right moment ;-)
09:35:29 <karry_> ApBBB few hints are hidden in translation strings ;-)
09:35:52 <cartron> Sailjail :-)
09:36:07 <cartron> (that's the only one I spotted)
09:36:12 <piggz> sledges: ah, true ... though, as porters, we cant use obs for the hybris part anyway ... and its just another path to check for mountpoints
09:36:14 <sledges> #info a nice active activity over the festive holiday season:
09:36:16 <sledges> #link https://forum.sailfishos.org/t/sailfish-devember-3-0/3322
09:36:29 <ApBBB> karry_ i know about the recorder. the app permision stuff. but we are translating 3.4
09:36:34 <fridl> Referes to: https://forum.sailfishos.org/t/expandingsection-in-silica-documentation/3994: Can anyone point me to the documentation for the ExpandingSection if available? Or shouldn't this Silica component be used (yet) for some reason? (Was to late to bring up as a topic, if no one can answer I'll ask for the next meeting.)
09:36:47 <ApBBB> i am sure 4 will have new android base.
09:36:59 <dcaliste> ApBBB, look at https://github.com/sailfishos and the latest activity there.
09:37:10 <dcaliste> There are ugrade-4.0.1 branches there.
09:37:11 <sledges> piggz: true it wouldn't break OBS build, but it was in my plans to cherry-pick all open hybris-boot PRs soon
09:38:23 <piggz> k
09:38:23 <sledges> piggz: the reason adaptations PRs are stale is because we'd need to test them on every feasible device that we support internally, and that's a nightmare of a job. that's why i took your droid-hal-version when i did other work for it
09:39:00 <piggz> yeah, that reminded me about the -boot one ... id forgot about the dhv pr
09:39:13 <ApBBB> is there even the slightest chance for a newer Qt in 4??
09:39:29 <flypig> fridl, I think this isn't part of the public API currently.
09:39:31 <chriadam> I think it's fair to say that the next version of Sailfish OS will include a lot of really important changes; both immediate improvements to various things, and also laying the foundation for more improvements in the future.
09:39:49 <piggz> ApBBB: cmon, its only 2020 :D
09:40:03 <sledges> qt4
09:40:22 <piggz> sfos 4 with qt 6
09:40:25 <flypig> fridl, there's a comment at the top of the qml file that says "If this is made into public API..." so I take that to mean it's not yet.
09:40:26 <ApBBB> piggz we need some good news. :)
09:40:41 <takimata70> qt 6 may bring some other licensing issues...
09:40:46 <sledges> nah, will just revert to qt4 to match versions ;)
09:41:12 <ApBBB> hehe
09:41:23 <chriadam> there's lots of good news, IMO.
09:41:44 <ApBBB> with all the licence situation in QT seems more reasonable to change the toolkit completely :P
09:41:46 <fridl> @flypig: I haven't seen that. My App was accepted for Harbour nevertheless ;-) But the Animation of this component is not so nice. Will it make the way to the public API? I have high interest!
09:41:51 <karry_> another question is... when we may expect SFOS 4 ? :-D
09:42:11 <ApBBB> karry_ that we know. when its ready :P
09:42:12 <Thaodan> Soon
09:42:14 <chriadam> soon (tm) / when it's ready, as per usual ;-)
09:42:19 <sledges> karry_: the hint also is in the translation strings process ;)
09:43:17 <sledges> and on this bombshell it's time to end
09:43:19 <sledges> #topic Next meeting time and date (5 min)
09:43:29 <flypig> fridl, your interest is noted :) I'm not sure whether it will I'm afraid (jpetrell should have a better idea). I'd suggest to add it as a full question for next time.
09:43:42 <sledges> Proposing 14th January at 8am UTC
09:44:16 <fridl> @flypig: Ok, thanks!
09:44:42 <flypig> No NYE party meeting then :(
09:44:59 <piggz> fridl: you need to jump on the rinigus components band wagon
09:45:11 <chriadam> +1 for the 14th, sure.
09:45:23 <chriadam> oh, and I hope everyone has a really great christmas and new year etc.
09:45:41 <sledges> Season's greetings to y'all!
09:45:51 <flypig> Yeah, sorry, that's +1 from me too. +similar Christmas and NY wishes.
09:45:51 <sledges> #info Next meeting will be held on Thursday 14th January 2021 at 8:00am UTC:  2021-01-14T08Z
09:47:03 <sledges> all have a nice rest from digitals, be more outdoorsy, and we'll come back in full strength after holiday period!
09:47:03 <chriadam> thanks everyone!
09:47:05 <karry_> Thank you for the juicy meeting guys. Have a nice christmas! And be positive ;-)
09:47:06 <sledges> #endmeeting