Hello,
On Wed, 3 Jun 2020 23:30:56 +0200
Alexandr Nedvedicky wrote:
> I'm OK with your change.
Thank you for your review and comment.
> However I would like to ask you to do yet another test. I wonder if things
> will eventually work on unfixed PF if rules will be constructed as follows:
>
>
tech@,
The following patch is a possible step towards improved thread safety
to vmd(8). (I'll be the first to say it's not perfect.)
The first major change: mutexes around most event addition/deletion
while using a defined event_base.
In vm.c and in the emulated devices, which is predominantly
Hello Yasuoka,
I'm OK with your change.
However I would like to ask you to do yet another test. I wonder if things
will eventually work on unfixed PF if rules will be constructed as follows:
pfctl -a test -t LB -T add 10.0.0.11@pair102
echo 'pass in on rdomain 102 quick proto tcp to
Remi Locherer(remi.loche...@relo.ch) on 2020.06.03 15:36:17 +0200:
> On Sat, May 30, 2020 at 04:37:43PM +0200, Denis Fondras wrote:
> > This diff updates how ospf6d(8) handles interfaces.
> > It is now in line with what ospfd(8) does.
> >
> > Last step before enabling reload.
> >
> > Tested
On Wed, Jun 03, 2020 at 05:33:24PM +0100, Nicholas Marriott wrote:
> Actually I've got them the wrong way round here, but others have already
> explained them anyway :-).
Yup, which is why I will simply drop the diff: way too much hassle for
single column of output, let alone potential breakages
Dear readers,
since 5.8 i ve been carrying around patches to manage :
* crazy server sending hostname like "crazy ISP name with space" ( in
one case the ignore or supersede failed to workaround the problem ),
it is a bit hard to test, and it looks like some improvement was made
to crash fatal
ping?
Actually I've got them the wrong way round here, but others have already
explained them anyway :-).
On Wed, Jun 03, 2020 at 05:04:43PM +0100, Nicholas Marriott wrote:
> xenl (xm) only matters for the last line - you can't write into the very
> bottom right position without causing the terminal
xenl (xm) only matters for the last line - you can't write into the very
bottom right position without causing the terminal to scroll. No xenl is
a pain and most applications solve it by just leaving that position
always empty. The only terminal still about without xenl that I am aware
of is the
Stuart Henderson wrote:
> On 2020/06/03 14:49, Klemens Nanni wrote:
> > On Wed, Jun 03, 2020 at 12:45:35PM +0100, Stuart Henderson wrote:
> > > It should check terminal capabilities for this, see termcap(5).
> > > If 'am' (auto-margin) is set then it shouldn't write to the final column.
> > > If
On 2020-05-31 20:46, Mark Kettenis wrote:
Forget about all that for a moment. Here is an alternative suggestion:
On sparc64 we need to support both tick_timecounter and
sys_tick_timecounter. So we need some sort of clockid value to
distnguish between those two. I already suggested to use the
On Sat, May 30, 2020 at 04:37:43PM +0200, Denis Fondras wrote:
> This diff updates how ospf6d(8) handles interfaces.
> It is now in line with what ospfd(8) does.
>
> Last step before enabling reload.
>
> Tested against Mikrotik and Zebra implementations.
>
> Warning: it changes the default
Klemens Nanni wrote in
<20200603124948.irvdnxrxa5g75pmi@eru>:
|On Wed, Jun 03, 2020 at 12:45:35PM +0100, Stuart Henderson wrote:
|> It should check terminal capabilities for this, see termcap(5).
|> If 'am' (auto-margin) is set then it shouldn't write to the final column.
|> If 'xn' is set
On 2020/06/03 14:49, Klemens Nanni wrote:
> On Wed, Jun 03, 2020 at 12:45:35PM +0100, Stuart Henderson wrote:
> > It should check terminal capabilities for this, see termcap(5).
> > If 'am' (auto-margin) is set then it shouldn't write to the final column.
> > If 'xn' is set then it's OK in some
On Wed, Jun 03, 2020 at 12:45:35PM +0100, Stuart Henderson wrote:
> It should check terminal capabilities for this, see termcap(5).
> If 'am' (auto-margin) is set then it shouldn't write to the final column.
> If 'xn' is set then it's OK in some circumstances (it's probably easier to
> skip
On Sun, May 31, 2020, at 17:27, Tobias Heider wrote:
> I don't think this is a good idea
> With your diff the log gets spammed with 'Undefined error: 0' for child SAs
> that have never been used.
> Also log_warn seems a bit too much as those errors are rarely serious.
Thank you for having a
Hello,
I'm working on porting xmm7360 device driver from Linux to OpenBSD,
the Linux code:
https://github.com/xmm7360/xmm7360-pci/
Most of device driver communication with the device is already
working, but currently I can't get the interrupt routine to actually
trigger after successful
On 2020/06/03 12:46, Klemens Nanni wrote:
>
> i_process() prints process lines from the global buffer thisline[MAX_COLS]
> which is filed by format_next_process() using snprintf(3), i.e. it is
> guaranteed to be NUL terminated.
>
> display_width is always set to screen_width and capped
On Wed, Jun 03, 2020 at 01:11:15PM +0200, Mark Kettenis wrote:
> Does that write into the last column of a 80-character wide screen?
> That causes a linewrap on some terminals isn't it? And that would be
> undesirable.
Yes, it does; xterm and st from the x11/st package have no problem
however to
On 2020/06/02 21:38, Bob Beck wrote:
> On Mon, Jun 01, 2020 at 06:04:17PM +0100, Stuart Henderson wrote:
> > OK to drop the expired AddTrust cert from cert.pem?
>
> yes, thanks.
>
> >
> > I checked against the firefox set, there are no new/removed certs that
> > work with libressl there. There
> Date: Wed, 3 Jun 2020 12:46:48 +0200
> From: Klemens Nanni
>
> i_process() prints process lines from the global buffer thisline[MAX_COLS]
> which is filed by format_next_process() using snprintf(3), i.e. it is
> guaranteed to be NUL terminated.
>
> display_width is always set to
i_process() prints process lines from the global buffer thisline[MAX_COLS]
which is filed by format_next_process() using snprintf(3), i.e. it is
guaranteed to be NUL terminated.
display_width is always set to screen_width and capped to MAX_COLS-1
in display_resize(), so NUL terminating
On 01/06/20(Mon) 15:41, Visa Hankala wrote:
> On Sun, May 31, 2020 at 10:48:52AM +0200, Martin Pieuchot wrote:
> > NFS poll(2)/select(2) and kqueue(2) behaviors are incoherent. Diff
> > below uses the kernel-only NOTE_IMM hint to make the kqueue handlers
> > behave like the current poll handler:
Hi,
pf.conf:
anchor {
pass in on rdomain 102 quick proto tcp to 10.0.0.101 port 8080 \
keep state ( sloppy ) route-to \
least-states sticky-address
}
table {
10.0.0.11@pair102
}
this doesn't work. All packets going to 10.0.0.101 are dropped with
'no-route'. The
24 matches
Mail list logo
