aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
...
* fb_mqtt_write: fix unreachable input_add (priv->wev was always 0)dequis2015-11-19-2/+1
| | | | | | | | | | | | | This was the only line that assigned anything to priv->wev, and it was behind an (incorrect) condition that checked if it's nonzero. That would have replaced priv->wev if the condition was ever true, but since it wasn't, the only result is potentially delayed writes (for example, filling the write buffer and only writing the rest a minute later when pinging the server) The new condition also checks the return value of fb_mqtt_cb_write(), which is true if it should continue writing, or false otherwise.
* travis: Remove coverity_scan addon, call it manually for job 1 onlydequis2015-11-05-17/+8
| | | | | | | | See https://github.com/travis-ci/travis-ci/issues/1975 Since the addon doesn't handle the job matrix very well, I copied one of the suggestions from that thread, which does pretty much the same as the addon but in a place we can control.
* travis: added Coverity supportjgeboski2015-11-05-4/+25
|
* fb_channel_join: add a null check for the "room" channel settingdequis2015-11-01-0/+5
| | | | | | Control channels never have a room setting, so joining to &facebook and trying to fbjoin a channel would result in a null pointer dereference in the next line (FB_ID_TO_STR)
* Show self-messages when there's a compatible bitlbeedequis2015-09-20-3/+16
| | | | | | | | | | | | This feature is not yet in any stable bitlbee release, but it's designed to be backwards compatible: - Run time: Detects if the "self_messages" global setting exists. - Build time: sets OPT_SELFMESSAGE to 0 if it doesn't exist. In other words, if this is built against a bitlbee version that supports this feature, it will still run in anything 3.4+, and only display these messages in the newer ones.
* facebook-api: fix groupchat self messagesdequis2015-09-20-6/+6
| | | | By not swapping uid with oid, since the latter is always 0.
* travis: fixed warnings not being fataljgeboski2015-09-15-5/+7
|
* Handle any away status from bitlbee as 'invisible' for the serverdequis2015-09-15-0/+29
|
* facebook: implemented auto-joining for incoming group chat messagesjgeboski2015-09-13-17/+61
| | | | | | | | | This adds a setting, group_chat_open, which if set to true, will allow the plugin to open added channels upon an incoming message. This also addresses: - Improper message printing for root commands - The fbchats command not joining existing channels
* facebook-data: fixed segfault when clearing the thread listjgeboski2015-09-13-9/+4
| | | | | | | The thread list is not being properly freed, as elements are left in the internal list. This ends up causing double frees. This fixes more than one use of the fbchats command segfaulting.
* facebook: wait for the user added event after invitingjgeboski2015-09-13-1/+0
| | | | | | | Currently, as soon as a user is invited to a group chat, they are added to the group chat. In order to ensure the user is actually added, the plugin should wait for an already handled group chat event for the user being added.
* facebook: implemented group chat KICKingjgeboski2015-09-13-1/+17
|
* README: link to wiki for usage instructions, mention apt repodequis2015-09-11-29/+14
| | | | And fix s/--libdir/--with-plugindir/
* Change the default values of mark_read and show_unread to falsedequis2015-09-11-2/+2
|
* facebook: initialize the GLib type systemjgeboski2015-08-28-0/+4
|
* facebook-api: fixed deleted XMAs being fataljgeboski2015-08-26-3/+9
|
* facebook-api: fixed the contact query not fetching non-usersjgeboski2015-08-25-99/+63
|
* Implemented group chat topic change eventsjgeboski2015-08-25-10/+63
|
* facebook-api: fixed generic API operations always failingjgeboski2015-08-25-1/+5
|
* facebook-api: removed weird usage of g_slist_copy_deep()jgeboski2015-08-24-3/+8
|
* Imported changes from purple-facebookjgeboski2015-08-24-4772/+9339
|
* debian: fixed several lintian warnings/errorsjgeboski2015-07-24-5/+15
| | | | | | | This resolves: - extended-description-is-empty - missing-build-dependency-for-dh-addon - non-empty-dependency_libs-in-la-file
* configure: fixed AC_REQUIRE() usage outside the scope of AC_DEFUN()jgeboski2015-07-06-2/+1
|
* facebook-api: fixed JSON parse errors with messagesjgeboski2015-06-22-2/+9
| | | | | | | | It was assumed there was always a leading "NULL" byte prepended to each message. This is not the case, the NULL byte is actually a variable integer, which is the size for a Thrift string. In order to navigate directly the JSON data, just read the data as a thrift string in order to obtain the offset of the JSON data.
* facebook-thrift: fixed improper string sizesjgeboski2015-06-22-4/+15
| | | | | The thrift string functions were not correctly adjusting for compact and non-compact strings, it was just assumed as one or the other.
* * added alternate dependency for bitlbee-libpurple in debian control filezer0def2015-05-28-1/+1
|
* Markdownify readmedequis2015-05-27-42/+56
|
* Add debian crapdequis2015-04-29-0/+49
|
* libtool: fixed harmless m4 warningsjgeboski2015-04-03-3/+6
|
* configure: use recommended build-aux directoryjgeboski2015-04-03-2/+2
|
* Reset stoken when getting ERROR_QUEUE_NOT_FOUND, to create a new onedequis2015-04-03-1/+12
| | | | | | Simpler and more verbose version of my other patch which silently created a new queue - this will show up as a reconnection and should make it obvious if an infinite loop happens. jgeboski's idea, not mine.
* facebook-json: On parse error, show an escaped fragment of the inputdequis2015-03-15-1/+10
| | | | | Just for debugging purposes with users who don't run this with debug enabled.
* fb_api_cb_mqtt_publish: Show topic as part of the debug messagedequis2015-03-11-1/+1
|
* fb_mqtt_cb_read: change read size to be remz, hopefully fixing timeoutsdequis2015-03-11-1/+1
| | | | | | | | | | | | | | | | | | | | It was mqtt->rbuf->len previously, the length of the bytearray, which doesn't make a lot of sense - it resulted in reading 2, 4, 8, 16, 32 bytes and when it reached a high enough number, ssl_read would either: 1. Stop because the socket buffer got empty (the main reason it kinda worked most of the time), or 2. Continue reading into the next packet And continuing to read means not just a desync but also that remz - rize (remaining bytes - read bytes) is negative, or more precisely, a huge number, since remz is unsigned. So it gets stuck reading ~2**64 bytes into that buffer, thinking it's a neverending packet, and that means not getting pongs. So it timeouts. The fix is trivial - just make it read exactly the amount of bytes it needs to read (remz), never more than that.
* gitignore: ignore distribution tarballsjgeboski2015-03-05-0/+1
|
* Updated copyright dates for 2015jgeboski2015-03-05-16/+16
|
* Makefile: added autogen.sh to EXTRA_DISTjgeboski2015-03-05-1/+2
| | | | This adds the autogen.sh script to the distribution tarball.
* facebook-json: add fb_json_str_escape() to properly escape messagesdequis2015-03-01-1/+40
| | | | | | | | Fixes issues such as losing messages that include a quote character. Only escapes the minimum needed to work - control characters, backslashes and quotes. UTF-8 chars are still valid json, so they are sent as-is.
* facebook: default to chat_type of room for persistencejgeboski2015-01-31-4/+21
| | | | | | | | | | | As of now, group chat channels do not persist after they are left. This is due in part to the channel not being of chat_type room. Furthermore, the account and room identifiers are not set on the channel. This issue becomes apparent when the plugin disconnects from the remote services for whatever reason, and the channel is not setup again. This issue was introduced in 06956d1.
* Migrated from OPT to BEE_USER flagsjgeboski2015-01-30-1/+1
| | | | | The compatibility flags of BEE_USER provided by OPT flags should not be used as they are deprecated.
* Revert "Implemented message sending queue"jgeboski2015-01-30-45/+1
| | | | | | | | This reverts 68c46dd. While the sending queue attempted to ensure each message was sent in order, it also lead to a significant delay in the sending of messages. This is due in part to Facebook taking upwards of a minute or more to reply to a message being sent. Moreover, the queue is not really needed unless messages are being spammed.
* steam-util: fixed missing return values in compression functionsjgeboski2015-01-30-3/+3
|
* facebook-api: fixed invalid GSList usagejgeboski2015-01-30-7/+7
|
* travis: initial Travis CI supportjgeboski2015-01-30-0/+51
|
* Check format string security at compile-timejgeboski2015-01-27-10/+12
| | | | | This enables various format string security checks by the compiler in attempt to avoid run-time failures.
* groupchat names can begin with # (it is then discarded)Alexandre `Zopieux` Macabies2015-01-24-1/+4
|
* facebook: create group chats directly with the fbjoin commandjgeboski2015-01-24-16/+77
| | | | | | | | | Currently, the plugin relies on the 'chat add' root command in order to create a new group chat. Aside from being an ugly hack, this prevents the plugin from being able to automatically join the bitlbee user into the newly created channel. In order to allow for automatic joining, the plugin should directly create the group chat, rather than relying on the "chat add" root command.
* facebook: allow root commands without an account identifierjgeboski2015-01-24-25/+79
| | | | | | | | | | | | | | Currently, all roots commands require an account identifier in order to operate. However, more times than not, there will only be one Facebook account per bitlbee user. The plugin should allow for the short handing of root commands, where the account identifier is negated when there is only one active Facebook account. This patch allows for users with only one active Facebook account to negate the account identifier. The negation of the account identifier is optional. If there is more than one active Facebook account, the root commands behave as they currently do, and require an account identifier.
* facebook: ensure the account is online with root commandsjgeboski2015-01-24-0/+5
| | | | | | | | Currently, it is just assumed that the account is online, however, this is not always the case. If one of the root commands attempts to act on an offline account, it will typically lead to a segmentation fault. To guard against this, an additional check must be added to ensure the account is actually online.
* facebook-api: removed unused topic subscriptionsjgeboski2015-01-23-10/+9
| | | | | | | | | This removes certain topic subscriptions which are of no importance to this plugin. This results in the usage of slightly less bandwidth. This also forcibly unsubscribes from the message notifications topic, which seems to cause the connection to die out randomly when messages are sent.
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-26 19:22:59 +0000