-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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 #1630
Comments
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. |
Flatpak would also do the trick, no need for deb or rpm packaging. |
Please add openSuse to the list of supported Linux distributions! |
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. |
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.
|
For everyone in need of a transitional solution: Check out #1627. |
I think it's #1639 is a better solution. Besides being a more "universal" option is the path where fedora is headed anyway. |
I don't see why #1639 is a better solution. Especially from a security point of view ... |
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. |
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. |
So does anyone have a way of building an rpm yet? |
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 |
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? |
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. |
Just here to agree that an RPM version would be much appreciated, as a Fedora user. |
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? |
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. |
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 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. |
I've just updated flatpak and Signal doesn't work anymore:
My distro is better maintained ... |
@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. |
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. |
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:
I agree that packaging of npm deps is difficult, but I do not see how flatpak can provide an advantage here. |
If they're going to provide a deb, they need to provide an rpm. |
@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) |
Yes indeed, but as long as there is no official Fedora version (from @signalapp) , I prefer to build my own RPM package, for security reasons |
As a Fedora proven packager, I'm more trustworthy if I package Signal in Fedora than outside? |
This is about the trustworthyness of a package, not you as a person. You can't expect people to memorize the list of proven packagers, they shouldn't even need to know what that title means. (Congratulations, by the way.) A package in the Fedora repositories or rpmfusion will always be more trustworthy than copr or other sources and I believe this is a good thing. |
I would argue that nodejs apps per default are not trustworthy. You should be careful how you run them. I have signal-desktop still secured with apparmor. Here is a
|
@cryptomilk |
That's not possible as Fedora 35 doesn't provide ffmpeg. I've just recently added ffmpeg to Fedora, it will be available with Fedora 36. You have to wait till f36 is out ... |
You can build your own Signal-Desktop rpm for Fedora 35 with this project @piotr-dobrogost https://github.com/BarbossHack/Signal-Desktop-Fedora That's what I'm using, and no problem so far on Fedora 35 |
It would be very very interesting to know how exactly you secured it with AppArmour. Would you mind sharing it? Thank you in advance. |
You can find the apparmor files here: |
The Docker build by BarbossHack works great. The following recipe could serve as a plan B. An approach to building
|
Now Fedora 36 package are available at: https://software.opensuse.org/download.html?project=network:im:signal&package=signal-desktop |
@cryptomilk |
Donate the money to either https://signal.org/donate/ or https://sfconservancy.org/donate/ or both :-) |
Thanks, wonderful! Thank you for your hard work on this. Will this be in the official repo soon? There is also this package from the one in the copr by luminoso: https://github.com/luminoso/fedora-copr-signal-desktop but it would be great to have an official package. Don't know if that is your plan. |
network:im:signal is way superior to mine. My understanding is that it builds signal and its dependencies offline and without pre-built binaries shipped along with the repo. On the other hand, my copr repo is way simpler. Just grabs signal-desktop repo and builds it. It requires internet connection and uses pre-built binaries from it. Wishful thinking that those binaries present in this signal-desktop repository are trustable 🤷 |
network:im:signal builds everything from sources and uses system components like ffmpeg, system fonts etc. Also it has a nodejs-electron package. To bring everything into Fedora is quite some work, the first step would be to bring nodejs-electron into Fedora. |
Has anyone using a signal repo like network:im:signal managed to upgrade from Fedora 36 to 37?
Related packages are blocking the upgrade for me. I could uninstall signal, upgrade, and reinstall, but I'd like to avoid that if possible to prevent having to re-configure signal and losing conversation history. |
@adatum I do use it and upgraded 36->37 successfully. |
Good to know upgrading worked for you.
|
@adatum I had same problem at some moment, but I did wait couple of weeks and it disappeared. Some packages just were updated in repos, I guess. signal-desktop-6.0.1-1.1.x86_64 |
Thanks for that info with the version numbers. I have the same versions for
I might wait a while longer in case the upgraded versions of those libraries come to F36, especially while waiting for a similar blocking problem with |
to install from (opensuse's fedora 37 repo) network-im-signal and have access to updates even after distro upgrades beyond fedora 37: curl -L \
-o /tmp/network_im_signal.repo \
http://download.opensuse.org/repositories/network:/im:/signal/Fedora_37/network:im:signal.repo
sed -i 's/37/$releasever/g' /tmp/network_im_signal.repo
sudo dnf config-manager --add-repo /tmp/network_im_signal.repo
sudo dnf update
sudo dnf install -y signal-desktop |
The repo: https://download.opensuse.org/repositories/network:/im:/signal/Fedora_38/ does not have the signal-desktop rpm for Fedora 38. I am not sure who to contact so I thought I would post here. |
Fedora 38 is missing for https://build.opensuse.org/project/show/devel:languages:nodejs which builds nodejs-electron. I've requested that it will be added. |
signal-desktop is in for Fedora 38. Thanks! |
For those who encountered this type of errors
I've resolved it with a complete reinstall. Make sure Signal uninstalled sudo dnf remove signal-desktop Remove the old key sudo rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} → %{summary}\n'
## e.g. resulted in
## gpg-pubkey-17280ddf-5e82f96b → network OBS Project <network@build.opensuse.org> public key
sudo rpm -e gpg-pubkey-17280ddf-5e82f96b Remove the OpenSuse Signal repository sudo dnf repolist
## network_im_signal Signal Messaging Devel Project (Fedora_38)
sudo rm /etc/yum.repos.d/network_im_signal.repo
sudo dnf clean all Re-import the OpenSuse Signal repository and its key sudo rpm --import https://download.opensuse.org/repositories/network:/im:/signal/Fedora_38/repodata/repomd.xml.key
sudo dnf config-manager --add-repo https://download.opensuse.org/repositories/network:/im:/signal/Fedora_38/network:im:signal.repo
sudo dnf update Re-install Signal sudo dnf install signal-desktop |
@cryptomilk when you get a second, it'd be nice to have Fedora 40 packages in https://build.opensuse.org/package/show/network:im:signal/signal-desktop :) let me know if there's anything I can do to help! |
@cryptomilk When you get a chance, it'd be nice to have Fedora 41 packages in https://build.opensuse.org/package/show/network:im:signal/signal-desktop I think it should be fine to stop supporting Fedora 39 at the end of this month. Feel free to let me know if there is anything I can do to help! |
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.
The text was updated successfully, but these errors were encountered: