On 30/03/2020 03:07, Christos Zoulas wrote:
On Mar 29, 2020, at 9:42 PM, Roy Marples <roy%marples.name@localhost> 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