Telegram Desktop unable to launch on Raspberry Pi 5

[ohmyboroda]

Steps to reproduce

An error occurs when trying to lauch the application on fresh installed system

1. Install flatpak https://flathub.org/setup/Raspberry%20Pi%20OS for RPi5
2. Install Desktop https://flathub.org/apps/org.telegram.desktop
3. Run Telegram Desktop flatpak run org.telegram.desktop

Device

OS: Debian GNU/Linux 12 (bookworm)
OS architecture: 64-bit
Kernel: aarch64 6.6.20+rpt-rpi-2712
Device model: Raspberry Pi 5 Model B Rev 1.0
SOC identifier: bcm2712
Cpu name: Cortex-A76
Ram size: 8.04 GB
Raspberry Pi OS image version: 2024-03-15
Language: en_US.UTF-8

Expected behaviour

Telegram is started after the steps listed above

Actual behaviour

Telegram unable to launch

Operating system

Debian GNU/Linux 12 (bookworm), 64-bit, kernel: aarch64 6.6.20+rpt-rpi-2712

Version of Telegram Desktop

4.16.8

Installation source

Flatpak

Crash ID

No response

Logs

flatpak run org.telegram.desktop
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
../glib/gprintf.c:349: failed to allocate memory

[ilya-fedin]

request support for your device at https://github.com/jemalloc/jemalloc with default build configuration

[theofficialgman]

@ilya-fedin they have no intention of changing the default as of now
redirecting the issue back to you.

[ilya-fedin]

@theofficialgman tdesktop doesn't have the intention either, especially since amd64 is the only officially supported architecture. arm64 flatpak exists only because flathub builders build it automatically (the same for snap).

[theofficialgman]

@ilya-fedin aarch64 is an officially supported architecture. Refer to the official verified flatpak https://flathub.org/apps/org.telegram.desktop

Let's get this issue with telegramdesktop fixed.

[ilya-fedin]

@theofficialgman i'm not sure what you wanted to proof by this link, arm64 is not officially supported by tdesktop. You can build it, flathub can build it but it's not guaranteed to work.

[ilya-fedin]

Don't get me wrong, I'm not against if someone would PR a solution that will let tdesktop work on rpi5 while not making tdesktop less optimized for other architectures and ideally other machines (that work right now) on the same architecture. Yet, I have no personal interest in this issue to work on it and arm64 is not an officially supported architecture to deserve an open issue about that.

Moreover, I guess having lesser page size is even more important on arms than on amd64, as such hardware usually has limited RAM size.

[theofficialgman]

@ilya-fedin flathub builds are official and supported (see verified tag at https://flathub.org/apps/org.telegram.desktop). Aarch64 is enabled in flathub builds https://github.com/flathub/org.telegram.desktop

Thus aarch64 is supported. Not sure why this concept is so difficult for you.

[ilya-fedin]

@theofficialgman only amd64 build is official. arm64 build is present only because builders build it, as I mentioned earlier.

[ilya-fedin]

And, well, flatpak and snap builds are more like semi-official, as they use API key created by a third party person.

[theofficialgman]

I see. I'll contact flathub and have the verified badge removal as it's not official.

[ilya-fedin]

Not sure why this concept is so difficult for you.

The problem is you're using third party projects (flathub) as the source of truth. If you will look this repository, you won't find any sign that ARM is supported. The official build instructions are amd64-only and previous issues about ARM support were closed as there doesn't seem to be any need in Linux ARM support from Telegram PoV and the community doesn't seem to have enough interest to help with code for ARM support (implementing a cross-compilation script to build official binaries for ARM on amd64 hardware).

[theofficialgman]

The problem is you're using third party projects (flathub) as the source of truth. If you will look this repository, you won't find any sign that ARM is supported.

flatpak (and thus all flatpak builds) are listed as a supported system in the readme of this repository
https://github.com/telegramdesktop/tdesktop/blob/dev/README.md?plain=1#L23

[ilya-fedin]

flatpak (and thus all flatpak builds)

I read that as support for packaging formats rather than all builds.

[ilya-fedin]

No need to argue, that won't change the real state of things - the lack of interest in Linux arm. You either contribute a fix or wait until someone else from community does that.

[theofficialgman]

We have already given you the fix
just add --with-lg-page=16 to your configuration args for jemalloc

I don't know where you are pulling this dependency but it needs to be built with that. I leave this up to you as the project maintainer.

[ilya-fedin]

just add --with-lg-page=16 to your configuration args for jemalloc

This will raise RAM consumption for all users (not only the affected ones by the issue) which doesn't seem a good solution.

[ilya-fedin]

I leave this up to you as the project maintainer.

I'm not the project maintainer. It's @john-preston.

[theofficialgman]

just add --with-lg-page=16 to your configuration args for jemalloc

This will raise RAM consumption for all users (not only the affected ones by the issue) which doesn't seem a good solution.

incorrect k3s-io/k3s#7335 (comment) . I quote:

4K pages made sense back when the Intel 386 came out. They are thoroughly obsolete, and the only reason they are the default on typical ARM64 distros is because 4K is the lowest common denominator supported everywhere and the Linux kernel's poor design does not allow deciding the page size at boot time. 16K is unarguably beneficial for all but the smallest embedded systems, and 64K is the logical choice for large servers. 4K pages increase overhead and do not provide a measurable memory savings. There's a reason Apple went with 16K for their entire 64-bit ARM ecosystem (because it's better, and because they control it all so they can make that decision).

[ilya-fedin]

I don't see how that is wrong is jemalloc developers say that changes the size of their structs. They don't want to make it the default due to that, I don't want to take that either - tdesktop already uses lots of RAM.