Revisit arm64 Telegram Desktop on 16K pagesize

[popey]

Is your feature request related to a problem?

The arm64 build of telegram-desktop crashes on arm64 Asahi Linux on Apple Silicon devices (M1 etc).

I am aware of previous conversations in issues #24564 and #24836 , but I am kindly asking to revisit this, as I have some additional data that may help this move forward. I'm also keen to understand if there's anything us Asahi Linux enthusiasts could do to help move this forward?

Describe the solution you'd like

Build the official telegram-desktop package to support installation simultaneously on a 16K page size system and a 4K page size system :pray:

Describe alternatives you've considered

I cloned the telegram-desktop/tdesktop source, and lightly patched it then published it as telegram-asahi in the snap store.

The patches:

• Change telegram-desktop to telegram-asahi to enable it to be published under a different name
• Switch from using the kisak/kisak-mesa ppa to tobhi/asahi

That's all, I'm using the upstream source, indeed using the upstream snapcraft.yaml only patched above.

For the last four months, I have published the telegram-asahi snap of the telegram-desktop snap up-to-date (typically within a day) in the snap store. I've been using this package on Ubuntu Asahi for all that time and have not experienced any issues so far.

v4.16.1 is building right now :sweat_smile:

The userbase is (perhaps unsurprisingly) quite small, with most users running Ubuntu Asahi 23.10 and Fedora Asahi 39.

Additional context

I appreciate that @ilya-fedin expressed concern in #24564 that building for the 16K page size would break on 4K systems. So I asked friends on the snapcraft forum to test the telegram-asahi snap on 4K page size systems. Their reports suggest it's fine.

https://forum.snapcraft.io/t/anyone-got-an-arm64-rpi-or-similar-non-asahi-to-test-something/39292

Obviously this isn't super extensive testing, but it should improve confidence, I hope. I'd be happy to get wider testing if that would further assist.

[ilya-fedin]

I'm not sure what should be done now given that jemalloc was replaced with scudo half a year ago?

[ilya-fedin]

I appreciate that @ilya-fedin expressed concern in #24564 that building for the 16K page size would break on 4K systems.

Well, not just break, but make them sub-optimal (e.g. consume more RAM) just like jemalloc developers were saying. tdesktop is already memory hungry so this is quite a big concern. It doesn't sound fair that everyone should get a less optimized binary due to one vendor.

[ilya-fedin]

Ok, I really hoped that would be solved by scudo but scudo now provides lots of crashes so tdesktop is switching back to jemalloc with its standard page size. My personal opinion remains: jemalloc defaults to what they believe is the best so it will be followed. When jemalloc changes the default to 16K pagesize, jemalloc update in tdesktop will get it. So asahi comminity has to work in the direction of changing jemalloc's default page size in jemalloc upstream.

[popey]

OK, I appreciate the feedback.