Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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
705778bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you build something, you need to have -devel versions of those libraries installed for build tools to find them
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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.
705778bThere was a problem hiding this comment.
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-infofile. If the version doesn't meet requirements for shared/tmpdirectory, fallback to$XDG_RUNTIME_DIRand 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.705778bThere was a problem hiding this comment.
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.