Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
On Tue, Jul 24, 2012 at 21:17:04 +0200, Julien Cristau wrote:
Did this stuff ever get fixed? screen's NEWS.Debian suggests it isn't,
which I find rather annoying. Said NEWS file also recommends
downloading and running code from a random web server as root, which
really doesn't seem appropriate, even in the context of this bug. If
this is indeed the state of screen in wheezy I'm thinking it'd be better
to go back to the previous (pre-compatibility-break) version.
I'm unimpressed. Seems like working around this in screen itself is way
simpler than the horrible kludge in the current maintainer scripts. The
following patch, while not all that pretty, seems to allow me to attach
to a screen started with either the squeeze or sid version. I'm sure
there's corner cases, but.
Cheers,
Julien
Index: screen-4.1.0~20120320gitdb59704/screen.h
===
--- screen-4.1.0~20120320gitdb59704.orig/screen.h
+++ screen-4.1.0~20120320gitdb59704/screen.h
@@ -240,6 +240,57 @@ struct msg
} m;
};
+struct old_msg
+{
+ int protocol_revision; /* reduce harm done by incompatible messages */
+ int type;
+ char m_tty[MAXPATHLEN]; /* ttyname */
+ union
+{
+ struct
+ {
+ int lflag;
+ int aflag;
+ int flowflag;
+ int hheight; /* size of scrollback buffer */
+ int nargs;
+ char line[MAXPATHLEN];
+ char dir[MAXPATHLEN];
+ char screenterm[20]; /* is screen really screen ? */
+ }
+ create;
+ struct
+ {
+ char auser[20 + 1]; /* username */
+ int apid; /* pid of frontend */
+ int adaptflag;/* adapt window size? */
+ int lines, columns; /* display size */
+ char preselect[20];
+ int esc; /* his new escape character unless -1 */
+ int meta_esc; /* his new meta esc character unless -1 */
+ char envterm[20 + 1]; /* terminal type */
+ int encoding; /* encoding of display */
+ }
+ attach;
+ struct
+ {
+ char duser[20 + 1]; /* username */
+ int dpid; /* pid of frontend */
+ }
+ detach;
+ struct
+ {
+ char auser[20 + 1]; /* username */
+ int nargs;
+ char cmd[MAXPATHLEN]; /* command */
+ int apid; /* pid of frontend */
+ char preselect[20];
+ }
+ command;
+ char message[MAXPATHLEN * 2];
+} m;
+};
+
/*
* And the signals the attacher receives from the backend
*/
Index: screen-4.1.0~20120320gitdb59704/socket.c
===
--- screen-4.1.0~20120320gitdb59704.orig/socket.c
+++ screen-4.1.0~20120320gitdb59704/socket.c
@@ -1067,7 +1067,9 @@ ReceiveMsg()
}
if (left 0)
{
- if (left != sizeof(m))
+ if (left == sizeof(struct msg) - sizeof(struct old_msg))
+;/* old format message, ignore */
+ else if (left != sizeof(m))
Msg(0, Message %d of %d bytes too small, left, (int)sizeof(m));
else
debug(No data on socket.\n);
Index: screen-4.1.0~20120320gitdb59704/attacher.c
===
--- screen-4.1.0~20120320gitdb59704.orig/attacher.c
+++ screen-4.1.0~20120320gitdb59704/attacher.c
@@ -133,6 +133,46 @@ struct msg *m;
return 0;
}
+int
+WriteOldMessage(struct msg *m)
+{
+ sleep(1); /* give the server some time to reopen the pipe */
+ if (m-type == MSG_ATTACH m-m.attach.detachfirst == MSG_ATTACH)
+{
+ struct old_msg old_m;
+ int s;
+ int r, l = sizeof(old_m);
+
+ s = MakeClientSocket(0);
+ if (s 0)
+ return 0;
+ old_m.protocol_revision = (('m'24) | ('s'16) | ('g'8) | 0);
+ old_m.type = m-type;
+ memcpy(old_m.m_tty, m-m_tty, sizeof(old_m.m_tty));
+ memcpy(old_m.m.attach.auser, m-m.attach.auser,
sizeof(old_m.m.attach.auser));
+ old_m.m.attach.apid = m-m.attach.apid;
+ old_m.m.attach.adaptflag = m-m.attach.adaptflag;
+ old_m.m.attach.lines = m-m.attach.lines;
+ old_m.m.attach.columns = m-m.attach.columns;
+ memcpy(old_m.m.attach.preselect, m-m.attach.preselect,
sizeof(old_m.m.attach.preselect));
+ old_m.m.attach.esc = m-m.attach.esc;
+ old_m.m.attach.meta_esc = m-m.attach.meta_esc;
+ memcpy(old_m.m.attach.envterm, m-m.attach.envterm,
sizeof(old_m.m.attach.envterm));
+ old_m.m.attach.encoding = m-m.attach.encoding;
+ while(l 0)
+{
+ r = write(s, (char *)old_m + (sizeof(struct old_msg) - l), l);
+ if (r == -1 errno == EINTR)
+ continue;
+ if (r == -1 || r == 0)
+ return -1;
+ l -= r;
+}
+ close(s);
+}
+ return 0;
+}
+
int
Attach(how)
@@ -397,6 +437,7 @@ int how;
if (WriteMessage(lasts, m))
Panic(errno, WriteMessage);
Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
On Sat, Nov 19, 2011 at 11:56:25 -0800, Steve Langasek wrote: On Sat, Nov 19, 2011 at 05:24:34PM +, Justin B Rye wrote: Axel Beckert wrote: Possible suggestions for the release notes: Use tmux instead of screen for the dist-upgrade. Not really a laudable note for screen, but I have currently no better idea. Would it make sense to recommend putting screen on hold and upgrading it separately after the dist-upgrade is finished? That wouldn't work for something like udev or gdm3, but it sounds like the simplest strategy for a leaf package like screen. (We'll need material for the release notes eventually, but first screen 4.1.0 is obviously going to need to put some warnings and recommendations in a NEWS.Debian file.) Any such mitigation strategies will be a poor substitute for having screen actually work properly across upgrades. There is nowhere that we can put such a recommendation that we can ensure users will see it before they start the upgrade; and once they've started the upgrade inside of a screen session, it's too late to put the package on hold / start the upgrade outside of screen / do anything at all except hope you don't have to reattach to the screen to answer the debconf/conffile prompts and complete the upgrade. Given that in other quarters I'm consistently hearing that screen has stagnated and been overtaken by tmux, it's incredibly bad form for the new upstream version to have broken protocol compatibility like this. I think the screen maintainer should insist on upstream fixing protocol compatibility before allowing this version into unstable. Did this stuff ever get fixed? screen's NEWS.Debian suggests it isn't, which I find rather annoying. Said NEWS file also recommends downloading and running code from a random web server as root, which really doesn't seem appropriate, even in the context of this bug. If this is indeed the state of screen in wheezy I'm thinking it'd be better to go back to the previous (pre-compatibility-break) version. Cheers, Julien signature.asc Description: Digital signature
Bug#649240: Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
Hi Steve, Steve Langasek wrote: Screen maintainers, could you please correct this lack of compatibility with the old protocol, which causes problems for any users trying to do distribution upgrades from inside of screen? JFTR: I just checked if reverting a few patches would help us in an easy way, but the changes seem to be too invasive. Sadrul bumped the msg struct version deliberately in these commits: http://git.savannah.gnu.org/cgit/screen.git/commit/?id=8b46d8a5d214ab124db868a47c5e569f1e83c33e http://git.savannah.gnu.org/cgit/screen.git/commit/?id=e3fc19a176c1ed2c266aca03cb5bcc17d0192630 From the commit message of the last one: A small change in the messaging system is necessary, thus bumping the message version, for the first time since it has been introduced, it seems. But I don't think it's going to break anything. Well, I guess we have a different opinion WRT to the breakage caused by this commit. ;-) For the discussion, the commit message refers to https://savannah.gnu.org/bugs/?24029 Explanation of the message versions used so far in screen at http://git.savannah.gnu.org/cgit/screen.git/tree/src/screen.h#n179 Regards, Axel -- ,''`. | Axel Beckert a...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649240: Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
On Sat, Nov 19, 2011 at 10:34:15PM +0100, Axel Beckert wrote: and once they've started the upgrade inside of a screen session, it's too late I disagree. to put the package on hold Yes, it's to late for that, but not for that: start the upgrade outside of screen / do anything at all except hope you don't have to reattach to the screen to answer the debconf/conffile prompts and complete the upgrade. Nope. It should do the trick if the 4.1.0 package fails to install very early in a way so that dpkg makes a rollback if the maintainer script encounters running screen sessions and then advises the user to wait with the screen upgrade until that session is finished. That's the way I currently plan to go. Doing this as part of a dist-upgrade between releases does not make for a very usable experience, because the upgrade will be at an arbitrary point in the upgrade when the screen preinst script is run, which may cause apt to abort with the system in a state that a subsequent 'apt-get dist-upgrade' run is not sufficient to correctly upgrade from. it's incredibly bad form for the new upstream version to have broken protocol compatibility like this. I agree. I think the screen maintainer should insist on upstream fixing protocol compatibility before allowing this version into unstable. I'd be happy if you could write that on screen-devel. Best would be to reply to group-reply to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788#22 I'm happy about everyone who helps to persuade upstream to fix that issue properly. :-) Well, done. :) Screen maintainers, could you please correct this lack of compatibility with the old protocol, which causes problems for any users trying to do distribution upgrades from inside of screen? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
Package: release-notes Tags: wheezy On Sat, Nov 19, 2011 at 04:03:30 +0100, Axel Beckert wrote: Hi Release-Team, I wanted to make you aware of an issue with screen which will very likely be present when dist-upgrading from Squeeze to Wheezy inside a Screen session: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788 If upstream doesn't add some option to let a screen 4.1.0 client communicate with a screen 4.0.3 server, it won't be possible to reattach to a running 4.0.3 screen session if screen has been upgraded to 4.1.0 already. I still have some hope, but if there's really no chance, this is IMHO definitely something which should go into the release notes. Possible suggestions for the release notes: Use tmux instead of screen for the dist-upgrade. Not really a laudable note for screen, but I have currently no better idea. And even if upstream adds some backward compatibility command-line option, this option should be mentioned in the Release Notes anyway Anyway, I'll let you know when I uploaded a screen 4.1.0 package to unstable and which options we have then. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
Axel Beckert wrote: Possible suggestions for the release notes: Use tmux instead of screen for the dist-upgrade. Not really a laudable note for screen, but I have currently no better idea. Would it make sense to recommend putting screen on hold and upgrading it separately after the dist-upgrade is finished? That wouldn't work for something like udev or gdm3, but it sounds like the simplest strategy for a leaf package like screen. (We'll need material for the release notes eventually, but first screen 4.1.0 is obviously going to need to put some warnings and recommendations in a NEWS.Debian file.) -- JBR For trifling occasions it is better to accomplish things simply by yelling - Hagakure, Yamamoto Tsunetomo (1716) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
On Sat, Nov 19, 2011 at 05:24:34PM +, Justin B Rye wrote: Axel Beckert wrote: Possible suggestions for the release notes: Use tmux instead of screen for the dist-upgrade. Not really a laudable note for screen, but I have currently no better idea. Would it make sense to recommend putting screen on hold and upgrading it separately after the dist-upgrade is finished? That wouldn't work for something like udev or gdm3, but it sounds like the simplest strategy for a leaf package like screen. (We'll need material for the release notes eventually, but first screen 4.1.0 is obviously going to need to put some warnings and recommendations in a NEWS.Debian file.) Any such mitigation strategies will be a poor substitute for having screen actually work properly across upgrades. There is nowhere that we can put such a recommendation that we can ensure users will see it before they start the upgrade; and once they've started the upgrade inside of a screen session, it's too late to put the package on hold / start the upgrade outside of screen / do anything at all except hope you don't have to reattach to the screen to answer the debconf/conffile prompts and complete the upgrade. Given that in other quarters I'm consistently hearing that screen has stagnated and been overtaken by tmux, it's incredibly bad form for the new upstream version to have broken protocol compatibility like this. I think the screen maintainer should insist on upstream fixing protocol compatibility before allowing this version into unstable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
Hi, Steve Langasek wrote: On Sat, Nov 19, 2011 at 05:24:34PM +, Justin B Rye wrote: Axel Beckert wrote: Possible suggestions for the release notes: Use tmux instead of screen for the dist-upgrade. Not really a laudable note for screen, but I have currently no better idea. Would it make sense to recommend putting screen on hold IMHO no. Most people won't read those recommendations. Besides I've never read such a recommendation before, neither for udev nor for gdm3. And I do read the release notes since approximately the Sarge/Etch dist-upgrade. and upgrading it separately after the dist-upgrade is finished? That's my current plan, but caused by a preconfigure or preinst script which fails if active screen sessions are running like udev did if it wasn't upgraded together with the kernel once. (We'll need material for the release notes eventually, but first screen 4.1.0 is obviously going to need to put some warnings and recommendations in a NEWS.Debian file.) Ehm, Justin, you seem not aware that there is already a first 4.1.0 package in Experimental which does exactly that: http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html (Look for the string NEWS.) The reason why I uploaded it to experimental and not to unstable is exactly the one we're now discussion about. :-) Any such mitigation strategies will be a poor substitute for having screen actually work properly across upgrades. Agreed. There is nowhere that we can put such a recommendation that we can ensure users will see it before they start the upgrade; Agreed. and once they've started the upgrade inside of a screen session, it's too late I disagree. to put the package on hold Yes, it's to late for that, but not for that: start the upgrade outside of screen / do anything at all except hope you don't have to reattach to the screen to answer the debconf/conffile prompts and complete the upgrade. Nope. It should do the trick if the 4.1.0 package fails to install very early in a way so that dpkg makes a rollback if the maintainer script encounters running screen sessions and then advises the user to wait with the screen upgrade until that session is finished. That's the way I currently plan to go. Given that in other quarters I'm consistently hearing that screen has stagnated and been overtaken by tmux, Well, it has stagnated if you take the average of several years, but it has taken up (a little) speed in the last two years with fresh blood in the team as it seems. I also disagree that it has been overtaken by tmux: I found tmux not really usable. That's why I took care of the slightly weathered screen package. But I know this opinion isn't the majority of people who tell things about screen and tmux. E.g. IMHO tmux' documentation doesn't help a lot. I wasn't able to implement something I did for screen in 10 minutes with tmux in 2 hours (and then I mostly gave up). it's incredibly bad form for the new upstream version to have broken protocol compatibility like this. I agree. I think the screen maintainer should insist on upstream fixing protocol compatibility before allowing this version into unstable. I'd be happy if you could write that on screen-devel. Best would be to reply to group-reply to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788#22 I'm happy about everyone who helps to persuade upstream to fix that issue properly. :-) P.S.: I didn't get Justin's mail (yet). Regards, Axel -- ,''`. | Axel Beckert a...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
