develooper Front page | perl.perl5.porters | Postings from December 2014

Re: Year-end EBCDIC porting status report

Thread Previous | Thread Next
From:
Karl Williamson
Date:
December 31, 2014 04:35
Subject:
Re: Year-end EBCDIC porting status report
Message ID:
54A37D1A.5060804@khwilliamson.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About