Front page | perl.perl5.porters |
Postings from December 2014
On 12/30/2014 08:46 PM, Karl Williamson wrote:
> On 12/30/2014 12:10 AM, Yaroslav Kuzmin wrote:
>> P.S. I am on vacation from 01.01.2015 to 12.01.2015
>
> Have a good vacation
>
> This would be a good time to update the current status. There are
> currently 10 failing core tests, 99% pass rate. These last few are
> proving somewhat intractable. I'll go over each:
>
> 1) t/run/locale.t: This appears to be some weird interaction with the
> shell. The data indicates that PerlEnv_getenv("LC_ALL") is getting
> "perlio" when the test environment is testing with perlio, and "stdio"
> when the test environment is stdio. This is instead of what these
> environment variables are actually getting set to (the string 'invalid')
> and Perl code inside the run that does
>
> print STDERR "ENV{LC_ALL}=", $ENV{LC_ALL}
>
> prints
> ENV{LC_ALL}=invalid
>
> So it appears that retrieving the environment is corrupted. That's why
> I would like this run manually from a terminal. My guess is that it
> will work.
>
> 2) t/re/pat_advanced.t This is now failing one test. I've broken it
> recently with a "fix" to an unrelated bug. And I just haven't had a
> chance to look at it, but it should be easy to fix.
>
> 3) t/op/pack.t. This should again be easy to fix when I get a chance to
> look in real depth.
>
> 4) t/op/stat.t I've discussed this in other emails. The OS is returning
> EBADF for a file descriptor that looks right. I'm hoping that after the
> holidays someone can look at it who has expertise.
>
> 5) t/porting/readme.t This is waiting for me to get around to looking
> at fixing a cpan module it depends on.
>
> 6) dist/Data-Dumper/t/dumper.t This is a parse bug. I now have narrowed
> it down to a single line change in the .t that causes the problem, and
> now have to pore over the debug log.
>
> 7) dist/ExtUtils-CBuilder/t/04-base.t This looks like an lstat()
> problem. lstat is frequently failing with errno=146=EDC5146I Too many
> levels of symbolic links. This happens frequently though this is the
> only time it is accompanied by a test failure. I'm waiting for an
> expert on os390 to look at this.
>
> 8) dist/Net-Ping/t/450_service.t This again looks like an OS
> interaction. Nothing on this has changed from an earlier status report
>
> 9) ext/POSIX/t/sigaction.t We have a suggestion to use a different
> library to see what happens. Yaroslav Have you tried that?
>
> 10) lib/open.t I think this will be fixed after a cpan module it uses
> gets fixed.
>
> When tests for the cpan modules shipped with core are added, we drop to
> a 91% pass rate.
>
> I'm hoping Yaroslave can manually run t/run/locale.t on the
> already-existing bracn before he leaves.
>
> There is a new branch as well, but it has re-enabled some code that I
> suspect will cause it not to work, so that smoking this likely will be
> very fast as it likely won't fully compile. I don't understand what the
> problem has been, and so it might be possible that something done in the
> mean time will have fixed whatever is causing the breakage, but I don't
> really have any candidate fixes that might have done that. But we need
> to try it out at some point, and doing so just before going on vacation
> seems like the best time.
>
Oh, and it would be good if f you could send me the latest contents of
the lib/unicore directory
Thread Previous
|
Thread Next