On വ്യാഴം 01 ഫെബ്രുവരി 2018 09:04 വൈകു, Daniel Kahn Gillmor wrote: > Thanks for the suggestions, Praveen and Jérémy! > > On Thu 2018-02-01 16:30:41 +0530, Pirate Praveen wrote: >> This is a bug in node-node-uuid, which is reported already. A workaround >> is to use older version of the deb from buster. > I supposed you're talking about https://bugs.debian.org/887069 which it > looks like Jonas just fixed. thanks! I've merged it with three other > reports, including my own. > >> salsa.debian.org/js-team > It looks like i haven't been added to this team yet. Is there an > interest in team maintenance of OpenPGP.js, or any of its > build-dependencies? I think it would be a good thing to maintain it in team. Since many dependencies are shared with packages already maintained in team. > If so, i'd request to join the team and i'd try to follow team standards > if i can find them. If there's no interest in co-maintenance, then i'd > just as soon put everything in the debian/ namespace and follow my own > packaging practices. But i'd really prefer to co-maintain if there's an > offer there. If there is, can i be added to the js-team group? You can request access to the team. > > As for OpenPGP.js, I'm concerned because of the build-time dependency > tree reported by npm2deb: > > 0 dkg@sid:~/src/node-openpgp$ npm2deb depends -b openpgp > Dependencies: > NPM Debian > openpgp (2.6.2) None > ├─ node-fetch (^1.3.3) node-fetch (1.7.3-1) > └─ node-localstorage (~1.3.0) None > > 0 dkg@sid:~/src/node-openpgp$ npm2deb depends -B openpgp > Build dependencies: > NPM Debian > asmcrypto-lite (^1.0.0) None > babel-core (^6.26.0) None > babel-preset-es2015 (^6.3.13) None > babelify (^8.0.0) None > browserify-derequire (^0.9.4) None > chai (~4.1.2) node-chai (4.1.2+dfsg-1) > es6-promise (^4.1.1) node-es6-promise > (4.1.1+ds-2) > grunt (~1.0.1) grunt (1.0.1-8) > grunt-browserify (~5.2.0) None > grunt-contrib-clean (~1.1.0) node-grunt-contrib-clean > (1.0.0-1) > grunt-contrib-connect (~1.0.2) None > grunt-contrib-copy (~1.0.0) node-grunt-contrib-copy > (1.0.0-2) > grunt-contrib-jshint (~1.1.0) None > grunt-contrib-uglify (~3.2.1) node-grunt-contrib-uglify > (2.0.0+dfsg-1) > grunt-contrib-watch (^1.0.0) None > grunt-jsbeautifier (~0.2.10) None > grunt-jscs (^3.0.1) None > grunt-jsdoc (~2.2.0) None > grunt-mocha-istanbul (^5.0.1) None > grunt-mocha-test (~0.13.3) None > grunt-saucelabs (9.0.0) None > grunt-text-replace (~0.4.0) None > istanbul (~0.4.1) None > mocha (~4.0.1) node-mocha (4.0.1-3) > rusha (^0.8.3) None > sinon (^1.17.3) node-sinon (1.17.6-1) > whatwg-fetch (~2.0.3) libjs-fetch (2.0.3-1) > zlibjs (~0.3.1) None > > > This seems to imply that we might need to review, build, and maintain > ~20 new debian packages in order to be able to build and maintain > OpenPGP.js in debian. is that right? I'm hoping that some of these are > inappropriate or unnecessary for the debian build -- like hooks into > external continuous integration systems (grunt-saucelabs? > grunt-contrib-connect? which clearly won't be run from the debian > buildds), or fallback-polyfill stuff (asmcrypto-lite? rusha? zlibjs?) > that we can skip because our own dependency management can ensure that > it's not needed. I have replied to your ITP about grunt. Yes, many of this can be ignored. You will need to replace browserify with webpack. > But i don't know how to judge these decisions yet. > > I'm also noticing that things like babel-preset-es2015 and babel-core > are listed as "None" in the output above, though > node-babel-preset-es2015 and node-babel-core appear to be present in > sid. so maybe npm2deb is confused? yes, its a bug in npm2deb. > lastly, it looks to me like the boilerplate dropped by npm2deb still > points to alioth, not salsa. > That should be updated, for this as well as in npm2deb. >> We usually work with tarballs and use gbp import-dsc --pristine-tar for >> the dsc file created by npm2deb create. > is there a specific example that you want to point me (and other > relative newbies) to that is well-maintained and modern? for example, i > work with tarballs too, but i prefer to link them to upstream's revision > control history (e.g. i put upstream-vcs-tag into debian/gbp.conf where > possible) so that the relationships between the threads of development > are visible in git. It is just how we have been working. May be you can convince the team to switch to that workflow. > any and all guidance welcome! > > --dkg
signature.asc
Description: OpenPGP digital signature
-- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
