Flyspray:: Flyspray:: Irssi core bugs: Recently opened tasks 2014-04-10T01:22:19Z FS#915: Wildcards in the nick inconsistent between commands 2014-04-10T01:22:19Z 2014-04-10T01:22:19Z
Description of the problem:

Hi, some commands that allow usage of wildcards in the nick includes issuing user in the resulting list but others do not. This doesn't seems to be documented.

Some commands that doesn't include "me": /op /deop /voice
And an example of command that includes "me": /who

How to reproduce:
1. Setup dancer-ircd, configure O:line password with +p "god privileges" (maybe some more like +* and +B)
2. Join channel with couple of users
3. Deop channel operator
4. Gain +p usering /oper with one of users
5. Issue /op -YES *
6. Issue /who *

Expected results:
All users in the channel are granted channel operator privileges including the issuing user;

Actual results:
Issuing user is not granted channel operator privileges but other users do.

Additional info:
I'm aware that this is a corner case, but anyway this should be consistent or at least documented.


Lukas Novy
FS#914: Patch attached: allow themes to reside in ~/.irssi/themes/ 2014-04-07T14:53:27Z 2014-04-07T14:53:27Z
Hi, I've created a patch to allow theme files to be in ~/.irssi/themes/, so users with a lot of .theme files don't get cluttered up with them in the .irssi directory.

src/fe-common/core/themes.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/src/fe-common/core/themes.c b/src/fe-common/core/themes.c
index 7c50c28..c1fb63b 100644
--- a/src/fe-common/core/themes.c
+++ b/src/fe-common/core/themes.c
@@ -833,17 +833,21 @@ THEME_REC *theme_load(const char *setname)

theme = theme_find(name);

- /* check home dir */
- fname = g_strdup_printf("%s/%s.theme", get_irssi_dir(), name);
+ /* check .irssi/themes/ */
+ fname = g_strdup_printf("%s/themes/%s.theme", get_irssi_dir(), name);
if (stat(fname, &statbuf) != 0) {
- /* check global config dir */
- fname = g_strdup_printf(THEMESDIR"/%s.theme", name);
+ /* check .irssi/ */
+ fname = g_strdup_printf("%s/%s.theme", get_irssi_dir(), name);
if (stat(fname, &statbuf) != 0) {
- /* theme not found */
- g_free(name);
- return theme; /* use the one in memory if possible */
+ /* check global themes directory */
+ fname = g_strdup_printf(THEMESDIR"/%s.theme", name);
+ if (stat(fname, &statbuf) != 0) {
+ g_free(fname);
+ g_free(name);
+ return theme; /* use the one in memory if possible */
+ }



Armin Jenewein
FS#913: /help log doesn't mention autolog 2014-03-21T12:41:50Z 2014-03-21T12:41:50Z
When I was trying to find out how to turn on logging in irssi I tried /help log but the functionality that I was after was auto-logging. I found it quite difficult to find a reference to this setting on the internet when searching for irssi logging yet when people think of IRC logs this is the setting they are after.

My request is that a reference to autolog or /help autolog be included (perhaps as an appendix) so that other users can find the autolog setting when they're searching for it.
Inspector Spacetime
FS#912: Mailing-list archive links broken 2014-02-07T21:42:57Z 2014-02-07T21:42:57Z
At is a link to the archives for irssi-users but it returns 404 "The requested URL /lists/irssi-users was not found on this server." Likewise for irssi-dev
Daniel Macks
FS#911: hilight-text improperly restores previous color 2014-01-31T08:10:46Z 2014-01-31T08:10:46Z
The hilight algorithm inserts color control codes to turn the desired text into the hilight color. Unfortunately, in retrieving what it thinks is the previous color control code, it ignores several codes (such as ^o (15) which resets colors). Thus, when in the presence of another script or a specially-formatted message (eg. from a bot that reports commits to a repo, giving different colors for username, branch, message, etc), it restores the previously used color.


^c5color^o plain Zannick should be plain
^c5color^o plain ^c8Zannick^c5 should be plain
where "should be plain" is colored red

Examples (where a script colors other users' nicks and irssi hilights mine):,0SN8TuO

A simplistic way to fix this for ^o would be to expand the else case in strip_real_length (which is where irssi finds the last color control code) to something like

if (IS_COLOR_CODE(*str)) {
*last_color_pos = (int)(str-start);
*last_color_len = 1;
} else {
[previous stuff...]

though this will still be wrong in the general case, since some of the control characters (eg. ^b ^f ^g ^v ^7) are toggles (and they do not remove the color from the hilight, either).

I'd suggest something more complicated where the toggles are tracked, and then hilight-text adds a ^o followed by the appropriate control characters:
^bbold Zannick still bold -> ^bbold ^c8Zannick^o^b still bold
FS#910: Please fIx compilation with -Werror=format-security 2014-01-10T20:31:34Z 2013-12-06T10:12:23Z
This can be good for users using GCC with hardened CFLAGS and also it is good practice of "defensive coding". For more details see Fedora bug:
Jaroslav Škarvada
FS#909: color code with no values followed by comma works appears incorrectly 2013-12-03T23:40:43Z 2013-12-03T23:40:43Z

When the above line is received by irssi, it displays the word testing white BG with black FG. The ",test" string following is displayed as black on black.

This seems incorrect as I would expect the string ",test" to appear in the normal formatting again.

It appears that the comma following the color code is what is throwing it off and not causing it to reset the text. If I remove the comma, it displays as expected.
Richard P.
FS#908: [PATCH] support SRV records 2013-11-27T07:27:53Z 2013-11-27T07:27:53Z specifies SRV records, which (in the case of IRC) look like _irc._tcp.domain, e.g. An SRV record specifies a priority, a weight, a hostname and a port (!), e.g.:

host -t SRV has SRV record 0 0 6667 has SRV record 0 0 6667

This is really handy if you want to run IRC on non-standard ports or just don’t want to bother with configuring SSL ports, which often differ from IRC network to IRC network. Furthermore, it clearly defines an order (by priorities), whereas just pointing one DNS record to multiple IP addresses is round-robin.

The attached patch is a work-in-progress which makes irssi use glib’s asynchronous DNS resolver to first resolve an SRV record, and fall back to normal DNS resolution if that is not possible.

I will continue working on this patch, but I’d like some things clarified first please:

1) Will you merge that patch at all, i.e. are you okay with irssi SRV-resolving?
2) Can we ignore the resolve_prefer_ipv6 setting? Then we could use GSocketConnectable and simplify the code even further.
3) Are there any big style guide violations, architectural problems or other problems with my current patch?

Michael Stapelberg
FS#907: Flyspray SQL error when using UTF-8 real name 2013-11-14T01:27:37Z 2013-11-14T01:27:37Z
Here's what I got when trying to register as "Marcin Cieślak" (not "Cieslak"):

Query {INSERT INTO `flyspray_registrations` ( reg_time, confirm_code, user_name, real_name, email_address, jabber_id, notify_type, magic_url, time_zone ) VALUES ( ?,?,?,?,?,?,?,?,? )} with params {1384391728,1303b7f7e517c89da9d0,saper,Marcin Cieślak,,,2,4b43221e953206fb6cc5c4a6888c8dc4,0} Failed! (Incorrect string value: '\xC5\x9Blak' for column 'real_name' at row 1)

most probably a configuration issue (make MySQL use utf8) or a bug in Flyspray.
Marcin Cieslak
FS#906: channels_list mangled, resulting in crash in xep/muc-reconnect.c 2013-11-14T01:24:22Z 2013-11-14T01:24:22Z
I am idling on MUC channel (it's public) and from time to time (like once per two weeks) irssi crashes with SIGSEGV:

#0 0x0000000803c13071 in sig_conn_copy (dest=0x7fffffffe570, src=0x814a35100)
at xep/muc-reconnect.c:39
#1 0x00000000004a2112 in signal_emit_real (rec=0x803ac4160, params=2, va=0x7fffffffe460,
first_hook=0x803b89160) at signals.c:242
#2 0x00000000004a2385 in signal_emit (signal=0x4cc51d "server connect copy", params=2)
at signals.c:286
#3 0x000000000049c5d6 in server_connect_copy_skeleton (src=0x814a35100, connect_info=0)
at servers-reconnect.c:154
#4 0x000000000049c9ca in sig_reconnect (server=0x813147580) at servers-reconnect.c:225
#5 0x00000000004a2112 in signal_emit_real (rec=0x803ab5240, params=2, va=0x7fffffffe6d0,
first_hook=0x803ab4d60) at signals.c:242
#6 0x00000000004a2385 in signal_emit (signal=0x4cc08f "server connect failed", params=2)
at signals.c:286
#7 0x000000000049a664 in server_connect_failed (server=0x813147580, msg=0x0) at servers.c:47
#8 0x000000000049b769 in server_disconnect (server=0x813147580) at servers.c:482
#9 0x0000000803c0a0ae in check_connection_timeout (server=0x813147580) at xmpp-servers.c:444
#10 0x0000000800e15ca7 in g_source_get_time () from /usr/local/lib/
#11 0x0000000800e15372 in g_main_context_dispatch () from /usr/local/lib/
#12 0x0000000800e18cee in g_main_context_prepare () from /usr/local/lib/
#13 0x0000000800e192d2 in g_main_context_iteration () from /usr/local/lib/
#14 0x000000000042e89d in main (argc=1, argv=0x7fffffffe9f0) at irssi.c:356
#0 0x0000000803c13071 in sig_conn_copy (dest=0x7fffffffe570, src=0x814a35100)
at xep/muc-reconnect.c:39
39 conn->channels_list = g_slist_append(conn->channels_list,
35 return;
36 conn = (XMPP_SERVER_CONNECT_REC *)*dest;
37 conn->channels_list = NULL;
38 for (tmp = src->channels_list; tmp != NULL; tmp = tmp->next) {
39 conn->channels_list = g_slist_append(conn->channels_list,
40 g_strdup(tmp->data));
41 }
42 }
$1 = (GSList *) 0x812bb3760
$2 = {data = 0x814af8a40, next = 0x0}
$3 = (GSList *) 0x53440aaf
Cannot access memory at address 0x53440aaf
$4 = (GSList *) 0x80b7bed90
$5 = {data = 0x80b7a56b0, next = 0x53440aaf}
$6 = (GSList *) 0x53440aaf

I have no idea why src->channels_list is corrupted.
Marcin Cieslak