Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 163576 - Does not terminate with unpackaged files
Does not terminate with unpackaged files
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-07-18 23:32 EDT by Michael A. Peters
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-22 09:45:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test case spec file that should fail in mock but doesn't (933 bytes, text/plain)
2005-07-18 23:35 EDT, Michael A. Peters
no flags Details
yum --installroot=/var/lib/mock/fedora-4-i386-core/root list installed (10.38 KB, text/plain)
2005-07-22 15:51 EDT, Michael A. Peters
no flags Details

  None (edit)
Description Michael A. Peters 2005-07-18 23:32:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
If a spec file has a packaging error resulting in installed but unpackaged files, rpm inside of mock will create the package anyway.

It looks like it has to do with the find command failing in the chroot due to permissions.

Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/testing-1-1-r
find: cannot get current directory: Permission denied
warning: Could not canonicalize hostname: utility.mpeters.local
Wrote: /builddir/build/RPMS/testing-1-1.i386.rpm

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create spec file that should fail due to unpackaged files
2. build spec file outside of mock and watch it fail
3. build spec file inside of mock and watch it build a package

Actual Results:  mock builds a package

Expected Results:  fail to build a package

Additional info:

I'll upload a simple spec file test case that demonstrates the problem
Comment 1 Michael A. Peters 2005-07-18 23:35:39 EDT
Created attachment 116910 [details]
test case spec file that should fail in mock but doesn't

rpmbuild -bs rpm/SPECS/testing.spec
mock -r fedora-4-i386-core rpm/SRPMS/testing-1-1.src.rpm
Comment 2 Seth Vidal 2005-07-22 12:01:45 EDT
odd b/c findutils is in the default buildgroups.

Can you run:
yum --installroot=/path/to/that/mock/tree list installed

and see if findutils is in there?

if so then we're having a path problem of some sort.
Comment 3 Michael A. Peters 2005-07-22 14:42:49 EDT
findutils is in there

* output snip *      
file.i386                                4.13-4                 installed       
filesystem.i386                          2.3.4-1                installed       
findutils.i386                           1:4.2.20-1             installed       
flex.i386                                2.5.4a-34              installed 
* output snip *

I'll upload the full list as an attachment to show exactly what is installed
when it builds the test case src.rpm (which should be just the bare minimals)
Comment 4 Michael A. Peters 2005-07-22 15:51:13 EDT
Created attachment 117073 [details]
yum --installroot=/var/lib/mock/fedora-4-i386-core/root list installed
Comment 5 Adrian Reber 2005-08-01 06:24:13 EDT
I see the same error that /usr/lib/rpm/check-files 'cannot get current directory'

It took me some time but I found the error. The problem is that
/usr/sbin/mock-helper chroot /var/lib/mock//fedora-4-i386-core/root
/sbin/runuser - root -c "/sbin/runuser -c 'rpmbuild --rebuild  --target i386
--nodeps /builddir/build/SRPMS/autossh-1.3-1.src.rpm' mockbuild"
runs in the home directory of the root user in the chroot and the user mockbuild
has no rights to stat that directory. There are many ways to work around this
error. One that works is following patch:

--- mock.py     2005-06-12 05:55:17.000000000 +0200
+++ /usr/bin/mock       2005-08-01 12:18:08.000000000 +0200
@@ -267,7 +267,7 @@
         self.state("Starting Build of %s" % srpmfn)
         # run with --nodeps b/c of the check above we know we have our build
         # deps satisfied.
-        cmd = "%s -c 'rpmbuild --rebuild  --target %s --nodeps %s' %s" % (
+        cmd = "cd /;%s -c 'rpmbuild --rebuild  --target %s --nodeps %s' %s" % (
              self.config['runuser'], self.target_arch, srpm_in, 

or /root could be 777 in the chroot.
Comment 6 Seth Vidal 2005-08-04 03:22:59 EDT
checked in your patch. Thanks.

Comment 7 Orion Poplawski 2005-11-30 16:11:10 EST
When will this get deployed?
Comment 8 Seth Vidal 2005-12-02 01:22:09 EST
hmm - it's been checked in - just not a recent mock release.

I'll work on fixing that very soon.

Comment 9 Orion Poplawski 2005-12-21 12:18:30 EST
Can we please get this deployed?  It's already caused me to mispackage at least
one piece of software.  I'm basically only building inside mock these days and
really need it to work.
Comment 10 Ville Skyttä 2006-01-18 15:58:54 EST
How about finally deploying this?  Dan, in case you're still hacking the
buildsys at the moment, there's a trivial fix in comment 5...
Comment 11 Ville Skyttä 2006-02-15 16:12:38 EST
Hm, Dan, I thought you had updated the FE buildsys roots with this fix, but for

Checking for unpackaged file(s): /usr/lib/rpm/check-files
find: cannot get current directory: Permission denied
Comment 12 Seth Vidal 2006-04-11 04:12:57 EDT
okay - I just verified it - this patch is definitely in mock in cvs.

I'm going to see if we can get a new version released this week with all of the
outstanding patches included so we can deploy it to all the builders and put to
bed a bunch of bugs.

Comment 13 Dan Williams 2006-04-11 07:53:38 EDT
I had, we've been using mock from CVS for a while now on the builders... I know
I patched the FE mock package with this a while ago.

So it looks like some of the builders haven't got it; at least ppc1 isn't
running the same mock as the rest of them are, which is wrong.
Comment 14 Ville Skyttä 2006-05-20 12:32:08 EDT
Indeed, based on looking at some build logs from today and yesterday, this is
still a problem.  Is there a problem with just bringing ppc1 up to date with the
Comment 15 Dan Williams 2006-05-22 09:45:04 EDT
Just put mock 0.4-5 onto ppc1, which is the same version that's on the other ppc
machines.  Please reopen if you see the issue again...

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