Re: Ping Packagers

[Dustin Kirkland]

On Sat, Dec 19, 2009 at 1:51 PM, Sadrul Habib Chowdhury
<address@hidden> wrote:
> * Dustin Kirkland had this to say on [09 Dec 2009, 10:37:17 -0800]:
>> On Wed, Dec 9, 2009 at 10:23 AM, Dustin Kirkland <address@hidden> wrote:
>> > On Wed, Dec 9, 2009 at 10:19 AM, Sadrul Habib Chowdhury
>> > <address@hidden> wrote:
>> >> Hello everyone. Are there any screen packagers on this list? I am
>> >> contemplating a sort of a beta-release somewhat soon-ish (still
>> >> non-trivial amount of work to do, though, so no ETA yet), and was
>> >> thinking if this list is the best place to reach the packagers.
>> >
>> > Hello-
>> >
>> > I maintain (along with some others) the screen package in Ubuntu, and
>> > I do follow this list.
>> >
>> > We (Ubuntu) as well as Debian are carrying a stack of patches against
>> > Screen.  Could we see about getting as many of these as possible into
>> > your next upstream release?
>>
>> FYI, you can see the patches we're carrying at:
>> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/screen/karmic/files/head%3A/debian/patches/
> [snip]
>
> I looked at a number of them:

Great, thanks!

>> 17manpage_sessionname_warning.dpatch
>
> Applied after slight modification.
> (855b8e7b98894e8f94033945720714c235911262)
>
>> 18manpage_maxwin_limit.dpatch
>
> Applied after removing the note about debian.
> (04005670529085ef8527608c0ec34b06569f0bd8)
>
>> 20defmonitor.dpatch
>
> Already in.
>
>> 21manpage_nethack_activation.dpatch
>
> Applied. (3b19a1d343e72e4fa786e9ab514d80303902a2c1)
>
>> 25allow_symlink_sockdir.dpatch
>
> Applied. (1e450254e75877b6bb5cacedd5466245dbb54576)
>
>> 27doc_sty_noenvpassing.dpatch
>
> Applied. (f6c4b82)
>
>> 28blankerprg_callsemantics.dpatch
>
> Applied in 52efeb8 after some change. Instead of unsetting blankerprg on
> no argument, it will show the currently set blankerprg. To unset, use ''
> as the argument. I have updated the man/info page accordingly.
>
>> 31upstream_cherries.dpatch
>
> Already in.
>
>> 32misc_minor_fixes.dpatch
>
> eh, I like that message :)
>
>> 33increase_max_winmsg_renditions.dpatch
>
> I think 256 is a bit too excessive. I am going to increase it to 128
> instead, which I honestly think should be more than enough.

Hmm, what's the actual cost?  Some memory?  How much?  Would it be
realistic to make this dynamically allocated?

I maintain a project that provides a layer on top of Screen called
Byobu.  We make heavy use of the hard status formatting with a series
of several dozen toggle on/off status scripts.  With 1920x1080
displays, and an 8 pitch font, there's a lot of room across the bottom
of the screen.

See for an example this screenshot (with almost everything toggled on):
http://rookery.canonical.com/~kirkland/Byobu.png

For each color change, I also use \005{-} to "undo" it, and bring it
back to the native color.  This means that each color change costs 2
against that 128 or 256 number.  They add up quickly.

I appreciate your bumping it up to 128.  We will probably continue to
carry a patch for 256 in Ubuntu.  Assuming it's not too expensive, it
would be nice if you would reconsider.  Thanks.

> I am also considering increasing the oft requested window limit. That
> will probably require a bit more work than just changing the define.

Definitely would be nice.  I'm currently hitting the limit at 40
windows.  What are you thinking for a limit?  Again, a dynamic malloc
would be nice (haven't looked at the code to judge the feasibility,
though).

>> 40cjk_eastasian.dpatch
>
> Already in.
>
>> 45suppress_remap.dpatch
>
> I think this is incorrect. What keybindings are broken now? I think
> 17b43961982caa5132d98544addc4de3f89103db fixes at least part of the bug
> this patch tries to fix. I need to know if keys other than the end-key
> are broken.

Checking with Loic, on CC.

Loic- the upstream Screen maintainer is helping review the stack of
patches Debian and Ubuntu are carrying and there's a question (above)
about the current applicability of your patch.  Care to comment?

>> 50EXP_tilde_expansion.dpatch
>
> Already in.
>
>> 51EXP_session_creation_time.dpatch
>
> Need to take a closer look. The idea sounds nice. But it doesn't look
> like the implementation is very portable. I think it would be simpler to
> add the timestamp of the session creation in the socket name, like we now
> add just the PID.
>
>> 56-source-file-not-found-warning.dpatch
>
> I disagree with this change. I think the error message is appropriate.

Understood.  Would you support an additional, new directive that would
source-if-found, but throw no warning if not?  Something like
"-source" or "@source" a la Makefile syntax?

>> 58-show-encoding-hardstatus.dpatch
>
> I don't like this patch. I wouldn't want more string escapes unless they
> are really useful. In this case, I am not convinced that showing the
> encoding in the caption is all that useful. This information is available
> in 'info'. Is there a use case where that's not enough?

I'm not sure.  An Ubuntu user complained about this, and provided a
patch that seemed to work for me.  It didn't bother me as a packager,
so I included it.  If it's ill-advised, or evil somehow, I can drop it
and inform the user that upstream rejected it.

>> 59-no-beep-on-write-acl.dpatch
>
> Applied. (84b8ef5)
>
> I can't get the rest of them at the moment, setting an "Internal Server
> Error" from launchpad.

Sorry about that.  There was a Launchpad maintenance window recently,
maybe you hit that.

Thanks for going over these!

In the future, what's the currently preferred mechanism for patch
submission?  Devel mailing list, bug tracker, or otherwise?

:-Dustin