Skip Menu |

This queue is for tickets about the Archive-Extract CPAN distribution.

Report information
The Basics
Id: 131072
Status: resolved
Worked: 1 hour (60 min)
Priority: 0/
Queue: Archive-Extract

People
Owner: Nobody in particular
Requestors: PMPERRY [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.82
Fixed in: 0.86



Subject: failed t tests in Windows
Windows 10, Strawberry Perl 5.26.1 Several of the subtests in 01_Archive-Extract.t fail. These appear to be the same failures as reported by one of the automated cpan-testers for Perl 5.26.3 (although 5.26.1 passed for whoever ran that one): Configuring B/BI/BINGOS/Archive-Extract-0.82.tar.gz with Makefile.PL Checking if your kit is complete... Looks good Generating a gmake-style Makefile Writing Makefile for Archive::Extract Writing MYMETA.yml and MYMETA.json BINGOS/Archive-Extract-0.82.tar.gz C:\Strawberry\perl\bin\perl.exe Makefile.PL -- OK Running make for B/BI/BINGOS/Archive-Extract-0.82.tar.gz cp lib/Archive/Extract.pm blib\lib\Archive\Extract.pm BINGOS/Archive-Extract-0.82.tar.gz C:\STRAWB~1\c\bin\gmake.exe -- OK Running make test for BINGOS/Archive-Extract-0.82.tar.gz "C:\Strawberry\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t t/01_Archive-Extract.t .. # Older versions of Archive::Zip may cause File::Spec warnings # See bug #19713 in rt.cpan.org. It is safe to ignore them t/01_Archive-Extract.t .. 1/? # Failed test 'Found correct output file 'y/z'' # at t/01_Archive-Extract.t line 498. ' got: 'y/z # expected: 'y/z' t/01_Archive-Extract.t .. 338/? # Failed test 'Found correct output file 'y/z'' # at t/01_Archive-Extract.t line 498. ' got: 'y/z # expected: 'y/z' # Failed test 'Found correct output file 'a'' # at t/01_Archive-Extract.t line 498. ' got: 'a # expected: 'a' # Failed test 'Found correct output file 'a'' # at t/01_Archive-Extract.t line 498. ' got: 'a # expected: 'a' t/01_Archive-Extract.t .. 1514/? # Looks like you failed 4 tests of 1524. t/01_Archive-Extract.t .. Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/1524 subtests (less 656 skipped subtests: 864 okay) Test Summary Report ------------------- t/01_Archive-Extract.t (Wstat: 1024 Tests: 1524 Failed: 4) Failed tests: 330, 354, 438, 462 Non-zero exit status: 4 Files=1, Tests=1524, 4 wallclock secs ( 0.22 usr + 0.00 sys = 0.22 CPU) Result: FAIL Failed 1/1 test programs. 4/1524 subtests failed. gmake: *** [Makefile:872: test_dynamic] Error 4 Lockfile removed. BINGOS/Archive-Extract-0.82.tar.gz C:\STRAWB~1\c\bin\gmake.exe test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports BINGOS/Archive-Extract-0.82.tar.gz Stopping: 'install' failed for 'Archive::Extract'. In the CPAN test, it appears that there may be an extra \n at the end of some 'z' values, while in my installation's tests, it might be a \r (x0D)? I haven't delved into the depths of the code, so I can't tell you if you should be routinely stripping whitespace, or if this indicates a genuine problem with one version of Perl on one OS. Anyway, I hope that gives you a clue where to look. If you need me to test a debug installation image and report results back to you, please don't hesitate to contact me offline.
Thanks for the ticket. I have been able to reproduce this myself on a new Windows Server 2019 installation with a self-compiled v5.30.1 I suspect \r shenanigans myself. Will update ticket when I get it fixed.
Auto-update attempt to 0.84 today. Exactly the same t-test errors as reported previously. Was this release a fix for other things, and you're still working on this bug?
On Thu Dec 05 09:54:14 2019, PMPERRY wrote: Show quoted text
> Auto-update attempt to 0.84 today. Exactly the same t-test errors as > reported previously. Was this release a fix for other things, and > you're still working on this bug?
Yeah, 0.84 resolved a different issue "Fix RT#119084 - won't compile on MSWin32 with taint" Windows 10 (and Windows Server 2019) now comes with a tar.exe in Windows\System32 which is a BSD tar My investigations so far have shown that that utility is being used in all the failing tests. I need to isolate out the IPC::Cmd code and make a test case to see what is going on.
Okay, I have found that the issue is with trailing carriage returns. The tar.exe that is in C:\Windows\System32 has CRLF line endings when doing tar -tf archive.tar I was curious so I found a GNU Tar for Windows and dropped that in a PATH location before C:\Windows\System32 and the tests passed. Presumably because GNU Tar was using LF line endings. Anyway, I have released 0.86 to CPAN which has the fixes.
I have not installed any GNU tar program, so I presume that your fix does not require any add-ons. 0.86 has successfully upgraded, so it looks like it works now. Thanks much!
Closing.