[Bug 1108635] New: perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails randomly
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1108635
Bug ID: 1108635
Summary: perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails
randomly
Product: Fedora
Version: rawhide
Component: perl-autobox-Core
Assignee: iarnell(a)gmail.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: iarnell(a)gmail.com, perl-devel(a)lists.fedoraproject.org
perl-autobox-Core-1.24-5.fc21 fails to build in F21 and F20 due randomly
failing tests:
# Failed test at t/flip.t line 8.
# Structures begin differing at:
# $got->{bar} = '2'
# $expected->{bar} = '3'
# Failed test 'Returns hash in list context'
# at t/flip.t line 12.
# Structures begin differing at:
# $got->{bar} = '2'
# $expected->{bar} = '3'
# Looks like you failed 2 tests of 2.
t/flip.t .........
Dubious, test returned 2 (wstat 512, 0x200)
Failed
This is caused by random hash key order probably.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Hf1uNKTicD&a=cc_unsubscribe
9 years, 9 months
[Bug 1026763] New: Locale::Maketext interpolating escaped backslashes improperly
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1026763
Bug ID: 1026763
Summary: Locale::Maketext interpolating escaped backslashes
improperly
Product: Fedora
Version: 18
Component: perl-Locale-Maketext
Assignee: ppisar(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: eggled(a)gmail.com, perl-devel(a)lists.fedoraproject.org,
ppisar(a)redhat.com, psabata(a)redhat.com
External Bug ID: CPAN 120457
+++ This bug was initially created as a clone of Bug #1025906 +++
Description of problem:
When a literal backslash is in an L10N value, it is treated nonuniformly by the
Locale::Maketext::_compile method, as patched by RH in Locale::Maketext::Guts
(per https://bugzilla.redhat.com/show_bug.cgi?id=884354). The result depends
on unrelated parts of the string.
[...]
How reproducible:
Always
Steps to Reproduce:
1. Create a language token, whose value is 'Some data\n'
2. Query the language token through Locale::Maketext ($lh->maketext($tag))
Actual results:
'Some data\\n'
Expected results:
'Some data\n'
Additional info:
The behavior changes in the following cases:
1) If the value contains a tokenized field, behavior depends on whether there
is a trailing newline:
'[_1]Some data\n' => 'Some data\n'
'[_1]Some data\n'."\n" => 'Some data\\n
'
2) If the escaped backslash is in a function call, it behaves as expected:
'Some data[sprintf,\n]' => 'Some data\n'
NOTE: All of these cases in standard perl (with Locale::Maketext v 1.13 from
CPAN) behave exactly the same as each other, and they all produce just a single
'\' before the 'n'.
--- Additional comment from Petr Pisar on 2013-11-04 12:16:19 GMT ---
The 'Some data\n' is due to back-porting the fix to perl 5.10.1.
The parameterized case behaves for me differently and is caused by the changes
in the fix. Even latest Locale::Maketext is affected.
----
All Fedoras are affected.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BtlUasPZ1z&a=cc_unsubscribe
9 years, 9 months