Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Specify minimum flatpak version
Since migration to Qt 6, people periodically creating issues about incorrect single instance check in flatpak. This goes from the fact Qt 6 does permission checks on the XDG_RUNTIME_DIR and there's no easy way to work around that, so declare we don't support those flatpak versions. Specifying the version that added shared /tmp support.
  • Loading branch information
ilya-fedin committed Mar 24, 2023
1 parent b1cbf0e commit 705778b
Showing 1 changed file with 1 addition and 0 deletions.
1 change: 1 addition & 0 deletions org.telegram.desktop.yml
Expand Up @@ -5,6 +5,7 @@ sdk: org.freedesktop.Sdk
command: telegram-desktop
rename-icon: telegram
finish-args:
- --require-version=1.11.1
- --share=ipc
- --share=network
- --socket=wayland
Expand Down

11 comments on commit 705778b

@gobalius
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks the compatibility with CentOS Linux release 7.9.2009 (Core), where latest Flatpak is 1.0.9
However, the application updater still detects that there is a new Telegram Desktop update, tries to install it and fails.
Since this old version of Flatpak doesn't support the mask command, there's nothing you can do and the system constantly warns about a pending update.

@gobalius
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, previous to this change fresh installations of Telegram Desktop via Flatpak were possible on CentOS 7.9, since this change this is no longer the case.

@ilya-fedin
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gobalius sorry, but you can't use the package on that version of CentOS without updating flatpak. You have to update flatpak or switch to the static binary from https://desktop.telegram.org or snap.

@gobalius
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilya-fedin yeah, that is a bit hard to accept when:

  • I can't update flatpak, 1.0.9 is the last in the yum repos, if I try to build it myself, that fails. I tried building 1.11.1 and the latest one - same problem:
    checking for cap_from_text in -lcap... no
    configure: error: *** libcap needed by bubblewrap but not found
    I have libcap installed...
    libcap.x86_64 version 2.22-11.el7
    libcap-ng.x86_64 version 0.7.5-4.el7

  • Static binary from official website only works up to version 4.1.1, newer versions don't open on CentOS 7.9, trying to run with -debug, etc. doesn't really produce a usable output to try and troubleshoot why.

  • snap Telegram Desktop installation has a similar problem to the official static binary - it won't open.

  • I have also tried cloning this flatpak app source, changing this yml file and building my local vesion of it - that also fails:
    flatpak-builder dies here:
    Downloading https://download.qt.io/archive/qt/6.4/6.4.3/submodules/qtbase-everywhere-src-6.4.3.tar.xz
    100 279 100 279 0 0 398 0 --:--:-- --:--:-- --:--:-- 5936
    100 45.8M 100 45.8M 0 0 3601k 0 0:00:13 0:00:13 --:--:-- 4780k
    Failed to download sources: module qtbase: Can't find file at (null)

I feel it's kind of silly that I had version 4.7.1 installed via Flatpak on my system, then trying to get rid of the constant notifications about updates I was trying different things and one of those was uninstalling, which prevents me to get 4.7.1 back.
Now I'm stuck with 4.1.1 offical binary - until it's going to be too old to work.
The system that I'm using is unfortunately a company owned one and it's locked to CentOS 7.9 for the time being, so I have to somehow survive on this OS.
Flatpak is, in my opinion, supposed to be enabling the users of old, unsuported OSes to use the latest applications...

I would accept any solution, but nothing I try is working.

@ilya-fedin
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gobalius static binary should work on CentOS 7 as it's being built on CentOS 7 (though there's plan to move to CentOS 8 in July, but you should have a working non-updatable copy after that), there's apparently some bug you can report at https://github.com/telegramdesktop/tdesktop

@ilya-fedin
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have libcap installed...

When you build something, you need to have -devel versions of those libraries installed for build tools to find them

@gobalius
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-devel versions of libs helped, I got a lot further, but...
Requested 'ostree-1 >= 2020.8' but version of OSTree is 2019.1
This is where I couldn't continue.
I'll open an issue at tdesktop...
@ilya-fedin thanks for trying to help.

@grulja
Copy link
Collaborator

@grulja grulja commented on 705778b Apr 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an alternative solution. Since you build your own Qt, you can revert https://codereview.qt-project.org/c/qt/qtbase/+/256521 for your builds. That way it will make it work even with older Flatpak releases. We did the same in the past in KDE Runtime.

@ilya-fedin
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really want to have that patch in tdesktop patchset indefinitely. The thing is that tdesktop has reverted to having socket in /tmp, so that alone won't work either. Having the socket in the runtime dir is problematic due to multiple different problems, so reverting the revert is also not something I want to do.

@grulja
Copy link
Collaborator

@grulja grulja commented on 705778b Apr 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about runtime detection of Flatpak version? You will find flatpak version in the flatpak-info file. If the version doesn't meet requirements for shared /tmp directory, fallback to $XDG_RUNTIME_DIR and do what Qt did in the past (setting required permissions) in Telegram instead. That way you will not need to modify Qt at all and you will just make it work the way it worked in the past for old Flatpak releases.

@ilya-fedin
Copy link
Collaborator Author

@ilya-fedin ilya-fedin commented on 705778b Apr 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problems of having the socket in the runtime dir still remain. The one of problems is that tdesktop has a really long socket name and flatpak doesn't work with just XDG_RUNTIME_DIR, you have to append the flatpak package name for the files to be shared between instances with flatpak versions older than 1.11.1. As a result, it fails to bind as the path is longer than 108 characters. Another problem is that code becomes really complicated: you have to handle the socket path length problem, you have to special case for flatpak, you have to special case for non-systemd users and finally fancy fairjail users go into your bugtracker and say you can't have a socket in the root of the runtime dir. I have tired of this.

The only way out of this I see is to have platform-dependent single instance communication, with the Linux backend using GApplication (which is already used for portal notifications). But that means putting quite a lot of effort into rewriting tdesktop's single instance communication architecture and then ensuring no other platform breaks. I don't have enough interest to dive into this.

Please sign in to comment.