Community meeting on 14th March 2024

Announcements
#3

@Jolla, please note that @jojomen merely asks for …

…, but not automatically altering partition sizes on extant SailfishOS installations.

IMO, this simply requires changing two characters in a configuration file and no extra quality assurance beyond review and checking for typos, because the space on internal mass storage (FLASH memory) is always sufficient for this on all supported Xperia models.

This measure would alleviate a very common failure mode for SailfishOS upgrades and installing SailfishOS-native software: no space left on root volume.

7 Likes
#4

Exactly. Primarily, I want (re-)flashing to use better defaults in order not to end up in the same out-of-space, upgrade blocking state again.

(But, of course, bonus points for an easy to use and properly tested way to do it on an existing install.)

4 Likes
#5
  • Name/IRC nick: Cryx
  • Topic: RCS Messenging
  • Some details about the topic: RCS seems to be at least the new Standard as Apple jumps on that train too (forced by the DMA of course…). On the long road RCS will be the successor of SMS/MMS services. What’s the status for RCS support on Sailfish OS?
  • Approx. time needed: 5
  • Substitute (optional): Don’t know if I will make it into the meeting due to work

We brought that topic on from time to time here in the forum (not just my me…), but it seems we never had that in a community meeting. So the main questions are if there was any thinking/investigation if and how these services could be added to SFOS.
To my mind it’s an interesting topic to also now if this might be possible as an implemented always on service like phone and SMS (as, we all know that other native messengers need to run in background to receive messages).

As said above I’ll probably won’t make it into the meeting, but in fact I’m just user and no dev and might not really help in the discussion at all.

(If I missed thst we already had that topic just drop it from the meeting.)

3 Likes
Add RCS Service support to Messages app
#6

It would be nice to see what other distributions are doing to enable RCS. I’ll try to update this comment if I find something.

Edit: So far I have not found anything. :frowning:

5 Likes
#7
  • Name/IRC nick: nephros
  • Topic: XDG Desktop Portals
  • Some details about the topic:
    Sorry for the wall-of text below. Most of it is informational-only/General Discussion, specific questions to Jollyboys in Part 2, below.
  • Approx. time needed: 10 Minutes for answers? Plus General Discussion
  • Substitute (optional): Meeting time is always hard for me to meet because of dayjob. I will try to, but can not guarantee that I will be able to comment. I can guarantee to be lurking/following the discussion as best I can and if necessary respond later.

Part 1: Informational: State of the PoC
The Proof-of-concept implementation of XDG Desktop Portals has been begun and has reached a stage where it at least can do some things. This follows the suggestions/agreements reached in the previous Meeting discussion.

  • An analysis/comparison of the specification and existing Sailfish OS functionality has been done and documented here. At the moment this has been done solely by me and is not aligned with anyone or anything (so it’s basically my opinion), but may serve as a starting point.
  • Low-hanging-fruit implementations have been done: Wallpaper, Screenshot, and Email portals (and Access as a dependency of Screenshot), leveraging existing SFOS interfaces.
  • A real-world demo/use case which shows why Portals are useful has been brought forth by community developer piggz: Kirigami-based apps (from Chum) currently display Kirigami-native file picker dialogs, which are not usable on Sailfish OS. The PoC implementation of the FileChooser portal solves this by enabling Kirigami apps to use Portals to launch a SFOS-native dialog.
    This implementation (and to a degree the others) shows a point where additions from Jollyboys would be needed: it requires UI components to be available, which act similarly to the dialogs from e.g. lipstick-{security,bluetooth}-ui, and lipstick-windowprompt.
    (Note that a very similar use-case exists for the mozilla-based Browser, which also has the capability to use portals. This may present the opportunity to reduce Browser-specific UI components if implemented more generically.)

Interested developers from the Community and from Jollyboys are invited to have a look. Basic instructions for testing are available here.

Part 2: Questions to Jollyboys

Assuming there is interest from the Jollyboys side to collaborate on this effort, please provide guidance on:

a) Naming things: I have chosen the name Amber for the implementation. I did not want to use things like Jolla, Sailfish, or Chum/Community (or legacy names like Nemo) because the aim is for everybody to collaborate on this, and there is some existing “middleware-like” components in SFOS called Amber.
The name appears in the binary names, D-Bus names, config directives (and obviously the package name). Are we ok to continue to use that name, e.g. because of existing conventions re. the Amber name? Suggestions for a better name otherwise?
b) Licensing: because I took some things from existing portal implementations of the KDE and lxqt projects, licensing for the c++ parts is currently a mix of LGPL2+ and LGPL3+. My own additions of UI components are currently Apache-2.0. Any objections/comments on that in the ligtht of mayyybe shipping this with SFOS proper at some point?
c) Technical details I: one of the dbus-services involved needs an environment variable set (XDG_CURRENT_DESKTOP), and this should be available to other software as well. Which is the correct place to do that? Is it ok/sufficient to place a file at /var/lib/environment/compositor/foo.conf?
d) Technical details II: The upstream portal systemd units currently use PartOf=graphical-session.target to launch. I understand this target currently does nothing on SFOS. Which unit/target would be the correct one?
e) Any other comments on this in general and how to proceed?

Part 3: Questions to everybody

  1. Continuing development Where shall the main codebase live?
    • leave as-is on github.com/nephros, do the usual PR/issue stuff, otherwise this stays as nephros pet project
    • moving a dedicated public github organisation
    • moving sailfishos-chum github organisation
    • some kind of secret-cabal type of arrangement
    • other
  2. Other important things to add?

Part 4: Informational: Future outlook and challenges

In order to keep this Topic brief (I failed, I know) I have listed some of the outlook and future benefits/challenges here. Interested parties are again invited get some further infos there.

References:

8 Likes
#8
  • Name/IRC nick: nephros
  • Topic: Release of adaptation repos for devices dropped in SFOS 4.6
  • Some details about the topic:

Any chance of making available the necessary materials needed for community ports of devices whose support has been dropped for SFOS 4.6?
Community porters may be able to continue support for older devices if enabled to do so.

It would also be a nice legacy for the Jolla Tablet if it could live on a bit, something that was unfortunately not possible for the original Jolla phone. (Although I fear, of all the dropped devices, the chance for getting the Tablet materials is the slimmest.)

  • Approx. time needed: 2-3min
6 Likes
Community meeting on 28th November 2024
#9
  • Name/IRC nick: tuplasuhveli
  • Topic: Migrating alphabetical scrollbar to Silica
  • Some details about the topic: This idea rose from a conversation regarding Flowplayer, but other SFOS apps could also benefit from the neat scrollbar presented in SFOS People app. Could Jolla consider adding the scrollbar into the Silica components?
  • Approx. time needed: 10mins
  • Substitute (optional): I’ll be present, but I would appreciate it, if someone more knowledgable would be able to attend as well.
6 Likes
#10
  • Name/IRC nick: KeeperoftheKeys
  • Topic: Qt version
  • Some details about the topic: Sorry if this was recently discussed - I was just looking up some documentation on certain QML elements and realized that the oldest version of Qt that still has documentation available is 5.15, while the Sailfish documentation is very far from complete and relies on the official Qt documentation. Though the documentation thankfully still notes when things were added all in all the situation to continue developing on much older versions is getting worse also from the point of view of being able to open docs and understanding what behaviour should be.
  • Approx. time needed: 5-10min
  • Substitute (optional): I don’t know that I can make it but I’m sure you don’t need me to discuss & answer this, the issue has been requested ad nauseam in the past maybe under new management this can finally be done?
4 Likes
#11

While direct links and search results do usually point to 5.15, there is documentation for older Qt releases at:
https://doc.qt.io/archives/index.html

4 Likes
#12

5.15 is in chum if you dont mind not using silica :slight_smile:

3 Likes
#13

Shouldn’t it read “dropped after SFOS 4.6” instead of “dropped in SFOS 4.6” ?
As I understand, Xperia X will get 4.6 but not 4.7 …

Anyway, your point is still valid…

3 Likes
#14
  • Name/IRC nick: rgrnetalk
  • Topic: response time store qa
  • Some details about the topic: I have submitted an update for one of my apps more than three weeks ago without any response so far. Others have as well as described here. Does the qa of the store has lower priority because of the new release or is something else the case?
  • Approx. time needed: 3 minutes.
  • Substitute (optional): None. If I can’t make it, I’d be happy with just a reply
1 Like
#15

Minutes: #sailfishos-meeting: Sailfish OS, open source, collaboration -- 14th March 2024
Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2024/sailfishos-meeting.2024-03-14-08.00.txt
Log: #sailfishos-meeting log

3 Likes
#16

First of all, apologies regarding response delay in store QA. We’re busy at the moment – being it Sauna release, getting last final bits ironed out, we just ramped up new shop platform, etc. A lot of exciting things happening.

Unfortunately this didn’t hit the community meeting itself.

@rgrnetalk I hope this answer satisfy your question and we do not need to postpone this to the next meeting.

7 Likes
Store on Vacation?
#17

Thanks for the answer, apparently no need to prepare it :wink: I’ll wait a bit then

#18

@rainemak et al, some comments from my side WRT discussing to expand the root volume size of all SailfishOS flashing images to 4000 MByte.

08:05:08 <rainemak> #topic Increased root partition size on older devices (5mins – asked by jojomen)
08:05:20 <rainemak> #info <jojomen> <Content of @jojomen’s post above>
…
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.

For almost a decade, I do not comprehend why this seems to be so hard to understand, because I ran into this issue with every device since the original Jolla phone (which did not have a fixed sized root volume due to BTRFS); this is why I developed and documented the aforementioned section of my SailfishOS installation guide on how to expand the root volume afterwards.
When Jolla released their SailfishOS flashing image for Xperia 10 II with a 4000 MByte root volume (v4.1.0 in April 2021) and later the one for Xperia 10 III, too, I assumed Jolla would have finally understood the issues the tiny root volume causes; apparently that was a misinterpretation on my side. A bit of a conundrum is since 2021, why Jolla has increased the root volume size for Xperia 10 II & III flashing images, but refrains to do that for older, supported models.

08:06:30 <rainemak> #info <Jolla> There are few scenarios that are easy to foresee / understand.
08:06:32 <rainemak> #info <Jolla>
08:06:54 <rainemak> #info <Jolla> … Of course, also just installing tons of apps.

Well, what Jolla may call “tons of apps” (because there are only very few in the Jolla Store) is just 50 to 150 in my case. Additionally a couple of command line tools from Jolla’s repository: bash, less, screen and some more. Two examples to visualise the issue:
a. (on the left) @ohnonot’s Xperia XA2 on SailfishOS 4.5.0 with just a few apps installed and the original root volume size (2500 MBytes).
b. (on the right) My old Xperia X on SailfishOS 3.2.1 with ca. 150 apps installed, additionally couple of command line tools provided by Jolla and expanded root volume size (4000 MBytes).

Screenshot_20240316_002
Screenshot_20240316_0021080×1920 517 KB
Screenshot_20240317_001
Screenshot_20240317_0011080×1920 172 KB

No debug info and dumped cores on both, but if you add up the 1500 MByte SailfishOS (including some additional tools), 375 MByte AlienDalvik (based on AOSP 11) and 500 MByte apps, these 2375 MByte leave just 125 MByte free on the original root volume size and are half of the 10% free filesystem capacity usually suggested as “manoeuvring space” for a filesystem to work well. It then takes some accumulated system log files or transient data during the mass installation of RPM files in the course of a SailfishOS upgrade to cause “no space left on root volume”.

The most common effect this has, is that SailfishOS upgrades fail: After downloading the aggregated RPMs and triggering the upgrade procedure, the device reboots to “upgrade mode”, starts to install the upgrade and then the progress bar hangs forever shortly before reaching 100%. After that the SailfishOS installation may be defunct (i.e. does not fully boot to the desktop / “launcher”), boot successfully and the old release seems to be installed, or boots successfully and the new release seems to be installed, but only partially is. There is no indication what went wrong (besides the upgrade process obviously did stall) and that the reason was “no space left on root volume”. One has to know to read and how to interpret /var/log/systemupdate.log to comprehend the reason. Jolla usually advises to reflash SailfishOS after an SailfishOS upgrade failed multiple times or if a SailfishOS installation misbehaves, which temporarily resolves the situation until the user installs the software (s)he had installed before. :frowning_face:

A root volume size of 4000 MByte provided by all SailfishOS flashing images (i.e. for all supported models) would at least alleviate this issue for users which follow Jolla’s advice to reflash.

Side note: It would be really helpful, if the SailfishOS updater displays an error message, at least for the most common failure modes (among them “no space left on root volume”), instead of just letting the progress bar cease to progress. To keep displaying a progress bar when an unrecoverable error occurred is rather disguising what happened.

08:07:28 <rainemak> #info <Jolla> … For time being maybe we just adjust
08:07:30 <rainemak> #info <Jolla> root partition for the older devices – …

Please do so!
And please do avoid requiring 6 years again (from 2015 to 2021) to extend the present solution (since 2021) to the whole set of supported devices.

8 Likes
#19

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. …

Some considerations WRT the idea to make the root volume read-only in the long run by suggesting to app developers to install their apps to /opt/apps/<app_name>/usr/bin/<app_name>, /opt/apps/<app_name>/usr/share/<app_name>/ and /opt/apps/<app_name>/usr/share/applications/<app_name>.desktop:

  • This is basically unrelated to discussing the size of the root volume. If one sees this as a solution for the tiny root volume size of 2500 MByte, I fully concur with this statement:
    08:14:54 <Thaodan> I think /opt/apps is a solution for a problem that is self created that will create more problems
  • Command line tools, local server services (e.g. OSM Scout Server) etc. (every non-app) provided by third parties still have to be installed / installable in their usual locations on the root volume.
  • The content of /etc has to remain writeable for deploying system-wide configuration changes.
  • The FHS defines /etc/opt for configuration files of add-on packages stored in /opt, hence this location also has to be writeable (which it is any way, if the prior point is given).
  • Creating a separate /opt/apps/<app_name>/usr/bin/<app_name> and especially /opt/apps/<app_name>/usr/share/<app_name>/ for each app will lead to data and / or binaries duplication.
    This scheme also prevents providing third party binaries and / or libraries for other apps.
  • After SailfishOS has adhered to a classic usage of the Filesystem Hierarchy Standard (FHS) for 11 years (i.e. in the way most other Linux distributions do), such a change will be very disruptive, because all badly maintained or unmaintained apps will fail to install when the root volume is switched to read-only.
    Side note: I really wonder why Jolla seems to love such disruptive, not backward compatible changes and employs them regularly (the needless nemo→defaultuser switch and applying a strict SailJail default configuration to apps which do not bring their own are two other examples of many) which kill old apps, despite the fact that the small app ecosystem always has constituted a major problem for SailfishOS (and continues to do, even more so because many third party developers have left the ship or perform only minimal maintenance of their software due to the structural problems SailfishOS has, especially the long outdated Qt version).

Consequently such a fundamental change would have to be announced loudly and firmly now, in order to perform this change in many years (e.g. for SailfishOS 6 in > 5 years).
Personally, I do not believe following this route is worth the effort, because it “will create more problems”.

11 Likes
#20

Thank you for the in-depth answer to my question about the /root partition size!

<Jolla> There shouldn’t be anything blocking to increase root partition size for older devices but only for flashable image (no resizing during upgrade).
...
<Jolla> For time being maybe we just adjust root partition for the older devices – we’ll comment this more a bit later.

This is really good news to me and I understand it’s not a promise on Jolla’s behalf. With 4.6 being the last release for older devices, it might seem that the “insufficient space for upgrade” issue is moot. However, please take into account the possibility of future community provided upgrades as discussed in the adaption repos topic by nephros.

<Jolla> Let’s start from the problem. We’d like to first understand how people end up running out space.
<Jolla> <...> Of course, also just installing tons of apps.

TL;DR for my case: I had to remove so much functionality that the upgrade was about as painful as a reflash.

Despite uninstalling almost every app from my Xperia X, I still didn’t have enough free storage on /root to upgrade. Some major culprits and several smaller items amounted to 435 MB of wasted space - recovering that would increase free space by 80% and take me over the upgrade threshold. However, I was advised not to touch most of these.

Documented in more detail here:
https://forum.sailfishos.org/t/root-partition-filling-up/

<Jolla> Secondly using alternative Sailfish app stores might cause problems.

Although not your responsibility, I would very much appreciate you taking alternative stores and their apps into full consideration when you decide on storage allocations.

As I’m sure you are aware, these are essential for the SailfishOS experience. Backup, edge swipe, tools for battery, WiFi, cellular and GPS, would all be missing or severely limited if we could only use the Jolla Store. Same goes for weather forecasts, SailfishOS Forum, offline maps and navigation, bug reporting, KDE Connect, and more.

<Jolla> There are two related goals that should be kept in mind:
    1) apps should not be installed to the root partition
    2) root partition should eventually be readonly

My takeaway from olf’s comment above is that this is complicated, and I’m not really competent to add anything. Having said that, I think a read-only root partition sounds like a security feature and a worthy goal.

<jojomen> RCS seems to be at least the new Standard as Apple jumps on that
I won’t take any credit for the RCS topic. To me, RCS is Revision Control System and I don’t think Apple jumped on that lately :wink:

2 Likes
#21

Yes. Me too. And all i ever did was installing a few cli tools from the official repos. Some people will argue that one should never ever build on the phone - well, then remove gcc from the repos. I have also heard mumblings about a chroot - but nothing close to an instruction. I think this usage isn’t strange - it’s a Linux phone after all. People will want to use that fact every now and then.

Many times i have had to scrounge for 10MB here and 10MB there - since the expected margin between normal usage and inability to upgrade has been 4-500 MB, if even that.

Please don’t go for readonly root filesystem like the nonsense Ubuntu Touch is pushing [without a proper overlay or something to mitigate the impact]. If i wanted Linux without the Linux i could use Android (well, except for the spamtastic UI).
Still reeling from that this was actually stated by Jolla and not an ill-conceived guess.

6 Likes
#22

Having overlay could well be an option and with developer mode enabled you could still do things.

3 Likes