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
>
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
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
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
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
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
> 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
11 matches
Mail list logo