Hello,
I'm not sure if help is still needed, but if i could be of any
assistance I will be. I'm try to get more involved in debian, and since
screen is an application i frequently use, i would enjoy working on it.
Let me know if my help is needed/wanted
-Kevin
signature.asc
Description: OpenP
Hi Sean,
Sean DuBois wrote:
> Hi I am new to Debian, but I am looking for a way to start out and
> learn the ropes.
Then welcome! Feel free to ask me questions by personal mail. Or on
IRC. Beyond other networks (Freenode, IRCNet, etc.), I'm on
irc.debian.org (aka OFTC) as XTaran.
> I am a C deve
Hi I am new to Debian, but I am looking for a way to start out and
learn the ropes. I am a C developer so I may be able to help with some
patching.
I am going to look through the instructions Axel sent out and
try to get my feet wet. Is there anything Debian related I should be
getting? As far as
Hi together,
sorry for the late reply, I wasn't subscribed to this RFH bug report
(but I am now :-) and as it's not a bug report against the screen
package but the wnpp pseudo package, I didn't receive your replies,
just found them by accident yesterday (and Francesco pointed me to
them today, too
Hi,
I'm very interested in contributing if you still need help so contact me
anytime if you like.
Best regards,
--
Jeffrey Vandenborne
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
I use this package quite often, but I haven't looked into the code but
if you still need help and Francesco's help is not enough, feel free to
contact me.
Regards,
--
L. Alberto Giménez
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscrib
Hi,
I'm interested to help the packaging of screen, if you still need help
please contact me.
Francesco
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 01/04/2012 10:24 PM, Axel Beckert wrote:
> Hi Simon,
>
> Simon McVittie wrote:
>
>> On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
>>
>>> On Mon, 02 Jan 2012, Axel Beckert wrote:
>>>
> /tmp is a good choice because the next reboot will automatically clean
>>
Axel Beckert wrote:
>Simon McVittie wrote:
>> Would it be enough for the "your old screen binary is
>> /tmp/screen-yhpoe8r/screen" notice to also say "if your /tmp is mounted
>> noexec, you might need to copy it elsewhere to run it"?
> That's my current plan -- with the noexec notice just being
Hi Simon,
Simon McVittie wrote:
> On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
> > On Mon, 02 Jan 2012, Axel Beckert wrote:
> > > > /tmp is a good choice because the next reboot will automatically clean
> > > > up everything (and obviously the old binary will not be needed aft
On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
> On Mon, 02 Jan 2012, Axel Beckert wrote:
> > > /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).
>
> Thank you Axel
On Tue, Jan 03, 2012 at 04:04:04PM +0100, Axel Beckert wrote:
> Hi,
>
> Roger Leigh wrote:
> [/tmp mounted noexec]
> > > /run/shm (IIRC formerly /dev/shm) likely would be an
> > > alternative option, too.
> >
> > No, it would not. This directory is reserved for the eglibc
> > POSIX SHM/SEM inter
Hi Tollef,
Tollef Fog Heen wrote:
> Not really a serious suggestion, but for completeness
>
> E) ignore the problem and just let people rescue the programs stuck in
> the old screen using retty, reptyr or similar.
My experiences with one of these tools (IIRC retty, but I'm not sure)
a few years
]] Axel Beckert
> I see the following options:
[...]
Not really a serious suggestion, but for completeness
E) ignore the problem and just let people rescue the programs stuck in
the old screen using retty, reptyr or similar.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who
Axel Beckert writes:
> And I can't really execute it, neither as the user owning the screen
> session nor as root:
> ~ # /proc/32039/exe -ls
> zsh: permission denied: /proc/32039/exe
Yes, /proc is mounted noexec so you need to use the ld-linux.so trick.
But now that I actually try it, I realiz
Hi,
Romain Francoise wrote:
> > Thank you Axel for your detailed response and IMHO this is indeed close
> > to an ideal (lightweight, self-cleaning, etc) resolution for this
> > scenario.
>
> Of course the real lightweight, self-cleaning solution is to not do
> anything special as the old binary
Yaroslav Halchenko writes:
> Thank you Axel for your detailed response and IMHO this is indeed close
> to an ideal (lightweight, self-cleaning, etc) resolution for this
> scenario.
Of course the real lightweight, self-cleaning solution is to not do
anything special as the old binary will be kept
On Jan 03, Didier Raboud wrote:
> 3) In a "screen-cleanup init script", test the inexistance of the flag and
> the
> existance of /usr/bin/screen-old; in that case, `rm` it.
> (+ appropriate version and sanity checks, + idempotency)
This is bad, because to solve a possible 30 minutes issu
Le mardi, 3 janvier 2012 16.58:08, Axel Beckert a écrit :
> Hi,
>
> Marco d'Itri wrote:
> > If /tmp is noexec then the administrator mounted it this way and knows
> > about it.
Another idea would be to use /usr/bin as temporary place for the old screen.
That would be a Policy violation but not a
Hi,
Marco d'Itri wrote:
> If /tmp is noexec then the administrator mounted it this way and knows
> about it.
Yeah, but that is possibly such a long time ago that it's not the
first thought. So a small hint to fresh up the memory can't be bad.
> So if he is smart enought to mount /tmp noexec then
On Jan 03, Edward Allcutt wrote:
> On Tue, 3 Jan 2012, Marco d'Itri wrote:
> >It does not matter, this is needed strictly for the time of the upgrade
> >process.
> Just how short do you expect this to be? I'm sure many of us
> dist-upgrade daily and (shock! horror!) don't reboot after each
> upgr
On Tue, 3 Jan 2012, Marco d'Itri wrote:
It does not matter, this is needed strictly for the time of the upgrade
process.
Just how short do you expect this to be? I'm sure many of us dist-upgrade
daily and (shock! horror!) don't reboot after each upgrade. We also don't
expect existing processe
On Jan 03, Axel Beckert wrote:
> Thanks for the comment. Cc'ing the relevant bug again, as this is
> crucial information when I work on fixing the bug.
If /tmp is noexec then the administrator mounted it this way and knows
about it. So if he is smart enought to mount /tmp noexec then he can
proba
Hi,
Roger Leigh wrote:
[/tmp mounted noexec]
> > /run/shm (IIRC formerly /dev/shm) likely would be an
> > alternative option, too.
>
> No, it would not. This directory is reserved for the eglibc
> POSIX SHM/SEM interfaces.
Thanks for this explanation. It's the first time I read or hear about
th
On Jan 03, Yaroslav Halchenko wrote:
> just thought of it: another possible complication of this approach (mv
> /usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
> screen (e.g. byobu) might be in the cold water if the default screen in
> the PATH cannot do its duties.
It does not ma
just thought of it: another possible complication of this approach (mv
/usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
screen (e.g. byobu) might be in the cold water if the default screen in
the PATH cannot do its duties.
FWIW:
$> apt-cache rdepends screen
screen
Reverse Depends:
On Tue, Jan 03, 2012 at 07:17:04AM +0100, Axel Beckert wrote:
> Hi Yaroslav!
>
> Yaroslav Halchenko wrote:
> > > > I strongly recommend this solution, along with a proper debconf notice.
> > > [...]
> > > > /tmp is a good choice because the next reboot will automatically clean
> > > > up everythi
Hi Yaroslav!
Yaroslav Halchenko wrote:
> > > 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).
On Mon, 02 Jan 2012, Axel Beckert wrote:
> > 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
Hi Julien,
Julien Cristau 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
> >could be Debian-only, i.e. a patch. (It of cour
On Mon, Jan 2, 2012 at 03:18:34 +0100, Axel Beckert 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
>could be Debian-only, i.e. a
Hi,
Romain Francoise wrote:
> >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,
.oO( Houston, we've got a problem. )
> the socket pat
Axel Beckert 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 re
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
> >
Axel Beckert 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
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, e
On Jan 02, Axel Beckert 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 w
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" t
Axel Beckert writes:
> 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 c
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
40 matches
Mail list logo
