I saw this in rc.log rc default logging started at Thu Apr 13 19:22:43 2023 (null)rsyslog (null)| (null)*(null) Checking rsyslogd's configuration(null) ... (null)dbus (null)| (null)*(null) Starting dbus(null) ... (null)rsyslog (null)|(null) (null)[(null) ok (null)](null) (null)rsyslog (null)| (null)*(null) Starting rsyslog(null) ... (null)irqbalance (null)| (null)*(null) Starting irqbalance(null) ... (null)dbus (null)|(null) (null)[(null) ok (null)](null) (null)irqbalance (null)|(null) (null)[(null) ok (null)](null) (null)net.br0 (null)| (null)*(null) Bringing up interface br0(null) (null)net.br0 (null)| (null)*(null) Caching network module dependencies(null) (null)net.br0 (null)| (null)*(null) Creating bridge br0(null) ... (null)net.br0 (null)| (null)*(null) Setting forward_delay: 0(null) (null)net.br0 (null)| (null)*(null) Setting hello_time: 1000(null) (null)net.br0 (null)| (null)*(null) Adding ports to br0(null) (null)net.br0 (null)| (null)*(null) eth0(null) ... (null)net.br0 (null)|(null) (null)[(null) ok (null)](null) (null)net.br0 (null)| (null)*(null) 192.168.2.3/24(null) ... (null)net.br0 (null)|(null) (null)[(null) ok (null)](null) (null)net.br0 (null)| (null)*(null) Adding routes(null) (null)net.br0 (null)| (null)*(null) default via 192.168.2.1(null) ... (null)net.br0 (null)|(null) (null)[(null) ok (null)](null) (null)net.br0 (null)|(null) (null)[(null) ok (null)](null) (null)rsyslog (null)|(null) (null)[(null) ok (null)](null) (null)cronie (null)| (null)*(null) Starting cronie(null) ... (null)named (null)| (null)*(null) Starting named(null) ... (null)elogind (null)| (null)*(null) Starting elogind(null) ... (null)named (null)| (null)*(null) Checking named configuration(null) ... (null)cronie (null)|(null) (null)[(null) ok (null)](null) (null)elogind (null)|(null) (null)[(null) ok (null)](null) (null)named (null)|(null) (null)[(null) ok (null)](null) (null)named (null)|(null) (null)[(null) ok (null)](null) (null)netmount (null)| (null)*(null) Mounting network filesystems(null) ... (null)netmount (null)|(null) (null)[(null) ok (null)](null) (null)chronyd (null)| (null)*(null) Starting chronyd(null) ... (null)chronyd (null)|(null) (null)[(null) ok (null)](null) (null)display-manager (null)| (null)*(null) Starting display-manager(null) ... (null)display-manager (null)|(null) (null)[(null) ok (null)](null) (null)local (null)| (null)*(null) Starting local(null) ... (null)local (null)|(null) (null)[(null) ok (null)](null) rc default logging stopped at Thu Apr 13 19:22:45 2023 Also in starting/stoping/statusing services rc-status Runlevel: (null)default(null) osclock (null) (null)[(null) started (null)](null) irqbalance (null) (null)[(null) started (null)](null) dbus (null) (null)[(null) started (null)](null) net.br0 (null) (null)[(null) started (null)](null) rsyslog (null) (null)[(null) started (null)](null) named (null) (null)[(null) started (null)](null) netmount (null) (null)[(null) started (null)](null) chronyd (null) (null)[(null) started (null)](null) cronie (null) (null)[(null) started (null)](null) elogind (null) (null)[(null) started (null)](null) display-manager (null) (null)[(null) started (null)](null) local (null) (null)[(null) started (null)](null) Dynamic Runlevel: (null)hotplugged(null) Dynamic Runlevel: (null)needed/wanted(null) lvm (null) (null)[(null) started (null)](null) display-manager-setup (null) REVERTING BACK TO sys-libs/ncurses-6.4_p20230401 SOLVED THE ISSUE.
This is arguably a dupe of bug 904263 but let's call it a separate one given the vim one is somewhat specific. In any case, I've just masked it.
Okay, so I can reproduce this by building OpenRC with ncurses support, and then running: ``` openrc-0.46-build/src/einfo $ ./ewarn hi (null)*(null) hi(null) ```
``` openrc-0.46-build/src/einfo $ ./eval_ecolors GOOD='(null)' WARN='(null)' BAD='(null)' HILITE='(null)' BRACKET='(null)' NORMAL='(null)' ``` In gdb: ``` (gdb) b libeinfo.c:440 Note: breakpoint 5 also set at pc 0x7ffff7fbbb5b. Breakpoint 6 at 0x7ffff7fbbb5b: file ../openrc-0.46/src/libeinfo/libeinfo.c, line 441. (gdb) p *ecolors_str $10 = 0x7ffff7fc1ac0 <ebuffer> "(null)\033[32m" (gdb) (gdb) p tmp $16 = "(null)\033[32m\000@\003\000\000\000m\000\000\005\000\000\000\277\000\000\000;\212\000\000\000\003\034\177\025\004\000\001\000\021\023\032\000\022\017\027\026\000\000\000\000\000\000\000\000\251qd20\326b\000\000\000\000\000\000\000\000\340\221\352\367\377\177\000\000\000m\000\000\005\000\000\000\277\000\000\000;\212\000\000\000\003\034\177" [...] (gdb) p myData $60 = {format = 0x55555555ace0 "\033[1m", tparm_type = 0, num_actual = 0, num_parsed = 0, num_popped = 0, param = {0, 0, 0, 0, 0, 0, 0, 0, 0}, p_is_s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (gdb) n colour_terminal (f=f@entry=0x7ffff7f825a0 <_IO_2_1_stdout_>) at ../openrc-0.46/src/libeinfo/libeinfo.c:436 436 strlcpy(tmp, tgoto(bold, 0, 0), sizeof(tmp)); (gdb) p tmp $61 = "\000\003\000\000@\003\000\000@\003\000\000@\003\000\000\000m\000\000\005\000\000\000\277\000\000\000;\212\000\000\000\003\034\177\025\004\000\001\000\021\023\032\000\022\017\027\026\000\000\000\000\000\000\000\000\n\024P\034\3446S\000\000\000\000\000\000\000\000\340\221\352\367\377\177\000\000\000m\000\000\005\000\000\000\277\000\000\000;\212\000\000\000\003\034\177" (gdb) p *tmp $62 = 0 '\000' (gdb) n 437 strlcat(tmp, tgoto(_af, 0, c & 0x07), sizeof(tmp)); (gdb) n [...] (gdb) p myData $71 = {format = 0x55555555aea0 "\033[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m", tparm_type = 0, num_actual = 1, num_parsed = 0, num_popped = 1, param = {0, 0, 0, 0, 0, 0, 0, 0, 0}, p_is_s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (gdb) n 1279 } else if (myData.num_actual > expected) { (gdb) n 1283 } else if (expected != 9 && myData.num_actual != expected) { (gdb) n 1290 va_start(ap, string); (gdb) n 1291 tparm_copy_valist(&myData, FALSE, ap); (gdb) n 1294 result = tparam_internal(tps, string, &myData); (gdb) n 1297 returnPtr(result); (gdb) p string $72 = 0x7ffff7fc1040 <tcapbuf> "\033[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m" (gdb) p result $73 = 0x55555555af10 "\033[32m" (gdb) n colour_terminal (f=f@entry=0x7ffff7f825a0 <_IO_2_1_stdout_>) at ../openrc-0.46/src/libeinfo/libeinfo.c:437 437 strlcat(tmp, tgoto(_af, 0, c & 0x07), sizeof(tmp)); (gdb) p tmp $74 = "(null)\000\000@\003\000\000@\003\000\000\000m\000\000\005\000\000\000\277\000\000\000;\212\000\000\000\003\034\177\025\004\000\001\000\021\023\032\000\022\017\027\026\000\000\000\000\000\000\000\000\n\024P\034\3446S\000\000\000\000\000\000\000\000\340\221\352\367\377\177\000\000\000m\000\000\005\000\000\000\277\000\000\000;\212\000\000\000\003\034\177" (gdb) ``` I'm not really sure what I'm looking for at this point, as I lack much knowledge at all about terminal capabilities.
I see that OpenRC is passing hardcoded strings to tgoto(), which do not come from the terminal database (when tgoto() returns a null, indicating a failure for that capability), and using the output of tgoto() to copy/use other places. That's a defect in OpenRC. Perhaps they'll fix it. The documentation is clear enough: o Because the capability may have padding characters, the output of tgoto should be passed to tputs rather than some other output func- tion such as printf(3). https://invisible-island.net/ncurses/man/curs_termcap.3x.html#h3-Formatting-Capabilities
So... within the scope of ncurses, I'm looking for valid scenarios where the terminal database is initialized, and holding correctly formatted information which will be output using ncurses functions such as tputs, printw, etc.
Understood, thanks for clarifying what OpenRC is doing wrong. I'll let you know if there's any other cases that are unclear, but it sounds like we have: - bug 904263 for vim which is an issue you're hopefully able to address in the next patch (there's some other comments in that bug about OpenRC but they're in the wrong place) - bug 904277 (this bug) for OpenRC abusing/misusing ncurses and it needs fixing on their end. It's unclear whether the issues with joe mentioned in bug 904263 are the same as the vim issue. Not aware of anything else.
The issue with vim might be the case that I mentioned ("tsl" = to-status-line, using the xterm title-string which doesn't have a parameter). I overlooked that last week (because this took longer than anticipated), and am testing a change for _that_ now. But I'll investigate vim, to see if there are other special cases that I hadn't thought of.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36cb6e7e797ce084f8952716da8816e3613bedd0 commit 36cb6e7e797ce084f8952716da8816e3613bedd0 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-04-16 03:26:39 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-04-16 03:28:54 +0000 sys-libs/ncurses: add 6.4_p20230415 This should fix the issues with vim (bug #904263) but this version remains masked for now because OpenRC itself needs fixing due to abuse of ncurses (bug #904277). Bug: https://bugs.gentoo.org/904247 Bug: https://bugs.gentoo.org/904277 Closes: https://bugs.gentoo.org/904263 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 5 + sys-libs/ncurses/Manifest | 3 + sys-libs/ncurses/ncurses-6.4_p20230415.ebuild | 431 ++++++++++++++++++++++++++ 3 files changed, 439 insertions(+)
Revisiting this, with current ncurses (20230418), I don't see it breaking. openrc's still abusing the interface, but for the joe-editor bug, I amended tgoto to permit no-parameter capabilities, which may be relevant. (not checking error-returns and passing a null pointer to fprintf is a bug in openrc which probably will be noticed by others)
I am looking at fixing openrc's usage of it.
I'm not able to reproduce this bug with openrc-0.48 and ncurses-6.4_p20230527. All colours in rc-status output looks nice.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=131cd61f4cddd46392a3c518ae33e2ef3b1d3e77 commit 131cd61f4cddd46392a3c518ae33e2ef3b1d3e77 Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2024-04-01 19:34:39 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2024-04-01 19:35:53 +0000 sys-apps/openrc: add 0.54 Closes: https://bugs.gentoo.org/904277 Signed-off-by: William Hubbs <williamh@gentoo.org> sys-apps/openrc/Manifest | 1 + sys-apps/openrc/openrc-0.54.ebuild | 162 +++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+)
