Package: tmux Version: 2.6-3 Severity: normal Many thanks for maintaining tmux! I use it constantly!
I've noticed a new problem with tmux on at least two buster machines,
but I have not observed it on any stretch machines.
I've got a tmux (2.3-4) session running on a stretch machine, from which
I ssh to a buster machine and run tmux (2.6-3). In both cases,
TERM=screen. When the output reaches the bottom of the screen, the
output gets garbled, leaving artifacts from previous states:
vagrant@wbs:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 00:1f:7b:b0:0c:43 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::21f:7bff:feb0:c43/64 scope link
valid_lft forever preferred_lft forever
vagrant@wbs:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 00:1f:7b:b0:0c:43 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
vagrant@wbs:~$ ip a:7bff:feb0:c43/64 scope link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/ether 00:1f:7b:b0:0c:43 brd ff:ff:ff:ff:ff:ff:00
inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::21f:7bff:feb0:c43/64 scope link
valid_lft forever preferred_lft forever
vagrant@wbs:~$ CAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
It gets progressively more garbled as more commands produce more
output. Issuing "reset" doesn't clear the screen, though the cursor
moves to the top.
It doesn't appear to happen if I ssh in from an xterm and start tmux,
so seems to have something to do with nested tmux sessions over ssh,
maybe some incompatibility between versions... ?
If it matters, the stretch machine was running amd64, but the buster
machines were armhf and arm64.
live well,
vagrant
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armhf (armv7l)
Kernel: Linux 4.15.0-1-armmp (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tmux depends on:
ii libc6 2.27-1
ii libevent-2.1-6 2.1.8-stable-4
ii libtinfo5 6.1-1
ii libutempter0 1.1.6-3
tmux recommends no packages.
tmux suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
