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.
, 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
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.
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.
5 Likes
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.
5 Likes
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 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).
- Developers have contributed a wide range of packages to SailfishOS:Chum, with many abandoned apps being revitalised within the SailfishOS:Chum organisation at GitHub: 62 source code repositories have been created there for either abandoned apps, or as packaging repositories for existing Linux tools.
- The goals and processes of SailfishOS:Chum are extensively documented at https://github.com/sailfishos-chum/main.
- A comprehensive, still concise list of additional benefits SailfishOS:Chum provides by leveraging the SailfishOS-OBS (over, e.g., OpenRepos) was written by @nephros: https://forum.sailfishos.org/t/community-obs-refurbished-and-re-floated/6556/41
-
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: - These and some additional points have been brought up at the Community meeting on IRC 12th May 2022 in the general discussion, from 07:45 to 08:15.
- @lbt intends to provide some access / download statistics for the SailfishOS-OBS.
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.
6 Likes
- 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):
5 Likes
- 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.
Ah maybe! 
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!
Minutes: #sailfishos-meeting: Sailfish OS, open source, collaboration -- 26th May 2022
Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2022/sailfishos-meeting.2022-05-26-07.00.txt
Log: #sailfishos-meeting log
We had some interesting discussion at the meeting. Thanks to everyone who joined.
2 Likes
Please note that the statement in line 70 of the meeting minutes is not really backed by anything @piggz or I wrote:
If this is supposed to be the essence of my section 3 and / or the “Summary / TL;DR” section, these sections were heavily misunderstood, unfortunately. What these sections try to express is:
#info The SailfishOS-OBS is indispensable for SailfishOS:Chum, plus Storeman Installer and Storeman (thus also for OpenRepos) to work.
#info I.e., both (= all) community app stores absolutely depend on the SailfishOS-OBS.
Side note: SailfishOS:Chum is not “critical” for Storeman, even though it is also offered there.
HTH