[Pkg-javascript-devel] uploading new browserify-lite version
Hi Jérémy, Daniel is interested in browserify-lite and I have completed and packaged up some feature requests that he had. He has offered to upload the new version this time. Daniel, I have done all the packaging and created the tag etc. All that remains is for you to check out the code from git, use gbp to build it, and upload it. Cheers, Andrew ___ 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-nan update
On Sun, May 17, 2015 at 12:51 AM Jérémy Lal kapo...@melix.org wrote: can you check if that goes well with reverse build dependencies please ? Yes. Fortunately the only reverse build dependencies are node-leveldown (which I am working on) and node-ws, which is supposed to be on nan version 1.8.x anyway. ___ 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] node-nan update
Hi Jérémy, I'm working on updating node-leveldown to the new upstream release and I need a newer node-nan release to do so. Want some help with node-nan? ___ 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#778568: unblock: node-findit2/2.2.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package node-findit2 The package build-depends on node-tap, a buggy package. However, this dependency is strictly optional and is only used to run upstream tests. Further, there are many examples of Debian JavaScript packages which have tests disabled. diff -Nru node-findit2-2.2.3/debian/changelog node-findit2-2.2.3/debian/changelog --- node-findit2-2.2.3/debian/changelog 2014-10-20 00:05:27.0 + +++ node-findit2-2.2.3/debian/changelog 2015-02-16 19:25:16.0 + @@ -1,3 +1,9 @@ +node-findit2 (2.2.3-2) unstable; urgency=medium + + * remove build dependency on buggy dependency: node-tap + + -- Andrew Kelley superjo...@gmail.com Mon, 16 Feb 2015 19:25:08 + + node-findit2 (2.2.3-1) unstable; urgency=medium * Initial release (Closes: #765772) diff -Nru node-findit2-2.2.3/debian/control node-findit2-2.2.3/debian/control --- node-findit2-2.2.3/debian/control 2014-10-20 00:03:35.0 + +++ node-findit2-2.2.3/debian/control 2015-02-16 19:23:44.0 + @@ -6,7 +6,6 @@ Build-Depends: debhelper (= 8) , dh-buildinfo - , node-tap , nodejs Standards-Version: 3.9.6 Homepage: https://github.com/andrewrk/node-findit diff -Nru node-findit2-2.2.3/debian/rules node-findit2-2.2.3/debian/rules --- node-findit2-2.2.3/debian/rules 2014-10-20 00:03:21.0 + +++ node-findit2-2.2.3/debian/rules 2015-02-16 19:24:00.0 + @@ -9,8 +9,6 @@ #override_dh_auto_build: -override_dh_auto_test: - tap test/*.js unblock node-findit2/2.2.3-1 -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ 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] can you fix node-tap and I will ask for the unblock?
Jérémy, Thank you for fixing node-serve-static. I have filed a bug for an unblock on the package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778566 Could you do the same for node-tap? Perhaps even by deleting the failing test? Then I will file an unblock on node-tap. Regards, Andrew ___ 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#778576: unblock: node-tap/0.4.13-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package node-tap
The bug that caused this package to be scheduled for autoremoval is
fixed with this small patch which disables a single test.
This does not affect the behavior of the package itself in any way.
diff -Nru node-tap-0.4.13/debian/changelog node-tap-0.4.13/debian/changelog
--- node-tap-0.4.13/debian/changelog2014-10-20 00:01:44.0 +
+++ node-tap-0.4.13/debian/changelog2015-02-16 22:53:56.0 +
@@ -1,3 +1,9 @@
+node-tap (0.4.13-2) unstable; urgency=medium
+
+ * Patch fixing failing test FTBFS (Closes: #775627)
+
+ -- Jérémy Lal kapo...@melix.org Mon, 16 Feb 2015 23:52:37 +0100
+
node-tap (0.4.13-1) unstable; urgency=low
* Initial release (Closes: #765988)
diff -Nru node-tap-0.4.13/debian/patches/mitigate_test_segv.patch
node-tap-0.4.13/debian/patches/mitigate_test_segv.patch
--- node-tap-0.4.13/debian/patches/mitigate_test_segv.patch 1970-01-01
00:00:00.0 +
+++ node-tap-0.4.13/debian/patches/mitigate_test_segv.patch 2015-02-16
22:53:00.0 +
@@ -0,0 +1,30 @@
+Description: exit code of segv test depend on platform - do not check it
+ For reasons yet to be discovered, the assumption in segv test is wrong on
+ the platform used for https://bugs.debian.org/775627.
+Last-Update: 2015-02-16
+Author: Jérémy Lal kapo...@melix.org
+Forwarded: no, need more info
+--- a/test/segv.js
b/test/segv.js
+@@ -37,9 +37,7 @@
+ , { 'id': 1,
+ 'ok': false,
+ 'name': ' ././segv',
+- 'exit': null,
+ 'timedOut': true,
+- 'signal': process.platform === 'linux' ? 'SIGSEGV' : 'SIGTERM',
+ 'command': './segv' }
+ , 'tests 1'
+ , 'fail 1' ]
+@@ -47,11 +45,6 @@
+ tc.on('data', function (d) {
+ var e = expect.shift()
+
+-// specific signal can be either term or bus
+-if (d.signal e.signal)
+- e.signal = d.signal === SIGTERM || d.signal === SIGBUS ?
+-d.signal : e.signal
+-
+ t.same(d, e)
+ })
+ tc.on('end', function () {
diff -Nru node-tap-0.4.13/debian/patches/series
node-tap-0.4.13/debian/patches/series
--- node-tap-0.4.13/debian/patches/series 2014-10-20 00:01:40.0
+
+++ node-tap-0.4.13/debian/patches/series 2015-02-16 22:53:00.0
+
@@ -1,3 +1,4 @@
nodejs_rename.patch
use_available_modules.patch
sbuild_disable_tests.patch
+mitigate_test_segv.patch
unblock node-tap/0.4.13-2
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
___
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] node-serve-static in danger of getting removed
Leo, The upstream maintainer of serve-static is going to release 1.6.5 (1.6.4 currently in danger of getting removed from debian) with the bug fix in it: https://github.com/expressjs/serve-static/commit/0399e399935bab99530d6926094b4451438c2d50#commitcomment-9590955 When that happens will you go through the process to get it unflagged for removal? Regards, Andrew ___ 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-serve-static in danger of getting removed
It seems I have been unsubscribed from pkg-javascript-devel for some reason and I did not see http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-January/009894.html until now. On Wed, Feb 4, 2015 at 1:16 PM, Andrew Kelley superjo...@gmail.com wrote: Leo, The upstream maintainer of serve-static is going to release 1.6.5 (1.6.4 currently in danger of getting removed from debian) with the bug fix in it: https://github.com/expressjs/serve-static/commit/0399e399935bab99530d6926094b4451438c2d50#commitcomment-9590955 When that happens will you go through the process to get it unflagged for removal? Regards, Andrew ___ 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] can we use my fork of node-findit?
On Oct 17, 2014 4:11 PM, Andrew Kelley superjo...@gmail.com wrote: Good idea. Done. On Fri, Oct 17, 2014 at 4:06 PM, Jérémy Lal kapo...@melix.org wrote: Maybe it can be written in the long description of the package ? This module is a backward-compatible rewrite of node-findit I found one more bug and fixed it upstream. Then updated the node-findit2 package which is ready for review and upload. Anything else you wanted me to do? ___ 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-findit2_2.2.3-1_amd64.changes is NEW
On Sun, Oct 19, 2014 at 5:34 PM, Debian FTP Masters ftpmas...@ftp-master.debian.org wrote: binary:node-findit2 is NEW. source:node-findit2 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. Hi FTP masters, This module, node-findit2, is a fork of node-findit. The 3 dependencies of node-findit in Debian have switched to node-findit2 upstream. After node-findit2 is accepted, node-findit can be removed. This package is NEW, but in practice it is closer to an update for node-findit which was already accepted. Regards, Andrew ___ 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] can we use my fork of node-findit?
On Thu, Oct 16, 2014 at 2:17 PM, Andrew Kelley superjo...@gmail.com wrote: On Wed, Oct 15, 2014 at 12:44 AM, Jérémy Lal kapo...@melix.org wrote: What should I do? Since both have same API, i'd add your patches as quilt patches to node-findit that is already in debian and add a binary package node-findit2 (symlinking /usr/lib/nodejs/findit to findit2). Or the reverse, change upstream and add binary node-findit to node-findit2. What about this? * Add patch as quilt patch to node-findit that is already in debian * When packaging other package updates that depend on findit2, patch them to depend on node-findit instead, since the patch provides the findit2 API and bug fixes. If you are OK with that strategy, then node-findit is ready for review and upload. Also if this strategy is OK, then node-multiparty is updated and ready for review and upload. Felipe, if Jérémy says that this strategy for node-findit is OK, then the groovebasin package is updated and ready for review and upload. ___ 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] can we use my fork of node-findit?
On Fri, Oct 17, 2014 at 12:15 AM, Jérémy Lal kapo...@melix.org wrote: Le jeudi 16 octobre 2014 à 14:17 -0700, Andrew Kelley a écrit : On Wed, Oct 15, 2014 at 12:44 AM, Jérémy Lal kapo...@melix.org wrote: What should I do? Since both have same API, i'd add your patches as quilt patches to node-findit that is already in debian and add a binary package node-findit2 (symlinking /usr/lib/nodejs/findit to findit2). Or the reverse, change upstream and add binary node-findit to node-findit2. What about this? * Add patch as quilt patch to node-findit that is already in debian * When packaging other package updates that depend on findit2, patch them to depend on node-findit instead, since the patch provides the findit2 API and bug fixes. I agree up to that point where you imply that findit2 has a different API ? If that's the case then findit2 must be... findit2 ! Hmm, in this case, since upstream seems to be ignoring my pull request, maybe I will * rename the module to a better fork name (as I did with formidable - multiparty) * add new node module to debian * update packages to depend on new module * delete node-findit from debian since nothing depends on it ___ 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] can we use my fork of node-findit?
On Fri, Oct 17, 2014 at 3:40 PM, Jérémy Lal kapo...@melix.org wrote: Le vendredi 17 octobre 2014 à 15:04 -0700, Andrew Kelley a écrit : On Fri, Oct 17, 2014 at 12:15 AM, Jérémy Lal kapo...@melix.org wrote: Le jeudi 16 octobre 2014 à 14:17 -0700, Andrew Kelley a écrit : On Wed, Oct 15, 2014 at 12:44 AM, Jérémy Lal kapo...@melix.org wrote: What should I do? Since both have same API, i'd add your patches as quilt patches to node-findit that is already in debian and add a binary package node-findit2 (symlinking /usr/lib/nodejs/findit to findit2). Or the reverse, change upstream and add binary node-findit to node-findit2. What about this? * Add patch as quilt patch to node-findit that is already in debian * When packaging other package updates that depend on findit2, patch them to depend on node-findit instead, since the patch provides the findit2 API and bug fixes. I agree up to that point where you imply that findit2 has a different API ? If that's the case then findit2 must be... findit2 ! Hmm, in this case, since upstream seems to be ignoring my pull request, maybe I will * rename the module to a better fork name (as I did with formidable - multiparty) * add new node module to debian * update packages to depend on new module * delete node-findit from debian since nothing depends on it If that's the case, then please keep a name close to the original one, so that when packaging a module depending on (old) findit, one can find easily the new findit to be a match. You might also want to commit to keep a backward-compatible API with node-findit. These are only suggestions. I have thought about it, and I decided to keep the name as findit2. Also I agree to commit to backward-compatible API with node-findit, so that debian packages can use findit2 instead. I should have a package done here shortly. One thing that is kind of funny, is that since I cleaned up the code considerably, the lines of code is now small enough that FTP masters might say it is too small!! But hopefully if we tell them we are going to remove node-findit and this package is intended to replace it, then they will be OK with it. ___ 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] can we use my fork of node-findit?
On Fri, Oct 17, 2014 at 3:43 PM, Andrew Kelley superjo...@gmail.com wrote: On Fri, Oct 17, 2014 at 3:40 PM, Jérémy Lal kapo...@melix.org wrote: Le vendredi 17 octobre 2014 à 15:04 -0700, Andrew Kelley a écrit : On Fri, Oct 17, 2014 at 12:15 AM, Jérémy Lal kapo...@melix.org wrote: Le jeudi 16 octobre 2014 à 14:17 -0700, Andrew Kelley a écrit : On Wed, Oct 15, 2014 at 12:44 AM, Jérémy Lal kapo...@melix.org wrote: What should I do? Since both have same API, i'd add your patches as quilt patches to node-findit that is already in debian and add a binary package node-findit2 (symlinking /usr/lib/nodejs/findit to findit2). Or the reverse, change upstream and add binary node-findit to node-findit2. What about this? * Add patch as quilt patch to node-findit that is already in debian * When packaging other package updates that depend on findit2, patch them to depend on node-findit instead, since the patch provides the findit2 API and bug fixes. I agree up to that point where you imply that findit2 has a different API ? If that's the case then findit2 must be... findit2 ! Hmm, in this case, since upstream seems to be ignoring my pull request, maybe I will * rename the module to a better fork name (as I did with formidable - multiparty) * add new node module to debian * update packages to depend on new module * delete node-findit from debian since nothing depends on it If that's the case, then please keep a name close to the original one, so that when packaging a module depending on (old) findit, one can find easily the new findit to be a match. You might also want to commit to keep a backward-compatible API with node-findit. These are only suggestions. I have thought about it, and I decided to keep the name as findit2. Also I agree to commit to backward-compatible API with node-findit, so that debian packages can use findit2 instead. I should have a package done here shortly. One thing that is kind of funny, is that since I cleaned up the code considerably, the lines of code is now small enough that FTP masters might say it is too small!! But hopefully if we tell them we are going to remove node-findit and this package is intended to replace it, then they will be OK with it. Alright, node-findit2 is packaged up and ready for review and upload. I think we should send a note to the FTP masters that it will replace node-findit. ___ 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] can we use my fork of node-findit?
Good idea. Done. On Fri, Oct 17, 2014 at 4:06 PM, Jérémy Lal kapo...@melix.org wrote: Le vendredi 17 octobre 2014 à 16:03 -0700, Andrew Kelley a écrit : Alright, node-findit2 is packaged up and ready for review and upload. I think we should send a note to the FTP masters that it will replace node-findit. Maybe it can be written in the long description of the package ? This module is a backward-compatible rewrite of node-findit ___ 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] can we use my fork of node-findit?
On Wed, Oct 15, 2014 at 12:44 AM, Jérémy Lal kapo...@melix.org wrote: What should I do? Since both have same API, i'd add your patches as quilt patches to node-findit that is already in debian and add a binary package node-findit2 (symlinking /usr/lib/nodejs/findit to findit2). Or the reverse, change upstream and add binary node-findit to node-findit2. What about this? * Add patch as quilt patch to node-findit that is already in debian * When packaging other package updates that depend on findit2, patch them to depend on node-findit instead, since the patch provides the findit2 API and bug fixes. If you are OK with that strategy, then node-findit is ready for review and upload. ___ 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] patching away readable-stream might not be right
See https://github.com/andrewrk/node-multiparty/commit/11780f4a6e3e8c6d439639794c795bb5fdaefe97#commitcomment-8163898 According to this, if a package depends on readable-stream 1.1.x, then it is actually puling in node 0.11 stream API. This means that patching it to use built-in v0.10.29 stream API could introduce bugs. So maybe we should package node-readable-stream 1.1.x? ___ 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] can we use my fork of node-findit?
I fixed all the bugs in node-findit and submitted the patch to upstream: https://github.com/substack/node-findit/pull/34 But I am afraid that upstream will not accept my code and I do not have time to wait. So I have forked findit to findit2 and started using that in my modules, because it fixes bugs. So now my question is, when packaging these modules, may I update node-findit, keeping the same package name, but use my fork instead? It keeps the same API and fixes all the findit bugs. Further, the only packages that depend on findit so far are mine: $ apt-cache rdepends node-findit node-findit Reverse Depends: groovebasin So far only groovebasin depends on node-findit. And this update happened upstream in groovebasin: groovebasin findit - findit2 connect-static findit - findit2 multiparty findit - findit2 So that's 3 places that need the fork instead of the original, and 0 places that need the original. What should I do? ___ 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] browserify-lite
On Oct 2, 2014 11:49 PM, Jérémy Lal kapo...@melix.org wrote: Le jeudi 02 octobre 2014 à 20:57 -0700, Andrew Kelley a écrit : To provide a possible alternative for upstream projects which depend on browserify, which is a heavy dependency dragging many things along with it, I have created a module called browserify-lite: https://github.com/andrewrk/browserify-lite My question, should I package this module for Debian? Or is it *too* lite? :-) Groove Basin already depends on it for its build system: https://github.com/andrewrk/groovebasin/commit/174af756e1dc2ca148e10a8848fb7db83b100378 Great ! What modifications are required to port a build script using browserify to browserify-lite ? It depends on how complicated the usage of browserify is. If it is very simple, then it might make sense to use browserify-lite, anything even slightly advanced and we would be better off packaging the real browserify. Anything in particular you're interested in? Would it be better to use uglifyjs ast parser ? Possibly. The tokenizer I coded up should probably be fine, but maybe since we already have uglifyjs packaged it would make sense to use that. ___ 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] Comments regarding node-clarinet_0.9.0-1_amd64.changes
On Thu, Oct 2, 2014 at 5:39 AM, Thorsten Alteholz ftpmas...@ftp-master.debian.org wrote: I marked your package for accept, but please remove the samples and test directories from the source tarball (or take care of the minified files in it). Thank you. I will do that right away. By the way, there is another package in the NEW queue - node-on-finished - that looks like a trivially small JavaScript package. But rest assured, it is not really a new package, but an update to an existing package, node-finished. Upstream renamed from finished to on-finished so the Debian package is renamed to match convention. ___ 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] browserify-lite
To provide a possible alternative for upstream projects which depend on browserify, which is a heavy dependency dragging many things along with it, I have created a module called browserify-lite: https://github.com/andrewrk/browserify-lite My question, should I package this module for Debian? Or is it *too* lite? :-) Groove Basin already depends on it for its build system: https://github.com/andrewrk/groovebasin/commit/174af756e1dc2ca148e10a8848fb7db83b100378 ___ 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] NPM: Cannot find module installed globally
On Sat, Sep 20, 2014 at 7:33 PM, Jérémy Lal kapo...@melix.org wrote: * npm actually discourages npm install -g in favor of cd thismodule; npm link cd thatmodule; npm link thismodule I think npm encourages using `npm install` which would put dependencies in a local folder called node_modules and would generally discourage use of `npm link`, unless you are developing a module and using npm link to test it while you develop it. Even then, most people do not use npm link. ___ 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] how to build jsondiffpatch?
I am working on packaging jsondiffpatch: https://github.com/benjamine/jsondiffpatch This would be: Source package: jsondiffpatch.js Node package: node-jsondiffpatch libjs package: libjs-jsondiffpatch Node package part is done. The hard part is the libjs package. The repository ships with build/* containing generated files. So I have excluded those in a dfsg tarball. However now we must build those files ourselves. The way it is done is with gulp: build: node_modules @./node_modules/.bin/gulp build gulp is not in debian and it would take a lot of work to get it there: http://paste.ubuntu.com/8352160/ Additionally, all the gulp stuff is apparently calling browserify, so that build-dependency is dragged in too! x.x What can we do? ___ 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] updated packages ready for upload
On Thu, Sep 11, 2014 at 9:50 PM, Andrew Kelley superjo...@gmail.com wrote: On Tue, Sep 9, 2014 at 12:52 PM, Jérémy Lal kapo...@melix.org wrote: i think method 2 of https://wiki.debian.org/Renaming_a_Package applies here. Can you do it, then i'll review and upload ? All done and ready for review. If node-on-finished looks good, then node-body-parser is ready to go too. ___ 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-connect-static_1.2.2-1_amd64.changes REJECTED
OK. Thorsten, Please feel free to reject node-errno as well. The upstream repository that I am ultimately trying to get all the dependencies uploaded for is now updated to have less dependencies, and among others, node-errno is no longer required. I am unaware of any other projects that intend to depend on node-errno. Regards, Andrew ___ 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] packages rejected
On Thu, Sep 11, 2014 at 2:06 PM, Jérémy Lal kapo...@melix.org wrote: Moving to pkg-javascript Le jeudi 11 septembre 2014 à 10:03 -0700, Andrew Kelley a écrit : node-mv nodemodules-fs Looks like this is not started yet, so I will start it. node-connect-static i know it's easier said than done, but can you consider doing a PR to serve-static with the feature(s) you're missing ? if not, then yes, bundle it inside groovebasin. I hadn't considered this. I will go ahead and make a pull request. I have worked with one of the maintainers in the past, so maybe they will consider it. After https://github.com/andrewrk/groovebasin/commit/c97a6ae74c46599ff3dfa7992f6e89593501e3f5 groovebasin no longer depends on node-prr. ha ok, but level will anyway, no ? I meant that even following the chain, node-prr is not depended on at all: leveldown (1.0.0) ├─ abstract-leveldown (~2.0.0) │ └─ xtend (~3.0.0) ├─ bindings (~1.2.1) ├─ nan (~1.3.0) └─ fast-future (~1.0.0) the prr dependency came in via level-packager, which groove basin completely avoids now. ___ 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] updated packages ready for upload
On Tue, Sep 9, 2014 at 12:52 PM, Jérémy Lal kapo...@melix.org wrote: i think method 2 of https://wiki.debian.org/Renaming_a_Package applies here. Can you do it, then i'll review and upload ? All done and ready for review. ___ 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] packages rejected
On Thu, Sep 11, 2014 at 2:28 PM, Andrew Kelley superjo...@gmail.com wrote: node-connect-static i know it's easier said than done, but can you consider doing a PR to serve-static with the feature(s) you're missing ? if not, then yes, bundle it inside groovebasin. I hadn't considered this. I will go ahead and make a pull request. I have worked with one of the maintainers in the past, so maybe they will consider it. I thought about this some more, and I think that I would rather not do it. As an upstream author, I think the packages are distinct. In particular, serve-static has these dependencies: serve-static (1.6.1) ├─ parseurl (~1.3.0) ├─ send (0.9.1) ├─ escape-html (1.0.1) └─ utils-merge (1.0.0) I don't want to drag these dependencies in. Additionally, serve-static and connect-static have different use cases and implementations; if they were merged then they would share no code. I think they really are distinct packages. However, as an alternative to bundling, I could see this being something like nodemodules-connect-middleware or something like that. But maybe bundling is fine since nothing else depends on connect-static as of yet. ___ 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] Comments regarding node-groove_2.2.4-1_amd64.changes
On Mon, Jul 28, 2014 at 4:26 AM, Thorsten Alteholz ftpmas...@ftp-master.debian.org wrote: danse.ogg seems to be created by Kevin MacLeod. Normally he licenses his stuff under CC BY. Can you please confirm that he is the author and then add an entry to debian/copyright. Good catch Thorsten. I have confirmed that he is the author and added a copyright entry for it now. The package is ready for upload when Felipe has time to do it. ___ 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-bl_0.8.2-1_amd64.changes REJECTED
Thorsten, My apologies for not noticing this. Good catch. I will be more careful in the future. On Fri, Jul 11, 2014 at 5:00 AM, Thorsten Alteholz ftpmas...@ftp-master.debian.org wrote: Hi Andrew, unfortunately I have to reject your package. The license in LICENSE does not match the license you use in your debian/copyright. Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ 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] can we upload node-uuid instead of node-node-uuid?
The proper package for upstream to depend on is uuid:
https://www.npmjs.org/package/uuid
I'd rather patch upstream sources that incorrectly do require('node-uuid')
instead of patching upstream sources (mine included) that correctly do
require('uuid').
___
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] can we upload node-uuid instead of node-node-uuid?
As an upstream author I'm happy to switch to using uid-safe. I don't know
what you're referring to with 'mz'.
On Fri, Jul 4, 2014 at 5:20 PM, Leo Iannacone l...@ubuntu.com wrote:
On 5 July 2014 00:16, Andrew Kelley superjo...@gmail.com wrote:
On Fri, Jul 4, 2014 at 2:24 PM, Leo Iannacone l...@ubuntu.com wrote:
Le vendredi 04 juillet 2014 à 12:14 -0700, Andrew Kelley a écrit :
I'd rather patch upstream sources that incorrectly do
require('node-uuid')
instead of patching upstream sources (mine included) that correctly
do
require('uuid').
May I ask you which module are you going to debianize??
https://github.com/andrewrk/groovebasin/
And, what about using this module:
https://github.com/crypto-utils/uid-safe ??
I will debianize it asap, but without the support to moderize 'mz' ...
--
Ubuntu Member - http://launchpad.net/~l3on
Home Page - http://leoiannacone.com
GPG Key Id - 0xD282FC25
___
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] These Node.js packages are ready for sponsorship
Another day, another update: node-abstract-leveldown node-ansi-regex node-ansi-styles node-bindings node-bl node-body-parser(depends on depd and media-typer) node-chalk (depends on strip-ansi, supports-color, and ansi-styles) node-connect-static (depends on findit 2.0.0, pend, bl) node-cookies(depends on keygrip) node-crc32-stream node-deferred-leveldown (depends on abstract-leveldown) node-deflate-crc32-stream node-depd node-diacritics node-end-of-stream node-errno (depends on prr) node-findit (updated to 2.0.0; upstream fixed an important bug) node-groove (depends on bindings) node-jsondiffpatch (depends on chalk) node-keese node-keygrip node-lazystream node-level (depends on level-packager and leveldown) node-leveldown (depends on bindings) node-level-packager (depends on levelup) node-levelup(depends on deferred-leveldown, bl, errno, prr) node-media-typer node-mess node-music-library-index(depends on diacritics) node-mv (depends on ncp) node-ncp(fixed the problem of the deleted binary in source) node-pend node-prr node-requireindex node-strip-ansi (depends on ansi-regex) node-stylus node-supports-color node-tar-stream (depends on bl and end-of-stream) node-zfill node-zip-stream (depends on crc32-stream, deflate-crc32-stream, debug 1.0.2) On Mon, Jun 30, 2014 at 8:41 AM, Andrew Kelley superjo...@gmail.com wrote: Updated ready-for-sponsorship list. I'll try to keep this email to one per day from now on. node-abstract-leveldown node-ansi-regex node-ansi-styles node-bindings node-bl node-connect-static (depends on bl and pend) node-cookies (depends on keygrip) node-crc32-stream node-deferred-leveldown (depends on abstract-leveldown) node-deflate-crc32-stream node-depd node-diacritics node-end-of-stream node-groove (depends on bindings) node-keese node-keygrip node-lazystream node-leveldown(depends on bindings) node-media-typer node-mess node-music-library-index (depends on diacritics) node-mv (depends on ncp) node-ncp node-pend node-prr node-strip-ansi (depends on ansi-regex) node-stylus node-supports-color node-tar-stream (depends on bl and end-of-stream) node-zfill On Sun, Jun 29, 2014 at 9:25 PM, Andrew Kelley superjo...@gmail.com wrote: Hello pkg-javascript team, I have completed many Node.js packages and more are on the way. I'm looking for someone to sponsor these packages: node-abstract-leveldown node-ansi-regex node-ansi-styles node-bindings node-leveldown depends on this one node-bl node-crc32-stream node-deflate-crc32-stream node-depd node-diacritics node-end-of-stream node-keese node-keygrip node-lazystream node-leveldown this one compiles native code and depends on libleveldb and libsnappy node-media-typer node-ncp node-pend node-prr node-supports-color node-zfill The repositories are all in /git/pkg-javascript/. Cheers, Andrew ___ 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] These Node.js packages are ready for sponsorship
Updated ready-for-sponsorship list. I'll try to keep this email to one per day from now on. node-abstract-leveldown node-ansi-regex node-ansi-styles node-bindings node-bl node-connect-static (depends on bl and pend) node-cookies (depends on keygrip) node-crc32-stream node-deferred-leveldown (depends on abstract-leveldown) node-deflate-crc32-stream node-depd node-diacritics node-end-of-stream node-groove (depends on bindings) node-keese node-keygrip node-lazystream node-leveldown(depends on bindings) node-media-typer node-mess node-music-library-index (depends on diacritics) node-mv (depends on ncp) node-ncp node-pend node-prr node-strip-ansi (depends on ansi-regex) node-stylus node-supports-color node-tar-stream (depends on bl and end-of-stream) node-zfill On Sun, Jun 29, 2014 at 9:25 PM, Andrew Kelley superjo...@gmail.com wrote: Hello pkg-javascript team, I have completed many Node.js packages and more are on the way. I'm looking for someone to sponsor these packages: node-abstract-leveldown node-ansi-regex node-ansi-styles node-bindings node-leveldown depends on this one node-bl node-crc32-stream node-deflate-crc32-stream node-depd node-diacritics node-end-of-stream node-keese node-keygrip node-lazystream node-leveldown this one compiles native code and depends on libleveldb and libsnappy node-media-typer node-ncp node-pend node-prr node-supports-color node-zfill The repositories are all in /git/pkg-javascript/. Cheers, Andrew ___ 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] whether or not to sometimes remove questionably useful binaries from node modules
from #debian-multimedia fsateler andrewrk: why did you remove the ncp binary? andrewrk fsateler, it clutters up the global bin namespace, and why would you ever use it instead of plain old cp ? andrewrk it seems common for node module authors to include useless binaries with their libraries andrewrk another one: https://github.com/rvagg/node-errno andrewrk in the common use case, all node modules are installed locally to the project. so people are not worried about picking globally unique binary names. in the above project if you were using it you could do something like: andrewrk ./node_modules/.bin/errno foo andrewrk while developing. but as node-errno debian package I think it makes sense to only include the library functionality andrewrk I suppose Jérémy Lal would have an opinion on this Any other opinions out there? ___ 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] where do I begin? I want to package many node module dependencies for an application
(~0.2.12) node-minimatch (0.2.12-1) │ │ ├─ lodash (~2.4.1) None │ │ ├─ glob (~3.2.6)node-glob (3.2.6-1) │ │ ├─ rimraf (~2.2.2) node-rimraf (2.2.2-2) │ │ ├─ findup-sync (~0.1.2) None │ │ │ ├─ glob (~3.2.9) node-glob (3.2.6-1) │ │ │ └─ lodash (~2.4.1) None │ │ ├─ iconv-lite (~0.2.11) None │ │ └─ isbinaryfile (~2.0.0)None │ ├─ readable-stream (~1.0.26) None │ └─ tar-stream (~0.4.0) None │ ├─ bl (~0.6.0) None │ │ └─ readable-stream (~1.0.26) None │ ├─ end-of-stream (~0.1.3) None │ │ └─ once (~1.3.0) node-once (1.1.1-1) │ ├─ xtend (~3.0.0) None │ └─ readable-stream (~1.0.26-4) None ├─ lastfm (~0.9.0)None │ └─ underscore () underscore (1.4.4-2ubuntu1) ├─ requireindex (~1.1.0) None ├─ mess (~0.1.1) None ├─ express (~4.4.3) node-express (2.5.9-2) ├─ mkdirp (~0.3.5)node-mkdirp (0.3.5-1) ├─ findit (~1.1.1)None ├─ keese (~1.0.0) None ├─ level (~0.18.0)None │ ├─ level-packager (~0.18.0)None │ │ └─ levelup (~0.18.0)None │ │ ├─ semver (~2.3.1) node-semver (2.1.0-2) │ │ ├─ xtend (~3.0.0)None │ │ ├─ deferred-leveldown (~0.2.0) None │ │ │ └─ abstract-leveldown (~0.12.1) None │ │ │ └─ xtend (~2.1.1) None │ │ ├─ bl (~0.8.0) None │ │ ├─ errno (~0.1.1)None │ │ │ └─ prr (~0.0.0) None │ │ ├─ readable-stream (~1.0.26) None │ │ └─ prr (~0.0.0) None │ └─ leveldown (~0.10.0) None │ ├─ bindings (~1.1.1)None │ └─ nan (~0.6.0) node-nan (0.3.2-1) ├─ osenv (0.0.3) node-osenv (0.0.3-1) ├─ superagent (~0.18.0) None │ ├─ qs (0.6.6) node-qs (0.6.5-1) │ ├─ cookiejar (1.3.2) None │ ├─ methods (0.0.1) None │ ├─ extend (~1.2.1) None │ ├─ form-data (0.1.2) node-form-data (0.1.0-1) │ ├─ mime (1.2.5)node-mime (1.2.11-1) │ ├─ readable-stream (1.0.27-1) None │ ├─ formidable (1.0.14) node-formidable (1.0.13-1) │ ├─ debug (~0.7.2) node-debug (0.6.0-1) │ ├─ reduce-component (1.0.1)None │ └─ component-emitter (1.1.2) None ├─ body-parser (~1.4.3) None │ ├─ depd (0.3.0)None │ ├─ qs (0.6.6) node-qs (0.6.5-1) │ ├─ raw-body (1.2.2)node-raw-body (0.0.3-1) │ ├─ type-is (1.3.1) None │ │ ├─ media-typer (0.2.0) None │ │ └─ mime-types (~1.0.1) None │ ├─ bytes (1.0.0) node-bytes (0.2.1-1) │ ├─ media-typer (0.2.0) None │ └─ iconv-lite (0.4.3) None ├─ mv (~2.0.0)None │ ├─ ncp (~0.4.2)None │ ├─ rimraf (~2.2.6) node-rimraf (2.2.2-2) │ └─ mkdirp (~0.3.5) node-mkdirp (0.3.5-1) ├─ ws (~0.4.31) None │ ├─ tinycolor (0.x) node-tinycolor (0.0.1~git20130725-1) │ ├─ nan (~0.3.0)node-nan (0.3.2-1) │ ├─ options (=0.0.5) None │ └─ commander (~0.6.1) node-commander (2.0.0-1) └─ groove (~2.2.1)None └─ bindings (~1.1.1) None Warnings occured: [warning] xtend: utils-merge does the same job (but it works only for two objects), see node-through2 for a patch [error] readable-stream: Only nodejs = 0.10.x is in debian, see node-multiparty for a patch On Thu, Jun 26, 2014 at 1:19 PM, Andrew Kelley superjo...@gmail.com wrote: Hello pkg-javascript-devel team, I am andrewrk from the pkg-multimedia-maintainers team. I started packaging Groove Basin http://groovebasin.com/ - a music
[Pkg-javascript-devel] These Node.js packages are ready for sponsorship
Hello pkg-javascript team, I have completed many Node.js packages and more are on the way. I'm looking for someone to sponsor these packages: node-abstract-leveldown node-ansi-regex node-ansi-styles node-bindings node-leveldown depends on this one node-bl node-crc32-stream node-deflate-crc32-stream node-depd node-diacritics node-end-of-stream node-keese node-keygrip node-lazystream node-leveldown this one compiles native code and depends on libleveldb and libsnappy node-media-typer node-ncp node-pend node-prr node-supports-color node-zfill The repositories are all in /git/pkg-javascript/. Cheers, Andrew ___ 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] where do I begin? I want to package many node module dependencies for an application
On Fri, Jun 27, 2014 at 12:35 AM, Emilien Klein emilien+deb...@klein.st wrote: Hi andrewrk, Let us know if you need more information. A couple questions for you: 1. Should I create ITPs for each and every one of the new modules (about 65)? 2. How does one package up modules that contain C++ code? For me these are: https://npmjs.org/package/ws https://npmjs.org/package/leveldown https://npmjs.org/package/groove Related question: both ws and leveldown have a conflicting runtime dependency on https://npmjs.org/package/nan but this looks like perhaps it should be a compile-time dependency. Any advice on this? P.S.: I'm assuming you are not subscribed to the pkg-javascript-devel@l.a.d.o list, hence the CC. Let us know if you are subscribed though. I am now subscribed :-) ___ 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] where do I begin? I want to package many node module dependencies for an application
On Fri, Jun 27, 2014 at 1:39 PM, Jérémy Lal kapo...@melix.org wrote: Le vendredi 27 juin 2014 à 21:28 +0200, Emilien Klein a écrit : 2014-06-27 17:34 GMT+02:00 Andrew Kelley superjo...@gmail.com: On Fri, Jun 27, 2014 at 12:35 AM, Emilien Klein emilien+deb...@klein.st wrote: 2. How does one package up modules that contain C++ code? For me these are: https://npmjs.org/package/ws https://npmjs.org/package/leveldown https://npmjs.org/package/groove Do these packages have a Makefile, or some building recipe? If it's using one of the popular tools, the package helpers should be able to take care of the building process for you. Usually c++ node modules use node-gyp, see packages build-depending on node-gyp to find out about it (reverse-depends -b node-gyp). Thanks, this is helpful. So far I have packaged up 3 modules: http://anonscm.debian.org/gitweb/?p=pkg-javascript/node-findit.git;a=summary http://anonscm.debian.org/gitweb/?p=pkg-javascript/node-pend.git;a=summary http://anonscm.debian.org/gitweb/?p=pkg-javascript/node-keygrip.git;a=summary Any feedback before I continue? ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
