07:00:03 <ViGe> #startmeeting Sailfish OS, open source, collaboration -- 22nd June 2023
07:00:03 <sailbot> Meeting started Thu Jun 22 07:00:03 2023 UTC. The chair is ViGe. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:03 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:00:09 <ViGe> #info Meeting information and agenda can be found here:
07:00:12 <ViGe> #link https://forum.sailfishos.org/t/community-meeting-on-irc-22nd-june-2023/15830
07:00:17 <ViGe> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and bee-hive.
07:00:21 <ViGe> #topic Brief introduction (5 min). Please prefix your name/handle with #info
07:00:27 <poetaster> #info poetaster community
07:00:40 <ViGe> #info Ville Nummela, sailor @ Jolla, chairperson today
07:00:52 <rainemak> #info Raine Mäkeläinen, sailor @ Jolla
07:00:54 <flypig> #info David Llewellyn-Jones, community
07:00:56 <sledges> #info Simonas Leleiva -- privateer for Jolla
07:01:04 <karry> #info Lukáš Karas, community
07:04:13 <ViGe> 3-3
07:04:42 <poetaster> let's not think in adverserial terms :)
07:05:06 <ViGe> #topic User space low memory killer (5-10 min -- asked by karry)
07:05:11 <ViGe> #info <karry> Many users, including me, are not satisfied with current behavior of low-memory-killer kernel module.
07:05:15 <ViGe> #info <karry> Even Android moved from kernel module to more flexible user-space lmkd.
07:05:18 <ViGe> #info <karry> I'm not saying that it would solve all memory related issues, but some flexibility would help here.
07:05:21 <ViGe> #info <karry> Is there any plan to move to user space implementation for SFOS? What implementation?
07:05:24 <ViGe> #info <karry> lmkd from android, systemd-oomd, facebook's lmk or other implementation?
07:05:27 <ViGe> #info <karry> Is there something where community may help?
07:05:33 <ViGe> #info <Jolla> We are investigating possible solutions.
07:05:37 <ViGe> #info <Jolla> It's worth noting that because of the different adaptations and kernel versions, different devices may need different approaches.
07:07:53 <flypig> karry, could you briefly explain the benefits of switching? Is it a case of the user-space approach being more user-configurable?
07:08:08 <ViGe> sledges probably knows more about this topic, so you might want to share some insight?
07:08:38 <sledges> in 4.4.0 we have disabled lmkd that was inside Android AppSupport container
07:08:54 <sledges> this greatly improved app killing management especially on Xperia 10 II
07:09:19 <sledges> before that, all android apps would still be running due to wrong oom score set by appsupport's lmkd
07:09:28 <sledges> leaving less and less memory slice for native apps
07:09:37 <karry> exactly, user space approcach may provide better configurability. right now, kernel lowmemorykiller is able to kill multiple apps in one round...
07:10:13 <sledges> we also had issues where native browser is never killed, this was also fixed in 4.4.0
07:10:19 <karry> ...it is able to kill music player playing the background with few megs of memory...
07:10:49 <rinigus> sledges: that lmkd disabling was done on each port separately, right?
07:11:02 <sledges> was done in appsupport once and for all
07:11:19 <sledges> except older devices where older appsupport runs
07:12:05 <rinigus> sledges: thanks! ok if it is regarding appsupport then no diff for community ports
07:12:17 <karry> what are the aspects that require different approaches on different devices?
07:12:53 <ViGe> karry: I would think kernel version and different amount of RAM
07:14:13 <poetaster> having a 6GB device (Rephone, piggz port), I noticed that RAM pressure was often not the cause of issues I had assumed. Browser for instance. It's not low memory.
07:14:29 <poetaster> not to see it's not 'memory' writ large.
07:14:36 <ViGe> #info <sledges> in 4.4.0 we have disabled lmkd that was inside Android AppSupport container
07:15:01 <ViGe> let's move on to next topic
07:15:04 <ViGe> #topic python3-sympy, python3-mpmath (10-15 min -- asked by poetaster)
07:15:09 <ViGe> #info <poetaster> Is it possible for these to allowed in harbour? I alone have 3 apps using them and packaging for harbour is a real pita.
07:15:14 <ViGe> #info <poetaster> sympy is also quite large (end up with 10+mb rpm).
07:15:18 <ViGe> #info <poetaster> With @nephros help I have them in chum which is nice, but as with Jollas efforts for PIL, having packaged solution is not just much more convenient, but more sustainable.
07:15:25 <ViGe> #info <Jolla> Short answer: Not in the near future
07:15:28 <ViGe> #info <Jolla> Longer answer:
07:15:31 <ViGe> #info <Jolla> While having community packaging these certainly help, there is still substantial amount of work left, especially when you consider future maintenance.
07:15:35 <ViGe> #info <Jolla> Therefore, we must consider carefully each package, before committing into maintaining it.
07:16:23 <poetaster> Yes, that's clear. Sympy is non-trivial.
07:18:00 <poetaster> I'll try to improve the state in obs, aiming at the simplicity of a submodule.
07:18:02 <flypig> I totally understand the caution about adding new packages. But poetaster's maths apps are really great: they offer really nice functionality :)
07:20:27 <flypig> poetaster, do you have to make changes to the packages to get them to work? Or are they equivalent to a pip install from the your packages identically to a pip installed version?
07:20:57 <flypig> (hopefully you can decipher that!)
07:21:40 <poetaster> the main reason I asked is that installs for harbour, I'm still using the evil: #python3 setup.py install --root=%{buildroot} --prefix=%{_datadir}/%{name}/
07:22:23 <poetaster> Is pip install actually allowed in harbour?
07:22:26 <ViGe> I wouldn't call that evil. That's just the way it has to be in order to get them into harbour.
07:22:52 <poetaster> ah, ok. It makes doing rapid releases very, very much less than rapid.
07:23:16 <dcaliste> #info Damien Caliste, community
07:23:20 <dcaliste> Sorry to be late.
07:23:24 <poetaster> I wonder, if the github actions builds would make it into harbour?
07:23:26 <flypig> I was thinking the same question poetaster. I suppose harbour only allows system python packages. You can't do a virtual environment or anything like that.
07:24:52 <poetaster> Hmm. I'm using actions to build on github, so maybe that's my short term solution. I just have very short release cycles at the moment and it kills my productivity.
07:26:21 <ViGe> Well there's nothing in Harbour that should prevent you from using github builds. Then again, we don't support that, so you get to keep both pieces every time something breaks.
07:26:46 <poetaster> ViGe, I'm the owner of the issue queue :)
07:27:21 <poetaster> Ok, so I'll try that on the next run and report in the forum.
07:28:49 <ViGe> Maybe it's time to move on
07:28:49 <poetaster> Ok, I have a roadmap. thanks!
07:28:54 <ViGe> #topic Open PR discussion (5 mins -- asked by jolla)
07:29:02 <ViGe> #info <jolla> Any open PRs to discuss?
07:31:02 <poetaster> oh, just a question if that url update on the geoservices plugin actually worked?
07:34:16 <ViGe> poetaster: I had to go back to the PR to remind me of what we discussed there... It seems I'm still waiting for your decision on what you are about to do ;) I haven't tried the new URLs
07:35:43 <dcaliste> For reference this is https://github.com/sailfishos/qtlocation/pull/2 (I guess)
07:35:52 <ViGe> yes, that's the one
07:36:33 <poetaster> ah, ok. I thought, see if we get minimal functioning OSM and then work on a minimal backport ... 5.8 is so far from 5.4 that a backport per se is not doable. I did up to 5.6 and realized the license issues wouldn't let me get further.
07:37:27 <ViGe> poetaster: could you squash the commits in the PR? I could then test it and if it works we could merge it. We would at least have something that works.
07:38:04 <poetaster> it's easier to squash on merge, isn't it? but, sure.
07:38:27 <ViGe> No it's really not
07:38:34 <poetaster> Okidoke.
07:38:53 <ViGe> Let's move on
07:38:55 <ViGe> #topic General discussion (20 min)
07:40:21 <sledges> more on the OOM topic: I refreshed my memory (if you pardon the pun) -- appsupport's lmkd used to set oom score in such way that all android apps get killed very aggressively
07:40:40 <sledges> to such extent that they would even not launch anymore (get killed on startup)
07:40:51 <sledges> native apps wouldn't get killed as a result
07:41:02 <sledges> so all that was fixed since 4.4.0
07:41:10 <sledges> also about e.g. facebook's oom:
07:42:06 <sledges> Thaodan found that we need cgroups2 for it, which we don't use at the moment iirc: https://github.com/facebookincubator/oomd/blob/main/docs/production_setup.md#cgroup2
07:43:01 <ViGe> So that's not suitable for us, at least not at the moment
07:43:12 <sledges> right
07:47:41 <poetaster> ViGe, commits squashed.
07:48:38 <ViGe> poetaster: thanks! I can't really promise when I have time to test it. Perhaps you can suggest a good way to test? i.e good test application?
07:52:49 <poetaster> I was using the qt test app but I was working on one ... I'll dig it up.
07:53:03 <ViGe> thanks
07:53:52 <poetaster> https://openrepos.net/content/rikujolla/draft-map was one I wanted to fix.
07:55:16 <ViGe> that looks interesting
07:55:42 <poetaster> indeed.
07:58:02 <ViGe> #topic Next meeting time and date (5 min)
07:58:08 <ViGe> The summer vacations are upon us, so there will be a gap between the meetings now.
07:58:13 <ViGe> Proposing Thursday 17th August at 07:00am UTC.
07:59:33 <flypig_> Hope you all have a wonderful break!
08:00:00 <poetaster> yes, have fun!
08:01:40 <ViGe> personally, I'm planning to go somewhere where there isn't any kind of mobile network coverage, so I'm sure it will be wonderful :)
08:01:58 <dcaliste> Enjoy the summer (or winter) period.
08:03:05 <ViGe> I don't see anyone complaining, so:
08:03:07 <ViGe> #info Next meeting will be held on Thursday 17th August 2023 at 07:00am UTC: 2023-08-17T0700Z
08:03:15 <ViGe> Thanks for the meeting everyone!
08:03:20 <ViGe> #endmeeting