Flyspray:: Flyspray:: Irssi core bugs: Recently opened tasks http://bugs.irssi.org/ 2014-06-30T11:17:34Z FS#922: Please close bugs.irssi.org add new task 2014-06-30T11:17:34Z 2014-06-30T06:46:00Z
Please close bugs.irssi.org "Add new task" feature as soon as possible, thank you as issues should be added to Github instead. All open issues should be either closed or migrated to Github and after that whole bugs.irssi.org can be used as HTTP forward or similar.
Henri Salo http://bugs.irssi.org/:922
FS#921: Right aligned statusbars do not redraw properly. 2014-05-28T18:12:35Z 2014-05-28T18:12:35Z
I have checked my terminal settings, used screen and xterm, Debian Jessie and RHEL 6.5, started irssi without configuration and without scripts, using the default.theme, and I am able to reproduce following these steps:

0. Assuming stock, no user configuration file, default.theme
1. /statusbar topic add -alignment right topic
2. /j #channel1 ... /topic some topic
3. /j #channel2 ... /topic completely different text
4. Switch between channels 1 and 2, and see the topic get munged and not redrawn properly.

Also affects other statusbars, originally noticed when chanact was not redrawing properly, after switching to channels with activity, and not having it redraw properly.
Christopher P. Bills http://bugs.irssi.org/:921
FS#920: enable /lastlog when connected via irssiproxy module 2014-05-23T20:30:21Z 2014-05-23T20:30:21Z
It would be nice if a client connected via irssiproxy could see the scrollback using /lastlog.

Cheers
Edd http://bugs.irssi.org/:920
FS#919: usermode is never NULL 2014-05-20T05:58:00Z 2014-05-20T05:58:00Z
irssi sends `MODE %s %s` to server even if `usermode = "";` in config.
This could lead to nickname or activity exposure if irssi used behind bouncer.

quickfix attached
zeebaasheDi9 http://bugs.irssi.org/:919
FS#918: Process still hangs after exiting Irssi (in cygterm). 2014-05-09T21:29:35Z 2014-05-09T21:29:35Z
When using Irssi in Cygterm, it will not close the process and it will remain connected to the IRC server after you close the application.

This happens in Windows 8.1 and I can duplicate the issue at hand. I was connected simultaneously to the same network until it blocked me from access, to discover I had over 5 processes running.

The attached image will show two Irssi.exe processes running but not a single Irssi window open in the taskbar.

This should not happen.
Jean-Luc Tallis http://bugs.irssi.org/:918
FS#917: Revert bug 316 - default tab completion should NOT stop signal 2014-05-05T10:15:31Z 2014-05-05T10:15:31Z
I'm writing a script which puts @ in front of nicks when completing them in a twitter channel on bitlbee.

In bug #316 there was a request to make default tab completions in the irssi source stop the 'complete word' signal. This was because the author was printing out debug output, and was surprised when they caught a signal with data filled in by previous functions.

I would consider this a feature, not a bug. I tried using this signal today, having looked at it in signals.txt, and considering the design where an arrayref is passed into the function for you to populate it, I was surprised that it was not coming through populated by the earlier functions that caught this signal - and in fact the signal was being stopped. It didn't seem consistent with the irssi signal design generally.

I think the behaviour introduced in  bug 316  isn't useful behaviour because:
- Other scripts that catch the signal first might not stop the signal, so you shouldn't write scripts with the idea that "if I catch this signal then it's because nothing else matched" just because the default completion behaves this way. I have at least one other script (tag.pl) which catches this signal early and doesn't stop it so that it goes through to default completions (it actually signal_continues)
- If you want to determine if anything has matched before you, there is a very simple way to do this - check the length of @$complist (the first argument to the signal function). There's no need to have the signal stopped to make it possible to do what the original bug filer wanted
- Not stopping the signal gives the ability to do several useful things, e.g. add additional completions to the list, filter out unwanted completions, and manipulate existing ones; without having to reimplement the entire default logic in your perl script.

I've searched online for existing scripts that use this signal and might break on this change:
- On scripts.irssi.org there is aspell_complete.pl which is dated from before  bug 316  and would change behaviour (back to what it was when the author first wrote it) so that if you tab complete e.g. something that matches someone's partial nickname, it will go through the nickname matches first, and then through the aspell suggestion(s). I believe this is better behaviour than currently and likely what the author intended originally
- There are a very few scripts which I've found on google but afaict they wouldn't be affected by this change
- There is a script by the person who submitted  bug 316 , only reference I can find of it is on a pastebin several years ago. It actually wouldn't particularly be affected by this bug as far as I can tell. Also I can find no newer versions of this script online or outside this one pastebin, and the version there has a few bugs ( return if $word !~ /([\@\?]).*/; should be return if $word !~ /^([\@\?])/; )
ferret http://bugs.irssi.org/:917
FS#916: Crash somewhere inside libcrypto 2014-04-23T06:30:22Z 2014-04-23T06:30:22Z
Hello!

Recently, irssi have been crashing randomly for me. I run irssi 24/7 through dtach (stripped down version of GNU screen), and I get about 1 crash per several weeks.

irssi 0.8.15 (20100403 1617)
OpenSSL 1.0.1e-freebsd 11 Feb 2013

I've obtained core dump this time. Here is the stack trace:

#0 0x00000008023d60e4 in ERR_pop_to_mark () from /lib/libcrypto.so.7
#1 0x00000008023cacdd in lh_retrieve () from /lib/libcrypto.so.7
#2 0x00000008023d59f6 in ERR_pop_to_mark () from /lib/libcrypto.so.7
#3 0x00000008023d5120 in ERR_reason_error_string () from /lib/libcrypto.so.7
#4 0x000000000048f408 in irssi_ssl_handshake ()
#5 0x0000000801505edc in g_io_channel_read () from /usr/local/lib/libglib-2.0.so.0
#6 0x00000000004822bc in net_receive ()
#7 0x000000000048196c in net_sendbuffer_receive_line ()
#8 0x0000000000459bf6 in irc_irc_deinit ()
#9 0x000000000047e396 in g_input_add_full ()
#10 0x00000008015128c2 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0
#11 0x0000000801512c63 in g_main_context_pending () from /usr/local/lib/libglib-2.0.so.0
#12 0x0000000801512cf4 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0
#13 0x000000000042ce7c in main ()

I've also attached some disassembly of this stack trace. Ask me if you need more or anything else.
WGH http://bugs.irssi.org/:916
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.

Thanks.

--
krtek
Lukas -krtek.net- Novy http://bugs.irssi.org/:915
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 */
g_free(fname);
- 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(fname);
- 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 */
+ }
}
}

--
1.7.10.4


Greetings,

Armin
Armin Jenewein http://bugs.irssi.org/:914
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 http://bugs.irssi.org/:913