the "cvs" command inside the su returns an error, that should be ignored.
(Aparently cvs returns "1" even if it's done a successful update but if
there were some files removed on purpose).
1) When checking if any of the required binary pkgs is newer, it's
not good to look into the (already existing) binary pkg, as that
might be unchanged. Instead, look at the DEPENDS.
In the context of the recent jpeg changes, the gd package itself was
not changed, but the DEPENDS were (via buildlink files). Now looking
into the existing gd binary pkg still said it wanted jpeg-6b instead
of the now-wanted jpeg>=6b, which was only available via the DEPENDS.
That's the first chunk of the patch below.
2) While debugging this, I found that the change in rev. 1.48 was
wrong, as can be seen throughout the last bulk build, search for errors
like:
find: "/usr/cvs.local/pkgsrc/packages/i386/All/gd-2.0.15.tgz": No such file or directory
As the whole operation is really on two files (as assured by "pkg_admin
lsbest" for pkg and REFS by definition), the quotes can be ommitted.
Why this wasn't caught when that change was tested is beyond me - maybe
different sh(1) behaviour? (The error happened on 1.6.1_STABLE, see
e.g. http://smaug.fh-regensburg.de/~feyrer/ftp/pub/NetBSD/pkgstat-i386/last/www/p5-Template-Toolkit/.broken.yui.html).
Anyways, that's addressed in the second part of the patch below, too.
3) Use ${FIND} while there.
Introduce sandboxEmptyFiles a list of files to create empty in the
sandbox if they exist on the hosting system. Hence put /var/run in
sandboxEmptyDirs list.
Use $cppprog instead of cp.
in the sandbox if they exist on the hosting system: put /var/spool/mqueue
as it was already created before and add /var/log for now (needed
for various packages, like security/ssh2).
Only create /var/run/utmp(x) if they exist on the hosting system.
XXX this may better be an opsys dependent action.
care not to blow away our bootstrap-pkgsrc stuff in the initial phase.
Also mark devel/bmake and devel/mk-files as broken on non-NetBSD so as not
to blow away our precious files from the bootstrap process in the middle
of a bulk-build. Now let's see if bulk-building works on Linux...
Provided that I copy a working gcc and the binaries from the bootstrap kit
into the sandbox manually, this gets me as far as having a pkgsrc
sandbox that can build pkg_tools/pkg_install.
