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: > > > http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.21.03.39.21
The full build log can be found at: http://releng.netbsd.org/b5reports/i386/2020/2020.06.21.03.39.21/build.log 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 setting .MAKE.DIE_QUIETLY=no Reviewed by: christos -- Andreas Gustafsson, [email protected]
