Community meeting on IRC 23rd June 2022

Schedule: Thursday 2022-06-23T07: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):


  • Name/IRC nick: rubdos / rubdos[m] / Ruben De Smet
  • Topic: Update Rust
  • Some details about the topic: Whisperfish requires Rust 1.56.

I don’t like to put this forward, but the shipped Rust compiler is getting old. It is currently on version 1.52, which is today one year and one month old. This is not usually old in Compiler Land, but sadly, for Rust, it is.

There are a few problems with this. I will take Whisperfish for context. It’s becoming increasingly difficult to deal with Rust 1.52. I fear that in a month or two, we will need to move towards Rust 2021, which is only available as of 1.56. The reasoning behind this, is that libsignal-client is moving forward, and has transitive dependencies that already moved on to Rust 2021. Among these are cryptographic base libraries, for which I’m rather angry that they put these requirements already, given their important position in the whole ecosystem.

Another reason for a bump of the required Rust version, is that many libraries and dependencies are adopting new features from even before edition 2021. Among those are Actix (MSRV 1.53), and even libsignal-client itself.

All of the above, summarized: for Whisperfish to be able to function and keep up with Signal’s developments, we require a version bump of Rust to at least 1.56, relatively soon.

Not updating means not updating libsignal (I’m maintaining a fork now, to patch around new features, but I won’t be able to hold that much longer), and not updating libsignal means potentially getting booted from their servers, or losing compatibility with future clients. Signal is very lenient in this, and they promise to maintain compatibility for three months, but in reality it’s usually more like a year.

Now, I understand that the Rust version is tied to the Gecko ESR release that Jolla builds for. The required Rust version for different Firefox versions are tabulated here: Rust Update Policy — Firefox Source Docs documentation
From that table, it’s clear that Jolla doesn’t need to update Rust in order to get even Firefox 100, so I understand that Jolla does not want to do the heavy lifting unless strictly necessary. I’m willing to chip in and bump the versions, but I’d love some feedback on whether Jolla will accept such big changes.

  • Approx. time needed: 10m
  • Substitute (optional):
9 Likes
  • Name/IRC nick: remote (won’t be present)
  • Topic: 4g should work on both SIMs simultaneously
  • Some details about the topic: SFOS doesn’t support 4g on both SIM slots, android ( and HW) does. So why do we have this artificial limitation and when will SFOS allow both SIMs run in 4g?
  • Approx. time needed: 5 min
1 Like

Sorry that we weren’t able to address your question properly in the last meeting @remote. We’ll give it another go in the next one.

1 Like

Untracked bug reports

ID Comments Additional information
11674
2661
10069
10404
2675
9058
11532
8524
11835
11659

Bug reports with missing tag

ID Missing Tag Comments
10077 fixed There were another bug report inside. They’re separate now.
4704 tracked See comment
9902 fixed See PR
11917 fixed User fixed himself

Duplicate/To be closed

ID Duplicate/To be closed Reason
1085 Duplicate 10077
3074 Can be closed Result is expected
11797 Duplicate 11146
9336 Can be closed Not a real bug report
5 Likes
  • Name/IRC nick: Cryx (but I might not be present cause of work…)
  • Topic: Adding additional Media Codecs to SFOS
  • Some details about the topic: see below
  • Approx. time needed: 5 min
  • Substitute (optional): none

Sailfish OS is missing some Media Codecs that are available by default on other systems (both mobile and desktop). This results in files being unsupported by SFOS and can’t be opend and show an error message about the missing codec.

For example: Photos taken with other devices and uploaded to Nextcloud aren’t viewable in Gallery - in my case these are Photos taken with an iPhone that are in HEIC format.
Same thing for videos in H. 265/HEVC.

And beside that I’d like to see especially Support for ALAC (Apple Lossless) as well.

As far as I know (didn’t do further Research right now) these Codecs could be used for free. So adding them - and maybe other additional Codecs that might be useful - to SFOS by default the whole system would be better up to date and would also offer a better User experience instead of dissapointment because of unplayable media files.

(Maybe something that’s related to missing codecs: Disney+ can’t play Videos and ends up with error 39…)

Wish/Conclusion: Add native supports for following codecs:

  • ALAC
  • HEIC
  • H. 265/HEVC
2 Likes

Can these bugs especially the USSD bug be discussed?

The best is to discuss it directly under the corresponding bug report.

1 Like
  • Name/IRC nick: Nico
  • Topic: Updating kf5bluezqt - MediaTransport conflict
  • Some details about the topic: see below
  • Approx. time needed: 15min
  • Substitute (optional):

Jolla intends to deprecate QBluetooth (part of QtConnectivity) usage in Sailfish: https://forum.sailfishos.org/t/deprecation-notice-bluez-gnutls-qtconnectivity-qtsysteminfo-repomd-pattern-builder/
Some applications currently use this to talk to advanced bluetooth gadgets. One of them is OBDFish: https://github.com/explit7/OBDFish

I wanted to update that application to use kf5bluezqt, since doing raw Dbus calls is not something I am comfortable with. The characteristics stuff in kf5bluezqt should be usable as a replacement for QBluetoothSocket. This was however added after the 5.50 version currently available in Sailfish. While that package was updated in February, it was only updated to 5.50, since newer version add a MediaTransport API which the Sailfish package added independently as a patch.

I would like to figure out how to move forward with that conflict to get a newer kf5bluezqt before QBluetooth is removed. Ideally we could just switch to the upstream implementation of MediaTransport, but this doesn’t expose some properties Sailfish does and some things have different names. Should those be merged? Are those necessary? What about binary compatibility concerns? I am not familiar enough with that package to judge that and I would like to figure out who I should talk to and maybe get some answers.

As an additional question some of the patches in that package look like they are valid bugfixes and should be upstreamed, but I am not sure if they are specific to the old Qt version SailfishOS uses or if they are even still applicable. It would be great to be able to drop some of those patches to make updating the package less of a pain.

You can find my current work in progress upgrade to 5.82.0 here: https://github.com/deepbluev7/kf5bluezqt

Feel free to postpone that question until a later meeting if it takes a while to answer or to approach me directly on IRC/Matrix/the forum, since this topic probably isn’t interesting to everyone.

2 Likes

Minutes: #sailfishos-meeting: Sailfish OS, open source, collaboration -- 23rd June 2022
Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2022/sailfishos-meeting.2022-06-23-07.00.txt
Log: #sailfishos-meeting log

Thanks everyone for all the nice questions and especially to those who joined the discussion today.

3 Likes

Personally I really appreciate work seen here. Especially work on bugs, various upgrades and communication with community!

7 Likes

A little reply to/from myself: The H.265 “issue” depends on Hardware - so Xperia 10 III and Xperia XA2 (and I guess the Xperias between - 10 and 10 II - will too) are playing H.265 files, but Jolla C doesn’t.

Also, just to tie things up, ALAC will be available in the next release.

3 Likes

Thanks! I’m very to hear this! :slight_smile:

@flypig Sorry to say, but after updating Jolla C and Xperia 10 III to 4.4.0.68 the error message Alac not supported still appears…

Edit: Codec works, but there seems to bee a bug in Media Player when trying to play an Alac file. I’ll try a little further and set up a bug report.

Thanks for flagging this @Cryx and for looking into it further. That’s an unexpected shame. If you could point me at the bug report (with a ping) once you’ve created it, I’d be grateful.

1 Like

@flypig To give a short explanation what’s working wrong:
*Open Media Player and select an Alac file to play - the error message “Alac not supported” appears.
*Chose another file that is not Alac - it will play (as expected).
*Then try again to play the Alac file - and surprisingly this time it will play without the error message.

So the bug is that media player can play an Alac file only when a non-Alac file was played first. (I can confirm this behaviour at least on Xperia 10 III - I’ll have to check that on Jolla C and Xperia XA2 too and set up the bug report then).

2 Likes