svn commit: r207849 - in head: . lib/libarchive rescue/rescue usr.bin/ar usr.bin/cpio usr.bin/cpio/test usr.bin/tar usr.bin/tar/test

[N.J. Mann]

In message <25885E8D-93A9-47C7-BC55-AEE2D3773010 at gmail.com>,
	Garrett Cooper (yanefbsd at gmail.com) wrote:
> Please detail the steps that you did to actually reproduce the problem.

I usually do a SVN update every day and then do a buildworld and buildkernel
(GENERIC and four other custom kernels) for head, stable/8 and stable/7.
Because the build box is an old dual-P3 machine that lot takes about 18
hours.  Also, I am preparing to update my desktop machine from 7-STABLE to
8-STABLE and so I didn't do a SVN update for a couple of days.  Hence, this
was the first time I had done a SVN update since lzma was imported to the
tree.

My usual procedure is:

1. remove any local patches
2. svn update
3. re-add local patches
4. buildworld in head
5. buildkernel in head (GENERIC and then custom kernels)
6. buildworld in stable/8
7. buildkernel in stable/8 (GENERIC and then custom kernels)
8. buildworld in stable/7
9. buildkernel in stable/7 (GENERIC and then custom kernels)

When I had the initial failure I immediately did a `rm -r /usr/obj' and
re-tried the build (step 4 above).  It failed again in the same place.  I
then moved my /usr/src.conf and /usr/make.conf aside, just in case, `rm -r
/usr/obj' again and re-tried the build.  It failed in the same place, so I
then started to a search to find which commit was causing the breakage:
207848 is okay, 207849 fails.

> Just to let you know though, piecewise updating of just libarchive isn't
> possible; you need to update some Makefiles and other pieces that Martin
> touched in the lzma import (in particular Makefile.inc1).
> Otherwise things will break quickly.

So, should I build 207848 and then update to 207849?  I think I must be
misunderstanding something here because I fail to see how that will work.
Please feel free to enlighten me.  :-)

Many thanks.


Cheers,
       Nick.
--