Package Details: signal 1.22.0-1

Git Clone URL: https://aur.archlinux.org/signal.git (read-only)
Package Base: signal
Description: Signal Private Messenger for the Desktop
Upstream URL: https://github.com/signalapp/Signal-Desktop
Keywords: messenger secure
Licenses: GPL3
Conflicts: signal-desktop, signal-desktop-beta, signal-desktop-bin
Provides: signal
Submitter: onny
Maintainer: dbirks (Jake)
Last Packager: dbirks
Votes: 188
Popularity: 16.342498
First Submitted: 2016-08-17 22:58
Last Updated: 2019-02-21 04:11

Pinned Comments

NicoHood commented on 2019-01-31 18:07

Guys! Just build in a chroot and you have no problems at all. It is a single line command to build: extra-x86_64-build

And LTS version of nodejs is still supported and updated, so it is absolutely fine to use it. It just has not that latest features available, but signal does not use them. That is an upstream decision, we have multiple packages depending on oder nodejs versions, thatswhy we have those in our repositories.

For everyone who does still have a problem with it, just use the bin package. Thats the reason why it is available.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Podrig commented on 2019-02-19 19:38

error signal-desktop@1.21.2: The engine "node" is incompatible with this module. Expected version "^10.13.0". Got "10.11.0"

dubnium is 10.11.0 whereas latest nodejs is 11.10.0

So even though this package depends on dubnium, it needs 10.13 or greater to build. And you're telling people to clean chroot in order to use the package? I've never seen a widely used AUR package be maintained this way before so it's a bit of a surprise.

Jake commented on 2019-02-07 14:04

@NicoHood: While i agree with the middle part of your pinned comment, the general opinion from the feedback is clearly that nvm was less annoying than the conflicting node packages. Chroot requires also additional work, especially it is not supported by most AUR package managers. This is fine for maintainers that build and test manually anyway, but not so much for people just using the software. So i am also leaning towards nvm in the meantime for the AUR, instead of just advocating the bin package now.

For the (community) repo it is of course different.
Why does this depend on signed releases from signal? If you want to build with the default commands is required to clone the repo anyway. Tarballs work only when omitting the gitinfo task, or patching the Gruntfile (https://github.com/signalapp/Signal-Desktop/issues/2376). Are you planning to go that route?

@baez: I still don't see any problems without git-lfs, could you explain for what exactly it is required?

baez commented on 2019-02-07 12:20

The package is missing a dependency to git-lfs. Would you mind to add it? Thanks a lot for providing this package!

NicoHood commented on 2019-02-06 14:33

@PieterDeBruijn Please see the pinned comment. Just built in a clean chroot.

@dbirks and jake: I pinned my comment, so people dont ask how to build over and over again. If you'd like to have another comment or nor comment pinned, please let me know.

I would also move this app to [community] if developers sign their releases. So If you want signal in the community repository from me, please upvote or comment the following issue: https://github.com/signalapp/Signal-Desktop/issues/1689

PieterDeBruijn commented on 2019-02-06 09:25

nodejs-lts-dubnium conflicts with nodejs, and I cannot remove nodejs. Hence I'm still on Signal v1.18. Any possibility of removing this dependancy on nodejs-lts-dubnium?

NicoHood commented on 2019-01-31 18:07

Guys! Just build in a chroot and you have no problems at all. It is a single line command to build: extra-x86_64-build

And LTS version of nodejs is still supported and updated, so it is absolutely fine to use it. It just has not that latest features available, but signal does not use them. That is an upstream decision, we have multiple packages depending on oder nodejs versions, thatswhy we have those in our repositories.

For everyone who does still have a problem with it, just use the bin package. Thats the reason why it is available.

Pryka commented on 2019-01-30 12:43

@Jake

I respect the work that you are doing with this package, but I must agree with the others. NVM is the way. Honestly, I did have an issue with it some time ago but it was quite easy to fix.

This whole jumping back and forth from nodejs to nodejs-lts-dubnium it's too much of a hassle for me.

petervaro commented on 2019-01-30 09:12

@Jake I can only agree with everyone who commented before me on how frustrating and "un-arch-y" the choice of nodejs-lts-dubnium here. I've been using this package since it appeared on AUR and I never had any problem with npm before (except the fact that it is slow as hell, but that's not the issue of the mainstream package but the nature of a JS package manager I guess).

Anyway, all I'm trying to say here is that the arch way is to be up to date, yes, everything, all the time! And as je-vv put it: if you could easily make this package working with the latest versions (which are in the official repos) then it is a no-brainer to do so.

I care about this package (and quite frankly I depend on it) as I believe the AUR packages should be installed from source not prebuilt (for security reasons mostly). So is there any chance that you would update the dependencies to their latest versions?

je-vv commented on 2019-01-27 00:11

@Jake, as you asked, to me it's important that the packages attempt to use latest system SW, and only as a work around build or running issues, use old SW. Depending on electron2 for example, when it's possible to use latest electron, doesn't make much sense to me. Same applies to nodejs, as it's possible to use nodejs, I see no reason to stick with a LTS old version of nodejs. AFAIK, using nvm is working fine. When updating a batch of packages from AUR, it's pretty possible that one forgets about replacing any makedepend package, and not always chroot is something one is willing to do.

That said, @Jake and all maintainers, it's always up to you. Just wanted to express my preference since it was asked if the current thing about nodejs was annoying. I really appreciate the effort maintainers do.

matthias.lisin commented on 2019-01-26 23:20

Hello dbirks, hello jake, have you tried making the application use the system hunspell dictionaries?

That way you could drop the following content:

/usr/lib/signal/resources/app.asar.unpacked/
/usr/lib/signal/resources/app.asar.unpacked/node_modules/
/usr/lib/signal/resources/app.asar.unpacked/node_modules/spellchecker/
/usr/lib/signal/resources/app.asar.unpacked/node_modules/spellchecker/vendor/
/usr/lib/signal/resources/app.asar.unpacked/node_modules/spellchecker/vendor/hunspell_dictionaries/
/usr/lib/signal/resources/app.asar.unpacked/node_modules/spellchecker/vendor/hunspell_dictionaries/README.txt
/usr/lib/signal/resources/app.asar.unpacked/node_modules/spellchecker/vendor/hunspell_dictionaries/en_US.aff
/usr/lib/signal/resources/app.asar.unpacked/node_modules/spellchecker/vendor/hunspell_dictionaries/en_US.dic

and most likely /usr/lib/signal/resources/electron.asar can be skipped too.