Re: [Pkg-javascript-devel] Bug#733586: closure-compiler: new upstream version available
Hello Thomas and Tony, CCing Javascript team (JS Team, please see below for why), and fixing threading, since top-posting is confusing. Reply follows inline: Thomas Koch writes: >> tony mancill hat am 29.03.2022 07:26 geschrieben: >> > On Mon, Mar 28, 2022 at 03:27:17PM -0400, Nicholas D Steeves wrote: >> > >> > This package came to my attention via #975505, where it was noted that >> > MathJax2 has had to disable functionality because of too ancient of a >> > closure-compiler, and at this time it appears that MathJax3 will have to >> > do the same. >> > >> > Closure-compiler is a candidate for salvaging: >> > >> > https://wiki.debian.org/PackageSalvaging >> > >> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging >> > >> > The ideal resolution would be for one of the listed Uploaders to resume >> > maintenance of the package, but orphaning is of course also an option :-) >> >> The closure-compiler package is officially a team-maintained package by >> the Java Team, so you or anyone else who is interested in joining Java >> Team and maintaining the package is welcome to do so. That is, please >> feel free to add yourself to Uploaders. >> >> That said, it's more of a JavaScript tool than a Java package, and so >> the package could also be moved to another team if that's preferable. >> >> I will gladly help with either of those options, or with reviewing and >> sponsoring an upload of a newer version if one is made available. >> >> Finally, I have never been a user of closure-compiler - my packaging >> work on it has been under the Java Team umbrella - and I have >> (obviously) been unable to devote sufficient time to it. I will remove >> myself from Uploaders to avoid any future confusion. >> > > Hello, > > sorry, I was under the wrong impression that closure-compiler would be > abandoned upstream and that it would eventually die of age and be > removed. I packaged closure-compiler as a dependency of the code > review system Gerrit which however couldn't be packaged at the time > due to GWT. > > Whoever does another upload to closure-compiler please also remove me > from uploaders. > > Thank you! > Thank you both for your quick reply! Your clarification and context is much appreciated :-) While closure-compiler is currently under the Java Team umbrella, removing both human uploaders will create a Policy §3.3 violation (the need for a human Maintainer/Uploader is unfulfilled): https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer Closure-compiler must be formally orphaned for this reason. There is additionally a practical reason to orphan it: The maintainers of all packages that depend on it will receive a Package Tracker notification that it is unmaintained; This includes transitive dependencies via MathJax2 (sigil, pandoc, etc). Furthermore, it will show up on the list of packages that prospective DMs and DDs investigate as part of their process. If I remember correctly the orphan bug will also appear for developers who have the "how-can-i-help" package installed. Thus, please file the wnpp Orphan bug, because it's clearly the correct avenue forward, and because it maximises the chance of finding a new maintainer. Cheers! Nicholas signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#960269: RFP: afterwriting -- Afterwriting provides post-processing tools for Fountain screenplays
Package: wnpp Severity: wishlist Control: block 960268 by -1 Package name: afterwriting Version : 1.12.9 Upstream Author : Piotr Jamróz URL : https://afterwriting.com and/or https://github.com/ifrost/afterwriting-labs specifically : https://github.com/ifrost/afterwriting-labs/blob/master/docs/clients.md License : MIT Programming Lang: JS Description : Afterwriting provides post-processing tools for Fountain screenplays Afterwriting provides post-processing tools for Fountain screenplays: * converts Fountain format to PDF * extracts basic screenplay info (number of pages, action/dialogue time, locations, etc.) * gathers statistics (location distribution, page balance, dialogue, etc.) * experimental features (script pulse, primary/secondary characters, etc.) -- I am interested exclusively in the CLI component. Features provided by other parts of the source: * loading and syncing with Google Drive / Dropbox (online version only) * importing .fdx (FinalDraft) <=NOTE= I'm not sure if this is included in awc.js * basic editor with auto-complete <=NOTE= should be skipped IMHO. Emacs and Atom are better. A GNOME HIG-compliant editor will probably appear in the next two years -- My interest in this package springs from Emacs' elpa-fountain-mode. A recent upstream update dropped export to PDF support, so I haven't updated it, because without Afterwriting this would represent a regression in functionality. To the best of my knowledge this is the best Fountain2PDF export tool. 'hope this RFP piques someone's interest! Nicholas -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Bug#944826: RFP: libjs-jquery-stickytableheaders -- stick table headers to the top of a viewport when scrolling
Dear JavaScript Team, I would sincerely appreciate it if someone would take a look at this RFP :-) Please CC this bug for any replies. Thanks! Nicholas On Fri, Nov 15, 2019 at 09:16:41PM -0500, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > Control: block 944704 by -1 > > Package name: libjs-jquery-stickytableheaders > Version : 0.1.24 > Upstream Author : Jonas Mosbech > URL : https://github.com/jmosbech/StickyTableHeaders > License : MIT > Programming Lang: JS > Description : stick table headers to the top of a viewport when scrolling > > StickyTableHeaders is a jQuery plugin that sticks table headers to the > top of a viewport. When scrolling through a long vertical list it > is easy for forget what header each column refers to. > StickyTableHeaders solves this issue by keeping column headers visible > at all times so that the user doesn't need to regularly scroll to the > top of a table. > > Upstream demo: https://jsfiddle.net/jmosbech/stFcx/ > > I discovered this package while working on org-html-themes, which > depends on StickyTableHeaders. Other than that, I am frequently > frustrated by websites that exhibit the issue this software solves > (eg: Wikipedia has this issue). While I'm generally sympathetic to > the "nojs" approach to web browsing, I believe that most users of > "nojs" would probably white-list StickyTableHeaders, because of how it > dramatically enhances the experience of reading long tables. I am not > aware of other packages that provide this functionality. > > Please consider packaging it soon! :-) > > > Thank you, > Nicholas signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#944826: RFP: libjs-jquery-stickytableheaders -- stick table headers to the top of a viewport when scrolling
Package: wnpp Severity: wishlist Control: block 944704 by -1 Package name: libjs-jquery-stickytableheaders Version : 0.1.24 Upstream Author : Jonas Mosbech URL : https://github.com/jmosbech/StickyTableHeaders License : MIT Programming Lang: JS Description : stick table headers to the top of a viewport when scrolling StickyTableHeaders is a jQuery plugin that sticks table headers to the top of a viewport. When scrolling through a long vertical list it is easy for forget what header each column refers to. StickyTableHeaders solves this issue by keeping column headers visible at all times so that the user doesn't need to regularly scroll to the top of a table. Upstream demo: https://jsfiddle.net/jmosbech/stFcx/ I discovered this package while working on org-html-themes, which depends on StickyTableHeaders. Other than that, I am frequently frustrated by websites that exhibit the issue this software solves (eg: Wikipedia has this issue). While I'm generally sympathetic to the "nojs" approach to web browsing, I believe that most users of "nojs" would probably white-list StickyTableHeaders, because of how it dramatically enhances the experience of reading long tables. I am not aware of other packages that provide this functionality. Please consider packaging it soon! :-) Thank you, Nicholas -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
