Sailfish Community News, 3rd April 2025 - Harbour

Community News
1

Sailfish OS update from Jolla

In last community meeting we had a question regarding new Sony vendor blobs that got recently released. As the question arrived very late we decided to cover that one on the next community meeting 10th April. These new blobs require work on NFC, GPS, sensors and VoLTE at least. So getting those working will require time and development efforts.

Meanwhile, if you have take your Xperia 10 IV or 10 V into use you could try to use Android 13 v4b blobs. You have reported that with v4b blobs battery indication is working but fingerprint and camera do not work. The fingerprint is missing from the delivery and camera is disabled in the adaptation. @direc85 has been using v4b blobs successfully the past week with Xperia 10 V.

# Take only one of the next two commands, depending on your phone!
$ fastboot flash oem_a *_v4b_murray.img   ## for Xperia 10 IV (XQ-CC54)
$ fastboot flash oem_a *_v4b_zambezi.img  ## for Xperia 10 V (XQ-DC54)
$ fastboot reboot

In the last fortnight we mentioned that we’re working on an Sailfish update. We’re still working on it. We were aiming to get that update out before April but now it looks that likely lands to your hands in coming weeks.

As a reminder, if you happen to contribute or update a package, please check review feedback and RPM packaging related notes.

Energy from the Community

Just few days back @poetaster approached us regarding taking over Fahrplan app. It is great to see you, Sailfish Community, being active on these kind of matters. @keto kindly reminded that transferring ownership of an app in Harbour requires a consent from the original author. Surely there are other means, if original author is not reachable.

Repository roundup

Web browsing

  • sailfish-browser, the browser itself, pvuorela fixed the history button visibility that sometimes became visible under certain conditions within the security info page. He also used a different icon to represent the state “always ask” from the state “deny” when indicating the permission exception of a page. rainemak is working on making the cover content to avoid relayouting and adjust itself in landscape orientation for small device form factors.

Network, communication and telephony stack

Multimedia

Main interface

Low level libraries

Developer’s corner

  • libsdl-gfx, the simple direct media layer - graphics primitives, pvuorela fixed a permission issue in packaging on the dynamic library.
  • gstreamer, a multimedia framework, mal fixed in packaging another permission issue on gst-ptp-helper tool.
  • shadow-utils, used to manage the the shadow password files, mal changed the packaging so some utils get the set-user-ID mode (meaning that when executed by a normal user, they are running with root privileges).
  • nemo-qml-plugin-dbus, QML bindings for DBus, pvuorela fixed a permission issue on a text file (used for tests), making it executable.
  • nemo-keepalive, CPU and display keepalive and scheduling library, pvuorela added the executable permission on the dynamic library libkeepalive-glib.so.
  • nemo-qml-plugin-email, QML bindings for emails, pvuorela merged the possibility to get the package running offline for testing purposes. Previously, it was specifically compiled in a separated package.
  • cargo-packaging, macros and tools to assist with cargo and rust packaging, direc85 pushed version 1.2.0 to this new repository.
  • cargo-auditable, a tool to embed auditing information in ELF sections of rust binaries, direc85 pushed version 0.6.4 to this new repository.
  • cargo-c, a helper to build and install c-like libraries from Rust, direc85 is working on version 0.9.31 in this new repository.

Please feed us your news

Hope you enjoyed reading this community newsletter! As always, please do not hesitate to share your ideas, thoughts, or suggestion for future newsletter topics – let’s keep on working together. This is your news!

Please do also join us at our community meetings on IRC, Matrix and Telegram. Next community meeting will be on the 10th April. Please note that you can also join via Matrix bridge.

29 Likes
2

Thanks for another update, but can I ask what happened to the App Roundup in these Community News posts? They were often my favorite part, and there hasn’t been one to read all year!

9 Likes
3

@Sharks I’m tempted to say that many of us have liked to read App Roundups. @flypig has been authoring those App Roundups and I believe that he has just been busy.

14 Likes
4

Thx for clarify the ownership of harbour apps. Can you document this in the harbour faq for coming generations?

1 Like
5

Hopefully we will see some old apps that have been missing from the store. With the J1 we had quite a few usefull ones that never reached newer phones.

3 Likes
6

There have been a couple “adopt an app” threads already, with mixed results.

But you could start another and list the apps you’re missing dearly.

7

Please can you post the outcome of your request at the owner of the apps you are missing? Please post here.

4 Likes
8

I posted in that thread. The thing is though apps to end in the store. Not chum.

9

Why not give any feedback in this bug report about the dns endpoint in wireguard Wireguard cannot handle dns server names ?
I found the git commits to fix this myself about 14 days ago as you can see in the last post, but there was not a single response from Jolla, not even a tag that the issue was tracked internally.

Makes me wonder why I should even bother creating bug reports.

2 Likes
10

Maybe not the best thread, but since v4b blobs were mentioned…

Anyone tried said v4b blobs on an xperia 10iv running 5.0.0.62?

Got these annyoing reboots after charging, and so I wonder if it’s a blob thing, where flashing could help.

1 Like
11

I’ve just flashed v4b blobs on my Xperia 10 V on which 5.0.0.62 was flashed over Android 13 and its stable. What didn’t work before still doesn’t work, but battery percentage does now update. Haven’t managed to check mobile data yet (was completely unusable before), but will do so when I go out later today.

3 Likes
12

Hi!

Sorry for the confusion, this issue was also known internally, as it was an upstream ConnMan issue too. We get the baseline from upstream ConnMan and then fix the issues, try to propose the change to upstream to get more comments, merge into our fork and publish them with SailfishOS when time comes for the next release. The fixes for WireGuard FQDN are scheduled for the next one we release. It should work with dynamic IPs now too, please let us know after the release is out how it operates.

We value your input on the bugs in all cases. Thank you for that. When internally testing and noticing the issues, while working on them at the same time, tracking may be forgotten, sorry about that.

For you to know, there are many things I’d like to improve and implement on that plugin. But I cannot make any promises when they get ready.

7 Likes
13

Thanks, good to have this (positive) feedback!

2 Likes
14

I flashed v4b blobs to my Xperia 10 V, haven’t noticed any differences apart from that the battery indicator is working, which is a welcome improvement. I regret I didn’t try it earlier though, these blobs released way back in August of last year.

1 Like
16

IMO the principal aspect, which was made obvious by the issue discussed, is the overboarding amount of routes Jolla propagates for reporting issues, detailed as follows.

  • FSO is the “principal location for reporting issues for SailfishOS”, as repeatedly stated by multiple sailors.
    For this purpose most issue trackers of SailfishOS-related projects by Jolla at GitHub remain closed, as argued by Jolla (@vige, @rainemak) etc.
  • I denoted multiple times that exactly this makes proper and easy handling of bug reports by advanced users and SFOS-software developers hard and tedious, e.g. by referencing and intermingling them with extant bug reports at GitHub, GitLab, Codeberg etc.!
    The counter-argument was: “This is not what Jolla wants!”
  • As this was a pretty clear statement by Jolla, @nephros as SFOS-community member developed the Bugger tool to ease reporting bugs to FSO for SFOS-users, despite knowing that a forum software is fundamentally unfit for tracking as well as documenting the analysis and resolution of software-related issues.
  • Recently Jolla started to propagate a separate “SailfishOS issue repository” (solely for tracking some issues for SFOS’ software components in various GitHub-repositories controlled by Jolla) at GitHub for reporting bugs WRT SailfishOS, because “that is much easier”; AFAICS that is just one more unsuitable place to dump issue reports, because each GitHub-project already has an (optional) issue tracker, hence that “SailfishOS issue repository” is another centralised heap of issue reports which are basically as loosely linked to the corresponding software proper as at FSO.
  • Additionally Jolla maintains its internal issue tracker, which is something nobody outside of Jolla should have to care about or even know of; but this is apparently the only bug tracker Jolla deems relevant for all, because everything revolves around it: Unresolvable (except for sailors) JB#xxxx-references in git-PR- and -commit-comments, Tracked by Jolla labels at TJC and FSO etc. etc. The exact status, meaning and information hidden behind these labels is opaque to developers and users, hence these labels are basically useless for anyone without access to Jolla’s internal bug tracker.
  • Furthermore there are even more routes for reporting bugs, e.g. Jolla’s Zendesk instance which Jolla proposes as “the official support channel for individual SFOS-licensees”, but is not well searchable and yet another database plus web-frontend, the latter being even worse than FSO and far worse than a proper issue tracker for this.
    And if all these different routes with piles of already heaped up and often already stale issue reports fail to deprive you of your motivation, it will be suggested that you must “discuss” issues you care about live IRC-session (“community meeting”) in the morning on a working day; I am positively surprised that so many volunteers regularly participate and absolutely appreciate that, but perceive the expectation by some sailors that volunteers have to show up simply as impertinent: I usually have to work and due to clearly uttered expectations will never participate, as these statements did contradict any proper and structural modelling of social behaviour on an par.

Hence I keep asking (myself, other SFOS-users, other developers and lastly sailors) for more than 10 years:
Does a proper modelling at Jolla exist of the various flows of information, OSS-issue tracking must at least be able to comprise (many more should be coverable)?

  • Starting from a user report at FSO to an upstream OSS-project, while being fully (!; i.e. including all information and all potentially relevant references) traceable for any SFOS-developer (just model this for, e.g. me).
  • Starting from a sailor (= Jolla employee) to an upstream OSS-project, while being fully traceable for any SFOS-developer (again, e.g. me).
  • Starting from a SFOS-app-developer detecting an SFOS-bug (while being transparent to all SFOS-users and -investors, both, financially and non-financially investing).

If @Jolla still does not have answers to these questions, this corroborates to my former perma-question, “Why does @Jolla not care about properly comprehending, modelling and executing OSS-development-processes, although these are obviously crucial for Jolla’s own business development prospects?” Maximally easing collaboration (technically, socially, organisationally, infrastructurally) for acquiring contributions from volunteers (issue reports, code and documentation contributions) is obviously crucial for an OSS-company to reduce the workload of the paid employees, especially if this company was facing bankruptcy multiple times, i.e. the cost / revenue ratio apparently has not been balanced for longer periods of time.

Why?


P.S.: The fact that issues with this OSS-forum are software issue (e.g. “Discourse”'s mixed-quoting-issue) which are not at all transported upstream by Jolla, strongly underlines this meta-issue, because Discourse is a central, absolutely crucial part of the SFOS-infrastructure deliberately chosen by Jolla as its principal egressing information channel to users and developers, and as the only ingressing one. Actually, FSO’s issue handling by Jolla is a litmus-test.

P.P.S.: While it is nice to see an SFOS-developer gaining understanding that this lack of knowledge and oversight is a fundamental issue for economic success for SailfishOS and Jolla, fully comprehending exactly this is what Jolla’s management shall have strived for right from the start (~ 15 years ago), but they still seem to be completely liberated from that; i.e. the Nokia-“culture” / -thinking from before Stephen Elop entered the company still seems to prevail (“OSS is just a helpful sticker to excel economically, because we can reuse vast amounts of extant software, but we sure do not have to alter our mindset, understanding or execution”); I have not perceived a significant change since then, ca. 15 years ago, despite that scheme is not working (although RedHat, SUSE, etc. showing which OSS-development schemes do work well, for a even longer period of time) and that is even worse for smaller companies, e.g. Jolla. Well, one could have observed these public, well-visible developments closely for multiple decades, or instead contract some consultant (company) now to provide this knowledge and its application.
Yes, I do perceive that Jolla as a company and especially some sailors do have significantly improved on some of the aspects addressed here in the past couple of years, and apparently continue to do so, but I am afraid that these changes are executed “too little, too late”, which leads right back to the dire resource issues which lets and did let a sustainable development of SFOS (e.g. fixing significantly more bugs than new ones become introduced, regardless if Sony, Jolla, the cellular network providers etc. are to blame) appear questionable. I really would like to see Jolla and SailfishOS persist, as there is no sufficiently well working alternative as a “mobile phone Linux distribution suitable” (for me, at least), invested lost of time since 2015 into maintaining software which in crucial for me, but the endless chain of regressions are often outweighing the fixes and new features of a fresh SFOS release from my perspective as a user and developer, thus regularly requiring a lot of work just to keep software running under recent SFOS releases. As consequence many significant developers of software for SFOS have already quit and I am regularly considering it, because some AOSP-distribution (LineageOS, GrapheneOS etc.), primarily with apps from F-Droid also provides one with a complete OSS-software stack, but better maintained, mostly more feature-rich (partially “much more”) software; I really do not want that, but massively gaining spare time while significantly improving some functionality of my phones sounds quite attractive.
Hence I do expect to see some SFOS-roadmap documented by Jolla, which actually has become a point even more SFOS-users address in the past 12 months than before due to the tremendously debilitating bugs the Jolla C2 and Xperia 10 IV / V exhibit since SFOS has been released for these devices in 2024. Knowing well that communicating release dates many weeks in advance when developing software in an heavily resource limited environment mostly becomes obsolete very soon after such an announcement has been made, but to provide a temporally ordered list without specific dates or timelines which software components are going to be addressed / altered / overhauled / fixed / enhanced next would be tremendously helpful to assess if software one maintains is going to be affected; while some of this information has been provided on a very abstract level in the regular, bi-weekly postings by Jolla, this information is only provided in hindsight (when the planning, implementation, quality assurance / review and committing the PR has already been carried out) and has to be actively (re)searched (because a continuously expanded roadmap does not exist), which exposes developers to stress, because the software one maintains often has to be adapted within a couple of weeks, because bigger batches of changes in SailfishOS are usually committed in the weeks before the initial-Beta release of a new SalfishOS-version: If one does not have the time to permanently monitor Jolla’s announcements at FSO and (sometimes triggered by them) commits at GitHub, one likely can be hit absolutely by “the SailfishOS:Chum GUI app and / or Storeman does not work for a cBeta-users”, only to receive multiple such messages a few weeks later from EA-users to be informed that havoc is imminent (by the upcoming GA-release a week later): The timeline have become too short about ten years ago and are kept as such by Jolla despite exactly this developer feedback, especially from infrastructure software developers.

P.P.P.S.: Please do not simply try to dismiss this message as …

  • derogative
  • criticising specific technical aspects (I did not address any specific technical aspects, only structural ones)
  • crazy

It is rather, “what other choices do we have?”

  • Individually
  • Among your kin (“the hood”)" / like-minded people
  • Jolla
  • A a community / company / society / country

… to archive some digital sovereignty.

TL;DR

I perceive Jolla failing to build a SailfishOS-developer community for over ten years now, because Jolla does not seem to see a strong necessity for that. Lots of lacking points SailfishOS has have been reported repeatedly in the forums (TJC and then here at FSO) right from the start in 2013, first and foremost the inability to earn money by distributing paid apps in the Jolla Store (nothing I personally want, but originally the demand was denoted quite often, though most of these developers went) and the completely outdated, unsupported, unmaintained and insecure Qt5: Despite these points (and many other, minor ones) being obviously crucial for an SFOS-ecosystem to ever work and Jolla has never denied this fact, Jolla actively refuses address or talk about these. As the software quality (i.e. the number and gravity of regressions) by Jolla clearly has been decreasing in the last couple of years and Jolla does not plan to resolve the most severe structural issues, I do not believe SailfishOS has a sustainable future due to ever decreasing number of app developers (I think ca. 50% of the volunteering developers ceased using and developing for SailfishOS since the late 2010s, and probably an even higher percentage of the software developing sailors due to repeated restructuring of the company).
Consequently I am convinced that time is running out for Jolla, if they do not start to address these structural deficits: My hope for this to happen is still alive (otherwise I would have not written this lengthy message), but my expectations are low when extrapolating Jolla trajectory without any change of their course.

5 Likes
17

Just to add to what I was saying, I don’t think I have needed to restart networking in Utilities a single time today (or at least it seems to be happening less), whereas before, mobile data would stop working if the screen was turned off and I would need to restart many times a day. I think the v4b blobs might have fixed this for me which is also a very very welcome improvement.

Also, I think I might be pulling the thread slightly off topic here, so I will post anything further in the 10 V thread.

1 Like
18

Been using the v4b blobs on my 10 v on 5.0.0.62 flashed over Android 13 now for a few days. Mobile data now works as well as it ever has and doesn’t drop out continually like it did with the original blobs used in Jolla’s flashing instructions. No crashes, battery percentage works … Best blobs for this phone so far.

3 Likes
19

What pieces are still missing from daily driveability?

20

Camera and fingerprint, I should say.

21

It really depends on what your threshold is, having nfc payments for smartappcard etc, as far as it gets and not getting any closer any time soon, BT controlling of your smart dishwasher that needs online connection for certain modes, just as far and thank god for that, if your home appliance needs to ping bosch to do a quick cleaning cycle and it will refuse to do basic tasks based on your internet connection, you’re the sucker that bought into this shit, but as far as daily driving c2 with microg, uber kinda works so at least that’s kinda working

3 Likes