Re: [Pkg-javascript-devel] node-websocket_1.0.19-2~bpo8+1_amd64.changes REJECTED
On 01/10/15 10:27, Rhonda D'Vine wrote: >Dear Daniel, > > * Daniel Pocock <dan...@pocock.pro> [2015-09-30 09:38:07 CEST]: >> On 29/09/15 20:25, Alexander Wirt wrote: >>> we (ftpmasters) expect you to update packages in bpo regulary during the >>> whole lifetime of a suite, if you are not able to do that, the package is >>> not >>> suitable for bpo. >> >> Some of the node-* packages change quite frequently and I don't >> personally have time to test every one of them every time they release >> and backport them too. > > "Regularly" doesn't mean every update that hits testing. In some > development steps it might make a lot of sense to wait for a later > upload in a bigger picture, so to say. > > But if you feel like taking regular care of the packages you backport > is too much of a trouble I suggest you to please, with sugar on top, NOT > upload them in the first place. backports is a service that is meant to > be used in addition to stable, and thus should be taken care of in a > useful and sensible way. That is: > > -) do not upload packages that aren't in testing (there are exceptions > to this, but in general those are rather rare than the default and it > would be convenient to ask beforehand) > > -) do not upload packages that are neither in testing nor in unstable! > Sorry, but that is absolutely off. When you want to have a certain > middle step of a package uploaded to backports, hold back the unstable > upload until it transitioned to testing before updating unstable, making > the version you backport from disappear ... > That was just an oversight with one package, it wasn't something deliberate. I had built the package for unstable but forgot to run dput. >> When I update JSCommunicator, as upstream developer, I test with a set >> of dependencies, including JsSIP and its dependencies, and everything >> that I've tested and validated is then uploaded to Debian (both unstable >> and eventually backports). This involves testing standalone >> JSCommunicator, testing DruCall, testing on rtc.debian.org and testing >> each major browser on Linux and Android. It is not feasible for me to >> repeat all of that every time a node-* package changes though. > > Backports is not your test field. You are pushing the testing towards > users of an expected stable system which isn't acceptable, no matter how > feasible you consider it. > That is not what I said: my statement was qualified "as upstream developer", which means this was a statement about what I do before an upstream tag. So the workflow is: - upstream testing, as described above - upstream tag/release - unstable upload - finally, backport >> I've uploaded a 1.0.19-1~bpo8+1 build corresponding to the version in >> testing, 1.0.19-1, this will work with the other packages that have >> already been accepted into jessie-backports yesterday. > > Thanks. And if you want to stay in the ACL file, whenever you try to > do something out of the line, speak to us beforehand, don't let us > stumble upon it like this because that doesn't help us to be convinced > that you should be able to upload to backports directly without anyone > else involved. You can find us in #debian-backports on irc which I know > you do use at least at times. > Thanks for the feedback Can you clarify one other thing: if a newer version of node-websocket propagates from unstable to testing while the node-websocket backport is in NEW, does that mean it will be rejected again? Or will it be accepted into backports because it had been in testing, at least at the moment I uploaded it? Regards, Daniel ___ 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-websocket_1.0.19-2~bpo8+1_amd64.changes REJECTED
On 29/09/15 20:25, Alexander Wirt wrote: > On Tue, 29 Sep 2015, Daniel Pocock wrote: > >> >> >> On 29/09/15 20:13, Alexander Wirt wrote: >>> On Tue, 29 Sep 2015, Daniel Pocock wrote: >>> >>>> >>>> >>>> On 29/09/15 18:01, Alexander Wirt wrote: >>>>> >>>>> Package not in testing >>>>> >>>> >>>> >>>> The version in testing had to be updated to 1.0.22 to work with node-nan >>>> 2.0.x. It is not clear if that dependency will be placed in >>>> debian-packports >>>> >>>> node-websocket versions <= 1.0.21 work with the node-nan version >>>> currently in jessie >>>> >>>> Please confirm I can upload this again and potentially upload 1.0.21 >>>> even though testing will carry a newer version. >>> no. we had this several times. Such packages will not be accepted within >>> bpo. >>> >> >> What about 1.0.19-1 that has been in testing for a while? Can I upload >> a 1.0.19-1~bpo8+1 build to jessie-backports even though a newer version >> is now in unstable? >> >> Jérémy, is there any problem with putting node-nan 2.0.x into >> jessie-backports? Should I go ahead and upload it, should it be >> avoided, or does it need some discussion? > we (ftpmasters) expect you to update packages in bpo regulary during the > whole lifetime of a suite, if you are not able to do that, the package is not > suitable for bpo. > Some of the node-* packages change quite frequently and I don't personally have time to test every one of them every time they release and backport them too. When I update JSCommunicator, as upstream developer, I test with a set of dependencies, including JsSIP and its dependencies, and everything that I've tested and validated is then uploaded to Debian (both unstable and eventually backports). This involves testing standalone JSCommunicator, testing DruCall, testing on rtc.debian.org and testing each major browser on Linux and Android. It is not feasible for me to repeat all of that every time a node-* package changes though. I've uploaded a 1.0.19-1~bpo8+1 build corresponding to the version in testing, 1.0.19-1, this will work with the other packages that have already been accepted into jessie-backports yesterday. Regards, Daniel ___ 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-typedarray-to-buffer_3.0.3-3~bpo8+1_amd64.changes REJECTED
On 29/09/15 18:01, Alexander Wirt wrote: > > This version is not even in debian. Sorry about that, I was updating a lot of these packages and forgot to dput this one, thanks for pointing that out, I have uploaded it 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
[Pkg-javascript-devel] Bug#799656: [JsSIP] Re: Bug#799656: NaN 2.x issue
On 28/09/15 18:18, Iñaki Baz Castillo wrote: > 2015-09-24 15:14 GMT+02:00 Daniel Pocock <dan...@pocock.pro>: >> Can anybody from the JsSIP team comment on this? How do you feel about >> having node-nan 2.x in the dependency hierarchy? Will you continue >> using node-websocket or would you possibly use node-ws[1] instead? >> Using node-ws instead of node-websocket will reduce the number of >> packages we have to keep track of in Debian. > Initially I used node-ws, and removed it in favor of node-websocket > because node-ws was not good for JsSIP needs. There is no way to move > back to node-ws (in fact, I'm now developer of node-websocket). Thanks for this feedback With the JsSIP move to Node, a lot of dependencies were added and I had to package all of them, including node-websocket. You can see the package details for node-websocket here: https://packages.qa.debian.org/n/node-websocket.html Debian and Ubuntu only allow one version of each dependency on each system. To use node-websocket >= 1.0.22 in Debian stable (via jessie-backports), we will need to either a) have node-nan >= 2.0.x in jessie-backports, or b) adapt node-websocket to support both old and new versions of node-nan using compiler macros, or c) maybe we could split the package to have a browser-only version that doesn't need any of this compiled code? That would be less painful to support. ___ 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] jssip_0.6.34-5~bpo8+1_amd64.changes REJECTED
On 29/09/15 18:01, Alexander Wirt wrote: > > Package not in testing. These packages only had their VCS fields updated, otherwise they are the same as the packages in testing ___ 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-websocket_1.0.19-2~bpo8+1_amd64.changes REJECTED
On 29/09/15 20:13, Alexander Wirt wrote: > On Tue, 29 Sep 2015, Daniel Pocock wrote: > >> >> >> On 29/09/15 18:01, Alexander Wirt wrote: >>> >>> Package not in testing >>> >> >> >> The version in testing had to be updated to 1.0.22 to work with node-nan >> 2.0.x. It is not clear if that dependency will be placed in >> debian-packports >> >> node-websocket versions <= 1.0.21 work with the node-nan version >> currently in jessie >> >> Please confirm I can upload this again and potentially upload 1.0.21 >> even though testing will carry a newer version. > no. we had this several times. Such packages will not be accepted within bpo. > What about 1.0.19-1 that has been in testing for a while? Can I upload a 1.0.19-1~bpo8+1 build to jessie-backports even though a newer version is now in unstable? Jérémy, is there any problem with putting node-nan 2.0.x into jessie-backports? Should I go ahead and upload it, should it be avoided, or does it need some discussion? Regards, Daniel ___ 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#799656: NaN 2.x issue
This is failing because node-nan 2.x is now in unstable I've filed a bug upstream requesting support for node-nan 2.x Maybe both old and new versions of node-nan will be needed in stretch? https://packages.qa.debian.org/n/node-nan.html ___ 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#799656: NaN 2.x issue
On 24/09/15 14:53, Jérémy Lal wrote: > 2015-09-24 14:42 GMT+02:00 Daniel Pocock <dan...@pocock.pro > <mailto:dan...@pocock.pro>>: > > > > This is failing because node-nan 2.x is now in unstable > > I've filed a bug upstream requesting support for node-nan 2.x > > > This is the right thing to do. > > > Maybe both old and new versions of node-nan will be needed in stretch? > > > This isn't ! The idea is to move forward to nodejs 4 / nan 2. > Maintaining legacy modules is more time-consuming than porting them > to nan 2.x - a task that i can do but that is best done by upstream. > > Since the two files built using node-gyp and node-nan have been taken > from node-ws, and since node-ws has already been ported to node-nan 2, > i suggest to be patient... > I saw comments in another bug tracker suggesting that some upstreams are not rushing into node-nan 2 as it is not a trivial change for them. I only reported this upstream today, so let's see how they respond. ___ 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-websocket_1.0.19-1_amd64.changes REJECTED
Hi Paul, I'm just following up on this, would you be able to approve it now that I updated the copyright file? Regards, Daniel On 30/07/15 12:07, Daniel Pocock wrote: On 29/07/15 20:00, Paul Richards Tagliamonte wrote: Howdy maintainer, At least src/validation.cc is MIT/Expat licensed. Please include it in your copyright file. Thanks for the feedback, I've added that and uploaded again https://github.com/dpocock/WebSocket-Node/commit/b8dcd238002c076e46123d71cdc664603a1d5728 ___ 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 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-websocket_1.0.19-1_amd64.changes REJECTED
On 29/07/15 20:00, Paul Richards Tagliamonte wrote: Howdy maintainer, At least src/validation.cc is MIT/Expat licensed. Please include it in your copyright file. Thanks for the feedback, I've added that and uploaded again https://github.com/dpocock/WebSocket-Node/commit/b8dcd238002c076e46123d71cdc664603a1d5728 ___ 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] Small Node.js packages in NEW
On 09/04/15 09:18, Dominique Dumont wrote: I don't have a better solution for small packages, but as long as there is no improvement in package handling, I think there should be no exception. I would still prefer the bundling of several small packages into bigger chunks. Isn't git able to handle several upstreams in one repository? Here's the main problem of bundling: it will (not might) require more work from packaging teams: improve tools, and more complex and frequent work to upgrade packages, more difficulties to handle dependencies, breakages... Unfortunately, packaging teams are all understaffed and we all must strive to make these teams more efficient in the quality and quantity of packages they can deliver. I also have concerns about this The ultimate outcome of such things is that people go elsewhere, e.g. they publish their code in NPM or Maven or whatever and they don't care too much if it can be in Debian or Ubuntu. This is actually quite sad because many of the other platforms out there are at the other end of the spectrum, they don't insist on sensible licensing, they don't have any process of review. Basically, they don't have an FTP master team. I just want to put a few ideas out there to help people progress with this: a) would the FTP masters accept small packages from NEW if they are only there to enable the update of some other package that we already have in Debian, maybe for a period of 6 months from now while a better strategy is discussed? b) could the FTP masters operate a separate catalog for NodeJS packages and people would add this into sources.list if they want this stuff? c) would we consider a temporary nodejs-modules.deb omnibus package solution, with something like: Provides: node-foo, node-bar, ... Conflicts: node-foo, node-bar, ... and then no other package should explicitly depend on nodejs-modules? This package would just contain stuff that is relatively stable perhaps. Regards, Daniel ___ 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-is-typedarray_1.0.0-1_amd64.changes
On 18/07/15 12:24, Thorsten Alteholz wrote: Hi Daniel, this package seems to be another candidate for a small-package-reject. Can't you merge this stuff into another package? I was making a 1-to-1 mapping from NodeJS / NPM package names to Debian package names as described in the policy: https://wiki.debian.org/Javascript/Nodejs/Manual Amongst other things, the packaging/naming convention allows people to more quickly package other NodeJS products that depend on this. Regards, Daniel ___ 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] uploading new browserify-lite version
On 08/07/15 09:29, Jérémy Lal wrote: 2015-07-07 23:20 GMT+02:00 Andrew Kelley superjo...@gmail.com mailto:superjo...@gmail.com: 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. Hi all, Thank you Andrew for the notification. Daniel, please note that pkg-javascript has no official policy regarding team maintenance. You should not update packages without getting a consent (by email or on #debian-js) of their main maintainer. That being said, please go ahead with browserify-lite. Great, Andrew mentioned you were sponsoring his uploads so I suggested he send the email before we go any further with this. I'm currently testing it out to build the latest JsSIP package. JsSIP is also waiting on some new dependencies sitting in NEW. 0.3.0-1 has just been uploaded. Regards, Daniel ___ 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] About node browserify, massive npm dependency graphs
On 30/04/14 10:48, Leo Iannacone wrote: Node browserify is a kind of software which makes node modules compatible and runnable for browsers. It seems many modules use it, so it would be nice package it. I have taken a look, and it madly depends on dozens of packages/modules[0]. My question is: do you know if exist something else which does the same job (with less depends)? A few points in reply to your question: browserify-lite exists now and helps some projects, I tried it for JsSIP packages and will share my results soon, some hints in the issue tracker[1] For Node-based projects with large dependency graphs, I'm starting another thread on this mailing list. 1. https://github.com/andrewrk/browserify-lite/issues?utf8=%E2%9C%93q=is%3Aopen+ ___ 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] packaging npm dependency graphs
There are more and more interesting projects using npm and related technologies like grunt and browserify browserify is a heavy user of npm dependencies itself[1] One idea that I had is that we could run some service (maybe using the URL http://npm.debian.net) to: a) automatically clone all the Git repositories for packages on https://www.npmjs.com/ b) create a debian branch in each cloned repository c) use a tool such as npm2debian[2] to create the debian/* artifacts and commit them on the branch d) publish all such generated packages in an unofficial apt repository e) (optional) upload each package to mentors.debian.net for visual review This would allow people to test the dependency graphs more quickly before they do the more tedious effort of making sure each source package is DFSG compatible, building debian/copyright and uploading it to NEW. Last year we investigated similar strategies for Java / Maven dependency graphs, this was Andrew Schurman's GSoC project[3]. There is probably some overlap in some of the automation that is required to do this at scale. Has anybody else had similar thoughts? Are there similar projects already? 1. http://bugs.debian.org/780357 2. https://www.npmjs.com/package/npm2debian 3. https://github.com/arcticwaters/dependency-builder ___ 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/browserify-lite automation
The most basic way of using browserify is not really consistent with the Debian approach. In most packages, we do everything to avoid having bundled libraries (e.g. in a C++ project) and aim to have each library in its own package so that any one library can be updated individually to fix a bug or security flaw. If I use browserify(-lite) from debian/rules, then it is copying code from other packages into my own binary package at build time. Instead of running browserify from debian/rules, maybe browserify can be run dynamically by some hook script each time dependency packages are installed or upgraded? This would mean the browserify output is not kept in any real binary packages, it is built locally on each system and stored in /var/cache perhaps ___ 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#771299: support for JsSIP event name 'confirmed'
Package: jscommunicator-web-phone Version: 2.0.1-1 Severity: important The latest JsSIP releases now emit an event called 'confirmed' instead of 'started' For people to use newer JsSIP versions, JSCommunicator should recognise this event. For maximum flexibility, JSCommunicator needs to handle either the new or old event name. ___ 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] Fwd: Bug#769779: Acknowledgement (O: sipml5 -- JavaScript SIP stack)
Orphaned package sipml5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769779 Original Message Subject: Bug#769779: Acknowledgement (O: sipml5 -- JavaScript SIP stack) Date: Sun, 16 Nov 2014 12:09:06 + From: ow...@bugs.debian.org (Debian Bug Tracking System) Reply-To: 769...@bugs.debian.org To: Daniel Pocock dan...@pocock.pro Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): w...@debian.org If you wish to submit further information on this problem, please send it to 769...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 769779: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769779 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ 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#768630: not all Font Awesome files accessible under module URL
Package: drupal7-mod-fontawesome Version: 1.0-1 Severity: serious Only the css directory is symlinked into Drupal The other directories also need to be symlinked into Drupal ___ 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#768639: jQuery UI not available
Package: drupal7-mod-drucall Version: 2.1-1 Severity: serious The new version of JSCommunicator requires some jQuery UI functionality Drupal7 provides jQuery UI in the page but doesn't expose the API automatically. Must use drupal_add_library to get it. Fixed upstream in 2.2. ___ 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#768502: function name mismatch
Package: drupal7-mod-jqueryi18nproperties Version: 1.0.0-1 Severity: serious Upstream bug: https://www.drupal.org/node/2371299 There is a mismatch in a PHP function name. This makes the function impossible to call. Upstream v1.1 fixes 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
[Pkg-javascript-devel] Bug#768351: must declare dependencies the Drupal way
Package: drupal7-mod-jscommunicator Version: 1.0.1-2 Severity: serious The .info file needs to include all dependencies for Drupal to ensure they are enabled correctly at runtime. ___ 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#768354: must sync with JSCommunicator itself
Package: drupal7-mod-drucall Version: 2.0.1-1 Severity: serious A newer JSCommunicator version was uploaded but the DruCall module could not be uploaded earlier while waiting for the FTP masters to approve new Drupal dependency wrapper packages drupal7-mod-jqueryi18nproperties and drupal7-mod-fontawesome They were approved just before the freeze and now everything needs to be uploaded and unblocked in sync to work together. ___ 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#768363: adjust font-awesome dependency version
Package: libjs-jscommunicator Version: 2.0.0-1 Severity: serious The font-awesome package has a ~ symbol in the dfsg version. Therefore, depending on the constraint (= 4.2.0) doesn't match the version 4.2.0~dfsg-1 Relax the dependency to depend on (= 4.1.0~dfsg) ___ 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#768363: adjust font-awesome dependency version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/14 21:22, Jonas Smedegaard wrote: Quoting Daniel Pocock (2014-11-06 20:43:48) The font-awesome package has a ~ symbol in the dfsg version. Therefore, depending on the constraint (= 4.2.0) doesn't match the version 4.2.0~dfsg-1 Relax the dependency to depend on (= 4.1.0~dfsg) Dependency should be 4.2.0~dfsg (i.e. 2 instead of 1). Perhaps simply a typo... Not quite, 4.1.0~dfsg appears to be sufficient for this and it is in backports. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJUW9kMAAoJEGxlgOd711bErF4QAIVYmGxLX9LH5mHnzgG5nnM+ 7hmdPrqi0sXh9O8oD/L6sLBl/1j+wk/isqnqjw2RDFXPLEPvoW5td3+UaxKoal9r AkVLImwhRdUvmGKrmIBdCnS7QMt189N5iiQcrBpDRlTQ12MYCDPidQ9oZwwuYxbF jc16qBooJewMMfbRIw1/nbcJKLNmB8AK3hAjV7czMhhHd4uEQawXEthz7ImHMuHz IXUn88/SSDjX0lHjhTkCLVCkjXHZMMYVzx444QOY9KUsjvrQsUYyROCPEZXQ8/xv Cjbijl18p9F3oqCKw14MuaBdt5TxCbOQUC1MHwYx5LORinEtCYGmhrogZERzFwMW 2+AvVDJWnHGo7DJ+HPX4dtM5e5bPXmzQMAOQI+WyyjtZpEMVdEvRZgt0fTUEv//N FU11oDRqST+yNqHhUDaATdmDinIVY/HLIQw8KbSNUCiN2NZYcVAd0UpRIqUnpzKW 2VgMfPh0EhOV09oq6ZH/ozdyUnmbolPn/hFJ2I2Yny8ydAtw35QrrGXxyp5kzCFl Opt4dd9zKCDmySJnsXiCjSvqbEko5wYKtlbMkV/7KD1yqIqF5x2r3IF+GhEcQAhz tFkm/TcaTM2g4gVQwipMPuKh2WtbCiScsJRD/z1AVjC16zjSpA9XoGyKndKfwv3X yeFmmZiyFifRLGpE1DDw =TuT8 -END 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
Re: [Pkg-javascript-devel] drupal7-mod-jqueryi18nproperties_1.0.0-1_amd64.changes REJECTED
On 10/10/14 13:42, Luca Falavigna wrote: Hi Daniel, 2014-10-10 13:24 GMT+02:00 Daniel Pocock dan...@pocock.pro: On 10/10/14 13:00, Luca Falavigna wrote: jQuery-i18n-properties is not actually part of this package - it is just a dependency The package itself is a wrapper that links it to Drupal I just re-read the package content, and indeed I was fooled by it. I considered some files to be actually part of jQuery-i18n-properties. I stand corrected, and I apologize for the mistake. If you could reupload the package again, I'll fast-track it. I tried to upload again and it rejected again at 14:19 I just uploaded with a new version 1.0.0-2 ___ 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] jquery-i18n-properties_1.0.9-1_amd64.changes REJECTED
On 03/08/14 19:00, Ansgar Burchardt wrote: Hi, the copyright and license information for css/blueprint/* is missing. Did you look at the 1.1.0 upload? It was missing in 1.0.9 only. Maybe I forgot to upload 1.1.0-1, it was on my disk but I don't see an email acknowledgment for any upload so this was probably my fault. In addition the package recommends jquery which is not a binary package in the archive (and it doesn't seem to be provided by anything either). That is a mistake - fixed. I just uploaded 1.1.0-1 with that fix too. Changes visible here: http://anonscm.debian.org/cgit/pkg-javascript/jquery-i18n-properties.git Thanks for taking the time to look at this. Regards, Daniel ___ 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] JavaScript policy clarifications?
Looking at https://wiki.debian.org/Javascript/Policy there are some ambiguities in point 4 (*should* ship a /minified/ version for each script, generated at build time (use /uglifyjs/ to this purpose) ) - a package should /only/ ship a minified version of a script, or it should ship both minified and unminified or it is at the maintainers discretion? - naming convention for minified scripts - a script minified by the packaging process should have a .min.js extension? Should all maintainers use the same extension for this purpose? Should there be a symlink foo.js - foo.min.js as in some packages? (maybe non-minified js files could go in a libjs-foo-dev package?) - the reference to uglifyjs could also mention closure-compiler ___ 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#736077: Bug#736077: dont leak private network information (at least not by default)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/14 15:22, Holger Levsen wrote: package: libjs-jssip tags: security Hi Daniel, thanks for working on usuable + secure RTC in the webbrowser! During your presentation at the Paris mini-debconf I just learned that your libjs-jssip leaks all networks to the sip server (or calling party), which I consider a privacy violation (which has been implemented to improve the user experience by allowing the application to choose the best network connection). Still, if I connect via route $X I expect this software not to leak my other routes, which might contaín sensitive information. In the talk you said it was trivial to comment out these lines, so I'm asking you to do this by default and optionally allow it. I actually did some experiments with this (using a PyRoute script in the SIP proxy to strip some ICE candidates from the SDP message body) I found that sometimes the other end of the connection wasn't happy with the SDP. Maybe there is something embedded in the STUN ICE check messages and the peer knows that the SDP has been modified. I would need to look more closely at the spec to find out. I'm CCing the Jitsi dev list, they develop the ice4j ICE library for Java and may be able to comment on this. It may also be useful for Jitsi, Empathy and other softphones to offer a similar feature and if it is practical, please raise the same bug against those packages. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEw8hAAoJEOm1uwJp1aqDpwAQAKaSO1626Q0FbYxkxL/6iEhv 03JCDeAHbpe7GWIYvJipjiq4l7WMxq1afYD7FInp39HOlvjcqjl3Pu//5NWR4043 R1hR/8M7+248Vk6Ss0eFNZuGnlSjl1Dg/ADrVlZTlmvEGjEfcLA20454dWEZWJII fy3yHNPthHeqza/QxYvCt5CjwLotnOyUZXOpIM9VvxAm/GIRLo48fCGQYCmAZsHy mjSnyX/MPoRYXo3OQTrvHjCVZzj/5DR/rNEsvIHannCwQdKJOQrALNJgHi5Q9g6u J3LnF36I+zcdnIle4MS+gjNQ5oVHzZBJ52OsGGFgzBreK4r09OUkpZStRQKpkZ9s iW9oPUNEjpMEafc37MYpCPN6xrGquIDZM2Y8lo3hrF3ZlZytJYlApaIjcTQNk5IK KKsS7UOPmBsoYFIM/qWUppTyWMEdO6KWRjyQxsFyHlQ/HGuDUQLYkk3PginNj46W o7V20ujhct8Lm1ah7KeYxKAJt3AZ6u8GJrgSYE89+ZUBZ5OYtXFXMflq8WCcoEiK B4hCvgCbTzzbsKDOt1S3xDEczeelP+aNbuhHFE+NfkpOuuvkk5K5WqdF2SvSgcYq GH3uZkJ3xmKHG+lfZEYj0P999j6IUMwbY80VhrjE3u7fl8sZA5RHwunftyhqSn7o NxIXj7mL2MBBr8VHcGel =LRNH -END 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#740489: include correct UA version string
package: libjs-jssip version: 0.4.0.20140212.1-1 The UA version string in the SIP headers is incorrect This is a bug in the way we use make instead of upstream's grunt build system to build the JavaScript. If grunt becomes part of Debian, then we will just use grunt and the problem will go away. If not, then we need to improve the Makefile to fix this and similar issues. ___ 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#716796: JSHint is optional
JSHint is optional, as noted earlier, it is just a tool to spot mistakes We can still build a valid jQuery package without running JSHint during the build Any calls to JSHint can be replaced with a call to /bin/true ___ 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] [Pkg-monitoring-maintainers] Bug#736104: Sourceless file
Hi pkg-javascript, Can anybody comment on the jQuery version in sid? It is still 1.7 while more and more upstreams appear to be using newer versions I would obviously like to resolve the source issue below by linking to a packaged jQuery. If it won't happen soon please let me know so I can find another solution or test against 1.7. Regards, Daniel On 19/01/14 21:53, bastien ROUCARIES wrote: Package: src:ganglia-web Version: 3.5.8-4 Severity: serious User: debian...@lists.debian.org Usertags: source-contains-prebuilt-javascript-object X-Debbugs-CC: ftpmas...@debian.org I could not find the source of: js/jquery-1.9.1.min.js js/jquery-ui-1.10.2.custom.min.js jquery.scrollTo-1.4.2-min.js dash/js/jquery-ui-1.8.14.custom.min.js ___ Pkg-monitoring-maintainers mailing list pkg-monitoring-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-monitoring-maintainers ___ 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 drupal7-mod-jscommunicator_1.0.0-1_amd64.changes
On 14/01/14 12:23, Thorsten Alteholz wrote: Hi Daniel, your debian/copyright says that this package is GPLv2, but according to COPYING it should be GPLv2+. Maybe you can correct this in one of the next uploads. Thanks for the feedback, I've fixed both in the repositories so it will definitely be part of the next 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] backport nodejs to wheezy
On 11/05/13 17:46, Marcelo Jorge Vieira wrote: Hi Jérémy, On Sun, 2013-05-05 at 23:35 +0200, Jérémy Lal wrote: On 05/05/2013 22:45, Marcelo Jorge Vieira wrote: Hi Jérémy, What do you think about backport nodejs to wheezy? When the migration from nodejs 0.6 to nodejs 0.10 is finished, all new packages will go to testing and be good candidates for backports. The current status is : * nodejs 0.10, libv8-3.14 are in experimental * node-gyp isn't but is not tested enough * i haven't set up a migration yet. Give me a few days... Almost all modules will need to be updated, and all c++ addons be moved to node-gyp instead of node-waf. However i don't think it is a good idea to backport npm, it is a lot of work and being mostly a development tool, people will probably better be using it in testing/sid. thanks for the feedback ;) Of course, as usual, any help is welcome. Yes, I will try it. I'm just wondering if anybody else thinks a wheezy-backports version of nodejs is feasible? I've run it on wheezy and built my own packages (pegjs, jssip) on wheezy and all seems OK ___ 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] backport nodejs to wheezy
On 11/10/13 10:20, Jérémy Lal wrote: On 11/10/2013 09:47, Daniel Pocock wrote: On 11/05/13 17:46, Marcelo Jorge Vieira wrote: Hi Jérémy, On Sun, 2013-05-05 at 23:35 +0200, Jérémy Lal wrote: On 05/05/2013 22:45, Marcelo Jorge Vieira wrote: Hi Jérémy, What do you think about backport nodejs to wheezy? When the migration from nodejs 0.6 to nodejs 0.10 is finished, all new packages will go to testing and be good candidates for backports. The current status is : * nodejs 0.10, libv8-3.14 are in experimental * node-gyp isn't but is not tested enough * i haven't set up a migration yet. Give me a few days... Almost all modules will need to be updated, and all c++ addons be moved to node-gyp instead of node-waf. However i don't think it is a good idea to backport npm, it is a lot of work and being mostly a development tool, people will probably better be using it in testing/sid. thanks for the feedback ;) Of course, as usual, any help is welcome. Yes, I will try it. I'm just wondering if anybody else thinks a wheezy-backports version of nodejs is feasible? I've run it on wheezy and built my own packages (pegjs, jssip) on wheezy and all seems OK Do you backport libv8 too ? Just looking at the system where I did this, I notice it is not pure wheezy It has a version of libv8 depending on libc = 2.14 - I simply pulled the packages selectively from testing some months ago Has anybody tried a build of libv8 in a pure wheezy 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
Re: [Pkg-javascript-devel] backport nodejs to wheezy
On 11/10/13 11:22, Jonas Smedegaard wrote: Quoting Daniel Pocock (2013-10-11 10:22:48) On 11/10/13 10:20, Jérémy Lal wrote: On 11/10/2013 09:47, Daniel Pocock wrote: I'm just wondering if anybody else thinks a wheezy-backports version of nodejs is feasible? I've run it on wheezy and built my own packages (pegjs, jssip) on wheezy and all seems OK Do you backport libv8 too ? Just looking at the system where I did this, I notice it is not pure wheezy It has a version of libv8 depending on libc = 2.14 - I simply pulled the packages selectively from testing some months ago Has anybody tried a build of libv8 in a pure wheezy system? I suspect you mean libv8-3.14 - libv8 is same version in stable, testing and unstable. I have not (yet) backported libv8-3.14 to stable, but I have backported nodejs-0.6.19~dfsg1 to stable, and backported uglifyjs, pegjs and jssip to stable infected by that nodejs backport: deb http://debian.jones.dk/ wheezy javascript Related to this, I prepared a fix for closure-compiler, one of the jssip build dependencies This should clear FTBFS: jssip and allow simplification of jssip:debian/rules and build-deps http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565#41 ___ 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] backport nodejs to wheezy
On 11/10/13 13:30, Jonas Smedegaard wrote: Quoting Daniel Pocock (2013-10-11 13:09:38) On 11/10/13 11:22, Jonas Smedegaard wrote: Quoting Daniel Pocock (2013-10-11 10:22:48) On 11/10/13 10:20, Jérémy Lal wrote: On 11/10/2013 09:47, Daniel Pocock wrote: I'm just wondering if anybody else thinks a wheezy-backports version of nodejs is feasible? I've run it on wheezy and built my own packages (pegjs, jssip) on wheezy and all seems OK Do you backport libv8 too ? Just looking at the system where I did this, I notice it is not pure wheezy It has a version of libv8 depending on libc = 2.14 - I simply pulled the packages selectively from testing some months ago Has anybody tried a build of libv8 in a pure wheezy system? I suspect you mean libv8-3.14 - libv8 is same version in stable, testing and unstable. I have not (yet) backported libv8-3.14 to stable, but I have backported nodejs-0.6.19~dfsg1 to stable, and backported uglifyjs, pegjs and jssip to stable infected by that nodejs backport: deb http://debian.jones.dk/ wheezy javascript Related to this, I prepared a fix for closure-compiler, one of the jssip build dependencies This should clear FTBFS: jssip and allow simplification of jssip:debian/rules and build-deps http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565#41 I still (as I believe I pointed out in one of the bugreports I filed that day when doing the backport) recommend using uglifyjs consistently. (upstream argued there was a big size gain using another minifier, but in actual test the difference was minimal, and uglifyjs is (also) well tested and means simpler dependencies, compared to Java-based tools. For some reason (I haven't checked exactly why) upstream uses closure-compiler for their Grammar file and uglify for the rest of their code While it wouldn't be hard, I'm not too keen to make further changes to their build system unless it is essential - however, if you are curious about this particular case, you could raise an issue in their github project page and we can try to understand 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] Comments regarding jssip_0.3.7-1_amd64.changes
On 06/09/13 09:32, Luca Falavigna wrote: Hi, I'm wondering about the files under src/Grammar/dist/. According to README.md, it seems they are generated using PEG.js. Can these files be generated at build time, and with what tool? PEGjs has been packaged too The package includes two build systems, grunt and a Makefile The Makefile includes rules to generate the Grammar at build time on every build ___ 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] packaging dependencies for Drupal modules
Drupal has a libraries module that helps co-ordinate the use of dependencies This seems to fit well with Debian's way of sharing library code, so I've started packaging it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704196 One of the main intentions of this is to share JavaScript code, such as that deployed under /usr/share/javascript on a Debian 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] packaging WebRTC, and pkg-javascript git repos
Hi, Thanks for adding me to the group I'm planning to upload packages of the two main WebRTC clients, SIPml5 and JsSIP I haven't done any JavaScript packaging before so any feedback is welcome I'm also working on the server-side infrastructure for WebRTC to come into Debian: http://www.resiprocate.org/WebRTC_and_SIP_Over_WebSockets Also, I notice that git SCM wasn't enabled in alioth, so I enabled it. Now it displays a link to http://alioth.debian.org/scm/browser.php?group_id=100128 and doesn't easily let people browse all the repos Furthermore, when I was added to the group, I notice alioth didn't automatically add me to the UNIX group scm_pkg-javascript - maybe this is because the SCM tool wasn't enabled at the time I was added. Anyhow, I've raised a ticket for the alioth support group to check my permissions. Regards, Daniel ___ 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] packaging WebRTC, and pkg-javascript git repos
On 23/02/13 23:32, Jonas Smedegaard wrote: Also, I notice that git SCM wasn't enabled in alioth, so I enabled it. Now it displays a link to http://alioth.debian.org/scm/browser.php?group_id=100128 and doesn't easily let people browse all the repos As I understand it, the Alioth interface is crappy and only provides interface for a single git repository, not a pile of them as we need. If I am right in that, I strongly recommend to *not* enable the VCS in the Alioth interface. Ok, but this could also explain why I had a problem with the UNIX group, we could end up with inconsistencies in our group memberships as new members get added. Maybe we can ask the alioth admins to let us substitute the SCM git page with some link to our directory of packages? Also, I prefer to use collab-maint and only use this team at Alioth for our mailinglist. The reason for that is to make it easiest possible for DDs to contribute (because all DDs are by default member of collab-maint). I find that easing access for DDs outweigh making it easiest possible for non-DDs to contribute (they need to first become member of our team and then ask for additional membership of collab-maint). I have heard rumors that it should be possible to ask the Alioth admins to mark our SCM area as automatically including all DDs just as the collab-maint does, but I have not checked if that is indeed possible. Let's have a look, I have two accounts: my guest account is in collab-maint (like many guest accounts): pocock@vasks:/git/collab-maint$ id dpocock-guest ... 40755(collab-maint) ... and my DD account is not in collab-maint but gains write access indirectly: pocock@vasks:/git/collab-maint$ id It may be that we want pkg-javascript owned by one of the other groups, e.g. scm_Debian I'd actually be in favor of giving much wider access though, if only we could limit certain high-risk activities (like git push --force) to pkg-* admins The more significant motivation for using pkg-javascript/*.git is just the logical organisation of the packages rather than security Do anyone in this team object to grant access to all DDs to our SCM? If not, do someone volunteer to figure out if it is possible? Furthermore, when I was added to the group, I notice alioth didn't automatically add me to the UNIX group scm_pkg-javascript - maybe this is because the SCM tool wasn't enabled at the time I was added. Anyhow, I've raised a ticket for the alioth support group to check my permissions. Maybe just a matter of time. Some ACL-related stuff is applied by CRON jobs. Ok, I'll check again tomorrow The package is uploaded now: http://anonscm.debian.org/gitweb/?p=collab-maint/sipml5.git I've just been making some test calls between wheezy and squeeze (both running Chrome 25) against my patched repro SIP proxy Just install the package and visit http://localhost/sipml5-web-phone ___ 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] packaging JsSIP - npm, grunt, etc
I've had a look at JsSIP:
https://github.com/versatica/JsSIP
In particular, it is built using a tool called grunt, and that requires
nodejs and the npm tool
It also pulls in some other dependencies:
https://github.com/opentelecoms-org/JsSIP/blob/master/package.json#L23
devDependencies: {
grunt: 0.3.17,
pegjs: 0.7.0,
node-minify: ~0.7.2
},
I'm just wondering what is the approach here:
a) should I iteratively create packages for everything in this hierarchy?
b) or do I just package the release artifact distributed from upstream?
http://jssip.net/download/
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
