Arch Linux

Upstream issue: http://search.cpan.org/~rjbs/perl-5.20.0/pod/perldelta.pod#Locale_decimal_point_character_no_longer_leaks_outside_of_use%C2%A0locale_scope

Edit: Actually it's an issue in Encode which is part of perl core. Funny. Adding use locale; there fixes it.

Edit: Strangely enough `LC_ALL=de_DE.utf8 perl -e 'use Encode qw(decode encode);'` can't reproduce the issue. Not sure what's going on.

It's not related to gprename, happens also in Shutter (Copy.pm) and Gmusicbrowser (Encode.pm). Maybe the misleading title can be edited to reflect this.

Bug reports for Copy.pm and Encode.pm sent upstream.

edit: Bug reports:

https://rt.cpan.org/Public/Bug/Display.html?id=96467 for Encode.pm
https://rt.perl.org/Public/Bug/Display.html?id=122105 for Copy.pm

Related forum thread: https://bbs.archlinux.org/viewtopic.php?pid=1422917#p1422917

As discussed in the comments to the second bug above (especially https://rt.perl.org/Public/Bug/Display.html?id=122105#txn-1297477 and below) there is a patch that needs testing by Arch users. If anybody has a playground Arch install in a Virtual Box already, please have a look. I won't be able to do any testing till weekend at earliest.

I did not manage to apply the patch to the perl code, but it is simply adding a line to vutil.c, and I used sed for doing so. That way, at least for gprename the issue went away.

Stefan, I tried to build your PKGBUILD, however khw.patch is not available in the official package, is it your patch? With this patch removed, it fails after a pretty long time with:

../ext/Pod-Html/t/cache.t (Wstat: 256 Tests: 10 Failed: 1)
Failed test: 8
Non-zero exit status: 1
Files=2405, Tests=721294, 1000 wallclock secs (79.16 usr 7.69 sys + 586.07 cusr 47.23 csys = 720.15 CPU)
Result: FAIL
makefile:839: recipe for target 'test_harness' failed
make: *** [test_harness] Error 90

Sorry, khw.patch is not needed. I missed to remove it from the PKGBUILD. I found it in the link you posted above. And you need to do

makepkg --nocheck

because the check function fails.

The earlier suspected causes of this bug are not the true causes. The cause is actually deeper in the perl core, inside of the "version" module, which is integrated with the code for perl and not just a core module.

The bug we are seeing was supposedly fixed by an earlier version of the "version" CPAN distribution. The error was introduced around version 0.9904 of "version" on 09/02/13 and was supposedly fixed in version 0.00907 on 01/15/14. The version module also exists in the perl core, where the C code is copied into vutil.c so it is even more closely integrated than most core modules. A similar bug was reported and supposedly fixed. I am trying to understand exactly why it isn't working.
https://rt.cpan.org/Public/Bug/Display.html?id=91987

If you use the previous patch, please be aware that it reintroduces a bug similar to one that was fixed in 2011.
https://rt.perl.org/Ticket/Display.html?id=105784

I think this post by Karl explains the issue best: https://rt.perl.org/Ticket/Display.html?id=121930#txn-1296317

Also the bug can be reproduced by running `LC_ALL=de_DE.utf8 perl -e'use Gtk2 -init; use 5.8.0'`

If you use en_US locale or don't load gtk it will not crash. Best solution would probably be to take a look at gtk and have it set the locale in a way perl knows about. That's assuming it doesn't, but after having read that explanation (and the remaining thread which talks about gtk3 doing just that) I think that's probably the case.

I've read that bug report, with the post from Karl, which is referenced by our forum thread. He claims that perl's version code in vutil.c cannot just use setlocale, instead of the perl-internal locale switching code because of performance issues. Later he mentions that Gtk2 is to blame and we should all rally against their locale changing.

The first claim is simply untrue as far as I can tell. Previous versions of vutil.c used setlocale prior to 1/15/14. See version of the "version" module prior to 0.9907. Here is a diff between 0.9906 and 0.9907. To see for yourself search for STORE_NUMERIC_LOCAL_SET_STANDARD in vutil.c:
https://metacpan.org/diff/file?target=JPEACOCK/version-0.9907/&source=JPEACOCK/version-0.9906/#vutil/vutil.c

The second claim seems to be based on the idea that perl checks the active locale. The locale exists in two senses, the one set internally by perl, by perl code for example which uses "use locale" and the locale currently set for the process by glibc's setlocale. Perl only checks to see if it changed the locale earlier, and doesn't actually call setlocale to retrieve the current active glibc locale. This is theoretically faster but seems more error prone.

Blaming Gtk2 seems counterproductive when reverting the "version" distribution will solve our immediate problem. The version parsing code that parses the "use 5.8.0" needs to revert to properly setting the numeric locale to C before parsing. Just to reiterate, this is exactly what it used to do. This is what it tries to do.

edit: I toned down the tone of the comment. I think because I just woke up I was a little grumpy.

Whatever is the best solution, I think that it would be nice if Arch could use the patch linked above to provide a workaround for the time till the problem is solved in a good way. As far as I can see, right now for every Arch user all applications using perl and GTK are broken, if the system locale has a comma as decimal point, which I'd call an exceptional state. This should be dealt with as fast as possible, discussions on a proper solution can still follow later.

If you use the above patch please be aware that it does not restore the locale properly, or do any error checking, etc. This was not intended as a long term solution. The patch was intended to diagnose the problem. I'm writing a patch right now that reverts version's vutil.c (in perl) like I suggested.

Attached is the patch which is also available as a gist.
https://gist.github.com/juster/bfb1f50ab0c624c4e4fd

In order to call setlocale directly, to duplicate the bug, I created a rough XS module and simple test script. I didn't want to install Gtk2 solely for this. If anyone is in a similar situation they can use the following XS module. Be sure to read the README if you do.
https://github.com/juster/perl-setlocale

edit: By the way, the patch will cause the porting/customized test to fail in perl's test suite. According to the error message, this is because the SHA1 for vutil.c was changed by changing the file contents.

Thanks for the patch, I've applied it to perl 5.20.0-5 in [testing].

Thanks, 5.20.0-5 fixes the problem for me (in Shutter and Gmusicbrowser).

Thanks, gprename also works again with perl 5.20.0-5.

New perl also fixes issues with pacmanager from aur.

I'd say, this bug can be closed then, couldn't it?

sorry, double post

I'll keep this open at least until perl 5.22 is released to remind me to look at this again.

I've pushed perl 5.20.1-1 to [testing], looks like the patch isn't needed any more and at least gprename works for me. Please test and report any issues.