> http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/cpp-hocon.log > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/glog.log > http://build-failures.rhaalovely.net/sparc64/2020-06-04/multimedia/libmatroska.log
"ninja: error: manifest 'build.ninja' still dirty after 100 tries" I am glad I'm not the only one running into this. Your clocks are probably not close enough on the build machines. ntpd isn't helping me with this, clocks are close enough that it tries to skew them, even with "trusted". I am currently running rdate -n on all my build machines immediately before starting a build but it's too early to know if that's really going to help. I had been thinking that maybe the machines swapping is resulting in clocks getting out of whack. Not sure if that's the case but I can't think of another explanation (and the i386 boxes are heavily bogged down at times to the extent that BREAK isn't processed). > http://build-failures.rhaalovely.net/sparc64/2020-06-04/x11/p5-Tk-ProgressBar-Mac.log "Makefile out-of-date with respect to /usr/local/libdata/perl5/site_perl/sparc64-openbsd/Tk/Config.pm" same. The actual problem is that a dep is built on one member of the cluster with a clock that is in-time, then it's installed on a machine with a clock that is running slow and some build infrastructure complains. autoconf/make doesn't usually care about times of installed files. it happens rarely with perl things, and all the damn time with cmake+ninja. > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/libidn2.log this is the thing I run into sometimes, /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a(c-ctype.o): In function `c_isalnum': c-ctype.c:(.text+0x0): multiple definition of `c_isalnum' /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a(c-ctype.o):c-ctype.c:(.text+0x0): first defined here /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a(c-ctype.o): In function `c_isalpha': c-ctype.c:(.text+0x60): multiple definition of `c_isalpha' > http://build-failures.rhaalovely.net/sparc64/2020-06-04/benchmarks/hyperfine.log > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/snare.log rust > http://build-failures.rhaalovely.net/sparc64/2020-06-04/games/wrath.log was broken on !x86, I've fixed it > http://build-failures.rhaalovely.net/sparc64/2020-06-04/lang/hashlink.log src/hl.h:247:9: error: unknown type name 'char16_t' broken on sparc64 I guess
