i humbly request a deb archive for easy installation under ubuntu, even better would be a ppa or repository (getting it into the ubuntu main repo).
Or at least a normal deb repository, the PPAs are not compatible with Debian
or just a pre-built .deb at least.
yes, also you should add a Fedora repo or a pre-built .rpm, @telegramdesktop please help us with that
Okay, so this can be split into a Debian repository of which can be used for Debian / Ubuntu PPAs and RPM compatible work. Two separate issues, no?
@auchri duplicate of #465 #146
Instead of adding ppa for Ubuntu, copr for Fedora, etc, you can just use OpenSuse OBS (no need to install OpenSuse) for autobuilt multidistro installers.
I think the community can provide initial packaging and then the Telegram team can both:
I am maintaining some packages:
I have no problems creating the packages with OBS.
Also, if you want to add the packages as reference/official packages, do it, just inform me first.
If anybody has some questions about my packaging just ask ahead. :wink:
@telegramdesktop and @auchri some packaging updates:
All the QT dependencies are built successfully, only missing Google Breakpad (should be easy to do).
The major problem is that I want the package to not conflict with the official one; so I'll have to make some dirty work, in order to install the patched QT version alongside with the official package.
Doing in this way, the QT library does not have to be rebuilt every time.
I've backported all the needed packages to Precise, at least it seems to me.
Here there is my PPA: https://launchpad.net/~itachi-san/+archive/ubuntu/telegramdesktop
Later I will try to pack up all the packaging needed for building.
Updates: I tried to repack QT into a "patched version" package. Pretty awful and hard to do (many conflicts to the official package).
What I'm doing now is to automatize sources download and build as for ArchLinux; the main problem is that the build script is not a shell script but a Makefile... So sometimes it complains a little.
Still, I am at a good point: sources folder creation is done, also the major building. Now I am trying to make it as much Debian style as possible. When I'll have a finally working package, I'll upload the sources somewhere.
@ItachiSan There is already a build script for arch, for example the .travis/build.sh
builds telegram desktop from the sources on arch.
@auchri I know, I am using it as reference; however, Debian packaging uses the _debian/rules_ file, which is a Makefile.
Update: I just need to backport some recent ffmpeg package and it should build properly... As of now, it can't find a decent ffmpeg version. Going to fix it really soon.
Backported FFmpeg and everything works properly. Waiting for the PPA to publish the backported zlib, then going to build again (almost everything was built, compilation stuck at minizip code... need at least zlib 1.2.7, available was 1.2.3)
@ItachiSan Isn't it stuck because of undefined type z_crc_t
?
@stek29 Yep, exactly.
I just backported the last zlib (1.2.8) and everything builds fine.
@john-preston @auchri I had some problems during the linking phase, but switching to the gold linker works fine and everything builds. I will do the last touches and tomorrow I will upload everything.
@ItachiSan So problem was old version of zlib... I just included zconf.h
in zip.c
.
Hi, did anybody succeeded building with gyp on debian/ubuntu? I am almost there but had to modify the gyp scripts..
@luckyluke Travis build from .travis/build.sh is building on Ubuntu from scratch.
@ItachiSan Is it possible to get my hands on the mentioned launchpad packages? Can you contact me at https://t.me/preston?
FWIW the package now just landed on the official Debian archive. Although it won't be in Debian stretch, and unless anybody does it (I would actually discourage it, tbh) in the upcoming Ubuntu zesty.
Also, just for the record, I find the packaging overhead needed to get telegram desktop in line with the Debian policy quite overwhelming... (just glance at debian/patches/, if you want to see)
@mapreri that packaging overhead is not that much; it patches Telegram Destkop to work with official QT and use dynamic linking and so system libraries.
The real overhead is to build Telegram Desktop using the Debian build system including the patched QT. That requires a really big effort.
@ItachiSan I mean, I'd very much prefer to dynamic link with system Qt (and other libraries) out of the box, without so much patching.
@mapreri that would be easy if Telegram Desktop could use the official QT.
No patches at source code level would be needed then.
up for the appimage version
With AppImage a minimal subset(!) of a custom Qt can be bundled as shared libraries coming inside the AppImage.
Point of official PPA / rpm / deb repository is not only easy installation - it's updates via distribution package manager (even Microsoft provide repository for Skype). So, AppImage is not solution for this particular issue. If you want AppImage - please fill separate bug-report about it.
Hey there!
We're automatically closing this issue since there was no activity in this issue since 468 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.
Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
(Please note that this is an automated comment.)
if this is in error, let us know with a comment and we'll be happy to reopen the issue.
That was an error.
I install it from https://flathub.org/apps/details/org.telegram.desktop and I doubt I'll use anything else even if we had a native package repo. It works like a charm!
It's always preferable to get software directly from the original author rather than from third party download sites for reasons of trust.
@probonopd Snap is official and is under Telegram deployment control.
You can probably install TDesktop from your distro repos -- if don't trust those, then TDesktop isn't the first thing you should be worried about.
Most helpful comment
It's always preferable to get software directly from the original author rather than from third party download sites for reasons of trust.