Usability from inside bitlbee: public channels

[TC01]

I recently tried to set up this plugin from inside bitlbee. After poking at it a bit, I was able to get it to connect to a mattermost server. However, while private contacts (i.e. "direct messages" or the equivalent of an IRC /query) seem to have been automatically loaded properly, I can't see any of the public channels that I'm in on the mattermost server.

I'm curious if this is a known problem, and if anyone else has successfully gotten this plugin working from inside bitlbee? When I attempted to connect from inside pidgin, I did automatically get a listing of the public channels I'm in (in addition to the private contacts), so I'm assuming this is just a problem integrating with bitlbee.

Thanks in advance.

[EionRobb]

Have you tired using help chat list to use the room list api and find the rooms you can connect to?

[TC01]

I had not! However... now that I have, I find that bitlbee segfaults when I do ("chat list eionrobb-mattermost"), with the following error message printed to syslog:

bitlbee[32282]: g_utf8_strlen: assertion 'p != NULL || max == 0' failed
audit[32282]: ANOM_ABEND auid=4294967295 uid=987 gid=980 ses=4294967295 subj=system_u:system_r:bitlbee_t:s0 pid=32282 comm="bitlbee" exe="/usr/sbin/bitlbee" sig=11 res=1
bitlbee[32282]: g_utf8_strlen: assertion 'p != NULL || max == 0' failed

This is with bitlbee 3.5.1, libpurple 2.12.0 and the latest purple-mattermost from git.

[EionRobb]

Can you get a backtrace? https://wiki.bitlbee.org/DebuggingCrashes

[TC01]

Sure, here's the trace:

(process:32752): GLib-CRITICAL **: g_utf8_strlen: assertion 'p != NULL || max == 0' failed

(process:32752): GLib-CRITICAL **: g_utf8_strlen: assertion 'p != NULL || max == 0' failed

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106             movdqu  (%rax), %xmm4
#0  0x00007ffff606bf86 in strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x0000000100030dec in str_pad_and_truncate (string=0x0, char_len=char_len@entry=79, ellipsis=ellipsis@entry=0x100069f1c "[...]") at misc.c:802
#2  0x0000000100028c2a in cmd_chat_list_finish (ic=ic@entry=0x100332dc0) at root_commands.c:1442
#3  0x0000000100036eb5 in imcb_chat_list_finish (ic=ic@entry=0x100332dc0) at bee_chat.c:279
#4  0x000000010003af1d in prplcb_roomlist_in_progress (list=0x10050c950, in_progress=<optimized out>) at purple.c:1590
#5  0x00007fffe6916df2 in mm_roomlist_got_list (ma=0x10033fb40, node=<optimized out>, user_data=0x1005164d0) at libmattermost.c:2778
#6  0x00007fffe69182c7 in mm_response_callback (http_conn=<optimized out>, user_data=0x1003409d0, url_text=<optimized out>, len=<optimized out>, error_message=0x0) at libmattermost.c:929
#7  0x00007ffff666ee10 in url_fetch_recv_cb (url_data=0x100346a70, source=<optimized out>, cond=<optimized out>) at util.c:4002
#8  0x000000010002c165 in gaim_io_invoke (source=<optimized out>, condition=<optimized out>, data=0x100504970) at events_glib.c:86
#9  0x00007ffff7600e52 in g_main_dispatch (context=0x1002b6fd0) at gmain.c:3203
#10 0x00007ffff7600e52 in g_main_context_dispatch (context=context@entry=0x1002b6fd0) at gmain.c:3856
#11 0x00007ffff76011d0 in g_main_context_iterate (context=0x1002b6fd0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3929
#12 0x00007ffff76014f2 in g_main_loop_run (loop=0x100299800) at gmain.c:4125
#13 0x0000000100016406 in main (argc=<optimized out>, argv=0x7fffffffe458) at unix.c:182

It looks like some sort of string processing problem; I can see from the log it occurs after fetching the list of channels from the server. Is it possible that a channel with empty "purpose" or "header" could be causing some kind of issue?

[AcouBass]

My backtrace seems to be far less useful than his -

(process:1499): GLib-CRITICAL **: g_utf8_strlen: assertion 'p != NULL || max == 0' failed

(process:1499): GLib-CRITICAL **: g_utf8_strlen: assertion 'p != NULL || max == 0' failed

Program received signal SIGSEGV, Segmentation fault.
0x769cb324 in strlen () from /usr/lib/libc.so.6
#0  0x769cb324 in strlen () at /usr/lib/libc.so.6
#1  0x00427f8c in str_pad_and_truncate ()
#2  0x0041f868 in cmd_chat_list_finish ()
#3  0x00432418 in  ()  

I managed to get my group chats working by editing the bitlbee accountname.xml file manually and adding the line:

<setting name="auto_join">true</setting>

and also doing running the standard command to create a new groupchat in &bitlbee, with the room name written as roomname---teamname. I then snagged the purple team ID from the Pidgin configuration (~/.purple/blist.xml) and manually added it to the bitlbee accountname.xml with the line:

<setting name="purple_team_id">stringofnumbersandletters</setting>

Restarting Bitlbee after doing all this gave me all the rooms with my Mattermost team, and it all seems to work, however my server buffer does get spammed with this quite often:

‎[01:12] ‎[(process:1624):]‎ GLib-CRITICAL **: g_strstr_len: assertion 'haystack != NULL' failed

[arichiardi]

@TC01 sorry to hijack this, but how did you login? I get a bunch of:

11:11 <root> eionrobb-mattermost - Logging in: Reconnecting in 5 seconds..
11:11 <root> eionrobb-mattermost - Login error: No server supplied (use
             username|server)

[robert-scheck]

@arichiardi, after reading the source code, account eionrobb-mattermost set username <username>|<servername> at least got me over this.

[The-Compiler]

FWIW you can get the name and ID via title -> "view info" in mattermost, and then do this after adding a channel:

channel #name set purple_id ...
channel #name set purple_name ...

[TC01]

Hey, just thought I'd follow up here. I thought I'd check out the latest version of the plugin and see if it works well with bitlbee now.

And it does! I'm actually able to join public channels (using the chat list and chat add commands). It seems to be working quite well.

For future reference for anyone looking at this, to get the plugin working from inside bitlbee one needs to:

acc add eionrobb-mattermost username|mattermost_server_url
acc eionrobb-mattermost set password [...]

# If using MMAUTHTOKEN as password.
acc eionrobb-mattermost set use-mmauthtoken true

From a bitlbee perspective, it might be nice if the plugin identified its protocol as "mattermost" instead of just "eionrobb-mattermost", as I'm pretty sure there aren't any other working mattermost implementations out there. But I think I'm going to go ahead and close this, as my main question ("can this work with bitlbee") now seems to be answered with "yes". :)

[aitzkora]

It was a little bit difficult to configure an account, thanks to your remarks i managed...The party about the token is hiddent in the windows install . To sum up acc add eionrobb-mattermost your_username| your_server #beware, no space around the | acc 0 set use-mmauthtoken true acc 0 set password your_gitlab_token # your can retrieve it following... GitLab cookie (MMAUTHTOKEN) authentication workaround:

Login to your mattermost server with your browser. Obtain the value of MMAUTHTOKEN cookie for your mattermost server. (on your Mattermost web page: right-click -> Inspect Element, under "Storage" open cookies and copy MMAUTHTOKEN content. It should look like "ewmxxxuxatndbjergsssizngry" ) Copy it to Password: field. In Advanced account setup tab check Password is Gitlab cookie. Note: MMAUTHTOKEN cookie expires after a server defined time: above procedure needs to be repeated each time it happens.