On Mon, Mar 30, 2020 at 03:03:32AM +0100, Roy Marples wrote:
>
> For this specifically, we need a test that a terminal we know has colour
> still has colour according to libcurses.
>
> There are a few other numerics which have now exceeded the POSIX terminfo
> limits, but AFAIK they don't apply t
> On Mar 30, 2020, at 12:03 AM, Roy Marples wrote:
>
> On 30/03/2020 04:05, Christos Zoulas wrote:
>>> On Mar 29, 2020, at 10:37 PM, Roy Marples wrote:
>>>
>>> blacklistd was not working for me and the ACL check you mention was
>>> certainly not described anywhere I saw. After reading the Fi
Date:Mon, 30 Mar 2020 03:26:23 +0100
From:Roy Marples
Message-ID:
| Without ncurses installed I have no idea how to test that.
| Ideas of course welcome.
You can write ATF tests that use programs not normally installed,
they just need an atf_require_prog (or wha
On 30/03/2020 04:05, Christos Zoulas wrote:
On Mar 29, 2020, at 10:37 PM, Roy Marples wrote:
blacklistd was not working for me and the ACL check you mention was certainly
not described anywhere I saw. After reading the Fine Man Page, I came to the
conclusion that passing a sockaddr with a
> On Mar 29, 2020, at 10:37 PM, Roy Marples wrote:
>
> blacklistd was not working for me and the ACL check you mention was certainly
> not described anywhere I saw. After reading the Fine Man Page, I came to the
> conclusion that passing a sockaddr with a fd of -1 was expected to work with
>
blacklistd was not working for me and the ACL check you mention was certainly
not described anywhere I saw. After reading the Fine Man Page, I came to the
conclusion that passing a sockaddr with a fd of -1 was expected to work with the
code as is. Hence my change.
As libterminfo is deeply embe
On 30/03/2020 03:07, Christos Zoulas wrote:
On Mar 29, 2020, at 9:42 PM, Roy Marples wrote:
On 30/03/2020 02:19, Christos Zoulas wrote:
The terminfo database before I cleaned it up was a mess. There was
no build process, or explanation how to import it, or what the local
changes where.
Whe
I don't touch dhcpd unless it stops working or crashes for me.
I don't make random changes to it or feature enhancements.
I consider it a critical enough daemon to need fixing ASAP.
If I was going to make improvements, I would propose them.
christos
> On Mar 29, 2020, at 9:25 PM, Roy Marples wro
> On Mar 29, 2020, at 9:42 PM, Roy Marples wrote:
>
> On 30/03/2020 02:19, Christos Zoulas wrote:
>> The terminfo database before I cleaned it up was a mess. There was
>> no build process, or explanation how to import it, or what the local
>> changes where.
>
> When I imported it there were no
On 30/03/2020 02:15, Brett Lymn wrote:
On Mon, Mar 30, 2020 at 01:59:35AM +0100, Roy Marples wrote:
Your import of newer terminfo descriptions broke numerics larger than int16_t.
I take equal blame for this because there should have been a check for this
in the initial code.
But still you could
On 30/03/2020 02:19, Christos Zoulas wrote:
The terminfo database before I cleaned it up was a mess. There was
no build process, or explanation how to import it, or what the local
changes where.
When I imported it there were no local changes, as such nothing to document
other than whence it ca
I did not plan to work on this in the first place, and I presented a better
solution to provide compatibility. Nobody jumped on it, and I felt that I
had to jump in and implement it before terminfo2 was cast in stone.
The terminfo database before I cleaned it up was a mess. There was
no build proc
On 30/03/2020 02:19, Christos Zoulas wrote:
Recently you changed blacklistd without prior discussion and
you introduced a security bug. The terminfo2 changes were not discussed
either - I would have objected to creating yet another file to hold the
compiled definitions.
You don't discuss any dh
On Mon, Mar 30, 2020 at 01:59:35AM +0100, Roy Marples wrote:
>
> Your import of newer terminfo descriptions broke numerics larger than int16_t.
> I take equal blame for this because there should have been a check for this
> in the initial code.
> But still you could have checked.
>
You know, fro
On 27/03/2020 14:32, Christos Zoulas wrote:
In article <431d1631-ef82-d1ec-98ff-e39b71418...@marples.name>,
Roy Marples wrote:
On 27/03/2020 13:15, Christos Zoulas wrote:
On Mar 27, 2020, at 4:05 AM, Roy Marples wrote:
On 27/03/2020 02:06, Christos Zoulas wrote:
@@ -494,6 +530,7 @@
In article <431d1631-ef82-d1ec-98ff-e39b71418...@marples.name>,
Roy Marples wrote:
>On 27/03/2020 13:15, Christos Zoulas wrote:
>>
>>
>>> On Mar 27, 2020, at 4:05 AM, Roy Marples wrote:
>>>
>>> On 27/03/2020 02:06, Christos Zoulas wrote:
@@ -494,6 +530,7 @@
if (tic == NULL)
On 27/03/2020 13:15, Christos Zoulas wrote:
On Mar 27, 2020, at 4:05 AM, Roy Marples wrote:
On 27/03/2020 02:06, Christos Zoulas wrote:
@@ -494,6 +530,7 @@
if (tic == NULL)
return NULL;
+ tic->rtype = _ti_find_rtype(cap);
buf.buf = NULL;
buf.buf
> On Mar 27, 2020, at 4:05 AM, Roy Marples wrote:
>
> On 27/03/2020 02:06, Christos Zoulas wrote:
>> @@ -494,6 +530,7 @@
>> if (tic == NULL)
>> return NULL;
>> + tic->rtype = _ti_find_rtype(cap);
>> buf.buf = NULL;
>> buf.buflen = 0;
>
> If I'm reading this patch
On 27/03/2020 02:06, Christos Zoulas wrote:
@@ -494,6 +530,7 @@
if (tic == NULL)
return NULL;
+ tic->rtype = _ti_find_rtype(cap);
buf.buf = NULL;
buf.buflen = 0;
If I'm reading this patch correctly, it means that the old terminfo library
cannot read
In article ,
Christos Zoulas wrote:
>In article <20200324144303.e147610...@quasar.astron.com>,
>Christos Zoulas wrote:
Finally here is a complete patch that deletes terminfo2.cdb.
This patch restores compatibility with the old terminfo format
for most entries except the handful ones that need th
In article <20200324144303.e147610...@quasar.astron.com>,
Christos Zoulas wrote:
>Hello,
>
>The recent terminfo ABI change to widen numeric constants from 16 bits to
>32 bits was done in the following way:
>
>1. Create a new terminfo2 database and rely on the fact that old
> programs will use th
21 matches
Mail list logo
