Hi, my PC with ATI Radeon HD 6450 rev 0x00 graphic card works just fine.
Thanks for your work, developpers!
Kenji
On 2018-12-02 22:12, Adam Thompson wrote:
> I'm unsure if my test is valid, but I switched to i8254 (confirmed successful
> via sysctl), and tset(1) continues to pause for an unnaturally long time.
> But then I rebooted and re-tested the same sysctl vaules, and this time
> tset(1) took 1sec, a
On 2018-12-02 20:50, Philip Guenther wrote:
> On Sun, Dec 2, 2018 at 2:15 PM Adam Thompson wrote:
>
>> I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
>> one thing there that's different from everywhere else I've used 6.4.
>>
>> tset(1) takes approximately 12-15 secon
On Sun, Dec 2, 2018 at 7:51 PM Edgar Pettijohn
wrote:
> Sorry just saw it came with some examples. Testing with the `lookupdns'
> program
> ended with a Bus error (core dumped). Here is gdb output:
>
> Core was generated by `lookupdns'.
> Program terminated with signal SIGBUS, Bus error.
> #0 _l
Sorry just saw it came with some examples. Testing with the `lookupdns' program
ended with a Bus error (core dumped). Here is gdb output:
Core was generated by `lookupdns'.
Program terminated with signal SIGBUS, Bus error.
#0 _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99
99 1:
I downloaded state threads from sourceforge and had to make the following
change to get it to build. I didn't test further than just compiling though.
Not sure what you would need to change to get your `autotools' makefiles to
work.
--- ./st-1.9/Makefile Thu Oct 1 17:55:03 2009
+++ Makefile
On Sun, Dec 2, 2018 at 2:15 PM Adam Thompson wrote:
> I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
> one thing there that's different from everywhere else I've used 6.4.
>
> tset(1) takes approximately 12-15 seconds to execute, (almost) every
> time.
>
> On a DigitalOc
On Sat, Dec 1, 2018 at 6:34 AM Claus Assmann
wrote:
> statethreads (http://state-threads.sourceforge.net/) crashes on
> OpenBSD 6.4/amd64 (release) with an error in ld (see below); it
> works fine on previous OpenBSD versions. Do I have to set some
> "special" cc/ld options to make this work?
I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
one thing there that's different from everywhere else I've used 6.4.
tset(1) takes approximately 12-15 seconds to execute, (almost) every
time.
On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
takes a
вс, 2 дек. 2018 г. в 22:59, stephane l1 :
>
> does the conflicts come because I have already installed the package Qt5.9.6
> (so release version) ?
Regarding conflicts - yes, you'll need to use "pkg_add -r" (replace
mode) to install alternative (FLAVORed) version of package. This is
documented in
does the conflicts come because I have already installed the package
Qt5.9.6 (so release version) ?
Hi thanks Vadim I have made it this afternoon,qtbase seems to be built,with
FLAVOR=debug
(I See a qtbasexx.tgz in /usr/ports/packages/amd64/all) but it fails on
installation
of the module (I have tryed too a pkg_add of .tgz but it says it is not
signed)
Le dim. 2 déc. 2018 à 20:51, Vadim Zhukov a
вс, 2 дек. 2018 г. в 16:31, stephane l1 :
>
> Hi,
> Shall I make FLAVOR=debug make in each Makefile of the modules of Qt in the
> port ?
Basically, yes. You can play with shell, of course, to run those in a
single command, though.
Please note that debug FLAVOR isn't linked to bulk builds, so i
Hi,
I need help to write a correct rule in pf.conf.
I want :
A -> B --> web
The appearing IP of A is the B's one on the web.
I managed to configure iked on A and B using default pubkeys according
to Stuart Henderson advices.
iked.conf on A :
ikev2 active ipcomp esp \
Hello,
alexan...@beard.se (Alexander Hall), 2018.11.28 (Wed) 23:24 (CET):
> On Wed, Nov 28, 2018 at 10:56:13AM +0100, Marcus MERIGHI wrote:
> > j...@openbsd.org (joshua stein), 2018.11.27 (Tue) 18:12 (CET):
> > > On Tue, 27 Nov 2018 at 14:32:50 +0100, Marcus Merighi wrote:
> > > > does 'xset(1) d
Hi,
Shall I make FLAVOR=debug make in each Makefile of the modules of Qt in
the port ?
Le dim. 2 déc. 2018 à 14:20, stephane l1 a écrit :
> ok thanks I will try to compile from the ports too..
> Yes it was just a Qt problem in qversiontagging.h.
> ok it would be more simple to use the ports th
Am 02.12.18 um 13:26 schrieb Stefan Wollny:
> Am 30.11.18 um 16:38 schrieb Joel Sing:
>> On Thursday 29 November 2018 20:38:23 Stefan Wollny wrote:
[ ..]
> SUCCESS!
>
> With this boot params the system came up as expected.
>
> THANK YOU once again for caring and your precious time! Much apprecia
ok thanks I will try to compile from the ports too..
Yes it was just a Qt problem in qversiontagging.h.
ok it would be more simple to use the ports thanks
Le dim. 2 déc. 2018 à 14:02, Vadim Zhukov a écrit :
> Well, I was talking about compiling from ports.
>
> If you try to compile Qt from sourc
Well, I was talking about compiling from ports.
If you try to compile Qt from sources on your own you're, well, on
your own. find /usr/ports/x11/qt5 -name '*.patch' should give you a
clue how much on your own you are. :)
вс, 2 дек. 2018 г. в 15:03, stephane l1 :
>
> Hi,
>
> I have tryed with FLAVO
Am 30.11.18 um 16:38 schrieb Joel Sing:
> On Thursday 29 November 2018 20:38:23 Stefan Wollny wrote:
>> Hi there!
>>
>> I need help / advice with a fresh install onto a Thinkpad T450s which I
>> recently bought on eBay.
>>
>> The system starts with UEFI enabled and was running fine with a rather
>>
Hi,
I have tryed with FLAVOR = debug make in the .pro and I have still this
error :
/usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name
qt_version_tag@Qt_5.8
/usr/bin/ld: failed to set dynamic section sizes: Bad value
clang++: error: linker command failed with exit code 1 (use -v to
You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build
components you're interested in.
вс, 2 дек. 2018 г. в 03:06, stephane l1 :
>
> Hi,
> I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 with the
> mkspecs of the package release Qt5.9.6 and the platform openbsd-cl
On Sat, Dec 01, 2018 at 01:19:00PM -0600, Adam Thompson wrote:
> PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec
> delay between keypress and sound.
>
[...]
> Is sndio(4) suitable for real-time(-ish) performance? Or do I need
> a (OS) platform that does ASIO or JAC
23 matches
Mail list logo
