Re: make release abends with "*** Error code 1"

Woodchuck <djvbedford.net> writes:
> On this machine: NetBSD jezebel.chuck 3.1_STABLE NetBSD
3.1_STABLE
> (GENERIC) #0:
> 	Wed Jan 17 15:08:30 EST 2007
>
> the commands:
> cd /usr/src
> make release 2>&1 | tee /home/make.out
>
> are failing.  This error is repeatable.

I'd suggest using build.sh instead of "make
release". It also looks
like you may be missing some of the error message
information, though
I'm not sure why.

Perry

On Fri, 19 Jan 2007, Perry E. Metzger wrote:

> Woodchuck <djvbedford.net> writes:
>> On this machine: NetBSD jezebel.chuck 3.1_STABLE
NetBSD 3.1_STABLE
>> (GENERIC) #0:
>> 	Wed Jan 17 15:08:30 EST 2007
>>
>> the commands:
>> cd /usr/src
>> make release 2>&1 | tee /home/make.out
>>
>> are failing.  This error is repeatable.
>
> I'd suggest using build.sh instead of "make
release". It also looks
> like you may be missing some of the error message
information, though
> I'm not sure why.
>
> Perry

Trust me, the sample command above (make release 2>...)
is *cut
and pasted* from the command history, and the total output
put up
at the website is unedited.

Googling various archives for Net- Free- and OpenBSD show
that your
response is a typical one going back several years , namely
"Where are the error messages?" And indeed I share
your mystification
about that.  I have the feeling that there is a *bug*
somewhere,
and that no error messages are in fact being produced, and
that the
bug is either in make or in something else, possibly some
shell
script, called by make, which is "stingy" with
information, or that
it is invoked with 2>/dev/null, as is sometimes done by
the "hurried"
programmer.  I have a another hypothesis that some program
or script
is returning an error to make either by failing to properly
set its
return code or by returning non-zero through a programming
oversight.

I suspect mtree, the command that seemed to have most
recently
executed.  A cursory inspection of the source in
/usr/src/usr.sbin/mtree/mtree.c shows this bit of code near
the
end:

 	status = verify();
 	if (Uflag & (status == MISMATCHEXIT))
 		status = 0;
 	exit(status);
}

I feel like putting in a spoiler gap here, so that readers
could
try to "spot that bug", but I won't 

Long experience suggests to me that the if statement should
read
 	if (Uflag && (status == MISMATCHEXIT))
I say that without analyzing the code.

If the bug repeats with build.sh, I'll let the list know. 
Then
I'll see about changing mtree.  I have a sense of deja-vu
about
mtree and this particular bug, I seem to recall hacking at
it many
years ago in a different OS.

I also have a suspicion why this mtree bug, if it is one,
doesn't
surface during the make-ing of releases by the core team.

Thanks for your response and encouragement.

Dave
-- 
         In each of us, there burns a soul of a woodchuck.
         In every generation a few are chosen to prove it.