On Mon, Jan 2, 2012 at 1:45 AM,
<debian-devel-digest-request@lists.debian.org> wrote:
Content-Type: text/plain
debian-devel-digest Digest Volume 2012 : Issue 2
Today's Topics:
Bug#654116: RFH: screen -- terminal [ Axel Beckert <abe@debian.org> ]
Re: Bug#654116: RFH: screen -- termi [ Yaroslav Halchenko <debian@onerussi ]
Re: from / to /usr/: a summary [ md@Linux.IT (Marco d'Itri) ]
Re: Bug#654116: RFH: screen -- termi [ Axel Beckert <abe@debian.org> ]
Packaging best practice when upstrea [ Axel Beckert <abe@debian.org> ]
Re: Bug#654116: RFH: screen -- termi [ md@Linux.IT (Marco d'Itri) ]
Re: Bug#644788: Bug#654116: RFH: scr [ Axel Beckert <abe@debian.org> ]
Re: Bug#644788: Bug#654116: RFH: scr [ Ben Finney <ben+debian@benfinney.id ]
Re: Bug#644788: Bug#654116: RFH: scr [ Axel Beckert <abe@debian.org> ]
Re: Bug#644788: Bug#654116: RFH: scr [ Karl Goetz <karl@kgoetz.id.au> ]
Re: Bug#654116: RFH: screen -- termi [ Romain Francoise <rfrancoise@debian ]
Re: Bug#654116: RFH: screen -- termi [ Adam Borowski <kilobyte@angband.pl> ]
Date: Mon, 02 Jan 2012 02:25:49 +0100
From: Axel Beckert <abe@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Message-ID: <[🔎] 87hb0eq4iq.fsf@nemo.deuxchevaux.org">[🔎] 87hb0eq4iq.fsf@nemo.deuxchevaux.org>
Content-Type: text/plain; charset=us-ascii
Package: wnpp
Severity: normal
Hi,
Debian's screen package needs help with bug triaging, wheezy migration
and upstream lobbying.
Jan took over Debian's screen package in 2007 and was a very active and
talented screen package maintainer. Unfortunately he no more has enough
time[1] to maintain GNU Screen in Debian.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641867#20
Because I still prefer screen over tmux, I jumped in as co-maintainer a
few months ago and with the help of Brian P Kroth I managed to upload[2]
an upstream git snapshot to Debian Experimental which fixed especially
the tons of bugs already fixed by upstream. I also created a git
repository for Debian's screen packaging at [3].
[2] http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html
[3] http://anonscm.debian.org/gitweb/?p=collab-maint/screen.git
Nevertheless I know I won't be able to maintain screen alone until Jan
has time for screen again. So screen definitely needs more (co-)
maintainers.
Additionally there are a few issues where I'd be happy to have other
people to dig into, too, especially:
* http://bugs.debian.org/644788 -- screen 4.1.0 can't attach to a
running or detached screen 4.0.3 session
* http://bugs.debian.org/649240 -- release-notes: Upcoming upgrade
issues with GNU Screen for Wheezy
Both these bug reports are defacto about the same issue, the first is
the technical issue itself while the second is about how to handle the
implications for screen's wheezy migration.
And both bug reports are somehow also about lobbying at upstream to fix
this issue upstream instead just for Debian and derivate distributions
like Ubuntu. Unfortunately a first reply[4] from upstream was a "won't
fix".
[4] https://lists.gnu.org/archive/html/screen-devel/2011-11/msg00020.html
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
Date: Sun, 1 Jan 2012 20:41:23 -0500
From: Yaroslav Halchenko <debian@onerussian.com>
To: debian-devel@lists.debian.org
Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with
VT100/ANSI terminal emulation
Message-ID: <[🔎] 20120102014123.GI16995@onerussian.com">[🔎] 20120102014123.GI16995@onerussian.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
pardon my blunt question:
but is there really possibility to have them 'fixed'? I am reading
upstream response just as a statement that it can't be achieved due to a
chance in protocol...
On Mon, 02 Jan 2012, Axel Beckert wrote:
> Additionally there are a few issues where I'd be happy to have other
> people to dig into, too, especially:
> * http://bugs.debian.org/644788 -- screen 4.1.0 can't attach to a
> running or detached screen 4.0.3 session
> * http://bugs.debian.org/649240 -- release-notes: Upcoming upgrade
> issues with GNU Screen for Wheezy
> Both these bug reports are defacto about the same issue, the first is
> the technical issue itself while the second is about how to handle the
> implications for screen's wheezy migration.
> And both bug reports are somehow also about lobbying at upstream to fix
> this issue upstream instead just for Debian and derivate distributions
> like Ubuntu. Unfortunately a first reply[4] from upstream was a "won't
> fix".
> [4] https://lists.gnu.org/archive/html/screen-devel/2011-11/msg00020.html
> Regards, Axel
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Date: Mon, 2 Jan 2012 02:49:31 +0100
From: md@Linux.IT (Marco d'Itri)
To: debian-devel@lists.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: from / to /usr/: a summary
Message-ID: <[🔎] 20120102014931.GA18149@bongo.bofh.it">[🔎] 20120102014931.GA18149@bongo.bofh.it>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj"
Content-Disposition: inline
--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Jan 01, Riku Voipio <riku.voipio@iki.fi> wrote:
> Would we really need that? If I understand correctly, the / to /usr will
> merely mean that
>=20
> People who want to have /usr on separate partition will need initramfs.
Correct.
It does not even mean that they would need to use initramfs-tools, there=20
are a few possible alternative solutions if anybody cared enough to=20
implement them.
I believe that creating a generic initramfs with busybox-static which
can mount /usr defined on the kernel command line would take a couple of=20
hours at most (and it could even be embedded in a custom kernel!).
--=20
ciao,
Marco
--9amGYk9869ThD9tj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk8BDSsACgkQFGfw2OHuP7HDvgCeOuQZacCanYkbzcpk+pNOw13L
UlcAnifIFrDNapTXcKBQ9sy4+iNnwKjh
=KMM2
-----END PGP SIGNATURE-----
--9amGYk9869ThD9tj--
Date: Mon, 2 Jan 2012 03:18:34 +0100
From: Axel Beckert <abe@debian.org>
To: debian-devel@lists.debian.org
Cc: 644788@bugs.debian.org
Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with
VT100/ANSI terminal emulation
Message-ID: <[🔎] 20120102021834.GH20942@sym.noone.org">[🔎] 20120102021834.GH20942@sym.noone.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Yaroslav,
Yaroslav Halchenko wrote:
> pardon my blunt question:
No, this question is completely valid and understandable and came up
already in the two mentioned bug reports (#644788 and #649240).
> but is there really possibility to have them 'fixed'?
Well, there are several ways to "fix" this, some are surely less
perfect and less favourable solutions, but then again -- as you
correctly state -- the perfect ones may not be possible.
But we have to choose at least one solution because otherwise the
dist-upgrade to Wheezy will be very ugly (and therefor not
debian-like) for those who run it inside a screen session remotely and
the network connections dies after screen has been dist-upgraded. (So
IMHO there is no option to do nothing at all. ;-)
> I am reading upstream response just as a statement that it can't be
> achieved due to a chance in protocol...
Yep.
I see the following options:
A) Add an option to screen so the screen client speaks the old
protocol to the running server protocol. This IMHO would be best
solution and one without a big impact. It's also something which
could be Debian-only, i.e. a patch. (It of course would be better
if upstream could be convinced to add such an option. :-)
B) Take care that nobody upgrades the screen package while running
inside a screen without being aware of the possible problems. There
are few ideas how to implement this:
1) Mention it in the release notes that screen has to be upgraded
to the very end of the dist-upgrade process if the dist-upgrade
is running inside screen.
Disadvantage: Many admins don't read the release notes.
2) Fail in the preinst maintainer script if screen server processes
are running like udev did from Etch to Lenny if not upgraded
together with the kernel.
Disadvantage: According to Steve Langasek this could be very
ugly, so I suggest to inform via debconf about the issue and let
the user decide if he wants to continue, abort (or maybe get a
shell to connect to that screen session and close it)
3) Tell people via the release notes that they should not run the
dist-upgrade inside screen, but inside tmux instead.
Disadvantage: Many admins don't read the release notes. People
may still distrust tmux for such an crucial task or just may not
be comfortable with the parts where tmux's behaviour differs
from screen's behaviour.
C) Provide both, screen 4.0.3 and screen 4.1.0 binaries. Again, here
are more than one option to do so:
1) Let the preinst maintainer script make a copy of the old screen
binary, provide a script to clean up this mess afterwards,
inform the user via debconf about the issue and his
possibilities (where the copy of the old screen is, etc.).
Disadvantage: It's a non-dpkg-managed mess.
2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
i.e. give them different source and binary package names.
Disadvantage: Dependencies between those packages needed for
proper Wheezy migration not obvious. We'd need something like
"if screen sessions are running, pull in screen-4.0.3 and
screen-4.1.0, but just pull in screen-4.1.0 if no screen session
is running", but of course this is impossible just with
dependencies.
Additionally, I'm not 100% (but let's say 90% :-) convinced that these
changes necessarily had to be incompatible. But changing them back (if
possible) would surely have some impact the other way round for those
already running git snapshots running with the current protocol
version. So there may be also an option "D":
D) Convince upstream to make the new protocol (which includes password
protected screen sessions even after reattaching) compatible to the
old protocol.
IMHO option A would be the most preferable one, D seems less
realistic, C2 is realistic but quite some work, B1, B3 and C1 are
ugly, and B2 is said to possibly become ugly, too.
So my current plan is that if nobody manages A, I'd have a closer look
at C2 and if that's not possible or too complicated, I'd go with B2
and the mentioned Debconf questions as the last resort.
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
Date: Mon, 2 Jan 2012 03:32:48 +0100
From: Axel Beckert <abe@debian.org>
To: debian-devel@lists.debian.org
Cc: pkg-zsh-devel@lists.alioth.debian.org
Subject: Packaging best practice when upstream git contains more directory
levels than the upstream tarball?
Message-ID: <[🔎] 20120102023248.GJ20942@sym.noone.org">[🔎] 20120102023248.GJ20942@sym.noone.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
for quite some while now I'm wondering what's the best practice to
maintain a package in a git repo if upstream uses a git repo, too, but
that has at least one directory level more than the official upstream
tarball.
I prefer to base my packages on official upstream tarballs for several
reasons (see below), but having the upstream git repo as remote in
your packaging git repo also has some advantages.
Unfortunately git has not yet a narrow clone like Subversion does
(i.e. with git you are not able to just clone a subdirectory instead
of the full repo), so things seem to get really complicated if the
upstream git repo contain more directory levels than the upstream
tarball.
So far the problem. Now to the advantages of both ways:
Upstream tarballs are preferable because:
* It's use is recommended in the Developer Reference
* It's clear how the tarball was generated -- built by upstream and
downloaded
* Distributions which build the software on package/port installation
time (like e.g. FreeBSD and Gentoo) rely a lot on the Debian
mirrors -- but only if we use the original upstream tarball.(*)
(*) Even if some may argue that's somebody else's problem, I think
it's a not so unimportant argument.
Tarballs built from a git repo which includes the upstream git repo as
a remote git repo are preferable because:
* They may include more files you possibly need for using
automake/autoconf foo or to rebuild other stuff which is prebuilt in
the official upstream tarball.(**)
* You can use git bisect to see where upstream introduced a bug.
* You can easily produce packages of upstream snapshots.
(**) From my current point of view this is the only really problematic
issue and if such an issue is not present, using upstream
tarballs is preferable.
In ran into this dilemma when I packaged a git snapshot of screen for
experimental. Nevertheless I noticed the fact that it really can be a
problem only when looking closer at the packaging of zsh -- which
currently has issues similar to the one marked with (**), but without
the "one more directory level" component. (I though believe that we
can do the balance between both worlds with zsh. :-)
My current "solution" (well, more a workaround than a solution) for
packaging screen is to use upstream tarballs and keep a clone of the
upstream git repo in a separate git working copy. (A separate branch
would also do it, but that would be like having clones of two
completely different git repos in two branches of one git repo.)
Another idea which I had was using git submodules for whatever is in
the upstream tar ball, but I ran into non-obvious problems already
while just imagining with it.
Anyone else ran into this problem? Anyone has found a better solution
-- or a better workaround? :-)
Maybe also the git-buildpackage-alike workflow in my head
(git-import-orig, debuild -uc -us, pdebuild, git-builtpackage
--git-tag-only) keeps me away from seeing the wood for the trees...
P.S.: If anyone is interested in helping to maintain screen in Debian,
have a look at this RFH: http://bugs.debian.org/654116 -- TIA :-)
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
Date: Mon, 2 Jan 2012 03:57:42 +0100
From: md@Linux.IT (Marco d'Itri)
To: debian-devel@lists.debian.org, 644788@bugs.debian.org
Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI
terminal emulation
Message-ID: <[🔎] 20120102025742.GA18754@bongo.bofh.it">[🔎] 20120102025742.GA18754@bongo.bofh.it>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7"
Content-Disposition: inline
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Jan 02, Axel Beckert <abe@debian.org> wrote:
> A) Add an option to screen so the screen client speaks the old
> protocol to the running server protocol. This IMHO would be best
> solution and one without a big impact. It's also something which
As long as the needed patch is simple. But if it were, this would=20
probably already have been solved.
> 2) Fail in the preinst maintainer script if screen server processes
> are running like udev did from Etch to Lenny if not upgraded
> together with the kernel.
The abort notice should be provided by debconf before the upgrade=20
process is started, indeed.
> 1) Let the preinst maintainer script make a copy of the old screen
> binary, provide a script to clean up this mess afterwards,
> inform the user via debconf about the issue and his
> possibilities (where the copy of the old screen is, etc.).
>=20
> Disadvantage: It's a non-dpkg-managed mess.
I strongly recommend this solution, along with a proper debconf notice.
If screen is running, the admin will be able to choose between:
- abort the upgrade, upgrade screen and its dependencies and then=20
start again the full upgrade
- continue the upgrade while knowing that the old binary will still be
available in /tmp/old-screen.$RANDOM/ or something
/tmp is a good choice because the next reboot will automatically clean=20
up everything (and obviously the old binary will not be needed after=20
a reboot).
> 2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
> i.e. give them different source and binary package names.
This would require a great amount of work to fix a tiny problem which=20
presents itself just for the length of the upgrade process, if at all.
I believe that this is a textbook example which shows how trying to=20
implement the perfect solution which will beautifully cover all corner=20
cases has indefinitly stalled development on the package.
Do not try to fix everything, you should aim to provide a reasonable=20
solution which will solve the most common cases.
--=20
ciao,
Marco
--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk8BHSYACgkQFGfw2OHuP7GO5QCdEGsLL24G6U5CWZ80PVLsnGR4
DEgAn3afbrP2aosPt1IxasAfWEVvBomB
=xJZ6
-----END PGP SIGNATURE-----
--1yeeQ81UyVL57Vl7--
Date: Mon, 2 Jan 2012 04:13:44 +0100
From: Axel Beckert <abe@debian.org>
To: debian-devel@lists.debian.org
Cc: 644788@bugs.debian.org
Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor
with VT100/ANSI terminal emulation
Message-ID: <[🔎] 20120102031344.GL20942@sym.noone.org">[🔎] 20120102031344.GL20942@sym.noone.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Marco,
Marco d'Itri wrote:
> > 1) Let the preinst maintainer script make a copy of the old screen
> > binary, provide a script to clean up this mess afterwards,
> > inform the user via debconf about the issue and his
> > possibilities (where the copy of the old screen is, etc.).
> >
> > Disadvantage: It's a non-dpkg-managed mess.
> I strongly recommend this solution, along with a proper debconf notice.
[...]
> /tmp is a good choice because the next reboot will automatically clean
> up everything (and obviously the old binary will not be needed after
> a reboot).
Thanks for that hint. This sounds better (and especially less messy)
than I thought! :-)
> > 2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
> > i.e. give them different source and binary package names.
> This would require a great amount of work
I fear so, yes.
> to fix a tiny problem which presents itself just for the length of
> the upgrade process, if at all.
Correct. It's an option nevertheless, so I mentioned it.
Thanks for your insight!
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
Date: Mon, 02 Jan 2012 15:17:07 +1100
From: Ben Finney <ben+debian@benfinney.id.au>
To: debian-devel@lists.debian.org
Cc: 644788@bugs.debian.org
Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Message-ID: <[🔎] 87ty4e20xo.fsf@benfinney.id.au">[🔎] 87ty4e20xo.fsf@benfinney.id.au>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Axel Beckert <abe@debian.org> writes:
> A) Add an option to screen so the screen client speaks the old
> protocol to the running server protocol. This IMHO would be best
> solution and one without a big impact. It's also something which
> could be Debian-only, i.e. a patch. (It of course would be better
> if upstream could be convinced to add such an option. :-)
That does sound like the best option. Reading upstream's latest
response, they don't seem to have expressed a position on accepting such
a change if someone does the work to implement it.
> B) Take care that nobody upgrades the screen package while running
> inside a screen without being aware of the possible problems. There
> are few ideas how to implement this:
>
> 1) Mention it in the release notes that screen has to be upgraded
> to the very end of the dist-upgrade process if the dist-upgrade
> is running inside screen.
>
> Disadvantage: Many admins don't read the release notes.
[=E2=80=A6]
> 3) Tell people via the release notes that they should not run the
> dist-upgrade inside screen, but inside tmux instead.
>
> Disadvantage: Many admins don't read the release notes.
The release notes (by which I assume you mean =E2=80=98changelog=E2=80=99 a=
nd
=E2=80=98changelog.Debian=E2=80=99) are not displayed by default, but I thi=
nk the
=E2=80=98NEWS.Debian=E2=80=99 file is intended for this sort of =E2=80=9Cyo=
u need to know this
before upgrading the package to this version=E2=80=9D information. See the
Developer's Reference =C2=A76.3.4.
--=20
\ =E2=80=9CI am as agnostic about God as I am about fairies and =
the |
`\ Flying Spaghetti Monster.=E2=80=9D =E2=80=94Richard Dawkins,=
2006-10-13 |
_o__) |
Ben Finney <ben@benfinney.id.au>
Date: Mon, 2 Jan 2012 05:29:48 +0100
From: Axel Beckert <abe@debian.org>
To: debian-devel@lists.debian.org
Cc: 644788@bugs.debian.org
Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor
with VT100/ANSI terminal emulation
Message-ID: <[🔎] 20120102042948.GN20942@sym.noone.org">[🔎] 20120102042948.GN20942@sym.noone.org>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Hi Ben,
Ben Finney wrote:
> > B) Take care that nobody upgrades the screen package while running
> > inside a screen without being aware of the possible problems. There
> > are few ideas how to implement this:
> >
> > 1) Mention it in the release notes that screen has to be upgraded
> > to the very end of the dist-upgrade process if the dist-upgrade
> > is running inside screen.
> >
> > Disadvantage: Many admins don't read the release notes.
> […]
> > 3) Tell people via the release notes that they should not run the
> > dist-upgrade inside screen, but inside tmux instead.
> >
> > Disadvantage: Many admins don't read the release notes.
>
> The release notes (by which I assume you mean ‘changelog’ and
> ‘changelog.Debian’)
Nope. I mean the release notes as published by Debian when releasing a
new stable release, i.e.
http://www.debian.org/releases/stable/releasenotes tracked at
http://bugs.debian.org/release-notes
> but I think the ‘NEWS.Debian’ file is intended for this sort of “you
> need to know this before upgrading the package to this version”
> information.
It's already in there since the last upload to experimental.
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
Date: Mon, 2 Jan 2012 16:07:04 +1100
From: Karl Goetz <karl@kgoetz.id.au>
To: debian-devel@lists.debian.org
Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor
with VT100/ANSI terminal emulation
Message-ID: <[🔎] 20120102160704.3a33e762@epicfail.kgoetz.id.au">[🔎] 20120102160704.3a33e762@epicfail.kgoetz.id.au>
Content-Type: multipart/signed; micalg=PGP-SHA1;
boundary="Sig_/IM3KmPnH/y_RZziQL1Z/njg"; protocol="application/pgp-signature"
--Sig_/IM3KmPnH/y_RZziQL1Z/njg
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Mon, 2 Jan 2012 04:13:44 +0100
Axel Beckert <abe@debian.org> wrote:
> Hi Marco,
>=20
> Marco d'Itri wrote:
> > > 2) Make screen 4.0.3 and screen 4.1.0 installable at the same
> > > time, i.e. give them different source and binary package names.
> > This would require a great amount of work
>=20
> I fear so, yes.
>=20
> > to fix a tiny problem which presents itself just for the length of
> > the upgrade process, if at all.
>=20
> Correct. It's an option nevertheless, so I mentioned it.
Sorry if I've misunderstood, but doesn't this problem manifest for
*anyone* trying to ssh from a wheezy system to a squeeze system?
thanks,
kk
--=20
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group
--Sig_/IM3KmPnH/y_RZziQL1Z/njg
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk8BO3gACgkQhIBzgCf88S6dfACgz4X8YSNcsph0QQUXhrArw5iq
Hv4An0pTyBHh6mQfotbg1RkWJy18Y9sY
=2Gt4
-----END PGP SIGNATURE-----
--Sig_/IM3KmPnH/y_RZziQL1Z/njg--
Date: Mon, 02 Jan 2012 09:28:39 +0100
From: Romain Francoise <rfrancoise@debian.org>
To: debian-devel@lists.debian.org
Cc: 644788@bugs.debian.org
Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Message-ID: <[🔎] 87sjjyy0co.fsf@silenus.orebokech.com">[🔎] 87sjjyy0co.fsf@silenus.orebokech.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Axel Beckert <abe@debian.org> writes:
> 3) Tell people via the release notes that they should not run the
> dist-upgrade inside screen, but inside tmux instead.
Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades,
the socket path was changed from /var/run/tmux to /tmp in order to remove
the setgid bit from the binary. So while the protocol itself hasn't
changed, the new tmux won't see the old servers unless given the path
explicitly (as documented in NEWS.Debian).
--
Romain Francoise <rfrancoise@debian.org>
http://people.debian.org/~rfrancoise/
Date: Mon, 2 Jan 2012 10:30:25 +0100
From: Adam Borowski <kilobyte@angband.pl>
To: debian-devel@lists.debian.org
Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with
VT100/ANSI terminal emulation
Message-ID: <[🔎] 20120102093025.GA9746@angband.pl">[🔎] 20120102093025.GA9746@angband.pl>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
On Mon, Jan 02, 2012 at 09:28:39AM +0100, Romain Francoise wrote:
> Axel Beckert <abe@debian.org> writes:
>
> > 3) Tell people via the release notes that they should not run the
> > dist-upgrade inside screen, but inside tmux instead.
>
> Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades,
> the socket path was changed from /var/run/tmux to /tmp in order to remove
> the setgid bit from the binary. So while the protocol itself hasn't
> changed, the new tmux won't see the old servers unless given the path
> explicitly (as documented in NEWS.Debian).
tmux breaks compatibility every a short while, this is one of reasons¹
people tend to prefer screen. So if you can manage making the transition
seamless, we'll love you a whole lot more.
[¹]. The other reason is tmux having some dubious default config choices
(it's configurable, though). On the other hand, tmux has better handling of
finer Unicode points.
--
1KB // Yo momma uses IPv4!