Well, it conflicts with the codes listed in the `USB HID to PS/2 Scan
Code Translation Table'
Yes, but that document just lists the codes that Windows translates to
internally when a USB keyboard is in use. I have no reason to believe
that any PS/2 device actually uses them in hardware,
Excellent. Try setting the default, though:
# wsconsctl keyboard.repeat.deln.default=350
keyboard.repeat.deln.default - 200
In fact, if you check, whenever a user changes the normal value, the
default value changes too. So a normal, non-root user can change the
values for all of the
kern malloc rolls its own linked list code. for the sake of clarity
and to make future changes easier, i'd like to make it a simpleq.
it would be very nice if this could be tested on a few different kinds
of machines. it's not supposed to actually change anything, but that's
what testing is to
I'm a GNU Guile 2.0 user, whose latest versions require latest
versions of the Boehm garbage collector. This uses the functions
pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which
don't exist in rthreads.
I've read that rthreads are just processes, albeit with a special flag
On 2013/03/21 11:03, Taylan Ulrich B. wrote:
I'm a GNU Guile 2.0 user, whose latest versions require latest
versions of the Boehm garbage collector. This uses the functions
pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which
don't exist in rthreads.
the current boehm-gc
Stuart Henderson s...@spacehopper.org writes:
the current boehm-gc port works with rthreads, best way forward is
probably to update that to a newer version, maintaining the patches that
we have.
perhaps the uthread workarounds that we used to have in the port got
committed upstream and now
i386 package build is still running, but there are a few common
failure modes I've picked up (and at least ffmpeg and gstreamer
will have knocked out big chunks of the tree) so I think I'll
send this out now.
Mostly binutils-related but there may be other failures mixed in
(this is the first full
Stuart Henderson s...@spacehopper.org writes:
As I said, perhaps the uthread workarounds that we used to have
in the port got committed upstream and now need to be reverted?
i.e. _used_ to have, before the change to rthreads.
Oh sorry, I understand now. Indeed, the patches in e.g. 5.0
On 2013/03/21 12:32, Taylan Ulrich B. wrote:
Stuart Henderson s...@spacehopper.org writes:
As I said, perhaps the uthread workarounds that we used to have
in the port got committed upstream and now need to be reverted?
i.e. _used_ to have, before the change to rthreads.
Oh
On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote:
On 2013/03/21 12:32, Taylan Ulrich B. wrote:
Stuart Henderson s...@spacehopper.org writes:
As I said, perhaps the uthread workarounds that we used to have
in the port got committed upstream and now need to be reverted?
Lawrence Teo l...@openbsd.org wrote:
The checksum flags listed in the mbuf(9) man page do not match the ones
in mbuf.h. In addition, the m_pkthdr.csum variable name should be
m_pkthdr.csum_flags.
The following diff fixes both issues.
OK?
Okay, but while you're there, could you remove
It seems there's an ITE 8728 chip on my motherboard, and, it's
showing some sensible information! :-)
ok?
it0 at isa0 port 0x2e/2: IT8728F rev 1, EC port 0x228
hw.sensors.it0.temp0=37.00 degC
hw.sensors.it0.temp1=34.00 degC
hw.sensors.it0.temp2=27.00 degC
hw.sensors.it0.fan0=2020 RPM
On Thu, Mar 21, 2013 at 06:05:11AM +, Miod Vallat wrote:
Excellent. Try setting the default, though:
# wsconsctl keyboard.repeat.deln.default=350
keyboard.repeat.deln.default - 200
In fact, if you check, whenever a user changes the normal value, the
default value changes too.
All AMD64 systems should be Y2K compliant, so we can kill this code from
clock.c on this arch.
The i386 version currently only functions if the first boot after
Jan 1, 2000 is actually in the year 2000. Obviously now that we are in
2013, it's much more useful to allow the user to map
1900-1969 -
patch to just call open() with O_CLOEXEC
Index: lib/libutil/check_expire.c
===
RCS file: /cvs/src/lib/libutil/check_expire.c,v
retrieving revision 1.8
diff -u -p -r1.8 check_expire.c
--- lib/libutil/check_expire.c 20 Apr 2004
patch to change 1 to FD_CLOEXEC. previous diff was OK'd by millert, but
here is an updated version.
Index: bin/systrace/openbsd-syscalls.c
===
RCS file: /cvs/src/bin/systrace/openbsd-syscalls.c,v
retrieving revision 1.41
diff -u -p
On Thu, Mar 21, 2013 at 11:03, Taylan Ulrich B. wrote:
I'm a GNU Guile 2.0 user, whose latest versions require latest
versions of the Boehm garbage collector. This uses the functions
pthread_suspend_np and pthread_resume_np, when built on OpenBSD, which
don't exist in rthreads.
Right. Early
So it seems the bulk of additional amd64 failures are looking like this:
/usr/bin/ld: MethodJIT.o: relocation R_X86_64_PC32 against
`JaegerTrampolineReturn' can not be used when making a shared object;
recompile with -fPIC
On 2013/03/21 10:52, Stuart Henderson wrote:
i386 package build is
- local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
Hmm, that's odd. `environ' is a common and not declared as static or
with any visibility attribute. Can you share the exact linking command
which has triggered this error?
- Error: suffix or operands invalid for `mov'
these
Date: Thu, 21 Mar 2013 21:54:02 +
From: Miod Vallat m...@online.fr
- local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
Hmm, that's odd. `environ' is a common and not declared as static or
with any visibility attribute. Can you share the exact linking command
which has
On 2013/03/21 21:54, Miod Vallat wrote:
- local symbol `environ' in /usr/lib/crt0.o is referenced by DSO
Hmm, that's odd. `environ' is a common and not declared as static or
with any visibility attribute. Can you share the exact linking command
which has triggered this error?
Build log
On 2013/03/21 21:54, Miod Vallat wrote:
- www/chromium - OSError: [Errno 8] Exec format error
Please make the binary available to me offlist, as well as its linking
command (or build log, whatever suits you).
Well this is very strange because if I run the program which generates
the error
Some ports in snapshot that include .po or .mo catalogs
different to es_ES are (just listing few without repetition):
davical es_AR es_MX es_VE
gnomebaker es_CO, es_CR
poedit es_PR
zarafa es_CA
The following packages have other localization files practically for
every spanish speaking
On Thu, Mar 21, 2013 at 04:13:35PM +, Christian Weisgerber wrote:
Lawrence Teo l...@openbsd.org wrote:
The checksum flags listed in the mbuf(9) man page do not match the ones
in mbuf.h. In addition, the m_pkthdr.csum variable name should be
m_pkthdr.csum_flags.
The following
use %u for unsigned (ino_t).
Index: fsdb.c
===
RCS file: /cvs/src/sbin/fsdb/fsdb.c,v
retrieving revision 1.23
diff -u -p -r1.23 fsdb.c
--- fsdb.c 27 Oct 2009 23:59:33 - 1.23
+++ fsdb.c 22 Mar 2013 01:49:27 -
@@
On Thu, Mar 21, 2013 at 06:59:44PM -0500, Vladimir Támara Patiño wrote:
Regarding the situtation with other languages, in
/usr/src/share/locale/ctype/Makefile I find the following languages
with countries pointing all of them to the same cmap definitions:
* de_AT, de_CH and de_DE
Taking this
On Thursday 21 March 2013 7:47:34 am Brad Smith wrote:
On Thu, Mar 21, 2013 at 11:43:15AM +, Stuart Henderson wrote:
On 2013/03/21 12:32, Taylan Ulrich B. wrote:
Stuart Henderson s...@spacehopper.org writes:
As I said, perhaps the uthread workarounds that we used to have
in
27 matches
Mail list logo
