Robert Elz wrote:
> There's no info in the log (the available log on the website) to allow
> anyone to work out what happened there (why is make debug enabled? The
> log that is there is filled with make debug noise)
I don't know the answer to this, but the question is known as PR 53561.
--
Andr
Updating src tree:
P src/distrib/sets/lists/xcomp/mi
P src/doc/3RDPARTY
P src/doc/CHANGES
P src/doc/CHANGES.prev
P src/external/bsd/tmux/dist/CHANGES
P src/external/bsd/tmux/dist/Makefile.am
P src/external/bsd/tmux/dist/Makefile.in
P src/external/bsd/tmux/dist/TODO
P src/external/bsd/tmux/dist/ac
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2019.11.13.00.19.46 kre src/external/bsd/tmux/dist/tty-keys.c,v 1.12
Log files can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2019.1
Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit :
> Not seen this locally, but that would be the switch to bsd/libarchive tar
| that that (building in the middle of an update) was what happened
| here, and that the next build might just work.
It didn't, but the build log this time contained enough info to allow
the problem (yet more gcc being stupid) to be determined. Might be fixed now.
kre
Date:Tue, 12 Nov 2019 21:38:15 + (UTC)
From:NetBSD Test Fixture
Message-ID: <157359469562.5635.13398973468170352...@babylon5.netbsd.org>
| This is an automatically generated notice of a NetBSD-current/i386
| build failure.
There's no info in the log (the avai
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 2019.11.12.19.44.46.
An extract from the build.sh output follows:
The prerequisites of `all' are being made.
Liv
Fixed in:
src/tests/lib/libc/sys/t_ptrace_wait.c r.1.141
src/tests/lib/libc/sys/t_ptrace_wait.h r.1.18
On 12.11.2019 18:34, Paul Goyette wrote:
> I've confirmed that these failures occur with builds from before
> my most recent changes. So, as Kamil indicated (and Joerg on
> IRC), it ain't my fa
I've confirmed that these failures occur with builds from before
my most recent changes. So, as Kamil indicated (and Joerg on
IRC), it ain't my fault!
On Tue, 12 Nov 2019, Paul Goyette wrote:
Hmmm, this might be my fault. Checking/bisecting now...
On Tue, 12 Nov 2019, NetBSD Test Fixture wro
On Tue, Nov 12, 2019 at 8:51 AM Joerg Sonnenberger wrote:
>
> On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote:
> > David Brownlee writes:
> >
> > > On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček
> > > wrote:
> > >>
> > >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a
> > >> écrit
On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote:
> David Brownlee writes:
>
> > On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček
> > wrote:
> >>
> >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit
> >> :
> >>>
> >>> Not seen this locally, but that would be the switch to bsd/li
David Brownlee writes:
> On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček
> wrote:
>>
>> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit :
>>>
>>> Not seen this locally, but that would be the switch to bsd/libarchive tar.
>>> Maybe it does not unlink files before extraction and replaces the
The problem is in ATF tests with assumptions that are no longer valid.
We are working on this. The right fix is to improve the tests.
On 12.11.2019 13:53, Paul Goyette wrote:
> Hmmm, this might be my fault. Checking/bisecting now...
>
> On Tue, 12 Nov 2019, NetBSD Test Fixture wrote:
>
>> Thi
On Tue, 12 Nov 2019, Kamil Rytarowski wrote:
The problem is in ATF tests with assumptions that are no longer valid.
We are working on this. The right fix is to improve the tests.
Oh, good - not my fault after all!
Thanks!
On 12.11.2019 13:53, Paul Goyette wrote:
Hmmm, this might be my
Hmmm, this might be my fault. Checking/bisecting now...
On Tue, 12 Nov 2019, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals
lib/libc/s
On Tue, 12 Nov 2019 at 11:33, Jaromír Doleček wrote:
>
> Le mar. 12 nov. 2019 à 12:05, Martin Husemann a écrit :
>>
>> Not seen this locally, but that would be the switch to bsd/libarchive tar.
>> Maybe it does not unlink files before extraction and replaces them in-space?
>>
>> I do the same kin
On 12.11.2019 09:26, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals
> lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_
On Tue, Nov 12, 2019 at 12:05:14PM +0100, Martin Husemann wrote:
> Not seen this locally, but that would be the switch to bsd/libarchive tar.
> Maybe it does not unlink files before extraction and replaces them in-space?
It doesn't unlink them by default, yes. -U would force that.
Joerg
Not seen this locally, but that would be the switch to bsd/libarchive tar.
Maybe it does not unlink files before extraction and replaces them in-space?
I do the same kind of updates, but usually on a very quiet system.
The crashes you see are from other running processes? Joerg would likely
say:
Prior to NetBSD-9 I extracted sets (bar etc) over running systems without
any issues
Now with NetBSD-9 I frequently get bus errors from running code when base
is extracted
[1] Bus error /bin/ln -sf "${src}" "${dest}"
*** Error code 138
This would be while "tar xzpf
/opt/netbsd/
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals
lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit
lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals
21 matches
Mail list logo
