Adding debian version 4.6.2-3+deb10u1.debian/4.6.2-3+deb10u1debian

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 182 insertions, 0 deletions

diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 0000000..ffd8b65
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,182 @@
+Screen Information
+==================
+
+See the copyright file for information about where to get screen,
+licensing, and other assorted information.
+
+
+Debian Modifications
+--------------------
+  * added Debian package maintenance files
+  * Use /run/screen as socket directory
+  * udeb only: Use setgid "utmp" instead of setuid root or
+    libutempter.
+
+
+Debian Screen Q&A
+-----------------
+
+Q: screen always complains about the permissions of /run/screen.
+   What's wrong?
+
+A: Simplified, the binary ensures that $SCREENDIR has just enough
+   permission bits enabled so that each user can create and access his
+   socket directory.  This means:
+
+   /usr/bin/screen setuid root -> /run/screen 0755
+   /usr/bin/screen setgid utmp -> /run/screen 0775
+   /usr/bin/screen without setid bits -> /run/screen 0777
+
+   These cases are all handled by the init script or by the tmpfiles.d
+   configuration documented later in this file. However, the actual
+   test is a bit more complicated. And as the variable names are all
+   quite self-explanatory, just have a look at the C code itself:
+
+]   n = (eff_uid == 0 && (real_uid || (st.st_mode & 0775) != 0775)) ? 0755 :
+]       (eff_gid == (int)st.st_gid && eff_gid != real_gid) ? 0775 :
+]       0777;
+]   if (((int)st.st_mode & 0777) != n)
+]     Panic(0, "Directory '%s' must have mode %03o.", SockDir, n);
+
+   If the invoking user has primary group utmp, the above assumption
+   will fail.  The same holds if the underlying file system is mounted
+   'nosuid'. In these cases you have to adapt the init script or
+   tmpfiles.d configuration yourself.
+
+
+Q: shift+page up in xterm/gnome-terminal/konsole used to let me scroll
+   back a bit, but now it doesn't. How can I make it work with
+   scrollback?
+
+A: It doesn't scrollback consistently because screen (the program)
+   displays in xterm's alternate screen buffer.
+
+   To have screen use xterm's normal screen buffer (which includes
+   scrollback), you can add the following to your .screenrc:
+
+   termcapinfo xterm|xterms|xs|rxvt ti@:te@
+
+
+Q: Screen sets my xterm titlebar. I don't like this, how do I make it
+   stop?
+
+A: The titlebar setting is set in the /etc/screenrc by telling screen
+   that some of the GUI terminals have a hardstatus line and that it
+   can be set by sending the xterm escape sequences that set the
+   title/icon.
+
+   # Set the hardstatus prop on gui terms to set the titlebar/icon title
+   termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007
+
+   You can override this on a system wide basis by commenting out this
+   line in the /etc/screenrc or you can override it in your personal
+   screenrc by adding the following line:
+
+   hardstatus alwaysmessage
+
+
+Q: Why do I get #!$@#$@!% trailing spaces when I cut and paste from
+   mutt running within screen?
+Q: Why does the statusbar in my irc client extend to the end of the
+   screen in xterm but not in screen?
+
+A: This has to do with handling of the bce terminal attribute, or lack
+   thereof by default in screen. You can enable bce on a per-user
+   basis by adding the following to your .screenrc:
+
+   defbce on
+   term screen-bce
+
+   NOTE: if you do this your TERM will be screen-bce. When you login
+         to other machines they may not have a screen-bce terminal
+         type, so you will see errors. To fix this you must put the
+         terminfo for screen-bce on that remote machine. The screen
+         terminfo is found in
+         /usr/share/doc/screen/terminfo/screeninfo.src and you can
+         compile it on the remote machine using tic(1).
+
+
+Q: Screen doesn't notice when I resize the term - what's wrong?
+
+A: Firstly look for the same question in FAQ.gz. If the problem
+   persists: There have been reports of sshd instances blocking
+   SIGWINCH (presumably restarted from aptitude and thus inheriting
+   its signal mask) which therefore also prohibit remote screen
+   sessions from ever seeing the signal. Have a look at the old
+   bugreport <https://bugs.debian.org/392302> for means to determine
+   whether you are affected. (You might have to restart sshd with a
+   crontab entry or similar magic if ssh is your only way to access
+   the box.)
+
+
+Q: Multiuser mode is not working - how can I enable it?
+
+A: Screen has to be setuid root to accomplish this. (Note the security
+   implications this has! See e.g. https://bugs.debian.org/852484 for
+   a bug which becomes a root exploit with this. Also bear in mind
+   that setuid programs remove some variables from their environment
+   for exactly this reason - see ld.so(1).) If you still want to
+   enable the feature, you may do so with the following commands:
+
+] dpkg-statoverride --update --add root root 4755 /usr/bin/screen
+] chmod 0755 /run/screen
+] echo 'd /run/screen 0755 root utmp' > /etc/tmpfiles.d/screen-cleanup.conf
+
+   dpkg-statoverride will make sure that the modified permissions
+   remain in effect even if a new version of the screen package is
+   installed. /run/screen will be automatically recreated with the
+   proper permissions if the directory lives on volatile storage
+   (doesn't persist between subsequent reboots).
+
+
+Q: I've configured screen with different permissions, but I want to go
+   back to the default setgid configuration - how can I do that?
+
+A:
+
+] dpkg-statoverride --remove /usr/bin/screen
+] chmod 1777 /run/screen
+] rm /etc/tmpfiles.d/screen-cleanup.conf
+
+
+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 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 different terminal settings, but there are also ways
+   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.)
+
+   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".
+
+   See https://bugs.debian.org/854414 for a thorough discussion on
+   this topic.
+
+ -- Axel Beckert <abe@debian.org>, Thu, 20 Jul 2017 23:54:05 +0200