Package: libc6 Version: 2.19-5 Severity: minor I don't know if libc6 is where the actual problem lies, but I don't experience this bug with any other package; so I'll start here. If the actual problem lies with some other package, feel free to reassign this bug report to the guilty package once you have figured out where the actual problem lies.
The Debian system uses a UTF-8 locale (en_US.UTF-8). The system administrator (root) is logged in to the system via a remote SSH client. In this case, the client is PuTTY, a very popular open source SSH client for Windows. (Ports are available to other platforms, but that's beside the point.) PuTTY is configured as recommended for use with a Debian system which uses a UTF-8 locale. (See https://lists.debian.org/debian-user/2014/07/msg00592.html for details.) As pointed out in the above link, PuTTY does not support the ISO-2022 escape sequences traditionally used to draw lines and boxes when operating in UTF-8 mode. (See also http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html for the official word on this.) The problem occurs when libc6 must be upgraded during "apt-get upgrade" or "apt-get dist-upgrade". I see a screen which looks like this: ----- lqqqqqqqqqqqqqqqqqqqqqqqqu Configuring libc6:s390x tqqqqqqqqqqqqqqqqqqqqqqqqk x Running services and programs that are using NSS need to be restarted, x x otherwise they might not be able to do lookup or authentication any more x x (for services such as ssh, this can affect your ability to login). x x Please review the following space-separated list of init.d scripts for x x services to be restarted now, and correct it if needed. x x x x Note: restarting sshd/telnetd should not affect any existing x x connections. x x x x Services to restart for GNU libc library upgrade: x x x x vsftpd exim4 cron atd____________________________________________________ x x x x <Ok> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj ----- As you can see, PuTTY was sent the traditional ISO-2022 box-drawing escape sequences to draw the box, which does not work when PuTTY is operating in UTF-8 mode. These need to be converted into equivalent UTF-8 sequences to look right. I wish to emphasize that libc6 is the *only* package which does this. Every other package which displays a screen like this is smart enough to send the proper UTF-8 sequences to draw the box. For example, on a recent upgrade of libssl1.0.0 I got this: ----- ┌─────────────────────┤ Configuring libssl1.0.0:s390x ├─────────────────────┐ │ This release of OpenSSL fixes some security issues. Services will not │ │ use these fixes until they are restarted. Please note that restarting │ │ the SSH server (sshd) should not affect any existing connections. │ │ │ │ Please check the list of detected services that need to be restarted and │ │ correct it, if needed. The services names must be identical to the │ │ initialization script names in /etc/init.d and separated by spaces. No │ │ services will be restarted if the list is empty. │ │ │ │ Any service that later fails unexpectedly after this upgrade should be │ │ restarted. It is recommended to reboot this host to avoid any │ │ SSL-related trouble. │ │ │ │ Services to restart to make them use the new libraries: │ │ │ │ vsftpd ssh exim4_________________________________________________________ │ │ │ │ <Ok> │ │ │ └───────────────────────────────────────────────────────────────────────────┘ ----- If the bug is not in package libc6, then why is libc6 the *only* package which doesn't use the proper box-drawing technique? Note that when using a terminal which *does* support ISO-2022 escape sequences in UTF-8 mode, such as the Linux console or xterm, the box looks fine. It's only when using a terminal which does *not* support ISO-2022 escape sequences in UTF-8 mode that we have a problem. Personally, I believe that supporting ISO-2022 escape sequences in UTF-8 mode represents a standards violation (see http://www.cl.cam.ac.uk/~mgk25/unicode.html#term). But that's beside the point. The point is that PuTTY does *not* support ISO-2022 escape sequences in UTF-8 mode, and due to the terminal type definition of xterm-utf8, ncurses knows this. Yet it is being sent untranslated ISO-2022 escape sequences somehow. But only when upgrading package libc6. Not when upgrading any other package. Very strange. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/504656925.4452.1405200626016.javamail.r...@md01.wow.synacor.com