powerpc userland broken b/w 2020/06/21 00:39 to 06/22 05:34 UTC
For powerpc ports, src/sys/arch/powerpc/mcontext.h rev 1.20 (existed b/w 2020/06/21 00:39:59 to 2020/06/22 05:34:57) turned out to be incorrect. Userland built with this file does not work on kernel as of today. If you have installed that userland, you need to install base.tgz, i.e., libc, rtld, and libpthread, *prior* to updating kernel. Then, update kernel and other userland binaries. If you didn't installed the affected userland, you can (and should) follow normal updating path. I am so sorry for the inconvenience. Thanks, rin
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2020.06.22.02.51.06 rin src/tests/lib/libc/sys/t_ptrace_signal_wait.h,v 1.3 2020.06.22.02.51.06 rin src/tests/lib/libc/sys/t_ptrace_wait.h,v 1.31 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_asxreg.h,v 1.2 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_bootbusreg.h,v 1.2 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_ciureg.h,v 1.8 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_corereg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_fpareg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_gmxreg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_gpioreg.h,v 1.2 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_ipdreg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_mpireg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_pip.c,v 1.7 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_pipreg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_powreg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_rnmreg.h,v 1.5 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_twsireg.h,v 1.3 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_usbcreg.h,v 1.2 2020.06.22.03.05.07 simonb src/sys/arch/mips/cavium/dev/octeon_usbnreg.h,v 1.2 2020.06.22.03.15.48 rin src/share/installboot/evbmips/Makefile,v 1.1 2020.06.22.03.16.29 rin src/etc/mtree/NetBSD.dist.base,v 1.220 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.22.03.16.29
daily CVS update output
Updating src tree: P src/crypto/external/bsd/openssl/dist/crypto/bn/asm/mips.pl P src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips.S P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips64.S P src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc/bn.inc P src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc/crypto.inc P src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc/modes.inc P src/distrib/sets/lists/base/mi P src/doc/CHANGES P src/external/bsd/atf/tests/atf/test-programs/Makefile P src/external/bsd/atf/tests/atf/tools/Makefile P src/external/bsd/kyua-cli/Makefile.inc P src/external/bsd/lutok/dist/state.cpp P src/external/bsd/lutok/tests/lib/liblutok/Makefile P src/external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c P src/lib/libterminfo/compile.c P src/lib/libterminfo/term_private.h P src/share/installboot/Makefile P src/share/installboot/evbarm/boards.plist U src/share/installboot/evbmips/boards.plist P src/share/mk/bsd.README P src/share/mk/bsd.dep.mk P src/sys/arch/aarch64/aarch64/aarch64_machdep.c P src/sys/arch/amd64/amd64/amd64_trap.S P src/sys/arch/amd64/amd64/locore.S P src/sys/arch/amd64/include/frameasm.h P src/sys/arch/arm/arm32/arm32_machdep.c P src/sys/arch/arm/arm32/pmap.c P src/sys/arch/arm/broadcom/bcm283x_platform.c P src/sys/arch/arm/fdt/arm_fdt.c P src/sys/arch/arm/fdt/arm_fdtvar.h P src/sys/arch/arm/imx/files.imx51 P src/sys/arch/mips/cavium/octeonvar.h P src/sys/arch/mips/cavium/dev/if_cnmac.c P src/sys/arch/mips/cavium/dev/if_cnmacvar.h P src/sys/arch/mips/cavium/dev/octeon_asx.c P src/sys/arch/mips/cavium/dev/octeon_asxvar.h P src/sys/arch/mips/cavium/dev/octeon_ciu.c P src/sys/arch/mips/cavium/dev/octeon_fpa.c P src/sys/arch/mips/cavium/dev/octeon_fpavar.h P src/sys/arch/mips/cavium/dev/octeon_gmx.c P src/sys/arch/mips/cavium/dev/octeon_gmxvar.h P src/sys/arch/mips/cavium/dev/octeon_ipd.c P src/sys/arch/mips/cavium/dev/octeon_ipdvar.h P src/sys/arch/mips/cavium/dev/octeon_pci.c P src/sys/arch/mips/cavium/dev/octeon_pip.c P src/sys/arch/mips/cavium/dev/octeon_pipvar.h P src/sys/arch/mips/cavium/dev/octeon_pko.c P src/sys/arch/mips/cavium/dev/octeon_pkovar.h P src/sys/arch/mips/cavium/dev/octeon_pow.c P src/sys/arch/mips/cavium/dev/octeon_powvar.h P src/sys/arch/mips/conf/files.octeon P src/sys/dev/iscsi/iscsi_globals.h P src/sys/dev/iscsi/iscsi_ioctl.c P src/sys/dev/wsfont/spleen12x24.h P src/sys/dev/wsfont/spleen16x32.h P src/sys/dev/wsfont/spleen32x64.h P src/sys/dev/wsfont/spleen5x8.h P src/sys/dev/wsfont/spleen8x16.h P src/sys/stand/efiboot/Makefile.efiboot P src/sys/stand/efiboot/boot.c U src/sys/stand/efiboot/bootmenu.c U src/sys/stand/efiboot/bootmenu.h P src/sys/stand/efiboot/efiboot.c P src/sys/stand/efiboot/efifdt.c P src/sys/stand/efiboot/efifdt.h P src/sys/stand/efiboot/exec.c U src/sys/stand/efiboot/module.c U src/sys/stand/efiboot/module.h P src/sys/stand/efiboot/version P src/sys/stand/efiboot/bootaa64/Makefile P src/sys/stand/efiboot/bootarm/Makefile P src/tests/lib/libc/sys/t_ptrace_signal_wait.h P src/tests/lib/libc/sys/t_ptrace_wait.h P src/tests/lib/libm/Makefile P src/tests/lib/libpthread/Makefile P src/tools/installboot/Makefile P src/usr.sbin/installboot/Makefile P src/usr.sbin/installboot/installboot.h P src/usr.sbin/installboot/machines.c U src/usr.sbin/installboot/arch/evbmips.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P sys/arch/x86/x86/cpu_rng.c P usr.sbin/hdaudioctl/graph.c P usr.sbin/hdaudioctl/hdaudioctl.8 P usr.sbin/hdaudioctl/hdaudioctl.c P usr.sbin/hdaudioctl/hdaudioctl.h Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.1 P etc/MAKEDEV.awk P etc/etc.cobalt/MAKEDEV.conf P etc/rc.d/postfix P games/fortune/datfiles/fortunes P games/fortune/datfiles/netbsd-tips P lib/libnpf/libnpf.3 P lib/libnpf/npf.c P lib/libnpf/npf.h P share/misc/acronyms P share/misc/acronyms-o.real P share/misc/acronyms.comp P share/misc/bsd-family-tree P sys/arch/cobalt/conf/majors.cobalt P sys/arch/ews4800mips/stand/common/bootxx.c P sys/arch/mac68k/dev/ams.c P sys/arch/mips/include/cache_r5k.h P sys/arch/mips/mips/bus_dma.c P sys/arch/mips/mips/cache.c P sys/arch/mips/mips/cache_r5k.c P sys/arch/mips/mips/cache_r5k_subr.S P sys/arch/x86/x86/cpu_rng.c P sys/dev/acpi/acpi_ec.c P sys/dev/pckbport/synaptics.c P sys/net/npf/files.npf P sys/net/npf/npf.c P sys/net/npf/npf.h P sys/net/npf/npf_alg.c P sys/net/npf/npf_alg_icmp.c P sys/net/npf/npf_conf.c P sys/net/npf/npf_conn.c P sys/net/npf/npf_conn.h P sys/net/npf/npf_conndb.c P sys/net/npf/npf_connkey.c P sys/net/npf/npf_ctl.c P sys/net/npf/npf_ext_log.c P sys/net/npf/npf_ext_normalize.c P sys/net/npf/npf_ext_rndblock.c P sys/net/npf/npf_handler.c P sys/net/npf/npf_if.c P sys/net/npf/npf_ifaddr.c P sys/net/npf/npf_impl.h P sys/net/npf/npf_inet.c P sys/net/npf/npf_mbuf.c P sys/net/npf/npf_nat.c P sys/net/npf/npf_os.c P
Re: Automated report: NetBSD-current/i386 build failure
On 20-06-21 13:21, Andreas Gustafsson wrote: | Luke, | | You wrote: | > I think I've fixed it with 2 follow up commits in tests/lib | | There's a new error: | | http://releng.netbsd.org/b5reports/i386/2020/2020.06.21.08.02.43/build.log.tail | | -- | Andreas Gustafsson, g...@gson.org I thought I fixed that one too, but more keep creeping in. The one I haven't debugged yet is in external/gpl3/gcc. I've reverted the bsd.dep.mk change for now, so people can build. regards, Luke.
Failure in latest current build
I updated /usr/src at about 11:30 am BST on Sunday. I used build.sh -O ../obj -T ../tools -x -u distribution, with /usr/obj cleaned out before hand. The breakage happened at: dependall ===> external/bsd/atf/tests/atf/test-programs nbmake[9]: don't know how to make cpp_helpers.cc. Stop.
Re: Automated report: NetBSD-current/i386 build failure
Andreas Gustafsson wrote: > I'll change bracket to look for that and see how it works. > > > BTW if this behavior change is a problem for your automation, you can > > disable it by setting .MAKE.DIE_QUIETLY=no > > That would be counter to my principle of testing with default settings. Sure, just making sure you know of the option.
Re: Automated report: NetBSD-current/i386 build failure
Simon J. Gerraty wrote: > Simon J. Gerraty wrote: > > > It would be helpful for both human and robotic users if error messages > > > consistently included the word "error", or if there was some other easy > > > way of identifying them in the build log. > > > > The regex 'make.*stopped' is the best clue to look for since it will > > always be present. I'll change bracket to look for that and see how it works. > BTW if this behavior change is a problem for your automation, you can > disable it by setting .MAKE.DIE_QUIETLY=no That would be counter to my principle of testing with default settings. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Simon J. Gerraty wrote: > > It would be helpful for both human and robotic users if error messages > > consistently included the word "error", or if there was some other easy > > way of identifying them in the build log. > > The regex 'make.*stopped' is the best clue to look for since it will > always be present. BTW if this behavior change is a problem for your automation, you can disable it by setting .MAKE.DIE_QUIETLY=no But adapting, would allow you to afford to spew a lot of info on failure, (we output about 100 lines of info), which gets a bit unwieldy if 8-30 make instances are going to report failure in that way. eg for our freebsd builds: mk -V MAKE_PRINT_VAR_ON_ERROR .ERROR_TARGET .ERROR_META_FILE .MAKE.LEVEL MAKEFILE .MAKE.MODE _ERROR_CMD .CURDIR .MAKE .OBJDIR .TARGETS DESTDIR LD_LIBRARY_PATH MACHINE MACHINE_ARCH MAKEOBJDIRPREFIX MAKESYSPATH MAKE_VERSION PATH SRCTOP OBJTOP .MAKE.MAKEFILES and for junos (which sets .CURDIR to a relative path and builds for many different operating systems): mk -V MAKE_PRINT_VAR_ON_ERROR HOSTNAME SB_LOCATION _CURDIR .CURDIR _OBJTOP OBJTOP _OBJDIR .OBJDIR .MAKE MAKE_VERSION CVS_RELEASE_TAG LD_LIBRARY_PATH MACHINE_ARCH MACHINE TARGET_OS HOST_OBJTOP _OBJROOT .TARGETS .ERROR_TARGET .ERROR_META_FILE .MAKE.LEVEL MAKEFILE .MAKE.MODE .MAKE.MAKEFILES
Re: Automated report: NetBSD-current/i386 build failure
Andreas Gustafsson wrote: > [External Email. Be cautious of content] > > > Martin pointed me to this error some 63 lines from the end of the log: > > --- dependall-tests --- > nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop > > I think the reason I didn't find it myself is that I have developed a > habit of searching for the message "Error code 1" (or similar with I find "stopped" the key. FWIW we do all our builds in meta mode, with a .ERROR target that copies failing .meta file to a well known plase ($SB/error where SB=`realpath src/..`) if such a file exits you *know* that was the cause of failure. That only applies if a target was being built. If a makefile caused the failure, you have to look for first instance of "stopped" in the log to see why and where. In that case we also spew a lot of info via MAKE_PRINT_VAR_ON_ERROR which greatly aids triage (important with 2k developers) > another number) which used to be printed by make, but that's no longer > there. Bracket also looks for that string as part of its heuristics > for deciding how much of the build log to include in the email report, > which is why this report didn't include any of it. > > It would be helpful for both human and robotic users if error messages > consistently included the word "error", or if there was some other easy > way of identifying them in the build log. The regex 'make.*stopped' is the best clue to look for since it will always be present.
Re: Automated report: NetBSD-current/i386 build failure
Hi Andreas The failure is: --- dependall-tests --- dependall ===> tests/lib/libm --- dependall-tests --- nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop .. --- dependall-tests --- nbmake[7]: stopped in /tmp/bracket/build/2020.06.21.03.39.21-i386/src/tests/lib/libm btw the log shows no further complaint from make - due to the commit mentioned below - which is the intent. --sjg > [External Email. Be cautious of content] > > > 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: > > > > > > https://urldefense.com/v3/__http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html*2020.06.21.03.39.21__;Iw!!NEt6yMaO-gk!WoQUQ5W-Fhc9xWwXb8ps6nhL-dcqVq3jCHi05GRZo-a4s_FnLX2MQTIP6VYa1A$ > > The full build log can be found at: > > > https://urldefense.com/v3/__http://releng.netbsd.org/b5reports/i386/2020/2020.06.21.03.39.21/build.log__;!!NEt6yMaO-gk!WoQUQ5W-Fhc9xWwXb8ps6nhL-dcqVq3jCHi05GRZo-a4s_FnLX2MQTJXvkU9_g$ > > 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, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Thanks for the heads up. I think I've fixed it with 2 follow up commits in tests/lib Cheers, Luke > On 21 Jun 2020, at 19:10, Andreas Gustafsson wrote: > > Martin pointed me to this error some 63 lines from the end of the log: > > --- dependall-tests --- > nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop > > I think the reason I didn't find it myself is that I have developed a > habit of searching for the message "Error code 1" (or similar with > another number) which used to be printed by make, but that's no longer > there. Bracket also looks for that string as part of its heuristics > for deciding how much of the build log to include in the email report, > which is why this report didn't include any of it. > > It would be helpful for both human and robotic users if error messages > consistently included the word "error", or if there was some other easy > way of identifying them in the build log. > -- > Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
On Sun, Jun 21, 2020 at 12:00:41PM +0300, Andreas Gustafsson wrote: > Martin pointed me to this error some 63 lines from the end of the log: > > --- dependall-tests --- > nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop > > I think the reason I didn't find it myself is that I have developed a > habit of searching for the message "Error code 1" (or similar with > another number) which used to be printed by make, but that's no longer > there. I fell for this as well - I usualy search for error:|stopped in and did miss this case as well. Martin
Re: Automated report: NetBSD-current/i386 build failure
Martin pointed me to this error some 63 lines from the end of the log: --- dependall-tests --- nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop I think the reason I didn't find it myself is that I have developed a habit of searching for the message "Error code 1" (or similar with another number) which used to be printed by make, but that's no longer there. Bracket also looks for that string as part of its heuristics for deciding how much of the build log to include in the email report, which is why this report didn't include any of it. It would be helpful for both human and robotic users if error messages consistently included the word "error", or if there was some other easy way of identifying them in the build log. -- Andreas Gustafsson, g...@gson.org
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: > > > 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, g...@gson.org
Automated report: NetBSD-current/i386 build failure
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
