Re: Automated report: NetBSD-current/i386 build failure
Date:Mon, 13 Mar 2023 19:40:18 + (UTC) From:NetBSD Test Fixture Message-ID: <167873641838.21770.3334724647239982...@babylon5.netbsd.org> | 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 2023.03.13.18.26.32. This should be fixed now, though I suspect we should also have a minor version bump on libm to go with these changes (I'll leave that for someone else to decide, and do if appropriate, and fix up the set lists if so). Please check that the order/place to the entries added to src/lib/libm/src/namespace.h makes sense - I was unable to work out the reasoning behind a lot of it. (Not that it matters, it is all just a bunch of #define lines, for distinct names). | An extract from the build.sh output follows: Deleted here, as that was almost irrelevant - did not show the real problem. kre
Re: Automated report: NetBSD-current/i386 build failure
Date:Sat, 7 Jan 2023 20:41:01 + (UTC) From:NetBSD Test Fixture Message-ID: <167312406178.23291.2878684022518773...@babylon5.netbsd.org> | The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, | using sources from CVS date 2023.01.07.19.41.30. This i386 build failure was fixed by: cvs rdiff -u -r1.56 -r1.57 src/sbin/fsck_ffs/pass5.c cvs rdiff -u -r1.105 -r1.106 src/sbin/fsck_ffs/setup.c by chs@ but b5 seems to have confused itself, and doesn't seem to have sent the normal "is working again" message, perhaps because it sent that other one, while the build was still broken due to this one. kre
Re: Automated report: NetBSD-current/i386 build failure
Date:Sun, 30 Oct 2022 02:23:22 + (UTC) From:NetBSD Test Fixture Message-ID: <166709660251.4897.4957055195986461...@babylon5.netbsd.org> | An extract from the build.sh output follows: | | ./usr/share/zoneinfo/America/Rainy_River | ./usr/share/zoneinfo/America/Thunder_Bay | ./usr/share/zoneinfo/Asia/Istanbul | ./usr/share/zoneinfo/Etc/GMT+0 | ./usr/share/zoneinfo/Etc/GMT-0 | ./usr/share/zoneinfo/Etc/GMT0 | ./usr/share/zoneinfo/Etc/Greenwich | ./usr/share/zoneinfo/Etc/Universal | ./usr/share/zoneinfo/Etc/Zulu | end of 10 missing files == Sorry everyone, that was my fault - I do do test builds, but to save time, I use -u, and those files were already there from a previous build, so I didn't notice that they had gone missing. I am still planning on properly automating the test for this (I have code that does it already that I use when testing pullup requests) but the tz updates have been very close together recently (the world seems to be in one of its periods of insane "we're changing/abandoning the summer time rules, and the changes take effect next week" periods that happen from time to time. I think this instance of this problem should be fixed now. kre
Re: Automated report: NetBSD-current/i386 build failure
The build is still failing, now with: --- release-bootcd-com --- Copying set gpufw pax: line 206: ./libdata/firmware/nouveau/nvidia/gp107/gr/fecs_bl.bin: type mismatch: specfile link, tree file This is from: http://releng.netbsd.org/b5reports/i386/2021/2021.12.14.16.55.45/build.log.tail -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Hi maya,
The build is still failing with:
> ./libdata/firmware/nouveau/nvidia/LICENCE.nvidia
> ./libdata/firmware/nouveau/nvidia/gm206/fecs_data.bin
> ./libdata/firmware/nouveau/nvidia/gm206/fecs_inst.bin
> ./libdata/firmware/nouveau/nvidia/gm206/gpccs_data.bin
> ./libdata/firmware/nouveau/nvidia/gm206/gpccs_inst.bin
> = end of 5 extra files ===
> *** Failed target: checkflist
> *** Failed commands:
> ${SETSCMD} ${.CURDIR}/checkflist ${MAKEFLIST_FLAGS}
> ${CHECKFLIST_FLAGS} ${METALOG.unpriv}
> *** [checkflist] Error code 1
> nbmake[2]: stopped in /tmp/build/2021.09.25.21.26.04-i386/src/distrib/sets
> 1 error
> nbmake[2]: stopped in /tmp/build/2021.09.25.21.26.04-i386/src/distrib/sets
> nbmake[1]: stopped in /tmp/build/2021.09.25.21.26.04-i386/src
> nbmake: stopped in /tmp/build/2021.09.25.21.26.04-i386/src
> ERROR: Failed to make release
since this commit:
> 2021.09.25.21.26.03 maya
> src/distrib/common/bootimage/Makefile.installimage,v 1.10
> 2021.09.25.21.26.03 maya src/distrib/sets/sets.subr,v 1.197
> 2021.09.25.21.26.04 maya src/distrib/sets/lists/gpufw/mi,v 1.3
--
Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Yesterday, the NetBSD Test Fixture wrote: > nbmake[3]: stopped in /tmp/build/2021.08.17.17.31.59-i386/src > nbmake[2]: stopped in /tmp/build/2021.08.17.17.31.59-i386/src > nbmake[1]: stopped in /tmp/build/2021.08.17.17.31.59-i386/src > nbmake: stopped in /tmp/build/2021.08.17.17.31.59-i386/src > ERROR: Failed to make release kre@ fixed this particular error, but the build is still failing on i386 and other 32-bit platforms, now with different errors such as these: --- dependall-sodium --- In file included from /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/include/sodium/private/ed25519_ref10_fe_51.h:3, from /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/include/sodium/private/ed25519_ref10.h:23, from /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/crypto_scalarmult/curve25519/ref10/x25519_ref10.c:7: /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/include/sodium/private/common.h:14:1: error: unable to emulate 'TI' 14 | typedef unsigned uint128_t __attribute__((mode(TI))); | ^~~ In file included from /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/include/sodium/private/ed25519_ref10.h:23, from /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/crypto_scalarmult/curve25519/ref10/x25519_ref10.c:7: /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/include/sodium/private/ed25519_ref10_fe_51.h: In function 'fe25519_mul': /tmp/build/2021.08.17.22.29.11-i386/src/sys/external/isc/libsodium/dist/src/libsodium/include/sodium/private/ed25519_ref10_fe_51.h:300:17: error: right shift count >= width of type [-Werror=shift-count-overflow] 300 | carry = r0 >> 51; | ^~ This is from: http://releng.netbsd.org/b5reports/i386/2021/2021.08.17.22.29.11/build.log.tail -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
On Sun, Jul 25, 2021 at 11:51:57PM +, Thomas Mueller wrote: ... > Or should I try with hg? I have devel/mercurial built and installed. > > Now to find a tutorial for Mercurial for git users: There was one, but I can > no longer find it. ... There's a related resource which isn't a tutorial per se, but... hg has some basic help built in to it for seasoned git users. This is probably also covered in that tutorial you're talking about, but where the tutorial is--I don't remember either. The git help has to be enabled in an hgrc file[*] before it can be accessed, e.g.: # mkdir -p /etc/mercurial/hgrc.d # echo '[extensions]' > /etc/mercurial/hgrc.d/githelp.rc # echo 'githelp='>> /etc/mercurial/hgrc.d/githelp.rc Then you can inquire how a particular git operation might be invoked for one of your hg repos instead. For one of mine: # cd # hg githelp init hg init # hg githelp fetch hg pull # hg githelp pull hg pull --rebase # hg githelp status hg status I don't know enough to vouch for how conservative the githelp recommendations are, though; so, extra caution (supplemental backups; only working on clones/test-copies of your repos; etc) with any trial-and-error stuff you want to do might be a good idea--at least until you've gotten the hang of it, or gotten more info from the experts. Best, -Dave [*] for more info on that: "hg help extensions"
Re: Automated report: NetBSD-current/i386 build failure
On Thu, Jul 22, 2021 at 10:32:37AM +0200, Reinoud Zandijk wrote: > > > it looks like CVS randomly didn't commit some of my changes, > > > investigating... > > > > Yeah, not sure what happened; something caused it to, apparently, > > think a few of the files in the second changeset still had the > > original checkout timestamps. This makes it completely blind to any > > changes in them (even if you run cvs diff explicitly) until you touch > > the files. > > [...] > > Why would other version systems not suffer from this same issue > when the date stamps are somehow wrong? Because they're more careful. e.g.: % touch -r file ref % echo 'more' >> file % touch -r ref file % hg status M file ? ref % -- David A. Holland dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
> On Mon, Jul 19, 2021 at 01:28:06AM +, David Holland wrote: > > that is... less than helpful :-( > > it looks like CVS randomly didn't commit some of my changes, > > investigating... > Yeah, not sure what happened; something caused it to, apparently, > think a few of the files in the second changeset still had the > original checkout timestamps. This makes it completely blind to any > changes in them (even if you run cvs diff explicitly) until you touch > the files. > Not sure how this happened. The affected files were all ones also > committed in the first changeset, which is probably not an accident, > but it wasn't all those files, just an arbitrary subset of them. > Doesn't make much sense. > High time we moved away from CVS. > Anyway, I am pretty sure I've found all the offending files and > committed them for real. If anything's still bust, holler... > On Mon, Jul 19, 2021 at 10:32:20AM +0900, Rin Okuyama wrote: > > Logs below are usually more helpful. > Right... I wonder what happened to bracket's error-matching script; it > usually does better than that. > David A. Holland > dholl...@netbsd.org I too would like to move away from CVS. What is happening on the switch to Mercurial? Last night, I was hit by a bug for the second time on NetBSD-9.99.82 amd64, when running cvs up -dP -A from /usr/src I was running in a root window in Xorg (native) with icewm 1.4.2. cvs download stopped, keyboard was not recognized though the mouse pointer could move, though clicks had no effect. I later found a message in the Xorg log file about GPU hang: only the second time this has happened, and only when running cvs up -dP -A from /usr/src in NetBSD 9.99.82 Not sure if GPU hang is a hardware problem or a software problem. Strangely, I could read the /home partition by NFS from the other computer. I had to hit the Reset button. On the second time, last night, part of the src tree was messed up, with messages about invalid CVS root in some package subdiretories, looked to be within external/bsd I ran rm -Rf external/bsd, then again cvs up -dP -A, but was stopped in src/external by a broken pipe from the server. So the src tree is partly messed up, and I don't know what to do. I could try again from non-X console, or possibly from root xterm with a quick switch to another window. Or should I try with hg? I have devel/mercurial built and installed. Now to find a tutorial for Mercurial for git users: There was one, but I can no longer find it. Tom
Re: Automated report: NetBSD-current/i386 build failure
On Monday, David Holland wrote: > Right... I wonder what happened to bracket's error-matching script; it > usually does better than that. I have now deployed bracket 2.15 on babylon5.netbsd.org, and the latest build failure report looks much better: http://mail-index.netbsd.org/current-users/2021/07/24/msg041311.html -- Andreas Gustafsson, g...@gson.org
make(1) enhancements (was Re: Automated report: NetBSD-current/i386 build failure)
On Mon, Jul 19, 2021 at 08:13:19AM +0300, Andreas Gustafsson wrote: > David Holland wrote: > > On Mon, Jul 19, 2021 at 10:32:20AM +0900, Rin Okuyama wrote: > > > Logs below are usually more helpful. > > > > Right... I wonder what happened to bracket's error-matching script; it > > usually does better than that. > > There are multiple causes, but a major one is that since babylon5 was > upgraded to a new server with more cores, the builds have more > parallelism, which causes make(1) to print more output from the other > parallel jobs after the actual error message, and bracket isn't > looking far enough back in the log. I have a fix in testing on my own > testbed but still need to deploy it on babylon5. I think I've expressed this idea before, but can't we enhance our make(1) to record all printouts for each make target? It could discard the logs of the targets that succeeded and print the one(s) that failed out on reporting the complation error? Then at least all the output of the failed targets are collected and readable. If this was already shot down once before, please ignore it. I'm not that familiar with the make(1) internals. Reinoud signature.asc Description: PGP signature
Re: Automated report: NetBSD-current/i386 build failure
David Holland wrote: > On Mon, Jul 19, 2021 at 10:32:20AM +0900, Rin Okuyama wrote: > > Logs below are usually more helpful. > > Right... I wonder what happened to bracket's error-matching script; it > usually does better than that. There are multiple causes, but a major one is that since babylon5 was upgraded to a new server with more cores, the builds have more parallelism, which causes make(1) to print more output from the other parallel jobs after the actual error message, and bracket isn't looking far enough back in the log. I have a fix in testing on my own testbed but still need to deploy it on babylon5. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
On 2021/07/19 10:28, David Holland wrote: that is... less than helpful :-( it looks like CVS randomly didn't commit some of my changes, investigating... Logs below are usually more helpful. On 2021/07/19 9:42, NetBSD Test Fixture wrote: Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.07.html#2021.07.18.23.57.34 Thanks, rin
Re: Automated report: NetBSD-current/i386 build failure
On Mon, Jul 19, 2021 at 12:42:49AM +, 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 2021.07.18.23.57.34.
>
> An extract from the build.sh output follows:
>
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U11}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U11}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U111}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U111}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/install-/}
> *** [build_install] Error code 1
> nbmake[4]: stopped in /tmp/build/2021.07.18.23.57.34-i386/src/lib
> 1 error
that is... less than helpful :-(
it looks like CVS randomly didn't commit some of my changes,
investigating...
--
David A. Holland
dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
In article <24751.41935.824926.178...@guava.gson.org>, Andreas Gustafsson wrote: >The i386 build is still failing, but now with a different error: > > --- in6_pcb.o --- > /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In >function 'in6_pcblookup_port': > cc1: error: function may return address of local variable >[-Werror=return-local-addr] > >/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: >note: declared here > 1056 | struct vestigial_inpcb better; >| ^~ > >It's not clear to me which of the commits made since christos first >broke the build could have triggered this, nor why this is not >affecting all ports. Fixed in: cvs commit bsd.own.mk /cvsroot/src/share/mk/bsd.own.mk,v <-- bsd.own.mk new revision: 1.1251; previous revision: 1.1250 christos
Re: Automated report: NetBSD-current/i386 build failure
In article , Christos Zoulas wrote: >In article <24751.41935.824926.178...@guava.gson.org>, >Andreas Gustafsson wrote: >>The i386 build is still failing, but now with a different error: >> >> --- in6_pcb.o --- >> /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In >>function 'in6_pcblookup_port': >> cc1: error: function may return address of local variable >>[-Werror=return-local-addr] >> >>/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: >>note: declared here >> 1056 | struct vestigial_inpcb better; >>| ^~ >> >>It's not clear to me which of the commits made since christos first >>broke the build could have triggered this, nor why this is not >>affecting all ports. > >That code is tricky and the compiler usage analysis might not be figuring >out that this can't happen. When I last looked at it, I considered simplifying >it so that it is obvious that this can't happen. I think that did it :-) Modified Files: src/external/gpl3/gcc: README.gcc10 src/share/mk: bsd.own.mk Log Message: switch mips* and i386 to GCC 10. I guess I'll have to simplify it for real now :-) christos
Re: Automated report: NetBSD-current/i386 build failure
In article <24751.41935.824926.178...@guava.gson.org>, Andreas Gustafsson wrote: >The i386 build is still failing, but now with a different error: > > --- in6_pcb.o --- > /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In >function 'in6_pcblookup_port': > cc1: error: function may return address of local variable >[-Werror=return-local-addr] > >/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: >note: declared here > 1056 | struct vestigial_inpcb better; >| ^~ > >It's not clear to me which of the commits made since christos first >broke the build could have triggered this, nor why this is not >affecting all ports. That code is tricky and the compiler usage analysis might not be figuring out that this can't happen. When I last looked at it, I considered simplifying it so that it is obvious that this can't happen. christos
Re: Automated report: NetBSD-current/i386 build failure
The i386 build is still failing, but now with a different error: --- in6_pcb.o --- /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In function 'in6_pcblookup_port': cc1: error: function may return address of local variable [-Werror=return-local-addr] /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c:1056:26: note: declared here 1056 | struct vestigial_inpcb better; | ^~ It's not clear to me which of the commits made since christos first broke the build could have triggered this, nor why this is not affecting all ports. Logs: http://releng.netbsd.org/b5reports/i386/commits-2021.05.html#2021.05.27.08.41.35 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Fixed...
christos
> On Apr 18, 2021, at 9:39 AM, Andreas Gustafsson wrote:
>
> The i386 build is still failing, with errors like these:
>
> --- dependall-tmux ---
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:
> In function 'cmd_display_menu_get_position':
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:158:8:
> error: comparison of integer expressions of different signedness: 'long int'
> and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
>158 | if (n >= tty->sy)
>|^~
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:191:8:
> error: comparison of integer expressions of different signedness: 'long int'
> and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
>191 | if (n >= tty->sy)
>|^~
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:239:8:
> error: comparison of integer expressions of different signedness: 'long int'
> and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
>239 | if (n < h)
>|^
>
> --
> Andreas Gustafsson, g...@gson.org
signature.asc
Description: Message signed with OpenPGP
Re: Automated report: NetBSD-current/i386 build failure
The i386 build is still failing, with errors like these:
--- dependall-tmux ---
/tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:
In function 'cmd_display_menu_get_position':
/tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:158:8:
error: comparison of integer expressions of different signedness: 'long int'
and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
158 | if (n >= tty->sy)
|^~
/tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:191:8:
error: comparison of integer expressions of different signedness: 'long int'
and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
191 | if (n >= tty->sy)
|^~
/tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:239:8:
error: comparison of integer expressions of different signedness: 'long int'
and 'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
239 | if (n < h)
|^
--
Andreas Gustafsson, g...@gson.org
Re: 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 2021.04.06.20.13.43. ... > *** Failed target: dependall-../external/bsd/elftoolchain ... > The following commits were made between the last successful build and > the failed build: > > 2021.04.06.19.44.24 jkoshy src/external/bsd/elftoolchain/Makefile,v 1.2 > 2021.04.06.20.13.43 jkoshy src/lib/Makefile,v 1.288 Revision 1.288 of src/lib/Makefile seems the culprit, and has been reverted. Apologies for the noise. Regards, Joseph Koshy
Re: Automated report: NetBSD-current/i386 build failure
Date:Sun, 14 Feb 2021 21:40:21 + (UTC) From:NetBSD Test Fixture Message-ID: <161333882137.19912.5576154194224308...@babylon5.netbsd.org> | 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 2021.02.14.20.58.35. knakahara@ fixed that one, and I have (I hope) fixed the next revealed build failure from the same set of commits. We'll see if there are still more to come. kre
Re: Automated report: NetBSD-current/i386 build failure
Hi, Roy Marples writes: > On 03/02/2021 17:55, Ryo ONODERA wrote: >> Exactly. It happens in dtrace userland build. > > Fixed. Sorry about that. > > Maybe we should not define CTASSERT ourselves and just use __CTASSERT to > avoid > this in the future? Thank you. I have no idea what is the best way to avoid conflicts in the future... > Roy -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: Automated report: NetBSD-current/i386 build failure
On 03/02/2021 17:55, Ryo ONODERA wrote: Exactly. It happens in dtrace userland build. Fixed. Sorry about that. Maybe we should not define CTASSERT ourselves and just use __CTASSERT to avoid this in the future? Roy
Re: Automated report: NetBSD-current/i386 build failure
Hi, Martin Husemann writes: > On Wed, Feb 03, 2021 at 05:31:11PM +, Roy Marples wrote: >> I cannot replicate this? >> I'm just building a stock kernel - what extra options do I need? > > It happens in the userland build. Exactly. It happens in dtrace userland build. > Martin -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: Automated report: NetBSD-current/i386 build failure
On Wed, Feb 03, 2021 at 05:31:11PM +, Roy Marples wrote: > I cannot replicate this? > I'm just building a stock kernel - what extra options do I need? It happens in the userland build. Martin
Re: Automated report: NetBSD-current/i386 build failure
On 03/02/2021 14:42, Ryo ONODERA wrote: Hi, It seems that CTASSERT in netinet/in.h conflicts with CTASSERT in external/cddl/osnet/dist/uts/common/sys/debug.h. Ryo ONODERA writes: Hi, However I have gotten another failure: --- dt_print.pico --- In file included from /usr/src/external/cddl/osnet/sys/sys/debug.h:51, from /usr/src/external/cddl/osnet/sys/sys/uio.h:64, from /usr/world/9.99/amd64/dest/usr/include/sys/socket.h:99, from /us r/src/external/cddl/osnet/lib/libdtrace/../../dist/lib/ libdtrace/common/dt_print.c:76: /usr/world/9.99/amd64/dest/usr/include/netinet/in.h:162:1: error: macro "__CTASS ERT" passed 2 arguments, but takes just 1 162 | CTASSERT(sizeof(struct in_addr) == 4); | ^~~~ I cannot replicate this? I'm just building a stock kernel - what extra options do I need? Roy
Re: Automated report: NetBSD-current/i386 build failure
Hi,
It seems that CTASSERT in netinet/in.h conflicts with
CTASSERT in external/cddl/osnet/dist/uts/common/sys/debug.h.
Ryo ONODERA writes:
> Hi,
>
> However I have gotten another failure:
>
> --- dt_print.pico ---
> In file included from /usr/src/external/cddl/osnet/sys/sys/debug.h:51,
> from /usr/src/external/cddl/osnet/sys/sys/uio.h:64,
> from /usr/world/9.99/amd64/dest/usr/include/sys/socket.h:99,
> from
> /usr/src/external/cddl/osnet/lib/libdtrace/../../dist/lib/
> libdtrace/common/dt_print.c:76:
> /usr/world/9.99/amd64/dest/usr/include/netinet/in.h:162:1: error: macro
> "__CTASS
> ERT" passed 2 arguments, but takes just 1
> 162 | CTASSERT(sizeof(struct in_addr) == 4);
> | ^~~~
>
> Ryo ONODERA writes:
>
>> Hi,
>>
>> NetBSD Test Fixture writes:
>>
>>> 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 2021.02.03.12.11.34.
>>>
>>> An extract from the build.sh output follows:
>>>
>>> *** Failed target: dependall-../external/bsd/am-utils/lib
>>> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
>>> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
>>> this="lib/"; real="/tmp/build/2021.02.03.12.11.34-i386/src/lib" ;; *)
>>> this="lib/${dir}/";
>>> real="/tmp/build/2021.02.03.12.11.34-i386/src/lib/${dir}" ;; esac;
>>> show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
>>> "${real}" && /tmp/build/2021.02.03.12.11.34-i386/tools/bin/nbmake
>>> _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget
>>> ../external/bsd/am-utils/lib dependall
>>> *** Error code 2
>>> Stop.
>>> nbmake[5]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
>>> *** [build_install] Error code 1
>>> nbmake[4]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
>>> 1 error
>>> nbmake[4]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
>>> nbmake[3]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>>> nbmake[2]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>>> nbmake[1]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>>> nbmake: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>>> ERROR: Failed to make release
>>>
>>> The following commits were made between the last successful build and
>>> the failed build:
>>>
>>> 2021.02.03.11.52.23 roy src/sys/netinet/tcp_debug.h,v 1.20
>>> 2021.02.03.11.53.43 roy src/sys/net/if_arp.h,v 1.36
>>> 2021.02.03.11.53.43 roy src/sys/net/if_ether.h,v 1.83
>>> 2021.02.03.11.53.43 roy src/sys/net/if_gre.h,v 1.46
>>> 2021.02.03.11.53.43 roy src/sys/netinet/if_ether.h,v 1.36
>>> 2021.02.03.11.53.43 roy src/sys/netinet/igmp.h,v 1.14
>>> 2021.02.03.11.53.43 roy src/sys/netinet/in.h,v 1.113
>>> 2021.02.03.11.53.43 roy src/sys/netinet/ip.h,v 1.37
>>> 2021.02.03.11.53.43 roy src/sys/netinet/ip6.h,v 1.28
>>> 2021.02.03.11.53.43 roy src/sys/netinet/ip_icmp.h,v 1.42
>>> 2021.02.03.11.53.43 roy src/sys/netinet/ip_mroute.h,v 1.34
>>> 2021.02.03.11.53.43 roy src/sys/netinet/ip_var.h,v 1.132
>>> 2021.02.03.11.53.43 roy src/sys/netinet/tcp.h,v 1.36
>>> 2021.02.03.11.53.43 roy src/sys/netinet/tcp_var.h,v 1.194
>>> 2021.02.03.11.53.43 roy src/sys/netinet/udp.h,v 1.18
>>> 2021.02.03.11.53.43 roy src/sys/netinet/udp_var.h,v 1.48
>>> 2021.02.03.12.11.34 roy src/sys/net/if_llc.h,v 1.22
>>>
>>> Logs can be found at:
>>>
>>>
>>> http://releng.NetBSD.org/b5reports/i386/commits-2021.02.html#2021.02.03.12.11.34
>>
>> if_ether.h has no #ifdef CTASSERT ... #endif.
>> The other file has this guard.
>> I think the following patch will work.
>>
>> Index: sys/netinet/if_ether.h
>> ===
>> RCS file: /cvsroot/src/sys/netinet/if_ether.h,v
>> retrieving revision 1.36
>> diff -u -r1.36 if_ether.h
>> --- sys/netinet/if_ether.h 3 Feb 2021 11:53:43 - 1.36
>> +++ sys/netinet/if_ether.h 3 Feb 2021 13:47:16 -
>> @@ -76,7 +76,9 @@
>> u_int8_t arp_tha[ETHER_ADDR_LEN]; /* target hardware address */
>> u_int8_t arp_tpa[4];/* target protocol address */
>> };
>> +#ifdef CTASSERT
>> CTASSERT(sizeof(struct ether_arp) == 28);
>> +#endif
>> #define arp_hrd ea_hdr.ar_hrd
>> #define arp_pro ea_hdr.ar_pro
>> #define arp_hln ea_hdr.ar_hln
>>
>>
>> --
>> Ryo ONODERA // r...@tetera.org
>> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
>
> --
> Ryo ONODERA // r...@tetera.org
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: Automated report: NetBSD-current/i386 build failure
Hi,
However I have gotten another failure:
--- dt_print.pico ---
In file included from /usr/src/external/cddl/osnet/sys/sys/debug.h:51,
from /usr/src/external/cddl/osnet/sys/sys/uio.h:64,
from /usr/world/9.99/amd64/dest/usr/include/sys/socket.h:99,
from /usr/src/external/cddl/osnet/lib/libdtrace/../../dist/lib/
libdtrace/common/dt_print.c:76:
/usr/world/9.99/amd64/dest/usr/include/netinet/in.h:162:1: error: macro "__CTASS
ERT" passed 2 arguments, but takes just 1
162 | CTASSERT(sizeof(struct in_addr) == 4);
| ^~~~
Ryo ONODERA writes:
> Hi,
>
> NetBSD Test Fixture writes:
>
>> 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 2021.02.03.12.11.34.
>>
>> An extract from the build.sh output follows:
>>
>> *** Failed target: dependall-../external/bsd/am-utils/lib
>> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
>> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="lib/";
>> real="/tmp/build/2021.02.03.12.11.34-i386/src/lib" ;; *) this="lib/${dir}/";
>> real="/tmp/build/2021.02.03.12.11.34-i386/src/lib/${dir}" ;; esac;
>> show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
>> "${real}" && /tmp/build/2021.02.03.12.11.34-i386/tools/bin/nbmake
>> _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget
>> ../external/bsd/am-utils/lib dependall
>> *** Error code 2
>> Stop.
>> nbmake[5]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
>> *** [build_install] Error code 1
>> nbmake[4]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
>> 1 error
>> nbmake[4]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
>> nbmake[3]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>> nbmake[2]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>> nbmake[1]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>> nbmake: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
>> ERROR: Failed to make release
>>
>> The following commits were made between the last successful build and
>> the failed build:
>>
>> 2021.02.03.11.52.23 roy src/sys/netinet/tcp_debug.h,v 1.20
>> 2021.02.03.11.53.43 roy src/sys/net/if_arp.h,v 1.36
>> 2021.02.03.11.53.43 roy src/sys/net/if_ether.h,v 1.83
>> 2021.02.03.11.53.43 roy src/sys/net/if_gre.h,v 1.46
>> 2021.02.03.11.53.43 roy src/sys/netinet/if_ether.h,v 1.36
>> 2021.02.03.11.53.43 roy src/sys/netinet/igmp.h,v 1.14
>> 2021.02.03.11.53.43 roy src/sys/netinet/in.h,v 1.113
>> 2021.02.03.11.53.43 roy src/sys/netinet/ip.h,v 1.37
>> 2021.02.03.11.53.43 roy src/sys/netinet/ip6.h,v 1.28
>> 2021.02.03.11.53.43 roy src/sys/netinet/ip_icmp.h,v 1.42
>> 2021.02.03.11.53.43 roy src/sys/netinet/ip_mroute.h,v 1.34
>> 2021.02.03.11.53.43 roy src/sys/netinet/ip_var.h,v 1.132
>> 2021.02.03.11.53.43 roy src/sys/netinet/tcp.h,v 1.36
>> 2021.02.03.11.53.43 roy src/sys/netinet/tcp_var.h,v 1.194
>> 2021.02.03.11.53.43 roy src/sys/netinet/udp.h,v 1.18
>> 2021.02.03.11.53.43 roy src/sys/netinet/udp_var.h,v 1.48
>> 2021.02.03.12.11.34 roy src/sys/net/if_llc.h,v 1.22
>>
>> Logs can be found at:
>>
>>
>> http://releng.NetBSD.org/b5reports/i386/commits-2021.02.html#2021.02.03.12.11.34
>
> if_ether.h has no #ifdef CTASSERT ... #endif.
> The other file has this guard.
> I think the following patch will work.
>
> Index: sys/netinet/if_ether.h
> ===
> RCS file: /cvsroot/src/sys/netinet/if_ether.h,v
> retrieving revision 1.36
> diff -u -r1.36 if_ether.h
> --- sys/netinet/if_ether.h3 Feb 2021 11:53:43 - 1.36
> +++ sys/netinet/if_ether.h3 Feb 2021 13:47:16 -
> @@ -76,7 +76,9 @@
> u_int8_t arp_tha[ETHER_ADDR_LEN]; /* target hardware address */
> u_int8_t arp_tpa[4];/* target protocol address */
> };
> +#ifdef CTASSERT
> CTASSERT(sizeof(struct ether_arp) == 28);
> +#endif
> #define arp_hrd ea_hdr.ar_hrd
> #define arp_pro ea_hdr.ar_pro
> #define arp_hln ea_hdr.ar_hln
>
>
> --
> Ryo ONODERA // r...@tetera.org
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: Automated report: NetBSD-current/i386 build failure
Hi,
NetBSD Test Fixture writes:
> 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 2021.02.03.12.11.34.
>
> An extract from the build.sh output follows:
>
> *** Failed target: dependall-../external/bsd/am-utils/lib
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="lib/";
> real="/tmp/build/2021.02.03.12.11.34-i386/src/lib" ;; *) this="lib/${dir}/";
> real="/tmp/build/2021.02.03.12.11.34-i386/src/lib/${dir}" ;; esac;
> show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
> "${real}" && /tmp/build/2021.02.03.12.11.34-i386/tools/bin/nbmake
> _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget
> ../external/bsd/am-utils/lib dependall
> *** Error code 2
> Stop.
> nbmake[5]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
> *** [build_install] Error code 1
> nbmake[4]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
> 1 error
> nbmake[4]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src/lib
> nbmake[3]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
> nbmake[2]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
> nbmake[1]: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
> nbmake: stopped in /tmp/build/2021.02.03.12.11.34-i386/src
> ERROR: Failed to make release
>
> The following commits were made between the last successful build and
> the failed build:
>
> 2021.02.03.11.52.23 roy src/sys/netinet/tcp_debug.h,v 1.20
> 2021.02.03.11.53.43 roy src/sys/net/if_arp.h,v 1.36
> 2021.02.03.11.53.43 roy src/sys/net/if_ether.h,v 1.83
> 2021.02.03.11.53.43 roy src/sys/net/if_gre.h,v 1.46
> 2021.02.03.11.53.43 roy src/sys/netinet/if_ether.h,v 1.36
> 2021.02.03.11.53.43 roy src/sys/netinet/igmp.h,v 1.14
> 2021.02.03.11.53.43 roy src/sys/netinet/in.h,v 1.113
> 2021.02.03.11.53.43 roy src/sys/netinet/ip.h,v 1.37
> 2021.02.03.11.53.43 roy src/sys/netinet/ip6.h,v 1.28
> 2021.02.03.11.53.43 roy src/sys/netinet/ip_icmp.h,v 1.42
> 2021.02.03.11.53.43 roy src/sys/netinet/ip_mroute.h,v 1.34
> 2021.02.03.11.53.43 roy src/sys/netinet/ip_var.h,v 1.132
> 2021.02.03.11.53.43 roy src/sys/netinet/tcp.h,v 1.36
> 2021.02.03.11.53.43 roy src/sys/netinet/tcp_var.h,v 1.194
> 2021.02.03.11.53.43 roy src/sys/netinet/udp.h,v 1.18
> 2021.02.03.11.53.43 roy src/sys/netinet/udp_var.h,v 1.48
> 2021.02.03.12.11.34 roy src/sys/net/if_llc.h,v 1.22
>
> Logs can be found at:
>
>
> http://releng.NetBSD.org/b5reports/i386/commits-2021.02.html#2021.02.03.12.11.34
if_ether.h has no #ifdef CTASSERT ... #endif.
The other file has this guard.
I think the following patch will work.
Index: sys/netinet/if_ether.h
===
RCS file: /cvsroot/src/sys/netinet/if_ether.h,v
retrieving revision 1.36
diff -u -r1.36 if_ether.h
--- sys/netinet/if_ether.h 3 Feb 2021 11:53:43 - 1.36
+++ sys/netinet/if_ether.h 3 Feb 2021 13:47:16 -
@@ -76,7 +76,9 @@
u_int8_t arp_tha[ETHER_ADDR_LEN]; /* target hardware address */
u_int8_t arp_tpa[4];/* target protocol address */
};
+#ifdef CTASSERT
CTASSERT(sizeof(struct ether_arp) == 28);
+#endif
#definearp_hrd ea_hdr.ar_hrd
#definearp_pro ea_hdr.ar_pro
#definearp_hln ea_hdr.ar_hln
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: Automated report: NetBSD-current/i386 build failure
On Sun, Jan 24, 2021 at 12:10:46PM -0800, Jason Thorpe wrote: > > > On Jan 24, 2021, at 11:31 AM, Robert Elz wrote: > > > > /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld: > > /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so: undefined > > reference to `rumpns_strlist_match' > > /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld: > > /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so: undefined > > reference to `rumpns_strlist_pmatch' > > collect2: error: ld returned 1 exit status > > If would be nice if rump weren?t so bloody fragile. It is not rump that is fragile here, all kernel builds are failing too. You probably forgot to commit libkern/Makefile.libkern. Martin
Re: Automated report: NetBSD-current/i386 build failure
> On Jan 24, 2021, at 5:38 PM, Robert Elz wrote: > >Date:Sun, 24 Jan 2021 16:25:55 -0800 >From:Jason Thorpe >Message-ID: > > | > If would be nice if rump weren't so bloody fragile. > > It would indeed. > > | I am not able to reproduce the build failure: > > Odd, it is still failing on b5, on all of i386 amd64 and evbarm (the only > three I looked at, probably all the others as well). > > You can easily check the b5 build logs and observe this for yourself. > > Is it possible that you might have some uncommitted changes in your tree > that might be making a difference? I don't think so, but I'll double-check. -- thorpej
Re: Automated report: NetBSD-current/i386 build failure
Date:Sun, 24 Jan 2021 16:25:55 -0800 From:Jason Thorpe Message-ID: | > If would be nice if rump weren't so bloody fragile. It would indeed. | I am not able to reproduce the build failure: Odd, it is still failing on b5, on all of i386 amd64 and evbarm (the only three I looked at, probably all the others as well). You can easily check the b5 build logs and observe this for yourself. Is it possible that you might have some uncommitted changes in your tree that might be making a difference? kre
Re: Automated report: NetBSD-current/i386 build failure
> On Jan 24, 2021, at 12:10 PM, Jason Thorpe wrote: > > >> On Jan 24, 2021, at 11:31 AM, Robert Elz wrote: >> >> /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld: >> /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so: undefined >> reference to `rumpns_strlist_match' >> /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld: >> /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so: undefined >> reference to `rumpns_strlist_pmatch' >> collect2: error: ld returned 1 exit status > > If would be nice if rump weren’t so bloody fragile. I am not able to reproduce the build failure: make release started at: Sun Jan 24 12:31:50 PST 2021 make release finished at: Sun Jan 24 16:13:30 PST 2021 -- thorpej
Re: Automated report: NetBSD-current/i386 build failure
Date:Sun, 24 Jan 2021 18:45:38 + (UTC) From:NetBSD Test Fixture Message-ID: <161151393856.1140.6101421274186394...@babylon5.netbsd.org> | An extract from the build.sh output follows: The actual error lines (with intervening unrelated stuff deleted) are: # link cgd/t_cgd_3des /tmp/build/2021.01.24.17.44.16-i386/tools/bin/i486--netbsdelf-gcc --sysroot=/tmp/build/2021.01.24.17.44.16-i386/destdir -Wl,--warn-shared-textrel -Wl,-z,relro -pie -shared-libgcc -o t_cgd_3des t_cgd_3des.o -Wl,-rpath-link,/tmp/build/2021.01.24.17.44.16-i386/destdir/lib -L=/lib -lrumpdev -lrumpdev_disk -lrumpdev_cgd -lrumpkern_crypto -lrumpvfs -lrump -lrumpvfs -lrumpvfs_nofifofs -lrumpuser -lrump -lpthread -lutil-latf-c /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld: /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so: undefined reference to `rumpns_strlist_match' /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld: /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so: undefined reference to `rumpns_strlist_pmatch' collect2: error: ld returned 1 exit status *** [t_cgd_3des] Error code 1 nbmake[8]: stopped in /tmp/build/2021.01.24.17.44.16-i386/src/tests/dev/cgd 1 error nbmake[8]: stopped in /tmp/build/2021.01.24.17.44.16-i386/src/tests/dev/cgd | The following commits were made between the last successful build and | the failed build: which was subsequently narrowed to just these: | 2021.01.24.17.29.11 thorpej src/distrib/sets/lists/comp/mi,v 1.2373 | 2021.01.24.17.29.11 thorpej src/share/man/man9/Makefile,v 1.455 | 2021.01.24.17.29.11 thorpej src/share/man/man9/kmem.9,v 1.27 | 2021.01.24.17.29.11 thorpej src/sys/kern/subr_kmem.c,v 1.81 | 2021.01.24.17.29.11 thorpej src/sys/sys/kmem.h,v 1.12 | 2021.01.24.17.42.36 thorpej src/sys/kern/subr_autoconf.c,v 1.276 | 2021.01.24.17.42.37 thorpej src/sys/sys/device.h,v 1.162 | 2021.01.24.17.44.16 thorpej src/sys/dev/ofw/ofw_subr.c,v 1.46 | Logs can be found at: | | http://releng.NetBSD.org/b5reports/i386/commits-2021.01.html#2021.01.24.18.02.51 Or at http://releng.netbsd.org/b5reports/i386/2021/2021.01.24.17.44.16/build.log.tail for the first to fail. kre
Re: Automated report: NetBSD-current/i386 build failure
On 23.01.2021 19:34, 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 2021.01.23.17.58.03. An extract from the build.sh output follows: *** Failed target: dependall-lint1 Just as a heads-up: the build still fails, although in another area now: --- virtio_pci.o --- /tmp/build/2021.01.24.11.34.01-i386/src/sys/dev/pci/virtio_pci.c:743:1: error: static declaration of 'bus_space_write_8' follows non-static declaration
Re: Automated report: NetBSD-current/i386 build failure
On Thu, Jan 21, 2021 at 04:33:40PM +0100, Reinoud Zandijk wrote: > I'd like to fix this ASAP but what is the correct way of dealing with this? Is > this an i386 failure or should code just not use bus_space_read_8() or > bus_space_write_8() ? Unless the spec requires it, you should just avoid those calls. Martin
Re: Automated report: NetBSD-current/i386 build failure
I'd like to fix this ASAP but what is the correct way of dealing with this? Is this an i386 failure or should code just not use bus_space_read_8() or bus_space_write_8() ? In the VirtIO case, it doesn't have to be written atomically though. What I could do is define a bus_space_write_8() function that gets compiled for i386 only but that's a hack. Reinoud On Thu, Jan 21, 2021 at 07:59:03PM +0700, Robert Elz wrote: > Date:Wed, 20 Jan 2021 21:17:40 + (UTC) > From:NetBSD Test Fixture > Message-ID: <161117746032.12857.1128493575446...@babylon5.netbsd.org> > > | 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 2021.01.20.19.46.48. > > The problem that caused that particular failure is fixed (martin@ > fixed the immediate problem, then I fixed a much older bug (2019 vintage) > that made martin's (correct) fix fail. > > But these commits are still responsible for the build (still) failing > > | The following commits were made between the last successful build and > | the failed build: > | > | 2021.01.20.19.46.48 reinoud src/sys/dev/acpi/virtio_acpi.c,v 1.5 > | 2021.01.20.19.46.48 reinoud src/sys/dev/fdt/virtio_mmio_fdt.c,v 1.5 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/if_vioif.c,v 1.66 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/ld_virtio.c,v 1.29 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vio9p.c,v 1.3 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viomb.c,v 1.12 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viornd.c,v 1.14 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vioscsi.c,v 1.25 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio.c,v 1.43 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pci.c,v 1.15 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pcireg.h,v 1.1 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtioreg.h,v 1.7 > | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtiovar.h,v 1.17 > | 2021.01.20.19.46.48 reinoud src/sys/dev/virtio/virtio_mmio.c,v 1.4 > > The most recent log is at: > > http://releng.netbsd.org/b5reports/i386/2021/2021.01.21.09.50.37/build.log.tail > > and contains the following error messages (all one underlying issue) > > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.o: in function `virtio_pci_setup_queue_10': > virtio_pci.c:(.text+0x1285): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x12a9): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x12cd): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x132e): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.c:(.text+0x1357): undefined reference to `bus_space_write_8' > /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: > virtio_pci.o:virtio_pci.c:(.text+0x1380): more undefined references to > `bus_space_write_8' follow > > This is as far as I can go with this one, I don't know whether i386 is > supposed to have a bus_space_write_8() function or not (and if not, what > should be used instead) or whether it exists, but for some reason isn't > being found (the error is detected in the INSTALL kernel build), or > something else. > > kre
Re: Automated report: NetBSD-current/i386 build failure
Date:Wed, 20 Jan 2021 21:17:40 + (UTC) From:NetBSD Test Fixture Message-ID: <161117746032.12857.1128493575446...@babylon5.netbsd.org> | 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 2021.01.20.19.46.48. The problem that caused that particular failure is fixed (martin@ fixed the immediate problem, then I fixed a much older bug (2019 vintage) that made martin's (correct) fix fail. But these commits are still responsible for the build (still) failing | The following commits were made between the last successful build and | the failed build: | | 2021.01.20.19.46.48 reinoud src/sys/dev/acpi/virtio_acpi.c,v 1.5 | 2021.01.20.19.46.48 reinoud src/sys/dev/fdt/virtio_mmio_fdt.c,v 1.5 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/if_vioif.c,v 1.66 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/ld_virtio.c,v 1.29 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vio9p.c,v 1.3 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viomb.c,v 1.12 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/viornd.c,v 1.14 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/vioscsi.c,v 1.25 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio.c,v 1.43 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pci.c,v 1.15 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtio_pcireg.h,v 1.1 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtioreg.h,v 1.7 | 2021.01.20.19.46.48 reinoud src/sys/dev/pci/virtiovar.h,v 1.17 | 2021.01.20.19.46.48 reinoud src/sys/dev/virtio/virtio_mmio.c,v 1.4 The most recent log is at: http://releng.netbsd.org/b5reports/i386/2021/2021.01.21.09.50.37/build.log.tail and contains the following error messages (all one underlying issue) /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.o: in function `virtio_pci_setup_queue_10': virtio_pci.c:(.text+0x1285): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x12a9): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x12cd): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x132e): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.c:(.text+0x1357): undefined reference to `bus_space_write_8' /tmp/build/2021.01.21.09.50.37-i386/tools/bin/i486--netbsdelf-ld: virtio_pci.o:virtio_pci.c:(.text+0x1380): more undefined references to `bus_space_write_8' follow This is as far as I can go with this one, I don't know whether i386 is supposed to have a bus_space_write_8() function or not (and if not, what should be used instead) or whether it exists, but for some reason isn't being found (the error is detected in the INSTALL kernel build), or something else. kre
Re: Automated report: NetBSD-current/i386 build failure
On 03.01.2021 21:00, 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 2021.01.03.19.15.36. An extract from the build.sh output follows: dependall ===> tools/lint1 sh: cannot open err.c: no such file Sorry, fixed in Makefile.err-msgs-h 1.2. Roland
Re: Automated report: NetBSD-current/i386 build failure
Sorry for breakage. I'll fix this.
rin
On 2020/12/19 17:40, 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.12.19.07.19.30.
An extract from the build.sh output follows:
/tmp/build/2020.12.19.07.19.30-i386/tools/bin/i486--netbsdelf-objcopy -x
maxfilename.o
--- dependall-sys ---
--- dependall-arch ---
In file included from
/tmp/build/2020.12.19.07.19.30-i386/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/lfsv1.c:30:
/tmp/build/2020.12.19.07.19.30-i386/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/ufs.c:
In function 'lfsv1_open':
/tmp/build/2020.12.19.07.19.30-i386/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/ufs.c:586:9:
error: 'FS' {aka 'struct salfs'} has no member named 'lfs_version'
586 | fs->lfs_version != REQUIRED_LFS_VERSION ||
| ^~
--- dependall-external ---
--- maxpathname.o ---
# compile libgroff/maxpathname.o
/tmp/build/2020.12.19.07.19.30-i386/tools/bin/i486--netbsdelf-c++
-frandom-seed=d9de403b -O2 -D__GETOPT_PREFIX=groff_ -Werror -fPIE -fno-rtti
-fno-exceptions --sysroot=/tmp/build/2020.12.19.07.19.30-i386/destdir
-DHAVE_CONFIG_H
-I/tmp/build/2020.12.19.07.19.30-i386/src/external/gpl2/groff/include
-I/tmp/build/2020.12.19.07.19.30-i386/src/external/gpl2/groff/dist/src/include
-c
/tmp/build/2020.12.19.07.19.30-i386/src/external/gpl2/groff/dist/src/libs/libgroff/maxpathname.cpp
-o maxpathname.o
--- dependall-usr.sbin ---
--- dependall-hdaudioctl ---
--- hdaudioctl.d ---
#create hdaudioctl/hdaudioctl.d
CC=/tmp/build/2020.12.19.07.19.30-i386/tools/bin/i486--netbsdelf-gcc
/tmp/build/2020.12.19.07.19.30-i386/tools/bin/nbmkdep -f hdaudioctl.d.tmp --
-std=gnu99 -D_KERNTYPES --sysroot=/tmp/build/2020.12.19.07.19.30-i386/destdir
/tmp/build/2020.12.19.07.19.30-i386/src/usr.sbin/hdaudioctl/hdaudioctl.c && mv
-f hdaudioctl.d.tmp hdaudioctl.d
--- dependall-external ---
--- dependall-gpl3 ---
checking for getrlimit... yes
--- dependall-sys ---
*** [lfsv1.o] Error code 1
--- dependall-external ---
--- dependall-mpl ---
The following commits were made between the last successful build and
the failed build:
2020.12.19.07.19.30 rin src/sys/lib/libsa/ufs.c,v 1.77
Logs can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2020.12.html#2020.12.19.07.19.30
Re: Automated report: NetBSD-current/i386 build failure
Roland Illig wrote: > >=== 2 extra files in DESTDIR = > Fixed in distrib/sets/lists/tests/mi 1.984. Confirmed fixed, thanks. The i386 build is still failing, though - it's now back to failing in mpu_acpi.c: --- kern-GENERIC --- /tmp/build/2020.12.07.08.31.07-i386/src/sys/dev/acpi/mpu_acpi.c:119:38: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 119 | sc->arg = acpi_intr_establish(self, (uint64_t)aa->aa_node->ad_handle, | ^ Logs: http://releng.netbsd.org/b5reports/i386/commits-2020.12.html#2020.12.07.08.31.07 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
On 07.12.2020 07:42, Andreas Gustafsson wrote: The build is now failing differently: === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/usr.bin/make/unit-tests/opt-keep-going-multiple.exp ./usr/tests/usr.bin/make/unit-tests/opt-keep-going-multiple.mk = end of 2 extra files === Fixed in distrib/sets/lists/tests/mi 1.984.
Re: Automated report: NetBSD-current/i386 build failure
The build is now failing differently: === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/usr.bin/make/unit-tests/opt-keep-going-multiple.exp ./usr/tests/usr.bin/make/unit-tests/opt-keep-going-multiple.mk = end of 2 extra files === Logs: http://releng.netbsd.org/b5reports/i386/commits-2020.12.html#2020.12.07.01.32.04 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > nbmake[2]: stopped in > /tmp/build/2020.12.06.12.54.32-i386/obj/sys/arch/i386/compile/LEGACY More specifically: --- mpu_acpi.o --- /tmp/build/2020.12.06.12.23.13-i386/src/sys/dev/acpi/mpu_acpi.c: In function 'mpu_acpi_attach': /tmp/build/2020.12.06.12.23.13-i386/src/sys/dev/acpi/mpu_acpi.c:119:38: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 119 | sc->arg = acpi_intr_establish(self, (uint64_t)aa->aa_node->ad_handle, | ^ > The following commits were made between the last successful build and > the failed build: Now bisected to this commit: > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/amdccp_acpi.c,v 1.3 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/atppc_acpi.c,v 1.18 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/fdc_acpi.c,v 1.44 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/lpt_acpi.c,v 1.21 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/mpu_acpi.c,v 1.14 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/pckbc_acpi.c,v 1.38 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/spic_acpi.c,v 1.7 > 2020.12.06.12.23.13 jmcneill src/sys/dev/acpi/wb_acpi.c,v 1.6 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Andreas Gustafsson wrote: > [External Email. Be cautious of content] > > > The build is now failing with: Ah, sorry there's some step I missed > > === 2 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > -- > ./usr/tests/usr.bin/make/unit-tests/objdir-writable.exp > ./usr/tests/usr.bin/make/unit-tests/objdir-writable.mk > = end of 2 extra files === >
Re: Automated report: NetBSD-current/i386 build failure
Andreas Gustafsson wrote: > The build is now failing with: Hopefully fixed now. > > === 2 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > -- > ./usr/tests/usr.bin/make/unit-tests/objdir-writable.exp > ./usr/tests/usr.bin/make/unit-tests/objdir-writable.mk > = end of 2 extra files ===
Re: Automated report: NetBSD-current/i386 build failure
The build is now failing with: === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/usr.bin/make/unit-tests/objdir-writable.exp ./usr/tests/usr.bin/make/unit-tests/objdir-writable.mk = end of 2 extra files === Logs at: http://releng.netbsd.org/b5reports/i386/commits-2020.11.html#2020.11.13.09.56.53 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
The build is still failing, but now with a different error:
nbmake[5]: "/tmp/build/2020.11.13.08.33.07-i386/src/external/ofl/Makefile"
line 3: Malformed conditional (${MKX11} != "no")
--
Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > nbmake[7]: nbmake[7]: don't know how to make -ltermlib. Stop The build is still failing. The problems started with this commit: 2020.11.08.21.56.47 nia src/external/bsd/kyua-cli/Makefile.inc,v 1.8 2020.11.08.21.56.47 nia src/external/ibm-public/postfix/Makefile.inc,v 1.25 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/Makefile.inc,v 1.9 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/bin/Makefile,v 1.7 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/lib/Makefile,v 1.12 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/lib/sqlite3.pc.in,v 1.3 2020.11.08.21.56.48 nia src/usr.sbin/makemandb/Makefile,v 1.10 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Should be fixed now... On Wed, 4 Nov 2020, 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.11.04.18.12.19. An extract from the build.sh output follows: --- dependall-sys --- In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:244:5: note: previous definition of 'ptrace_common_init' was here 244 | int ptrace_common_init(void); | ^~ /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:1585:1: error: redefinition of 'ptrace_common_fini' 1585 | ptrace_common_fini(void) | ^~ In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:245:5: note: previous definition of 'ptrace_common_fini' was here 245 | int ptrace_common_fini(void); | ^~ --- dependall-tests --- #create chacha/.depend rm -f .depend --- dependall-crypto/external --- --- ssh --- --- dependall-tests --- CC=/tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbmkdep -s .o\ .ln\ .d -d -f .depend chacha_ref.d chacha_selftest.d chacha_sse2.d chacha_sse2_impl.d t_chacha.d --- dependall-crypto/external --- # link ssh/ssh /tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc --sysroot=/tmp/build/2020.11.04.18.12.19-i386/destdir -pie -shared-libgcc -Wl,--warn-shared-textrel -Wl,-z,relro -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o auth.o gss-genr.o -Wl,-rpath-link,/tmp/build/2020.11.04.18.12.19-i386/destdir/lib -L=/lib -lgssapi -lheimntlm -lkrb5 -lcom_err -lhx509 -lcrypto -lasn1 -lwind -lheimbase -lcom_err -lroken -lsqlite3 -lm -lcrypt -lutil -lssh -lcrypto -lcrypt -lz --- dependall-tests --- --- dependall --- --- dependall-crypto --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION bftest.o --- dependall-rump --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION h_stresscli.o --- dependall-sys --- --- .gdbinit --- --- dependall-sys --- --- dependall-ipl --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -L VERSION ip_scan.o --- dependall-tests --- --- dependall-crypto --- --- h_bftest --- --- dependall-sys --- --- dependall-procfs --- --- procfs_note.d --- --- dependall-tests --- --- dependall-rump --- --- h_forkcli --- --- dependall-sys --- rm -f .gdbinit --- dependall-sys --- --- dependall-ptrace_common --- *** [sys_ptrace_common.o] Error code 1 --- dependall-tests --- --- dependall-crypto --- The following commits were made between the last successful build and the failed build: 2020.11.04.18.12.18 pgoyette src/sys/kern/sys_ptrace_common.c,v 1.90 2020.11.04.18.12.19 pgoyette src/sys/sys/ptrace.h,v 1.73 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.11.html#2020.11.04.18.12.19 !DSPAM:5fa2fd60115747723319370! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
Working on it ... On Wed, 4 Nov 2020, 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.11.04.18.12.19. An extract from the build.sh output follows: --- dependall-sys --- In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:244:5: note: previous definition of 'ptrace_common_init' was here 244 | int ptrace_common_init(void); | ^~ /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:1585:1: error: redefinition of 'ptrace_common_fini' 1585 | ptrace_common_fini(void) | ^~ In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:245:5: note: previous definition of 'ptrace_common_fini' was here 245 | int ptrace_common_fini(void); | ^~ --- dependall-tests --- #create chacha/.depend rm -f .depend --- dependall-crypto/external --- --- ssh --- --- dependall-tests --- CC=/tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbmkdep -s .o\ .ln\ .d -d -f .depend chacha_ref.d chacha_selftest.d chacha_sse2.d chacha_sse2_impl.d t_chacha.d --- dependall-crypto/external --- # link ssh/ssh /tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc --sysroot=/tmp/build/2020.11.04.18.12.19-i386/destdir -pie -shared-libgcc -Wl,--warn-shared-textrel -Wl,-z,relro -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o auth.o gss-genr.o -Wl,-rpath-link,/tmp/build/2020.11.04.18.12.19-i386/destdir/lib -L=/lib -lgssapi -lheimntlm -lkrb5 -lcom_err -lhx509 -lcrypto -lasn1 -lwind -lheimbase -lcom_err -lroken -lsqlite3 -lm -lcrypt -lutil -lssh -lcrypto -lcrypt -lz --- dependall-tests --- --- dependall --- --- dependall-crypto --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION bftest.o --- dependall-rump --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION h_stresscli.o --- dependall-sys --- --- .gdbinit --- --- dependall-sys --- --- dependall-ipl --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -L VERSION ip_scan.o --- dependall-tests --- --- dependall-crypto --- --- h_bftest --- --- dependall-sys --- --- dependall-procfs --- --- procfs_note.d --- --- dependall-tests --- --- dependall-rump --- --- h_forkcli --- --- dependall-sys --- rm -f .gdbinit --- dependall-sys --- --- dependall-ptrace_common --- *** [sys_ptrace_common.o] Error code 1 --- dependall-tests --- --- dependall-crypto --- The following commits were made between the last successful build and the failed build: 2020.11.04.18.12.18 pgoyette src/sys/kern/sys_ptrace_common.c,v 1.90 2020.11.04.18.12.19 pgoyette src/sys/sys/ptrace.h,v 1.73 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.11.html#2020.11.04.18.12.19 !DSPAM:5fa2fd60115747723319370! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
On Fri, Oct 30, 2020 at 03:02:16PM +0900, Rin Okuyama wrote: > On 2020/10/30 2:10, Rin Okuyama wrote: > > On 2020/10/30 1:58, nia wrote: > > > It should be fixed already. > > > > Please also try build for sun2, which does not support shlib; > > All programs linked to libsqlite3 need -lm explicitly. > > Periodic build for sun2 and vax is broken due to the sqlite3 change: > > https://releng.netbsd.org/builds/HEAD/202010292030Z/ I just fixed VAX (I think). I saw discussions of the required DPADD changes for sun2, so guess the next build for that should also work. Martin
Re: Automated report: NetBSD-current/i386 build failure
On 2020/10/30 2:10, Rin Okuyama wrote: On 2020/10/30 1:58, nia wrote: It should be fixed already. Please also try build for sun2, which does not support shlib; All programs linked to libsqlite3 need -lm explicitly. Periodic build for sun2 and vax is broken due to the sqlite3 change: https://releng.netbsd.org/builds/HEAD/202010292030Z/ Nia, please fix them. Note that vax uses its own (i.e., non-IEE754) floating-point formats. Thanks, rin
Re: Automated report: NetBSD-current/i386 build failure
nia wrote: > It should be fixed already. It's not, it's now failing earlier in the build: http://releng.netbsd.org/b5reports/i386/commits-2020.10.html#2020.10.29.16.35.33 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Yes, your commit message arrived here while I was typing the message containing my (obviously incorrect, and now discarded) patch, along with the rant. kre
Re: Automated report: NetBSD-current/i386 build failure
On 2020/10/30 1:58, nia wrote: It should be fixed already. Please also try build for sun2, which does not support shlib; All programs linked to libsqlite3 need -lm explicitly. Thanks, rin
Re: Automated report: NetBSD-current/i386 build failure
It should be fixed already.
Re: Automated report: NetBSD-current/i386 build failure
Date:Thu, 29 Oct 2020 15:53:25 + (UTC)
From:NetBSD Test Fixture
Message-ID: <160398680587.14474.16594358311982355...@babylon5.netbsd.org>
|
/tmp/build/2020.10.29.12.38.06-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
/tmp/build/2020.10.29.12.38.06-i386/destdir/usr/lib/libsqlite3.so: undefined
reference to `log'
| collect2: error: ld returned 1 exit status
| *** [dig] Error code 1
| --- dependall-games ---
| --- dependall-bin ---
It is possible that the following patch will fix this, but right now
I'm in the middle of something else, and cannot do a build to verify
that this is the right change.
Nia: please always do a build.sh release before committing any significant
change. An efficient way for me, is to work on several (unrelated)
changes, then do one release build (and fix any problems and repeat) and
then when all is OK, go back to each of the updates and commit them
individually. How many of those there should be depends upon how
much you're working on at once, but if needed, doing the first
release build (which sometimes takes a while if enough has changed)
while you're doing something else (like sleeping) can also help.
kre
Index: Makefile
===
RCS file: /cvsroot/src/external/public-domain/sqlite/bin/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile14 Feb 2013 21:07:25 - 1.5
+++ Makefile29 Oct 2020 16:35:15 -
@@ -5,7 +5,7 @@
SRCS= shell.c
DPADD+=${LIBSQLITE3} ${LIBEDIT} ${LIBTERIMINFO}
-LDADD+=-lsqlite3 -ledit -lterminfo
+LDADD+=-lsqlite3 -ledit -lterminfo -lm
BINDIR=/usr/bin
Re: Automated report: NetBSD-current/i386 build failure
On 12/09/2020 07:40, 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.09.12.01.36.26. An extract from the build.sh output follows: --- dependall-include --- /tmp/bracket/build/2020.09.12.01.36.26-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: /tmp/bracket/build/2020.09.12.01.36.26-i386/destdir/usr/lib/librumpnet_net.so: undefined reference to `rumpns_nd_set_timer' /tmp/bracket/build/2020.09.12.01.36.26-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: /tmp/bracket/build/2020.09.12.01.36.26-i386/destdir/usr/lib/librumpnet_net.so: undefined reference to `rumpns_nd_resolve' /tmp/bracket/build/2020.09.12.01.36.26-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: /tmp/bracket/build/2020.09.12.01.36.26-i386/destdir/usr/lib/librumpnet_net.so: undefined reference to `rumpns_nd_nud_hint' /tmp/bracket/build/2020.09.12.01.36.26-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: /tmp/bracket/build/2020.09.12.01.36.26-i386/destdir/usr/lib/librumpnet_net.so: undefined reference to `rumpns_nd_attach_domain' collect2: error: ld returned 1 exit status *** [t_socket] Error code 1 nbmake[8]: stopped in /tmp/bracket/build/2020.09.12.01.36.26-i386/src/tests/include/sys --- dependall-sys --- --- dependall-bootxx --- This should now be fixed in sys/rump/net/lib/libnet/Makefile r1.33 Roy
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > --- kern-XEN3PAE_DOMU --- > *** [netbsd] Error code 1 > nbmake[2]: stopped in > /tmp/bracket/build/2020.08.09.11.04.05-i386/obj/sys/arch/i386/compile/XEN3PAE_DOMU Specifically: --- kern-XEN3PAE_DOMU --- /tmp/bracket/build/2020.08.09.11.04.05-i386/tools/bin/i486--netbsdelf-ld: trap.o: in function `trap': trap.c:(.text+0xe27): undefined reference to `x86_cpu_is_lcall' -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
> Date: Sun, 26 Jul 2020 15:20:05 +0300 > From: Andreas Gustafsson > > The build is still failing, current error as of 2020.07.26.09.17.24: > > === 1 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > -- > ./usr/libdata/debug/usr/tests/sys/crypto/chacha > = end of 1 extra files === Should be fixed now.
Re: Automated report: NetBSD-current/i386 build failure
The build is still failing, current error as of 2020.07.26.09.17.24: === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libdata/debug/usr/tests/sys/crypto/chacha = end of 1 extra files === -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
> I just committed usr.bin/make/var.c r1.270 which seems to fix > everything. Confirmed. Thanks for a quick response. --- Izumi Tsutsui
Re: Automated report: NetBSD-current/i386 build failure
On 19.07.2020 19:34, Andreas Gustafsson wrote: > The build is still broken as of source date 2020.07.19.16.22.44: > > > http://releng.netbsd.org/b5reports/i386/commits-2020.07.html#2020.07.19.16.22.44 I'm sorry, I should have had a build running in parallel to my changes all the time. I just committed usr.bin/make/var.c r1.270 which seems to fix everything. (It was a double-free.) I'll try to add a corresponding test to the make(1) unit tests. Roland
Re: Automated report: NetBSD-current/i386 build failure
The build is still broken as of source date 2020.07.19.16.22.44: http://releng.netbsd.org/b5reports/i386/commits-2020.07.html#2020.07.19.16.22.44 -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
This has already been fixed - thanks, Roy! On Fri, 3 Jul 2020, 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.07.03.11.03.42. An extract from the build.sh output follows: obsolete_stand fix: postinstall fixes passed: obsolete_stand postinstall fixes failed: AWK=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbawk DB=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbdb HOST_SH=/bin/sh MAKE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmake PWD_MKDB=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbpwd_mkdb SED=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbsed STAT=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbstat /bin/sh /tmp/bracket/build/2020.07.03.11.03.42-i386/obj/usr.sbin/postinstall/postinstall -m i386 -a i386 -s /tmp/bracket/build/2020.07.03.11.03.42-i386/src -d /tmp/bracket/build/2020.07.03.11.03.42-i386/destdir/ fix obsolete_stand_debug Source directory: /tmp/bracket/build/2020.07.03.11.03.42-i386/src Target directory: /tmp/bracket/build/2020.07.03.11.03.42-i386/destdir/ obsolete_stand_debug fix: postinstall fixes passed: obsolete_stand_debug postinstall fixes failed: === checkflist ===> distrib/sets --- check_DESTDIR --- --- checkflist --- cd /tmp/bracket/build/2020.07.03.11.03.42-i386/src/distrib/sets && DESTDIR=/tmp/bracket/build/2020.07.03.11.03.42-i386/destdir MACHINE=i386 MACHINE_ARCH=i386 AWK=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbawk CKSUM=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbcksum DB=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbdb EGREP=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbgrep\ -E HOST_SH=/bin/sh MAKE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmake MKTEMP=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmktemp MTREE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmtree PAX=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip GZIP=-n XZ_OPT=-9 TAR_SUFF=tgz PKG_CREATE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbpkg_create SED=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbsed TSORT=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbts o rt\ -q /bin/sh /tmp/bracket/build/2020.07.03.11.03.42-i386/src/distrib/sets/checkflist -L base -M /tmp/bracket/build/2020.07.03.11.03.42-i386/destdir/METALOG.sanitised === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./var/db/dhcpcd = end of 1 extra files === *** [checkflist] Error code 1 nbmake[2]: stopped in /tmp/bracket/build/2020.07.03.11.03.42-i386/src/distrib/sets 1 error The following commits were made between the last successful build and the failed build: 2020.07.03.10.19.18 jmcneill src/sys/arch/arm/arm32/db_machdep.c,v 1.34 2020.07.03.10.19.18 jmcneill src/sys/arch/arm/include/arm32/db_machdep.h,v 1.10 2020.07.03.10.45.43 roy src/external/bsd/dhcpcd/dist/src/defs.h,v 1.1.1.45 2020.07.03.10.46.45 roy src/external/bsd/dhcpcd/dist/src/dhcpcd.c,v 1.41 2020.07.03.10.47.29 roy src/doc/3RDPARTY,v 1.1735 2020.07.03.10.47.29 roy src/doc/CHANGES,v 1.2708 2020.07.03.11.03.42 roy src/etc/mtree/NetBSD.dist.base,v 1.221 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.07.html#2020.07.03.11.03.42 !DSPAM:5eff331c222464894717810! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
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.
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
Re: Automated report: NetBSD-current/i386 build failure
On 12/06/2020 16:13, 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.12.11.21.36. An extract from the build.sh output follows: --- dependall-libagr --- --- if_agrether_hash.d --- #create libagr/if_agrether_hash.d CC=/tmp/bracket/build/2020.06.12.11.21.36-i386/tools/bin/i486--netbsdelf-gcc /tmp/bracket/build/2020.06.12.11.21.36-i386/tools/bin/nbmkdep -f if_agrether_hash.d.tmp -- -std=gnu99 --sysroot=/tmp/bracket/build/2020.06.12.11.21.36-i386/destdir -DCOMPAT_50 -DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -DCOMPAT_90 -nostdinc -imacros /tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../include/opt/opt_rumpkernel.h -I/tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr -I. -I/tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../../../common/include -I/tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../include -I/tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../include/opt -I/tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../../arch -I/tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../.. -DDIAGNOSTIC - DKTRACE -D_FORTIFY_SOURCE=2 /tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libagr/../../../../net/agr/if_agrether_hash.c && mv -f if_agrether_hash.d.tmp if_agrether_hash.d --- dependall-libnet --- /tmp/bracket/build/2020.06.12.11.21.36-i386/src/sys/rump/net/lib/libnet/../../../../netinet6/in6.c:112:10: fatal error: compat/netinet6/nd6.h: No such file or directory #include ^~~ Fixed here: https://mail-index.netbsd.org/source-changes/2020/06/12/msg118239.html Roy
Re: Automated report: NetBSD-current/i386 build failure
On Fri, May 22, 2020 at 12:07:52AM +, 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.05.21.21.12.31. ... > --- lapic.o --- > *** [lapic.o] Error code 1 > nbmake[2]: stopped in > /tmp/bracket/build/2020.05.21.21.12.31-i386/obj/sys/arch/i386/compile/LEGACY > --- lance.o --- This one is fixed already with 1.82 of sys/arch/x86/x86/lapic.c. Andrew
Re: Automated report: NetBSD-current/i386 build failure
I am using this diff but I am not sure what I am doing.
Index: tests/rump/modautoload/Makefile
===
RCS file: /cvsroot/src/tests/rump/modautoload/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- tests/rump/modautoload/Makefile 17 Aug 2019 04:04:28 - 1.9
+++ tests/rump/modautoload/Makefile 16 May 2020 12:25:13 -
@@ -17,7 +17,7 @@
LDADD+=-Wl,--whole-archive ${DESTDIR}/usr/lib/librumpvfs.a
\
${DESTDIR}/usr/lib/librump.a\
-Wl,--no-whole-archive
-LDADD+=-lrumpuser -lpthread
+LDADD+=-lrumpvfs_nofifofs -lrumpuser -lpthread
DPADD+=${LIBRUMPVFS} ${LIBRUMP} ${LIBRUMPUSER}
WARNS= 4
Index: usr.bin/rump_server/Makefile
===
RCS file: /cvsroot/src/usr.bin/rump_server/Makefile,v
retrieving revision 1.13
diff -u -r1.13 Makefile
--- usr.bin/rump_server/Makefile1 Jun 2019 06:59:18 - 1.13
+++ usr.bin/rump_server/Makefile16 May 2020 12:25:13 -
@@ -8,6 +8,6 @@
NOMAN= installed by ../rump_allserver
LDADD+=-Wl,--whole-archive -lrumpkern_sysproxy -lrump
-lrumpvfs \
- -lrumpuser -Wl,--no-whole-archive -lpthread
+ -lrumpvfs_nofifofs -lrumpuser -Wl,--no-whole-archive -lpthread
.include
Index: usr.sbin/npf/npftest/Makefile
===
RCS file: /cvsroot/src/usr.sbin/npf/npftest/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- usr.sbin/npf/npftest/Makefile 13 May 2019 17:55:09 - 1.12
+++ usr.sbin/npf/npftest/Makefile 16 May 2020 12:25:13 -
@@ -17,7 +17,7 @@
DPADD+=${LIBNPFTEST}/libnpftest.a
LDADD+=-L${LIBNPFTEST} -lnpftest
-LDADD+=-lrump -lrumpvfs -lrumpuser -lrumpnet -lrumpnet_net
+LDADD+=-lrump -lrumpvfs -lrumpvfs_nofifofs -lrumpuser
-lrumpnet -lrumpnet_net
LDADD+=-lrumpdev_bpf
.include
Index: usr.sbin/puffs/Makefile.inc
===
RCS file: /cvsroot/src/usr.sbin/puffs/Makefile.inc,v
retrieving revision 1.15
diff -u -r1.15 Makefile.inc
--- usr.sbin/puffs/Makefile.inc 23 Jan 2016 21:22:50 - 1.15
+++ usr.sbin/puffs/Makefile.inc 16 May 2020 12:25:13 -
@@ -43,7 +43,7 @@
LDADD+=-lrumpdev_disk -lrumpdev
.endif
-LDADD+=-lp2k -lukfs -lrumpvfs -lrump -lrumpuser -lpuffs -lutil
+LDADD+=-lp2k -lukfs -lrumpvfs -lrumpvfs_nofifofs -lrump
-lrumpuser -lpuffs -lutil
LDADD+=-lpthread
DPADD+=${LIBP2K} ${LIBUKFS} ${LIBRUMPVFS} ${LIBRUMP}
${LIBRUMPUSER}
re: Automated report: NetBSD-current/i386 build failure
Andrew Doran writes: > Doesn't show up in Opengrok, maybe it dislikes rump. Already fixed. opengrok is missing massive portions of src, please don't rely upon it to find "all" of anything. ... or can we have it fixed please? :) (grep -r across 'src' is really fast on a modern system when it's in cache. fwiw...) .mrg.
Re: Automated report: NetBSD-current/i386 build failure
Doesn't show up in Opengrok, maybe it dislikes rump. Already fixed. Andrew On Sun, Apr 19, 2020 at 09:56:55PM +, 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.04.19.20.35.29. > > An extract from the build.sh output follows: > > /tmp/bracket/build/2020.04.19.20.35.29-i386/tools/bin/nbctfconvert -g -L > VERSION klock.o > > /tmp/bracket/build/2020.04.19.20.35.29-i386/tools/bin/i486--netbsdelf-objcopy > -x klock.o > --- etfs_wrap.o --- > > /tmp/bracket/build/2020.04.19.20.35.29-i386/tools/bin/i486--netbsdelf-objcopy > -x etfs_wrap.o > --- sleepq.o --- > > /tmp/bracket/build/2020.04.19.20.35.29-i386/src/lib/librump/../../sys/rump/librump/rumpkern/sleepq.c:65:1: > error: conflicting types for 'sleepq_enqueue' > sleepq_enqueue(sleepq_t *sq, wchan_t wc, const char *wmsg, syncobj_t > *sob) > ^~ > In file included from > /tmp/bracket/build/2020.04.19.20.35.29-i386/src/lib/librump/../../sys/rump/librump/rumpkern/sleepq.c:36: > > /tmp/bracket/build/2020.04.19.20.35.29-i386/src/lib/librump/../../sys/rump/../sys/sleepq.h:63:6: > note: previous declaration of 'sleepq_enqueue' was here > void sleepq_enqueue(sleepq_t *, wchan_t, const char *, struct syncobj *, > ^~ > --- rumpkern_syscalls.o --- > --- locks.o --- > --- hyperentropy.o --- > /tmp/bracket/build/2020.04.19.20.35.29-i386/tools/bin/nbctfconvert -g -L > VERSION hyperentropy.o > --- rumpkern_syscalls.o --- > # compile librump/rumpkern_syscalls.o > --- hyperentropy.o --- > > /tmp/bracket/build/2020.04.19.20.35.29-i386/tools/bin/i486--netbsdelf-objcopy > -x hyperentropy.o > --- sleepq.o --- > *** [sleepq.o] Error code 1 > nbmake[7]: stopped in > /tmp/bracket/build/2020.04.19.20.35.29-i386/src/lib/librump > --- rumpkern_syscalls.o --- > > The following commits were made between the last successful build and > the failed build: > > 2020.04.19.18.47.40 jdolecek src/sys/arch/xen/include/xen_shm.h,v 1.11 > 2020.04.19.18.47.40 jdolecek src/sys/arch/xen/x86/xen_shm_machdep.c,v 1.15 > 2020.04.19.18.47.40 jdolecek src/sys/arch/xen/xen/hypervisor.c,v 1.75 > 2020.04.19.18.47.40 jdolecek src/sys/arch/xen/xen/xbdback_xenbus.c,v 1.79 > 2020.04.19.19.12.37 jmcneill > src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_nv50_display.c,v 1.12 > 2020.04.19.19.12.37 jmcneill > src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/mmu/nouveau_nvkm_subdev_mmu_nv44.c,v > 1.4 > 2020.04.19.19.20.32 gutteridge src/share/man/man5/fstab.5,v 1.47 > 2020.04.19.19.36.49 kre src/sys/arch/arm/arm32/pmap.c,v 1.410 > 2020.04.19.19.37.06 christos src/sbin/fsck_ffs/pass1.c,v 1.59 > 2020.04.19.20.07.53 jdolecek src/sys/arch/xen/xen/privcmd.c,v 1.55 > 2020.04.19.20.31.59 thorpej src/sys/compat/linux/common/linux_misc.c,v > 1.248 > 2020.04.19.20.31.59 thorpej src/sys/compat/linux/common/linux_sched.c,v > 1.74 > 2020.04.19.20.31.59 thorpej > src/sys/compat/linux32/common/linux32_sysinfo.c,v 1.11 > 2020.04.19.20.31.59 thorpej src/sys/compat/netbsd32/netbsd32_execve.c,v > 1.42 > 2020.04.19.20.31.59 thorpej src/sys/kern/kern_exec.c,v 1.497 > 2020.04.19.20.31.59 thorpej src/sys/kern/kern_exit.c,v 1.288 > 2020.04.19.20.31.59 thorpej src/sys/kern/kern_proc.c,v 1.244 > 2020.04.19.20.31.59 thorpej src/sys/miscfs/procfs/procfs_linux.c,v 1.81 > 2020.04.19.20.31.59 thorpej src/sys/miscfs/procfs/procfs_vfsops.c,v 1.105 > 2020.04.19.20.32.00 thorpej src/sys/rump/librump/rumpkern/lwproc.c,v 1.45 > 2020.04.19.20.35.29 ad src/sys/kern/kern_condvar.c,v 1.47 > 2020.04.19.20.35.29 ad src/sys/kern/kern_sleepq.c,v 1.66 > 2020.04.19.20.35.29 ad src/sys/kern/kern_synch.c,v 1.347 > 2020.04.19.20.35.29 ad src/sys/kern/kern_timeout.c,v 1.61 > 2020.04.19.20.35.29 ad src/sys/kern/kern_turnstile.c,v 1.39 > 2020.04.19.20.35.29 ad src/sys/kern/sys_lwp.c,v 1.77 > 2020.04.19.20.35.29 ad src/sys/kern/sys_select.c,v 1.54 > 2020.04.19.20.35.29 ad src/sys/sys/sleepq.h,v 1.29 > > Logs can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2020.04.html#2020.04.19.20.35.29
Re: Automated report: NetBSD-current/i386 build failure
Date:Fri, 17 Apr 2020 14:08:27 + (UTC) From:NetBSD Test Fixture Message-ID: <158713250771.23564.16282845902177835...@babylon5.netbsd.org> | The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, | using sources from CVS date 2020.04.17.11.21.06. | | An extract from the build.sh output follows: | | jemalloc.c:(.text+0x4947): multiple definition of `calloc'; libhack.o:(.text+0x3fc0): first defined here I am test-building a potential fix for this now. kre
Re: Automated report: NetBSD-current/i386 build failure
Fix committed. The compiler was correct - I reused code around frame_list from setup, didn't notice the type is different. Thank yo. Jaromir Le ven. 10 avr. 2020 à 22:35, Robert Elz a écrit : > > Date:Thu, 9 Apr 2020 22:24:47 + (UTC) > From:NetBSD Test Fixture > Message-ID: <158647108721.6125.11585167398565454...@babylon5.netbsd.org> > > | This is an automatically generated notice of a NetBSD-current/i386 > | build failure. > > The i386 build remains broken since this commit: > > | 2020.04.09.19.26.38 jdolecek src/sys/arch/xen/xen/xengnt.c,v 1.31 > > The problem is when compiling i386_PAE and is in the new function: > > static int > xengnt_map_status(void) > > in this line: > > set_xen_guest_handle(getstatus.frame_list, pages); > > which gcc diagnoses as assigning a pointer of one type to a > pointer of a different tye (u_long * being assigned to unsigned long long *). > > While I have issues with this kind of thing being treated as an error, > it looks as if it might be easy to fix. > > "pages" is the u_long * - and looks as if it should be a paddr_t * > > When it is dereferenced later in the code, the value is cast to a paddr_t > > This would perhaps be a real bug, as (as best I understand the x86 > architecture) a u_long is not big enough to hold a paddr_t on 386 PAE. > (Only perhaps, as it looks as if it is really storing page numbers, > not paddr_t's at all, but ...) > > Changing "pages" to be paddr_t * instead of u_long * seems to fix the > i386 builds (I also deleted the now redundant cast on the dereference > in the same function - whether there are more elsewhere I didn't look.) > > I am not going to commit this, as I don't understand what is happening > well enough, and I also haven't tested to confirm that the amd64 builds > still work with that change made. > > Jaromir could you check this, and commit a fix so as to make the i386 builds > work again? > > There was a similar problem in a debug printf earlier, that was "fixed" by > turning off XEN_DEBUG (so the code isn't being compiled) - but it was a > related problem, with printf formats (attempting to print a paddr_t as > a pointer I(%p) I believe in that case (with a cast, but paddr_t's cannot > be transformed into pointers directly on PAE systems, I think,) > > kre >
Re: Automated report: NetBSD-current/i386 build failure
Date:Thu, 9 Apr 2020 22:24:47 + (UTC) From:NetBSD Test Fixture Message-ID: <158647108721.6125.11585167398565454...@babylon5.netbsd.org> | This is an automatically generated notice of a NetBSD-current/i386 | build failure. The i386 build remains broken since this commit: | 2020.04.09.19.26.38 jdolecek src/sys/arch/xen/xen/xengnt.c,v 1.31 The problem is when compiling i386_PAE and is in the new function: static int xengnt_map_status(void) in this line: set_xen_guest_handle(getstatus.frame_list, pages); which gcc diagnoses as assigning a pointer of one type to a pointer of a different tye (u_long * being assigned to unsigned long long *). While I have issues with this kind of thing being treated as an error, it looks as if it might be easy to fix. "pages" is the u_long * - and looks as if it should be a paddr_t * When it is dereferenced later in the code, the value is cast to a paddr_t This would perhaps be a real bug, as (as best I understand the x86 architecture) a u_long is not big enough to hold a paddr_t on 386 PAE. (Only perhaps, as it looks as if it is really storing page numbers, not paddr_t's at all, but ...) Changing "pages" to be paddr_t * instead of u_long * seems to fix the i386 builds (I also deleted the now redundant cast on the dereference in the same function - whether there are more elsewhere I didn't look.) I am not going to commit this, as I don't understand what is happening well enough, and I also haven't tested to confirm that the amd64 builds still work with that change made. Jaromir could you check this, and commit a fix so as to make the i386 builds work again? There was a similar problem in a debug printf earlier, that was "fixed" by turning off XEN_DEBUG (so the code isn't being compiled) - but it was a related problem, with printf formats (attempting to print a paddr_t as a pointer I(%p) I believe in that case (with a cast, but paddr_t's cannot be transformed into pointers directly on PAE systems, I think,) kre
Re: Automated report: NetBSD-current/i386 build failure
On 05.04.2020 01:14, 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.04.04.21.36.15.
>
> An extract from the build.sh output follows:
>
> # compile lib/parsewhoisline.o
> /tmp/bracket/build/2020.04.04.21.36.15-i386/tools/bin/i486--netbsdelf-gcc
> -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional
> -Wa,--fatal-warnings -Werror -fPIE -Wno-stringop-truncation
> --sysroot=/tmp/bracket/build/2020.04.04.21.36.15-i386/destdir
> -I/tmp/bracket/build/2020.04.04.21.36.15-i386/src/external/bsd/ipf/dist
> -I/tmp/bracket/build/2020.04.04.21.36.15-i386/src/external/bsd/ipf/dist/tools
> -I/tmp/bracket/build/2020.04.04.21.36.15-i386/src/sys/external/bsd/ipf
> -I/tmp/bracket/build/2020.04.04.21.36.15-i386/src/sys/external/bsd/ipf/netinet
> -DSTATETOP -D__UIO_EXPOSE -DINET -DINET6 -c
> /tmp/bracket/build/2020.04.04.21.36.15-i386/src/external/bsd/ipf/dist/lib/parsewhoisline.c
> -o parsewhoisline.o
> --- dependall-sys ---
> --- dependall-examples ---
>
> /tmp/bracket/build/2020.04.04.21.36.15-i386/src/sys/modules/examples/current_time/current_time.c:
> In function 'print_current_time':
>
> /tmp/bracket/build/2020.04.04.21.36.15-i386/src/sys/modules/examples/current_time/current_time.c:58:32:
> error: format '%lu' expects argument of type 'long unsigned int', but
> argument 3 has type 'uint64_t' {aka 'long long unsigned int'}
> [-Werror=format=]
> printf("Current Time: %s, %04lu/%02u/%02u %02u:%02u:%02u UTC\n",
> ^
> %04llu
> w_day[dt.dt_wday], dt.dt_year, dt.dt_mon, dt.dt_day, dt.dt_hour,
> ~~
> cc1: all warnings being treated as errors
> *** [current_time.o] Error code 1
> nbmake[9]: stopped in
> /tmp/bracket/build/2020.04.04.21.36.15-i386/src/sys/modules/examples/current_time
> 1 error
>
> Between the last successful build and the failed build, a total of 481
> revisions were committed, by the following developers:
>
> ad
> christos
> dholland
> fox
> is
> jdolecek
> kamil
> thorpej
>
> The first of these commits was made on CVS date 2020.04.04.19.46.01,
> and the last on 2020.04.04.21.36.15.
>
> Logs can be found at:
>
>
> http://releng.NetBSD.org/b5reports/i386/commits-2020.04.html#2020.04.04.21.36.15
>
Fixed in current_time.c r. 1.2.
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > --- dependall-gdb --- > > CC=/tmp/bracket/build/2020.04.02.11.52.41-i386/tools/bin/i486--netbsdelf-c++ > /tmp/bracket/build/2020.04.02.11.52.41-i386/tools/bin/nbmkdep -f maint.d.tmp > -- -std=gnu++11 > --sysroot=/tmp/bracket/build/2020.04.02.11.52.41-i386/destdir -D_KERNTYPES > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb > > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/arch/i386 > > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb > > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/config > > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/common > > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/gnulib/import > > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/include/opcode > -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb > /lib/libgdb/../../dist/libdecn--- dependall-gcc --- > > /tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gcc/dist/gcc/machmode.h:593:30: > error: 'mode_nunits_inline' was not declared in this scope > ? mode_nunits_inline (mode) : mode_nunits[mode]); > ^ > *** [min-insn-modes.lo] Error code 1 > nbmake[9]: stopped in > /tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gcc/usr.bin/backend > --- gengtype.lo --- This looks like a random failure, and there has been a couple of other similar ones also involving machmode.h: http://releng.netbsd.org/b5reports/i386/2019/2019.11.26.08.38.19/build.log.tail http://releng.netbsd.org/b5reports/i386/2020/2020.03.15.15.58.24/build.log.tail Someone please fix. -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
Date:Thu, 2 Apr 2020 14:09:14 + (UTC) From:NetBSD Test Fixture Message-ID: <158583655484.15292.8162724620486601...@babylon5.netbsd.org> | An extract from the build.sh output follows: | | #create libgdb/maint.d | --- dependall-gcc --- | /tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gcc/dist/gcc/machmode.h: In function 'poly_uint16 mode_to_nunits(machine_mode)': | --- dependall-gdb --- | CC=/tmp/bracket/build/2020.04.02.11.52.41-i386/tools/bin/i486--netbsdelf-c++ /tmp/bracket/build/2020.04.02.11.52.41-i386/tools/bin/nbmkdep -f maint.d.tmp -- -std=gnu++11 --sysroot=/tmp/bracket/build/2020.04.02.11.52.41-i386/destdir -D_KERNTYPES -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/arch/i386 -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/config -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/common -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/gnulib/import -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gdb/lib/libgdb/../../dist/include/opcode -I/tmp/bracket/build/2020.04.02.11.52.41-i386/src/exte! rnal/gpl3/ gdb | /lib/libgdb/../../dist/libdecn--- dependall-gcc --- | /tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gcc/dist/gcc/machmode.h:593:30: error: 'mode_nunits_inline' was not declared in this scope | ? mode_nunits_inline (mode) : mode_nunits[mode]); | ^ | *** [min-insn-modes.lo] Error code 1 | nbmake[9]: stopped in /tmp/bracket/build/2020.04.02.11.52.41-i386/src/external/gpl3/gcc/usr.bin/backend This looks to be something in the build infrastructure - most likely parallel builds getting out of sync. It is inconceivable that any of the commits between the previous successful build and this one could have caused this particular problem. Further, it is just as inconceivable that the following commits could have fixed it, yet the subsequent build went past this point (seemingly, with stuff happening in parallel it is always hard to be certain). That build also failed - because of a different problem, which I believe Roy has already fixed (that failure won't get reported here, but assuming it was fixed, the "success" message should come soon). kre
Re: Automated report: NetBSD-current/i386 build failure
Fixed with 1.18 src/sys/rump/librump/rumpkern/sleepq.c Apologies, forgot to commit earlier. Andrew On Thu, Mar 26, 2020 at 10:36:27PM +, 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.03.26.21.25.26. > > An extract from the build.sh output follows: > > *(elm)->field.tqe_prev = (elm)->field.tqe_next; \ > ^~~~ > > /tmp/bracket/build/2020.03.26.21.25.26-i386/src/lib/librump/../../sys/rump/librump/rumpkern/sleepq.c:131:2: > note: in expansion of macro 'TAILQ_REMOVE' > TAILQ_REMOVE(l->l_sleepq, l, l_sleepchain); > ^~~~ > > /tmp/bracket/build/2020.03.26.21.25.26-i386/src/lib/librump/../../sys/rump/../sys/queue.h:548:40: > error: 'struct ' has no member named 'tqe_next'; did you mean > 'le_next'? > *(elm)->field.tqe_prev = (elm)->field.tqe_next; \ > ^~~~ > > /tmp/bracket/build/2020.03.26.21.25.26-i386/src/lib/librump/../../sys/rump/librump/rumpkern/sleepq.c:131:2: > note: in expansion of macro 'TAILQ_REMOVE' > TAILQ_REMOVE(l->l_sleepq, l, l_sleepchain); > ^~~~ > *** [sleepq.o] Error code 1 > nbmake[7]: stopped in > /tmp/bracket/build/2020.03.26.21.25.26-i386/src/lib/librump > --- rumpkern_syscalls.o --- > > The following commits were made between the last successful build and > the failed build: > > 2020.03.26.19.42.39 ad src/sys/kern/kern_idle.c,v 1.33 > 2020.03.26.19.42.39 ad src/sys/kern/kern_synch.c,v 1.345 > 2020.03.26.19.46.42 ad src/sys/kern/kern_condvar.c,v 1.44 > 2020.03.26.19.46.42 ad src/sys/kern/kern_sleepq.c,v 1.63 > 2020.03.26.19.46.42 ad src/sys/kern/kern_turnstile.c,v 1.37 > 2020.03.26.19.46.42 ad src/sys/kern/sys_select.c,v 1.53 > 2020.03.26.19.46.42 ad src/sys/sys/condvar.h,v 1.15 > 2020.03.26.19.46.42 ad src/sys/sys/lwp.h,v 1.203 > 2020.03.26.19.46.42 ad src/sys/sys/sleepq.h,v 1.28 > 2020.03.26.19.47.23 ad src/sys/sys/param.h,v 1.655 > 2020.03.26.20.19.06 ad src/sys/kern/kern_lwp.c,v 1.230 > 2020.03.26.20.19.06 ad src/sys/kern/kern_softint.c,v 1.63 > 2020.03.26.20.19.06 ad src/sys/sys/intr.h,v 1.20 > 2020.03.26.20.19.06 ad src/sys/sys/userret.h,v 1.33 > 2020.03.26.21.15.14 ad src/sys/sys/syncobj.h,v 1.13 > 2020.03.26.21.25.26 ad src/sys/kern/kern_sig.c,v 1.385 > > Logs can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2020.03.html#2020.03.26.21.25.26
Re: Automated report: NetBSD-current/i386 build failure
Fixed with src/sys/kern/vfs_vnode.c 1.115. Andrew On Sun, Mar 22, 2020 at 04:23:47PM +, 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.03.22.14.43.05. > > An extract from the build.sh output follows: > > --- vfs_vnops.pico --- > --- vfs_vnode.po --- > > -I/tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/include > > -I/tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/include/opt > > -I/tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/../arch > > -I/tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/.. > -DDIAGNOSTIC -DKTRACE -D_FORTIFY_SOURCE=2 -c -DGPROF -DPROF-pg -fPIC > /tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/../kern/vfs_vnode.c > -o vfs_vnode.po > --- vfs_vnode.pico --- > > /tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/../kern/vfs_vnode.c: > In function 'vcache_reclaim': > > /tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/../kern/vfs_vnode.c:1679:17: > error: 'VI_DEADCHECK' undeclared (first use in this function); did you mean > 'PG_READAHEAD'? > vp->v_iflag |= VI_DEADCHECK; /* for genfs_getpages() */ > ^~~~ > PG_READAHEAD > > /tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs/../../sys/rump/../kern/vfs_vnode.c:1679:17: > note: each undeclared identifier is reported only once for each function it > appears in > *** [vfs_vnode.pico] Error code 1 > nbmake[7]: stopped in > /tmp/bracket/build/2020.03.22.14.43.05-i386/src/lib/librumpvfs > --- vfs_syscalls_50.pico --- > > The following commits were made between the last successful build and > the failed build: > > 2020.03.22.13.30.10 pgoyette src/lib/librumpuser/rumpuser_dl.c,v 1.33 > 2020.03.22.13.30.10 pgoyette src/sys/rump/include/rump/rumpuser.h,v 1.116 > 2020.03.22.13.30.10 pgoyette src/sys/rump/librump/rumpkern/rump.c,v 1.343 > 2020.03.22.14.27.33 ad src/distrib/sets/lists/comp/mi,v 1.2313 > 2020.03.22.14.27.33 ad src/sys/sys/Makefile,v 1.172 > 2020.03.22.14.27.33 ad src/sys/sys/vnode_impl.h,v 1.22 > 2020.03.22.14.38.37 ad src/sys/kern/init_sysctl.c,v 1.225 > 2020.03.22.14.38.37 ad src/sys/kern/vfs_cache.c,v 1.128 > 2020.03.22.14.38.37 ad src/sys/kern/vfs_getcwd.c,v 1.56 > 2020.03.22.14.38.37 ad src/sys/kern/vfs_vnode.c,v 1.114 > 2020.03.22.14.38.37 ad src/sys/sys/namei.src,v 1.49 > 2020.03.22.14.38.37 ad src/sys/sys/vnode_impl.h,v 1.23 > 2020.03.22.14.39.03 ad src/sys/rump/include/rump/rump_namei.h,v 1.39 > 2020.03.22.14.39.03 ad src/sys/sys/namei.h,v 1.105 > 2020.03.22.14.39.28 ad src/usr.bin/vmstat/vmstat.c,v 1.237 > 2020.03.22.14.41.32 ad src/usr.bin/pmap/main.c,v 1.28 > 2020.03.22.14.41.32 ad src/usr.bin/pmap/pmap.c,v 1.55 > 2020.03.22.14.41.32 ad src/usr.bin/pmap/pmap.h,v 1.12 > 2020.03.22.14.43.05 ad src/sys/sys/param.h,v 1.654 > > Logs can be found at: > > > http://releng.NetBSD.org/b5reports/i386/commits-2020.03.html#2020.03.22.14.43.05
Re: Automated report: NetBSD-current/i386 build failure
Should be fixed with 1.91 src/sys/miscfs/genfs/genfs_io.c. Andrew On Sat, Mar 14, 2020 at 07:46:02PM +, 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.03.14.18.08.40. > > An extract from the build.sh output follows: > > # compile librumpvfs/spec_vnops.po > --- rump_vfs.po --- > > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-objcopy > -X rump_vfs.po > --- spec_vnops.po --- > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-gcc > -O2 -fno-delete-null-pointer-checks -ffreestanding -fno-strict-aliasing > -msoft-float -mno-mmx -mno-sse -mno-avx -msoft-float -mno-mmx -mno-sse > -mno-avx -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional > -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual > -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror > -Wno-format-zero-length -Wno-pointer-sign -fPIE -fstack-protector > -Wstack-protector --param ssp-buffer-size=1 > --sysroot=/tmp/bracket/build/2020.03.14.18.08.40-i386/destdir -DCOMPAT_50 > -DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -nostdinc -imacros > /tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/include/opt/opt_rumpkernel.h > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs -I. > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../.. > /sys/rump/../../common/include > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/include > > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/include/opt > > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/../arch > > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/.. > -DDIAGNOSTIC -DKTRACE -D_FORTIFY_SOURCE=2 -c -DGPROF -DPROF-pg -fPIC > /tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/../miscfs/specfs/spec_vnops.c > -o spec_vnops.po > --- subr_bufq.pico --- > # compile librumpvfs/subr_bufq.pico > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-gcc > -O2 -fno-delete-null-pointer-checks -ffreestanding -fno-strict-aliasing > -msoft-float -mno-mmx -mno-sse -mno-avx -msoft-float -mno-mmx -mno-sse > -mno-avx -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional > -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual > -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror > -Wno-format-zero-length -Wno-pointer-sign -fPIE -fstack-protector > -Wstack-protector --param ssp-buffer-size=1 > --sysroot=/tmp/bracket/build/2020.03.14.18.08.40-i386/destdir -DCOMPAT_50 > -DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -nostdinc -imacros > /tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../../sys/rump/include/opt/opt_rumpkernel.h > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs -I. > -I/tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs/../.. > /sys/rump/../../common/include--- rumpvfs_if_wrappers.po --- > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/nbctfconvert -g -L > VERSION rumpvfs_if_wrappers.po > > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-objcopy > -X rumpvfs_if_wrappers.po > --- rumpblk.po --- > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/nbctfconvert -g -L > VERSION rumpblk.po > > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-objcopy > -X rumpblk.po > --- rumpvfs_if_wrappers.pico --- > > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-objcopy > -x rumpvfs_if_wrappers.pico > --- rumpvfs_syscalls.po --- > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/nbctfconvert -g -L > VERSION rumpvfs_syscalls.po > > /tmp/bracket/build/2020.03.14.18.08.40-i386/tools/bin/i486--netbsdelf-objcopy > -X rumpvfs_syscalls.po > --- genfs_io.pico --- > cc1: all warnings being treated as errors > *** [genfs_io.pico] Error code 1 > nbmake[7]: stopped in > /tmp/bracket/build/2020.03.14.18.08.40-i386/src/lib/librumpvfs > --- genfs_io.po --- > > The following commits were made between the last successful build and > the failed build: > > 2020.03.14.13.34.43 ad src/sys/arch/sparc/sparc/intr.c,v 1.124 > 2020.03.14.13.37.49 ad src/sys/fs/tmpfs/tmpfs_subr.c,v 1.107 > 2020.03.14.13.39.36 ad src/sys/fs/tmpfs/tmpfs_vnops.c,v 1.135 > 2020.03.14.13.50.46 ad src/sys/arch/x86/acpi/acpi_cpu_md.c,v 1.82 > 2020.03.14.13.53.26 ad src/sys/uvm/uvm_pdpolicy_clock.c,v 1.35 >
Re: Automated report: NetBSD-current/i386 build failure
On 07.03.2020 20:43, Andreas Gustafsson wrote: > The NetBSD Test Fixture wrote: >> cc1: all warnings being treated as errors >> *** [t_ptrace_wait.o] Error code 1 > > The compiler error message did not appare because it was too far > back from the end of the build log (5149 lines): > > --- dependall-sys --- > /tmp/bracket/build/2020.03.07.14.53.14-i386/src/tests/lib/libc/sys/t_ptrace_wait.c: > In function 'traceme_crash': > /tmp/bracket/build/2020.03.07.14.53.14-i386/src/tests/lib/libc/sys/t_ptrace_wait.c:441:24: > error: implicit declaration of function 'are_fpu_exceptions_supported'; did > you mean 'are_fpu_exceptions_supporter'? [-Werror=imp\ > licit-function-declaration] > if (sig == SIGFPE && !are_fpu_exceptions_supported()) > ^~~~ > are_fpu_exceptions_supporter > Fixed. signature.asc Description: OpenPGP digital signature
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > cc1: all warnings being treated as errors > *** [t_ptrace_wait.o] Error code 1 The compiler error message did not appare because it was too far back from the end of the build log (5149 lines): --- dependall-sys --- /tmp/bracket/build/2020.03.07.14.53.14-i386/src/tests/lib/libc/sys/t_ptrace_wait.c: In function 'traceme_crash': /tmp/bracket/build/2020.03.07.14.53.14-i386/src/tests/lib/libc/sys/t_ptrace_wait.c:441:24: error: implicit declaration of function 'are_fpu_exceptions_supported'; did you mean 'are_fpu_exceptions_supporter'? [-Werror=imp\ licit-function-declaration] if (sig == SIGFPE && !are_fpu_exceptions_supported()) ^~~~ are_fpu_exceptions_supporter -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
In article <20200303122717.gb...@mail.duskware.de>, Martin Husemann wrote: >On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote: >> Would it be too much to ask that imports of entire new subsystems like >> this be at least build tested with "build.sh release"? > >The lossage in this case seems to depend on -j values and whether you do >incremental builds, so not clearly detectable by a simple local build >(I was able to build sparc64 and evbarm earlier today localy, while the >build cluster still fails all the builds) Yup, I build amd64 and sun2 with no issues but when I built i386 with -j 60 I was able to reproduce it. christos
Re: Automated report: NetBSD-current/i386 build failure
On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote: > Would it be too much to ask that imports of entire new subsystems like > this be at least build tested with "build.sh release"? The lossage in this case seems to depend on -j values and whether you do incremental builds, so not clearly detectable by a simple local build (I was able to build sparc64 and evbarm earlier today localy, while the build cluster still fails all the builds) Martin
Re: Automated report: NetBSD-current/i386 build failure
NetBSD Test Fixture wrote: > *** [cleandir-pamu2fcfg] Error code 2 > nbmake[7]: stopped in > /tmp/bracket/build/2020.03.03.00.47.33-i386/src/external/bsd/pam-u2f/bin The build is still broken as of source date 2020.03.03.08.56.05: http://releng.netbsd.org/b5reports/i386/commits-2020.03.html#2020.03.03.08.56.05 Would it be too much to ask that imports of entire new subsystems like this be at least build tested with "build.sh release"? -- Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
> On Mar 1, 2020, at 8:05 AM, Andrius V wrote:
>
> Hi,
>
> Was the build failure noticed? Seems like this commit is at fault:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/if_stge.c.diff?r1=1.79=1.80_with_tag=MAIN=h
>
Working on this now.
> ../../../../dev/pci/if_stge.c: In function 'stge_attach':
> ../../../../dev/pci/if_stgereg.h:54:22: error: conversion from 'long
> long unsigned int' to 'bus_addr_t' {aka 'long unsigned int'} changes
> value from '68719476736' to '0' [-Werror=overflow]
> #define FRAG_ADDR(x) (((uint64_t)(x)) << 0)
> ../../../../dev/pci/if_stgereg.h:55:24: note: in expansion of macro
> 'FRAG_ADDR'
> #define FRAG_ADDR_MASK FRAG_ADDR(0xfULL)
>^
> ../../../../dev/pci/if_stge.c:453:7: note: in expansion of macro
> 'FRAG_ADDR_MASK'
> FRAG_ADDR_MASK + 1ULL,
> ^~
> cc1: all warnings being treated as errors
> *** Error code 1
>
>
> On Sun, Mar 1, 2020 at 3:06 AM 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.02.29.20.44.15.
>>
>> An extract from the build.sh output follows:
>>
>>--- umidi.d ---
>>#create LEGACY/umidi.d
>>
>> CC=/tmp/bracket/build/2020.02.29.20.44.15-i386/tools/bin/i486--netbsdelf-gcc
>> /tmp/bracket/build/2020.02.29.20.44.15-i386/tools/bin/nbmkdep -f umidi.d.tmp
>> -- -msoft-float -mno-mmx -mno-sse -mno-avx -mindirect-branch=thunk
>> -mindirect-branch-register -ffreestanding -fno-zero-initialized-in-bss
>> -fno-delete-null-pointer-checks -O2 -fno-omit-frame-pointer
>> -fstack-protector -Wstack-protector --param ssp-buffer-size=1
>> -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main
>> -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
>> -Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual
>> -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes
>> -Wextra -Wno-unused-parameter -Wold-style-definition -Wno-sign-compare
>> --sysroot=/tmp/bracket/build/2020.02.29.20.44.15-i386/destdir -Di386 -I.
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/acpica/dist
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bs
>> d/libnv/dist
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/../common/lib/libx86emu
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/../common/lib/libc/misc
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/../common/include
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/arch
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys -nostdinc
>> -DCOMPAT_UTILS -DDIAGNOSTIC -DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/lib/libkern/../../../common/lib/libc/quad
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/lib/libkern/../../../common/lib/libc/string
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string
>>-D_FORTIFY_SOURCE=2
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/isc/atheros_hal/dist
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/isc/atheros_hal/ic
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bs
>> d/common/include
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/common/include
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/include
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/include
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/include/drm
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/common/include
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/dist/include
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/dist/include/drm
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/dist/uapi
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/dist
>> -D__KERNEL__ -DCONFIG_BACKLIGHT_CLASS_DEVICE=0
>> -DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0 -DCONFIG_DRM_FBDEV_EMULATION=1
>> -DCONFIG_FB=0
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/../common/include
>> -I/tmp/bracket/build/2020.02.29.20
>> .44.15-i386/src/sys/external/bsd/libnv/dist
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/i915drm
>>
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/dist/drm/i915
>> -DCONFIG_DRM_I915_FBDEV=1 -DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0
>> -DCONFIG_DRM_FBDEV_EMULATION=1
>> -I/tmp/bracket/build/2020.02.29.20.44.15-i386/src/sys/external/bsd/drm2/include/radeon
>>
>>
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote:
> *** [hifn7751.o] Error code 1
> nbmake[8]: stopped in
> /tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/modules/hifn
Specifically:
--- dependall-hifn ---
In file included from
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:53:
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c: In
function 'hifn_rng_locked':
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:692:13:
error: comparison of integer expressions of different signedness: 'unsigned
int' and 'int' [-Werror=sign-compare]
nwords = MIN(__arraycount(num), nwords);
^~~
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:692:13:
error: operand of ?: changes signedness from 'int' to 'unsigned int' due to
unsignedness of other operand [-Werror=sign-compare]
nwords = MIN(__arraycount(num), nwords);
^~~
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c: In
function 'hifn_next_signature':
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:850:16:
error: comparison of integer expressions of different signedness: 'int' and
'u_int' {aka 'unsigned int'} [-Werror=sign-compare]
for (i = 0; i < cnt; i++) {
^
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c: In
function 'hifn_ramtype':
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:1134:16:
error: comparison of integer expressions of different signedness: 'int' and
'unsigned int' [-Werror=sign-compare]
for (i = 0; i < sizeof(data); i++)
^
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:1145:16:
error: comparison of integer expressions of different signedness: 'int' and
'unsigned int' [-Werror=sign-compare]
for (i = 0; i < sizeof(data); i++)
^
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c: In
function 'hifn_sramsize':
/tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/dev/pci/hifn7751.c:1171:16:
error: comparison of integer expressions of different signedness: 'int32_t'
{aka 'int'} and 'unsigned int' [-Werror=sign-compare]
for (i = 0; i < sizeof(data); i++)
^
--
Andreas Gustafsson, g...@gson.org
Re: Automated report: NetBSD-current/i386 build failure
On Thu, Feb 27, 2020 at 09:18:59AM +0200, Andreas Gustafsson wrote: > The NetBSD Test Fixture wrote: > > nbmake[8]: nbmake[8]: don't know how to make libpam_echo.so.. Stop > > This was fixed but the build is still broken as of 2020.02.27.03.25.08: > > # link rescue/rescue > [...] > > /tmp/bracket/build/2020.02.27.03.25.08-i386/tools/lib/gcc/i486--netbsdelf/8.3.0/../../../../i486--netbsdelf/bin/ld: > > /tmp/bracket/build/2020.02.27.03.25.08-i386/destdir/usr/lib/libssh.a(sshkey.o): > in function `.L1885': > sshkey.c:(.text+0x83d9): undefined reference to `sshsk_sign' > collect2: error: ld returned 1 exit status > *** [rescue] Error code 1 > > More logs: > > > http://releng.netbsd.org/b5reports/i386/commits-2020.02.html#2020.02.27.03.25.08 > > -- > Andreas Gustafsson, g...@gson.org Confirmed on amd64 also. -- Best, Rares
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > nbmake[8]: nbmake[8]: don't know how to make libpam_echo.so.. Stop This was fixed but the build is still broken as of 2020.02.27.03.25.08: # link rescue/rescue [...] /tmp/bracket/build/2020.02.27.03.25.08-i386/tools/lib/gcc/i486--netbsdelf/8.3.0/../../../../i486--netbsdelf/bin/ld: /tmp/bracket/build/2020.02.27.03.25.08-i386/destdir/usr/lib/libssh.a(sshkey.o): in function `.L1885': sshkey.c:(.text+0x83d9): undefined reference to `sshsk_sign' collect2: error: ld returned 1 exit status *** [rescue] Error code 1 More logs: http://releng.netbsd.org/b5reports/i386/commits-2020.02.html#2020.02.27.03.25.08 -- Andreas Gustafsson, g...@gson.org
