Open blastwave opened 3 months ago
So that is annoying. The only way to get that info is to actually do the install of the broken perl that can not pass a testsuite.
You can do `./perl -Ilib -V
I suspect this is because I always build perl "out of tree" and the actual pristine sources from the tarball are always extracted as root. That means that the sources can not be mangled by anyone or any process. Seems to work great with things like GCC where nothing will attempt to bork around with the source tree during a build or test.
Not so with PERL ?
I would consider that a bug. It's in a contributed module though, it should be fixed upstream.
(Original post edited to distinguish code blocks from text.)
This ticket reports test failures in several different files. Problems with the following tests should first be reported upstream:
../cpan/Archive-Tar/t/09_roundtrip.t
at https://rt.cpan.org/Dist/Display.html?Name=Archive-Tar
../cpan/Pod-Simple/t/corpus.t
../cpan/Pod-Simple/t/htmlbat.t
at https://github.com/perl-pod/pod-simple/issues
If there's no satisfactory resolution upstream, you can re-file an issue here.
There is no real problem with the following test:
../cpan/autodie/t/version.t
The upstream maintainer is merely indicating that this test only needs to be run by the maintainer when preparing a CPAN release.
The following test file is the only one directly under the control of the maintainers of the Perl core distribution (Perl 5 Porters):
../dist/Storable/t/huge.t
The test file runs no tests if the user has not set the envvar PERL_TEST_MEMORY
at all or only to a value of 4 or less. The file probably should do a better job of skipping tests that require much larger quantities of memory even when PERL_TEST_MEMORY
has been defined by the user. Patches welcome.
Incredibly similar to https://github.com/Perl/perl5/issues/21233
However this is a really trivial Linux machine on AMD64 and nothing even remotely interesting about it. There is no Microsoft SystemD on this machine as it is based on the Devuan distro goodness. It runs nothing at all other than NTPd and the SSHd daemons. I use it for baseline testing.
To begin with we have to get the perl -V stuff :
So that is annoying. The only way to get that info is to actually do the install of the broken perl that can not pass a testsuite.
OKay so then I backup the affected destination area and then install and we see :
Then we get to the tests that fail wherein I did run the testsuite over and over with a few different env vars set as per documentation. Just to see if a few of the longer tests would run. They did. Some of them.
In the ./t directory I did run the ../perl harness procedure with a few env vars set :
Before anyone asks about the "AUTHOR_TESTING=1" suffice it to say that nothing else seemed to make a difference so why not give it a whirl? It made no difference in the test results. The same tests fail over and over :
There we see the "09_roundtrip.t" fails. Again. Same as in bug #21233. So that is not new. The other two are new ones however I am guessing it is because I always build perl "out of tree" in a separate build directory.
So that is a familiar failure.
Other oddball things I see that make me curious about the really large memory tests :
I guess I need to run those on a much larger machine with buckets of memory installed. In fact, wow, perhaps a machine with at least 128G of memory or more.
OKay .. next issues are likely due to permissions.
I suspect this is because I always build perl "out of tree" and the actual pristine sources from the tarball are always extracted as root. That means that the sources can not be mangled by anyone or any process. Seems to work great with things like GCC where nothing will attempt to bork around with the source tree during a build or test.
Not so with PERL ?
Yep. Looks like the PERL testsuite wants to bork around with the actual source tree as opposed to using the build directory. That can not be a good way to do things.
So there ya have it.
Also ... what is this RELEASE_TESTING thing ?
Sounds like a good item to test.
-- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken