[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing
Sean Whitton <spwhit...@spwhitton.name> writes: > Hello Jérémy, > > On Tue, Oct 03 2017, Jérémy Lal wrote: > >> It might be a good idea to make policy more explicit about downloads >> during build. > > I'm not sure how it could be more explicit: > > For packages in the main archive, no required targets may attempt > network access. The problem seems to be that Praveen reads that prohibition as implying that it is totally OK to do this when not in main. This strikes me as equivalent to reading: All men are mortal, Socrates is a man, and concluding that women are immortal. The correct way to read this bit of policy is that network access during build is considered such a bad idea that it is not allowed under any circumstances in Debian proper (main). That being the case, it is a safe bet to assume that it's a bad idea in packages in contrib and non-free too. If one wants to vary from that, the reason should be made very clear indeed. I don't believe that Praveen has provided any real justification for needing network access, beyond his opinion that policy allows it. I suspect that in the particular case of using rollup, it is even worse than Simon McVittie eloquently describes in his mail to this thread. A quick read of rollup's changelog shows that they have had about 30 releases since July, that they've recently had a major refactoring, and that every release since that refactoring has involved fixing that refactoring. They had a release within a day of Praveen's changelog entry for the package, so it's not completely obvious which version of rollup would have been used for the package build, but chances are that he used one version, and that within 24 hours nobody, not even Praveen, would be certain of being able to reproduce that package because it would then be using a new version of rollup to do all the work. They've had another release since -- more fixups for the refactoring. I'm astonished that Praveen thinks it is sensible to build on these shifting sands. My astonishment is then only magnified at every step: o When it is pointed out, still not realising the folly of this. o Running to policy, looking for excuses. o Blaming ftp masters for not noticing these flaws. o Insisting that the TC needs to be involved to fix the mess Should we really try to make policy forbid all the foolish ways in which one might try to assemble a package, in order to ensure that there is nowhere for people to hide in policy? I think not. It would seem much more straightforward to remove the upload rights from people who insist on repeating this sort of behaviour incessantly. Praveen, please don't do it again. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP 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
[Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Jérémy Lal <kapo...@melix.org> writes: > 2017-08-30 11:50 GMT+02:00 Philip Hands <p...@hands.com>: > >> Jérémy Lal <kapo...@melix.org> writes: >> >> > 2017-08-29 21:39 GMT+02:00 Didier 'OdyX' Raboud <o...@debian.org>: >> > >> >> Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit : >> >> > Leave /usr/bin/nodejs there for at least one more release. >> >> >> >> I'll just note for the purpose of the TC discussion that as of nodejs >> >> 6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs >> → >> >> node >> >> symlink still exists, so at this point, I don't consider there is >> material >> >> for >> >> a TC decision either way, but it's an important conversation to be had. >> >> >> >> Jérémy: could you maybe clarify your plan and your rationale? This would >> >> help >> >> putting everyone on common grounds. >> >> >> > >> > I replaced /usr/bin/nodejs by /usr/bin/node, and made a symlink from >> > /usr/bin/nodejs to /usr/bin/node. >> > My plan was to simply keep /usr/bin/nodejs around for some time until >> > no debian package rely on it. The JavaScript debian team wiki is updated >> > to reflect that. >> >> I was against the TC instructing you how to behave in detail in our >> resolution, because I couldn't imagine that anyone would think that >> tidiness was more important than not breaking things for our users. >> >> Are you really going to prove me wrong? >> >> How much is it costing you to keep the symlink there? >> >> Do you expect that cost to ever exceed the effort of responding to even >> the first bug reported about this, when you turn out to have broken >> someone's locally-written script? >> >> Actually, do you expect it to ever exceed the effort already wasted in >> responding to this thread by you and us? >> >> It's pretty clear that if you do decide to go ahead and remove >> /usr/bin/nodejs quickly, that someone is likely to kick the matter back >> up to the TC. >> >> I for one will have absolutely no sympathy with your side of the case at >> that point, not only because I think it is senseless, but also because >> you'll have been responsible for wasting the time of all involved. >> >> I will also not be even slightly timid about micro-managing you the >> second time around, since if that comes to pass you'll have demonstrated >> the need. > > > Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs > until it's no longer needed - be it other debian packages or other user > scripts. > If it was to be really removed, it shouldn't be done without some > deprecation > warning and time for users to notice and change their code. Ah, well -- that's all fine then. Thanks for clarifying. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP 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
[Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Jérémy Lal <kapo...@melix.org> writes: > 2017-08-29 21:39 GMT+02:00 Didier 'OdyX' Raboud <o...@debian.org>: > >> Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit : >> > Leave /usr/bin/nodejs there for at least one more release. >> >> I'll just note for the purpose of the TC discussion that as of nodejs >> 6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs → >> node >> symlink still exists, so at this point, I don't consider there is material >> for >> a TC decision either way, but it's an important conversation to be had. >> >> Jérémy: could you maybe clarify your plan and your rationale? This would >> help >> putting everyone on common grounds. >> > > I replaced /usr/bin/nodejs by /usr/bin/node, and made a symlink from > /usr/bin/nodejs to /usr/bin/node. > My plan was to simply keep /usr/bin/nodejs around for some time until > no debian package rely on it. The JavaScript debian team wiki is updated > to reflect that. I was against the TC instructing you how to behave in detail in our resolution, because I couldn't imagine that anyone would think that tidiness was more important than not breaking things for our users. Are you really going to prove me wrong? How much is it costing you to keep the symlink there? Do you expect that cost to ever exceed the effort of responding to even the first bug reported about this, when you turn out to have broken someone's locally-written script? Actually, do you expect it to ever exceed the effort already wasted in responding to this thread by you and us? It's pretty clear that if you do decide to go ahead and remove /usr/bin/nodejs quickly, that someone is likely to kick the matter back up to the TC. I for one will have absolutely no sympathy with your side of the case at that point, not only because I think it is senseless, but also because you'll have been responsible for wasting the time of all involved. I will also not be even slightly timid about micro-managing you the second time around, since if that comes to pass you'll have demonstrated the need. Be warned. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP 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
[Pkg-javascript-devel] Bug#855147: node-os-browserify: The ITP mentioned 'os' in the short description, but that has been lost in the upload
Package: node-os-browserify Severity: normal Dear Maintainer, I think you should use a short description of: 'os' module from node.js, but for browsers. or perhaps: provides an 'os' module for use with browserify As it is, the short description does not make it clear that this module stands in for the standard 'os' module. In fact it makes it seem like it might be a polyfill, which I assume it is not, in fact. Cheers, Phil. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-tty-browserify_0.0.0-1_amd64.changes REJECTED
Pirate Praveen <prav...@onenetbeyond.org> writes:
...
> "This module is a dependency for browserify." is already present in
> the description. And short description says "tty module from node core
> for browsers".
That presumably makes sense to people that know what node is.
I'm somewhat aware what it means, having pondered quite a lot of these
ITPs, but it is pretty close to nonsense.
Someone that does not know what node is needs to decide if that should
be read to mean one of:
tty module from [node core for browsers]
or
tty module from node core, for browsers
or perhaps something else.
Having done that, they then need to wonder what a tty module might be.
Then again, they could try looking at the code, which astonishingly does
nothing other than throw errors about how none of this is implemented,
except in the case of the one function that does anything ('isatty')
which unconditionally returns false.
That being the case, one might have hoped for a description saying
something like:
stub version of tty, to (barely) satisfy browserify's dependencies
The description that you are attempting to defend has been lifted,
unedited, from the github repository.
I'd suggest that it was already misleading to the audience that it was
aimed at, which is not the audience it is now being misapropriated for.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP 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
[Pkg-javascript-devel] Bug#840721: node-escodegen: FIX_ME long description
Package: node-escodegen Followup-For: Bug #840721 Hi Praveen, Prompted by your request for help with descriptions, here's one. I'm sure it is possible to come up with a better description than this, but at least this gets rid of the FIX_ME problem. Cheers, Phil. >From 33f38ea82ab07f174b79700dd18860474dd0332c Mon Sep 17 00:00:00 2001 From: Philip Hands <p...@hands.com> Date: Sat, 7 Jan 2017 23:02:12 +0100 Subject: [PATCH] add a long description, of sorts (closes: 840721) --- debian/changelog | 6 ++ debian/control | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 01bfbfc..52f37be 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +node-escodegen (1.8.1+dfsg-2) UNRELEASED; urgency=medium + + * add a long description, of sorts (closes: 840721) + + -- Philip Hands <p...@hands.com> Sat, 07 Jan 2017 22:55:42 +0100 + node-escodegen (1.8.1+dfsg-1) unstable; urgency=low * Initial release (Closes: #840615) diff --git a/debian/control b/debian/control index c98b3bf..0451355 100644 --- a/debian/control +++ b/debian/control @@ -23,6 +23,7 @@ Depends: , node-esutils (>= 2.0.2) , node-esprima (>= 2.7.1) Description: ECMAScript code generator - FIX_ME long description + This is an ECMAScript (also popularly known as JavaScript) code generator + from Mozilla's Parser API AST. . Node.js is an event-based server-side JavaScript engine. -- 2.11.0 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Fri, 4 May 2012 19:00:10 +0200, Pau Garcia i Quiles pgqui...@elpauer.org wrote: ... Agreed. That's why my proposal was that *all* of those (Debian, Fedora, Suse, MacPorts and brew) did the rename, not just us (Debian). It's certainly not nice to push upstream to do something they don't want to do, but when upstream is not doing their due diligence... As a lapsed HAM who's not transmitted anything for about 20 years, and someone vaguely aware of node.js, I feel relatively unbiased about this. How about doing the following: node package replaced by a node-legacy package that contains no more than a README and a symlink node -- ax25-node, and depends on ax25-node ax25-node package, which contains what node does now, with the binary renamed nodejs package replaced by a node.js-legacy (or a better name if there is one) package that contains no more than a README and a symlink node -- node.js (or whatever), and depends on node.js node.js package that is the nodejs package with a renamed binary. and make node-legacy and node.js-legacy conflict. The problems with this would seem to be the potential pain of renaming packages, and the fact that using conflicts like that is a policy violation -- could we perhaps make an exception for a case like this on the basis that the package descriptions could spell out why the conflict is there. The result would be that either camp can install the -legacy package and carry on unaffected, and anyone that needs both simply avoids the -legacy packages, and fixes any hard-coded paths on their system, which they'll know to do because they'll be a (probably more cluefull than average) combined HAM and Node.js user who's been pointed at the READMEs by the conflict and the package descriptions. The -legacy naming will apply a gentle pressure to just use the real packages, which will leave the door open to upstreams to see the light and change their default name, but not so much pressure that they'll get upset about it. The READMEs of all the packages could refer to why this was done, and how to get what you want depending one which of the various permutations of behaviours you want. So this would need package replacement, which is a pain, and an exception for a policy violation -- is that enough to kill the idea? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpl7vKwFiPBK.pgp Description: PGP 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
