Tobias Stoeckmann(tob...@stoeckmann.org) on 2021.09.21 22:23:55 +0200:
> Hi,
>
> upstream (greenwood) less has disabled history file support for secure
> mode, i.e. LESSSECURE=1: https://github.com/gwsw/less/pull/201
>
> The problem was about permanent marks for which we do not have support
> any
Hello,
As discussed, this looks correct to me
> On 22 Sep 2021, at 15:46, Eric Faurot wrote:
>
> Hi.
>
> A user reported that decoded SRS addresses are not correctly evaluated
> against the ruleset. That's because the ruleset always matches against
> the expanded address ("dest") and not the
If the situation isn't going to change anytime soon then I have some
diffs for INSTALL.i386 and INSTALL.amd64. The latter has not specified
disk requirements, I guess since anyone who owns an amd64 system will
very likely be using a disk big enough for X, so I figured that the
same would apply
On Wed, 22 Sep 2021 15:46:13 +0200, Eric Faurot wrote:
> A user reported that decoded SRS addresses are not correctly evaluated
> against the ruleset. That's because the ruleset always matches against
> the expanded address ("dest") and not the original address ("rcpt").
> This diff should fix it.
Hi.
A user reported that decoded SRS addresses are not correctly evaluated
against the ruleset. That's because the ruleset always matches against
the expanded address ("dest") and not the original address ("rcpt").
This diff should fix it.
Eric.
Index: lka_session.c
In bgpd we do not follow the RFC8050 encoding for RIB_GENERIC_ADDPATH.
Mainly because it does not fit the way the code works and also because the
only other BGP implementation that seems to care about RIB_GENERIC_ADDPATH
does it the same way.
Because of this it makes no sense to parse RIB_GENERIC_
On Wed, Sep 22, 2021 at 10:38:14AM +0100, Stuart Henderson wrote:
> On 2021/09/22 11:28, Landry Breuil wrote:
> > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a ?crit :
> > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200:
> > > > On Mon, Sep 20, 2021 at 03:54:5
On Wed, Sep 22, 2021 at 11:28:21AM +0200, Landry Breuil wrote:
> Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a ?crit :
> > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200:
> > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote:
> > > > did i screwup
On 2021/09/22 11:28, Landry Breuil wrote:
> Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit :
> > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200:
> > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote:
> > > > did i screwup something somewhere
Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit :
> Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200:
> > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote:
> > > did i screwup something somewhere in my config and there's a better way
> > > for th
> I suggest that entering a NUL character will abort the search-history
> mode, much like ^[ does. This leaves the handling of said character to
> the "ordinary" command editing.
Makes sense. In vi mode, this problem doesn't occur, as the ^@ is
displayed in the search string.
ok tb for after re
11 matches
Mail list logo