Join GitHub today
sometimes wrong/useless path set for perl_use_lib #132
And, after much trial and error....its because in 1.70 it switched from List::Util to List::AllUtils and wanting the 'any' method. Which exists in List::Util, providing its new enough....either from using Perl 5.20 or having Scalar-List-Utils installed.
The problem is on systems where the latter is being done.
Scalar-List-Utils installs a List::Util in SITEARCH to override the base version in ARCH. And site_perl paths normally come before the base paths in @inc.
However, with irssi, the configure figures out what the INSTALLARCHLIB path is and promotes that to being searched first. Which causes the older List::Util to get loaded and eventually break things like 'twirssi'. (unable to determine local time zone)
The explanation I gleaned is that its trying to determine where Irssi.pm is going to get installed and making that come first. Problem is that Irssi.pm goes under INSTALLSITEARCH, which by default is first...
While the work around is to use '/set perl_use_lib ...', it might be nice this wasn't needed or required so much hair pulling....
Oh fun, Irssi has managed to reinvent an issue from the perl 5.8 days... So there's actually two things here:
I would like to fix this for 0.8.18. It may need bumping the minimum perl version requirement to 5.10. Making sure this works for manual upgrades and packagers will take some effort, but as you've demonstrated the result of this issue is very hard to debug issues so we really should fix this.
[Aside: I think there's a DateTime bug here in that it hides the error from you which makes debugging this too hard. This is either because it uses Class::Load (which uses an eval block) or it itself runs this code in an eval block and doesn't correctly report an error.]
Yes, I had originally reported the problem against DateTime::TimeZone, as all I got was "Cannot determine local time zone", which was emitted by a die in DateTime::TimeZone::Local.pm. And, changing /etc/localtime from copy of timezone to symlink didn't help.
In other plugins, I spotted the error "Attempt to reload DateTime::TimeZone::America::Chicago.pm aborted".
But, routines to test these calls would work outside of irssi. Also ran into problems when trying to figure out how to debug Perl inside of irssi. Finding this post: http://marc.info/?l=perl5-porters&m=123274874501455&w=2 slowed me down....
And at first it involved frequent restarts of irssi...not sure if it bothered me or all the users in all the channels I autojoin more...
After it had been over a month of no movement on the ticket, and users of couple of local plugins I had done being affected by this problem, had started pestering me constantly this week....I dug in.
And, now that I look...its making use of numerous eval blocks, and nested eval blocks, where most are only concerned with whether they get a new object or not. Ignores $@ and blocks the die's. Though there are some places where it does check and interpret the error, but meaningless when its calling these routines from eval blocks that don't. (and makes the error vague.)
The configure.ac already has the basic set-up for this, but because cras was fighting with some Perl 5.6 issues I guess this wasn't resolved properly. In a running irssi, if your irssi libraries already are in Perl's default search path, you can safely
changed the title from
DateTime::TimeZone > 1.69 doesn't work inside of irssi, due to wrong path set for perl_use_lib
sometimes wrong/useless path set for perl_use_lib
Sep 18, 2015
I am suffering from this problem, on the FreeBSD port of irssi 0.8.19, see http://www.freshports.org/irc/irssi/
/script exec use Data::Dumper; print Dumper @INC [16:02:41] $VAR1 = '/home/gedge/.irssi/scripts'; [16:02:41] $VAR2 = '/usr/local/share/irssi/scripts'; [16:02:41] $VAR3 = '/usr/local/lib/perl5/5.20/mach'; [16:02:41] $VAR4 = '/usr/local/lib/perl5/site_perl/mach/5.20'; [16:02:41] $VAR5 = '/usr/local/lib/perl5/site_perl'; [16:02:41] $VAR6 = '/usr/local/lib/perl5/5.20'; [16:02:41] $VAR7 = '/usr/local/lib/perl5/site_perl/5.20/amd64-freebsd-thread-multi'; [16:02:41] $VAR8 = '/usr/local/lib/perl5/site_perl/5.20'; [16:02:41] $VAR9 = '/usr/local/lib/perl5/site_perl/5.20/mach'; [16:02:41] $VAR10 = '.';
The offending line is indicated by VAR3 above, which seems to have been move up, relative to:
% perl -V ... @INC: /usr/local/lib/perl5/site_perl/mach/5.20 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.20/mach /usr/local/lib/perl5/5.20 /usr/local/lib/perl5/site_perl/5.20/amd64-freebsd-thread-multi /usr/local/lib/perl5/site_perl/5.20 /usr/local/lib/perl5/site_perl/5.20/mach .
Happy to help debug more.
dropping the FreeBSD port's
21:28 $VAR1 = '/home/gedge/.irssi-test2/scripts'; 21:28 $VAR2 = '/usr/local/share/irssi/scripts'; 21:28 $VAR3 = '/usr/local/lib/perl5/amd64-freebsd-thread-multi'; 21:28 $VAR4 = '/usr/local/lib/perl5/site_perl/mach/5.20'; 21:28 $VAR5 = '/usr/local/lib/perl5/site_perl'; 21:28 $VAR6 = '/usr/local/lib/perl5/5.20/mach'; 21:28 $VAR7 = '/usr/local/lib/perl5/5.20'; 21:28 $VAR8 = '/usr/local/lib/perl5/site_perl/5.20/amd64-freebsd-thread-multi'; 21:28 $VAR9 = '/usr/local/lib/perl5/site_perl/5.20'; 21:28 $VAR10 = '/usr/local/lib/perl5/site_perl/5.20/mach'; 21:28 $VAR11 = '.';
the last part of the output of
whereas, without that option to
FYI, I just this problem for the first time after upgrading to Arch Linux's 0.8.20 package — my