Date:Mon, 13 Mar 2023 19:40:18 + (UTC)
From:NetBSD Test Fixture
Message-ID: <167873641838.21770.3334724647239982...@babylon5.netbsd.org>
| This is an automatically generated notice of a NetBSD-current/i386
| build failure.
|
| The failure occurred on
Date:Sat, 7 Jan 2023 20:41:01 + (UTC)
From:NetBSD Test Fixture
Message-ID: <167312406178.23291.2878684022518773...@babylon5.netbsd.org>
| The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
| using sources from CVS date 2023.01.07.19.41.30.
Date:Sun, 30 Oct 2022 02:23:22 + (UTC)
From:NetBSD Test Fixture
Message-ID: <166709660251.4897.4957055195986461...@babylon5.netbsd.org>
| An extract from the build.sh output follows:
|
| ./usr/share/zoneinfo/America/Rainy_River
|
The build is still failing, now with:
--- release-bootcd-com ---
Copying set gpufw
pax: line 206: ./libdata/firmware/nouveau/nvidia/gp107/gr/fecs_bl.bin: type
mismatch: specfile link, tree file
This is from:
Hi maya,
The build is still failing with:
> ./libdata/firmware/nouveau/nvidia/LICENCE.nvidia
> ./libdata/firmware/nouveau/nvidia/gm206/fecs_data.bin
> ./libdata/firmware/nouveau/nvidia/gm206/fecs_inst.bin
> ./libdata/firmware/nouveau/nvidia/gm206/gpccs_data.bin
>
Yesterday, the NetBSD Test Fixture wrote:
> nbmake[3]: stopped in /tmp/build/2021.08.17.17.31.59-i386/src
> nbmake[2]: stopped in /tmp/build/2021.08.17.17.31.59-i386/src
> nbmake[1]: stopped in /tmp/build/2021.08.17.17.31.59-i386/src
> nbmake: stopped in
On Sun, Jul 25, 2021 at 11:51:57PM +, Thomas Mueller wrote:
...
> Or should I try with hg? I have devel/mercurial built and installed.
>
> Now to find a tutorial for Mercurial for git users: There was one, but I can
> no longer find it.
...
There's a related resource which isn't a tutorial
On Thu, Jul 22, 2021 at 10:32:37AM +0200, Reinoud Zandijk wrote:
> > > it looks like CVS randomly didn't commit some of my changes,
> > > investigating...
> >
> > Yeah, not sure what happened; something caused it to, apparently,
> > think a few of the files in the second changeset still
> On Mon, Jul 19, 2021 at 01:28:06AM +, David Holland wrote:
> > that is... less than helpful :-(
> > it looks like CVS randomly didn't commit some of my changes,
> > investigating...
> Yeah, not sure what happened; something caused it to, apparently,
> think a few of the files in the
On Monday, David Holland wrote:
> Right... I wonder what happened to bracket's error-matching script; it
> usually does better than that.
I have now deployed bracket 2.15 on babylon5.netbsd.org, and the latest
build failure report looks much better:
On Mon, Jul 19, 2021 at 08:13:19AM +0300, Andreas Gustafsson wrote:
> David Holland wrote:
> > On Mon, Jul 19, 2021 at 10:32:20AM +0900, Rin Okuyama wrote:
> > > Logs below are usually more helpful.
> >
> > Right... I wonder what happened to bracket's error-matching script; it
> > usually does
David Holland wrote:
> On Mon, Jul 19, 2021 at 10:32:20AM +0900, Rin Okuyama wrote:
> > Logs below are usually more helpful.
>
> Right... I wonder what happened to bracket's error-matching script; it
> usually does better than that.
There are multiple causes, but a major one is that since
On 2021/07/19 10:28, David Holland wrote:
that is... less than helpful :-(
it looks like CVS randomly didn't commit some of my changes,
investigating...
Logs below are usually more helpful.
On 2021/07/19 9:42, NetBSD Test Fixture wrote:
Logs can be found at:
On Mon, Jul 19, 2021 at 12:42:49AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2021.07.18.23.57.34.
>
> An
In article <24751.41935.824926.178...@guava.gson.org>,
Andreas Gustafsson wrote:
>The i386 build is still failing, but now with a different error:
>
> --- in6_pcb.o ---
> /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In
>function 'in6_pcblookup_port':
> cc1: error: function
In article ,
Christos Zoulas wrote:
>In article <24751.41935.824926.178...@guava.gson.org>,
>Andreas Gustafsson wrote:
>>The i386 build is still failing, but now with a different error:
>>
>> --- in6_pcb.o ---
>> /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In
>>function
In article <24751.41935.824926.178...@guava.gson.org>,
Andreas Gustafsson wrote:
>The i386 build is still failing, but now with a different error:
>
> --- in6_pcb.o ---
> /tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In
>function 'in6_pcblookup_port':
> cc1: error: function
The i386 build is still failing, but now with a different error:
--- in6_pcb.o ---
/tmp/build/2021.05.27.08.58.29-i386/src/sys/netinet6/in6_pcb.c: In function
'in6_pcblookup_port':
cc1: error: function may return address of local variable
[-Werror=return-local-addr]
Fixed...
christos
> On Apr 18, 2021, at 9:39 AM, Andreas Gustafsson wrote:
>
> The i386 build is still failing, with errors like these:
>
> --- dependall-tmux ---
>
> /tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:
> In function
The i386 build is still failing, with errors like these:
--- dependall-tmux ---
/tmp/build/2021.04.18.12.05.29-i386/src/external/bsd/tmux/dist/cmd-display-menu.c:
In function 'cmd_display_menu_get_position':
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2021.04.06.20.13.43.
...
> *** Failed target: dependall-../external/bsd/elftoolchain
...
> The following
Date:Sun, 14 Feb 2021 21:40:21 + (UTC)
From:NetBSD Test Fixture
Message-ID: <161333882137.19912.5576154194224308...@babylon5.netbsd.org>
| This is an automatically generated notice of a NetBSD-current/i386
| build failure.
|
| The failure occurred on
Hi,
Roy Marples writes:
> On 03/02/2021 17:55, Ryo ONODERA wrote:
>> Exactly. It happens in dtrace userland build.
>
> Fixed. Sorry about that.
>
> Maybe we should not define CTASSERT ourselves and just use __CTASSERT to
> avoid
> this in the future?
Thank you.
I have no idea what is the
On 03/02/2021 17:55, Ryo ONODERA wrote:
Exactly. It happens in dtrace userland build.
Fixed. Sorry about that.
Maybe we should not define CTASSERT ourselves and just use __CTASSERT to avoid
this in the future?
Roy
Hi,
Martin Husemann writes:
> On Wed, Feb 03, 2021 at 05:31:11PM +, Roy Marples wrote:
>> I cannot replicate this?
>> I'm just building a stock kernel - what extra options do I need?
>
> It happens in the userland build.
Exactly. It happens in dtrace userland build.
> Martin
--
Ryo
On Wed, Feb 03, 2021 at 05:31:11PM +, Roy Marples wrote:
> I cannot replicate this?
> I'm just building a stock kernel - what extra options do I need?
It happens in the userland build.
Martin
On 03/02/2021 14:42, Ryo ONODERA wrote:
Hi,
It seems that CTASSERT in netinet/in.h conflicts with
CTASSERT in external/cddl/osnet/dist/uts/common/sys/debug.h.
Ryo ONODERA writes:
Hi,
However I have gotten another failure:
--- dt_print.pico ---
In file included from
Hi,
It seems that CTASSERT in netinet/in.h conflicts with
CTASSERT in external/cddl/osnet/dist/uts/common/sys/debug.h.
Ryo ONODERA writes:
> Hi,
>
> However I have gotten another failure:
>
> --- dt_print.pico ---
> In file included from /usr/src/external/cddl/osnet/sys/sys/debug.h:51,
>
Hi,
However I have gotten another failure:
--- dt_print.pico ---
In file included from /usr/src/external/cddl/osnet/sys/sys/debug.h:51,
from /usr/src/external/cddl/osnet/sys/sys/uio.h:64,
from /usr/world/9.99/amd64/dest/usr/include/sys/socket.h:99,
Hi,
NetBSD Test Fixture writes:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2021.02.03.12.11.34.
>
> An extract from the build.sh output follows:
>
>
On Sun, Jan 24, 2021 at 12:10:46PM -0800, Jason Thorpe wrote:
>
> > On Jan 24, 2021, at 11:31 AM, Robert Elz wrote:
> >
> > /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
> >
> On Jan 24, 2021, at 5:38 PM, Robert Elz wrote:
>
>Date:Sun, 24 Jan 2021 16:25:55 -0800
>From:Jason Thorpe
>Message-ID:
>
> | > If would be nice if rump weren't so bloody fragile.
>
> It would indeed.
>
> | I am not able to reproduce the build failure:
>
>
Date:Sun, 24 Jan 2021 16:25:55 -0800
From:Jason Thorpe
Message-ID:
| > If would be nice if rump weren't so bloody fragile.
It would indeed.
| I am not able to reproduce the build failure:
Odd, it is still failing on b5, on all of i386 amd64 and evbarm (the
> On Jan 24, 2021, at 12:10 PM, Jason Thorpe wrote:
>
>
>> On Jan 24, 2021, at 11:31 AM, Robert Elz wrote:
>>
>> /tmp/build/2021.01.24.17.44.16-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
>> /tmp/build/2021.01.24.17.44.16-i386/destdir/usr/lib/librump.so:
Date:Sun, 24 Jan 2021 18:45:38 + (UTC)
From:NetBSD Test Fixture
Message-ID: <161151393856.1140.6101421274186394...@babylon5.netbsd.org>
| An extract from the build.sh output follows:
The actual error lines (with intervening unrelated stuff deleted) are:
#
On 23.01.2021 19:34, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2021.01.23.17.58.03.
An extract from the build.sh output follows:
On Thu, Jan 21, 2021 at 04:33:40PM +0100, Reinoud Zandijk wrote:
> I'd like to fix this ASAP but what is the correct way of dealing with this? Is
> this an i386 failure or should code just not use bus_space_read_8() or
> bus_space_write_8() ?
Unless the spec requires it, you should just avoid
I'd like to fix this ASAP but what is the correct way of dealing with this? Is
this an i386 failure or should code just not use bus_space_read_8() or
bus_space_write_8() ?
In the VirtIO case, it doesn't have to be written atomically though.
What I could do is define a bus_space_write_8()
Date:Wed, 20 Jan 2021 21:17:40 + (UTC)
From:NetBSD Test Fixture
Message-ID: <161117746032.12857.1128493575446...@babylon5.netbsd.org>
| This is an automatically generated notice of a NetBSD-current/i386
| build failure.
|
| The failure occurred on
On 03.01.2021 21:00, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2021.01.03.19.15.36.
An extract from the build.sh output follows:
Sorry for breakage. I'll fix this.
rin
On 2020/12/19 17:40, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.12.19.07.19.30.
An
Roland Illig wrote:
> >=== 2 extra files in DESTDIR =
> Fixed in distrib/sets/lists/tests/mi 1.984.
Confirmed fixed, thanks. The i386 build is still failing, though -
it's now back to failing in mpu_acpi.c:
--- kern-GENERIC ---
On 07.12.2020 07:42, Andreas Gustafsson wrote:
The build is now failing differently:
=== 2 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
The build is now failing differently:
=== 2 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/tests/usr.bin/make/unit-tests/opt-keep-going-multiple.exp
The NetBSD Test Fixture wrote:
> nbmake[2]: stopped in
> /tmp/build/2020.12.06.12.54.32-i386/obj/sys/arch/i386/compile/LEGACY
More specifically:
--- mpu_acpi.o ---
/tmp/build/2020.12.06.12.23.13-i386/src/sys/dev/acpi/mpu_acpi.c: In function
'mpu_acpi_attach':
Andreas Gustafsson wrote:
> [External Email. Be cautious of content]
>
>
> The build is now failing with:
Ah, sorry there's some step I missed
>
> === 2 extra files in DESTDIR =
> Files in DESTDIR but missing from flist.
> File is obsolete or flist is out of date ?
>
Andreas Gustafsson wrote:
> The build is now failing with:
Hopefully fixed now.
>
> === 2 extra files in DESTDIR =
> Files in DESTDIR but missing from flist.
> File is obsolete or flist is out of date ?
> --
>
The build is now failing with:
=== 2 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/tests/usr.bin/make/unit-tests/objdir-writable.exp
The build is still failing, but now with a different error:
nbmake[5]: "/tmp/build/2020.11.13.08.33.07-i386/src/external/ofl/Makefile"
line 3: Malformed conditional (${MKX11} != "no")
--
Andreas Gustafsson, g...@gson.org
The NetBSD Test Fixture wrote:
> nbmake[7]: nbmake[7]: don't know how to make -ltermlib. Stop
The build is still failing. The problems started with this commit:
2020.11.08.21.56.47 nia src/external/bsd/kyua-cli/Makefile.inc,v 1.8
2020.11.08.21.56.47 nia
Should be fixed now...
On Wed, 4 Nov 2020, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.11.04.18.12.19.
An extract from the
Working on it ...
On Wed, 4 Nov 2020, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.11.04.18.12.19.
An extract from the build.sh
On Fri, Oct 30, 2020 at 03:02:16PM +0900, Rin Okuyama wrote:
> On 2020/10/30 2:10, Rin Okuyama wrote:
> > On 2020/10/30 1:58, nia wrote:
> > > It should be fixed already.
> >
> > Please also try build for sun2, which does not support shlib;
> > All programs linked to libsqlite3 need -lm
On 2020/10/30 2:10, Rin Okuyama wrote:
On 2020/10/30 1:58, nia wrote:
It should be fixed already.
Please also try build for sun2, which does not support shlib;
All programs linked to libsqlite3 need -lm explicitly.
Periodic build for sun2 and vax is broken due to the sqlite3 change:
nia wrote:
> It should be fixed already.
It's not, it's now failing earlier in the build:
http://releng.netbsd.org/b5reports/i386/commits-2020.10.html#2020.10.29.16.35.33
--
Andreas Gustafsson, g...@gson.org
Yes, your commit message arrived here while I was typing the message
containing my (obviously incorrect, and now discarded) patch, along
with the rant.
kre
On 2020/10/30 1:58, nia wrote:
It should be fixed already.
Please also try build for sun2, which does not support shlib;
All programs linked to libsqlite3 need -lm explicitly.
Thanks,
rin
It should be fixed already.
Date:Thu, 29 Oct 2020 15:53:25 + (UTC)
From:NetBSD Test Fixture
Message-ID: <160398680587.14474.16594358311982355...@babylon5.netbsd.org>
|
/tmp/build/2020.10.29.12.38.06-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
On 12/09/2020 07:40, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.09.12.01.36.26.
An extract from the build.sh output follows:
The NetBSD Test Fixture wrote:
> --- kern-XEN3PAE_DOMU ---
> *** [netbsd] Error code 1
> nbmake[2]: stopped in
> /tmp/bracket/build/2020.08.09.11.04.05-i386/obj/sys/arch/i386/compile/XEN3PAE_DOMU
Specifically:
--- kern-XEN3PAE_DOMU ---
> Date: Sun, 26 Jul 2020 15:20:05 +0300
> From: Andreas Gustafsson
>
> The build is still failing, current error as of 2020.07.26.09.17.24:
>
> === 1 extra files in DESTDIR =
> Files in DESTDIR but missing from flist.
> File is obsolete or flist is out of date ?
>
The build is still failing, current error as of 2020.07.26.09.17.24:
=== 1 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
> I just committed usr.bin/make/var.c r1.270 which seems to fix
> everything.
Confirmed. Thanks for a quick response.
---
Izumi Tsutsui
On 19.07.2020 19:34, Andreas Gustafsson wrote:
> The build is still broken as of source date 2020.07.19.16.22.44:
>
>
> http://releng.netbsd.org/b5reports/i386/commits-2020.07.html#2020.07.19.16.22.44
I'm sorry, I should have had a build running in parallel to my changes
all the time.
I just
The build is still broken as of source date 2020.07.19.16.22.44:
http://releng.netbsd.org/b5reports/i386/commits-2020.07.html#2020.07.19.16.22.44
--
Andreas Gustafsson, g...@gson.org
This has already been fixed - thanks, Roy!
On Fri, 3 Jul 2020, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.07.03.11.03.42.
An
On 20-06-21 13:21, Andreas Gustafsson wrote:
| Luke,
|
| You wrote:
| > I think I've fixed it with 2 follow up commits in tests/lib
|
| There's a new error:
|
|
http://releng.netbsd.org/b5reports/i386/2020/2020.06.21.08.02.43/build.log.tail
|
| --
| Andreas
Andreas Gustafsson wrote:
> I'll change bracket to look for that and see how it works.
>
> > BTW if this behavior change is a problem for your automation, you can
> > disable it by setting .MAKE.DIE_QUIETLY=no
>
> That would be counter to my principle of testing with default settings.
Sure,
Simon J. Gerraty wrote:
> Simon J. Gerraty wrote:
> > > It would be helpful for both human and robotic users if error messages
> > > consistently included the word "error", or if there was some other easy
> > > way of identifying them in the build log.
> >
> > The regex 'make.*stopped' is the
Simon J. Gerraty wrote:
> > It would be helpful for both human and robotic users if error messages
> > consistently included the word "error", or if there was some other easy
> > way of identifying them in the build log.
>
> The regex 'make.*stopped' is the best clue to look for since it will
>
Andreas Gustafsson wrote:
> [External Email. Be cautious of content]
>
>
> Martin pointed me to this error some 63 lines from the end of the log:
>
> --- dependall-tests ---
> nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop
>
> I think the reason I didn't find it myself is
Hi Andreas
The failure is:
--- dependall-tests ---
dependall ===> tests/lib/libm
--- dependall-tests ---
nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop
..
--- dependall-tests ---
nbmake[7]: stopped in
/tmp/bracket/build/2020.06.21.03.39.21-i386/src/tests/lib/libm
btw the log
Thanks for the heads up.
I think I've fixed it with 2 follow up commits in tests/lib
Cheers,
Luke
> On 21 Jun 2020, at 19:10, Andreas Gustafsson wrote:
>
> Martin pointed me to this error some 63 lines from the end of the log:
>
> --- dependall-tests ---
> nbmake[7]: nbmake[7]: don't know
On Sun, Jun 21, 2020 at 12:00:41PM +0300, Andreas Gustafsson wrote:
> Martin pointed me to this error some 63 lines from the end of the log:
>
> --- dependall-tests ---
> nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop
>
> I think the reason I didn't find it myself is that I
Martin pointed me to this error some 63 lines from the end of the log:
--- dependall-tests ---
nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop
I think the reason I didn't find it myself is that I have developed a
habit of searching for the message "Error code 1" (or similar
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2020.06.21.03.39.21.
>
> The following commits were made between the last
On 12/06/2020 16:13, NetBSD Test Fixture wrote:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.06.12.11.21.36.
An extract from the build.sh output follows:
On Fri, May 22, 2020 at 12:07:52AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2020.05.21.21.12.31.
...
> ---
I am using this diff but I am not sure what I am doing.
Index: tests/rump/modautoload/Makefile
===
RCS file: /cvsroot/src/tests/rump/modautoload/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
---
Andrew Doran writes:
> Doesn't show up in Opengrok, maybe it dislikes rump. Already fixed.
opengrok is missing massive portions of src, please don't
rely upon it to find "all" of anything.
... or can we have it fixed please? :)
(grep -r across 'src' is really fast on a modern system when
it's
Doesn't show up in Opengrok, maybe it dislikes rump. Already fixed.
Andrew
On Sun, Apr 19, 2020 at 09:56:55PM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64
Date:Fri, 17 Apr 2020 14:08:27 + (UTC)
From:NetBSD Test Fixture
Message-ID: <158713250771.23564.16282845902177835...@babylon5.netbsd.org>
| The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
| using sources from CVS date 2020.04.17.11.21.06.
Fix committed. The compiler was correct - I reused code around
frame_list from setup, didn't notice the type is different.
Thank yo.
Jaromir
Le ven. 10 avr. 2020 à 22:35, Robert Elz a écrit :
>
> Date:Thu, 9 Apr 2020 22:24:47 + (UTC)
> From:NetBSD Test Fixture
>
Date:Thu, 9 Apr 2020 22:24:47 + (UTC)
From:NetBSD Test Fixture
Message-ID: <158647108721.6125.11585167398565454...@babylon5.netbsd.org>
| This is an automatically generated notice of a NetBSD-current/i386
| build failure.
The i386 build remains broken since
On 05.04.2020 01:14, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2020.04.04.21.36.15.
>
> An extract from the build.sh output
The NetBSD Test Fixture wrote:
> --- dependall-gdb ---
>
> CC=/tmp/bracket/build/2020.04.02.11.52.41-i386/tools/bin/i486--netbsdelf-c++
> /tmp/bracket/build/2020.04.02.11.52.41-i386/tools/bin/nbmkdep -f maint.d.tmp
> -- -std=gnu++11
>
Date:Thu, 2 Apr 2020 14:09:14 + (UTC)
From:NetBSD Test Fixture
Message-ID: <158583655484.15292.8162724620486601...@babylon5.netbsd.org>
| An extract from the build.sh output follows:
|
| #create libgdb/maint.d
| --- dependall-gcc ---
|
Fixed with 1.18 src/sys/rump/librump/rumpkern/sleepq.c
Apologies, forgot to commit earlier.
Andrew
On Thu, Mar 26, 2020 at 10:36:27PM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on
Fixed with src/sys/kern/vfs_vnode.c 1.115.
Andrew
On Sun, Mar 22, 2020 at 04:23:47PM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources
Should be fixed with 1.91 src/sys/miscfs/genfs/genfs_io.c.
Andrew
On Sat, Mar 14, 2020 at 07:46:02PM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
>
On 07.03.2020 20:43, Andreas Gustafsson wrote:
> The NetBSD Test Fixture wrote:
>> cc1: all warnings being treated as errors
>> *** [t_ptrace_wait.o] Error code 1
>
> The compiler error message did not appare because it was too far
> back from the end of the build log (5149 lines):
>
>
The NetBSD Test Fixture wrote:
> cc1: all warnings being treated as errors
> *** [t_ptrace_wait.o] Error code 1
The compiler error message did not appare because it was too far
back from the end of the build log (5149 lines):
--- dependall-sys ---
In article <20200303122717.gb...@mail.duskware.de>,
Martin Husemann wrote:
>On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote:
>> Would it be too much to ask that imports of entire new subsystems like
>> this be at least build tested with "build.sh release"?
>
>The lossage in
On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote:
> Would it be too much to ask that imports of entire new subsystems like
> this be at least build tested with "build.sh release"?
The lossage in this case seems to depend on -j values and whether you do
incremental builds, so not
NetBSD Test Fixture wrote:
> *** [cleandir-pamu2fcfg] Error code 2
> nbmake[7]: stopped in
> /tmp/bracket/build/2020.03.03.00.47.33-i386/src/external/bsd/pam-u2f/bin
The build is still broken as of source date 2020.03.03.08.56.05:
> On Mar 1, 2020, at 8:05 AM, Andrius V wrote:
>
> Hi,
>
> Was the build failure noticed? Seems like this commit is at fault:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/if_stge.c.diff?r1=1.79=1.80_with_tag=MAIN=h
>
Working on this now.
> ../../../../dev/pci/if_stge.c: In
The NetBSD Test Fixture wrote:
> *** [hifn7751.o] Error code 1
> nbmake[8]: stopped in
> /tmp/bracket/build/2020.02.29.11.03.44-i386/src/sys/modules/hifn
Specifically:
--- dependall-hifn ---
In file included from
On Thu, Feb 27, 2020 at 09:18:59AM +0200, Andreas Gustafsson wrote:
> The NetBSD Test Fixture wrote:
> > nbmake[8]: nbmake[8]: don't know how to make libpam_echo.so.. Stop
>
> This was fixed but the build is still broken as of 2020.02.27.03.25.08:
>
> # link rescue/rescue
> [...]
>
The NetBSD Test Fixture wrote:
> nbmake[8]: nbmake[8]: don't know how to make libpam_echo.so.. Stop
This was fixed but the build is still broken as of 2020.02.27.03.25.08:
# link rescue/rescue
[...]
1 - 100 of 263 matches
Mail list logo
