Bug#614316: ncurses-base: Update mach* terminfo

[Thomas Dickey]

On Sun, Jan 22, 2012 at 07:28:14PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Thomas Dickey, le Sat 23 Apr 2011 15:05:50 -0400, a ?crit :
> > What's the source for this?  The only mach sources I see are for Mach 3.0
> > at CMU - and the console sequences are much cruder than that used here.
> 
> Oops, it seems I have missed this mail.
> 
> The source is the GNU Mach, which is a branch of Mach 3.0 developped in
> the GNU project.

Where can I find the cvs/svn/git/whatever for this?

I'd like to read the source for the corresponding console driver,
to compare.
 
> Maybe you'd prefer to fork the mach terminfo entry into e.g. mach-gnu?
> It should be fine for us.

clone, or whatever - right

thanks

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#653435: libtinfo5: tic writes to /usr/share/terminfo by default

[Thomas Dickey]

On Mon, Jan 23, 2012 at 06:47:05PM +0100, Sven Joachim wrote:
> On 2012-01-22 18:34 +0100, Thomas Dickey wrote:
> 
> > On Sun, Jan 22, 2012 at 05:00:41PM +0100, Sven Joachim wrote:
> >> On 2011-12-28 10:45 +0100, Sven Joachim wrote:
> >> 
> >> > Package: libtinfo5
> >> > Version: 5.9-4
> >> > Severity: normal
> >> >
> >> > Configuring ncurses --with-default-terminfo-dir=/usr/share/terminfo, as
> >> > we have been doing since 5.7+20100313-1, has the unfortunate side effect
> >> > that tic(1) writes to /usr/share/terminfo instead of /etc/terminfo by
> >> > default when run as root (overridable with the -o option).
> >> >
> >> > I'm reluctant to revert the change, since that would mean reintroducing
> >> > bug #509919.
> >> 
> >> Looking closer, it seems to me I have now found the root cause of
> >> #509919.  In misc/gen-edit.sh, the tabset directory is computed from the
> >> default terminfo directory, but misc/Makefile.in actually installs the
> >> tabset files into ${datadir}/tabset which is not necessarily the same
> >> place.
> >> 
> >> The following patch removes this discrepancy and seems to DTRT:
> >
> > ...
> >> Thomas, what do you think of that?
> >  
> > I agree (seems to work).  Checking the history, I see that chunk dates
> > from 2004, and was originally from run_tic.sh in 1996.
> 
> For the record, I have applied the patch in our git repository.

thanks (it'll be in the next weekly patch)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665645: tack: "xterm -tn xterm-256color" fails (ccc) (initc) (initp)

[Thomas Dickey]

On Sat, Mar 24, 2012 at 06:01:23PM -0400, Samuel Bronson wrote:
> Package: tack
> Version: 1.07-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I've been seeing funny results for the "(ccc) (initc) (initp)" test...

...with 256 colors, I suppose so.

I have a couple of notes (20091031 is the most recent):
tack with extended color palette doesn't reset it

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665877: ncurses-term: /usr/share/terminfo/s/st-256color confilcted with file from suckless-tools

[Thomas Dickey]

On Mon, Mar 26, 2012 at 09:47:23PM +0200, Sven Joachim wrote:
> # reassign to ncurses-term only, since we're the ones who introduced
> # the file conflict
> reassign 665877 ncurses-term 5.9-5
> clone 665877 -1
> reassign -1 suckless-tools 38-1
> severity -1 wishlist
> retitle -1 suckless-tools: stop providing /usr/share/terminfo/s/st-256color
> thanks
> 
> On 2012-03-26 20:30 +0200, Alexander V. Kudrevatykh wrote:
> 
> > Package: ncurses-term
> > Version: 5.9-4
> 
> Should have read 5.9-5, but this has already been corrected.
> 
> > Severity: normal
> 
> Correct would have been serious, has been corrected as well.
> 
> > version 5.9-5 fails to install when suckless-tools installed
> 
> Sorry for not having noticed this in advance.  There are two
> possibilities to solve that problem:
> 
> 1. Stop shipping the st-256color terminfo entry in ncurses-term and
>continue to include it in suckless-tools.
> 
> 2. Include st-256color in ncurses-term and stop shipping it in
>suckless-tools, which means that suckless-tools have to depend on
>ncurses-term (>= 5.9-5), and ncurses-term will add Replaces+Breaks on
>suckless-tools (<< 39-1) (or whatever version is the first to stop
>shipping st-256color).

I noticed an error in ncurses' st-256color (the use= clauses are in the
wrong order).  Fix will be in the next patch...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#611487: xterm: immediately exits upon running: exec login USER

[Thomas Dickey]

On Mon, Mar 26, 2012 at 06:27:47PM -0400, Jeffrey Sheinberg wrote:
> On Thu, Feb 03, 2011 at 05:47:46AM -0500, Thomas Dickey wrote:
> 
> > Looks like a possible workaround would be to use sudo or other
> > wrapper that holds the setuid behavior.
> 
> Hi Thomas,
> 
> I tried your above suggestion, in my case I used su like this,
> 
> $ su -l jsroot
> 
> to get a user "jsroot" login shell.
> 
> I have decided it is not appropriate to expect "exec login jsroot" to work,
> even though it seemed to work when /bin/login is setuid 0 and xterm 235-2 was
> installed.  I say seemed to work because, actually, the count of logged in
> users on my system was always off by +1 when I used this technique.

sounds good (I wasn't getting far with this, last year, though I'd not
given up).
 
> Now, when I get a "jsroot" login shell via "su -l jsroot", the following
> situation exists,
> 
> # tty
> /dev/pts/2
> 
> # logname
> jeff
> 
> # var user logname
> export USER='jsroot'
> export LOGNAME='jsroot'
> 
> # who | grep pts/2
> jeff pts/2Mar 26 09:18 (:0.0)
> 
> And when I then launch an xterm from this "jsroot" login shell on pts/2,
> I have problems with xterm 261-1 & 276-2, like this,
> 
> # tty
> /dev/pts/6
> 
> # logname
> root
> 
> # var user logname
> export USER='jsroot'
> export LOGNAME='root'
> 
> # who | grep pts/6
> root pts/6Mar 26 16:12 (:0.0)
> 
> while xterm 235-2 works correctly, like this,
> 
> # tty
> /dev/pts/6
> 
> # logname
> jsroot
> 
> # var user logname
> export USER='jsroot'
> export LOGNAME='jsroot'
> 
> # who | grep pts/6
> jsroot   pts/6Mar 26 16:02 (:0.0)
> 
> Note that both lxterminal 0.1.8-2 and xfce4-terminal 0.4.5-1 exibit the same
> (IMO, correct) behavior as xterm 235-2 in this case.

hmm - I'll have to investigate this.  It sounds as if you're referring
to the effect of this chunk in main.c:

login_name = NULL;
if (x_getpwuid(screen->uid, &pw)) {
login_name = x_getlogin(screen->uid, &pw);
}

which (is supposed to follow this guideline):

/*
 * If the logon-name differs from the value we get by looking in the
 * password file, check if it does correspond to the same uid.  If so,
 * allow that as an alias for the uid.
 */
 
...so perhaps there's some information that I've discarded before that
point.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#515609: ncurses-base: in linux terminfo data, smacs and rmacs are incorrect

[Thomas Dickey]

On Tue, Mar 27, 2012 at 05:15:10PM +0200, Sven Joachim wrote:
> On 2009-02-16 14:47 +0100, Vincent Lefevre wrote:
> 
> > Package: ncurses-base
> > Version: 5.7+20090207-1
> > Severity: normal
> >
> > In the linux terminfo data: smacs=\E[11m and rmacs=\E[10m
> > However the correct values are: smacs=^N and rmacs=^O
> 
> This has been implemented in the 20110716 patchlevel and in the Debian
> 5.9-5 release, however it causes rather bad breakage in non-UTF-8
> locales.  For instance, Midnight Commander displays funny characters
> instead of nice line drawings with LC_ALL=C, and bug #665959 mentions a
> similar problem in Mutt.

hmm - I didn't notice that problem (or perhaps I did - see the 20110910 change
below).

Because ncurses won't _use_ the rmacs/smacs strings when it's running on Linux
console in UTF-8 mode, then it sounds as if the change was entirely incorrect
and should be reverted.

I did (later than the patch level you mentioned) make this choice configurable
(assuming that the kernel for the build is comparable to the system on which it
is installed):

20110910
+ modify misc/gen_edit.sh to select a "linux" entry which works with
  the current kernel rather than assuming it is always "linux3.0"
  (cf: 20110716).

If the problem is simply from using pre-3.0 kernels, then that could be
addressed using the gen_edit.sh change.

Regarding smacs/rmacs, see "man ncurses" -

   NCURSES_NO_UTF8_ACS
During initialization, the  ncurses  library  checks  for  special
cases  where  VT100  line-drawing (and the corresponding alternate
character set capabilities) described in the terminfo are known to
be  missing.   Specifically,  when  running in a UTF-8 locale, the
Linux console emulator and the GNU screen  program  ignore  these.
Ncurses checks the TERM environment variable for these.  For other
special cases, you should set this  environment  variable.   Doing
this  tells  ncurses to use Unicode values which correspond to the
VT100 line-drawing glyphs.   That  works  for  the  special  cases
cited, and is likely to work for terminal emulators.

When  setting this variable, you should set it to a nonzero value.
Setting it to zero (or to a nonnumber) disables the special  check
for Linux and screen.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665959: ncurses-base: linux console can't display ACL's anymore

[Thomas Dickey]

On Tue, Mar 27, 2012 at 08:10:42PM +0200, Elimar Riesebieter wrote:
> * Sven Joachim  [2012-03-27 19:54 +0200]:
> 
> > Am 27.03.2012 um 17:34 schrieb Elimar Riesebieter:
> > 
> > > * Sven Joachim  [2012-03-27 17:06 +0200]:
> [...]
> > >> This combination is asking for trouble since you will generally not be
> > >> able to display non-ASCII characters with it.  At least LC_MESSAGES and
> > >> LC_CTYPE must both be set to a UTF-8 locale or both to a legacy locale.
> > >
> > > Exporting LC_ALL=de_DE.utf8 doesn't display ACS characters here.
> > 
> > You have to put the console into unicode mode first, e.g. by running
> > unicode_start.  Does it work then?
> 
> Mostly. German Umlauts and € (Euro-Sign) isn't accepted.

hmm, Linux's UTF-8 support isn't that extensive, but I'd thought Umlauts would 
work.

But if your kernel's "3.3", supposedly it supports proper SI/SO controls.

ncurses uses the locale-encoding value based on the locale settings.
In spite of the explicit LC_CTYPE, that's determined in this case
by the LANG setting, i.e., UTF-8.

If your locale doesn't look like UTF-8 encoding to ncurses (and if the
console isn't in UTF-8 mode), then it's supposed to handle line-drawing.

A drawback to doing that would be in editing text, etc.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665959: ncurses-base: linux console can't display ACL's anymore

[Thomas Dickey]

On Tue, Mar 27, 2012 at 04:58:42PM -0400, Thomas Dickey wrote:
> On Tue, Mar 27, 2012 at 08:10:42PM +0200, Elimar Riesebieter wrote:
> > * Sven Joachim  [2012-03-27 19:54 +0200]:
> > 
> > > Am 27.03.2012 um 17:34 schrieb Elimar Riesebieter:
> > > 
> > > > * Sven Joachim  [2012-03-27 17:06 +0200]:
> > [...]
> > > >> This combination is asking for trouble since you will generally not be
> > > >> able to display non-ASCII characters with it.  At least LC_MESSAGES and
> > > >> LC_CTYPE must both be set to a UTF-8 locale or both to a legacy locale.
> > > >
> > > > Exporting LC_ALL=de_DE.utf8 doesn't display ACS characters here.
> > > 
> > > You have to put the console into unicode mode first, e.g. by running
> > > unicode_start.  Does it work then?
> > 
> > Mostly. German Umlauts and € (Euro-Sign) isn't accepted.

A simpler solution would be to set TERM to the older entry,
i.e., "linux2.2".

As I recall, the main reason why the change for #515609 was accepted was
considering the non-ncurses uses (such as termcap applications and slang).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#666213: lynx: large file sizes are truncated in directory listings

[Thomas Dickey]

On Thu, Mar 29, 2012 at 08:48:29PM +0200, Frank Heckenbach wrote:
> Package: lynx
> Version: 2.8.8dev.5-1
> Severity: normal
> Tags: lfs upstream
> 
> *** Please type your report below this line ***
> 
> In a directory listing, sizes of files >2 GB are printed mod 4 GB
> (even negative, if it happens to be).

thanks.

When I made fixes for this area ~2006, I hadn't any files (or filesystems)
large enough to test the display aspect.  Now I do, and can reproduce this
problem (on a 64-bit machine...).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#554167: Updating Mawk in Debian

[Thomas Dickey]

On Mon, May 28, 2012 at 02:48:02PM -0500, Jonathan Nieder wrote:
> Hi Yann,
> 
> yannubu...@gmail.com wrote:
> 
> > any news about updating Mawk with the last upstream version?
> 
> I don't think it can happen and be properly tested in time for wheezy.
> The new upstream version has significant changes relative to the
> packaged version and probably introduces some (minor or not)
> regressions.  (For example, the -W i option didn't work in Turkic
> locales the last time I checked, because toupper('i') is not 'I'.)
> 
> What would be very helpful is code review.  For example, collect
> a batch of twenty or so patches (e.g., changes up to 1.3.3-20090705)
> from [1] or straight from Thomas.  File a bug that lists the patches,
> their purpose, potential regressions, and how that potential can be
> mitigated.  Then I would be happy to help get those patches applied
> in experimental.

I don't recall seeing any comments from Steve on this.
 
> Another way to help is to get the code history up to the present in a
> readable state, to help that same effort.  That basically means:
> 
>  * improve the "rcs fast-export" tool[2].  All improvements are good. :)

It needs work.  I commented on what I'd done a couple of months ago,
but saw no replies.  (At the moment I'm actually working on mawk).

>Packaging it for Debian would be great because then we get a
>bugtracker.  If you can get the raw RCS files to test changes, that
>might make this task easier.

I have in mind creating a git-bundle using my fixed-up rcs-fast-export
(as an export-only...).

>  * collect more changes (in RCS or git bundle form) and let me know
>so I can update [1] to include the updated code.
> 
> Testing is of course also welcome.
> 
> Hope that helps,
> Jonathan
> 
> [1] http://git.debian.org/?p=users/jrnieder-guest/mawk-historical.git
> [2] http://wok.oblomov.eu/tecnologia/rcs-fast-export/
> 
> 

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#554167: Updating Mawk in Debian

[Thomas Dickey]

On Mon, May 28, 2012 at 03:35:47PM -0500, Jonathan Nieder wrote:
> (culling cc list)
> Thomas Dickey wrote:
> 
> > I have in mind creating a git-bundle using my fixed-up rcs-fast-export
> > (as an export-only...).
> 
> Thanks.  Please let me know when it's ready and I can publish it in
> the same place as the earlier export.

ok.  Will do that after I get done with my current change...
It's related to this:
http://sources.redhat.com/ml/libc-alpha/2007-12/msg00028.html

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#554167: Updating Mawk in Debian

[Thomas Dickey]

On Mon, May 28, 2012 at 03:35:47PM -0500, Jonathan Nieder wrote:
> (culling cc list)
> Thomas Dickey wrote:
> 
> > I have in mind creating a git-bundle using my fixed-up rcs-fast-export
> > (as an export-only...).
> 
> Thanks.  Please let me know when it's ready and I can publish it in
> the same place as the earlier export.

hmm.  I think it's more complicated than that.  I've created a git-bundle,
but it requires some discussion.  Here's a recap:

+ I spent a chunk of time in January working with rcs-fast-export,
  and setup a script to fixup the email addresses, to make the logs
  work as expected.  I modified rcs-fast-export to accept an option
  which makes it resolve the RCS identifiers properly.  (You may
  recall from earlier discussion that the identifiers _stored_ in
  the archive are from the previous data, rather than the actual
  revision).  That's slower to execute, of course.

+ In January I also worked (without much success) to develop a
  script to splice my changes onto a copy of the git bundle that
  you had published.  There is more than one apparent problem
  (aside from my own lack of git experience).  With or without
  the corrected RCS identifiers, the process fails due to merge
  problems.  I recall that this only gets about 60% through the
  import.  (I can of course provide you with the corresponding
  scripts, and we can discuss better approaches to the problem).

+ Not having progress on git (and having agreed to provide that),
  the dependent activities were stalled.  However, I'm back on
  mawk for a few weeks.  As I indicated, I noticed an interesting
  problem using mawk in a case where it's a matter of implementing
  a gawk-extension.

  I can see that extension would be a distraction (so I put it
  aside for the moment).

+ On a related thread, it was suggested that I get mawk into
  savannah for using bug-tracking.  When I investigated that,
  I noticed that they rather insist on having each file marked
  with copyrights.  Both Mike and I had not done that as rigorously
  as I think savannah wants.  So... I made that change on top of
  my 20101207 tag, calling that 20101210 (and kept the timestamps
  on that date to avoid confusing git further).  The tag is "old"
  of course since it's solely done to mark copyrights as of that
  date, and to avoid confusion with other changes that I have in
  mind.

  I put the mawk bundle for that in
ftp://invisible-island.net/GIT/
  and uploaded that version as a new release on my webpage.
  
  I think those are enough pieces in place that I can followup on
  savannah; but have an idea that we need some discussion on how
  to proceed for your idea of providing patches based on git.
  (It would be nice if there were some way to record the transformation
  from my rcs/git archive into yours so that I could generate a better
  export).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#554167: Updating Mawk in Debian

[Thomas Dickey]

On Wed, May 30, 2012 at 03:04:01PM -0500, Jonathan Nieder wrote:
> Thomas Dickey wrote:
> 
> > I've created a git-bundle,
> > but it requires some discussion.
> 
> Neat.  My first impressions are that this looks nicer --- e.g., the
> initial check-ins have meaningful messages now instead of just saying
> RCS_BASE.
> 
> Do I understand correctly that this covers the same revision history
> as the old bundle (i.e., up to 2010-12-07), just imported more
> accurately?

yes, except:
there's a t20101210 label for the copyrights

In reviewing the bundle with gitk, I noticed a "t20080909-base" 
label which I seem to recall applying to help with my scripting
in January (not used currently).

The content of the commits in git is accurate (pulling out a label would
give identical results to the corresponding release from rcs).

> [...]
> > + In January I also worked (without much success) to develop a
> >   script to splice my changes onto a copy of the git bundle that
> >   you had published.  There is more than one apparent problem
> >   (aside from my own lack of git experience).  With or without
> >   the corrected RCS identifiers, the process fails due to merge
> >   problems.  I recall that this only gets about 60% through the
> >   import.  (I can of course provide you with the corresponding
> >   scripts, and we can discuss better approaches to the problem).
> 
> Yes, I'd be happy to look at the scripts (feel free to send a private
> email).

will do...
 
> [...]
> > + On a related thread, it was suggested that I get mawk into
> >   savannah for using bug-tracking.  When I investigated that,
> >   I noticed that they rather insist on having each file marked
> >   with copyrights.  Both Mike and I had not done that as rigorously
> >   as I think savannah wants.  So...
> 
> Oh.  I didn't know Savannah was so picky.  I guess it would also be
> useful for other pedantic legal teams that aren't willing to review
> the source control logs.

They have a checklist...
 
> > I made that change on top of
> >   my 20101207 tag, calling that 20101210 (and kept the timestamps
> >   on that date to avoid confusing git further).  The tag is "old"
> >   of course since it's solely done to mark copyrights as of that
> >   date, and to avoid confusion with other changes that I have in
> >   mind.
> 
> When did you make this change?  If not December of 2010, this is very
> confusing, so in that case please add a note to CHANGES mentioning
> when it happened.  I think it's ok if the version number doesn't match
> the date but the date should be recorded somewhere.

hmm - I can add a note in a checkin-comment (the CHANGES file is generated) and
reissue the bundle if you like.  (Having more than a hundred rcs id's saying
2012 on files using 2010 copyrights is not one of my preferred solutions).
 
> [...]
> >   I think those are enough pieces in place that I can followup on
> >   savannah; but have an idea that we need some discussion on how
> >   to proceed for your idea of providing patches based on git.
> >   (It would be nice if there were some way to record the transformation
> >   from my rcs/git archive into yours so that I could generate a better
> >   export).
> 
> Yeah, unfortunately most of my tweaks were manual (e.g., splitting
> changes produced by the "indent" program from semantic changes).  It
> would probably be possible to automate if I were less lazy.

hmm - I'll followup on this

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#554167: Updating Mawk in Debian

[Thomas Dickey]

On Wed, May 30, 2012 at 05:03:56PM -0400, Thomas Dickey wrote:
> hmm - I can add a note in a checkin-comment (the CHANGES file is generated) 
> and
> reissue the bundle if you like.  (Having more than a hundred rcs id's saying
> 2012 on files using 2010 copyrights is not one of my preferred solutions).

sorry - too many programs: mawk's CHANGES is not generated ;-)

either way, I can add a note

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#675433: xterm: terminal bell randomly stops and requires a reboot to get back

[Thomas Dickey]

On Thu, May 31, 2012 at 11:53:05PM -0700, David Griffith wrote:
> Package: xterm
> Version: 278-1
> Severity: normal
> 
> After a normal bootup, the terminal bell with Xterm works as expected.  
> After some time it stops.  This happens with RXVT, Gnome Terminal, and 
> XFCE Terminal.  The problem does not appear to be related to starting or 
> stopping any sort of audio-using program.  While this isn't a 
> showstopping bug, I feel it must definitely be cured before declaring 
> Wheezy ready for promotion to Stable.

If it happens with all of those, it's not xterm-specific (nor specific to
xlibs).  Sounds more like a problem with the desktop or window manager.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#675465: diffstat doesn't handle svn diff with spaces in path

[Thomas Dickey]

On Sat, Jun 02, 2012 at 07:01:08PM +0200, Sandro Tosi wrote:
> forwarded 675465 dic...@invisible-island.net
> thanks
> 
> Hello Stuart,
> thanks for the patch.
> 
> Dear Thomas,
> I've just received a patch for the diffstat Debian package to fix a
> bug when the svn diff has a space in the pathname. I'm going to
> include in the package, would you consider its inclusion in the next
> release of diffstat?

hmm (I did see it via google yesterday).  I just ran a quick test,
and it didn't change any of the existing test results (good).
For 1.56, I'll have to explore some additional testcases (in case
it's svn-specific) but it's okay for now (thanks).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#670638: #670638 xterm color options no longer work with 278-1 in Debian Testing

[Thomas Dickey]

This is fixed in patch #279

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#670638: #670638 xterm color options no longer work with 278-1 in Debian Testing

[Thomas Dickey]

On Fri, May 11, 2012 at 04:33:43AM -0400, Justin Piszcz wrote:
> Hi,
> 
> Thanks for the update!

no problem (report bugs).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#611487: #611487 xterm: immediately exits upon running: exec login USER

[Thomas Dickey]

xterm patch #279 implements the improvement I suggested.  To actually fix
the problem reported will take further changes, to libutempter itself.
(I might do that, though iirc libutempter lacks a maintainer...).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#671227: ncurses-term: glitches in bterm

[Thomas Dickey]

On Sun, May 13, 2012 at 01:15:50AM +0200, Samuel Thibault wrote:
> Hello,
> 
> Sven Joachim, le Wed 02 May 2012 17:13:07 +0200, a ?crit :
> > |   acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', 
> > 'aajjkkllmmqqttuuxx'.
> 
> > |   op: NULL, '\E49;39m'.
> 
> This is the culprit.
> 
> > |   sgr: '\E[0m%?%p1%t\E[7m%;%?%p2%t\E[4m%;', NULL.
> > `
> > 
> > There are comments in ncurses' misc/terminfo.src regarding the
> > differences in acsc and sgr:
> > 
> > ,
> > | # Notes:
> > | # bterm only supports acs using wide-characters, has case for these: 
> > qjxamlkut
> > | # bterm does not support sgr, since it only processes one parameter -TD
> 
> for the same reason as sgr: \E49;39m is two parameters, which bterm can
> not grok. Dropping 'op' makes the glitches go away.

oh.  Actually there are two errors: the string is also missing '[' after
the 'E'.  I'll put out an improved version in tonight's patch (which I
was almost done with...).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#671227: ncurses-term: glitches in bterm

[Thomas Dickey]

On Sun, May 13, 2012 at 11:09:47AM +0200, Samuel Thibault wrote:
> Sven Joachim, le Sun 13 May 2012 10:31:29 +0200, a ?crit :
> > So now we have op=\E[49m\E[39m which does not resemble anything else in
> > terminfo.src.  Samuel, does it work?
> 
> Yes it does. I had some other glitch, but that was due to a color
> configuration in my .muttrc which was not taking into account that the
> default might be black on white, and not white on black.

sounds good.

I recall making that typo before, should add a warning to tic's checking, e.g.,
\E followed by something other than a digit or one of the special cases which
correspond to a C1 control.  It would take some tuning to make it usable
though...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#668208: lynx: Support for TLS server name indication (http, ftp)

[Thomas Dickey]

On Mon, Apr 09, 2012 at 07:57:47PM +0200, kwadronaut-deb...@riseup.net wrote:
> Package: lynx
> Version: 2.8.8dev.5-1
> Severity: important

hmm - that's a feature request, which makes it either normal (functionality
which is essentially reporting that a nonessential feature is broken), or
wishlist (new functionality).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#224268: #224268 lynx: Very long lines have been truncated!

[Thomas Dickey]

This was fixed in 2.8.8dev.12, which is in testing.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#559542: #559542 lynx: CTRL-R (reload) does not work with # (hash) in URL

[Thomas Dickey]

This is fixed in 2.8.8dev.12

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#670638: xterm color options no longer work with 278-1 in Debian Testing

[Thomas Dickey]

On Fri, Apr 27, 2012 at 09:55:01AM -0400, Justin Piszcz wrote:
> Package: xterm
> Version: 278-1
> 
> Hello,
> 
> After a recent upgrade of xterm (278), text no longer shows up in
> xterm with the options I normally use:
> 
> xterm -bg black -fg white
> 
> The screen is black in xterms now, it does not honor the foreground
> color?  Unless I run it without these arguments, I have downgraded to
> xterm 261 (still in the FTP dir) and all works normally again.

I don't see this behavior in an update to Debian/unstable, or Debian/testing.
It's possible that there's some X resource setting on your machine which
has foreground pre-set, making it impossible to override.  That would be
either a local customization, or some desktop junk (KDE's been an offender
in this area, for instance).  Some details about the X resources, e.g.,
as seen by appres and the window manager/desktop might show the problem.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#670638: xterm color options no longer work with 278-1 in Debian Testing

[Thomas Dickey]

On Sat, Apr 28, 2012 at 05:52:55AM -0400, Justin Piszcz wrote:
> On Fri, Apr 27, 2012 at 9:49 PM, Thomas Dickey  wrote:
> > On Fri, Apr 27, 2012 at 09:55:01AM -0400, Justin Piszcz wrote:
> >> Package: xterm
> >> Version: 278-1
> >>
> >> Hello,
> >>
> >> After a recent upgrade of xterm (278), text no longer shows up in
> >> xterm with the options I normally use:
> >>
> >> xterm -bg black -fg white
> >>
> >> The screen is black in xterms now, it does not honor the foreground
> >> color? ?Unless I run it without these arguments, I have downgraded to
> >> xterm 261 (still in the FTP dir) and all works normally again.
> >
> > I don't see this behavior in an update to Debian/unstable, or 
> > Debian/testing.
> > It's possible that there's some X resource setting on your machine which
> > has foreground pre-set, making it impossible to override. ?That would be
> > either a local customization, or some desktop junk (KDE's been an offender
> > in this area, for instance). ?Some details about the X resources, e.g.,
> > as seen by appres and the window manager/desktop might show the problem.
> 
> Hi,
> 
> I found the root cause, when using vnc, if you use "-depth 24" when
> starting vncserver, the text will be black.  When "-depth 24" is not
> specified, it honors the background color.
> 
> What is interesting is vnc has not changed and the older version of
> xterm  (267) did not exhibit the issue w/ vnc when  "-depth 24" was
> specified.
> 
> The new version works as long as "-depth 24" is not specified.
> 
> How to reproduce:
> 1. Install Debian Testing x86_64
> 2. Install vnc4server 4.1.1+X4.3.0-37
> 3. Run: vncserver -geometry 1024x768 -depth 24
> 4. Make sure xterm 278-1 is installed (debian/testing)
> 5. /usr/bin/xterm -bg black -fg white
> 6. Then you can kill that vnc and re-run it without the -depth 24 and
> it works fine.
> 
> Seems like an xterm/vnc/color/depth bug?  When the default is used
> (-depth 16) the text appears properly and the background color is
> honored.

That's probably related to this change from #277:

 * add  a  workaround  for  XAllocColor(),  which  does  not actually
   allocate  "a read-only colormap entry corresponding to the closest
   RGB   value  supported  by  the  hardware",  but  rather  a  rough
   approximation (Debian #650291).

...and I'll see if I can reproduce the effect you're describing.  The
fix might be as simple as excluding depth 24 from the workaround.

In a quick check, I don't see any fixes for regressions relative to #276,
so you might be able to upgrade to _that_ version.  (I'm near the end of
a large change for #279).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#671227: ncurses-term: glitches in bterm

[Thomas Dickey]

On Wed, May 02, 2012 at 05:13:07PM +0200, Sven Joachim wrote:
> Package: ncurses-term
> Version: 5.9-7
> Severity: normal
> 
> On 2012-05-01 12:12 +0200, Samuel Thibault wrote:
> 
> > There is however apparently a discrepancy between the
> > bogl-provided bterm and the ncurses-provided bterm (I assumed that they
> > were the same, but they are not), resulting in quite a few glitches e.g.
> > in mutt. The ncurses one is probably outdated, we will have to fix that.

It would be nice to have details (or a screenshot).
 
> Running infocmp shows the following differences (bterm-bogl being the
> file from bogl 0.1.18-6, bterm-ncurses the file from ncurses-term
> 5.9-7):
> 
> ,
> | comparing bterm-bogl to bterm-ncurses.
> | comparing booleans.
> | comparing numbers.
> | comparing strings.
> | acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', 
> 'aajjkkllmmqqttuuxx'.
> | op: NULL, '\E49;39m'.
> | sgr: '\E[0m%?%p1%t\E[7m%;%?%p2%t\E[4m%;', NULL.
> `
> 
> There are comments in ncurses' misc/terminfo.src regarding the
> differences in acsc and sgr:
> 
> ,
> | # Notes:
> | # bterm only supports acs using wide-characters, has case for these: 
> qjxamlkut
> | # bterm does not support sgr, since it only processes one parameter -TD
> `

right (I read the source-code using the Debian package as a reference,
and that's accurate enough barring updates past my review at the end of 2009).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#670436: override or add to key bindings by adding to the configuration file

[Thomas Dickey]

On Wed, Apr 25, 2012 at 05:42:45PM +0200, Jordi Pujol wrote:
> Package: dialog
> Version: 1.1-20120215-1
> Severity: normal
> 
> the configuration file /etc/jobadmin.d/dialogrc.conf adds key bindings to 
> some 
> keys, It occurs from version 1.1-20111018,
> 
> DIALOGRC=/etc/jobadmin.d/dialogrc.conf dialog --stdout ...
> 
> the command is attached in file "test.sh.
> 
> debug shows that this bindings are added but the form does not use them.
> 
> Regards,
> 
> Jordi Pujol

> bindkey formbox F1 HELP
> bindkey formbox ^H HELP
> bindkey formbox F5 EXTRA
> bindkey formbox ^R EXTRA
> bindkey formbox F10 OK
> bindkey formbox ^O OK
> bindkey formbox F12 CANCEL
> bindkey formbox ^C CANCEL

something like that.  The form only uses certain keycodes; it is not using the
ones that your are binding.

In the log, dialog shows the bindings which are built-in:

# key bindings for formbox widgets
bindkey formbox ^E HELPFILE
bindkey formbox F1 HELPFILE
bindkey formbox HELP HELPFILE
bindkey formbox ^J ENTER
bindkey formbox ^M ENTER
bindkey formbox ENTER ENTER
bindkey formbox ^I FIELD_NEXT
bindkey formbox BTAB FIELD_PREV
bindkey formbox ^N ITEM_NEXT
bindkey formbox DOWN ITEM_NEXT
bindkey formbox NEXT ITEM_NEXT
bindkey formbox ^P ITEM_PREV
bindkey formbox PREVIOUS ITEM_PREV
bindkey formbox UP ITEM_PREV
bindkey formbox NPAGE PAGE_NEXT
bindkey formbox PPAGE PAGE_PREV

Each widget has a case-statement which corresponds to the last column.
It can actually have more symbols than show up in the log (if I overlook
making a widget-specific binding for something).  The reverse is true -
the binding list could include something that is not handled by the widget.
That's because of the way I've built up the binding lists - not all of the
keycodes are applicable in some special cases. -- I don't have an automatic
way to check for these; though I can conceive of some way to construct an
analysis script (more work;-).

The formbox widget uses two sets of bindings - the "formbox" ones, and
"formfield" (also in the log).  The formfield bindings are used when it's
reading from the form fields in the grid, while formbox handles input from the
buttons (outside the grid). --- This is in the manpage, by the way.

In the widget, those are two lists built up with macros:

static DLG_KEYS_BINDING binding[] = {
HELPKEY_BINDINGS,
ENTERKEY_BINDINGS,
NAVIGATE_BINDINGS,
END_KEYS_BINDING
};

static DLG_KEYS_BINDING binding2[] = {
INPUTSTR_BINDINGS,
HELPKEY_BINDINGS,
ENTERKEY_BINDINGS,
NAVIGATE_BINDINGS,
END_KEYS_BINDING
};

Within those lists, it's possible to have duplicates.  dialog simply
uses the first match.  INPUTSTR_BINDING is actually handled in a common
function (below the widget), as is HELPKEY_BINDINGS.

The HELP/EXTRA/OK/CANCEL codes are not in those lists.  They are tested
as a special case only if the key is not already mapped to something.
F1 is mapped to HELPFILE.  However, if you add the same bindings to
formfield, then it'll work as you expect:

bindkey formfield F1 HELP
bindkey formfield ^H HELP
bindkey formfield F5 EXTRA
bindkey formfield ^R EXTRA
bindkey formfield F10 OK
bindkey formfield ^O OK
bindkey formfield F12 CANCEL
bindkey formfield ^C CANCEL

I did mention before that I should make a table to show which keycodes
are applicable to each widget.  The discussion of widget names in the
binding section of the manpage was a start.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#670436: override or add to key bindings by adding to the configuration file

[Thomas Dickey]

On Thu, Apr 26, 2012 at 07:50:18AM +0200, Jordi Pujol wrote:
> Hello Thomas,
> 
> correct,
> this configuration has solved the problem.
> 
> Thanks for your help,

no problem (I'll use my notes to improve the manpage - that part about
OK/CANCEL bindings is awkward and should be explained there).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#676461: libncursesw5: buggy test causes select() to be used instead of poll(), making ncurses really slow

[Thomas Dickey]

On Thu, Jun 07, 2012 at 06:42:24AM +, shawn wrote:
> Package: libncursesw5
> Version: 5.9-8
> Severity: important
> Tags: upstream
> 
> int main() {
> struct pollfd myfds;
> int ret;
> 
> myfds.fd = 0;
> myfds.events = POLLIN;
> 
> ret = poll(&myfds, 1, 100);

Reflecting on it, the check relies on the given file-descriptor and timeout.
Standard input is not redirected.

The check does need a tty though (for Darwin).  The return-code for that might
be a -1 (making a comparison for that case more apt - will have to test).

Almost all of my build-logs (reviewing my build-logs, I see one out of ~60
combinations failing for Linux) for Linux show it working - probably depends
upon the environment.

> If i compile the C test myself, adding a printf at the end, ret==0 after the 
> poll().
> 
> The buildds are returning 
> 
> "checking if poll really works... no"
> 
> yet Linux's poll() is fine.

usually (I seem to recall that the original reason for testing poll vs
select was in fact a buggy implementation on Linux - that's been a while).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#676461: libncursesw5: buggy test causes select() to be used instead of poll(), making ncurses really slow

[Thomas Dickey]

On Thu, Jun 07, 2012 at 01:43:11PM +0200, Sven Joachim wrote:
> On 2012-06-07 12:51 +0200, Thomas Dickey wrote:
> 
> > On Thu, Jun 07, 2012 at 06:42:24AM +, shawn wrote:
> >> Package: libncursesw5
> >> Version: 5.9-8
> >> Severity: important
> >> Tags: upstream
> >> 
> >> int main() {
> >> struct pollfd myfds;
> >> int ret;
> >> 
> >> myfds.fd = 0;
> >> myfds.events = POLLIN;
> >> 
> >> ret = poll(&myfds, 1, 100);
> >
> > Reflecting on it, the check relies on the given file-descriptor and timeout.
> > Standard input is not redirected.
> >
> > The check does need a tty though (for Darwin).  The return-code for that 
> > might
> > be a -1 (making a comparison for that case more apt - will have to test).
> >
> > Almost all of my build-logs (reviewing my build-logs, I see one out of ~60
> > combinations failing for Linux) for Linux show it working - probably depends
> > upon the environment.
> 
> I am surprised to read that, since the test has apparently always failed
> not only on the Debian buildds, but also in Fedora[1].  For me it also
> fails unless stdin is redirected.

I don't know either: I last changed that check (CF_FUNC_POLL) at the end of
January (to add the check for /dev/null), and have rebuilt most platforms since
then.  The previous version is from 2006.

I build everything essentially in the same way (redirecting stdout/stderr,
running as non-root except for installs), and see exactly one Linux failure,
for Debian 6.0 64-bits (the other failures are for Darwin and MinGW).

Most of the builds do more than one configuration.  The single failure,
now that I'm looking closely at the log, is for cross-compiling to MinGW.
So there's actually no failure that I can see here (ymmv)

I've also built with Debian 6.0 32-bits, Debian 5, unstable and testing
(the test says that poll works).  Also Fedora 13-16 (same result), as
well as Arch, CentOS (4-6), Mandriva, OpenSuSE (11 and 12), Slackware, and
Ubuntu.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#676461: libncursesw5: buggy test causes select() to be used instead of poll(), making ncurses really slow

[Thomas Dickey]

On Fri, Jun 08, 2012 at 09:58:00PM +0200, Sven Joachim wrote:
> Do you also redirect stdin?  Otherwise it's hard to get a non-zero

no - just stdout/stderr

On the other hand, rpm and dpkg build tools can redirect things as well.

> result from poll(): you have to manage pressing the return key during
> the 100 milliseconds the test takes, it seems.

The exit code is inverted: it is true if nonzero, which could be
-1 or some number greater than zero (the latter would indicate some
input happening, though which of the cases is hard to tell).

The ret==0 that was noted before would make the test succeed.

I've modified the test to fix the two issues that I could see,
and made rpm/dpkg scripts which did fail, but now work with the
changed test.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#676461: libncursesw5: buggy test causes select() to be used instead of poll(), making ncurses really slow

[Thomas Dickey]

On Sat, Jun 09, 2012 at 10:36:00AM +0200, Sven Joachim wrote:
> On 2012-06-09 09:47 +0200, Sven Joachim wrote:
> 
> > On 2012-06-09 01:51 +0200, Thomas Dickey wrote:
> >
> >> The exit code is inverted: it is true if nonzero, which could be
> >> -1 or some number greater than zero (the latter would indicate some
> >> input happening, though which of the cases is hard to tell).
> >
> > Aah, of course.  Now this makes sense even to me.
> 
> However, I still have some problems understanding the test: in the
> "else" branch, isn't it guaranteed that ret >= 0, no matter what?
> The following makes more a bit more sense to me:

man poll:

RETURN VALUE
   On success, a positive number is returned; this is the number of struc-
   tures  which  have  non-zero  revents  fields  (in  other  words, those
   descriptors with events or errors reported).  A value  of  0  indicates
   that  the call timed out and no file descriptors were ready.  On error,
   -1 is returned, and errno is set appropriately.
 
> --8<---cut here---start->8---
> diff --git a/aclocal.m4 b/aclocal.m4
> index f5a7260..304ddba 100644
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -1730,7 +1730,7 @@ int main() {
>   myfds.revents = 0;
>  
>   ret = poll(&myfds, 1, 100);
> - if (ret < 0) {
> + if (ret > 0) {
>   ret = 0;
>   }
>   }
> --8<---cut here---end--->8---
> 
> Or, since you no longer check for ret != 0, but rather ret < 0 at the
> end:
> 
> --8<---cut here---start->8---
> diff --git a/aclocal.m4 b/aclocal.m4
> index f5a7260..9270878 100644
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -1730,9 +1730,6 @@ int main() {
>   myfds.revents = 0;
>  
>   ret = poll(&myfds, 1, 100);
> - if (ret < 0) {
> - ret = 0;
> - }

ouch - I think you're right.
(for next week - I'm out the rest of the weekend)

>   }
>   ${cf_cv_main_return:-return}(ret < 0);
>  }],
> --8<---cut here---end--->8---
> 
> Also, shouldn't the test check whether opening /dev/tty was actually
> successful?

I assumed in that instance that poll would simply fail :-)
> 
> Cheers,
>Sven
> 
> 

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#645736: Please hide xterm and uxterm icons from the GNOME menu

[Thomas Dickey]

On Tue, 18 Oct 2011, Fabian Greffrath wrote:


Am 18.10.2011 13:56, schrieb Thomas E. Dickey:

I saw that in Ubuntu #129041; however a better fix would be to distribute
the desktop files in a separate package, e.g., "xterm-desktop", which
depends on xterm. There's no argument to the fact that people who would
install that would get what they're asking for, without being filtered
through the biases of the gnome developers.


Not installing the desktop files will raise other issues, c.f. 
. So, please keep them 
in the xterm package but hide them from the menus.


well perhaps there are 3 categories of users:

a) people who intentionally use xterm (and don't mind the menus)
b) people who more/less accidentally run xterm
c) other (probably not gnome developers)

Are you addressing (b)?

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645736: Please hide xterm and uxterm icons from the GNOME menu

[Thomas Dickey]

On Wed, 19 Oct 2011, Fabian Greffrath wrote:


Am 18.10.2011 23:17, schrieb Thomas Dickey:

well perhaps there are 3 categories of users:

a) people who intentionally use xterm (and don't mind the menus)
b) people who more/less accidentally run xterm
c) other (probably not gnome developers)

Are you addressing (b)?


I am not addressing a specific user category and I am not a gnome developer. 
It is just a matter of fact that gnome (and kde, xfce and lxde, btw) have 
their own well integrated terminal applications and thus xterm should not 
show up as an additional alternative in the menus *in these desktop 
environments*.


Without further qualifications then, you appear to be suggesting that only
applications which are part of gnome should be allowed to show up in its
menus (for instance emacs isn't).  To pointedly *exclude* xterm, there 
should be some better justification than that it's not part of gnome.


awai

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645736: Please hide xterm and uxterm icons from the GNOME menu

[Thomas Dickey]

On Wed, 19 Oct 2011, Fabian Greffrath wrote:


Am 19.10.2011 10:23, schrieb Thomas Dickey:

Without further qualifications then, you appear to be suggesting that
only
applications which are part of gnome should be allowed to show up in its
menus (for instance emacs isn't). To pointedly *exclude* xterm, there
should be some better justification than that it's not part of gnome.\


..snip

you didn't answer my question - you only repeated your previous statement.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645736: Please hide xterm and uxterm icons from the GNOME menu

[Thomas Dickey]

On Wed, 19 Oct 2011, Fabian Greffrath wrote:


Am 19.10.2011 11:28, schrieb Thomas Dickey:

On Wed, 19 Oct 2011, Fabian Greffrath wrote:


Am 19.10.2011 10:23, schrieb Thomas Dickey:

Without further qualifications then, you appear to be suggesting that
only
applications which are part of gnome should be allowed to show up
in its
menus (for instance emacs isn't). To pointedly *exclude* xterm, there
should be some better justification than that it's not part of gnome.\


..snip

you didn't answer my question - you only repeated your previous
statement.



Only applications for which there is no appropriate replacement already 
provided as part of GNOME should show up in the GNOME menu.


actually, looking through my .desktop files, I'm not seeing that this
advice is being followed.

Back to my point: why are you singling out xterm?


xterm is replaced by GNOME's own gnome-terminal in every regard. When it


that's an untruthful comment, of course.

bye

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645736: Please hide xterm and uxterm icons from the GNOME menu

[Thomas Dickey]

On Wed, 19 Oct 2011, Fabian Greffrath wrote:


Am 19.10.2011 11:45, schrieb Thomas Dickey:

actually, looking through my .desktop files, I'm not seeing that this
advice is being followed.


For these cases there is still /etc/gnome/menus.blacklist


Back to my point: why are you singling out xterm?


Because it suddenly began to show an icon in the menus and did not before. 
But I am not singling out xterm, it is just that it caught my attention right 
now. I have already filed similar bug reports in the past, e.g. #579160 or 
#579154.



that's an untruthful comment, of course.


Hehe, let's say it's biased. ;)


This might help (I'd seen essentially the same statement more than once, 
though I don't recall which people) - numbers instead of subjective 
comments:


http://invisible-island.net/xterm/xterm.faq.html#compare_versions

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#646072: dialog: 'Segmentation fault' after '--inputbox'

[Thomas Dickey]

On Thu, 20 Oct 2011, A. Costa wrote:


Package: dialog
Version: 1.1-20111018-1
Severity: important

Today after upgrading 'dialog' I find an often used several year old
script (that uses 'dialog') has broken.

Run the following line, then hit 'Enter', or mouse click
on either "OK" or "Cancel":

   % dialog  --inputbox "Edit subject line..."  6 75 "foo bar" ; echo $?
   Segmentation fault
   139


I think this is fixed in 20111020

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#646072: dialog: 'Segmentation fault' after '--inputbox'

[Thomas Dickey]

On Fri, 21 Oct 2011, Santiago Vila wrote:


On Fri, 21 Oct 2011, Thomas Dickey wrote:


On Thu, 20 Oct 2011, A. Costa wrote:


Package: dialog
Version: 1.1-20111018-1
Severity: important

Today after upgrading 'dialog' I find an often used several year old
script (that uses 'dialog') has broken.

Run the following line, then hit 'Enter', or mouse click
on either "OK" or "Cancel":

   % dialog  --inputbox "Edit subject line..."  6 75 "foo bar" ; echo $?
   Segmentation fault
   139


I think this is fixed in 20111020


Yes, I've checked and the segfault no longer happens, so I've closed
this bug in the 20111020 upload I've just made.

(However, I have not looked at the code, so I don't know why it
segfaulted, and I don't know why it no longer does. I leave this to
you :-)


I didn't dig down, but from the scenario it's probably the case where 
dialog's freeing sub-windows.  One of those where it seemed to work for 
the 3-4 days after I made the change...


(It was easy to spot with valgrind though).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#646977: libncurses5-dev: "Multi-Arch: same" but files differ across architectures

[Thomas Dickey]

On Mon, 31 Oct 2011, Craig Small wrote:


On Fri, Oct 28, 2011 at 11:05:54PM +0200, Sven Joachim wrote:

The value of ETIP_NEEDS_MATH_H is probably dependent on the build
environment, rather than on the architecture.  Craig, do you have any
build logs?

i do, I would not of used pbuilder most likely.


| /tmp/buildd/ncurses-5.9/c++/etip.h.in:116:25: fatal error: ncurses_dll.h: No 
such file or directory
| compilation terminated.
| configure:17659: $? = 1

How strange you get this error.

configure:17630: checking for special defines needed for etip.h
configure:17656: /usr/bin/g++ -c -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security 
-I/home/csmall/debian/ncurses/ncurses/c++ -I/home/csmall/debian/ncurses/ncurses/menu 
-I/home/csmall/debian/ncurses/ncurses/include  -D_GNU_SOURCE -DNDEBUG conftest.cc 
>&5
configure:17659: $? = 0


When building on my normal system, this problem is hidden because
libncurses5-dev is installed, and so the ncurses_dll.h copy in
/usr/include is used:

That seems wrong to me.  It should be using "its own" header file,
shouldn't it?


It should.  I saw something of that sort yesterday, and made a note to 
check on it.  But I've spent most of the weekend working on a change to 
the way _XOPEN_SOURCE is defined (lots of builds to retest).  So it'll 
probably be unresolved in tonight's (expected) patch.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611487: xterm: immediately exits upon running: exec login USER

[Thomas Dickey]

On Tue, Mar 27, 2012 at 06:59:46AM -0400, Thomas Dickey wrote:
> On Mon, Mar 26, 2012 at 06:27:47PM -0400, Jeffrey Sheinberg wrote:
> > Now, when I get a "jsroot" login shell via "su -l jsroot", the following
> > situation exists,
> > 
> > # tty
> > /dev/pts/2
> > 
> > # logname
> > jeff
> > 
> > # var user logname
> > export USER='jsroot'
> > export LOGNAME='jsroot'
> > 
> > # who | grep pts/2
> > jeff pts/2Mar 26 09:18 (:0.0)
> > 
> > And when I then launch an xterm from this "jsroot" login shell on pts/2,
> > I have problems with xterm 261-1 & 276-2, like this,
> > 
> > # tty
> > /dev/pts/6
> > 
> > # logname
> > root
> > 
> > # var user logname
> > export USER='jsroot'
> > export LOGNAME='root'
> > 
> > # who | grep pts/6
> > root pts/6Mar 26 16:12 (:0.0)
> > 
> > while xterm 235-2 works correctly, like this,
> > 
> > # tty
> > /dev/pts/6
> > 
> > # logname
> > jsroot
> > 
> > # var user logname
> > export USER='jsroot'
> > export LOGNAME='jsroot'
> > 
> > # who | grep pts/6
> > jsroot   pts/6Mar 26 16:02 (:0.0)

I can make $USER and $LOGNAME the same in the xterm as in its parent,
but utempter doesn't provide a way to set the user's name which would
show up in "who".  It only has parameters for hostname and pty name.
It fills in the user and date by itself.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665959: ncurses-base: linux console can't display ACL's anymore

[Thomas Dickey]

On Fri, Mar 30, 2012 at 04:43:21PM +0200, Vincent Lefevre wrote:
> On 2012-03-27 17:22:01 -0400, Thomas Dickey wrote:
> > As I recall, the main reason why the change for #515609 was accepted was
> > considering the non-ncurses uses (such as termcap applications and slang).
> 
> Not sure what you mean by "non-ncurses uses", but scripts that
> use the tput command were affected by bug #515609, and tput is
> provided by ncurses-bin.

I distinguish things by what features they use:
ncurses - fullscreen applications (things that rely on libncurses in the
current packaging scheme).
terminfo - things that use the database but do not use ncurses screen
optimization (this includes all of the command-line tools)
termcap - interface provided for compatibility (applications such as
vim and w3m).

terminfo/termcap applications have their own logic.

Elimar's probably can probably be solved by setting TERM to linux2.2

comparing linux2.2 to linux3.0.
comparing booleans.
comparing numbers.
comparing strings.
rmacs: '\E[10m', '^O'.
sgr: 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;11%;m',
 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;'.
sgr0: '\E[0;10m', '\E[m\017'.
smacs: '\E[11m', '^N'.

Sure, \e[11m is "wrong".  But a lot of Linux console is wrong, and
has been for more than 15 years.  SI/SO was deliberately broken in
the late 1990s by the people who added UTF-8 support to Linux console,
and it remained broken for about 10 years.

However, I don't have enough information to see whether changing the
default behavior was a bad idea or a good one.  That comes down to
seeing which group is largest:

a) ncurses users are largely unaffected (except for those doing
   remote logins from one Linux console to another Linux system
   with different kernel versions hence different default TERM
   settings).

   I did spend some time attempting to identify the first kernel
   version in which the SI/SO change _actually_ appeared.  Let's
   not go there - it's enough to point out that by the time it
   was actually delivered, it was at least 5 years overdue ;-)

b) users with workarounds for Linux console quirks (as Elimar
   appears to be) are affected.

c) some unspecified number of users would like to use tput for
   drawing lines (they're affected).  I'd expect only a small
   fraction of those to be slang users (simply because they
   generally would use slang's quirks rather than script with
   tput).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665959: ncurses-base: linux console can't display ACL's anymore

[Thomas Dickey]

On Sun, Apr 01, 2012 at 10:32:59AM +0200, Sven Joachim wrote:
> On 2012-04-01 08:32 +0200, Sven Joachim wrote:
> 
> > How about running a test, e.g. like this:
> >
> > LC_ALL=C dialog --infobox "Line drawing characters garbled" 24 80
> >
> > I see lots of 'Ä' characters at the top/bottom and '³' characters on the
> > left and right margins.
> 
> Incidentally, reverting the rmacs/smacs changes fixes that problem in
> slang applications (mc and whiptail), but not in dialog.  Do I need to
> revert the sgr0 change for that?

yes - it has the same information.
 
> > And what about
> >
> >   e) sysadmins who run their system with LANG=C and see garbage on
> >  the screen now whenever they install a package that asks a
> >  question via debconf?
> >
> > Those are the ones who are affected now.
> 
> I'll probably revert all the linux changes from the 20110716 patch,
> since their outcome seems unacceptable to me.

actually I've made changes to two parts (terminfo.src and the change to
gen_edit.sh - but I recall your patch level is before the latter - 20110910).

(sorry if I seem unresponsive - I didn't see further discussion, was trying
to decide whether to make the 20110910 change explicitly configurable, and was
investigating an issue related to my fix in st-256color).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#665959: ncurses-base: linux console can't display ACL's anymore

[Thomas Dickey]

On Sun, Apr 01, 2012 at 12:30:55PM +0200, Sven Joachim wrote:
> On 2012-04-01 11:51 +0200, Thomas Dickey wrote:
> 
> > On Sun, Apr 01, 2012 at 10:32:59AM +0200, Sven Joachim wrote:
> >> 
> >> I'll probably revert all the linux changes from the 20110716 patch,
> >> since their outcome seems unacceptable to me.
> 
> Thinking about it again, it is probably better to just make the linux
> terminfo entry use linux2.2 by default.  This should keep everyone
> relatively happy, Vincent can then set TERM to linux3.0 if he so
> desires.
> 
> > actually I've made changes to two parts (terminfo.src and the change to
> > gen_edit.sh - but I recall your patch level is before the latter - 
> > 20110910).
> 
> Right, I have just updated the terminfo entries but no other files.  The
> 20110910 change to gen_edit.sh is irrelevant for us anyway, since Debian
> has dropped support for Linux kernels older than 2.6 a few years ago.

okay... (though the SI/SO patch was introduced sometime during the 2.6
series).

For now, I'll change the terminfo.src file (making the default "linux2.2")
and modify gen_edit.sh to provide for a configure-script option.  But I'm
undecided whether the feature is going to have much demand as a configure
script option (so the gen_edit.sh change will simply agree with the default
in the terminfo.src file).

> > (sorry if I seem unresponsive - I didn't see further discussion, was trying
> > to decide whether to make the 20110910 change explicitly configurable, and 
> > was
> > investigating an issue related to my fix in st-256color).
> 
> I'll pick up the st-256color fix later, but for now I have to drop
> st-256color from ncurses-term anyway to solve #665877.

that sounds okay (I did see something of a tangle in upgrades).
I may have other fixes related to use-ordering after I'm done with my
script.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#799910: libtinfo5: Since a recent upgrade, bash complains about libtinfo5 (which destroys some important scripts)

[Thomas Dickey]

On Thu, Sep 24, 2015 at 08:31:05AM +0200, Emmanuel Charpentier wrote:
> Package: libtinfo5
> Version: 6.0+20150810
> Severity: normal
...
> Since a recent upgrade, bash complains about this library lacking version
> information.
> 
> the following message is printed a *lot* during some bash scripts execution :
> 
> bash: /usr/local/sage/local/lib/libtinfo.so.5: no version information 
> available
> (required by bash)

Possibly LD_LIBRARY_PATH is set in user's environment, causing bash
to become confused about which library to use.  I seem to recall that
a Debian guideline for packaging says to not use the rpath feature
(which would prevent this problem).  It is not a bug in ncurses, but
a problem with the user's environment or custom configuration.

As it is, there are a few possible solutions (by the user):

+ repair the environment (i.e., dropping
  /usr/local/sage/local/lib from LD_LIBRARY_PATH)

+ remove the conflicting library from /usr/local/sage/local/lib

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#847479: xterm: display issue with double-width character like ? on the last column via ncurses

[Thomas Dickey]

On Thu, Dec 08, 2016 at 05:37:15PM +0100, Vincent Lefevre wrote:
> Notes:
> 
> The character appears in the subject of this mail, so that you can
> use it as a test case. :)
> 
> The problem doesn't appear with a shell and printf. Thus I assume that
> it may be related to margins and things like that.

Attaching a script, for discussion.  I don't see the problem, but noticed
that the character is "new", and for instance if you were running xterm
remotely so that the wcwidth wasn't known then you could get odd results.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net
#!/usr/bin/env perl

use strict;
use warnings;
use Encode 'encode_utf8';

binmode( STDOUT, ":utf8" );

my $margin = `tput cols`;
my $length = $margin - 8;
for my $n ( 1 .. 10 ) {
for my $m ( 1 .. $length ) {
printf '.';
}
printf "{{%s}}\n", chr(0x1f378);
$length++;
}
printf 'DONE!\n'


signature.asc
Description: Digital signature

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

[Thomas Dickey]

- Original Message -
| From: "Vincent Lefevre" 
| To: "Debian Bug Tracking System" 
| Sent: Sunday, May 7, 2017 1:23:00 PM
| Subject: Bug#862042: xterm: if the faceName resource is defined, the -fn 
(-font) option is ignored
| 
| Package: xterm
| Version: 327-2
| Severity: minor
| 
| If I define the faceName resource, e.g. with
| 
| XTerm*faceName: Monospace
| 
| in the .Xresources file (read by xrdb), then the -fn (-font) option
| is ignored. For instance,
| 
|   xterm -fn 7x13
| 
| has no effect. Options normally override the default resources, but
| this is not the case here. And the observed behavior is not
| documented.

last paragraph in this section:

http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:faceSize

(it's been there quite a while, and won't be changed)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

Bug#847479: xterm: display issue with double-width character like ? on the last column via ncurses

[Thomas Dickey]

- Original Message -
| From: "Vincent Lefevre" 
| To: dic...@his.com, 847...@bugs.debian.org
| Sent: Sunday, May 7, 2017 12:56:32 PM
| Subject: Bug#847479: xterm: display issue with double-width character like ? 
on the last column via ncurses
| 
| On 2017-05-07 10:53:24 -0400, Thomas Dickey wrote:
| > Attaching a script, for discussion.  I don't see the problem, but
| > noticed
| > that the character is "new", and for instance if you were running
| > xterm
| > remotely so that the wcwidth wasn't known then you could get odd
| > results.
| 
| I can't reproduce the problem with your script. But it is
| reproducible
| with Mutt. Maybe a problem that occurs only when margins are used.
| I don't know what ncurses does exactly...
| 
| Everything is local on the machine.


a typescript (from "script") helps.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

[Thomas Dickey]

- Original Message -
| From: "Vincent Lefevre" 
| To: "Thomas Dickey" 
| Cc: 862...@bugs.debian.org
| Sent: Sunday, May 7, 2017 5:13:32 PM
| Subject: Bug#862042: xterm: if the faceName resource is defined, the -fn 
(-font) option is ignored
| 
| On 2017-05-07 16:29:35 -0400, Thomas Dickey wrote:
| > - Original Message -
| > | From: "Vincent Lefevre" 
| > | To: "Debian Bug Tracking System" 
| > | Sent: Sunday, May 7, 2017 1:23:00 PM
| > | Subject: Bug#862042: xterm: if the faceName resource is defined,
| > | the -fn (-font) option is ignored
| > | 
| > | Package: xterm
| > | Version: 327-2
| > | Severity: minor
| > | 
| > | If I define the faceName resource, e.g. with
| > | 
| > | XTerm*faceName: Monospace
| > | 
| > | in the .Xresources file (read by xrdb), then the -fn (-font)
| > | option
| > | is ignored. For instance,
| > | 
| > |   xterm -fn 7x13
| > | 
| > | has no effect. Options normally override the default resources,
| > | but
| > | this is not the case here. And the observed behavior is not
| > | documented.
| > 
| > last paragraph in this section:
| > 
| > 
http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:faceSize
| > 
| > (it's been there quite a while, and won't be changed)
| 
| Sorry, but I don't understand. In particular, this does not
| explain the behavior when none of faceSize resources are set.

Perhaps you'll see it here:

http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:renderFont

Most of xterm's options work by setting resource values (there are a handful
of special cases such as "-help", "-version" which do not).  I can clarify the
manual, but there's no reason to change the program logic (in this bug, 
anyway). 

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

Bug#862042: xterm: if the faceName resource is defined, the -fn (-font) option is ignored

[Thomas Dickey]

- Original Message -
| From: "Vincent Lefevre" 
| To: "Thomas Dickey" 
| Cc: 862...@bugs.debian.org
| Sent: Sunday, May 7, 2017 6:10:47 PM
| Subject: Bug#862042: xterm: if the faceName resource is defined, the -fn 
(-font) option is ignored
| 
| On 2017-05-07 17:24:43 -0400, Thomas Dickey wrote:
| > Perhaps you'll see it here:
| > 
| > 
http://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:renderFont
| > 
| > Most of xterm's options work by setting resource values (there are
| > a
| > handful of special cases such as "-help", "-version" which do not).
| > I can clarify the manual, but there's no reason to change the
| > program logic (in this bug, anyway).
| 
| The behavior is not what is described in this section. I would agree
| if renderFont were "true". But the manual says:
| 
|   The default is "default".
| 
| (and I haven't changed it). For "default":
| 
| startup using the normal (bitmap) font, but enable the
| ^^
| "TrueType Fonts" menu entry to allow runtime switching
| to/from TrueType fonts.
| 
| If there is no faceName resource set, then runtime
| switching to TrueType fonts is disabled.  Xterm has a
| separate  compiled-in value for faceName for the special
| case where renderFont is "default".  That is normally
| "mono".
| 
| So, according to the manual, I should get the bitmap font.

I'll take a closer look, to see where the disagreement lies.

| Moreover, the text for "-fn font" is not sufficient.
| 
| This option specifies the font to be used for displaying normal
| text.  The corresponding resource name is font.  The resource
| value default is fixed.
| 
| First, it is not mentioned that the font must be a bitmap font (?).
| For instance, it does not work with "Monospace". It should also be
| clarified when the -fn option is ignored.

"-fn" is (as noted in the manual page), an "X Toolkit Option", which is
documented in the X manual page, where it expects an XLFD.

https://www.x.org/archive//X11R6.8.2/doc/X.7.html

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

Bug#862148: Lynx: Long search strings to Google get truncated.

[Thomas Dickey]

On Mon, May 08, 2017 at 09:17:22PM -0700, David Lawyer wrote:
> Package: lynx
> Varsion: 2.8.9dev13-l
> 
> When I type in a search string (in English) to Google or Bing and the length 
> of my
> search string is longer than the blank space that Goolge or Bing provides
> for it, the excess part of the string doesn't get typed in (or if it does
> it doesn't get echoed to the screen).  This problem was not present in
> dev11-1.  I suspect that this bug is due to the fix for another bug
> involving the echoing of multi-byte characters #841155 which dev13-1
> fixed.  But it seems that this fix has resulted in a new bug.

I see.  While I'm fixing this case, it would be nice to know if the
original bug report is addressed...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#862148: Lynx: Long search strings to Google get truncated.

[Thomas Dickey]

On Tue, May 09, 2017 at 09:57:56PM -0700, David Lawyer wrote:
> On Tue, May 09, 2017 at 07:48:53PM -0400, Thomas Dickey wrote:
> > On Mon, May 08, 2017 at 09:17:22PM -0700, David Lawyer wrote:
> > > Package: lynx
> > > Varsion: 2.8.9dev13-l
> > > 
> > > When I type in a search string (in English) to Google or Bing and the 
> > > length of my
> > > search string is longer than the blank space that Goolge or Bing provides
> > > for it, the excess part of the string doesn't get typed in (or if it does
> > > it doesn't get echoed to the screen).  This problem was not present in
> > > dev11-1.  I suspect that this bug is due to the fix for another bug
> > > involving the echoing of multi-byte characters #841155 which dev13-1
> > > fixed.  But it seems that this fix has resulted in a new bug.
> > 
> > I see.  While I'm fixing this case, it would be nice to know if the
> > original bug report is addressed...
> Yes, the typing of search terms in Russian (mult-byte characters) worked
> OK in dev13-1 but I probably didn't use long strings.  Thanks for 
> getting it fixed.

okay... I uploaded a new version, which works (for me) for the cases
we've discussed.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#862472: tack: FTBFS: ./tack.h:78:32: error: dereferencing pointer to incomplete type 'TERMINAL {aka struct term}'

[Thomas Dickey]

On Sat, May 13, 2017 at 11:33:13AM +0200, Sven Joachim wrote:
> Source: tack
> Version: 1.07-1
> Tags: buster sid fixed-upstream
> 
> With libncurses5-dev from experimental, tack FTBFS.  From the build log:

This has been fixed upstream:

http://invisible-island.net/ncurses/tack/CHANGES.html#t20170318

2017-03-18

* init.c:
use def_prog_mode() to eliminate two internal details from ncurses

* edit.c, tack.h: accommodate opaque TERMINAL structure in ncurses

(offhand, I'm not aware of other programs than the ones I've fixed,
but the fix in each case is the same, and as far as I'm aware,
my opaque-change was binary-compatible for anything that didn't
store a copy of TERMINAL...).
 
> ,
> | gcc -c -DHAVE_CONFIG_H -I. -I. -Wdate-time -D_FORTIFY_SOURCE=2 
> -DXTSTRINGDEFINES -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/tmp/tack-1.07=. 
> -fstack-protector-strong -Wformat -Werror=format-security control.c
> | In file included from ./tack.h:51:0,
> |  from control.c:22:
> | control.c: In function 'alloc_arrays':
> | ./tack.h:78:32: error: dereferencing pointer to incomplete type 'TERMINAL 
> {aka struct term}'
> |  #define CUR_TP  (&(cur_term->type))
> | ^
> | ./tack.h:79:33: note: in expansion of macro 'CUR_TP'
> |  #define MAX_STRINGS NUM_STRINGS(CUR_TP)
> |  ^~
> | control.c:81:45: note: in expansion of macro 'MAX_STRINGS'
> |pads = (struct test_results **)calloc(MAX_STRINGS, sizeof(struct 
> test_results *));
> |  ^~~
> | Makefile:242: recipe for target '../tack-1.07/control.o' failed
> `
> 
> The reason is the following change in ncurses:
> 
> ,
> | 20170318
> | + change TERMINAL structure in term.h to make it opaque.  Some
> |   applications misuse its members, e.g., directly modifying it
> |   rather than using def_prog_mode().
> `
> 
> The latest upstream snapshot at
> ftp://ftp.invisible-island.net/ncurses/current/tack-1.07-20170318.tgz
> fixes the problem, it might be good to package it after the stretch
> release.  Or persuade upstream to release tack 1.08, since 1.07 is
> already over seven years old.
> 

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#863008: failing to load previously-loaded pages of some websites

[Thomas Dickey]

On Sat, May 20, 2017 at 03:20:21AM +0100, Zefram wrote:
> Package: lynx-cur
> Version: 2.8.9dev1-2+deb8u1
> Severity: important
> 
> Lynx has developed a habit of finding it difficult to load the same web
> page twice in one session, for pages in some websites but not others.

This report doesn't indicate a version where Lynx behaves as you expect.

> Where the bug is in effect, the first loading of any page from an affected
> website works normally, but then any second or subsequent attempt to
> load the same page shortly thereafter fails.  This happens for almost
> any means of invoking a page load: following a link from another page,
> typing in the URL manually, or following a link from the browser's
> "visited links" page.  But page loading succeeds if invoked by following
> a link from the browser's "history" page, by using the "u" command to pop
> the history stack, or by using the ^R command to reload the current page.
> Where page loading fails due to this bug, there is activity in the status
> line that seems to reflect a network request, but then the activity ends
> and the status line returns to normal without changing page, as if the
> request to load the affected page had never been made.

This sounds like the longstanding Lynx behavior: it doesn't automatically
reload a page which has been read and is cached locally.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#863008: failing to load previously-loaded pages of some websites

[Thomas Dickey]

On Sun, May 21, 2017 at 08:39:33PM +0100, Zefram wrote:
> Thomas Dickey wrote:
> >This report doesn't indicate a version where Lynx behaves as you expect.
> 
> Strangely, this misbehaviour doesn't seem to have arrived with a specific
> Lynx version, but developed over time.  I'm sure that the present version
> worked fine on these websites when it was first installed here a year and
> a half ago.  It was definitely working for <https://www.theguardian.com>
> two weeks ago, for which it's not working now.  Presumably this version
> always had the bug, but it's being triggered by some unusual environmental
> condition that has changed over time.  So I never noticed this bug with
> the previously-installed Lynx version, whatever that was, but I don't
> see any reason to think that that version actually lacked the bug.
> 
> If you can't reproduce the problem, I could have a go at compiling a
> bunch of Lynx versions from source to see which ones do this.

That might help.  Also, steps to reproduce the problem.

When I compile my own (equivalent to Debian's package), I use this script:

#!/bin/sh
# $Id: cfg-lynx-debian,v 1.3 2013/10/03 08:37:39 tom Exp $
# settings corresponding to Debian package for lynx-cur
DEBOP="--enable-debug --enable-warnings --disable-echo"
env cf_cv_SYSTEM_MAIL=/usr/sbin/sendmail \
COMPRESS=/usr/bin/compress BZIP2=/bin/bzip2 UNZIP=/usr/bin/unzip \
ZIP=/usr/bin/zip \
LIBS="-lbsd" \
./configure --prefix=/usr --libexecdir=/usr/lib \
--sysconfdir=/etc/lynx-cur --localstatedir=/var \
--libdir=/etc/lynx-cur --enable-8bit-toupper --enable-externs \
--enable-nsl-fork --enable-cgi-links --enable-exec-links \
--enable-exec-scripts --enable-persistent-cookies --enable-nls \
--enable-gzip-help --enable-prettysrc --enable-source-cache \
--enable-cjk --enable-default-colors --enable-nested-tables \
--enable-japanese-utf8 --enable-ipv6 \
--enable-forms-options --enable-justify-elts --enable-partial \
--enable-read-eta --enable-scrollbar --enable-syslog \
--with-zlib --with-bzlib --without-included-gettext \
--with-screen=ncursesw --enable-justify-elts \
--with-gnutls=/usr --enable-persistent-cookies \
${DEBOP} $*

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#780176: [xterm] XTerm and UXTerm appear in Xfce 4.10 main menu twice

[Thomas Dickey]

On Mon, Mar 06, 2017 at 06:33:44PM +0100, Sven Joachim wrote:
> On 2015-03-11 19:04 -0400, Thomas Dickey wrote:
> 
> > On Tue, Mar 10, 2015 at 07:18:31AM +0100, bullgard wrote:
> >> Package: xterm
> >> Version: 312-1
> >> Severity: wishlist
> >> 
> >> --- Please enter the report below this line. ---
> >> XTerm and UXTerm appear in Xfce 4.10 main menu twice. Please decide
> >
> > The xterm package doesn't provide the bits for that menu.
> >
> > Apparently it's Xcfe:
> >
> > If it were coming from xterm, the only possible place would be the 
> > categories
> > in the .desktop file, e.g,. treating Utility as "Accessories", and System
> > as "System".  Given the report, something is missing because half of the
> > entries in my collection of .desktop files for Debian 8 beta which have
> > System also have Utility (after excluding GNOME).  So it can't be that.
> > Otherwise this report would cite all of the cases where the .desktop file
> > could be used that way.
> >
> > If this were a bug that is relevant to xterm, the place to start would
> > be pointing to a relevant Debian policy.
> 
> The Debian policy just references the FreeDesktop specification[1] which
> lists "System", but not "Utility" as a related category of
> "TerminalEmulator".  Both gnome-terminal and konsole follow this advice,
> so maybe it would be good not to mention "Utility" in xterm's .desktop
> file either.
> 
> Cheers,
>Sven
> 
> 
> 1. https://specifications.freedesktop.org/menu-spec/latest/
> 2. https://specifications.freedesktop.org/menu-spec/latest/apas02.html

hmm - I recall using Utility because that was used by Red Hat.

fwiw, a quick check shows Utility unused by Konsole (since introducing
a .desktop file in 2003).

GNOME dropped Utility about 10 years later, in 2013:

https://bugzilla.gnome.org/show_bug.cgi?id=707552

The bug report refers to 3.10

so yes, it's a reasonable change for xterm :-)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#780176: [xterm] XTerm and UXTerm appear in Xfce 4.10 main menu twice

[Thomas Dickey]

On Mon, Mar 06, 2017 at 07:41:13PM -0500, Thomas Dickey wrote:
> On Mon, Mar 06, 2017 at 06:33:44PM +0100, Sven Joachim wrote:
... 
> hmm - I recall using Utility because that was used by Red Hat.
> 
> fwiw, a quick check shows Utility unused by Konsole (since introducing
> a .desktop file in 2003).
> 
> GNOME dropped Utility about 10 years later, in 2013:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=707552
> 
> The bug report refers to 3.10
> 
> so yes, it's a reasonable change for xterm :-)

However, the choice is done in the configure script, which adds "Utility"
if any of the list of terminals which it checks also uses that category.

So the problem (from Debian's viewpoint) would go away automatically in
xterm if the other packages were fixed.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#780176: [xterm] XTerm and UXTerm appear in Xfce 4.10 main menu twice

[Thomas Dickey]

On Tue, Mar 07, 2017 at 08:17:29PM +0100, Sven Joachim wrote:
> On 2017-03-06 20:06 -0500, Thomas Dickey wrote:
> 
> > On Mon, Mar 06, 2017 at 07:41:13PM -0500, Thomas Dickey wrote:
> >> On Mon, Mar 06, 2017 at 06:33:44PM +0100, Sven Joachim wrote:
> > ... 
> >> hmm - I recall using Utility because that was used by Red Hat.
> >> 
> >> fwiw, a quick check shows Utility unused by Konsole (since introducing
> >> a .desktop file in 2003).
> >> 
> >> GNOME dropped Utility about 10 years later, in 2013:
> >> 
> >> https://bugzilla.gnome.org/show_bug.cgi?id=707552
> >> 
> >> The bug report refers to 3.10
> >> 
> >> so yes, it's a reasonable change for xterm :-)
> >
> > However, the choice is done in the configure script, which adds "Utility"
> > if any of the list of terminals which it checks also uses that category.
> 
> I would expect the list of terminals to be empty on the Debian buildds,
> since those should normally not have any terminal emulators installed in
> the build chroot.  Yet configure still adds "Utility" there, is that
> intended? 

yes - I might change the default, but it was certainly relevant to Red Hat
when I wrote the script.
 
> > So the problem (from Debian's viewpoint) would go away automatically in
> > xterm if the other packages were fixed.
> 
> For Debian we should configure --with-desktop-category to make the build
> deterministic, since the presence of random packages on the build system
> should not change the outcome.

agreed

> diff --git a/debian/rules b/debian/rules
> index a35d111..521becf 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -48,6 +48,7 @@ override_dh_auto_configure:
>   --enable-backarrow-is-erase \
>   --enable-sixel-graphics \
>   --with-utempter \
> + --with-desktop-category=System,TerminalEmulator, \
>   DESKTOP_FLAGS="$(DESKTOP_FLAGS)" \
>   CFLAGS="$(CFLAGS)" \
>   CPPFLAGS="$(CPPFLAGS)" \

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#851462: [pkg-gnupg-maint] Bug#851462: #851462 gpg-agent: a gpg-agent is already running - not starting a new one

[Thomas Dickey]

On Tue, Apr 25, 2017 at 05:55:18PM -0400, Daniel Kahn Gillmor wrote:
> Hi Thomas--
> 
> I'm sorry, but i don't understand what you're trying to do here.  I'm
> re-closing this bug report (#851462) because it doesn't seem to be
> related to the original report anyway, other than the string "gpg-agent
> is already running" appearing in both of them.
> 
> I've asked you some questions below about what you're trying to do --
> feel free to open a new bug report when answering them with a clearer
> description (or to reopen this one again if you're sure this is the same
> issue).

You should reopen it.
 
> On Sat 2017-02-11 19:51:29 -0500, Thomas Dickey wrote:
> > It's broken, and recently.  I noticed this about a week ago.
> >
> > On my machines, I mostly use ssh to connect, and have a script which
> > ties together gpg/ssh, using gpg-agent.  I do this to get the keys
> > for both in - package signing and network connections.
> 
> "to get the keys for both in" what?

both means two:

1 = ssh
2 = gpg

Referring to the manual page:

 gpg-agent --daemon --enable-ssh-support \

I tried using the ssh-support option, have never seen it work reliably.
After some experimentation a few years ago, I came up with this working
solution.

The updates for gpg-agent in January broke my solution (and the
explanation of the "new" behavior sounds as though it's been "improved"
to only work in a desktop session - if that is incorrect, you should
provide that information clearly in the README.Debian file - as written
it does not address this bug report:

gnupg-agent (2.1.18-1) unstable; urgency=medium

  If your machine is configured with system user session management,
  gpg-agent will be managed automatically by systemd's user sessions on
  machines configured with use systemd.  Please consider installing the
  packages that the gnupg-agent package Suggests:, and see
  /usr/share/doc/gnupg-agent/README.Debian for more details.

and

Users who don't want systemd to manage their gpg-agent in this way for
all future sessions should do:

systemctl --user mask --now gpg-agent.service gpg-agent.socket 
gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket

Doing this means that gpg-agent will fall back to its manual mode of
operation.  (This decision can be reversed by the user with "unmask"
instead of "mask")

leaves a lot unsaid.  In my case, there was no desktop session.
(The package still depends upon either pinentry-curses or pinentry).

> > Here's the script:
> >
> > #!/bin/sh
> > # $Id: wrapssh,v 1.9 2015/12/21 09:47:59 tom Exp $
> > # vi:ts=4 sw=4
> > # Initialize a subshell which will run ssh-agent, sets a variable that we 
> > can
> > # use in the initialization to force an ssh-add prompt.
> >
> > unset SSH_AGENT_PID
> > unset SSH_AUTH_SOCK
> > unset SSH2_AUTH_SOCK
> > unset SSH2_AGENT_PID
> >
> > if test -f /usr/bin/ssh-agent
> > then
> > SSH_ADD="passphrase"
> > export SSH_ADD
> > if test -f /usr/bin/gpg-agent && test -f /usr/bin/pinentry-curses
> > then
> > killall gpg-agent 2>/dev/null
> > ssh-agent presign
> > else
> > ssh-agent $SHELL
> > fi
> > fi
> 
> why are you doing "killall gpg-agent" ?  what do you hope to gain from that?
> 
> what is "presign" ?  is that the script below?

hmm - no: I overlooked that.  It's been a couple of years since I put these
together.  The "killall" in "wrapssh" is redundant; I'm killing it in
"presign" so that I can force it to use pinentry-curses

#!/bin/sh
# $Id: presign,v 1.2 2014/09/01 14:54:50 tom Exp $
# vi:ts=4
# Initialize a subshell which will run gpg-agent, sets a variable that we can
# use in the initialization to force an gpg-sign prompt.

unset GPG_ADD

if test -f /usr/bin/gpg-agent && test -f /usr/bin/pinentry-curses
then
GPG_ADD="${GNUPGHOME:=HOME}/.gpg-agent-`hostname`"
export GPG_ADD
pgrep gpg-agent
killall gpg-agent 2>/dev/null

OPTS="--csh"
OPTS="$OPTS --pinentry-program /usr/bin/pinentry-curses"
OPTS="$OPTS -vvv --debug-level 8 --debug-all"
PROG=$SHELL
/usr/bin/gpg-agent --log-file /tmp/gpgagent.log --daemon $OPTS 
--write-env-file $GPG_ADD $PROG
fi

... and Debian/testing isn't the only system that I use it on.
 
> > ...and it calls back with a new shell (tcsh in my case) to activate this:
> >
> > if ( $?

Bug#851462: [pkg-gnupg-maint] Bug#851462: #851462 gpg-agent: a gpg-agent is already running - not starting a new one

[Thomas Dickey]

On Wed, Apr 26, 2017 at 07:28:56PM -0700, Daniel Kahn Gillmor wrote:
> Hi Thomas--
> 
> On Tue 2017-04-25 21:37:46 -0400, Thomas Dickey wrote:
> > Referring to the manual page:
> >
> >  gpg-agent --daemon --enable-ssh-support \
> 
> The above line doesn't appear in the gpg-agent manual page, afaict.  In

It certainly was in the version provided when I wrote the script.

(The most recent manual page has removed that information, trimming
about a third of the manual).

> a modern version of gpg-agent, ssh support is always enabled.
> 
>  The OpenSSH Agent protocol is always enabled
> 
> whether you decide to use it for ssh-agent or whether you decide to use
> a different ssh-agent implementation is up to you, and you can make that
> decision explicit by deciding how you'll set the $SSH_AUTH_SOCK
> environment variable.

It didn't connect to most of the machines I use.  I'm not going to consider
using the feature unless it works with all machines.
 
> > I tried using the ssh-support option, have never seen it work reliably.
> > After some experimentation a few years ago, I came up with this working
> > solution.
> 
> if it never worked reliably, and you found some complex workaround, it's
> entirely possible that upstream fixed the unreliability and was unaware
> of whatever workaround you've chosen to do.  I'm still having a hard
> time following it myself.
> 
> Perhaps using it as currently expected by upstream (and removing complex
> workarounds) will be the most fruitful result for you.

no - if it's not interoperable with the different machines I use,
it is of no use to me.  If gpgconf exists only on a few machines,
it's not useful (at best, it would be a choice provided via a
script, but if the script cannot be made reliable because the program
does not return useful error-codes, then that wouldn't be useful).
 
> > The updates for gpg-agent in January broke my solution (and the
> > explanation of the "new" behavior sounds as though it's been "improved"
> > to only work in a desktop session - if that is incorrect, you should
> > provide that information clearly in the README.Debian file - as written
> > it does not address this bug report:
> 
> you can use gpg-agent without needing a desktop session, but if you need
> interactive prompting, a desktop session is recommended.  desktops are
> good at that kind of interactivity :)

Combining "desktop" and "good" in the same sentence won't lead to
a productive discussion.  Don't go there.
 
> > leaves a lot unsaid.  In my case, there was no desktop session.
> > (The package still depends upon either pinentry-curses or pinentry).
> 
> ok, so you're running from a network console?  from a vt?  some other
> environment?  the more you can help me understand your setup, the better
> i'll be able to help.

You should read the mail.  I am using ssh to connect to a machine where
I want to run gpg-agent.  With the recent change, I can no longer use
gpg-agent.  With Debian for instance, I use it for signing packages.
 
> > hmm - no: I overlooked that.  It's been a couple of years since I put these
> > together.  The "killall" in "wrapssh" is redundant; I'm killing it in
> > "presign" so that I can force it to use pinentry-curses
> 
> if your goal is to force the use of pinentry-curses, and you're on a
> machine without a desktop environment, you should either ensure that
> /usr/bin/pinentry points to pinentry-curses, or you should put
> "pinentry-program /usr/bin/pinentry-curses" into ~/.gnupg/gpg-agent.conf

I'll investigate that (I recall that aspect not working on some systems,
which insisted on using the X version of pinentry, but don't have the
list in my memory).

> > #!/bin/sh
> > # $Id: presign,v 1.2 2014/09/01 14:54:50 tom Exp $
> > # vi:ts=4
> > # Initialize a subshell which will run gpg-agent, sets a variable that we 
> > can
> > # use in the initialization to force an gpg-sign prompt.
> 
> You should *not* expect to run multiple concurrent gpg-agents on the
> same GnuPG home directory.  That is explicitly not supported by
> upstream.
> 
> > ... and Debian/testing isn't the only system that I use it on.
> 
> I'm sorry, but i can't support arbitrary scripts that run on arbitrary
> operating systems.  My hands are pretty full with supporting GnuPG on
> debian :/

Likewise, I cannot make Debian a priority.  It has to cooperate with
other development.
 
> > Back to the bug report: what I'm reading is that gpg-agent can no longer
> > be used as documented.
> 
> I still don't see this, sorry.  Can you try to produce the simplest
> possible example that reproduces the problem?
> 
>  --dkg

I'll take a look to add information.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#841155: 841155 - Lynx browser: Typing utf-8 2-byte characters only diplays first

[Thomas Dickey]

As the followups indicate, this is a documentation issue.  The user's guide
is the place for detailed information.  I modified the manual page to include
a list of all of the variables which might be used, but that list was already
in the user's guide (which is part of the Debian package).

The treatment of the variables is handled in lynx's trace-logs.

All of the questions raised in this report could have been addressed by
reading the existing documentation.

If there's no useful followup, this can be closed.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#841155: 841155 - Lynx browser: Typing utf-8 2-byte characters only diplays first

[Thomas Dickey]

On Sat, Apr 29, 2017 at 08:04:01AM -0400, Thomas Dickey wrote:

...hmm - too much cut/paste (I made code-changes for this one, since
there actually was a bug to report).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#858142: xterm: 'xrdb -merge .Xresources' vs 'xrdb .Xresources'

[Thomas Dickey]

On Tue, May 02, 2017 at 12:37:48PM +, David Griffith wrote:
> 
> This bug is also triggered if a face size of 12 is used.

You haven't mentioned a bug.  What's described is a partial investigation
into the resources which are set before running xrdb (incomplete so far),
and your changes to those resources.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#851462: #851462 gpg-agent: a gpg-agent is already running - not starting a new one

[Thomas Dickey]

It's broken, and recently.  I noticed this about a week ago.

On my machines, I mostly use ssh to connect, and have a script which
ties together gpg/ssh, using gpg-agent.  I do this to get the keys
for both in - package signing and network connections.

Here's the script:

#!/bin/sh
# $Id: wrapssh,v 1.9 2015/12/21 09:47:59 tom Exp $
# vi:ts=4 sw=4
# Initialize a subshell which will run ssh-agent, sets a variable that we can
# use in the initialization to force an ssh-add prompt.

unset SSH_AGENT_PID
unset SSH_AUTH_SOCK
unset SSH2_AUTH_SOCK
unset SSH2_AGENT_PID

if test -f /usr/bin/ssh-agent
then
SSH_ADD="passphrase"
export SSH_ADD
if test -f /usr/bin/gpg-agent && test -f /usr/bin/pinentry-curses
then
killall gpg-agent 2>/dev/null
ssh-agent presign
else
ssh-agent $SHELL
fi
fi

...and it calls back with a new shell (tcsh in my case) to activate this:

if ( $?GPG_ADD ) then
setenv GPG_TTY `tty`
unsetenv GPG_ADD
echo "GPG-signing on $GPG_TTY ..."
if ( -e /usr/bin/gpg ) then
echo | gpg -s >/dev/null
else
echo | gpg2 -s >/dev/null
endif
echo "...GPG-signing"
endif
if ( $?SSH_ADD ) then
echo "prompt $SSH_ADD"
unsetenv SSH_ADD
ssh-add
endif

With the newly broken package, I don't get a gpg-prompt.  
Ditto for ssh-prompt.  What I get is this (turning on the trace):

~ (101) sh -x wrapssh
+ unset SSH_AGENT_PID
+ unset SSH_AUTH_SOCK
+ unset SSH2_AUTH_SOCK
+ unset SSH2_AGENT_PID
+ test -f /usr/bin/ssh-agent
+ SSH_ADD=passphrase
+ export SSH_ADD
+ test -f /usr/bin/gpg-agent
+ test -f /usr/bin/pinentry-curses
+ killall gpg-agent
+ ssh-agent presign
gpg-agent[1791]: reading options from '/users/tom/.gnupg/gpg-agent.conf'
gpg-agent[1791]: WARNING: "--write-env-file" is an obsolete option - it has no 
effect
gpg-agent[1791]: enabled debug flags: cache ipc
gpg-agent: a gpg-agent is already running - not starting a new one
gpg-agent: secmem usage: 0/65536 bytes in 0 blocks

By the way, I don't have a gpg-agent.conf (so that's another error).

Looks like the breakage occurred in
gnupg-agent:amd64 (2.1.17-2, 2.1.18-3)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#823658: ncurses-base: linux terminfo entry lacks the E3 capability

[Thomas Dickey]

On Mon, May 16, 2016 at 08:09:42PM +0200, Sven Joachim wrote:
> Control: tags -1 + fixed-upstream
> 
> On 2016-05-07 05:08 -0400, Thomas Dickey wrote:
> 
> > On Sat, May 07, 2016 at 10:23:32AM +0200, Sven Joachim wrote:
> >> Package: ncurses-base
> >> Version: 6.0+20160319-1
> >> Severity: normal
> >> 
> >> The linux terminfo entry lacks the E3 capability, meaning that 
> >> clear(1) does not clear the scrollback buffer.  The capability was added
> >> to the linux3.0 terminfo entry, but we are not using this because it has
> >> some undesired side effects in non-Unicode locales, see the discussion
> >> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665959.
> >> 
> >> I'm not quite sure what to do, but given that Linux kernels older than
> >> 3.0 are now unsupported, the terminfo entry for linux should certainly
> >> advertise this capability.
> >  
> > comparing linux to linux3.0.
> > comparing booleans.
> > comparing numbers.
> > comparing strings.
> > rmacs: '\E[10m', '^O'.
> > sgr: 
> > '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;11%;m',
> >  
> > '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;'.
> > sgr0: '\E[0;10m', '\E[m\017'.
> > smacs: '\E[11m', '^N'.
> > E3: NULL, '\E[3J'.
> >
> > E3 is (as far as I know) harmless; the other features were the reason for
> > reverting.  When I checked a year or two ago, those were still relying on
> > an unofficial patch (since the entire concept of SI/SO offends UTF-8
> > purists), and could be absent from various kernels.
> >
> > I'll see what I can learn, but adding E3 to "linux" might be the proper
> > change.
> 
> The 20160514 patchlevel works fine, thanks.  Looks like it fixes bug
> #515609[1] as well, doesn't it?

You can mark that done, as well.

I verified that the behavior when UTF-8 mode is on gives okay results
(though I'll keep the "U8" flag for a while).  The behavior with UTF-8
mode off misses some characters (diamond, s1, s3, s7 and s9), and I've
a to-do to investigate a little further.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#793295: xterm: Menu font is too small on high-dpi screen

[Thomas Dickey]

On Wed, Jul 22, 2015 at 04:32:22PM +0200, Vincent Lefevre wrote:
> Package: xterm
> Version: 318-2
> Severity: normal
> 
> The Xterm menu font (menus obtained with Ctrl-click) is too small on
> high-dpi screen, and there's nothing in the documentation saying how
> to configure it (neither in the xterm(1) man page, nor in the FAQ).

menus are done by libxaw7 (will reassign).

By the way, this is a wishlist item.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#820803: xterm: X resources parsed with locale settings

[Thomas Dickey]

On Wed, Apr 13, 2016 at 07:55:06AM +0200, Philipp Marek wrote:
> > > Configuration files should be parsed via the "C" locale, IMO - having to 
> > > think about "," vs. "." in there is awkward.
> 
> faceSize is affected, too, BTW.
> 
> 
> > As far as I can tell the conversion is done in
> > https://cgit.freedesktop.org/xorg/lib/libXt/tree/src/Converters.c#n822
> > which indeed depends on the locale.
> > 
> > But since there's no way to tell how many people depend on the current
> > behaviour, and changing it would break their configuration...
> Well, it can't be *that* many people - because it's not that likely that
>  a) different locale settings apply, AND
>  b) user wants to change one of the few configuration settings that
> are affected, AND
>  c) user figures out that "," (or whatever else) would be the answer.
> 
> So, IMO changing that would be safe enough.
> 
> 
> If you disagree with me, then how about just keeping the current behaviour, 
> but try to parse with the "C" locale too!?

It's a little late for that (existing configurations would break if xterm
switched to "C" locale for evaluating resources).

And unlike the workaround used for "menuLocale", it's too early in the
initialization for it to be a good solution for xterm (because that
would break other parts of the initialization).

Besides this, there's the scaleHeight resource with the same potential issue.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#738794: xterm: the right part of the window is not always erased

[Thomas Dickey]

On Mon, May 02, 2016 at 03:40:54PM +0200, Vincent Lefevre wrote:
> Control: found -1 324-1
> 
> Hi,
> 
> On 2014-02-16 20:55:46 -0500, Thomas Dickey wrote:
> > (I've seen this, but not often enough to have a scenario where it can
> > be reproduced...)
> 
> Perhaps you can reproduce it with the attached log file.
> This seems to be exactly the same problem.
> 
>   xterm -fn 6x13 -geometry 43x24 -hold -e cat debbug738794.log
> 
> See the dot on the right at line 17 ("I enjoyed ... at his house").

I can see a dot :-)

My initial guess is that the missing glyphs on the line confuse xterm
(regarding the cursor position) and it displays the dot outside the vt100
window.  That'll take some study.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#816887: libncursesw5: background color of mutt's message is black

[Thomas Dickey]

On Wed, Jun 08, 2016 at 08:38:45PM +0200, Javier Cantero wrote:
> I've found that the bug has been happening since this change:
> 
> http://invisible-island.net/ncurses/NEWS.html#t20151017
> 
>   + remove an early-return from _nc_do_color, which can interfere with
>   data needed by bkgd when ncurses is configured with extended colors
>   (patch by Denis Tikhomirov).
> 
> I've applied this patch (to undo it) and now mutt is working as before:

I made that change early in May, before this report - see

http://invisible-island.net/ncurses/NEWS.html#t20160507

20160507
+ amend change to _nc_do_color to restore the early return for the
  special case used in _nc_screen_wrap (report by Dick Streefland,
  cf: 20151017).

and reported here:

http://lists.gnu.org/archive/html/bug-ncurses/2016-05/msg2.html

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#822958: [Lynx-dev] ANN: lynx2.8.9dev.9

[Thomas Dickey]

- Original Message -
| From: "Axel Beckert" 
| To: lynx-...@nongnu.org
| Cc: 822...@bugs.debian.org, 822958-submit...@bugs.debian.org
| Sent: Saturday, April 30, 2016 11:22:26 AM
| Subject: Re: [Lynx-dev] ANN: lynx2.8.9dev.9
| 
| Control: tag -1 + wontfix
| 
| Hi Thomas,
| 
| Thomas Dickey wrote:
| > | Nevertheless, in this case, the fix might have broken something
| > | else
| > | as it probably caused the following regression reported in Debian
| > | today: https://bugs.debian.org/822958
| > 
| > yes/no: the report noted breakage in an earlier fix to remove the
| > feature:
| > 
| > ignore LEFT-TO-RIGHT-MARK (U+200E) in HTML files (Debian
| > #408835) -TD
| 
| Ah, I see. Thanks for the clarification.
| 
| > If someone sees it "working" in some version, that is accidental
| > (i.e., a bug), since neither ncurses nor slang actually support
| > bidi
| > in the sense that they know what's on the screen between the
| > (zero-width!) markers.
| 
| Ok, marking as "wontfix" then.
| 

no problem: there's something to explore in ncurses, but for lynx the problem 
is compounded
by (a) lynx needing to know what's on the screen, and (b) the issue of how much 
text is BIDI -
potentially the entire document...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

Bug#822958: [Lynx-dev] ANN: lynx2.8.9dev.9

[Thomas Dickey]

- Original Message -
| From: "Vincent Lefevre" 
| To: lynx-...@nongnu.org, 822...@bugs.debian.org
| Sent: Saturday, April 30, 2016 8:33:37 PM
| Subject: Bug#822958: [Lynx-dev] ANN: lynx2.8.9dev.9
| 
| Hi,
| 
| On 2016-04-30 17:22:26 +0200, Axel Beckert wrote:
| > Thomas Dickey wrote:
| > > If someone sees it "working" in some version, that is accidental
| > > (i.e., a bug), since neither ncurses nor slang actually support
| > > bidi
| > > in the sense that they know what's on the screen between the
| > > (zero-width!) markers.
| > 
| > Ok, marking as "wontfix" then.
| 
| OK, interesting information. If I understand correctly, all ncurses
| based applications should filter out these bidi marks.

ncurses doesn't actually know anything about the BIDI marks.

It only knows about characters that are printable (or not), and the widths of 
characters.
If the C runtime claims that a BIDI mark is printable, ncurses will (try to) 
print it.
If it says it's not printable, ncurses will either treat it as a control 
character (and "render" it),
or it will treat it as part of a combining character.

(I'll do some investigation and see what holes might exist).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net

Bug#823658: ncurses-base: linux terminfo entry lacks the E3 capability

[Thomas Dickey]

On Sat, May 07, 2016 at 10:23:32AM +0200, Sven Joachim wrote:
> Package: ncurses-base
> Version: 6.0+20160319-1
> Severity: normal
> 
> The linux terminfo entry lacks the E3 capability, meaning that 
> clear(1) does not clear the scrollback buffer.  The capability was added
> to the linux3.0 terminfo entry, but we are not using this because it has
> some undesired side effects in non-Unicode locales, see the discussion
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665959.
> 
> I'm not quite sure what to do, but given that Linux kernels older than
> 3.0 are now unsupported, the terminfo entry for linux should certainly
> advertise this capability.
 
comparing linux to linux3.0.
comparing booleans.
comparing numbers.
comparing strings.
rmacs: '\E[10m', '^O'.
sgr: 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;11%;m',
 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;'.
sgr0: '\E[0;10m', '\E[m\017'.
smacs: '\E[11m', '^N'.
E3: NULL, '\E[3J'.

E3 is (as far as I know) harmless; the other features were the reason for
reverting.  When I checked a year or two ago, those were still relying on
an unofficial patch (since the entire concept of SI/SO offends UTF-8
purists), and could be absent from various kernels.

I'll see what I can learn, but adding E3 to "linux" might be the proper
change.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#822426: libncursesw5: wget_wch() returning KEY_CODE_YES with xterm Ctrl/Alt/Shift keys outside the range KEY_MIN <= key <= KEY_MAX

[Thomas Dickey]

On Sun, Apr 24, 2016 at 06:06:08AM -0400, Kevin Lamonte wrote:
> Package: libncursesw5
> Version: 5.9+20140913-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> I am the author of a curses-based terminal emulator, and noticed that
> wget_wch() is returning KEY_CODE_YES with values that are outside the
> range KEY_MIN and KEY_MAX.  This behavior is inconsistent with the
> documented API.

man use_extended_names

(it's been documented quite a while, though a few more cross-references might
help)

man keyname notes:

   The keyname function may return the names of user-defined string  capa‐
   bilities  which  are defined in the terminfo entry via the -x option of
   tic.  This implementation automatically assigns at run-time keycodes to
   user-defined  strings  which  begin  with  "k".   The keycodes start at
   KEY_MAX, but are not guaranteed to be the same value for different runs
   because  user-defined  codes  are merged from all terminal descriptions
   which have  been  loaded.   The  use_extended_names  function  controls
   whether  this  data  is loaded when the terminal description is read by
   the library.

The relevant xterm terminal description information has been in the database
since 2004...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#753699: lynx: Alert!: This client does not contain support for HTTPS URLs.

[Thomas Dickey]

On Tue, Jul 08, 2014 at 07:22:39PM +0200, Andreas Metzler wrote:
> On 2014-07-08 Atsuhito Kohda  wrote:
> > On Fri, 4 Jul 2014 20:09:52 +0200, Andreas Metzler wrote:
> 
> > > Looks like lynx-cur is missing a build-dependency on
> > > libgcrypt20-dev as a hotfix or better use gnutls_rnd() instead of
> > > gcry_randomize() and stop linking against gcrypt. (Totally untested,
> > > no guarantees patch attached.)
> 
> > I only added libgcrypt20-dev to B-D and built the package, then
> > it seems lynx works fine so I uploaded the package.  
> > But if your patch is necessary to fix the problem properly, 
> > please let me know.
> 
> Hello Atsuhito,
> 
> thanks for fixing the issue.
> 
> it is less a "necessary" than a "I think it is ugly". ;-) Afaict (but
> please take this with a grain of salt) lynx is only using a single
> gcrypt function, and gnutls would provide something equivalent. So by
> using the gnutls function the external dependency could be avoided.
> Imho this should be fixed upstream.

probably (at least, to ensure that the given function is present, etc).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#756353: ncurses-base: screen-256color: SGR 7 (reverse video) does not work (appears as italics)

[Thomas Dickey]

On Mon, Jul 28, 2014 at 10:49:19PM -0700, Suraj N. Kurapati wrote:
> Package: ncurses-base
> Version: 5.9+20140712-2
> Severity: minor

from the discussion here, it sounds more like a problem with tmux:

http://lists.gnu.org/archive/html/bug-ncurses/2014-06/msg00028.html

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#756353: ncurses-base: screen-256color: SGR 7 (reverse video) does not work (appears as italics)

[Thomas Dickey]

On Tue, Jul 29, 2014 at 03:05:13PM -0700, Suraj Kurapati wrote:
> Hi Thomas,
> 
> On Tue, Jul 29, 2014 at 2:05 PM, Thomas Dickey wrote:
> > On Mon, Jul 28, 2014 at 10:49:19PM -0700, Suraj N. Kurapati wrote:
> >> Package: ncurses-base
> >> Version: 5.9+20140712-2
> >> Severity: minor
> >
> > from the discussion here, it sounds more like a problem with tmux:
> > http://lists.gnu.org/archive/html/bug-ncurses/2014-06/msg00028.html
> 
> Thanks for the link.  It seems that the latest ncurses-base update
> actually fixed TERM=screen-256color to behave the same inside tmux
> as it does outside tmux.  For instance, with TERM=screen-256color

It's more complicated than that.  Barring some analysis from the
tmux developers pinpointing a problem in ncurses, what I see is this:

a) in recent changes, I _tried_ to make screen's terminal descriptions
   use italics.
b) that didn't work - because of a long-ago design flaw in screen.
c) for some other terminal types, the terminal description supports
   italics
d) tmux did not have screen's particular design flaw - but it 
   tries to use screen's terminal description.
e) tmux's developers indicated they were considering changing tmux
   to improve this area.  (I think their best plan would be to handle
   the special case of "TERM=screen*" and introduce their own TERM=tmux
   which would be used in preference when it exists - compatibility is
   hard sometimes).

> outside tmux, my terminal renders standout mode in an italic font.
> Whereas, inside tmux, standout mode is rendered (1) as reverse video
> with the previous ncurses-base 5.9+20140118-1 package and (2) in an
> italic font with the current ncurses-base 5.9+20140712-2 package.
> 
> I didn't realize that it was standout mode that changed because all
> I observed was that, inside tmux, things that were previously shown
> in reverse video were now shown in an italic font.
> 
> Sorry for the confusion.  You can close this bug report as invalid.

perhaps not yet - I'm unsure where the change is coming from...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#786436: ncurses FTBFS: configure loops

[Thomas Dickey]

- Original Message -
| From: "Helmut Grohne" 
| To: 786...@bugs.debian.org
| Sent: Thursday, May 21, 2015 1:48:24 PM
| Subject: Bug#786436: ncurses FTBFS: configure loops
| 
| Control: tags -1 - moreinfo
| Control: severity -1 serious
| 
| On Thu, May 21, 2015 at 07:24:18PM +0200, Helmut Grohne wrote:
| > | Looking for ncursesw-config
| > | checking for ncursesw-config... no
| > | checking for ncursesw6-config... no
| > | checking for ncursesw5-config... no
| 
| There is a notable difference to successful builds here. Those say:
| 
| | checking for ncursesw5-config... ncursesw5-config
| 
| Now where does that come from? ncurses-bin. Well, it came from there,
| but it no longer does.

On the other hand, I have the impression that Debian packagers would prefer to 
use ".pc" files.
The log shows that there is no suitable pkg-config for the cross-compiler, so 
it falls through
to the script looking for ncurses*-config

I did that recently, and verified that the script works with the pkg-config 
which is part of
the MinGW cross-compilers.  (If there is something I've overlooked, that would 
be nice to know).

Perhaps the proper fix for your build is to ensure that there is a pkg-config 
for the cross-build,
rather than restoring the ncurses*-config scripts to your build-environment.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#786436: ncurses FTBFS: configure loops

[Thomas Dickey]

- Original Message -
| From: "Sven Joachim" 
| To: "Helmut Grohne" 
| Cc: "Thomas Dickey" , 786...@bugs.debian.org
| Sent: Monday, May 25, 2015 8:31:29 AM
| Subject: Bug#786436: ncurses FTBFS: configure loops
| 
| Am 25.05.2015 um 13:43 schrieb Helmut Grohne:
| 
| > On Mon, May 25, 2015 at 01:37:17PM +0200, Sven Joachim wrote:
| >> Since the pkg-config files are only created at "make
| >> install.libs", we
| >> currently need to install the library into a temporary location.
| >>  I've
| >> come up with the following patch:
| >> 
| >> --8<---cut here---start->8---
| >> diff --git a/debian/rules b/debian/rules
| >> index a52135b..c3b7d6e 100755
| >> --- a/debian/rules
| >> +++ b/debian/rules
| >> @@ -275,8 +275,9 @@ $(wobjdir-32)/config.status:
| >> config.guess-stamp
| >>  
| >>  $(objdir-test)/config.status: build-wide config.guess-stamp
| >>test -d $(objdir-test) || mkdir $(objdir-test)
| >> -  cd $(objdir-test) && CFLAGS="$(CFLAGS)" $(srcdir)/test/configure
| >> \
| >> -  $(CONFARGS-TEST)
| >> +  cd $(objdir-test) && CFLAGS="$(CFLAGS)" \
| >> +
| >>
PKG_CONFIG_LIBDIR=$(wobjdir)/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
| >> \
| >> +  $(srcdir)/test/configure $(CONFARGS-TEST)
| >>  
| >>  build-arch build-indep: build
| >>  
| >> @@ -308,8 +309,7 @@ build-debug: $(objdir-debug)/config.status
| >>  build-wide: $(wobjdir)/config.status
| >>cd $(wobjdir) && $(MAKE)
| >># needed for building the examples
| >> -  mv $(wobjdir)/lib/libncursesw.so
| >> $(wobjdir)/lib/libncursesw.so.saved
| >> -  echo "INPUT(libncursesw.so.5 -ltinfo)" >
| >> $(wobjdir)/lib/libncursesw.so
| >> +  $(MAKE) -C $(wobjdir) DESTDIR=$(wobjdir) install.libs
| >>touch $@
| >>  
| >>  build-wide-static: $(wobjdir-static)/config.status
| >> --8<---cut here---end--->8---
| >
| > If ncurses uses any external pkg-config files, then this patch
| > breaks
| > cross building, because the pkg-config cross wrapper only sets
| > PKG_CONFIG_LIBDIR when it is unset.
| >
| > Given that libgpm-dev does not ship a .pc file, it seems likely
| > that
| > this is not the case.
| 
| It surely is not, but the cross build is broken anyway:
| 
| ,
| | checking for specific curses-directory...
| | /tmp/ncurses-5.9+20150516/obj-wide
| | checking for specified curses library type... ncursesw
| | checking for multibyte character support... yes
| | checking pkg-config for ncursesw... yes
| | checking if the ncursesw package files work... configure: error:
| | cannot run test program while cross compiling
| `
| 
| Sounds like something for Thomas to look at.

This (cannot run...) at least is a problem in something I have changed
recently.

The apparent cause of the infinite loop
(seen here by disabling the pkg-config and ncurses*-config checks)
is a while-loop in CF_ADD_INCDIR, which has been (it seems)
waiting since 2007 for someone to notice a problem...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#777461: FTBFS with gcc-5

[Thomas Dickey]

On Sun, Feb 08, 2015 at 02:03:54PM +0100, Helmut Grohne wrote:
> Source: ncurses
> Version: 5.9+20140913-1
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> I noticed that ncurses FTBFS with gcc-5. Please find a failing log
> attached. The file that fails compilation is generated using shell and
> awk from the output of the preprocessor. The cpp included in gcc-5 can
> split lines which may cause confusion to the source generator. See
> #777374 for a similar bug. Most likely, ncurses relies on UB in gcc and
> thus this is a bug in ncurses indeed.

You appear to be discussing a bug in gcc for which I made a workaround
in December:

http://invisible-island.net/ncurses/NEWS.html#index-t20141206

(the most recent version of gcc in Debian/testing still appears to be 4.9)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#699068: lynx: Cannot Type a Page-Number more than 999

[Thomas Dickey]

On Fri, Jun 27, 2014 at 03:22:23PM +0900, Atsuhito Kohda wrote:
> Hi Hart, sorry for so late reply.
> 
> On Sat, 26 Jan 2013 17:34:33 -0800, Larry Hart wrote:
> 
> > When browsing an item with more than 999 screens or pages,
> > I am unable to type a number past 999.
> > Sure I can use a spacebar to advance, but if its thousands of
> > screens, this is unworkable.  And just as bad, you cannot arrow through a 
> > typed number
> > to insert extra digits, the field won't go past 3.
> 
> I'd like to know any real URL so that I can test your problem.
> Thanks for your interest in lynx.

Looking at the suggested

https://packages.debian.org/testing/allpackages

it is slow - but I am not seeing how to reproduce the problem.  For instance
if I type
0
1
2
3
0
p


I get the

Follow link (or goto link or page) number:

and can edit the line, and on pressing , lynx shows page 1230

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#775295: AW: Bug#775295: dialog: ok/cancel shortcuts not working in many dialogs

[Thomas Dickey]

On Wed, Jan 21, 2015 at 12:58:17PM +, FUCHS Gerfried wrote:
> Hi!
> 
> I was refering to man 3 dialog, which speaks in the dlg_char_to_button
> function about key bindings.  If it's not meant to be a shortcut, why does it
> receive a hilight on the first character then?  And if it's not meant to be a
> shortcut, is there a way with a switch or such to manually disable the
> hilighting as a workaround?  I'm uncertain how --visit-items should play into
> the issue.

The highlighting is done as part of setting up the button row (ok,
cancel, etc), so there's (currently) no way to turn it off.  I think the
way to accomplish this change is to add a flag to the widget state to
suppress highlighting for the button row, and to set that in the widgets
where abbreviation is done differently.

Inevitably, someone will then complain that the buttons aren't the same
appearance as before - but adding a command-line option to control this
seems a worse solution.
 
>  Thanks for your quick response. :)

no problem

> Gerfried Fuchs
> 
> -Ursprüngliche Nachricht-
> Von: Thomas Dickey [mailto:dic...@his.com] 
> Gesendet: Sonntag, 18. Januar 2015 19:49
> An: 775...@bugs.debian.org
> Cc: 775295-submit...@bugs.debian.org
> Betreff: Bug#775295: dialog: ok/cancel shortcuts not working in many dialogs 
> (WARNING!!! PGP with incorrect signature)
> 
> On Tue, Jan 13, 2015 at 04:46:53PM +, FUCHS Gerfried wrote:
> > Package: dialog
> > Version: 1.1-20120215-2
> > Severity: normal
> > 
> >Hi!
> > 
> > I've noticed that the shortcuts for the OK and Cancel buttons (O and C
> > respectively) don't work in --menu dialogs.  It seems to work in 
> > --calendar and --dselect/--fselect/--editbox (once the input focus 
> > isn't on the input box anymore), but not in --menu or --checklist.  I 
> > didn't test them all through, but it's strange that they seem to work 
> > in some but not others, which is kinda confusing for the users, 
> > especially since it is documented to work that way in the manpage.  :/
> 
> hmm - yes/no - I'm not sure which part of the manpage you're reading.
> In a quick check, this part of the description is all that I'm seeing which 
> tells specifically about abbreviations (shortcuts):
> 
>--visit-items
>   Modify  the  tab-traversal  of checklist, radiolist, menubox and
>   inputmenu to include the list of items as  one  of  the  states.
>   This  is useful as a visual aid, i.e., the cursor position helps
>   some users.
> 
>   When this option is given, the cursor is initially placed on the
>   list.   Abbreviations (the first letter of the tag) apply to the
>   list items.  If you tab to the button row,  abbreviations  apply
>   to the buttons.
> 
> It's probably confusing that the OK/Cancel buttons have a character 
> highlighted in their labels.  But essentially the widgets which support 
> abbreviations for a list-item are doing this with the cursor never leaving 
> the ok/cancel buttons, but maintaining a highlighted line on the list itself.
> They're different from inputbox (where the cursor does move around).
> 
> --
> Thomas E. Dickey  http://invisible-island.net 
> ftp://invisible-island.net
> 

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#752610: #752610 lynx: Can connect to CVE-2014-0092 test site

[Thomas Dickey]

The report/discussion appears to be the same as #745835, and I merged them
for that reason.  The original report is unreproducible, because the test
site is gone.  closing.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#699068: lynx: Cannot Type a Page-Number more than 999

[Thomas Dickey]

On Sun, Feb 01, 2015 at 01:33:31PM +0100, Andreas Metzler wrote:
> On 2014-12-09 Thomas Dickey  wrote:
> > On Fri, Jun 27, 2014 at 03:22:23PM +0900, Atsuhito Kohda wrote:
> >> Hi Hart, sorry for so late reply.
> >> On Sat, 26 Jan 2013 17:34:33 -0800, Larry Hart wrote:
> 
> >>> When browsing an item with more than 999 screens or pages,
> >>> I am unable to type a number past 999.
> [...]
> > https://packages.debian.org/testing/allpackages
> 
> > it is slow - but I am not seeing how to reproduce the problem.  For instance
> > if I type
> > 0
> > 1
> > 2
> > 3
> > 0
> > p
> > 
> 
> > I get the
> 
> > Follow link (or goto link or page) number:
> 
> > and can edit the line, and on pressing , lynx shows page 1230
> 
> Hello Thomas,
> 
> I can still reproduce this with 2.8.9dev4. Pressing 0 gives me the
> "Follow link (or goto link or page) number:"-prompt. However this
> prompt only accepts 4 characters of input, and therefore page 999
> ("999p") is the limit.

I'm puzzled, since my own build of it works as I noted (just checked now). 
Running in a 40-line terminal, that gives this text at the top:

Debian -- Software Packages in "jessie" (p1230 of 4978)>
   libcommon-sense-perl (3.73-2+b1)^
  module that implements some sane defaults for Perl programs  ▒
   ▒

Just as a sanity check, I did 04975p, and got (as expected) just a few
screens before the end of the file.

Perhaps there is some option-setting which is interfering - but I don't
see that turning on the links/fields numbering changes anything.

> ametzler@argenau:/tmp/LYNX/lynx-cur-2.8.9dev4$ LANG=C lynx --version
> Lynx Version 2.8.9dev.4 (25 Jan 2015)
> libwww-FM 2.14, SSL-MM 1.4.1, GNUTLS 3.3.8, ncurses 5.9.20140913(wide)
> Built on linux-gnu Jan 26 2015 17:58:46

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#783808: Please add a new terminal type: xterm-256color-utf8

[Thomas Dickey]

- Original Message -
| From: "Stephen Powell" 
| To: sub...@bugs.debian.org
| Sent: Thursday, April 30, 2015 7:21:11 AM
| Subject: Bug#783808: Please add a new terminal type: xterm-256color-utf8
| 
| Package: ncurses
| Version 5.9+20140913-1
| Severity: wishlist
| 
| There is a need for a new terminal definition, which I call
| xterm-256color-utf8.  It is based on xterm-256color, except that
| it does not support the alternate character set when operating
| in utf-8 mode.  This is needed for xterm if the vt100Graphics
| resource is set to false.  It is also very useful for modern
| versions of PuTTY, which emulate a modern 256-color xterm but
| do not support alternate character sets in utf-8 mode.
| 
| The following patch will provide the needed terminal type:
| 
|http://users.wowway.com/~zlinuxman/PuTTY/add_xterm-256color-utf8.patch

There is no possibility that I will include a patch which implies that PuTTY is 
xterm,
but that inevitably leads to more bug reports.

The existing "putty" entry already does what is asked.

See for example

http://invisible-island.net/ncurses/terminfo.src.html#tic-putty

| Note that if this patch is implemented, a corresponding change will
| be needed
| to the database of color terminals in coreutils (src/dircolors.hin).
| 
| (I don't know why dircolors can't interrogate the terminal definition
| in ncurses to determine if the terminal supports color, rather than
| maintaining its own database of color terminals.  But that's another
| subject.)


dircolors is hardcoded, ignores terminal database (and some of its definitions
as I recall, do not correspond to the terminal database).


-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783806: ibm3161 terminfo definition incomplete (and others derived from it)

[Thomas Dickey]

- Original Message -
| From: "Stephen Powell" 
| To: sub...@bugs.debian.org
| Sent: Thursday, April 30, 2015 6:57:16 AM
| Subject: Bug#783806: ibm3161 terminfo definition incomplete (and others 
derived from it)
| 
| Package: ncurses
| Version: 5.9+20140913-1
| Severity: minor
| 
| The ibm3161 terminal definition in ncurses is incomplete.  It is
| missing the
| ich1, il1, and xon attributes.  The following patch will fix the
| problem:
| 
|http://users.wowway.com/~zlinuxman/add_ibm3161_ich1_il1_xon.patch
| 
| This change also affects the following aliases and other terminal
| definitions
| derived from it:
| 
| i3164, ibm3151, ibm3161-C, ibm3162, ibm3163, ibm3164, and wy60-316X.

thanks - will review/et

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783486: one more memory leak in ncurses

[Thomas Dickey]

On Mon, Apr 27, 2015 at 07:56:52AM -0400, Daniel Kahn Gillmor wrote:
> following up on my earlier post about memory leaks in ncurses, there
> appears to be another leak in wrefresh as well:
> 
>  at 0x4C28C20: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>  by 0x4E3D7EE: _nc_scroll_optimize (in 
> /lib/x86_64-linux-gnu/libncursesw.so.5.9)
>  by 0x4E5E52C: doupdate (in /lib/x86_64-linux-gnu/libncursesw.so.5.9)
>  by 0x4E4B8A8: wrefresh (in /lib/x86_64-linux-gnu/libncursesw.so.5.9)

There are no steps to repeat given (the sample code in the bug report
does not use wrefresh).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#783808: Please add a new terminal type: xterm-256color-utf8

[Thomas Dickey]

On Thu, Apr 30, 2015 at 06:09:22PM -0400, Stephen Powell wrote:
> On Thu, 30 Apr 2015 07:39:31 -0400 (EDT), Thomas Dickey wrote:
> > 
> > There is no possibility that I will include a patch which implies
> > that PuTTY is xterm, but that inevitably leads to more bug reports.
> > 
> 
> Nor should you.  I agree.  But apparently you did not review my patch
> carefully enough.  The patch itself does not even mention PuTTY.

The intent of the patch is to remove functionality from the xterm description
to make it more like the putty description.  Keep in mind that the original
"putty" description was not from the core PuTTY developers; they have never
contributed to any of this.

> The only mention of PuTTY is in this bug report.  But the patch itself
> does not mention PuTTY.
> >
> > The existing "putty" entry already does what is asked.
> > 
> > See for example
> > 
> > http://invisible-island.net/ncurses/terminfo.src.html#tic-putty
> 
> No, it doesn't.  I am aware of the existence of the "putty" terminal
> type definition in ncurses, but I don't use it because it is way
> out of date.  (That's one problem with a terminal implemented in

PuTTY hasn't changed that much.  I used the default keyboard settings.

> software.  The terminal's capabilities can change over time, whereas
> a hardware terminal generally doesn't change its behavior over time.)
> 
> For a more complete discussion of this topic, please see my PuTTY
> web page at
> 
>http://users.wowway.com/~zlinuxman/putty.htm#ConnectionD

I read through this, but don't see anything other than a PuTTY-centric
viewpoint.  Encouraging PuTTY users to use TERM=xterm only leads to
bug reports.  To remind you, here's an infocmp listing showing the
differences:

comparing xterm-new to putty.
comparing booleans.
OTbs: T:F.
bw: F:T.
ccc: F:T.
hs: F:T.
km: T:F.
mc5i: T:F.
npc: T:F.
xon: F:T.
AX: T:F.
comparing numbers.
cols: 80, NULL.
lines: 24, NULL.
ncv: NULL, 22.
U8: NULL, 1.
comparing strings.
acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', 
'``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'.
clear: '\E[H\E[2J', '\E[H\E[J'.
cnorm: '\E[?12l\E[?25h', '\E[?25h'.
cud1: '^J', '\ED'.
cuu1: '\E[A', '\EM'.
cvvis: '\E[?12;25h', NULL.
dim: '\E[2m', NULL.
dispc: NULL, 
'%?%p1%{8}%=%t\E%%G\342\227\230\E%%@%e%p1%{10}%=%t\E%%G\342\227\231\E%%@%e%p1%{12}%=%t\E%%G\342\231\0\E%%@%e%p1%{13}%=%t\E%%G\342\231\252\E%%@%e%p1%{14}%=%t\E%%G\342\231\253\E%%@%e%p1%{15}%=%t\E%%G\342\230\274\E%%@%e%p1%{27}%=%t\E%%G\342\206\220\E%%@%e%p1%{155}%=%t\E%%G\340\202\242\E%%@%e%p1%c%;'.
dsl: NULL, '\E]0;\007'.
enacs: NULL, '\E(B\E)0'.
flash: '\E[?5h$<100/>\E[?5l', '\E[?5h\E[?5l'.
fsl: NULL, '^G'.
ich: '\E[%p1%d@', NULL.
initc: NULL, 
'\E]P%p1%x%p2%{255}%*%{1000}%/%02x%p3%{255}%*%{1000}%/%02x%p4%{255}%*%{1000}%/%02x'.
invis: '\E[8m', NULL.
is2: '\E[!p\E[?3;4l\E[4l\E>', 
'\E7\E[r\E[m\E[?7h\E[?1;4;6l\E[4l\E8\E>\E]R'.
kDC: '\E[3;2~', NULL.
kEND: '\E[1;2F', NULL.
kHOM: '\E[1;2H', NULL.
kIC: '\E[2;2~', NULL.
kLFT: '\E[1;2D', NULL.
kNXT: '\E[6;2~', NULL.
kPRV: '\E[5;2~', NULL.
kRIT: '\E[1;2C', NULL.
kb2: '\EOE', '\E[G'.
kcub1: '\EOD', '\E[D'.
kcud1: '\EOB', '\E[B'.
kcuf1: '\EOC', '\E[C'.
kcuu1: '\EOA', '\E[A'.
kend: '\EOF', '\E[4~'.
kent: '\EOM', NULL.
kf1: '\EOP', '\E[11~'.
kf13: '\E[1;2P', '\E[25~'.
kf14: '\E[1;2Q', '\E[26~'.
kf15: '\E[1;2R', '\E[28~'.
kf16: '\E[1;2S', '\E[29~'.
kf17: '\E[15;2~', '\E[31~'.
kf18: '\E[17;2~', '\E[32~'.
kf19: '\E[18;2~', '\E[33~'.
kf2: '\EOQ', '\E[12~'.
kf20: '\E[19;2~', '\E[34~'.
kf21: '\E[20;2~', NULL.
kf22: '\E[21;2~', NULL.
kf23: '\E[23;2~', NULL.
kf24: '\E[24;2~', NULL.
kf25: '\E[1;5P', NULL.
kf26:

Bug#783808: Please add a new terminal type: xterm-256color-utf8

[Thomas Dickey]

On Sat, May 02, 2015 at 05:21:21PM -0400, Stephen Powell wrote:
> On Sat, 02 May 2015 16:40:16 -0400 (EDT), Thomas Dickey wrote:
> > 
> > The intent of the patch is to remove functionality from the xterm 
> > description
> > to make it more like the putty description.
> > ...
> 
> The intent of the patch is to provide a new terminal definition,
> xterm-256color-utf8, for users of a modern xterm with the vt100Graphics
> resource set to false.  This new terminal definition reflects how xterm 
> actually
> behaves under those conditions.  None of the existing terminal definitions are
> altered.  And the patch does not mention putty.  Please reconsider.

The request said

 It is also very useful for modern
 versions of PuTTY, which emulate a modern 256-color xterm but
 do not support alternate character sets in utf-8 mode.

and I pointed out that it would only lead to more bug reports.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#775295: dialog: ok/cancel shortcuts not working in many dialogs

[Thomas Dickey]

On Tue, Jan 13, 2015 at 04:46:53PM +, FUCHS Gerfried wrote:
> Package: dialog
> Version: 1.1-20120215-2
> Severity: normal
> 
>Hi!
> 
> I've noticed that the shortcuts for the OK and Cancel buttons (O and C
> respectively) don't work in --menu dialogs.  It seems to work in --calendar
> and --dselect/--fselect/--editbox (once the input focus isn't on the input
> box anymore), but not in --menu or --checklist.  I didn't test them all
> through, but it's strange that they seem to work in some but not others,
> which is kinda confusing for the users, especially since it is documented to
> work that way in the manpage.  :/

hmm - yes/no - I'm not sure which part of the manpage you're reading.
In a quick check, this part of the description is all that I'm seeing
which tells specifically about abbreviations (shortcuts):

   --visit-items
  Modify  the  tab-traversal  of checklist, radiolist, menubox and
  inputmenu to include the list of items as  one  of  the  states.
  This  is useful as a visual aid, i.e., the cursor position helps
  some users.

  When this option is given, the cursor is initially placed on the
  list.   Abbreviations (the first letter of the tag) apply to the
  list items.  If you tab to the button row,  abbreviations  apply
  to the buttons.

It's probably confusing that the OK/Cancel buttons have a character
highlighted in their labels.  But essentially the widgets which support
abbreviations for a list-item are doing this with the cursor never leaving the
ok/cancel buttons, but maintaining a highlighted line on the list itself.
They're different from inputbox (where the cursor does move around).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#775294: cursor keys don't work after tab in --editbox

[Thomas Dickey]

On Tue, Jan 13, 2015 at 04:53:26PM +, FUCHS Gerfried wrote:
> Package: dialog
> Version: 1.1-20120215-2
> Severity: normal
> 
>Hi!
> 
> With dialog --editbox one isn't able to use the cursor keys after tabbing out
> of the input field like it is possible with other dialog boxes.  Again, I
> haven't tested all through, there might be other dialog boxest hat have the
> same issue.

I see - the navigational keybindings aren't consistent.  will see...

(thanks)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#712738: lynx-cur: segfault after adding KEYMAP lines

[Thomas Dickey]

On Fri, Mar 06, 2015 at 11:10:56AM +0100, Denis Briand wrote:
> Hello,
> I have the same behaviour of Atsuhito.
> Is the crash fixed with the right syntax?

I was not able to reproduce the problem (a walkback trace with gdb
might help).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#780176: [xterm] XTerm and UXTerm appear in Xfce 4.10 main menu twice

[Thomas Dickey]

On Tue, Mar 10, 2015 at 07:18:31AM +0100, bullgard wrote:
> Package: xterm
> Version: 312-1
> Severity: wishlist
> 
> --- Please enter the report below this line. ---
> XTerm and UXTerm appear in Xfce 4.10 main menu twice. Please decide

The xterm package doesn't provide the bits for that menu.

Apparently it's Xcfe:

If it were coming from xterm, the only possible place would be the categories
in the .desktop file, e.g,. treating Utility as "Accessories", and System
as "System".  Given the report, something is missing because half of the
entries in my collection of .desktop files for Debian 8 beta which have
System also have Utility (after excluding GNOME).  So it can't be that.
Otherwise this report would cite all of the cases where the .desktop file
could be used that way.

If this were a bug that is relevant to xterm, the place to start would
be pointing to a relevant Debian policy.

Terminator is configured to do the same thing (perhaps there is no policy).
On the other hand, I see that Terminator is still violating the Debian
guideline on package priority.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#484250: lynx-cur #484250 - Wrong keybindings for languages other than english

[Thomas Dickey]

- Original Message -
| From: "Stéphane Aulery" 
| To: "Denis Briand" 
| Cc: 484...@bugs.debian.org, "Thomas Dickey" 
| Sent: Saturday, March 14, 2015 7:46:51 PM
| Subject: Re: lynx-cur #484250 - Wrong keybindings for languages other than 
english
| 
| Hello Denis,
| 
| Le dimanche 15 mars 2015 à 12:10:54, Denis Briand a écrit :
| > 
| > Have you sent your patch to the upstream team?
| > Could you send us this patch, please?
| > Many thank for your work.
| 
| Yes, I have send a patch to
| http://www.iro.umontreal.ca/contrib/po/HTML/domain-lynx.html as
| indicated in
| package documentation po/readme. I had checked it a year ago, if I
| remember
| right, and the patch was not integrated. But this site seems down. I
| do not
| have a copy of my original post because I cleaned my emails long ago.
| 
| Is the translation subproject still active? Thomas Dickey might be
| able to
| answer?

The translation project makes occasional updates - the most recent from last 
August.
But keep in mind that updates tend to be based on individual translators, not 
all
of whom are active.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#484250: lynx-cur #484250 - Wrong keybindings for languages other than english

[Thomas Dickey]

- Original Message -
| From: "Stéphane Aulery" 
| To: "Thomas Dickey" 
| Cc: 484...@bugs.debian.org, "Denis Briand" 
| Sent: Saturday, March 14, 2015 8:27:27 PM
| Subject: Re: lynx-cur #484250 - Wrong keybindings for languages other than 
english
| 
| Hello Thomas,
| 
| Le samedi 14 mars 2015 à 08:26:26, Thomas Dickey a écrit :
| > | Le dimanche 15 mars 2015 à 12:10:54, Denis Briand a écrit :
| > | > 
| > | > Have you sent your patch to the upstream team?
| > | 
| > | Yes, I have send a patch to
| > | http://www.iro.umontreal.ca/contrib/po/HTML/domain-lynx.html as
| > | indicated in
| > | package documentation po/readme. I had checked it a year ago, if
| > | I
| > | remember
| > | right, and the patch was not integrated. But this site seems
| > | down. I
| > | do not
| > | have a copy of my original post because I cleaned my emails long
| > | ago.
| > | 
| > | Is the translation subproject still active? Thomas Dickey might
| > | be
| > | able to
| > | answer?
| > 
| > The translation project makes occasional updates - the most recent
| > from last August.
| > But keep in mind that updates tend to be based on individual
| > translators, not all
| > of whom are active.
| 
| The site seems unavailable. Did I wrong? If I could only found my
| original patch in a list, I could do somethings.

I usually just check the webpage that I get patches from (because I
get email notification for dialog and lynx):

http://translationproject.org/latest/lynx

It's been a while since I talked with anyone from the project :-(

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#484250: lynx-cur #484250 - Wrong keybindings for languages other than english

[Thomas Dickey]

- Original Message -
| From: "Stéphane Aulery" 
| To: "Thomas Dickey" 
| Cc: 484...@bugs.debian.org, "Denis Briand" 
| Sent: Saturday, March 14, 2015 9:06:16 PM
| Subject: Bug#484250: lynx-cur #484250 - Wrong keybindings for languages other 
than english
| 
| Hello,
| 
| Le samedi 14 mars 2015 à 08:37:58, Thomas Dickey a écrit :
| > 
| > 
| > - Original Message -
| > | From: "Stéphane Aulery" 
| > | To: "Thomas Dickey" 
| > | Cc: 484...@bugs.debian.org, "Denis Briand"
| > | 
| > | Sent: Saturday, March 14, 2015 8:27:27 PM
| > | Subject: Re: lynx-cur #484250 - Wrong keybindings for languages
| > | other than english
| > | 
| > | Hello Thomas,
| > | 
| > | Le samedi 14 mars 2015 à 08:26:26, Thomas Dickey a écrit :
| > | > | Le dimanche 15 mars 2015 à 12:10:54, Denis Briand a écrit :
| > | > | > 
| > | > | > Have you sent your patch to the upstream team?
| > | > | 
| > | > | Yes, I have send a patch to
| > | > | http://www.iro.umontreal.ca/contrib/po/HTML/domain-lynx.html
| > | > | as
| > | > | indicated in
| > | > | package documentation po/readme. I had checked it a year ago,
| > | > | if
| > | > | I
| > | > | remember
| > | > | right, and the patch was not integrated. But this site seems
| > | > | down. I
| > | > | do not
| > | > | have a copy of my original post because I cleaned my emails
| > | > | long
| > | > | ago.
| > | > | 
| > | > | Is the translation subproject still active? Thomas Dickey
| > | > | might
| > | > | be
| > | > | able to
| > | > | answer?
| > | > 
| > | > The translation project makes occasional updates - the most
| > | > recent
| > | > from last August.
| > | > But keep in mind that updates tend to be based on individual
| > | > translators, not all
| > | > of whom are active.
| > | 
| > | The site seems unavailable. Did I wrong? If I could only found my
| > | original patch in a list, I could do somethings.
| > 
| > I usually just check the webpage that I get patches from (because I
| > get email notification for dialog and lynx):
| > 
| > http://translationproject.org/latest/lynx
| > 
| > It's been a while since I talked with anyone from the project :-(
| 
| @Thomas:
| 
| Okay, official page is
| http://translationproject.org/domain/lynx.html.
| 
| Can you fix this in po/readme please?

yes, I can do this

| @Thomas and @Denis:
| 
| I remember now. I sent to translators individual patches for each
| language. I have received no response.
| 
| I think I'll sign the disclaimer and submit myself translations with
| the
| robot, it fast in the end.

sounds good

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#484250: lynx-cur #484250 - Wrong keybindings for languages other than english

[Thomas Dickey]

- Original Message -
| From: "Stéphane Aulery" 
| To: "Thomas Dickey" 
| Cc: 484...@bugs.debian.org, "Denis Briand" 
| Sent: Saturday, March 14, 2015 9:52:52 PM
| Subject: Bug#484250: lynx-cur #484250 - Wrong keybindings for languages other 
than english
| 
| Hello,
| 
| Le samedi 14 mars 2015 à 09:22:38, Thomas Dickey a écrit :
| > - Original Message -
| > | From: "Stéphane Aulery" 
| > | Sent: Saturday, March 14, 2015 9:06:16 PM
| > | 
| > | @Thomas:
| > | 
| > | Okay, official page is
| > | http://translationproject.org/domain/lynx.html.
| > | 
| > | Can you fix this in po/readme please?
| > 
| > yes, I can do this
| 
| Ok, thank you.
| 
| > | @Thomas and @Denis:
| > | 
| > | I remember now. I sent to translators individual patches for each
| > | language. I have received no response.
| > | 
| > | I think I'll sign the disclaimer and submit myself translations
| > | with
| > | the
| > | robot, it fast in the end.
| > 
| > sounds good
| 
| I have signed the disclaimer and requested to join the french Team. I
| also asked if it is possible to send patches for all languages of the
| software without signing up to each team. It only remains to wait.

sounds good: at the moment I'm busy on other stuff (and reluctant to
make a new snapshot for a one-line change to documentation).  If there
are several po-file updates, that would be enough.  (There are other
bug-reports as well... which all take time).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#429606: must ~/.mailcap be a plain file with only one link?

[Thomas Dickey]

On Tue, Mar 17, 2015 at 05:03:27PM +0100, Denis Briand wrote:
> tags 429606 moreinfo
> severity 429606 minor
> thanks
> 
> 
> Hello,
> Is this issue fixed on 2.8.9dev4 version?
> regards

Well - note my response pointing out that the issue with symbolic links
was by design.  There was no followup from the OP pursuing the question
of a hardlink.  (Generally, if there's some followup explaining why they
wanted a change, I'll either explain why not, or make the change, but
lacking a dialogue, there's little to go on).

The feature in question had been there more than ten years:

http://lynx.isc.org/current/CHANGES.html#v2.8.1dev.20

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#763731: terminfo: linux (linux-basic: CP437), linux-vt entries vs. ACS support

[Thomas Dickey]

On Thu, Oct 02, 2014 at 08:51:32AM +, Ivan Shmakov wrote:
> Source:   ncurses
> Version:  5.9+20140913-1
> Control:  affects -1  console-setup
> Tags: patch
> Severity: minor
> 
>   As of the current version of the Terminfo database, the ‘linux’
>   terminal entry implies the use of the CP437 encoding for the
>   box-drawing characters and the like (also known as “alternate
>   character set”, or ACS):
...
>   This is hardly a safe assumption these days, especially taking
>   into account the widespread use of UTF-8, /including/ on ttys.

several comments.

a) this should be merged with #515609

b) no progress has been observed in upstream (Linux kernel of course) in
   making the SCS patch referred to in #515609 an official part of Linux.

   When I investigated this earlier, I found that it wasn't - in fact did
   _not_ work for the kernels which Debian provided.  We can discuss this if
   the situation has changed.

c) the documentation in console_codes hasn't been updated for instance.
   The only "recent" (past 6 years) change there was the note about erase
   with "3" parameter since Linux 3.0.

d) this report does prescribe a change, but lacks the patch which is indicated
   in the flags.

e) the choice of enacs is problematic since the documentation (console_codes
   manpage) is pretty clear:

   ESC ( B   Select default (ISO 8859-1 mapping)
   ESC ( 0   Select VT100 graphics mapping

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#763731: terminfo: linux (linux-basic: CP437), linux-vt entries vs. ACS support

[Thomas Dickey]

On Sat, Oct 04, 2014 at 01:34:37PM -0400, Thomas Dickey wrote:
>When I investigated this earlier, I found that it wasn't - in fact did
>_not_ work for the kernels which Debian provided.  We can discuss this if
>the situation has changed.

In a quick check (using "TERM=linux-vt tack"), the Debian7 configuration does
not show line-drawing).  Likewise Debian/testing.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature