(not sure if related to tinfo USE-flag) After upgrading to =sys-libs/ncurses-6.4_p20230401 I've found that some terminfo definitions became broken. For example, xterm-direct256, which I used for years, now makes `less` to produce: ``` WARNING: terminal is not fully functional ``` and don't enter alternate screen mode. `vim9` also doesn't enter altscreen anymore with it. `mc` - blames that terminal doesn't support 256 colors, despite both terminal application and selected terminfo (xterm-direct256) do support it. `mtr` also blames `Error opening terminal: xterm-direct256.` and refuses to start. And so on. Same behaviour also can be seen with some others terminfos. (!!!) downgrading to 6.3_p20221203-r2 makes all the things work fine again. // Probably blocker for https://bugs.gentoo.org/457530 Reproducible: Always
You're not using USE=minimal, right? One thing different with the ancient 2022 version is that it installed a few fallback terminfo (including some xterm ones) even with USE=minimal
emerge --info sys-libs/ncurses, please.
(In reply to Ionen Wolkens from comment #1) > You're not using USE=minimal, right? One thing different with the ancient > 2022 version is that it installed a few fallback terminfo (including some > xterm ones) even with USE=minimal Or wait, nevermind that didn't change. I forget why I thought that (recall something changed, but can't remember). Eitherway I wouldn't recommend minimal.
(In reply to Ionen Wolkens from comment #3) > (In reply to Ionen Wolkens from comment #1) > > You're not using USE=minimal, right? One thing different with the ancient > > 2022 version is that it installed a few fallback terminfo (including some > > xterm ones) even with USE=minimal > Or wait, nevermind that didn't change. I forget why I thought that (recall > something changed, but can't remember). Eitherway I wouldn't recommend > minimal. Oh right, with USE=-split-usr they don't get installed in /etc/terminfo. That shouldn't have an impact though.
Thus far, I've reproduced the reported behaviour by setting TERM=xterm-direct256 in the course of executing less-633, mtr-0.95 and vim-9.0.1503. Upgrading from 6.4_p20230401 to 6.4_p20230527 (which currently masked) did not alter said behaviour. I tried the exact same tests in Arch (ncurses 6.4_20230520-1, less 1:633-1, vim 9.0.1676-1), which does not exhibit any issue. Why is unclear to me. In all cases, I used xterm as the terminal emulator, not that it ended up mattering.
On a whim, I prevented the ebuild from applying any patches, which rather bluntly rectifies the issue.
Created attachment 865609 [details] emerge --info sys-libs/ncurses (In reply to Sam James from comment #2) > emerge --info sys-libs/ncurses, please. Oh, sorry, I've distracted and forgot to attach
Applying only ncurses-6.4-20230107.patch still results in a working build. Applying ncurses-6.4-20230114.patch on top of that results in a defective build.
May I ask why we have all these patches to begin with? Can we not just pick a snapshot tarball from the following location? https://invisible-mirror.net/archives/ncurses/current/ It seems to be me that doing would simplify the maintenance burden while also making it less likely for things to go awry. At the time of writing, Arch's PKGBUILD fetches ncurses-6.4-20230520.tgz, which works fine in so far as this bug is concerned.
I think(?) the reason it works for Arch is that they're forcing everything to link with the widec version of the libraries. i.e. if I link less(1) with tinfow rather than tinfo, it seems(?) fine. So the version/tarball used by Arch is likely still affected, but they just have a setup that doesn't trigger the issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4835fedb1257d15d871c885e19b8fecfff78abfd commit 4835fedb1257d15d871c885e19b8fecfff78abfd Author: Sam James <sam@gentoo.org> AuthorDate: 2023-07-17 22:02:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-07-17 22:03:32 +0000 sys-apps/less: fix tinfo linkage, add LFS Thanks to ionen and kerframil for doing the hard work here wrt tinfo, just doing the then-obvious patch as a result. Also, while at it, enable large file support. Closes: https://bugs.gentoo.org/896316 Closes: https://bugs.gentoo.org/910430 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/less/files/less-633-tinfow.patch | 52 +++++++++++++++++++ sys-apps/less/less-633-r2.ebuild | 86 +++++++++++++++++++++++++++++++ sys-apps/less/less-9999.ebuild | 8 ++- 3 files changed, 145 insertions(+), 1 deletion(-)
Thomas, I was wondering if you had any insight here. The gist is that less was finding -lncursesw but using -ltinfo (not -ltinfow) because of bad search order, and then `TERM=xterm-direct256 less` errored out. It's apparently exposed by https://github.com/ThomasDickey/ncurses-snapshots/commit/7144200303b2df93a7441a1b47ae133a56e06ad7. I assume the mixing is unsupported but I wonder: - Is there a workaround possible? - Is there a way to poison ncursesw when building with split tinfo, so that you get some unresolved symbol in there which only tinfow can satisfy? - Is this mixture supported? (I assume not, but I have to ask.) I note https://bugzilla.redhat.com/show_bug.cgi?id=1580323 in the past which was kind of similar. Anyway, I've sent a fix upstream to less at https://github.com/gwsw/less/pull/403, but I worry about more of these.
(In reply to Sam James from comment #12) > Thomas, I was wondering if you had any insight here. > > The gist is that less was finding -lncursesw but using -ltinfo (not > -ltinfow) because of bad search order, and then `TERM=xterm-direct256 less` > errored out. > > It's apparently exposed by > https://github.com/ThomasDickey/ncurses-snapshots/commit/ > 7144200303b2df93a7441a1b47ae133a56e06ad7. > > I assume the mixing is unsupported but I wonder: > - Is there a workaround possible? > - Is there a way to poison ncursesw when building with split tinfo, so that > you get some unresolved symbol in there which only tinfow can satisfy? > - Is this mixture supported? (I assume not, but I have to ask.) > > I note https://bugzilla.redhat.com/show_bug.cgi?id=1580323 in the past which > was kind of similar. > > Anyway, I've sent a fix upstream to less at > https://github.com/gwsw/less/pull/403, but I worry about more of these. ... or maybe there isn't any mixing, as only tinfo or tinfow is linked at the end, and perhaps the termcap is just broken for tinfo? (but there's still mixing of headers it seems anyway.)
Debian provides just tinfo, which is shared between ncurses/ncursesw. The calling interfaces are supposed to be compatible. The ncurses utilities use the structs internally - other programs don't see those. I don't see anything odd in the patch, other than perhaps if one was building the terminal database using an old version of tic, which had problems with forward-references. That was before 6.3 (but some of the fixes were in tinfo): https://invisible-island.net/ncurses/announce-6.2.html#h3-bug-fixes Since less (as a termcap application) doesn't use any of the structs, I don't see how a difference in alignment would affect it. If (as suggested below) the structs are misaligned, one could add a step in the build to show the offsets (make check), for both tinfo and tinfow. Regarding tarballs - I don't keep the development tarballs indefinitely. Patches are retained (and accumulated in a zip-file). The "same" information is exported to git.
By the way, less is not the only application that doesn't want to work with `TERM=xterm-direct256`. Same for `tmux` and `mtr`: `tmux`: missing or unsuitable terminal: xterm-direct256 `mtr`: Error opening terminal: xterm-direct256. (both exiting with code 1) Also, vim9 fails to enter alt_screen, and `mc` blames that terminal doesn't support 256colors (despite that xterm-direct256 is exactly for 256color support)
Okay, so it seems like there really is an issue with newer ncurses and certain terminfos if not using tinfow. No mixing involved.
Created attachment 865763 [details] script used to mock-up the Gentoo packages
Created attachment 865764 [details] ncurses debugging trace from "demo_terminfo" I created this trace by setting NCURSES_TRACE=0xfffff when running "demo_terminfo" in the mockup for "ncurses", which shows that it successfully reads the terminal database entry with extended numbers, which are truncated to 32767. There's a "demo_termcap" program too, but it wouldn't see any big numbers.
I checked with a mockup of the Gentoo package configuration, but see no problem running it. If you've configured with the trace feature, you may see some useful information with it. fwiw, both the terminfo and termcap library interfaces work for me. (The issue with openrc isn't applicable to vim and less, since they use tgoto rather than tparm). That's with current code - the changes we discussed earlier for tparm were after 20230401 (which is the title of this bug report) and before the 20230527 used in the ebuild.
Created attachment 865766 [details] out from infocmp ABI 5 versus 6 Just as a reminder, "tinfo" does not support the extended number format introduced in ncurses 6.1, which means that (while the terminal description is certainly usable by termcap applications) some of the extended terminfo features are limited. Here's the output from infocmp, for "xterm-direct256" to illustrate.
