Re: RFS: vttest - test compatibility of terminals
Wen-Yen Chuang <[EMAIL PROTECTED]> wrote: > I think its manpage is good enough for people who want to try this > program. I have no DEC VT100 terminal nor its manual. vt100.net does have manuals (but the comment about a vt100 manual is older than the web) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
The Fungi <[EMAIL PROTECTED]> wrote: > Of course, I can't imagine an ANSI library would be anything more > than a few dozen string constant definitions, unless you wanted man tput (no point in hardcoding "a few dozen string" definitions, unless one _likes_ the nasty comments that people make when they read the code ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
Adam Borowski <[EMAIL PROTECTED]> wrote: > curses does only full-screen display, and is useless for anything > line-based. And being capable of colouring your display is a MAJOR thing if > you want to be able to read text quickly. man filter -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
Adam Borowski <[EMAIL PROTECTED]> wrote: > I'm afraid the very concept of termcap/terminfo is thoroughly broken. > It makes the following assumptions: > * all TERM strings are known to all machines. Mere ssh will break > otherwise. And even after all these years, Solaris still doesn't > know what TERM="linux" means (the last time I checked it didn't, at > least). That's not a technical problem... > In other words, "TERM" is totally useless. How is it supposed to > tell me that I have to write spaces to every position instead of > usual means of clearing the screen if bgcolor isn't transparent man terminfo (on Solaris btw, the termcap equivalent doesn't match anyone else's, but since Sun's provided terminfo is deficient, you may as well install ncurses' terminfo): back_color_erasebce beScreen erased with background color > (older putties) -- and even if it could, neither termcap nor terminfo > have means to convey this info. Or, do I need to restore the \e[???m > attrs after moving the cursor (libvt in some cases)? Or, what are ditto (msgr). > the effects of \n on the line right to the cursor? Or, how to be > told if arrow keys pressed are Kpad ones or the new-style "gray" > ones? I'm afraid terminfo libraries cannot see your keyboard (but they can keep a list of the possibilities much better than a hand-crafted table in a script ;-) >>From my own experience, the only way to get decent portability is, > ironically, hard-coding a certain subset of vt100ish codes. Querying > termcap/terminfo tends to lose rather fast in comparison. oh. Then you'll have to give up on color, since vt100's never did that. bye -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#660162: RFS: tack/1.07-2
>Hmm, yes, that can be a problem. Unfortunately, it's currently >hardwired into the Makefile at configure time; this is likely related >to a desire to work with a wider range of Make implementations than is >usual? I did that a different way (there's a macro which I normally use for most scripts). >> Later in the build log I see: >> | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if >> "debian/tack/usr/bin/tack" were not uselessly linked against it (they use >> none of its symbols). >> >> It would be nice if you could get rid of this dependency. (But that's OK if >> you don't want to.) > >Yes, I've already reported this upstream[1], and Thomas seemed sympathetic? > >[1]: [94]http://thread.gmane.org/gmane.comp.lib.ncurses.bugs/4797 I'm working on a fix for this now (have coded it, and have to check it on a few platforms). I spent all of last week on the ncurses changes that I finished yesterday (investigating cross compiles led to review of not-recently-built stuff which reminded me about the OpenBSD warning messages, etc). tack is much simpler (I haven't tried cross compiling it yet ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Re: Bug#554167: Updating Mawk in Debian
On Mon, May 28, 2012 at 02:48:02PM -0500, Jonathan Nieder wrote:
> Hi Yann,
>
> yannubu...@gmail.com wrote:
>
> > any news about updating Mawk with the last upstream version?
>
> I don't think it can happen and be properly tested in time for wheezy.
> The new upstream version has significant changes relative to the
> packaged version and probably introduces some (minor or not)
> regressions. (For example, the -W i option didn't work in Turkic
> locales the last time I checked, because toupper('i') is not 'I'.)
>
> What would be very helpful is code review. For example, collect
> a batch of twenty or so patches (e.g., changes up to 1.3.3-20090705)
> from [1] or straight from Thomas. File a bug that lists the patches,
> their purpose, potential regressions, and how that potential can be
> mitigated. Then I would be happy to help get those patches applied
> in experimental.
I don't recall seeing any comments from Steve on this.
> Another way to help is to get the code history up to the present in a
> readable state, to help that same effort. That basically means:
>
> * improve the "rcs fast-export" tool[2]. All improvements are good. :)
It needs work. I commented on what I'd done a couple of months ago,
but saw no replies. (At the moment I'm actually working on mawk).
>Packaging it for Debian would be great because then we get a
>bugtracker. If you can get the raw RCS files to test changes, that
>might make this task easier.
I have in mind creating a git-bundle using my fixed-up rcs-fast-export
(as an export-only...).
> * collect more changes (in RCS or git bundle form) and let me know
>so I can update [1] to include the updated code.
>
> Testing is of course also welcome.
>
> Hope that helps,
> Jonathan
>
> [1] http://git.debian.org/?p=users/jrnieder-guest/mawk-historical.git
> [2] http://wok.oblomov.eu/tecnologia/rcs-fast-export/
>
>
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
Bug#689219: licensing
manlinks.sed is a special case, because I adapted a script which I written for ncurses. http://invisible-island.net/cdk/cdk.html#licensing -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Re: Bug#689219: RFS: libcdk5/5.0.20120323-1 [ITA] -- C-based curseswidget library
On Sunday, September 30, 2012 7:00:02 PM UTC-4, Jose G. López wrote: > El dom, 30-09-2012 a las 21:30 +0200, Bart Martens escribió: > > > Hi Jose, > > > > > > I had a look at libcdk5 at mentors uploaded there on 2012-09-30 12:50. The > > > file debian/copyright is not yet complete, see for example manlinks.sed. > > > > Done (re-uploaded). I've used 'MIT-NCURSES' for license short name following > Machine-readable > > manual and after looking at this http://en.wikipedia.org/wiki/MIT_License > > I hope it's ok ... http://invisible-island.net/cdk/cdk.html#licensing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fd231e5f-fd8c-4cd2-a701-48204efd5...@googlegroups.com
Bug#689219: RFS: libcdk5/5.0.20120323-1 [ITA] -- C-based curseswidget library
On Tue, Oct 02, 2012 at 07:47:36AM +0200, Jose G. López wrote:
> El lun, 01-10-2012 a las 10:50 +0200, Thomas Dickey escribió:
>
> > http://invisible-island.net/cdk/cdk.html#licensing
>
> Hello Thomas,
>
> Thanks for pointing that. I already read that page before packaging and
> I think it's correct to use the BSD-4-clause license. You and Mike are
> marked as copyright authors.
> Could you, please, review the debian/copyright from here?
> http://paste.debian.net/plain/195093
hmm - mostly correct. The dates are an issue (I keep each file
separately marked according to the last modification).
The most recent years that I have marked in the sources are
2012, 2011, 2010, and 2009:
CHANGES:6:Modifications copyright Thomas E. Dickey 1999-2010, 2011
COPYING:1:Modifications copyright Thomas Dickey 1999, 2000, 2001, 2002, 2003,
2004, 2005, 2006, 2007
Makefile.in:3:# Copyright 2001-2011,2012 Thomas E. Dickey
README:4:Copyright Thomas Dickey 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
aclocal.m4:4:dnl Copyright 1999-2011,2012 Thomas E. Dickey
cdk-config.in:4:# Copyright (c) 2007,2011 Thomas E. Dickey
#
manlinks.sed:3:# Copyright 2000-2002,2005 Thomas E. Dickey
#
manlinks.sh:5:# Copyright 2002,2005 Thomas Dickey
include/alphalist.h:23: * Changes 1999-2006,2012 copyright Thomas E. Dickey
include/binding.h:20: * Changes 1999-2004,2005 copyright Thomas E. Dickey
include/button.h:21: * Changes 2002-2004,2012 copyright Thomas E. Dickey
include/buttonbox.h:23: * Changes 1999-2005,2012 copyright Thomas E. Dickey
include/calendar.h:23: * Changes 2000-2011,2012 copyright Thomas E. Dickey
include/cdk.h:13: * Changes 2000-2009,2012 copyright Thomas E. Dickey
include/cdk_compat.h:14: * Copyright 2004,2005 Thomas E. Dickey
include/cdk_int.h:16: * Copyright 2003-2009,2011 Thomas E. Dickey
include/cdk_objs.h:22: * Copyright 1999-2005,2012 Thomas E. Dickey
include/cdk_params.h:20: * Copyright 2003-2005,2012 Thomas E. Dickey
include/cdk_test.h:16: * Copyright 2005,2008 Thomas E. Dickey
include/cdk_util.h:22: * Changes 1999-2006,2012 copyright Thomas E. Dickey
include/cdk_version.hin:13: * Copyright 2002,2012 Thomas E. Dickey
include/cdkscreen.h:20: * Changes 1999-2004,2005 copyright Thomas E. Dickey
include/curdefs.h:14: * Changes 1999-2004,2009 copyright Thomas E. Dickey
include/dialog.h:23: * Changes 1999-2003,2012 copyright Thomas E. Dickey
include/draw.h:23: * Changes 1999-2003,2004 copyright Thomas E. Dickey
include/entry.h:23: * Changes 1999-2003,2012 copyright Thomas E. Dickey
include/fselect.h:25: * Changes 1999-2006,2012 copyright Thomas E. Dickey
include/gen-scale.h:23: * Copyright 2004,2012 Thomas E. Dickey
include/gen-slider.h:23: * Copyright 2004,2012 Thomas E. Dickey
include/graph.h:23: * Changes 2000-2004,2012 copyright Thomas E. Dickey
include/histogram.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
include/itemlist.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
include/label.h:23: * Changes 2000-2003,2012 copyright Thomas E. Dickey
include/marquee.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
include/matrix.h:23: * Changes 1999-2008,2012 copyright Thomas E. Dickey
include/mentry.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
include/menu.h:23: * Changes 1999-2005,2012 copyright Thomas E. Dickey
include/radio.h:23: * Changes 1999-2005,2012 copyright Thomas E. Dickey
include/scroll.h:23: * Changes 1999-2006,2012 copyright Thomas E. Dickey
include/selection.h:23: * Changes 1999-2005,2012 copyright Thomas E. Dickey
include/swindow.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
include/template.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
include/traverse.h:21: * Copyright 1999-2004,2005 Thomas E. Dickey
include/viewer.h:23: * Changes 1999-2004,2012 copyright Thomas E. Dickey
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
Re: RFS: YSM ICQ client
Ilya M. Slepnev <[EMAIL PROTECTED]> wrote: > First of all, it is a nice, small, with clear interface, full of humor > client. It doesn't depend on any ncurses, as centericq. Ok, I > understand, that many people think about console clients as becomed > obsolete and not so featured. This client includes all standart > features, and simplicity of console utils. I am using this client with > screen program, and it looks powerfull. > ldd ysm libnsl.so.1 => /lib/libnsl.so.1 (0x4002f000) libpthread.so.0 => /lib/libpthread.so.0 (0x40044000) libreadline.so.5 => /lib/libreadline.so.5 (0x40095000) libc.so.6 => /lib/libc.so.6 (0x400c3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x401f6000) libdl.so.2 => /lib/libdl.so.2 (0x4024f000) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: YSM ICQ client
Ilya M. Slepnev <[EMAIL PROTECTED]> wrote: > --ibTvN161/egqYuK8 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > Hi, > On 19:15 Wed 27 Apr, Thomas Dickey wrote: >> > ldd ysm >> libnsl.so.1 =3D> /lib/libnsl.so.1 (0x4002f000) >> libpthread.so.0 =3D> /lib/libpthread.so.0 (0x40044000) >> libreadline.so.5 =3D> /lib/libreadline.so.5 (0x40095000) >> libc.so.6 =3D> /lib/libc.so.6 (0x400c3000) >> /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x4000) >> libncurses.so.5 =3D> /usr/lib/libncurses.so.5 (0x401f6000) >> libdl.so.2 =3D> /lib/libdl.so.2 (0x4024f000) > That's very strange... Is that log a log for my package?! May be, you have = > compiled this with ncurses > support?! I compiled it from source (the configure script looks for libreadline, which is dependent upon libncurses). If libreadline isn't present, the source has a copy of getline.c -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers
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
Re: Bug#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers
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#1081570: RFS: luit/2.0.20240910-1
Package: sponsorship-requests Severity: normal I've updated https://salsa.debian.org/debian/luit for the current version of luit, and would like a sponsor.
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On Fri, Sep 13, 2024 at 12:55:01AM +0100, Phil Wyett wrote: > Control: tags -1 +moreinfo > > Thomas, > > Preamble... > > Thank you for taking the time to prepare this package and your contribution > to the Debian project. > > The review below is for assistance. This review is offered to help package > submitters to Debian mentors inorder to improve their packages prior to > possible sponsorship into Debian. There is no obligation on behalf of the > submitter to make any alterations based upon information provided in the > review. > > Review... I'll address most of this (thanks) > 1. Build: > > * pbuilder [1]: Good > * sbuild [2]: Good > > 2. Lintian [3]: Issues > > W: luit source: build-depends-on-obsolete-package Build-Depends: pkg-config > => pkgconf > N: > N: The package build-depends on a package that has been superseded. If the > N: superseded package is part of an ORed group, it should not be the first > N: package in the group. > N: > N: Visibility: warning > N: Show-Always: no > N: Check: fields/package-relations > N: > N: > I: luit source: out-of-date-standards-version 4.6.1.0 (released 2022-05-11) > (current is 4.7.0) > N: > N: The source package refers to a Standards-Version older than the one that > N: was current at the time the package was created (according to the > N: timestamp of the latest debian/changelog entry). Please consider > updating > N: the package to current Policy and setting this control field > N: appropriately. > N: > N: If the package is already compliant with the current standards, you > don't > N: have to re-upload the package just to adjust the Standards-Version > control > N: field. However, please remember to update this field next time you > upload > N: the package. > N: > N: See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the > N: debian-policy package for a summary of changes in newer versions of > N: Policy. > N: > N: Please refer to > N: https://www.debian.org/doc/debian-policy/upgrading-checklist.html for > N: details. > N: > N: Visibility: info > N: Show-Always: no > N: Check: fields/standards-version > N: > N: > I: luit source: unused-override no-debian-changes [debian/source/lintian- > overrides:2] > N: > N: Your package specifies the named override but there were no tags that > N: could have been silenced by it. > N: > N: Maybe you fixed an underlying condition but forgot to remove the > override. > N: It is also possible that the Lintian maintainers fixed a false positive. > N: > N: If the override is now unused, please remove it. > N: > N: This tag is similar to mismatched-override except there a tag could have > N: been silenced if the context had matched. > N: > N: Sometimes, overrides end up not being used because a tag appears only on > N: some architectures. In that case, overrides can be equipped with an > N: architecture qualifier. > N: > N: Please refer to Architecture specific overrides (Section 2.4.3) in the > N: Lintian User's Manual for details. > N: > N: Visibility: info > N: Show-Always: yes > N: Check: lintian > N: > N: 0 hints overridden; 1 unused override > > 3. Licenses [4]: Issues, with false positives possible > > philwyett@ks-tarkin:~/Development/builder/debian/mentoring/luit$ lrc > en: Versions: recon 1.18 check 3.3.9-1 > > Parsing Source Tree > Reading copyright > Missing Files Paragraph for debian/ > Running licensecheck > > d/copyright | licensecheck > > X11 | Expat charset.c licensecheck has a problem. I recommend fixing it. https://invisible-island.net/ncurses/ncurses-license.html#issues_expat I don't see that here with licensecheck - must be a recent bug: ./COPYING: MIT License ./COPYING.asc: *No copyright* UNKNOWN ./Makefile.in: UNKNOWN ./aclocal.m4: UNKNOWN ./builtin.c: *No copyright* UNKNOWN [generated file] ./charset.c: MIT License ./charset.h: MIT License ./config.guess: GNU General Public License v3.0 or later ./config.sub: GNU General Public License v3.0 or later ./config_h.in: *No copyright* UNKNOWN ./configure: FSF Unlimited License ./configure.in: UNKNOWN ./fontenc.c: MIT License ./install-sh: X11 License [generated file] ./iso2022.c: MIT License ./iso2022.h: MIT License ./luit.c: MIT License ./luit.h: MIT License ./luit.log.html: MIT License ./luit.man: MIT License ./luitconv.c: MIT License ./luitconv.h: MIT License ./minstall.sh: MIT License ./other.c: MIT License ./other.h: MIT License ./parser.c: MIT License ./parser.h: MIT License ./plink.sh: MIT License ./sys.c: MIT License ./sys.h: MIT License ./trace.c: MIT License ./trace.h: MIT License ./version.h: *No co
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On Sat, Sep 14, 2024 at 02:08:44AM +0100, Phil Wyett wrote: > Control: tags -1 +moreinfo > > Thomas, > > Many thanks for addressing some of the issues raised. ... > 'd/copyright'. Please add a 'Files: debian/*' section that will inform of > changes related to persons who have made contribution to the debian packaging > related files and directories. Some Debian Developers (DDs) will be hesitant > to sponsor a package without this section being included. For me it is good > for completeness and clarity. So far there are no signifant changes therein (none as much as 10 lines). For the debian directory, I see this: Author Files Commits Inserts Deletes Bastian Germann 1122 Debian Janitor 3291 Thomas E. Dickey18 42 489 172 TOTAL 18 45 500 175 where that "9" includes 6 lines inserted into the changelog file. I'll add an explicit debian/* pattern, to remind developers to update the copyright file if there are relevant changes in the future. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On Sat, Sep 14, 2024 at 02:08:44AM +0100, Phil Wyett wrote: > Control: tags -1 +moreinfo > > Thomas, > > Many thanks for addressing some of the issues raised. > > One lintian issue remains. > > I: luit source: unused-override no-debian-changes [debian/source/lintian- > overrides:2] On removing that file, I get this warning (and by the way do not see the warning which you report): > run-lintian luit_2.0.20240910-1.dsc luit_2.0.20240910-1_amd64.buildinfo luit_2 .0.20240910-1_amd64.changes N: W: luit source: no-debian-changes N: N: This non-native package makes no changes to the upstream sources in the N: Debian-related files. N: N: Maybe a mistake was made when the upstream tarball was created, or maybe N: this package is really a native package but was built non-native by N: mistake. N: N: Debian packaging is sometimes maintained as part of upstream, but that is N: not recommended as best practice. Please make this package native, if the N: software is only for Debian. Otherwise, please remove the debian directory N: from upstream releases and add it in the Debian packaging. N: N: Format 1.0 packages are subject to the restriction that the diff cannot N: remove files from the debian directory. For Format 3.0 packages, the N: debian directory is automatically purged during unpacking. N: N: Visibility: warning N: Show-Always: no N: Check: files/artifact N: Renamed from: empty-debian-diff N: -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On Sat, Sep 14, 2024 at 01:43:53PM +0100, Jeremy Sowden wrote: > On 2024-09-14, at 06:52:31 -0400, Thomas Dickey wrote: > > On Sat, Sep 14, 2024 at 02:08:44AM +0100, Phil Wyett wrote: > > > Control: tags -1 +moreinfo > > > > > > Thomas, > > > > > > Many thanks for addressing some of the issues raised. > > > > > > One lintian issue remains. > > > > > > I: luit source: unused-override no-debian-changes [debian/source/lintian- > > > overrides:2] > > > > On removing that file, I get this warning (and by the way do not see the > > warning which you report): > > > > > run-lintian luit_2.0.20240910-1.dsc luit_2.0.20240910-1_amd64.buildinfo > > > luit_2 > > .0.20240910-1_amd64.changes > > N: > > W: luit source: no-debian-changes > > N: > > N: This non-native package makes no changes to the upstream sources in the > > N: Debian-related files. > > N: > > N: Maybe a mistake was made when the upstream tarball was created, or > > maybe > > N: this package is really a native package but was built non-native by > > N: mistake. > > N: > > N: Debian packaging is sometimes maintained as part of upstream, but that > > is > > N: not recommended as best practice. Please make this package native, if > > the > > N: software is only for Debian. Otherwise, please remove the debian > > directory > > N: from upstream releases and add it in the Debian packaging. > > N: > > N: Format 1.0 packages are subject to the restriction that the diff cannot > > N: remove files from the debian directory. For Format 3.0 packages, the > > N: debian directory is automatically purged during unpacking. > > N: > > N: Visibility: warning > > N: Show-Always: no > > N: Check: files/artifact > > N: Renamed from: empty-debian-diff > > N: > > I've just cloned g...@salsa.debian.org:debian/luit, added the missing > upstream/2.0.20240910 tag, and built the package using gbp-buildpackage. > I got two lintian warnings: > > $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit 0 > W: luit source: orig-tarball-missing-upstream-signature > luit_2.0.20240910.orig.tar.gz > I: luit source: unused-override no-debian-changes > [debian/source/lintian-overrides:2] > N: 0 hints overridden; 1 unused override > > I deleted d/s/lintian-overrides, built the package again and got just > one: > > $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit 0 > W: luit source: orig-tarball-missing-upstream-signature > luit_2.0.20240910.orig.tar.gz > > Do you have local changes that you haven't pushed? no - I signed the tarball on the 10th, and exported the corresponding labeled version to github. However, when I set up this update on salsa (on gitlab, fetching from github...), it showed my signature as unverified. After some investigation, I re-added my public key, guessing that salsa was confused after I updated the expiration date a while back, probably in January. Most packagers use the tarballs, but a few of the Debian packages use github as the media (in a quick check, those are byacc, dialog and luit). After re-adding my public key, my subsequent commits show as verified. Perhaps what you're seeing is another symptom of that problem. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "byacc": * Package name: byacc Version : 1:2.0.20220114-1 Upstream Author : (Thomas E. Dickey) * URL : https://invisible-island.net/byacc/ * License : GPL-3, public-domain, other-BSD * Vcs : https://salsa.debian.org/debian/byacc Section : devel It builds those binary packages: byacc - public domain Berkeley LALR Yacc parser generator byacc2 - public domain Berkeley LALR Yacc parser generator, with back-tracking To access further information about this package, please visit the following URL: https://mentors.debian.net/package/byacc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/byacc/byacc_2.0.20220114-1.dsc Changes since the last upload: byacc (1:2.0.20220114-1) unstable; urgency=medium . * work around git-buildpackage's absence of configurability regarding uscan. * fix lintian issues reported in update. Regards, -- Thomas Dickey -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "luit": * Package name: luit Version : 2.0.20220111-1 Upstream Author : Thomas Dickey * URL : http://invisible-island.net/luit/ * License : GPL-3, X11 * Vcs : https://salsa.debian.org/dickey/luit Section : utils It builds those binary packages: luit2 - locale and ISO 2022 support for Unicode terminals To access further information about this package, please visit the following URL: https://mentors.debian.net/package/luit/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/luit/luit_2.0.20220111-1.dsc Changes for the initial release: luit (2.0.20220111-1) unstable; urgency=low . * Initial package release (Closes: #1003130) Regards, -- 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
On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > On 2022-01-15 Thomas Dickey wrote: > [...] > > I am looking for a sponsor for my package "byacc": > > > * Package name: byacc > >Version : 1:2.0.20220114-1 > >Upstream Author : (Thomas E. Dickey) > > * URL : https://invisible-island.net/byacc/ > > * License : GPL-3, public-domain, other-BSD > > * Vcs : https://salsa.debian.org/debian/byacc > >Section : devel > > > It builds those binary packages: > > > byacc - public domain Berkeley LALR Yacc parser generator > > byacc2 - public domain Berkeley LALR Yacc parser generator, with > > back-tracking > [...] > > Hello Thomas, > > I would like to question the introduction of another binary package: > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > "byacc2" only finds links related to this RFS. Ultimately that's because Debian's the only place where the older "btyacc" is packaged. > * The packages are tiny (about 100k) and have no conflicting files. > /usr/bin/byacc2 and /usr/bin/byacc could be shipped in on binary > package. yes, I could do that. I don't believe that would interfere with using the alternatives mechanism for selecting "yacc". I made them separate because I thought that would be the expected way. > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 I thought it would be the safest approach. I've made some effort to keep the two compatible, but sooner or later will get some bug report related to their differences. Debian's the usual place for that sort of thing. > incompatible with /usr/bin/byacc2? A quick glance at the yacc.1 seems > to suggests that /usr/bin/byacc2 is a backward compatible extension of > /usr/bin/byacc the only difference being that it additionally supports > | -B create a backtracking parser ...with these caveats: a) because of the backtracking support, the skeletons differ. b) backtracking can be slow However, Mageia and OpenSUSE provide packages for byacc with backtracking enabled. (I should make a list of the other packages, but the rpm's are easy to check at the moment). -- 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
On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: ... > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > I thought it would be the safest approach. I've made some effort to keep > the two compatible, but sooner or later will get some bug report related > to their differences. Debian's the usual place for that sort of thing. fwiw, the reference files in test/*yacc show that backtracking doesn't simply _add_ definitions: 155 files changed, 53852 insertions(+), 1785 deletions(-) (presumably reviewing those deletions would tell me whether two binaries are still needed). -- 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
On Sun, Jan 16, 2022 at 02:39:04PM +0100, ابو الغيث عليّ wrote: > Hello Thomas, > > What is the difference between Yacc and Lex GNU tools. > And Byacc or Bison?! bison has a lot of non-yacc extensions. I don't believe any third-party has made a list of differences. Consider this like the difference between pmake and "gmake". > Berkeley still a source of truthful tools and clean mainstream. "Berkeley" is long out of the picture. The various BSDs package both byacc and bison. I see byacc here: MacOS base has this, which isn't the original byacc 1.9, but rather a copy of what was in NetBSD: https://opensource.apple.com/tarballs/yacc/ but ports have this byacc: https://github.com/macports/macports-ports/blob/master/devel/byacc/Portfile https://formulae.brew.sh/formula/byacc (fwiw, Apple rarely updates tools such as this except as required for POSIX certification). FreeBSD has this byacc both in base and ports: https://svnweb.freebsd.org/base/head/usr.bin/yacc/ https://svnweb.freebsd.org/ports/head/devel/byacc/ NetBSD has retired their copy of byacc 1.9 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/yacc/?only_with_tag=MAIN in favor of this byacc: https://pkgsrc.se/devel/byacc OpenBSD has only byacc 1.9 copied from NetBSD, with minor changes: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/yacc/ (fwiw, OpenBSD's ports are a subset of pkgsrc, e.g., 9453 vs 18329). There's also DragonFly (also using this byacc): https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/usr.bin/yacc/Makefile https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/contrib/byacc > Do it keep byacc and blex. there's a similar story for lex, but I think that's off-topic. > Kind regards, > > > > > > > > > On Sun, 16 Jan 2022 at 14:09 Thomas Dickey wrote: > > > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > > ... > > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > > > I thought it would be the safest approach. I've made some effort to keep > > > the two compatible, but sooner or later will get some bug report related > > > to their differences. Debian's the usual place for that sort of thing. > > > > fwiw, the reference files in test/*yacc show that backtracking doesn't > > simply _add_ definitions: > > > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > > > (presumably reviewing those deletions would tell me whether two binaries > > are still needed). > > > > -- > > Thomas E. Dickey > > https://invisible-island.net > > ftp://ftp.invisible-island.net > > -- 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
On Sun, Jan 16, 2022 at 08:07:42AM -0500, Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > ... > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > I thought it would be the safest approach. I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > > fwiw, the reference files in test/*yacc show that backtracking doesn't > simply _add_ definitions: > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > (presumably reviewing those deletions would tell me whether two binaries > are still needed). reviewing one of those (e.g., a "calc" test-case which doesn't rely upon the backtracking features, and looking at the ".c" file), it seems to be properly ifdef'd so that the extra text is activated when the -B option is supported/used. There are a few spots where the code is reorganized to integrate the two flavors. There's one functional difference: The debugging output in the btyacc flavor goes to stderr, while the byacc flavor goes to stdout. (The manual page doesn't mention this - nor does it mention that -h goes to stderr) -- added a to-do... -- 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
On Sun, Jan 16, 2022 at 05:34:42PM +0100, Andreas Metzler wrote: > On 2022-01-16 Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > [...] > > > > I would like to question the introduction of another binary package: > > > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > > > "byacc2" only finds links related to this RFS. > > > Ultimately that's because Debian's the only place where the older "btyacc" > > is packaged. > > [...] > > > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance > > > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward > > > compatible extension of /usr/bin/byacc the only difference being > > > that it additionally supports > > > | -B create a backtracking parser > > > I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > [...] > > ...with these caveats: > > > a) because of the backtracking support, the skeletons differ. > > > b) backtracking can be slow > > > However, Mageia and OpenSUSE provide packages for byacc with backtracking > > enabled. > [...] > > Hello Thomas, > > afaict from > https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec > Fedora also builds without backtracking: > | # Revert default stack size back to 1 > | # https://bugzilla.redhat.com/show_bug.cgi?id=743343 > | find . -type f -name \*.c -print0 | > | xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 1/g' > | > | %build > | %configure --disable-dependency-tracking my configure script doesn't use that option. I see it in the initial 2007 commit on Fedora, but it's not been part of any version that I've provided. (it looks like old copy/paste from somewhere). Since the Fedora package is reasonably up-to-date (last August), I didn't get involved with that (yet). > | %make_build > > I would think that is something you need to solve upstream. It cannot be > a good thing(TM) if the same version of byacc is incompatible between > different major distributions. Don't you agree? yes... but the reminder was useful > With "solve" meaning, that you decide whether you intend to provide a > limited-feature-set binary forever, and starting from there decide on > the naming of old (if it shall exist) and new byacc. I reviewed the test-data differences, didn't see a problem, and verified with cproto (which uses lex/yacc) that there are no differences. So I updated the debian files to combine the two (just packaging one "byacc" with backtracking). I'll probably change the default in the upstream configure script to turn on backtracking, so that the packagers who didn't sign onto backtracking will get it by default. Fedora, for instance. But that's another byacc-update away. I see in my to-do list that I have some documentation issues, as well as improving leak-checking (and the usual wishlist...), but nothing that requires a new release. For now, I'm just working on the Debian package of the current release :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals
On Sat, Jan 22, 2022 at 03:54:37PM +0100, Bastian Germann wrote: > On Sat, 15 Jan 2022 09:31:08 -0500 Thomas Dickey wrote: > > Changes for the initial release: > > > > luit (2.0.20220111-1) unstable; urgency=low > > . > >* Initial package release (Closes: #1003130) > > > > Regards, > > d/copyright: Juliusz Chroboczek's copyright notice is only mentioned for one > of the files. odd, but I never noticed that, when copying the information from x11-utils. It's incorrect there. His name appears on 10 files: charset.c:5:Copyright (c) 2001 by Juliusz Chroboczek charset.h:5:Copyright (c) 2001 by Juliusz Chroboczek iso2022.c:5:Copyright (c) 2001 by Juliusz Chroboczek iso2022.h:5:Copyright (c) 2001 by Juliusz Chroboczek luit.c:5:Copyright (c) 2001 by Juliusz Chroboczek luit.h:5:Copyright (c) 2001 by Juliusz Chroboczek parser.c:5:Copyright (c) 2001 by Juliusz Chroboczek parser.h:4:Copyright (c) 2001 by Juliusz Chroboczek sys.c:5:Copyright (c) 2001 by Juliusz Chroboczek sys.h:5:Copyright (c) 2001 by Juliusz Chroboczek Looking for a tool, I've seen "debmake". "debmake -cc" merges the lists for all three authors (18 files), which is misleading. debmake also gives incorrect information for the configure/make scripts in a similar fashion. > Several other files include this as well. Tomohiro KUBOTA's copyright is also > misrepresented. I see his name on two files: other.c other.h However, inspecting the change history from XFree86, https://gitlab.freedesktop.org/ajax/xfree86 git://people.freedesktop.org/~libv/xfree86 there are changes to these: charset.c charset.h iso2022.c iso2022.h > I have invited you to https://salsa.debian.org/debian/luit. Please use > thatrepo goingforward. > > Thanks, > Bastian > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals
On Sat, Jan 22, 2022 at 10:39:33AM -0500, Thomas Dickey wrote: ... > Looking for a tool, I've seen "debmake". > > "debmake -cc" merges the lists for all three authors (18 files), > which is misleading. debmake also gives incorrect information > for the configure/make scripts in a similar fashion. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ says that a single paragraph "may" be used in this instance, but does not require it. In the merges noted above, the result is misleading, hence not an improvement. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals
On Sat, Jan 22, 2022 at 10:44:49AM -0500, Thomas Dickey wrote: > On Sat, Jan 22, 2022 at 10:39:33AM -0500, Thomas Dickey wrote: > ... > > Looking for a tool, I've seen "debmake". > > > > "debmake -cc" merges the lists for all three authors (18 files), > > which is misleading. debmake also gives incorrect information > > for the configure/make scripts in a similar fashion. debmake misidentifies MIT/X11 license text as "Expat". (It also misleads on "install-sh"). licensecheck does better (identifies the correct license), but gets confused about extracting license text from some commonly-used comment forms. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals
- Original Message - | From: "Thomas Dickey" | To: 1003...@bugs.debian.org | Cc: 1003770-submit...@bugs.debian.org | Sent: Saturday, January 22, 2022 11:43:05 AM | Subject: Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals | On Sat, Jan 22, 2022 at 10:44:49AM -0500, Thomas Dickey wrote: |> On Sat, Jan 22, 2022 at 10:39:33AM -0500, Thomas Dickey wrote: |> ... |> > Looking for a tool, I've seen "debmake". |> > |> > "debmake -cc" merges the lists for all three authors (18 files), |> > which is misleading. debmake also gives incorrect information |> > for the configure/make scripts in a similar fashion. | | debmake misidentifies MIT/X11 license text as "Expat". | (It also misleads on "install-sh"). see this: https://lists.gnu.org/archive/html/automake/2018-09/msg1.html -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Bug#1003770: RFS: luit/2.0.20220111-1 [ITP] -- locale and ISO 2022 support for Unicode terminals
On Sat, Jan 22, 2022 at 11:43:05AM -0500, Thomas Dickey wrote: > On Sat, Jan 22, 2022 at 10:44:49AM -0500, Thomas Dickey wrote: > > On Sat, Jan 22, 2022 at 10:39:33AM -0500, Thomas Dickey wrote: > > ... > > > Looking for a tool, I've seen "debmake". > > > > > > "debmake -cc" merges the lists for all three authors (18 files), > > > which is misleading. debmake also gives incorrect information > > > for the configure/make scripts in a similar fashion. > > debmake misidentifies MIT/X11 license text as "Expat". see https://invisible-island.net/ncurses/ncurses-license.html#issues_expat -- 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
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
Re: Bug#1013246: RFS: kmscon/9.0.0-1 [ITP] -- Simple terminal emulator based on Kernel Mode Setting
On Mon, Jun 20, 2022 at 12:52:20AM +0200, Adam Borowski wrote: > On Sun, Jun 19, 2022 at 11:02:54PM +0200, Victor Westerhuis wrote: > > * Package name: kmscon > >Version : 9.0.0-1 > > > kmscon (9.0.0-1) unstable; urgency=medium > > . > >* Initial release (Closes: #1004919) > > Hi! > I've uploaded to NEW, as the basic packaging looks good in general. > > Integration with Debian conventions, though, requires some work. > > The biggest problem: there's only a .service file but no init script, > making kmscon work only with systemd but not with any other init/rc > system. > > It fails to set term settings, making cooked mode not work until something The TSM developer says in the README: This library is very similar to libvte of the gnome project. However, libvte is highly bound to GTK+, which makes it unsuitable for non-graphics projects that need to parse escape sequences. Instead, TSM tries to restrict its API to terminal emulation only. Furthermore, TSM does not try to establish a new terminal emulation standard, but instead keeps compatibility as close to xterm as possible. This is why the TERM variable can be set to xterm-color256 with any TSM based terminal emulator. (because the terminal behavior doesn't come close to xterm, that's going to produce bug reports) > else (eg. bash) messes with them. This makes eg. backspace not work on > the login prompt. > > It probably should run getty instead of inventing its own stuff. > > /etc/issue should be printed before the login prompt. > > > There's also a bunch of upstreamish issues, such as application keypad mode > not working, or failing to either support existing mouse daemons (such as > consolation) or providing its own mouse handling, but such stuff seems more > fit for the upstream bug tracker. The libtsm upstream bug tracker doesn't show much recent activity (and glancing over the libtsm source, can readily see that there are a lot of problems yet to be reported - perhaps this package will do that). To start with, it's not "VT100 compatible". -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Bug#1013246: RFS: kmscon/9.0.0-1 [ITP] -- Simple terminal emulator based on Kernel Mode Setting
On Tue, Jun 21, 2022 at 04:13:40PM +0200, Victor Westerhuis wrote: > Op 20-06-2022 om 12:09 schreef Thomas Dickey: > > On Mon, Jun 20, 2022 at 12:52:20AM +0200, Adam Borowski wrote: > > > On Sun, Jun 19, 2022 at 11:02:54PM +0200, Victor Westerhuis wrote: > > > > * Package name: kmscon > > > > Version : 9.0.0-1 > > > > > > > kmscon (9.0.0-1) unstable; urgency=medium > > > > . > > > > * Initial release (Closes: #1004919) > > > > > > Hi! > > > I've uploaded to NEW, as the basic packaging looks good in general. > > > > > > Integration with Debian conventions, though, requires some work. > > > > > > The biggest problem: there's only a .service file but no init script, > > > making kmscon work only with systemd but not with any other init/rc > > > system. > > > > > > It fails to set term settings, making cooked mode not work until something > > > > The TSM developer says in the README: > > > >This library is very similar to libvte of the gnome project. However, > > libvte is > >highly bound to GTK+, which makes it unsuitable for non-graphics > > projects that > >need to parse escape sequences. Instead, TSM tries to restrict its API to > >terminal emulation only. Furthermore, TSM does not try to establish a new > >terminal emulation standard, but instead keeps compatibility as close to > > xterm > >as possible. This is why the TERM variable can be set to xterm-color256 > > with any > >TSM based terminal emulator. > > > > (because the terminal behavior doesn't come close to xterm, that's > > going to produce bug reports) > This text from the README is also included in the description of the binary > packages from src:libtsm. > > Do you think that the text needs to be changed for a next upload? Or should > I add a warning message? It won't have much effect :-) > > > else (eg. bash) messes with them. This makes eg. backspace not work on > > > the login prompt. > > > > > > It probably should run getty instead of inventing its own stuff. > > > > > > /etc/issue should be printed before the login prompt. > > > > > > > > > There's also a bunch of upstreamish issues, such as application keypad > > > mode > > > not working, or failing to either support existing mouse daemons (such as > > > consolation) or providing its own mouse handling, but such stuff seems > > > more > > > fit for the upstream bug tracker. > > > > The libtsm upstream bug tracker doesn't show much recent activity > > (and glancing over the libtsm source, can readily see that there are > > a lot of problems yet to be reported - perhaps this package will do that). > > > > To start with, it's not "VT100 compatible". > > > The upstream maintainer of the packaged libtsm fork is the same as the > upstream maintainer for kmscon and they've been very responsive when issues > came up while packaging kmscon and libtsm. I noticed (reading the source code of course) that it identifies itself via a DA1 response that doesn't correspond to any existing terminal, with non-VT100 options that turn out to be all unimplemented. > I will work with them to improve the quality for future releases. sounds good -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On Sat, Sep 14, 2024 at 08:13:29AM -0400, Thomas Dickey wrote: > On Sat, Sep 14, 2024 at 01:43:53PM +0100, Jeremy Sowden wrote: > > On 2024-09-14, at 06:52:31 -0400, Thomas Dickey wrote: > > > On Sat, Sep 14, 2024 at 02:08:44AM +0100, Phil Wyett wrote: > > > > Control: tags -1 +moreinfo > > > > > > > > Thomas, > > > > > > > > Many thanks for addressing some of the issues raised. > > > > > > > > One lintian issue remains. > > > > > > > > I: luit source: unused-override no-debian-changes > > > > [debian/source/lintian- > > > > overrides:2] > > > > > > On removing that file, I get this warning (and by the way do not see the > > > warning which you report): > > > > > > > run-lintian luit_2.0.20240910-1.dsc luit_2.0.20240910-1_amd64.buildinfo > > > > luit_2 > > > .0.20240910-1_amd64.changes > > > N: > > > W: luit source: no-debian-changes > > > N: > > > N: This non-native package makes no changes to the upstream sources in > > > the > > > N: Debian-related files. > > > N: > > > N: Maybe a mistake was made when the upstream tarball was created, or > > > maybe > > > N: this package is really a native package but was built non-native by > > > N: mistake. > > > N: > > > N: Debian packaging is sometimes maintained as part of upstream, but > > > that is > > > N: not recommended as best practice. Please make this package native, > > > if the > > > N: software is only for Debian. Otherwise, please remove the debian > > > directory > > > N: from upstream releases and add it in the Debian packaging. > > > N: > > > N: Format 1.0 packages are subject to the restriction that the diff > > > cannot > > > N: remove files from the debian directory. For Format 3.0 packages, the > > > N: debian directory is automatically purged during unpacking. > > > N: > > > N: Visibility: warning > > > N: Show-Always: no > > > N: Check: files/artifact > > > N: Renamed from: empty-debian-diff > > > N: > > > > I've just cloned g...@salsa.debian.org:debian/luit, added the missing > > upstream/2.0.20240910 tag, and built the package using gbp-buildpackage. > > I got two lintian warnings: > > > > $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit > > 0 > > W: luit source: orig-tarball-missing-upstream-signature > > luit_2.0.20240910.orig.tar.gz > > I: luit source: unused-override no-debian-changes > > [debian/source/lintian-overrides:2] > > N: 0 hints overridden; 1 unused override > > > > I deleted d/s/lintian-overrides, built the package again and got just > > one: > > > > $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit > > 0 > > W: luit source: orig-tarball-missing-upstream-signature > > luit_2.0.20240910.orig.tar.gz > > > > Do you have local changes that you haven't pushed? > > no - I signed the tarball on the 10th, and exported the corresponding labeled > version to github. > > However, when I set up this update on salsa (on gitlab, fetching from > github...), it showed my signature as unverified. > > After some investigation, I re-added my public key, guessing that salsa was > confused after I updated the expiration date a while back, probably in > January. Most packagers use the tarballs, but a few of the Debian packages > use github as the media (in a quick check, those are byacc, dialog and luit). > > After re-adding my public key, my subsequent commits show as verified. > > Perhaps what you're seeing is another symptom of that problem. > > -- > Thomas E. Dickey > https://invisible-island.net -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On Sat, Sep 28, 2024 at 10:03:16AM -0400, Thomas Dickey wrote: ... I believe that I answered the questions, but don't see a followup. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
