Community meeting on IRC 21st December 2023

rainemak · 7 December 2023 14:04

Schedule: Thursday 2023-12-21T08:00:00Z

The meeting will be held on oftc.net IRC #sailfishos-meeting.
You can also join on Matrix or read-only on Telegram.
Logs of previous meetings: 2023, 2022, 2021, 2020, earlier.

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):

Open Pull Requests:
If you have, or know of, a pull request that’s been open for at least 3 weeks, but which you think deserves attention, please add a comment using the template below and we’ll consider it during the next meeting.

* Name/IRC nick:
* Open PR URL:

voidanix · 12 December 2023 10:00

Name/IRC nick: voidanix
Topic: Status of VoLTE packages availability
Some details about the topic: another SFOS release is supposedly behind the corner and many carriers have been shutting down their 3G/2G infrastructures this year. What is blocking Jolla from releasing the (currently proprietary) VoLTE packages to public repositories, similarly to how sailfish-fpd/sailfish-fpd-slave-binder are available, for the next release? Even if possibly incompatible with other devices, they would be of great use with ports whose architecture is close to the ones of the SFOS X supported devices (Qualcomm in general).
Approx. time needed: 10 minutes
Substitute (optional):

voidanix · 12 December 2023 10:13

Name/IRC nick: voidanix
Topic: Status of OpenSSL
Some details about the topic: OpenSSL 1.1.1 has reached EOL in September this year. Is Jolla already working internally on an upgrade to the latest 3.1 (or even better, 3.2) version? If not, should we expect it for the release following the next one?
Approx. time needed: 5 minutes
Substitute (optional):

rubdos · 13 December 2023 09:49

Name/IRC nick: Ruben / @rubdos and @direc85
Topic: cross-packages
Some details about the topic:
Approx. time needed: 5 min
Substitute (optional): @direc85

Since 2022-12-14, several packages (including rust and cargo) have build dependencies on cross-{armv7hl,aarch64}-{gcc,binutils,as,glibc} and some more. I assume some refactoring has been done in the packaging, since before that time, we could build rust etc. ourselves on the Platform SDK. These packages are nowhere to be found, nor can we find a way to build them ourselves, currently. This makes it difficult to contribute patches to Rust (and gcc and gecko, cc @flypig), especially in terms of testing the resulting compiler.

Would it be possible for Jolla to provide us with some insight, sources and/or binaries for these missing dependencies? We have asked mal on IRC a few times, to which the understandable answer was that he could test the build on OBS. This is however not a sustainable process, especially since we currently don’t get our hands on the resulting 1.72 compiler.

@rainemak already said in the previous meeting to have a look at this, but I’d like to formalize the request here. Thank you!

TNZ · 13 December 2023 09:53

Name/IRC nick: TNZ & cquence
Topic: What are the plans to enable 5G connectivity?
Some details about the topic: I remember some work taking place a while ago. Any update you can share would be great! P.S. Well done on the restructuring and fair winds ahead! I probably won’t be able to attend due to work commitments but will read the logs afterwards.
Approx. time needed: 5 mins
Substitute (optional):

cquence · 13 December 2023 16:45

Thanks for moving the question over - just copied it too without reading first

TNZ · 13 December 2023 17:49

I add your nickname in the post

pherjung · 18 December 2023 21:26

No bug reports this week. Unfortunately, I haven’t had time to list and test them.
Anyway, feel free to check this page (especially the next meeting column).

piggz · 19 December 2023 16:59

Name/IRC nick: piggz
Topic: Unlock via dbus
Some details about the topic:
I made a fun little hack which allows a user to auto-unlock the phone if some configured BT device is connected (GitHub - piggz/harbour-smartunlock). Unfortunately it required a nasty hack in nemo-qml-plugin-devicelock to allow unlocking via dbus (GitHub - piggz/nemo-qml-plugin-devicelock at dbus-unlock), I can envisage a setup where the user enters the unlock code into some settings, and a dbus method that accepted the code could do the unlocking, which would be a bit better. This currently works great on the PInephones, but not on my phone which uses sailfish-devicelock-fpd. That closed part does link to /usr/lib64/libnemodevicelock.so.0 and exposes the same dbus method, but replies with an Auth error before hitting the modified code in MceDeviceLockAdaptor::setState() I think this is because it statically links the library, so my override in the dynamic lib doesnt work. Would you be interested in adding some real way to auto-unlock a device? What are your thoughts on this? My use case is to not need to unlock the phone if it know im “close by” … eg, if connected to my watch or my car"
Approx. time needed: 10 mins?
Substitute (optional): I probably wont make the meeting, its xmas time afterall, but interested in what you think

rainemak · 20 December 2023 10:32

Here’s a non-standard community meeting reply. This is due to the fact that reply ended up being too long for the meeting. Let’s edit & comment this and finally create a PR to the docs.sailfishos.org. We’ll use this post a reference during the meeting.

There are multiple aspects involved. There are some issues that we’re seeing also in the next Platform SDK release. First, you do not want to install cross-{armv7hl,aarch64}-{gcc,binutils,as,glibc} to the target as those should be installed to the tooling. Secondly, it’s not easy to understand how these cross-packages are intended to work – thanks from the request to formalizing this. Sorry that it took a while to realize what you were trying to do and what’s wrong – at least we think that we understood the issue now. It’s not also easy to understand how SDK chroot, tooling, and target work together. Hopefully this sheds a bit of light to that. The cross packages are already available and hopefully this will unlock your work. Let’s open the hood a bit.

First thing is that we revert (or commented out) following lines from the rust spec. This is something we missed previously – apologies. We’ll create a PR to the rust spec that makes this optional to OBS. In addition to this, there were some project config changes around the time frame that you mention which in combination broke this or that’s what we believe.

Next let’s verify that you have your tooling in a good shape. You need to install the spec lines that you removed to the tooling.

/srv/mer/toolings/SailfishOS-latest-public/mer-tooling-chroot 
ssu ar jolla-aarch64 https://releases.jolla.com/releases/4.5.0.18/jolla/aarch64 
ssu ar jolla-armv7hl https://releases.jolla.com/releases/4.5.0.18/jolla/armv7hl 
zypper ref 

# aarch64 
zypper in cross-aarch64-gcc cross-aarch64-binutils cross-aarch64-as cross-aarch64-glibc cross-aarch64-glibc-devel cross-aarch64-glibc-headers cross-aarch64-kernel-headers 

# armv7hl 
zypper in cross-armv7hl-gcc cross-armv7hl-binutils cross-armv7hl-as cross-armv7hl-glibc cross-armv7hl-glibc-devel cross-armv7hl-glibc-headers cross-armv7hl-kernel-headers 

exit

Now we’re back in the SDK chroot. Let’s install i486 counterparts to the SDK itself. At least glibc-common, glibc-devel, and glibc-headers. The mb2 build installs build requirements (BuildRequires from spec) to the target so no need to worry about the build target.

sudo zypper ref 
sudo zypper in glibc-common glibc-devel glibc-headers

If build fails with an odd error and objdump -T <lib-name> in the target shows that symbols are there, it is good to check that tooling and SDK have right packages.

Instruction for building dumb packages can be found here

With mb2 it would be for example like:

mb2 –s ../rust.spec build

Hope this helps! Merry Christmas!

nephros · 20 December 2023 10:58

Name/IRC nick: nephros
Topic: XDG-Desktop-Portal specification: interesting for Sailfish OS?
Some details about the topic:

While experimenting with PipeWire I came across something called “XDG Portal specification”.
I am aware that something like this would be a rather large effort, so this is more of a long-term strategy/design question (SFOS v5/6/7 or so ;)) but here we go:

It is described as:

A portal frontend service for Flatpak and other desktop containment frameworks.

xdg-desktop-portal works by exposing a series of D-Bus interfaces known as portals under a well-known name ( org.freedesktop.portal.Desktop ) and object path ( /org/freedesktop/portal/desktop ).

The portal interfaces include APIs for file access, opening URIs, printing and others.

Ignoring the buzzwords “pipewire” and “flatpack” for a moment, the actual specification for some of the functionality does align with some core functions of Sailfish OS (others are geared more towards proper desktops and can be ignored.).

Flatpak grants sandboxed applications talk access to names in the org.freedesktop.portal.* prefix. One possible way to use the portal APIs is thus just to make D-Bus calls. For many of the portals, toolkits (e.g. GTK) are expected to support portals transparently if you use suitable high-level APIs.

To implement most portals, xdg-desktop-portal relies on a backend that provides implementations of the org.freedesktop.impl.portal.* interfaces.

Sounds familiar, huh?

For more details, see the links.

IMHO, this presents an opportunity to move from Sailfishos-only interfaces to more widely-used ones, or, maybe, existing functionality can be kept as-is, but additionally be made available on these interfaces.
Thus we could benefit from implementations on other operating systems, applications, and toolkits, and increase interoperability and portability.

Just as an example, Lipstick already has the functiionality of triggering a screenshot via DBus on org.nemomobile.lipstick, and this functionality could also be exposed as a Portal on org.freedesktop.impl.portal.Screenshot. Similar things cold be done for e.g. Screencasting, and some of the other specified interfaces.

Also, Applications under SailJail accessing DBus interfaces is a not-very-well-solved problem right now, and following parts of such a specification could help in this regard as well.

So,

Purely looking at it from a design standpoint (disregarding implementation efforts for the moment): would Joll(a|yBoys) see any benefits to having some of this on SFOS at all?
I believe this could be an area where the community could help, if there is some highlevel guidance.

Links/References:

Approx. time needed: 10min (or more)
Substitute (optional): I will likely not be able to attend actively participating, but will monitor the meeting logs and be curious about the answer.

PS: I know this comes rather late, happy to wait for next year/next meeting for an answer, or chatting in “General” without formal answers prepared.

rainemak · 20 December 2023 11:43

Thanks for topic @nephros . As this is a very late submission could you please open this to the next meeting that will be created after tomorrow’s meeting. Thank you in advance.

rainemak · 20 December 2023 12:11

Hi @piggz. This is also a late submission. Could you please open this to the next meeting that will be created after tomorrow’s meeting. This way we get best out of this topic. Thank you in advance.

rainemak · 21 December 2023 09:05

Minutes: #sailfishos-meeting: Sailfish OS, open source, collaboration -- 21st Dec 2023
Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2023/sailfishos-meeting.2023-12-21-08.00.txt
Log: #sailfishos-meeting log

rainemak · 21 December 2023 09:15

@nephros & @piggz we scheduled next community meeting. Could you please copy your topics there. Thank you.

direc85 · 21 December 2023 12:53

Thanks for the long and detailed post! It was indeed all we needed to make Rust 1.72.1 happen for all three architectures!

So: I had the i486 binaries available before, since Ruben compiled them. All I needed was the other arches. In Sailfish Platform SDK, I was then able to compile the stub packages with the instructions, the resulting packages are as follows (with the proper git tag added locally):

8995 Dec 21 11:15 cargo-1.72.1+git1-1.aarch64.rpm
9069 Dec 21 11:15 cargo-1.72.1+git1-1.armv7hl.rpm
8743 Dec 21 11:15 rust-1.72.1+git1-1.aarch64.rpm
8819 Dec 21 11:15 rust-1.72.1+git1-1.armv7hl.rpm

I then put them in correct subfolders of my output-prefix folder in Sailfish SDK and started compiling Whisperfish - they were pulled in automatically, and the resulting RPM package works fine. My test case was Whisperfish for armv7hl, copied over to my Jolla Phone (still running SFOS 3.4), and after a quick Whisperfish profile transfer later, I was happily sending messages with it!

Thank you for everybody that helped in making Rust 1.72.1 for Sailfish OS happen! This would not have been possible without such a great team effort!

harbourlights · 21 December 2023 23:44

What a great Christmas present to read about plans for the next Sailfish OS release - and even for the one after that!
Thank you for the very productive and concrete answers today!

direc85 · 31 December 2023 15:53

It turned out that the Rust 1.72.1 builds at that time did not work, and because Rust 1.75.0 builds behaved the same way, I jumped to that instead. Long story short, with a little workaround in the application-side .spec file – export TMPDIR=$(realpath "%{_sourcedir}/.tmp") ; mkdir -p $TMPDIR – I am now actually able to compile Whisperfish for all three architectures. What a nice note to end the year with!

Happy new year everyone!