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 2015.10.30.18.04.42. An extract from the build.sh output follows: #create libc/strtoimax.d --- strtok.d --- #create libc/strtok.d --- strtoimax.d --- CC=/tmp/bracket/build/2015.10.30.18.04.42-i386/tools/bin/i486--netbsdelf-gcc /tmp/bracket/build/2015.10.30.18.04.42-i386/tools/bin/nbmkdep -f strtoimax.d.tmp -- -std=gnu99 --sysroot=/tmp/bracket/build/2015.10.30.18.04.42-i386/destdir -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -D_DIAGNOSTIC -DHESIOD -DINET6 -DNLS -DYP -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/include -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/sys -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/compat/../locale -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/compat/stdlib -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/compat/../stdlib -D__BUILD_LEGACY -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/../../common/lib/libc/quad -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/../../common/lib/libc/string -I/tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/. ./../common/lib/libc/arch/i386/string --- strptime.d --- /tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc/time/strptime.c:472:2: error: #endif without #if #endif ^ nbmkdep: compile failed. *** [strptime.d] Error code 1 nbmake[6]: stopped in /tmp/bracket/build/2015.10.30.18.04.42-i386/src/lib/libc --- strtoimax.d --- The following commits were made between the last successful build and the failed build: 2015.10.30.16.21.46 tsutsui src/sys/arch/sparc64/dev/zs.c,v 1.75 2015.10.30.18.04.42 christos src/lib/libc/time/strptime.c,v 1.54 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2015.10.html#2015.10.30.18.04.42
Re: showstopper, libGL error with (at least) radeon in -current
On Fri, 30 Oct 2015 17:49:28 +0100 Reinoud Zandijk wrote: > I've just basically re-installed my NetBSD/amd64 to -current of the 26st of > October and I'm running into libGL init issues: > > > glxgears > libGL error: unable to load driver: r600_dri.so > Any ideas? Check /var/log/Xorg.0.log if Xorg itself was able to load r600_dri.so. It might provide more useful diagnostics than glxgears. You should see lines similar to: [26.881] (II) RADEON(0): [DRI2] Setup complete [26.881] (II) RADEON(0): [DRI2] DRI driver: r600 [26.881] (II) RADEON(0): [DRI2] VDPAU driver: r600 [26.963] (II) AIGLX: Loaded and initialized r600 [26.963] (II) GLX: Initialized DRI2 GL provider for screen 0 (HD5450, current amd64, pkgsrc X.org) -Tobias
Re: showstopper, libGL error with (at least) radeon in -current
On Fri, 30 Oct 2015 17:49:28 +0100,Reinoud Zandijk wrote: > libGL error: unable to load driver: r600_dri.so > > libGL error: driver pointer missing > libGL error: failed to load driver: r600 > libGL error: unable to load driver: swrast_dri.so > libGL error: failed to load driver: swrast i saw same things by glxgears, glxinfo, mpv. $ ls -l /usr/X11R7/lib/modules/dri/ total 17520 lrwxr-xr-x 1 root wheel 16 Oct 29 23:57 gallium_dri.so -> gallium_dri.so.0 -r--r--r-- 1 root wheel 7988396 Oct 29 23:57 gallium_dri.so.0 lrwxr-xr-x 1 root wheel 13 Aug 28 01:00 i915_dri.so -> i915_dri.so.0 lrwxr-xr-x 1 root wheel 21 Aug 28 01:00 i915_dri.so.0 -> mesa_dri_drivers.so.0 lrwxr-xr-x 1 root wheel 13 Aug 28 01:00 i965_dri.so -> i965_dri.so.0 lrwxr-xr-x 1 root wheel 21 Aug 28 01:00 i965_dri.so.0 -> mesa_dri_drivers.so.0 lrwxr-xr-x 1 root wheel 14 Aug 28 01:00 kms_swrast_dri.so -> gallium_dri.so lrwxr-xr-x 1 root wheel 16 Aug 28 01:00 kms_swrast_dri.so.0 -> gallium_dri.so.0 lrwxr-xr-x 1 root wheel 16 Oct 29 23:57 libmesa_dri.so -> libmesa_dri.so.0 -r--r--r-- 1 root wheel 3521735 Oct 29 23:57 libmesa_dri.so.0 lrwxr-xr-x 1 root wheel 21 Oct 29 23:57 mesa_dri_drivers.so -> mesa_dri_drivers.so.0 -r--r--r-- 1 root wheel 5735252 Oct 29 23:57 mesa_dri_drivers.so.0 lrwxr-xr-x 1 root wheel 14 Oct 27 19:32 nouveau_dri.so -> gallium_dri.so lrwxr-xr-x 1 root wheel 16 Oct 27 19:32 nouveau_dri.so.0 -> gallium_dri.so.0 lrwxr-xr-x 1 root wheel 13 Aug 28 01:00 r200_dri.so -> r200_dri.so.0 lrwxr-xr-x 1 root wheel 21 Aug 28 01:00 r200_dri.so.0 -> mesa_dri_drivers.so.0 lrwxr-xr-x 1 root wheel 13 Oct 29 23:57 r300_dri.so -> r300_dri.so.0 -r--r--r-- 1 root wheel 599561 Oct 29 23:57 r300_dri.so.0 lrwxr-xr-x 1 root wheel 14 Aug 28 01:00 r600_dri.so -> gallium_dri.so lrwxr-xr-x 1 root wheel 16 Aug 28 01:00 r600_dri.so.0 -> gallium_dri.so.0 lrwxr-xr-x 1 root wheel 15 Aug 28 01:00 radeon_dri.so -> radeon_dri.so.0 lrwxr-xr-x 1 root wheel 21 Aug 28 01:00 radeon_dri.so.0 -> mesa_dri_drivers.so.0 lrwxr-xr-x 1 root wheel 14 Aug 28 01:00 swrast_dri.so -> gallium_dri.so lrwxr-xr-x 1 root wheel 16 Aug 28 01:00 swrast_dri.so.0 -> gallium_dri.so.0 -- Ryosuke
showstopper, libGL error with (at least) radeon in -current
Hi folks, I've just basically re-installed my NetBSD/amd64 to -current of the 26st of October and I'm running into libGL init issues: > glxgears libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL error: failed to load driver: r600 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. ... Looking at the ktrace I don't see any obvious issues nor am I seeing any missing dependencies. It runs on: radeon0 at pci2 dev 0 function 0: vendor 1002 product 9440 (rev. 0x00) drm: initializing kernel modesetting (RV770 0x1002:0x9440 0x174B:0x114A). Any ideas? With regards, Reinoud signature.asc Description: PGP signature
Re: build problem: external/bsd/ntp/dist/ntpd/
Date:Fri, 30 Oct 2015 12:26:09 +1100 From:Geoff Wing Message-ID: <20151030012609.ga7...@primenet.com.au> | recently external/bsd/ntp/dist/ntpd/ntp_parser.[ch] have been | built in the source directories, presumably from ntp_parser.y | Obviously this is not the right spot for them. I haven't seen | a fix in the last couple of days but may have missed it. The problem has been around for a while, xsrc/50098 is a PR that's related to the same issue. There's clearly some build issue with translating .y and .l files and where the results are placed. kre
