On Thu, Aug 18, 2011 at 3:36 PM, Tim van der Molen wrote:
> When run without root privileges, getpwent(), getpwnam() and friends
> always set errno, even if they succeed. Because of this, it is
> impossible to distinguish between true errors (for which errno should be
> set) and conditions like "e
While working on djm's wishlist I ran across a hang.
To reproduce the hang go like: "^[16000l" which would insert 16000
letter l'. As far as I know going over the line limit makes no sense so
limit it's repetition and prevent the hang in the process.
ok?
Index: emacs.c
=
The diff below adds support for ALPS touchpads to the pms(4) driver.
I'm looking for testers with or without ALPS hardware, especially if you
have a touchpad, to be sure it doesn't break anything.
Currently, ALPS DualPoint are untested and support for special buttons
(back, forward, etc) is missi
Resending.
On Fri, 19 Aug 2011 00:36:51 +0200, Tim van der Molen wrote:
> When run without root privileges, getpwent(), getpwnam() and friends
> always set errno, even if they succeed. Because of this, it is
> impossible to distinguish between true errors (for which errno should be
> set) and cond
The vendor part should be sorted by number, I fixed that part
up and committed, thanks.
On Sat, Sep 03, 2011 at 03:41:57AM -0400, Loganaden Velvindron wrote:
> I added it to the usbdevs file, and
> modified the device probe code in if_udav.c
>
> Index: usbdevs
> ==
On Sun, Sep 04, 2011 at 02:56:48PM +0200, Martin Pelikan wrote:
> On Sun, Sep 04, 2011 at 09:50:26PM +1000, Jonathan Gray wrote:
> > The H61 LPC correction is fine but do you actually have
> > this 0x1c51 device? It doesn't appear in the Intel 6 series
> > datasheets, perhaps just stick with the c
I forgot about the dmesg:
udav0 at uhub3 port 2 "DM9601 USB NIC DM9601 USB NIC" rev 1.10/1.01 addr 2
amphy0 at udav0 phy 0: DM9601 10/100 PHY, rev. 0
usbdevs -v
port 2 addr 2: full speed, power 144 mA, config 1, DM9601 USB NIC(0x9601),
DM9601 USB NIC(0x01e1), rev 1.01, iSerialNumber 9601
On Sun, Sep 04, 2011 at 09:50:26PM +1000, Jonathan Gray wrote:
> The H61 LPC correction is fine but do you actually have
> this 0x1c51 device? It doesn't appear in the Intel 6 series
> datasheets, perhaps just stick with the correction.
No, I don't have that one. I didn't know Intel releases this
> Hi!
>
> I'm working with Gigabyte H61M-S2V-B3 right now. Graphics built in CPU
> supports at most 800x600 in X.org, but the rest of the machine seems
> fine. Dmesg at dmesg@ and at NYCBUG database.
>
>
> Index: dev/pci/pcidevs
> =
On Sun, Sep 04, 2011 at 01:41:26AM +0200, Martin Pelikan wrote:
> Hi!
>
> I'm working with Gigabyte H61M-S2V-B3 right now. Graphics built in CPU
> supports at most 800x600 in X.org, but the rest of the machine seems
> fine. Dmesg at dmesg@ and at NYCBUG database.
>
> However, these are missing (f
On Sat, Sep 03, 2011 at 02:25:37AM +0200, Alexander Bluhm wrote:
> During socket splicing the relayd session timeouts could not be
> measured exactly in user land. Use the new idle timeout for socket
> splicing in the kernel to make it correct.
I think, I got the flag handling wrong. Make sure t
On Fri, Sep 02, 2011 at 01:01:37PM -0700, Matthew Dempsky wrote:
> Our sys/socket.h and netinet/in.h headers do require sys/types.h, so
> it seems consistent to at least document that. ok matthew@
>
> (POSIX requires headers to be self-sufficient, but we're a ways off from
> that.)
>
there was
On Sun, Sep 04, 2011 at 01:59:11AM +0200, Martin Pelikan wrote:
> Index: disklabel.8
> ===
> RCS file: /cvs/src/sbin/disklabel/disklabel.8,v
> retrieving revision 1.103
> diff -u -p -r1.103 disklabel.8
> --- disklabel.8 5 Jun 201
13 matches
Mail list logo
