Debian Bug report logs - #854414
screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: csights <cwseys@physics.wisc.edu>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

Date: Mon, 06 Feb 2017 14:33:25 -0600

Package: screen
Version: 4.5.0-3
Severity: important

Dear Maintainer,

After upgrading from Jessie to Stretch, when I ssh to another computer and then try to use
atop, nano, and others they fail to run with:
Error opening terminal: screen.xterm-256color.

Running these programs locally within screen gives no problems

A workaround is to do:
export TERM=xterm

Thanks for your help!
C.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages screen depends on:
ii  libc6      2.24-9
ii  libpam0g   1.1.8-3.5
ii  libtinfo5  6.0+20161126-1

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  <none>
ii  ncurses-term                6.0+20161126-1

-- no debconf information

Message #10 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: csights <cwseys@physics.wisc.edu>, 854414@bugs.debian.org

Subject: Re: Bug#854414: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

Date: Mon, 6 Feb 2017 21:55:48 +0100

Control: tag -1 + moreinfo

Hi,

csights wrote:
> After upgrading from Jessie to Stretch, when I ssh to another computer and then try to use
> atop, nano, and others they fail to run with:
> Error opening terminal: screen.xterm-256color.
> 
> Running these programs locally within screen gives no problems

Is the package ncurses-term installed on both, local and remote system
or only on one of them?

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #17 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: 854414@bugs.debian.org

Subject: ncurses-term installed on both, but older version missing xterm-256color definition

Date: Thu, 23 Feb 2017 12:54:12 +0100

Hello Alexander.

ncurses-term is on both, but only on Stretch it contains the required terminal 
definition.

See below for a demonstration.

This also creates interoperability issues with for example CentOS 7.2.

root@admin:~# cat /etc/debian_version 
9.0
root@admin:~# echo $TERM
screen.xterm-256color

root@admin:~# ssh ns1
Debian GNU/Linux 8 (jessie)
Last login: Fri Feb 24 12:28:38 2017 from admin.demotuxdc.lab
root@ns1:~# echo $TERM
screen.xterm-256color
root@ns1:~# dpkg -l | grep ncurses-term
ii  ncurses-term                   5.9+20140913-1              all          
additional terminal type definitions
root@ns1:~# cd /etc
root@ns1:/etc# git diff
WARNING: terminal is not fully functional
root@ns1:/etc# N)
root@ns1:/etc# 
root@ns1:/etc# cd
root@ns1:~# dpkg -L ncurses-term | grep screen.xterm-256color
root@ns1:~# Abgemeldet
Connection to ns1 closed.

root@admin:~# dpkg -L ncurses-term | grep screen.xterm-256color
/usr/share/terminfo/s/screen.xterm-256color
root@admin:~# 

Thanks,
Martin

Message #22 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: 854414@bugs.debian.org

Subject: ncurses-term installed on both, but older version missing xterm-256color definition

Date: Mon, 13 Mar 2017 13:40:44 +0100

Any update on this one?

Thanks,
-- 
Martin

Message #27 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Chad William Seys <cwseys@physics.wisc.edu>

To: 854414@bugs.debian.org

Subject: Re: Bug#854414: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

Date: Mon, 19 Jun 2017 12:07:40 -0500

I've had this problem when sshing to Macintosh, so no Debian
ncurses-term there.

Chad.

Message #32 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: <854414@bugs.debian.org>

Cc: <control@bugs.debian.org>

Subject: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 22 Jun 2017 12:14:10 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 - moreinfo
thanks

Dear maintainer(s), dear Axel.

Removing moreinfo tag as I now provide more info than you ever wanted to know 
and as "moreinfo" tag still being set may have led to lack of maintainer 
feedback

I digged quite a bit deeper into the issue. 

My finding is that current Debian Stretch screen behaviour breaks SSH sessions 
to many other systems by adding "screen." to the terminal name in $TERM and by 
not using just "screen" as Debian Jessie´s screen did. See SLES 12 SP2 and 
CentOS 7 as two examples below.

Since this bug report is still quite sparse on maintainer feedback and adding 
"export TERM=xterm" or something like that to any affected system is quite 
tedious. I investigated adding

term xterm-256color

and later

term xterm

to "/etc/screenrc", but while this leads to given terminal being set in the 
screen session, this won´t work nicely either. It will lead to background 
color in YaST not being painted everywhere.

See attached screenshot "screen-term-xterm-256color.png". "no-screen-term-
xterm-256color.png" shows how YaST should look like instead. So it appears to 
me that screen indeed needs some special handling for colors, which seems to 
be activated by prepending using "screen.xterm-256color" instead of just 
"xterm-256color" in the current screen package in Stretch.

So I finally checked what terminal screen of Debian Jessie sets. And it is just 
"screen". So I tried:

term screen

in "/etc/screenrc", but this leads to "screen.xterm-256color". So there seems 
to be some automagic stuff in screen that adds the original terminal name if 
the terminal is set to "screen" and I am finally in the mode to just ditch 
"screen" and try with "tmux" and I am absolutely not in favor of software 
breaking perfectly fine working things by some automagic that I do not know how 
to disable.

But after trying my way through terminals "vt100" and "ansi" I finally found a 
work-around to this issue that appears to work:

term screen-256color

in "/etc/screenrc" appears to work nicely with both SLES 12 and CentOS 7.

I really suggest logging into this as this will likely break shell sessions in 
non-obvious ways for quite some users as they upgrade to Debian Stretch. Even 
if they just use Debian, cause Debian Jessie also doesn´t know 
"screen.xterm-256color".

So I really ask for the maintainers to step up and think about a solution to 
this issue and finally fix it.


demotuxdcproxy is Debian Stretch.

# With SLES12 SP 2, without screen

root@demotuxdcproxy:~# ssh root@ldap3
ldap3:~ # echo $TERM
xterm-256color

=> works perfectly

# With SLES12 SP 2, with screen

root@demotuxdcproxy:~# ssh root@ldap3
ldap3:~ # echo $TERM
screen.xterm-256color

ldap3:~ # LANG=C vim
E437: terminal capability "cm" required
Press ENTER or type command to continue

=> Completely broken, even backspace does not work, however it does not appear 
to be recognized as an unknown terminal, in "vim" even linefeeds are not 
displayed


# With CentOS 7.3.1611, without screen

root@demotuxdcproxy:~# ssh root@ldap2
[root@ldap2 ~]# echo $TERM
screen.xterm-256color

=> Works perfectly

# With CentOS 7.3.1611, with screen

[root@ldap2 ~]# echo $TERM
screen.xterm-256color

[root@ldap2 ~]# nmtui-edit
Unknown terminal: screen.xterm-256color
Check the TERM environment variable.
Also make sure that the terminal is defined in the terminfo database.
Alternatively, set the TERMCAP environment variable to the desired
termcap entry.

=> Unknown terminal definition.

Thanks,
-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerwald@teamix.de | web:  http://www.teamix.de | blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller, Jason Clark, Jakob Høholdt

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

[no-screen-term-xterm-256color.png (image/png, attachment)]

[screen-term-xterm-256color.png (image/png, attachment)]

Message #39 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: <854414@bugs.debian.org>

Subject: Re: Bug#854414: screen in Stretch/Sid sets TERM to value that doesn´t work in Debian 8, SLES 12, CentOS 7 for 256 color terminal emulators

Date: Thu, 22 Jun 2017 12:33:04 +0200

Martin Steigerwald - 22.06.17, 12:14:
> Dear maintainer(s), dear Axel.

Sorry, subject line was misleading. "xterm-256color" works perfectly, but only 
*without* screen. The terminal that works in both screen and my Konsole 
terminal windows appears to be "screen-256color" as I described.

[…]

> demotuxdcproxy is Debian Stretch.
> 
> # With SLES12 SP 2, without screen
> 
> root@demotuxdcproxy:~# ssh root@ldap3
> ldap3:~ # echo $TERM
> xterm-256color
> 
> => works perfectly
> 
> # With SLES12 SP 2, with screen
> 
> root@demotuxdcproxy:~# ssh root@ldap3
> ldap3:~ # echo $TERM
> screen.xterm-256color
> 
> ldap3:~ # LANG=C vim
> E437: terminal capability "cm" required
> Press ENTER or type command to continue
> 
> => Completely broken, even backspace does not work, however it does not
> appear to be recognized as an unknown terminal, in "vim" even linefeeds are
> not displayed

Same then opening a screen session in Debian Sid and SSHing to a Debian Jessie 
machine.

So currently screen in Stretch/Sid sets TERM to value that doesn´t work in 
Debian 8, SLES 12, CentOS 7. But it does so only with terminals that use 
"xterm-256color" instead of "xterm" as TERM. Which is at least Konsole from 
Plasma desktop. The terminal emulators of GNOME, Cinnamon, MATE, XFCE, LXDE or 
any other terminal emulators that support 256 colors may also be affected.

XTerm however sets terminal type to "xterm" which leads to terminal type 
"screen" in a screen session.

So at least the scope of the users that face this issue is limited.

So maybe screen should do the following with terminal type by default:

- "xterm" => "screen" as it does already.
- "xterm-256color" => "screen-256color" instead of "screen.xterm-256color"

Thanks,

-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerwald@teamix.de | web:  http://www.teamix.de | blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller, Jason Clark, Jakob Høholdt

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

Message #44 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Martin Steigerwald <martin.steigerwald@teamix.de>

Cc: 854414@bugs.debian.org, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 22 Jun 2017 16:03:50 +0200

[Message part 1 (text/plain, inline)]

Hi Martin,

Martin Steigerwald wrote:
> My finding is that current Debian Stretch screen behaviour breaks SSH sessions 
> to many other systems by adding "screen." to the terminal name in $TERM and by 
> not using just "screen" as Debian Jessie´s screen did. See SLES 12 SP2 and 
> CentOS 7 as two examples below.

Thanks for the details. Will check more details later as I haven't
looked at all of it yet.

But I at least found out what caused it and why I never ran into this
issue so far myself.

What caused it and how to mitigate it:

Not yet tested, but suspected to mitigate this is to uninstall
ncurses-term from the Stretch machine on which screen is running and
then exiting and starting the screen session again.

Because screen only prepends "screen." if it finds the according
termcap definitions locally. And that definition seems to having been
added to ncurses-term during the Stretch release cycle. From
/usr/share/doc/ncurses-term/changelog.gz:

| 20150627
|         [...]
|         + comment-out "screen.xterm" entry, and inherit screen.xterm-256color
|           from xterm-new (report by Richard Birkett) -TD

Oh, and this behaviour is not really a regression of screen in
Stretch. In contrary, screen has that feature/behaviour since version
3.0pl7. Citing from /usr/share/doc/screen/changelog.gz:

    309 Changes up to Screen 3.0 Patchlevel 7
    310 =====================================
    311 
    312 Better terminfo support: Screen now checks if a termcap/info
    313 entry which the name "screen.$TERM" does exist. Look in the
    314 "VIRTUAL TERMINAL" section of the manual for more details.

Unfortunately no date is given in that changelog, but since
https://ftp.gnu.org/gnu/screen/ shows 3.6.1 being from January 1995,
and the first screen release being from 1987, this feature must have
been added during the early 90s.

Another more narrowing hint gives screen's git history:

| commit 03ca1358baa788de6060511e924ad3733f087583
| Author: jnweiger <jnweiger>
| Date:   Fri Dec 16 16:01:32 2005 +0000
| 
|     historic version screen-3.1 Sep  9  1991
| 
| commit c9079740b6396769f5e4ed3d8f74e25c4cce6505
| Author: jnweiger <jnweiger>
| Date:   Fri Dec 16 15:54:39 2005 +0000
| 
|     historic version screen-2.3 Feb 25  1991

A "git grep -F '%s.%s'" confirms that this feature has been introduced
between these two commits, i.e. between Februar and September 1991,
i.e. approximately 26 years ago. (And this feature is even older than
Linux.)

What changed between Jessie and Stretch is that ncurses-term now also
includes termcap definitions for "screen.xterm-256color" (as shown
above) and since it's now available, screen now also uses that
definition, i.e. behaves as documented in the screen(1) man page:

| THE VIRTUAL TERMINAL
|        [...]
| 
|        When screen tries to figure out a terminal name for itself, it
|        first looks for an entry named "screen.<term>", where <term> is
|        the contents of your $TERM variable. If no such entry exists,
|        screen tries "screen" (or "screen-w" if the terminal is wide
|        (132 cols or more)). If even this entry cannot be found,
|        "vt100" is used as a substitute.

Given that this is ancient screen behaviour and the usual cause for
people arguing about this behaviour is that ncurses-term improves over
time, too, I'm currently thinking about tagging this as "wontfix".

Merging with #694178 also comes to my mind as this seems more or less
the same issue, just with a different set of new termcap definitions
having been added to ncurses-term between two other releases of
Debian.

The only programmatic fix I can imagine is to ask upstream to add a
switch to disable this ancient feature. Which feels kinda wrong, also
because there seems no related upstream bug report yet. But then
again, this behaviour is admittedly not undisputed, at least in
Debian, otherwise nobody would have written metapackages like
https://www.mirbsd.org/~tg/Debs/dists/etch/wtf/Pkgs/mirabilos-support/ncurses-term-considered-harmful_36_all.deb

Will decide how to proceed on this after having looked through all
details of your mail.

Ah, and FTR: Why I never ran into this myself:

I've added "term screen-256color-bce" to my .screenrc IIRC when xterm
got 256 colors support, but screen didn't detect it properly. And
never having removed that again (my fault, yes) hid the issue for me,
i.e. connecting to Jessie or Wheezy works fine that way. Not with
CentOS 7 though.

The other reason why I never ran into that (e.g. with CentOS 7, RHEL
5/6/7, OpenWRT, FreeWRT, etc.) is that I nearly never do SSH inside
screen but nearly always first use ssh and then start screen on the
remote machine. (I even have a shell alias for that.)

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

[signature.asc (application/pgp-signature, inline)]

Message #49 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Axel Beckert <abe@debian.org>

Cc: Martin Steigerwald <martin.steigerwald@teamix.de>, 854414@bugs.debian.org, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 10:16:53 +0200

On 2017-06-22 16:03 +0200, Axel Beckert wrote:

> Martin Steigerwald wrote:
>> My finding is that current Debian Stretch screen behaviour breaks SSH sessions 
>> to many other systems by adding "screen." to the terminal name in $TERM and by 
>> not using just "screen" as Debian Jessie´s screen did. See SLES 12 SP2 and 
>> CentOS 7 as two examples below.
>
> Thanks for the details. Will check more details later as I haven't
> looked at all of it yet.
>
> But I at least found out what caused it and why I never ran into this
> issue so far myself.
>
> What caused it and how to mitigate it:
>
> Not yet tested, but suspected to mitigate this is to uninstall
> ncurses-term from the Stretch machine on which screen is running and
> then exiting and starting the screen session again.

A less drastic measure is to change the TERM variable before running
screen, e.g. to xterm.

> Because screen only prepends "screen." if it finds the according
> termcap definitions locally. And that definition seems to having been
> added to ncurses-term during the Stretch release cycle. From
> /usr/share/doc/ncurses-term/changelog.gz:
>
> | 20150627
> |         [...]
> |         + comment-out "screen.xterm" entry, and inherit screen.xterm-256color
> |           from xterm-new (report by Richard Birkett) -TD

That's correct, systems running older ncurses versions lack that
terminal description.

> What changed between Jessie and Stretch is that ncurses-term now also
> includes termcap definitions for "screen.xterm-256color" (as shown
> above)

The other thing that changed is that libvte-2.91-0 now sets
TERM=xterm-256color[1], which means that many people will be affected
since {gnome,mate,xfce4}-terminal and a few other terminal emulators use
libvte-2.91-0.

If nothing else can be done about it, could the problem and a mitigation
(e.g. "run TERM=xterm screen if you run into it") at least be mentioned
in README.Debian?

> The only programmatic fix I can imagine is to ask upstream to add a
> switch to disable this ancient feature. Which feels kinda wrong, also
> because there seems no related upstream bug report yet.

There are, however, requests to make the -T switch and "term=screen"
in .screenrc work like that[2,3].

> Ah, and FTR: Why I never ran into this myself:
>
> I've added "term screen-256color-bce" to my .screenrc IIRC when xterm
> got 256 colors support, but screen didn't detect it properly. And
> never having removed that again (my fault, yes) hid the issue for me,
> i.e. connecting to Jessie or Wheezy works fine that way. Not with
> CentOS 7 though.

That's because CentOS 7 puts screen-256color-bce into the ncurses-term
package and the remote system did not have that package installed.  On
Debian, screen-256color-bce is in ncurses-base.  I suppose we could add
screen.xterm-256color there too, but that's only going to help in four
years or so when buster becomes oldstable and people start to migrate to
it from stretch-LTS, and in the meantime it breaks your workaround to
uninstall ncurses-term… :-/

> The other reason why I never ran into that (e.g. with CentOS 7, RHEL
> 5/6/7, OpenWRT, FreeWRT, etc.) is that I nearly never do SSH inside
> screen but nearly always first use ssh and then start screen on the
> remote machine. (I even have a shell alias for that.)

I agree that starting screen on the remote machine makes more sense -
provided that it is installed there in the first place.

Cheers,
       Sven


1. https://git.gnome.org/browse/vte/commit/?id=82a8b0697dd948fa488b5a51ee7391deb35d49be
2. https://savannah.gnu.org/bugs/?48848
3. https://bugzilla.redhat.com/show_bug.cgi?id=1357981

--
There are a numerous problems with $TERM per se. It's by design a legacy crap.
-- Egmont Koblinger

Message #54 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Sven Joachim <svenjoac@gmx.de>

Cc: Martin Steigerwald <martin.steigerwald@teamix.de>, 854414@bugs.debian.org, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 10:44:47 +0200

Control: tag -1 + confirmed

Hi Sven,

thanks again for taking the time to dig into this and providing even
more useful information!

Sven Joachim wrote:
> > Not yet tested, but suspected to mitigate this is to uninstall
> > ncurses-term from the Stretch machine on which screen is running and
> > then exiting and starting the screen session again.
> 
> A less drastic measure is to change the TERM variable before running
> screen, e.g. to xterm.

Good point. But that recommendation seems to depend a lot on what
"screen.something" is provided by ncurses-term.

Another suggestion which is probably worth documenting comes from
https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled
as non-working there: Using "term screen" inside .screenrc. At least
"term screen-256color-bce" worked for me so well that I never noticed
this issue.

> > What changed between Jessie and Stretch is that ncurses-term now also
> > includes termcap definitions for "screen.xterm-256color" (as shown
> > above)
> 
> The other thing that changed is that libvte-2.91-0 now sets
> TERM=xterm-256color[1], which means that many people will be affected
> since {gnome,mate,xfce4}-terminal and a few other terminal emulators use
> libvte-2.91-0.

I see.

> If nothing else can be done about it, could the problem and a mitigation
> (e.g. "run TERM=xterm screen if you run into it") at least be mentioned
> in README.Debian?

Yep, documenting it as a first step is also something which came to my
mind — now that we understand the issue much better.

> > The only programmatic fix I can imagine is to ask upstream to add a
> > switch to disable this ancient feature. Which feels kinda wrong, also
> > because there seems no related upstream bug report yet.
> 
> There are, however, requests to make the -T switch and "term=screen"
> in .screenrc work like that[2,3].
[…]
> 2. https://savannah.gnu.org/bugs/?48848
> 3. https://bugzilla.redhat.com/show_bug.cgi?id=1357981

Oh, [2] is nice find! Thanks!

> > Ah, and FTR: Why I never ran into this myself:
> >
> > I've added "term screen-256color-bce" to my .screenrc IIRC when xterm
> > got 256 colors support, but screen didn't detect it properly. And
> > never having removed that again (my fault, yes) hid the issue for me,
> > i.e. connecting to Jessie or Wheezy works fine that way. Not with
> > CentOS 7 though.
> 
> That's because CentOS 7 puts screen-256color-bce into the ncurses-term
> package and the remote system did not have that package installed.  On
> Debian, screen-256color-bce is in ncurses-base.  I suppose we could add
> screen.xterm-256color there too, but that's only going to help in four
> years or so when buster becomes oldstable and people start to migrate to
> it from stretch-LTS, and in the meantime it breaks your workaround to
> uninstall ncurses-term… :-/

Yeah, most recommendations depend a lot on the version respectively on
the exact term definitions included in ncurses-term. *sigh*

So my current plan is to document the issue in README.Debian with the
following suggestions as workaround, depending on the ncurses-term
versions installed locally and remote:

* Use "env TERM=xterm screen" (or similar).
* Use "term screen" inside .screenrc
* Uninstall ncurses-term locally or install ncurses-term on the remote
  machine.

Exact wording still needs to be determined. Suggestions welcome,
especially from users which ran into that issue and hence have a
better feeling what works in which case and what doesn't.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #61 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Axel Beckert <abe@debian.org>

Cc: 854414@bugs.debian.org, Martin Steigerwald <martin.steigerwald@teamix.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 11:07:09 +0200

On 2017-07-13 10:44 +0200, Axel Beckert wrote:

> Another suggestion which is probably worth documenting comes from
> https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled
> as non-working there: Using "term screen" inside .screenrc. At least
> "term screen-256color-bce" worked for me so well that I never noticed
> this issue.

I can confirm that "term screen" in ~/.screenrc does not help, screen
still sets $TERM to screen.xterm-256color then.

Cheers,
       Sven

Message #66 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: Sven Joachim <svenjoac@gmx.de>

Cc: Axel Beckert <abe@debian.org>, 854414@bugs.debian.org, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 11:20:31 +0200

[Message part 1 (text/plain, inline)]

Sven Joachim - 13.07.17, 10:16:
> On 2017-06-22 16:03 +0200, Axel Beckert wrote:
[…]
> > What caused it and how to mitigate it:
> > 
> > Not yet tested, but suspected to mitigate this is to uninstall
> > ncurses-term from the Stretch machine on which screen is running and
> > then exiting and starting the screen session again.
> 
> A less drastic measure is to change the TERM variable before running
> screen, e.g. to xterm.

Ideally I think screen would recognize that the remote machine doesn´t have 
the terminal description and try from fallback terminal (i.e. 
"screen-256color" which appears to work nice on all Debian 8, CentOS 7, SLES 
12). Like:

fallbackterm screen-256color screen

But that would be an upstream feature request and I am not sure whether it is 
reasonably possible to implement it. If so, I am willing to create one.

> > What changed between Jessie and Stretch is that ncurses-term now also
> > includes termcap definitions for "screen.xterm-256color" (as shown
> > above)
> 
> The other thing that changed is that libvte-2.91-0 now sets
> TERM=xterm-256color[1], which means that many people will be affected
> since {gnome,mate,xfce4}-terminal and a few other terminal emulators use
> libvte-2.91-0.

As written Konsole is also affected although on first sight on the dependencies 
it doesn´t appear to use libvte (I looked down to libkf5pty and libqt5core).

> If nothing else can be done about it, could the problem and a mitigation
> (e.g. "run TERM=xterm screen if you run into it") at least be mentioned
> in README.Debian?

I think that would be nice.

> > The only programmatic fix I can imagine is to ask upstream to add a
> > switch to disable this ancient feature. Which feels kinda wrong, also
> > because there seems no related upstream bug report yet.
> 
> There are, however, requests to make the -T switch and "term=screen"
> in .screenrc work like that[2,3].
> 
> > Ah, and FTR: Why I never ran into this myself:
> > 
> > I've added "term screen-256color-bce" to my .screenrc IIRC when xterm
> > got 256 colors support, but screen didn't detect it properly. And
> > never having removed that again (my fault, yes) hid the issue for me,
> > i.e. connecting to Jessie or Wheezy works fine that way. Not with
> > CentOS 7 though.
> 
> That's because CentOS 7 puts screen-256color-bce into the ncurses-term
> package and the remote system did not have that package installed.  On
> Debian, screen-256color-bce is in ncurses-base.  I suppose we could add

It appears that "screen-256color" without "-bce" just works fine on CentOS 7:

[root@centostest ~]# rpm -qa | grep ncurses
ncurses-base-5.9-13.20130511.el7.noarch
ncurses-libs-5.9-13.20130511.el7.x86_64
ncurses-5.9-13.20130511.el7.x86_64

[root@centostest ~]# rpm -ql ncurses-base | grep screen-256
/usr/share/terminfo/s/screen-256color

Thats why I currently have:

root@admin:~# grep "^term " /etc/screenrc
term screen-256color

This really works here,

The initscript mentioned in report¹ 

[root@centostest ~]# rpm -qf /etc/profile.d/256term.sh 
initscripts-9.49.37-1.el7_3.1.x86_64

is clearly opt-in:

# Set this variable in your local shell config (such as ~/.bashrc)
# if you want remote xterms connecting to this system, to be sent 256 colors.
# This must be set before reading global initialization such as /etc/bashrc.
#   SEND_256_COLORS_TO_REMOTE=1

And it even appears that it would do the *right* thing:

  case "$TERM" in
    'xterm') TERM=xterm-256color;;
    'screen') TERM=screen-256color;;
    'Eterm') TERM=Eterm-256color;;
  esac

Its just that screen there mangles both "screen" and "xterm256-color" into 
"screen.xterm-256color". Strangely it does for both while in the bug² Charles 
mentions that for him its does so only for "screen". On my admin VM this works 
cause ncurses-term package is installed.

Thus installing ncurses-term package on CentOS 7 as well, but no luck, it just 
doesn´t have "screen.xterm-256color"

[root@centostest ~]# rpm -ql ncurses-term | grep 256color    
/usr/share/terminfo/m/mlterm-256color
/usr/share/terminfo/m/mrxvt-256color
/usr/share/terminfo/n/nsterm-256color
/usr/share/terminfo/s/screen-256color-bce
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/x/xterm+256color

It does however have "screen256-color":

[root@centostest ~]# rpm -ql ncurses-base | grep 256color
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm-256color

I will comment on their bug report that CentOS 7 could *fix*" the issue by 
providing this terminal description.

Debian 9 package ncurses-term which has "screen.xterm-256color":

root@admin:~# dpkg -L ncurses-term | grep 256color
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/m/mlterm-256color
/usr/share/terminfo/m/mrxvt-256color
/usr/share/terminfo/n/nsterm-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/r/rxvt-unicode-256color
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/s/screen.konsole-256color
/usr/share/terminfo/s/screen.mlterm-256color
/usr/share/terminfo/s/screen.putty-256color
/usr/share/terminfo/s/screen.vte-256color
/usr/share/terminfo/s/screen.xterm-256color
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/t/tmux-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm+256color

SLES 12 does not seem to have a ncurses-term package at all, their terminal 
definitions seem to be in these two packages:

slestest:~ # rpm -ql terminfo-base | grep 256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/r/rxvt-unicode-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/x/xterm-256color

slestest:~ # rpm -ql terminfo | grep 256color
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/m/mlterm-256color
/usr/share/terminfo/m/mrxvt-256color
/usr/share/terminfo/n/nsterm-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/s/screen-256color-bce
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm+256color


So they *all* have "screen-256color" and I actually wonder why this isn´t 
used.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1357981
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1357981#c4

> > The other reason why I never ran into that (e.g. with CentOS 7, RHEL
> > 5/6/7, OpenWRT, FreeWRT, etc.) is that I nearly never do SSH inside
> > screen but nearly always first use ssh and then start screen on the
> > remote machine. (I even have a shell alias for that.)
> 
> I agree that starting screen on the remote machine makes more sense -
> provided that it is installed there in the first place.

While it is more secure to only ever start screens on target machines, using a 
central screen on an admin machine makes it possible to have sessions of 
several machines in one screen. So globally declarding what makes sense does 
not take different scenarious in account and implies that everyone should do 
it how – it in the opinion of some – makes the most sense.

Like this:

root@admin:~# cat screenrc-demotuxdc 
screen bash
title "A"
screen bash
title "A"
screen ssh root@demotuxdc
title "P"
screen ssh root@ns1
title "NS1"
screen ssh root@ldap1
title "L1"
screen ssh root@ldap2
[…]

Thanks,

[signature.asc (application/pgp-signature, inline)]

Message #71 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Sven Joachim <svenjoac@gmx.de>

Cc: 854414@bugs.debian.org, Martin Steigerwald <martin.steigerwald@teamix.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 11:30:31 +0200

Hi Sven,

Sven Joachim wrote:
> On 2017-07-13 10:44 +0200, Axel Beckert wrote:
> > Another suggestion which is probably worth documenting comes from
> > https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled
> > as non-working there: Using "term screen" inside .screenrc. At least
> > "term screen-256color-bce" worked for me so well that I never noticed
> > this issue.
> 
> I can confirm that "term screen" in ~/.screenrc does not help, screen
> still sets $TERM to screen.xterm-256color then.

Meh, indeed. But why?

I've digged through the code to try to figure out why "term screen"
does not work while "term screen-256color-bce" does work. But so far I
didn't find the reason.

Next step would be using debug output. But screen in Debian is compiled
without -DDEBUG due to #98839 from 2001. According to the man page,
these "debug on" only works if compiled with -DDEBUG, so I'll check if
that bug report still applies to current screen versions. I tough
don't have time to dig that deep today.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #76 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Martin Steigerwald <martin.steigerwald@teamix.de>

Cc: 854414@bugs.debian.org, Axel Beckert <abe@debian.org>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 11:41:35 +0200

Am 13.07.2017 um 11:20 schrieb Martin Steigerwald:

> Sven Joachim - 13.07.17, 10:16:
>> On 2017-06-22 16:03 +0200, Axel Beckert wrote:
> […]
>> > What caused it and how to mitigate it:
>> > 
>> > Not yet tested, but suspected to mitigate this is to uninstall
>> > ncurses-term from the Stretch machine on which screen is running and
>> > then exiting and starting the screen session again.
>> 
>> A less drastic measure is to change the TERM variable before running
>> screen, e.g. to xterm.
>
> Ideally I think screen would recognize that the remote machine doesn´t have 
> the terminal description and try from fallback terminal (i.e. 
> "screen-256color" which appears to work nice on all Debian 8, CentOS 7, SLES 
> 12). Like:
>
> fallbackterm screen-256color screen
>
> But that would be an upstream feature request and I am not sure whether it is 
> reasonably possible to implement it. If so, I am willing to create one.

It is not possible at all because screen cannot even notice that you're
intending to connect to a remote machine, much less read that machine's
terminal database.  Only programs on the remote machine can notice that
there's no terminal entry for your $TERM, and since they have no clue
what terminal emulator you use, they cannot provide a fallback either
(except "dumb" perhaps, which is not too useful).

Cheers,
       Sven

Message #81 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Axel Beckert <abe@debian.org>

Cc: 854414@bugs.debian.org, Martin Steigerwald <martin.steigerwald@teamix.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 11:58:02 +0200

On 2017-07-13 11:30 +0200, Axel Beckert wrote:

> Hi Sven,
>
> Sven Joachim wrote:
>> On 2017-07-13 10:44 +0200, Axel Beckert wrote:
>> > Another suggestion which is probably worth documenting comes from
>> > https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled
>> > as non-working there: Using "term screen" inside .screenrc. At least
>> > "term screen-256color-bce" worked for me so well that I never noticed
>> > this issue.
>> 
>> I can confirm that "term screen" in ~/.screenrc does not help, screen
>> still sets $TERM to screen.xterm-256color then.
>
> Meh, indeed. But why?
>
> I've digged through the code to try to figure out why "term screen"
> does not work while "term screen-256color-bce" does work. But so far I
> didn't find the reason.

There is no screen-256color-bce.xterm-256color terminfo entry, so
screen will not set $TERM to that value.  You can create one and test for
yourself:

$ mkdir -p ~/.terminfo/s
$ cp /lib/terminfo/s/screen-256color-bce ~/.terminfo/s/screen-256color-bce.xterm-256color

Cheers,
       Sven

Message #86 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: Axel Beckert <abe@debian.org>

Cc: Sven Joachim <svenjoac@gmx.de>, 854414@bugs.debian.org, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:08:36 +0200

[Message part 1 (text/plain, inline)]

Axel Beckert - 13.07.17, 10:44:
> Sven Joachim wrote:
> > > Not yet tested, but suspected to mitigate this is to uninstall
> > > ncurses-term from the Stretch machine on which screen is running and
> > > then exiting and starting the screen session again.
> > 
> > A less drastic measure is to change the TERM variable before running
> > screen, e.g. to xterm.
> 
> Good point. But that recommendation seems to depend a lot on what
> "screen.something" is provided by ncurses-term.

As written in my reply to Sven:

- CentOS 7, ncurses-base
- SLES 12, terminfo-base

both have "screen-256color". 

And Debian 8 has too:

mondschein:~> dpkg -L ncurses-base | grep 256color
/lib/terminfo/x/xterm-256color
/lib/terminfo/s/screen-256color-bce
/lib/terminfo/s/screen-256color

So "screen-256color" seems to be a sweet spot for me.

> Another suggestion which is probably worth documenting comes from
> https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled
> as non-working there: Using "term screen" inside .screenrc. At least
> "term screen-256color-bce" worked for me so well that I never noticed
> this issue.

Ok, I summarize what I see on Debian 9 screen 

- TERM=xterm-256color screen -T screen => screen.xterm-256color
- TERM=xterm screen -T screen => screen

- TERM=screen screen -T screen => screen
  (funny colors in screen status bar, due to due to how Konsole handles 
TERM="screen", can reproduce this locally, leaving this one out then)

And now take this:

- TERM=xterm-256color screen -T xterm => xterm (!!?!?!?!)
- ERM=xterm screen -T xterm => xterm


But then take this:
- TERM=xterm-256color screen -T screen-256color => screen-256color
- TERM=xterm screen -T screen-256color => screen-256color

And this:
- TERM=xterm-256color screen -T xterm-256color => xterm-256color
- TERM=xterm screen -T xterm-256color => xterm-256color


This is no joke: Now if you don´t call this crazy, I will.

So whether screen does something with TERM depends on *both* what TERM is set 
to *and* what "-T" or "term" in /etc/screenrc is set to. A pattern I gazered 
so far:

screen just seems to modify "-T screen", but only if it detects a 256 color 
mode. Lets try this assumption:

- TERM=screen-256color screen -T screen => screen

Let me add: But only if its not a "screen-256color" 256 color mode :)

But if you thought we would be finished here, take this:

-  TERM=vte-256color screen -T screen => screen.vte-256color

Yet:

- TERM=tmux-256color screen -T screen => screen

But:

- TERM=putty-256color screen -T screen  => screen.putty-256color

Still as I thought I found a pattern, take this:

- TERM=rxvt-256color screen -T screen => screen
- TERM=konsole-256color screen -T screen => screen.konsole-256color

(Konsole there doesn´t even appear to use this terminal definition!)

I think I still found a pattern:

root@admin:~# dpkg -L ncurses-term | grep "screen\..*-256color"
/usr/share/terminfo/s/screen.konsole-256color
/usr/share/terminfo/s/screen.mlterm-256color
/usr/share/terminfo/s/screen.putty-256color
/usr/share/terminfo/s/screen.vte-256color
/usr/share/terminfo/s/screen.xterm-256color

Screen will change "-T screen" / "term screen" to "screen.something-256color"… 
if, and *only* if on the *local* system a corresponding terminal definition 
does exist.

Two ideas:

1. Drop this behavior.

2. *Make this behavior work*. That is, again, reconsider that decision when 
logging in to remote system. If remote system doesn´t have 
"screen.something256-color" then use "screen-256color".

But even in second case, I´d at least allow to optionally disable that 
automagic "I surprise you funnily with mangling TERM" behavior.

> > If nothing else can be done about it, could the problem and a mitigation
> > (e.g. "run TERM=xterm screen if you run into it") at least be mentioned
> > in README.Debian?
> 
> Yep, documenting it as a first step is also something which came to my
> mind — now that we understand the issue much better.

From my experiments above, I´d say: screen-256color appears to be the best 
"term" option for screen at the moment.

[…]
> Yeah, most recommendations depend a lot on the version respectively on
> the exact term definitions included in ncurses-term. *sigh*
> 
> So my current plan is to document the issue in README.Debian with the
> following suggestions as workaround, depending on the ncurses-term
> versions installed locally and remote:
> 
> * Use "env TERM=xterm screen" (or similar).
> * Use "term screen" inside .screenrc
> * Uninstall ncurses-term locally or install ncurses-term on the remote
>   machine.

The third option won´t work. See my response to Sven where I listed the exact 
terminal definitions. ncurses-term on CentOS 7.3.1611 doesn´t contain 
"screen.xterm-256color" and SLES 12 doesn´t even have a ncurses-term package 
but also does not seem to have this term def in any of their terminfo 
packages.

> Exact wording still needs to be determined. Suggestions welcome,
> especially from users which ran into that issue and hence have a
> better feeling what works in which case and what doesn't.

I´d say:

1. Permanent work-around: "term screen-256color" in /etc/screenrc of the 
screen which accesses remote machines.

2. Temporary work-around: "screen -T screen-256color"

3. If "screen-256color" doesn´t work (unlikely with recent distributions) use 
"screen"

I end with a plea to terminal emulator and terminal definition developers:

*STOP* inventing new terminal definitions. *Now*.

(Inspired by Jordan Sissel´s, Logstash developer, "Don´t invent new time 
formats")

*Pretty please*.

Create one standard and ask all terminal developers to adopt it. Of course 
this will only help within about 10 years, but still. Konsole, Putty, GNOME 
Terminal, XFCE / MATE / LXDE (Qt), xterm terminals basically all displays 
chars on the screen… have one terminal definition for 256 colors for all of 
them :)

Thanks,

[signature.asc (application/pgp-signature, inline)]

Message #91 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: Axel Beckert <abe@debian.org>

Cc: Sven Joachim <svenjoac@gmx.de>, <854414@bugs.debian.org>, "Chad William Seys" <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:10:30 +0200

[Message part 1 (text/plain, inline)]

This message contains a digitally signed email which can be read by opening the attachment.
-- 
   

teamix GmbH
Südwestpark 43
90449 Nürnberg 

Tel.:  +49 911 30999 0 | Fax: +49 911 30999 99
mail: info@teamix.de | web:  http://www.teamix.de | blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller, Jason Clark, Jakob Høholdt

*** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

[Message part 2 (message/rfc822, inline)]

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: Axel Beckert <abe@debian.org>

Cc: Sven Joachim <svenjoac@gmx.de>, <854414@bugs.debian.org>, "Chad William Seys" <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:10:30 +0200

[Message part 3 (text/plain, inline)]

Axel Beckert - 13.07.17, 11:30:
> Hi Sven,
> 
> Sven Joachim wrote:
> > On 2017-07-13 10:44 +0200, Axel Beckert wrote:
> > > Another suggestion which is probably worth documenting comes from
> > > https://savannah.gnu.org/bugs/?48848#comment0 despite it seems labeled
> > > as non-working there: Using "term screen" inside .screenrc. At least
> > > "term screen-256color-bce" worked for me so well that I never noticed
> > > this issue.
> > 
> > I can confirm that "term screen" in ~/.screenrc does not help, screen
> > still sets $TERM to screen.xterm-256color then.
> 
> Meh, indeed. But why?
> 
> I've digged through the code to try to figure out why "term screen"
> does not work while "term screen-256color-bce" does work. But so far I
> didn't find the reason.

I can´t say anything about the code ATM, but I think I reverse engineered its 
behavior by testing. See the summary in my last mail.

Thanks,

[signature.asc (application/pgp-signature, inline)]

Message #96 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: Sven Joachim <svenjoac@gmx.de>

Cc: 854414@bugs.debian.org, Axel Beckert <abe@debian.org>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:29:52 +0200

[Message part 1 (text/plain, inline)]

Sven Joachim - 13.07.17, 11:41:
> > Ideally I think screen would recognize that the remote machine doesn´t
> > have  the terminal description and try from fallback terminal (i.e.
> > "screen-256color" which appears to work nice on all Debian 8, CentOS 7,
> > SLES  12). Like:
> > 
> > fallbackterm screen-256color screen
> > 
> > But that would be an upstream feature request and I am not sure whether it
> > is  reasonably possible to implement it. If so, I am willing to create
> > one.
> It is not possible at all because screen cannot even notice that you're
> intending to connect to a remote machine, much less read that machine's
> terminal database.  Only programs on the remote machine can notice that
> there's no terminal entry for your $TERM, and since they have no clue
> what terminal emulator you use, they cannot provide a fallback either
> (except "dumb" perhaps, which is not too useful).

Okay. Then I´d say say the best thing would be to recommend to use "term 
screen256-color" in /etc/screenrc until every distro out there has those 
"screen.something-256color" definitions.

I basically understand what screen upstream developers are trying to achieve 
here:

1. Screen seems to need a different terminal definition than for example xterm 
or Konsole. Unlike tmux, but see below.

2. Screen used "screen" for a long time.

3. To support 256 colors screen would need to use a different terminal 
definition.

4. Instead of just using "screen-256color" it tries to accomodate for special 
terminal emulator needs by trying whether "screen.something-256color" exists 
locally.

Now my question would be: Do current terminal emulators like xterm or Konsole 
really have special needs? My Konsole doesn´t even use "konsole-256color".

Okay, further testing ahead:

=== Konsole ===

- TERM="xterm-256color" aptitude => Ok
- TERM="konsole-256color" aptitude => Ok
- TERM="screen-256color" aptitude => Ok
- TERM="tmux-256color" aptitude => Ok

=== GNU screen ===

- TERM="xterm-256color" aptitude => Broken, background color missing in empty 
areas
- TERM="konsole-256color" aptitude => Broken, background color missing in 
empty areas
- TERM="screen-256color" aptitude => Ok
- TERM="tmux-256color" aptitude => Ok

=== tmux ===

- TERM="xterm-256color" aptitude => Ok
- TERM="konsole-256color" aptitude => Ok
- TERM="screen-256color" aptitude => Ok
- TERM="tmux-256color" aptitude => Ok

Can´t we just have *that* for screen as well?

BTW:

- TERM=screen tmux => screen
- TERM=screen-256color tmux => screen
- TERM=xterm-256color tmux => screen
- TERM=konsole-256-color tmux => screen

Option "-2" forces tmux to assume it has 256 colors. So lets see:

- TERM=screen tmux => screen
- TERM=screen-256color tmux => screen
- TERM=xterm-256color tmux => screen
- TERM=konsole-256-color tmux => screen

*Seriously* there *are* different oppinions there on how to handle these 
things.

=== xterm ===

- TERM="xterm-256color" aptitude => Ok
- TERM="konsole-256color" aptitude => Ok
- TERM="screen-256color" aptitude => Ok
- TERM="tmux-256color" aptitude => Ok


Conclusion:

Only screen seems to need special "screen" like terminal definitions. The 
others don´t care. Didn´t test any libvte pased terminal so far.


Can´t we just have all terminals have UTF-8 with 256 colors and get rid of 
these terminal definitions :). I have seen more about the behavior of terminal 
emulations than I ever wanted to know now.

Thanks,
Martin

[signature.asc (application/pgp-signature, inline)]

Message #101 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: 854414@bugs.debian.org

Cc: Axel Beckert <abe@debian.org>, Sven Joachim <svenjoac@gmx.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:41:58 +0200

[Message part 1 (text/plain, inline)]

Martin Steigerwald - 13.07.17, 12:08:
> As written in my reply to Sven:
> 
> - CentOS 7, ncurses-base
> - SLES 12, terminfo-base
> 
> both have "screen-256color". 
> 
> And Debian 8 has too:
> 
> mondschein:~> dpkg -L ncurses-base | grep 256color
> /lib/terminfo/x/xterm-256color
> /lib/terminfo/s/screen-256color-bce
> /lib/terminfo/s/screen-256color
> 
> So "screen-256color" seems to be a sweet spot for me.

According to Charles´ comment

https://bugzilla.redhat.com/show_bug.cgi?id=1357981#c3

Scientific Linux 6.7 has "screen-256color" as well. I bet this will hold true 
to CentOS 6.7 and RHEL 6.7 as well. CentOS 5.11 doesn´t have it, but 
seriously, thats pretty old.

Fedora 24 has it as well, plus the "screen.something-256color" definitions that 
Debian 9´s ncurses-term has as well.

Thanks,

[signature.asc (application/pgp-signature, inline)]

Message #106 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: <854414@bugs.debian.org>

Cc: Sven Joachim <svenjoac@gmx.de>, Axel Beckert <abe@debian.org>, "Chad William Seys" <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:50:40 +0200

[Message part 1 (text/plain, inline)]

This message contains a digitally signed email which can be read by opening the attachment.
-- 
   

teamix GmbH
Südwestpark 43
90449 Nürnberg 

Tel.:  +49 911 30999 0 | Fax: +49 911 30999 99
mail: info@teamix.de | web:  http://www.teamix.de | blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller, Jason Clark, Jakob Høholdt

*** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

[Message part 2 (message/rfc822, inline)]

From: Martin Steigerwald <martin.steigerwald@teamix.de>

To: <854414@bugs.debian.org>

Cc: Sven Joachim <svenjoac@gmx.de>, Axel Beckert <abe@debian.org>, "Chad William Seys" <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 13 Jul 2017 12:50:40 +0200

[Message part 3 (text/plain, inline)]

Martin Steigerwald - 13.07.17, 12:29:
> I basically understand what screen upstream developers are trying to
> achieve  here:
> 
> 1. Screen seems to need a different terminal definition than for example
> xterm  or Konsole. Unlike tmux, but see below.
> 
> 2. Screen used "screen" for a long time.
> 
> 3. To support 256 colors screen would need to use a different terminal 
> definition.
> 
> 4. Instead of just using "screen-256color" it tries to accomodate for
> special  terminal emulator needs by trying whether
> "screen.something-256color" exists locally.
> 
> Now my question would be: Do current terminal emulators like xterm or
> Konsole  really have special needs? My Konsole doesn´t even use
> "konsole-256color".
> 
> Okay, further testing ahead:
> 
> === Konsole ===
> 
> - TERM="xterm-256color" aptitude => Ok
> - TERM="konsole-256color" aptitude => Ok
> - TERM="screen-256color" aptitude => Ok
> - TERM="tmux-256color" aptitude => Ok
> 
> === GNU screen ===
> 
> - TERM="xterm-256color" aptitude => Broken, background color missing in
> empty  areas
> - TERM="konsole-256color" aptitude => Broken, background color missing in 
> empty areas
> - TERM="screen-256color" aptitude => Ok
> - TERM="tmux-256color" aptitude => Ok

[… tmux and xterm both okay with all four of them …]

- screen: TERM="xterm" aptitude => Broken, background color missing in empty  
areas

- tmux: : TERM="xterm" aptitude => Okay

(I think I don´t need to test xterm and Konsole with TERM="xterm" :)

I think my most prefered long-term fix would be this:

- screen just works okayish with all of these TERM settings
- screen drops the mangling of TERM completely.

I can create an upstream bug report in case it makes sense to you.

Thanks,
Martin

[signature.asc (application/pgp-signature, inline)]

Message #111 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 854414@bugs.debian.org

Cc: Martin Steigerwald <martin.steigerwald@teamix.de>, Sven Joachim <svenjoac@gmx.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Sun, 16 Jul 2017 23:26:46 +0200

Hi,

Axel Beckert wrote:
> So my current plan is to document the issue in README.Debian with the
> following suggestions as workaround, depending on the ncurses-term
> versions installed locally and remote:
> 
> * Use "env TERM=xterm screen" (or similar).
> * Use "term screen" inside .screenrc
> * Uninstall ncurses-term locally or install ncurses-term on the remote
>   machine.
> 
> Exact wording still needs to be determined. Suggestions welcome,
> especially from users which ran into that issue and hence have a
> better feeling what works in which case and what doesn't.

Based on the feedback on this mail, I've made a first try on
documenting ways out of that $TERM fiddling hell:

https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=5aa1cd4cbaf92e2d7570b102e9069d8898ca4807

Feedback is welcome!

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #116 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <martin@lichtvoll.de>

To: 854414@bugs.debian.org, Axel Beckert <abe@debian.org>

Cc: Martin Steigerwald <martin.steigerwald@teamix.de>, Sven Joachim <svenjoac@gmx.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 20 Jul 2017 21:25:43 +0200

[Message part 1 (text/plain, inline)]

Axel Beckert - 16.07.17, 23:26:
> Hi,
> 
> Axel Beckert wrote:
> > So my current plan is to document the issue in README.Debian with the
> > following suggestions as workaround, depending on the ncurses-term
> > versions installed locally and remote:
> > 
> > * Use "env TERM=xterm screen" (or similar).
> > * Use "term screen" inside .screenrc
> > * Uninstall ncurses-term locally or install ncurses-term on the remote
> > 
> >   machine.
> > 
> > Exact wording still needs to be determined. Suggestions welcome,
> > especially from users which ran into that issue and hence have a
> > better feeling what works in which case and what doesn't.
> 
> Based on the feedback on this mail, I've made a first try on
> documenting ways out of that $TERM fiddling hell:
> 
> https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=5aa1cd4cb
> af92e2d7570b102e9069d8898ca4807

Quoting in mail:

> diff --git a/debian/README.Debian b/debian/README.Debian
> index 1797fc4..6d4479c 100644
> --- a/debian/README.Debian
> +++ b/debian/README.Debian
[…]
> +Q: When I'm using ssh from inside screen, I get the error message
> +   "Error opening terminal: screen.xterm-256color." or similar.
> +
> +A: The TERM variable inside a screen session (which is then passed to
> +   the remote shell by ssh) depends on two things:
> +
> +   1. Availability of of specific termcap entries locally.
> +   2. Value of the TERM variable when the session was started.
> +
> +   To avoid this error message, the best way is to start a new screen
> +   session under a different circumstances, but there are also ways

=> "under different circumstances"

I am not sure whether I´d understand this as "under different circumstances" 
is quite unspecific. I´d think I´d rather write "with different terminal 
configuration"

> +   without starting a new sessions. You have several options:
> +
> +   Without starting a new screen session:
> +
> +   * Start ssh with "env TERM=screen-256color ssh".
> +
> +   * Install ncurses-term on  the remote machine and then  start a new
> +     ssh session. (Might help, depending on the remote distribution.)
> +
> +   Exiting the current screen session, change one of the following and
> +   start a new screen session:
> +
> +   * Add "term screen-256color" to ~/.screenrc or /etc/screenrc on
> +     your local machine.
> +
> +   * Start the new screen session with "env TERM=xterm screen".
> +
> +   * Start the new screen session with "screen -T screen-256color".
> +
> +   * Uninstall ncurses-term locally and then start a new screen
> +     session. (Might help, depending on the remote distribution.)

Whoa, I wondered whether to give this many options, but… I think its okay :) 
as you added the options that IMHO works best at the beginning of the lists.

> +   If "screen-256color" is not available on the remote distribution
> +   either, especially if it's not a recent release, try just "screen"
> +   instead of "screen-256color".

You might want to add a link to the bug report in README.Debian. I know you 
added a hint to it into the Changelog, but I think I´d add it here as well for 
people who want to know the background behind all of this.

Thanks,
-- 
Martin

[signature.asc (application/pgp-signature, inline)]

Message #121 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Martin Steigerwald <martin@lichtvoll.de>, 854414@bugs.debian.org

Cc: Sven Joachim <svenjoac@gmx.de>, Chad William Seys <cwseys@physics.wisc.edu>

Subject: Re: Bug#854414: screen uses "screen.xterm-256color" without screen I get "xterm-256color" which works

Date: Thu, 20 Jul 2017 23:57:01 +0200

Hi Martin,

Martin Steigerwald wrote:
> > +   To avoid this error message, the best way is to start a new screen
> > +   session under a different circumstances, but there are also ways
> 
> => "under different circumstances"

Good catch!

> I am not sure whether I´d understand this as "under different circumstances" 
> is quite unspecific.

Hrm. It's very general on purpose as the different circumstances are
listed only afterwards.

> I´d think I´d rather write "with different terminal 
> configuration"

I think I had "a different environent" in mind when I wrote that "a".

I went with ""with different terminal settings" for now the "terminal
configuration" feels misleading to me.

> Whoa, I wondered whether to give this many options, but… I think its okay :) 
> as you added the options that IMHO works best at the beginning of the lists.

I prefer choice. :-)

> You might want to add a link to the bug report in README.Debian.

Thanks! That's a good idea! Done and pushed to the git repository.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #126 received at 854414@bugs.debian.org (full text, mbox, reply):

From: Egmont Koblinger <egmont@gmail.com>

To: 854414@bugs.debian.org

Subject: Re: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."

Date: Tue, 24 Oct 2017 23:08:34 +0200

[Message part 1 (text/plain, inline)]

Hi guys,

Quickly glazing through the thread, a couple of remarks:

- screen/tmux indeed needs that TERM inside them is something
screen-related. Forget xterm or xterm-256color, go with screen,
screen-256color or screen.xterm-256color or alike. This is properly
documented in their docs/faqs and answered on hundreds of random forums
(whereas, of course, the opposite is also answered on random forums, you
should use common sense which answers to trust :)) The most notable
difference is the lack of "bce" causing colored lines (e.g. in midnight
commander) not to fill the entire line, but there are other differences as
well.

- The most standard setup according to my experiences is that TERM=xterm of
the graphical terminal emulator (8/16 colors) translates into TERM=screen
inside (also 8/16 colors), whereas TERM=xterm-256color of the external
emulator ideally translates into TERM=screen-256color. I haven't heard of
any problems with this approach. (Well, strictly speaking you're still in
trouble if you launch screen from a 256-color emulator, detach and then
re-attach from an 8/16-color one.)

- Then ncurses added screen.xterm-256color, which, according to screen's
old-time behavior of prepending "screen." if such a definition is
available, messed up ssh'ing and friends. Of course given screen's
behavior, there's no way such a change could've been introduced without
such breakages.

- I don't understand why you're reluctant moving screen.xterm and
screen.xterm-256color from ncurses-term into ncurses-base. Of course it
wouldn't fix a thing now, but it's not clear to me what it'd break, and
it's desired to make screen.xterm{,-256color} widely available in the long
run. Please do it as soon as possible.

- On my machine (Ubuntu Artful) screen-256color and screen.xterm-256color
are not exactly the same file. We should investigate what's the difference
and why, and which one's the better to have.

- 256 colors became pretty standard perhaps like 5-7 years ago. Since then,
some of us put noticeable effort into pushing even further and have
truecolor support here and there (with less limited success than 256
colors, but it's already available at many places). Please, pretty please
don't make a step backwards and don't advocate solutions/workaround that
reduce the available colors to 8/16. Please don't recommend TERM=xterm or
TERM=screen as a workaround where the underlying terminal is known to
support 256 colors.

- A proper workaround might be to set screen-256color from screenrc, or
translate TERM=screen.xterm-256color into TERM=screen-256color in
/etc/bashrc.

- I've never seen anyone quoting from me; Sven, I'm happy to see you did :)
I can't remember where I wrote those exact words, but I've sure written
something analogous at multiple places. One day I might write a standalone
page summarizing all the issues and outlining a recommendation for
something better.

cheers,
egmon

[Message part 2 (text/html, inline)]

Message #131 received at 854414-close@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 854414-close@bugs.debian.org

Subject: Bug#854414: fixed in screen 4.6.1-2

Date: Wed, 25 Oct 2017 06:34:07 +0000

Source: screen
Source-Version: 4.6.1-2

We believe that the bug you reported is fixed in the latest version of
screen, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 854414@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Axel Beckert <abe@debian.org> (supplier of updated screen package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 25 Oct 2017 08:08:11 +0200
Source: screen
Binary: screen screen-udeb
Architecture: source amd64
Version: 4.6.1-2
Distribution: unstable
Urgency: medium
Maintainer: Axel Beckert <abe@debian.org>
Changed-By: Axel Beckert <abe@debian.org>
Description:
 screen     - terminal multiplexer with VT100/ANSI terminal emulation
 screen-udeb - terminal multiplexer with VT100/ANSI terminal emulation - udeb (udeb)
Closes: 854414
Changes:
 screen (4.6.1-2) unstable; urgency=medium
 .
   * Document possible solutions for issues where ssh sessions from inside
     screen do not work properly due to missing terminal definitions on the
     remote machine. (Closes: #854414, LP: #1726826)
   * Declare compliance with Debian Policy 4.1.1.
     + Drop no more needed "Priority: extra" header from screen-udeb.
   * Fix duplicate word in README.Debian. Thanks Lintian!
   * Drop no more needed "Testsuite: autopkgtest" header.
   * debian/upstream/metadate: Use HTTPS for git.savannah.gnu.org URLs.
   * debian/patches/52fix_screen_utf8_nfd.patch: Use HTTPS URL for Origin.
Checksums-Sha1:
 a9229707a309d460ce73a3665460fbd3008c2cad 2128 screen_4.6.1-2.dsc
 0357cab6e9f39943153fa0e7609f41dc0b77f4c6 45820 screen_4.6.1-2.debian.tar.xz
 e2b299265f1ac8d7173a80dfa151974477f2d6a7 458728 screen-dbgsym_4.6.1-2_amd64.deb
 5bd71f02fefc72288e5d3804e3bc2ddc2249cbb0 380788 screen-udeb_4.6.1-2_amd64.udeb
 06d40c000dcaddb602e131b31ed176d78530111d 6227 screen_4.6.1-2_amd64.buildinfo
 30c466c1c3e5a6323071a46204ac7b699fab5971 585956 screen_4.6.1-2_amd64.deb
Checksums-Sha256:
 1802ce62153db92874408029f7bb6f4d05f52d0e36a0c15fd97ff3abcf8b3d7a 2128 screen_4.6.1-2.dsc
 a094459b1f512d58cd1737a36eed434f19f59dabbe9bf6f3cdd0615c4e0d9b4f 45820 screen_4.6.1-2.debian.tar.xz
 12799109404c0a7a4c664e155284871dcfffaddf606899f8fc5beb424fd494ec 458728 screen-dbgsym_4.6.1-2_amd64.deb
 2e5fa21e79bfea5344dff421355d930512eb547a6fad8d890fce1449ced7230f 380788 screen-udeb_4.6.1-2_amd64.udeb
 ec95a54eafc61f96ba558d98dda97e2726abfbcdf7c7bbcb6800eed7f3410b30 6227 screen_4.6.1-2_amd64.buildinfo
 1576c5182ecb7d3e6db6235d4f66ad5a6241f2bd9c0aa808de9b0841a7533486 585956 screen_4.6.1-2_amd64.deb
Files:
 c11dd1464a617ea5dc5101eb769f1863 2128 misc standard screen_4.6.1-2.dsc
 9570b7fa26e202c322f34198bf549053 45820 misc standard screen_4.6.1-2.debian.tar.xz
 fcb9de2ab85f8716516eb545bbe47aac 458728 debug optional screen-dbgsym_4.6.1-2_amd64.deb
 0925b7ed36663d10735f13335c2e5f57 380788 debian-installer standard screen-udeb_4.6.1-2_amd64.udeb
 1e566941ffd54d413edb1e39e5557b4f 6227 misc standard screen_4.6.1-2_amd64.buildinfo
 c34cf5902d5f94082785bbe620c1b38a 585956 misc standard screen_4.6.1-2_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEERoyJeTtCmBnp12Ema+Zjx1o1yXUFAlnwK3sACgkQa+Zjx1o1
yXVQ0hAAsDVLZSQh/8SQAdg1k8z02H+8C+1MujrvUlo8YqVYkV6H90cYiQ84+9VB
SJbaUVANvF/YL7C4nomuaDxCyvTseUBRBqYH8Ih1+fuN9CEDljTTLmvB/5BZY8Hx
xBbwDOBTbxHMb9jR4qr1JVCMeTFGbPj+5I0XigEa95VRNE065PRfGGGt/j5rdcBm
WQwQj/XRAmNnB6zJPzzeHg/Vmc8WvYbvkI1wtW6anqIz0FR7LzPAOUH/7RW07FGl
TGd0jgpyQKjIidpIieblvFLJlN+RBAslkMbRVIMgsAw2QMGUOyme1e5lbK0IUNa2
cBb81Ctq7i6WivvdCF1OxR3SMVGKgwNVmcBOERk0ROYTLKDeONG8si50Q5kMJTOT
R/FdLkuhjQ7ocXbAXUbHkvclQ6RPtCuQK+3UxpwGxmZ4pL7ERSYOqNUKE1cNn1Du
+VEUPk3QdFb1TsKEnhbbpfkfHETH+Go35Sw2LvK46X3NMKLo/zCrvnMx5jHP7MI3
PE9hgJLAbdFPmCT1t4cr+2bsyDX0tr4Vy1iNuEFr0tffWsyYbDOuzPUiy+LjbdGA
cjNLdIsRNCMm+K82Dil0JXINzVcrjapnpmpF3IRE7DD7JhrYqK+d7EKZu4BMEWZX
GpYlwNGQF8LQx/6/yXP5YKdsldj/eKVWKe+JoTOYHehOud9tNwE=
=lZ13
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.