Bug 722474

Summary: rpm-4.9.1-1.fc16 : erroneous unpackaged files
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ffesti, jnovy, mads, pmatilai
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-20 16:48:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rex Dieter 2011-07-15 13:14:15 UTC
Seems some builds are failing due to mysterious "unpackaged files" errors since rpm-4.9.1-1.fc16 landed in rawhide's buildroot.


Example, pkg with -devel subpkg 

%files devel
%{_includedir}/foo/

build fails with

error: Installed (but unpackaged) file(s) found:
   /usr/include/foo/bar.h

Either %_includedir isn't being processed properly, or recursive/dir directives like the example above are failing now for some reason.

Comment 1 Rex Dieter 2011-07-15 13:17:22 UTC
Since this seems to be causing a fair number of failed rawhide builds, I untagged rpm-4.9.1-1.fc16

Comment 2 Panu Matilainen 2011-07-19 08:43:47 UTC
Yup. I missed one seemingly unrelated commit when cherry-picking stuff for 4.9.1 from HEAD, which causes directories with trailing / not to be recursed, and none of my test-packages happened to have such a construct. Doh.

Fixed in rpm-4.9.1-2.fc16 and hoping there are no more brown paperbag-bugs in 4.9.1...

Comment 3 Rex Dieter 2011-07-20 16:46:29 UTC
you sure?  I'm still seeing build failures of the same type with rpm-4.9.1-2.fc16 too, in particular,
http://koji.fedoraproject.org/koji/taskinfo?taskID=3215364

Comment 4 Rex Dieter 2011-07-20 16:48:00 UTC
oh, the error is different now and highlights a packaging bug after all, sorry!