Bug#1071581: dialog: stop using libtool-bin

[Thomas Dickey]

On Wed, May 22, 2024 at 10:34:12AM +0200, Helmut Grohne wrote:
> Hi Thomas,
> 
> On Wed, May 22, 2024 at 03:53:43AM -0400, Thomas Dickey wrote:
> > I don't use autoheader (though it's present in the fork I've maintained for
> > about the past quarter-century).  The configure script generates the 
> > complete
> > dlg_config.h without that crutch.  Attempting to bypass that will certainly
> > lead to unnecessary bug reports.
> 
> I fear it occurred to me late that I should be using autoconf-dickey
> instead of the standard autoconf for dialog. Hence my patch makes it
> work the "wrong" autoconf and thus runs autoheader. I see how that would
> not be necessary with autoconf-dickey.
> 
> > Actually it would be AC_FOREACH, which invokes AH_TEMPLATE
> > 
> > fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999),
> > and there are other macros which might use those features.
> 
> Yeah. And if you make dialog work with autoconf-dickey and without
> autoheader, then all of this becomes moot anyway.
> 
> Feel free to come up with a different solution as long as we stop
> relying on /usr/bin/libtool as that's the component that will go away.
> We now have one working solution and I'm happy if that is sufficient to
> get the ball rolling for a better solution than mine.

thanks (on my to-do list)

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


signature.asc
Description: PGP signature

Bug#1071581: dialog: stop using libtool-bin

[Thomas Dickey]

On Wed, May 22, 2024 at 08:12:04AM +0200, Helmut Grohne wrote:
> Hi Thomas,
> 
> On Tue, May 21, 2024 at 03:06:00PM -0400, Thomas Dickey wrote:
> > hmm - there are two sets of changes - I don't see a reason for the
> > change to the curses function checks.
> 
> Thank you for reviewing my patch. The curses function check change does
> have a reason. It can be solved differently in principle.
> 
> When I ran autoheader, config.hin would lack all the defines that should

I don't use autoheader (though it's present in the fork I've maintained for
about the past quarter-century).  The configure script generates the complete
dlg_config.h without that crutch.  Attempting to bypass that will certainly
lead to unnecessary bug reports.

> have come from CF_CURSES_FUNCS while the relevant HAVE_* defines would
> still show up in config.log after running configure and therefore the
> resulting dlg_config.h would also lack them. That meant that dialog
> would perceive a very dysfunctional curses and its shim would fail to
> compile. Quite clearly, we shouldn't assume a crippled curses and
> config.hin should contain the relevant templates. As it turns out,
> autoheader interprets the m4 files and collects the AC_DEFINE and
> AC_DEFINE_UNQUOTED invocations, well some of them actually. The
> AC_CHECK_FUNCS would be collected whereas CF_CURSES_FUNCS not, even
> though both seemed quite similar. The subtle difference is that
> AC_CHECK_FUNCS uses AS_FOR (a loop that is evaluated using m4) whereas

Actually it would be AC_FOREACH, which invokes AH_TEMPLATE

fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999),
and there are other macros which might use those features.

(I added a to-do to follow up on this)

> CF_CURSES_FUNCS uses a shell for loop. Thus, autoheader would only see a
> single, bogus AC_DEFINE_UNQUOTED for all of CF_CURSES_FUNCS and ignore
> that. Avoiding this shell loop is key here and I went for manually
> unrolling it, because AS_FOR didn't work out initially and unrolling
> seemed workable to me. The crucial bit here is that you cannot use shell
> for control flow here. If you prefer AS_FOR or some other working
> mechanism, that's fine. Just do something about it to avoid dialog
> failing to build when we remove libtool-bin from Debian.
> 
> Helmut
> 

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


signature.asc
Description: PGP signature

Bug#1071581: dialog: stop using libtool-bin

[Thomas Dickey]

On Tue, May 21, 2024 at 04:00:56PM +0200, Helmut Grohne wrote:
> Source: dialog
> Version: 1.3-20240307-2
> Severity: normal
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability
> 
> Hi Santiago,
> 
> we want to remove the package libtool-bin from the archive, because any
> attempt of using it breaks cross compilation. The dialog package is a
> bit strange in this regard. It's autoconf stuff attempts to detect
> whether there is a libtool.m4 and when there isn't attempts to use a
> pre-configured libtool (the one from libtool-bin). Unfortunately, last
> time it was autoreconf'ed, that happened without libtool.m4. So
> basically, making libtool-bin go away here amounts to autoreconfing
> dialog after libtoolizing it. And that's pretty much what I did in the
> attached patch. The dialog binary and libdialog.la are bit-identical
> with this change.

hmm - there are two sets of changes - I don't see a reason for the
change to the curses function checks.

(as for libtool - I recall commenting on that, recently)

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


signature.asc
Description: PGP signature

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Thomas Dickey]

On Sat, Mar 30, 2024 at 08:02:18PM +0100, Sven Joachim wrote:
> On 2024-03-30 12:38 +0100, Santiago Vila wrote:
> 
> > El 30/3/24 a las 9:43, Sven Joachim escribió:
> >> I think it would make sense for Debian to follow what Arch and Fedora
> >> are doing, introduce a libdialog15 package with the shared library and a
> >> libdialog-dev package with the .so symlink but without libdialog.a,
> >> because that requires (if I understood you correctly) configuring and
> >> building dialog twice, greatly complicating packaging.
> >> Santiago, do you think this is a good plan?
> >
> > Yes. If we can avoid the static library to keep it simple, that would be 
> > better.
> >
> > Simple question: Is that really allowed these days? I wanted to be sure
> > by reading Policy but did not find any statement saying they are required
> > or not.
> 
> I could only find the following two sentences in §8.3:
> 
> ,
> | The static library ("libraryname.a") is usually provided in addition
> | to the shared version. It is placed into the development package (see
> | below).
> `
> 
> So shipping static libraries is recommended but not required, and there
> are certainly quite a few packages where upstream does not support them.
> But see below.

Actually, for development on MacOS, I have to use static libraries,
because there's no useful analog for LD_LIBRARY_PATH :-)
 
> >> I can work on an updated patch.
> >
> > That would definitely help.
> 
> This afternoon I got my hands dirty.  The first attempt to simply pass
> --with-shared to configure failed to give me a libdialog.a, and it also
> produced the following odd collection of *.so* files:
> 
> libdialog.so -> libdialog.so.15.0.0
> libdialog.so.1.3
> libdialog.so.15.0.0 -> libdialog.so.1.3

fwiw, ncurses, dialog and cdk use the same scripts (and version information)
 
> Not what you would expect, and it does not match the files shipped in
> the Fedora and Arch packages.  A closer look revealed that they both
> configure dialog --with-libtool, and that worked great because it gave
> me not only the expected layout of *.so* files, but also a static
> libdialog.a library. :-)

perhaps - but since aside from Linux, libtool support is not reliable,
it's not going to be of primary concern to me.

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


signature.asc
Description: PGP signature

Bug#1067771: cdk.h file location has changed, breaks application build

[Thomas Dickey]

On Fri, Mar 29, 2024 at 01:30:58PM -0500, Steven Robbins wrote:
> On Thursday, March 28, 2024 8:04:30 P.M. CDT Thomas Dickey wrote:
> 
> > I suppose that I _could_ have made a symlink in /usr/include/cdk,
> > to address both old/new locations.  You might consider that for
> > the package...
> 
> That's a good idea.  I've implemented your suggestion and closed the bug.

no problem (report bugs)

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


signature.asc
Description: PGP signature

Bug#1067771: cdk.h file location has changed, breaks application build

[Thomas Dickey]

On Thu, Mar 28, 2024 at 08:55:04PM -0400, Thomas Dickey wrote:
> On Thu, Mar 28, 2024 at 11:15:04AM -0500, Steven Robbins wrote:
> > Hello Thomas!
> > 
> > Thanks for chiming in on this issue.  I had sent a follow-up at about the 
> > same 
> > time you did with a few details on the history as I could reconstruct it.
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067771#18
> > 
> > In summary: I believe you changed the default location from  to 
> >  in 2012, adding a configure option at the same time.  When this 
> > version 
> > was uploaded to Debian (much later), a debian-specific patch was added to 
> > retain the original location.  Four years ago, the previous debian 
> > maintainer 
> > removed that patch - but was never uploaded to debian unstable.  I took 
> > over 
> > maintenance a month ago and inadvertently uploaded to unstable a version 
> > where 
> > the header change from 2012 was exposed for the first time.
> 
> ...yes - I didn't record a reason for the change, so likely what prompted it
> was noting that cdk.h includes all of the other files, which makes it
> inconsistent to put it in the same subdirectory as the others.  fwiw, I do the
> same for dialog.
> 
> Just in case someone disagreed, I made it configurable.

I suppose that I _could_ have made a symlink in /usr/include/cdk,
to address both old/new locations.  You might consider that for
the package...

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


signature.asc
Description: PGP signature

Bug#1067771: cdk.h file location has changed, breaks application build

[Thomas Dickey]

On Thu, Mar 28, 2024 at 11:15:04AM -0500, Steven Robbins wrote:
> Hello Thomas!
> 
> Thanks for chiming in on this issue.  I had sent a follow-up at about the 
> same 
> time you did with a few details on the history as I could reconstruct it.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067771#18
> 
> In summary: I believe you changed the default location from  to 
>  in 2012, adding a configure option at the same time.  When this 
> version 
> was uploaded to Debian (much later), a debian-specific patch was added to 
> retain the original location.  Four years ago, the previous debian maintainer 
> removed that patch - but was never uploaded to debian unstable.  I took over 
> maintenance a month ago and inadvertently uploaded to unstable a version 
> where 
> the header change from 2012 was exposed for the first time.

...yes - I didn't record a reason for the change, so likely what prompted it
was noting that cdk.h includes all of the other files, which makes it
inconsistent to put it in the same subdirectory as the others.  fwiw, I do the
same for dialog.

Just in case someone disagreed, I made it configurable.
 
> I can see a valid argument for retaining the Debian practice.  But when I 
> discovered that the upstream change was 12 years old, I figured that there 
> are 
> likely other folks long used to the "new" header location and have adapted 
> their code.  So there is also a valid argument to adhering to the upstream 
> location and harmonizing the landscape for code using libcdk.
> 
> I actually did a search on github and discovered examples of all three cases:
> * code using  only
> * code using  only
> * code that probes both locations and uses the one found
> 
> I'm wondering whether you have an opinion on the merits of one path versus 
> the 
> other.  Do you have any information about how much currently-maintained 
> software is still using ?

not really (actually I don't keep track for any of my programs)

In a quick check of other packages that I know about, I don't see any using
the subdirectory.  (I've corrected the configure option, just for tidiness).
 
> At present, I'm leaning towards retaining the default location .

I suppose it depends on how many packages have to be tweaked.
(actually in the current set of changes for time_t, I'd suppose
that changes like this would be less favored)

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


signature.asc
Description: PGP signature

Bug#1067771: cdk.h file location has changed, breaks application build

[Thomas Dickey]

On Tue, Mar 26, 2024 at 03:37:10PM +0100, Harald Welte wrote:
> Package: libcdk5-dev
> Version: 5.0.20230201-3
> Severity: normal
> 
> It used to be the case (for probably more than a decade) that the main cdk.h 
> file
> contained in libcdk5-dev is located in /usr/include/cdk/cdk.h

odd - I dimly recall some long-ago discussion.

But reviewing it, I see that I had implemented a configure option,
which doesn't actually work.  In configure.in, I see that the option
should have set $HDR_SUBDIR, and that if the option was set, the value for
HDR_ROOTNAME also is incorrect:

1.53 (tom  20-Mar-12): AC_MSG_CHECKING(if cdk.h should be in header 
subdirectory)
1.53 (tom  20-Mar-12): AC_ARG_WITH(hdrname,
1.53 (tom  20-Mar-12):  [  --enable-hdr-subdir install 
cdk.h in the header subdirectory],
1.53 (tom  20-Mar-12):  [HDR_ROOTNAME=no])
1.53 (tom  20-Mar-12): AC_MSG_RESULT($HDR_SUBDIR)
1.53 (tom  20-Mar-12): AC_SUBST(HDR_SUBDIR)
1.53 (tom  20-Mar-12): 
1.53 (tom  20-Mar-12): if test "$HDR_SUBDIR" = yes
1.53 (tom  20-Mar-12): then
1.53 (tom  20-Mar-12):  HDR_SUBDIR="#"
1.53 (tom  20-Mar-12): else
1.53 (tom  20-Mar-12):  HDR_SUBDIR=
1.53 (tom  20-Mar-12): fi

However, looking at the history for the Debian package,

https://salsa.debian.org/debian/libcdk5

I don't see how it worked around the HDR_SUBDIR value.

The existing script can be worked-around by setting HDR_SUBDIR to "yes"
when running the configure script.

(The updates for 2023 fixed the known fail-to-build issues; I have some
further unreleased changes, but had overlooked this although I might have
stumbled onto this bug by some ongoing work to compare the layout in my
test-packages vs Debian).
 
> This is still the case in debian stable as of 5.0.20180306-3
> 
> However, in currnt unstable (5.0.20230201-3), the location has suddenly 
> shifted to
> /usr/include/cdk.h
> 
> This is breaking applications like osmo-bsc, which is using the following
> autoconf macro to test for cdk.h presence:
> 
> AC_CHECK_HEADERS(cdk/cdk.h, [], AC_MSG_ERROR(Unable to find libcdk))
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libcdk5-dev depends on:
> pn  libcdk5t64  
> ii  libncurses-dev  6.4+20240113-1
> 
> libcdk5-dev recommends no packages.
> 
> libcdk5-dev suggests no packages.
> 

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


signature.asc
Description: PGP signature

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#1033423: lynx: Status line stuck on "HTTP/1.1 200 OK", body not rendered, no input accepted when receiving a specifically-formatted response

[Thomas Dickey]

tags 1033423 fixed-upstream

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


signature.asc
Description: PGP signature

Bug#1033423: lynx: Status line stuck on "HTTP/1.1 200 OK", body not rendered, no input accepted when receiving a specifically-formatted response

[Thomas Dickey]

On Mon, Mar 27, 2023 at 07:20:25PM -0400, Thomas Dickey wrote:
> On Fri, Mar 24, 2023 at 08:36:26PM +0100, наб wrote:
> > Package: lynx
> > Version: 2.9.0dev.6-3~deb11u1
> > Version: 2.9.0dev.12-1
> > Severity: normal
> ...
> > I get the same thing when I run
> >   echo 
> > 485454502F312E3120323030204F4B0D0A436F6E74656E742D547970653A20746578742F68746D6C0D0A5472616E736665722D456E636F64696E673A206368756E6B65640D0A0D0A33350D0A3C6D65746120636861727365743D7574662D383E3C7469746C653E657370333270736B6F3C2F7469746C653E43757272656E743A200D0A340D0A444F574E0D0A34330D0A3C6272202F3E3C666F726D206D6574686F643D706F73743E3C6C6162656C3E4E65773A203C696E70757420747970653D636865636B626F78206E616D653D76616C75650D0A32640D0A3E3C2F6C6162656C3E3C696E70757420747970653D7375626D69742076616C75653D5365743E3C2F666F726D3E0D0A300D0A0D0A
> >  | base16 -d | nc -lp 8000
> > and open localhost:8000, for a cheaper repro.
> 
> thanks - I can reproduce this case (trace shows it reads the whole file)

The basic problem is that using nc in this way differs from a real webserver,
because it leaves the connection open and inactive.  Lynx actually will
time out in that case, but it is a long time by default, to provide for
slow connections.

man lynx:
   -read_timeout=N
  Sets the read-timeout, where N is given in seconds.

lynx.cfg:
.h2 READ_TIMEOUT
# Specifies (in seconds) read-timeout. Default value is rather huge.
#READ_TIMEOUT:18000

(30 minutes).  Some other programs (not all) work around this by either
using multiple threads (and providing for partial updates), or polling
for activity (for the same purpose).  Lynx does neither.

As an alternative, one can interrupt the read, e.g., using ^G.
In the existing Lynx, that has the drawback that the connection
is abandoned (which is a problem if you run it to just connect
to a certain page -- Lynx exits).  To work around that problem,
I modified the behavior to gracefully close (no exit) if you
interrupt the read loop.  That keeps ^G in its existing behavior
for interrupting connection attempts, and makes this example work
as intended.

The workaround is in Lynx 2.9.0

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


signature.asc
Description: PGP signature

Bug#1058041: ncurses: breaks `hg histedit` (_curses.error: endwin() returned ERR)

[Thomas Dickey]

On Sat, Dec 16, 2023 at 10:48:33AM +0100, Sven Joachim wrote:
> On 2023-12-11 15:12 -0500, Thomas Dickey wrote:
> 
> > On Mon, Dec 11, 2023 at 05:47:23PM +0100, Sven Joachim wrote:
> >>
> >> I am not familiar with Mercurial, but most likely this has been
> >> triggered by the following change in the 2023111 patchlevel:
> >>
> >> ,
> >> | 2023
> >> |  + modify endwin() to return an error if it is called again without an
> >> |intervening screen update (report by Rajeev Pillai, NetBSD #57592).
> >> `
> >>
> >> NetBSD #57592 is
> >> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57592 .
> >
> > sounds plausible.  fwiw, handling error returns (other than throwing an
> > exception) is something that developers should do.
> 
> I may be something that developers should do, but in the case of
> endwin() hardly anybody does it.  In C/C++ programs, nobody seems to
> check the return value of endwin() in the first place, so this change is
> not really going to make a difference.
> 
> In Python the situation is different, because a curses.error exception
> occurs.  The wrapper does not handle it, FWIW.
> 
> > I suspect that making ncurses not return error-codes is a step in the wrong
> > direction.  The example in the NetBSD bug report was clearly a defect in
> > the application using ncurses.
> 
> The question is how many such defects are there, and how do we find
> them?  Based on the current report I looked on codesearch.debian.net for
> more instances where programs make the same mistake as mercurial (using
> both curses.wrapper and calling curses.endwin() explicitly).  I could

which does this:

finally:
# Set everything back to normal
if 'stdscr' in locals():
stdscr.keypad(0)
curses.echo()
curses.nocbreak()
curses.endwin()

(and appears to have its own problems with copy/paste: the settings changes
are redundant).

> not find something as broken as the current case, but there seem to be a
> few instances where programs call curses.endwin() in a signal handler,
> and that may cause issues like #1058626 in pulsemixer.
> 
> > In this case, I chose to make it behave like SVr4 curses.  Explaining this
> > nicely in a portability section of the manpage is still on my to-do list,
> > but it's clear in the note that I made.  NetBSD curses returns no error,
> > but it's based on some code to handle SIGTSTP.
> 
> I think it is too late to change behavior in ncurses.  This change is
> going to cause problems for end users which outweigh any benefits from
> forcing changes in non-conforming applications, IMHO.

If I weren't spending about a quarter of my time repairing configure scripts
broken by "improvements" to compiler warnings, I'd be more agreeable.

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


signature.asc
Description: PGP signature

Bug#1058560: libncursesw6: getch(3ncurses) returns -1 with errno unchanged, only documented to return -1 with errno=EINTR

[Thomas Dickey]

On Wed, Dec 13, 2023 at 11:09:41PM +0100, наб wrote:
> On Wed, Dec 13, 2023 at 03:49:48PM +0100, наб wrote:
> > On Wed, Dec 13, 2023 at 02:09:35PM +0100, наб wrote:
> > > On Tue, Dec 12, 2023 at 08:30:02PM -0500, Thomas Dickey wrote:
> > > > mouseinterval(0) tells it to not wait for mouse events,
> > > Well, mouseinterval(3curses) says
> > >   Use mouseinterval(0) to disable click resolution.
> > > which is different from "not wait for mouse events".
> > Even funnier, it also says that
> >   The  mouseinterval  function  sets  the  maximum time (in thousands of
> >   a second) that can elapse between press and release events for them to
> >   be recognized as a click.
> > and it appears to only actually be used for coalescing adjacent click
> > events into double and triple clicks (testing confirms this),
> > so the manual sure reads like disinformation.
> Okay so it does appear to be true... on NetBSD.
>
> > In light of this,
> > > > I'd have used a 5msec delay (or 1msec for "modern" computers :-)
> > I wouldn't, since this corresponds to the actual delay between
> > consecutive clicks, and even I can't click twice in 5ms.
> And in a quite-slow VM, under X and uxterm,
> mouseinterval(0) works sporadically but mouseinterval(5) works always.
>
> Admittedly, curses_mouse(3) simultaneously says
> "There is currently no actual mouse support" and
> "The mouse functions were added in NetBSD 10.0";
> the default is 200ms.

I've noticed that they added stubs (mainly to allow some programs to link),
but probably won't take a close look until NetBSD 10.0 is actually released.

They haven't documented it here, for instance:

https://www.netbsd.org/changes/changes-10.0.html

...and since I'm commenting on it, a quick look at the source code shows
me just a stub (like all of the other functions in that file):

int
mouseinterval(__unused int erval)
{

return DEFAULT_MAXCLICK;
}

from this commit:

commit bb2ce1fb3dcd76a4268234f209e31a4af8ac8135
Author: roy 
Date:   Mon Mar 23 13:37:36 2020 +

curses: Add stubs for mouse functions

No mouse support actually included.
But that doesn't matter because most terms don't actually support a mouse.

We should look into hooking these into wsmouse(4) and xterm mouse
in the future.

Compatable with nCurses mouse API version 2.

So I'd hold off on discussing what NetBSD curses does, until they get around
to actually doing it.

> (Additionally it also governs coalescing multiple clicks into
>  double/triple, just like under ncurses.)
>
> So the ncurses manual documents the behaviour of non-n-curses,
> it's contradicted by experimentation on ncurses,
> and the most common response to this
> (I recommend a codesearch.d.n for "mouseinterval\(0" vs
>   "mouseinterval\([1-9]")
> works on ncurses but breaks on non-n-curses?

it's in the manpage:

PORTABILITY
   These  calls  were designed for ncurses(3NCURSES), and are not found in
   SVr4 curses, 4.4BSD curses, or any other previous version of curses.

> Why do I have to learn of this by gruesome experimentation
> (the ISO was 743.78M 33.8KB/sin 5h 39m)
> and an off-hand comment instead of this being in the manual?

This particular function is little used, but generally speaking,
having an idea of how click-resolution _has_ to be computed
(like function-key stuff), it's not effective to use zero-delays.

Currently it's used in one test program, and I see that it's using zero
there (I didn't write that one, but have made several corrections to it -
overlooked this detail).

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


signature.asc
Description: PGP signature

Bug#1058560: libncursesw6: getch(3ncurses) returns -1 with errno unchanged, only documented to return -1 with errno=EINTR

[Thomas Dickey]

On Wed, Dec 13, 2023 at 01:33:59AM +0100, наб wrote:
> On Tue, Dec 12, 2023 at 05:55:38PM -0500, Thomas Dickey wrote:
> > On Tue, Dec 12, 2023 at 11:09:13PM +0100, наб wrote:
> > > urlview 1c-1 whose xterm was killed but which didn't die consumes 100% 
> > > CPU.
> > > The event loop is for(;;) switch(getch()) ... and ignores -1
> > If it's going to ignore the error return (while at the same time
> > manipulating the time delays with mousemask), then this is expected
> > (mis)behavior.
> Sure.
> 
> Still, it doesn't set errno to EINTR,

...and the manual page does not say it would do that.

It lists three possible causes for ERR being returned,
and on the third it mentions that errno will be set:

   returns ERR if the window pointer is null, or if its timeout
   expires without having any data, or if the execution was interrupted by
   a signal (errno will be set to EINTR).

It could be reformatted like this without changing its meaning:

   returns ERR
   
   * if the window pointer is null, or

   * if its timeout expires without having any data, or

   * if the execution was interrupted by a signal (errno will be set to
 EINTR).

though doing that for every 2-3 line sentence will make the page less readable.

(errno isn't set for a null window pointer either)

> and instant empty reads you get from a hung-up teletype
> definitely aren't exceeding the timeout.

https://git.sr.ht/~nabijaczleweli/urlview-ng/tree/1c/item/urlview.c#L441

mouseinterval(0) tells it to not wait for mouse events, and results in
a zero-delay in check_mouse_activity:

https://github.com/ThomasDickey/ncurses-snapshots/blob/b5a2b7c720102b187e6d1099f36ed2643fea4934/ncurses/base/lib_getch.c#L152

That looks like someone's attempting to make the wheel mouse work at
infinite velocity -- and might be the reason for ignoring errors -- and
might be the reason for the 100% CPU.

I'd have used a 5msec delay (or 1msec for "modern" computers :-)

If ncurses is actually reading from a closed file descriptor, the manpage
for read(2) suggests that errno may be set to EBADF -- but since you say
errno is _not_ being set, then there's nothing to alert ncurses to the
problem -- the timeout expired.  (You may get more insight using strace).

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


signature.asc
Description: PGP signature

Bug#1058560: libncursesw6: getch(3ncurses) returns -1 with errno unchanged, only documented to return -1 with errno=EINTR

[Thomas Dickey]

On Tue, Dec 12, 2023 at 11:09:13PM +0100, наб wrote:
> Package: libncursesw6
> Version: 6.4+20231121-1
> Severity: normal
> 
> Dear Maintainer,
> 
> urlview 1c-1 whose xterm was killed but which didn't die consumes 100% CPU.
> The event loop is for(;;) switch(getch()) ... and ignores -1

If it's going to ignore the error return (while at the same time
manipulating the time delays with mousemask), then this is expected
(mis)behavior.

That's in the manpage -- see below.

> (https://git.sr.ht/~nabijaczleweli/urlview-ng/tree/1c/item/urlview.c#L576).
> 
> strace -p:
>   read(0, "", 1)  = 0
>   read(0, "", 1)  = 0
>   read(0, "", 1)  = 0
>   read(0, "", 1)  = 0
>   read(0, "", 1)  = 0
>   read(0, "", 1)  = 0
> 
> 
> ltrace -p:
>   wgetch(0x55e356e14860, 0, 0, 1)   = 0x
>   wgetch(0x55e356e14860, 0x, 0, 0x) = 0x
>   wgetch(0x55e356e14860, 0, 0, 1)   = 0x
>   wgetch(0x55e356e14860, 0x, 0, 0x) = 0x
>   wgetch(0x55e356e14860, 0, 0, 1)   = 0x
>   wgetch(0x55e356e14860, 0x, 0, 0x) = 0x
>   wgetch(0x55e356e14860, 0, 0, 1)   = 0x
>   wgetch(0x55e356e14860, 0x, 0, 0x) = 0x
> 
> 
> gdb -p, b ./urlview.c:576:
>   (gdb) cont
>   Continuing.
>   
>   Breakpoint 1, main (argc=, argv=) at 
> ./urlview.c:576
>   576 int c = getch();
>   (gdb) n
>   578 switch(c) {
>   (gdb) p c
>   $1 = -1
>   (gdb) p *__errno_location()
>   $3 = 5
> this is EIO. By resetting *__errno_location() = 0 and letting it rip for
> a few more loops, I see it continue to be 0,
> so it just returns 0 but doesn't change errno
> (I'm assuming changing errno is a side-effect of read(),
>  which completes successfully but emptily here),
> presumably the EIO is from an earlier refresh to a dead pty.
> 
> getch(3ncurses) on bookworm and sid says
>   RETURN VALUE
> All routines return the integer ERR upon failure and an integer
> value other than ERR (OK in the case of ungetch) upon successful
> completion.
> 
> wgetch returns ERR if the window pointer is null, or if its
> timeout expires without having any data, or if the execution
  ^^^

> was interrupted by a signal (errno will be set to EINTR).
> so how precisely you're meant to handle this is unclear to me.
> 
> The first sentence implies "case ERR: exit(1)",
> but the second implies "case ERR: if(errno != EINTR) exit(1); break"
> to me.
> 
> I set no timeouts so I expect that bit to not apply,
> but I read this as the EINTR parenthetical applying to both the
> interruption and timeout cases.
> 
> Either way, if errno isn't (re)set, then returning ERR isn't really
> reliable or meaningful i think (lest you "errno=0, getch()" always?
> which kinda sucks).
> 
> I see SUSv2 XCURSES say:
>   Upon successful completion getch(), mvgetch(), mvwgetch() and
>   wgetch() return the single-byte character, KEY_ value, or ERR.
>   When in the nodelay mode and no data is available, ERR is returned.
> which makes it silent on the issue.
> 
> Reopening its pty fails with EIO, as expected, but consulting stty
> against urlview in a live xterm I see
>   speed 38400 baud; rows 54; cols 172; line = 0;
>   -brkint -icrnl -imaxbel iutf8
>   -onlcr
>   -icanon -echo
> so -icanon min=1 time=0, which is by no means a "nodelay" mode,
> and it doesn't have a "timeout" set.
> 
> Naturally, setting min=0 time=1 I reproduce the empty-returning read()s,
> and the unchanging errno.
> 
> So to this point, I think this just needs disambiguation to the tune of
> "having any data (with errno unchanged)".
> 
> Empty read()s from a hung-up teletype aren't covered by the
> documentation. Naturally this is an adversarial reading,
> but it may not be obvious to all readers that these are homologous
> conditions:
> "or if the read from returns empty \(em be it due to a timeout
>  expiring with no data or due to a hangup (with errno unchanged),"
> 
> In a similar vein, I see a lot of references to a "cbreak mode"
> (sometimes in bold) and a "nocbreak mode" (never in bold).
> I suppose this is a left-over from old berkeley manuals(?),
> but that's not a feature of the Linux teletype driver,
> and according to my notes[1] the CBREAK mode features in [V7, 4.4BSD)
> exclusively, which isn't really useful to the modern reader,
> with the 4.4BSD URM being released close to 30 years ago now.
> The only remnant of this remains in stty(1), but that consistently calls
> it cbreak/-cbreak mapping it to -icanon/icanon. This makes it even more
> jarring to a modern reader.
> 
> Anyway, is this behaviour expected, and is the loop best-served as
>   for(;;) switch(errno=0, getch()) case ERR: if(errno != EINTR) { err = true; 
> 

Bug#1058041: ncurses: breaks `hg histedit` (_curses.error: endwin() returned ERR)

[Thomas Dickey]

On Mon, Dec 11, 2023 at 05:47:23PM +0100, Sven Joachim wrote:
> On 2023-12-11 16:22 +0100, Julien Cristau wrote:
> 
> > Source: ncurses
> > Version: 6.4+20231121-1
> > Severity: important
> > Control: affects -1 mercurial
> > X-Debbugs-Cc: jcris...@debian.org
> >
> > Hi,
> >
> > Since a ncurses upgrade in testing recently `hg histedit` seems to
> > crash consistently, upon trying to apply the changes:
> >
> >> Traceback (most recent call last):
> >>   File "/usr/bin/hg", line 59, in 
> >> dispatch.run()
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 142, 
> >> in run
> >> status = dispatch(req)
> >>  ^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 231, 
> >> in dispatch
> >> status = _rundispatch(req)
> >>  ^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 275, 
> >> in _rundispatch
> >> ret = _runcatch(req) or 0
> >>   ^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 456, 
> >> in _runcatch
> >> return _callcatch(ui, _runcatchfunc)
> >>^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 466, 
> >> in _callcatch
> >> return scmutil.callcatch(ui, func)
> >>^^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 152, in 
> >> callcatch
> >> return func()
> >>^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 446, 
> >> in _runcatchfunc
> >> return _dispatch(req)
> >>^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1271, 
> >> in _dispatch
> >> return runcommand(
> >>^^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 904, 
> >> in runcommand
> >> ret = _runcommand(ui, options, cmd, d)
> >>   
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1283, 
> >> in _runcommand
> >> return cmdfunc()
> >>^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1269, 
> >> in 
> >> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
> >> ^
> >>   File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1878, in 
> >> check
> >> return func(*args, **kwargs)
> >>^
> >>   File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1918, in 
> >> histedit
> >> return _chistedit(ui, repo, freeargs, opts)
> >>
> >>   File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1764, in 
> >> _chistedit
> >> curses.endwin()
> >> _curses.error: endwin() returned ERR
> 
> I am not familiar with Mercurial, but most likely this has been
> triggered by the following change in the 2023111 patchlevel:
> 
> ,
> | 2023
> | + modify endwin() to return an error if it is called again without an
> |   intervening screen update (report by Rajeev Pillai, NetBSD #57592).
> `
> 
> NetBSD #57592 is
> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57592 .

sounds plausible.  fwiw, handling error returns (other than throwing an
exception) is something that developers should do.

I suspect that making ncurses not return error-codes is a step in the wrong
direction.  The example in the NetBSD bug report was clearly a defect in
the application using ncurses.

In this case, I chose to make it behave like SVr4 curses.  Explaining this
nicely in a portability section of the manpage is still on my to-do list,
but it's clear in the note that I made.  NetBSD curses returns no error,
but it's based on some code to handle SIGTSTP.

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


signature.asc
Description: PGP signature

Bug#1057688: aptitude: Stray input on window click when running under tmux

[Thomas Dickey]

On Fri, Dec 08, 2023 at 05:01:43PM +0100, Sven Joachim wrote:
> On 2023-12-07 17:41 -0500, Thomas Dickey wrote:
> 
> > On Thu, Dec 07, 2023 at 06:06:49PM +0100, Axel Beckert wrote:
> >> Hi Sven,
> >>
> >> Sven Joachim via Aptitude-devel wrote:
> >> > Debian ncurses maintainer here, bringing the ncurses upstream developer
> >> > into the loop.
> >>
> >> Thanks for that!
> >>
> >> > In addition to aptitude, mouse support is also broken in dialog(1) under
> >> > tmux.
> >> >
> >> > > Maybe this bug should instead be assigned to ncurses?
> >> >
> >> > Probably should be reassigned to ncurses-base, but let's first see what
> >> > Thomas has to say about it.
> >
> > It's probaby the same issue as this;
> >
> > 20231028
> > + move xterm focus mode 1004 from xterm+sm+1006 into xterm+focus as
> >   fe/fd capabilities, like vim (vim-pr #13440).
> 
> Looking at the misc/terminfo.src changes in that patchlevel, I see that
> you added xterm+focus to several terminfo entries that had used
> xterm+sm+1006, which is logical and in line with the NEWS entry.
> 
> However, tmux got changed the other way around: it already had used
> xterm+focus, and you added xterm+sm+1006.  This is the diff hunk:
> 
> ,
> | @@ -8550,7 +8556,7 @@ tmux|tmux terminal multiplexer,
> | use=ecma+italics, use=ecma+strikeout, use=xterm+edit,
> | use=xterm+pcfkeys, use=xterm+sl, use=xterm+tmux,
> | use=screen, use=bracketed+paste, use=report+version,
> | -   use=xterm+focus,
> | +   use=xterm+focus, use=xterm+sm+1006,
> |
> |  tmux-256color|tmux with 256 colors,
> | use=xterm+256setaf, use=tmux,
> `
> 
> That seems to be not really intended and should likely be reverted,
> given the issue at hand.

will do.

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


signature.asc
Description: PGP signature

Bug#1057688: [Aptitude-devel] Bug#1057688: aptitude: Stray input on window click when running under tmux

[Thomas Dickey]

On Thu, Dec 07, 2023 at 06:06:49PM +0100, Axel Beckert wrote:
> Hi Sven,
> 
> Sven Joachim via Aptitude-devel wrote:
> > Debian ncurses maintainer here, bringing the ncurses upstream developer
> > into the loop.
> 
> Thanks for that!
> 
> > In addition to aptitude, mouse support is also broken in dialog(1) under
> > tmux.
> >
> > > Maybe this bug should instead be assigned to ncurses?
> > 
> > Probably should be reassigned to ncurses-base, but let's first see what
> > Thomas has to say about it.

It's probaby the same issue as this;

20231028
+ move xterm focus mode 1004 from xterm+sm+1006 into xterm+focus as
  fe/fd capabilities, like vim (vim-pr #13440).

(a change to the terminal description to help vim turned out to expose one
of the VTE bugs - fixed by making it less likely for other applications
to trigger the bug)

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


signature.asc
Description: PGP signature

Bug#1057651: ncurses-doc: cross references in manpages are broken

[Thomas Dickey]

On Wed, Dec 06, 2023 at 07:18:55PM -0500, Thomas Dickey wrote:
> On Wed, Dec 06, 2023 at 05:26:35PM +0100, Sven Joachim wrote:
> > Package: ncurses-doc
> > Version: 6.4+20231121-1
> > 
> > References to other manpages, e.g. in the "SEE ALSO" section, do no
> > longer work correctly.
> > 
> > ,
> > | $ man terminfo_variables | grep -A1 "SEE ALSO"
> > | SEE ALSO
> > |curses(3X), curs_terminfo(3X), curs_threads(3X), terminfo(5)
> > `
> > 
> > Compare that with the correct references in ncurses-doc 6.4-4 (bookworm):
> > 
> > ,
> > | $ man terminfo_variables | grep -A1 "SEE ALSO"
> > | SEE ALSO
> > |ncurses(3NCURSES), terminfo(3NCURSES), threads(3NCURSES), 
> > terminfo(5).
> > `
> 
> I hadn't noticed that (I had to make other fixes to get the filenames
> to work after Branden's changes in the NAME section, but overlooked this 
> part).
>  
> > Bisection revealed that (at least for the manpage in question) the
> > formatting changes in the 20231001 patchlevel triggered the problem.
> > The man/make_sed.sh script most likely needs to be adjusted, it has not
> > seen any changes since the 20230625 patchlevel.
> 
> yes... it's that "\%" pair (will fix)

something like this:

--- man/make_sed.sh 2023/11/25 14:31:18 1.18
+++ man/make_sed.sh 2023/12/07 01:16:43
@@ -76,9 +76,10 @@
$UPPER
 
 echo "# Do the embedded references"
-sed-e 's/
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1057651: ncurses-doc: cross references in manpages are broken

[Thomas Dickey]

On Wed, Dec 06, 2023 at 05:26:35PM +0100, Sven Joachim wrote:
> Package: ncurses-doc
> Version: 6.4+20231121-1
> 
> References to other manpages, e.g. in the "SEE ALSO" section, do no
> longer work correctly.
> 
> ,
> | $ man terminfo_variables | grep -A1 "SEE ALSO"
> | SEE ALSO
> |curses(3X), curs_terminfo(3X), curs_threads(3X), terminfo(5)
> `
> 
> Compare that with the correct references in ncurses-doc 6.4-4 (bookworm):
> 
> ,
> | $ man terminfo_variables | grep -A1 "SEE ALSO"
> | SEE ALSO
> |ncurses(3NCURSES), terminfo(3NCURSES), threads(3NCURSES), 
> terminfo(5).
> `

I hadn't noticed that (I had to make other fixes to get the filenames
to work after Branden's changes in the NAME section, but overlooked this part).
 
> Bisection revealed that (at least for the manpage in question) the
> formatting changes in the 20231001 patchlevel triggered the problem.
> The man/make_sed.sh script most likely needs to be adjusted, it has not
> seen any changes since the 20230625 patchlevel.

yes... it's that "\%" pair (will fix)

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


signature.asc
Description: PGP signature

Bug#1056365: luit: Separate luit package should not be in bookworm (stable).

[Thomas Dickey]

On Tue, Nov 21, 2023 at 02:00:13PM -0500, Jesse Rhodes wrote:
> Package: luit
> Version: 2.0.20221028-1
> Severity: important
> X-Debbugs-Cc: je...@sney.ca
> 
> Hi,
> 
> As I understand from #1010337 & co, the luit binary was split into a
> separate package for xterm compatibility. However, bookworm still has
> /usr/bin/luit in x11-utils, referenced by the Breaks/Replaces in the
> new luit package. This gets us into some funny situations, e.g. where
> x11-utils can't be installed[1] because the luit package was pulled in
> automatically by xterm.
> 
> Since, as far as I can tell, /usr/bin/luit is identical in x11-utils
> 7.7+5 and luit 2.0.20221028-1, the most straightforward solution is

I don't see that - x11-utils-7.7+5 was tagged 3 years ago:

https://salsa.debian.org/xorg-team/app/x11-utils/-/commit/a228065f0382b13712540cfe1f9ba7a977832843

Timo Aaltonen   Sat, 29 Feb 2020 08:29:50 +0200

while 7.7+6 is not yet in bookworm, which I read was released in June 2023.

(I don't know the solution to this, either)

> simply to drop the extra luit package from bookworm. Another option
> may be to leave it and change the Recommendation order in xterm, from
> luit | x11-utils (<< 7.7+6~) to x11-utils (<<7.7+6~) | luit .

That (amending the recommendation) sounds promising, since xterm likely is
the only package doing that.
 
> sney
> 
> [1] Steps to reproduce:
> - Install bookworm with no desktop tasks selected
> - Install a window manager and xterm
> - Attempt to install something that depends on x11-utils, such as chromium
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages luit depends on:
> ii  libc6  2.37-12
> 
> luit recommends no packages.
> 
> luit suggests no packages.
> 
> -- no debconf information

-- 
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#1055882: libncurses6: waddnstr() reads n+1 bytes, ought to end at n bytes

[Thomas Dickey]

On Tue, Nov 14, 2023 at 03:50:31PM +0100, наб wrote:
> On Mon, Nov 13, 2023 at 08:13:02PM -0500, Thomas Dickey wrote:
> > The null terminator should be checked only for the special case where
> > the passed-in length is negative.
> I agree in principle but the manual says
> > The four functions with n as the last argument write at most n bytes, or
> > until a terminating null is reached.  If n is -1, then the entire string
> > will be added.
> Which reads to me like it ought to behave like printf(%.*s),
> terminating at the first specified condition ‒
> a C string with a limit, not a range ‒
> so if it's supposed to be a range then maybe something to the effect of

no - as I understand the history of this feature, if the length is specified,
it's possible to send a null character in the middle of the string.
 
> Also I just noticed the comma in mvwaddnstr is italic,

thanks - I have a to-do item to extend the script which I've been
developing to check manpages, to flag these (from seeing Branden's
reports, etc).

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


signature.asc
Description: PGP signature

Bug#1055882: libncurses6: waddnstr() reads n+1 bytes, ought to end at n bytes

[Thomas Dickey]

On Mon, Nov 13, 2023 at 02:54:06PM +0100, наб wrote:
> Package: libncurses6
> Version: 6.4-4
> Severity: normal
> Tags: patch
...
> I see "while ((*str != '\0') && (n-- > 0)) {" is in the wrong order,
> and ought to be "(n-- > 0) && (*str != '\0')" ‒ only reading from str
> when it's not past the end.

It's a little more complicated than that.  The problem was introduced here:

20201205
+ eliminate an additional strlen and wsclen.
+ eliminate an unnecessary strlen in waddnstr() (suggested by Benjamin
  Abendroth).

The null terminator should be checked only for the special case where
the passed-in length is negative.  I overlooked this case when eliminating
the strlen's.  Here's what I have in mind (using a flag to short-circuit
past the test for null terminator):

diff -u -r1.58 lib_addstr.c
--- lib_addstr.c2022/06/11 20:12:04 1.58
+++ lib_addstr.c2023/11/14 01:09:13
@@ -55,16 +55,18 @@
 
 T((T_CALLED("waddnstr(%p,%s,%d)"), (void *) win, _nc_visbufn(astr, n), n));
 
-if (win && (str != 0)) {
+if (win && (str != 0) && (n != 0)) {
+   bool explicit = (n > 0);
+
TR(TRACE_VIRTPUT | TRACE_ATTRS,
   ("... current %s", _traceattr(WINDOW_ATTRS(win;
code = OK;
 
TR(TRACE_VIRTPUT, ("str is not null, length = %d",
-  ((n > 0) ? n : (int) strlen(str;
-   if (n < 0)
+  (explicit ? n : (int) strlen(str;
+   if (!explicit)
n = INT_MAX;
-   while ((*str != '\0') && (n-- > 0)) {
+   while ((explicit || (*str != '\0')) && (n-- > 0)) {
NCURSES_CH_T ch;
TR(TRACE_VIRTPUT, ("*str = %#o", UChar(*str)));
SetChar(ch, UChar(*str++), A_NORMAL);
@@ -228,16 +230,18 @@
 
 T((T_CALLED("waddnwstr(%p,%s,%d)"), (void *) win, _nc_viswbufn(str, n), 
n));
 
-if (win && (str != 0)) {
+if (win && (str != 0) && (n != 0)) {
+   bool explicit = (n > 0);
+
TR(TRACE_VIRTPUT | TRACE_ATTRS,
   ("... current %s", _traceattr(WINDOW_ATTRS(win;
code = OK;
 
TR(TRACE_VIRTPUT, ("str is not null, length = %d",
-  ((n > 0) ? n : (int) wcslen(str;
-   if (n < 0)
+  (explicit ? n : (int) wcslen(str;
+   if (!explicit)
n = INT_MAX;
-   while ((*str != L('\0')) && (n-- > 0)) {
+   while ((explicit || (*str != L('\0'))) && (n-- > 0)) {
NCURSES_CH_T ch;
TR(TRACE_VIRTPUT, ("*str[0] = %#lx", (unsigned long) *str));
SetChar(ch, *str++, A_NORMAL);
 
-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1006193: Remove luit, now packaged separately

[Thomas Dickey]

On Wed, Mar 02, 2022 at 03:09:37PM -0500, Thomas Dickey wrote:
> On Wed, Mar 02, 2022 at 08:15:15PM +0100, Sven Joachim wrote:
> > On 2022-02-21 10:14 +1100, Brendan O'Dea wrote:
> > 
> > > Package: x11-utils
> > > Version: 7.7+5
> > > Severity: normal
> > > Tags: patch
> > > X-Debbugs-Cc: b...@debian.org
> > >
> > > Merge request to remove luit from x11-utils:
> > >
> > >   https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1
> > >
> > > now packaged separately, this commit removes luit and adds a recommends 
> > > for
> > > the new package.
> > 
> > Thanks, I have merged that now.  Are there any packages besides xterm
> > that use luit?  On codesearch.debian.net I found some 75 hits[1], but
> > they seem to be either completely unrelated or only commentaries.

While this has been applied, it's not moving along because the related
version x11-utils (7.7+6) has not gone into testing yet - more than a year.

What has to be done to make that happen?

-- 
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#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers

[Thomas Dickey]

On Sun, Oct 15, 2023 at 04:51:47AM -0400, Thomas Dickey wrote:
> On Sun, Oct 15, 2023 at 02:23:28AM +0200, Salvo Tomaselli wrote:
> > Could you improve the description?

(needs some work :-)

> Unlike the last one on this topic, it uses the terminology of ncurses
> without using the word "ncurses".

Likewise, it uses xterm's documentation (and source code) extensively
(such as in termquery.cpp) without mentioning the source of the information.

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


signature.asc
Description: PGP signature

Bug#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers

[Thomas Dickey]

On Sun, Oct 15, 2023 at 02:23:28AM +0200, Salvo Tomaselli wrote:
> Could you improve the description?
> 
> What does this do?
> 
> For me low level access is ioctl, write or similar…

no - in this case "low level" is a synonym for "hard-coded"

It's just another of the programs written with the assumption that the
terminal is xterm (or one of its imitators).

Unlike the last one on this topic, it uses the terminology of ncurses
without using the word "ncurses".

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


signature.asc
Description: PGP signature

Bug#1043299: xterm: build with ReGIS support

[Thomas Dickey]

On Tue, Aug 08, 2023 at 02:33:10PM -0400, Benjamin Barenblat wrote:
> Package: xterm
> Version: 384-1
> Severity: wishlist
> 
> Xterm supports ReGIS (DEC vector graphics) emulation, but it’s not
> compiled in by default. Would you be willing to add
> `--enable-regis-graphics` to the `configure` invocation in debian/rules?

INSTALL says:

  --enable-regis-graphics enable support for ReGIS graphics

Compile-in code to support experimental ReGIS graphics

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


signature.asc
Description: PGP signature

Bug#1042767: xterm: wrong path to utmp file in manpage

[Thomas Dickey]

On Fri, Aug 04, 2023 at 05:36:12PM +0200, Sven Joachim wrote:
> On 2023-07-31 20:13 -0400, Thomas Dickey wrote:
> 
> > On Mon, Jul 31, 2023 at 05:56:59PM +0200, Sven Joachim wrote:
> >> Package: xterm
> >> Version: 384-1
> >> Severity: minor
> >>
> >> The path to the utmp(5) file in the xterm manpage is wrong:
> >>
> >> ,
> >> | $ man xterm | grep -A1 /utmp
> >> |/etc/utmp
> >> | the system log file, which records user logins.
> >> `
> >>
> >> That should read /var/run/utmp rather than /etc/utmp.  The minstall
> >> script tries to detect the path to the utmp file and substitute the
> >> correct value, but in the build chroot /var/run/utmp has apparently been
> >> absent, as no-one has ever logged in there.
> >
> > yes... /etc/utmp appears to be the convention on AIX and HPUX.
> > I could put that last, (along with /var/adm), since those are
> > systems where people actually log in -- odd, but perhaps the
> > default should be the system where the file is least likely to
> > exist :-)
> 
> That would make sense if the autodetection worked on the other systems,
> but in a world where distributors build packages in chroots and
> containers this is generally not the case.
> 
> I checked the xterm manpage in the packages for Arch Linux, Fedora
> Rawhide, Mageia Cauldron and Opensuse Tumbleweed.  All but the last of
> these do not only mention /etc/utmp but also /etc/wtmp in the FILES
> section, and I am pretty sure those two files do not exist.
> 
> Since autodetection for the paths to the utmp and wtmp files does not
> work reliably, maybe new configure options could help packagers?

that'd be the most reliable way
(for Linux - I'm think of "auto" as the default).

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


signature.asc
Description: PGP signature

Bug#1042767: xterm: wrong path to utmp file in manpage

[Thomas Dickey]

On Mon, Jul 31, 2023 at 05:56:59PM +0200, Sven Joachim wrote:
> Package: xterm
> Version: 384-1
> Severity: minor
> 
> The path to the utmp(5) file in the xterm manpage is wrong:
> 
> ,
> | $ man xterm | grep -A1 /utmp
> |/etc/utmp
> | the system log file, which records user logins.
> `
> 
> That should read /var/run/utmp rather than /etc/utmp.  The minstall
> script tries to detect the path to the utmp file and substitute the
> correct value, but in the build chroot /var/run/utmp has apparently been
> absent, as no-one has ever logged in there.

yes... /etc/utmp appears to be the convention on AIX and HPUX.
I could put that last, (along with /var/adm), since those are
systems where people actually log in -- odd, but perhaps the
default should be the system where the file is least likely to
exist :-)

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


signature.asc
Description: PGP signature

Bug#1041686: Add support for HTTP Status Code 308 as described in RFC 7238 (with patch)

[Thomas Dickey]

On Sat, Jul 22, 2023 at 09:05:17AM +0200, Joey Schulze wrote:
> Package: lynx
> Version: 2.9.0dev.12-1
> Severity: wishlist
> Tags: patch upstream
> X-Debbugs-Cc: j...@infodrom.org
> 
> Hi,
> 
> please add support for HTTP Status Code 308 (Permanent Redirect) to
> lynx, at least for the request method GET.  This new code has been
> specified in RFC 7238 in 2014.
> 
> Attached please find a patch for the quilt system which can be easily
> integrated.

The patch duplicates the check for 301 as 308 (including copying a comment
by "FM", who's not been active for about 25 years.  I'm assuming that
modifying the if-statement for 301 would be what you had in mind.

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


signature.asc
Description: PGP signature

Bug#1027414: luit: broken apt install xorg from a debootstrap installed environment

[Thomas Dickey]

On Sat, Jul 15, 2023 at 08:13:19AM -0400, Thomas Dickey wrote:
> On Sat, Jul 15, 2023 at 10:16:22AM +, David Roderick wrote:
> > Package: luit
> > Version: 2.0.20221028-1
> > Followup-For: Bug #1027414
> > X-Debbugs-Cc: I have been told to report this by #debian on libera irc, 
> > dmr...@inspirondebian.home
> > 
> > Breaks: x11-utils (<<7.7+6) but bookworm contains x11-utils (7.7+5)
> 
> I'd expect that this is a problem to be resolved by releasing x11-utils
> (recall that Brendan's updates to disentangle luit were in January 2022)
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=x11-utils
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003021
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006193
> 
> There are several packages which depend upon x11-utils; probably only
> xterm uses luit, so releasing the update should not cause problems.

For instance, I've seen occasional mention that luit is useful with emacs.
But its source-code doesn't mention luit.

Actually (for better maintenance), the rest of x11-utils should be split up
because its upstream is a collection of tar-balls which introduce dependencies
unwanted by most users.  In particular, this doesn't belong:

/usr/bin/xdriinfo

Since it's actually a problem with x11-utils, this bug should be reassigned.

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


signature.asc
Description: PGP signature

Bug#1027414: luit: broken apt install xorg from a debootstrap installed environment

[Thomas Dickey]

On Sat, Jul 15, 2023 at 10:16:22AM +, David Roderick wrote:
> Package: luit
> Version: 2.0.20221028-1
> Followup-For: Bug #1027414
> X-Debbugs-Cc: I have been told to report this by #debian on libera irc, 
> dmr...@inspirondebian.home
> 
> Breaks: x11-utils (<<7.7+6) but bookworm contains x11-utils (7.7+5)

I'd expect that this is a problem to be resolved by releasing x11-utils
(recall that Brendan's updates to disentangle luit were in January 2022)

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=x11-utils
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003021
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006193

There are several packages which depend upon x11-utils; probably only
xterm uses luit, so releasing the update should not cause problems.

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


signature.asc
Description: PGP signature

Bug#1039986: xterm unicode rendering issue

[Thomas Dickey]

On Fri, Jun 30, 2023 at 06:54:00PM +0200, 10dmar10 wrote:
> Package: xterm
> Version: 382-2
> Severity: minor
> 
> Hi,
> 
> I noticed a unicode character rendering issue in xterm since
> the latest update in debian testing.
> 
> The problem seems to be limited to double width japanese/chinese characters 
> and
> only when using the default bitmap x11 font.

thanks - I had thought the boxes problem was fixed in #381, but
someone reported a related problem on Wednesday, and followed up
with some debugging details (will be working on that soon - after
a more urgent bug-fix).

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


signature.asc
Description: PGP signature

Bug#1037353: lynx.1: a few formatting fixes for the manual

[Thomas Dickey]

On Mon, Jun 12, 2023 at 01:56:56AM +, Bjarni Ingi Gislason wrote:
> Package: lynx
> Version: 2.9.0dev.12-1
> Severity: minor
> Tags: patch
> 
> Dear Maintainer,
> 
> here are some fixes.
> 
> Input file is lynx.1
> 
> Output from "mandoc -T lint lynx.1"
> mandoc: lynx.1:27:2: WARNING: missing date, using "": TH
> mandoc: lynx.1:109:2: WARNING: unknown font, skipping request: ft C   
> 
> mandoc: lynx.1:317:2: WARNING: unknown font, skipping request: ft C   
> 
> mandoc: lynx.1:366:2: WARNING: unknown font, skipping request: ft C   
> 
> mandoc: lynx.1:831:2: WARNING: unknown font, skipping request: ft C   
> 
> mandoc: lynx.1:838:2: WARNING: unknown font, skipping request: ft C   
> 
> mandoc: lynx.1:1131:2: WARNING: unknown font, skipping request: ft C  
> 

That seems to be harmless for nroff, but mainly is for troff (and groff)
to select a fixed-pitch font for PDFs and PostScript.  I'll see if this
is at least no worse than the plain "C".

Solaris 10 appears to have "CO" for "Courier" (troff), while
an AIX that I can access uses "CR".  But on those systems,
I'm not actually using troff :-)

I've been using "C" quite a while, and hadn't noticed a problem with
the indicated usage (i.e., generating PDFs, etc).

> ###
> 
> Increase size of ~ (tilde) to make it more visible
> with "troff" by using character \(ti.

That appears to be groff-specific.
 
> 264:If none is specified, the default value is ~/.lynx_cookies
> 265:for most systems, but ~/cookies for MS-DOS.
> 
> #
> 
>   The following issue is not in the patch:
> 
> an.tmac:lynx.1:27: style: .TH missing third argument; suggest document 
> modification date in ISO 8601 format (-MM-DD)
> an.tmac:lynx.1:27: style: .TH missing fourth argument; suggest 
> package/project name and version (e.g., "lynx ...")

maybe - there are pros/cons (the version number is in the manpage,
and that indirectly gives an accurate date).  If I did put a date,
it would be the modification date for _that_ file.
 
> #
> 
> --- lynx.12023-06-05 16:20:24.0 +
> +++ lynx.1.new2023-06-12 01:32:27.0 +
> @@ -15,7 +15,7 @@
>  .ie n  .in +4
>  .el.in +2
>  .nf
> -.ft C\" Courier
> +.ft CR   \" Courier
>  ..
>  .de NE
>  .fi
> @@ -261,8 +261,8 @@ Sets the connection timeout, where N is
>  .TP
>  .B \-cookie_file\fR=\fIFILENAME
>  specifies a file to use to read cookies.
> -If none is specified, the default value is ~/.lynx_cookies
> -for most systems, but ~/cookies for MS-DOS.
> +If none is specified, the default value is \(ti/.lynx_cookies
> +for most systems, but \(ti/cookies for MS-DOS.
>  .TP
>  .B \-cookie_save_file\fR=\fIFILENAME
>  specifies a file to use to store cookies.
> 
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.27-1 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages lynx depends on:
> ii  libbsd0   0.11.7-2
> ii  libbz2-1.01.0.8-5+b1
> ii  libc6 2.36-9
> ii  libgnutls30   3.7.9-2
> ii  libidn2-0 2.3.3-1+b1
> ii  libncursesw6  6.4-4
> ii  libtinfo6 6.4-4
> ii  lynx-common   2.9.0dev.12-1
> ii  zlib1g1:1.2.13.dfsg-1
> 
> Versions of packages lynx recommends:
> ii  mailcap  3.70+nmu1
> 
> lynx suggests no packages.
> 
> -- no debconf information
> 

-- 
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#1035621: ncurses: FTBFS: dh_autoreconf error on various architectures

[Thomas Dickey]

On Sat, May 06, 2023 at 10:27:54PM +0200, Sven Joachim wrote:
> On 2023-05-06 15:11 -0400, Thomas Dickey wrote:
> 
> > On Sat, May 06, 2023 at 08:01:22PM +0200, Sven Joachim wrote:
> >> On 2023-05-06 19:15 +0200, Sven Joachim wrote:
> >> 
> >> > Source: ncurses
> >> > Version: 6.4-3
> >> > Severity: important
> >> > Tags: ftbfs
> >> >
> >> > On at least three architectures (hurd-i386, powerpc and x32) ncurses
> >> > FTBFS with the following error:
> >> >
> >> > ,
> >> > | dh_autoreconf autoreconf-dickey -- -f -i
> >
> > autoreconf calls automake, which doesn't do any good.
> >
> > At most, it would be replacing config.sub and config.guess with
> > whatever version it happens to have available -- sometimes that's
> > a downgrade, sometimes not - but _very_ rarely would an upgrade of
> > those files benefit Debian.
> 
> Not that it matters, but the config.sub and config.guess files are
> already replaced by the ones in the autotools-dev package, as per Debian
> Policy § 4.3[1].
> 
> And while automake and aclocal are not useful, bypassing them (e.g. via
> "AUTOMAKE=true ACLOCAL=true autoreconf-dickey -f -i") does not help
> either, unfortunately.
> 
> >> So autoreconf-dickey picks up the backup of configure.in below the .pc/
> >> directory and runs aclocal.  As there is no aclocal.m4 in that
> >> directory, the above warning and error about AM_LANGINFO_CODESET ensue,
> >> answering the second question.  That still leaves the first one open,
> >> though.
> >
> > yes - I expect that something in the externals has changed.
> 
> What really has changed is that I am patching ncurses' configure.in for
> the first time in the package's history.  Now the quilt patchsystem
> creates a backup file with the same name below the .pc directory, and I
> do not know how to tell autoreconf to ignore it.
> 
> 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 `.').

-- 
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 Sat, May 06, 2023 at 08:01:22PM +0200, Sven Joachim wrote:
> On 2023-05-06 19:15 +0200, Sven Joachim wrote:
> 
> > Source: ncurses
> > Version: 6.4-3
> > Severity: important
> > Tags: ftbfs
> >
> > On at least three architectures (hurd-i386, powerpc and x32) ncurses
> > FTBFS with the following error:
> >
> > ,
> > | dh_autoreconf autoreconf-dickey -- -f -i

autoreconf calls automake, which doesn't do any good.

At most, it would be replacing config.sub and config.guess with
whatever version it happens to have available -- sometimes that's
a downgrade, sometimes not - but _very_ rarely would an upgrade of
those files benefit Debian.

> > | aclocal: warning: autoconf input should be named 'configure.ac', not 
> > 'configure.in'
> > | configure.in:910: warning: macro 'AM_LANGINFO_CODESET' not found in 
> > library
> > | configure.in:941: error: possibly undefined macro: AM_LANGINFO_CODESET
> > | mv: cannot move '/tmp/aruX6IKF/ahKAGeTw/config.hin' to 
> > 'include/ncurses_cfg.hin': No such file or directory
> > | touch: cannot touch 'include/stamp-h.in': No such file or directory
> > | dh_autoreconf: error: autoreconf-dickey -f -i returned exit code 1
> > `
> >
> > Compare with a successful build on amd64:
> >
> > ,
> > | dh_autoreconf autoreconf-dickey -- -f -i
> > | aclocal: warning: autoconf input should be named 'configure.ac', not 
> > 'configure.in'
> > | configure.in:910: warning: macro 'AM_LANGINFO_CODESET' not found in 
> > library
> > | configure.in:941: error: possibly undefined macro: AM_LANGINFO_CODESET
> > | mv: cannot move '/tmp/ardz33hA/ahzccjnH/config.hin' to 
> > 'include/ncurses_cfg.hin': No such file or directory
> > | touch: cannot touch 'include/stamp-h.in': No such file or directory
> > | touch config.guess-stamp
> > `
> >
> > This raises at least two questions:
> >
> > - Why does dh_autoreconf error out on some architectures, but not on
> >   others?
> >
> > - Why is AM_LANGINFO_CODESET not found, despite being defined in
> >   aclocal.m4?
> >
> > Needs to be investigated, at the moment I have no clue. :-(
> 
> With the -v option, autoreconf-dickey gives some useful hints:
> 
> ,
> | autoreconf-dickey -f -i -v
> | autoreconf-dickey: using autoconf 2.52.20230114: /usr/bin//autoconf-dickey
> | autoreconf-dickey: using autoheader 2.52.20230114: 
> /usr/bin//autoheader-dickey
> | autoreconf-dickey: using automake 1.16.5: automake
> | autoreconf-dickey: using aclocal 1.16.5: aclocal
> | autoreconf-dickey: running aclocal --verbose --output=./aclocal.m4 in 
> .pc/fix-configure-root-args-option.diff
> | aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> | aclocal: found macro AC_PATH_XTRA in configure.in: 45
> `
> 
> So autoreconf-dickey picks up the backup of configure.in below the .pc/
> directory and runs aclocal.  As there is no aclocal.m4 in that
> directory, the above warning and error about AM_LANGINFO_CODESET ensue,
> answering the second question.  That still leaves the first one open,
> though.

yes - I expect that something in the externals has changed.

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


signature.asc
Description: PGP signature

Bug#1034549: libncurses-dev: ships header files that can't be compiled (ncurses_cfg.h)

[Thomas Dickey]

On Wed, Apr 19, 2023 at 08:20:40PM +0200, Sven Joachim wrote:
> On 2023-04-17 17:09 -0700, Steve Langasek wrote:
> 
> > Package: libncurses-dev
> > Version: 6.4-2
> > Severity: normal
> >
> > The libncurses-dev package ships several header files that can't be
> > compiled, because they depend on ncurses_cfg.h which is not available.
> >
> > $ grep -rl ncurses_cfg /usr/include/
> > /usr/include/tic.h
> > /usr/include/curses.h
> > /usr/include/nc_tparm.h
> > $
> 
> The curses.h file is a false positive, as ncurses_cfg.h is only
> mentioned inside a comment:
> 
> ,
> | $  grep -A2 -B1 ncurses_cfg /usr/include/curses.h
> | /*
> |  * We cannot define these in ncurses_cfg.h, since they require parameters 
> to be
> |  * passed (that is non-portable).
> |  */
> `
> 
> The other two files indeed #include the non-existent ncurses_cfg.h file.
> Perhaps surprisingly, this is actually done on purpose, as mentioned in
> the upstream NEWS file:
> 
> ,
> | 20170722
> | + add dependency upon ncurses_cfg.h to tic's header-files; any program
> |   using tic-library will have to supply this file.  Legacy tack
> |   versions supply this file; ongoing tack development has dropped the
> |   dependency upon tic-library and new releases will not be affected.
> `

yes... before I revised it in 2017 -

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

tack used internal entrypoints of ncurses, which I eliminated.
Version 1.07 and earlier do that, and could be built within
ncurses' source-tree (to get at those headers).  The current
versions of tack use only term_entry.h, which is needed to
provide its editable-terminfo feature.

While repology lists some older versions, I don't see a need to continue
the support for those.

https://repology.org/project/tack/versions

Those headers would be needed if there were some application using "ticlib",
but that doesn't build if we have ncurses+tinfo, so there aren't any users.

> Supplying an empty ncurses_cfg.h file might be sufficient for your
> purposes, but I don't know what these are.

It would supply values for the #if statements:

tic.h

#if NCURSES_EXT_COLORS && HAVE_INIT_EXTENDED_COLOR
#if HAVE_LONG_FILE_NAMES
#ifdef TRACE
#ifndef TERMINFO
#ifdef NCURSES_INTERNALS
#if BROKEN_LINKER

nc_tparm.h

#ifndef NC_TPARM_included
#ifndef TPARM_ARG
#ifdef NCURSES_TPARM_ARG
#if NCURSES_TPARM_VARARGS
#ifdef NCURSES_INTERNALS

term_entry.h has a few (and tack's configure-script sets them as needed):

#ifdef NCURSES_INTERNALS
#if NCURSES_USE_DATABASE
#if NCURSES_USE_TERMCAP
#if NCURSES_XNAMES

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


signature.asc
Description: PGP signature

Bug#1034372: ncurses: CVE-2023-29491

[Thomas Dickey]

On Sat, Apr 15, 2023 at 07:27:45AM -0400, Thomas Dickey wrote:
> On Sat, Apr 15, 2023 at 09:05:25AM +0200, Sven Joachim wrote:
> > On 2023-04-13 20:39 +0200, Moritz Mühlenhoff wrote:
> > 
> > > The following vulnerability was published for ncurses.
> > >
> > > CVE-2023-29491 was assigned to 
> > > https://invisible-island.net/ncurses/NEWS.html#index-t20230408
> > >
> > > If you fix the vulnerability please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > >
> > > For further information see:
> > >
> > > [0] https://security-tracker.debian.org/tracker/CVE-2023-29491
> > > https://www.cve.org/CVERecord?id=CVE-2023-29491
> > 
> > Security boundaries are only crossed for setuid/setgid programs here,
> > and we probably do not have many setuid binaries linked to libtinfo in
> > the distribution (on my system, I could not find any).  So I guess you
> > probably do not want to issue a DSA here, right?
> > 
> > Gentoo users have noticed a few problems after upgrading to the 20230408
> > patchlevel[1,2,3], most notably output of openrc being completely
> > broken.  While we do not have that particular problem because openrc in
> 
> It was already broken (the "(null)" strings come from its misuse of the
> ncurses interface, which will require fixes in OpenRC).  I'm not going
> to provide a patch for OpenRC itself - any maintainer should be able to
> do _that_.
> 
> Today I'll put out the fix for zero-parameter tsl, along with similar minor
> improvements, and if nothing else surfaces, use that as the basis for the
> security-patch.

I had another fix, which works fine.  Except of course for programs which
call tparm without actually reading from the terminal database, and don't
check error returns.  I could digress...

...reflecting on all of this, the low-impact change would be to use the
--disable-root-environ configure option (possibly --disable-root-access
as well).

By the way, the issues that I've been addressing exist in other
implementations.  Have a nice day.

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


signature.asc
Description: PGP signature

Bug#1034372: ncurses: CVE-2023-29491

[Thomas Dickey]

On Sat, Apr 15, 2023 at 09:05:25AM +0200, Sven Joachim wrote:
> On 2023-04-13 20:39 +0200, Moritz Mühlenhoff wrote:
> 
> > The following vulnerability was published for ncurses.
> >
> > CVE-2023-29491 was assigned to 
> > https://invisible-island.net/ncurses/NEWS.html#index-t20230408
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> >
> > For further information see:
> >
> > [0] https://security-tracker.debian.org/tracker/CVE-2023-29491
> > https://www.cve.org/CVERecord?id=CVE-2023-29491
> 
> Security boundaries are only crossed for setuid/setgid programs here,
> and we probably do not have many setuid binaries linked to libtinfo in
> the distribution (on my system, I could not find any).  So I guess you
> probably do not want to issue a DSA here, right?
> 
> Gentoo users have noticed a few problems after upgrading to the 20230408
> patchlevel[1,2,3], most notably output of openrc being completely
> broken.  While we do not have that particular problem because openrc in

It was already broken (the "(null)" strings come from its misuse of the
ncurses interface, which will require fixes in OpenRC).  I'm not going
to provide a patch for OpenRC itself - any maintainer should be able to
do _that_.

Today I'll put out the fix for zero-parameter tsl, along with similar minor
improvements, and if nothing else surfaces, use that as the basis for the
security-patch.

> Debian is built without ncurses support, I do not currently have an idea
> which other packages might show misbehavior.  So I am rather reluctant
> to fix this bug before the bookworm release.

Actually, the discussion there should be based on what the disclosure covers.
I'm addressing their concerns as well as I'm able.
 
> Cheers,
>Sven
> 
> 
> 1. https://bugs.gentoo.org/904247
> 2. https://bugs.gentoo.org/904263
> 3. https://bugs.gentoo.org/904277
> 

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


signature.asc
Description: PGP signature

Bug#1033423: lynx: Status line stuck on "HTTP/1.1 200 OK", body not rendered, no input accepted when receiving a specifically-formatted response

[Thomas Dickey]

On Fri, Mar 24, 2023 at 08:36:26PM +0100, наб wrote:
> Package: lynx
> Version: 2.9.0dev.6-3~deb11u1
> Version: 2.9.0dev.12-1
> Severity: normal
...
> I get the same thing when I run
>   echo 
> 485454502F312E3120323030204F4B0D0A436F6E74656E742D547970653A20746578742F68746D6C0D0A5472616E736665722D456E636F64696E673A206368756E6B65640D0A0D0A33350D0A3C6D65746120636861727365743D7574662D383E3C7469746C653E657370333270736B6F3C2F7469746C653E43757272656E743A200D0A340D0A444F574E0D0A34330D0A3C6272202F3E3C666F726D206D6574686F643D706F73743E3C6C6162656C3E4E65773A203C696E70757420747970653D636865636B626F78206E616D653D76616C75650D0A32640D0A3E3C2F6C6162656C3E3C696E70757420747970653D7375626D69742076616C75653D5365743E3C2F666F726D3E0D0A300D0A0D0A
>  | base16 -d | nc -lp 8000
> and open localhost:8000, for a cheaper repro.

thanks - I can reproduce this case (trace shows it reads the whole file)

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


signature.asc
Description: PGP signature

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

[Thomas Dickey]

- Original Message -
| From: "Brendan O'Dea" 
| To: "Helmut Grohne" , 1032...@bugs.debian.org
| Sent: Friday, March 10, 2023 4:24:40 PM
| Subject: Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf 
test

| tags 1032651 unreproducible
| thanks
| 
| On Fri, Mar 10, 2023 at 12:24:26PM +0100, Helmut Grohne wrote:
|>Source: vile
|>Version: 9.8y-2
|>
|>vile fails to cross build from source, because the cross-compilation
|>specific test contains a syntax error. This will become obvious once
|>looking at the attached patch. Thus it fails to define GETPRGP_VOID and
|>that produces a compilation error later.
| 
| This was fixed in 9.8y-2 (closing #1029956).
| 
| I can't reproduce with the source packages:
| 
|  % apt-get source vile
|  [...]
|  Get:1 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (dsc) 
[2,034
|  B]
|  Get:2 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (tar) 
[1,735
|  kB]
|  Get:3 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (diff) 
[10.3
|  kB]
|  [...]
|  % cd vile-9.8y
|  % fgrep -c \$ac_includes_default aclocal.m4
|  15
|  % fgrep -c \#ac_includes_default aclocal.m4
|  0
| 
| See also:
| 
|  
https://salsa.debian.org/debian/vile/-/commit/f57788a3b30cfb3d860bd31a01ce57fc43b9c0e6

https://github.com/ThomasDickey/vile-snapshots/commit/6a620881ed41acac88eb22b14de392eba8f84993


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

Bug#1022006: Acknowledgement (New version fixes a warning)

[Thomas Dickey]

- Original Message -
| From: "Bjarni Ingi Gislason" 
| To: 1022...@bugs.debian.org
| Cc: "Bjarni Ingi Gislason" 
| Sent: Sunday, March 5, 2023 4:24:44 PM
| Subject: Bug#1022006: Acknowledgement (New version fixes a warning)

| The new version did not fix the observed behaviour.

For the given bug-report, I don't recall any relevant changes.

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

Bug#239205: Processed: refile under reset

[Thomas Dickey]

On Wed, Jan 25, 2023 at 07:02:45PM +0100, Sven Joachim wrote:
> Going through some old bug reports…
> 
> On 2004-05-31 20:04 -0400, Thomas Dickey wrote:
> 
> > On Mon, 31 May 2004, Daniel Jacobowitz wrote:
> >
> >> Are there really no other terminals which have a capability string to
> >> enter or exit UTF-8 mode?  I suppose for xterm, you have to start it in
> >> UTF-8 mode or not.  So maybe the Linux terminal really is unique in
> >> this respect.
> >
> > xterm can enter/exit via escape sequence, but a reset doesn't change the
> > UTF-8 mode.
> 
> Which would be rather undesirable anyway, at least in my opinion.
> 
> It also seems that the kernel's behavior (switching out of UTF-8 mode
> when it receives a reset sequence) which caused the initial complaint
> has changed, probably many years ago.
> 
> At least I am unable to reproduce the problem here with a 5.10 kernel
> and am inclined to just close the bug.

It was fixed in 2007 (as a side-effect of a configuration parameter that
was removed).  See the "default_utf8" variable and reset_terminal() in

https://github.com/torvalds/linux/commit/2e8ecb9db0bcc19e1cc8bb51e9252fe6a86a9863

https://github.com/torvalds/linux/commit/77bf2bab91e4e7df361963451c7b9a803516438c

Before that change, it was not initialized (and false), so a \Ec would
revert it to Latin-1.

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


signature.asc
Description: PGP signature

Bug#1029956: vile FTCBFS: broken getpgrp check

[Thomas Dickey]

On Sun, Jan 29, 2023 at 06:35:11AM +0100, Helmut Grohne wrote:
> Source: vile
> Version: 9.8y-1
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> vile used to cross build until 9.8x-1. Now it fails. The reasons are not
> entirely clear to me. Here is what I know:
> 
> 1. It checks for setpgrp and getpgrp and these tests turn out to be
>successful in all cases.
> 2. When cross compiling, it avoids AC_FUNC_SETPGRP and AC_FUNC_GETPGRP
>even though these macros work fine with cross compiling today.
> 3. For some reason, SETPGRP_VOID and GETPGRP_VOID end up not getting
>defined during cross compilation. configure isn't very verbose about
>why.
> 4. If you delete the extra code that tries to support cross building, it
>just works.
> 
> As such, I recommend skipping deeper investigation and rather deleting

hmm...

> the evidently broken cross compilation support code. Do note that you
> must regenerate configure before upload or enable autoreconf to apply
> this change. I'm attaching the bare configure.in patch for your
> convenience.
> 
> Helmut

> --- vile-9.8y.orig/aclocal.m4
> +++ vile-9.8y/aclocal.m4
> @@ -2932,35 +2932,9 @@
>  dnl messes up the messages...
>  define([CF_KILLPG],
>  [
> -if test "$cross_compiling" = yes ; then
> - AC_CHECK_FUNC(setpgrp,[
> - AC_TRY_COMPILE([
> -#ifdef HAVE_UNISTD_H
> -#include 
> -#endif
> -#include 
> -#include 
> -],[
> -(void) setpgrp();
> -],
> - [AC_DEFINE(SETPGRP_VOID)])])
> -else
>   AC_FUNC_SETPGRP
> -fi
>  
> -if test "$cross_compiling" = yes ; then
> - AC_CHECK_FUNC(getpgrp,[
> - AC_TRY_COMPILE([
> -#ac_includes_default

actually this line is the problem (I made this typo in another
place, and corrected it, but overlooked this occurrence).

The "#" should be "$".  In a quick grep, I've 50 uses of $ac_includes_default,
with this as the only (current) typo.

If there are further issues, the usual approach for reporting bugs is to
include the config.log and config.status to demonstrate the issue.

https://invisible-island.net/personal/bug-reports.html

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


signature.asc
Description: PGP signature

Bug#60377: "reset" broken for dumb terminals

[Thomas Dickey]

On Mon, Jan 23, 2023 at 04:45:02PM -0800, Ben Wong wrote:
> On Sat, Jan 21, 2023 at 08:55:26AM +0100, Sven Joachim wrote:
> > It does not happen very often that somebody replies to an over 20 years
> > old bug, and this seems to have escaped both my and upstream's
> > attention.
> 
> Thank you, Sven. I realize this is unusual and I hope you do not mind. As a
> user, I greatly appreciate that Debian took a "universal" view of this bug
> and did not close it for simply being "old", as so many commercial products
> do.
> 
> 
> On Sat, 21 Jan 2023 17:18:18 -0500, Thomas Dickey wrote:
> > Given the size of the patch, it's going to take some time to investigate.
> > - Most of the items in question date back to the mid-1990s.
> 
> I do apologize for the large patch. It is mostly due to removing all the
> undocumented settings.
> 
> I tried to find the point in time when the code diverged from the
> documentation to see if any reasoning was given, but had no success. I did,
> however, manage to figure out why those particular termios options were
> chosen: it looks like it was an attempt to set _everything._ The Linux
> manpage for termios(3),
> https://manpages.debian.org/sid/manpages-dev/termios.3.en.html, contains
> the same list in the same order, albeit with a few newer additions. That's
> not to say that `reset` was based on the Linux manpage, as they both could

The Linux manpage would have been based on some version of the ncurses manpage.
(Very few "Linux manpages" are original work, none related to anything I do).

> have been derived from some other source. It merely indicates that the
> purpose of the code was to be exhaustive.
> 
> > - There's also the consideration of compatbility with other systems.
> 
> A good question. If such a compatibility issue does turn up, I suggest
> that, at a baseline, the code ought to agree with the documentation. If
> compatibility problems are minor, it might be possible to accept that this
> change would break systems that (unwisely) relied on undocumented features.
> On the other hand, if the code cannot change, then the documentation must.
> Unfortunately, that looks to be more of a chore as every option that is
> kept in the code would need documentation of how reset will change it and
> (ideally) why.

sure - that's why it'll take some time (some may change, some may not)

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


signature.asc
Description: PGP signature

Bug#60377: "reset" broken for dumb terminals

[Thomas Dickey]

On Sat, Jan 21, 2023 at 08:55:26AM +0100, Sven Joachim wrote:
> It does not happen very often that somebody replies to an over 20 years
> old bug, and this seems to have escaped both my and upstream's
> attention.  Thomas, could you please have a look?

I've started looking.

Given the size of the patch, it's going to take some time to investigate.

- Most of the items in question date back to the mid-1990s.

- There's also the consideration of compatbility with other systems.

fwiw, here's a slice from tset.c in ncurses 4.2:

0.1  (tom  17-Sep-95): /*
0.1  (tom  17-Sep-95):  * Reset the terminal mode bits to a 
sensible state.  Very useful after
0.1  (tom  17-Sep-95):  * a child program dies in raw mode.
0.1  (tom  17-Sep-95):  */
0.1  (tom  17-Sep-95): static void
0.1  (tom  17-Sep-95): reset_mode(void)
0.1  (tom  17-Sep-95): {
0.5  (tom  30-Nov-95): #ifdef TERMIOS
0.1  (tom  17-Sep-95):  tcgetattr(STDERR_FILENO, );
0.5  (tom  30-Nov-95): #else
0.15 (tom  20-Aug-96):  stty(STDERR_FILENO,);
0.5  (tom  30-Nov-95): #endif
0.1  (tom  17-Sep-95): 
0.5  (tom  30-Nov-95): #ifdef TERMIOS
0.1  (tom  17-Sep-95): #if defined(VDISCARD) && defined(CDISCARD)
0.1  (tom  17-Sep-95):  mode.c_cc[VDISCARD] = 
CHK(mode.c_cc[VDISCARD], CDISCARD);
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95):  mode.c_cc[VEOF] = CHK(mode.c_cc[VEOF], 
CEOF);
0.1  (tom  17-Sep-95):  mode.c_cc[VERASE] = 
CHK(mode.c_cc[VERASE], CERASE);
0.1  (tom  17-Sep-95): #if defined(VFLUSH) && defined(CFLUSH)
0.1  (tom  17-Sep-95):  mode.c_cc[VFLUSH] = 
CHK(mode.c_cc[VFLUSH], CFLUSH);
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95):  mode.c_cc[VINTR] = 
CHK(mode.c_cc[VINTR], CINTR);
0.1  (tom  17-Sep-95):  mode.c_cc[VKILL] = 
CHK(mode.c_cc[VKILL], CKILL);
0.1  (tom  17-Sep-95): #if defined(VLNEXT) && defined(CLNEXT)
0.1  (tom  17-Sep-95):  mode.c_cc[VLNEXT] = 
CHK(mode.c_cc[VLNEXT], CLNEXT);
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95):  mode.c_cc[VQUIT] = 
CHK(mode.c_cc[VQUIT], CQUIT);
0.1  (tom  17-Sep-95): #if defined(VREPRINT) && defined(CRPRNT)
0.1  (tom  17-Sep-95):  mode.c_cc[VREPRINT] = 
CHK(mode.c_cc[VREPRINT], CRPRNT);
0.1  (tom  17-Sep-95): #endif
0.13 (tom  25-May-96): #if defined(VSTART) && defined(CSTART)
0.1  (tom  17-Sep-95):  mode.c_cc[VSTART] = 
CHK(mode.c_cc[VSTART], CSTART);
0.13 (tom  25-May-96): #endif
0.13 (tom  25-May-96): #if defined(VSTOP) && defined(CSTOP)
0.1  (tom  17-Sep-95):  mode.c_cc[VSTOP] = 
CHK(mode.c_cc[VSTOP], CSTOP);
0.13 (tom  25-May-96): #endif
0.13 (tom  25-May-96): #if defined(VSUSP) && defined(CSUSP)
0.1  (tom  17-Sep-95):  mode.c_cc[VSUSP] = 
CHK(mode.c_cc[VSUSP], CSUSP);
0.13 (tom  25-May-96): #endif
0.1  (tom  17-Sep-95): #if defined(VWERASE) && defined(CWERASE)
0.1  (tom  17-Sep-95):  mode.c_cc[VWERASE] = 
CHK(mode.c_cc[VWERASE], CWERASE);
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95): 
0.1  (tom  17-Sep-95):  mode.c_iflag &= ~(IGNBRK | PARMRK | 
INPCK | ISTRIP | INLCR | IGNCR
0.1  (tom  17-Sep-95): #ifdef IUCLC
0.1  (tom  17-Sep-95):| IUCLC
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95): #ifdef IXANY
0.1  (tom  17-Sep-95):| IXANY
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95):| IXOFF);
0.1  (tom  17-Sep-95): 
0.1  (tom  17-Sep-95):  mode.c_iflag |= (BRKINT | IGNPAR | 
ICRNL | IXON
0.1  (tom  17-Sep-95): #ifdef IMAXBEL
0.1  (tom  17-Sep-95):   | IMAXBEL
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95):   );
0.1  (tom  17-Sep-95): 
0.1  (tom  17-Sep-95):  mode.c_oflag &= ~(0
0.1  (tom  17-Sep-95): #ifdef OLCUC
0.1  (tom  17-Sep-95):| OLCUC
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95): #ifdef OCRNL
0.1  (tom  17-Sep-95):| OCRNL
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95): #ifdef ONOCR
0.1  (tom  17-Sep-95):| ONOCR
0.1  (tom  17-Sep-95): #endif
0.1  (tom  17-Sep-95): #ifdef ONLRET
0.1  (tom  17-Sep-95):| ONLRET
0.1  (tom  17-Sep-95): #endif

Bug#1029118: Possible typo in "#if !(defined(yylex) ..."

[Thomas Dickey]

On Wed, Jan 18, 2023 at 12:45:50AM +, Bjarni Ingi Gislason wrote:
> Package: byacc
> Version: byacc - 2.0 20221229
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>   Compiling groff

(in a quick check, I compiled the version from 2022/12/28
on my Debian/oldstable without seeing this problem - but I see
the issue is compiler options).
 
> 
> 
> output.c:   putl_code(fp, "#if !(defined(yylex) || defined(YYSTATE))\n");
> 
>   "yylex" is a name of a function but "#... defined(...)" applies to
> macros not functions(?).

That's intentional (not a bug).  It's done to allow changing the function
signature -- but not if there's already a macro to confuse things.

Here's more context:

/* Parameters sent to lex. */
#ifdef YYLEX_PARAM
# define YYLEX_DECL() yylex(void *YYLEX_PARAM)
# define YYLEX yylex(YYLEX_PARAM)
#else
# define YYLEX_DECL() yylex(void)
# define YYLEX yylex()
#endif

#if !(defined(yylex) || defined(YYSTATE))
int YYLEX_DECL();
#endif

Changing that YYSTATE to YYLEX will turn off the declaration.

YYSTATE is a lex symbol (#define'd), so it seemed a better choice than
the flex-specific FLEX_SCANNER symbol which Guy Harris used in the first
version of this ifdef.

The intent here is to not use the declaration if the lex/flex code is
inserted before that point (reducing redefinition problems).

> 
> 
>   When compiling, a warning is issued:
> 
>   CXX  src/preproc/eqn/eqn-eqn.o
> src/preproc/eqn/eqn.cpp:73:23: warning: redundant redeclaration of 'int
> yylex()' in same scope [-Wredundant-decls]
>73 | # define YYLEX_DECL() yylex(void)
>   |   ^

yes - that's a problem.  There's been no universally-guaranteed prototype
for yylex, so applications add one.  (There was some update on the Austin
review a couple of years ago, but the recommendation from that would run
into the same problem -- and it introduced other problems).

For this case, I could add a third symbol, which would "only" be set by
the caller (not a lex/flex symbol that one might trip over).

> src/preproc/eqn/eqn.cpp:78:5: note: in expansion of macro 'YYLEX_DECL'
>78 | int YYLEX_DECL();
>   | ^~
> ../src/preproc/eqn/eqn.ypp:31:5: note: previous declaration of 'int
> yylex()'
>31 | int yylex(void);
>   | ^
>   CXXLDeqn
> 
> 
> 
>   When I change "yylex" to "YYLEX" in the "putl_code(...)" line there
> is no warning.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.12-1 (SMP w/2 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
> LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages byacc depends on:
> ii  libc6  2.36-8
> 
> byacc recommends no packages.
> 
> byacc suggests no packages.

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


signature.asc
Description: PGP signature

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Thomas Dickey]

- Original Message -
| From: "Santiago Vila" 
| To: "Thomas Dickey" , 1012...@bugs.debian.org
| Cc: "Sven Joachim" 
| Sent: Thursday, January 5, 2023 7:09:22 PM
| Subject: Bug#1012325: dialog: Multi-Arch: foreign package should not contain 
static library

| El 6/1/23 a las 0:39, Thomas Dickey escribió:
|> On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote:
|>> In Debian the static library has always been named libdialog.a,
|>> but the library according to the author is called libcdialog.so.
|> 
|> A development package could have both static and dynamic libraries.
|> dialog can build either, but not both at the same time (just like ncurses).
| 
| Ok, I didn't know, but the thing which I'm worried about is
| really libdialog vs libcdialog, not ".a" vs ".so".

I name my Dialog package with a "c" to allow me to have
both the Debian and my test-package installed without conflict.

(I do this for most of my test-packages, because it's otherwise awkward to
respond to bug-reports)

My comment about the layout was in more general terms,
to show how it might be reorganized to provide the development library.

| (sorry for mixing both things)
| 
| To be more precise: Are there any applications in the wild linked
| against libcdialog.so which would not run in a Debian system
| if I decide to provide libdialog.so in the Debian package?

very few people (aside from me) use my test-packages :-)

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

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Thomas Dickey]

On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote:
> Thanks a lot for the patch.
> 
> Yes, it would make sense to move *.h and .a to a libdialog-dev package.
> 
> But I'm not sure about the best way to proceed after reading the reply from 
> Thomas:
> 
> > actually, a shared library is generally preferred for development packages.
> > This is what I build for my own use (scripts in the package/debian 
> > directory),
> > as "cdialog-dev":
> > 
> > /usr/bin/cdialog-config*
> > /usr/include/cdialog/dlg_colors.h
> > /usr/include/cdialog/dlg_config.h
> > /usr/include/cdialog/dlg_keys.h
> > /usr/include/cdialog.h
> > /usr/share/doc/cdialog-dev/changelog.Debian.gz
> > /usr/share/doc/cdialog-dev/changelog.gz
> > /usr/share/doc/cdialog-dev/copyright
> > /usr/share/man/man3/cdialog.3.gz
> > /lib/x86_64-linux-gnu/libcdialog.so@
> 
> In Debian the static library has always been named libdialog.a,
> but the library according to the author is called libcdialog.so.

A development package could have both static and dynamic libraries.
dialog can build either, but not both at the same time (just like ncurses).
 
> If I go ahead and create a shared library package (which I suspect is
> the only thing ftpmasters will accept if they see NEW binary packages),
> should I worry about binary compatibility with other distros?
> 
> Thanks.
> 

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


signature.asc
Description: PGP signature

Bug#1027435: ncurses-base: Breaks pasting in vim within tmux

[Thomas Dickey]

On Sat, Dec 31, 2022 at 02:18:49PM +0100, Antoine Le Gonidec wrote:
> Package: ncurses-base
> Version: 6.3+20221224-2
> Severity: important

that's probably this - which will be in today's update/release:

--- ncurses-6.3-20221224+/misc/terminfo.src 2022-12-24 18:18:58.0 
+
+++ ncurses-6.4-20221231/misc/terminfo.src  2022-12-29 20:11:56.0 
+
@@ -6,8 +6,8 @@
 # Report bugs and new terminal descriptions to
 #  bug-ncur...@gnu.org
 #
-#  $Revision: 1.1039 $
-#  $Date: 2022/12/24 18:18:58 $
+#  $Revision: 1.1041 $
+#  $Date: 2022/12/29 20:11:56 $
 #
 # The original header is preserved below for reference.  It is noted that there
 # is a "newer" version which differs in some cosmetic details (but actually
@@ -5768,7 +5768,7 @@
 # detail.  The names for the extended capabilities here were introduced by vim
 # in January 2017.
 bracketed+paste|xterm bracketed paste,
-   BD=\E[?2004l, BE=\E[?2004h, PD=\E[201~, PE=\E[200~,
+   BD=\E[?2004l, BE=\E[?2004h, PE=\E[201~, PS=\E[200~,
 
  XTERM Mouse
 # The xterm mouse protocol is used by other terminal emulators.
@@ -8210,7 +8210,7 @@
use=screen4,
 
 no+brackets|cancel bracketed paste,
-   BD@, BE@, PD@, PE@,
+   BD@, BE@, PE@, PS@,
 
 # The bce and status-line entries are from screen 3.9.13 (and require some
 # changes to .screenrc).
@@ -25508,8 +25508,8 @@
 #
 # BE enables bracketed paste
 # BD disables bracketed paste
-# PE is sent before the pasted text
-# PD is sent after the pasted text
+# PS is sent before the pasted text
+# PE is sent after the pasted text
 #
 # Here are the other xterm-related extensions which are used in this file:
 #
@@ -27713,4 +27713,8 @@
 #  + add/use bracketed+paste to help identify terminals supporting this
 #xterm feature (prompted by discussion with Bram Moolenaar) -TD
 #
+# 2022-12-29
+#  + correct PS vs PE names in bracketed+paste (report by Bram Moolenaar)
+#-TD
+#
  SHANTIH!  SHANTIH!  SHANTIH!

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


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Wed, Nov 16, 2022 at 04:02:18AM -0500, Thomas Dickey wrote:
> On Wed, Nov 16, 2022 at 09:50:36AM +0100, Andreas Tille wrote:
> > Control: severity -1 minor
...
> > After restarting X xterm is starting properly now.  It somehow seems
> > that the mkfontdir call changed the game.  Unfortunately we do not
> > really know what might have caused the issue.  As I said I would also
> > have loved if xterm would not have crashed.
> 
> agreed (I did try reproducing the crash for the case where the font
> was missing, but so far unsuccessful).

never mind - I see the problem now (was thinking that it occurred when
the font _was_ installed).  Will upload #376 in the early morning.

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


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Wed, Nov 16, 2022 at 09:50:36AM +0100, Andreas Tille wrote:
> Control: severity -1 minor
> 
> Hi Thomas,
> 
> at first thanks a lot for your patience.
> 
> Am Tue, Nov 15, 2022 at 08:10:18PM -0500 schrieb Thomas Dickey:
> > On Tue, Nov 15, 2022 at 09:15:43AM +0100, Andreas Tille wrote:
> > > Hi again,
> > > 
> > > I need to admit that the issue "vanished" on my workhorse laptop which is
> > > nice on one hand but having an explanation would be even nicer. ;-)
> > > I've now tried the other laptop with the same problem:
> > > 
> > > $ dpkg --get-selections | grep terminus
> > > fonts-terminusinstall
> > > $ xlsfonts | grep terminus
> > 
> > That might be one of these possibilities:
> > 
> > a) the X configuration (seen with "xset -q") has something amiss with
> >the fontpath (see attached example from my Debian/testing).
> 
> There was no attachment but here is mine:

sorry - will do that, for the record
 
> $ xset -q
> Keyboard Control:
>   auto repeat:  onkey click percent:  0LED mask:  
>   XKB indicators:
> 00: Caps Lock:   off01: Num Lock:off02: Scroll Lock: off
> 03: Compose: off04: Kana:off05: Sleep:   off
> 06: Suspend: off07: Mute:off08: Misc:off
> 09: Mail:off10: Charging:off11: Shift Lock:  off
> 12: Group 2: off13: Mouse Keys:  off
>   auto repeat delay:  400repeat rate:  20
>   auto repeating keys:  00ffdbbf
> fedfffefffed
> 9fff
> fff7
>   bell percent:  50bell pitch:  400bell duration:  100
> Pointer Control:
>   acceleration:  2/1threshold:  4
> Screen Saver:
>   prefer blanking:  yesallow exposures:  yes
>   timeout:  180cycle:  600
> Colors:
>   default colormap:  0x20BlackPixel:  0x0WhitePixel:  0xff
> Font Path:
>   
> /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
> DPMS (Energy Star):
>   Standby: 0Suspend: 300Off: 600
>   DPMS is Enabled
>   Monitor is On
> 
>  
> > b) updates to the bitmap font-directories have to be finished using
> >mkfontdir (part of xfonts-utils).  I've seen occasional comments
> >where package updates didn't work as intended.
> > 
> > Either way, "dpkg -L xfonts-terminus" tells me that the relevant files
> > are in
> > 
> > /usr/share/fonts/X11/misc
> > 
> > If xset reports that's in the font path, I'd try (based on the manpage)
> > 
> > sudo mkfontdir /usr/share/fonts/X11/misc
> 
> Done.
>  
> > or (by habit, since long ago it ignored the parameter...)
> > 
> > cd /usr/share/fonts/X11/misc
> > sudo mkfontdir
> > 
> > and restart X.
> 
> After restarting X xterm is starting properly now.  It somehow seems
> that the mkfontdir call changed the game.  Unfortunately we do not
> really know what might have caused the issue.  As I said I would also
> have loved if xterm would not have crashed.

agreed (I did try reproducing the crash for the case where the font
was missing, but so far unsuccessful).
 
> In any case I consider the severity of the bug as lower now and have
> set it to minor.  I'll leave it to your decision whether you consider
> it closed or some helpful resource to find a way to avoid the issue.
> 
> Kind regards and thanks again for your help
>Andreas.
> 
> -- 
> http://fam-tille.de
> 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Keyboard Control:
  auto repeat:  onkey click percent:  0LED mask:  0002
  XKB indicators:
00: Caps Lock:   off01: Num Lock:on 02: Scroll Lock: off
03: Compose: off04: Kana:off05: Sleep:   off
06: Suspend: off07: Mute:off08: Misc:off
09: Mail:off10: Charging:off11: Shift Lock:  off
12: Group 2: off13: Mouse Keys:  off
  auto repeat delay:  500repeat rate:  20
  auto repeating keys:  00ffdbbf
fadfffefffed
9fff
fff7
  bell percent:  50bell pitch:  400bell duration:  100
Pointer Control:
  acceleration:  2/1threshold:  4
Screen Saver:
  prefer blanking:  yesallow exposures:  yes
  timeout:  600cycle:  600
Colors:
  default colormap:  0x20BlackPixel:  0x0WhitePixel:  0xff
Font Path:
  
/usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
DPMS (Energy Star):
  Standby: 600Suspend: 0Off: 900
  DPMS is Enabled
  Monitor is On


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 15, 2022 at 09:15:43AM +0100, Andreas Tille wrote:
> Hi again,
> 
> I need to admit that the issue "vanished" on my workhorse laptop which is
> nice on one hand but having an explanation would be even nicer. ;-)
> I've now tried the other laptop with the same problem:
> 
> $ dpkg --get-selections | grep terminus
> fonts-terminusinstall
> $ xlsfonts | grep terminus

That might be one of these possibilities:

a) the X configuration (seen with "xset -q") has something amiss with
   the fontpath (see attached example from my Debian/testing).

b) updates to the bitmap font-directories have to be finished using
   mkfontdir (part of xfonts-utils).  I've seen occasional comments
   where package updates didn't work as intended.

Either way, "dpkg -L xfonts-terminus" tells me that the relevant files
are in

/usr/share/fonts/X11/misc

If xset reports that's in the font path, I'd try (based on the manpage)

sudo mkfontdir /usr/share/fonts/X11/misc

or (by habit, since long ago it ignored the parameter...)

cd /usr/share/fonts/X11/misc
sudo mkfontdir

and restart X.

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


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Mon, Nov 14, 2022 at 06:21:50PM +0100, Andreas Tille wrote:
> Am Mon, Nov 14, 2022 at 04:27:30AM -0500 schrieb Thomas Dickey:
> > > Since xterm is crashing before this does not report anything
> > > interesting.
> > 
> > hmm - it's not showing much.
> > 
> > What does xfd do with that pattern?  (using single quotes):
> > 
> > xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'
> > 
> > If you don't have that installed, it's part of x11-utils: /usr/bin/xfd
> > 
> > (reinstalling the font might be helpful)
> 
> OK
> 
> ~$ sudo apt install fonts-terminus
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Die folgenden NEUEN Pakete werden installiert:
>   fonts-terminus
> 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
> Es müssen 81,0 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 464 kB Plattenplatz zusätzlich benutzt.
> Holen:1 http://deb.debian.org/debian testing/main amd64 fonts-terminus amd64 
> 1.2.0+ds-7 [81,0 kB]
> Es wurden 81,0 kB in 0 s geholt (596 kB/s).
> Vormals nicht ausgewähltes Paket fonts-terminus wird gewählt.
> (Lese Datenbank ... 417804 Dateien und Verzeichnisse sind derzeit 
> installiert.)
> Vorbereitung zum Entpacken von .../fonts-terminus_1.2.0+ds-7_amd64.deb ...
> Entpacken von fonts-terminus (1.2.0+ds-7) ...
> fonts-terminus (1.2.0+ds-7) wird eingerichtet ...
> Trigger für fontconfig (2.13.1-4.5) werden verarbeitet ...
> ~$ xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'
> Warning: Cannot convert string "-*-terminus-*-*-*-32-*-*-*-*-*-*-*" to type 
> FontStruct
> xfd:  no font to display

That's (sort of) promising - it tells me that it's not a bug in _xterm_.

xterm and xfd use the same font-related libraries.

It could still be a configuration problem -- I seem to recall seeing
cases where mkfontdir wasn't run on font updates.  xlsfonts should
show the terminus fonts in its (usually long) output.

For instance, on my Debian/oldstable, I get 494 lines from

xlsfonts | grep terminus

(including an alias "terminus-32").  xlsfonts doesn't use any of those
font-related libraries, talks directly to the X server.

The Xlib calls that xterm uses for bitmap fonts (e.g., Terminus) should use the
same information.

If you were using a TrueType font, xterm and xfd would use the Xft and
fontconfig libraries (the "font-related" libraries that I mentioned).  xterm
and xfd if using "-fa" (rather than "-fn") will ask fontconfig for the font,
and it does know enough to do that, e.g.,

xfd -fa terminus-32
xterm -fa terminus-32

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


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Mon, Nov 14, 2022 at 09:02:22AM +0100, Andreas Tille wrote:
> Am Sun, Nov 13, 2022 at 08:33:09PM -0500 schrieb Thomas Dickey:
> > > LANGUAGE=
> > > LC_CTYPE="de_DE.UTF-8"
> > > LC_NUMERIC="de_DE.UTF-8"
> > > LC_TIME="de_DE.UTF-8"
> > > LC_COLLATE="de_DE.UTF-8"
> > > LC_MONETARY="de_DE.UTF-8"
> > > LC_MESSAGES="de_DE.UTF-8"
> > > LC_PAPER="de_DE.UTF-8"
> > > LC_NAME="de_DE.UTF-8"
> > > LC_ADDRESS="de_DE.UTF-8"
> > > LC_TELEPHONE="de_DE.UTF-8"
> > > LC_MEASUREMENT="de_DE.UTF-8"
> > > LC_IDENTIFICATION="de_DE.UTF-8"
> > > LC_ALL=
> > 
> > I tried that - no change
> 
> I admit I do not think the locale setting is responsible for the issue.
>   
> > > I've made the Geometry that size to fit exactly a quarter of my screen
> > > fitting 4 xterms at one time.  Xfce4 places these intelligently in a
> > > 2x2 matrix.
> > 
> > Something like this will work, but fixing the problem with the menus:
> > 
> > XTerm*VT100.geometry: 111x36
> > 
> > It's in the FAQ:
> > 
> > https://invisible-island.net/xterm/xterm.faq.html#tiny_menus
> 
> Thanks for the hint but I think this was not my main problem. ;-)
>  
> > > I'm using Debian packages exclusively - I have no time to spent
> > > extra fancy things.  BTW. I'm observing the very same bug on my
> > > second laptop I'm using for traveling (but my desktop with the
> > > same setup works without any problem)
> > >  
> > > Could you send me the full command line
> > >"xrdb -load ??"
> > 
> > I pasted the text from earlier mail as "bad.ad" (attached),
> > and loaded it with
> > 
> > xrdb -load bad.ad
> 
> I tried this but it did not changed the problem.
>  
> > > I could check here.  What strace call should I send to track
> > > down the issue.  Please note that while I'm an experienced
> > 
> > I'd just
> > 
> > strace -o trace.log -s 1024 xterm
> > 
> > to capture a long trace (~200kb),
> > and look to see if there's something interesting where xterm dies.
> 
> I've attached my gziped trace.log.
>  
> > I also ran xterm using -report-fonts, which shows the fonts opened.
> 
> Since xterm is crashing before this does not report anything
> interesting.

hmm - it's not showing much.

What does xfd do with that pattern?  (using single quotes):

xfd -fn '-*-terminus-*-*-*-32-*-*-*-*-*-*-*'

If you don't have that installed, it's part of x11-utils: /usr/bin/xfd

(reinstalling the font might be helpful)

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


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Sat, Nov 12, 2022 at 03:17:01PM +0100, Andreas Tille wrote:
> Am Sun, Nov 06, 2022 at 07:55:33PM -0500 schrieb Thomas Dickey:
> > On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> > > Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > > > *VT100.utf8Fonts.font: fixed
> > 
> > what locale settings are you using?
> > 
> > (that might be relevant - or the choice of desktop/window-manager)
> 
> $ locale
> LANG=de_DE.UTF-8
> LANGUAGE=
> LC_CTYPE="de_DE.UTF-8"
> LC_NUMERIC="de_DE.UTF-8"
> LC_TIME="de_DE.UTF-8"
> LC_COLLATE="de_DE.UTF-8"
> LC_MONETARY="de_DE.UTF-8"
> LC_MESSAGES="de_DE.UTF-8"
> LC_PAPER="de_DE.UTF-8"
> LC_NAME="de_DE.UTF-8"
> LC_ADDRESS="de_DE.UTF-8"
> LC_TELEPHONE="de_DE.UTF-8"
> LC_MEASUREMENT="de_DE.UTF-8"
> LC_IDENTIFICATION="de_DE.UTF-8"
> LC_ALL=

I tried that - no change
 
> Desktop environment is xfce4.
>  
> > > Sorry its "comment".
> > > 
> > > > > (the grep seems to indicate that the latter is meant)
> > > > > 
> > > > > > crash with segmentation fault when not finding some specified font.
> > 
> > I suppose the problem is something along the lines of the X server
> > returning some error in using the fonts.  If it were TrueType fonts,
> > I'd use strace to verify that they're opened -- but for bitmap
> > fonts, that's done on the server side.
> 
> I admit I'm fine with any nicely readable font.  I once considered the
> terminus fonts to fit this requirement and never found any reason
> to change this.
>  
> > > The crash happens for
> > > 
> > > $ xrdb -query
> > > *VT100.utf8Fonts.font:  fixed
> > > XTermVT100.faceSize:22
> > > XTerm*geometry: 111x36
> > 
> > hmm - I'm still not seeing _this_ problem.
> > (by the way, the geometry resource is over-broad, making the font-menu
> > less than useful).
> 
> I've made the Geometry that size to fit exactly a quarter of my screen
> fitting 4 xterms at one time.  Xfce4 places these intelligently in a
> 2x2 matrix.

Something like this will work, but fixing the problem with the menus:

XTerm*VT100.geometry: 111x36

It's in the FAQ:

https://invisible-island.net/xterm/xterm.faq.html#tiny_menus

> > I used xcfe4 for testing, on a virtual machine.
> > 
> > My most recent snapshot (from 2022/11/01) didn't work - some problem
> > with X and the window manaager), so I upgraded from 2022/10/29,
> > to get a workable machine.
> > 
> > Given that (I also have the terminus font installed),
> > I used "xrdb -load" with these resources, and ran xterm
> > from the Debian package.  It looks okay to me - no crash.
> 
> I'm using Debian packages exclusively - I have no time to spent
> extra fancy things.  BTW. I'm observing the very same bug on my
> second laptop I'm using for traveling (but my desktop with the
> same setup works without any problem)
>  
> Could you send me the full command line
>"xrdb -load ??"

I pasted the text from earlier mail as "bad.ad" (attached),
and loaded it with

xrdb -load bad.ad

> I could check here.  What strace call should I send to track
> down the issue.  Please note that while I'm an experienced

I'd just

strace -o trace.log -s 1024 xterm

to capture a long trace (~200kb),
and look to see if there's something interesting where xterm dies.

I also ran xterm using -report-fonts, which shows the fonts opened.

> Debian user and long year developer I would not consider myself
> an X expert.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
Loaded VTFonts(font6)
fNorm: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
all chars: no
default char:  63
direction: 0
ascent:26
descent:   6
first char:0
last char: 255
maximum-chars: 256
missing-chars: 37
present-chars: 219
min_byte1: 0
max_byte1: 0
properties:22
min_bounds:
lbearing: 0
rbearing: 0
width:16
ascent:   -1
descent:  -22
max_bounds:
  

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > *VT100.utf8Fonts.font: fixed

what locale settings are you using?

(that might be relevant - or the choice of desktop/window-manager)

> > > > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > > > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > > > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> > 
> > for the record, xfonts-terminus includes all of these sizes.
> > 
> > > > here.  If I uncomment these settings xterm starts.  However, I think 
> > > > xterm should not
> > > 
> > > Is that "uncomment", or "comment"?
> 
> Sorry its "comment".
> 
> > > (the grep seems to indicate that the latter is meant)
> > > 
> > > > crash with segmentation fault when not finding some specified font.

I suppose the problem is something along the lines of the X server
returning some error in using the fonts.  If it were TrueType fonts,
I'd use strace to verify that they're opened -- but for bitmap
fonts, that's done on the server side.

> > > 
> > > agreed -
> > 
> > I've not been able to reproduce the problem, which I suspect is in
> > the error-recovery section of xterm's xtermLoadFont function.
> > 
> > Perhaps seeing the whole set of resources would help
> > (the output of "xrdb -query", too).
> 
> I have:
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> The crash happens for
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36

hmm - I'm still not seeing _this_ problem.
(by the way, the geometry resource is over-broad, making the font-menu
less than useful).

I used xcfe4 for testing, on a virtual machine.

My most recent snapshot (from 2022/11/01) didn't work - some problem
with X and the window manaager), so I upgraded from 2022/10/29,
to get a workable machine.

Given that (I also have the terminus font installed),
I used "xrdb -load" with these resources, and ran xterm
from the Debian package.  It looks okay to me - no crash.

> XTerm.VT100.font1:  -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2:  -*-terminus-*-*-*-18-*-*-*-*-*-*-*
> XTerm.VT100.font3:  -*-terminus-*-*-*-20-*-*-*-*-*-*-*
> XTerm.VT100.font4:  -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5:  -*-terminus-*-*-*-28-*-*-*-*-*-*-*
> XTerm.VT100.font6:  -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> I confirm I have installed xfonts-terminus

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 03:49:52AM -0400, Thomas Dickey wrote:
> On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> > Package: xterm
> > Version: 375-1
> > Severity: important
> > 
> > Hi,
> > 
> > after upgrading from xterm 374-1 to 375-1 I get:
> > 
> > $ xterm
> > xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> > Segmentation fault
> > 
> > I guess this local setting is relevant:
> > 
> > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > *VT100.utf8Fonts.font: fixed
> > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*

for the record, xfonts-terminus includes all of these sizes.

> > here.  If I uncomment these settings xterm starts.  However, I think xterm 
> > should not
> 
> Is that "uncomment", or "comment"?
> 
> (the grep seems to indicate that the latter is meant)
> 
> > crash with segmentation fault when not finding some specified font.
> 
> agreed -

I've not been able to reproduce the problem, which I suspect is in
the error-recovery section of xterm's xtermLoadFont function.

Perhaps seeing the whole set of resources would help
(the output of "xrdb -query", too).

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


signature.asc
Description: PGP signature

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> Package: xterm
> Version: 375-1
> Severity: important
> 
> Hi,
> 
> after upgrading from xterm 374-1 to 375-1 I get:
> 
> $ xterm
> xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> Segmentation fault
> 
> I guess this local setting is relevant:
> 
> $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> *VT100.utf8Fonts.font: fixed
> XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-* 
>  
> XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> 
> here.  If I uncomment these settings xterm starts.  However, I think xterm 
> should not

Is that "uncomment", or "comment"?

(the grep seems to indicate that the latter is meant)

> crash with segmentation fault when not finding some specified font.

agreed -
 
> Kind regards
> Andreas.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages xterm depends on:
> ii  libc6   2.35-4
> ii  libfontconfig1  2.13.1-4.5
> ii  libfreetype62.12.1+dfsg-3
> ii  libice6 2:1.0.10-1
> ii  libtinfo6   6.3+20220423-2
> ii  libutempter01.2.1-2
> ii  libx11-62:1.8.1-2
> ii  libxaw7 2:1.0.14-1
> ii  libxext62:1.3.4-1+b1
> ii  libxft2 2.3.6-1
> ii  libxinerama12:1.1.4-3
> ii  libxmu6 2:1.1.3-3
> ii  libxpm4 1:3.5.12-1
> ii  libxt6  1:1.2.1-1
> ii  xbitmaps1.1.1-2.2
> 
> Versions of packages xterm recommends:
> ii  x11-utils  7.7+5
> 
> Versions of packages xterm suggests:
> pn  xfonts-cyrillic  
> 
> -- no debconf information
> 

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


signature.asc
Description: PGP signature

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

- Original Message -
| From: "Thomas Dickey" 
| To: 1021...@bugs.debian.org
| Cc: 1021243-submit...@bugs.debian.org
| Sent: Tuesday, October 4, 2022 8:22:23 PM
| Subject: Bug#1021243: xterm: different font size after upgrading from 372-1 
to 373-1

| On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
|> Package: xterm
|> Version: 373-1
|> Severity: important
|> 
|> Hi,
|> 
|> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
|> 
|> See what the fonts used to look like with 372-1 vs 373-1 in the attached
|> screenshots.
| 
| thanks (I had a similar report yesterday, and am investigating)

https://github.com/ThomasDickey/xterm-snapshots/commit/932678ac4823db3f94fc831b4c0db89307b04a5c

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

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
> Package: xterm
> Version: 373-1
> Severity: important
> 
> Hi,
> 
> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
> 
> See what the fonts used to look like with 372-1 vs 373-1 in the attached
> screenshots.

thanks (I had a similar report yesterday, and am investigating)

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


signature.asc
Description: PGP signature

Bug#31477: #31477 lynx: bookmark file is relative to home dir

[Thomas Dickey]

The documentation was updated in 2.8.2dev.4, to state

.h2 DEFAULT_BOOKMARK_FILE
# DEFAULT_BOOKMARK_FILE is the filename used for storing personal 
bookmarks.
# It will be prepended by the user's home directory.
# NOTE that a file ending in .html or other suffix mapped to text/html
# should be used to ensure its treatment as HTML.  The built-in default
# is lynx_bookmarks.html.  On both Unix and VMS, if a subdirectory off 
of
# the HOME directory is desired, the path should begin with "./" (e.g.,
# ./BM/lynx_bookmarks.html), but the subdirectory must already exist.
# Lynx will create the bookmark file, if it does not already exist, on
# the first ADD_BOOKMARK attempt if the HOME directory is indicated
# (i.e., if the definition is just filename.html without any slashes),
# but requires a pre-existing subdirectory to create the file there.
# The user can re-define the default bookmark file, as well as a set
# of sub-bookmark files if multiple bookmark file support is enabled
# (see below), via the 'o'ptions menu, and can save those definitions
# in the .lynxrc file.
#
#DEFAULT_BOOKMARK_FILE:lynx_bookmarks.html

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


signature.asc
Description: PGP signature

Bug#1015756: lynx: segfault when setting 'default colors' to 'OFF'

[Thomas Dickey]

On Wed, Jul 20, 2022 at 06:37:18PM -0400, Thomas Dickey wrote:
> On Wed, Jul 20, 2022 at 06:27:34PM -0400, Thomas Dickey wrote:
> > On Wed, Jul 20, 2022 at 06:01:01PM -0400, Thomas Dickey wrote:
> > > On Wed, Jul 20, 2022 at 05:50:48PM +0200, Cédric Hannotier wrote:
> > > > Package: lynx
> > > > Version: 2.9.0dev.10-1
> > > > Severity: normal
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > Seems that toggling off the "default colors" in the option menu
> > > > crashes lynx (segfault).
> > > > 
> > > > Steps:
> > > >  - $ lynx
> > > >  - Press o
> > > >  - navigate to "Default colors (!)"
> > > >  - switch from "ON_" (default) to "OFF"
> > > >  - navigate to "Accept Changes" and press enter
> > > > 
> > > > Disabling it using the command-line option
> > > > (lynx -default_colors) seems to work.
> > > > However, toggling it ON, then OFF makes it segfault.
> > > 
> > > thanks (I can reproduce this, will investigate)
> > 
> > The issue that I can reproduce is in ncurses.
> 
> (my traceback is longer than that given in the bug report)
> 
> > Will reassign & resolve it there.
> 
> The apparent problem is from this change:
> 
> 20211106
>   + fix a memory-leak in del_curterm (prompted by discussion with Bram
> Moolenaar, cf: 20210821).
> 
> Lynx uses delscreen (in libncurses*) when resetting curses,
> which calls del_curterm (in libtinfo*).
> 
> Few programs do this, so it's taken a while to notice.

There was more than one problem, all older than the indicated change.
That just happened to move things around to make the problems noticeable.

In the diffstat:

 ncurses/base/lib_set_term.c   |8 +--
 ncurses/tinfo/lib_setup.c |4 +--
 ncurses/tinfo/lib_tputs.c |9 
 ncurses/trace/lib_trace.c |   22 +++-
 ncurses/tty/tty_update.c  |   16 ++-

The changes in "tinfo" and "tty" are relevant.  The core dump is fixed
by the change in tty_update.c, while the other changes are things that
would be a problem at another time.  (The change to lib_set_term.c is
just to be more certain, and the trace change doesn't affect Debian).

However, there's still a less-visible issue in lynx source (seen with
valgrind), which is fixed in

v2-9-0dev_10i

seen here

https://github.com/ThomasDickey/lynx-snapshots/commit/76e3af60e119146f4da21a008af1ff752c61136f

Since that didn't cause the core-dump which I can reproduce,
it's just fyi - will be in dev.11

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


signature.asc
Description: PGP signature

Bug#1015756: lynx: segfault when setting 'default colors' to 'OFF'

[Thomas Dickey]

On Wed, Jul 20, 2022 at 06:27:34PM -0400, Thomas Dickey wrote:
> On Wed, Jul 20, 2022 at 06:01:01PM -0400, Thomas Dickey wrote:
> > On Wed, Jul 20, 2022 at 05:50:48PM +0200, Cédric Hannotier wrote:
> > > Package: lynx
> > > Version: 2.9.0dev.10-1
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > Seems that toggling off the "default colors" in the option menu
> > > crashes lynx (segfault).
> > > 
> > > Steps:
> > >  - $ lynx
> > >  - Press o
> > >  - navigate to "Default colors (!)"
> > >  - switch from "ON_" (default) to "OFF"
> > >  - navigate to "Accept Changes" and press enter
> > > 
> > > Disabling it using the command-line option
> > > (lynx -default_colors) seems to work.
> > > However, toggling it ON, then OFF makes it segfault.
> > 
> > thanks (I can reproduce this, will investigate)
> 
> The issue that I can reproduce is in ncurses.

(my traceback is longer than that given in the bug report)

> Will reassign & resolve it there.

The apparent problem is from this change:

20211106
+ fix a memory-leak in del_curterm (prompted by discussion with Bram
  Moolenaar, cf: 20210821).

Lynx uses delscreen (in libncurses*) when resetting curses,
which calls del_curterm (in libtinfo*).

Few programs do this, so it's taken a while to notice.

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


signature.asc
Description: PGP signature

Bug#1015756: lynx: segfault when setting 'default colors' to 'OFF'

[Thomas Dickey]

On Wed, Jul 20, 2022 at 06:01:01PM -0400, Thomas Dickey wrote:
> On Wed, Jul 20, 2022 at 05:50:48PM +0200, Cédric Hannotier wrote:
> > Package: lynx
> > Version: 2.9.0dev.10-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Seems that toggling off the "default colors" in the option menu
> > crashes lynx (segfault).
> > 
> > Steps:
> >  - $ lynx
> >  - Press o
> >  - navigate to "Default colors (!)"
> >  - switch from "ON_" (default) to "OFF"
> >  - navigate to "Accept Changes" and press enter
> > 
> > Disabling it using the command-line option
> > (lynx -default_colors) seems to work.
> > However, toggling it ON, then OFF makes it segfault.
> 
> thanks (I can reproduce this, will investigate)

The issue that I can reproduce is in ncurses.
Will reassign & resolve it there.

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


signature.asc
Description: PGP signature

Bug#1015756: lynx: segfault when setting 'default colors' to 'OFF'

[Thomas Dickey]

On Wed, Jul 20, 2022 at 05:50:48PM +0200, Cédric Hannotier wrote:
> Package: lynx
> Version: 2.9.0dev.10-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Seems that toggling off the "default colors" in the option menu
> crashes lynx (segfault).
> 
> Steps:
>  - $ lynx
>  - Press o
>  - navigate to "Default colors (!)"
>  - switch from "ON_" (default) to "OFF"
>  - navigate to "Accept Changes" and press enter
> 
> Disabling it using the command-line option
> (lynx -default_colors) seems to work.
> However, toggling it ON, then OFF makes it segfault.

thanks (I can reproduce this, will investigate)

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


signature.asc
Description: PGP signature

Bug#1014625: xterm: screen corruption of scrollback buffer

[Thomas Dickey]

On Sat, Jul 09, 2022 at 02:39:41PM +1000, Tim Connors wrote:
> Package: xterm
> Version: 372-1
> Severity: normal
> 
> I'm getting screen corruption (scattered blocks of blackness) over
> text in the xterm display when scrolling back.  The blocks move with
> the contents of the scrollback when scrolling.  When that text is
> eventually scrolled off the screen, scrolling back may induce a
> different corruption pattern.  Forcing a redisplay of the contents of
> the terminal by going to a different virtual desktop and back will get
> rid of the corruption.

also, menu "Main Options", "Redraw Window" can help.
 
> This has happened ever since I changed my hardware -- mostly updating
> my video card to a radeon RX570 -- necessitating new versions of some
> drivers and kernel.  While I would happily accept that the video card
> might have some dodgy memory (note to self: find a GPU memory stress
> tester), this corruption has not affected any other program other than
> xterm's scrollback buffer, so I wonder if it's a bug instead.
> 
> Screengrabs of the symptom:
> 
> https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption.png
> https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption2.png
> 
> radeon amdgpu drivers and firmware are the latest version allowed by
> otherwise being on debian stable - ie,

It looks like the problem is in the drivers (not xterm).

That could be defective implementation of XCopyArea, for instance.

https://bugs.freedesktop.org/show_bug.cgi?id=110214

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


signature.asc
Description: PGP signature

Bug#1014289: vile: FTBFS with Perl 5.36: ‘regexp_aligned’ undeclared here

[Thomas Dickey]

On Sun, Jul 03, 2022 at 04:57:01PM +0300, Niko Tyni wrote:
> Source: vile
> Version: 9.8v-2
> Severity: normal
> Tags: ftbfs
> User: debian-p...@lists.debian.org
> Usertags: perl-5.36-transition
> 
> This package fails to build from source with Perl 5.36 (currently in 
> experimental).

fix attached.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
===
RCS file: RCS/perl.xs,v
retrieving revision 1.143
diff -u -r1.143 perl.xs
--- perl.xs	2021/12/07 01:40:25	1.143
+++ perl.xs	2022/07/03 18:02:36
@@ -13,7 +13,7 @@
  * vile.  The file api.c (sometimes) provides a middle layer between
  * this interface and the rest of vile.
  *
- * $Id: perl.xs,v 1.143 2021/12/07 01:40:25 tom Exp $
+ * $Id: perl.xs,v 1.144 2022/07/03 18:02:36 tom Exp $
  */
 
 /*
@@ -21,7 +21,6 @@
  */
 #ifdef __GNUC__
 #pragma GCC diagnostic ignored "-Wcast-qual"
-#pragma GCC diagnostic ignored "-Wcompound-token-split-by-macro"
 #pragma GCC diagnostic ignored "-Wconversion"
 #pragma GCC diagnostic ignored "-Wnested-externs"
 #pragma GCC diagnostic ignored "-Wshadow"
@@ -119,20 +118,20 @@
 
 /* for vile */
 #define MARK vile_MARK
+#define regexp vile_regexp
 #include "estruct.h"
 #include "edef.h"
 #include "api.h"
+#undef regexp
 #undef MARK
 #undef ABORT
 
 /* for perl */
 #define main perl_main
-#define regexp perl_regexp
 #include 
 #include 
 #include 
 #undef main
-#undef regexp
 #undef dofile
 
 #ifdef __GNUC__


signature.asc
Description: PGP signature

Bug#1012800: ncurses-term: Terminfo entry jfbterm should not be linked to kon

[Thomas Dickey]

On Tue, Jun 14, 2022 at 08:19:13PM +0800, Steven Shiau wrote:
> Package: ncurses-term
> Version: 6.3+20220423-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Terminfo entry jfbterm should not be linked to kon. It causes CJK

That part's debatable (there probably are no active packages for either).
The entry you're commenting about dates from 2006.

REV:1.300   terminfo.src2006/09/09 22:38:37   tom
tags:v5_5_20060916, v5_5_20060909

   reviewed kon (kon2) and the later version jfbterm.  I can run the former,
   and read code for both.  Reviewing, I also noticed that linux was using
   invis, but that's incorrect.
...
# This is based on the Linux console (relies on the console to perform some
# of the functionality), but does not recognize as many control sequences.
# The program comes bundled with an old (circa 1998) copy of the Linux
# console terminfo.  It recognizes some non-ANSI/VT100 sequences such as
#   \E* move cursor to home, as as \E[H
#   \E,Xsame as \E(X
#   \EE move cursor to beginning of row
#   \E[y,xf same as \E[y,xH
#
# Note: The status-line support is buggy (dsl does not work).
kon|kon2|jfbterm|Kanji ON Linux console,
ccc@, hs,
civis@, cnorm@, cvvis@, dsl=\E[?H, flash@, fsl=\E[?F, initc@,
initp@, kcbt@, oc@, op=\E[37;40m, rs1=\Ec, tsl=\E[?T,
use=linux,

Seeing the report, the obvious problem is that in updating "linux" to
use "linux2.6", I altered these (which inherit from "linux"):

# 2011-07-16
#   * add/use xterm+tmux chunk from xterm #271 -TD
#   * resync xterm-new entry from xterm #271 -TD
#   * add E3 extended capability to linux-basic (Miroslav Lichvar)
#   * add linux2.2, linux2.6, linux3.0 entries to give context for E3 -TD
#   * add SI/SO change to linux2.6 entry (Debian #515609) -TD

the smacs/rmacs are SI/SO.

There's a related enacs...

> (Chinese, Japanes, Korean) environment showing weird characters.
> The original terminfo entry jfbterm from it's orignal tarball 0.4.7,

...uploaded in 2011-11-18, using sources dated 2005-02-24.

The accompanying Debian patch takes out the dsl which I commented on.

> could be found here:
> https://launchpad.net/ubuntu/+source/jfbterm/0.4.7-9

However, comparing the 0.4.7 version, I see these differences:

acsc: 
'++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', 
'++\,\,--..00II``aaffgghhjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'.
enacs: '\E)0', -.
rmacs: '^O', '\E[10m'.
smacs: '^N', '\E[11m'.

So the fix is to undo that detail.

Whether kon and jfbterm should/should not be linked depends on what kon
really does (I don't seem to have a source tarball for that at hand).

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


signature.asc
Description: PGP signature

Bug#1007833: terminfo: The package name should be "golang-github-xo-terminfo"

[Thomas Dickey]

On Mon, Jun 06, 2022 at 12:38:24AM +0530, Nilesh Patra wrote:
> Control: close -1
> 
> On Thu, 17 Mar 2022 10:08:16 -0400 Thomas Dickey  
> wrote:
> > Package: terminfo
> > Version: 0.0~git20210125.ca9a967-1
> > Severity: important
...
> The source package name is golang-github-xo-terminfo itself.
> It provides two "binary packages" - golang-github-xo-terminfo-dev and 
> terminfo, see[1]
> 
> Maybe terminfo should be named golang-terminfo is that'd what you want to 
> point at.

That would work.

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


signature.asc
Description: PGP signature

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Thomas Dickey]

On Sat, Jun 04, 2022 at 11:19:20AM +0200, Sven Joachim wrote:
> Control: tags -1 + patch
> 
> On 2022-06-04 09:52 +0200, Sven Joachim wrote:
> 
> > Package: dialog
> > Version: 1.3-20211214-1
> > Severity: normal
> > User: multiarch-de...@lists.alioth.debian.org
> > Usertags: multiarch
> >
> > The dialog package is marked Multi-Arch: foreign, but contains the
> > static library /usr/lib//libdialog.a.  This is flagged as an
> > error by lintian.

actually, a shared library is generally preferred for development packages.
This is what I build for my own use (scripts in the package/debian directory),
as "cdialog-dev":

/usr/bin/cdialog-config*
/usr/include/cdialog/dlg_colors.h
/usr/include/cdialog/dlg_config.h
/usr/include/cdialog/dlg_keys.h
/usr/include/cdialog.h
/usr/share/doc/cdialog-dev/changelog.Debian.gz
/usr/share/doc/cdialog-dev/changelog.gz
/usr/share/doc/cdialog-dev/copyright
/usr/share/man/man3/cdialog.3.gz
/lib/x86_64-linux-gnu/libcdialog.so@

Adding a static library is helpful, of course.

> > ,
> > | $ lintian-explain-tags multiarch-foreign-static-library
> > | N:
> > | E: multiarch-foreign-static-library
> > | N:
> > | N:   The package is architecture-dependent, ships a static library in a 
> > public, architecture-dependent library search path
> > | N:   and is marked Multi-Arch: foreign. A compiler will be unable to find 
> > this file, unless it is installed for a matching
> > | N:   architecture, but the foreign marking says that the architecture 
> > should not matter.
> > | N:
> > | N:   Please remove the Multi-Arch: foreign stanza.
> > `
> >
> > The lintian diagnosis looks correct to me, but I do not think the
> > suggested remedy is what we want here.  Rather, the correct fix should
> > be to split out libdialog.a and the header files into a separate
> > libdialog-dev package (which probably could be marked Multi-Arch: same).
> 
> See the attached patch which is build-time tested.  The package
> description for libdialog-dev might have to be tweaked, and if
> 1.3-20211214-2 is not the version that first applies the patch, the
> Breaks/Replaces relationships need to be adjusted.
> 
> I also noticed that dialog.h #includes curses.h, so added a dependency
> on libncurses-dev to libdialog-dev.
> 
> Cheers,
>Sven
> 

> diff --git a/debian/control b/debian/control
> index 14ddb48..a38a59b 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -9,7 +9,6 @@ Homepage: https://invisible-island.net/dialog/dialog.html
>  Package: dialog
>  Architecture: any
>  Depends: ${shlibs:Depends}, debianutils (>= 1.6)
> -Provides: libdialog-dev
>  Multi-Arch: foreign
>  Description: Displays user-friendly dialog boxes from shell scripts
>   This application provides a method of displaying several different types
> @@ -29,3 +28,17 @@ Description: Displays user-friendly dialog boxes from 
> shell scripts
>tail Allows viewing the end of files (tail) that auto updates
>background tail  Similar to tail but runs in the background.
>editbox  Allows editing an existing file
> +
> +Package: libdialog-dev
> +Architecture: any
> +Section: libdevel
> +Depends: ${misc:Depends}, libncurses-dev
> +Multi-Arch: same
> +Replaces: dialog (<< 1.3-20211214-2~)
> +Breaks: dialog (<< 1.3-20211214-2~)
> +Description: Displays user-friendly dialog boxes -- development files
> + The dialog application provides a method of displaying several different
> + types of dialog boxes from shell scripts.  This allows a developer of a
> + script to interact with the user in a much friendlier manner.
> + .
> + This package contains the header files and the static library.
> diff --git a/debian/dialog.install b/debian/dialog.install
> index 891ffa2..7186321 100644
> --- a/debian/dialog.install
> +++ b/debian/dialog.install
> @@ -1 +1,4 @@
>  dialog.pl usr/share/perl5
> +usr/bin
> +usr/share/locale
> +usr/share/man/man1
> diff --git a/debian/libdialog-dev.install b/debian/libdialog-dev.install
> new file mode 100644
> index 000..95c4b91
> --- /dev/null
> +++ b/debian/libdialog-dev.install
> @@ -0,0 +1,3 @@
> +usr/include
> +usr/lib
> +usr/share/man/man3


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


signature.asc
Description: PGP signature

Bug#1010628: libsm6: Missing symbolic link libSM.so (to libSM.so.6.0.1)

[Thomas Dickey]

On Thu, May 05, 2022 at 01:43:00PM -0400, Kevin Cole wrote:
> Package: libsm6

The symbolic link is provided by the development package,
and doesn't belong in the runtime.

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


signature.asc
Description: PGP signature

Bug#1010630: libice6: Missing symbolic link libICE.so (to libICE.so.6.3.0)

[Thomas Dickey]

On Thu, May 05, 2022 at 01:45:53PM -0400, Kevin Cole wrote:
> Package: libice6

The symbolic link is provided in the development package (libice-dev)

/.
/usr
/usr/include
/usr/include/X11
/usr/include/X11/ICE
/usr/include/X11/ICE/ICE.h
/usr/include/X11/ICE/ICEconn.h
/usr/include/X11/ICE/ICElib.h
/usr/include/X11/ICE/ICEmsg.h
/usr/include/X11/ICE/ICEproto.h
/usr/include/X11/ICE/ICEutil.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libICE.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/ice.pc
/usr/share
/usr/share/doc
/usr/share/doc/libice-dev
/usr/share/doc/libice-dev/changelog.Debian.gz
/usr/share/doc/libice-dev/changelog.gz
/usr/share/doc/libice-dev/copyright
/usr/lib/x86_64-linux-gnu/libICE.so

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


signature.asc
Description: PGP signature

Bug#1010270: Recent update break xterm

[Thomas Dickey]

On Wed, Apr 27, 2022 at 08:28:48PM +0200, Sven Joachim wrote:
> Control: reassign -1 ncurses-base 6.3+20220423-1
> 
> Please keep the bug report CC'ed.
> 
> Am 27.04.2022 um 18:25 schrieb Klaus Ethgen:
> 
> > Am Mi den 27. Apr 2022 um 15:49 schrieb Sven Joachim:
> >> > Package: libtinfo5
> >> > Version: 6.3+20220423-1
> >> > Severity: normal
> >> >
> >> > Since the last update of this package, applications running inside of
> >> > xterm are not always able to update the window title.
> >> >
> >> > Instead, control output are breaking the layout of the application.
> >> >
> >> > Broken Applications:
> >> > - mutt
> >> > - cmus
> >> >
> >> > Still working:
> >> > - zsh
> >>
> >> Can you give steps to reproduce what is broken?  Also, which version of
> >> xterm do you use, and what is the value of the TERM environment
> >> variable?
> >
> > ~> dpkg -l xterm
> > ii  xterm  372-1amd64X terminal emulator
> > ~> echo $TERM
> > xterm-256color
> >
> > For cmus, just use it, it should show the title of the current song in
> > the title of your terminal.
> >
> > Same for mutt. It should show the message count in title ans some more
> > infomations.
> 
> Not in its default configuration, you need to have "set ts_enabled=yes"
> in your muttrc file.  With that I can confirm the problem.
> 
> Two workarounds: set TERM=xterm-p370, _or_ downgrade ncurses-base to
> 6.3-2, I recommend the latter.

hmm - for consistency in xterm, I should have made the default for

  --enable-status-line
 
enabled.  But since there are few actual uses of tsl/fsl (almost all are
hard-coded), I'd overlooked those which mix hard-coding and terminfo
(such as the programs given as examples here).

Applications which assume xterm's title-string should use the terminfo
"XT" flag anyway (documented in terminfo.src), because it doesn't allow
for a parameter in tsl, as documented in terminfo(5):

  to_status_line  tsl   ts move to status line,
   column #1

   Some terminals with status lines need special sequences to  access  the
   status  line.  These may be expressed as a string with single parameter
   tsl which takes the cursor to a given zero-origin column on the  status
   line.   The  capability fsl must return to the main-screen cursor posi‐
   tions before the last tsl.  You may need to embed the string values  of
   sc  (save  cursor) and rc (restore cursor) in tsl and fsl to accomplish
   this.

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


signature.asc
Description: PGP signature

Bug#1004874: dialog: --max-input ignores values higher than 2048

[Thomas Dickey]

fixed in 1.3.20220414

https://invisible-island.net/dialog/CHANGES.html#t20220414

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


signature.asc
Description: PGP signature

Bug#1004868: dialog: menu segfaults when resizing

[Thomas Dickey]

fixed in 1.3.20220404

https://invisible-island.net/dialog/CHANGES.html#t20220404

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


signature.asc
Description: PGP signature

Bug#1003185: dialog: Dialog segfaults when passing large line to editbox

[Thomas Dickey]

fixed in 1.3.20220117

https://invisible-island.net/dialog/CHANGES.html#t20220117

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


signature.asc
Description: PGP signature

Bug#1007810: ITP: lf -- terminal file manager written in Go

[Thomas Dickey]

On Thu, Mar 17, 2022 at 09:38:22AM -0400, Thomas Dickey wrote:
> >Features:
> >
> > - Single binary without any runtime dependencies (except terminfo database)
> 
> Actually, I don't see any sign of terminfo in the source code.
> Perhaps its developer intends to do that some time.
> 
> In its current state, its terminal interface relies upon hard-coded strings,
> doesn't use terminfo at all.

By the way, I see this in aptitude:

--- Installed Packages (2)
--\ Not Installed Packages (2)
  --\ golang Go programming language, libraries, and development tools (
--\ main   The main Debian archive (2)
p golang-github-xo-terminfo-dev 0.0~git2021012
p terminfo  0.0~git2021012

and

terminfo provides a pure-Go implementation of reading information from the
terminfo database. This provides the infocmp binary from terminfo.
Homepage: https://github.com/xo/terminfo

It seems that the package which should be named "golang-github-xo-terminfo"
is mis-named "terminfo" (but that's someone else's bug).

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


signature.asc
Description: PGP signature

Bug#1007833: terminfo: The package name should be "golang-github-xo-terminfo"

[Thomas Dickey]

Package: terminfo
Version: 0.0~git20210125.ca9a967-1
Severity: important

Dear Maintainer,

The package name should be "golang-github-xo-terminfo", and the package name
amended to avoid suggesting that it provides "infocmp" (which is part of
ncurses-bin).

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages terminfo depends on:
ii  libc6  2.33-7

terminfo recommends no packages.

terminfo suggests no packages.

Bug#1007810: ITP: lf -- terminal file manager written in Go

[Thomas Dickey]

>Features:
>
> - Single binary without any runtime dependencies (except terminfo database)

Actually, I don't see any sign of terminfo in the source code.
Perhaps its developer intends to do that some time.

In its current state, its terminal interface relies upon hard-coded strings,
doesn't use terminfo at all.

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


signature.asc
Description: PGP signature

Bug#1007709: xterm: Sometimes xterm last lines are not shown, amd64->arm64

[Thomas Dickey]

On Tue, Mar 15, 2022 at 01:05:17PM +0100, Jose L. Fernandez Jambrina wrote:
> Package: xterm
> Version: 366-1
> Severity: normal
> X-Debbugs-Cc: j.fdez.jambr...@gr.ssr.upm.es
> 
> Dear Maintainer,
> 
> Sometimes xterm last lines are not shown, pressing enter forces them to
> appear.  This happen with xterm running on an amd4 machine but displayed in a
> raspberry-4 machine, both running bullseye /stable

That sounds like a problem with the X server rather than xterm.

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


signature.asc
Description: PGP signature

Bug#1006193: Remove luit, now packaged separately

[Thomas Dickey]

On Wed, Mar 02, 2022 at 08:15:15PM +0100, Sven Joachim wrote:
> On 2022-02-21 10:14 +1100, Brendan O'Dea wrote:
> 
> > Package: x11-utils
> > Version: 7.7+5
> > Severity: normal
> > Tags: patch
> > X-Debbugs-Cc: b...@debian.org
> >
> > Merge request to remove luit from x11-utils:
> >
> >   https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1
> >
> > now packaged separately, this commit removes luit and adds a recommends for
> > the new package.
> 
> Thanks, I have merged that now.  Are there any packages besides xterm
> that use luit?  On codesearch.debian.net I found some 75 hits[1], but
> they seem to be either completely unrelated or only commentaries.

I'm not aware of any other direct dependencies such as xterm.

The occasional mention that I see for luit is for running it
manually from the command-line, e.g., to make a shell for using emacs
with some legacy character set.
 
> Cheers,
>Sven
> 
> 
> 1. https://codesearch.debian.net/search?q=%5Cbluit%5Cb=0
> 

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


signature.asc
Description: PGP signature

Bug#576670: #576670 xterm: *.sh and *pl files are not installed (color scripts)

[Thomas Dickey]

A separate package probably wouldn't be that useful (since most of the
xterm features are poorly supported by other terminal emulators).

There are currently 60 scripts.

In my test-packages, I add those in /usr/share/doc/*/examples:

dh_installexamples tektests vttests

which consumes about as much diskspace as the changelog (xterm.log.html).

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


signature.asc
Description: PGP signature

Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

[Thomas Dickey]

I was recently reminded of this one, and can see that it's no longer relevant:

+ The bug-report made incorrect assumptions about what xprop ought to be doing.
  So it's not relevant to xprop.

+ Cloos' comment about xterm was interesting but not useful for xterm, because
  the encoding as STRING rather than COMPOUND_STRING is done by the X Toolkit
  library.
  
  Reading the Shell.c file in libXt, arguably an application _could_ set the
  resources titleEncoding and iconNameEncoding while setting the title and
  icon-name, but even setting those to COMPOUND_STRING (which does _not_
  hold UTF-8) wouldn'd make the server transmute those into EWMH names (which
  _does_ hold UTF-8).

+ Regarding xterm, my changes in patch #349 make it do by default what Vincent
  assumed.

 Patch #349 - 2019/09/22
 * improve title-string feature:
  + if any of allowC1Printable, utf8Title or titleModes hint that
an  application  might  send a title-string encoded in UTF-8,
check  if  that  is  the  case,  and  if it is recodable into
ISO-8859-1, use that for the ICCCM-style title.
  + check  if the title given by a control sequence happens to be
already  encoded  in UTF-8, to avoid double-encoding (FreeBSD
#240393).
  + Make sameName resource work for the EWMH titles.
  + Modify menu-state of utf8Title to be consistent with the utf8
source,  i.e., setting the EWMH properties automatically when
UTF-8 is active.

just for grins, I'll close this (expecting the usual response from Vincent).

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


signature.asc
Description: PGP signature

Bug#1005272: libxt6: out-of-date copyright file

[Thomas Dickey]

Package: libxt6
Version: 1:1.2.0-20190617
Severity: important

The copyright file in package libxt (version 1:1.2.1-1) is out-of-date.
The sources from which libxt were built have a current copyright file
at the top of the source-tree "COPYRIGHT" which can be used to replace
the out-of-date copyright file in the package.

Debian policy addresses this issue:

https://www.debian.org/doc/debian-policy/ch-source.html#copyright-debian-copyright

Every package must be accompanied by a verbatim copy of its distribution
license(s) in the file /usr/share/doc/PACKAGE/copyright.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libxt6 depends on:
ii  libc6  2.33-5
ii  libice62:1.0.10-1
ii  libsm6 2:1.2.3-1
ii  libx11-6   2:1.7.2-2+b1
ii  multiarch-support  2.28-10

libxt6 recommends no packages.

libxt6 suggests no packages.

-- no debconf information

Bug#1004901: ncurses-bin: issues with the infocmp(1) man page and databases

[Thomas Dickey]

On Thu, Feb 03, 2022 at 11:10:50AM +0100, Vincent Lefevre wrote:
> Package: ncurses-bin
> Version: 6.3-2
> Severity: minor
> 
> In the infocmp(1) man page:
> 
>Changing Databases [-A directory] [-B directory]
>Like  other  ncurses  utilities, infocmp looks for the terminal
>descriptions in several places.  You can use the  TERMINFO  and
>TERMINFO_DIRS environment variables to override the compiled-in
>default list of places to search (see curses(3X) for details).
> 
> The curses(3X) man page does not exist. It is curses(3ncurses).

yes... ncurses has a data-file which I developed along with configure/build
scripting to install the manpages renamed for Debian's special case
(man_db.renames).  That data (along with manhtml.aliases) could be used in some
as-yet-unwritten script to modify the manual pages as they are installed.

Because Debian is the only organization that uses this feature (and looking
at the change history, it's been more than 15 years since Debian reported
minor errors in the data-file), it hasn't been worth generalizing further.

If someone wants to spend (at least) a few days developing the script and
contributes it (same license, etc), I can integrate it.

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


signature.asc
Description: PGP signature

Bug#1004689: xterm: CVE-2022-24130

[Thomas Dickey]

On Mon, Jan 31, 2022 at 08:37:03PM +0100, Salvatore Bonaccorso wrote:
> Source: xterm
> Version: 370-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for xterm.
> 
> CVE-2022-24130[0]:
> | xterm through Patch 370, when Sixel support is enabled, allows
> | attackers to trigger a buffer overflow in set_sixel in
> | graphics_sixel.c via crafted text.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

changelog as usual reflects the actual report, not a succession of
secondhand information.

I applied a fix for the issue yesterday, which will be in #371.
For backports, do as suggested here:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/xterm/patches/patch-graphics__sixel.c

derived from

https://github.com/ThomasDickey/xterm-snapshots/blob/master/graphics_sixel.c

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


signature.asc
Description: PGP signature

Bug#904572: move x11-utils to Suggests

[Thomas Dickey]

On Mon, Jan 24, 2022 at 10:06:46AM +0100, Harald Dunkel wrote:
> Maybe the Recommends could be replaced by a Suggests: x11-utils.
> By now I didn't even know that there is a tool "luit".

It's used (when available and if the locale encoding is not UTF-8) by xterm
for quite a while.  But it doesn't use the X display (unlike the other
programs in x11-utils).

Moving it to a separate package would only affect xterm and a (probably)
small number of direct command-line users.  Changing the "recommends" to
a "suggests" would have an impact on xterm, since some users would not
see luit automatically.  As I understand it, the best route would be to
get luit available separately and then change the xterm package to recommend
luit rather than x11-utils.

By the way - the existing version of luit uses libfontenc, which _is_ used
by several applications.  Take a look at

apt-rdepends --reverse libfontenc1

However, in my upgrade, I dispensed with that dependency, so the resulting
luit depends only on glibc and libz.  That makes it easily portable - unlike
most of x11-utils :-)

So... decoupling luit (and libfontenc1) from x11-utils will improve the
dependencies of both xterm and x11-utils.

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


signature.asc
Description: PGP signature

Bug#904572: move x11-utils to Suggests

[Thomas Dickey]

On Sun, Jan 23, 2022 at 05:55:37PM +, Ivan Shmakov wrote:
> > Harald Dunkel  writes:
> 
>  > Package: xterm
>  > Version: 333-1
> 
>  > xterm recommends x11-utils.  Assuming the default configuration, this
>  > brings in a huge list of packages unrelated to xterm's main purpose:
>  > Running a shell or another cli program.  Sample:

xterm actually should recommend luit, which is not yet a separate package
see #1003130 and #1003770:

https://mentors.debian.net/package/luit/

once that's completed, the xterm package should be changed to recommend luit
(about 130kb for that package, no dependencies except that it might suggest
the xfonts-encodings package).
 
>   There’re several ways to resolve the issue, one of which is
>   indeed to move luit into a package of its own, though I can’t
>   say I’m particularly fond of practices that lead to the
>   expansion of the Packages files, as well as /var/lib/dpkg/.

that's unclear (there's only ~66 thousand packages so far)

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


signature.asc
Description: PGP signature

Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator

[Thomas Dickey]

On Sun, Jan 23, 2022 at 02:08:00PM +0100, Andreas Metzler wrote:
> On 2022-01-16 Andreas Metzler  wrote:
> [...]
> > I will probably followup with further wishes/comments later, not today
> > but hopefully in next week.
> [...]
> 
> Hello Thomas,
> 
> I think there are just two thing left pre upload:
> 
> 1. The upload introduces an epoch because the upstream version went from
> mmdd to 2.0.mmdd. Given that the new version scheme seems to
> have found acceptance in e.g. Fedora /I/ do not see a better way. Could
> you ask about the epoch on debian-devel (as per policy
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
> ) - TIA.

thanks - I will do this.
 
> 2. It would be nice to merge the changelog entries for 1:2.0.20220109-1
> and 1:2.0.20220114-1, listing only the changes relative to what was yet
> uploaded to Debian. (I would not consider this a must for sponsorship.)

okay - a single upload comment would be simpler

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


signature.asc
Description: PGP signature

Bug#1003130: ITP: luit in 2013.

[Thomas Dickey]

On Fri, Jan 07, 2022 at 11:30:07AM -0500, Thomas Dickey wrote:
> On Wed, Jan 05, 2022 at 03:23:13PM -0500, Thomas Dickey wrote:
> > On Wed, Jan 05, 2022 at 03:26:13PM +0200, Timo Aaltonen wrote:
> ...
> > > If not, I don't see a point in creating a separate package for it. And I
> 
> actually as I understand Debian policy, it would have to be a separate
> package because the upstream source differs.

I discussed this further with Brendan O'Dea, and mentioned also that
upstream luit doesn't use automake, i.e., like the other programs which
I maintain would depend upon autoconf-dickey.  Mixing that with x11-utils
would be unlikely to be a satisfactory arrangement.

Brendan suggested that rather than using the alternatives feature,
to instead

a) use dpkg-divert to allow luit 2.0 to be installed with
   the existing x11-utils, and
b) after luit 2.0 is available in main, update x11-utils
   to remove luit 1.1.1, replacing it with a "Recommends".

I've uploaded the version using dpkg-divert here:

https://mentors.debian.net/package/luit/

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


signature.asc
Description: PGP signature