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
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#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
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
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
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#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 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
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 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#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#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 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 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 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#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
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#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 dic...@invisible-island.net 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 dic...@invisible-island.net 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
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 dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
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 dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
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
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]
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: 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: 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]
