Bug 1253321 - perl-CHI: FTBFS in rawhide
perl-CHI: FTBFS in rawhide
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: perl-CHI (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Extras Quality Assurance
https://apps.fedoraproject.org/kosche...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-13 09:29 EDT by Jitka Plesnikova
Modified: 2015-08-15 03:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-15 03:18:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jitka Plesnikova 2015-08-13 09:29:05 EDT
Description of problem:
Package perl-CHI fails to build from source in rawhide.

Version-Release number of selected component (if applicable):
0.60-4.fc23

Steps to Reproduce:
koji build --scratch f24 perl-CHI-0.60-4.fc23.src.rpm

Additional info:
This package is tracked by Koschei. See:
https://apps.fedoraproject.org/koschei/package/perl-CHI


The build failed due to missing build-requires perl(Time::HiRes)

Can't locate Time/HiRes.pm in @INC (you may need to install the Time::HiRes module) (@INC contains: /builddir/build/BUILD/CHI-0.60/blib/lib /builddir/build/BUILD/CHI-0.60/blib/arch /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /builddir/build/BUILD/CHI-0.60/blib/lib/CHI/Driver.pm line 23.
...
Compilation failed in require at t/Bugs.t line 2.
BEGIN failed--compilation aborted at t/Bugs.t line 2.
Comment 1 Ralf Corsepius 2015-08-15 03:18:15 EDT
This bug is interesting. 

Initially could not reproduce this issue in local mocks but could only reproduce it in scratch-builds.

After making sure not to be using any caches ("rm -rf /var/{cache,lib}/mock/*"), I also could reproduce this in mock. Seems to me, as if mock is having caching problems. I am inclined to blame this piece of crap called dnf, mock now uses underneath for this.

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