Skip to content
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 · 105 comments
Open

Packages for rpm-based linux distributions like Fedora #1630

nikwen opened this issue Nov 1, 2017 · 105 comments

Comments

@nikwen
Copy link

@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
Copy link

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

@kees-closed
Copy link

@kees-closed kees-closed commented Nov 1, 2017

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

@euneuber
Copy link

@euneuber euneuber commented Nov 1, 2017

Please add openSuse to the list of supported Linux distributions!

@zimmski
Copy link

@zimmski 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
Copy link

@sebix sebix commented Nov 2, 2017

@nikwen
Copy link
Author

@nikwen nikwen commented Nov 2, 2017

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

@diazbastian
Copy link

@diazbastian 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
Copy link

@cryptomilk cryptomilk commented Jan 5, 2018

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

@SISheogorath
Copy link

@SISheogorath SISheogorath commented Jan 21, 2018

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

@exploide
Copy link

@exploide 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
Copy link

@wrender 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
Copy link

@wrender wrender commented Feb 3, 2018

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

@rriemann
Copy link

@rriemann 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
Copy link

@cryptomilk 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
Copy link

@rriemann 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
Copy link

@steelstring94 steelstring94 commented Feb 8, 2018

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

@diazbastian
Copy link

@diazbastian 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
Copy link

@cryptomilk 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
Copy link

@exploide 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
Copy link

@cryptomilk 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
Copy link

@diazbastian 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
Copy link

@sevagh 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
Copy link

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

@ErikLentz
Copy link

@ErikLentz ErikLentz commented Feb 20, 2018

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

@kees-closed
Copy link

@kees-closed kees-closed 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
Copy link

@SISheogorath 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)

@bes1002t
Copy link

@bes1002t bes1002t commented Jan 12, 2021

Any progress in this feature request?
Would be very helpful to have this available in the future.

If this is not possible, why not providing a web version like Threema?

@cynici
Copy link

@cynici cynici commented Jan 13, 2021

Taking a hint from this comment, #1630 (comment)
I have successfully installed RPM on Fedora 33 from https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

It works well.

[update] see #1630 (comment)

@cmpunches
Copy link

@cmpunches cmpunches commented Jan 13, 2021

Don't use a COPR for distribution of a security-sensitive application. Submit an RPM SPEC to a reputable repo like RPMFusion or Fedora proper.

@cynici
Copy link

@cynici cynici commented Jan 13, 2021

Don't use a COPR for distribution of a security-sensitive application. Submit an RPM SPEC to a reputable repo like RPMFusion or Fedora proper.

@cmpunches thank you for a heads up. I'm a fedora noob.

@bes1002t
Copy link

@bes1002t bes1002t commented Jan 13, 2021

@cynici that has nothing to do with fedora, I think in general security sensitive applications should only be installed from the official repository of the distribution, or at least from the developers

@cryptomilk
Copy link

@cryptomilk cryptomilk commented Jan 14, 2021

I have signal-desktop building from source (including webrtc, ringrtc and zkgroup) for openSUSE. The next step is to build electron from sources.

I've started to make multi distro build for nodejs as you need to build with the same nodejs version on all distros. So Fedora is on the plan but will take time.

@bes1002t
Copy link

@bes1002t bes1002t commented Jan 14, 2021

@cryptomilk thanks for taking care of this!

Is it possible to add this multi distro build into Fedroa DNF repository? This would help a lot keeping the client up to date. :)

@cmpunches
Copy link

@cmpunches cmpunches commented Jan 14, 2021

@cryptomilk
I may be misunderstanding your intent -- you intend to build one rpm to distribute to multiple distros' repos?

If that is the case I might suggest generating an RPM for each distro to avoid problems.

Unless you're using mock with Fedora profiles, there's not really such a thing as a "multi-distro build" when it comes to packaging even if the filename ends in ".rpm" due to dependency tree variance between distros. Think of the linker.

If it's compiled, you've got layers of dependencies that will vary by existence and versioning between distros. It's that way if it's not compiled, but in those cases dependency tree items can be filled in so it's a little safer but not much -- things will break with naming discrepancies so requires a different package build.

I had this same conversation with the Slack team when they were failing to package their software -- electron is problematic unless packaged carefully -- it is really a distro-specific thing and should have distro-specific packages.

It is not hard to build an RPM though. Just script it up for each distro with mock. I doubt Fedora will accept a "multi-distro build" rpm because of the general lack of feasibility of the artifacts created.

https://docs.fedoraproject.org/en-US/packaging-guidelines/

These toolchains are not intended to build cross-distro compatible packages, so, I would be surprised if they conform to the packaging guidelines for Fedora.

So, my suggestion is to use mock with a Fedora profile to make a Fedora-specific RPM containing Fedora-compiled artifacts depending on Fedora-named dependencies.

@cmpunches
Copy link

@cmpunches cmpunches commented Jan 14, 2021

Some informative links since there are parts of this that are unfamiliar:

Please see:
https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault

Also:

"To be an official fedora package it would have to build in koji - they can't just upload an rpm built in suse's multi distro build system" (T. Hughes)

@cmpunches
Copy link

@cmpunches cmpunches commented Jan 15, 2021

I owe this thread and related threads an apology -- after significant discussion in #fedora-devel where the package maintainers discuss things like this for Fedora on FreeNode, it's painfully clear that nodejs and electron distribution, are NOT solved problems in the Fedora ecosystem and they ARE inclining these types of things to be met by FlatPak and similar until a solution is found.

It should be noted that this is yet another architectural problem with nodejs itself, where pieces want to independently pull things to the systems as needed as opposed to relying on an integrated package management solution, but, a bigger issue for another day.

I hope that the solution here is for Signal to ultimately decouple itself from the client, release specs for the APIs this interacts with, and let the community supply viable clients to use the service in more suitable runtimes.

:: disappears ::

@cryptomilk
Copy link

@cryptomilk cryptomilk commented Jan 15, 2021

I may be misunderstanding your intent -- you intend to build one rpm to distribute to multiple distros' repos?

If that is the case I might suggest generating an RPM for each distro to avoid problems.

Unless you're using mock with Fedora profiles, there's not really such a thing as a "multi-distro build" when it comes to packaging even if the filename ends in ".rpm" due to dependency tree variance between distros. Think of the linker.

You might want to look into how the build service works. You can build packages for most of the Linux distributions out there. And by the way I'm a Fedora packager too.

nodejs is a pain .. ... ... for packagers. The signal-desktop build process pulls binary blobs and header files somewhere from the internet. You have to do a lot of hacks to actually disconnect the build process from the net, so it only builds with the things you have in your build environment, else you don't have a reproducible build ...

Everything from Google is also horrible. You have to download gigabytes of source codes for webrtc. Then you have to hack it again that it builds against system libraries instead of integrated version. Electron is another story.

@blalyasar
Copy link

@blalyasar blalyasar commented Jan 15, 2021

For fedora desktop with dnf package manager . https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

@cryptomilk
Copy link

@cryptomilk cryptomilk commented Jan 16, 2021

For fedora desktop with dnf package manager . https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

It isn't new that people create signal packages in copr. This is also not a reproducible build and this is the nut to crack ...

@Borderliner
Copy link

@Borderliner Borderliner commented Jan 22, 2021

For fedora desktop with dnf package manager . https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

It isn't new that people create signal packages in copr. This is also not a reproducible build and this is the nut to crack ...

I personally don't mind it not being reproducible, as long as it works and is regularly updated.

@melonmouse
Copy link

@melonmouse melonmouse commented Jan 25, 2021

I owe this thread and related threads an apology -- after significant discussion in #fedora-devel where the package maintainers discuss things like this for Fedora on FreeNode, it's painfully clear that nodejs and electron distribution, are NOT solved problems in the Fedora ecosystem and they ARE inclining these types of things to be met by FlatPak and similar until a solution is found.

It should be noted that this is yet another architectural problem with nodejs itself, where pieces want to independently pull things to the systems as needed as opposed to relying on an integrated package management solution, but, a bigger issue for another day.

I hope that the solution here is for Signal to ultimately decouple itself from the client, release specs for the APIs this interacts with, and let the community supply viable clients to use the service in more suitable runtimes.

:: disappears ::

Thanks so much for your research+reply. Would it be possible to outline what needs to be done to fix the nodejs and electron distribution (if that's clear)? Or is that tracked elsewhere? Perhaps I (and others) could help out if there are actionable points.

@stemid
Copy link

@stemid stemid commented Jan 25, 2021

Since this thread is huge now I thought I'd just repeat that it is quite simple to build Signal-desktop yourself.

I do it regularly thanks to this repo and this guide (my own blog).

Because I don't want to add a bunch of copr repos on my clean Fedora system so I prefer this method.

As far as getting a Signal-desktop package into Fedora, you'll have to sign up for the Fedora maintainers group and try to get a sponsor to tell you what needs to be fixed with the packaging. It takes some time and commitment, so until someone can find that I'll just keep building it myself.

@AlbinoGeek
Copy link

@AlbinoGeek AlbinoGeek commented Jan 26, 2021

It takes 5,000 people requesting and 4 years to add alien to your build process? Or just... actually build an RPM?

I guess I'll just run alien myself -_-


Just read about the issues risen in #fedora-devel , which are totally fair, but have not stopped other electron applications from being ported to Fedora (so.. I don't understand what the issue is here.) I have RocketChat, Discord and a number of other electron applications packaged and built as RPMs just fine..?

@cryptomilk
Copy link

@cryptomilk cryptomilk commented Jan 26, 2021

Thanks so much for your research+reply. Would it be possible to outline what needs to be done to fix the nodejs and electron distribution (if that's clear)? Or is that tracked elsewhere? Perhaps I (and others) could help out if there are actionable points.

In the openSUSE build service, we need to build nodejs for Fedora, this is mostly making the current RPM supporting multiple distributions.

The next step is to build electron from sources. You can take a look at the chromium package how it is built. It is also similar to the signal-webrtc package. Both use the same build system (gn).

https://build.opensuse.org/package/show/network:im:signal/

@cryptomilk
Copy link

@cryptomilk cryptomilk commented Jan 26, 2021

As far as getting a Signal-desktop package into Fedora, you'll have to sign up for the Fedora maintainers group and try to get a sponsor to tell you what needs to be fixed with the packaging. It takes some time and commitment, so until someone can find that I'll just keep building it myself.

As a proven Fedora packager I can tell you that it isn't as simple as you think it is.

@sikand
Copy link

@sikand sikand commented Mar 3, 2021

I still can't find an RPM for OpenSuse 42.3

What am I missing ? I just want to run Signal desktop.

@adatum
Copy link

@adatum adatum commented Mar 3, 2021

I still can't find an RPM for OpenSuse 42.3

What am I missing ? I just want to run Signal desktop.

It doesn't exist officially.

Unofficial options mentioned in this thread:

@sikand
Copy link

@sikand sikand commented Mar 3, 2021

I am now running via flatpak, it was (mostly) painless. thanks @adatum

@adatum
Copy link

@adatum adatum commented Mar 3, 2021

Sure, but you asked about an RPM, and flatpack != RPM. That dead horse has been beaten enough...

@sikand
Copy link

@sikand sikand commented Mar 3, 2021

Indeed, I tried the first link you sent previously and no luck with a modern opensuse so I gave up !

Frankly, I am still struggling to understand why there is no native RPM but if the horse is dead.....so be it.

@phrxmd
Copy link

@phrxmd phrxmd commented Mar 5, 2021

@sikand OpenSUSE Leap 42 is hardly a modern OpenSUSE. It was released in 2015 and manufacturer support ended several years ago.

For OpenSUSE Tumbleweed and Leap 15.2 there are packages that you can find at https://software.opensuse.org/package/signal-desktop - they're labeled "experimental" (which means mainly they haven't made their way into the main distribution yet), but I'm running it right now under OpenSUSE TW and it runs fine.

@m5shiv
Copy link

@m5shiv m5shiv commented Mar 5, 2021

@phrxmd Thanks for the reality check. Upgraded to 15.2 and all is well

@coldserenity
Copy link

@coldserenity coldserenity commented Mar 29, 2021

Just donated to Signal with comment Sponsoring "Packages for rpm-based linux distributions like Fedora" #1630

@cmpunches
Copy link

@cmpunches cmpunches commented Mar 29, 2021

Just donated to Signal with comment Sponsoring "Packages for rpm-based linux distributions like Fedora" #1630

@coldserenity In appreciation for your financial support and validation of this issue, I will now perform a dance for you.

You can't see it since this is a text-based medium, but I am dancing, and it is a spectacular performance.

Thanks again.

@5x3
Copy link

@5x3 5x3 commented Jun 5, 2021

Please do not donate for it.
From a security standpoint the developer HAVE TO provide statically linked (not dynamically linked with other libs) binaries without packaging to RPM or DEB for a such "secure" messenger since user may download trojan wile searching RPM package.

Take a look at the Telegram approach for Linux and do the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet