Description of problem: perl-Pugs-Compiler-Rule fails to build in rawhide. Version-Release number of selected component (if applicable): perl-Pugs-Compiler-Rule-0.37-5.fc14 How reproducible: Always. Steps to Reproduce: 1. rebuild the package Actual results: Fails to build. Expected results: Success. Additional info: * Apparently this package is incompatible to perl-5.12 and can't be built against it. * Its upstream appears dead. This package needs to be made working or it will have to be removed from Fedora >= 14. AFAICT, this package is not used by Fedora itself, so it's probably safe to remove it.
This should be simple to fix. It's only t/ast/00-basic.t that is failing due to different indentation of Data::Dumper. And as a bonus, when it fails, it writes out a new t/ast/00-basic.t_ file with the correct indentation. make test # fails diff -b t/ast/00-basic.t t/ast/00-basic.t_ # no difference mv -f t/ast/00-basic.t_ t/ast/00-basic.t make test # succeeds
Checking test results on CPAN, results on different perl versions, checking source code show the problem is more mysterious. More ever adding some debugging prints into the test one can see Data::Dumper treat local hashes and AST hashes in different manner. In addition if we patch the tests, it will start failing on lower perls.
Openly said, I don't see much sense in trying to "fix" this package. It's not used by Fedora, its upstream build-matrix (http://matrix.cpantesters.org/?dist=Pugs-Compiler-Rule+0.37) also speaks a very clear language. My vote goes to "let this package die".
(In reply to comment #2) > Checking test results on CPAN, results on different perl versions, checking > source code show the problem is more mysterious. Certainly, bleadperl is throwing up more problems. > More ever adding some debugging prints into the test one can see Data::Dumper > treat local hashes and AST hashes in different manner. Just more indentation differences? Or really different? > In addition if we patch the tests, it will start failing on lower perls. Not too much of a problem for us. Either patch the tests only in f14+, or better, simply do something like: make test \ || diff -qb t/ast/00-basic.t{,_} \ && mv -f t/ast/00-basic.t{_,} \ && make test (In reply to comment #3) >Openly said, I don't see much sense in trying to "fix" this package. At the minute, the package itself doesn't seem to be broken - only its tests fail for an understandable reason. >It's not used by Fedora, Think of the DarkPAN! >its upstream build-matrix >(http://matrix.cpantesters.org/?dist=Pugs-Compiler-Rule+0.37) >also speaks a very clear language. That its test fail - but we can see why. >My vote goes to "let this package die". I don't really mind either way. Just playing devil's advocate. But according to rel-eng, Steve needs to kill it, not you (or us).
(In reply to comment #4) > (In reply to comment #2) > > More ever adding some debugging prints into the test one can see Data::Dumper > > treat local hashes and AST hashes in different manner. > > Just more indentation differences? Or really different? > Just indentation. Different number of spaces before hash keys and closing bracket. (If I recall properly.).
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I removed the test. Mainly because I haven't permission to remove this package from distro.
(In reply to comment #7) > I removed the test. Please no. What are you trying to achieve? Playing down this package's brokenness? This is not helpful. > Mainly because I haven't permission to remove this package > from distro. Rel-eng made very clear that they want to cope with this package. REOPENING.
There is another problem within Perl 5.14.1: https://rt.cpan.org/Public/Bug/Display.html?id=69816
Steven, please kill (http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife) this package.
Package blocked in Koji (in F17 only?) <https://fedorahosted.org/rel-eng/ticket/4976>.
*** Bug 770960 has been marked as a duplicate of this bug. ***