Adding Dennis Gilmore as he is listed as:
rpm -qip buildsys-macros-7-4.fc7.noarch.rpm 
Packager    : Dennis Gilmore

while there is no `buildsys-macros' package in Bugzilla.

Using mock for F7 I originally got:
+ /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/gdb-6.6
...
25725 blocks
+ /usr/lib/rpm/check-buildroot
/var/tmp/rpm-tmp.20364: line 58: /usr/lib/rpm/check-buildroot: No such file or
directory
error: Bad exit status from /var/tmp/rpm-tmp.20364 (%install)

Providing a repository with empty `buildsys-macros' package file workarounds it
but I do not understand why such file exists there if it breaks the build:
$ cat etc/rpm/macros.checkbuild 
%__arch_install_post /usr/lib/rpm/check-buildroot

Created attachment 156402 [details]
Fedora 7 x86_64 (incl. the i386 part) as a temporary file before the official update.

Requires:       rpmdevtools  

is in the buildsys-macros spec  which provides /usr/lib/rpm/check-buildroot 

Can you verify that rpmdevtools is in your buildroot?  if its not can you send 
me the logs for buildroot

Thanks, you were right, unfortunately mock does not report unsatisfied
dependencies in any way (posted as mock Bug 243117).  I had restricted packages
list in my /etc/mock/*.cfg .

Please disregard my Comment 1.

*** Bug 243640 has been marked as a duplicate of this bug. ***

A new update is coming very soon for this.

*** This bug has been marked as a duplicate of 242276 ***

(In reply to comment #6)
> A new update is coming very soon for this.

Are you referring to mock-0.7.0-1.fc7 ?

/me thinks this version is severely bugged.

2 issues:

1) mock --debug -r fedora-7-i386-local somepackage.src.rpm
...
DEBUG: Executing timeout(0): /usr/sbin/mock-helper chroot
/var/lib/mock/fedora-7-i386-local/root /sbin/runuser - root -c "chown 1001
/etc/resolv.conf"
chroot: cannot run command `/sbin/runuser': No such file or directory
DEBUG: _prep_install: files needing ownership fixup:
/var/lib/mock/fedora-7-i386-local/root/etc/mtab
/var/lib/mock/fedora-7-i386-local/root/etc/fstab
/var/lib/mock/fedora-7-i386-local/root/var/log/yum.log
/var/lib/mock/fedora-7-i386-local/root/etc/yum.conf /etc/resolv.conf


2. --autocach seems to be non-functional
#mock --debug --autocach -r fedora-7-i386-local somepackage.src.rpm
...
Executing timeout(0): /usr/sbin/mock-helper rm -rf /var/lib/mock/fedora-7-i386-local
...
Executing timeout(0): /usr/sbin/mock-helper yum --installroot
/var/lib/mock/fedora-7-i386-local/root install buildsys-build
...
Transaction Summary
=============================================================================  
Install    109 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 104 M
[long wait]
Executing timeout(0): /usr/sbin/mock-helper pack
/var/lib/mock/fedora-7-i386-local
/var/lib/mock/root-cache/fedora-7-i386-local.tar.gz root

I can't find any indication of yum unpacking the cache. Either it's deeply
hidden, or autocaching really doesn't work - I think, the latter.

Hrm, the first issue was supposed to be fixed.  It was some fallout from making
mock work with multiple users making use of the same chroots, but a chmod call
got done too early.  Clark said he had fixed that in his git tree, perhaps that
fix didn't make it to the package.  Clark?

Could be.  I don't test with autocache myself, so that could have slipped
through.  Thanks for the feedback so far, will work with Clark and Michael Brown
on these issues.

Well, I am using an rpm having been built from extra's F-7 CVS.

The first issue seems to be related to having 
 config_opts['use_host_resolv'] = True
in /etc/mock/defaults.cfg

Setting it to False lets the error disappear.

The autocache error seems to be stateful, i.e. it seems to depend upon the
result of previous mock runs, esp. on the result of preceding "mock init" runs.
I am inclined to think it to be a side effect of the 1st bug.

At least, with use_host_resolv set to False in defaults.cfg
# mock ... --rebuildcache init
...
# mock ... --autocache <somepackage1>.src.rpm
...
# mock ... --autocache <somepackageN>.src.rpm
succeeds deterministically.

With it set to True, different kinds of weird breakdowns occur