praveen at debian.org
Thu Feb 1 16:11:48 UTC 2018
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.
> 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
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 at sid:~/src/node-openpgp$ npm2deb depends -b openpgp
> 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 at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 862 bytes
Desc: OpenPGP digital signature