Bug #91987 for version: Scripts using version-0.9904+ are broken under locales with decimal comma

Thu Jan 09 11:40:15 2014 contyk [...] cpan.org - Ticket created

Subject:

Scripts using version-0.9904+ are broken under locales with decimal comma

The subject says it all. This issue can be easily reproduced with the code below: LC_NUMERIC=hu_HU.utf8 perl -e 'use Gtk2 -init; use DBD::Pg;' Invalid version format (non-numeric data) at /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 237. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. This runs just fine with <=0.9903 or with decimal point locales.

Fri Jan 10 07:07:26 2014 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #91987] Scripts using version-0.9904+ are broken under locales with decimal comma
Date:	Fri, 10 Jan 2014 07:07:13 -0500
To:	bug-version [...] rt.cpan.org, undisclosed-recipients:;
From:	John Peacock <john.peacock [...] havurah-software.org>

On 01/09/2014 11:40 AM, Petr Šabata via RT wrote: Show quoted text

> Thu Jan 09 11:40:15 2014: Request 91987 was acted upon. > Transaction: Ticket created by contyk > Queue: version > Subject: Scripts using version-0.9904+ are broken under locales with > decimal comma > Broken in: 0.9904 > Severity: (no value) > Owner: Nobody > Requestors: contyk@redhat.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=91987 > > > > The subject says it all. This issue can be easily reproduced with the code below: > > LC_NUMERIC=hu_HU.utf8 perl -e 'use Gtk2 -init; use DBD::Pg;' > Invalid version format (non-numeric data) at /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 237. > Compilation failed in require at -e line 1. > BEGIN failed--compilation aborted at -e line 1. > > This runs just fine with <=0.9903 or with decimal point locales. >

I am unable to replicate this using 0.9906 (current) or anything earlier. NOTE: because you are not explicitly using version in your example, you are in fact using whatever version.pm is currently in the core code for your Perl (which you didn't tell me about). John

Fri Jan 10 07:07:26 2014 The RT System itself - Status changed from 'new' to 'open'

Fri Jan 10 08:14:40 2014 contyk [...] cpan.org - Correspondence added

From:

contyk [...] redhat.com

On Fri Jan 10 07:07:26 2014, john.peacock@havurah-software.org wrote: Show quoted text

> On 01/09/2014 11:40 AM, Petr Šabata via RT wrote:

> > Thu Jan 09 11:40:15 2014: Request 91987 was acted upon. > > Transaction: Ticket created by contyk > > Queue: version > > Subject: Scripts using version-0.9904+ are broken under locales > > with > > decimal comma > > Broken in: 0.9904 > > Severity: (no value) > > Owner: Nobody > > Requestors: contyk@redhat.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=91987 > > > > > > > The subject says it all. This issue can be easily reproduced with > > the code below: > > > > LC_NUMERIC=hu_HU.utf8 perl -e 'use Gtk2 -init; use DBD::Pg;' > > Invalid version format (non-numeric data) at > > /usr/share/perl5/vendor_perl/Exporter/Heavy.pm line 237. > > Compilation failed in require at -e line 1. > > BEGIN failed--compilation aborted at -e line 1. > > > > This runs just fine with <=0.9903 or with decimal point locales. > >

> > I am unable to replicate this using 0.9906 (current) or anything > earlier. NOTE: because you are not explicitly using version in your > example, you are in fact using whatever version.pm is currently in the > core code for your Perl (which you didn't tell me about). > > John

I'm running perl 5.18.1 but I'm not using the `version' bundled with it (0.9902); I only have CPAN `version' installed [0] and this issue appears with 0.9904 or newer, without any other changes on the system, every time. Even though the reproducer doesn't use version directly, I assume it's used somewhere in Gtk2 or DBD::Pg, or modules used by them. This was originally reported for Fedora here: https://bugzilla.redhat.com/show_bug.cgi?id=1050042 [0] Fedora replaces the core packages with updates from CPAN, if available.

Fri Jan 10 19:11:39 2014 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #91987] Scripts using version-0.9904+ are broken under locales with decimal comma
Date:	Fri, 10 Jan 2014 19:11:29 -0500
To:	bug-version [...] rt.cpan.org, undisclosed-recipients:;
From:	John Peacock <john.peacock [...] havurah-software.org>

On 01/10/2014 08:14 AM, Petr Šabata via RT wrote: Show quoted text

> I'm running perl 5.18.1 but I'm not using the `version' bundled with > it (0.9902); I only have CPAN `version' installed [0] and this issue > appears with 0.9904 or newer, without any other changes on the > system, every time. Even though the reproducer doesn't use version > directly, I assume it's used somewhere in Gtk2 or DBD::Pg, or modules > used by them.

It is not possible to separate the version C/XS code from the core; if they have just eliminated the version.pm file, they are not doing anything useful (it is just a stub in the core). The C/XS code is part of util.c/universal.c and it is not severable. Similarly, just installing the cpan version.pm distribution doesn't replace the core XS code until something calls 'use version;' at which point the cpan code overrides the core code for most purposes. In this case, it appears that DBD::Pg is the one that is calling the CPAN version code. Show quoted text

> >

This was originally reported for Fedora here Show quoted text

> https://bugzilla.redhat.com/show_bug.cgi?id=1050042 > > [0] Fedora replaces the core packages with updates from CPAN, if available. >

It is far more likely that Fedora's usual interference in Perl packaging has broken something. It isn't the first time and it won't be the last. To some extent, I can understand their desire to have smaller more modular packaging, but it makes life hard for everyone else. I suppose I'll have to set up a VM running Fedora 20 and see if I can figure out what is going on... John

Sat Jan 11 12:17:29 2014 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #91987] Scripts using version-0.9904+ are broken under locales with decimal comma
Date:	Sat, 11 Jan 2014 12:17:18 -0500
To:	bug-version [...] rt.cpan.org, undisclosed-recipients:;
From:	John Peacock <john.peacock [...] havurah-software.org>

On 01/10/2014 07:11 PM, John Peacock via RT wrote: Show quoted text

> It is far more likely that Fedora's usual interference in Perl packaging > has broken something. It isn't the first time and it won't be the last. > To some extent, I can understand their desire to have smaller more > modular packaging, but it makes life hard for everyone else. > > I suppose I'll have to set up a VM running Fedora 20 and see if I can > figure out what is going on...

I have managed to replicate it on my system running the moral equivalent of the originally reported command: Show quoted text

> $ LC_NUMERIC=hu_HU.utf8 perl -I blib/lib/ -I blib/arch/ -Mversion -e 'use POSIX qw/locale_h/; use locale; setlocale(LC_NUMERIC,"hu_HU.utf8"); print version->VERSION(0.9902);' > Invalid version format (non-numeric data) at -e line 1.

Removing either the setlocale() or the LC_NUMERIC from the environment causes the problem to go away. I've only managed to replicate this under 5.18.1 so far. I'm going to try and add this to my test suite and see if it is specific to 5.18.x or not (I suspect it is). So I cannot directly blame Fedora's disregard for CPAN authors for /this/ bug, though I can complain that the perl-version RPM you are shipping has its package Version listed as 0.99.04, which I can assure you has never existed. John

Sat Jan 11 17:00:22 2014 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #91987] Scripts using version-0.9904+ are broken under locales with decimal comma
Date:	Sat, 11 Jan 2014 17:00:11 -0500
To:	bug-version [...] rt.cpan.org, undisclosed-recipients:;
From:	John Peacock <john.peacock [...] havurah-software.org>

On 01/11/2014 12:17 PM, John Peacock via RT wrote: Show quoted text

> Removing either the setlocale() or the LC_NUMERIC from the environment > causes the problem to go away. I've only managed to replicate this > under 5.18.1 so far. I'm going to try and add this to my test suite and > see if it is specific to 5.18.x or not (I suspect it is).

I've tracked this down ultimately to a bug in Perl itself. version.pm used to (pre 0.9904) always save the current locale and switch to 'C', then switch back. Starting with 0.9904, the version.pm code attempted to only switch the locale when necessary. But that turns out to not be reliable with older Perls. Improvements have been made to Perl, so it is now possible to consistently determine whether a non-C locale is in force. I have a patch that restores the old behavior for the Perl releases prior to 5.19.0, which appears to fix the problem everywhere. I'll try and push a new release soonish... John

Mon Jan 13 06:49:10 2014 jpeacock [...] cpan.org - Correspondence added

Fixed in 0.9907

Mon Jan 13 06:49:11 2014 jpeacock [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Jan 14 10:53:37 2014 contyk [...] cpan.org - Correspondence added

From:

contyk [...] redhat.com

On Mon Jan 13 06:49:10 2014, JPEACOCK wrote: Show quoted text

> Fixed in 0.9907

Thank you, I'm looking forward to the release :) To explain the version string in Fedora -- this is a hack for RPM introduced with the 0.7701, I assume. RPM compares versions by splitting the version string by periods and then comparing the numbers. This guaranteed a clean upgrade path for 0.78. It's obviously unneeded for 0.99* but it doesn't break anything either. Thanks again for a quick fix, Petr