/build/2013.06.20.05.39.19-i386/src/usr.bin/netstat/inet.c:309:43:
error: cast from pointer to integer of different size
--
Andreas Gustafsson, g...@gson.org
; giving up
More log output at:
http://releng.netbsd.org/b5reports/i386/build/2013.08.07.05.19.40/build.log.tail
--
Andreas Gustafsson, g...@gson.org
indefinitely
like we currently do for the 1000-line summaries would use too much
space; we would have to introduce some kind of expiry mechanism.
In any case, the build was fixed by your commit of
src/tools/Makefile.gnuhost 1.41 and src/tools/autoconf/Makefile 1.6.
--
Andreas Gustafsson, g...@gson.org
build issue, because it's
failing with the same error message on the TNF testbed, which
does not use update builds:
http://releng.netbsd.org/b5reports/sparc/build/2013.08.24.15.42.29/build.log.tail
--
Andreas Gustafsson, g...@gson.org
PR 44046, but I thought that bug had been fixed...
--
Andreas Gustafsson, g...@gson.org
. But only a few of those 300+ builds
are recent, so it is possible that it was fixed but has recently
reappeared.
--
Andreas Gustafsson, g...@gson.org
picture, put the pictures in
some public location on the web (e.g., flickr or dropbox), and
file a problem report including the URLs of the pictures at
http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd
--
Andreas Gustafsson, g...@gson.org
, I was seeing it; right now it is hidden by the build
failing at an earlier stage with cannot find -lrumpkern_z.
--
Andreas Gustafsson, g...@gson.org
://releng.netbsd.org/b5reports/i386/commits-2014.01.html#2014.01.21.14.52.07
--
Andreas Gustafsson, g...@gson.org
unrelated
failures leaving build logs of almost exactly the same size on mine.
Sorry about the noise. That just leaves the issue Paul originally
reported, then.
--
Andreas Gustafsson, g...@gson.org
/b5reports/i386/commits-2014.01.html#2014.01.25.05.09.59
--
Andreas Gustafsson, g...@gson.org
/detect_unused_tests
These started failing with Christos' commit of src/share/mk/bsd.own.mk
1.784 on 2014-03-11 23:22:36, with the commit message switch amd64 to
gcc-4.8.
--
Andreas Gustafsson, g...@gson.org
that specifically require execution as
an unprivileged user.
--
Andreas Gustafsson, g...@gson.org
error: bconfig.h: No such file or directory
compilation terminated.
There is now a PR for thethese random build failures: PR 48914.
--
Andreas Gustafsson, g...@gson.org
. This really needs to be fixed - random build failures
like these are a serious drain on everyone's productivity.
--
Andreas Gustafsson, g...@gson.org
of the failed tests is at:
http://releng.netbsd.org/b5reports/amd64/build/2014.07.23.21.19.33/test.html#net_bpfjit_t_mbuf_bpfjit_mbuf_ldb_ind
--
Andreas Gustafsson, g...@gson.org
. The last time we did was July 21, 2012.
If you can, please help out by fixing bugs that are causing tests to
fail, and/or filing PRs about failing tests so that they can be marked
as expected failures.
Yours,
--
Andreas Gustafsson, g...@netbsd.org
/lib/modules/dri/radeon_dri.so.0.debug
./usr/libdata/debug/usr/X11R7/lib/modules/dri/swrast_dri.so.0.debug
end of 7 missing files ==
Full log at:
http://www.gson.org/netbsd/bugs/build/amd64-debug/2014/2014.12.24.08.55.09/build.log.tail
Merry Christmas,
--
Andreas Gustafsson
log from the automated build, the only
place where the string r200_dri.so.0.debug occurs is in the Files
in flist but missing from DESTDIR error message, so it would appear
that it is not only not being installed, but not being built, either.
--
Andreas Gustafsson, g...@gson.org
else noticed this?
I have noticed this also and found it highly confusing. And
install/49440 does look like the same thing.
I have not run into the other problem you reported, but then I haven't
done any installs using DHCP configuration lately.
--
Andreas Gustafsson, g...@gson.org
-
just start a single VM instead of two, and gdb away.
--
Andreas Gustafsson, g...@gson.org
/r600_dri.so.0.debug
./usr/libdata/debug/usr/X11R7/lib/modules/dri/radeon_dri.so.0.debug
./usr/libdata/debug/usr/X11R7/lib/modules/dri/swrast_dri.so.0.debug
--
Andreas Gustafsson, g...@gson.org
(with YES in upper case) rather than
MKDEBUG=yes in the build options.
I think the Makefiles and my build options are both wrong - do you
agree?
--
Andreas Gustafsson, g...@gson.org
] Abort trap (core dumped) ${runcmd} ${mak...
--
Andreas Gustafsson, g...@gson.org
There were commits by agc, chopps, jmcneill, macallan, matt, maxv,
msaitoh, ozaki-r, and riastradh. Please check your commits to see if
they could be the cause.
--
Andreas Gustafsson, g...@gson.org
test
cases, but new test cases that were added by riastradh during the time
period in case.
--
Andreas Gustafsson, g...@gson.org
similar failures under qemu 2.3.0.
--
Andreas Gustafsson, g...@gson.org
working now; the kernel debugging I've done since then
has been using qemu's built-in gdb stub instead, as described in
https://wiki.netbsd.org/kernel_debugging_with_qemu/.
--
Andreas Gustafsson, g...@gson.org
The tests are also failing:
http://releng.netbsd.org/b5reports/amd64/build/2015.08.16.19.22.33/test.html#dev_cgd_t_cgd_basic
Maybe someone committed something without running the tests first :)
--
Andreas Gustafsson, g...@gson.org
.html
--
Andreas Gustafsson, g...@gson.org
inbetween, and
failed in the same place both times. The other confusing thing is
that the two reports were sent to current-users out of order; perhaps
the first one got moderated due to its size?
In any case, the failure of the 16th is still not fixed (hi Christos!).
--
Andreas Gustafsson, g
Michael van Elst wrote:
I haven't seen any kind of system freezes so far, but the tests
did not time out either.
dksubr.c 1.73 fixes the LOCKDEBUG issue with cgd.
Looks like it also fixed the tests - thanks.
--
Andreas Gustafsson, g...@gson.org
2+0x8
The discussion that ensued branched out in lots of different
directions, but as far as I can see, none of them actually
offered a diagnosis of the original problem reported.
To me, this looks very much like the same problem as PR 50060, which
was recently fixed in -current by riastradh@. A pu
p 'min: ' amd64/2015*/test.log.gz
Thanks to spz@ for setting up the rsync service.
Yours,
--
Andreas Gustafsson, g...@netbsd.org
NDONENTER="bt"'
in the INSTALL and GENERIC kernels.
--
Andreas Gustafsson, g...@gson.org
Paul Goyette wrote:
> Of course you'd still need to manually transcribe the console display,
> or take a pic for screen capture.
Of course. I think we should encourage the latter option; it's less
work for the user, less error prone, and likely to contain more
information.
--
Andreas Gust
Paul Goyette wrote:
> In attempts to debug another problem (see the thread about "killing
> zombies"), I've twice forced crash dumps from ddb. Once with the 'sync'
> command, and once with 'reboot 0x104'.
[...]
> Yet, gdb fails to process these files:
PR 48915?
--
nosuch: No address associated with hostname
I get the above (incorrect) output on both 6.1.4 and -current.
> Any ideas what could be the reason for this?
Looks like a bug in NetBSD's getaddrinfo() to me.
--
Andreas Gustafsson, g...@gson.org
e is whatever corresponds to
a getaddrinfo() return value of EAI_NONAME, not EAI_NODATA.
See also PR 44915.
--
Andreas Gustafsson, g...@gson.org
Manuel Bouyer wrote:
> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
> NetBSD i386/Xen doesn't boot any more (since the 2016-05-20 07:10 UTC
> build), init dies with:
> exec /sbin/init: error 2
>
> any idea ?
Probably related to kern/51173.
--
Andreas Gustafsson, g...@gson.org
sparc still
builds so that we don't lose our entire automated testing
infrastructure to this.
--
Andreas Gustafsson, g...@gson.org
Paul Goyette wrote:
> Host is a few weeks old, 7.99.25 from Dec. 23rd.
If this is a host issue, it's probably more recent than that. I'm
starting a test of building -current on -current. It will take
some hours to complete since it involves two full release builds.
--
Andreas Gustafsson
Paul Goyette wrote:
> I did a clean build earlier today without any problems.
How current was the host?
--
Andreas Gustafsson, g...@gson.org
rge -t -g -L
666 22045 18528 105084 16 10 26676 4564 parked INl pts/4 0:00.03
/tmp/bracket/build/2016.02.06.18.23.26-i386/tools/bin/nbctfmerge -t -L VE
Any idea what's causing this?
--
Andreas Gustafsson, g...@gson.org
For a second time, NetBSD Test Fixture wrote:
> ERROR: nbctfmerge: Caught signal 15 - exiting
This was another hung nbctfmerge process in the i386 build. Someone
please fix this. It seems to be happening only randomly, so bisection
won't help.
--
Andreas Gustafsson, g...@gson.org
Christos,
The other day, you said:
> The better question is: Do installed modules have both ctf and dwarf debug
> info? Because they should only have ctf. ctf debugging info is much more
> compact...
What command should I run to determine this?
--
Andreas Gustafsson, g...@gson.org
host
around that time, and that upgrading to today's -current will likely
help.
--
Andreas Gustafsson, g...@gson.org
release (assuming the increase in disk use is permanent).
--
Andreas Gustafsson, g...@gson.org
counts for most of the space.
>
> Any idea why modules are that big these days ?
Presumably this is because of src/share/mk/bsd.kmodule.mk 1.56,
"If we are building CTF, keep debugging symbols."
--
Andreas Gustafsson, g...@gson.org
g -current with -j 16 on amd64 many times a day,
--
Andreas Gustafsson, g...@gson.org
rge).
--
Andreas Gustafsson, g...@gson.org
http://releng.netbsd.org/b5reports/i386/commits-2016.03.html#2016.03.01.06.48.55
--
Andreas Gustafsson, g...@gson.org
nit: error 2
init path (default /sbin/init):
More logs at:
http://releng.netbsd.org/b5reports/i386/commits-2016.04.html#2016.04.10.15.32.27
--
Andreas Gustafsson, g...@gson.org
gt;
>
> Is anyone else seeing anything similar?
The testbed is failing with the same error:
http://releng.netbsd.org/b5reports/amd64/commits-2016.04.html#2016.04.04.22.14.38
i386 and sparc are also failing. CC:ing christos since the failure
appeared after his commits.
--
Andreas Gustafsson, g...@gson.org
A short while ago, i said:
> There was some crypto breakage that affected CCD
Never mind - I got CCD and CGD mixed up. Thanks to Paul Goyette for
pointing it out.
--
Andreas Gustafsson, g...@gson.org
re was some crypto breakage that affected
CCD starting some time between source dates 2016.03.20.22.17.13 and
2016.03.20.22.27.44, and ending at 2016.03.21.19.13.15.
--
Andreas Gustafsson, g...@gson.org
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
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
rst 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 that is/was intentional...)
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.
--
Andreas Gustafsson, g...@gson.org
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
lter out in one's MUA.
Sure.
--
Andreas Gustafsson, g...@gson.org
ations saying "build is still
failing after 24 hours" would be more useful than "build now
succeeding again".
--
Andreas Gustafsson, g...@gson.org
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
> Please make it thread properly to the original failure...
Should be threaded now.
--
Andreas Gustafsson, g...@gson.org
Now that -current builds again, there are more than 800 failing test cases.
The ones I looked at were all failing with:
panic: in_control
rump kernel halting...
--
Andreas Gustafsson, g...@gson.org
as errors
*** [linux_socket.o] Error code 1
--
Andreas Gustafsson, g...@gson.org
Jonathan A. Kollasch wrote:
> > cosdata.c:(.text+0xaa): undefined reference to `__arraycount'
[...]
> I think I just fixed this.
Yes, the build is now working. Thank you!
--
Andreas Gustafsson, g...@gson.org
-linuxhost/2017/2017.01.29.05.13.55/build.log.tail
--
Andreas Gustafsson, g...@gson.org
'long unsigned int', but argument
3 has type 'bus_size_t {aka unsigned int}' [-Werror=format=]
aprint_debug_dev(sc->sc_dev, "ECR %lx: %08x\n", ecp, ecr);
--
Andreas Gustafsson, g...@gson.org
also show the part of the dmesg output indicating which type
of host controller the USB port is attached to (uhci/ohci/ehci/xhci)?
--
Andreas Gustafsson, g...@gson.org
More data at:
http://releng.netbsd.org/b5reports/sparc/commits-2016.10.html#2016.10.30.15.01.46
http://www.gson.org/netbsd/bugs/build/sparc/commits-2016.10.html#2016.10.28.20.38.12
--
Andreas Gustafsson, g...@gson.org
SERT does nothing
unless DIAGNOSTIC is also defined, and it is not defined by default,
your patch made no difference.
If you still need me to test a patch, please send one that includes
all necessary changes.
--
Andreas Gustafsson, g...@gson.org
, as soon as the bisection that's now running on my test machine
has finished.
--
Andreas Gustafsson, g...@gson.org
. The filesystems involved are all newly created
in each test run.
--
Andreas Gustafsson, g...@gson.org
image stored in a file, causing the file to grow
correspondingly. Since the expansion does not even exist in the image
file prior before resize_ffs is run, there is no way for it to have
non-zero content.
--
Andreas Gustafsson, g...@gson.org
work
runs each test case in a clean work directory.
--
Andreas Gustafsson, g...@gson.org
of the diff and did
not spot anything that could be a cause of the panic.
--
Andreas Gustafsson, g...@gson.org
-Werror=pointer-to-int-cast]
rv = (paddr_t)cb->s.start + off;
^
nat@, please fix.
--
Andreas Gustafsson, g...@gson.org
say
that you have actually tested the sources immediately before and after
a suspect commit, rather than relying on the assumption that certain
types of commits can't possibly cause problems.
--
Andreas Gustafsson, g...@gson.org
he ABI [-Werror=psabi]
This is still broken after more than 24 hours, as of source date
2017.01.14.19.32.10.
The testbed's auto-bisection has identified this commit as the cause:
2017.01.13.14.34.58 christos src/share/mk/bsd.sys.mk 1.267
--
Andreas Gustafsson, g...@gson.org
Yorick Hardy wrote:
> I frequently encounter an illegal instruction when using SSL with
> python2.7 and wip/rawdog.
Looks like the same issue as PR 51569.
--
Andreas Gustafsson, g...@gson.org
the ATF test
run as a whole to also time out. This is affecting amd64 and sparc on
bablyon5 (i386 is not even building at the moment).
--
Andreas Gustafsson, g...@gson.org
ooks/50-ypbind:
stat: No such file or directory
--
Andreas Gustafsson, g...@gson.org
with a grain of salt. The qemu on
babylon5 was recently updated and we're still ironing out some
performance issues. The tests are currently taking about twice as
long as usual, which may be causing timing related failures.
--
Andreas Gustafsson, g...@gson.org
tal error: machine/ibcs2_machdep.h: No such file or directory
This is still failing as of source date 2017.08.11.07.30.01.
--
Andreas Gustafsson, g...@gson.org
ilure of lib/libc/sys/t_mincore:mincore_resid.
This was not in the automated report because that test is skipped on
i386 due to a lack of memory, but but it shows up on amd64.
--
Andreas Gustafsson, g...@gson.org
int', but argument 5 has
type 'unsigned int' [-Werror=format=]
--
Andreas Gustafsson, g...@gson.org
- Rsl ? 194:32.70
rump_server -lrumpdev -lrumpnet -lrumpnet_net -lrumpnet_netin
0 203561 666580 27 0 73884 4024 - Rsl ? 216:32.72
rump_server -lrumpdev -lrumpnet -lrumpnet_net -lrumpnet_netin
This is slowing down the test VMs enough to make some of the test runs
time out.
--
Andreas Gustafsson, g...@gson.org
.html
http://mail-index.netbsd.org/current-users/2017/12/04/msg032842.html
> Ok, I understand this one, should be fixed!
OK, presumably that will make it go back to hanging in
t_ptrace_wait:resume1 again.
--
Andreas Gustafsson, g...@gson.org
out.
>
> Ok, I understand this one, should be fixed!
It's still hanging as of source date 2017.12.18.22.44.30.
Also, it seems to me that when a kernel change causes the whole system
to hang during a test, the problem is with the kernel change, not the
test.
--
Andreas Gustafsson, g...@gson.org
src/external/gpl3/gcc/dist/gcc/config/i386/netbsd-elf.h 1.8
--
Andreas Gustafsson, g...@gson.org
/test.html#lib_libc_sys_t_ptrace_wait_signal4
--
Andreas Gustafsson, g...@gson.org
tests/lib/libc/sys/t_ptrace_wait.h:159:18:
note: in definition of macro 'FORKEE_ASSERT_NEQ'
uintmax_t vy = (y); \
^
--
Andreas Gustafsson, g...@gson.org
:23:
/bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9:
error: unknown type name 'u_longlong_t'
typedef u_longlong_t ulonglong_t;
^~~~
--
Andreas Gustafsson, g...@gson.org
The build is now working again on my Debian 9 host - thanks.
--
Andreas Gustafsson, g...@gson.org
their changes
with a full release build before committing, (b) fix or revert their
commits quickly if they nonetheless turn out to break the build, and
(c) wait until the tree is building successfully before committing
unrelated changes, so that those changes can benefit from automated
testing.
--
Andreas
tbsd.org/b5reports/i386/2018/2018.06.03.15.26.03/build.log.tail)
Looks like martin's sysinst changes...
--
Andreas Gustafsson, g...@gson.org
FWIW, amd64 is also affected:
http://www.gson.org/netbsd/bugs/build/amd64-baremetal/2018/2018.06.03.13.23.58/build.log.tail
To find the relevant error message in the above, search for kmutex_t.
--
Andreas Gustafsson, g...@gson.org
n in a fifth way, this time
by pgoyette:
--- cleandir-share ---
nbmake[6]:
"/tmp/bracket/build/2018.06.03.09.22.34-i386/src/share/mk/bsd.man.mk" line 257:
Wrong number of words (2549) in .for substitution list with 2 vars
I just committed a change that will hopefully fix that one.
--
Andreas Gustafsson, g...@gson.org
);
^
The amd64 build is now working - thanks to those who committed fixes.
--
Andreas Gustafsson, g...@gson.org
1 - 100 of 272 matches
Mail list logo
