Signal-desktop: Packages for rpm-based linux distributions like Fedora

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

[AquaL1te]

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.

[AquaL1te]

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

[AquaL1te]

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

[AquaL1te]

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

[AquaL1te]

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

[tuxayo]

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]

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

Regularly updated.

[intika]

Those are not official builds but Luminoso's builds

[tpressure]

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]

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]

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!

[AquaL1te]

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]

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]

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]

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

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/[email protected]
#   node-pre-gyp install --build-from-source

which wants again download something.

[cryptomilk]

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]

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]

Waiting for an official rpm build

[heyakyra]

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

[kaushalyap]

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

[cryptomilk]

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]

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]

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

[bes1002t]

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

[cryptomilk]

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]

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

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

[cmpunches]

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]

This is becoming a joke.

[brian-provenzano]

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

[bes1002t]

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]

~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]

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]

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]

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

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]

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

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

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]

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]

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]

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

[cryptomilk]

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]

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]

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]

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]

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]

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]

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]

I still can't find an RPM for OpenSuse 42.3

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

[adatum]

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:

• Binary RPMs and/or repositories for Fedora and openSuse: https://software.opensuse.org/download/package?package=signal-desktop&project=home%3Aithod%3Asignal
• A helpful blog post with instructions for how to build your own RPMs from source on Fedora: https://stefan.midjich.name/technical/fedora/building_signal_on_fedora/
• negativo17's multimedia repo for Fedora/EPEL which contains Signal-Desktop (note the capitalization). Note that it conflicts with the RPMFusion repo. https://negativo17.org/multimedia/

[sikand]

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

[adatum]

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

[sikand]

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]

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

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