Bug#1066263: xfonts-utils: FTBFS: ../fonttosfnt/util.c:89:10: error: implicit declaration of function ‘vasprintf’; did you mean ‘vsprintf’? [-Werror=implicit-function-declaration]

[Thomas Dickey]

On Wed, Mar 13, 2024 at 10:44:07PM +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 13, 2024 at 12:46:49PM +0100, Lucas Nussbaum wrote:
> > > ../fonttosfnt/util.c: In function ‘vsprintf_alloc’:
> > > ../fonttosfnt/util.c:89:10: error: implicit declaration of function 
> > > ‘vasprintf’; did you mean ‘vsprintf’? 
> > > [-Werror=implicit-function-declaration]
> Looks like it's caused by the lack of -D_GNU_SOURCE, not sure who should
> set it. There is a very old debian/changelog entry about temporarily
> setting it from d/rules and fonttosfnt/write.c sets it but
> fonttosfnt/util.c doesn't and there is nothing related in the autotools
> stuff.

The Debian rules file is rather old, which may be the problem.

https://salsa.debian.org/xorg-team/font/xfonts-utils

In my (other) test packages, I haven't had to add -D_DEFAULT_SOURCE,**
only for non-package builds has that been necessary.

** -D_GNU_SOURCE should only be used for the rare program relying upon
   non-POSIX interfaces.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1066469: tack: FTBFS: configure: error: No curses header-files found

[Thomas Dickey]

On Wed, Mar 13, 2024 at 07:03:29PM +0100, Sven Joachim wrote:
> On 2024-03-13 13:08 +0100, Lucas Nussbaum wrote:
> 
> > Source: tack
> > Version: 1.08-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240313 ftbfs-trixie
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> >
> > Relevant part (hopefully):
> >> configure: WARNING: pkg-config is not installed
> >> checking for specific curses-directory... no
> >> checking for specified curses library type... curses
> >> checking for extra include directories... no
> >> checking if we have identified curses headers... none
> >> configure: error: No curses header-files found
> >>tail -v -n \+0 config.log
> 
> This reminds me that I really should update the tack package to a newer
> version.  The error is still present in tack 1.09 (the latest stable
> release), but fixed as of tack 1.09-20230201 (the latest development
> snapshot).
> 
> @Thomas: since tack 1.09 is more than four years old and there has been
> no new snapshot for over a year, how about releasing tack 1.10?  This
> bug will likely hit other distros as they upgrade to GCC 14.

I suppose so - though others seem okay with the snapshots
(I'll take a look "soon" - am working on Lynx at the moment)

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]

[Thomas Dickey]

On Wed, Mar 13, 2024 at 03:09:03PM +0500, Andrey Rakhmatullin wrote:
> On Sun, Mar 10, 2024 at 05:51:43AM -0400, Thomas Dickey wrote:
> > | configure:7811: gcc -c -g -O2 -Werror=implicit-function-declaration
> > | -ffile-prefix-map=/<>=. -fstack-protector-strong
> > | -fstack-clash-protection -Wformat -Werror=format-security -fPIE
> > | -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
> > | -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_DEFAULT_SOURCE conftest.c >&5
> > | configure: In function 'main':
> > | configure:7804:12: error: implicit declaration of function 'tgoto'
> > 
> > already fixed upstream,
> > over a year ago,
> > if someone chose to upgrade.
> > 
> > https://invisible-island.net/cdk/CHANGES.html#t20230201
> I tried to cherry-pick the changes, but "simply" diffing aclocal.m4 in the

that wouldn't go well, because it involved redesigning the checks

> last two upstream releases and removing hunks that only change the
> comments didn't produce a diff that can be applied directly to the older
> version in Debian so somebody needs to either indeed update to the latest
> version or make a usable diff.

upgrading really is the simplest solution - not much depends on this,
and nothing cares about the actual version:

libcdk5nc6
Reverse Depends:
  libcdk5-dev
  osmo-bsc-meas-utils
  cpm
  libcdk-perl
  gphoto2

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]

[Thomas Dickey]

- Original Message -
| From: "Sebastian Ramacher" 
| To: "Debian Bug Tracking System" 
| Sent: Saturday, March 9, 2024 3:57:04 PM
| Subject: Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: 
implicit declaration of function 'tgoto'
| [-Werror=implicit-function-declaration]

| Source: libcdk5
| Version: 5.0.20180306-3.1
| Severity: serious
| Tags: ftbfs
| Justification: fails to build from source (but built successfully in the past)
| X-Debbugs-Cc: sramac...@debian.org
| 
| 
https://buildd.debian.org/status/fetch.php?pkg=libcdk5=armel=5.0.20180306-3.1=1709540851=0
| 
| configure:7811: gcc -c -g -O2 -Werror=implicit-function-declaration
| -ffile-prefix-map=/<>=. -fstack-protector-strong
| -fstack-clash-protection -Wformat -Werror=format-security -fPIE
| -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
| -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_DEFAULT_SOURCE conftest.c >&5
| configure: In function 'main':
| configure:7804:12: error: implicit declaration of function 'tgoto'

already fixed upstream,
over a year ago,
if someone chose to upgrade.

https://invisible-island.net/cdk/CHANGES.html#t20230201

-- 
Thomas E. Dickey 
https://invisible-island.net

Bug#1062246: libcdk5: NMU diff for 64-bit time_t transition

[Thomas Dickey]

On Thu, Feb 01, 2024 at 07:54:08PM +0100, Sven Joachim wrote:
> On 2024-01-31 20:15 +, Steve Langasek wrote:
> 
> > Source: libcdk5
> > Version: 5.0.20180306-3
...

upstream is about 6 years newer.

> As you likely have noticed, an upload to experimental was not possible
> because a newer version is already there.  What is the backup plan?

...and that's still a few years out of date.

(aside from soname, no ABI changes that I recall - upgrading is recommended)

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1056340: 6.4+20231118-1 screws many terminal utilities

[Thomas Dickey]

On Tue, Nov 21, 2023 at 04:02:20PM -0500, Thomas Dickey wrote:
> On Tue, Nov 21, 2023 at 05:33:54PM +0100, Sven Joachim wrote:
> > Control: reassign -1 libncursesw6 6.4+20231118-1
> > Control: severity -1 grave
> > 
> > On 2023-11-21 12:32 +0100, Gianluigi Tiesi wrote:
> > 
> > > Source: ncurses
> > > Severity: important
> > > X-Debbugs-Cc: sher...@gmail.com
> > >
> > > I've updated to 6.4+20231118-1 version of ncurses but many
> > > utils are screwed, tested in konsole and linux console (vt)
> > >
> > > htop shows a lot of ^@ characters
> 
> thanks - I can reproduce this (will fix)

I see - I misread the older logic for waddnstr in last week's fix,
and will amend that more/less as suggested.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1056340: 6.4+20231118-1 screws many terminal utilities

[Thomas Dickey]

On Tue, Nov 21, 2023 at 05:33:54PM +0100, Sven Joachim wrote:
> Control: reassign -1 libncursesw6 6.4+20231118-1
> Control: severity -1 grave
> 
> On 2023-11-21 12:32 +0100, Gianluigi Tiesi wrote:
> 
> > Source: ncurses
> > Severity: important
> > X-Debbugs-Cc: sher...@gmail.com
> >
> > I've updated to 6.4+20231118-1 version of ncurses but many
> > utils are screwed, tested in konsole and linux console (vt)
> >
> > htop shows a lot of ^@ characters

thanks - I can reproduce this (will fix)

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1054022: libncursesw6: broken in GNU Screen

[Thomas Dickey]

On Mon, Oct 16, 2023 at 06:36:40PM +0200, Sven Joachim wrote:
> On 2023-10-16 04:36 +0200, Vincent Lefevre wrote:
> 
> > Package: libncursesw6
> > Version: 6.4+20231007-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > With libncursesw6 6.4+20231007-1, I get the following issue:
> >
> > $ screen -dRR mutt /usr/bin/mutt
> > [screen is terminating]
> >
> > after a few seconds (or immediately "[screen is terminating]" when
> > I hit a key). When rebuilding Mutt with debug support, this shows
> > that Mutt is actually running, but with no output, and I don't know
> > why it terminates.
> 
> The strace output you sent gives a hint.
> 
> > 659013 write(2, "Error opening terminal: screen.xterm-256color.\n", 47) = 47
> 
> This message is coming from ncurses' initscr() function, which
> terminates the program if it cannot setup the terminal.
> 
> > Downgrading the ncurses packages to 6.4+20230625-2 makes this problem
> > disappear.
> 
> Since I was able to reproduce the problem, I bisected it and found the
> following change as the culprit:
> 
> ,
> | 20231001
> | + modify setupterm to provide for using ANSI cursor-position report (in
> |   user6/user7 terminfo capabilities) to obtain screensize if neither
> |   environment variables or ioctl is used.  The ncurses test-program
> |   with options "-E -T" demonstrates this feature.
> `
> 
> Reverting ncurses/tinfo/lib_setup.c to the 20230923 patchlevel made the
> problem disappear.  I'll leave it to Thomas to work out the details.

I suppose it's timing.

I was unable to reproduce it if any tracing (ncurses or strace) was active.
Without that - once or twice out of a few dozen tries, screen exited without
any message.

I'm making the feature optional for now.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1054022: libncursesw6: broken in GNU Screen

[Thomas Dickey]

On Mon, Oct 16, 2023 at 04:36:07AM +0200, Vincent Lefevre wrote:
> Package: libncursesw6
> Version: 6.4+20231007-1
> Severity: grave
> Justification: renders package unusable
> 
> With libncursesw6 6.4+20231007-1, I get the following issue:
> 
> $ screen -dRR mutt /usr/bin/mutt
> [screen is terminating]
> 
> after a few seconds (or immediately "[screen is terminating]" when
> I hit a key). When rebuilding Mutt with debug support, this shows
> that Mutt is actually running, but with no output, and I don't know
> why it terminates.
> 
> Same issue with
> 
>   screen -dRR mutt sh -c "true; /usr/bin/mutt"
> 
> but
> 
>   screen -dRR mutt sh -c "sleep 1; /usr/bin/mutt"
> 
> appears to work. Some kind of race condition?
> 
> With
> 
>   /usr/bin/screen -dRR mutt strace -f -o str.out -s 256 /usr/bin/mutt
...
> Downgrading the ncurses packages to 6.4+20230625-2 makes this problem
> disappear.

hmm - at least it's not likely the tiparm fixes from April.

But in a quick check to "upgrade", my sources.list to investigate this,
I get stopped by the "improvements".  It might help if you posted the
corresponding sources.list (or are you using the separate gpg stuff?).
 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> merged-usr: no
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.5.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libncursesw6 depends on:
> ii  libc6  2.37-12
> ii  libtinfo6  6.4+20231007-1
> 
> Versions of packages libncursesw6 recommends:
> ii  libgpm2  1.20.7-10+b1
> 
> libncursesw6 suggests no packages.
> 
> -- no debconf information
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1035621: ncurses: FTBFS: dh_autoreconf error on various architectures

[Thomas Dickey]

On Sun, May 07, 2023 at 01:04:49PM +0200, Sven Joachim wrote:
> Control: clone -1 -2
> Control: reassign -2 autoconf-dickey
> Control: tags -2 - ftbfs
> Control: retitle -2 autoreconf-dickey runs in all subdirectories
> 
> On 2023-05-06 16:44 -0400, Thomas Dickey wrote:
> 
> > On Sat, May 06, 2023 at 10:27:54PM +0200, Sven Joachim wrote:
> >>
> >> Since Autoconf 2.53 subdirectories are only processed if they are in
> >> AC_CONFIG_SUBDIRS or explicitly given on the command line[2], but at
> >> least for now I have to make do with Autoconf 2.52.20230114.
> >
> > hmm - incorporating that change isn't what I had in mind.
> >
> > I'd just use autoconf-dickey (rather than autoreconf-dickey, in any case),
> > since only the first part of this is useful:
> >
> >Run  `autoconf'  (and  `autoheader', `aclocal', `automake', 
> > `autopoint'
> >(formerly `gettextize'), and `libtoolize' where appropriate) 
> > repeatedly
> >to remake the GNU Build System files in specified DIRECTORIES and 
> > their
> >subdirectories (defaulting to `.').
> 
> Thanks for the tip, that seems to work.  Actually I should run
> autoconf-dickey in both the toplevel and the test/ directory, since
> test/configure is used in the Debian build process, and while we are not
> currently patching any files in the test directory, this might change in
> the future.
> 
> Anyway, if my research on codesearch.debian.net is correct, there are
> currently seven packages in the archive which invoke autoreconf-dickey
> in debian/rules, so it would seem desirable to fix that command before
> they trip over the same issue as I did here.

I don't think there are other occurrences of this, because ncurses is the
only source where I maintain more than one configure.in

fwiw, there are more than 7 package-sources in Debian which could use
"autoreconf-dickey", though I haven't checked which actually do this.

Offhand, 14:

add (tapecalc), bcpp, byacc, cdk, cproto, dialog, diffstat, luit,
lynx, mawk, ncurses, vile, vttest, xterm.

In that description of autoreconf, I'm using only the first step.

The others are unused, and as an improvement can simply be trimmed out :-)

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#965445: #965445 byacc: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Thomas Dickey]

I'm told that Dave Becket is MIA.

I'm in the process of preparing an update for this package,
and will maintain it in Debian henceforth.

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


signature.asc
Description: PGP signature

Bug#965836: #965836 tapecalc: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Thomas Dickey]

When I find someone to sign my gpg key, I'll provide an NMU for this.
It's unlikely that will happen before this deadline.

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


signature.asc
Description: PGP signature

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

[Thomas Dickey]

On Sat, Mar 06, 2021 at 06:46:25PM +0100, Sven Joachim wrote:
...
> Run xterm under valgrind and select some text.  Valgrind will be very
> unhappy with xterm 327-2+deb9u1 but should not show up any errors in

valgrind usually has something to say, but (noting that I'm only
interested in what it says when I configure --with-valgrind(*)),
I get a report of ~5000 lines using these options

OPTS="-v \
--num-callers=10 \
--error-limit=no \
--show-reachable=yes \
--leak-resolution=high \
--track-origins=yes \
--leak-check=yes \
--show-reachable=yes"

...and almost all of that is stuff that I can't fix without adding
interfaces in X11, Xt and Xaw.

(*) asan2 also has things to say, but most of that is not useful
without a complete set of debug-libraries (again, X11/Xt/Xaw).

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


signature.asc
Description: PGP signature

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

[Thomas Dickey]

On Sat, Mar 06, 2021 at 06:07:43PM +, Thorsten Glaser wrote:
> Sven Joachim dixit:
> 
> >I see that this might be a problem (albeit unlikely to happen in
> >practice), however I have trouble understanding exactly where a
> >use-after-realloc bug comes into play.  Maybe Thorsten can help me fix
> >my blindness?
> 
> The next time something is selected, the code a little further
> up will check if the allocated size is sufficient, and, if so,
> use screen->selection_data which was the pre-realloc address of
> line.
> 
> >> I am glad and surprised that sid is okay and there doesn't seem to be
> 
> The code in sid completely differs (structures, variable names, etc).

The renaming (selection_size) comes from patch #338,
which looks like this item:

Patch #338 - 2018/12/09
 * amend  solution  for  Debian  #758633  to  ensure that replies for
   bracketed  paste  are  not  sent  while processing a selection for
   exec-formatted (Debian #913237).
 
> >suggestion you could also apply the patches to the SaltTextAway()
> >function from xterm 365e.
> 
> If 365e is like 366 (currently in sid), you’ll have lots of fun due
> to the renamed everything.

366 is current.  I have some changes for 367 which I'll put out after
seeing what I can do to improve performance with fwvm active-icon.
 
> I’d rather Tom changed xterm upstream to address the realloc-failure
> difference. I know he reads Debian bugreports ;-) and he’s really
> busy so probably takes longer to respond.

it used to be the case that downstream would ask my opinion on patches
like this -- it's been a while since anyone did

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


signature.asc
Description: PGP signature

Bug#963377: xterm: FTBFS: /bin/sh: 1: col: not found

[Thomas Dickey]

On Sun, Jun 21, 2020 at 10:13:41PM +0200, Lucas Nussbaum wrote:
> Source: xterm
> Version: 356-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200620 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

col's in bsdmainutils

> > GROFF_NO_SGR=stupid /bin/sh -c "tbl ../ctlseqs.ms | groff -Tascii -ms | col 
> > -bx" >../ctlseqs.txt
> > /bin/sh: 1: col: not found
> > make[2]: *** [Makefile:180: ../ctlseqs.txt] Error 127

refer to

xterm (332-1) unstable; urgency=medium

  * Regenerate ctlseqs.txt from ctlseqs.ms (Closes: #848818).   
- Add groff to Buils-Depends.

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


signature.asc
Description: PGP signature

Bug#916349: xterm: X error (BadLength) with GNU screen

[Thomas Dickey]

- Original Message -
| From: "Vincent Lefevre" 
| To: "Thomas Dickey" , 916349-qu...@bugs.debian.org
| Cc: 916...@bugs.debian.org
| Sent: Thursday, December 13, 2018 7:20:00 PM
| Subject: Bug#916349: xterm: X error (BadLength) with GNU screen

| Control: retitle -1 xterm: X error (BadLength) when trying to display some
| glyphs
| 
| On 2018-12-13 18:35:43 -0500, Thomas Dickey wrote:
|> On Thu, Dec 13, 2018 at 06:25:42PM -0500, Thomas Dickey wrote:
|> > On Thu, Dec 13, 2018 at 02:11:28PM +0100, Vincent Lefevre wrote:
|> > > Package: xterm
|> > > Version: 338-1
|> > > Severity: grave
|> 
|> make it normal (and read the guidelines...)
| 
| I disagree. That's actually data loss, thus grave. And what makes it
| worse, this is typically from data from remote users (received mail).


fine - I'll work on the Arch bug, and will not discuss this one with you 
anymore.

bye

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

Bug#916349: xterm: X error (BadLength) with GNU screen

[Thomas Dickey]

On Thu, Dec 13, 2018 at 06:35:43PM -0500, Thomas Dickey wrote:
> On Thu, Dec 13, 2018 at 06:25:42PM -0500, Thomas Dickey wrote:
> > On Thu, Dec 13, 2018 at 02:11:28PM +0100, Vincent Lefevre wrote:
> > > Package: xterm
> > > Version: 338-1
> > > Severity: grave
> 
> make it normal (and read the guidelines...)
> 
> > 1281  openat(AT_FDCWD, 
> > "/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf", O_RDONLY) = 5
> > 1281  openat(AT_FDCWD, "/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf", 
> > O_RDONLY) = 5
> 
> Which Debian package provides this font?

never mind - I have a copy, and can see that it doesn't work with Xft/etc.
You could have found that by running

xfd -fa 'Noto Color Emoji'

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


signature.asc
Description: Digital signature

Bug#916349: xterm: X error (BadLength) with GNU screen

[Thomas Dickey]

On Thu, Dec 13, 2018 at 06:25:42PM -0500, Thomas Dickey wrote:
> On Thu, Dec 13, 2018 at 02:11:28PM +0100, Vincent Lefevre wrote:
> > Package: xterm
> > Version: 338-1
> > Severity: grave

make it normal (and read the guidelines...)

> 1281  openat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf", 
> O_RDONLY) = 5
> 1281  openat(AT_FDCWD, "/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf", 
> O_RDONLY) = 5

Which Debian package provides this font?

I need that information, plus the details of the missing glyph to reproduce
this issue.
 
> I haven't run into anything like this, of course, but with the font
> information and a (script) typescript to see what's sent to the screen,
> can probably see what's breaking.
> 
> I could add a feature to tell xterm to not exit on (certain) errors
> if it's not actually an xterm bug.  Seems it's not:
> 
> https://groups.google.com/forum/#!topic/wmii/i92CyORGZQ0
> https://bugzilla.redhat.com/show_bug.cgi?format=multiple=1498269
> https://github.com/cdown/clipmenu/issues/88

I had noticed this one, but didn't stumble onto one of the problematic
fonts when testing for missing glyphs:

https://bugs.archlinux.org/task/58706

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


signature.asc
Description: Digital signature

Bug#916349: xterm: X error (BadLength) with GNU screen

[Thomas Dickey]

On Thu, Dec 13, 2018 at 02:11:28PM +0100, Vincent Lefevre wrote:
> Package: xterm
> Version: 338-1
> Severity: grave
> Justification: renders package unusable
> 
> After upgrading xterm to 338-1, I get X errors when using GNU screen:
> 
> zira% xterm -e screen -r
> /usr/bin/xterm: warning, error event received:
> X Error of failed request:  BadLength (poly request too large or internal 
> Xlib length error)
>   Major opcode of failed request:  139 (RENDER)
>   Minor opcode of failed request:  20 (RenderAddGlyphs)

Perhaps it's a problem with the Xft improvements and a particular
glyph for which Xft/freetype2/fontconfig breaks.

The strace shows that xterm's opened a second font, and dies shortly
after:

1281  openat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf", 
O_RDONLY) = 5
1281  openat(AT_FDCWD, "/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf", 
O_RDONLY) = 5

I haven't run into anything like this, of course, but with the font
information and a (script) typescript to see what's sent to the screen,
can probably see what's breaking.

I could add a feature to tell xterm to not exit on (certain) errors
if it's not actually an xterm bug.  Seems it's not:

https://groups.google.com/forum/#!topic/wmii/i92CyORGZQ0
https://bugzilla.redhat.com/show_bug.cgi?format=multiple=1498269
https://github.com/cdown/clipmenu/issues/88

>   Serial number of failed request:  1168
>   Current serial number in output stream:  1200
> 
> This one is now always reproducible.
> 
> I've attached a compressed strace output, if this can be helpful.

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


signature.asc
Description: Digital signature

Bug#890811: lynx: FTBFS: msgfmt errors

[Thomas Dickey]

On Sun, Feb 18, 2018 at 10:45:51PM -0800, Daniel Schepler wrote:
> Source: lynx
> Version: 2.8.9dev16-2
> Severity: serious
> 
> >From my pbuilder build log:

hmm - where is that?

By the way, since your log is incomplete, there's insufficient information
to comment further.

>dh_auto_build
>make -j8

take out the -j8, for a start.

> translating ca.po to ca.gmo
> translating cs.po to cs.gmo
> translating da.po to da.gmo
> translating de.po to de.gmo
> translating eo.po to eo.gmo
> translating et.po to et.gmo
> translating fi.po to fi.gmo
> translating fr.po to fr.gmo
> ...updated homepage URL
> ...updated homepage URL
> ...updated homepage URL
> ...updated homepage URL
> ...updated homepage URL
> ...updated homepage URL
> pass1.tmp:243: keyword "Champ" unknown

This appears to be a problem with your script, which you should solve
before opening a bug report.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://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, Aug 26, 2017 at 01:37:20PM +0200, Sven Joachim wrote:
> On 2017-07-27 05:06 -0400, Thomas Dickey wrote:
> 
> > Debian's package hasn't kept up with any of the other changes in tack.
> > Let's see how long it takes for it to be updated to 1.08:
> >
> > http://invisible-island.net/ncurses/tack/CHANGES.html
> 
> Thanks for the new upstream release.  I have prepared a Debian package
> at [1], if the maintainer does not respond I will ask for a sponsor.
> 
> Cheers,
>Sven
> 
> 
> 1. https://anonscm.debian.org/git/users/joachim-guest/tack.git/log/?h=nmu

sounds good (I also considered making the ncurses headers generate
deprecation warnings, but that looked like more clutter than I'd like).

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#868609: le FTBFS with latest ncurses

[Thomas Dickey]

On Wed, Jul 26, 2017 at 05:18:57AM -0400, Thomas Dickey wrote:
> On Tue, Jul 25, 2017 at 01:19:16PM +0300, Alexander V. Lukyanov wrote:
> > On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote:
> > > > > e) fix a different fail-to-build with the opaque TERMTYPE
> > > >
> > > > I don't see how these lines are equivalent:
> > > >
> > > > -   TERMTYPE *tp = _term->type;
> > > > +   TERMTYPE *tp = (TERMTYPE *)(_term);
> > >
> > > They're the same because the first member of TERMINAL happens to be
> > > a TERMTYPE, and since TERMINAL is opaque in current code (so you
> > > cannot refer to the "type" member any longer).
> > 
> > But shouln't it be (TERMTYPE *)(cur_term) ?
> 
> hmm - I agree that doesn't look right (the problem with casts).
> I'm surprised it worked.

attaching an improved patch (with some additional compiler-warning fixes)

sadly enough, either way the cast gives no warnings, and the program
appears to run.

also attaching a copy of valgrind log from running the program with
the _nc_free_and_exit function turned on (just from opening a file,
looking at some menus and quitting - ymmv).

> > Is there a new function or macro to get current TERMTYPE, so that I could
> > use it if available?
> 
> Not syntactically the same.  This is what I use in term.h:
> 
> /* The cast works because TERMTYPE is the first data in TERMINAL */
> #define CUR ((TERMTYPE *)(cur_term))->

I'm reluctant to add a new function for accessing things that "should"
just work: the definitions in term.h are the defined interface, and
providing a function to access those in a different way doesn't seem
a good solution.

Of course, if that structure hadn't happened to be first in TERMINAL,
I'd have had to provide a function, just to keep TERMINAL opaque.

Since I'm keeping binary compatibility (aside from preventing applications
from knowing how large TERMINAL is), it's good enough for now.

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
# ftp://invisible-island.net/temp/le-1.16.3-fix2.patch.gz
# patch by Thomas E. Dickey <dic...@invisible-island.net>
# created  Sun Jul 30 21:45:33 UTC 2017
# --
# color.cc |6 +++---
# edit.cc  |   26 ++
# keymap.cc|4 ++--
# keynames.cc  |2 +-
# make-mainmenu.pl |2 +-
# regex.c  |   10 --
# 6 files changed, 33 insertions(+), 17 deletions(-)
# --
Index: src/color.cc
--- le-1.16.3/src/color.cc	2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix2/src/color.cc	2017-07-22 12:42:26.0 +
@@ -33,7 +33,7 @@
 int   can_use_default_colors;
 
 int   next_pair;
-static int find_pair(int fg,int bg)
+static int find_or_init_pair(int fg,int bg)
 {
if(!can_use_default_colors)
{
@@ -67,7 +67,7 @@
   attr_table[an].n_attr=0;
   if(pal[i].fg!=NO_COLOR || pal[i].bg!=NO_COLOR)
   {
-	 pair=find_pair(pal[i].fg,pal[i].bg);
+	 pair=find_or_init_pair(pal[i].fg,pal[i].bg);
 	 attr_table[an].n_attr|=COLOR_PAIR(pair);
   }
   attr_table[an].n_attr|=pal[i].attr;
@@ -94,7 +94,7 @@
 	 else
 	 {
 	attr_table[i].so_attr=(attr_table[i].n_attr|hl->attr)&~A_COLOR;
-	pair=find_pair(hl->fg,pal[p].bg);
+	pair=find_or_init_pair(hl->fg,pal[p].bg);
 	attr_table[i].so_attr|=COLOR_PAIR(pair);
 	 }
   }
Index: src/edit.cc
--- le-1.16.3/src/edit.cc	2015-12-03 07:15:40.0 +
+++ le-1.16.3-fix2/src/edit.cc	2017-07-22 13:15:35.0 +
@@ -53,6 +53,15 @@
 # define fcntl(x,y,z)	(0)
 #endif
 
+#ifdef HAVE__NC_FREE_AND_EXIT
+extern "C" {
+extern void _nc_free_and_exit(int);
+#define ExitProgram(code) _nc_free_and_exit(code)
+};
+#else
+#define ExitProgram(code) exit(code)
+#endif
+
 #include 
 #include "localcharset.h"
 
@@ -385,7 +394,7 @@
if(le_scr==NULL)
{
   fprintf(stderr,"le: newterm() failed. Check your $TERM variable.\n");
-  exit(1);
+  ExitProgram(1);
}
 #endif
 
@@ -529,7 +538,7 @@
 
TermCurses();
 
-   exit(0);
+   ExitProgram(0);
 }
 
 void  PrintUsage(int arg)
@@ -557,7 +566,7 @@
 	  "\n"
 	  "The last file will be loaded. If no files specified, last readable file\n"
 	  "from history will be loaded if the path is relative or it is the last.\n");
-   exit(1);
+   ExitProgram(1);
 }
 
 #if USE_MULTIBYTE_CHARS
@@ -680,19 +689,19 @@
 	 break;
   case('?'):
 	 fprintf(stderr,"%s: Try `%s --help' for more information\n",Program,argv[0]);
-	 exit(1);
+	 ExitProgram(1);
   case(DUMP_KEYMAP):
 	 WriteActionMap(stdout);
-	 exit(0);
+	 ExitPr

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:
> 
> ,
> | 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.

Debian's package hasn't kept up with any of the other changes in tack.
Let's see how long it takes for it to be updated to 1.08:

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

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


signature.asc
Description: Digital signature

Bug#863969: marked as pending

[Thomas Dickey]

On Sat, Jun 03, 2017 at 08:31:28AM +, Sven Joachim wrote:
> tag 863969 pending
> thanks
> 
> Hello,
> 
> Bug #863969 reported by you has been fixed in the Git repository. You can
> see the changelog below, and you can check the diff of the fix at:
> 
> 
> https://anonscm.debian.org/cgit/collab-maint/ncurses.git/commit/?id=d5bc8bb
> 
> ---
> commit d5bc8bb04b3d0092f898263c8dc58f746dde9bae
> Author: Sven Joachim 
> Date:   Sat Jun 3 10:24:25 2017 +0200
> 
> Blacklist dvtm and dvtm-256color terminfo entries

Actually the upstream dvtm description has more than one error, which
I noticed (and fixed).
 
> They are already shipped in the dvtm package.  While it would be
> desirable to take the files over in ncurses-term, this requires
> consent from the dvtm maintainer who is currently unavailable as per
> https://www.debian.org/News/2017/20170417.

:-)
 
> diff --git a/debian/changelog b/debian/changelog
> index f3eacb8..58001ba 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +ncurses (6.0+20170408-2) UNRELEASED; urgency=low
> +
> +  * Blacklist dvtm and dvtm-256color terminfo entries which are shipped
> +in the dvtm package (Closes: #863969).
> +
> + -- Sven Joachim   Sat, 03 Jun 2017 09:50:35 +0200
> +
>  ncurses (6.0+20170408-1) experimental; urgency=low
>  
>* New upstream patchlevel.
> 

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


signature.asc
Description: Digital signature

Bug#868609: le FTBFS with latest ncurses

[Thomas Dickey]

On Tue, Jul 25, 2017 at 01:19:16PM +0300, Alexander V. Lukyanov wrote:
> On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote:
> > > > e) fix a different fail-to-build with the opaque TERMTYPE
> > >
> > > I don't see how these lines are equivalent:
> > >
> > > -   TERMTYPE *tp = _term->type;
> > > +   TERMTYPE *tp = (TERMTYPE *)(_term);
> >
> > They're the same because the first member of TERMINAL happens to be
> > a TERMTYPE, and since TERMINAL is opaque in current code (so you
> > cannot refer to the "type" member any longer).
> 
> But shouln't it be (TERMTYPE *)(cur_term) ?

hmm - I agree that doesn't look right (the problem with casts).
I'm surprised it worked.
 
> Is there a new function or macro to get current TERMTYPE, so that I could
> use it if available?

Not syntactically the same.  This is what I use in term.h:

/* The cast works because TERMTYPE is the first data in TERMINAL */
#define CUR ((TERMTYPE *)(cur_term))->

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#868609: le FTBFS with latest ncurses

[Thomas Dickey]

On Tue, Jul 25, 2017 at 10:04:02AM +0300, Alexander V. Lukyanov wrote:
> On Sat, Jul 22, 2017 at 10:52:19AM -0400, Thomas Dickey wrote:
> > c) add a cast to fix a signed/unsigned compiler warning
> 
> I will check if a newer/better version of regex.c if available in emacs (it 
> was taken from there).
> 
> > d) add (to help with running valgrind) the ExitProgram macro
> 
> Where is HAVE__NC_FREE_AND_EXIT defined?

It would be defined if you had (an optional) configure check for
_nc_free_and_exit.

I do this for example when debugging ncurses applications and want to check
for memory leaks.  But see

http://invisible-island.net/ncurses/ncurses.faq.html#config_leaks

> > e) fix a different fail-to-build with the opaque TERMTYPE
> 
> I don't see how these lines are equivalent:
> 
> -   TERMTYPE *tp = _term->type;
> +   TERMTYPE *tp = (TERMTYPE *)(_term);

They're the same because the first member of TERMINAL happens to be
a TERMTYPE, and since TERMINAL is opaque in current code (so you
cannot refer to the "type" member any longer).

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#868609: le FTBFS with latest ncurses

[Thomas Dickey]

To ensure that I made a correct fix, I test-compiled le-1.16.3 and ran it.
Doing that, I noticed some additional issues (partly because I did not
override the makefile's C++ variables, but that was just as well, since
it prompted me to do the extra fixes):

a) renamed the private symbol find_pair to find_or_init_pair
b) include unistd.h to get prototype for write()
c) add a cast to fix a signed/unsigned compiler warning
d) add (to help with running valgrind) the ExitProgram macro
e) fix a different fail-to-build with the opaque TERMTYPE

Having done that, in a quick check the menus came up, and valgrind
had only reported an issue with linux_process_key() which I suppose
Alexander is familiar with.

There are still more than a hundred compiler warnings.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net
# patch by Thomas E. Dickey 
# created  Sat Jul 22 14:39:46 UTC 2017
# --
# color.cc|6 +++---
# edit.cc |   26 ++
# keynames.cc |2 +-
# regex.c |8 ++--
# 4 files changed, 28 insertions(+), 14 deletions(-)
# --
Index: src/color.cc
--- le-1.16.3/src/color.cc	2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix/src/color.cc	2017-07-22 12:42:26.382956801 +
@@ -33,7 +33,7 @@
 int   can_use_default_colors;
 
 int   next_pair;
-static int find_pair(int fg,int bg)
+static int find_or_init_pair(int fg,int bg)
 {
if(!can_use_default_colors)
{
@@ -67,7 +67,7 @@
   attr_table[an].n_attr=0;
   if(pal[i].fg!=NO_COLOR || pal[i].bg!=NO_COLOR)
   {
-	 pair=find_pair(pal[i].fg,pal[i].bg);
+	 pair=find_or_init_pair(pal[i].fg,pal[i].bg);
 	 attr_table[an].n_attr|=COLOR_PAIR(pair);
   }
   attr_table[an].n_attr|=pal[i].attr;
@@ -94,7 +94,7 @@
 	 else
 	 {
 	attr_table[i].so_attr=(attr_table[i].n_attr|hl->attr)&~A_COLOR;
-	pair=find_pair(hl->fg,pal[p].bg);
+	pair=find_or_init_pair(hl->fg,pal[p].bg);
 	attr_table[i].so_attr|=COLOR_PAIR(pair);
 	 }
   }
Index: src/edit.cc
--- le-1.16.3/src/edit.cc	2015-12-03 07:15:40.0 +
+++ le-1.16.3-fix/src/edit.cc	2017-07-22 13:15:35.326113146 +
@@ -53,6 +53,15 @@
 # define fcntl(x,y,z)	(0)
 #endif
 
+#ifdef HAVE__NC_FREE_AND_EXIT
+extern "C" {
+extern void _nc_free_and_exit(int);
+#define ExitProgram(code) _nc_free_and_exit(code)
+};
+#else
+#define ExitProgram(code) exit(code)
+#endif
+
 #include 
 #include "localcharset.h"
 
@@ -385,7 +394,7 @@
if(le_scr==NULL)
{
   fprintf(stderr,"le: newterm() failed. Check your $TERM variable.\n");
-  exit(1);
+  ExitProgram(1);
}
 #endif
 
@@ -529,7 +538,7 @@
 
TermCurses();
 
-   exit(0);
+   ExitProgram(0);
 }
 
 void  PrintUsage(int arg)
@@ -557,7 +566,7 @@
 	  "\n"
 	  "The last file will be loaded. If no files specified, last readable file\n"
 	  "from history will be loaded if the path is relative or it is the last.\n");
-   exit(1);
+   ExitProgram(1);
 }
 
 #if USE_MULTIBYTE_CHARS
@@ -680,19 +689,19 @@
 	 break;
   case('?'):
 	 fprintf(stderr,"%s: Try `%s --help' for more information\n",Program,argv[0]);
-	 exit(1);
+	 ExitProgram(1);
   case(DUMP_KEYMAP):
 	 WriteActionMap(stdout);
-	 exit(0);
+	 ExitProgram(0);
   case(DUMP_COLORS):
 	 DumpDefaultColors(stdout);
-	 exit(0);
+	 ExitProgram(0);
   case(PRINT_HELP):
 	 PrintUsage(0);
-	 exit(0);
+	 ExitProgram(0);
   case(PRINT_VERSION):
 	 PrintVersion();
-	 exit(0);
+	 ExitProgram(0);
   case(USE_MMAP):
 	 opt_use_mmap=1;
 	 if(optView==-1)
@@ -793,5 +802,6 @@
}
Edit();
Terminate();
+   ExitProgram(0);
return 0;
 }
Index: src/keynames.cc
--- le-1.16.3/src/keynames.cc	2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix/src/keynames.cc	2017-07-22 14:37:00.829660294 +
@@ -353,7 +353,7 @@
 
if(!cur_term)
   return;
-   TERMTYPE *tp = _term->type;
+   TERMTYPE *tp = (TERMTYPE *)(_term);
if(!tp)
   return;
if(NUM_STRINGS(tp)<=STRCOUNT)
Index: src/regex.c
--- le-1.16.3/src/regex.c	2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix/src/regex.c	2017-07-22 12:52:29.475732342 +
@@ -202,6 +202,10 @@
 char *realloc ();
 # endif
 
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
 /* When used in Emacs's lib-src, we need xmalloc and xrealloc. */
 
 void *
@@ -2152,7 +2156,7 @@
 re_wctype (str)
  re_char *str;
 {
-  const char *string = str;
+  const char *string = (const char *)str;
   if  (STREQ (string, "alnum"))	return RECC_ALNUM;
   else if (STREQ (string, "alpha"))	return RECC_ALPHA;
   else if (STREQ (string, "word"))	return RECC_WORD;
@@ -2742,7 +2746,7 @@
 	main_pend = pend;
 	main_pattern = pattern;
 	p = pattern = whitespace_regexp;
-	pend = p + strlen (p);
+	pend = p + strlen ((const char *) p);
 	break;
 	  }
 

Bug#868609: le FTBFS with latest ncurses

[Thomas Dickey]

On Mon, Jul 17, 2017 at 02:51:22PM +0300, Alexander V. Lukyanov wrote:
> On Mon, Jul 17, 2017 at 05:28:09AM -0400, Thomas Dickey wrote:
> > On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote:
> > > On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote:
> > > > Source: le
> > > > Version: 1.16.3-1
> > > > Severity: serious
> > > > Tags: buster sid
> > > >
> > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html

This is a problem with "le".  I'm reassigning to that program, along with
a patch to fix the issues I found.

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#868609: le FTBFS with latest ncurses

[Thomas Dickey]

On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote:
> On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote:
> > Source: le
> > Version: 1.16.3-1
> > Severity: serious
> > Tags: buster sid
> >
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html
> >
> > ...
> > gcc -DHAVE_CONFIG_H -I. -I../lib  -I../lib -I../lib -I/usr/include/ncursesw 
> > -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual 
> > -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc
> > color.cc: In function 'int find_pair(int, int)':
> > color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and 
> > later 'static' [-fpermissive]
> >  static int find_pair(int fg,int bg)
> > ^
> > In file included from edit.h:36:0,
> >  from color.cc:27:
> > /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int 
> > find_pair(int, int)'
> >  extern NCURSES_EXPORT(int) find_pair (int, int);
> > ^
> > Makefile:1299: recipe for target 'color.o' failed
> > make[3]: *** [color.o] Error 1
> 
> ncurses was extended with new symbols, some of which conflict with "le"
> internal names. So either ncurses should be fixed not to export these
> symbols by default or le should be fixed to rename its identifiers.

hmm - not that I'm oblivious to the problem, but (for example) a quick
check on an alternate name "find_color_pair" finds existing usage too.
This problem will come up since there's no namespaces in C (not that
C++ is free from the problem).

So... I could look for a rarely-used name (which still gives the same
connotations), or the couple of applications using ncurses could be
modified.

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


signature.asc
Description: Digital signature

Bug#868328: libtinfo5: ABI break: _nc_read_entry symbol dropped

[Thomas Dickey]

On Fri, Jul 14, 2017 at 09:45:50PM +0200, Sven Joachim wrote:
> On 2017-07-14 18:57 +0200, Sven Joachim wrote:
> 
> > On 2017-07-14 16:13 +0200, Sven Joachim wrote:
> >
> >> The symbol _nc_read_entry got inadvertently dropped in favor of
> >> _nc_read_entry2, and this breaks reverse dependencies (ncurses-bin
> >> before 6.0+20170701-1 and tack):
> >
> > This happened because _nc_read_entry is only compiled in if
> > NCURSES_EXT_NUMBERS is #defined and not 0.  There's probably a good reason
> > for this, since when I take out this condition infocmp from stretch
> > segfaults.
> >
> > Bringing back the previous implementation of _nc_read_entry instead
> > seems to work, as in the attached patch.  While this might to be good
> > enough for Debian, upstream likely want a better solution that works
> > with other configure flags as well.
> 
> Another point interesting for upstream here, although it does not affect
> the current Debian package: even when building --with-abi-version=6
> (i.e. the default), _nc_read_entry is still missing from the tinfo
> library unless --enable-widec is also given.

The (small) fix I made yesterday seems to fix both configurations.
If it doesn't, I'll investigate further, given the relevant configure
options.

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


signature.asc
Description: Digital signature

Bug#860751: Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Thomas Dickey]

On Thu, Apr 20, 2017 at 05:11:17PM +0200, Bernhard Übelacker wrote:
> Hello,
> this seems to be the same problem seen in #391051 for regular
> expressions (collect_RE).
> 
> In this bug we overrun the size limit of string_buff (tempbuff._string_buff)
> in function collect_string.
> 
> Attached patch adds a similar check like in #391051 to collect_string.

hmm - upstream mawk makes 7 checks like this in scan.c

start here:

https://github.com/ThomasDickey/mawk-snapshots/blob/master/scan.c#L72

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


signature.asc
Description: Digital signature

Bug#848818: xterm: ctlseqs.txt is not rebuilt from ctlseq.ms

[Thomas Dickey]

severity 848818 wishlist
close 848818

I'm not going to discuss this further -

https://www.debian.org/Bugs/Developer#severities
http://invisible-island.net/personal/changelogs.html#problem_hostile

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


signature.asc
Description: Digital signature

Bug#848818: xterm: ctlseqs.txt is not rebuilt from ctlseq.ms

[Thomas Dickey]

On Mon, Dec 19, 2016 at 02:39:27PM -0800, Ben Longbons wrote:
> Package: xterm
> Version: 327-2
> Severity: serious

severity's incorrect.

You should change that.

> Justification: Policy 2.1
> 
> Dear Maintainer,
> 
> The ctlseqs.txt file is not built from ctlseqs.ms if it is modified
> (which it should be, since it is wrong in a few places).

I don't recall any bug reports on the topic.  The only to-do item for
ctlseqs.ms which I _have_ is a comment from a different person that at
least one item isn't ordered alphabetically.  I'm working on _that_,
now (another script to check the file).

ctlseqs.txt is part of the upstream sources, has been since June 2006.

Each time I make an update to ctlseqs.ms, I regenerate the ".txt" file
using the rule in the makefile.  If it's not, my test-builds would fail.

Since all of the upstream source has proper timestamps, there's
nothing to rebuild.  Debian builds from pristine upstream source, so
there's no reason for timestamp contamination, say, by pulling it from
someone's source repo.
 
> The command to bytewise-reproduce the existing file is:
> 
> $ groff -P{-c,-b,-o,-u} -Tascii -t -ms < ctlseqs.ms > ctlseqs.txt
> 
> Note: You need to add a build-dep on `groff`, not just `groff-base`,
> in order to install the macro packages `-ms`.
> 
> But there are some *better* command variants.
> 
> * Remove the -P options to preserve formatting, less can handle it.

The makefile doesn't use -P.

> * -Tutf8 (better quotes/bullets; the VT fonts have everything they need).

no.  It's an ASCII file.  Pretty bullets don't help much, considering that
less than 1% of the file uses that.  For interesting typography, refer to
the PDF.

> * -Tpdf

You can do this with the makefile.

> * -Thtml
> 
> The html and pdf formats provide significant features not in the txt

groff's html format isn't useful.  I don't use that anymore:

http://invisible-island.net/scripts/man2html.html

> version, though the PDF doesn't have a Table of Contents.

hmm - ms macros are said to support table of contents,

https://www.hactrn.net/ietf/rfcgen/textms.html

but I've not found it necessary, e.g, generated with man2html plus
a post-processing script to construct the navigation area:

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

> -Ben
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32, arm64
> 
> Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages xterm depends on:
> ii  libc6   2.24-8
> ii  libfontconfig1  2.11.0-6.7
> ii  libice6 2:1.0.9-1+b1
> ii  libtinfo5   6.0+20161126-1
> ii  libutempter01.1.6-3
> ii  libx11-62:1.6.4-2
> ii  libxaw7 2:1.0.13-1
> ii  libxft2 2.3.2-1
> ii  libxinerama12:1.1.3-1+b1
> ii  libxmu6 2:1.1.2-2
> ii  libxpm4 1:3.5.11-1+b1
> ii  libxt6  1:1.1.5-1
> ii  xbitmaps1.1.1-2
> 
> Versions of packages xterm recommends:
> ii  x11-utils  7.7+3
> 
> Versions of packages xterm suggests:
> ii  xfonts-cyrillic  1:1.0.4
> 
> -- no debconf information
> 

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


signature.asc
Description: Digital signature

Bug#827905: Character U+2028 can yield file corruption when edited in xterm

[Thomas Dickey]

On Wed, Jul 13, 2016 at 08:23:34PM +0200, Sven Joachim wrote:
> On 2016-06-22 13:46 +0200, Vincent Lefevre wrote:
> 
> > Control: reassign -1 xterm 325-1
> 
> This problem seems to stem from the attempt to fix bug #738794, at least
> it is not present in xterm 324 and earlier.

agreed (I'm studying it to see how to improve that).

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


signature.asc
Description: Digital signature

Bug#827905: Character U+2028 can yield file corruption when edited in xterm

[Thomas Dickey]

On Thu, Jul 14, 2016 at 07:27:52PM +0200, Sven Joachim wrote:
> On 2016-07-13 18:24 -0700, Vincent Lefevre wrote:
> 
> > On 2016-07-13 20:15:49 -0400, Thomas Dickey wrote:
> >> I don't see the behavior which is described, and haven't seen any
> >> suitable justification for marking this as a "grave" issue, rather
> >> than "normal".  Keep in mind that this is a rarely used line-break
> >> character.
> >
> > This is not common, but this was sufficient to *silently* corrupt one
> > of my files (what makes things really worse is that the corruption
> > doesn't seem to appear immediately, and one notices it when it may be
> > too late).
> >
> >> What I see on the screen is a box-outline for the nonprintable
> >> character (no space).
> >
> > Could this depend on some library version or on the font?
> 
> On the latter.  With the default font I see no corruption, but with the
> 9x15 font, for instance.  See the attached screenshot.

9x15 is an ISO-8859-1 font, and can't show U+2028

-- 
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#827905: Character U+2028 can yield file corruption when edited in xterm

[Thomas Dickey]

On Wed, Jul 13, 2016 at 08:23:34PM +0200, Sven Joachim wrote:
> On 2016-06-22 13:46 +0200, Vincent Lefevre wrote:
> 
> > Control: reassign -1 xterm 325-1
> 
> This problem seems to stem from the attempt to fix bug #738794, at least
> it is not present in xterm 324 and earlier.
> 
> > Control: retitle -1 Character U+2028 can yield file corruption when edited 
> > in xterm
> >
> > This seems to be an xterm bug since there is no such problem in
> > urxvt and mlterm, where U+2028 takes its own space. Moreover, I
> > get exactly the same problem with vi in xterm.
> 
> > On 2016-06-22 12:48:46 +0200, Vincent Lefevre wrote:
> >> When editing a file where a line started by the U+2028 character,
> >> it got corrupted. Basically, what was stored is not what was
> >> displayed.
> >
> > To reproduce the beginning of a corruption:
> >
> > 1. Type: printf "\u2028abcd\n" > file
> > 2. Type: "emacs -Q -nw file" or "vi file"
> > 3. Move the cursor several times to the right.
> >
> > One gets successively:
> >
> > abcd(no cursor)
> > aacd(cursor on the 2nd column)
> > aabd(cursor on the 3rd column)
> > aabc(cursor on the 4th column)
> > aabcd   (cursor on the 5th column)
> 
> That's not quite what I get, but the output is certainly corrupted.
> Basically what I see is in Emacs (moving from column 0 to 5):
> cd → ad → ab → abc → abcd → abcd.

I don't see the behavior which is described, and haven't seen any
suitable justification for marking this as a "grave" issue, rather
than "normal".  Keep in mind that this is a rarely used line-break
character.

What I see on the screen is a box-outline for the nonprintable character
(no space).

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


signature.asc
Description: Digital signature

Bug#809646: New xterm deletes content of SHELL environment

[Thomas Dickey]

On Sat, Jan 02, 2016 at 02:23:21PM +0100, Sven Joachim wrote:
> Control: severity -1 grave
> 
> Am 02.01.2016 um 11:54 schrieb Klaus Ethgen:
> 
> > Package: xterm
> > Version: 321-1
> > Severity: important
> >
> > Today I installed the newest version of xterm. After that, most of the
> > stuff in my terminal was not working anymore. (For that I would like to
> > set the bug severity to even grave as many of my stuff, even unrelated
> > stuff is not working anymore.)
> >
> > I found out very fast that the new xterm clears the environment variable
> > $SHELL.
> 
> Ouch, sorry for not noticing that in advance.  I'm pretty sure it was
> not intended.

true - the suggested fix that I applied worked, but had a compiler warning.
My fix for _that_ was incorrect.  This works (for me):

--- /usr/build/xterm/xterm-321+/main.c  2015-12-29 15:19:35.0 +
+++ /usr/build/xterm/xterm-321a/main.c  2016-01-02 14:12:19.0 +
@@ -1,7 +1,7 @@
-/* $XTermId: main.c,v 1.776 2015/12/29 15:19:35 tom Exp $ */
+/* $XTermId: main.c,v 1.777 2016/01/02 14:12:19 tom Exp $ */
 
 /*
- * Copyright 2002-2014,2015 by Thomas E. Dickey
+ * Copyright 2002-2015,2016 by Thomas E. Dickey
  *
  * All Rights Reserved
  *
@@ -3248,8 +3248,8 @@
 if (validProgram(pathname)
&& stat(ok_shells, ) == 0
&& (sb.st_mode & S_IFMT) == S_IFREG
-   && (sb.st_size != 0)
-   && (sb.st_size < (off_t) (((size_t) ~0) - 2))
+   && ((size_t) sb.st_size > 0)
+   && ((size_t) sb.st_size < (((size_t) ~0) - 2))
&& (blob = calloc((size_t) sb.st_size + 2, sizeof(char))) != 0) {
if ((fp = fopen(ok_shells, "r")) != 0) {
rc = fread(blob, sizeof(char), (size_t) sb.st_size, fp);

-- 
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: Sven Joachim svenj...@gmx.de
| To: Helmut Grohne hel...@subdivi.de
| Cc: Thomas Dickey dic...@his.com, 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 dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-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: Helmut Grohne hel...@subdivi.de
| 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 dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


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

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 dic...@invisible-island.net
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 ko...@pm.tokushima-u.ac.jp 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 dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#752047: latter half of Chinese lines now injured suddenly

[Thomas Dickey]

- Original Message -
| From: 積丹尼 Dan Jacobson jida...@jidanni.org
| To: Thomas Dickey dic...@his.com
| Cc: 752...@bugs.debian.org
| Sent: Friday, June 20, 2014 2:35:24 AM
| Subject: Re: Bug#752047: latter half of Chinese lines now injured suddenly
| 
| Kool!

no problem (I'd like to get the italics change stable while I work on mawk and 
vile,
so regressions get my attention)

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


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

Bug#752047: latter half of Chinese lines now injured suddenly

[Thomas Dickey]

On Thu, Jun 19, 2014 at 01:14:36PM +0800, 積丹尼 Dan Jacobson wrote:
 Package: xterm
 Version: 307-1
 Severity: important
 
 Do this:
 while sleep 1; do echo 歡迎收看「小姐愛魔術」; done
 Notice how only half of the chars appear?
 Now switch to another window and then back.
 Notice how the older lines are now OK looking?

I don't see the indicated behavior in a quick check.
However, problems in this area can be hard to duplicate :-(

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


signature.asc
Description: Digital signature

Bug#752047: latter half of Chinese lines now injured suddenly

[Thomas Dickey]

On Thu, Jun 19, 2014 at 04:20:06AM -0400, Thomas Dickey wrote:
 On Thu, Jun 19, 2014 at 01:14:36PM +0800, 積丹尼 Dan Jacobson wrote:
  Package: xterm
  Version: 307-1
  Severity: important
  
  Do this:
  while sleep 1; do echo 歡迎收看「小姐愛魔術」; done
  Notice how only half of the chars appear?
  Now switch to another window and then back.
  Notice how the older lines are now OK looking?
 
 I don't see the indicated behavior in a quick check.
 However, problems in this area can be hard to duplicate :-(

now that my attention is called to it, I found a different
test (in the ncurses test-driver, menu O) which is probably
related.  I'll investigate that...

thanks

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


signature.asc
Description: Digital signature

Bug#752047: latter half of Chinese lines now injured suddenly

[Thomas Dickey]

On Fri, Jun 20, 2014 at 05:38:13AM +0800, 積丹尼 Dan Jacobson wrote:
 Anyway in all cases the final character of what does show is deformed.
 Still displays but is deformed.

I isolated a cause for the problem that I was able to reproduce, and will
be uploading #308...

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


signature.asc
Description: Digital signature

Bug#750733: Processed: bumping severity

[Thomas Dickey]

On Mon, Jun 09, 2014 at 07:48:49PM -0400, Thomas Dickey wrote:
 fixed in
 
   ftp://invisible-island.net/temp/xterm-306b.patch.gz

If something else along this line comes up, I'll work on it.

However, I'm investigating some problems with italics which Egmont Koblinger
reported, and (unless that drags on), will try to resolve those for #307.

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


signature.asc
Description: Digital signature

Bug#750733: Processed: bumping severity

[Thomas Dickey]

On Mon, Jun 09, 2014 at 07:12:11PM +, Debian Bug Tracking System wrote:
 Processing commands for cont...@bugs.debian.org:
 
  # Not sure if the problem happens with more readable fonts than 5x8,
  # but better keep this xterm version out of testing
  severity 750733 serious
 Bug #750733 [xterm] Newest version sets the foreground to the background 
 color in some cases
 Severity set to 'serious' from 'normal'
  thanks
 Stopping processing here.

fwiw, there's a fix for this in

ftp://invisible-island.net/temp/xterm-306a.patch.gz

(at the moment I'm investigating the terminfo report)

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


signature.asc
Description: Digital signature

Bug#750733: Processed: bumping severity

[Thomas Dickey]

- Original Message -
| From: Sven Joachim svenj...@gmx.de
| To: Thomas Dickey dic...@his.com
| Cc: 750...@bugs.debian.org, Klaus Ethgen kl...@ethgen.ch
| Sent: Monday, June 9, 2014 3:43:20 PM
| Subject: Re: Bug#750733: Processed: bumping severity
| 
| On 2014-06-09 21:22 +0200, Thomas Dickey wrote:
| 
|  On Mon, Jun 09, 2014 at 07:12:11PM +, Debian Bug Tracking
|  System wrote:
|  Processing commands for cont...@bugs.debian.org:
|  
|   # Not sure if the problem happens with more readable fonts than
|   5x8,
|   # but better keep this xterm version out of testing
|   severity 750733 serious
|  Bug #750733 [xterm] Newest version sets the foreground to the
|  background color in some cases
|  Severity set to 'serious' from 'normal'
|   thanks
|  Stopping processing here.
| 
|  fwiw, there's a fix for this in
| 
|  ftp://invisible-island.net/temp/xterm-306a.patch.gz
| 
| Thanks, this fixes the problem with the bold text.  However, when
| running 16colors.sh I see that text which is supposed to be
| underlined
| is not, still a regression from xterm 304.
| 

thanks (I had not noticed that).  I will work on that next...

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


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

Bug#750733: Processed: bumping severity

[Thomas Dickey]

On Mon, Jun 09, 2014 at 03:49:39PM -0400, Thomas Dickey wrote:
 - Original Message -
 | From: Sven Joachim svenj...@gmx.de
 | To: Thomas Dickey dic...@his.com
 | Cc: 750...@bugs.debian.org, Klaus Ethgen kl...@ethgen.ch
 | Sent: Monday, June 9, 2014 3:43:20 PM
 | Subject: Re: Bug#750733: Processed: bumping severity
 | 
 | On 2014-06-09 21:22 +0200, Thomas Dickey wrote:
 | 
 |  On Mon, Jun 09, 2014 at 07:12:11PM +, Debian Bug Tracking
 |  System wrote:
 |  Processing commands for cont...@bugs.debian.org:
 |  
 |   # Not sure if the problem happens with more readable fonts than
 |   5x8,
 |   # but better keep this xterm version out of testing
 |   severity 750733 serious
 |  Bug #750733 [xterm] Newest version sets the foreground to the
 |  background color in some cases
 |  Severity set to 'serious' from 'normal'
 |   thanks
 |  Stopping processing here.
 | 
 |  fwiw, there's a fix for this in
 | 
 |ftp://invisible-island.net/temp/xterm-306a.patch.gz
 | 
 | Thanks, this fixes the problem with the bold text.  However, when
 | running 16colors.sh I see that text which is supposed to be
 | underlined
 | is not, still a regression from xterm 304.
 | 
 
 thanks (I had not noticed that).  I will work on that next...

fixed in

ftp://invisible-island.net/temp/xterm-306b.patch.gz

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


signature.asc
Description: Digital signature

Bug#745835: lynx-cur: certificate revocation is not checked

[Thomas Dickey]

On Fri, Apr 25, 2014 at 07:41:31PM +0200, Vincent Lefevre wrote:
 Package: lynx-cur
 Version: 2.8.8pre5-1
 Severity: grave

In

https://www.debian.org/Bugs/Developer#severities

the closest description is important.  (This couldn't allow a breakin
to the users's account which would be the justification for grave).

By the way, the same issue applies to elinks, links2 and w3m

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


signature.asc
Description: Digital signature

Bug#719578: Patch for a cdk-perl-20130717 build failure with Perl 5.18

[Thomas Dickey]

On Fri, Aug 16, 2013 at 10:41:56AM +0200, Dominic Hargreaves wrote:
 On Thu, Aug 15, 2013 at 08:24:44PM -0400, Thomas Dickey wrote:
  On Thu, Aug 15, 2013 at 10:23:54PM +0300, Niko Tyni wrote:
   Hi Thomas,
   
   recent changes in cdk-perl-20130717 broke the build again with
   newer versions of ExtUtils::ParseXS, including the one
   bundled with Perl 5.18.
  
  thanks (I'd have found this directly, but haven't found a way to get
  5.18 other than compiling it myself - it seems that Debian/experimental
  skipped a step between 5.14 and 5.18).
 
 Debian experimental did have 5.16 at one point, and 5.18 is now in Debian
 experimental. In any case, the main practical problem with testing is the
 large number of other perl XS module packages which also need to be
 rebuilt (over 300 in the archive). This has been done for i386 and the
 results are at
 
 http://people.debian.org/~dom/perl/test/perl-5.18.0/
 
 (only suitable for a dedicated test system really).
 Apologies that this has been less than useful for package maintainers
 so far.

well, I was puzzled at the delay - I'd been tracking this since the first
report, thinking that getting a package update would be the most reliable
way to duplicate the problem.  Yesterday I downloaded perl 5.18.1 and
built that for testing this problem (as well as verifying that vile's
perl.xs was not affected).

I didn't see any additional fixes (including compiler warnings) that
I should make to cdk-perl, so I marked that as 20130816.  There was
some outage on my ISP yesterday; I've uploaded the version with this
patch.  Later when I'm done with my changes to cdk, I may update this
package for fixes as needed.

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


signature.asc
Description: Digital signature

Bug#719578: Patch for a cdk-perl-20130717 build failure with Perl 5.18

[Thomas Dickey]

On Thu, Aug 15, 2013 at 10:23:54PM +0300, Niko Tyni wrote:
 Hi Thomas,
 
 recent changes in cdk-perl-20130717 broke the build again with
 newer versions of ExtUtils::ParseXS, including the one
 bundled with Perl 5.18.

thanks (I'd have found this directly, but haven't found a way to get
5.18 other than compiling it myself - it seems that Debian/experimental
skipped a step between 5.14 and 5.18).

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


signature.asc
Description: Digital signature

Bug#708829: dialog broken by ncurses 5.9+20130504-1, with --stdout sends term controls to stdout

[Thomas Dickey]

On Fri, May 24, 2013 at 10:14:02AM +0200, Santiago Vila wrote:
 On Wed, 22 May 2013, Sven Joachim wrote:
  Which does not help, because the dialog version in testing has the same
  problem with the new ncurses.
 
 I was obviously confused, sorry.
 
 Anyway, there is now a new dialog by Thomas which I'll package asap.

sounds good.  If I'd noticed that ncurses was near testing, I'd have
done this fix a week ago...

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


signature.asc
Description: Digital signature

Bug#708829: dialog broken by ncurses 5.9+20130504-1, with --stdout sends term controls to stdout

[Thomas Dickey]

On Wed, May 22, 2013 at 09:26:53PM +0200, Sven Joachim wrote:
 On 2013-05-22 16:40 +0200, Sven Joachim wrote:
 
  On 2013-05-22 12:02 +0200, Thomas Dickey wrote:
 
  Per my previous comment, I would have expected this to mark in some
  way a blocking-bug to prevent ncurses to propagate until this issue
  is resolved.
 
  Indeed, doing that now.  Hopefully it's not too late.
 
 Unfortunately it _was_ too late, ncurses migrated to testing today so
 this problem will affect testing users until dialog is fixed. :-(

The problem is the calls to putp in util.c, which always write to stdout.

Before my changes, putp had (incorrectly for some time) written using ncurses's
own file descriptor passed in from newterm.  I noticed/fixed that while ironing
out the changes related to 20120825 

I'll fix this in dialog by ensuring that it uses the same file descriptor
as that used for newterm.

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


signature.asc
Description: Digital signature

Bug#708829: dialog broken by ncurses 5.9+20130504-1, with --stdout sends term controls to stdout

[Thomas Dickey]

On Wed, May 22, 2013 at 11:16:16AM +0200, Santiago Vila wrote:
 severity 708829 serious
 thanks
 
 I don't know how many users will be affected by this, so just to be
 safe, I'm going to mark this as serious, only to prevent this to
 propagate to testing.

Per my previous comment, I would have expected this to mark in some
way a blocking-bug to prevent ncurses to propagate until this issue
is resolved.

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


signature.asc
Description: Digital signature

Bug#708829: dialog broken by ncurses 5.9+20130504-1, with --stdout sends term controls to stdout

[Thomas Dickey]

On Wed, May 22, 2013 at 09:26:53PM +0200, Sven Joachim wrote:
 On 2013-05-22 16:40 +0200, Sven Joachim wrote:
 
  On 2013-05-22 12:02 +0200, Thomas Dickey wrote:
 
  Per my previous comment, I would have expected this to mark in some
  way a blocking-bug to prevent ncurses to propagate until this issue
  is resolved.
 
  Indeed, doing that now.  Hopefully it's not too late.
 
 Unfortunately it _was_ too late, ncurses migrated to testing today so
 this problem will affect testing users until dialog is fixed. :-(

yes... it hadn't occurred to me that ncurses was ready to go (I've been
juggling a lot of things recently).  I'll put together a fix for this
one tonight/tomorrow.

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


signature.asc
Description: Digital signature

Bug#695653: lynx-cur: on any https URL, I get SSL error:self signed certificate

[Thomas Dickey]

On Tue, Dec 11, 2012 at 04:37:02AM -0500, Thomas Dickey wrote:
 On Tue, Dec 11, 2012 at 09:55:38AM +0100, Vincent Lefevre wrote:
  Package: lynx-cur
  Version: 2.8.8dev.15-1
  Severity: grave
  Justification: renders package unusable
  
  On any https URL[*], I get te following error:
  
SSL error:self signed certificate-Continue? (y) 
  
  As accepting is regarded as a security problem (for most sites),
  one can consider that lynx no longer works with https URL's (or
  can tend to make users do insecure things), which is a major
  problem nowadays.
  
  [*] I've tried with:
* https://gforge.inria.fr/
* https://www.gandi.net/
* https://www.vinc17.net/
* https://ent.ens-lyon.fr/
 
 fwiw, lynx built according to the Debian options (with gnutls) works
 fine on my Debian 6 machine (will investigate this evening to see
 what's different in the current package or environment).

I'm not able to reproduce the problem, either by recompiling, or by installing
this version on my Debian/testing system.  For each configuration, lynx
accepts the certificate and does not prompt.

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


signature.asc
Description: Digital signature

Bug#695653: lynx-cur: on any https URL, I get SSL error:self signed certificate

[Thomas Dickey]

On Wed, Dec 12, 2012 at 05:08:21AM -0500, Thomas Dickey wrote:
 I'm not able to reproduce the problem, either by recompiling, or by installing
 this version on my Debian/testing system.  For each configuration, lynx
 accepts the certificate and does not prompt.

I tested first with LYNX_CFG unset, and then with it set to ''.

I put a script and detailed logs to demonstrate the latter in
ftp://invisible-island.net/temp/db695693-logs.zip


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


signature.asc
Description: Digital signature

Bug#695653: lynx-cur: on any https URL, I get SSL error:self signed certificate

[Thomas Dickey]

On Wed, Dec 12, 2012 at 12:44:23PM +0100, Vincent Lefevre wrote:
 On 2012-12-12 06:28:56 -0500, Thomas Dickey wrote:
  On Wed, Dec 12, 2012 at 05:08:21AM -0500, Thomas Dickey wrote:
   I'm not able to reproduce the problem, either by recompiling, or
   by installing this version on my Debian/testing system. For each
   configuration, lynx accepts the certificate and does not prompt.
  
  I tested first with LYNX_CFG unset, and then with it set to ''.
 
 LYNX_CFG contains a filename. Do not set it to '', but to /dev/null
 for instance.

I can reproduce this, and see that the problem is arguably a
configuration error on your part.  The first interesting difference is
this line omitted from a trace of the malfunctioning session:

HTGetSSLHandle: certfile is set to /etc/ssl/certs/ca-certificates.crt by config 
SSL_CERT_FILE

What is happening is that gnutls is confused about the reason why the
certificate could not be traced to an authority - it only knows that
the attempt failed.  It sets the status which lynx reports here:

if (ret == 0  tls_status  GNUTLS_CERT_SIGNER_NOT_FOUND) {
msg2 = gettext(self signed certificate);

Since there is no configuration information available to lynx,
there is no way for it to check any of the certificates.

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


signature.asc
Description: Digital signature

Bug#695653: lynx-cur: on any https URL, I get SSL error:self signed certificate

[Thomas Dickey]

On Thu, Dec 13, 2012 at 10:12:51AM +0900, Atsuhito Kohda wrote:
 Hi all,
 
 I can't reproduce the problem with neither testing
 (2.8.8dev.12-2) nor unstable (2.8.8dev.15-1).

I can - but even if we modified lynx so that the default path for the cert
file is compiled-in, there's still some ambiguity in the return-codes from
gnutls which could be viewed as the same issue.

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


signature.asc
Description: Digital signature

Bug#695653: lynx-cur: on any https URL, I get SSL error:self signed certificate

[Thomas Dickey]

On Tue, Dec 11, 2012 at 09:55:38AM +0100, Vincent Lefevre wrote:
 Package: lynx-cur
 Version: 2.8.8dev.15-1
 Severity: grave
 Justification: renders package unusable
 
 On any https URL[*], I get te following error:
 
   SSL error:self signed certificate-Continue? (y) 
 
 As accepting is regarded as a security problem (for most sites),
 one can consider that lynx no longer works with https URL's (or
 can tend to make users do insecure things), which is a major
 problem nowadays.
 
 [*] I've tried with:
   * https://gforge.inria.fr/
   * https://www.gandi.net/
   * https://www.vinc17.net/
   * https://ent.ens-lyon.fr/

fwiw, lynx built according to the Debian options (with gnutls) works
fine on my Debian 6 machine (will investigate this evening to see
what's different in the current package or environment).

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


signature.asc
Description: Digital signature

Bug#691642: xterm: outputting the mc5 sequence (prtr_on / turn on printer) makes xterm crash

[Thomas Dickey]

On Sun, Oct 28, 2012 at 12:07:04AM +0200, Vincent Lefevre wrote:
 Package: xterm
 Version: 278-2
 Severity: grave
 Tags: security
 Justification: causes non-serious data loss
...

 I have the following X resource:
 
   *printerCommand: 
 
 The xterm(1) man page says:
 
   printerCommand (class PrinterCommand)
 Specifies  a shell command to which xterm will open a pipe when
 the first MC (Media Copy) command is initiated.  The default is
 an  empty  string, i.e., ??.  If the resource value is given as
 an empty string, the printer is disabled.
 
 So, it doesn't behave correctly with the empty string!

The documentation is correct; there is an error in your report.
The rules for X resource syntax are different from your expectation.
This is an empty string:

*printerCommand:

This is the two double-quote characters (literally):

*printerCommand: 

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


signature.asc
Description: Digital signature

Bug#691642: xterm: outputting the mc5 sequence (prtr_on / turn on printer) makes xterm crash

[Thomas Dickey]

On Sun, Oct 28, 2012 at 01:21:39AM +0200, Vincent Lefevre wrote:
 On 2012-10-27 18:34:11 -0400, Thomas Dickey wrote:
  The documentation is correct; there is an error in your report.
  The rules for X resource syntax are different from your expectation.
  This is an empty string:
  
  *printerCommand:
  
  This is the two double-quote characters (literally):
  
  *printerCommand: 
 
 It is a bit strange because the  is a special character:
 
 $ echo '*printerCommand: ' | xrdb -merge
 stdin:1:18: warning: missing terminating  character [enabled by default]

The warning is coming from xrdb (or the C preprocessor).
It's not coming from xterm or the X libraries.

I would have expected somthing like this:

$ echo '*printerCommand: ' | xrdb -merge

By the way, the resource is actually set in this instance to a blank,
but xterm trims leading/trailing blanks (to reduce user confusion).

The absence of quoting, and limited escapes are something I can't
fix inside xterm.
 
 Now, concerning the bug, with the empty string, there are indeed
 no effects. But I don't think that xterm should terminate when
 there is a problem with the printer command.

true - but the severity level is normal (a problem exposed by
an unusual configuration - not the default as was stated).

I'll investigate to see what the internals are -

-- 
Thomas E. Dickey dic...@invisible-island.net
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 dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#644728: libncurses5-dev: static linking with -lncurses is broken

[Thomas Dickey]

On Sun, 9 Oct 2011, Matthias Klose wrote:


On 10/08/2011 07:56 PM, Thomas Dickey wrote:

...

If zsh used pkg-config, it could use today's update (ncurses patch)

pkg-config --static --libs ncurses

That's one path forward...

But most of your FTBFS's will be only looking for -lncurses, not
supposing that tgetent would be in another library.


I like the idea of fixing pkg-config, and making the few packages to use it.
Do you have an idea how many packages are affected?


not I (remember I'm the upstream, and can only guess)

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



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

Bug#644728: libncurses5-dev: static linking with -lncurses is broken

[Thomas Dickey]

On Sat, 8 Oct 2011, Sven Joachim wrote:


On 2011-10-08 16:14 +0200, Sven Joachim wrote:


Package: libncurses5-dev
Version: 5.9-2
Severity: serious
X-Debbugs-CC: Matthias Klose d...@debian.org

Static linking with -lncurses fails if you need symbols from libtinfo:

,
| $ cat foo.c
| #include term.h
| #include stdlib.h
|
| int main(void)
| {
|   return tgetent(NULL, );
| }
| $ LANG=C gcc foo.c -lncurses -static
| /tmp/ccRe0RW2.o: In function `main':
| foo.c:(.text+0x19): undefined reference to `tgetent'
| collect2: ld returned 1 exit status
`

This makes zsh and possibly a few other packages FTBFS.


So maybe we need to append each libtinfo.a to libncurses{,w}.a, like
this:

ar xo libtinfo.a  ar sr libncurses.a *.o  rm -f *.o

Any less ugly ideas?


If zsh used pkg-config, it could use today's update (ncurses patch)

pkg-config --static --libs ncurses

That's one path forward...

But most of your FTBFS's will be only looking for -lncurses, not
supposing that tgetent would be in another library.

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



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

Bug#607662: ncurses-base: backspace key deletes forwards on the kFreeBSD console

[Thomas Dickey]

On Tue, 21 Dec 2010, Sven Joachim wrote:


On 2010-12-21 04:58 +0100, brian m. carlson wrote:


On Mon, Dec 20, 2010 at 10:06:00PM +0100, Sven Joachim wrote:

The changes to the kFreeBSD console and the kbdcontrol package (see
#605065 and #605777) need to be accompanied by changing the cons25
terminfo entry accordingly, otherwise ncurses-based programs severely
misbehave.


You really can't just unilaterally change the cons25 terminfo entry.  If
this proposed change is implemented, people running stock FreeBSD will
have their consoles broken if they log into a Debian system.


Right, they will have the opposite problem then, the delete key deletes
backwards while backspace works correctly.  Note that a similar problem
already exists for the xterm terminfo entry, see
/usr/share/doc/libncurses5/FAQ.


If kFreeBSD needs different settings than the stock cons25 entry, it
needs to create and use a different TERM type.


I suppose that ncurses-base would ship the terminfo entry for it, and
kfreebsd-image-* packages need to depend on an ncurses-base version that
has this terminfo entry, right?  Any suggestions for the name?


perhaps kons25

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



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

Bug#594300: [Lynx-dev] lynx2.8.8dev.5

[Thomas Dickey]

The current version of lynx is 2.8.7

It's available at
http://lynx.isc.org/
ftp://lynx.isc.org/lynx2.8.7/
2.8.8 Development  patches:
http://lynx.isc.org/current/index.html

2010-08-25 (2.8.8dev.5)
* modify convert_to_idna() to check for malformed urls (Debian #594300 reports
  this as CVE-2010-2810) -TD
* correct typo in po/makefile.inn from removal of mkdirs.sh in dev.4 (Debian
  #592078) -TD
* correct a sign-extension error in UpdateBoundary(), used for MIME boundary
  computation, broken in dev.4 compiler-warning fixes -TD

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


signature.asc
Description: Digital signature
___
Lynx-dev mailing list
lynx-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lynx-dev

Bug#514635: #514635 defoma: Use Font::FreeType instead of Freetype.pm

[Thomas Dickey]

The fix is incomplete, since the package dependencies do not include
libfont-freetype-perl

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


signature.asc
Description: Digital signature

Bug#514635: #514635 defoma: Use Font::FreeType instead of Freetype.pm

[Thomas Dickey]

On Wed, 16 Sep 2009, Don Armstrong wrote:


On Wed, 16 Sep 2009, Thomas Dickey wrote:

The fix is incomplete, since the package dependencies do not include
libfont-freetype-perl


The package Recommends: libfont-freetype-perl, which is sufficient.


dselect didn't note this when I added it.
The package doesn't run without it.

awai.

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



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

Bug#514635: #514635 defoma: Use Font::FreeType instead of Freetype.pm

[Thomas Dickey]

On Wed, 16 Sep 2009, Don Armstrong wrote:

I'll keep your opinion in mind.

It's equivalent to stating that you'll recommend tic in ncurses
and not provide user configurability.

awai

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



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

Bug#536689: mawk: incorrect license in copyright file

[Thomas Dickey]

Package: mawk
Version: 1.3.3-14
Severity: serious
Justification: mawk's sources do not agree with Debian's add-on copyright.

Justification:  mawk's sources have several comments stating explicitly that it
is distributable in GPLv2, e.g.,

Mawk is distributed without warranty under the terms of 
the GNU General Public License, version 2, 1991. 

The Debian changelog has no indication that Mike Brennan changed the license.
Debian's copyright notice has added

/usr/share/doc/mawk/copyright

which says

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

(The Debian changelog does not indicate at what point the license terms
were changed).

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_US)
Shell: /bin/sh linked to /bin/bash

Versions of packages mawk depends on:
ii  libc6 2.9-4  GNU C Library: Shared libraries

mawk recommends no packages.

mawk suggests no packages.

-- no debconf information



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

Bug#536177: /lib/libncurses.so.5.7: Segfaults in apps linking against libncurses

[Thomas Dickey]

On Wed, 8 Jul 2009, Michael Biebl wrote:


Package: libncurses5
Version: 5.7+20090606-1
Severity: serious
File: /lib/libncurses.so.5.7
Justification: breaks other packages

Since the latest update of libncurses, I get a lot of segfaults of
programs linking against libncurses. As I haven't seen this behaviour
before the libncurses update, my guess is that it's a ncurses bug.
My dmesg shows e.g.


yes - I caught that the next day -

20090607
+ fix a regression in lib_tputs.c, from ongoing merges.

(past that point, I've not seen any breakage, though the change to 
wadd_wch this weekend is large...)




[19701.044380] top[15170]: segfault at 4cc ip b7ed9c59 sp bfbdf150 error
4 in libncurses.so.5.7[b7eb2000+3]
[17067.320886] tput[10186]: segfault at 4cc ip b809cc59 sp bfa03190
error 4 in libncurses.so.5.7[b8075000+3]

Cheers,
Michael


-- System Information:
Debian Release: squeeze/sid
 APT prefers unstable
 APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libncurses5 depends on:
ii  libc6 2.9-19 GNU C Library: Shared libraries

Versions of packages libncurses5 recommends:
ii  libgpm2   1.20.4-3.2 General Purpose Mouse - shared lib

libncurses5 suggests no packages.

-- no debconf information






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



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

Bug#510030: #510030 [CVE-2008-2383] xterm: DECRQSS and comments

[Thomas Dickey]

I plan to fix this for etch by disabling UDKs, font shifting, X
property changes, and applying Paul's patch.  Any objections?

well, yes - Szabo's patch works, but is incorrect.

For the rest - Matthieu Herrb forwarded Weimer's proposed patch,
which also needs work.

(coincidentally, I'd intended working on xterm today or tomorrow -
looks like I have extra to-do items)

bye.

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


signature.asc
Description: Digital signature

Bug#506717: ncurses: diff for NMU version 5.6+20080830-1.1

[Thomas Dickey]

On Sun, 30 Nov 2008, Thomas Viehmann wrote:


tags 506717 + patch pending
severity 506717 serious
thanks

Hi everyone,

actually, ncurses-using applications (e.g. aptitude) will crash without
this patch. As such this should be fixed in testing.
Attached is a proposed t-p-u upload.

...

diff -u ncurses-5.6+20080830/debian/patches/00list 
ncurses-5.6+20080830/debian/patches/00list

...

+--- a/ncurses/base/lib_mouse.c 2008-11-24 00:29:19.0 +0100
 b/ncurses/base/lib_mouse.c 2008-11-24 00:31:12.0 +0100
+@@ -651,7 +651,15 @@
+   /* query server for event, return TRUE if we find one */
+   Gpm_Event ev;
+
+-  if (my_Gpm_GetEvent(ev) == 1) {
++  if (sp-_mouse_fd == -1)


rather than a break _here_, making it like _this_ seems better:

if (sp-_mouse_fd = 0) {

... and leaving the break after the chunk that's protected.


++  break;
++
++  switch (my_Gpm_GetEvent(ev)) {


but this can return -1, 0 or 1.

(even if we don't want to close the connection, we probably want to
ignore the resulting data on a -1).


++  case 0:
++  /* Connection closed, drop the mouse. */
++  sp-_mouse_fd = -1;
++  break;
++  case 1:
+   /* there's only one mouse... */
+   eventp-id = NORMAL_EVENT;
+
+@@ -684,6 +692,7 @@
+   /* bump the next-free pointer into the circular list */
+   sp-_mouse_eventp = eventp = NEXT(eventp);
+   result = TRUE;
++  break;
+   }
+   }
+   break;


with that, the diff would look something like

--- lib_mouse.c.orig2008-11-22 19:11:46.0 -0500
+++ lib_mouse.c 2008-11-29 20:37:27.0 -0500
@@ -694,11 +694,16 @@

 #if USE_GPM_SUPPORT
 case M_GPM:
-   {
+   if (sp-_mouse_fd = 0) {
/* query server for event, return TRUE if we find one */
Gpm_Event ev;

-   if (my_Gpm_GetEvent(ev) == 1) {
+   switch (my_Gpm_GetEvent(ev)) {
+   case 0:
+   /* Connection closed, drop the mouse. */
+   sp-_mouse_fd = -1;
+   break;
+   case 1:
/* there's only one mouse... */
eventp-id = NORMAL_EVENT;

@@ -731,6 +736,7 @@
/* bump the next-free pointer into the circular list */
sp-_mouse_eventp = eventp = NEXT(eventp);
result = TRUE;
+   break;
}
}
break;


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



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#470882: /dev/gpmctl freezes acknowledge

[Thomas Dickey]

On Sun, Oct 12, 2008 at 12:19:49PM +0200, Kurt Roeckx wrote:
 On Thu, Oct 09, 2008 at 01:14:28AM +0200, Samuel Thibault wrote:
  
  Now, that being said, that reminds me bug #472063: actually libgpm
  shouldn't even have tried to connect to the server, it should have just
  noticed it is running in an X terminal and set gpm_fd to -2...
 
 Both people reporting this bug seem to be using rxvt-unicode, and 
 #472063 is also about that.  #472063 is also still open.
 
 So I've tried a few different things.  Using aptitude:
 - virtual console shows mouse, but doesn't work as expected.  Clicking
   somewhere doesn't always seem to have an effect.  Click and drag seems
   to have a weird effects.

ncurses is only using a click-style interface for GPM (no dragging).
As I recall it, GPM also has some built-in behavior for select/paste
which ncurses doesn't try to work around.

 - xterm: the mouse icon stays the same as a normal xterm, one used for
   selecting text.  Clicking someone does seem to have the desired
   effect.  However, it seems that the place where the cursor is shown
   in other cases it just shows an empty space instead of the '-'.

I'm not sure why ncurses would behave different from gnome/konsole here.
The description isn't clear (to me) though...

(coincidentally, I was just testing gnome-terminal with vttest, seeing
some mouse-related bugs there ;-)

 - rxvt-unicode: The mouse icon is also the text selecting one, and it's
   all that it seems to be doing.  The cursor is not shown.

that may depend on the terminfo (Debian maintains that one).

 - gnome-terminal: the mouse icon is a normal pointer.  It also works
   as expected.  When aptitude wasn't started it was the text selection
   icon.
 - konsole: behaves the same as gnome-terminal.
 
 For w3m:
 - virtual console: no mouse shown, also doesn't seem to have
   any effect at all.
 - xterm: same as aptitude, but text under cursor still shown.
 - rxvt-unicode: same as aptitude, but the cursor is shown now.
 - gnome-terminal: same as aptitude.
 - konsole: same as aptitude.
 
 For pdmenu:
 - virtual console: no mouse shown, but moving it changes the current
   line of the menu.  It's shown in white on black, no colors.
 - xterm, rxvt-unicode, gnome-terminal, konsole: Just selection
   of text.  They all show it in color, rxvt-unicode with a grey
   background, the rest with a blue background.
 
 
 So it seems to me that the problem might be in the terminal emulator.
 
 I was not able to reproduce any hanging or segfaults or something
 simular.
 
 
 Packages used:
 aptitude   0.4.11.8-1
 gpm1.20.4-2
 libncurses55.6+20080830-1
 w3m0.5.2-2+b1
 rxvt-unicode   9.05-1
 gnome-terminal 2.22.3-3
 xterm  235-1
 konsole  4:3.5.9.dfsg.1-5

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


pgpVvTzvIT84N.pgp
Description: PGP signature

Bug#470882: /dev/gpmctl freezes acknowledge

[Thomas Dickey]

On Fri, Oct 10, 2008 at 01:10:35PM +0200, Gerfried Fuchs wrote:
 * Samuel Thibault [EMAIL PROTECTED] [2008-10-09 23:59:43 CEST]:
  Thomas Dickey, le Wed 08 Oct 2008 20:00:32 -0400, a écrit :
   With the latest update, ncurses won't try to use gpm if $TERM doesn't
   contain linux, unless it's overridden (with a new environment variable).
  
  Ah, indeed.  Rhonda, Zito or Simon, could you check whether upgrading
  your libncurses5 and libncursesw5 to 5.6+20081004-1 fixes the bug?  I
  think that should fix it for the usual cases.
 
  These packages are currently installed:
 
 w3m 0.5.2-2+b1, Versions of packages w3m depends on:

I already commented on w3m.  It's using names from ncurses without actually
using the ncurses library, to fool gpm into working by calling w3m's code.

See

  http://invisible-island.net/ncurses/ncurses.faq.html#using_gpm_lib

 ii  libc6  2.7-13GNU C Library: Shared libraries
 ii  libgc1c2   1:6.8-1.1 conservative garbage collector 
 for
 ii  libgpm21.20.4-2  General Purpose Mouse - shared 
 lib
 ii  libncurses55.6+20081004-1shared libraries for terminal 
 hand
 ii  libssl0.9.80.9.8g-13 SSL shared libraries
 ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
 
  Doesn't solve the issue, unfortunately. I've upgraded all my ncurses
 packages, after that started gpm and did run and quit
 'w3m http://nm.debian.org/' exactly seven times (reproducible), likewise
 with pdmenu:

...Of the programs mentioned, ncurses updates should only affect aptitude.
pdmenu does not appear to rely on ncurses (see my first reply).

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


pgpxORA8HfRKv.pgp
Description: PGP signature

Bug#470882: /dev/gpmctl freezes acknowledge

[Thomas Dickey]

On Thu, Oct 09, 2008 at 01:14:28AM +0200, Samuel Thibault wrote:
 Just to summarize a few things:

recap - there's more than one client scenario:

a) w3m, the last I looked, was abusing ncurses interface to
   access gpm in its own way.  I'll keep in mind to not break
   it, but its usage is completely unsupported.

b) I'm not as familiar with pdmenu source - but reading, seems to
   talk directly to gpm using its documented interface, and to
   be using slang.

c) aptitude is using ncurses via cwidgets (this might be mine ;-)
 
 - apparently it happens just for clients run in an terminal in X.
 - the server logs previously attached to the bug show
 Failed gpm connect attempt by uid 1000 for vc /dev/tty0
 which means that libgpm tried to connect to the gpm server, and failed
 since it didn't know which VT to acquire, thus tried tty0, and failed
 since it probably belongs to root, not to uid 1000.
 
 I tried to reproduce that, and I noticed something in the strace I could
 get: 
 
 # the client logs the connection error
 sendto(52, 14Oct  9 00:55:37 aptitude: *** info, 39, MSG_NOSIGNAL, NULL, 
 0) = 39
 sendto(52, 14Oct  9 00:55:37 aptitude: Warning: closing connection, 57, 
 MSG_NOSIGNAL, NULL, 0) = 57
 # closes the socket
 close(4)
 ...
 # and still tries to select it!
 select(5, [0 4], NULL, NULL, {0, 166000}) = -1 EBADF (Bad file descriptor)
 
 it looks like the caller of libgpm didn't notice that gpm_fd is not
 a valid file descriptor any more.  In the case of aptitude, that's
 ncurses...  Thomas?
 
 Now, that being said, that reminds me bug #472063: actually libgpm
 shouldn't even have tried to connect to the server, it should have just
 noticed it is running in an X terminal and set gpm_fd to -2...

With the latest update, ncurses won't try to use gpm if $TERM doesn't
contain linux, unless it's overridden (with a new environment variable).

Before the immediate changes of the past month - ncurses would try to
use gpm - and I agree that it should have failed since I'd expect gpm_fd
to be returned as a negative value.  That check is made in one place in
lib_mouse.c:

result = (my_Gpm_Open(SP-_mouse_gpm_connect, 0) = 0);

I noticed that for some reason it was _not_ failing, when the gpm server was
running, but did not dig into the gpm package (just examined the source code
w/o seeing the problem).  As I recall it, ncurses did both checks because
some previous users insisted that gpm works in xterm.

But that issue prompted me to add the additional restriction, to move
away from gpm a little further.

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


pgpPm4zsrdV6O.pgp
Description: PGP signature

Bug#501421: Specify the -l flags to $(MAKE) directly

[Thomas Dickey]

On Tue, Oct 07, 2008 at 08:30:07PM +0200, Neil Williams wrote:
 Removing the -ltic from the LDFLAGS variable exported prior
 to ./configure and instead passing it directly to $(MAKE) allows
 libtool to link tack correctly.

hmm -- last I knew, Debian isn't using the libtool configuration for
ncurses or tack.
 
 I've just built tack by removing -ltic from the variable exported
 to ./configure, using this line in debian/rules:
 
 $(MAKE) LDFLAGS=-ltic -lncurses
 
 The problem is the need to add ncurses which is plain ugly. I suspect
 an upstream bug. Maybe stop copying config.guess and config.sub and

I usually start by assuming the answer's in the changelog.
Sounds like

20080823
+ modify configure script for the case where tic library is used (and
  possibly renamed) to remove its dependency upon ncurses/ncursew
  library (patch by Dr Werner Fink).

 actually use 'autoreconf -ifs' to sort out the autoconf problems from
 upstream, although that looks like it will need a patch for
 configure.in. I suspect upstream are not testing the release with 'make
 distcheck'.

that ought to be an faq (but the comments in configure.in should be
sufficient).

bye.

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


pgpw0CjzwGYuo.pgp
Description: PGP signature

Bug#491182: byacc: diff for NMU version 20070509-1.1

[Thomas Dickey]

On Sun, Aug 24, 2008 at 11:50:06PM +0200, Thomas Viehmann wrote:
 tags 491182 + patch pending
 thanks

fwiw, see

http://invisible-island.net/byacc/CHANGES

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


pgprBNpfCVPkD.pgp
Description: PGP signature

Bug#491182: byacc: CVE-2008-3196: out of bound access

[Thomas Dickey]

On Thu, Jul 17, 2008 at 03:00:23PM +0200, Steffen Joeris wrote:
 Package: byacc
 Severity: grave
 Tags: security, patch
 Justification: user security hole
 
 Hi
 
 Quoting an email[0] from Jan Lieskovsky about CVE-2008-3196.
 
 Description of problem:
 ===
 
 Otto Moerbeck has reported the following potential out of bounds of the
 allocated stack access in the yacc binary:

I saw the comment on another mailing list (it would have been nice if
he'd given a test case that exercised more than the 2-line slice affected,
since changing this has the potential for breaking other things...).

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


pgp4kiwXFA86x.pgp
Description: PGP signature

Bug#488219: lynx: claims to support lynx-ssl but doesn't support HTTPS URLs

[Thomas Dickey]

On Fri, Jun 27, 2008 at 09:40:13AM +0200, Mario 'BitKoenig' Holbe wrote:
 Package: lynx
 Version: 2.8.6-2.1
 Severity: serious
 
 Hello,
 
 with 2.8.6-2.1 lynx stopped linking against a SSL library and thus lynx
 complains when it is requested to open a https:// URL:
   Alert!: This client does not contain support for HTTPS URLs.
 
 However, the package still claims to replace and provide lynx-ssl, which
 is obviously not true anymore.

afaik the lynx-cur package is linking to gnutls, and that there was
some discussion about making lynx-cur replace lynx.

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


pgpEa1Y7olt6M.pgp
Description: PGP signature

Bug#473050: tkdiff: Error in startup script

[Thomas Dickey]

On Fri, Mar 28, 2008 at 12:30:09AM +0100, Andy Spiegl wrote:
 Package: tkdiff
 Version: 1:4.1.3-1
 Severity: grave
 Justification: renders package unusable
 
 tkdiff doesn't start anymore.  It just throws this error:

It appears that someone changed the font-syntax.
I got it working by this chunk
(there's also some change in PrefsFileVersion, which may be relevant):

 # Text widget options
 -define textopt {-background white -foreground gray  -font 6x13 -wrap none}
 +define textopt {-background white -foreground gray  -font {Courier -12 bold} 
-wrap none}

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


pgpTcqcBJAhOx.pgp
Description: PGP signature

Bug#473050: tkdiff: Error in startup script

[Thomas Dickey]

On Sat, Mar 29, 2008 at 10:18:37PM +0100, Andy Spiegl wrote:
   # Text widget options
   -define textopt {-background white -foreground gray  -font 6x13 -wrap none}
   +define textopt {-background white -foreground gray  -font {Courier -12 
  bold} -wrap none}
 
 Thanks, but uhm, it doesn't help here.  After patching .tkdiffrc
 I still get:

sorry - that's as deep as I had to go to fix it for me.
I encountered this a couple of weeks ago...

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


pgp10ZgYFJn38.pgp
Description: PGP signature

Bug#446267: Missing libtic.so.5

[Thomas Dickey]

On Fri, 12 Oct 2007, Dennis Boone wrote:


This morning's update fixed this issue for me, but just in case it helps
the next guy identify his problem...

In addition to all of the binaries which couldn't run due to the missing
library (tic, tset, clear, etc.), the less binary was throwing
segfaults.


It shouldn't - less is basically a termcap application.  So it would 
resolve against the other library/libraries (libtinfo could be separate).


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



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#433357: ncurses-bin: breaks the whole system when usplash is installed

[Thomas Dickey]

On Mon, 16 Jul 2007, Florent Bayle wrote:


Package: ncurses-bin
Version: 5.6+20070714-1
Severity: critical
Justification: breaks the whole system

Hi,

Since I've upgraded ncurses-bin (and other ncurses packages) to the lastest
version, my whole system is broken.
Lots of init scripts are failing :
# invoke-rc.d networking restart
* Reconfiguring network interfaces...   /usr/bin/tput: invalid option -- 2
usage: tput [-V] [-S] [-T term] capname


tput's command-line parsing hasn't changed since before 5.6 (December).
(what was the previous version you had installed?).

Did usplash change recently?


invoke-rc.d: initscript networking, action restart failed.
#

It seems that this bug is related to :
- ncurses-bin: tput now fails at boot time since the last upgrade
- lsb-base: calls tput
- usplash: activate fancy boot messages in lsb-base.
Please note that if I remove usplash or if I downgrade ncurses, my system
works as usual.

--
Florent





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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#433357: some clues perhaps

[Thomas Dickey]

On Mon, 16 Jul 2007, Christian Ohm wrote:



I've also encountered this problem (not even having usplash installed
anymore, just a leftover /etc/lsb-base-logging.sh - that's what you get
for not purging packages...). In lsb-base-logging.sh, there are some
tests for terminal width via tput cols. For some reason, the result of
that is -1, from which stuff gets substracted. This is then given to
tput hpa (like tput hpa -9) as an argument, which in result
complains about an invalid option.


That could be a -1 for a couple of reasons - I'll check to see if I 
introduced an initialization bug in the restructuring changes to the

ncurses library (the most likely problem that comes to mind).


I got rid of the problem purging usplash, but it's quite annoying. I
don't really know where the problem is (perhaps the terminfo data got
some faulty update), but one problem is definitely that usplash doesn't
handle the unexpected tput cols output well.

Hope that helps,


it sounds useful (thanks)

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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#433357: some clues perhaps

[Thomas Dickey]

On Mon, Jul 16, 2007 at 06:39:49PM +0200, Christian Ohm wrote:
 
 I've also encountered this problem (not even having usplash installed
 anymore, just a leftover /etc/lsb-base-logging.sh - that's what you get
 for not purging packages...). In lsb-base-logging.sh, there are some
 tests for terminal width via tput cols. For some reason, the result of
 that is -1, from which stuff gets substracted. This is then given to
 tput hpa (like tput hpa -9) as an argument, which in result
 complains about an invalid option.

See

ftp://invisible-island.net/ncurses/5.6/ncurses-5.6-20070716.patch.gz

In restructuring things to make it simpler to support reentrant code,
I got to one of those cases where it was awkward and did not appear
needed.  Since it is needed, I repaired it...

-- 
Thomas E. Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#431165: cpio: Wrong GPL verson in debian/copyright

[Thomas Dickey]

On Sat, Jun 30, 2007 at 01:00:10PM +0200, Sven Joachim wrote:
 Package: cpio
 Version: 2.9-1
 Severity: serious
 
 Hi,
 
 the new cpio version is released under GPL 3, but debian/copyright
 still says it's under GPL 2.  You need to update the file and include
 the complete GPL 3 text, as long as base-files does not contain it.

actually not: it's only a requirement if the packagers choose (as is
likely but not certain) to upgrade to the new version.  At that point,
the packagers would as a matter of course(*) change the documentation
to reflect the new source.

(*) one would assume, though I've noted incorrect licenses on this
mailing list in the past which were ignored by the package maintainer.

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


pgpaunTOgitiT.pgp
Description: PGP signature

Bug#431165: cpio: Wrong GPL verson in debian/copyright

[Thomas Dickey]

On Sat, Jun 30, 2007 at 02:11:57PM +0200, Sven Joachim wrote:
 Thomas Dickey writes:
   the new cpio version is released under GPL 3, but debian/copyright
   still says it's under GPL 2.  You need to update the file and include
   the complete GPL 3 text, as long as base-files does not contain it.
  
  actually not: it's only a requirement if the packagers choose (as is
  likely but not certain) to upgrade to the new version.
 
 Sorry, I do not understand this: Whom do you refer to as packagers?
 If you mean the upstream authors, they _have_ just switched to GPL 3;
 if you refer to the Debian maintainer, he has to follow that, of course.

no, he does not.  He has a valid license for the 2.9 source.
No upstream change can take that away.

(there's nothing new about this situation)

   At that point,
  the packagers would as a matter of course(*) change the documentation
  to reflect the new source.
 
 Well, that's just what I wanted to say.
 
  (*) one would assume, though I've noted incorrect licenses on this
  mailing list in the past which were ignored by the package maintainer.
 
 Which mailing list?

bugs.debian.org

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


pgpMhuY7UORAV.pgp
Description: PGP signature

Bug#423732: dialog --tailbox not functional (fwd)

[Thomas Dickey]

On Thu, 24 May 2007, Andrey J. Melnikoff (TEMHOTA) wrote:


Hi Thomas Dickey!
On Wed, May 23, 2007 at 06:53:38AM -0400, Thomas Dickey wrote next:


Hello.

Received this from the Debian BTS. I've increased the severity to
serious
to avoid this package to enter testing, as it's a regression.


I'll investigate this evening (thanks)

Still no go - file re-readed ONLY after I press Left/Right key.
Up/Down keys - only refresh screen and nothing.

up/down keys don't do anything, haven't done anything in tailbox in any
previous version.


In this version - file content re-readed and displayed only if I press
Left/Right key. If I don't touch keyboard - dialog stay in loop
into dlg_getc(). File content not checked and not displayed.


I see (sounds as if this is broken by the change I made to not pass
ERR results from dlg_getc).  I'll look/see for a better fix.

thanks

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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#423732: dialog --tailbox not functional (fwd)

[Thomas Dickey]

On Wed, 23 May 2007, Andrey J. Melnikoff (TEMHOTA) wrote:


Hi Thomas Dickey!
On Mon, May 14, 2007 at 06:19:45AM -0400, Thomas Dickey wrote next:


On Mon, 14 May 2007, Santiago Vila wrote:


Hello.

Received this from the Debian BTS. I've increased the severity to serious
to avoid this package to enter testing, as it's a regression.


I'll investigate this evening (thanks)

Still no go - file re-readed ONLY after I press Left/Right key.
Up/Down keys - only refresh screen and nothing.


up/down keys don't do anything, haven't done anything in tailbox in any
previous version.

That's a wishlist item which you should report separately.

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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396964: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Sat, Dec 02, 2006 at 04:51:45PM +0100, Florian Weimer wrote:
 * Thomas Dickey:
 
  It's a #define.  But the change to use the home directory is in the
  wrong place.  I'd point out that it doesn't solve the problem, and
  that the program is still subject to the same issue as reported, [...]
 
 This is not correct.  Gracious write operations to the home directory

Then address my comment in the context of the original report.
OP claimed among other things that this is a problem with files
downloaded by lynx.

(this thread is dead as far as I'm concerned, since it's presenting
no new information, just harrassment).

 are considered a security problem, but file creation in other
 directories does not share this problem.  Unless software
 automatically interprets certain files in the current directory, which
 is a very bad thing to do for that reason.
 
 It seems to me that the patch should be changed to prepend the home
 directory if the configured path is not absolute (that is, does not
 start with a slash).

Did you read the patch which I made _before_ this all started, or are
you simply replying to the general discussion?

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


pgpdKyk7bEs79.pgp
Description: PGP signature

Bug#396964: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Thu, Nov 30, 2006 at 01:46:31PM +0100, Guus Sliepen wrote:
 I didn't know PERSONAL_MAILCAP was run-time configurable (it looks
 a #define to me). If apt-get source wasn't segfaulting at the moment I'd

It's a #define.  But the change to use the home directory is in the
wrong place.  I'd point out that it doesn't solve the problem, and
that the program is still subject to the same issue as reported, but
that would be redundant.

 check it. But this explaination is a lot more useful than upstream
 won't accept it. But why did you send this to the debian-devel mailing
 list instead of as a follow-up to the bugreport?

I've noticed that my comments to followup on the lynx bug reports are
ignored by the package maintainer as well as the security team.

It's nice to get replies.  (And normally expected that one or both of
those would solicit comments from upstream).

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


pgpg0inIGCKLM.pgp
Description: PGP signature

Bug#396964: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Thu, Nov 30, 2006 at 02:15:42PM +0100, Andreas Barth wrote:
 * Thomas Dickey ([EMAIL PROTECTED]) [061130 14:12]:
  On Thu, Nov 30, 2006 at 01:46:31PM +0100, Guus Sliepen wrote:
   I didn't know PERSONAL_MAILCAP was run-time configurable (it looks
   a #define to me). If apt-get source wasn't segfaulting at the moment I'd
  
  It's a #define.  But the change to use the home directory is in the
  wrong place.  I'd point out that it doesn't solve the problem, and
  that the program is still subject to the same issue as reported, but
  that would be redundant.
 
 So, what do you think would be the appropriate behaviour? I don't mind
 changing the behaviour to something which sounds sensible for you too,
 but - taking the files from the cwd opens up a can of issues.

yes - I agreed with that, but also pointed out that there wasn't a check
to ensure that the file is not world-writable, etc.  That's something
that the various shell programs do for example - iirc csh won't use
.cshrc if you don't own it (for at least some systems ;-).

It would be nice to ensure that the global mailcap/mime.types files also
are secure, but that's harder to do (portably) since you can't assume
much about the ownership of the file.  But I did at least ensure that
those are absolute pathnames.

  I've noticed that my comments to followup on the lynx bug reports are
  ignored by the package maintainer as well as the security team.
 
 I'm sorry, but I didn't see any comments from you on this bug report -
 though perhaps I didn't look deep enough.

It was moved from another number, where I pointed out that most of the
given examples were still true for the user's home directory.  However,
my remark about ignored comments applies to last couple of years.

Anyway, compare with the patch I made a couple of weeks ago.

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


pgpdqmEqi59dK.pgp
Description: PGP signature

Bug#396949: fixed in lynx-cur 2.8.7dev2-1

[Thomas Dickey]

On Tue, Nov 14, 2006 at 01:20:13AM +0100, Steinar H. Gunderson wrote:
 On Mon, Nov 06, 2006 at 10:02:13PM -0800, Atsuhito KOHDA wrote:
 * New Upstream Release.
  - modify logic for reading PERSONAL_EXTENSION_MAP and PERSONAL_MAILCAP 
  to
ensure that they are files that are controlled only by the user.  The
default values for these allow lynx to read configuration information
from the user's current directory at lynx's startup (Closes: #396949)
 
 Unfortunately, the patch is flawed; the logic is basically:
 
   1. Stat the file.
   2. If not owned by the user, abort.
   3. Read the file.

It's somewhat more than that.  The point of adding the check was to ensure
that files in the user's home directory (the ultimate goal, for dev.3/dev.4)
are not world-writable.
 
 There's nothing that says the status can't change between 1 and 3, so we have
 a race condition; IOW, the bug is still there, only slightly harder to
 exploit.

dev.4 is current (from yesterday).  Let's focus on the current code, not
the first step that I took.
 
 Actually, the upstream CHANGES file also claims this release checks
 that the paths for PERSONAL_EXTENSION_MAP and PERSONAL_MAILCAP are absolute,
 but this appears to be a typo; from the diff it is clear that what's checked
 are the _global_ type and extension maps.

yes - that's a cut/paste error that I fixed in the dev.3 patch.

bye

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


pgpiey4Yqw4Un.pgp
Description: PGP signature

Bug#396949: #396949 (lynx)

[Thomas Dickey]

On Tue, 7 Nov 2006, Piotr Engelking wrote:


reopen 396949
thanks

Version 2.8.7dev2 attempts to fix the bug by checking if the user owns
the .mime.types and .mailcap files before opening them. The assumption
that user trusts the files he owns, is, however, flawed. Consider, for
an example:

* files downloaded by the user
* files unpacked by the user from an archive
* files on a filesystem mounted by the user


...none of which would be executed by the user unknowingly (and could 
equally be confused with his home directory), and furthermore, the comment 
does not address my point that the files are read once at startup


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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396949: #396949 (lynx)

[Thomas Dickey]

The secondary issue of files which the user trusts, but may not want to be 
executed can be addressed by changing the customized lynx.cfg to use 
~/.mailcap and ~/.mime.types, etc., to ensure that the default 
configuration uses files from the user's home directory.


The response that I just read will still not be addressed, since it's 
still possible to make a case where the user downloads into his home 
directory.  But the given examples were absurd, so perhaps we can 
disregard them.


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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396949: #396949 (lynx)

[Thomas Dickey]

This allows an attacker to cause lynx to execute arbitrary shell code when a
user runs lynx while visiting a directory with attacker-provided contents.

That's inaccurate:  the mime files are read at startup, not while visiting a
directory.  Reading it from the user's starting directory is as pointed out,
not good, but not in the same realm as indicated in the report.

-- 
Thomas E. Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#384593: xterm: allowWindowOps should be disabled by default

[Thomas Dickey]

On Tue, Sep 05, 2006 at 12:00:14PM +0200, Samuel Thibault wrote:
 tags 384593 + fixed-upstream
 thanks
 
 This got fixed upstream in version 218.

The #218 fix wasn't for the app-defaults setting, but to fix the bug that
you reported with regard to non-printing characters.

While testing this, I did notice that not all of the terminal emulators
in Debian had eliminated the title-response string which is addressed by
the allowWindowOps resource.  I'm reluctant to change the default resource
value since (without a solid policy enforced for _all_ terminal emulators),
it only would add to the bug reports that I have to deal with.

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


pgpNU0bUMar3k.pgp
Description: PGP signature