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