On June 18, 2018 11:00:00 PM GMT+02:00, Richard Procter
wrote:
>
>On 6/06/2018, at 10:20 AM, Alexander Hall wrote:
>
>> This adds a "clear-screen" editing command to the emacs editing mode.
>> This is the same name as bash and zsh uses, and then I stopped
>looking.
>>
>> Thoughts? OK?
>
On 6/06/2018, at 10:20 AM, Alexander Hall wrote:
> This adds a "clear-screen" editing command to the emacs editing mode.
> This is the same name as bash and zsh uses, and then I stopped looking.
>
> Thoughts? OK?
It's unclear to me what need is being being addressed here --- are you
wanting a
On Mon, Jun 18, 2018 at 19:29 +0200, Paul de Weerd wrote:
> Updated diff included below. I've set the product name to LD220.
> This diff lacks the updates to usbdevs{,_data}.h, whoever commits
> should update those too.
>
> Any takers to commit this? Tested by an owner of the actual device,
>
I take back my previous answer to this question:
> Are you sure the name always contain an underscore? Can't it be
> "Button:Button42" ?
In my previous response I had only discovered three cases of usage -1.
I took another look and discovered that there indeed is a scenario as you
mention other
On Mon, 18 Jun 2018 20:14:37 +0200, Jeremie Courreges-Anglas wrote:
> here are two tweaks for whois.c:
> - in whois() call freeaddrinfo(3) asap, there is no reason to keep the
> results around for longer than necessary. whois() is recursive so
> this should reduce the amount of memory used
Hi,
here are two tweaks for whois.c:
- in whois() call freeaddrinfo(3) asap, there is no reason to keep the
results around for longer than necessary. whois() is recursive so
this should reduce the amount of memory used when following redirects.
- choose_server() doesn't attempt to free the
maybe you can share a dmesg of the machine with the device attached as
uplcom(4)?
uplcom0 at uhub3 port 2 configuration 1 interface 0 "Prolific Technology Inc.
USB-Serial Controller" rev 1.10/3.10 addr 4
ucom3 at uplcom0
-JP
Updated diff included below. I've set the product name to LD220.
This diff lacks the updates to usbdevs{,_data}.h, whoever commits
should update those too.
Any takers to commit this? Tested by an owner of the actual device,
so that's good. Jan-Piet, maybe you can share a dmesg of the machine
On Mon, Jun 18, 2018 at 04:37:32PM +0200, Jan Schreiber wrote:
> Hi,
>
> this patch closes potential memory leaks in the mandoc memory wrapper
> functions and follows the examples in the manpages.
>
These are not leaks since mandoc exits via err(3) immediately after an
allocation failure. Which
On Mon, 18 Jun 2018 18:40:05 +0200, Martijn van Duren wrote:
> parse_char_class does a really fancy *s != '\n' dance.
> I say we remove it and let regcomp determine if we have a properly
> formatted char_class.
>
> This changes our error message for a unbalanced char_class from:
> unbalanced
Hello tech@,
parse_char_class does a really fancy *s != '\n' dance.
I say we remove it and let regcomp determine if we have a properly
formatted char_class.
This changes our error message for a unbalanced char_class from:
unbalanced brackets ([])
to:
brackets ([ ]) not balanced
OK?
martijn@
> Date: Mon, 18 Jun 2018 11:24:00 +0200
> From: Martin Pieuchot
>
> Diff below is the last of the serie to remove the KERNEL_LOCK() from
> sendto(2) and sendmsg(2) for sockets protected by the NET_LOCK().
>
> As explained previously [0] this diff uses a simple non-intrusive
> approached based
> Date: Mon, 18 Jun 2018 09:07:58 +0200
> From: Martin Pieuchot
>
> On 16/06/18(Sat) 19:28, Mark Kettenis wrote:
> > > Date: Thu, 14 Jun 2018 14:28:07 +0200
> > > From: Martin Pieuchot
> > >
> > > This version should fixes the previous issue where LARVAL files were
> > > incorrectly accounted
I've made up a
product name (the "product HP USB2SER 0x3524 Prolific uplcom" part of
the diff). That should be improved first. Do you have a model name
for this HP product? Any additional stickers that help identify it?
A URL from the HP website for this product?
The product is an "LD220-HP"
Hi Jan-Piet!
On Mon, Jun 18, 2018 at 04:16:34PM +0200, Jan-Piet Mens wrote:
| > Only one way to find out :)
|
| I spare you a lot of details by pointing you at a photo I just took of the
| working display: if you'd please scroll to the bottom of [1] .. ?
|
| A final (hah!) question: will your
Only one way to find out :)
I spare you a lot of details by pointing you at a photo I just took of
the working display: if you'd please scroll to the bottom of [1] .. ?
A final (hah!) question: will your patch be incorporated into OpenBSD?
Best regards,
-JP
[1]
On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
>
> > If folks indeed think that this is a must-have feature, this is
> > certainly a better approach. I wonder though if the setupterm() call
> > should happen earlier when
Hi,
this patch closes potential memory leaks in the mandoc memory wrapper
functions and follows the examples in the manpages.
diff --git mandoc_aux.c mandoc_aux.c
index 7c23ecfdd01..dbfb83faffc 100644
--- mandoc_aux.c
+++ mandoc_aux.c
@@ -66,27 +66,43 @@ mandoc_malloc(size_t size)
void *
Instead of grabbing the KERNEL_LOCK() in pfkey_sendup(), assert the
corresponding socket lock is held.
It's currently the same since the kernel lock is still the socket lock
for pfkey sockets. However this prepare the terrain for using a
different lock. This reuse the same pattern already used
Hi,
I have committed a patch to -current which refactors the six ways that PF
finds TCP options into one new function.
I expect no side-effects, and the minor changes to finding MSS and WSCALE
options that this involved were immaterial to the large sample of live
traffic that I've examined.
Diff below is the last of the serie to remove the KERNEL_LOCK() from
sendto(2) and sendmsg(2) for sockets protected by the NET_LOCK().
As explained previously [0] this diff uses a simple non-intrusive
approached based on a single mutex. I'd like to get this in before
doing any refactoring of
On Sun, Jun 17, 2018 at 09:23:50PM +0100, Jason McIntyre wrote:
> hi.
>
> diff below removes the section header SECTIONS for conf files,
> preventing a one line DESCRIPTION. it also stops numbering the amount of
> sections because a) it is unimportant and b) every time we add or remove
> a
On 16/06/18(Sat) 19:28, Mark Kettenis wrote:
> > Date: Thu, 14 Jun 2018 14:28:07 +0200
> > From: Martin Pieuchot
> >
> > This version should fixes the previous issue where LARVAL files were
> > incorrectly accounted in find_last_set() resulting in a panic() in
> > fd_unused().
> >
> > If you
Hi,
in some circumstances ospfd behaves not the way a user would expect and
it's not easy understand how to recover. With below diff ospfd recovers
automatically from the following three cases.
1) netstart
When someone runs the netstart script on a running system it most likely
assigns the
24 matches
Mail list logo
