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 t
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 10
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 again
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 o
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 o
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 t
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 Ne
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 behav
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 then
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 cir
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 writing
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 look
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 pci_intr_
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 to
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 a
> 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 screen
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 th
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: t
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 pr
24 matches
Mail list logo
