On 30/03/2020 03:07, Christos Zoulas wrote:
On Mar 29, 2020, at 9:42 PM, Roy Marples <r...@marples.name> 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 local changes, as such nothing to document
other than whence it came and I believe that is self documented.
Any changes I have made were submitted upstream.
Have you submitted your cleanups upstream or do we need to de-tangle them from
the next import?
There is a vendor branch now so the local changes will be merged in the next
import.
Whoever "imported" for the first time just cvs added it and committed instead
of importing.
Just following the precedence of our old termcap.
It also took 4 months before we discovered the
uint16_t field overflow. I didn't even know that there was a 16 bit
limitation, so I could not have figured it out.
Versioning, layout and limitations described here:
https://nxr.netbsd.org/xref/src/lib/libterminfo/term_private.h?r=1.1#39
You must have read that to be able to propose and make the changes.
I still would not have looked or found the field overflow visualy.
Even when I aksed you to check you didn't break screen-256color?
I tested my changes (and tetris seemed to work but with different colors).
Maybe a clue?
But without unit-tests or a test procedure it is impossible to check all cases.
In fact I introduced a bug Andreas found in sysinst for using the wrong
variable.
I *asked* you to test screen-256colour because that is why I introdued a new
record type, to ensure that any database merges don't break anything just
recently fixed.
It should not be that hard to compare the compiled output from infocmp with the
terminfo description for large numbers.
My personal test procedure is to take infocmp -1 output from netbsd and ncurses
and run them through diff for all the terminals. They should be identical and
were when I last imported.
This can be scripted, but AFAIK we can't hook pkgsrc into the unit tests.
Ok. Why do we need pkgsrc here? Can't we fix our infocmp?
Our libterminfo/infocmp can't guess how or where ncurses will further extend any
terminfo descriptions from POSIX it maintains.
Without ncurses installed I have no idea how to test that.
Ideas of course welcome.
Roy
