Re: [aur-general] Perl Upgrade, make test failures and you: The Hurt That Finds You First

2014-06-12 Thread WorMzy Tykashi
On 9 June 2014 21:53, John D Jones III unixgeek1...@gmail.com wrote:
 All:
 In my quest to begin getting my packages updated for the recent Perl 5.20
 release. I have run into a number of problems with tests failing on most of
 the pkgbuilds, even stable pkgbuilds like perl-moose or perl-moo. These test
 errors primarily smell like this:

Hi,

You've probably thought of this, but have you checked your hardware is
okay? If I was experiencing the behaviour you describe, I'd leave a
memtest86+ going for several passes and see if it finds any faults.
Or is it generally accepted that perl's tests fail periodically for no
obvious reason?

Cheers,


WorMzy

P.S. Perl sucks.
(Everyone should have a good laugh every so often) :P


Re: [aur-general] Perl Upgrade, make test failures and you: The Hurt That Finds You First

2014-06-12 Thread Justin Davis
I was wondering about this myself. I think the tests failing might
indicate that broken modules are being used but it's probably too late
to know for sure. Unofficial, platform-dependent perl modules (i.e.
those with .so files) need to be rebuilt for perl 5.20 which I assume
you noticed, John.

To really get to the bottom of things, it helps to cut through the
layers of abstraction and just run the test script directly. For
example something like this might give you a more explicit error
message:

perl -Mblib src/perl-whatever-01/t/00-modules.t

Back to your terse, error message. In the test harness, Wstat is the
wait status of the perl process that ran the test. If you shift 512
right by 8 bits, you get 2, which is the exit status. This doesn't
indicate a segfault, though, which is surprising. If that were true
one of the first 8 bits would be set, I think.

Anyways, it's probably too late to tell what was causing your test failures.
-- 
-Justin


Re: [aur-general] Perl Upgrade, make test failures and you: The Hurt That Finds You First

2014-06-12 Thread John D Jones III

On 06/12/14 07:36, Justin Davis wrote:

I was wondering about this myself. I think the tests failing might
indicate that broken modules are being used but it's probably too late
to know for sure. Unofficial, platform-dependent perl modules (i.e.
those with .so files) need to be rebuilt for perl 5.20 which I assume
you noticed, John.

To really get to the bottom of things, it helps to cut through the
layers of abstraction and just run the test script directly. For
example something like this might give you a more explicit error
message:

perl -Mblib src/perl-whatever-01/t/00-modules.t

Back to your terse, error message. In the test harness, Wstat is the
wait status of the perl process that ran the test. If you shift 512
right by 8 bits, you get 2, which is the exit status. This doesn't
indicate a segfault, though, which is surprising. If that were true
one of the first 8 bits would be set, I think.

Anyways, it's probably too late to tell what was causing your test failures.

Well, the more I dig into it, it seems that it has to do with a number 
of modules that have AUR pkgbuilds that were moved into core_perl this 
release. Perl looks in vendor_perl for it's modules before core_perl and 
since the vendor_perl module's version is too low, that was the point of 
failure for a number of them. As for the test failures such as these:


t/00_modules.t  (Wstat: 512 Tests: 0
Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output

I have yet to find the source of those. I suspect one of the many 
modules I have installed ( probably even one of mine ) just needs a 
pkgrel bump to force a reinstall, which is why the wanton mass 
rebuilding of all the installed modules seems to 'fix' the problem. A 
bad backfire from having the pkgbuilds deleted, is that the files 
installed by the pkgbuild become orphans... and other modules trying to 
use the modules find these outdated orphaned files, instead of the shiny 
new module in core_perl. A purging of the dirs of orphans will fix 
that... I'm still working on getting everything back to a stable state 
so I can get the buildserver working again to pkgrel bump what needs it.


DIR=$(perl -E'say join  , grep {!/\./} @INC');
find $(echo $DIR) -type f -exec pacman -Qo -- {} + /dev/null

A quick run of that, nets a buttload of files orphaned on my system and 
I may have found my problem...



error: No package owns /usr/share/perl5/site_perl/TAP/Parser.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Iterator.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Result.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Scheduler.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/ResultFactory.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Result/Version.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Result/Unknown.pm

error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Result/Test.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Result/Comment.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Result/Bailout.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Result/Pragma.pm

error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Result/Plan.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Result/YAML.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Source.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/SourceHandler/Perl.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/SourceHandler/Executable.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/SourceHandler/File.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/SourceHandler/RawTAP.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/SourceHandler/Handle.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Scheduler/Job.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Scheduler/Spinner.pm

error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Grammar.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/IteratorFactory.pm

error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Aggregator.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Iterator/Stream.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Iterator/Array.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/Iterator/Process.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/SourceHandler.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/YAMLish/Reader.pm
error: No package owns 
/usr/share/perl5/site_perl/TAP/Parser/YAMLish/Writer.pm

error: No package owns /usr/share/perl5/site_perl/TAP/Parser/Multiplexer.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Harness.pm
error: No package owns /usr/share/perl5/site_perl/TAP/Harness/Env.pm

Re: [aur-general] Perl Upgrade, make test failures and you: The Hurt That Finds You First

2014-06-12 Thread John D Jones III

On 06/12/14 17:25, John D Jones III wrote:

On 06/12/14 07:36, Justin Davis wrote:
Well, the more I dig into it, it seems that it has to do with a number
of modules that have AUR pkgbuilds that were moved into core_perl this
release. Perl looks in vendor_perl for it's modules before core_perl and
since the vendor_perl module's version is too low, that was the point of
failure for a number of them. As for the test failures such as these:

t/00_modules.t  (Wstat: 512 Tests: 0
Failed: 0)
   Non-zero exit status: 2
   Parse errors: No plan found in TAP output

I have yet to find the source of those. I suspect one of the many
modules I have installed ( probably even one of mine ) just needs a
pkgrel bump to force a reinstall, which is why the wanton mass
 *SNIP*


I think I found the problem:

I installed perl-test-output and poof, perl-moo started building. 
Another module perl-eval-closure was core dumping on the tests, an 
strace netted these three modules as the culprits:


perl-padwalker
perl-devel-caller
perl-devel-lexalias

I will update these, more failed modules:

perl-variable-magic : prevented perl-moose from building when I updated 
to the current version on cpan, first commenting out make test to get it 
installed then reinstalling with make test, it simply segfaulted; after 
reinstalling perl-variable-magic all was well.


perl-any-moose seems to be deprecated upstream for perl-moo tests fail 
with deprecated warnings. All packages that reply on perl-any-moose in 
the system, should be tested and reported upstream as necessary to get 
the migration done.


So the listed modules seem to be fixing the problem, I'm mass 
reinstalling again and so far everything looks like it's succeeding, 
except the out of date packages, which I'll deal with when I get home 
from work in a cpl hours.


--
Thanks,
John D Jones III
UNIX Zealot; Perl Lover
unixgeek1...@gmail.com
jnbek1...@gmail.com
http://zoelife4u.org/