Bug 151602 - Package build ignores self-test errors
Summary: Package build ignores self-test errors
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-20 18:36 UTC by Steve Snyder
Modified: 2007-11-30 22:11 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2005-05-17 23:52:52 UTC


Attachments (Terms of Use)

Description Steve Snyder 2005-03-20 18:36:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050227 Fedora/1.7.5-4.icc

Description of problem:
When rebuilding binary RPM from recent perl SRPMs, errors in self-test are ignored.

The Perl self-test always fails (at least 1 failure - see bug #127023).  This can clearly seen by running this command:

  rpmbuild -bc /usr/src/redhat/SPREC/perl.spec

The self-test is run as part of the build and the number of failed test is shown at the end.

Now do this:

  rpmbuild -bb /usr/src/redhat/SPREC/perl.spec

The same errors occure during the compile/self-test, but this time the build breezes right by, continuing to build the binary packages.


Version-Release number of selected component (if applicable):
perl-5.8.3-18.src.rpm through perl-5.8.6-5.src.rpm

How reproducible:
Always

Steps to Reproduce:
1. Rebuild binary Perl packages from SRPM.
2. Pay attention to the results of the self-test, note non-zero number of failures.
3. Build of binary packages runs to completion despite failures.


Actual Results:  Some tests within the self-test suite fail, yet binary packages build without complaint.

Expected Results:  Either no self-tests should fail (the ideal) or the build of the binary RPMs should also fail, to reflect the bad build.


Additional info:

I see this same behavior with the Perl SRPMs from FC2, FC3 and current Rawhide.  I just picked the FC3 distro as the "Version" because it is the most recently released.  This is actually a long-standing problem.

Comment 1 Warren Togami 2005-05-17 23:52:52 UTC
We are unable to fix this at this time.



Note You need to log in before you can comment on or make changes to this bug.