[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#677303: [RFR] templates://screen/{templates}



Hi,

Justin B Rye wrote:
> > -_Description: Previous screen binary has been copied to /tmp/screen-4.0.3
> > +_Description: Warning: upgrading screen with an active session

I dislike this version as it reads as this is something which is
generally the case (which it is not). I though like the idea of the
word "Warning" in it.

My suggestion: "Warning: upgrading to screen 4.1.0 with an active 4.0.3 session"

> >   GNU Screen 4.1.0 currently can't speak with GNU Screen sessions
> >   started by GNU Screen 4.0.3.
> 
> Drop "currently", unless we really expect stable-update versions of
> Screen 4.1.0 to be backward-compatible.

That's what I expect, yes, and for what I hoped will happen before the
freeze so I don't have to bother with debconf based workarounds like
this.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788#232 or
https://lists.gnu.org/archive/html/screen-devel/2012-02/msg00004.html

> s/speak/communicate/

Good idea.

> If they're sessions started by Screen, they're obviously Screen
> sessions, and we don't need all this GNU branding.

Granted. On the website they just say "Screen" in floating text, too:
http://www.gnu.org/software/screen/

>     GNU Screen 4.1.0 can't communicate with sessions started by Screen 4.0.3.

Looks fine.

>     There seems to be at least one GNU Screen session running on this system;
>     possibly the one you are running this upgrade in. However, GNU Screen 4.1.0
>     can't communicate with sessions started by Screen 4.0.3.
[...]
>     To reconnect to a running GNU Screen session after the new version has been
>     unpacked, you'll need to call the old screen binary instead of the new one,
>     so a copy has been made which can be invoked as "/tmp/screen-4.0.3 -rd".
[...]
>     If your /tmp/ is a separate mount point mounted with the nosuid or noexec
>     options, you may need to copy it to somewhere else (such as /root) before
>     calling it. Its permissions should be 2755 (-rwxr-sr-x) and it should
>     belong to the user root and group utmp.

Fine for me, thanks!

> >  To be able to reconnect to your running GNU Screen session after the
> >  new screen package has been unpacked, you'll need to call the old
> >  screen binary instead of the new one. For that purpose, it has been
> >  tried to copy the old screen binary to /tmp/screen-4.0.3, but
> >  unfortunately this failed.
> 
> "It has been tried to copy" doesn't work.  Why not just:
> 
>    To reconnect to a running GNU Screen session after the new version has been
>    unpacked, you'll need to call the old screen binary instead of the new one.
>    However, the attempt to copy it to /tmp/screen-4.0.3 has failed.
> 
> (Last minute thought: does the second error message ever appear
> without being preceded by the first one?)

Shouldn't. Both, config and preinst have the following code snippet:

      if cp -pnT /usr/bin/screen /tmp/screen-4.0.3 ; then
          echo Copied /usr/bin/screen to /tmp/screen-4.0.3
          db_input high screen/410-upgrade || true
          db_go || true
      else
          echo Copying /usr/bin/screen to /tmp/screen-4.0.3 failed
          db_input high screen/403-copy-failed || true
          db_go || true
      fi

But another thought: I posted a workaround for the worst case (dpkg
stuck inside unreachable screen, i.e. you can't run dpkg -i
screen_4.0.3*deb outside the screen and you don't want to kill it) at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677227#5 -- would it
make sense to include this URL somehow? Or the workaround itself?

> Moving on to the control file: okay, this is a good package
> description already, so none of the following is more than wishlist. 
> 
> > Description: terminal multiplexor with VT100/ANSI terminal emulation
>                                  ^
> Google says "Did you mean: multiplexer?"

I wondered about that, too, but suspect it's because it's
"multiplexer" in my mother tongue (German), too.

> >  screen is a terminal multiplexor that runs several separate "screens" on a
>    ^                             ^
> s/screen/GNU Screen/ - an appropriate place for branding, given that
> it also saves us from initial lowercase.

Granted.

> >  single physical character-based terminal.  Each virtual terminal emulates a
> >  DEC VT100 plus several ANSI X3.64 and ISO 2022 functions.  Screen sessions
> >  can be detached and resumed later on a different terminal.
> 
> (While I'm here I'm imposing d-l-e "house style" single-spacing.)

I thought double spacing is common for English (but not for German AFAIK).

> >  Screen also supports a whole slew of other features.  Some of these are:
> 
> Just say "including".

*nod* Do I get a final summary for this, too, or shall change that now
already? :-)

> >  configurable input and output translation, serial port support, configurable
> >  logging, multi-user support, and utf8 charset support.
> 
> Failing to support UTF-8 by default has been a bug since at least
> Lenny, so drop that one.

Huh? Works fine for me, I do write all my private mails inside Screen
including German with umlauts. Just wide-character support (e.g.
Japanese and Chinese) seems to be incomplete. Or do you mean automatic
character set detection? (And no, I don't know all screen bug reports
by mind. :-)

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


Reply to: