On Wed, Jul 29, 2009 at 4:24 AM, demerphq<demerphq@gmail.com> wrote: > 2009/7/28 David Favor <david@davidfavor.com>: >> As an example here's a compile of PPI which works >> and one which fails. >> >> perl-5.10.1-1641 >> http://davidfavor.com/archive/perl-bug/works.txt >> >> perl-5.10.1-1655 >> http://davidfavor.com/archive/perl-bug/fails.txt > > That was a doc patch. Can you try your test again from a few commits earlier? Thanks for the report, David, and thanks for testing. After climbing back into the chair from which I'd fallen and looking up what PPI is, I realized that nothing "breaks 100s of modules." Something breaks one module, PPI, which now apparently has pretty basic difficulties doing its job of parsing other modules. As Yves says, narrowing this down further would help (maybe use git bisect?). You might also look into why on your run with failures, the manifest checker finds cache files from a previous run: Not in MANIFEST: t/data/18_cache/6/64/64568092e7faba16d99fa04706c46517.ppi Not in MANIFEST: t/data/18_cache/a/ab/abcdef1234567890abcdef1234567890.ppi Does clearing those out manually make any difference in the test failures? Even if it doesn't, the clean targets in PPI may need a little attention. The tests that fail spew a lot of warnings that weren't there before. Can you follow the clues they give about where the trouble might be and create a smaller reproducer? I'm cc'ing Adam Kennedy, who appears to be the PPI maintainer, in case he has any advice or insight.Thread Previous | Thread Next