search

signalapp / Signal-Desktop

A private messenger for Windows, macOS, and Linux.
https://signal.org/download
GNU Affero General Public License v3.0
14.5k stars 2.63k forks source link

Packages for rpm-based linux distributions #1630

Closed nikwen closed 2 years ago

nikwen commented 6 years ago

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.

tuxayo commented 6 years ago

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?

ErikLentz commented 5 years ago

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

Regularly updated.

intika commented 5 years ago

Those are not official builds but Luminoso's builds

tpressure commented 5 years ago

Hi,

please help me understand. What was the actual reason to deprecate the Chrome version of Signal without providing alternatives for a wide user base? From my perspective, it can only be bad for the overall reputation of signal because people had something that worked (out of the box), which does not work anymore.

maikell commented 5 years ago

Can I please get a statement on the above or why there's no RPM available. Also, how do I know that COPR repo mentioned above is trust worthy? And why does Signal not mention anything about RPM distro's like Fedora? Kind regards...

pavangayakwad commented 4 years ago

Seriously? this discussion has been going on since from 2017 and no considerable action has been taken on this yet! strange :-) As a fedora user, RPM is expected from my side too!

kees-closed commented 4 years ago

Seriously? this discussion has been going on since from 2017 and no considerable action has been taken on this yet! strange :-) As a fedora user, RPM is expected from my side too!

Consider switching to an alternative messenger, I've done the same. Signal doesn't care about RPM-based distributions.

stemid commented 4 years ago

Signal still has the widest adoption among regular users with relatively good security. @pavangayakwad I'm also on Fedora but I build my own with a .spec file based on this repo.

Just a heads up though, I couldn't get their new build setup to work so I modified their spec file to make it workf or me. I've described the process I use to build Signal here, where you'll also find my spec file linked.

I last used this method just now to upgrade from 1.27.3 to 1.27.4 so I know it works on Fedora 30 (desktop) and F29 (laptop).

pavangayakwad commented 4 years ago

Thanks for taking time and sharing this valuable info @stemid. Quick question, do i have to do this every time when new version of signal is published?

stemid commented 4 years ago

@pavangayakwad An rpm must be built for each version, if you have to do it is up to you. I don't follow the releases that obsessively.

The best thing would be to make a pipeline out of it and that is exactly what the repo I linked has done. But I don't trust some random persons RPM files so I prefer making my own.

Here is that persons copr repo with pre-built RPMs: https://copr-fe.cloud.fedoraproject.org/coprs/drahnr/signal-desktop

Right now it's showing a certificate error.

cryptomilk commented 4 years ago

I'm currently trying to package this monster. A build system with constantly wants to connect to the internet downloading 1711 packages isn't fun. So I'm using a vendor tarball with all the node modules.

The Signal source code is downloaded directly from Github by the OBS service.

https://build.opensuse.org/package/show/home:gladiac:signal/signal-desktop

However there is one last problem with

#   @journeyapps/sqlcipher@4.0.0
#   node-pre-gyp install --build-from-source

which wants again download something.

cryptomilk commented 4 years ago

I still haven't found out how to prevent building sqlcipher without internet access. Build hosts normally don't have access to prevent manipulation and have reproducible builds.

Adding Fedora as a build target would be easy once the it builds once.

cryptomilk commented 4 years ago

I'm still not able to create an offline reproducible build.

However I found ELECTRON_BUILDER_CACHE. But sqlcipher wants to connect to electronjs.org

kaushalyap commented 4 years ago

Waiting for an official rpm build

heyakyra commented 4 years ago

Desktop GNU+Linux is moving to Fedora, and that's where enhanced security is default with SELinux. Why isn't this a priority?

kaushalyap commented 4 years ago

In order to install Signal-Desktop on Fedora use Flatpak : https://hobo.house/2018/03/16/using-signal-desktop-on-fedora-with-flatpak/

cryptomilk commented 4 years ago

I have a package in the openSUSE Build service. The thing is that distributions want reproducible builds! However the is downloading stuff somewhere from the internet even, if you download node modules in advance there are still some modules which download more stuff like electron-builder itself.

I've tried various things that they use existing downloaded code instead of connection to the internet, but it doesn't work. If someone is interested to help:

https://build.opensuse.org/package/show/home:gladiac:signal/signal-desktop

Once we figured this out, it is easy to add more distributions.

rriemann commented 4 years ago

Hey @cryptomilk , the only other app using electron I could find in the opensuse buildservice is slack. They just import an existing rpm file. Many other electron-based apps like Ghost Desktop, Wordpress Desktop, Atom are not in there. Maybe this is reason enough to reach out to the build service community to have a common push for a electron recipe to build such packages.

SchoolGuy commented 4 years ago

Also by the way this issue is linked to this one: https://github.com/signalapp/Signal-Desktop/issues/2718

bes1002t commented 4 years ago

looking forward to this. Hope you find a way to get reproducablebuilds!

cryptomilk commented 4 years ago

I was able to package signal-desktop for openSUSE in the OBS correctly:

https://build.opensuse.org/package/show/home:gladiac:signal/signal-desktop

phrxmd commented 4 years ago

@cryptomilk I get a 404 when trying to access this link. I also don't see it in community packages.

OBS does have an version in the experimental build packages, though: https://build.opensuse.org/package/show/network%3Aim%3Asignal/signal-desktop

cryptomilk commented 4 years ago

Everything moved to https://build.opensuse.org/package/show/network:im:signal/signal-desktop

cmpunches commented 3 years ago

please re-open this ticket, as it is a bad security process to depend on flatpack for package sources -- there is a process for including rpm's in the official repositories. there is also the less used but more standard rpmfusion repositories. please use one or both of those instead of creating supply chain vectors into users' systems with flaky 3rd party package management software

maikell commented 3 years ago

This is becoming a joke.

brian-provenzano commented 3 years ago

I gave up on this a LONG time ago and abandoned signal (sadly).

bes1002t commented 3 years ago

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 commented 3 years ago

~Taking a hint from this comment, https://github.com/signalapp/Signal-Desktop/issues/1630#issuecomment-545336422 I have successfully installed RPM on Fedora 33 from https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/~

~It works well.~

[update] see https://github.com/signalapp/Signal-Desktop/issues/1630#issuecomment-759243909

cmpunches commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

cryptomilk commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

I still can't find an RPM for OpenSuse 42.3

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

adatum commented 3 years ago

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 commented 3 years ago

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

adatum commented 3 years ago

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

sikand commented 3 years ago

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.