New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages for rpm-based linux distributions like Fedora #1630

Open
nikwen opened this Issue Nov 1, 2017 · 54 comments

Comments

Projects
None yet
@nikwen

nikwen commented Nov 1, 2017

  • 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

This comment has been minimized.

janvlug commented Nov 1, 2017

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.

@AquaL1te

This comment has been minimized.

AquaL1te commented Nov 1, 2017

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

@euneuber

This comment has been minimized.

euneuber commented Nov 1, 2017

Please add openSuse to the list of supported Linux distributions!

@zimmski

This comment has been minimized.

zimmski commented Nov 2, 2017

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

This comment has been minimized.

sebix commented Nov 2, 2017

@nikwen

This comment has been minimized.

nikwen commented Nov 2, 2017

For everyone in need of a transitional solution: Check out #1627.

@diazbastian

This comment has been minimized.

diazbastian commented Nov 2, 2017

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

@cryptomilk

This comment has been minimized.

cryptomilk commented Jan 5, 2018

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

@SISheogorath

This comment has been minimized.

SISheogorath commented Jan 21, 2018

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

@exploide

This comment has been minimized.

exploide commented Jan 22, 2018

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

I don't know what exactly you miss, but according to flatpak/flatpak#675, flatpak does support ibus now.

@wrender

This comment has been minimized.

wrender commented Jan 22, 2018

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

This comment has been minimized.

wrender commented Feb 3, 2018

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

@rriemann

This comment has been minimized.

rriemann commented Feb 4, 2018

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

This comment has been minimized.

cryptomilk commented Feb 4, 2018

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

This comment has been minimized.

rriemann commented Feb 4, 2018

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

This comment has been minimized.

steelstring94 commented Feb 8, 2018

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

@diazbastian

This comment has been minimized.

diazbastian commented Feb 8, 2018

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

This comment has been minimized.

cryptomilk commented Feb 8, 2018

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

This comment has been minimized.

exploide commented Feb 8, 2018

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

This comment has been minimized.

cryptomilk commented Feb 8, 2018

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

This comment has been minimized.

diazbastian commented Feb 8, 2018

@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

This comment has been minimized.

sevagh commented Feb 9, 2018

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

This comment has been minimized.

rriemann commented Feb 9, 2018

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.

@smeggysmeg

This comment has been minimized.

smeggysmeg commented Feb 20, 2018

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

@AquaL1te

This comment has been minimized.

AquaL1te commented Feb 27, 2018

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.

screenshot from 2018-02-27 10-56-23
screenshot from 2018-02-27 10-56-30
screenshot from 2018-02-27 10-58-18

@SISheogorath

This comment has been minimized.

SISheogorath commented Feb 27, 2018

@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

This comment has been minimized.

cryptomilk commented Feb 27, 2018

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

This comment has been minimized.

exploide commented Feb 27, 2018

@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

@AquaL1te

This comment has been minimized.

AquaL1te commented Feb 27, 2018

@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

This comment has been minimized.

heyakyra commented Mar 14, 2018

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

@isaiahfrantz

This comment has been minimized.

isaiahfrantz commented Mar 15, 2018

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

This comment has been minimized.

ckujau commented Mar 15, 2018

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

@cryptomilk

This comment has been minimized.

cryptomilk commented Mar 15, 2018

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

@sebix

This comment has been minimized.

sebix commented Mar 15, 2018

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

This comment has been minimized.

cryptomilk commented Mar 15, 2018

@sadsfae

This comment has been minimized.

sadsfae commented Mar 16, 2018

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.

@AquaL1te

This comment has been minimized.

AquaL1te commented Mar 16, 2018

@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

This comment has been minimized.

SISheogorath commented Mar 16, 2018

@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

This comment has been minimized.

sadsfae commented Mar 16, 2018

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.

@AquaL1te

This comment has been minimized.

AquaL1te commented Mar 16, 2018

@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

This comment has been minimized.

yithian commented Mar 16, 2018

@AquaL1te #1639 (comment) implies otherwise and https://signal.org/download/ doesn't mention anything about flatpak.

Am I misunderstanding?

@ejpcmac

This comment has been minimized.

ejpcmac commented Mar 16, 2018

@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.

@smeggysmeg

This comment has been minimized.

smeggysmeg commented Mar 16, 2018

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

This comment has been minimized.

BastianBalthasarBux commented Mar 25, 2018

+1 for getting an official rpm package!

@sadsfae

This comment has been minimized.

sadsfae commented Apr 5, 2018

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

This comment has been minimized.

codewiz commented Apr 6, 2018

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

This comment has been minimized.

exploide commented Apr 6, 2018

@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

This comment has been minimized.

stemid commented May 3, 2018

@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

This comment has been minimized.

drahnr commented May 17, 2018

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 rpm.

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

@flocomkoko

This comment has been minimized.

flocomkoko commented Jul 17, 2018

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 ?

@tuxayo

This comment has been minimized.

tuxayo commented Aug 5, 2018

Some previous message:

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

@flocomkoko

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 ?

Isn't that better to contribute having official packages for Atom and then for Signal Desktop?

@intika

This comment has been minimized.

intika commented Nov 6, 2018

A quick solution for rpm based system :

  1. download the debian package from here
    https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.17.3_amd64.deb

  2. Extract it and use it like a portable package...

I tried to convert that deb package to rpm with "alien -r" but i had some errors i did not analyze it further and or tried to convert it as the application just work as portable package... but if any one would take time to do that should be easily doable with some modifications and "alien"

@smeggysmeg

This comment has been minimized.

smeggysmeg commented Nov 7, 2018

I use this copr repo: https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

Regularly updated.

@intika

This comment has been minimized.

intika commented Nov 7, 2018

Those are not official builds but Luminoso's builds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment