- 21 Mar, 2019 2 commits
-
-
Richard Bayerle authored
-
Richard Bayerle authored
-
- 30 Dec, 2018 3 commits
-
-
Richard Bayerle authored
-
Richard Bayerle authored
Version to use in directory and file name can be specified in env This fixes #94
-
Richard Bayerle authored
-
- 24 Dec, 2018 1 commit
-
-
Richard Bayerle authored
This fixes #107.
-
- 09 Dec, 2018 2 commits
-
-
Richard Bayerle authored
-
Richard Bayerle authored
This fixes #127.
-
- 13 Nov, 2018 1 commit
-
-
Richard Bayerle authored
-
- 11 Nov, 2018 1 commit
-
-
Richard Bayerle authored
-
- 10 Nov, 2018 1 commit
-
-
Richard Bayerle authored
This fixes #113.
-
- 23 Oct, 2018 4 commits
-
-
Richard Bayerle authored
-
Richard Bayerle authored
-
Richard Bayerle authored
-
Richard Bayerle authored
-
- 20 Oct, 2018 1 commit
-
-
Richard Bayerle authored
-
- 02 Oct, 2018 1 commit
-
-
Alexander Tsoy authored
-
- 06 Jul, 2018 1 commit
-
-
Lunar authored
If build-essential isn't installed on the system it complains about "No CMAKE_CXX_COMPILER could be found"
-
- 06 Jun, 2018 1 commit
-
-
Richard Bayerle authored
So far turning logging from axc on works. Log level still ignored.
-
- 04 Jun, 2018 1 commit
-
-
defanor authored
Rebuilding used to happen when it shouldn't, for instance on `make install` after `make`. The "Types of Prerequisites" section of GNU make manual describes this situation.
-
- 13 May, 2018 1 commit
-
-
Richard Bayerle authored
The fix in the last commit uncovered that such messages do not always have a "to" attribute (at least they do not with Prosody). "Uncovered" means this was completely broken. Additionally, lurch now ignores a decryption failure under specific circumstances: If both sender and recipient are the own account, and the error code is libsignal's "duplicate message", a warning is written to the debug log and the message itself ignored, as it was probably a carbon-copy.
-
- 09 May, 2018 1 commit
-
-
Daniel Hornung authored
Should be fully backwards compatible, future further cleanup is possible, but not mandatory.
-
- 05 May, 2018 3 commits
-
-
Steffen Sledz authored
Like Redhat SuSE uses libxmpp instead of libjabber. Fixes issue #98 Signed-off-by:Steffen Sledz <sledz@dresearch-fe.de>
-
Richard Bayerle authored
Previously, the message was written to the sender's conversation. In this case this is always the own account, which was probably handled intelligently by libpurple in many, but not all, cases. Might help with #52.
-
Richard Bayerle authored
-
- 21 Apr, 2018 3 commits
-
-
Richard Bayerle authored
And update README.
-
Richard Bayerle authored
This closes #40.
-
Richard Bayerle authored
I think sending encrypted messages was leaking memory this whole time...
-
- 20 Apr, 2018 1 commit
-
-
Richard Bayerle authored
Found that the data I need is not in PurpleConv, but in JabberConv. Replaced that and removed my own hashtables and presence parsing.
-
- 17 Apr, 2018 3 commits
-
-
Richard Bayerle authored
-
Richard Bayerle authored
Added missing newline at the end of the log message template. Disabled because it's way too noisy.
-
Richard Bayerle authored
-
- 15 Apr, 2018 8 commits
-
-
Richard Bayerle authored
Usually, these are messages sent from a different device. This fixes #63.
-
Richard Bayerle authored
XMPP type "chat" is libpurple type "IM", not "CHAT". Not sure how this ever worked.
-
Richard Bayerle authored
-
Richard Bayerle authored
-
Arthur Lutz authored
-
Richard Bayerle authored
This can happen if there is an additional <body> element, since the messages are then saved and replayed on entering as chat history. Should help with #65. As the message is then completely ignored by this plugin, This also means that the text in the <body> will be displayed to the user.
-
Richard Bayerle authored
-
Richard Bayerle authored
-