Red Hat Bugzilla – Bug 163576
Does not terminate with unpackaged files
Last modified: 2007-11-30 17:11:10 EST
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 oot-mockbuild 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): mock-0.3-2.fc4 How reproducible: Always 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
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
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.
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)
Created attachment 117073 [details] yum --installroot=/var/lib/mock/fedora-4-i386-core/root list installed
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, self.config['chrootuser']) or /root could be 777 in the chroot.
checked in your patch. Thanks.
When will this get deployed?
hmm - it's been checked in - just not a recent mock release. I'll work on fixing that very soon.
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.
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...
Hm, Dan, I thought you had updated the FE buildsys roots with this fix, but for example: http://buildsys.fedoraproject.org/logs/fedora-development-extras/4478-lincvs-1.4.4-1.fc5/i386/build.log [...] Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/lincvs-1.4.4-1.fc5-root find: cannot get current directory: Permission denied [...]
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.
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.
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 rest?
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...