Re: aarch64-current build failure

[Chavdar Ivanov]

On Sun, 12 May 2024 at 09:14, Chavdar Ivanov  wrote:
>
> Hi,
>
> I am getting:
> 
> #create  libEGL/loader.d
> CC=/dumps/sysbuild/evbarm64/tools/bin/aarch64--netbsd-gcc
> /dumps/sysbuild/evbarm64/tools/bin/nbmkdep -f loader.d.tmp  --
> -std=gnu99 -Werror  --sysroot=/dumps/sysbuild/evbarm64/de
> stdir -I/usr/xsrc/external/mit/MesaLib/dist/include
> -I/usr/xsrc/external/mit/MesaLib/dist/include/drm-uapi
> -I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/main
> -I/usr/xsrc/external/m
> it/MesaLib/dist/src/egl/main
> -I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/backends/dri
> -I/usr/xsrc/external/mit/MesaLib/dist/src/loader
> -I/usr/xsrc/external/mit/MesaLib/dist/src -
> I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include/libdrm
> -DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"
> -D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_X11 -D_EGL_DRIVER_SEARCH_DIR=\"/
> usr/X11R7/lib\" -D_EGL_OS_UNIX=1 -DHAVE_X11_PLATFORM
> -DHAVE_DRM_PLATFORM -DHAVE_TIMESPEC_GET -DHAVE_PTHREAD -DHAVE_LIBDRM
> -DHAVE_MINCORE -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -
> I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include
> -I/usr/xsrc/external/mit/MesaLib/dist/src/util
> -I/usr/xsrc/external/mit/MesaLib/dist/../src/util
> -I/usr/xsrc/external/mit/M
> esaLib/dist/src/mesa  -I/usr/xsrc/external/mit/MesaLib/dist/src
> -DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"  -DUSE_DRICONF
> -DHAVE_LIBDRM /usr/xsrc/external/mit/MesaLib.ol
> d/dist/src/loader/loader.c &&  mv -f loader.d.tmp loader.d
> /usr/xsrc/external/mit/MesaLib.old/dist/src/loader/loader.c:54:10:
> fatal error: util/xmlpool.h: No such file or directory
>54 | #include "util/xmlpool.h"
>   |  ^~~~
>
> 
>

Must have been failure of the update build - after several attempts I
wiped out obj, destdir and tools and the build finished.

> Chavdar
>
>
> --
> 



-- 

aarch64-current build failure

[Chavdar Ivanov]

Hi,

I am getting:

#create  libEGL/loader.d
CC=/dumps/sysbuild/evbarm64/tools/bin/aarch64--netbsd-gcc
/dumps/sysbuild/evbarm64/tools/bin/nbmkdep -f loader.d.tmp  --
-std=gnu99 -Werror  --sysroot=/dumps/sysbuild/evbarm64/de
stdir -I/usr/xsrc/external/mit/MesaLib/dist/include
-I/usr/xsrc/external/mit/MesaLib/dist/include/drm-uapi
-I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/main
-I/usr/xsrc/external/m
it/MesaLib/dist/src/egl/main
-I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/backends/dri
-I/usr/xsrc/external/mit/MesaLib/dist/src/loader
-I/usr/xsrc/external/mit/MesaLib/dist/src -
I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include/libdrm
-DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"
-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_X11 -D_EGL_DRIVER_SEARCH_DIR=\"/
usr/X11R7/lib\" -D_EGL_OS_UNIX=1 -DHAVE_X11_PLATFORM
-DHAVE_DRM_PLATFORM -DHAVE_TIMESPEC_GET -DHAVE_PTHREAD -DHAVE_LIBDRM
-DHAVE_MINCORE -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -
I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include
-I/usr/xsrc/external/mit/MesaLib/dist/src/util
-I/usr/xsrc/external/mit/MesaLib/dist/../src/util
-I/usr/xsrc/external/mit/M
esaLib/dist/src/mesa  -I/usr/xsrc/external/mit/MesaLib/dist/src
-DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"  -DUSE_DRICONF
-DHAVE_LIBDRM /usr/xsrc/external/mit/MesaLib.ol
d/dist/src/loader/loader.c &&  mv -f loader.d.tmp loader.d
/usr/xsrc/external/mit/MesaLib.old/dist/src/loader/loader.c:54:10:
fatal error: util/xmlpool.h: No such file or directory
   54 | #include "util/xmlpool.h"
  |  ^~~~



Chavdar


-- 

Re: i386 -current build failure

[Chavdar Ivanov]

On Mon, 14 Aug 2023 at 13:50, Chavdar Ivanov  wrote:
>
> On Mon, 14 Aug 2023 at 10:35, Martin Husemann  wrote:
> >
> > On Mon, Aug 14, 2023 at 09:23:37AM +0100, Chavdar Ivanov wrote:
> > > Hi,
> > > ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
> > > from C sources, but no CTF data was present
> >
> > Can you reproduce it after removing that .o file (or the whole kernel build
> > directory)?
>
> I did reproduce it once more after removing that .o file. Subsequently
> I nuked the entire obj directory and restarted.
>
> I suspect this was a result of my previous attempt to build it on that
> particular host using NJOBS=4 - it is a quite old now system with an
> i7-2600K CPU on an Intel motherboard; it has some memory problems
> under heavier multicore load (memtest+ passes each individual stick
> fine, but whenever more than one stick is in use, any conbination of
> the four, two tests fail, one of them Intel says is not actually a
> failure, but apparently the other is...). I run the builds normally
> with NJOBS=1 and I am now so repeating the full i386 build.

 which completed OK; there were no intervening cvs updates at all,
so the reason for the failure must have been exactly the above.

> >
> > This symptom often shows up when one of the ctf tools died in an earlier
> > run.
> >
> > Martin
>
> Chavdar
>
>
> --
> 



-- 

Re: i386 -current build failure

[Chavdar Ivanov]

On Mon, 14 Aug 2023 at 10:35, Martin Husemann  wrote:
>
> On Mon, Aug 14, 2023 at 09:23:37AM +0100, Chavdar Ivanov wrote:
> > Hi,
> > ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
> > from C sources, but no CTF data was present
>
> Can you reproduce it after removing that .o file (or the whole kernel build
> directory)?

I did reproduce it once more after removing that .o file. Subsequently
I nuked the entire obj directory and restarted.

I suspect this was a result of my previous attempt to build it on that
particular host using NJOBS=4 - it is a quite old now system with an
i7-2600K CPU on an Intel motherboard; it has some memory problems
under heavier multicore load (memtest+ passes each individual stick
fine, but whenever more than one stick is in use, any conbination of
the four, two tests fail, one of them Intel says is not actually a
failure, but apparently the other is...). I run the builds normally
with NJOBS=1 and I am now so repeating the full i386 build.
>
> This symptom often shows up when one of the ctf tools died in an earlier
> run.
>
> Martin

Chavdar


-- 

Re: i386 -current build failure

[Martin Husemann]

On Mon, Aug 14, 2023 at 09:23:37AM +0100, Chavdar Ivanov wrote:
> Hi,
> ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
> from C sources, but no CTF data was present

Can you reproduce it after removing that .o file (or the whole kernel build
directory)?

This symptom often shows up when one of the ctf tools died in an earlier
run.

Martin

i386 -current build failure

[Chavdar Ivanov]

Hi,

Does anybody else get the following while building i396 -current:

---
#  link  INSTALL_XEN3PAE_DOMU/netbsd
/dumps/sysbuild/i386/tools/bin/i486--netbsdelf-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0xc010 -e start -X -o netbsd
${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
/dumps/sysbuild/i386/tools/bin/i486--netbsdelf-ld: warning: netbsd has
a LOAD segment with RWX permissions
NetBSD 10.99.7 (INSTALL_XEN3PAE_DOMU) #2: Mon Aug 14 01:43:53 BST 2023
   textdata bss dec hex filename
6066821 5262648 1622016 12951485 c59fbd netbsd
ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
from C sources, but no CTF data was present

*** Failed target: netbsd
*** Failed commands:
${SYSTEM_LD_HEAD}
=> @rm -f netbsd
${SYSTEM_LD}
=> echo '#  ' "   link  INSTALL_XEN3PAE_DOMU/netbsd";
--

Chavdar


-- 

Re: -current build failure

[Thomas Klausner]

On Mon, Jun 05, 2023 at 03:01:37AM +1000, Luke Mewburn wrote:
> I managed to reproduced this just building the tools with -V MKLLVM=yes.
> I've reverted tools/Makefile.host revision 1.35 and it seems to fix the
> tools build for me.
> 
> Does this resolve the issue for you?

Yes.

Now I just have a setlists problem:

===  10 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/tests/libexec/ld.elf_so/libh_abuse_dynamic_g.a
./usr/tests/libexec/ld.elf_so/libh_abuse_static_g.a
./usr/tests/libexec/ld.elf_so/libh_def_dynamic_g.a
./usr/tests/libexec/ld.elf_so/libh_def_static_g.a
./usr/tests/libexec/ld.elf_so/libh_onlyctor_dynamic_g.a
./usr/tests/libexec/ld.elf_so/libh_onlydef_g.a
./usr/tests/libexec/ld.elf_so/libh_onlyuse_dynamic_g.a
./usr/tests/libexec/ld.elf_so/libh_onlyuse_static_g.a
./usr/tests/libexec/ld.elf_so/libh_use_dynamic_g.a
./usr/tests/libexec/ld.elf_so/libh_use_static_g.a
=  end of 10 extra files  ===

 Thomas

Re: -current build failure

[Luke Mewburn]

On 23-06-05 03:01, I wrote:
  | BTW: I don't know why replacing
  | NOINFO= # defined
  | NOLINT= # defined
  | NOMAN=  # defined
  | MKREPRO=no # Native toolchain might be unable to do it
  | .include 
  | 
  | with 
  | .include 
  | 
  | where bsd.hostinit.mk is:
  | NOINFO= # defined
  | NOLINT= # defined
  | NOMAN=  # defined
  | MKREPRO=no  # Native toolchain might be unable to do it
  | .include 
  | 
  | and bsd.init.mk:
  | .-include "${.CURDIR}/../Makefile.inc"
  | .include 
  | .MAIN: all
  | 
  | causes such issues with tools/llvm*.
  | Maybe something in the ../Makefile.inc, or the .MAIN:all ?
  | 
  | 
  | I didn't have time to debug, easier to revert my change.

It looks like Christos already ran into this problem in 2018
when he first implemented !
Per tools/Makefile.host history:


revision 1.34
date: 2018-05-05 00:50:18 +1000;  author: christos;  state: Exp;  lines: +7 -2; 
 commitid: SGtsHWSE1y0IqZAA;
revert previous, breaks llvm build and not easy to fix.

revision 1.33
date: 2018-05-02 05:59:46 +1000;  author: christos;  state: Exp;  lines: +2 -7; 
 commitid: 10Ge8
dYtIFEjeDAA;
Create a new bsd.hostinit.mk file and put the build definitions for all host
programs there; make all Makefiles that use bsd.hostprog.mk include it.
Namely turn off MKREPRO and don't make lint, man pages, info files etc.
Remove the Makefile.inc files that contained these same settings, and
remove the settings from Makefile.host

Re: -current build failure

[Luke Mewburn]

On 23-06-04 14:40, Thomas Klausner wrote:
  | Hi!
  | 
  | I just tried updating my -current but the build failed:
  | 
  | build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -V 
NOGCCERROR=yes -T /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
/usr/obj/amd64.gcc.20230604 -R /usr/obj/amd64.gcc.20230604.release distribution
  | 
  | --- support-modules ---
  | g++: error: unrecognized command-line option '-stdlib=libc++'
  | g++: error: unrecognized command-line option '-fmodules'; did you mean 
'-fmoduleinfo'?
  | g++: error: unrecognized command-line option '-fcxx-modules'
  | g++: error: unrecognized command-line option 
'-fmodules-cache-path=./module.cache'
  | 
  | 
  | Any ideas how to fix this?
  | 

I managed to reproduced this just building the tools with -V MKLLVM=yes.
I've reverted tools/Makefile.host revision 1.35 and it seems to fix the
tools build for me.

Does this resolve the issue for you?


BTW: I don't know why replacing
NOINFO= # defined
NOLINT= # defined
NOMAN=  # defined
MKREPRO=no # Native toolchain might be unable to do it
.include 

with 
.include 

where bsd.hostinit.mk is:
NOINFO= # defined
NOLINT= # defined
NOMAN=  # defined
MKREPRO=no  # Native toolchain might be unable to do it
.include 

and bsd.init.mk:
.-include "${.CURDIR}/../Makefile.inc"
.include 
.MAIN: all

causes such issues with tools/llvm*.
Maybe something in the ../Makefile.inc, or the .MAIN:all ?


I didn't have time to debug, easier to revert my change.

Luke.

Re: -current build failure

[Martin Husemann]

On Sun, Jun 04, 2023 at 02:40:16PM +0200, Thomas Klausner wrote:
> Hi!
> 
> I just tried updating my -current but the build failed:
> 
> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -V 
> NOGCCERROR=yes -T /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
> /usr/obj/amd64.gcc.20230604 -R /usr/obj/amd64.gcc.20230604.release 
> distribution
> 
> --- support-modules ---
> g++: error: unrecognized command-line option '-stdlib=libc++'
> g++: error: unrecognized command-line option '-fmodules'; did you mean 
> '-fmoduleinfo'?
> g++: error: unrecognized command-line option '-fcxx-modules'
> g++: error: unrecognized command-line option 
> '-fmodules-cache-path=./module.cache'
> 
> 
> Any ideas how to fix this?

I couldn't even compile a amd64 GENERIC kernel w/o the attached patch -
CC_WNO_ADDRESS_OF_PACKED_MEMBER is undefined in kernel builds
(but that hack sounds like the wrong way to fix things).

Luke, what would be the correct fix?

Martin
Index: Makefile.amd64
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/Makefile.amd64,v
retrieving revision 1.86
diff -u -p -r1.86 Makefile.amd64
--- Makefile.amd64  6 Jan 2023 15:35:06 -   1.86
+++ Makefile.amd64  4 Jun 2023 13:49:07 -
@@ -22,6 +22,7 @@ USETOOLS?=no
 NEED_OWN_INSTALL_TARGET?=no
 NOSANITIZER=
 .include 
+.include 
 
 USE_SSP?=  yes
 

-current build failure

[Thomas Klausner]

Hi!

I just tried updating my -current but the build failed:

build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -V 
NOGCCERROR=yes -T /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
/usr/obj/amd64.gcc.20230604 -R /usr/obj/amd64.gcc.20230604.release distribution

--- support-modules ---
g++: error: unrecognized command-line option '-stdlib=libc++'
g++: error: unrecognized command-line option '-fmodules'; did you mean 
'-fmoduleinfo'?
g++: error: unrecognized command-line option '-fcxx-modules'
g++: error: unrecognized command-line option 
'-fmodules-cache-path=./module.cache'


Any ideas how to fix this?

Cheers,
 Thomas

Re: -current build failure?

[Chavdar Ivanov]

On 30 December 2022 14:26:09 (+00:00), Martin Husemann wrote:

> On Fri, Dec 30, 2022 at 01:04:46PM +, Chavdar Ivanov wrote:
> > Hi,
> > 
> > I am getting again a failure in binutils.old, after having cleaned 
four days

> > ago the entire obj:
> 
> binutils.old is the wrong directory, your build should use binutils now.

> You need to clean the tools/binutils obj dir.
Thanks. 


There appear to be some missing merges?

...


sysbuild: I: Running 'cvs -danon...@anoncvs.netbsd.org:/cvsroot -q update 
-d -P' in /home/sysbuild/src

M external/gpl3/binutils/dist/bfd/doc/bfd.info
M external/gpl3/binutils/dist/gas/config/m68k-parse.c

...

> 


> Martin

> 


--

Chavdar Ivanov

Re: -current build failure?

[Martin Husemann]

On Fri, Dec 30, 2022 at 01:04:46PM +, Chavdar Ivanov wrote:
> Hi,
> 
> I am getting again a failure in binutils.old, after having cleaned four days
> ago the entire obj:

binutils.old is the wrong directory, your build should use binutils now.
You need to clean the tools/binutils obj dir.

Martin

-current build failure?

[Chavdar Ivanov]

Hi, 

I am getting again a failure in binutils.old, after having cleaned four 
days ago the entire obj:

...


  CC   archive.lo
In file included from 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/archive.c:134:


/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:127:1: 
warning: function declaration isn't a prototype [-Wstrict-prototypes]

  127 | extern void free ();
  | ^~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:131:1: 
warning: function declaration isn't a prototype [-Wstrict-prototypes]

  131 | extern char *getenv ();
  | ^~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:135:8: 
error: unknown type name 'PTR'

  135 | extern PTR malloc ();
  |^~~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:135:1: 
warning: function declaration isn't a prototype [-Wstrict-prototypes]

  135 | extern PTR malloc ();
  | ^~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:135:12: 
error: conflicting types for 'malloc'

  135 | extern PTR malloc ();
  |^~
In file included from 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:60,
 
from 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/archive.c:134:


/usr/include/stdlib.h:117:7: note: previous declaration of 'malloc' was 
here

  117 | void *malloc(size_t);
  |   ^~


--

Chavdar Ivanov

re: amd64 -current build failure

[matthew green]

matthew green writes:
> > manual xkeyboard-config.7 matches @.*@, probably missing updates
> > *** [xkeyboard-config.7] Error code 1
>
> hmm, i thought i commited this fix for this.. but nope, i
> only had it sitting in my tree.
>
> please try again with
> src/external/mit/xorg/lib/xkeyboard-config/Makefile 1.14

you also want the altest from src/distrib/sets/lists.


.mrg.

re: amd64 -current build failure

[matthew green]

> manual xkeyboard-config.7 matches @.*@, probably missing updates
> *** [xkeyboard-config.7] Error code 1

hmm, i thought i commited this fix for this.. but nope, i
only had it sitting in my tree.

please try again with
src/external/mit/xorg/lib/xkeyboard-config/Makefile 1.14


.mrg.

amd64 -current build failure

[Chavdar Ivanov]

Hi,

I am getting, three times in a row:
...
--- xkeyboard-config.pc ---
if /home/sysbuild/amd64/tools/bin/nbsed -e '/tab(@)/,/^\.TE/d' -e
'/^\.IN /d' xkeyboard-config.pc.tmp |
/home/sysbuild/amd64/tools/bin/nbgrep -E '@([^
]+)@'; then  echo "pkg-config xkeyboard-config.pc matches
@.*@, probably missing updates" 1>&2;  false;  else  mv -f
xkeyboard-config.pc.tmp xkeyboard-config.pc;  fi
--- xkeyboard-config.7 ---
@xkb_base@/compat
@xkb_base@/compiled
@xkb_base@/geometry
@xkb_base@/keycodes
@xkb_base@/keymap
@xkb_base@/rules
@xkb_base@/semantics
@xkb_base@/symbols
@xkb_base@/types
manual xkeyboard-config.7 matches @.*@, probably missing updates
*** [xkeyboard-config.7] Error code 1
nbmake[7]: stopped in /home/sysbuild/src/external/mit/xorg/lib/xkeyboard-config
1 error
nbmake[7]: stopped in /home/sysbuild/src/external/mit/xorg/lib/xkeyboard-config
*** Failed target:  dependall-xkeyboard-config
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this="external/mit/xorg/lib/";
real="/home/sysbuild/src/external/mit/xorg/lib" ;; *)
this="external/mit/xorg/lib/${dir}/";
real="/home/sysbuild/src/external/mit/xorg/lib/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" && /home/sysbuild/amd64/tools/bin/nbmake _THISDIR_="${this}"
"$@" ${target}; }; _makedirtarget xkeyboard-config dependall
*** Error code 2
*** [build_install] Error code 1
nbmake[4]: stopped in /home/sysbuild/src/external/mit/xorg/lib
1 error
nbmake[4]: stopped in /home/sysbuild/src/external/mit/xorg/lib

ERROR: Failed to make release
*** BUILD ABORTED ***
sysbuild: W: Command failed with code 1
.

On the last attempt I did clean the obj directory, as well as did a '
make cleandir' in the src directory - which is the usual I do first
when the build fails - to no avail.

Chavdar


-- 

Re: -current build failure

[Thomas Klausner]

On Wed, Sep 30, 2020 at 08:24:10AM +0100, Chavdar Ivanov wrote:
> --- install-tests ---
> x86_64--netbsd-install:
> /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile.inst.dY8rCE:
> mkstemp: No such file or directory

Fixed a short while ago.
 Thomas
--- Begin Message ---
Module Name:src
Committed By:   mrg
Date:   Wed Sep 30 07:55:31 UTC 2020

Modified Files:
src/etc/mtree: NetBSD.dist.tests

Log Message:
add missing new if_vether subdir.


To generate a diff of this commit:
cvs rdiff -u -r1.176 -r1.177 src/etc/mtree/NetBSD.dist.tests

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/etc/mtree/NetBSD.dist.tests
diff -u src/etc/mtree/NetBSD.dist.tests:1.176 src/etc/mtree/NetBSD.dist.tests:1.177
--- src/etc/mtree/NetBSD.dist.tests:1.176	Wed Aug 26 16:03:41 2020
+++ src/etc/mtree/NetBSD.dist.tests	Wed Sep 30 07:55:31 2020
@@ -1,4 +1,4 @@
-#	$NetBSD: NetBSD.dist.tests,v 1.176 2020/08/26 16:03:41 riastradh Exp $
+#	$NetBSD: NetBSD.dist.tests,v 1.177 2020/09/30 07:55:31 mrg Exp $
 
 ./usr/libdata/debug/usr/tests
 ./usr/libdata/debug/usr/tests/atf
@@ -357,6 +357,7 @@
 ./usr/tests/net/if_pppoe
 ./usr/tests/net/if_tap
 ./usr/tests/net/if_tun
+./usr/tests/net/if_vether
 ./usr/tests/net/if_vlan
 ./usr/tests/net/if_wg
 ./usr/tests/net/in_cksum

--- End Message ---

-current build failure

[Chavdar Ivanov]

Hi,

I am getting:

--- install-tests ---
--- /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile ---
#   install  /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-install -U -M
/home/sysbuild/amd64/destdir/METALOG -D /home/sysbuild/amd64/destdir
-h sha256 -N /home/sysbuild/src/etc -c -p -r  -o root  -g wheel  -m
444   Atffile /home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile
--- install-external ---
--- install-doc ---
--- install-share ---
install ===> share/man/man8/man8.sgimips
--- install-tests ---
x86_64--netbsd-install:
/home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile.inst.dY8rCE:
mkstemp: No such file or directory
*** [/home/sysbuild/amd64/destdir/usr/tests/net/if_vether/Atffile] Error code 1
--- install-external ---
install ===> external/gpl2/groff/doc
--- install-share ---
--- install-sys ---

ERROR: Failed to make release
.



-- 

Re: -current build failure

[Chavdar Ivanov]

Hi,

Builds now.

On Sun, 9 Aug 2020 at 10:38, Chavdar Ivanov  wrote:
>
> Hi,
>
> With sources just updated, I am getting:
> 
> #  link  INSTALL_XEN3_DOMU/netbsd
> ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020
> -e start -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ}
> vers.o swapnetbsd.o
> ld: netbsd32_mod.o: in function `amd64_oosyscall_handle':
> netbsd32_mod.c:(.text+0x111): undefined reference to `x86_cpu_is_lcall'
> *** Error code 1
> .
>
> Chavdar
>
>
> --
> 



-- 

-current build failure

[Chavdar Ivanov]

Hi,

With sources just updated, I am getting:

#  link  INSTALL_XEN3_DOMU/netbsd
ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020
-e start -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ}
vers.o swapnetbsd.o
ld: netbsd32_mod.o: in function `amd64_oosyscall_handle':
netbsd32_mod.c:(.text+0x111): undefined reference to `x86_cpu_is_lcall'
*** Error code 1
.

Chavdar


-- 

Re: early tools -current build failure

[Chavdar Ivanov]

Ok, thanks.

On Sun, 19 Jul 2020 at 13:51, Martin Husemann  wrote:

> On Sun, Jul 19, 2020 at 01:42:30PM +0100, Chavdar Ivanov wrote:
> > Any ideas? Perhaps I've missed something new in the BUILDING file?
> > there is nothing particular in these two lines of the bsd.nls.mk:
>
> make(1) is broken right now.
>
> Martin
>
-- 

Re: early tools -current build failure

[Martin Husemann]

On Sun, Jul 19, 2020 at 01:42:30PM +0100, Chavdar Ivanov wrote:
> Any ideas? Perhaps I've missed something new in the BUILDING file?
> there is nothing particular in these two lines of the bsd.nls.mk:

make(1) is broken right now.

Martin

early tools -current build failure

[Chavdar Ivanov]

Hi,

My attempt to build -current amd64 failed twice today; after the first
failure I moved aside the obj and tools directory and did 'make
cleandir', essentially starting from scratch; it failed identically:
...
 build.sh command:./build.sh -D/home/sysbuild/amd64/destdir
-M/home/sysbuild/amd64/obj -N2 -R/home/sysbuild/release
-T/home/sysbuild/amd64/tools -U -X/home/sysbuild/xsrc -j4 -mamd64 -u
-x release iso-image
..

cc  -D_PATH_DEFSYSPATH="/home/sysbuild/src/share/mk"
-DDEFSHELL_CUSTOM="/bin/sh" -DHAVE_SETENV=1 -DHAVE_STRDUP=1
-DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_VSNPRINTF=1  -O -c
/home/sysbuild/src/usr.bin/make/lst.lib/lstSucc.c
cc -o nbmake *.o
===> MAKECONF file:   /etc/mk.conf
#objdir  /home/sysbuild/amd64/obj/home/sysbuild/src/tools
nbmake: "/home/sysbuild/src/share/mk/bsd.nls.mk" line 18: Unknown directive
nbmake: "/home/sysbuild/src/share/mk/bsd.nls.mk" line 19: Unknown directive
nbmake: Fatal errors encountered -- cannot continue
ERROR: bomb_getmakevar TOOLDIR: /tmp/nbbuild81/nbmake failed
*** BUILD ABORTED ***
sysbuild: W: Command failed with code 1
-- 

Any ideas? Perhaps I've missed something new in the BUILDING file?
there is nothing particular in these two lines of the bsd.nls.mk:
.
# Build rules
.if ${MKNLS} != "no"

NLSALL= ${NLS:.msg=.cat}

realall:${NLSALL}   < 18
.NOPATH:${NLSALL}

.SUFFIXES: .cat .msg
.



Chavdar

Re: -current build failure

[Manuel Bouyer]

On Wed, May 27, 2020 at 06:54:47PM +0100, Chavdar Ivanov wrote:
> Hi,
> 
> With sources updated about an hour ago I get:
> .
> --- kern-XEN3_DOM0 ---
> /home/sysbuild/amd64/tools/bin/x86_64--netbsd-ld: pintr.o: in function
> `xen_pic_to_gsi':
> pintr.c:(.text+0x78): undefined reference to `msipic_get_pci_info'
> /home/sysbuild/amd64/tools/bin/x86_64--netbsd-ld: pci_intr_machdep.o:
> in function `pci_intr_release':
> pci_intr_machdep.c:(.text+0x775): undefined reference to 
> `x86_pci_msix_release'

Did you clean the build directory ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: -current build failure - flist

[Robert Elz]

Date:Sun, 5 Apr 2020 00:41:20 +0100
From:Chavdar Ivanov 
Message-ID:  


  | It appears a flist hasn't been updated after the bfd upgrade:

That has since been fixed (by Christos).

kre

-current build failure - flist

[Chavdar Ivanov]

Hi,

It appears a flist hasn't been updated after the bfd upgrade:

===  8 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/lib/i386/libbfd.so.16
./usr/lib/i386/libbfd.so.16.0
./usr/lib/i386/libopcodes.so.9
./usr/lib/i386/libopcodes.so.9.0
./usr/lib/libbfd.so.16
./usr/lib/libbfd.so.16.0
./usr/lib/libopcodes.so.9
./usr/lib/libopcodes.so.9.0
=  end of 8 extra files  ===
==  8 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/lib/i386/libbfd.so.15
./usr/lib/i386/libbfd.so.15.0
./usr/lib/i386/libopcodes.so.8
./usr/lib/i386/libopcodes.so.8.0
./usr/lib/libbfd.so.15
./usr/lib/libbfd.so.15.0
./usr/lib/libopcodes.so.8
./usr/lib/libopcodes.so.8.0
  end of 8 missing files  ==

(expects the older versions to be present).

(apologies if it has been fixed already - it took some time to
complete full clean build).


-- 

Re: amd64 -current build failure

[Chavdar Ivanov]

I had to wipe the tools directory as well before I finally went
through the 9.99.26 build. I also used NJOBS=1, but don't know if this
had anything to do with it.

On Tue, 17 Dec 2019 at 19:23, Chavdar Ivanov  wrote:
>
> On Tue, 17 Dec 2019 at 16:27, Paul Goyette  wrote:
> >
> > On Tue, 17 Dec 2019, Chavdar Ivanov wrote:
> >
> > > I am still getting the same errors, my CVS log is empty...
> >
> > You might have to run a full build.  I was trying an update build
> > which failed, but a full build seems to work.
>
> I did a full build this morning, which failed with the rump set of
> errors. I'll start one once more (basically, I wipe obj and destdir
> and run 'make cleandir' in src and xsrc; hope this should be enough).
>
>
> >
> >
> >
> >
> > >
> > > On Tue, 17 Dec 2019 at 15:12, Paul Goyette  wrote:
> > >>
> > >> Christos just fixed the lzma stuff...
> > >>
> > >> On Tue, 17 Dec 2019, Chavdar Ivanov wrote:
> > >>
> > >>> Looks like it; the lzma/bz2 undefined references still there though,
> > >>> 10 minutes ago.
> > >>>
> > >>> On Tue, 17 Dec 2019 at 13:18, Andrew Doran  wrote:
> > 
> >  Hi,
> > 
> >  On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote:
> > 
> > > Last two days I haven't been able to build amd64 -current:
> > > ...
> > > /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
> > > /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
> > > to `rumpns_cpuctl_ioctl'
> > > collect2: error: ld returned 1 exit status
> > 
> >  I think I fixed that one late last night - your followup message seems 
> >  to
> >  confirm.
> > 
> >  Andrew
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> 
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> ++--+---+
> > >> | 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   |
> > >> ++--+---+
> > >
> > >
> > >
> > > --
> > > 
> > >
> > > !DSPAM:5df8fd1c112731575111740!
> > >
> > >
> >
> > ++--+---+
> > | 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: amd64 -current build failure

[Paul Goyette]

On Tue, 17 Dec 2019, Chavdar Ivanov wrote:


I am still getting the same errors, my CVS log is empty...


You might have to run a full build.  I was trying an update build
which failed, but a full build seems to work.






On Tue, 17 Dec 2019 at 15:12, Paul Goyette  wrote:


Christos just fixed the lzma stuff...

On Tue, 17 Dec 2019, Chavdar Ivanov wrote:


Looks like it; the lzma/bz2 undefined references still there though,
10 minutes ago.

On Tue, 17 Dec 2019 at 13:18, Andrew Doran  wrote:


Hi,

On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote:


Last two days I haven't been able to build amd64 -current:
...
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
to `rumpns_cpuctl_ioctl'
collect2: error: ld returned 1 exit status


I think I fixed that one late last night - your followup message seems to
confirm.

Andrew




--







++--+---+
| 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   |
++--+---+




--


!DSPAM:5df8fd1c112731575111740!




++--+---+
| 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: amd64 -current build failure

[Chavdar Ivanov]

I am still getting the same errors, my CVS log is empty...

On Tue, 17 Dec 2019 at 15:12, Paul Goyette  wrote:
>
> Christos just fixed the lzma stuff...
>
> On Tue, 17 Dec 2019, Chavdar Ivanov wrote:
>
> > Looks like it; the lzma/bz2 undefined references still there though,
> > 10 minutes ago.
> >
> > On Tue, 17 Dec 2019 at 13:18, Andrew Doran  wrote:
> >>
> >> Hi,
> >>
> >> On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote:
> >>
> >>> Last two days I haven't been able to build amd64 -current:
> >>> ...
> >>> /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
> >>> /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
> >>> to `rumpns_cpuctl_ioctl'
> >>> collect2: error: ld returned 1 exit status
> >>
> >> I think I fixed that one late last night - your followup message seems to
> >> confirm.
> >>
> >> Andrew
> >
> >
> >
> > --
> > 
> >
> > !DSPAM:5df8dacf79529213120201!
> >
> >
>
> ++--+---+
> | 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: amd64 -current build failure

[Paul Goyette]

Christos just fixed the lzma stuff...

On Tue, 17 Dec 2019, Chavdar Ivanov wrote:


Looks like it; the lzma/bz2 undefined references still there though,
10 minutes ago.

On Tue, 17 Dec 2019 at 13:18, Andrew Doran  wrote:


Hi,

On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote:


Last two days I haven't been able to build amd64 -current:
...
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
to `rumpns_cpuctl_ioctl'
collect2: error: ld returned 1 exit status


I think I fixed that one late last night - your followup message seems to
confirm.

Andrew




--


!DSPAM:5df8dacf79529213120201!




++--+---+
| 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: amd64 -current build failure

[Chavdar Ivanov]

Looks like it; the lzma/bz2 undefined references still there though,
10 minutes ago.

On Tue, 17 Dec 2019 at 13:18, Andrew Doran  wrote:
>
> Hi,
>
> On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote:
>
> > Last two days I haven't been able to build amd64 -current:
> > ...
> > /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
> > /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
> > to `rumpns_cpuctl_ioctl'
> > collect2: error: ld returned 1 exit status
>
> I think I fixed that one late last night - your followup message seems to
> confirm.
>
> Andrew



-- 

Re: amd64 -current build failure

[Andrew Doran]

Hi,

On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote:

> Last two days I haven't been able to build amd64 -current:
> ...
> /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
> /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
> to `rumpns_cpuctl_ioctl'
> collect2: error: ld returned 1 exit status

I think I fixed that one late last night - your followup message seems to
confirm.

Andrew

Re: amd64 -current build failure

[Chavdar Ivanov]

Hi,

And the next build:
...
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/libmagic.so
: undefined reference to `lzma_code'
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/libmagic.so
: undefined reference to `BZ2_bzDecompressInit'
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/libmagic.so
: undefined reference to `BZ2_bzDecompress'
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/libmagic.so
: undefined reference to `BZ2_bzDecompressEnd'
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/libmagic.so
: undefined reference to `lzma_end'
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/libmagic.so
: undefined reference to `lzma_auto_decoder'
collect2: error: ld returned 1 exit status
...

On Tue, 17 Dec 2019 at 09:49, Chavdar Ivanov  wrote:
>
> Hi,
>
> Last two days I haven't been able to build amd64 -current:
> ...
> /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
> /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
> to `rumpns_cpuctl_ioctl'
> collect2: error: ld returned 1 exit status
> ...
>
> I have removed the obj directory and ran 'make cleandir'  in src and
> xsrc, which usually clears any leftovers; the cvs log does not show
> any inconsistencies from head.
>
> Chavdar
>
>
>
> --
> 



-- 

amd64 -current build failure

[Chavdar Ivanov]

Hi,

Last two days I haven't been able to build amd64 -current:
...
/home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld:
/home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference
to `rumpns_cpuctl_ioctl'
collect2: error: ld returned 1 exit status
...

I have removed the obj directory and ran 'make cleandir'  in src and
xsrc, which usually clears any leftovers; the cvs log does not show
any inconsistencies from head.

Chavdar



-- 

Re: -current build failure in compiler_rt/dist/lib/msan/msan_interceptors.cc

[Thomas Klausner]

On Wed, Oct 23, 2019 at 08:52:32PM +0200, Kamil Rytarowski wrote:
> On 23.10.2019 10:46, Kamil Rytarowski wrote:
> > On 23.10.2019 06:33, Thomas Klausner wrote:
> >> Hi!
> >>
> >> Yesterday evening's current with:
> >>
> >> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T 
> >> /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
> >> /usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release 
> >> distribution
> >>
> > 
> > I will have a look.
> > 
> 
> MKLLVM=yes builds now for me.

Thank you, works for me as well!
 Thomas

Re[2]: -current build failure in compiler_rt/dist/lib/msan/msan_interceptors.cc

[bruce_1975]

--
Inviato da Libero Mail per Android mercoledì, 23 ottobre 2019, 10:46AM +02:00 
da Kamil Rytarowski  n...@gmx.com :

>On 23.10.2019 06:33, Thomas Klausner wrote:
> Hi!
>
> Yesterday evening's current with:
>
> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T 
> /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
> /usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release 
> distribution
>
>I will have a look.
>
> gives me:
>
>
> --- msan_interceptors.o ---
> In file included from 
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:18:
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
>  error: 'void __interceptor___libc_thr_keycreate(void*, void (*)(void*))'
> alias between functions of incompatible types 'void(void*, void (*)(void*))' 
> and 'int(__sanitizer::__sanitizer_pthread_key_t*, void (*)(void*))' {aka 'int
> (unsigned int*, void (*)(void*))'} [-Werror=attribute-alias]
> # define WRAP(x) __interceptor_ ## x
> ^~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
>  note: in expansion of macro 'WRAP'
> ret_type WRAP(func)(__VA_ARGS__)
> ^~~~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1060:1:
>  note: in expansion of macro 'INTERCEPTOR'
> INTERCEPTOR(void, __libc_thr_keycreate, void *m, void (*dtor)(void *value)) \
> ^~~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
>  note: aliased declaration here
> # define WRAP(x) __interceptor_ ## x
> ^~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
>  note: in expansion of macro 'WRAP'
> ret_type WRAP(func)(__VA_ARGS__)
> ^~~~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1049:1:
>  note: in expansion of macro 'INTERCEPTOR'
> INTERCEPTOR(int, pthread_key_create, __sanitizer_pthread_key_t *key,
> ^~~
>
> Thomas
>
>
>

Re: -current build failure in compiler_rt/dist/lib/msan/msan_interceptors.cc

[Kamil Rytarowski]

On 23.10.2019 10:46, Kamil Rytarowski wrote:
> On 23.10.2019 06:33, Thomas Klausner wrote:
>> Hi!
>>
>> Yesterday evening's current with:
>>
>> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T 
>> /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
>> /usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release 
>> distribution
>>
> 
> I will have a look.
> 

MKLLVM=yes builds now for me.

>> gives me:
>>
>>
>> --- msan_interceptors.o ---
>> In file included from 
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:18:
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
>>  error: 'void __interceptor___libc_thr_keycreate(void*, void (*)(void*))'
>>  alias between functions of incompatible types 'void(void*, void 
>> (*)(void*))' and 'int(__sanitizer::__sanitizer_pthread_key_t*, void 
>> (*)(void*))' {aka 'int
>> (unsigned int*, void (*)(void*))'} [-Werror=attribute-alias]
>>  # define WRAP(x) __interceptor_ ## x
>>   ^~
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
>>  note: in expansion of macro 'WRAP'
>>ret_type WRAP(func)(__VA_ARGS__)
>> ^~~~
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1060:1:
>>  note: in expansion of macro 'INTERCEPTOR'
>>  INTERCEPTOR(void, __libc_thr_keycreate, void *m, void (*dtor)(void *value)) 
>> \
>>  ^~~
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
>>  note: aliased declaration here
>>  # define WRAP(x) __interceptor_ ## x
>>   ^~
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
>>  note: in expansion of macro 'WRAP'
>>ret_type WRAP(func)(__VA_ARGS__)
>> ^~~~
>> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1049:1:
>>  note: in expansion of macro 'INTERCEPTOR'
>>  INTERCEPTOR(int, pthread_key_create, __sanitizer_pthread_key_t *key,
>>  ^~~
>>
>>  Thomas
>>
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: -current build failure in compiler_rt/dist/lib/msan/msan_interceptors.cc

[Kamil Rytarowski]

On 23.10.2019 06:33, Thomas Klausner wrote:
> Hi!
> 
> Yesterday evening's current with:
> 
> build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T 
> /usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
> /usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release 
> distribution
> 

I will have a look.

> gives me:
> 
> 
> --- msan_interceptors.o ---
> In file included from 
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:18:
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
>  error: 'void __interceptor___libc_thr_keycreate(void*, void (*)(void*))'
>  alias between functions of incompatible types 'void(void*, void (*)(void*))' 
> and 'int(__sanitizer::__sanitizer_pthread_key_t*, void (*)(void*))' {aka 'int
> (unsigned int*, void (*)(void*))'} [-Werror=attribute-alias]
>  # define WRAP(x) __interceptor_ ## x
>   ^~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
>  note: in expansion of macro 'WRAP'
>ret_type WRAP(func)(__VA_ARGS__)
> ^~~~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1060:1:
>  note: in expansion of macro 'INTERCEPTOR'
>  INTERCEPTOR(void, __libc_thr_keycreate, void *m, void (*dtor)(void *value)) \
>  ^~~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
>  note: aliased declaration here
>  # define WRAP(x) __interceptor_ ## x
>   ^~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
>  note: in expansion of macro 'WRAP'
>ret_type WRAP(func)(__VA_ARGS__)
> ^~~~
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1049:1:
>  note: in expansion of macro 'INTERCEPTOR'
>  INTERCEPTOR(int, pthread_key_create, __sanitizer_pthread_key_t *key,
>  ^~~
> 
>  Thomas
> 




signature.asc
Description: OpenPGP digital signature

-current build failure in compiler_rt/dist/lib/msan/msan_interceptors.cc

[Thomas Klausner]

Hi!

Yesterday evening's current with:

build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T 
/usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D 
/usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release distribution

gives me:


--- msan_interceptors.o ---
In file included from 
/usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:18:
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
 error: 'void __interceptor___libc_thr_keycreate(void*, void (*)(void*))'
 alias between functions of incompatible types 'void(void*, void (*)(void*))' 
and 'int(__sanitizer::__sanitizer_pthread_key_t*, void (*)(void*))' {aka 'int
(unsigned int*, void (*)(void*))'} [-Werror=attribute-alias]
 # define WRAP(x) __interceptor_ ## x
  ^~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
 note: in expansion of macro 'WRAP'
   ret_type WRAP(func)(__VA_ARGS__)
^~~~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1060:1:
 note: in expansion of macro 'INTERCEPTOR'
 INTERCEPTOR(void, __libc_thr_keycreate, void *m, void (*dtor)(void *value)) \
 ^~~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
 note: aliased declaration here
 # define WRAP(x) __interceptor_ ## x
  ^~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
 note: in expansion of macro 'WRAP'
   ret_type WRAP(func)(__VA_ARGS__)
^~~~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1049:1:
 note: in expansion of macro 'INTERCEPTOR'
 INTERCEPTOR(int, pthread_key_create, __sanitizer_pthread_key_t *key,
 ^~~

 Thomas

Re: Current build failure on AMD64

[Fekete Zoltán]

2019-01-29 09:59 időpontban Martin Husemann ezt írta:

On Tue, Jan 29, 2019 at 09:30:13AM +0100, Fekete Zoltán wrote:

Hi There,

My current's build breaks with the message below for 2 weeks now. 
Could you

please help to resolve?

/usr/tools/lib/gcc/x86_64--netbsd/6.5.0/../../../../x86_64--netbsd/bin/ld:
libgcc_s_pic.a(enable-execute-stack.pico): file class ELFCLASS64
incompatible with ELFCLASS32
/usr/tools/lib/gcc/x86_64--netbsd/6.5.0/../../../../x86_64--netbsd/bin/ld:
final link failed: file in wrong format
collect2: error: ld returned 1 exit status


Clean the object dir - you must have some 32bit object files mixed with 
64bit

objects.

Martin


Thanks, Martin,

Now it works. My MAKEOBJPREFIX vaiable pointed to an old place in 
mk.conf...


Regards,

FeZ

Re: Current build failure on AMD64

[Martin Husemann]

On Tue, Jan 29, 2019 at 09:30:13AM +0100, Fekete Zoltán wrote:
> Hi There,
> 
> My current's build breaks with the message below for 2 weeks now. Could you
> please help to resolve?
> 
> /usr/tools/lib/gcc/x86_64--netbsd/6.5.0/../../../../x86_64--netbsd/bin/ld:
> libgcc_s_pic.a(enable-execute-stack.pico): file class ELFCLASS64
> incompatible with ELFCLASS32
> /usr/tools/lib/gcc/x86_64--netbsd/6.5.0/../../../../x86_64--netbsd/bin/ld:
> final link failed: file in wrong format
> collect2: error: ld returned 1 exit status

Clean the object dir - you must have some 32bit object files mixed with 64bit
objects.

Martin

Current build failure on AMD64

[Fekete Zoltán]

Hi There,

My current's build breaks with the message below for 2 weeks now. Could 
you please help to resolve?


/usr/tools/lib/gcc/x86_64--netbsd/6.5.0/../../../../x86_64--netbsd/bin/ld: 
libgcc_s_pic.a(enable-execute-stack.pico): file class ELFCLASS64 
incompatible with ELFCLASS32
/usr/tools/lib/gcc/x86_64--netbsd/6.5.0/../../../../x86_64--netbsd/bin/ld: 
final link failed: file in wrong format

collect2: error: ld returned 1 exit status

*** Failed target:  libgcc_s.so.1.0

Thanks in advance,

FeZ

current build failure (gcc)

[Riccardo Mottola]

Hi,

I get a different error than the build bot:

nbgmake[1]: Entering directory `/usr/obj/tools/gcc/build/gcc'
c++ -c   -O -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/. 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../include 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libcpp/include 
-I/usr/src/obj/tooldir.NetBSD-8.99.5-amd64/include 
-I/usr/src/obj/tooldir.NetBSD-8.99.5-amd64/include 
-I/usr/src/obj/tooldir.NetBSD-8.99.5-amd64/include 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libdecnumber 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libdecnumber/dpd 
-I../libdecnumber 
-I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libbacktrace 
-DNETBSD_TOOLS -DTARGET_SYSTEM_ROOT=0 -DTARGET_SYSTEM_ROOT_RELOCATABLE 
-o auto-profile.o -MT auto-profile.o -MMD -MP -MF 
./.deps/auto-profile.TPo 
/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/auto-profile.c
/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/auto-profile.c:147:14: 
error: 'map' in namespace 'std' does not name a template type

 typedef std::map icall_target_map;
  ^
/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/auto-profile.c:151:14: 
error: 'set' in namespace 'std' does not name a template type

 typedef std::set stmt_set;
  ^
/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/auto-profile.c:160:3: 
error: 'icall_target_map' does not name a type

   icall_target_map targets;
   ^
/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/auto-profile.c:201:16: 
error: 'map' in namespace 'std' does not name a template type
   typedef std::map 
string_index_map;

^
/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/auto-profile.c:203:3: 
error: 'string_index_map' does not name a type

   string_index_map map_;
   ^

<>


Riccardo

Re: -current build failure of evbearm-el,Re: -current build failure of evbearm-el

[Ryo ONODERA]

Hi,

From: Kamil Rytarowski , Date: Sun, 8 Jan 2017 02:23:34 +0100

> 
> 
> On 07.01.2017 12:17, Ryo ONODERA wrote:
>> Hi,
>> 
>> Recent NetBSD/evbearm-el-current build fails as follows.
>> A build of NetBSD/amd64-current from same tree is fine.
>> 
>> --- proc_bkpt.po ---
>> In file included from 
>> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/siginfo
>> .h:35:0,
>>  from 
>> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/ptrace.
>> h:37,
>>  from 
>> /usr/src/external/bsd/libproc/lib/../dist/proc_bkpt.c:38:
>> /usr/world/7.99/evbearm-el/destdir/usr/include/arm/signal.h:115:2: error: 
>> unknow
>> n type name 'sigset_t'
>>   sigset_t sc_mask;  /* signal mask to restore (new style) */
>>   ^
>> --- proc_regs.pico ---
>> In file included from 
>> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/siginfo.h:35:0,
>>  from 
>> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/ptrace.h:37,
>>  from 
>> /usr/src/external/bsd/libproc/lib/../dist/proc_regs.c:38:
>> /usr/world/7.99/evbearm-el/destdir/usr/include/arm/signal.h:115:2: error: 
>> unknown type name 'sigset_t'
>>   sigset_t sc_mask;  /* signal mask to restore (new style) */
>>   ^
>> --- proc_bkpt.po ---
>> *** [proc_bkpt.po] Error code 1
>> 
>> --
>> Ryo ONODERA // ryo...@yk.rim.or.jp
>> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3
>> 
> 
> Should be fixed in current by Christos.
> 

Thanks for your reply.
I have confirmed this is fixed.

--
Ryo ONODERA // ryo...@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: -current build failure of evbearm-el

[Kamil Rytarowski]

On 07.01.2017 12:17, Ryo ONODERA wrote:
> Hi,
> 
> Recent NetBSD/evbearm-el-current build fails as follows.
> A build of NetBSD/amd64-current from same tree is fine.
> 
> --- proc_bkpt.po ---
> In file included from 
> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/siginfo
> .h:35:0,
>  from 
> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/ptrace.
> h:37,
>  from 
> /usr/src/external/bsd/libproc/lib/../dist/proc_bkpt.c:38:
> /usr/world/7.99/evbearm-el/destdir/usr/include/arm/signal.h:115:2: error: 
> unknow
> n type name 'sigset_t'
>   sigset_t sc_mask;  /* signal mask to restore (new style) */
>   ^
> --- proc_regs.pico ---
> In file included from 
> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/siginfo.h:35:0,
>  from 
> /usr/world/7.99/evbearm-el/destdir/usr/include/sys/ptrace.h:37,
>  from 
> /usr/src/external/bsd/libproc/lib/../dist/proc_regs.c:38:
> /usr/world/7.99/evbearm-el/destdir/usr/include/arm/signal.h:115:2: error: 
> unknown type name 'sigset_t'
>   sigset_t sc_mask;  /* signal mask to restore (new style) */
>   ^
> --- proc_bkpt.po ---
> *** [proc_bkpt.po] Error code 1
> 
> --
> Ryo ONODERA // ryo...@yk.rim.or.jp
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3
> 

Should be fixed in current by Christos.



signature.asc
Description: OpenPGP digital signature

-current build failure of evbearm-el

[Ryo ONODERA]

Hi,

Recent NetBSD/evbearm-el-current build fails as follows.
A build of NetBSD/amd64-current from same tree is fine.

--- proc_bkpt.po ---
In file included from /usr/world/7.99/evbearm-el/destdir/usr/include/sys/siginfo
.h:35:0,
 from /usr/world/7.99/evbearm-el/destdir/usr/include/sys/ptrace.
h:37,
 from /usr/src/external/bsd/libproc/lib/../dist/proc_bkpt.c:38:
/usr/world/7.99/evbearm-el/destdir/usr/include/arm/signal.h:115:2: error: unknow
n type name 'sigset_t'
  sigset_t sc_mask;  /* signal mask to restore (new style) */
  ^
--- proc_regs.pico ---
In file included from 
/usr/world/7.99/evbearm-el/destdir/usr/include/sys/siginfo.h:35:0,
 from 
/usr/world/7.99/evbearm-el/destdir/usr/include/sys/ptrace.h:37,
 from /usr/src/external/bsd/libproc/lib/../dist/proc_regs.c:38:
/usr/world/7.99/evbearm-el/destdir/usr/include/arm/signal.h:115:2: error: 
unknown type name 'sigset_t'
  sigset_t sc_mask;  /* signal mask to restore (new style) */
  ^
--- proc_bkpt.po ---
*** [proc_bkpt.po] Error code 1

--
Ryo ONODERA // ryo...@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: current build failure automated messages

[Andreas Gustafsson]

On July 20, Paul Goyette wrote:
> For me, I'd be interested in another message that detailed changes in 
> the sets of Pass/Fail ATF tests.  The "New test failures" and "Tests No 
> Longer Failing" lines are useful for me.

As you may have noticed, email is now sent to current-users when an
ATF test case goes from consistently passing to consistently failing,
for some definition of "consistently".

There is currently no corresponding email when a test case gets fixed.
-- 
Andreas Gustafsson, g...@gson.org

Re: current build failure automated messages

[Andreas Gustafsson]

> Please make it thread properly to the original failure...

Should be threaded now.
-- 
Andreas Gustafsson, g...@gson.org

Re: current build failure automated messages

[Andreas Gustafsson]

Joerg Sonnenberger wrote:
> Please make it thread properly to the original failure...

I'll see what I can do about that.
-- 
Andreas Gustafsson, g...@gson.org

Re: current build failure automated messages

[Joerg Sonnenberger]

On Sun, Jul 31, 2016 at 12:26:58PM +0300, Andreas Gustafsson wrote:
> As you may have noticed, the build server now sends email to
> current-users not only when the i386 build breaks, but also
> when it has been fixed, with the subject line
> 
>   Automated report: NetBSD-current/i386 build success

Please make it thread properly to the original failure...

Joerg

Re: current build failure automated messages

[Andreas Gustafsson]

As you may have noticed, the build server now sends email to
current-users not only when the i386 build breaks, but also
when it has been fixed, with the subject line

  Automated report: NetBSD-current/i386 build success

-- 
Andreas Gustafsson, g...@gson.org

Re: current build failure automated messages

[Andreas Gustafsson]

Paul Goyette wrote:
> For me, I'd be interested in another message that detailed changes in 
> the sets of Pass/Fail ATF tests.  The "New test failures" and "Tests No 
> Longer Failing" lines are useful for me.

The "new test failures" part I have already implemented some time ago.
I have been testing it by running it on my personal testbed with the
emails going to myself, and I have been forwarding them to the
relevant committers as needed.  I do intend to deploy it on b5 with
the emails going to current-users eventually.  New test failures
actually happen pretty rarely compared to build breakage anyway.

The hard part of this is filtering out spurious reports from tests
that fail randomly.  My current heuristic is that a test has a "new
failure" if the last three runs all failed and the 20 or so runs
before that all passed, and this seems to be working pretty well.
-- 
Andreas Gustafsson, g...@gson.org

Re: current build failure automated messages

[Andreas Gustafsson]

Greg Troxel wrote:
> I would like to see not only a build-ok message (on transition from fail
> to pass),

I have now implemented this, and it's being tested on my personal
testbed before I deploy it on the TNF one.

> but also a fail message on every fresh build during the
> failure time,

I think "on every fresh build" is too often, especially if many
commits are being made - it could end up being more than one email
per hour.  I'd be OK with one every 12 hours.

> with 3 separate subject lines for new-fail still-fail
> now-ok, so that these are easy to filter out in one's MUA.

Sure.
-- 
Andreas Gustafsson, g...@gson.org

Re: current build failure automated messages

[Paul Goyette]

On Tue, 19 Jul 2016, Greg Troxel wrote:



Andreas Gustafsson  writes:


I can appreciate that - different people have different preferences
and workflows.  I'd like to hear the opinions of other developers -
if there is a consensus that "build has been fixed" email notifications
would be useful, I can certainly add them.  And even if the consensus
is that they are not useful, I just might add them anyway, but
hardcode the recipient address as "kre" :)


I would like to see not only a build-ok message (on transition from fail
to pass), but also a fail message on every fresh build during the
failure time, with 3 separate subject lines for new-fail still-fail
now-ok, so that these are easy to filter out in one's MUA.


For me, I'd be interested in another message that detailed changes in 
the sets of Pass/Fail ATF tests.  The "New test failures" and "Tests No 
Longer Failing" lines are useful for me.



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: current build failure automated messages

[Greg Troxel]

Andreas Gustafsson  writes:

> I can appreciate that - different people have different preferences
> and workflows.  I'd like to hear the opinions of other developers -
> if there is a consensus that "build has been fixed" email notifications
> would be useful, I can certainly add them.  And even if the consensus
> is that they are not useful, I just might add them anyway, but
> hardcode the recipient address as "kre" :)

I would like to see not only a build-ok message (on transition from fail
to pass), but also a fail message on every fresh build during the
failure time, with 3 separate subject lines for new-fail still-fail
now-ok, so that these are easy to filter out in one's MUA.


signature.asc
Description: PGP signature

Re: current build failure automated messages

[Robert Elz]

Date:Tue, 19 Jul 2016 12:40:34 +0300
From:Andreas Gustafsson 
Message-ID:  <22413.62866.53313.424...@guava.gson.org>


  | You don't have to screen scrape the HTML reports - you can get the
  | underlying data by anonymous rsync, as described in
  | 
  |   https://mail-index.netbsd.org/current-users/2015/10/18/msg028217.html

Thanks - I haven't seen that message (yet) - I have a kind of bizarre
way of reading NetBSD e-mail, I cherry pick current messages, reading any
where the subject looks interesting, and then I have two "current" pointers,
where I am really reading - one is back in early 2014 somewhere, and is
where I was up to in reading (more or less) everything - until a busy period
in 2013 (I think) made me just start the cherry picking of current messages
and only very occasionally moving the real read pointer forwards (though
it has moved 5 or 6 months - probably more, since then.)Then early this
year I just established a second read pointer, and went back to reading all
the messages again, just leaving a big gap in the messages I had read.
Then of course, that one slipped behind as well - it is currently up to
the start of May, and I'm back cherry picking again...  That one I am trying
to get caught up, but the gap between April 2014 (1st read pointer) and
Jan 2016 (where I started reading again) is not closing very fast - every
now and again when I'm bored I go process a couple of hundred messages
from back then, but it will take a while before I reach Oct 2015.)

  | With those, finding out if the
  | latest build succeeded is a one-liner in sh, for example:

Yes, just finding the success/fail or the build, even using the HTML
version, is trivial - but I also wanted the commit messages to be available.
I am not going to use them often, but a few times I have seen a build
failure, looked into it, and failed to work out how it should be fixed.
But then, obviously, it gets fixed by someone who knows how - by looking
at how it was fixed, hopefully I can learn more.   Some old dogs actually
appreciate new tricks...   For that I need to know what happened between the
last failure to build and when it started working again.

I will take a look at what is there and see if processing those logs
would be easier than the current processing of the HTML (which is not
really very difficult.)

  | The Python code that generates the existing HTML reports and email
  | notifications is also available if you want it.

Not really.   python is on my "I hope I never have to go there" list...

  | A new monthly report page is created when there is a build result to
  | report from building sources with a CVS source date in that month.

OK, thanks.

  | Since the internal date storage format of CVS has a "month" field, in
  | principle the above definition is complete without introducing the
  | concept of a time zone.

Not directly in the report generating code, but it is there in the way
CVS works, and is always UTC (or always on a unix type system anyway.)
I will adapt my script.   By adopting CVS dates for this, you're effectively
adopting UTC for the dates in the file names - which is as it should be.

  | so a commit made after 0:00 UTC on the 1st will trigger the
  | creation of a new report page once it has been built.

That's fine - a failure to fetch the log, if the script requests it before
it is created will (should, and almost does) just cause the script to
assume that there is no status change - which must be true, if it was not
changed (to fixed or to broken) after the last commit of the previous month,
and there has been no commit this month, then it is still in the same state.

I realise at the minute my script doesn't quite handle this properly, but
I will fix that, the file fetching part of it is the easy part...

  | Again, I think it is would be better to use the underlying data than
  | to screen scrape HTML reports that were never intended for machine
  | parsing.

Understood.   But for now, what I have works, so at least until the
generated HTML changes, I'm happy...

  | If I end up adding the "build fixed" notifications to the TNF test
  | server, it will be a reimplementation in Python anyway, sharing code
  | with the existing build failure notifications.

Sure, with the raw data, and knowledge how to use it (and much of the code
already existing) that would be a much better way.

kre

ps: if anyone has any actual interest in the script I posted, let me know,
and I will either send (via private e-mail) it after it is fixed, or
send it to the list again if there are many requests.

Re: current build failure automated messages

[Andreas Gustafsson]

Robert Elz wrote:
>   | If the page says "Build: OK" at the end, the issue has
>   | been fixed.  At least for me, this is less work overall than it would
>   | be to handle twice the number of emails.
> 
> I actually cannot imagine that being possible for me, one more e-mail to
> delete every few days is nothing, just switching to a browser and waiting
> for it to page in takes an order of magnitude longer - let alone the
> startup time if I don't have one running (which is not unusual) - plus
> that I can read e-mail on a text terminal trivially, and while that web
> page would not be hard for a text browser to process, it just seems wrong
> to me...

I can appreciate that - different people have different preferences
and workflows.  I'd like to hear the opinions of other developers -
if there is a consensus that "build has been fixed" email notifications
would be useful, I can certainly add them.  And even if the consensus
is that they are not useful, I just might add them anyway, but
hardcode the recipient address as "kre" :)

>   | If we're going to start sending more emails, I think adding notifications
>   | saying "build is still failing after 24 hours" would be more useful
>   | than "build now succeeding again".
> 
> I'm not sure about "more" useful, but that would certainly be useful,
> though I think 12 hours would be a better timeout - that's long enough
> for whoever broke it to have had time to fix things before causing others
> to be provoked into getting involved.

Noted.

> I am appending the script I am now using below.   One caveat - as is the way
> with these things - I made a couple of minor adjustments to the script after
> it worked earlier - and there has not been another failure since to validate
> it still works (it should, but ...)

You don't have to screen scrape the HTML reports - you can get the
underlying data by anonymous rsync, as described in

  https://mail-index.netbsd.org/current-users/2015/10/18/msg028217.html

This will probably yield more data than you want, but rsync has plenty
of options and can hopefully be coaxed into mirroring only the
"bracket.db" files, for example.  With those, finding out if the
latest build succeeded is a one-liner in sh, for example:

  find i386 -name bracket.db | sort | tail | xargs grep build_status | grep 
build_status=0

The Python code that generates the existing HTML reports and email
notifications is also available if you want it.

> Also, I have no idea of the timezone in which the log files are created, so
> I am currently running the script using just local time (for whoever runs it.)
> That only affects the name of the file that is fetched, and if right near the
> beginning of the month, the previous one - just in case the commit list that
> causes a failure, or corrects a failure, spans the month boundary).  As it
> is now, I am probably going to start attempting to fetch August's log before
> it first gets created (as August will come earlier for me than many of you).
> Of course, if the timezone for those files is from Japan or Australia then
> all would be fine (for me).   It should probably be, and probably is, UTC,
> but before I make the script work that way, I'd appreciate confirmation from
> someone who knows (that is: what timezone is used when deciding it is time
> to create a new log file -- i.e.: that a new month has started?)

A new monthly report page is created when there is a build result to
report from building sources with a CVS source date in that month.

Since the internal date storage format of CVS has a "month" field, in
principle the above definition is complete without introducing the
concept of a time zone.  In practice, the NetBSD CVS repository uses
UTC dates, so a commit made after 0:00 UTC on the 1st will trigger the
creation of a new report page once it has been built.

> It would also be easier if the html markup actually marked the content
> rather than just for appearance (class="build" means a different background
> colour, class="ok" just means "text is green" and class="fail" "text is red",
> and they're used that way... ideally there should be different classes for
> different purposes, and if several of them all just happen to result in the
> same appearance, that would be fine...)

Again, I think it is would be better to use the underlying data than
to screen scrape HTML reports that were never intended for machine
parsing.

> Also, the script, attached below, attempts to make a directory
>   /var/db/build-status
> to keep track of what the current status is, for each architecture monitored,
> (and some other stuff) but unless it is run as root (not recommended), it is
> probably going to fail...   So just make the directory by hand before running
> the script, and give it a suitable owner and permissions.   The first time
> the script is run for an architecture it will send a more or less useless
> e-mail which tells the current build status for that architecture (that it
> does 

Re: current build failure automated messages

[Robert Elz]

Date:Sat, 16 Jul 2016 12:15:41 +0300
From:Andreas Gustafsson 
Message-ID:  <22409.64317.493648.115...@guava.gson.org>

  | It would not be hard to implement, but I'm not sure it would be useful
  | enough to justify doubling the number of messages to the list.

With the current rate of build failures, "doubling the number of messages
to the list" means one extra message every few days normally - not something
I would be too concerned about.

  | What I do when I want to know if a reported build failure has been
  | fixed is to visit the web page whose URL is given at the very end of
  | the email.

I have used that if I want to get to the log of the actual build that
failed, when the extract in the e-mail is insufficient to work out what
actually happened.I guess it relates to how old I am these days, but
jumping on a browser is rarely my first reaction to anything - I mostly
predate www.* and basically consider http a total botch of a protocol, so,
I am almost always looking for an alternative.   Something simpler to deal
with.

  | If the page says "Build: OK" at the end, the issue has
  | been fixed.  At least for me, this is less work overall than it would
  | be to handle twice the number of emails.

I actually cannot imagine that being possible for me, one more e-mail to
delete every few days is nothing, just switching to a browser and waiting
for it to page in takes an order of magnitude longer - let alone the
startup time if I don't have one running (which is not unusual) - plus
that I can read e-mail on a text terminal trivially, and while that web
page would not be hard for a text browser to process, it just seems wrong
to me...

  | Most build failures are fixed quickly anyway.

Yes, that is exactly the point.   There was a build failure early this
morning (my time) - when I saw it (aside from the current-users message
about it) I had 2 e-mails from a script I created, one telling me of the
failure, and another telling me it was fixed.   Then I knew immediately
I could simply ignore the failure mail (the current-users message wasn't
even worth looking at.)   All I needed to see was the Subject lines of the
messages, and all the info was available for me to delete all of them
(in this cases I didn't, as this was the first failure since I got the
script finished, and I wanted to see how well it worked, or if it worked
at all ... which is also why I waited to reply here until now, I wanted
to have something productive, IMO anyway, to share...)

  | If we're going to start sending more emails, I think adding notifications
  | saying "build is still failing after 24 hours" would be more useful
  | than "build now succeeding again".

I'm not sure about "more" useful, but that would certainly be useful,
though I think 12 hours would be a better timeout - that's long enough
for whoever broke it to have had time to fix things before causing others
to be provoked into getting involved.

I am appending the script I am now using below.   One caveat - as is the way
with these things - I made a couple of minor adjustments to the script after
it worked earlier - and there has not been another failure since to validate
it still works (it should, but ...)

Currently I am just running it from cron every 15 minutes, but probably
better would be to have it triggered by the current-users build failure mail,
and then run it every N minutes until it goes to OK again, and then just
send the "now OK" mail and terminate.  That part (aside from the mail sending)
would get done by another script.

Also, I have no idea of the timezone in which the log files are created, so
I am currently running the script using just local time (for whoever runs it.)
That only affects the name of the file that is fetched, and if right near the
beginning of the month, the previous one - just in case the commit list that
causes a failure, or corrects a failure, spans the month boundary).  As it
is now, I am probably going to start attempting to fetch August's log before
it first gets created (as August will come earlier for me than many of you).
Of course, if the timezone for those files is from Japan or Australia then
all would be fine (for me).   It should probably be, and probably is, UTC,
but before I make the script work that way, I'd appreciate confirmation from
someone who knows (that is: what timezone is used when deciding it is time
to create a new log file -- i.e.: that a new month has started?)

It would also be easier if the html markup actually marked the content
rather than just for appearance (class="build" means a different background
colour, class="ok" just means "text is green" and class="fail" "text is red",
and they're used that way... ideally there should be different classes for
different purposes, and if several of them all just happen to result in the
same appearance, that would be fine...)

Also, the script, attached below, attempts to make a directory

Re: current build failure automated messages

[Andreas Gustafsson]

Robert Elz wrote:
> From time to time there are messages to current-users about
> build failures (the messages are generally useful even if sometimes
> the content - just what failed - can be most obscure ... but that's
> not the point of this message.)
> 
> I was wondering if it would be possible to also send "build now succeeding
> again" messages ?
>
> There are times when a build failure looks to be something I could
> investigate and perhaps fix - sometimes just looking at the commits
> around the time of the build failure report are enough to see that
> it already has been fixed, and so there is nothing to investigate,
> but other times it is not nearly so obvious.
> 
> A message indicating that the failing build is not failing any more
> seems like it would be useful to me (well, I know it would be useful
> to me, I suspect it might be useful to others as well.)
> 
> It could just contain that message, or better, as clearly from the
> failure reports, the info is available somewhere, a list of commits
> from the version that (first, since the previous success) failed, to
> the first version that succeeded building again.

It would not be hard to implement, but I'm not sure it would be useful
enough to justify doubling the number of messages to the list.

What I do when I want to know if a reported build failure has been
fixed is to visit the web page whose URL is given at the very end of
the email.  If the page says "Build: OK" at the end, the issue has
been fixed.  At least for me, this is less work overall than it would
be to handle twice the number of emails.

Most build failures are fixed quickly anyway.  If we're going to start
sending more emails, I think adding notifications saying "build is still
failing after 24 hours" would be more useful than "build now
succeeding again".
-- 
Andreas Gustafsson, g...@gson.org

current build failure automated messages

[Robert Elz]

>From time to time there are messages to current-users about
build failures (the messages are generally useful even if sometimes
the content - just what failed - can be most obscure ... but that's
not the point of this message.)

I was wondering if it would be possible to also send "build now succeeding
again" messages ?

There are times when a build failure looks to be something I could
investigate and perhaps fix - sometimes just looking at the commits
around the time of the build failure report are enough to see that
it already has been fixed, and so there is nothing to investigate,
but other times it is not nearly so obvious.

A message indicating that the failing build is not failing any more
seems like it would be useful to me (well, I know it would be useful
to me, I suspect it might be useful to others as well.)

It could just contain that message, or better, as clearly from the
failure reports, the info is available somewhere, a list of commits
from the version that (first, since the previous success) failed, to
the first version that succeeded building again.

kre

Re: -current build failure: table has too many members

[Thomas Klausner]

On Wed, Oct 14, 2015 at 11:54:41PM +0200, Thomas Klausner wrote:
> I haven't seen this one before, but just now it popped up:
> 
> 
> --- glapi_gentable.po ---
> ERROR: glapi_gentable.c: sou _glapi_table has too many members: 1155 > 1023
> Removing glapi_gentable.po
> *** [glapi_gentable.po] Error code 1
> 
> nbmake[6]: stopped in /archive/foreign/src/external/mit/xorg/lib/libGL
> --- glapi_gentable.o ---
> /archive/build/tools.gcc/bin/nbctfconvert -g -L VERSION -g glapi_gentable.o
> ERROR: glapi_gentable.c: sou _glapi_table has too many members: 1155 > 1023
> Removing glapi_gentable.o
> *** [glapi_gentable.o] Error code 1
> 
> This was in a gcc build with MKDTRACE, MKCTF, HAVE_LIBGCC_EH=no and
> DBG="-O2 -g".
> 
> Any ideas?

christos fixed this.
 Thomas

-current build failure: table has too many members

[Thomas Klausner]

I haven't seen this one before, but just now it popped up:


--- glapi_gentable.po ---
ERROR: glapi_gentable.c: sou _glapi_table has too many members: 1155 > 1023
Removing glapi_gentable.po
*** [glapi_gentable.po] Error code 1

nbmake[6]: stopped in /archive/foreign/src/external/mit/xorg/lib/libGL
--- glapi_gentable.o ---
/archive/build/tools.gcc/bin/nbctfconvert -g -L VERSION -g glapi_gentable.o
ERROR: glapi_gentable.c: sou _glapi_table has too many members: 1155 > 1023
Removing glapi_gentable.o
*** [glapi_gentable.o] Error code 1

This was in a gcc build with MKDTRACE, MKCTF, HAVE_LIBGCC_EH=no and
DBG="-O2 -g".

Any ideas?
 Thomas

Re: NetBSD/evbearmv7hf-el -current build failure

[Ryo ONODERA]

Hi,

From: Martin Husemann mar...@duskware.de, Date: Thu, 2 Jul 2015 09:48:53 +0200

 On Thu, Jul 02, 2015 at 04:03:19AM +0900, Ryo ONODERA wrote:
 Hi,
 
 I have gotten the following error.
 I did something wrong?
 
 Can you try removing $OBJDIR/compat/arm/oabi and then retry the build.sh?

I have removed all obj files and build.sh does not stop now.

Thank you.

--
Ryo ONODERA // ryo...@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

Re: amd64 -current build failure

[Chavdar Ivanov]

Glad to hear it wasn't something stupid I have done... I see that - it has
been going through the build today - not yet finished.

Thanks,

Chavdar


On Wed, 13 May 2015 at 13:26 Christos Zoulas chris...@astron.com wrote:

 In article CAG0OUxj83ke25NM2O6MnWpbKbF77y09ET=
 0ae1osn8w25b0...@mail.gmail.com,
 Chavdar Ivanov  ci4...@gmail.com wrote:
 Hi,
 
 My overnight build of -current (only amd64 on this machine) failed due
 to lack of disk space. The day before there was more than 200GB free
 on the filesystem in question.
 
 I found the following file at the end:
 
 ...
 
 -- total 473048080
 -rw-r--r--  1 sysbuild  sysbuild 68521 May 11 18:20 .depend
 -rw-r--r--  1 sysbuild  sysbuild  242170084173 May 13 03:24 cgram.c
 -rw-r--r--  1 sysbuild  sysbuild  3190 May 11 18:20 cgram.d
 -rw-r--r--  1 sysbuild  sysbuild  2125 May 13 00:53 cgram.h
 -rw-r--r--  1 sysbuild  sysbuild 94672 May 11 18:20 cgram.lo
 
 
 in /home/sysbuild/amd64/obj/home/sysbuild/src/tools/lint1
 
 - it seems the default configuration of sysbuild somehow places one
 more copy of src under the object subdirectory; as about the cgram.c
 file, it looks properly generated .c source, apart from the fact that
 it does not finish.
 
 Any suggestions as to why this might have happened? I build the day
 before the system - not via cron as in this case, but by manually
 executing the command line which is normally started by cron.

 This has been fixed; make cleandir in /usr/src/tools/lint1

 christos

Re: amd64 -current build failure

[Christos Zoulas]

In article CAG0OUxjTbSQZF48uDHkheM5ZEgQoPqnBPXcxRs=tjuzbeaj...@mail.gmail.com,
Chavdar Ivanov  ci4...@gmail.com wrote:
-=-=-=-=-=-

Glad to hear it wasn't something stupid I have done... I see that - it has
been going through the build today - not yet finished.

If there is any consolation, my cgram.c file was as large as yours...

christos

amd64 -current build failure

[Chavdar Ivanov]

Hi,

My overnight build of -current (only amd64 on this machine) failed due
to lack of disk space. The day before there was more than 200GB free
on the filesystem in question.

I found the following file at the end:

...

-- total 473048080
-rw-r--r--  1 sysbuild  sysbuild 68521 May 11 18:20 .depend
-rw-r--r--  1 sysbuild  sysbuild  242170084173 May 13 03:24 cgram.c
-rw-r--r--  1 sysbuild  sysbuild  3190 May 11 18:20 cgram.d
-rw-r--r--  1 sysbuild  sysbuild  2125 May 13 00:53 cgram.h
-rw-r--r--  1 sysbuild  sysbuild 94672 May 11 18:20 cgram.lo


in /home/sysbuild/amd64/obj/home/sysbuild/src/tools/lint1

- it seems the default configuration of sysbuild somehow places one
more copy of src under the object subdirectory; as about the cgram.c
file, it looks properly generated .c source, apart from the fact that
it does not finish.

Any suggestions as to why this might have happened? I build the day
before the system - not via cron as in this case, but by manually
executing the command line which is normally started by cron.


Chavdar Ivanov

Re: amd64 -current build failure

[Christos Zoulas]

In article CAG0OUxj83ke25NM2O6MnWpbKbF77y09ET=0ae1osn8w25b0...@mail.gmail.com,
Chavdar Ivanov  ci4...@gmail.com wrote:
Hi,

My overnight build of -current (only amd64 on this machine) failed due
to lack of disk space. The day before there was more than 200GB free
on the filesystem in question.

I found the following file at the end:

...

-- total 473048080
-rw-r--r--  1 sysbuild  sysbuild 68521 May 11 18:20 .depend
-rw-r--r--  1 sysbuild  sysbuild  242170084173 May 13 03:24 cgram.c
-rw-r--r--  1 sysbuild  sysbuild  3190 May 11 18:20 cgram.d
-rw-r--r--  1 sysbuild  sysbuild  2125 May 13 00:53 cgram.h
-rw-r--r--  1 sysbuild  sysbuild 94672 May 11 18:20 cgram.lo


in /home/sysbuild/amd64/obj/home/sysbuild/src/tools/lint1

- it seems the default configuration of sysbuild somehow places one
more copy of src under the object subdirectory; as about the cgram.c
file, it looks properly generated .c source, apart from the fact that
it does not finish.

Any suggestions as to why this might have happened? I build the day
before the system - not via cron as in this case, but by manually
executing the command line which is normally started by cron.

This has been fixed; make cleandir in /usr/src/tools/lint1

christos

Re: xz -current build failure

[Jeff Rizzo]

On 4/17/15 1:17 PM, bch wrote:

includes === lib/../external/mit/expat/lib/libexpat
includes === lib/../external/public-domain/sqlite/lib
includes === lib/../external/public-domain/xz/lib
#create  lib/pub-lzma.h
rm -f pub-lzma.h
/usr/src/obj/tooldir.NetBSD-7.99.9-amd64/bin/nbcat
/usr/src/external/public-domain/xz/lib/../dist/src/liblzma/api/lzma.h

pub-lzma.h

nbmake[4]: don't know how to make lzma.h. Stop




update and try again.

+j

xz -current build failure

[bch]

includes === lib/../external/mit/expat/lib/libexpat
includes === lib/../external/public-domain/sqlite/lib
includes === lib/../external/public-domain/xz/lib
#create  lib/pub-lzma.h
rm -f pub-lzma.h
/usr/src/obj/tooldir.NetBSD-7.99.9-amd64/bin/nbcat
/usr/src/external/public-domain/xz/lib/../dist/src/liblzma/api/lzma.h
 pub-lzma.h
nbmake[4]: don't know how to make lzma.h. Stop

nbmake[4]: stopped in /usr/src/external/public-domain/xz/lib

*** Failed target:  includes-../external/public-domain/xz/lib
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1;
shift; case ${dir} in /*) this=${dir}/; real=${dir} ;; .)
this=lib/; real=/usr/src/lib ;; *) this=lib/${dir}/;
real=/usr/src/lib/${dir} ;; esac; show=${this:-.}; echo ${target}
=== ${show%/}${1:+ (with: $@)}; cd ${real} 
/usr/src/obj/tooldir.NetBSD-7.99.9-amd64/bin/nbmake
_THISDIR_=${this} $@ ${target}; }; _makedirtarget
../external/public-domain/xz/lib includes
*** Error code 2

Stop.
nbmake[3]: stopped in /usr/src/lib

*** Failed target:  includes-lib
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1;
shift; case ${dir} in /*) this=${dir}/; real=${dir} ;; .)
this=; real=/usr/src ;; *) this=${dir}/; real=/usr/src/${dir}
;; esac; show=${this:-.}; echo ${target} === ${show%/}${1:+ (with:
$@)}; cd ${real} 
/usr/src/obj/tooldir.NetBSD-7.99.9-amd64/bin/nbmake
_THISDIR_=${this} $@ ${target}; }; _makedirtarget lib includes
*** Error code 1

Re: -current build failure

[Justin Cormack]

On 8 March 2015 at 04:22, Christos Zoulas chris...@astron.com wrote:
 In article 
 CABfrOT9xEj5GzGVxva-=hvtoyXbx4ZtY5f=l8fvmq-y8fvd...@mail.gmail.com,
 bch  brad.har...@gmail.com wrote:
===  10 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_linux
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_linux/dtrace_syscall_linux.kmod
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_netbsd32
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_netbsd32/dtrace_syscall_netbsd32.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall
./stand/amd64/7.99.6/modules/dtrace_syscall/dtrace_syscall.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall_linux
./stand/amd64/7.99.6/modules/dtrace_syscall_linux/dtrace_syscall_linux.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall_netbsd32
./stand/amd64/7.99.6/modules/dtrace_syscall_netbsd32/dtrace_syscall_netbsd32.kmod
=  end of 10 extra files  ===
==  4 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./stand/amd64-xen/7.99.6/modules/dtrace_linux_syscall
./stand/amd64-xen/7.99.6/modules/dtrace_linux_syscall/dtrace_linux_syscall.kmod
./stand/amd64-xen/7.99.6/modules/dtrace_netbsd32_syscall
./stand/amd64-xen/7.99.6/modules/dtrace_netbsd32_syscall/dtrace_netbsd32_syscall.kmod
  end of 4 missing files  ==

 Should be fixed now.


sys/rump/kern/lib/libsys_linux is not building either:

http://build.myriabit.eu:8012/builders/netbsd64/builds/5041/steps/shell_3/logs/stdio


n file included from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/timevar.h:66:0,
 from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/time.h:262,
 from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/param.h:142,
 from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/rump_linux_sysent.c:13:
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/systm.h:124:11:
note: 'sy_entry' declared here
  uint32_t sy_entry; /* DTrace entry ID for systrace. */
   ^
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/rump_linux_sysent.c:519:6:
error: missing initializer for field 'sy_entry' of 'struct sysent'
[-Werror=missing-field-initializers]
  linux_sys_nosys },   /* 242 = unimplemented mlockall */
  ^
In file included from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/timevar.h:66:0,
 from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/time.h:262,
 from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/param.h:142,
 from
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/rump_linux_sysent.c:13:
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/../../../../sys/systm.h:124:11:
note: 'sy_entry' declared here
  uint32_t sy_entry; /* DTrace entry ID for systrace. */
   ^
/home/justin/buildbot-netbsdhead/netbsd64/build/nbsrc/sys/rump/kern/lib/libsys_linux/rump_linux_sysent.c:521:6:
error: missing initializer for field 'sy_entry' of 'struct sysent'
[-Werror=missing-field-initializers]
  linux_sys_nosys },   /* 243 = unimplemented munlockall */

Re: -current build failure

[Justin Cormack]

On 8 March 2015 at 15:31, Christos Zoulas chris...@astron.com wrote:
 In article 
 CAK4o1Wy1FtqSek+MX9TO_DwWsjTNjN=1toj-0ujhdmytrzl...@mail.gmail.com,
 Justin Cormack  jus...@specialbusservice.com wrote:

sys/rump/kern/lib/libsys_linux is not building either:

 Pooka has stashed more syscall build stuff... Fixed.

Thanks it is all looking good now.

Justin

Re: -current build failure

[Christos Zoulas]

In article CAK4o1Wy1FtqSek+MX9TO_DwWsjTNjN=1toj-0ujhdmytrzl...@mail.gmail.com,
Justin Cormack  jus...@specialbusservice.com wrote:

sys/rump/kern/lib/libsys_linux is not building either:

Pooka has stashed more syscall build stuff... Fixed.

christos

Re: -current build failure

[Christos Zoulas]

In article CABfrOT9xEj5GzGVxva-=hvtoyXbx4ZtY5f=l8fvmq-y8fvd...@mail.gmail.com,
bch  brad.har...@gmail.com wrote:
===  10 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_linux
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_linux/dtrace_syscall_linux.kmod
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_netbsd32
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_netbsd32/dtrace_syscall_netbsd32.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall
./stand/amd64/7.99.6/modules/dtrace_syscall/dtrace_syscall.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall_linux
./stand/amd64/7.99.6/modules/dtrace_syscall_linux/dtrace_syscall_linux.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall_netbsd32
./stand/amd64/7.99.6/modules/dtrace_syscall_netbsd32/dtrace_syscall_netbsd32.kmod
=  end of 10 extra files  ===
==  4 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./stand/amd64-xen/7.99.6/modules/dtrace_linux_syscall
./stand/amd64-xen/7.99.6/modules/dtrace_linux_syscall/dtrace_linux_syscall.kmod
./stand/amd64-xen/7.99.6/modules/dtrace_netbsd32_syscall
./stand/amd64-xen/7.99.6/modules/dtrace_netbsd32_syscall/dtrace_netbsd32_syscall.kmod
  end of 4 missing files  ==

Should be fixed now.

christos

-current build failure

[bch]

===  10 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_linux
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_linux/dtrace_syscall_linux.kmod
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_netbsd32
./stand/amd64-xen/7.99.6/modules/dtrace_syscall_netbsd32/dtrace_syscall_netbsd32.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall
./stand/amd64/7.99.6/modules/dtrace_syscall/dtrace_syscall.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall_linux
./stand/amd64/7.99.6/modules/dtrace_syscall_linux/dtrace_syscall_linux.kmod
./stand/amd64/7.99.6/modules/dtrace_syscall_netbsd32
./stand/amd64/7.99.6/modules/dtrace_syscall_netbsd32/dtrace_syscall_netbsd32.kmod
=  end of 10 extra files  ===
==  4 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./stand/amd64-xen/7.99.6/modules/dtrace_linux_syscall
./stand/amd64-xen/7.99.6/modules/dtrace_linux_syscall/dtrace_linux_syscall.kmod
./stand/amd64-xen/7.99.6/modules/dtrace_netbsd32_syscall
./stand/amd64-xen/7.99.6/modules/dtrace_netbsd32_syscall/dtrace_netbsd32_syscall.kmod
  end of 4 missing files  ==
*** [checkflist] Error code 1