[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2020.06.21.03.39.21.
> The following commits were made between the last successful build and
> the failed build:
> 2020.06.21.03.39.21 lukem src/share/mk/bsd.dep.mk,v 1.85
> Logs can be found at:
The full build log can be found at:
It's not clear from the log what the error was or where it occurred,
and I'm wondering if the lack of identifying and locating information
could be related to another recent commit:
2020.06.19.21.17.48 sjg src/usr.bin/make/job.c 1.198
2020.06.19.21.17.48 sjg src/usr.bin/make/main.c 1.275
2020.06.19.21.17.48 sjg src/usr.bin/make/make.h 1.108
Avoid unnecessary noise when sub-make or sibling dies
When analyzing a build log, the first 'stopped' output
from make, is the end of interesting output.
Normally when a build fails deep down in a parallel build
the log ends with many blockes of error output from make,
with all but the fist being unhelpful.
We add a function dieQuietly() which will return true
if we should supress the error output from make.
If the failing node was a sub-make, we want to die quietly.
Also when we read an abort token we call dieQuietly telling we
want to die quietly.
This behavior is suppressed by -dj or
Reviewed by: christos
Andreas Gustafsson, gson%gson.org@localhost
Main Index |
Thread Index |