Blead Breaks CPAN: ZEFRAM/Lexical-SealRequireHints-0.011.tar.gz #16520
Comments
From @eserteThis is a bug report for perl from slaven@rezic.de, The swash tests of Lexical-SealRequireHints-0.011 fail ... # Failed test at ./t/swash.t line 51. Flags: Site configuration information for perl 5.27.11: Configured by eserte at Fri Apr 20 21:45:30 CEST 2018. Summary of my perl5 (revision 5 version 27 subversion 11) configuration: @INC for perl 5.27.11: Environment for perl 5.27.11: |
From @dur-randirOn Fri, 20 Apr 2018 13:41:15 -0700, slaven@rezic.de wrote:
This happened somewhere in the 2d74dcf..394d2d3 range (3 commits). I can't bisect inside this range (see #133136). |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 04/20/2018 03:36 PM, Sergey Aleynikov via RT wrote:
These commits remove swashes from being used, mostly, in the perl core, Swashes still exist and are usable; its just that they don't get created
|
From @jkeenanOn Fri, 20 Apr 2018 20:41:15 GMT, slaven@rezic.de wrote:
Failure confirmed. As Sergey Aleynikov noted in RT #133136, bisection pointed to a range of 3 commits which could not be bisected further. I built perl at each of the three commits in question. 'make' failed in the first two of them, so modules could only be installed on the third -- which is where I was able to confirm the problem. See attachment. Thank you very much. -- |
From @jkeenan$ install_branch_for_testing 2d74dcf $ install_branch_for_testing 2cdbf8d $ install_branch_for_testing 394d2d3 |
From @jkeenanSummary of my perl5 (revision 5 version 27 subversion 11) configuration: Characteristics of this binary (from libperl): |
From @eserteDana Fri, 20 Apr 2018 13:41:15 -0700, slaven@rezic.de reče:
The changed behavior can be reduced to: $ strace -eopen perl5.27.10 -e '"foo\x{666}" =~ /foo\p{Alnum}/' |& grep utf8.pm $ strace -eopen perl5.27.11 -e '"foo\x{666}" =~ /foo\p{Alnum}/' |& grep utf8.pm That is, utf8.pm is not loaded anymore in this situation, and that's what the now failing swash.t test checks. |
From @jkeenanOn Fri, 20 Apr 2018 20:41:15 GMT, slaven@rezic.de wrote:
Because Lexical::SealHints is high up on the CPAN river, this failure means that, absent the use of 'force install', other CPAN distributions cannot be reached by 'cpan', 'cpanm', etc., and therefore cannot be assessed for 5.28.0-readiness. Some of the modules known to be broken are: strictures Thank you very much. -- |
From @arcThe test failure is caused by Perl no longer loading utf8.pm for most Unicode property matches. I've written a patch to the Lexical::SealRequireHints test suite so that it now picks one of the few remaining property matches that *does* load utf8.pm, and submitted it to the L::SRH RT queue as https://rt.cpan.org/Ticket/Display.html?id=125176 For reference, the patch looks like this: Inline Patchdiff -urN Lexical-SealRequireHints-0.011.orig/t/swash.t Lexical-SealRequireHints-0.011/t/swash.t
--- Lexical-SealRequireHints-0.011.orig/t/swash.t 2017-07-15 22:56:08.000000000 +0200
+++ Lexical-SealRequireHints-0.011/t/swash.t 2018-04-22 15:08:14.000000000 +0200
@@ -44,8 +44,13 @@
# is the execution. Hence for this test we must arrange for
# both to occur between the surrounding segments of test code.
# A BEGIN block achieves this nicely.
- my $x = "foo\x{666}";
- $x =~ /foo\p{Alnum}/;
+ #
+ # From Perl 5.27.11 onwards, far fewer properties cause the swash
+ # mechanism to be invoked. One option is an nv property in
+ # non-canonical form, but nv properties don't work in older Perls.
+ my ($x, $prop) = "$]" >= 5.027011 ? ("foo\x{be}", '\p{nv=0.75}')
+ : ("foo\x{666}", '\p{Alnum}');
+ $x =~ /foo$prop/;
}
BEGIN {
ok exists($INC{"utf8.pm"});
-- Aaron Crane |
From @khwilliamsonOn 04/22/2018 07:18 AM, Aaron Crane via RT wrote:
But note, that those few properties are going to stop loading utf8.pm
|
From @iabynOn Sun, Apr 22, 2018 at 08:18:58AM -0600, Karl Williamson wrote:
Given that the module needs fixing rather than perl, and that the module -- |
From @eserteDana Mon, 23 Apr 2018 05:59:01 -0700, davem reče:
Having a stable release where more than 100 CPAN distributions are not buildable anymore is just bad user experience. A blocker ticket does not have to mean that something have to be changed in the perl interpreter, but that at least there should be some management done to fix this situation. |
From @jkeenanOn Thu, 26 Apr 2018 06:02:50 GMT, slaven@rezic.de wrote:
Today I posted in https://rt.cpan.org/Ticket/Display.html?id=125176 confirming the value of the patch submitted by Aaron Crane and requesting that the upstream maintainer apply it and issue a new CPAN release. Thank you very much. |
From @iabynOn Tue, May 15, 2018 at 10:31:49AM -0700, James E Keenan via RT wrote:
In the meantime, Karl has pushed v5.27.11-39-g3cacfe74ed, which -- |
jkeenan
added
BBC
The comment in the code was wrong. The workaround therein is for RT #133135, not for what the comment said. But 133135 is GH #16520, so change to the new number.
The comment in the code was wrong. The workaround therein is for RT #133135, not for what the comment said. But 133135 is GH Perl#16520, so change to the new number.
The comment in the code was wrong. The workaround therein is for RT #133135, not for what the comment said. But 133135 is GH Perl#16520, so change to the new number.
The comment in the code was wrong. The workaround therein is for RT #133135, not for what the comment said. But 133135 is GH Perl#16520, so change to the new number.
Migrated from rt.perl.org#133135 (status was 'open')
Searchable as RT133135$
The text was updated successfully, but these errors were encountered: