Packages for rpm-based linux distributions

[nikwen]

• [x] I have searched open and closed issues for duplicates

---

Currently, Signal-Desktop is only available for Debian-based distros with the APT package manager. Please provide pre-built packages for rpm-based distributions such as Fedora or RHEL.

[janvlug]

It would also be good to warn before the migration that there are only .deb packages. I did the migration to learn only after that the Chrome Desktop is disabled that there are is no RPM installer available.

[kees-closed]

Flatpak would also do the trick, no need for deb or rpm packaging.

[euneuber]

Please add openSuse to the list of supported Linux distributions!

[zimmski]

Please use the open build service http://openbuildservice.org/ to build packages. I do not know if the public instance https://build.opensuse.org enabled building packages for all major distributions, but the service application itself has the functionality https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto, https://en.opensuse.org/openSUSE:Build_Service_Debian_builds. I am sure that the build service guys will support you with the configuration of your projects.

[sebix]

On 11/02/2017 10:52 AM, Markus Zimmermann wrote:

I do not know if the public instance [https://build.opensuse.org] enabled building packages for all major distributions,

Yes, it does. I can help with OBS for deb- and rpm packages.

[nikwen]

For everyone in need of a transitional solution: Check out https://github.com/WhisperSystems/Signal-Desktop/pull/1627.

[diazbastian]

I think it's #1639 is a better solution. Besides being a more "universal" option is the path where fedora is headed anyway.

[cryptomilk]

I don't see why #1639 is a better solution. Especially from a security point of view ...

[SISheogorath]

There is one complete deal breaker for #1639: Missing ibus support on Flatpaks.

[exploide]

There is one complete deal breaker for #1639: Missing ibus support on Flatpaks.

I don't know what exactly you miss, but according to https://github.com/flatpak/flatpak/issues/675, flatpak does support ibus now.

[wrender]

An RPM would be nice. I think the idea of these other package types are good, but they need to be built into base linux OS's by default before they are actually useful.

[wrender]

So does anyone have a way of building an rpm yet?

[rriemann]

There is an rpm for suse. Note that it is a user contribution and may not be trustworthy.

https://software.opensuse.org/package/signal-desktop

spec file: https://build.opensuse.org/package/view_file/home:ithod:signal/signal-desktop/signal-desktop.spec

[cryptomilk]

I dicussed that with some friend yesterday. Packaging Signal is probably a huge task. However it could be done in the build service on a collaborative effort. The build services can also grab signed git tags and verify the signature. So you can rely on the integrity of the source code that way.

However, the biggest effort would be to package all the nodejs modules and other dependencies not available yet. They are not available and that would need to be done first. The spec @rriemann mentions is a bad packaging example. It includes just everything instead of packaging the dependencies.

Is 'npm install' actually checking signatures, is it trustworthy?

[rriemann]

On the security issues introduced by npm dependencies: https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

I imagine that Signal is carefully reviewing all packages and then all updates of them and their dependencies and guess that like ruby packages, npm package versions are locked.

Opensuse has some tool to package npms: https://github.com/marguerite/nodejs-packaging

Please read the ideas in the repo readme on some general remarks on node module packaging. In essence: packaging dependencies of node modules and their node modules to a global namespace does not make sense from their point of view.

[steelstring94]

Just here to agree that an RPM version would be much appreciated, as a Fedora user.

[diazbastian]

I don't know if the way is to duplicate the efforts in maintaining different options, but as I mentioned before, the path of fedora is towards the use of flatpak, on the other hand this alternative works in a wide range of other distributions.

@cryptomilk Could you be more specific?

[cryptomilk]

Distributions and package managers have been invented so that packages stay up to date and share resources.

flatpak doesn't share resources with my system it loads another Linux system into RAM (libc, xorg, gtk, openssl etc.) I don't really know if this system keeps up with security updates. It is a waste of resources just running a simple messenger.

[exploide]

While I totally agree that package maintainers of classical package repositories are important and do a good job, there are also reasonable usecases for Flatpak.

Most importantly to bundle proprietary software. Not that I like this kind of software but sometimes some people need it and classically it comes with an obscure install.sh and does horrible thing to your system. Flatpak is really a better bet there.

Additionally, even for FLOSS software, if a program is hard to package and the responsibility remains at the software authors, not the distribution's package maintainers, then the use of Flatpak can decrease their effort needed to serve to more Linux users. This is the case here. You say "simple messenger" but this is not what Signal Desktop is. It is based on Electron, and Fedora packagers didn't manage to include the closely associated Atom editor in the repositories, yet. The Electron/Chromium/Node stuff is simply too much effort. And here for OWS it is simpler to provide a distribution independent Flatpak than to manage multiple distribution specific build systems.

[cryptomilk]

I've just updated flatpak and Signal doesn't work anymore:

flatpak run org.signal.Signal
Gtk-Message: Failed to load module "canberra-gtk-module"
No protocol specified

My distro is better maintained ...

[diazbastian]

@cryptomilk I thought you had technical arguments against it, but I see that simply "the new model is not to your liking". With Flatpak, applications can be distributed directly from their providers, so in theory security updates will be obtained more quickly by its users than through an intermediary (maintainer). It also offers isolation and its runtime system allows resource sharing and deduplication, etc.

My Signal installation works properly for me, maybe you should update the runtime.

[sevagh]

Why does the path to Fedora necessarily involve endless circular discussions about Flatpak, while Debian-based distros are sitting happy with their debs? Whatever arguments you provide for not providing RPMs should be applied to block the release of debs as well.

[rriemann]

Can we please have the flatpak discussion somewhere else? I use opensuse and have never installed an app like this. However, I know how to deal with rpms. That's a widely used standard and if it is imperfect, than maybe the distros should invest into flatpak before individual applications do so.

My observations:

• If I cannot trust my distro and their build system, I cannot use my computer. I would need to assume keyloggers that take my data even before it is encrypted on the app level by e.g. Signal.
• I have to trust Signal.
• Both my distro and Signal are opensource which makes trust easier.
• So after all these assumptions, I do not understand the problem to also trust opensuse to checkout the code from signal, check the signatures and build using a transparent tool chain a trustworthy rpm.
• Same argument goes for Fedora.

I agree that packaging of npm deps is difficult, but I do not see how flatpak can provide an advantage here.

[ErikLentz]

If they're going to provide a deb, they need to provide an rpm.

[kees-closed]

I just noticed that in GNOME Software (on Fedora) a Signal Flatpak is available via FlatHub. It installed and works like a charm, it's the latest Signal Desktop edition. I consider the issue closed.

[SISheogorath]

@AquaL1te no, it's not. Neither does this flatpak support ibus, nor is it build against Fedora libraries.

Apart from this there is a noticeable difference when you install an application as flatpak or install it as a native application. It starts at CLI integration, differences in the security setup, cache-ability, which is actually more complicated with Flatpaks (apart from the point that a lot of people have RPM caches in place, while no flatpak cache right now), …

So it's far from being solved, even when the flatpak exists and is for a lot of people a valid alternative. (yes, I use it myself for month, but for all communication that needs some more special letters, I have to use my phone)

[cryptomilk]

Signal via flatpak requires 850 MB of additional space (just the runtime) and 1.2G of additional RAM (loading the runtime) just for a messenger app.

[exploide]

@SISheogorath concerning your ibus problems, maybe if you open an issue at https://github.com/flathub/org.signal.Signal, @bermeitinger-b or the Flatpak/Flathub folks might have an idea how to fix that

[kees-closed]

@cryptomilk you're greatly exacerbating those requirements. If you use Fedora already then Flatpak will become more dominant anyway. No developer is forced to provide deb/rpm packages for their software, that gap can be filled with community support. Packaging it won't be such a big deal, you already have an example based on the deb. But, why bother ;)

[heyakyra]

@AquaL1te I'm wary of installing unofficial builds for something security-oriented

[isaiahfrantz]

I just wanted the stand alone to work on fedora so here is what I did: 1) spin up an ubuntu vm 2) add signal repo as described in their install popup 3) apt download signal-desktop 4) extracted the files: ar vx signal-desktop*deb; tar xJf data.tar.xz 5) move files to host: mkdir signal;mv opt/ usr/ signal/;tar cJf signal.tar.xz signal/; cp signal.tzr.xz /media/vb_share/ 6) (on host) tar xJf signal.tar.xz; signal/Signal/signal-desktop 7) I get to use signal-desktop until an rpm is released 8) profit?

It is some manual hoops to jump through and it may not stay up-to-date, I havent seen it try to update itself yet so I dont know if it will. I probably could have just built the project from source but Im lazy... :P

[ckujau]

I've cobbled together something like this to install Signal to /opt/Signal Beta on my Fedora desktop.

[cryptomilk]

I will look into it as soon as the OpenBuildService supports gpg signatures and Signal starts to sign their git tags ...

[sebix]

I will look into it as soon as the OpenBuildService supports gpg signatures

Do you mean the verification of the sources? https://en.opensuse.org/openSUSE:Package_source_verification

[cryptomilk]

I mean https://github.com/openSUSE/obs-service-tar_scm/issues/127

[sadsfae]

Here's a guide to setting up signal via flatpak on Fedora (I just walked through it) but I'd prefer to see official RPM builds as well and hope that it gets added.

[kees-closed]

@thekyriarchy and others who don't regard Flathub as a trusted source, please have a look at the submission process. Flathub is intended to centralize distribution without having fragmented releases over different Linux distributions. This is also the reason Steam has been removed from RPM Fusion, it's now available on Flathub. More applications like e.g. Skype and Spotify will choose this way to distribute their software. IMHO there is really no real benefit of having a native RPM, but that's just me of course. If you do want an RPM, then feel free to package it yourself. There is no rule that devs should package their own software for your favorite distribution.

[SISheogorath]

@AquaL1te while I agree that flathub is a great way to provide software, I think the debate "a flatpak is enough" is actually off-topic here as in many other places.

It's a bit like a tabs vs spaces debate. Both sides have valid arguments. There is no final answer right now. And yes, there is no rule that anyone has to provide package format X but that's not the point of this issue. It's a friendly question by people who would like to have an .rpm package.

The entire flatpak, appimage, snap, … vs. .deb, .rpm, … debate is pointless at least in issues that ask for a package format. If the signal devs doesn't want to do it, no problem, just close the issue with "won't fix" but that didn't happen now.

So could people please stop to run around and tell everyone "oh you can use flatpak instead" when people explicitly ask for an RPM even after 20 times of mentioning flatpak or snap.

[sadsfae]

Adding here there is a huge install base between CentOS, RHEL, and derivatives like Scientific Linux as well as Fedora. It would only be a benefit to Whisper Systems (especially in the corporate messaging space where these platforms are very prevalent) to put in the effort to also provide officially released RPMs. At the core of Signal is privacy, security and trust and I'd imagine most people using Signal would view 3rd party resources not in the same favourable light as something signed/verified by Whisper Systems builders.

[kees-closed]

@sadsfae the thing is, that the Signal installation that's available on Flathub is from the developers. The whole point of Flathub is to allow developers to directly provide their software to their users without a 3rd party.

Edit: I stand corrected by @yithian and @ejpcmac, although the Flathub submission process seems to strongly favor devs to publish their own work, there is indeed, if upstream is not willing to contribute, an option for other people to submit a package to Flathub.

[yithian]

@AquaL1te https://github.com/signalapp/Signal-Desktop/issues/1639#issuecomment-350656714 implies otherwise and https://signal.org/download/ doesn't mention anything about flatpak.

Am I misunderstanding?

[ejpcmac]

@sadsfae Developers can provide their software on Flathub, but as far as I know the Signal one is not maintained by a Signal team member.

Aside: I subscribed to this issue a while ago to be informed about news on the RPM status. Please discuss Flatpak issues elsewhere, there is a lot of junk mail involved.

[ErikLentz]

I agree that the Flatpak discussion is irrelevant to this question. Unless the discussion is whether to transition Signal to only Flatpak, and eliminate distro-specific releases, I feel like it's perfectly reasonable to ask for an RPM build.

Here is a copr repo that is updated, although it is not official: https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

[BastianBalthasarBux]

+1 for getting an official rpm package!

[sadsfae]

Thank you for providing a COPR repo, that's good enough for me but I know many others would love to see an official RPM (though I quite like Flatpak now after using it :) I've updated my signal flatpak blog post to reference this.

[codewiz]

I know many others would love to see an official RPM

Most packages in Fedora and in other Linux distros are actually not maintained by the original developer of the software, and that's usually a good thing because distro packagers are more likely to care follow the guidelines of the distribution for consistency and integration with other packages. App developers sometimes make choices to maximize the visibility of their own product even when it hurts the overall user experience (like displaying splash screens, installing icons in multiple locations, claiming many mime type, etc).

I quite like Flatpak now after using it :)

I tried the flatpak too, but it seems to re-import all messages every time it starts, and it takes a couple of minutes in my case. Is this how the Signal Desktop app normally behaves?

[exploide]

@codewiz

Regarding the first point: Since Signal-Desktop is Electron-based and even the first Electron-based application Atom didn't make it into official distribution's repositories, it is rather unlikely that Signal-Desktop will be in the foreseeable future. This is because Electron/NodeJS stuff is rather hard to package when strict guidelines must be adhered. So you will only see unofficial repositories or one from the Signal developers (if they decide to).

Regarding the second point: It is normal that Signal-Desktop syncs the messages that got delivered to your phone while Desktop was offline first. But not the whole conversation history. Try starting Signal-Desktop when there is nothing to sync, it should take only a few seconds. Otherwise it's a bug.

BTW, the amount of posts in this issue is very high. Most points better fit to the community forum.

[stemid]

@ckujau

I've cobbled together something like this to install Signal to /opt/Signal Beta on my Fedora desktop.

This is not a bad workaround that should be emphasized for others who find this thread. It helped me install Signal on Fedora 26 after a few tweaks to the script.

There is no 512 checksum in the InRelease file. So I changed that to 256 which works just as well.

[drahnr]

So I fiddled a little with the Signal-Desktop buildsystem, and actually yarn can spit out an rpm package too, just like it does for deb.

Until this becomes integrated and official, feel free to grab the package of ~1.11.0~ 1.14.1 (in any kind of version or security need you feel):

github spec file source: https://github.com/drahnr/signal-desktop-rpm copr rpm repo: http://copr-fe.cloud.fedoraproject.org/coprs/drahnr/signal-desktop/ ci pipeline: https://ci.spearow.io/teams/main/pipelines/signal-desktop

Update: Note that currently things are borked and the builds for copr fail, while local building works.

[ghost]

What are the current technical blockers for OWS to set up a rpm-repo like microsoft does for its distribution of vscode, also an electron application ?