FHEM - Hausautomations-Systeme > Unterstützende Dienste

Neues Modul: Signalbot (Integration für den Signal Messenger) via signal-cli

<< < (96/120) > >>

Adimarantis:
Update signal-cli 0.9.2

Nachdem ich festgestellt habe, dass die nächste signal-cli Version auch von Java 11 auf Java 17 updaten wird, habe ich mich dazu entschlossen jetzt signal-cli 0.9.2 als vorerst letzte signal-cli version freizugeben. Heisst leider auch dass es wohl erstmal keinen Fix für das weiter oben beschriebene Captcha Problem geben wird.
Wer updaten will holt mit "reinit" das neueste Script nach www/signal und führt es mit

--- Code: ---sudo ./signal_install.sh
--- Ende Code ---
aus.
Sofern eine Warnung "[....] is an unsupported combination - signal-cli binary libraries might not work" kommt, sollte die Installation abgebrochen werden.
Es gibt aktuell aber keinen zwingenden Grund für das Update - V0.9.0 kann getrost weiter verwendet werden.

Hintergrund zu der Java Version:
In Debian bzw. Raspian "Buster" ist nur openJDK11 verfügbar. Es gibt zwar Java17, aber derzeit nicht offiziell über "apt install".
Java17 ist erst mit Debian "Bullseye" (11.x) offiziell verfügbar. Inzwischen ist zwar auch das entsprechende Raspberry OS basierend auf "Bullseye" verfügbar, es wird aber geraten eine Neuinstallation zu machen - und wer macht das mit einem Heimautomatisierungssystem, wenn sonst alles läuft.

Mittelfristig werde ich mir anschauen, ob neue signal-cli Versionen interessant genug sind, um den Aufwand zu betreiben, den Installer um eine "private" Java Version zu ergänzen bzw. "Bullseye" zu unterstützen. Ihr seht aber schon - die Platformabhängigkeiten werden immer komplexer.

@Jamo: Ich denke ich habe den richtigen Branch dafür gefunden um die Debian 10 libs zu übersetzen, hab diese aber nicht getestet. Wäre schön wenn du das überprüfen könntest.

Jörg

Gisbert:
Hallo Jörg,

ich hab den update-Prozess durchlaufen, ist auch ordentlich durchgelaufen, bekomme aber diese Info im Device:

--- Code: ---VERSION Signalbot:3.1 signal-cli:0.9.0 Protocol::DBus:0.19
--- Ende Code ---
Das Modul habe ich auch noch per reload erneuert.

Viele​ Grüße​ Gisbert​

Gisbert:
Ein nicht beabsichtigter Fhem-Neustart hat dazu geführt, dass jetzt die richtige Signal-Version angezeigt wird.

vaulie:
Hi,
ich hatte gestern versucht, erstmalig Signal zu installieren. Das hat leider nicht geklappt...
Vor einigen Monaten war ich schonmal an einem völlig veralteten Betriebssystem gescheitert, weswegen ich dann mein Raspberry mal komplett neu aufgesetzt habe und nun "Linux raspi3 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l" läuft.
Außer fhem und Samba habe ich auch nichts besonderes noch installiert.
Dann habe ich mich an den Wiki-Beitrag und das install-script gehalten. Als erstes fiel mir dann "armhf-glibc2.31-0.9.0 is an unsupported combination" auf, habe aber weiter gemacht, weil ich dachte, ich habe doch die neuesten Pakete.
Nunja, bei start signal-cli service blieb er dann (wie erwarten?) hängen:

--- Code: ---Start signal-cli service
Job for signal.service failed because the control process exited with error code.
See "systemctl status signal.service" and "journalctl -xe" for details.
Checking installation via dbus-send command...Error org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
unexpected reply
Sending a message via perl Protocol::DBus...Error getting reply.

OpenJDK Server VM warning: You have loaded library /tmp/resource3715067888090005771.so which might have disabled stack guard. The VM wi>
Dez 04 22:37:53 raspi3 signal-cli[2232]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.

--- Ende Code ---
Damit bin ich wohl beim "Standard-Fehler" auf Raspberrys wie im zweiten Eintrag der FAQ beschrieben. Das Löschen von /opt/signal hat aber nichts gebracht. Der erste der "weiteren Tests" zeigt dann auch tatsächlich Treffer:

--- Code: ---sudo ldconfig -v | grep libzkgroup.so
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib« mehrfach angegeben
ldconfig: /lib/arm-linux-gnueabihf/ld-2.31.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring

--- Ende Code ---

Ich bin in Linux nicht so zu Hause, dass ich dieses Ergebnis nun selbst beheben könnte.
Daher nun meine Fragen,
* bin ich nach dem "unsupported combination" überhaupt noch richtig davor? Wie könnte ich eine supported combination hinkriegen?
* wie kann ich die mehrfach angegebenen Pfade beheben?
* im Wiki war es für mich nicht klar, ob ich vor oder nach dem Skript, den Signalbot in fhem definieren muss.. Wann muss das geschehen?

Danke für Hinweise,
Gruß Volker

Adimarantis:
Hi Volker,

Du bist dann schon auf "bullseye".
Dafür habe ich mangels eigenem System, leider die nativen Libs noch nicht übersetzt.
Diese hängen von der verwendeten glibc Version ab und die muss exakt stimmen, sonst gibt es beim Start einen Fehler.
Ich hab vor mein Testsystem demnächst auf bullseye zu ziehen, dann kann ich das machen.
Oder magst du dich dran probieren?

Jörg

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln