| *** vgtw_ is now known as vgtw | 04:17 | |
| sledges | #startmeeting Sailfish OS, open source, collaboration -- 17th December 2020 | 08:00 |
|---|---|---|
| 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 |
| sailbot | Useful Commands: #action #agreed #help #info #idea #link #topic. | 08:00 |
| *** sailbot changes topic to " (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 08:00 | |
| sledges | #info Meeting information and agenda can be found here: | 08:00 |
| sledges | #link https://forum.sailfishos.org/t/community-meeting-on-irc-17th-dec-2020/3499 | 08:00 |
| 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 |
| sledges | #topic Brief introduction (5 min). Please prefix your name/handle with #info | 08:00 |
| *** sailbot changes topic to "Brief introduction (5 min). Please prefix your name/handle with #info (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 08:00 | |
| sledges | #info Simonas Leleiva - privateer for Jolla | 08:01 |
| ViGe | #info Ville Nummela - sailor@Jolla | 08:01 |
| abranson | #info Andrew Branson - another privateer for Jolla | 08:01 |
| Thaodan | #info Björn Bidar - sailor @ Jolla | 08:01 |
| veskuh | #info Vesa-Matti Hartikainen - sailor @ Jolla | 08:02 |
| sledges | sailors 5:0 community :) | 08:02 |
| chriadam | #info Chris Adams - privateer for Jolla | 08:02 |
| rubdos | #info Ruben De Smet - developer of Whisperfish and Rust User Group Belgium person. | 08:02 |
| rubdos | sailors 6:1 community ;-) | 08:03 |
| karry_ | #info Lukas Karas - community, developer | 08:03 |
| flypig | I'm loving your Whisperfish development rubdos | 08:03 |
| flypig | #info David Llewellyn-Jones - sailor @ Jolla | 08:03 |
| rubdos | Thanks! Good to have some love from a Jolla sailor :-) | 08:04 |
| piggz | #info piggz community porter | 08:06 |
| cartron | hello! | 08:08 |
| * sledges (in the voice of a UK football commentator:)): closing in at sailors 7, community ... three | 08:08 | |
| sledges | hi cartron, you had a chance of last goal with your #info :) | 08:08 |
| takimata70 | #info : takimata - user/dev | 08:08 |
| cartron | #info: ncartron - user | 08:09 |
| cartron | #info: cartron - user | 08:09 |
| * sledges referee whistles 3 times, 7:5, close but no cigar:)) | 08:09 | |
| sledges | #topic State of the Jolla Store (10 min -- asked by thigg) | 08:09 |
| *** sailbot changes topic to "State of the Jolla Store (10 min -- asked by thigg) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 08:09 | |
| 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:09 |
| sledges | #link https://forum.sailfishos.org/t/jolla-store-what-is-the-plan/2691/15 | 08:10 |
| sledges | do we have thigg or sailr in spirit? | 08:10 |
| ApBBB | you can answer it without them. it is one of the big problems we have. | 08:11 |
| sledges | ok, here comes the answer: | 08:11 |
| 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 |
| 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 |
| 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:11 |
| ApBBB | sledges is it possible for jolla to bend the rules a bit for really nice apps ? | 08:13 |
| 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 |
| flypig | "OpenSee", nice :) | 08:14 |
| sledges | ApBBB: unfortunately what usually happens in such case, other devs might be furious about discrimination | 08:14 |
| flypig | *OpenSea | 08:14 |
| takimata70 | e.g., some kind of rolling release store | 08:14 |
| karry_ | it is planned to allow to install background systemd services in harbour? | 08:14 |
| gmc | #info: gmc - community | 08:15 |
| Thaodan | takimata70: That is what OpenRepos already is | 08:15 |
| 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:15 |
| rubdos | A rule against "crappy daemons" would be something, I suppose. | 08:16 |
| rubdos | Not sure whether many processes is a big problem an-sich, but feel free to correct me there. | 08:16 |
| sledges | but if a user is an "app collector", even many background processes would accumulate to a overall performance hit | 08:16 |
| ViGe | sledges: That's not even the biggest hazard. Think about autostarting services which blank the screen at startup... | 08:16 |
| 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 |
| 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 |
| ApBBB | sledges this is a user problem. of he is a hoarder its his problem | 08:17 |
| 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 |
| rubdos | fair point wrt. app-collectors. Maybe an | 08:17 |
| sledges | ApBBB: jpetrell's point about memory footprint is part of the same hazard | 08:17 |
| 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 |
| ApBBB | sledges i get that you like to keep things slim but phones these days are beasts | 08:18 |
| 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 |
| sledges | ApBBB: but linux is multitasking as is (android just suspends apps, that's why it feels 'performant') | 08:18 |
| 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:19 |
| 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 |
| sledges | another point of pure discussion by sailr: | 08:20 |
| 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:20 |
| 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:21 |
| rubdos | If Jolla could provide us with a Gitlab Ultimate, that would be very nice of course ;-) | 08:22 |
| 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 |
| 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 |
| takimata70 | If it would be a gitlab instance; I would use it (but still mirroring the code elsewhere) | 08:22 |
| 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 |
| 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:23 |
| piggz | re services, both amazfish and taskswitcher of mine have bacjground services, and allow control via their respective ui | 08:24 |
| flypig | Providing app upload from sfdk might achieve something similar (hook the app upload to the store into the CI) | 08:24 |
| ViGe | flypig: Now that's an interesting idea! | 08:25 |
| sledges | ApBBB: like said in the answer, we've plans to improve developer offering | 08:25 |
| karry_ | Not sure what problem want sailr to solve...? Unmaintained applications maybe? | 08:25 |
| sledges | karry_: centralised source repo (and bug tracking), also addresses unmaintained apps indeed | 08:26 |
| 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 |
| 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:27 |
| 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 |
| 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 |
| rubdos | The problem is about humans, not about systems, afaict. | 08:28 |
| abranson | exactly | 08:28 |
| 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 |
| 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 |
| gmc | (ie other than requiring the user to keep the app open) | 08:29 |
| 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 |
| sledges | i think instant messenger such as Sailfish OS Telegram apps would also benefit from a background notifications service at startup | 08:30 |
| 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 |
| jpetrell | yeah since we don't have push notifications background services are needed by communications apps for notifying user of arriving messages | 08:30 |
| karry_ | to unmaintained applications, forks on VCS (Github) may solve it, but would be great to allow team accounts in Harbour... | 08:30 |
| rubdos | adoption rules ++, the bug tracker location is not really relevant if you can "adopt" them on harbour, I'd think. | 08:31 |
| 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 |
| 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 |
| 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 |
| 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:31 |
| Thaodan | rinigus: That is why I said: *except apps that do their job mostly in background* | 08:32 |
| flypig | Adoption may be tricky, but team accounts is a nice idea karry_. | 08:32 |
| Thaodan | +1 | 08:32 |
| sledges | #info <ViGe> Starting that series of polls which was mentioned in the answer: | 08:33 |
| sledges | #link https://forum.sailfishos.org/t/what-apis-are-missing-from-harbour/4017 | 08:33 |
| gmc | abranson: true, good point | 08:34 |
| rinigus | Thaodan: right. | 08:34 |
| sledges | #info Teams accounts on Jolla Store proposed as a good idea to address unmaintained apps | 08:34 |
| sledges | and we went into overtime with this one;) let's move on | 08:34 |
| sledges | #topic Bi-weekly / monthly community updates (10 min -- asked by Nico[m]) | 08:34 |
| *** sailbot changes topic to "Bi-weekly / monthly community updates (10 min -- asked by Nico[m]) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 08:34 | |
| sledges | #info <Nico[m]> Quite a few projects give regular community updates. One popular example is Matrix with "This week in matrix": | 08:34 |
| sledges | #link https://matrix.org/blog/category/this-week-in-matrix/ | 08:34 |
| sledges | #info <Nico[m]> another one is Nate Graham from KDE: | 08:34 |
| sledges | #link https://pointieststick.com/ | 08:34 |
| 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:34 |
| 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 |
| sledges | #info <Nico[m]> (Note that this would not replace community meeting, but rather extend them to less developer minded people.) | 08:35 |
| 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 |
| 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:35 |
| sledges | such updates would be technical/developer-oriented, so forum would be preferred instead of the blog | 08:36 |
| takimata70 | forum would also be fine i think | 08:36 |
| 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 |
| gmc | but does the forum have an rss feed that i can use to just pull in that blog-like form thread? | 08:36 |
| rubdos | nice thing about a blog-like thing is RSS, but the forum is a nice place too I suppose. | 08:36 |
| sledges | (in the light of what Jolla posts in the blog) | 08:36 |
| dcaliste | #info Damien, community, very late | 08:37 |
| abranson | Blogs are definitely more visible | 08:37 |
| ApBBB | since many stuff for sfos are developed in the open (git) isn't this duplication in a way. | 08:37 |
| piggz | abranson: not my blog, its very well hidden! | 08:37 |
| gmc | possibly create a community blog seperate from the corporate blog, if jolla doesn't want to mix the two? | 08:37 |
| sledges | ViGe: is RSS a possibility in the forum?:) | 08:37 |
| sledges | abranson: +1 | 08:37 |
| abranson | piggz: you have a blog? ;) | 08:38 |
| 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 |
| piggz | abranson: you wouldnt know! | 08:38 |
| 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 |
| rinigus | I would expect forum would be fine. You could also advertise posts on twitter if needed | 08:38 |
| gmc | plus, a blog can summarize things that are *not yet* being developed | 08:38 |
| sledges | who remembers the "planet" thing? ;) | 08:38 |
| abranson | Tweeting the forum post would be even more visible | 08:38 |
| piggz | i still subscribe to "planets" :) | 08:38 |
| 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 |
| ViGe | sledges: Just add .rss to any URL in the forum | 08:38 |
| dcaliste | It could be taken by community to write these digests, though | 08:39 |
| sledges | rubdos: ^ | 08:39 |
| sledges | err | 08:39 |
| sledges | gmc ^^ | 08:39 |
| sledges | #info one can add .rss to any URL in the forum to just pull in that blog-like form thread | 08:40 |
| 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 |
| 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:40 |
| rubdos | doesn't have to be weekly, monthly would also be very nice | 08:41 |
| gmc | could be a rotating job among those who are interested in this? | 08:41 |
| rubdos | the pace of projects like Rust is very high, so weekly makes sense there | 08:41 |
| 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:41 |
| sledges | dcaliste: ApBBB: this topic is about community updates, not Jolla's | 08:42 |
| sledges | what app developers are up to etc | 08:42 |
| rubdos | if you can do it by PR+review, it's almost no work for the responsible person | 08:42 |
| 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 |
| dcaliste | Oh, sorry misunderstood ! | 08:42 |
| gmc | not only app developers, but a more newspaper-like report of these meetings as well for eg | 08:42 |
| 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 |
| flypig | rubdos, I like that PR+review idea. | 08:42 |
| flypig | That really could cut down the effort. | 08:43 |
| abranson | piggz: and also very similar to how these meetings work | 08:43 |
| flypig | Have some markdown in a repo, then transfer it to the forum every fortnight or something. | 08:43 |
| rubdos | ah right, you can just make it Jekyll-style pull requests and have CI move them to the forum | 08:44 |
| Thaodan | flypig: Or pelican and run a ci job to generate the HTML | 08:44 |
| karry_ | I like the idea of aggregated changelogs from newly releases :-) | 08:44 |
| 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 |
| flypig | rubdos, Thaodan, yes, nice. | 08:44 |
| Thaodan | I use pelican for my homepage (thaodan.de) and it works quite well | 08:44 |
| chriadam | karry_: changelogs for releases are available already, right? | 08:45 |
| gmc | yeah pelican is great :) | 08:45 |
| cartron | sledges I have a #SailfishOS column in my tweetdeck to track that :) | 08:45 |
| Thaodan | Even works with org-mode which is the better markdown imho. | 08:45 |
| gmc | sledges: and not everyone is on twitter...... | 08:45 |
| sledges | exactly | 08:45 |
| gmc | especially the people I know who use sailfish, they tend to not be on twitter :) | 08:45 |
| Thaodan | Also twitter is a single point of failure which can break. | 08:45 |
| chriadam | karry_: at least, we used to publish those, e.g. https://together.jolla.com/question/191507/changelog-300-lemmenjoki/ | 08:46 |
| abranson | we also have other SoMe channels | 08:46 |
| sledges | chriadam: we still publish changelog on forum | 08:46 |
| chriadam | great | 08:46 |
| karry_ | chriadam: I have community applications in my mind | 08:47 |
| chriadam | oh I see | 08:47 |
| 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:47 |
| sledges | thanks all, will amalgamate ideas and see what comes out of them:) | 08:48 |
| sledges | #topic The state of Rust as (application) programming language for Sailfish OS (10 min -- asked by rubdos) | 08:48 |
| *** sailbot changes topic to "The state of Rust as (application) programming language for Sailfish OS (10 min -- asked by rubdos) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 08:48 | |
| sledges | #info <rubdos> Sailfish OS 3.4 introduced Rust support. I and others: | 08:49 |
| sledges | #link https://forum.sailfishos.org/t/rust-howto-request/3187/22 | 08:49 |
| 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 |
| sledges | #link https://gitlab.com/rubdos/whisperfish/-/merge_requests/5 | 08:49 |
| 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 |
| 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 |
| rubdos | I suppose that mostly answers the question indeed. | 08:50 |
| rubdos | There are quite a few practical problems with using Rust from the application perspective. | 08:51 |
| flypig | Could you briefly explain how you use rust to build your applications at the moment rubdos? | 08:51 |
| 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:51 |
| rubdos | Indeed, flypig, I think the answer to your question is "no", because "briefly" wouldn't really cut it. | 08:52 |
| flypig | :) | 08:52 |
| 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 |
| rubdos | this process also works using Debian as a host | 08:53 |
| 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 |
| rubdos | Fedora, notably running on my home server, doesn't have a complete-enough cross compilation environment for it to work. | 08:53 |
| rubdos | Indeed, chriadam, without UI components it's very easy :-) | 08:53 |
| rubdos | or easy-enough :P | 08:54 |
| ViGe | rubdos: Have you tried compiling your stuff with the Sailfish SDK? | 08:54 |
| 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 |
| rubdos | I've given it a shot | 08:54 |
| rubdos | but haven't tried for long enough, and I don't really recall what went wrong... | 08:54 |
| rubdos | (haven't had time lately, had too much other work on my head...) | 08:55 |
| 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:55 |
| 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 |
| rubdos | I will report back on compile issues, for sure. Any specific place where you want them reported? | 08:56 |
| 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 |
| 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 |
| 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:57 |
| 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:58 |
| rubdos | I've been diving way too deep in the Qt source for my own mental sanity before giving up on that :'-) | 08:59 |
| sledges | #info (discussing about adventures when building sfos apps with rust, also via sdk, using Whisperfish as reference) | 08:59 |
| rubdos | (basically, an ambience change in the system doesn't trigger a font color change in-app) | 08:59 |
| sledges | time's up, good talk indeed, will continue via forum's bug reports:) | 09:00 |
| sledges | #topic reappearing calenders after each sync (5 min -- asked by apozaf) | 09:00 |
| *** sailbot changes topic to "reappearing calenders after each sync (5 min -- asked by apozaf) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 09:00 | |
| sledges | #info any news or fix? Why is that [bug still] in 3.4? | 09:00 |
| sledges | #link https://forum.sailfishos.org/t/calendar-bug-for-disabled-calendars-in-3-4-ea/2563 | 09:00 |
| 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:00 |
| cartron | "our non-resident calendar expert" ^^ | 09:01 |
| 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 |
| cartron | I believe it also fixes deletion of a recurring event which is still displayed, as stated by flypig ? | 09:01 |
| 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 |
| cartron | chriadam I know :) | 09:01 |
| rubdos | chriadam: thanks, I'll note that in my bug tracker. | 09:01 |
| flypig | cartron, yes, it's a different bug/fix, but that should get fixed as well. | 09:02 |
| dcaliste | I must mentioned that flypig contributed also for the fix and he did all the work on Google plugin. | 09:02 |
| 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 |
| cartron | thanks flypig and dcaliste ! | 09:03 |
| sledges | thanks chriadam ! | 09:04 |
| sledges | 5mins gon, let's move on | 09:04 |
| sledges | #topic Silica components license and source code (15 min -- asked by Karry) | 09:04 |
| *** sailbot changes topic to "Silica components license and source code (15 min -- asked by Karry) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 09:04 | |
| 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 |
| 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:04 |
| sledges | #info Long version: | 09:05 |
| sledges | #link https://forum.sailfishos.org/t/silica-components-license-and-source-code/3561 | 09:05 |
| 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:05 |
| karry_ | The biggest issue that I see here is the unclear situation now... | 09:06 |
| karry_ | So, when it is was not decided, you are saying that it is proprietary, right? | 09:07 |
| dcaliste | sledges, what do you mean clean up the header ? Relicence to a proprietray one for the versions to come ? | 09:07 |
| sledges | dcaliste: i believe it referred to sailfishsilica-qt5-devel | 09:08 |
| rinigus | karry_: do I understand you right that we cannot use silica in gpl apps? | 09:08 |
| flypig | karry_, yes, the licence is proprietary. | 09:08 |
| rubdos | We can link to Silica, no? | 09:08 |
| piggz | rinigus: that would surely be unfortunate :D | 09:08 |
| gmc | i guess it depends on whether the app is a derivative work of silica? | 09:09 |
| gmc | but oh my, gpl legal arguments | 09:09 |
| rubdos | It would be very unfortunate. Not only Whisperfish is (A)GPL... and that cannot be changed because of libsignal. | 09:09 |
| 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 |
| karry_ | rinigus, my understand to GPL is, that you cannot link (share address space) GPL and proprietary code in one process | 09:09 |
| ViGe | https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException | 09:09 |
| abranson | there are gpl apps for windows... | 09:09 |
| piggz | ViGe: yeah, that seems to clear it up | 09:10 |
| flypig | ViGe, that's really helpful. | 09:10 |
| 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:10 |
| rinigus | ViGe thanks! | 09:11 |
| 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 |
| dcaliste | Eh sorry BSD, not LGPL. | 09:12 |
| rinigus | From this Jolla statement we can conclude that no Silica opening up is coming. | 09:13 |
| rinigus | Right? | 09:13 |
| jpetrell | dcaliste: clean up means updating the source code headers, silica C++ bits are still proprietary | 09:15 |
| karry_ | Thanks ViGe to link that exception. So, the trick is to call Silica "system library"... | 09:16 |
| 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:16 |
| dcaliste | Oh, I see now, it's about the headres, sorry. | 09:17 |
| jpetrell | dcaliste: I don't think that will change | 09:17 |
| 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 |
| chriadam | veskuh should probably field this question more comprehensively, I think | 09:18 |
| 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:18 |
| veskuh | Unfortunately, I lost internet for awhile on key momenent on this topic | 09:20 |
| sledges | veskuh: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-12-17-08.00.log.txt | 09:20 |
| veskuh | sledges, thanks | 09:20 |
| 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 |
| piggz | https://www.gnu.org/licenses/gpl-faq.en.html#WindowsRuntimeAndGPL | 09:22 |
| 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:22 |
| veskuh | We are in process of marking correct licenses on any packages where we know there is an error | 09:23 |
| 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 |
| sledges | #info <veskuh> We are in process of marking correct licenses on any packages where we know there is an error | 09:24 |
| sledges | well, silica is certainly not distributed with an app itself, so it'd qualify as System Library | 09:25 |
| piggz | sure | 09:25 |
| karry_ | Thanks. That anvers my question :-) And thanks that clarification of usage GPL code with proprietary system libraries... | 09:25 |
| sledges | #info <community> you can link a GPL app to Silica, because Silica qualifies as System Library | 09:26 |
| sledges | #link veskuh> We are in process of marking correct licenses on any packages where we know there is an error | 09:26 |
| sledges | #undo | 09:26 |
| sailbot | Removing item from minutes: <MeetBot.items.Link object at 0x7f3d2750a8d0> | 09:26 |
| sledges | #link https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException | 09:26 |
| sledges | #link https://www.gnu.org/licenses/gpl-faq.en.html#WindowsRuntimeAndGPL | 09:26 |
| sledges | dem click paste:) | 09:26 |
| sledges | thank you all for putting this together, moving on | 09:26 |
| piggz | and the actual GPLv2 words it like this: | 09:26 |
| 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 |
| 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:26 |
| sledges | #undo | 09:27 |
| sailbot | Removing item from minutes: <MeetBot.items.Info object at 0x7f3d288260f0> | 09:27 |
| sledges | #topic Wired headset media buttons don't work with Android apps (10 min -- asked by sailr) | 09:27 |
| *** sailbot changes topic to "Wired headset media buttons don't work with Android apps (10 min -- asked by sailr) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 09:27 | |
| sledges | #link https://forum.sailfishos.org/t/headset-media-buttons-dont-work-with-android-apps/2428 | 09:27 |
| 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 |
| sledges | #info <sailr> However, I want to use them with Android apps such as Spotify, but they don't seem to work. | 09:27 |
| 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 |
| 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 |
| 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 |
| 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:27 |
| 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 |
| sledges | i even found him mentioning it on #mer once:)) | 09:28 |
| sledges | but i'm not sure on the scope of this task as of yet | 09:29 |
| sledges | let's move to general discussion in case there still are comments to the points above | 09:32 |
| sledges | #topic General Discussion (10 min) | 09:32 |
| *** sailbot changes topic to "General Discussion (10 min) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 09:32 | |
| ApBBB | SOOOOO. whats comming for SFOS 4. can we have a sneak preview?? | 09:33 |
| fridl | #info fridl - community | 09:33 |
| 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:33 |
| piggz | fridl: just made it for the general discussion :D | 09:34 |
| ViGe | ApBBB: Nice try ;) | 09:34 |
| chriadam | I mean, most stuff is done in public repositories | 09:35 |
| ApBBB | ViGe a christmas gift of some sort. we 've been nice all year :P | 09:35 |
| sledges | piggz: nice idea, but i can't see this working on an OBS though | 09:35 |
| fridl | piggz: I have been watching, but did not want to disturb as I missed the right moment ;-) | 09:35 |
| karry_ | ApBBB few hints are hidden in translation strings ;-) | 09:35 |
| cartron | Sailjail :-) | 09:35 |
| cartron | (that's the only one I spotted) | 09:36 |
| 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 |
| sledges | #info a nice active activity over the festive holiday season: | 09:36 |
| sledges | #link https://forum.sailfishos.org/t/sailfish-devember-3-0/3322 | 09:36 |
| ApBBB | karry_ i know about the recorder. the app permision stuff. but we are translating 3.4 | 09:36 |
| 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 |
| ApBBB | i am sure 4 will have new android base. | 09:36 |
| dcaliste | ApBBB, look at https://github.com/sailfishos and the latest activity there. | 09:36 |
| dcaliste | There are ugrade-4.0.1 branches there. | 09:37 |
| 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:37 |
| piggz | k | 09:38 |
| 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:38 |
| piggz | yeah, that reminded me about the -boot one ... id forgot about the dhv pr | 09:39 |
| ApBBB | is there even the slightest chance for a newer Qt in 4?? | 09:39 |
| flypig | fridl, I think this isn't part of the public API currently. | 09:39 |
| 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 |
| piggz | ApBBB: cmon, its only 2020 :D | 09:39 |
| sledges | qt4 | 09:40 |
| piggz | sfos 4 with qt 6 | 09:40 |
| 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 |
| ApBBB | piggz we need some good news. :) | 09:40 |
| takimata70 | qt 6 may bring some other licensing issues... | 09:40 |
| sledges | nah, will just revert to qt4 to match versions ;) | 09:40 |
| ApBBB | hehe | 09:41 |
| chriadam | there's lots of good news, IMO. | 09:41 |
| ApBBB | with all the licence situation in QT seems more reasonable to change the toolkit completely :P | 09:41 |
| 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 |
| karry_ | another question is... when we may expect SFOS 4 ? :-D | 09:41 |
| ApBBB | karry_ that we know. when its ready :P | 09:42 |
| Thaodan | Soon | 09:42 |
| chriadam | soon (tm) / when it's ready, as per usual ;-) | 09:42 |
| sledges | karry_: the hint also is in the translation strings process ;) | 09:42 |
| sledges | and on this bombshell it's time to end | 09:43 |
| sledges | #topic Next meeting time and date (5 min) | 09:43 |
| *** sailbot changes topic to "Next meeting time and date (5 min) (Meeting topic: Sailfish OS, open source, collaboration -- 17th December 2020)" | 09:43 | |
| 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 |
| sledges | Proposing 14th January at 8am UTC | 09:43 |
| fridl | @flypig: Ok, thanks! | 09:44 |
| flypig | No NYE party meeting then :( | 09:44 |
| piggz | fridl: you need to jump on the rinigus components band wagon | 09:44 |
| chriadam | +1 for the 14th, sure. | 09:45 |
| chriadam | oh, and I hope everyone has a really great christmas and new year etc. | 09:45 |
| sledges | Season's greetings to y'all! | 09:45 |
| flypig | Yeah, sorry, that's +1 from me too. +similar Christmas and NY wishes. | 09:45 |
| sledges | #info Next meeting will be held on Thursday 14th January 2021 at 8:00am UTC: 2021-01-14T08Z | 09:45 |
| sledges | all have a nice rest from digitals, be more outdoorsy, and we'll come back in full strength after holiday period! | 09:47 |
| chriadam | thanks everyone! | 09:47 |
| karry_ | Thank you for the juicy meeting guys. Have a nice christmas! And be positive ;-) | 09:47 |
| sledges | #endmeeting | 09:47 |
| sailbot | Meeting ended Thu Dec 17 09:47:06 2020 UTC. | 09:47 |
| sailbot | Minutes: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-12-17-08.00.html | 09:47 |
| sailbot | Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-12-17-08.00.txt | 09:47 |
| sailbot | Log: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2020/sailfishos-meeting.2020-12-17-08.00.log.html | 09:47 |
| *** sailbot changes topic to "Next meeting will be held on Thursday 17th of December 2020 at 8:00am UTC. Topics can be read here: https://forum.sailfishos.org/t/community-meeting-on-irc-17th-dec-2020/3499" | 09:47 | |
| fridl | @piggz: was he interested in that special component or in more components generally? | 09:47 |
| flypig | Thanks sledges, merry christmas all. | 09:47 |
| piggz | fridl: its a full set of compoenents, which, when used, allows app to run on sailfish, desktop/kirigam, qqc2 and ubuntu-touch | 09:47 |
| piggz | messy christmas | 09:47 |
| sledges | vaskas: does your nickname actually mean „vaškas“? ;) | 09:48 |
| piggz | s/merry :D | 09:48 |
| sledges | I don't think it was a typo :D | 09:48 |
| piggz | well, not likely to me messy ....apart from the 5 days boris saays we can ;) | 09:48 |
| karry_ | messy :-D | 09:48 |
| fridl | @piggz: Ah, yes, I have seen that he made a way to compile as Kirigami as well. If I have time I'll adopt that. Its pretty cool! | 09:49 |
| sledges | will make a mess out of Christmas Eve dinner that's for sure (a big thing where i come from, minimum 12 dishes:) | 09:49 |
| piggz | fridl: yeah, im using it on amazfish now ... with people porting for postmartekos/manjaro now | 09:50 |
| abranson | piggz: we get one day over here in France. Xmas eve is the only night we're allowed out after 8pm :( | 09:50 |
| piggz | abranson: oof, thats gotta hurt | 09:51 |
| flypig | Only to go to church, I assume? | 09:51 |
| piggz | church with whiskey? | 09:51 |
| flypig | A new take on Communion, maybe? | 09:51 |
| abranson | i think we have one of those church things somewhere | 09:52 |
| flypig | :D | 09:52 |
| fridl | @piggz: Do you still build and compile all of that in Sailfish IDE or do you use an other environment to get e. g. the Kirigami part compiled? | 09:53 |
| piggz | fridl: for the deskopt kirigami build, i use regular qt creator that came with distro | 09:53 |
| fridl | @piggz: ok, nice | 09:55 |
| santhosh | sorry for sending message lately. I was waiting to send this in General Discussion as I couldn't join the meeting in time(lunch time here) but failed to do send it in time as I got a call. BlackBerry10 had few restrictions and how things worked for background process. this could help regarding the background process. | 09:55 |
| santhosh | https://developer.blackberry.com/native/documentation/device_platform/headless_apps/ | 09:55 |
| gmc | whoops sorry, trailed of there, $dayjob distraction, delivery at the door.. chaos! merry xmas all, happy devember! | 10:01 |
| flypig | santhosh, interesting + useful. Thanks! | 10:03 |
| rubdos | Sorry for the late thanks, but thanks for the nice meeting indeed! | 10:16 |
| *** santhosh-4759 is now known as santhoshm | 10:53 | |
| Nico[m] | Oh no, I overslept >.< | 12:06 |
| *** ChanServ changes topic to "Next meeting will be held on Thursday 14th of January 2021 at 8:00am UTC. Topics can be read here: https://forum.sailfishos.org/t/community-meeting-on-irc-14th-jan-2021/4030" | 12:59 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!