Closed ppar closed 1 year ago
The missing recipients-store
issue is #202. It has been fixed in master
, but the releases had not been updated, till now. I have made a new release that catches up with it. Try using v0.7.2
, or just clone this repo with git
.
Testing "daemon" fails because DISPLAY is not set. This is a server machine, so no X11 or friends.
Scli listens to signal-cli's daemon's stdout, but sends commands to its dbus service (see also my reply in #207).
These were the choices available at the time scli has been written. Now that signal-cli offers JSON-RPC over stdin/out that would have been preferred, and would remove the dbus dependency.
X11 or a desktop environment is not required for scli, as long as the DBUS session is running. But dbus might fail to start if the $DISPLAY
variable is not set, as in #200 or AsamK/signal-cli#1070. There are several questions on stackoverflow etc about this (I have tried googling "dbus display not set"). One way around this seems to be: execute export DBUS_SESSION_BUS_ADDRESS=""
. DBus docs on this: https://dbus.freedesktop.org/doc/dbus-launch.1.html. Maybe also helpful: https://github.com/AsamK/signal-cli/wiki/DBus-service#macos-and-dbus-send.
Summary:
Using
scli
to link an existing account seems to work fine, but starting the client crashes because~/ .local/share/signal-cli/data/NNNNNN.d/recipients-store
is missing.Environment:
Steps to reproduce:
Link it - seems to work fine
Try to run it - crashes because something hasn't created that file
Files that were created under .local:
Tests as per README.md:
Testing "receive" - either shows nothing, or a bunch of sync messages confirming the account was linked successfully
Testing "daemon" fails because DISPLAY is not set. This is a server machine, so no X11 or friends. Is this test actually relevant for scli? AFAIK it executes signal-cli in a subprocess and I guess talks to it over stdout/stdin, does it need a dbus daemon running somewhere?