Community meeting on IRC 26th May 2022

Schedule: Thursday 2022-05-26T07:00:00Z   :world_map:   :date:

Topic proposals for the meeting:

  • Add your name/nick using the template below to suggest a topic.
  • Indicate how much time you’ll need so we can time-box the meeting accordingly.
  • Please be as thorough as you can with your question/topic.
  • If you can’t make the meeting please ask and name a substitute.

It is expected that you show up and present your topic, or name a substitute and make sure they attend in your absence. These IRC meetings are for real time participation and live discussions, otherwise you can post the topic on here and get responses that way.

We need you to be present to clarify details in the topic, and to ensure the discussion is leading to the answers you are looking for! If you do not participate or your question/topic isn’t clear enough it will be postponed. Also: always ask for more time than you anticipate your topic needs!

Please have your topics ready at least 3 days before the meeting so we can prepare good answers. Topics announced afterwards will be postponed to the next meeting.

Template for topic proposal: (post your topic proposals as comments to this forum topic).

* Name/IRC nick:
* Topic:
* Some details about the topic:
* Approx. time needed:
* Substitute (optional):

Untracked bug reports

Bug reports with missing tag

ID Comments
6328 Seems fixed
11329 Fix and PR provided
10147 Seems fixed
10313 Seems fixed
10417 Seems fixed
10732 Seems fixed
9908 Seems fixed
8916 Tag tracked seems missing
11330 Seems fixed

short question, what Tag is needed to by tracked by …? Jolla?

What do you mean with what tag?

To be added to this list, a bug report need to be filled correctly, contains all necessary information and be easily reproducible. Depending the situation, Jolla will tag as tracked, pending or fixed.

1 Like

i mean id 8916. Is there more information needed?

No! And this is typically a good bug report. If you see it here, it’s usually a good sign.

I forgot to mention, we, the Bug Coordination Team, add 10 bugs report. The rest are bugs reports we think they’re already fixed or internally tracked, but have a missing tag.

:+1:, now I know the purpose of the list .

@pherjung, 7631 was once tracked by Jolla (in 2019 at TJC), but I never heard anything from Jolla WRT it any more, after FSO started.

Please add it to your community bugs list.

I do have 2 bug reports laying around that never got any reply from Jolla itself:

1 Like

I thank @olf, @adekker for their comment and bug reports. I checked and they’re already present in our list. It always help us to be notified about “old” bug reports.

For your information: Once the bug is well written and easily reproducible, 10 of them are randomly selected to fill the list.

1 Like
  • Name/IRC nick: rinigus

  • Topic: Open sourcing VoLTE implementation

  • Some details about the topic: VoLTE support packages - modem_auto_config and ofono-vendor-qti-radio-plugin - have proprietary license. Does Jolla plan to release the code? If you do, please be specific with the time frame, as we have heard about many plans for open sourcing, but none of them worked out. So, without specific time frame, you may as well reply as “no, we don’t have any plans and would keep it closed source”.
    Some background info: Beta VoLTE on the Xperia 10 III, disabled by default - #37 by rinigus

  • Approx. time needed: 10 min

  • Substitute (optional): I am sure many could join the topic. Due to working hours, I suspect that I cannot make it to the meeting.


Can I just add to this, that Ofono upstream already contains a QTI driver, so what is the sense in making this proprietary. Would it not benefit all to work to better the upstream driver (which is used by the PInepone too)? Is this driver a clean room implementation and not contaminated by any of the open source implementation, which exists in the ofono code base, so presumably anyone writing a new QTI driver for Ofono would have easy access to it? Many device ports would benefit from VoLTE, so having it open source may make adoption on these devices easier.


Feedback on the SailfishOS-OBS topic discussed at the Community meeting on IRC 12th May 2022:

Why is the SailfishOS-OBS a crucial part of the larger SailfishOS-ecosystem.

This is a concatenated version of the pieces originally written by @piggz and @olf, see and

The SailfishOS-OBS is primarily used for application development/distribution, and device porting. These two different use cases have different sets of statistics.

  1. Application development/distribution using the “SailfishOS:Chum” repository:

  2. Hardware adaptation ports are typically subprojects of the “nemo:devel:hw” project on the SailfishOS-OBS. That project contains 102 device ports at the time of writing, though no claim is made for how active each is. I know of 2 other active ports which will arrive on OBS shortly, for a total of 104 device adaptations.

  3. Storeman as the only maintained OpenRepos client app, depends on being built and distributed by the SailfishOS-OBS.
    In detail: The Storeman Installer for initially deploying Storeman on a SailfishOS device and also Storeman’s self-updating mechanism relies on the SailfishOS-OBS for providing SailfishOS release version specific builds in order to support a wide range of SailfishOS releases. Hence the SailfishOS-OBS is necessary for building and distributing Storeman. Because Storeman is and has been the only maintained OpenRepos client app for long (many years), without it SailfishOS would lack an app for downloading, installing and managing RPMs and repositories from / at OpenRepos.

Summary / TL;DR

By shutting down the SailfishOS-OBS, both community app stores would become obsolete and cease to work: SailfishOS:Chum, because it directly utilises the SailfishOS-OBS for building and distributing the software it contains (point 1), and OpenRepos, because its only client app Storeman relies on being built and distributed by the SailfishOS-OBS (point 3).

Furthermore, most community ports of SailfishOS depend on the SailfishOS-OBS for their hardware adaptation (point 2). Switching off the SailfishOS-OBS means to discard more than 100 device ports (and additional ones in the pipeline)!

  1. Additional perspectives

We hope that depicting the vast value of the SailfishOS-OBS and the potential consequences of shutting down the SailfishOS-OBS is helpful for Jolla to consider maintaining it sustainably, because it has become a indispensable piece of the infrastructure for many third-party SailfishOS apps and most SailfishOS ports over the years.

Clearly denoting such a commitment would be much appreciated, because some tasks and actions using the SailfishOS-OBS were put on the hold due to its unclear future.

  • Name/IRC nick: attah
  • Topic: The future
  • Some details about the topic: How is the ownership situation progressing? I think i speak for the entire community when i say that i hope it gets a speedy resolution with stable and interested ownership. Similarly; is there anything you can share on the “engineering effort” that started recently?
  • Approx. time needed: 15 minutes
  • Substitute (optional):
  • Name/IRC nick: piggz
  • Topic: OBS Improvement for ports
  • Some details about the topic:
    At around Sailfish 4.3, and new hw-common repository was added which packages common hw adaptation packages which can now be shared across devices. When building on OBS for community ports, these packages are not available, so it is still necessary to build certain packages to allow the droid-hal-version package to build correctly. Could the packages in the new common repository be added to the OBS targets to reduce the amount of packages needed to be built by ports? (lbt will be useful here)
  • Approx. time needed: 20 mins
  • Substitute (optional):
1 Like

Thanks for the question @piggz. I’m afraid this will have to be bumped to the next meeting, as I won’t have time to collect any info on it before the meeting tomorrow (you’re welcome to discuss it informally in the General section of course).

Yeah, no problem, my fault for not being quick enough.

@piggz Do you have mixed QMI and QTI. Ofono contains QMI driver.

Ah maybe! :man_facepalming: my bad !

Hmmm … I was basing that on the Pinephone open firmware project, which has a QTI implementation called OpenQTI … so, something must be using that? Too many Q?I technologies in modems!

Edit: OpenQTI in the pine phone, apparently takes QMI messages from the ADSP, and passes them to the phone via USB … so, there is some relationship between qmi and qti probably adding to the confusion!