Matrix Synapse failing to install on brand new DietPi installation when SSH'd in using the kitty terminal emulator

[jahway603]

Creating a bug report/issue

Required Information

• DietPi version | cat /boot/dietpi/.version
  G_DIETPI_VERSION_CORE=8
  G_DIETPI_VERSION_SUB=10
  G_DIETPI_VERSION_RC=-1
  G_GITBRANCH='matrix-synapse'
  G_GITOWNER='MichaIng'
• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  bullseye
• Kernel version | uname -a
Linux hostname 5.15.72-rockchip64 #22.08.4 SMP PREEMPT Fri Oct 7 16:46:30 UTC 2022 aarch64 GNU/Linux
• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  ROCK64 (aarch64)
• Power supply used | (EG: 5V 1A RAVpower)
  Pine64 supplied power supply
• SD card used | (EG: SanDisk ultra)
  Booting directly off a Samsung T7 USB SSD drive - no SD card used on this system

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
  Matrix Synapse
• Was the software title installed freshly or updated/migrated?
  Freshly
• Can this issue be replicated on a fresh installation of DietPi?
  Yes

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. SSH into dietpi system using kitty terminal emulator.
2. Run the following commands as discussed in Draft #DietPi-Software | Synapse: Fix install due to Rust integration #5778

G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=matrix-synapse' /boot/dietpi.txt
dietpi-update 1
dietpi-software install 125

3. Install fails due to the terminal used [Please see Actual behaviour below for exact error]

Expected behaviour

• It should install correctly and not fail.

Actual behaviour

• Install fails on the "Synapse Matrix" portion and the result is listed below:

 DietPi-Software
─────────────────────────────────────────────────────
 Step: Installing Synapse: Matrix homeserver implementation

[ INFO ] DietPi-Software | APT install for: gcc libpq-dev make, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
gcc is already the newest version (4:10.2.1-1).
make is already the newest version (4.3-4.1).
libpq-dev is already the newest version (13.8-0+deb11u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[  OK  ] DietPi-Software | APT install for: gcc libpq-dev make
[  OK  ] DietPi-Software | mount -o remount,size=2G /tmp
tput: unknown terminal "xterm-kitty"
/boot/dietpi/func/dietpi-globals: line 271: ( 70 + 5 ) /  : syntax error: operand expected (error token is "/  ")

Extra details

• This might be related to Issue [New as of DietPi 8.2.2] Keep getting "Unsupported SSH client terminal" popup window upon login #5341 regarding the kitty terminal software.
• When I used a different terminal emulator, alacritty, then it installed correctly and did not fail.

[MichaIng]

Yes, the issue is the KiTTY terminal, which is not supported OOTB by any OS I know but must be manually installed as stated in the KiTTY FAQ linked in the link.

However, I'd just change the TERM passed by KiTTY to xterm, which can be done in the KiTTY settings.

What I wonder is that you should see a related warning already on login:
Can you show the output of the following commands when logged in via KiTTY and xterm-kitty:

echo "$SSH_TTY"
term="/${TERM::1}/$TERM"
ls -l "/lib/terminfo$term" "/usr/share/terminfo$term" ~/".terminfo$term" "/etc/terminfo$term"

[jahway603]

dietpi@hostname:~$ echo "$SSH_TTY"
/dev/pts/0
dietpi@hostname:~$ term="/${TERM::1}/$TERM"
dietpi@hostname:~$ ls -l "/lib/terminfo$term" "/usr/share/terminfo$term" ~/".terminfo$term" "/etc/terminfo$term"
ls: cannot access '/lib/terminfo/x/xterm-kitty': No such file or directory
ls: cannot access '/usr/share/terminfo/x/xterm-kitty': No such file or directory
ls: cannot access '/etc/terminfo/x/xterm-kitty': No such file or directory
-rw-r--r-- 1 dietpi dietpi 3394 Oct 11 18:15 /home/dietpi/.terminfo/x/xterm-kitty

[jahway603]

On new servers, I always follow this from the kitty FAQ because the kitty terminfo files are not available on the server. kitty +kitten ssh myserver is the command which will automatically copy the terminfo files to the server, which is why there is
-rw-r--r-- 1 dietpi dietpi 3394 Oct 11 18:15 /home/dietpi/.terminfo/x/xterm-kitty

[MichaIng]

kitty +kitten ssh myserver

Ah I didn't know that one 👍.

So it is installed, but for dietpi user only. I suggest to move it to global configs to be available for all users:

sudo mkdir -p /etc/terminfo/x
sudo mv /{home/dietpi/.,etc/}terminfo/x/xterm-kitty

[jahway603]

The /etc/terminfo directory has a README with the following in it:

This directory is for system-local terminfo descriptions. By default, 
ncurses will search ${HOME}/.terminfo first, then /etc/terminfo (this 
directory), then /lib/terminfo, and last not least /usr/share/terminfo.

On my production DietPi system, I have this file copied into /lib/terminfo/x/xterm-kitty, as was suggested as a work around here #5341 (comment)

Is there the possibility to include xterm-kitty in the DietPi build (in one of the directories mentioned in the README above) so that no one else will have these types of issues moving forward?

[MichaIng]

Is there the possibility to include xterm-kitty in the DietPi build

No, I'm not going to start adding custom terminal support without even knowing which/if there is any benefit of using this terminal. Do you know what xterm-kitty is actually used for, what makes it better with KiTTY compared to xterm?

/lib/terminfo and /usr/share/terminfo are used by packages, so it can be seen slightly cleaner to put custom ones into /etc/terminfo when they shall be applied system-wide, else ~/.terminfo for a single user only.

[jahway603]

@MichaIng this is my favorite desktop terminal emulator which I've been using for years now. Unfortunately, I do not have the answer to the question "Do you know what xterm-kitty is actually used for, what makes it better with KiTTY compared to xterm?", but perhaps the developer of this terminal, @kovidgoyal, can answer this Q so we can both learn more.

[MichaIng]

Jep, I'm interested in this as well, cannot find any info in KiTTY docs or changelog.

EDIT: It has been added with one of the very first commits on GitHub, but not explaining why and it was definitely not used by default 1-2 years ago when I tested KiTTY last for other reasons 🤔 (or I just forgot that I changed it to xterm that time): kovidgoyal/kitty@3bb429df

[jahway603]

@MichaIng filed Issue kovidgoyal/kitty#5597 with upstream to track this.

[MichaIng]

If is not "required", but it may enable some additional text formatting features, color schemes or such.

[jahway603]

Without it, I can't run certain applications, like htop, on any server I SSH into.

[MichaIng]

When setting up xterm as TERM variable in KiTTY settings?

[jahway603]

When setting up xterm as TERM variable in KiTTY settings?

Upstream answered our questions in kovidgoyal/kitty#5597 & closed the Issue. I learned that KiTTY and kitty terminal (which is what I use) are not the same and that setting TERM to xterm will break my terminal.

[MichaIng]

And I at first overlooked that important statement 😄. So the question then is why KiTTY uses kitty by default instead of a more compatible terminal. But sometimes initiatives like this are required to overcome dinosaurs and move to the future. If everyone just tries to be most compatible by using most established/old stuff, then nothing would move 😉. Just a guess what might be the reason.

EDIT: Lol, again wrong, you used kitty while I understood you used KiTTY. This is the reason I didn't face the issue when testing KiTTY some time ago 😄.

[trygveaa]

No, I'm not going to start adding custom terminal support without even knowing which/if there is any benefit of using this terminal. Do you know what xterm-kitty is actually used for, what makes it better with KiTTY compared to xterm?

Note that kittys terminfo is packaged in Debian, so you'd only have to include that package: https://packages.debian.org/bullseye/kitty-terminfo

Ideally, the terminfo on the server would be for the same version that the local terminal is, but that's hard to achieve. I don't think there's been that many changes to the terminfo lately, so it should work mostly fine.