FAQ
# New Ticket Created by James E Keenan
# Please include the string: [perl #121079]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=121079 >


I last successfully built and tested Perl on Darwin/PPC on Jan 19 2014
at commit 20e5bab43efd0e449d0741f5c5a278e7e20ee9dc.

Tonight I was testing a smoke-me branch I created to test alh's patch.
This branch, 5b009e54b722a20afcd404d9b156ad7250559add, is essentially
commit e0580a69498c2947ff447422771cbabc77945e2d plus alh's patch. I
experienced new failures during 'make test' in lib/locale.t. Full
output is attached, but here are the failures:

#####
not ok 244 Verify that a different locale radix works when doing "=="
with a constant
not ok 245 Verify that a different locale radix works when doing "=="
with a scalar
...
not ok 249 Verify that "==" with a scalar and an intervening sprintf
still works in inner no locale
...
not ok 252 Verify that after a no-locale block, a different locale radix
still works when doing "==" with a scalar and an intervening sprintf
...
not ok 254 Verify that don't get warning under "==" even if radix is not
a dot
#####

In addition, more locales had problems. Previously, I would get these
locale failures:

#####
# The following locales
#
# lt_LT.ISO8859-13 lt_LT.ISO8859-4
#
# had problems.
#####

But this evening I got:

#####
# The following locales
#
# eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
# lt_LT.ISO8859-13 lt_LT.ISO8859-4
#
# had problems.
#####

I have been compiling blead on this machine weekly for two years. This
is the first time I can recall problems with those three eu_ES* locales.

While I haven't bisected, suspicion naturally falls on the
locale-related commits such as a02ae656c54414fd3b04bf8cc53393e5c2438083
made on Jan 22.

Thank you very much.
Jim Keenan

Search Discussions

  • Karl Williamson at Jan 25, 2014 at 5:26 pm

    On 01/24/2014 08:09 PM, James E Keenan (via RT) wrote:
    # New Ticket Created by James E Keenan
    # Please include the string: [perl #121079]
    # in the subject line of all future correspondence about this issue.
    # <URL: https://rt.perl.org/Ticket/Display.html?id=121079 >


    I last successfully built and tested Perl on Darwin/PPC on Jan 19 2014
    at commit 20e5bab43efd0e449d0741f5c5a278e7e20ee9dc.

    Tonight I was testing a smoke-me branch I created to test alh's patch.
    This branch, 5b009e54b722a20afcd404d9b156ad7250559add, is essentially
    commit e0580a69498c2947ff447422771cbabc77945e2d plus alh's patch. I
    experienced new failures during 'make test' in lib/locale.t. Full
    output is attached, but here are the failures:

    #####
    not ok 244 Verify that a different locale radix works when doing "=="
    with a constant
    not ok 245 Verify that a different locale radix works when doing "=="
    with a scalar
    ...
    not ok 249 Verify that "==" with a scalar and an intervening sprintf
    still works in inner no locale
    ...
    not ok 252 Verify that after a no-locale block, a different locale radix
    still works when doing "==" with a scalar and an intervening sprintf
    ...
    not ok 254 Verify that don't get warning under "==" even if radix is not
    a dot
    #####

    In addition, more locales had problems. Previously, I would get these
    locale failures:

    #####
    # The following locales
    #
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4
    #
    # had problems.
    #####

    But this evening I got:

    #####
    # The following locales
    #
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4
    #
    # had problems.
    #####

    I have been compiling blead on this machine weekly for two years. This
    is the first time I can recall problems with those three eu_ES* locales.

    While I haven't bisected, suspicion naturally falls on the
    locale-related commits such as a02ae656c54414fd3b04bf8cc53393e5c2438083
    made on Jan 22.

    Thank you very much.
    Jim Keenan
    I have some ideas about what could be happening, but I really need a
    debugger on a Darwin machine to see for sure. Until one shows up, could
    you rerun the test with the environment variable PERL_DEBUG_FULL_TEST=2
    set, and send me the results?
  • Craig A. Berry at Jan 25, 2014 at 5:51 pm

    On Sat, Jan 25, 2014 at 11:26 AM, Karl Williamson wrote:

    I have some ideas about what could be happening, but I really need a
    debugger on a Darwin machine to see for sure. Until one shows up, could you
    rerun the test with the environment variable PERL_DEBUG_FULL_TEST=2 set, and
    send me the results?
    FWIW I can't reproduce these new problems on my Darwin PPC system, but
    it's osvers=9.8.0, not osvers=8.11.0 like Jim's. This with

    % git describe
    v5.19.8-107-ge0580a6
  • James E Keenan via RT at Jan 25, 2014 at 8:57 pm

    On Sat Jan 25 09:27:02 2014, public@khwilliamson.com wrote:
    I have some ideas about what could be happening, but I really need a
    debugger on a Darwin machine to see for sure. Until one shows up, could
    you rerun the test with the environment variable PERL_DEBUG_FULL_TEST=2
    set, and send me the results?
    Attached.

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • James E Keenan via RT at Jan 30, 2014 at 1:04 pm
    As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

    # The following locales^M
    #^M
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
    #^M
    # had problems.^M


    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • James E Keenan via RT at Feb 9, 2014 at 6:19 pm

    On Thu Jan 30 05:04:35 2014, jkeenan wrote:
    As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

    # The following locales^M
    #^M
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
    #^M
    # had problems.^M

    Karl,

    Have you had a chance to take a look at this?

    Given the age of this platform, *fixing* the problem would be nice but *understanding* the cause of the breakage is probably more important.

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • Karl Williamson at Feb 10, 2014 at 4:12 am

    On 02/09/2014 11:19 AM, James E Keenan via RT wrote:
    On Thu Jan 30 05:04:35 2014, jkeenan wrote:
    As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

    # The following locales^M
    #^M
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
    #^M
    # had problems.^M

    Karl,

    Have you had a chance to take a look at this?

    Given the age of this platform, *fixing* the problem would be nice but *understanding* the cause of the breakage is probably more important.

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
    I'm going to need the output of a run with the environment variable set
    properly. I don't know what you were doing, but you haven't
    successfully set it. If you are doing it on a separate line, in Linux,
    it needs to be exported. A single line command on Linux would be

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T lib/locale.t > locale.log 2>&1

    I presume the same thing works on Darwin, but don't know for sure
  • Karl Williamson at Feb 10, 2014 at 8:41 pm

    On 02/09/2014 09:12 PM, Karl Williamson wrote:
    On 02/09/2014 11:19 AM, James E Keenan via RT wrote:
    On Thu Jan 30 05:04:35 2014, jkeenan wrote:
    As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

    # The following locales^M
    #^M
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
    #^M
    # had problems.^M

    Karl,

    Have you had a chance to take a look at this?

    Given the age of this platform, *fixing* the problem would be nice but
    *understanding* the cause of the breakage is probably more important.

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
    I'm going to need the output of a run with the environment variable set
    properly. I don't know what you were doing, but you haven't
    successfully set it. If you are doing it on a separate line, in Linux,
    it needs to be exported. A single line command on Linux would be

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T lib/locale.t > locale.log 2>&1

    I presume the same thing works on Darwin, but don't know for sure
    On second thought, also add a -DL option to the command line

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T -DL lib/locale.t > locale.log 2>&1
  • Karl Williamson at Feb 19, 2014 at 6:15 am

    On 02/10/2014 01:40 PM, Karl Williamson wrote:
    On 02/09/2014 09:12 PM, Karl Williamson wrote:
    On 02/09/2014 11:19 AM, James E Keenan via RT wrote:
    On Thu Jan 30 05:04:35 2014, jkeenan wrote:
    As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

    # The following locales^M
    #^M
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
    #^M
    # had problems.^M

    Karl,

    Have you had a chance to take a look at this?

    Given the age of this platform, *fixing* the problem would be nice but
    *understanding* the cause of the breakage is probably more important.

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
    I'm going to need the output of a run with the environment variable set
    properly. I don't know what you were doing, but you haven't
    successfully set it. If you are doing it on a separate line, in Linux,
    it needs to be exported. A single line command on Linux would be

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T lib/locale.t > locale.log 2>&1

    I presume the same thing works on Darwin, but don't know for sure
    On second thought, also add a -DL option to the command line

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T -DL lib/locale.t > locale.log 2>&1
    I never got an email that you had responded, but I looked at the ticket
    after you said something in irc, and found the output I needed. What's
    happening is that the three eu_ES locales are saying that the decimal
    radix character is the apostrophe, which I find hard to believe. I
    found a version of that locale on the internet which has a comma as the
    decimal point.

    I can write a short C program to send you to compile and run to verify
    that Perl is not getting mixed up about this, but I suspect Perl is
    right about it.

    That would mean that Perl is making some assumptions that the decimal
    point is never going to be a quoting character. I am thinking that it's
    not worth trying to fix that. Craig was unable to reproduce your issue
    with a later version of the OS. Though it may be that he just doesn't
    have those locales installed. But I think it is likely that
    the locale on your OS version is buggy, and it should have been fixed in
    later versions.

    I have a friend living in Basque Spain who uses Apple stuff. I could
    see if he knows anything about this.
  • James E Keenan at Feb 19, 2014 at 12:37 pm

    On 2/19/14 1:15 AM, Karl Williamson wrote:
    On 02/10/2014 01:40 PM, Karl Williamson wrote:
    On 02/09/2014 09:12 PM, Karl Williamson wrote:
    On 02/09/2014 11:19 AM, James E Keenan via RT wrote:
    On Thu Jan 30 05:04:35 2014, jkeenan wrote:
    As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

    # The following locales^M
    #^M
    # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
    # lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
    #^M
    # had problems.^M

    Karl,

    Have you had a chance to take a look at this?

    Given the age of this platform, *fixing* the problem would be nice but
    *understanding* the cause of the breakage is probably more important.

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
    I'm going to need the output of a run with the environment variable set
    properly. I don't know what you were doing, but you haven't
    successfully set it. If you are doing it on a separate line, in Linux,
    it needs to be exported. A single line command on Linux would be

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T lib/locale.t > locale.log 2>&1

    I presume the same thing works on Darwin, but don't know for sure
    On second thought, also add a -DL option to the command line

    PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T -DL lib/locale.t > locale.log 2>&1
    I never got an email that you had responded, but I looked at the ticket
    after you said something in irc, and found the output I needed. What's
    happening is that the three eu_ES locales are saying that the decimal
    radix character is the apostrophe, which I find hard to believe. I found
    a version of that locale on the internet which has a comma as the
    decimal point.

    I can write a short C program to send you to compile and run to verify
    that Perl is not getting mixed up about this, but I suspect Perl is
    right about it.

    That would mean that Perl is making some assumptions that the decimal
    point is never going to be a quoting character. I am thinking that it's
    not worth trying to fix that. Craig was unable to reproduce your issue
    with a later version of the OS. Though it may be that he just doesn't
    have those locales installed. But I think it is likely that
    the locale on your OS version is buggy, and it should have been fixed in
    later versions.

    I have a friend living in Basque Spain who uses Apple stuff. I could see
    if he knows anything about this.
    Thanks for your investigation. Please send me (on or off list) that C
    program and any instructions. Once we identify the problem, we can
    always put SKIP blocks in the test file for this platform/version.

    Thank you very much.
    Jim Keenan
  • Craig A. Berry at Feb 19, 2014 at 1:17 pm

    On Wed, Feb 19, 2014 at 12:15 AM, Karl Williamson wrote:
    Craig was unable to reproduce your issue with a later
    version of the OS. Though it may be that he just doesn't have those locales
    installed. But I think it is likely that
    the locale on your OS version is buggy, and it should have been fixed in
    later versions.
    I have them:

    % uname -v
    Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009;
    root:xnu-1228.15.4~1/RELEASE_PPC
    % locale -a | grep eu_ES
    eu_ES
    eu_ES.ISO8859-1
    eu_ES.ISO8859-15
    eu_ES.UTF-8
  • Karl Williamson via RT at Feb 23, 2014 at 5:27 am
    I sent Jim a C program to print the radix characters. It showed for these locales
    eu_ES.ISO8859-1
    eu_ES.ISO8859-15
    eu_ES.UTF-8
    that the radix was a string of two characters: An apostrophe followed by a space. Since Craig isn't having this problem on his later version of libc, this appears to be a bug in these locales that has since been fixed. I was wrong when I told Jim offlist that a single-byte locale, such as 8859, can only have a single byte radix character. In fact the radix is a string, so this is legal POSIX . I *think* also that Perl can cope with a multi-char radix, but it can't cope with this one. From the error messages, it is likely that Perl can't handle a quote character being part of a decimal point. As I said above, I don't believe it's worth fixing this, given until and if we are ever presented with a legitimate locale that has this characteristic.

    The reason this hasn't shown up before is the same reason the Lithuanian locales used to pass. I have added a lot of locale tests in 5.19 that never were there before. In this case, it started failing when I added some new radix tests. (In the Lithuanian case, tests for upper/lowercase pairs showed that the ENG character casing hasn't been implemented correctly).

    locale.t has also been updated so that if a certain percentage of tests on a machine pass completely, the failures don't fail the test as a whole. For most platforms the number is >5% failure triggers the whole test failing. The percentage can be varied depending on platform. For MSWindows, every locale but the C locale has at least one violation of the POSIX standard, so the acceptable percentage of failures is 99.9%.

    Rather than make special cases for these tests, I think the general mechanism is good enough. If it's the case that these failures are pushing the failure rate too high for this platform and OS version, then we can up the acceptable failure rate enough to get it to pass.
    --
    Karl Williamson

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • James E Keenan via RT at Feb 23, 2014 at 1:50 pm

    On Sat Feb 22 21:27:22 2014, khw wrote:
    I sent Jim a C program to print the radix characters. It showed for
    these locales
    eu_ES.ISO8859-1
    eu_ES.ISO8859-15
    eu_ES.UTF-8
    that the radix was a string of two characters: An apostrophe followed
    by a space. Since Craig isn't having this problem on his later
    version of libc, this appears to be a bug in these locales that has
    since been fixed. I was wrong when I told Jim offlist that a single-
    byte locale, such as 8859, can only have a single byte radix
    character. In fact the radix is a string, so this is legal POSIX . I
    *think* also that Perl can cope with a multi-char radix, but it can't
    cope with this one. From the error messages, it is likely that Perl
    can't handle a quote character being part of a decimal point. As I
    said above, I don't believe it's worth fixing this, given until and if
    we are ever presented with a legitimate locale that has this
    characteristic.

    The reason this hasn't shown up before is the same reason the
    Lithuanian locales used to pass. I have added a lot of locale tests
    in 5.19 that never were there before. In this case, it started
    failing when I added some new radix tests. (In the Lithuanian case,
    tests for upper/lowercase pairs showed that the ENG character casing
    hasn't been implemented correctly).

    locale.t has also been updated so that if a certain percentage of
    tests on a machine pass completely, the failures don't fail the test
    as a whole. For most platforms the number is >5% failure triggers the
    whole test failing. The percentage can be varied depending on
    platform. For MSWindows, every locale but the C locale has at least
    one violation of the POSIX standard, so the acceptable percentage of
    failures is 99.9%.

    Rather than make special cases for these tests, I think the general
    mechanism is good enough. If it's the case that these failures are
    pushing the failure rate too high for this platform and OS version,
    then we can up the acceptable failure rate enough to get it to pass.

    Karl, thank you for the time and effort you have put into this investigation.

    Let me see if I understand the situation correctly. The problem I reported had two parts.

    First, 5 unit tests in lib/locale.t that had been passing for many years suddenly started to fail. With the recent renumbering of the tests, those tests are now:

    #####
    not ok 295 Verify that a different locale radix works when doing "==" with a constant
    not ok 296 Verify that a different locale radix works when doing "==" with a scalar
    ...
    not ok 300 Verify that "==" with a scalar and an intervening sprintf still works in inner no locale
    ...
    not ok 303 Verify that after a no-locale block, a different locale radix still works when doing "==" with a scalar and an intervening sprintf
    ...
    not ok 305 Verify that don't get warning under "==" even if radix is not a dot
    #####

    Second, the number of failing locales on this platform increased from 2 to 6:

    #####
    eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
    lt_LT.ISO8859-13 lt_LT.ISO8859-4
    #####

    The 4 eu_* locales are new failures; the 2 lt_* locales are problematic even on more recent versions of Darwin.

    The FAIL which I am getting in lib/locale.t on Darwin/PPC is caused by the 5 'not ok' tests, i.e., the first problem. The FAIL is not, per se, caused by the increased number of problematic locales.

    The overall FAIL in lib/locale.t is causing 'make test' as a whole to FAIL on this platform. Hence, to get 'make test' to PASS, we need to address the 5 failing unit tests. In other contexts (t/io/eintr.t) we have tested for platform and OS version and simply SKIPped tests known to fail on a certain platform. Would that be acceptable here?

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • Karl Williamson at Feb 24, 2014 at 6:09 am

    On 02/23/2014 06:50 AM, James E Keenan via RT wrote:
    On Sat Feb 22 21:27:22 2014, khw wrote:
    I sent Jim a C program to print the radix characters. It showed for
    these locales
    eu_ES.ISO8859-1
    eu_ES.ISO8859-15
    eu_ES.UTF-8
    that the radix was a string of two characters: An apostrophe followed
    by a space. Since Craig isn't having this problem on his later
    version of libc, this appears to be a bug in these locales that has
    since been fixed. I was wrong when I told Jim offlist that a single-
    byte locale, such as 8859, can only have a single byte radix
    character. In fact the radix is a string, so this is legal POSIX . I
    *think* also that Perl can cope with a multi-char radix, but it can't
    cope with this one. From the error messages, it is likely that Perl
    can't handle a quote character being part of a decimal point. As I
    said above, I don't believe it's worth fixing this, given until and if
    we are ever presented with a legitimate locale that has this
    characteristic.

    The reason this hasn't shown up before is the same reason the
    Lithuanian locales used to pass. I have added a lot of locale tests
    in 5.19 that never were there before. In this case, it started
    failing when I added some new radix tests. (In the Lithuanian case,
    tests for upper/lowercase pairs showed that the ENG character casing
    hasn't been implemented correctly).

    locale.t has also been updated so that if a certain percentage of
    tests on a machine pass completely, the failures don't fail the test
    as a whole. For most platforms the number is >5% failure triggers the
    whole test failing. The percentage can be varied depending on
    platform. For MSWindows, every locale but the C locale has at least
    one violation of the POSIX standard, so the acceptable percentage of
    failures is 99.9%.

    Rather than make special cases for these tests, I think the general
    mechanism is good enough. If it's the case that these failures are
    pushing the failure rate too high for this platform and OS version,
    then we can up the acceptable failure rate enough to get it to pass.

    Karl, thank you for the time and effort you have put into this investigation.

    Let me see if I understand the situation correctly. The problem I reported had two parts.

    First, 5 unit tests in lib/locale.t that had been passing for many years suddenly started to fail. With the recent renumbering of the tests, those tests are now:

    #####
    not ok 295 Verify that a different locale radix works when doing "==" with a constant
    not ok 296 Verify that a different locale radix works when doing "==" with a scalar
    ...
    not ok 300 Verify that "==" with a scalar and an intervening sprintf still works in inner no locale
    ...
    not ok 303 Verify that after a no-locale block, a different locale radix still works when doing "==" with a scalar and an intervening sprintf
    ...
    not ok 305 Verify that don't get warning under "==" even if radix is not a dot
    #####

    Second, the number of failing locales on this platform increased from 2 to 6:

    #####
    eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
    lt_LT.ISO8859-13 lt_LT.ISO8859-4
    #####

    The 4 eu_* locales are new failures; the 2 lt_* locales are problematic even on more recent versions of Darwin.

    The FAIL which I am getting in lib/locale.t on Darwin/PPC is caused by the 5 'not ok' tests, i.e., the first problem. The FAIL is not, per se, caused by the increased number of problematic locales.

    The overall FAIL in lib/locale.t is causing 'make test' as a whole to FAIL on this platform. Hence, to get 'make test' to PASS, we need to address the 5 failing unit tests. In other contexts (t/io/eintr.t) we have tested for platform and OS version and simply SKIPped tests known to fail on a certain platform. Would that be acceptable here?

    Thank you very much.
    Jim Keenan
    I had misunderstood this problem, but it turns out that the offending
    commit had to be b6d186bba098ec33d9f80ce56b932da1ad7a069c,
    which removed the following comments and code:

    <
       < if ($^O eq 'darwin') {
       < # Darwin 8/Mac OS X 10.4 and 10.5 have bad Basque locales: perl bug

        #35895,
       < # Apple bug ID# 4139653. It also has a problem in Byelorussian.
       < (my $v) = $Config{osvers} =~ /^(\d+)/;
       < if ($v >= 8 and $v < 10) {
       < debug "# Skipping eu_ES, be_BY locales -- buggy in Darwin\n";
       < @Locale = grep ! m/^(eu_ES(?:\..*)?|be_BY\.CP1131)$/, @Locale;
       < } elsif ($v < 12) {
       < debug "# Skipping be_BY locales -- buggy in Darwin\n";
       < @Locale = grep ! m/^be_BY\.CP1131$/, @Locale;
       < }
       < }


    So, the reason this didn't fail until after this commit was these
    locales were skipped. I had thought when I made that commit that
    the new scheme of allowing a percentage of failures would cover these,
    but there are complications, which I need to look into the best way to
    fix this.
  • James E Keenan at Feb 24, 2014 at 11:40 am
    On 2/24/14 1:09 AM, karl williamson via RT wrote:
    [snip]
    I had misunderstood this problem, but it turns out that the offending
    commit had to be b6d186bba098ec33d9f80ce56b932da1ad7a069c,
    which removed the following comments and code:

    <
    < if ($^O eq 'darwin') {
    < # Darwin 8/Mac OS X 10.4 and 10.5 have bad Basque locales: perl bug

    #35895,
    < # Apple bug ID# 4139653. It also has a problem in Byelorussian.
    < (my $v) = $Config{osvers} =~ /^(\d+)/;
    < if ($v>= 8 and $v< 10) {
    < debug "# Skipping eu_ES, be_BY locales -- buggy in Darwin\n";
    < @Locale = grep ! m/^(eu_ES(?:\..*)?|be_BY\.CP1131)$/, @Locale;
    < } elsif ($v< 12) {
    < debug "# Skipping be_BY locales -- buggy in Darwin\n";
    < @Locale = grep ! m/^be_BY\.CP1131$/, @Locale;
    < }
    < }


    So, the reason this didn't fail until after this commit was these
    locales were skipped. I had thought when I made that commit that
    the new scheme of allowing a percentage of failures would cover these,
    but there are complications, which I need to look into the best way to
    fix this.
    My manual bisecting last night confirms this.

    803505a9dec91bbcf4dc2400c1400d3c80f8848c PASS (with the 2 failing lt_*
    locales)

    b6d186bba098ec33d9f80ce56b932da1ad7a069c FAIL (with 5 individual tests
    failing and eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
    additional locale failures).

    Would it be possible to revert b6d186bba098ec33d9f80ce56b932da1ad7a069c
    until a better solution is found?

    Thank you very much.
    Jim Keenan
  • Karl Williamson via RT at Feb 24, 2014 at 7:23 pm

    On Mon Feb 24 03:40:31 2014, jkeen@verizon.net wrote:
    On 2/24/14 1:09 AM, karl williamson via RT wrote:
    [snip]
    I had misunderstood this problem, but it turns out that the offending
    commit had to be b6d186bba098ec33d9f80ce56b932da1ad7a069c,
    which removed the following comments and code:

    <
    < if ($^O eq 'darwin') {
    < # Darwin 8/Mac OS X 10.4 and 10.5 have bad Basque locales:
    perl bug

    #35895,
    < # Apple bug ID# 4139653. It also has a problem in
    Byelorussian.
    < (my $v) = $Config{osvers} =~ /^(\d+)/;
    < if ($v>= 8 and $v< 10) {
    < debug "# Skipping eu_ES, be_BY locales -- buggy in
    Darwin\n";
    < @Locale = grep ! m/^(eu_ES(?:\..*)?|be_BY\.CP1131)$/,
    @Locale;
    < } elsif ($v< 12) {
    < debug "# Skipping be_BY locales -- buggy in Darwin\n";
    < @Locale = grep ! m/^be_BY\.CP1131$/, @Locale;
    < }
    < }


    So, the reason this didn't fail until after this commit was these
    locales were skipped. I had thought when I made that commit that
    the new scheme of allowing a percentage of failures would cover
    these,
    but there are complications, which I need to look into the best way
    to
    fix this.
    My manual bisecting last night confirms this.

    803505a9dec91bbcf4dc2400c1400d3c80f8848c PASS (with the 2 failing lt_*
    locales)

    b6d186bba098ec33d9f80ce56b932da1ad7a069c FAIL (with 5 individual tests
    failing and eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
    additional locale failures).

    Would it be possible to revert
    b6d186bba098ec33d9f80ce56b932da1ad7a069c
    until a better solution is found?

    Thank you very much.
    Jim Keenan
    It's best to not skip testing an entire locale because it is defective in one area. I had forgotten that the way locale.t works is that some test failures are considered likely to be a core failure, and some tests are considered to likely be a bad locale definition, and only are considered a core failure if more than an acceptable percentage of locales fail. These failures were in the first group, but really should be in the second.

    Attached are two patches that move these tests to the second group. Please apply them to make sure that your machine passes with them. Then I will push them to blead.

    I tested on my machine by creating a temporary hack to locale.c that returns the bad radix string for the Basque locales. With that, I was able to reproduce your problem. With these patches, the .t passes for me.
    --
    Karl Williamson

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • James E Keenan via RT at Feb 25, 2014 at 2:20 am
    On Mon Feb 24 11:23:02 2014, khw wrote:
    [snip]
    It's best to not skip testing an entire locale because it is defective
    in one area. I had forgotten that the way locale.t works is that some
    test failures are considered likely to be a core failure, and some
    tests are considered to likely be a bad locale definition, and only
    are considered a core failure if more than an acceptable percentage of
    locales fail. These failures were in the first group, but really
    should be in the second.

    Attached are two patches that move these tests to the second group.
    Please apply them to make sure that your machine passes with them.
    Then I will push them to blead.
    The two patches DWIMmed. On darwin/ppc, lib/locale.t once again PASSes because the 5 tests that were failing are now marked TODO. The 4 es_* locales are still listed as having problems -- as are the 2 lt_* locales -- but that is not causing the test file as a whole to fail. Consequently, for the first time in four weeks, 'make test' is once again PASSing on this platform.

    I also tested the patches on linux/x86_64 and darwin/x86_64. lib/locale.t was not failing on those platforms. The two patches do no harm.

    So, please apply the patches to blead and then close this RT.

    Thank you very much.
    Jim Keenan

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079
  • Karl Williamson via RT at Feb 25, 2014 at 5:39 am
    The commit that actually fixed this was
    b057411ddb1a3d8b6ab062d667c8e39f80cd7343
    --
    Karl Williamson

    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=121079

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedJan 25, '14 at 3:10a
activeFeb 25, '14 at 5:39a
posts18
users4
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase