Bug 1253321

Summary: perl-CHI: FTBFS in rawhide
Product: [Fedora] Fedora Reporter: Jitka Plesnikova <jplesnik>
Component: perl-CHIAssignee: Ralf Corsepius <rc040203>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: perl-devel, rc040203
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://apps.fedoraproject.org/koschei/package/perl-CHI
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-15 07:18:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jitka Plesnikova 2015-08-13 13:29:05 UTC 
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 07:18:15 UTC 
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.