Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1271178 > unrolled thread

Bug#1121191: libncurses6:armhf: Remote terminal display a 'yes' word in the promt and another 'yes' word when a I press return

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1121191: libncurses6:armhf: Remote terminal display a 'yes' word in the promt and another 'yes' word when a I press return Christian Marillat <marillat@deb-multimedia.org> - 2025-11-22 15:50 +0100
    Bug#1121191: libncurses6:armhf: Remote terminal display a 'yes' word in the promt and another 'yes' word when a I press return Thomas Dickey <dickey@invisible-island.net> - 2025-11-22 16:30 +0100
      Bug#1121191: libncurses6:armhf: Remote terminal display a 'yes' word in the promt and another 'yes' word when a I press return Christian Marillat <marillat@debian.org> - 2025-11-22 16:50 +0100
    Bug#1121191: (no subject) Christian Marillat <marillat@debian.org> - 2025-11-22 17:10 +0100
      Bug#1121191: (no subject) Thomas Dickey <dickey@invisible-island.net> - 2025-11-22 19:30 +0100
    Bug#1121191: (no subject) Adam Reviczky <reviczky@gmail.com> - 2025-11-23 06:30 +0100
      Bug#1121191: (no subject) Thomas Dickey <dickey@invisible-island.net> - 2025-11-23 12:10 +0100
        Bug#1121191: (no subject) Thomas Dickey <dickey@invisible-island.net> - 2025-11-23 12:40 +0100
    Bug#1121191: smkx/rmkx changes cause zsh issues Chris Hofstaedtler <zeha@debian.org> - 2025-11-23 16:00 +0100
      Bug#1121191: smkx/rmkx changes cause zsh issues Chris Hofstaedtler <zeha@debian.org> - 2025-11-23 16:50 +0100
        Bug#1121191: smkx/rmkx changes cause zsh issues Chris Hofstaedtler <zeha@debian.org> - 2025-11-23 17:00 +0100
    Bug#1121191: (no subject) Thomas Dickey <dickey@invisible-island.net> - 2025-11-23 17:40 +0100
    Bug#1121191: smkx/rmkx changes cause zsh issues Christian Marillat <marillat@debian.org> - 2025-11-23 18:40 +0100

#1271178 — Bug#1121191: libncurses6:armhf: Remote terminal display a 'yes' word in the promt and another 'yes' word when a I press return

Package: libncurses6
Version: 6.5+20251115-2
Severity: normal
X-Debbugs-Cc: marillat@debian.org

Dear Maintainer,

I can reproduce this issue with armhf, arm64, riscv64 architectures

zsh is the shell for theses arches.

downgrading ncurses related packages to 6.5+20250216-2 solve this issue.

Christian

-- System Information:
Debian Release: forky/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 6.12.58-1-custom (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libncurses6:armhf depends on:
ii  libc6      2.41-12
ii  libtinfo6  6.5+20251115-2

Versions of packages libncurses6:armhf recommends:
ii  libgpm2  1.20.7-12

libncurses6:armhf suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1271186

[Multipart message — attachments visible in raw view] — view raw

On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
> Package: libncurses6
> Version: 6.5+20251115-2
> Severity: normal
> X-Debbugs-Cc: marillat@debian.org
> 
> Dear Maintainer,
> 
> I can reproduce this issue with armhf, arm64, riscv64 architectures
> 
> zsh is the shell for theses arches.

presumably both local and remote systems have comparable package versions.
 
> downgrading ncurses related packages to 6.5+20250216-2 solve this issue.

there are at least three places where the problem might be:

	ncurses
	zsh
	terminal emulator

A "typescript" from the "script" program would show what's written to the
terminal, while the environment variables (and output of infocmp) for
the local and remote systems would help with the discussion.

> Christian
> 
> -- System Information:
> Debian Release: forky/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 6.12.58-1-custom (SMP w/4 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libncurses6:armhf depends on:
> ii  libc6      2.41-12
> ii  libtinfo6  6.5+20251115-2
> 
> Versions of packages libncurses6:armhf recommends:
> ii  libgpm2  1.20.7-12
> 
> libncurses6:armhf suggests no packages.
> 
> -- no debconf information
> 

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1271194

On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net> wrote:

> On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
>> Package: libncurses6
>> Version: 6.5+20251115-2
>> Severity: normal
>> X-Debbugs-Cc: marillat@debian.org
>> 
>> Dear Maintainer,
>> 
>> I can reproduce this issue with armhf, arm64, riscv64 architectures
>> 
>> zsh is the shell for theses arches.
>
> presumably both local and remote systems have comparable package versions.

Yes, all have the same packages.

>> downgrading ncurses related packages to 6.5+20250216-2 solve this issue.
>
> there are at least three places where the problem might be:
>
> 	ncurses
> 	zsh
> 	terminal emulator
>
> A "typescript" from the "script" program would show what's written to the
> terminal, while the environment variables (and output of infocmp) for
> the local and remote systems would help with the discussion.

[toc] | [prev] | [next] | [standalone]

#1271195 — Bug#1121191: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net> wrote:

> On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
>> Package: libncurses6
>> Version: 6.5+20251115-2
>> Severity: normal
>> X-Debbugs-Cc: marillat@debian.org
>> 
>> Dear Maintainer,
>> 
>> I can reproduce this issue with armhf, arm64, riscv64 architectures
>> 
>> zsh is the shell for theses arches.
>
> presumably both local and remote systems have comparable package versions.

Yes, all have the same packages.

>> downgrading ncurses related packages to 6.5+20250216-2 solve this issue.
>
> there are at least three places where the problem might be:
>
> 	ncurses
> 	zsh
> 	terminal emulator
>
> A "typescript" from the "script" program would show what's written to the
> terminal, while the environment variables (and output of infocmp) for
> the local and remote systems would help with the discussion.

E-mail send to quickly.

Here is the remote output.

[toc] | [prev] | [next] | [standalone]

#1271208 — Bug#1121191: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On Sat, Nov 22, 2025 at 04:47:39PM +0100, Christian Marillat wrote:
> On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net> wrote:
> 
> > On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
> >> Package: libncurses6
> >> Version: 6.5+20251115-2
> >> Severity: normal
> >> X-Debbugs-Cc: marillat@debian.org
> >> 
> >> Dear Maintainer,
> >> 
> >> I can reproduce this issue with armhf, arm64, riscv64 architectures
> >> 
> >> zsh is the shell for theses arches.
> >
> > presumably both local and remote systems have comparable package versions.
> 
> Yes, all have the same packages.
> 
> >> downgrading ncurses related packages to 6.5+20250216-2 solve this issue.
> >
> > there are at least three places where the problem might be:
> >
> > 	ncurses
> > 	zsh
> > 	terminal emulator
> >
> > A "typescript" from the "script" program would show what's written to the
> > terminal, while the environment variables (and output of infocmp) for
> > the local and remote systems would help with the discussion.
> 
> E-mail send to quickly.
> 
> Here is the remote output.

The local and remote look much the same (agreeing with that).
Just to check, I updated my testing machine to unstable, and
(same terminal emulator, same shell) don't see this happening.

I did a 'strings' on zsh and the main libraries (libtinfo6, libcap),
don't see "yes" compiled-in.  It's not in the terminal description.

Most of the changes for libtinfo since mid-February are specific to
the MinGW/Windows port.

Since I don't use zsh, my test-configuration is pretty minimal.
I'm guessing that the "yes" comes from some program which is run
from your shell, e.g., for configuring the prompt.  I checked
my configuration to see what zsh might run, by

	urxvt -e strace -fo trace.log zsh

but in my case, there were no subprocesses of zsh.

In your typescript files, for each case, the "yes" appears immediately
before enabling or disabling bracketed paste, mode 2004
(which may be coincidental).

In my trace.log, I see the corresponding 2004's:

11657 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m           "..., 103) = 103
11657 write(10, "\r\33[m\33[27m\33[24m\33[Jprl-debiancur-6"..., 35) = 35
11657 write(10, "\33[K", 3)             = 3
11657 write(10, "\33[?2004h", 8)        = 8
11657 write(10, "\33[?2004l", 8)        = 8
11657 write(10, "\r\n", 2)              = 2

In your configuration, you may see some different process writing the "yes".
(Or if it's really zsh, the open's in the trace would probably include the
file containing that "yes").

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1271249 — Bug#1121191: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On Sat, 22 Nov 2025 13:26:16 -0500 Thomas Dickey <
dickey@invisible-island.net> wrote:
> On Sat, Nov 22, 2025 at 04:47:39PM +0100, Christian Marillat wrote:
> > On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net>
wrote:
> >
> > > On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
> > >> Package: libncurses6
> > >> Version: 6.5+20251115-2
> > >> Severity: normal
> > >> X-Debbugs-Cc: marillat@debian.org
> > >>
> > >> Dear Maintainer,
> > >>
> > >> I can reproduce this issue with armhf, arm64, riscv64 architectures
> > >>
> > >> zsh is the shell for theses arches.
> > >
> > > presumably both local and remote systems have comparable package
versions.
> >
> > Yes, all have the same packages.
> >
> > >> downgrading ncurses related packages to 6.5+20250216-2 solve this
issue.
> > >
> > > there are at least three places where the problem might be:
> > >
> > > ncurses
> > > zsh
> > > terminal emulator
> > >
> > > A "typescript" from the "script" program would show what's written to
the
> > > terminal, while the environment variables (and output of infocmp) for
> > > the local and remote systems would help with the discussion.
> >
> > E-mail send to quickly.
> >
> > Here is the remote output.
>
> The local and remote look much the same (agreeing with that).
> Just to check, I updated my testing machine to unstable, and
> (same terminal emulator, same shell) don't see this happening.
>
> I did a 'strings' on zsh and the main libraries (libtinfo6, libcap),
> don't see "yes" compiled-in.  It's not in the terminal description.
>
> Most of the changes for libtinfo since mid-February are specific to
> the MinGW/Windows port.
>
> Since I don't use zsh, my test-configuration is pretty minimal.
> I'm guessing that the "yes" comes from some program which is run
> from your shell, e.g., for configuring the prompt.  I checked
> my configuration to see what zsh might run, by
>
> urxvt -e strace -fo trace.log zsh
>
> but in my case, there were no subprocesses of zsh.
>
> In your typescript files, for each case, the "yes" appears immediately
> before enabling or disabling bracketed paste, mode 2004
> (which may be coincidental).
>
> In my trace.log, I see the corresponding 2004's:
>
> 11657 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m           "..., 103) =
103
> 11657 write(10, "\r\33[m\33[27m\33[24m\33[Jprl-debiancur-6"..., 35) = 35
> 11657 write(10, "\33[K", 3)             = 3
> 11657 write(10, "\33[?2004h", 8)        = 8
> 11657 write(10, "\33[?2004l", 8)        = 8
> 11657 write(10, "\r\n", 2)              = 2
>
> In your configuration, you may see some different process writing the
"yes".
> (Or if it's really zsh, the open's in the trace would probably include the
> file containing that "yes").

The 'yes' is printed out by zle with the 'terminfo' command.

The specific lines from the system-wide zshrc are
https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L76:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Bsmkx%5D%7D
 and
https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L80:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Brmkx%5D%7D
.

You can test this by starting zsh without rc files: zsh -f

Adam

>
> --
> Thomas E. Dickey <dickey@invisible-island.net>
> https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1271266 — Bug#1121191: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 23, 2025 at 05:24:16AM +0000, Adam Reviczky wrote:
> On Sat, 22 Nov 2025 13:26:16 -0500 Thomas Dickey <
> dickey@invisible-island.net> wrote:
> > On Sat, Nov 22, 2025 at 04:47:39PM +0100, Christian Marillat wrote:
> > > On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net>
> wrote:
> > >
> > > > On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
> > > >> Package: libncurses6
> > > >> Version: 6.5+20251115-2
> > > >> Severity: normal
> > > >> X-Debbugs-Cc: marillat@debian.org
> > > >>
> > > >> Dear Maintainer,
> > > >>
> > > >> I can reproduce this issue with armhf, arm64, riscv64 architectures
> > > >>
> > > >> zsh is the shell for theses arches.
> > > >
> > > > presumably both local and remote systems have comparable package
> versions.
> > >
> > > Yes, all have the same packages.
> > >
> > > >> downgrading ncurses related packages to 6.5+20250216-2 solve this
> issue.
> > > >
> > > > there are at least three places where the problem might be:
> > > >
> > > > ncurses
> > > > zsh
> > > > terminal emulator
> > > >
> > > > A "typescript" from the "script" program would show what's written to
> the
> > > > terminal, while the environment variables (and output of infocmp) for
> > > > the local and remote systems would help with the discussion.
> > >
> > > E-mail send to quickly.
> > >
> > > Here is the remote output.
> >
> > The local and remote look much the same (agreeing with that).
> > Just to check, I updated my testing machine to unstable, and
> > (same terminal emulator, same shell) don't see this happening.
> >
> > I did a 'strings' on zsh and the main libraries (libtinfo6, libcap),
> > don't see "yes" compiled-in.  It's not in the terminal description.
> >
> > Most of the changes for libtinfo since mid-February are specific to
> > the MinGW/Windows port.
> >
> > Since I don't use zsh, my test-configuration is pretty minimal.
> > I'm guessing that the "yes" comes from some program which is run
> > from your shell, e.g., for configuring the prompt.  I checked
> > my configuration to see what zsh might run, by
> >
> > urxvt -e strace -fo trace.log zsh
> >
> > but in my case, there were no subprocesses of zsh.
> >
> > In your typescript files, for each case, the "yes" appears immediately
> > before enabling or disabling bracketed paste, mode 2004
> > (which may be coincidental).
> >
> > In my trace.log, I see the corresponding 2004's:
> >
> > 11657 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m           "..., 103) =
> 103
> > 11657 write(10, "\r\33[m\33[27m\33[24m\33[Jprl-debiancur-6"..., 35) = 35
> > 11657 write(10, "\33[K", 3)             = 3
> > 11657 write(10, "\33[?2004h", 8)        = 8
> > 11657 write(10, "\33[?2004l", 8)        = 8
> > 11657 write(10, "\r\n", 2)              = 2
> >
> > In your configuration, you may see some different process writing the
> "yes".
> > (Or if it's really zsh, the open's in the trace would probably include the
> > file containing that "yes").
> 
> The 'yes' is printed out by zle with the 'terminfo' command.
> 
> The specific lines from the system-wide zshrc are
> https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L76:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Bsmkx%5D%7D
>  and
> https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L80:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Brmkx%5D%7D
> .
> 
> You can test this by starting zsh without rc files: zsh -f

I tried this, didn't see the problem, doing this to (try to) eliminate my
environment:

	#!/bin/sh
	unset TERMINFO
	unset TERMINFO_DIRS
	export TERM=xterm-256color
	strace -fo /tmp/trace.log zsh -f

The shell doesn't show anything odd.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1271268 — Bug#1121191: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 23, 2025 at 05:53:53AM -0500, Thomas Dickey wrote:
> On Sun, Nov 23, 2025 at 05:24:16AM +0000, Adam Reviczky wrote:
> > On Sat, 22 Nov 2025 13:26:16 -0500 Thomas Dickey <
> > dickey@invisible-island.net> wrote:
> > > On Sat, Nov 22, 2025 at 04:47:39PM +0100, Christian Marillat wrote:
> > > > On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net>
> > wrote:
> > > >
> > > > > On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat wrote:
> > > > >> Package: libncurses6
> > > > >> Version: 6.5+20251115-2
> > > > >> Severity: normal
> > > > >> X-Debbugs-Cc: marillat@debian.org
> > > > >>
> > > > >> Dear Maintainer,
> > > > >>
> > > > >> I can reproduce this issue with armhf, arm64, riscv64 architectures
> > > > >>
> > > > >> zsh is the shell for theses arches.
> > > > >
> > > > > presumably both local and remote systems have comparable package
> > versions.
> > > >
> > > > Yes, all have the same packages.
> > > >
> > > > >> downgrading ncurses related packages to 6.5+20250216-2 solve this
> > issue.
> > > > >
> > > > > there are at least three places where the problem might be:
> > > > >
> > > > > ncurses
> > > > > zsh
> > > > > terminal emulator
> > > > >
> > > > > A "typescript" from the "script" program would show what's written to
> > the
> > > > > terminal, while the environment variables (and output of infocmp) for
> > > > > the local and remote systems would help with the discussion.
> > > >
> > > > E-mail send to quickly.
> > > >
> > > > Here is the remote output.
> > >
> > > The local and remote look much the same (agreeing with that).
> > > Just to check, I updated my testing machine to unstable, and
> > > (same terminal emulator, same shell) don't see this happening.
> > >
> > > I did a 'strings' on zsh and the main libraries (libtinfo6, libcap),
> > > don't see "yes" compiled-in.  It's not in the terminal description.
> > >
> > > Most of the changes for libtinfo since mid-February are specific to
> > > the MinGW/Windows port.
> > >
> > > Since I don't use zsh, my test-configuration is pretty minimal.
> > > I'm guessing that the "yes" comes from some program which is run
> > > from your shell, e.g., for configuring the prompt.  I checked
> > > my configuration to see what zsh might run, by
> > >
> > > urxvt -e strace -fo trace.log zsh
> > >
> > > but in my case, there were no subprocesses of zsh.
> > >
> > > In your typescript files, for each case, the "yes" appears immediately
> > > before enabling or disabling bracketed paste, mode 2004
> > > (which may be coincidental).
> > >
> > > In my trace.log, I see the corresponding 2004's:
> > >
> > > 11657 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m           "..., 103) =
> > 103
> > > 11657 write(10, "\r\33[m\33[27m\33[24m\33[Jprl-debiancur-6"..., 35) = 35
> > > 11657 write(10, "\33[K", 3)             = 3
> > > 11657 write(10, "\33[?2004h", 8)        = 8
> > > 11657 write(10, "\33[?2004l", 8)        = 8
> > > 11657 write(10, "\r\n", 2)              = 2
> > >
> > > In your configuration, you may see some different process writing the
> > "yes".
> > > (Or if it's really zsh, the open's in the trace would probably include the
> > > file containing that "yes").
> > 
> > The 'yes' is printed out by zle with the 'terminfo' command.
> > 
> > The specific lines from the system-wide zshrc are
> > https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L76:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Bsmkx%5D%7D
> >  and
> > https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L80:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Brmkx%5D%7D
> > .
> > 
> > You can test this by starting zsh without rc files: zsh -f
> 
> I tried this, didn't see the problem, doing this to (try to) eliminate my
> environment:
> 
> 	#!/bin/sh
> 	unset TERMINFO
> 	unset TERMINFO_DIRS
> 	export TERM=xterm-256color

as an afterthought, I recall this was using urxvt.
Commenting out that TERM=, and trying with urxvt gave the same result.

> 	strace -fo /tmp/trace.log zsh -f
> 
> The shell doesn't show anything odd.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1271288 — Bug#1121191: smkx/rmkx changes cause zsh issues

Control: affects -1 zsh

* Adam Reviczky <reviczky@gmail.com> [251123 14:39]:
>> > > You can test this by starting zsh without rc files: zsh -f
>> >
>> > I tried this, didn't see the problem, doing this to (try to) eliminate
>my
>> > environment:
>> >
>> > #!/bin/sh
>> > unset TERMINFO
>> > unset TERMINFO_DIRS
>> > export TERM=xterm-256color
>
>On my ARM machine, I have run this with TERM=xterm-256color
>(trace-xterm-256color.log), TERM= (trace-unset.log) and without "-f" for
>zsh (trace-xterm-256color-full.log).

So indeed the "yes" thing shows up because Debian's system zshrc 
does something.

Reducing the system zshrc gives me:

$ zsh -f
tiksta% echo "$terminfo[smkx]"
yes
tiksta% echo "$terminfo[rmkx]"
yes
tiksta% echo $TERM
alacritty

After downgrading *ncurses* and libtinfo6 to 6.5+20250216-2:

$ zsh -f
tiksta% echo "$terminfo[smkx]"

tiksta% echo "$terminfo[rmkx]"

Best,
Chris

[toc] | [prev] | [next] | [standalone]

#1271295 — Bug#1121191: smkx/rmkx changes cause zsh issues

* Chris Hofstaedtler <zeha@debian.org> [251123 15:53]:
>Reducing the system zshrc gives me:
>
>$ zsh -f
>tiksta% echo "$terminfo[smkx]"
>yes
>tiksta% echo "$terminfo[rmkx]"
>yes
>tiksta% echo $TERM
>alacritty
>
>After downgrading *ncurses* and libtinfo6 to 6.5+20250216-2:
>
>$ zsh -f
>tiksta% echo "$terminfo[smkx]"
>
>tiksta% echo "$terminfo[rmkx]"

Looking at this further, with this C test program:

#include <curses.h>
#include <term.h>

int main(int argc, char** argv)
{
     char *name = "rmkx";
     int num;
     initscr();
     num = tigetnum(name);
     printf("tigetnum %s = %d\n", name, num);
     num = tigetflag(name);
     printf("tigetflag %s = %d\n", name, num);
     return 0;
}

I get the following results, with ncurses 6.5+20251115-2:
   tigetnum rmkx = -2
   tigetflag rmkx = 255

With the older ncurses 6.5+20250216-2:
   tigetnum rmkx = -2
   tigetflag rmkx = -1

Note that these results were obtained using the Debian binaries in 
an arm64 VM.

I see patch 20251101 changed the definition of ABSENT_BOOLEAN from
   ((signed char)-1) 
to
   ((NCURSES_SBOOL)-1)

While configure.in detects the possibility of using `signed char` 
for `NCURSES_SBOOL`, I think by default it uses `char` (without 
--enable-signed-char).

That seems like a problem on platforms where char is unsigned, like 
arm64. Note that on amd64 ("x86"), char is signed.

Chris

[toc] | [prev] | [next] | [standalone]

#1271296 — Bug#1121191: smkx/rmkx changes cause zsh issues

Control: retitle -1 ncurses: API/ABI break for tigetflag return value on unsigned char archs
Control: severity -1 serious

* Chris Hofstaedtler <zeha@debian.org> [251123 16:45]:
>I see patch 20251101 changed the definition of ABSENT_BOOLEAN from
>  ((signed char)-1) to
>  ((NCURSES_SBOOL)-1)
>
>While configure.in detects the possibility of using `signed char` for 
>`NCURSES_SBOOL`, I think by default it uses `char` (without 
>--enable-signed-char).

I think this is an unintentional ABI break on unsigned-char archs, 
and also all binaries which were compiled using 20251101 or newer 
need to be recompiled(!).

Raising severity for awareness.

Chris

[toc] | [prev] | [next] | [standalone]

#1271302 — Bug#1121191: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 23, 2025 at 01:36:53PM +0000, Adam Reviczky wrote:
> On Sun, 23 Nov 2025 06:18:58 -0500 Thomas Dickey <
> dickey@invisible-island.net> wrote:
> > On Sun, Nov 23, 2025 at 05:53:53AM -0500, Thomas Dickey wrote:
> > > On Sun, Nov 23, 2025 at 05:24:16AM +0000, Adam Reviczky wrote:
> > > > On Sat, 22 Nov 2025 13:26:16 -0500 Thomas Dickey <
> > > > dickey@invisible-island.net> wrote:
> > > > > On Sat, Nov 22, 2025 at 04:47:39PM +0100, Christian Marillat wrote:
> > > > > > On 22 nov. 2025 10:13, Thomas Dickey <dickey@invisible-island.net>
> > > > wrote:
> > > > > >
> > > > > > > On Sat, Nov 22, 2025 at 03:45:47PM +0100, Christian Marillat
> wrote:
> > > > > > >> Package: libncurses6
> > > > > > >> Version: 6.5+20251115-2
> > > > > > >> Severity: normal
> > > > > > >> X-Debbugs-Cc: marillat@debian.org
> > > > > > >>
> > > > > > >> Dear Maintainer,
> > > > > > >>
> > > > > > >> I can reproduce this issue with armhf, arm64, riscv64
> architectures
> > > > > > >>
> > > > > > >> zsh is the shell for theses arches.
> > > > > > >
> > > > > > > presumably both local and remote systems have comparable package
> > > > versions.
> > > > > >
> > > > > > Yes, all have the same packages.
> > > > > >
> > > > > > >> downgrading ncurses related packages to 6.5+20250216-2 solve
> this
> > > > issue.
> > > > > > >
> > > > > > > there are at least three places where the problem might be:
> > > > > > >
> > > > > > > ncurses
> > > > > > > zsh
> > > > > > > terminal emulator
> > > > > > >
> > > > > > > A "typescript" from the "script" program would show what's
> written to
> > > > the
> > > > > > > terminal, while the environment variables (and output of
> infocmp) for
> > > > > > > the local and remote systems would help with the discussion.
> > > > > >
> > > > > > E-mail send to quickly.
> > > > > >
> > > > > > Here is the remote output.
> > > > >
> > > > > The local and remote look much the same (agreeing with that).
> > > > > Just to check, I updated my testing machine to unstable, and
> > > > > (same terminal emulator, same shell) don't see this happening.
> > > > >
> > > > > I did a 'strings' on zsh and the main libraries (libtinfo6, libcap),
> > > > > don't see "yes" compiled-in.  It's not in the terminal description.
> > > > >
> > > > > Most of the changes for libtinfo since mid-February are specific to
> > > > > the MinGW/Windows port.
> > > > >
> > > > > Since I don't use zsh, my test-configuration is pretty minimal.
> > > > > I'm guessing that the "yes" comes from some program which is run
> > > > > from your shell, e.g., for configuring the prompt.  I checked
> > > > > my configuration to see what zsh might run, by
> > > > >
> > > > > urxvt -e strace -fo trace.log zsh
> > > > >
> > > > > but in my case, there were no subprocesses of zsh.
> > > > >
> > > > > In your typescript files, for each case, the "yes" appears
> immediately
> > > > > before enabling or disabling bracketed paste, mode 2004
> > > > > (which may be coincidental).
> > > > >
> > > > > In my trace.log, I see the corresponding 2004's:
> > > > >
> > > > > 11657 write(10, "\33[1m\33[7m%\33[27m\33[1m\33[m           "...,
> 103) =
> > > > 103
> > > > > 11657 write(10, "\r\33[m\33[27m\33[24m\33[Jprl-debiancur-6"..., 35)
> = 35
> > > > > 11657 write(10, "\33[K", 3)             = 3
> > > > > 11657 write(10, "\33[?2004h", 8)        = 8
> > > > > 11657 write(10, "\33[?2004l", 8)        = 8
> > > > > 11657 write(10, "\r\n", 2)              = 2
> > > > >
> > > > > In your configuration, you may see some different process writing
> the
> > > > "yes".
> > > > > (Or if it's really zsh, the open's in the trace would probably
> include the
> > > > > file containing that "yes").
> > > >
> > > > The 'yes' is printed out by zle with the 'terminfo' command.
> > > >
> > > > The specific lines from the system-wide zshrc are
> > > >
> https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L76:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Bsmkx%5D%7D
> > > >  and
> > > >
> https://salsa.debian.org/debian/zsh/-/blob/debian/debian/zshrc?ref_type=heads#L80:~:text=printf%20%27%25s%27%20%24%7Bterminfo%5Brmkx%5D%7D
> > > > .
> > > >
> > > > You can test this by starting zsh without rc files: zsh -f
> > >
> > > I tried this, didn't see the problem, doing this to (try to) eliminate
> my
> > > environment:
> > >
> > > #!/bin/sh
> > > unset TERMINFO
> > > unset TERMINFO_DIRS
> > > export TERM=xterm-256color
> 
> On my ARM machine, I have run this with TERM=xterm-256color
> (trace-xterm-256color.log), TERM= (trace-unset.log) and without "-f" for
> zsh (trace-xterm-256color-full.log).
> 
> Adam
> 
> >
> > as an afterthought, I recall this was using urxvt.
> > Commenting out that TERM=, and trying with urxvt gave the same result.
> >
> > > strace -fo /tmp/trace.log zsh -f
> > >
> > > The shell doesn't show anything odd.
> >
> > --
> > Thomas E. Dickey <dickey@invisible-island.net>
> > https://invisible-island.net

just looking at "zsh" and "open", I don't see anything really different
from my configuration (though I also added the "zsh-xxx" packages, just
to check):

> 8854  execve("/usr/bin/zsh", ["zsh", "-f"], 0x7fffd332bca8 /* 67 vars */) = 0
> 8854  newfstatat(AT_FDCWD, "/etc/zsh/zshenv.zwc", 0x7fffd58d8a18, 0) = -1 ENOENT (No such file or directory)
> 8854  newfstatat(AT_FDCWD, "/etc/zsh/zshenv", {st_mode=S_IFREG|0644, st_size=623, ...}, 0) = 0
> 8854  openat(AT_FDCWD, "/etc/zsh/zshenv", O_RDONLY|O_NOCTTY) = 3
> 8854  read(11, "# /etc/zsh/zshenv: system-wide ."..., 8192) = 623
> 8854  openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/zle.so", O_RDONLY|O_CLOEXEC) = 3
> 8854  openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/complete.so", O_RDONLY|O_CLOEXEC) = 3
> 8854  openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/compctl.so", O_RDONLY|O_CLOEXEC) = 3
> 8896  execve("/usr/bin/zsh", ["zsh", "-f"], 0x7ffffcaa02e8 /* 67 vars */) = 0
> 8896  newfstatat(AT_FDCWD, "/etc/zsh/zshenv.zwc", 0x7fffd0161ec8, 0) = -1 ENOENT (No such file or directory)
> 8896  newfstatat(AT_FDCWD, "/etc/zsh/zshenv", {st_mode=S_IFREG|0644, st_size=623, ...}, 0) = 0
> 8896  openat(AT_FDCWD, "/etc/zsh/zshenv", O_RDONLY|O_NOCTTY) = 3
> 8896  read(11, "# /etc/zsh/zshenv: system-wide ."..., 8192) = 623
> 8896  openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/zle.so", O_RDONLY|O_CLOEXEC) = 3
> 8896  openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/complete.so", O_RDONLY|O_CLOEXEC) = 3
> 8896  openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/zsh/5.9/zsh/compctl.so", O_RDONLY|O_CLOEXEC) = 3

ltrace can also show pertinent details, but in a quick check of that,
I see only "yes" found when reading the /usr/bin directory (and that's
expected).

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

[toc] | [prev] | [next] | [standalone]

#1271305 — Bug#1121191: smkx/rmkx changes cause zsh issues

On 23 nov. 2025 12:13, Thomas Dickey <dickey@invisible-island.net> wrote:

[...]

> Actually it's used in lib_ti.c, and promoted to an int.
> So it may/may not be sign-extended, which I assume is the bug.
>
> I have an arm64 machine, which may show me the issue.

Argh! So I'm not mad.

Christian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web