Flyspray:: Fri, 02 Oct 2015 16:41:52 +0000 Flyspray:: Irssi core bugs: Recently opened tasks http://bugs.irssi.org/ FS#922: Please close bugs.irssi.org add new task Henri Salo Mon, 30 Jun 2014 06:46:00 +0000 http://bugs.irssi.org/index.php?do=details&task_id=922 http://bugs.irssi.org/index.php?do=details&task_id=922 FS#921: Right aligned statusbars do not redraw properly. Christopher P. Bills Wed, 28 May 2014 18:12:35 +0000
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.]]>
http://bugs.irssi.org/index.php?do=details&task_id=921 http://bugs.irssi.org/index.php?do=details&task_id=921
FS#920: enable /lastlog when connected via irssiproxy module Edd Fri, 23 May 2014 20:30:21 +0000
Cheers]]>
http://bugs.irssi.org/index.php?do=details&task_id=920 http://bugs.irssi.org/index.php?do=details&task_id=920
FS#919: usermode is never NULL zeebaasheDi9 Tue, 20 May 2014 05:58:00 +0000 This could lead to nickname or activity exposure if irssi used behind bouncer.

quickfix attached]]>
http://bugs.irssi.org/index.php?do=details&task_id=919 http://bugs.irssi.org/index.php?do=details&task_id=919
FS#918: Process still hangs after exiting Irssi (in cygterm). Jean-Luc Tallis Fri, 09 May 2014 21:29:35 +0000
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.]]>
http://bugs.irssi.org/index.php?do=details&task_id=918 http://bugs.irssi.org/index.php?do=details&task_id=918
FS#917: Revert bug 316 - default tab completion should NOT stop signal ferret Mon, 05 May 2014 10:15:31 +0000
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 !~ /^([\@\?])/; )]]>
http://bugs.irssi.org/index.php?do=details&task_id=917 http://bugs.irssi.org/index.php?do=details&task_id=917
FS#916: Crash somewhere inside libcrypto WGH Wed, 23 Apr 2014 06:30:22 +0000
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.]]>
http://bugs.irssi.org/index.php?do=details&task_id=916 http://bugs.irssi.org/index.php?do=details&task_id=916
FS#915: Wildcards in the nick inconsistent between commands Lukas -krtek.net- Novy Thu, 10 Apr 2014 01:22:19 +0000
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]]>
http://bugs.irssi.org/index.php?do=details&task_id=915 http://bugs.irssi.org/index.php?do=details&task_id=915
FS#914: Patch attached: allow themes to reside in ~/.irssi/themes/ Armin Jenewein Mon, 07 Apr 2014 14:53:27 +0000

---
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]]>
http://bugs.irssi.org/index.php?do=details&task_id=914 http://bugs.irssi.org/index.php?do=details&task_id=914
FS#913: /help log doesn't mention autolog Inspector Spacetime Fri, 21 Mar 2014 12:41:50 +0000
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.]]>
http://bugs.irssi.org/index.php?do=details&task_id=913 http://bugs.irssi.org/index.php?do=details&task_id=913