the same machine - if you
enable Hyper-V, VirtualBox stops working. Obviously this still doesn't
mean this is the reason, but is likely.
]
On Sat, 16 Feb 2019 at 21:37, Chavdar Ivanov wrote:
>
> Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll
> build a new kernel
Thanks, I will try the suggested fix after the build completes.
On Sat, 16 Feb 2019 at 21:42, Cherry G.Mathew wrote:
>
> Chavdar Ivanov writes:
>
> > Mine is 8.99.34 from 09/02/2019, self build, works just fine. I'll
> > build a new kernel now to compare.
>
I always have a few NewBSD guests under VirtualBox, I have never
disabled SVS so far.
On Sun, 17 Feb 2019 at 09:20, Martin Husemann wrote:
>
> On Sun, Feb 17, 2019 at 09:23:41AM +0100, Adam wrote:
> > VirtualBox does not support SVS.
>
> I am not sure how to parse that - what part of Virtual Box
guest to setup a dedicated build host, so
wanted at least 4 CPUs...
On Sun, 17 Feb 2019 at 17:33, Chavdar Ivanov wrote:
>
> I always have a few NewBSD guests under VirtualBox, I have never
> disabled SVS so far.
>
> On Sun, 17 Feb 2019 at 09:20, Martin Husemann wrote:
> >
>
Hi,
I run a few NetBSD VMs under XCP-NG in PV mode, booting unmodified
XEN3_DOMU of their respective releases. One is an amd64 8_STABLE from
december 2018 vintage, which continues to properly
shutdown/poweroff/reboot. The others closely follow -current, right
now running a kernel and userland
wrote:
>
> On 19 February 2019 11:31:37 PM MYT, Martin Husemann
> wrote:
> >On Tue, Feb 19, 2019 at 03:28:23PM +, Chavdar Ivanov wrote:
> >> Any bells ringing?
> >
> >I think this already has been fixed by Cherry?
> >
> >Martin
>
>
uild
A moz.build file called the error() function.
The error it encountered is:
No TimeStamp implementation on this platform. Build will not succeed
Correct the error condition and try again.
...
I have PYTHON_VERSION_DEFAULT=37, if this is relevant. The platform is
amd64, -current from yestrday.
Chavdar Ivanov
--
, Jan Beich wrote:
>
> Chavdar Ivanov writes:
>
> > Hi,
> >
> > I got:
> > ..
> > File "/usr/pkg/.wrkobjdir/www/firefox/work/firefox-65.0/configure.py",
> > line 118, in config_status
> > [0/1910]
&g
Eventually completed and working fine. First attempt had cargo hung, I
waited for parhaps an hour, there was no activity, so I interrupted
and restarted make (without cleaning, I've had that previously).
On Fri, 1 Feb 2019 at 17:29, Chavdar Ivanov wrote:
>
> I had a look at this report and
.
On Fri, 1 Feb 2019 at 22:51, bch wrote:
>
>
>
> On Fri, Feb 1, 2019 at 23:17 Chavdar Ivanov wrote:
>>
>> Eventually completed and working fine. First attempt had cargo hung, I
>> waited for parhaps an hour, there was no activity, so I interrupted
>> and restar
Hi,
I have been having lately X crash when I try to input a single character
in Emacs 26.1 window when using a keyboard different from the default
one. In my case, apart from the default en-GB keyboard, I have also
Italian and Bulgarian one, they both work fine - например тук - with the
I did a full build yesterday and my iwm works fine.
On Wed, 30 Jan 2019, 09:53 Paul Goyette That should have been fixed already, but the build cluster might not
> have picked up the fix. If you can't build your own kernel, wait for
> the next build cycle. Other folks who had the same problem
Just FYI - I am getting the same message whe starting kde4's konqueror:
There was an error loading the module Dolphin View.
The diagnostics is:
Cannot load library /usr/pkg/lib/kde4/dolphinpart.so:
(/usr/X11R7/lib/libGL.so.3: Use of initialized Thread Local Storage
with model initial-exec and
Please don't be so quick reverting the Intel driver. With today's build my
laptop is working very well, I have no visible effects, glmark2 executes as
expected with the exception of the crash upon exit, Kde4 was previously
crashing on testing the gl capability, now everything works. Great work, in
With these two settings now kdm, xdm and slim work as expected;
previously the username and the password echo did not show properly.
Now my Intel graphics works rather well. I get hangs only when I run
some of the xscreensaver demos in full screen mode, rendering the
mouse/keyboard unresponsive -
FYI glmark2 ran rather well under VirtualBox a moment ago with a few
hours old system, only crashing on exit:
...
Reading symbols from /usr/pkg/bin/glmark2...done.
[New process 1]
[New process 4]
Core was generated by `glmark2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0
I have on occasion similar behaviour on my HP Envy laptop using the
530 graphics, it is rather weird. I also get the messages about not
being able to load the two microcode files, even if I have placed them
in the right location.
On Thu, 11 Apr 2019 at 21:31, Ron Georgia wrote:
>
> My monitor is
On Fri, 31 May 2019 at 02:07, Joerg Sonnenberger wrote:
>
> On Thu, May 30, 2019 at 09:32:24PM +0100, Chavdar Ivanov wrote:
> > error: 'asm' undeclared (first use in this function)
> > asm volatile ("pause");
> > ^~~
> > ...
> >
Hi,
Forget about this thread - replacing 'asm' with '__asm' in cpufunc.h
solves the problem, as was indeed mentioned above. VirtualBox
extensions compile ok.
On Fri, 31 May 2019 at 08:11, Chavdar Ivanov wrote:
>
> On Fri, 31 May 2019 at 02:07, Joerg Sonnenberger wrote:
> >
> &
Hi,
That was badly described. It is not just hal crash, it is NetBSD panic
when hal is starting. Obvious from the trace, but still.
On Thu, 30 May 2019 at 14:49, Chavdar Ivanov wrote:
>
> Hi,
>
>
> I got a repeatable crash of hal under 8.99.42; running ok under 8.99.41
> from
Hi,
I got a repeatable crash of hal under 8.99.42; running ok under 8.99.41
from the 27th of May. I have disabled hal for the moment. The dmesg of
the panic looks as follows:
...
[ 34.627608] acpibat0: normal capacity on 'charge state'
[ 66.605334] fatal protection fault in supervisor
- should I continue to locally modify
cpufunc.h from the NetBSD src/sys/arch/x86/include/ ? What is the
purpose of having 'asm volatile' if __asm__ does the job (and volatile
is a NOP anyway, according to the gcc manual, it is considered
volatile without the keyword)?
On Sun, 12 May 2019 at 20:5
На 2019-05-31 в 08:05, matthew green написа:
>> I don't seem to be able to get the core into gdb 8.3 either with target
>> kvm or with target kcore. How does one do this now with this version of
>> gdb?
> christos put the 'target kvm' support back in today.
> update and rebuild gdb and it should
I just had the same installing a -current guest under XCP-NG; I
thought there was some problem with the screen emulation, though. I
did manage to complete the installation, as despite the wrong display
overall, the current line is shown correctly and one is able to select
whatever choices one
On Thu, 30 May 2019 at 09:29, Martin Husemann wrote:
>
> On Wed, May 29, 2019 at 06:15:52PM -, Christos Zoulas wrote:
> > >> - we have very obvious display bugs at first sight in xdm
> > >
> > >let's revert to the old xdm for now. this one should be easy.
> > >can someone work on it please?
На 2019-05-30 в 12:56, Martin Husemann написа:
> On Thu, May 30, 2019 at 12:25:42PM +0100, Chavdar Ivanov wrote:
>>> Michael looked into it, and it seems to be code bugs (calculating the
>>> edit field sizes and border coordinates). It is not just resource changes.
>&g
My two pennies...
I use -current on an HP Envy 17 with what is reported as Intel 530
graphics. It also has an NVidia GeForce 950M chip, but this is not
usable for now by NetBSD, although correctly identified. The new
graphics driver together with the Mesa updates finally got me with a
proper
На 2019-06-01 в 12:33, Kamil Rytarowski написа:
> On 01.06.2019 12:01, matthew green wrote:
>> so, i just updated a few X11 packages in -current. as part
>> of testing, i ran them on the sandy bridge laptop i've seen
>> display glitches with the new intel driver on (mate-terminal).
>>
>> these
My HP Envy laptop boots NetBSD-current in EFI mode for quite some time
now, perhaps a year. The GeForce 950M doesn't work, as expected, but
the Intel 530 now works perfectly fine with full 3D acceleration and
quite decent full screen video.
On Wed, 5 Jun 2019 at 20:32, Frank Kardel wrote:
>
>
Hi,
with sources updated an hour or so ago I get:
..
/home/sysbuild/amd64/tools/bin/nbmakefs -M 1475346432 -m 1475346432
-B 1234 -F
work.spec -N w
ork/etc
-o bsize=16384,fsize=2048,density=8192
I managed to test it already - 8.99.43 installation went fine on a
XCP-NG guest, no screen problems whatsoever.
On Sun, 9 Jun 2019 at 17:12, David Brownlee wrote:
>
> On Sun, 9 Jun 2019 at 09:00, Brett Lymn wrote:
> >
> > On Sat, Jun 08, 2019 at 01:25:24AM +0300, Valery Ushakov wrote:
> > >
> >
Not any more, I just finished one.
On Mon, 17 Jun 2019 at 19:45, Andreas Gustafsson wrote:
>
> The build is still failing as of source date 2019.06.17.16.34.02:
>
> -- kern-INSTALL ---
> /tmp/bracket/build/2019.06.17.16.34.02-i386/tools/bin/i486--netbsdelf-ld:
> chfs_vfsops.o: in function
Cool, thanks!
On Tue, 18 Jun 2019 at 21:01, wrote:
>
> On Tue, Jun 18, 2019 at 07:58:07PM +0100, Chavdar Ivanov wrote:
> > /usr/X11R7/lib/pkgconfig/gl.pc file contains:
> >
> > Libs: -Wl,-rpath,${libdir} -L${libdir} -l@GL_PKGCONF_LIB@
> >
> >
>
/usr/X11R7/lib/pkgconfig/gl.pc file contains:
Libs: -Wl,-rpath,${libdir} -L${libdir} -l@GL_PKGCONF_LIB@
There are quite a few packages which fail with the default pkgsrc
setup because of that.
Perhaps the variable GL_PKGCONF_LIB should be defined somewhere? I
guess this depends on
Hi,
Perhaps not for current-users@, but on yesterday's -current and with
updated pkgsrc I get the following while building lang/mono:
.
@ymir - /usr/pkgsrc/lang/mono/work/mono-4.0.4/mono/mini -
gdb /usr/bin/ld ld.core
GNU gdb (GDB) 8.3
...
Reading symbols from /usr/bin/ld...
(No debugging
. Not that I personally use it, but there are gnome
bits dependend on it ( which I currently comment out ).
On Wed, 19 Jun 2019 at 05:03, wrote:
>
> On Tue, Jun 18, 2019 at 10:02:47PM +0100, Chavdar Ivanov wrote:
> > Hi,
> >
> > Perhaps not for current-users@, but
---
/p/VirtualBox-6.0.8/src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c.ORIG
2019-06-19 19:48:40.880337377 +0100
+++ /p/VirtualBox-6.0.8/src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c
2019-06-19 19:48:51.063261324 +0100
@@ -1011,7 +1011,7 @@
error =
He has done it already.
On Thu, 20 Jun 2019 at 09:10, wrote:
>
> On Wed, Jun 19, 2019 at 06:55:06PM +0100, Chavdar Ivanov wrote:
> > ---
> > /p/VirtualBox-6.0.8/src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c.ORIG
> >2019-06-19 19:48:40.880337377 +0100
&g
strike that down, bad update (there was a panic after sysupgrade,
before reboot; subsequent sysupgrade fixed it).
On Thu, 20 Jun 2019 at 19:31, Chavdar Ivanov wrote:
>
> However, on 8.99.47, I am stuck:
> ..
> gcc -Wl,-rpath /usr/X11R7/lib -m64 -o
> /p/Virtu
: ***
[/p/VirtualBox-6.0.8/out/netbsd.amd64/release/obj/VBoxClient/VBoxClient]
Error 1
No idea what this is .
On Thu, 20 Jun 2019 at 08:21, Chavdar Ivanov wrote:
>
> He has done it already.
>
> On Thu, 20 Jun 2019 at 09:10, wrote:
> >
> > On Wed, Jun 19, 2019 at 06:55:06PM +01
You are using very old VirtualBox version from pkgsrc/wip. This is
something I haven't bothered ever to try. I download the source from
VirtualBox and build it myself. All you need is kbuild and yasm and
LocalConfig.kmk with the following contents:
...
VBOX_WITHOUT_HARDENING := 1
I had the same. Changed the emulated device to Intel audio, now it boots OK.
On Fri, 10 May 2019 at 18:56, Christoph Badura wrote:
>
> Yesterday I tried booting an amd64 install iso from sources updated
> around 16:00 UTC under virtualbox 6.0.6. The kernel paniced with
> panic:
tion is fine.
On Fri, 10 May 2019 at 20:47, Mayuresh wrote:
>
> On Fri, May 10, 2019 at 08:25:45PM +0100, Chavdar Ivanov wrote:
> > You are using very old VirtualBox version from pkgsrc/wip. This is
> > something I haven't bothered ever to try. I download the source from
>
Hi,
While The said version compiles cleanly under 8.99.37 (I did it a few
days ago), today under 8.99.39 it fails for me as follows:
/p/VirtualBox-6.0.6/out/netbsd.amd64/release/obj/netbsd/include/x86/cpufunc.h:
In function 'x86_pause':
:
>
> On Sat, May 11, 2019 at 11:25:42PM +0100, Chavdar Ivanov wrote:
> > There is definitely some recent problem with the new Intel driver. A few
> > days ago, still under 8.99.37, it worked very well for me (Intel 530).
> > glmark2 completed with no problems, videos were played as
На 2019-05-11 в 06:10, Kamil Rytarowski написа:
> On 11.05.2019 04:54, Kamil Rytarowski wrote:
>> On 10.05.2019 08:29, matthew green wrote:
>>> this is probably the recently discussed intel driver issues.
>>> i've added a build option to use the older driver.
>>>
>>> can you try build with
На 2019-05-12 в 07:34, Kamil Rytarowski написа:
> On 12.05.2019 08:09, Martin Husemann wrote:
>> On Sat, May 11, 2019 at 11:25:42PM +0100, Chavdar Ivanov wrote:
>>> There is definitely some recent problem with the new Intel driver. A few
>>> days ago, still under 8
Sure, although the last time I did this was months ago.
On Fri, 10 May 2019 at 02:29, Mayuresh wrote:
> On Thu, May 09, 2019 at 09:43:10PM +0100, Chavdar Ivanov wrote:
> > While The said version compiles cleanly under 8.99.37 (I did it a few
> > days ago), today under 8.99.39
I haven't tested if this happens on NetBSD8, on -current every time I
reinstall x11-lnks (after osabi, hence on every bump of -current), I
have to:
--- /usr/pkg/share/x11-links/lib/pkgconfig/gl.pc.ORIG 2019-05-09
19:52:57.141922336 +0100
+++ /usr/pkg/share/x11-links/lib/pkgconfig/gl.pc
На 2019-04-29 в 18:34, John D. Baker написа:
> I managed to fire up another machine w/intel graphics I have. It uses:
>
> [...]
> i915drmkms0 at pci0 dev 2 function 0: Intel 82946GZ Integrated Graphics
> Device (rev. 0x02)
> [...]
> kern info: [drm] Memory usable by graphics device = 512M
>
Hi,
On fresh -current I am getting:
checking for swig... /usr/pkg/bin/swig
checking swig version... 1.3.38
configure: Configuring python swig binding
checking for Python includes... -I/usr/pkg/include/python3.7
checking for compiling Python extensions... gcc -pthread -fPIC
checking for
, Chavdar Ivanov wrote:
>
> Hi,
>
>
> On fresh -current I am getting:
>
>
>
> checking for swig... /usr/pkg/bin/swig
> checking swig version... 1.3.38
> configure: Configuring python swig binding
> checking for Python includes... -I/usr/pkg/include/pytho
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 t
Very similar experience with kdm in the same environment. Click on the
username, enter it, nothing apperas. Click on the password, enter it,
ditto. Press Enter, and you are in. If you mistype a password, second
time the username is displayed correctly. So far the best experience
has been starting
Hi,
On a VirtualBox guest running amd64 -current as of 2-3 hours ago with
the builtin vboxvideo driver I get now:
[87.285] (II) AIGLX: Screen 0 is not DRI2 capable
[87.327] (EE) AIGLX error: dlopen of
/usr/X11R7/lib/modules/dri/swrast_dri.so failed
Hi,
A couple of days ago I built wip/qemu-nvmm to find out if I can use
this setup instead of xen on one particular laptop I have in use now.
Cudos to this - my initial tries were very promising, I think I can
easily run some 8-10 VMs on this hardware. I installed a couple of
Linux distributions
ig", 0,
0xff8295b8) Err#2 ENOENT
so there is the directory name twice, in reality the installation
places the file in /usr/pkg/etc/mono/config.
# cd /usr/pkg/etc/mono ; ln -s . mono
sorts it.
On Wed, 14 Aug 2019 at 20:14, wrote:
>
> On Tue, Aug 13, 2019 at 12:00:31PM +0100, Chavda
BTW I just noticed there are no gnome packages in
/usr/pkgsrc/meta-packages any more, while there are still some in x11
directory - was there any announce that it has been phased out?
On Thu, 15 Aug 2019 at 13:09, Chavdar Ivanov wrote:
>
> It actually is a part of the package:
>
On Thu, 15 Aug 2019 at 15:12, wrote:
>
> On Thu, Aug 15, 2019 at 02:50:52PM +0100, Chavdar Ivanov wrote:
> > BTW I just noticed there are no gnome packages in
> > /usr/pkgsrc/meta-packages any more, while there are still some in x11
> > directory - was there any announce
Hi,
I haven't been able to build lang/mono on -current ( or elsewhere, for
that matter ) for quite some time. I tend to try periodically on
version jumps and pkgsrc updates to build it - not that I have a
particular use for it, but for the bits needed by gnome.
The failure I got this time was of
Thanks, I didn't have it yer in my wip clone, I pulled it and am
trying to build now.
On Tue, 13 Aug 2019 at 09:50, wrote:
>
> wip/mono6 should be a replacement that works on netbsd.
> (still some issues to fix, like LD_LIBRARY_PATH=/usr/X11R7/lib for
> graphical stuff being necessary)
--
07d] in :0
--- End of inner exception stack trace ---
at Mono.Driver.Main (System.String[] args) [0x00010] in
:0
LD_LIBRARY_PATH=/usr/X11R7lib in the environment did not make a difference.
On Tue, 13 Aug 2019 at 09:18, Chavdar Ivanov wrote:
>
> Thanks, I didn't have it yer in my wip clone, I pulle
Thanks, it's fine. I didn't add 'zfs=YES' to /etc/rc.conf as running
'/etc/rc.d/zfs start' without it did not produce the usual warning of
undefined variable.
On Mon, 16 Sep 2019 at 12:21, Brad Spencer wrote:
>
> Chavdar Ivanov writes:
>
> > Since yesterday I don't get my z
Since yesterday I don't get my zfs fule systems automatically mounted,
I have to issue 'zfs mount -a'.
Should I add some entry in /etc/fstab or place the above command in
one of the scripts?
The zvols are accessible as usual.
On Sat, 7 Sep 2019 at 14:54, Brad Spencer wrote:
>
> m...@netbsd.org
upstream TeXmacs
distribution file. I haven't dealt so far with extended headers and am
apparently somewhat confused where the problem lies.
Chavdar Ivanov
--
got bsdtar in place of the usual one.
On Tue, 30 Jul 2019 at 14:09, Joerg Sonnenberger wrote:
>
> On Tue, Jul 30, 2019 at 10:51:11AM +0100, Chavdar Ivanov wrote:
> > GNU tar reports the extended header and does not restore it by default - the
> > file can be unlinked:
> >
On Tue, 30 Jul 2019 at 16:48, Martin Husemann wrote:
>
> On Tue, Jul 30, 2019 at 10:44:07PM +0700, Robert Elz wrote:
> > Check your mk.conf and whatever you use to generate builds.
> > If anything has MKBSDTAR=yes that would explain it. The default
> > (and so what the releng builds use), is
On Tue, 30 Jul 2019 at 18:00, Martin Husemann wrote:
>
> On Tue, Jul 30, 2019 at 04:50:19PM +0100, Chavdar Ivanov wrote:
> > The releng build from yesterday still has /bin/tar hard-linked to
> > /bin/cpio.
>
> Which build is that? Maybe you used the .../latest/ symlink and
I used to get this a lot weeks or months ago
On Fri, 2 Aug 2019 at 09:07, Martin Husemann wrote:
> On Thu, Aug 01, 2019 at 04:27:29PM -0700, Hisashi T Fujinaka wrote:
> > Oh, duh, I think I remember that the real issue is that you can't run as
> > many $JOBS. Before it would be better about
Lately, perhaps the last 4-5 Firefox and rust builds, I have never had a
single failure. Also I haven’t seen yet a llvm build failure on this
machine.
It’s a 20gb laptop, but I always use make_jobs 1. So perhaps it is indeed a
resource problem.
On Fri, 2 Aug 2019 at 09:31, Chavdar Ivanov wrote
Hi,
FYI VirtualBox guest cleanly compiles and apparently works under
9.0-BETA; in this case I used fresh svn update:
...
Starting local daemons:12:58:44.643043 main VBoxService 6.0.97
r80012 (verbosity: 0) netbsd.amd64 (Aug 1 2019 13:54:41) release log
12:58:44.643086 main Log opened
It builds with the following two patches (the first one almost
certainly wrong, although the result appears to be working):
.
--- ./src/VBox/Runtime/common/path/RTPathAbsEx.cpp.ORIG2019-07-20
11:55:09.661784205 +0100
+++ ./src/VBox/Runtime/common/path/RTPathAbsEx.cpp 2019-07-20
Hi,
NFS server - 8.99.51 amd64, /etc/exports contains:
/home/sysbuild/release -maproot=0:10 -network 192.168.0/24
NFS client - an hour ago it was 8.99.50 from about a week ago and worked
fine, I was able to NFS mount the release directory and perform the
usual sysupgrade dance.
Now the client
I noticed wip/mono6 has been removed, the other mono packages use
earlier versions. Any particular reasons for this worth knowing?
On Tue, 13 Aug 2019 at 09:50, wrote:
>
> wip/mono6 should be a replacement that works on netbsd.
> (still some issues to fix, like LD_LIBRARY_PATH=/usr/X11R7/lib for
-10-29 at 10:38 +0000, Chavdar Ivanov wrote:
> > > I've tested xfce4 - a few days old build from -current pkgsrc - now
> > > on
> > > real hardware with functional dri2. I get the same as with the
> > > VirtualBox client - I have to disable compositing to get xfwm4
Hi,
Perhaps it is some local issue or I have missed some update, but I
don't seem to be able to run zfs/zpool commands as non-root user at
all:
[~]; zpool status
internal error: failed to initialize ZFS library
[~]; zfs list
internal error: failed to initialize ZFS library
Everything works as
Hi,
I've setup autofs on one of my -current systems with nfs, nothing
modified. It kinda works, but a typical session would look like:
.
> ls /net/freenas
gls: reading directory '/net/freenas': No such file or directory
> ls /net/freenas
gls: reading directory '/net/freenas': No such file or
Hi,
The wiki still says we do not have support for RPI4 at this time.
Is this so indeed, or if the support is partial and in need of
testing, what is to be done?
--
does not do anything - 'gpt show wd0'
returns that the disk is mbr.
On Thu, 12 Dec 2019 at 22:03, Chavdar Ivanov wrote:
>
> Ok, thanks. I am building now.
>
> On Thu, 12 Dec 2019 at 22:02, Martin Husemann wrote:
> >
> > On Thu, Dec 12, 2019 at 09:24:09PM +00
at 01:13, Chavdar Ivanov wrote:
>
> Sorry, no go. I did two builds after that. None of the menu-driven
> disk operations work with GPT at the moment, under VirtualBox. The day
> before all worked as expected, with the exception of the incorrect
> .efi file only. Now if I
На 2019-12-12 в 19:42, co...@sdf.org написа:
> hi folks,
>
> I applied an upstream security fix to i915. It's pretty big.
>
> It touches the suspend codepath, and I can't test that on my machine.
>
> Additionally I am looking for confirmation that i915 is fine in the last
> week. My testing
Dec 2019 at 11:57, Bodie wrote:
>
>
>
> On 14.12.2019 12:43, Chavdar Ivanov wrote:
> > FWIW, the installation iso of my yesterday's build of 9.99.23 amd64
> > boots just fine under VirtualBox 6.1.
> >
>
> Do you have VBox.log to see what host is under and what
On Sat, 14 Dec 2019 at 12:52, Chavdar Ivanov wrote:
>
> I can attach the whole log file, should you need it; in the mean time
> the three variable mentioned above are the same:
> ...
> 00:00:03.502252 IBRS_IBPB - IA32_SPEC_CTRL.IBRS and
> IA32_PRED_CMD.IBPB = 0 (1)
> 00
FWIW, the installation iso of my yesterday's build of 9.99.23 amd64
boots just fine under VirtualBox 6.1.
On Sat, 14 Dec 2019 at 10:22, Bodie wrote:
>
>
>
> On 12.12.2019 17:38, Maxime Villard wrote:
> > Le 12/12/2019 à 16:34, Valery Ushakov a écrit :
> >> On Thu, Dec 12, 2019 at 06:47:50 +0100,
Hi,
Since 9.99.18 I am not able to build lsof; I get:
...
gcc -O2 -DNETBSDV=700 -DN_UNIXV=/dev/ksyms -DHASKVMGETPROC2
-DHASNFSPROTO -DHASIPv6 -DHASFDESCFS=1 -DHASFDLINK -DHASNULLFS
-DHASPROCFS -DHASPROCFS_PFSROOT -DHASBUFQ_H -DHAS9660FS=1
-DHASMSDOSFS=1 -DHASKERNFS -DHASKERNFS_KFS_KT
On Sun, 15 Dec 2019 at 19:10, Bodie wrote:
>
>
>
> On 12.12.2019 17:38, Maxime Villard wrote:
> > Le 12/12/2019 à 16:34, Valery Ushakov a écrit :
> >> On Thu, Dec 12, 2019 at 06:47:50 +0100, Bodie wrote:
> >>
> >>> On 11.12.2019 23:32, Valery Ushakov wrote:
> On Wed, Dec 11, 2019 at 23:15:38
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 +0000, Chavdar Ivanov wrote:
>
> > Last two days I haven't been able to build amd64 -curre
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
>
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 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 thoug
I can confirm - in the case of yesterday's -current - that there is
nothing wrong with the efi/gpt installation procedure and the problem
is with the two .efi files. On VirtualBox I attached the new 'bad'
disk to the working EFI NetBSD instance, renamed the 'boot' folder in
the FAT partition to
Just to confirm the same. I still have a NetBSD EFI VirttualBox guest
working just fine, built around 9.99.10 or thereabouts, perhaps
following the manual installation procedure mentioned above. Upon
seeng this thread, I tried to test the installation of a fresh 9.99.21
in efi with gpt; it
Today's -current has a proble installing in gpt mode - it claims not
to be able to determine the geometry of the disk and does not give an
option to format it in gpt mode at all.
Just FYI.
On Thu, 12 Dec 2019 at 16:27, Martin Husemann wrote:
>
> On Thu, Dec 12, 2019 at 03:10:41PM +0100,
Ok, thanks. I am building now.
On Thu, 12 Dec 2019 at 22:02, Martin Husemann wrote:
>
> On Thu, Dec 12, 2019 at 09:24:09PM +, Chavdar Ivanov wrote:
> > Today's -current has a proble installing in gpt mode - it claims not
> > to be able to determine the geometry of the disk
I haven't done raidframe installations for a long time, but followed
your sequence using two days old amd64-current -9.99.19- and it failed
the same way for me. It was under VirtualBox, though.
Chavdar
On Fri, 6 Dec 2019 at 01:39, Matthias Petermann wrote:
>
> Hello,
>
> there seems to be a
is that on first invocation xfce4 sets use_composing to
true, even if composing is not available or not functional.
On Sun, 27 Oct 2019 at 02:24, wrote:
>
> On Sun, Oct 27, 2019 at 01:30:48AM +0100, Chavdar Ivanov wrote:
> > In my case its also swrast_dri, VirtualBox host. I haven't recent
Native.
On Sun, 27 Oct 2019 at 16:25, Robert Swindells wrote:
>
>
> Chavdar Ivanov wrote:
> >I do not have MesaLib installed on this v/b guest at all.
>
> Are you running modular or native xorg ?
--
I also have xfwm4 crash, but only if there is .config/xfce4 directory.
So far if I remove it, xfce4 works fine. Otherwise the trace appeared
similar to the above.
On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge wrote:
>
> On Tue, 15 Oct 2019, at 12:00:42 +0100, Robert Swindells wrote:
> > I
Thanks! Sorted.
On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote:
>
> On 10/28, Chavdar Ivanov wrote:
> > After the above message I rebuilt the system and got eventually
> > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded
> > to rebuild wip/qemu-n
And then one has to change the permissions of the tap device and the
disk in use, e,g,
...
chown root:nvmm /dev/tap3
chmod 660 /dev/tap3
chown root:nvmm /dev/zvol/rdsk/pail/openbsd
chmod 660 /dev/zvol/rdsk/pail/openbsd
...
On Mon, 28 Oct 2019 at 22:54, Chavdar Ivanov wrote:
>
> Thanks!
201 - 300 of 687 matches
Mail list logo
