[Pkg-javascript-devel] Bug#999497: lintian: complain about packages with parts of npm2deb FIX_ME or templates still present
Package: lintian Version: 2.111.0 Severity: wishlist X-Debbugs-CC: npm2...@packages.debian.org npm2deb converts node/npm packages to Debian source packages, in the process it leaves FIX_ME items and template info in various places in the Debian source package for the maintainer to clean up before upload. Sometimes these FIX_ME items even get past the NEW queue (for example node-winston). I looked at the npm2deb source code and found several strings that need to be checked for. There may be some more strings that I missed though. Note that the description_template string could contain an upstream_description string, so you will need to check for the prefix and suffix instead of the whole string. PS: I wonder if there should be a standard prefix for all template strings that all packaging tools could use in their templates or template strings and then lintian could just check for that prefix. https://wiki.debian.org/AutomaticPackagingTools npm2deb/__init__.py: self.debian_license = "FIX_ME debian license" self.debian_author = 'FIX_ME debian author' args['Description'] = 'FIX_ME write the Debian package description' self.upstream_license = "FIX_ME upstream license" self.upstream_version = 'FIX_ME version' self.upstream_description = 'FIX_ME no upstream package description' result = 'FIX_ME upstream author' result = 'FIX_ME repo url' npm2deb/templates.py: description_template = """ Write the short and long descriptions for the Debian package as explained in the Developer's Reference, §6.2.1 – §6.2.3. . You can start with the short upstream package description, “%(upstream_description)s”. . Be aware that most upstream package descriptions are not written to conform with Debian package guidelines. You need to explain the role of this package for a Debian audience. . Node.js is an event-based server-side JavaScript engine. """ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part -- 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] New "ctype" option in uscan
On Mon, Nov 30, 2020 at 9:11 AM Xavier wrote: > I added a new feature in uscan to help uscan comparison when components > are embedded, especially when "checksum" target is used: if "ctype" > exists, uscan will use "version" value from package.json (JavaScript) or > META.json (Perl) to get current component value. This reminds me of a similar feature in the fakeupstream redirector: https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=github_commits_package_json/olov/stringmap https://qa.debian.org/cgi-bin/fakeupstream.cgi?file=CMakeLists.txt;type=cmake;upstream=github_commits_package_json/fhackenberger/ktikz -- bye, pabs https://wiki.debian.org/PaulWise -- 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] node-fn.name vs node-fn-name
On Thu, 2020-11-05 at 07:17 +0200, Andrius Merkys wrote: > I was aware of node-fn-name at the time I uploaded node-fn.name. > However, due to my lack of experience with NodeJS I did not compare the > packages to understand the difference of their APIs and functionality. I > would love to deduplicate (maybe by removing node-fn.name which should > have less reverse dependencies), but I need someone to confirm that > these packages could be used interchangeably, or provide patching > suggestions if APIs are different. Based solely on the usage information in the README, their APIs are compatible, so just changing from fn.name to fn-name or vice versa in the require() call will be enough to switch between them. I'm not sure which one is better, but fn-name started earlier and has more recent commits than fn.name. The fn-name README inspires more confidence in me since the example uses const instead of var to store the name finding function. I don't know much about JavaScript nor NodeJS, but my intuition says const seems to be more correct for importing functions. StackOverflow agrees: https://stackoverflow.com/questions/55948935/const-vs-var-in-nodejs-require-statement I noticed that neither fn-name nor fn-name have any reverse dependencies in Debian so perhaps they should just both be removed? I also noticed that fn-name is outdated in Debian compared to upstream. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part -- 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] node-fn.name vs node-fn-name
Hi all, [Please CC me on reply] Based on the GitHub descriptions, node-fn.name and node-fn-name have identical functionality. Should one of them be removed from Debian and should one of the upstream projects be replaced by the other within the NodeJS ecosystem? It seems pointless to have both exist. https://github.com/sindresorhus/fn-name https://github.com/3rd-Eden/fn.name -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part -- 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] twemoji packaging: Fonts question
On Sat, 2020-09-12 at 11:31 +0200, Felix Natter wrote: > Unfortunately, ndo...@twitter.com bounces: ... > Shall I just package twemoji since it's unlikely that it's non-free? I would try to contact other recent contributors to the project or if that fails just open an issue on github to discuss it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part -- 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] twemoji packaging: Fonts question
On Sun, 2020-08-23 at 10:34 +0200, Felix Natter wrote: > I did not find an email address on github Normally you can get an email address by appending .patch to the commit URL, but in this case the commit is too big to do that. So you will have to clone the repository and show the commit to get the email. https://github.com/twitter/twemoji/commit/d008619cc043b65bc6283f2b0d882b8d088811c2.patch git clone https://github.com/twitter/twemoji.git cd twemoji git show d008619cc043b65bc6283f2b0d882b8d088811c2 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part -- 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] twemoji packaging: Fonts question
On Sun, Aug 9, 2020 at 2:34 PM Felix Natter wrote: > 2. quoting Jonas: > "Speaking of SVGs, are you sure this is the real source of those SVG > files? It seems amchine-generated to me, and I suspect there is real > concern as to freedom aspects of distributing only as provided here. > Even if you choose to use the JavaScript team as platform for your > package maintenance, I recommend that you discuss the issue of source of > fonts with the font team, as there is collected quite some knowledge and > experience in that team." While the SVG files are clearly not hand-written with a text editor, that doesn't necessarily mean that they aren't source, they could be edited using a GUI editor, and SVG files often are edited with GUI editors like Inkscape. Unfortunately they don't have any metadata to indicate how they were created, so only upstream is able to answer whether or not they are source files or not. OTOH Looking at the git repository, there is some indication that they are using Adobe Illustrator to edit the files; there is a commit message "Remove the AI assets, as this is a proprietary format and the SVGs should suffice for editing". It isn't clear to me if this means they no longer use the AI files and use Adobe Illustrator to edit the SVG files or if they still use the AI files but keep them secret for internal use but expect downstream folks to be fine just editing the SVG files. The way that the commits that update the SVG/PNG files (just dumping a whole bunch of changes into one commit, instead of logical commits) and the fact that the PNG files have no automatic build system makes me think that the AI files are still the source and they are in an internal-to-Twitter project that just sends a pre-built SVG/PNG dump to the GitHub project every once in a while. https://github.com/twitter/twemoji/commit/d008619cc043b65bc6283f2b0d882b8d088811c2 So I suggest contacting the project to discuss how they develop the SVGs. Also, sending them a patch for one of the SVGs would be an interesting way to test where their actual source is. Probably asking them to autobuild the PNG files would be a good idea too. -- bye, pabs https://wiki.debian.org/PaulWise -- 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] Browserified copy and DFSG
On Fri, Sep 7, 2018 at 7:22 PM, Bastien ROUCARIES wrote: > Ok adding cc @security > > How will you handle security problem in static > (browserified/webpacked) javascript library ? Same goes for the other languages that do static linking. It would be great to have this wiki page updated with some realistic strategies: https://wiki.debian.org/StaticLinking IIRC the security team recently flagged Go packages as being problematic for security support in the Debian buster release. I guess the same will apply to Rust now that Firefox switched to it? -- bye, pabs https://wiki.debian.org/PaulWise -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
