freebsd stable - Jan 2018 - why does buildworld fail on stable/11 ?

Subject: Re: why does buildworld fail on stable/11 ?

     On Mon, 22 Jan 2018 12:42:58 +0000 lists <tech-lists at zyxst.net>
wrote:
>On 22/01/2018 09:17, Scott Bennett wrote:
>>     Anyway, I'm stuck.  Can someone please tell me what is going
wrong and
>> how to fix it?  I'd really like to be able to update my system, not
only to
>> keep it reasonably current, but also to be able to customize a kernel. 
Thanks
>> in advance for any suggestions/solutions.
>
>Hi,
     Thank you for responding with your thoughts on
this.
>
>What I'd do is firstly to make things as simple as possible. First do
>the upgrade simply. Either delete or call make.conf & src.conf something
     Okay.
>else. Then get a fresh src  and ports tree via svnlite. Then do
/usr/src has not been altered since I ran the checkout.  Is there some reason
to use svnlite rather than svn, which is how I did the
checkout?
>
>rm -rf /buildwork/ccache.freebsd
>mkdir /buildwork/ccache.freebsd
     I'm not following your thinking here.  If I've eliminated
/etc/make.conf
from the picture, then ccache is not involved at all, so why should I wipe out
the cache contents?
>
>then
>
>[/usr/src #] make cleandir && make clean && make buildworld
&& make
>buildkernel && make installkernel && mergemaster -p
     At this point, that looks very optimistic, to say the least. :-)  I've
tried "make cleanworld" (with /etc/make.conf still in place), and it
failed
exactly like the buildworld example I posted before.
>
>[make changes if needed]
>
>[/usr/src #] make installworld && mergemaster
>
>[make more changes if needed]
>
>reboot
>
>then cd into /usr/src as root, then do
>
>yes | make delete-old
>yes | make delete-old-libs
     What do you expect the above to accomplish on a freshly installed system
on which no obsolete directories or libraries from a previous release should
exist?
>
>reboot again
>
>then re-enable your extra lines in make.conf and src.conf, if you need them.
>
>It may be down to something in the ccache dir, I guess.
>
     I will try it with no /etc/{make,src}.conf then just to find out what
will happen, but I will still need a way to build from source with ccache
involved in the process for normal use because it typically cuts the build
times by 50% - 75% from the usual five or six hours elapsed time.
     Thanks again for your suggestions.  I will try it without
/etc/{make,src}.conf and report back.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************

On 24/01/2018 08:15, Scott Bennett wrote:
>> Hi,
> 
>      Thank you for responding with your thoughts on this.
>>
>> What I'd do is firstly to make things as simple as possible. First
do
>> the upgrade simply. Either delete or call make.conf & src.conf
something
> 
>      Okay.
> 
>> else. Then get a fresh src  and ports tree via svnlite. Then do
> 
> /usr/src has not been altered since I ran the checkout.  Is there some
reason
> to use svnlite rather than svn, which is how I did the checkout?
I use svnlite because it's in base, and in your type of situation I'd
want to use base tools. When did you run the checkout? Did it complete
without error?
>>
>> rm -rf /buildwork/ccache.freebsd
>> mkdir /buildwork/ccache.freebsd
> 
>      I'm not following your thinking here.  If I've eliminated
/etc/make.conf
> from the picture, then ccache is not involved at all, so why should I wipe
out
> the cache contents?
that's the way it *should* work. But by doing this, we eliminate the
possibility of ccache being in the equation at all.
>> then cd into /usr/src as root, then do
>>
>> yes | make delete-old
>> yes | make delete-old-libs
> 
>      What do you expect the above to accomplish on a freshly installed
system
> on which no obsolete directories or libraries from a previous release
should
> exist?
*should* exist. What I'm suggesting makes *certain*. What we know is
make is encountering a problem. What I'm suggesting removes things make
might be picking up, for certain. It's how I've overcome similar issues
in the past - elmiminate all the variables I can, then run it in a
vanilla way, to see if it's still broken.

-- 
J.