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):
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.
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.
Hi!
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.
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.
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 https://forum.sailfishos.org/t/community-meeting-on-irc-12th-may-2022/11334/7 and https://forum.sailfishos.org/t/community-meeting-on-irc-12th-may-2022/11334/10.
The SailfishOS-OBS is primarily used for application development/distribution, and device porting. These two different use cases have different sets of statistics.
Application development/distribution using the “SailfishOS:Chum” repository:
On 26th May 2022, SailfishOS:Chum contains 222 packages. Most of these are being built for 10 SailfishOS releases over all 3 supported architectures (aarch64, armv7hl, i486).
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.
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)!
Additional perspectives
Jolla should consider which effects shutting down Jolla’s internal OBS would have (and using the SailfishOS-SDK instead for building SailfishOS and its core apps): It is the same for the community!
This topic (need for the SailfishOS-OBS) has already been discussed in depth almost two years ago: A proper alternative to the SailfishOS-OBS needs to provide the mass-building for different SailfishOS releases, dependency management (e.g., for complex projects as Pure Maps) and distribution capabilities (of the built RPMs) to the same extent as the SailfishOS-OBS.
References:
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.
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?
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)
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).
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!
, now I know the purpose of the list .
my bad !