On 09/18/2011 01:03 PM, Karl Williamson wrote:
On 09/18/2011 12:47 PM, Karl Williamson wrote:
On 09/18/2011 12:26 PM, Nicholas Clark wrote:
On Sat, Sep 17, 2011 at 10:13:02PM -0600, Karl Williamson wrote:
On 09/17/2011 01:35 PM, George Greer wrote:
Failures: (common-args) -Dcc=g++ -O
[default] -Uusenm
[default] -DDEBUGGING -Uusenm
[default] -Uusenm -Duseithreads
[default] -DDEBUGGING -Uusenm -Duseithreads
../t/porting/podcheck.t.....................................FAILED
181, 494
I can't reproduce this on my linux machine. I've tried two different
configurations, the final one being,
I can reproduce this (on one machine, not tried further). Not sure why.
not ok 181 - POD of pod/perldelta.pod
# Apparent broken link (4 occurrences)
# to "Array::Base" near line 73
# to "Classic::Perl" near line 74
# to "Array::Base" near line 75
# to "Devel::PPPort" near line 197
# See end of this test output for your options on silencing this
not ok 493 - POD of lib/Devel/PPPort.pm
# Pod NAME already used
# 'cpan/Devel-PPPort/PPPort_pm.PL' also has NAME 'Devel::PPPort' near
line ???
The latter makes little sense to me.
I'm surprised that the former isn't reproducible everywhere.
[Hence why I'm not jumping right in to fix it, as I assume that it's
going
to take more than 10 minutes to figure out and test]
I'm not going to be able to look into this for at least an hour,
possibly
not tonight at all.
Nicholas Clark
I can figure it out from the details you gave, and will have it fixed by
the time you wake tomorrow.
I'm reconsidering this, after thinking about it some more. It appears
that for a period during the build that the Devel::PPPort pod is in some
weird state, and that podcheck.t is being called at that time. That
would explain both of these failures. I don't know how we could
synchronize this better.
I don't know what the best way forward is. I think this is an
indication of a deeper problem. The problem started with commit
df80274d3278c640a5e0fbf3982950bb5ca9d7bc which stopped ignoring as a
matter of course files that end in '.PL', because this isn't a good
thing to do on non-case preserving file systems, such as the default VMS
file system. But, in so doing, it is finding a problem with
lib/Devel/PPPort_pm.PL, or a build artifact of that, that apparently is
timing-related, and gone by the time things are done. podcheck
shouldn't be run until things are stable. And, at second blush, it
seems like this is what is going on. Are there other tests that are run
during such times, and can the results be relied on?
