Updating src tree:
P
src/external/gpl3/gcc/dist/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc
P
src/external/gpl3/gcc/dist/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
P src/external/gpl3/gcc/dist/libstdc++-v3/src/c++98/compatibility.cc
P src/external/gpl3/gcc/dist/libstdc++-v3/s
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2019.04.23.17.35.10 christos src/usr.bin/uniq/uniq.c,v 1.22
Log files can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2019.04.html#20
On Sun, 21 Apr 2019 at 07:38, Martin Husemann wrote:
>
> On Sat, Apr 20, 2019 at 08:31:29PM +, m...@netbsd.org wrote:
> > I understand it's meant to aim for 80x25, which is what we used to have.
> > There were some complaint threads about how much smaller DRM/KMS made
> > things, but perhaps p
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.04.23.14.40.12.
An extract from the build.sh output follows:
--- net.d ---
#create libiscntp/net.d
On Tue, Apr 23, 2019 at 04:38:31PM +0100, Chavdar Ivanov wrote:
> Update - it now works fine for me.
Now, updated module works fine for me too.
Regards,
--
Piotr 'aniou' Meyer
Update - it now works fine for me.
On Tue, 23 Apr 2019 at 17:35, Piotr Meyer wrote:
>
> On Wed, Apr 17, 2019 at 01:13:50PM +0100, Chavdar Ivanov wrote:
> [...]
>
> > The problem I am having is with NetBSD-current, amd64. I am able to
> > install it and run it with the default accelleration, which
On Wed, Apr 17, 2019 at 01:13:50PM +0100, Chavdar Ivanov wrote:
[...]
> The problem I am having is with NetBSD-current, amd64. I am able to
> install it and run it with the default accelleration, which is
> obviously very slow (perhaps 20-30 times, I haven't measured). If I
> use nvmm, I consisten
an...@smutek.pl (Piotr Meyer) writes:
>Just for curiosity - from where is selection algorithm called in
>following case?
>I'm thinking about following case:
>drmkms0 at i915drmkms0
>drmkms0: interrupting at ioapic0 pin 16 (i915)
>i915drmkms0: framebuffer at 0x8000453d5000, size 1920x1080, dep
On Sun, Apr 21, 2019 at 08:38:17AM +0200, Martin Husemann wrote:
[...]
> It is way too big on my old 14" pinebook too, we need a better selection
> algorithm (or maybe there is a bug, I'll check resulting rows/columns
> with the default font next week).
Just for curiosity - from where is selecti
