08:00:00 <rainemak> #startmeeting Sailfish OS, open source, collaboration -- 14th March 2024
08:00:00 <sailbot> Meeting started Thu Mar 14 08:00:00 2024 UTC. The chair is rainemak. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:00 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:00 <rainemak> #info Meeting information and agenda can be found here:
08:00:00 <rainemak> #link https://forum.sailfishos.org/t/community-meeting-on-14th-march-2024/18132
08:00:00 <rainemak> 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.
08:00:00 <rainemak> #topic Brief introduction (5 min). Please prefix your name/handle with #info
08:00:15 <rainemak> Wow, that was sharp 10:00
08:00:26 <rainemak> Not too many topics today but surely some will take more than proposed/reserved.
08:00:40 <rainemak> #info Raine Mäkeläinen, sailor @ Jolla, chairperson today
08:00:46 <nephros> #info nephros, community desktop portal poodle
08:00:54 <ViGe> #info Ville Nummela - community
08:01:12 <tuplasuhveli[m]> #info tuplasuhveli, community
08:01:15 <abr> #info Andrew Branson, sailing by
08:01:21 <voidanix[m]> #info voidanix - community, i think
08:01:30 <flypig> #info David Llewellyn-Jones, community
08:01:46 <pvuorela> #info Pekka Vuorela, Jolla
08:03:15 <Jetset> #info Jetset
08:03:44 <direc85[m]> #info Matti Viljanen, community
08:03:56 <Crabster> #info Crabster - lurker
08:04:50 <rainemak> very good number of participants
08:04:59 <rainemak> let's get going
08:05:08 <rainemak> #topic Increased root partition size on older devices (5mins -- asked by jojomen)
08:05:20 <rainemak> #info <jojomen> There are numerous threads here and in the old forum about people
08:05:20 <rainemak> #info <jojomen> running into trouble after filling up their root partition.
08:05:20 <rainemak> #info <jojomen> @olf has written a good guide on resizing it. However, it’s
08:05:20 <rainemak> #info <jojomen> tedious work on top of the already somewhat convoluted flashing
08:05:20 <rainemak> #info <jojomen> procedure, and low-level work on the storage config can be scary.
08:05:21 <rainemak> #info <jojomen>
08:05:23 <rainemak> #info <jojomen> Link to guide, that also has some links to forum topics about
08:05:25 <rainemak> #info <jojomen> resizing:
08:05:27 <rainemak> #link https://forum.sailfishos.org/t/problems-when-trying-to-resize-the-root-partition/10563/12
08:05:30 <rainemak> #info <jojomen> Having the SFOS installation image default to a 4 GB root
08:05:32 <rainemak> #info <jojomen> partition (same as newer devices) would make things easier, and -
08:05:34 <rainemak> #info <jojomen> as olf’s guide points out - an SD card can compensate for the 1.5
08:05:36 <rainemak> #info <jojomen> GB lost from the home partition.
08:05:38 <rainemak> #info <jojomen>
08:05:40 <rainemak> #info <jojomen> Would Jolla consider making this change or, if not, what are the
08:05:42 <rainemak> #info <jojomen> key factors against it?
08:05:44 <rainemak> #info <jojomen>
08:05:48 <rainemak> #info <jojomen> A comment from olf
08:05:50 <rainemak> #info <jojomen> …, but not automatically altering partition sizes on extant
08:05:52 <rainemak> #info <jojomen> SailfishOS installations.
08:05:54 <rainemak> #info <jojomen>
08:05:56 <rainemak> #info <jojomen> IMO, this simply requires changing two characters in a
08:05:58 <ExTechOp> #info Otto Mäkelä. community
08:05:58 <rainemak> #info <jojomen> configuration file and no extra quality assurance beyond review
08:06:00 <rainemak> #info <jojomen> and checking for typos, because the space on internal mass storage
08:06:02 <rainemak> #info <jojomen> (FLASH memory) is always sufficient for this on all supported
08:06:04 <rainemak> #info <jojomen> Xperia models.
08:06:06 <rainemak> #info <jojomen>
08:06:08 <rainemak> #info <jojomen> This measure would alleviate a very common failure mode for
08:06:10 <ExTechOp> (sorry for being a bit late)
08:06:10 <rainemak> #info <jojomen> SailfishOS upgrades and installing SailfishOS-native software: no
08:06:12 <rainemak> #info <jojomen> space left on root volume.
08:06:14 <rainemak> Sorry there will be longish answer
08:06:18 <rainemak> #info <Jolla> Let’s start from the problem. We’d like to first understand how
08:06:20 <rainemak> #info <Jolla> people end up running out space. What’s causing it? There shouldn’t
08:06:22 <rainemak> #info <Jolla> be anything blocking to increase root partition size for older
08:06:24 <rainemak> #info <Jolla> devices but only for flashable image (no resizing during upgrade).
08:06:26 <rainemak> #info <Jolla> Something similar that we did for newer devices.
08:06:28 <rainemak> #info <Jolla>
08:06:30 <rainemak> #info <Jolla> There are few scenarios that are easy to foresee / understand.
08:06:32 <rainemak> #info <Jolla>
08:06:34 <rainemak> #info <Jolla> From platform developer point of view root partition size can be
08:06:36 <rainemak> #info <Jolla> problematic especially if you’re working on large project(s) and
08:06:38 <rainemak> #info <Jolla> need debug symbols. First thing is to toggle on “Settings ->
08:06:40 <rainemak> #info <Jolla> Developer Mode -> Store debug symbols to home
08:06:42 <rainemak> #info <Jolla> partition” (alternative you can install package
08:06:44 <rainemak> #info <Jolla> jolla-developer-mode-home-debug-location). This way debug symbols
08:06:48 <rainemak> #info <Jolla> won’t consume space from root partition.
08:06:50 <rainemak> #info <Jolla>
08:06:52 <rainemak> #info <Jolla> Secondly using alternative Sailfish app stores might cause
08:06:54 <rainemak> #info <Jolla> problems. Of course, also just installing tons of apps.
08:06:56 <rainemak> #info <Jolla>
08:06:58 <rainemak> #info <Jolla> For apps we are considering something like /opt/apps/<app-name>/
08:07:00 <rainemak> #info <Jolla> application root path that would be out of root partition. Under
08:07:02 <rainemak> #info <Jolla> this application root path, developers should still use & follow
08:07:04 <rainemak> #info <Jolla> Filesystem Hierarchy Standard (FHS) for example like:
08:07:06 <rainemak> #info <Jolla>
08:07:08 <rainemak> #info <Jolla> /opt/apps/<app_name>/usr/bin/<app_name>
08:07:10 <rainemak> #info <Jolla> /opt/apps/<app_name>/usr/share/<app_name>/
08:07:12 <rainemak> #info <Jolla> /opt/apps/<app_name>/usr/share/applications/<app_name>.desktop
08:07:14 <rainemak> #info <Jolla>
08:07:18 <rainemak> #info <Jolla> There are two related goals that should be kept in mind:
08:07:20 <rainemak> #info <Jolla> 1) apps should not be installed to the root partition
08:07:22 <rainemak> #info <Jolla> 2) root partition should eventually be readonly
08:07:24 <rainemak> #info <Jolla>
08:07:26 <rainemak> #info <Jolla> If both of these would be met, then size of root partition would
08:07:28 <rainemak> #info <Jolla> not be that big of an issue. For time being maybe we just adjust
08:07:30 <rainemak> #info <Jolla> root partition for the older devices – we’ll comment this more a
08:07:32 <rainemak> #info <Jolla> bit later.
08:07:34 <rainemak> ExTechOp, no worries
08:08:29 <rainemak> Would somebody have case where you have run of space on root? What has caused it?
08:08:49 <voidanix[m]> waydroid
08:09:01 <nephros> rainemak: it is always apps, through to library packaging requirements making packages very small.
08:09:04 <nephros> sorry large.
08:09:34 <rainemak> voidanix[m], ok thank you
08:10:01 <rainemak> nephros, moving apps to out of root partition to let's say /opt/apps would help that
08:10:17 <voidanix[m]> w/ 4GB root you can install very few apps in the container; it installs itself in /opt/waydroid IIRC
08:10:24 <nephros> I guess, yes.
08:10:49 <direc85[m]> There's a nice application that lets you visualize the disk space used; Space Inspector.
08:10:57 <nephros> Maybe /opt/apps could even be something like unionfs, collecting apps from device storag, and SD card?
08:11:00 <rainemak> voidanix[m], it should probably create a symlink from /opt/waydroid to /home/.system/waydroid
08:11:06 <rainemak> this way it'd go to home
08:11:39 <direc85[m]> Using /opt/apps/ for user-installed applications sounds excellent!
08:11:46 <rainemak> thinking is that whatever is the size of the root partition, it can be filled
08:11:54 <nephros> One thing that is eating some space from the OS is l10n files.
08:12:14 <flypig> I agree, moving the app executable dir out of root makes sense.
08:12:15 <nephros> /usr/share/locale is 80+MB
08:12:16 <rainemak> it would like be a symlink to /home/.system/apps
08:12:45 <rainemak> flypig, target / goal is that eventually root partition would be turned to readonly
08:12:54 <flypig> Even better :)
08:12:55 <flypig> I've also experienced it (yesterday as it happens) installing libraries to /usr/lib64. But this was for development; not typical.
08:12:59 <voidanix[m]> direc85 wouldn't /usr/local/ be a better candidate?
08:13:20 <rainemak> flypig, that's platform dev headache :-) I feel you
08:13:26 <Thaodan> #info Björn Bidar - Sailor @ Jolla
08:13:32 <Thaodan> Sorry lost track of time
08:13:47 <nephros> FDO/FHS people do not like /usr/local
08:14:07 <Thaodan> They don't like /opt/apps either..
08:14:24 <nephros> true!
08:14:34 <rainemak> #info Extended topic by 5mins
08:14:36 <voidanix[m]> at least one is standardized across basically all distros
08:14:38 <flypig> What's the situation with apps on a multi-user device?
08:14:42 <rainemak> ~ minute to go
08:14:54 <rainemak> flypig, no difference
08:14:54 <Thaodan> I think /opt/apps is a solution for a problem that is self created that will create more problems
08:15:15 <flypig> App access is controlled by shortcuts?
08:15:33 <Thaodan> deduplication and using more of the unused storage should help further
08:15:41 <flypig> Or everyone has access to all apps?
08:15:43 <direc85[m]> voidanix Could be. Using /opt/ would keep the separation larger and simpler in my opinion. And in some distros /usr/local/bin and /usr/bin point to the same place.
08:15:45 <nephros> Another place for the OS that could be reviewed is /usr/share/fonts. That's 33MB, and maybe thinks like the symbola font are not necessary.
08:15:56 <rainemak> flypig, I'm not sure if I'm following
08:16:20 <abr> it'd be nice to see the old maemo word 'optification' brought back :)
08:16:22 <rainemak> flypig, Sailfish OS are shared for each device users... app specific data is user specific
08:16:41 <rainemak> have we covered this topic
08:16:47 <direc85[m]> Using something like /opt/apps/<username>/ could make per-user applications possible.
08:17:01 <flypig> rainemak, sorry, I'm describing it poorly, but you just answered me. I was wondering if there are user-specific apps, but there aren't (only user-specific data).
08:17:37 <direc85[m]> Actually, disregard my previous comment. ~/.local/bin is the place for per-user binaries.
08:17:37 <rainemak> over time already... let's move on
08:17:37 <Thaodan> nephros: Symbola is used for is used for emojiis? I think. not sure
08:17:56 <dcaliste> #info Damien Caliste, community
08:18:01 <dcaliste> Sorry to be late.
08:18:02 <Thaodan> Any work like we talk about should not be done before /usrmove is done
08:18:05 <nephros> Thaodan: yes, but there are better emoji fonts
08:18:35 <rainemak> I'll give 2 more mins
08:18:38 <voidanix[m]> direc85 sure, apps can also be snug under ~/.apps ala flatpak
08:18:48 <Thaodan> after usrmove we can separate /usr and /var better
08:18:56 <nephros> what's usrmove?
08:19:20 <Thaodan> nephros: /bin /lib -> to /usr/bin /usr/lib
08:19:20 <rainemak> as this discussion is flourishing
08:19:28 <nephros> ah that one.
08:19:43 <Thaodan> essentially you can remove all files from / that are in /usr and just have /usr as rootfs
08:19:48 <rainemak> discussion drifting quite a bit...
08:19:59 <rainemak> let's do not fix whole world now
08:20:15 <rainemak> sounds like a plausible newsletter topic actually
08:20:27 <rainemak> moving on
08:20:28 <rainemak> #topic RCS Messenging  (5mins -- asked by Cryx)
08:20:28 <Thaodan> is empty besides /etc and /var can be on a separate volume. The point is that don't add more mess before cleaning up.
08:20:39 <rainemak> #info <jojomen> RCS seems to be at least the new Standard as Apple jumps on that
08:20:39 <rainemak> #info <jojomen> train too (forced by the DMA of course…). On the long road RCS
08:20:39 <rainemak> #info <jojomen> will be the successor of SMS/MMS services. What’s the status for
08:20:39 <rainemak> #info <jojomen> RCS support on Sailfish OS?
08:20:39 <rainemak> #info <jojomen>
08:20:41 <rainemak> #info <jojomen> We brought that topic on from time to time here in the forum (not
08:20:42 <rainemak> #info <jojomen> just my me…), but it seems we never had that in a community
08:20:44 <rainemak> #info <jojomen> meeting. So, the main questions are if there was any
08:20:48 <rainemak> #info <jojomen> thinking/investigation if and how these services could be added
08:20:50 <rainemak> #info <jojomen> to SFOS.
08:20:52 <rainemak> #info <jojomen>
08:20:54 <rainemak> #info <jojomen> To my mind it’s an interesting topic to also now if this might be
08:20:56 <rainemak> #info <jojomen> possible as an implemented always on service like phone and SMS
08:20:58 <rainemak> #info <jojomen> (as, we all know that other native messengers need to run in
08:21:00 <rainemak> #info <jojomen> background to receive messages).
08:21:02 <rainemak> #info <jojomen>
08:21:04 <rainemak> #info <jojomen> As said above I’ll probably won’t make it into the meeting, but
08:21:06 <rainemak> #info <jojomen> in fact I’m just user and no dev and might not really help in the
08:21:08 <rainemak> #info <jojomen> discussion at all.
08:21:10 <rainemak> #info <Jolla> Thank pherjung for your checking what other distributions are doing
08:21:12 <rainemak> #info <Jolla> to enable Rich Communication Services (RCS). No findings.
08:21:14 <rainemak> #info <Jolla>
08:21:18 <rainemak> #info <Jolla> Apple’s jump was not forced by Digital Markets Act (DMA) as
08:21:20 <rainemak> #info <Jolla> iMessage was not deemed as gatekeeper by the European Commission.
08:21:22 <rainemak> #info <Jolla> Actually, Rich Communication Services (RCS) is not even mentioned
08:21:24 <rainemak> #info <Jolla> there.
08:21:26 <rainemak> #link https://ec.europa.eu/commission/presscorner/detail/en/mex_24_785
08:21:28 <rainemak> #info <Jolla>
08:21:30 <rainemak> #info <Jolla> The Rich Communication Services (RCS) has been “coming” around 15
08:21:32 <rainemak> #info <Jolla> years. Maybe now with Apple’s push it could really lift off and
08:21:34 <rainemak> #info <Jolla> GSMA will agree on standard. That said, it’s still a phone carrier
08:21:36 <rainemak> #info <Jolla> protocol just like SMS with similar security model.
08:21:38 <rainemak> #link https://en.wikipedia.org/wiki/Rich_Communication_Services
08:21:40 <rainemak> #link https://www.eff.org/deeplinks/2024/01/what-apples-promise-support-rcs-means-text-messaging
08:21:43 <rainemak> #info <Jolla>
08:21:45 <rainemak> #info <Jolla> We have been looking into this but so far always seen this as not
08:21:49 <rainemak> #info <Jolla> yet mandatory. Effort wise this is huge. Whether RCS would be
08:21:51 <rainemak> #info <Jolla> compatible with current messaging architecture is another big
08:21:53 <rainemak> #info <Jolla> topic.
08:21:55 <rainemak> #info <Jolla> Further, we should think & compare RCS to Signal for example.
08:21:57 <rainemak> #info <Jolla> Could/Should we somehow facilitate deeper Whisperfish integration –
08:21:59 <rainemak> #info <Jolla> maybe we should?
08:22:42 <flypig> We should!
08:22:43 <ExTechOp> (just a side note, dammit, why did they want to use the RCS acronym, the world is full of 3-letter acronyms, and they reuse the one for Revision Control System?)
08:23:10 <voidanix[m]> tbh RCS is not better than SMS - the reason it's getting adopted so much is because every phone ships Google Messages
08:23:10 <sebix[m]> switch to VCS (Version Control system) :)
08:23:15 <Thaodan> :D
08:23:18 <voidanix[m]> which is absolutely packed with proprietary extensions
08:23:25 <abr> I didn't know apple were going for RCS now. It's been in Google's messaging app for a while so that's going to be important
08:23:35 <rainemak> ExTechOp, hehe, indeed
08:23:55 <abr> but sfos messages need to support multi-user chats first. MMS does those. very popular in the US
08:24:01 <Thaodan> I think RCS will be necessary sooner or later.
08:24:20 <Thaodan> If we would have a connection manager that does rcs for telepathy it would be great.
08:24:22 <rainemak> Thaodan, eventually yes
08:24:23 <ExTechOp> I remember back when Sailfish started, the "selling point" of the device was thorough integration of the different messaging protocols, unfortunately it hasn't been like that for a while.
08:24:34 <ViGe> yup, when both google and apple use RCS, it's going to be expected to be supported by everyone.
08:24:37 <abr> the volte work implemented IMS a bit, which volte shares with RCS
08:25:11 <abr> but google uses a 3rd party to provide RCS iirc
08:25:14 <Thaodan> abr: Not really. IMS is done inside the modem mostly. Can we do RCS outside the modem using that?
08:25:15 <direc85[m]> As a Whisperfish dev, I know we'd love to be able to integrate into the OS in a Harbour compatible way. Whisperfish is already highly non-compatible. But that's another topic.
08:25:16 <rainemak> abr, +1 for multi-user chat
08:25:47 <voidanix[m]> I expect apple's implementation to be very barebones, not by choice, but because the standardized spec is
08:25:48 <Thaodan> Sailfish OS telepathy was the only one missing group chat ui
08:25:50 <abr> Thaodan: iiuc the modem provides the auth tokens for RCS
08:25:57 <Thaodan> abr: ah thanks
08:25:58 <abr> through ims
08:26:07 <abr> same for the wifi calling stuff
08:26:17 <abr> vowifi
08:26:27 <Thaodan> I think a requirement for rcs would be that all the volte stuff is available for all devices not just Jolla devices.
08:26:48 <Thaodan> my ports are volte capable but dont get access to them
08:26:52 <abr> not even sure if that's possible. it's all super proprietary isn't it
08:28:03 <rainemak> abr, these are all big items and I can almost surely say that we cannot pull them off this year... maybe plausible to get some of them done by doing together with you all
08:28:19 <Thaodan> That would be a great idea.
08:28:24 <abr> huge amount of work. might be good to try to do it with other distros
08:28:35 <Thaodan> If we can implement some of the enables for the community that would be great
08:28:41 <Thaodan> abr: agreed
08:28:49 <rainemak> abr, I thought the same regarding rcs
08:29:07 <abr> this apple news is good motivation
08:29:22 <Thaodan> however I wonder how can the work be shared in hybris vs mainline stacks
08:29:35 <rainemak> next by nephros is long one
08:29:38 <flypig> I think Jolla should be aiming to provide interfaces for others to add things to. A messaging interface that apps can plug in to (so messaging apps don't have to run services), and which different backends can attach to.
08:29:42 <Thaodan> plus it has to be independent of the network manager involved
08:30:03 <Thaodan> flypig: that's telepathy and the accounts framework..
08:30:13 <Thaodan> but both a a nono in harbour
08:30:15 <abr> multiuser chats for MMS would be really good baby step. need to know how those look
08:30:18 <nephros> ... and libsocialcache to a degree
08:30:18 <rainemak> alright, let's move on
08:30:37 <Thaodan> ping me on irc if help is needed :)
08:30:43 <abr> if that can be done in telepathy, then the likes of signal/whisperfish could be integrated too :)
08:30:50 <rainemak> #topic XDG Desktop Portals (10mins -- asked by nephros)
08:30:50 <rainemak> #info <nephros> Sorry for the wall-of text below. Most of it is informational
08:30:50 <rainemak> #info <nephros> -only/General Discussion, specific questions to Jollyboys in
08:30:50 <rainemak> #info <nephros> Part 2, below.
08:30:50 <rainemak> #info <Jolla> Too long post, so here’s a link to the post:
08:30:51 <rainemak> #link https://forum.sailfishos.org/t/community-meeting-on-14th-march-2024/18132/7
08:31:01 <direc85[m]> abr, agreed!
08:31:12 <rainemak> abr, yeap
08:31:17 <piggz> great work on the portal so far imo
08:31:36 <rainemak> #info <Jolla> Part 1 Informational: State of the PoC
08:31:36 <rainemak> #info <Jolla> Good to see progress!
08:31:36 <rainemak> #info <Jolla> Part 2 Questions to Jollyboys
08:31:36 <rainemak> #info <Jolla> a) Regarding naming, we’d propose to go with Sailfish as the
08:31:36 <rainemak> #info <Jolla> implementation will eventually be Sailfish OS specific. Whilst this
08:31:37 <rainemak> #info <Jolla> link regarding coding conventions points to apps it applies well
08:31:39 <rainemak> #info <Jolla> for platform development as well.
08:31:41 <rainemak> #link https://docs.sailfishos.org/Develop/Apps/Coding_Conventions/
08:31:43 <rainemak> #info <Jolla> So, D-Bus names org.sailfishos -prefix, use namespace Sailfish
08:31:45 <rainemak> #info <Jolla> Amber is meant for platform agnostic components.
08:31:49 <rainemak> #info <Jolla>
08:31:51 <rainemak> #info <Jolla> b) At this point LGPLv3+ is still problematic. If plausible, would
08:31:53 <rainemak> #info <Jolla> be simpler to rewrite those sources pulling in LGPLv3+ and go with
08:31:55 <rainemak> #info <Jolla> a compatible license.
08:31:57 <rainemak> #info <Jolla>
08:31:59 <rainemak> #info <Jolla> c) It should go to /var/lib/environment/nemo/[dd]-name.conf that
08:32:01 <rainemak> #info <Jolla> then gets included by user@.service
08:32:03 <rainemak> #info <Jolla>
08:32:05 <rainemak> #info <Jolla> d) Sounds like PartOf=user-session.target might be applicable.
08:32:07 <rainemak> #info <Jolla> Alternatively: Many services (e.g. ngfd) utilize “preinstalled”
08:32:09 <rainemak> #info <Jolla> WantedBy= user-session.target  symlinks in
08:32:11 <rainemak> #info <Jolla> user-session.target.wants -directory.
08:32:13 <rainemak> #info <Jolla>
08:32:17 <rainemak> #info <Jolla> e) Not really at this point
08:32:19 <rainemak> #info <Jolla>
08:32:21 <rainemak> #info <Jolla> Part 3 Questions to everybody
08:32:23 <rainemak> #info <Jolla> 1. Given that license is sorted out we could take this to the
08:32:25 <rainemak> #info <Jolla> github.com/sailfishos
08:32:27 <rainemak> #info <Jolla> 2. Other important things to add?
08:32:29 <rainemak> #info <Jolla>
08:32:31 <rainemak> #info <Jolla> Part 4 Informational: Future outlook and challenges
08:32:33 <rainemak> piggz, great progress indeed
08:32:50 <nephros> Thanks, good answers!
08:33:17 <Thaodan> c) Violates FHS. Eventually it would make sense to follow the environment.d standard.
08:33:44 <rainemak> Thaodan, we're not fixing that nemo thingie now
08:34:49 <rainemak> Thaodan, there are also some systemd related things that we should take into use ... but that's another topic as well
08:34:58 <direc85[m]> Great work with the portals! SailfishOS is turning into quite a versatile platform!
08:35:08 <nephros> One thing that needs to be thought about with Portals is the Permissions aspect.
08:35:21 <nephros> It kinda clashes with the SailJail concept.
08:36:06 <Thaodan> nephros: I'm not sure how the concept can be adjusted. I noticed Qt6 has permissions builtin but it also depends on the platform below.
08:36:10 <nephros> Portal does on-demand/on-access permissions, while SJ of course does everything at binary lanch.
08:36:48 <flypig> To add to what others said: amazing work nephros.
08:37:11 <abr> sailjail could be adjusted to provide everything that other permissions can control
08:37:29 <Thaodan> abr: question if firejail can be adjusted?
08:37:32 <rainemak> abr, i think so
08:37:43 <rainemak> Thaodan, or developed forward
08:37:44 <abr> firejail will mount whatever you tell it to
08:37:53 <rainemak> abr, yeap
08:38:24 <abr> so if you tell it to mount everything that other permissions can control, then it will. it's still important that it hides bits of the fs that apps should never be able to access, such as other app's data.
08:38:31 <rainemak> there will be easily work on the area of xdg-dbus-proxy
08:39:01 <Thaodan> abr: Of course it does but how does it handle cases where a permission doesn't exist anymore for an app at runtime?
08:39:22 <rainemak> one minute
08:39:28 <Thaodan> Firejail just executes a profile before starting and then continues without change.
08:39:32 <abr> then it would be up to the higher level permission system to handle that.
08:39:32 <nephros> The point is though, Portals are by design running outside the sandbox. So, e.g. the File picker can choose files that the app that it handed back the URIs cannot access.
08:40:19 <abr> wouldn't that be the case for other app container systems too e.g. flatpak?
08:40:34 <direc85[m]> The clash between portals and firejail is causing issues elsewhere too, so there may be some solutions out there already.
08:40:43 <nephros> One question from me: where do we continue architecutral/integration discussions? Forum? Github? elsewhere?
08:40:47 <rainemak> time is running out, moving on... sorry to stop this lively discussion... let's try to continue some discussion in the generic part
08:41:06 <rainemak> #topic Release of adaptation repos for devices dropped in SFOS 4.6 (2-3mins -- asked by nephros)
08:41:13 <rainemak> #info <nephros> Any chance of making available the necessary materials needed for
08:41:13 <rainemak> #info <nephros> community ports of devices whose support has been dropped for
08:41:13 <rainemak> #info <nephros> SFOS 4.6?
08:41:13 <rainemak> #info <nephros>
08:41:13 <rainemak> #info <nephros> Community porters may be able to continue support for older
08:41:15 <rainemak> #info <nephros> devices if enabled to do so.
08:41:18 <rainemak> #info <nephros>
08:41:20 <rainemak> #info <nephros> It would also be a nice legacy for the Jolla Tablet if it could
08:41:22 <rainemak> #info <nephros> live on a bit, something that was unfortunately not possible for
08:41:24 <rainemak> #info <nephros> the original Jolla phone. (Although I fear, of all the dropped
08:41:26 <rainemak> #info <nephros> devices, the chance for getting the Tablet materials is the
08:41:28 <rainemak> #info <nephros> slimmest.)
08:41:30 <rainemak> #info <Jolla> Jolla C & Tablet are tricky as there were some proprietary sources.
08:41:32 <rainemak> #info <Jolla> Sony Xperia X repositories are already available.
08:41:59 <rainemak> nephros, feel free to ping me if you need more info regarding xperia x
08:42:32 <nephros> rainemak: thanks, unfortunately my XC has developped bulging battery syndrome
08:42:50 <rainemak> I think this doesn't need more time
08:42:53 <rainemak> let's move on
08:42:53 <nephros> How about the Gemini?
08:43:01 <nephros> Is that also already out there?
08:43:10 <rainemak> Same as tablet i think
08:43:14 <nephros> OK
08:43:17 <rainemak> #topic Migrating alphabetical scrollbar to Silica (10mins -- asked by tuplasuhveli)
08:43:21 <Thaodan> In case one wants to start porting Xperia X I can help with starting the port and manage bugs. My project is open for more community ports
08:43:29 <rainemak> #info <tuplasuhveli> This idea rose from a conversation regarding Flowplayer 2,
08:43:29 <rainemak> #info <tuplasuhveli> but other SFOS apps could also benefit from the neat
08:43:29 <rainemak> #info <tuplasuhveli> scrollbar presented in SFOS People app. Could Jolla consider
08:43:29 <rainemak> #info <tuplasuhveli> adding the scrollbar into the Silica components?
08:43:29 <rainemak> #link https://github.com/sailfishos-applications/flowplayer
08:43:38 <rainemak> #info <Jolla> Yes, this could well be something to consider. It has some
08:43:38 <rainemak> #info <Jolla> references to contacts that should be cut before it could be even
08:43:38 <rainemak> #info <Jolla> considered to be moved to Silica. Very good suggestion! Needs more
08:43:38 <rainemak> #info <Jolla> thinking and planning.
08:44:29 <rainemak> tuplasuhveli[m], to complement above, this won't happen anytime soon I'd say
08:44:44 <tuplasuhveli[m]> Yeah, it doesn't sound like the number one priority :D
08:45:01 <rainemak> let's move on...
08:45:06 <rainemak> #topic Qt version (5mins -- asked by KeeperoftheKeys)
08:45:10 <rainemak> #info <KeeperoftheKeys> Sorry if this was recently discussed - I was just looking
08:45:10 <rainemak> #info <KeeperoftheKeys> up some documentation on certain QML elements and
08:45:10 <rainemak> #info <KeeperoftheKeys> realized that the oldest version of Qt that still has
08:45:10 <rainemak> #info <KeeperoftheKeys> documentation available is 5.15, while the Sailfish
08:45:10 <rainemak> #info <KeeperoftheKeys> documentation is very far from complete and relies on the
08:45:11 <rainemak> #info <KeeperoftheKeys> official Qt documentation. Though the documentation
08:45:13 <rainemak> #info <KeeperoftheKeys> thankfully still notes when things were added all in all
08:45:17 <rainemak> #info <KeeperoftheKeys> the situation to continue developing on much older
08:45:19 <rainemak> #info <KeeperoftheKeys> versions is getting worse also from the point of view of
08:45:21 <rainemak> #info <KeeperoftheKeys> being able to open docs and understanding what behaviour
08:45:23 <rainemak> #info <KeeperoftheKeys> should be.
08:45:25 <rainemak> #info <Jolla> You can find Qt 5.6 documentation here.
08:45:27 <rainemak> #link https://doc.qt.io/archives/qt-5.6/index.html
08:45:30 <rainemak> that you nephros for answering already in the forum thread
08:45:58 <rainemak> please, no need to go into Qt upgrade discussion now
08:46:10 <rainemak> I think this is covered
08:46:12 <rainemak> #topic Open PR discussion (5 mins -- asked by Jolla)
08:46:17 <rainemak> #info <Jolla> Any open PRs to discuss?
08:46:33 <Thaodan> The Qt 5.15 dopcumentation works quite well even fro Qt 5.6 as it mentions when a feature was changed/added
08:47:11 <direc85[m]> I'm interested in the state of Rust 1.75: https://github.com/sailfishos/rust/pull/22
08:47:24 <ViGe> I believe Qt 5.6 documentation is also bundled with the SDK
08:47:36 <direc85[m]> The last I head of it was the TMPDIR fix worked in OBS too.
08:48:02 <ExTechOp> Is there anything that Jolla folks might be able to divulge, eg. new hardware in the pipeline for SFOS?
08:48:15 <rainemak> direc85[m], if I'm not mistaken there were issues to build gecko esr78 against it
08:48:29 <rainemak> some back porting needed
08:48:44 <Thaodan> or flypig is faster XD
08:48:57 <rainemak> thus, I'd rush it in
08:49:09 <voidanix[m]> talking about backporting, what about kernel upgrades? https://github.com/mer-hybris/android_kernel_sony_msm/pull/136
08:49:30 <rainemak> direc85[m], hopefully this doesn't hinder much your Whisperfish development
08:49:42 <rainemak> Thaodan, yes esr91 is an option as well
08:49:48 <direc85[m]> rainemak Thanks for the info. I suppose this is something the community could try helping with?
08:50:21 <rainemak> will check
08:50:29 <ViGe> voidanix[m]: is there something particularly interesting in those upgrades?
08:50:42 <ExTechOp> Also, is there any work on the Sony binary blobs, if I've understood correctly the normal SFOS updates don't update them?
08:50:46 <voidanix[m]> other than a display fix for tama, not really
08:50:47 <direc85[m]> rainemak No, Whisperfish is well in the 1.75 era now! Our CI/CD uses a custom build image with updated Rust too, so we're covered.
08:51:09 <rainemak> direc85[m], very good
08:51:21 <voidanix[m]> i'm looking into fixing more tama things in the future, but the port pulls from the mer-hybris kernel
08:51:46 <rainemak> #action Check voidanix[m] comment, talking about backporting, what about kernel upgrades? https://github.com/mer-hybris/android_kernel_sony_msm/pull/136
08:52:17 <rainemak> As there are no bug reports today. Let's move to general discussion. We could spend a few minutes there.
08:52:28 <rainemak> #topic General discussion (6 min)
08:52:40 <Thaodan> ExTechOp: We/I have figured out on how to manage the issue but it requires work to do it properly in the ui. For community ports I would work on the lower level parts such as the initrd to check the right blob version to avoid issues.
08:52:44 <rainemak> I have one myself...
08:52:45 <rainemak> Would somebody like to volunteer to be translation coordinator for Finnish language?
08:52:45 <rainemak> #link https://docs.sailfishos.org/Develop/L10n/#coordinators
08:53:15 <Thaodan> I would try out the kumano port as the first port to test the upgrade process.
08:53:48 <Thaodan> But first I had to figure out os upgrades for community ports through the ui which is done now
08:54:34 <ExTechOp> Thaodan Excellent! I'm sure we'll hear from you once things progress.
08:54:56 <rainemak> Thanks for each participants... I enjoyed hosting this once again! What a great discussion we had!
08:55:17 <voidanix[m]> Thaodan I'm not sure about upgrading the binaries, they are proprietary sony stuff
08:55:32 <rainemak> before somebody says, there was a question from this morning as well... let's cover that in the forum
08:55:36 <direc85[m]> rainemak I can be a coordinator.
08:55:44 <ExTechOp> Is there anything that (the company formerly known as) Jolla folks might be able to divulge, eg. new hardware in the pipeline for SFOS?
08:56:00 <direc85[m]> (Here I go, assuming Finnish was handled in-house!)
08:56:08 <Thaodan> voidanix[m]: we're not upgrading the binaries but providing ui/guidance to upgrade them during the upgrade or download them so the installer can flash them
08:56:50 <rainemak> ExTechOp, I commented about Sony xperia 10 IV & 10 V in the last newsletter
08:56:57 <rainemak> ExTechOp, will dig out a link for you
08:57:02 <ExTechOp> Thanks!
08:57:08 <voidanix[m]> Thaodan: ah, I see
08:57:17 <rainemak> #link https://forum.sailfishos.org/t/sailfish-community-news-7th-march-2024-eula/18184
08:58:45 <rainemak> direc85[m], give a look to the link regarding coordinators and the last paragraph
08:59:06 <direc85[m]> Will do!
08:59:06 <rainemak> direc85[m], and thank you for volunteering
08:59:23 <rainemak> let'
08:59:28 <rainemak> let's schedule next meeting
08:59:35 <rainemak> #topic Next meeting time and date (1 mins)
08:59:41 <rainemak> Proposing Thursday 28th March at 08:00am UTC
09:00:24 <direc85[m]> Works for me
09:00:27 <flypig> Right before Easter. LGTM.
09:00:52 <ExTechOp> Works for me too
09:00:54 <rainemak> correct
09:01:24 <rainemak> let's it then
09:01:25 <rainemak> #info Next meeting will be held on Thursday 28th March 2024 at 08:00am UTC: 2024-03-28T0800Z
09:01:30 <rainemak> #endmeeting