[Pkg-javascript-devel] Bug#892227: Bug#892227: node-backbone: dependencies fail to resolve when jQuery not installed
Quoting Ben Finney (2018-03-07 02:51:55) > On 07-Mar-2018, Jonas Smedegaard wrote: > > Quoting Ben Finney (2018-03-07 01:04:19) > > > $ cat ./source/foo.js > > > "use strict"; > > > import 'backbone'; > > > > > > So the Debian package dependencies are all satisfied, but these are > > > not sufficient for Webpack to resolve the Backbone dependencies. > > > > Backbone by design avoids dependency on jQuery. > > And yet, a very simple application that *only* requests ‘backbone’ > will fail to build with Webpack because Backbone tries to find jQuery. > > In other words: The expectation is that installing Debian packages > ‘webpack’ ands ‘node-backbone’ should allow the above application to > build with Webpack. > > So, something is wrong with the Debian Backbone, or the Debian > Webpack, or something else. I slept on it, and realized this morning¹ that you are right: This is a bug in Debian packaging of Backbone: It should recommend node-jquery. Similarly it should recommend node-underscore | node-lodash. I will make that happen. Thanks! - Jonas ¹ ...before reading your reply above, but that helps too: Your emails are in general easy to comprehend and quite often enlightening. Thanks! -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#892227: Bug#892227: node-backbone: dependencies fail to resolve when jQuery not installed
Quoting Ben Finney (2018-03-07 01:04:19)
> Package: node-backbone
> Version: 1.3.3~dfsg-3
> Severity: normal
>
> The dependencies for ‘node-backbone’ do not allow a Backbone
> application to be built with Webpack.
>
> =
> $ dpkg --list webpack
> […]
> ii webpack3.5.6-1 all Packs CommonJs/AMD modules for
> the browser
>
> $ webpack --version
> 3.5.6
>
> $ cat ./webpack.config.js
> "use strict";
> const path = require('path');
> module.exports = {
> entry: './source/foo.js',
> output: {
> path: path.resolve(__dirname, 'dist'),
> filename: 'app.js',
> },
> resolve: {
> modules: ['/usr/lib/nodejs', '.'],
> },
> resolveLoader: {
> modules: ['/usr/lib/nodejs'],
> },
> };
>
> $ cat ./source/foo.js
> "use strict";
> import 'backbone';
>
> $ webpack --config webpack.config.js
> Hash: a9597112585b9ca5fb40
> Version: webpack 3.5.6
> Time: 209ms
> AssetSize Chunks Chunk Names
> app.js 129 kB 0 [emitted] main
>[0] ./source/foo.js 34 bytes {0} [built]
>[1] /usr/share/javascript/backbone/backbone.js 72.2 kB {0} [built]
>[2] (webpack)/buildin/global.js 488 bytes {0} [built]
>[3] /usr/share/javascript/underscore/underscore.js 52.9 kB {0} [built]
>
> ERROR in /usr/share/javascript/backbone/backbone.js
> Module not found: Error: Can't resolve 'jquery' in
> '/usr/share/javascript/backbone'
> @ /usr/share/javascript/backbone/backbone.js 17:4-21:6
> @ ./source/foo.js
> =
>
> So the Debian package dependencies are all satisfied, but these are
> not sufficient for Webpack to resolve the Backbone dependencies.
Backbone by design avoids dependency on jQuery. Applications may use
jQuery via Backbone, or may choose to instead use Zepto or Lodash, and
then need themselves to make sure the chosen helper is available.
At http://backbonejs.org/ is listed a few projects choosing to use
Backbone with Zepto instead of jQuery.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: 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] ES6 ‘import’ of Debian-installed module
Quoting Ben Finney (2018-03-06 22:37:22) > Pirate Praveen <prav...@onenetbeyond.org> writes: > > > On ചൊവ്വ 06 മാർച്ച് 2018 03:45 വൈകു, Ben Finney wrote: > > > Is that a bug in the Debian Webpack, or a bug in the Debian > > > Backbone, or a bug in the Debian jQuery? Or a bug in the Webpack > > > configuration I've shown above? > > > > Do you have node-jquery installed? I don't think it is a bug in > > webpack or jquery, because the combination work well in case of > > gitlab. > > The Debian ‘node-backbone’ package does not depend on ‘node-jquery’, yet > when Backbone is imported it needs jQuery. So this is a bug in the > Debian ‘node-backbone’ package? I suspect that would be an upstream bug - http://backbonejs.org/ says: > Backbone's only hard dependency is Underscore.js - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Javascript team policy and rejection of node-three binary package
Quoting Pirate Praveen (2018-03-02 15:26:40) > Javascript maintainers team have evolved a policy for javascript > packages and it is available at > https://wiki.debian.org/Javascript/Policy > > Its last point says, > 5. should generate a node-foo binary package if the script is usable > also for Nodejs I generally read team policies with an implicit "...as long as it doesn't conflict with the general Debian Policy". Specifically, I read the "should" in above quote as "in most cases, but not a "must". We have in the Javascript team an old practice of avoiding duplicate code: When code is same for Browsers and Nodejs, we ship the code in the libjs-* package and have that package "Provides: " the nodejs package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] select2.js_4.0.3~dfsg2-1_amd64.changes REJECTED
Quoting Thorsten Alteholz (2018-02-21 23:00:10) > one of our trainees looked at your package and found: > > docs/_sass/vendor/bootstrap/*, docs/css/bootstrap.scss copyright > "Copytight 2011-2015 Twitter, Inc." is not listed in d/copyright. > > docs/_sass/vendor/font-awesome/*, docs/css/font-awesome.scss copyright > "Font Awesome 4.5.0 by @davegandy" is not listed in d/copyright. Excellent spotted! I will make sure to improve licensecheck to cover that typo (and a few others - apart from "Copytight" and "Copyeight" both obvious typos (neighbouring keys on most keyboards) codesearch.debian.org also reveals "Copylight" which I guess happens among native japanese people (for whom consonants "l" and "r" are audibly difficult to distinguish). @Thorsten: I am curious if the ftpmaster trainee spotted it by manually sifting through the files, or if using some tool then which one handled this typo? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#890395: Bug#890395: uglifyjs: Please update the package to new version v3.3.10
Hi W. Martin, Quoting W. Martin Borgert (2018-02-14 12:21:24) > v3.3.10 has been released on 2018-02-08. > Please consider updating the Debian package. Thanks for raising this issue! Uglifyjs 3.3.10 is now released to experimental. Since it is a major new release - SemVer-versioned, which implies backwards-incompatible changes - so the package need to be tested against its reverse dependencies before it can enter unstable. Help is much appreciated doing that compatibility testing! If it turns out too many reverse dependencies cannot use UglifyJS 3 (and cannot easily be patched to do so), the package could be released as separate uglifyjs3 source+binary package. I might also choose to go down that route if too long time passes without anyone (myself included) finds time to do the needed testing of all reverse dependencies... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Accepted uglifyjs 3.3.10-1 (source all) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 14 Feb 2018 20:23:59 +0100 Source: uglifyjs Binary: node-uglify libjs-uglify Architecture: source all Version: 3.3.10-1 Distribution: experimental Urgency: medium Maintainer: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org> Changed-By: Jonas Smedegaard <d...@jones.dk> Description: libjs-uglify - UglifyJS in library form node-uglify - JavaScript parser, mangler/compressor and beautifier toolkit Closes: 890395 Changes: uglifyjs (3.3.10-1) experimental; urgency=medium . [ upstream ] * New release(s). Closes: Bug#890395. Thanks to W. Martin Borgert. . [ Jonas Smedegaard ] * Set experimental branches in git-buildpackage config. * Revert to watch file to track any upstream version. * Update package relations: + (Build-)depend on node-commander (not node-yargs). + Build-depend on node-semver. + Stop build-depend on node-escodegen node-estraverse. + Stop suggest node-uglify-to-browserify. * Drop patch 1003: Obsolete (code now uses commander, not yargs). * Unfuzz patches. * Update copyright file: + Extend coverage for upstream author to include recent years. + Strip superfluous copyright signs. * Stop fix executable: Obsolete (extract-props dropped upstream). Checksums-Sha1: 25312592442c369b7ee483f3da26a9399b7119d8 2131 uglifyjs_3.3.10-1.dsc 5ccbcd2257bdf860cd240f51cf419f0bbed3cd5d 261152 uglifyjs_3.3.10.orig.tar.gz 1e5ee454117fb5c5bb94860feb43b23ae528f6a1 10480 uglifyjs_3.3.10-1.debian.tar.xz 0f552cc0bef1204c1d93c040bd8b6289987474db 80584 libjs-uglify_3.3.10-1_all.deb 791299c2496bb5ea3a291d1b8317376e1323d8f4 125936 node-uglify_3.3.10-1_all.deb 6504b544c7436509c475b25417f469ce40fb66e0 8742 uglifyjs_3.3.10-1_amd64.buildinfo Checksums-Sha256: 5b18c9559265b6442e7785f6856a136762055922ec3f0a5d4706928b7867f86c 2131 uglifyjs_3.3.10-1.dsc df9622a9b3d87e547a4a235833e3ebf598694dea068a9816aab884eb936c5418 261152 uglifyjs_3.3.10.orig.tar.gz 8e0d713687bfe05c91c5e179860beb0fdebfa9dd7e1a151461c82acc58e8cca7 10480 uglifyjs_3.3.10-1.debian.tar.xz 1bd4e5d2a1dc7952d5b29b5175d69308074b738bb9f35275dfd647f4f2e6bda4 80584 libjs-uglify_3.3.10-1_all.deb e1a1f186897f8d1262342f0a3fc5999efba535c5125e81b27561a56f10bcb524 125936 node-uglify_3.3.10-1_all.deb ea6ea42a782e1f3d5dba68b5515caa2064fe856525bcf7d405185132b8e859ee 8742 uglifyjs_3.3.10-1_amd64.buildinfo Files: f8b0ea592291492b67d61c1c600218b0 2131 javascript optional uglifyjs_3.3.10-1.dsc 9e93d6f532ec1ee1320c06bc968401e5 261152 javascript optional uglifyjs_3.3.10.orig.tar.gz c34940ada20b0f42a1c16f599cc9677a 10480 javascript optional uglifyjs_3.3.10-1.debian.tar.xz 626059394d41c574aab2a67dc218e455 80584 javascript optional libjs-uglify_3.3.10-1_all.deb 0b8182d1ec93527639906d31ba440e9d 125936 javascript optional node-uglify_3.3.10-1_all.deb f4b4bca4fbb7cebe64128632b8923a0d 8742 javascript optional uglifyjs_3.3.10-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlqEkcoACgkQLHwxRsGg ASGmUQ//Wv1Fnp6q2+ualwWSpCW5nqUVHYHR1y/iJ+jMY9nLMTOHqkUrgfi3rcz8 QMQmjrlO8gJVR79CguLICKyK8ELn9MAq73nD9sFkrKyliM1JbxK89amlABhdAXik RLCxGE4EPDOEdxILe3HH91Y3tds8oPDpOSJVT7z9e0bQd/eFWx985QAZuZsJHEA4 6VmXJvsdjwv7YUpE+VGpTzcSKcRYCCM3hs75/9ecYIDNd87LGNU+VewpAQdHM+FA 1gISCsfPWhikyjBFHco0Qrso90TpClamt2ntgUt307nEgzu5YB6TzD9buvzYZ/+p lPc5yGtbXqLPubTjgaLemIRUL5+Cu7CJIM//Qn0vZzZZiDLTJa4PBPCn8yUEh8NW T0a94qHNC/nQPxGIF5loCW29nUbCDAXTuGDbE/rzy+jsArf/tRUmkO9471q+cYTd +WqWTfJd3mgwySEZcUjxXImkqbUyUzJuYTbZsPPpTESNziAfmAeOGZxv2yKIerTg xf/roX5IVV3qa7l+J8j/cEFkM3CVFBQczgkc+UZpss9FByP+Ypg9bMyqPJj+IdNE Xt9UNPpq3VFlFeJDnVn6PWxHgc3bYTOoNO1T4UiALM4cl1qqZY1a6BQ6ERQJwrcI C4rfU08wmuE22LBggIoStChE1/P7nm/Ky3Aa+jhOxKcCu75bi2c= =2xbF -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] Review request: rainloop
Quoting Daniel Ring (2018-02-02 04:48:25) > However, upstream bundles quite a few dependencies, and in a few cases > they have modified the minified code of bundled libraries to fix bugs. > I added everything that couldn't be unbundled to debian/copyright but > I'd appreciate a review of this to make sure I've done it correctly. In the cases of bugfixes to minified code, those bugfixes should likely be passed upstream to those other code projects, and if those code projects are aloready packaged for Debian then possibly also applied to the Debian packages (e.g. for security-related bugs affecting stable). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Accepted node-uuid 1.4.7-5 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 01 Feb 2018 16:00:43 +0100 Source: node-uuid Binary: libjs-node-uuid node-node-uuid Architecture: source all Version: 1.4.7-5 Distribution: unstable Urgency: medium Maintainer: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org> Changed-By: Jonas Smedegaard <d...@jones.dk> Description: libjs-node-uuid - simple and fast RFC4122 UUID generation - JavaScript library node-node-uuid - simple and fast RFC4122 UUID generation - Node.js module Changes: node-uuid (1.4.7-5) unstable; urgency=medium . * Add autopkgtests. Thanks to Pirate Praveen. Checksums-Sha1: 527f63f4ee77255b9ec746223a930e5e5153b8f2 2045 node-uuid_1.4.7-5.dsc 29ce8532d3e0fa6c7266f4f2e6aa87b2fe9ed910 5092 node-uuid_1.4.7-5.debian.tar.xz 8940fcd0d6206936d6e4c23241001519eeffc400 11688 libjs-node-uuid_1.4.7-5_all.deb 51ea1b52dea7216eb596adaf0405f6c8d8cf6f3d 8500 node-node-uuid_1.4.7-5_all.deb 9c43607719d838a293f537654f4e846e9a4dbd65 7080 node-uuid_1.4.7-5_amd64.buildinfo Checksums-Sha256: a174d59c14a22c672f12e1d8c1e8b7c71a85a6fb3674bb65f1d977c85b514e97 2045 node-uuid_1.4.7-5.dsc ab9173839d4bf6826e6d9eada2249baad1fc1918e3a9d170e638789cb26115e0 5092 node-uuid_1.4.7-5.debian.tar.xz fa83fdccf0b0e3872f053b29f818e3bc3c9e98ae143289da5504410c087a5ee6 11688 libjs-node-uuid_1.4.7-5_all.deb 8c121b86765ee1ea001279014f08211b8e2cf6ae02285864456112dd5d71cbc9 8500 node-node-uuid_1.4.7-5_all.deb 388b47f7c648abfeec695ab3c5fc91c7055fc322d2e5eb7c96994576384552c9 7080 node-uuid_1.4.7-5_amd64.buildinfo Files: 2521a6444547c0b006e844a37a1fd4f9 2045 javascript optional node-uuid_1.4.7-5.dsc f718a54f45935fb597b432acabaa2e7c 5092 javascript optional node-uuid_1.4.7-5.debian.tar.xz 1ebc18b340b499baca84b6fca2eaf7dc 11688 javascript optional libjs-node-uuid_1.4.7-5_all.deb 37a74e318aec39f0f5ce1f1997fef204 8500 javascript optional node-node-uuid_1.4.7-5_all.deb c2e133688ad45877aecbad72f80f69dc 7080 javascript optional node-uuid_1.4.7-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlpzLCgACgkQLHwxRsGg ASHVHQ//UnC1U/Y6MFH9Bu/ahZtWFUViDoVRbVOj0U80PS+CMlXNBn4QL7aw06MN 7aA+ncfyJWjKbjFkImKHgBwiYxROW5jc8vq/j6KpNbt4igipSauVCsWXXYXaOOzQ j+URf+Z1gUZnYgMBS/fXlbe7a/mHyD2WbdFn7k0mOljzehnvxQDSgWx4+r0KqN3Q 98/cvukUZQmC/Vyi1T/nmsHxLWQ8MJLunLlx8Uc7d68M/8/ukrLNopua9RLP9jxw n0Wg2LeBzztn/M0lL6JrN+f/Qf1+Yg1RMF2d9yOCBc+M5i2k7vHmwKsY0+dWqtEy Vs7NPvXrXswrKYFuWE/G6RPL134kf8PphwreD1gzJWSGV63aqgnHXWAtCwr9ypPb kxuzdR731StZ0cIwarcaM7LeyVmjVWvOunaDnAs25a1wo7mAC8zntbwCHqa5yMWd VUjTzDSOhg1vY7rZxKBgTiNUtWaKP571sZhmr9Ax9imGZZ4kLEQU/luGaX2uwgwx siSp+QFjkrOLufl1YIGfpgF4/LBxFPfQC8AGhUm8Qa3Vbkz7okDPcuJVUYtH5jHL dRNLnDtdDGSc/HZcp1QoV7EPe11soIwOv6JbzsaN3pNfwotybwK5IeeO3W2360r9 OJuBBsWlSrRafvo+AmI8Ynr8Yax3siwmGoTfOoKf/J3uENgyxYk= =jnHP -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] node-node-uuid
Quoting Paolo Greppi (2018-01-10 10:04:57)
> Il 09/01/2018 13:33, Jérémy Lal ha scritto:
>> 2018-01-09 12:53 GMT+01:00 Paolo Greppi <paolo.gre...@libpf.com
>> <mailto:paolo.gre...@libpf.com>>:
>>> Hi, the package node-node-uuid seems broken, this fails: nodejs -e
>>> "require('uuid');"
>>>
>>> Also it triggers lintian error
>>> node-package-install-in-nodejs-rootdir because it installs
>>> /usr/lib/nodejs/node-uuid.js.
>>>
>>> Next 1.4.0 is quite old and v. 3.1.0. is required for node-yarnpkg.
>>>
>>> Finally I have some doubts on the the naming,
[...]
> From here:
> https://www.npmjs.com/package/node-uuid
> it says "node-uuid DEPRECATED: Use the uuid package instead."
>
> It appears node-uuid was a fork, then it got merged back.
> There are two github projects both confusingly called "node-uuid":
> - current: https://github.com/kelektiv/node-uuid is at 3.1.0
> - deprecated: https://github.com/brrofs/node-uuid is at 3.0.0
>
> The debian node-uuid source package upstream is the "deprecated" fork.
> That's why the tracker says "a new upstream version is available:
> 3.0.0" and not 3.1.0
>
> In the light of these facts I am even more convinced that it should be
> renamed.
> Additionally its upstream should be set to
> https://github.com/kelektiv/node-uuid
Thanks for the investigations, Paolo and Jérémy.
Yes, node-node-uuid is quite confusing and I am happy that upstream haas
cleaned up that mess, so we can do so as well (our package was wrongly
named and partially corrected in release 1.2.0~20110510-2 to at least
get the binary package correct).
I will look into updating the package, including checking that its
reverse dependencies work with the newer+renamed node-uuid.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: 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#883956: node-rollup-plugin-commonjs: should declare that it "Enhances: rollup"
Package: node-rollup-plugin-commonjs Version: 8.2.4-2 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 node-rollup-plugin-commonjs is a plugin for commonjs - i.e. and enhancement for that. Please declare it in the control file, to ease locating the package when browsing for packages relating to rollup, like this: Enhances: rollup - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlosO4cACgkQLHwxRsGg ASEvUg//dKEblBgPm6wwOEtZ0eFgsdjx3iZb8ZvbiSpEHuG8zHzybuLVBRrp6Ljg dFUx3aTaoEofJrlGR+QTmzzSMyPKv/B3mzjrNFROwrt8bHZifS2GeUotBmbitvf6 WIWtWPKs80TqiGWy0Jf/zBgMRihewCdYU5+HcYeVuDQchKHliu/QBus+/YDiP8Rl uDYWTHtv46XRm7Q34O0XpJ23tbfLAITvSG+pkhHYsisAaaFUUP8Ll06kzj4ZHwMK k0mQSFGC2v9lYzq7ZJgnGPmSQ1z9jX2LP5VMlOWD+My+kVGdJ4upIn8RACKvkSXK 3MzsYlMDuFfTb0mSv/DAYikiLSY0dJoKWj5Woqglmon/mUO3nNLudNQOFToj57/R 4Uc5UYWd8bzoHVZxuiZwZpt2GfmO21QHLcQJnJIwXBXQQMvODOSMYRhcEYjUHonL 5ZBV8G6SLYoBNnhDjr1G5d0zjGn8hZGflAwsjpsWkiOjKfeLEr2CE+sDXZQRS1Sq ig4VrySdz/eUNDt5tkN908OhWWhiNPl5axO097+P3Cql8jZRkWLep7OJzX8moSlb jHCsRbPQVAlDdar/u9Az2tyirRxxMxS+x42D2H5vsXwlWzL+5DJgxZRTGUBMJPEQ gXh7MmMElhVobw2lWmOa2Mi3l2zNfqU5/Od6ibmAf3UyY6v0HYY= =Ddz5 -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#883954: rollup: wrong homepage - should instead use https://rollupjs.org/
Package: rollup Version: 0.47.4-3 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The rollup package lists its Github page as Homepage. That is wrong: Even that Github page instead promotes as its homepage this: https://rollupjs.org/ - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlosOoEACgkQLHwxRsGg ASHHtA//bJXe53Px1L8p7Io32yK81DGnLCHco7HHUOTjG8yUiRr5gCnCOzjUKGG2 nLekJFtztUKmkR7Mz1S7xIRUJ7r9JoObU2pNEDyjjArExDfBU3XS9Dw9BbY7ChXE 7Xe1GvT+P3/uW+8DZQ2b3NyV3Hrhlb96HkN7QHFaNR+zReD/vi0Twv9Py6l35cOz sazaDeA6ZIkxrTY4UWaAYLCtACKq9ch74RrMbpok7Gai7j00PdVJcNmFKNj89GW7 +7nE3OXypryJUgl5aH7qop4qPzzG7iCtVwzYNAnkve3uNi189lIV/FDuIYyY27xh YXPgS/mQrAgfhlzVs8SoiM6ZZqe508EWZVyI4+j+zGBD37+y/PXKnu/qry3t8Q8S MWPTS1SSvNibqGVXXrICvPB5FEYVLuXODbfXHwgI46edAaOY7QUR28QVMozD7OlI qIpwTjGah0piknFAH1XTJlFYC8qhZ4cOpLQ5BNI5CrqCtZNnmZzSfCQpK6RRtAmJ ybrihD63/iztBknr1dpwHL2Y61v3dvG0J2HTmyrUXY2g3oCW1giF6IaoV2+9ucHE ImLpa4O/v7Da9zlLRSAWdZe58vyd3puOW2gRoKrcEsJ1fBDASN496SXMlo4W6GNh OqY4x20Y37ems87hJv3Tv45iwxnqZPcAWzPrYWZLgh6UdoN/zjo= =OxNF -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#883409: webpack: depends on non-existing package node-uglifyjs-webpack-plugin
Package: webpack Version: 3.5.6-1 Severity: serious Justification: 2 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The binary package webpack depends on non-existing package node-uglifyjs-webpack-plugin, making the former impossible to install. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlokKeAACgkQLHwxRsGg ASHF/RAAiJN2TCNXESFBRDOkHGd8P//x4KJ0tx9D+afi7MRaPxO3n58cxJyMiKjD WlwszYEe6g24URaH2XZqF3aN5JkCwp6usXwQlejwMuRWfVvwWthM04jRJQ8KP1+q I7Jv5+6Wr70Y5YGAmHcNRn2sCPvywsUPV2ciHmC5z4gWFV5bzyxDNjAvgb0/ubiV U9P4DJhxuRDyfDz+oG820qHAQ6QEDKyubr+8ycUa4dtPV+8RyaEvPOpP4UTvzK6w ltrasb5O7peNeG1CCDIu+8p/7+E/tyaJJcmufs5fTPcS+8ClLrRg5Xt7haJfauw8 dBbXsCSe0suH4xoUqZ/hXNHvPontg3pCQryzKScc07w79fsAlEgZIfbgIlVIXWtg aLJcaoXGkrcVsqfDUswRRHEHoeod3QXrw4ij0QvoBi0pdbAe3krAZhmA5a0ExnrN jS75rntnKv71SQCQB6UlKuH4VC73pvE9MiMkRmind+EKP8cUO5DlZHHplNc1EB4W Ai2y5pZoPYmhL5GgjVcLMeOhzXOUdB605x8nvuWxeVxmADp0wmYa/k+QnUZQapkD E4FJ9Qpn6DEnJHfcwd1BsuEVm7d8l2JApS/6AwJ81HHFWJCGws1irSMU9so9WFBR YaIVPIZ0Lwml3YGlq2sfc4uvLzkvWXpJbtEAjNaj9OiYon3zCZc= =TuNH -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#882467: node-typescript-types: should provide virtual packages for each /type package, versioned
Package: node-typescript-types Version: 20170519-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Currently there is no way to ensure dependency on a specific version of a specific Typescript type library. Please add "Provides:" hints for each included type library, with version (which should be supported with recent APT tools). - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloWmLYACgkQLHwxRsGg ASGeJA/9HKQylf8tPxDVcOeExxp398FRg8rXiJZAdpJ0pEqE+ArvZmYKwxfx2Uxn lEe4+aeStmvqe76lazoESQf/16ft8KD+lBgoWY42TiuZ+XDu/yRfikFFCOh0DRBU nonGW8KMWD7TFwrz2Qnzu6J1TxW6pNrKLmZ9z8nTgZJn37sVxaLAw7pA6KAGZG2Z b/Je1Mjba1GAcZDR23NWr+doSE0imCQWf/d2q1cdknPBMVoDilWFHy3ENIOR+sFF McuSAOxC738CZarPzYl+B1CKWl/jcNGmr8W4dZGvjOFKyx6d6DOWlrf63+IGStsW as3ZKroKxe1BqQppKiLaO7GjadQitqKofDJV9rchLXl35BRy7c+c4GFMHqu/9Sqr vnovY3FtrHiJRRQOfCrrNSTTZ1AsKJ6v/s4ysQVxdAnUwJu/4LWDdFLJIIKB0xOI QbFQyZUfhfTH34fKLXx21dRUE8AppjDcTwvG89RrSv2TJWjkXH1UCMZaw9gvm/O8 GrUzA5DRGodnNFNFH/nR7ZOL8BJCfnzNuIQjEunCnSkZzt5o0Kh59PUI9UwlcKrV 2yU0Wqx0OXQ/eXQ1A1QQHr1P+f+t0CWDRj7zPJwWXR0QJJDNCDJqIcPXG5/QxwYX Gyh5w2kCrWg+tBxSEoLh/oRtxGKCWHbd8sxnzL8XeTvvqvF71VQ= =MnOj -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] node-babel_6.25.0+dfsg-13_amd64.changes REJECTED
Quoting Pirate Praveen (2017-10-24 05:43:48) > On ചൊവ്വ 10 ഒക്ടോബര് 2017 03:49 വൈകു, Pirate Praveen wrote: > > On ചൊവ്വ 10 ഒക്ടോബര് 2017 03:05 വൈകു, Pirate Praveen wrote: > >> Sorry about the whole discussion escalating to this level. > > > > Just add context, I was asked to add this to copyright file by another > > ftp master and it was not found by licensecheck. > > > > http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-August/020220.html > > > > and it was accepted subsequently before Chris brought up again. > > Just asked upstream about the license and my initial assumption about > these being under Apache license was correct > https://github.com/babel/babel/issues/6497 I am growing tired of your weird non-constructive parts of this conversation, Praveen: Please either respond(!) to Chris' points, or or if you insist on talking to yourself about different topic(s) then remove the Javascript mailinglist from that weird conversation. For others following along: Praveen contacted me on irc requesting advice on this email thread, and I believe we had a sensible conversation. In other words my remark here does not com out of thin air - I tried (albeit in a side-channel, by Praveens choice). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] Javascript policy and npm2deb
Quoting Pirate Praveen (2017-10-12 08:25:06) > On ബുധന് 11 ഒക്ടോബര് 2017 10:10 വൈകു, Ben Finney wrote: > > What change to the policy do you suggest? > > > Add this, > > 6. If the library is primarily developed as a Node.js module and browser > part is generated from Node.js sources using a module bundler like > browserify, webpack or rollup, it should follow > https://wiki.debian.org/Javascript/Nodejs/Manual I see no need for making policy on such detail. Seems the need for such policy is to keep code in npm2deb simple, but If only a "should" then npm2den needs to handle exceptions anyway. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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-tap-mocha-reporter_3.0.6-1_amd64.changes REJECTED
Quoting roucaries bastien (2017-09-06 10:11:24) > On Tue, Sep 5, 2017 at 11:00 PM, Thorsten Alteholz > <ftpmas...@ftp-master.debian.org> wrote: > > > > Hi Bastien, > > > > please mention TJ Holowaychuk in your debian/copyright. > > Done reuploaded > > Will open a bug against license check, and will add a mental note Thanks, I will look forward to that, whatever it means. :-) Remember to also push the packaging git to Alioth - it seems you didn't yet. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#873380: Find copyright holders in the contributors list
Quoting Julien Puydt (2017-08-27 11:02:36) > npm2deb could also get copyright holders from the contributors list > instead of just the authors. Copyright holders _may_ be the authors or contributors, but not necessarily. If a project does not explicitly state who holds copyright, then it makes sense to try guess who the copyright holders _might_ be but such guessork should then always be double-checked by the package maintainer and if used in debian/copyright then pleas additionally add in a Comment: field that copyright holder(s) were assumed from that weaker indirect information. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] wanted: maintainer(s) for jquery
Quoting Antonio Terceiro (2017-08-23 20:00:20) > I just pushed a commit to the git repository of jquery removing myself > from the Uploaders: list. Nobody else has done anything on this > package in a long time, and I am not willing to work on it anymore. > > Even though jquery is inside the pkg-javascript "team", it is now > effectively orphaned. Anyone willing to work on it can count on me to > answer questions to help them take over; just reach out by email or > IRC. That's sad, but understandable. Thanks a lot for your past work on that challenging package! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#873016: Bug#873016: node-lodash-packages: not preferred form for source: Should be built from node-lodash
Quoting Pirate Praveen (2017-08-23 20:11:28) > On ബുധന് 23 ആഗസ്റ്റ് 2017 11:33 വൈകു, Jonas Smedegaard wrote: > > Package: node-lodash-packages > > Severity: serious > > Justification: Policy 2.1 > > I do not think the root issue is serious, but only important. Lack of source is serious. Please elaborate why you think differently. > > The source package node-lodash-packages does not contain the source > > form preferred for editing by upstream. Instead, upstream documents > > how the contents of that code is generated from the sources included > > in Debian in the source package node-lodash. > > Adding a build dependency on node-lodash would be enough for the > policy requirement. If your reasoning is that the bug is easy to fix, then that does not change the severity (only - hopefully - the longevity of the bug staying open). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#873016: node-lodash-packages: not preferred form for source: Should be built from node-lodash
Package: node-lodash-packages Severity: serious Justification: Policy 2.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The source package node-lodash-packages does not contain the source form preferred for editing by upstream. Instead, upstream documents how the contents of that code is generated from the sources included in Debian in the source package node-lodash. - Jonas -BEGIN PGP SIGNATURE- iQIyBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlmdw4sACgkQLHwxRsGg ASGTug/2Lp398huckuiUYZpi1L3JQ1gKA52++Vn/q57MoT1nRd/9FvY9dkRuNmCw B1kD+wp/Fd/MkWxdP+b/ZaoizQbbpGLg6BT1AHqFht1iwLl1pNDYsJkHx3R9LqTW JCOfaKsetIcW+DPzYV6sbaqaULWtxK1p1oN9xcYsFaeD+vBk8D1dIerT3E6wLbRJ B6p/h7T6k1nHZdik1eTD7Hyereocu8QzicNhkY0lCOmqa//bWTrkrP4xPICM0JEw g3U8VlUHkezb+XlP/IcRp7iK6Oz7L5c2ZBmzxxmku/tapGMbtqm7JI/lvjuNldyZ TKepo6jywEjJAx6F3D35U5vEla22TRpWNm0UP4S9IzAxfl4nGofY2vOp1lR8cNbb LMhXWIdIcAA5NKwMxnzSZv4zH1tEPB8GrPNPUM8FCuwQN2mNxlURhkb7S8TZX2di QdmvR6lRuECrOUWS6VeRsPK1HeHqXkKDo52fSJK5yCfJChHxPHtNUv+mARs3BWdC rZVQcVXm4BoQp2OdwsqIH5Wg/h89GApRVh16C/6bbjWe7tim7QCt0W6B67woHmU2 cK41cZVvcCawPFzC1N2ggk8SqI+3bxsokN/YvAUibZRpj+box92QlJNd9Yak9IlF 7BU/XDLRlrRegafJ1KRm8P66v14D+O3PfAso3nCQCAHFI2MtXA== =Kn8q -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] JavaScript in-browser program, packaged in Debian
Quoting Jérémy Lal (2017-08-23 09:27:54) > 2017-08-23 8:50 GMT+02:00 Ben Finney <bign...@debian.org>: > > > Ben Finney <bign...@debian.org> writes: > > > > > I am interested in packaging for Debian some JavaScript code that is a > > > self-contained program. > > > > > > Such programs are designed, by their authors, to be downloaded to a > > > directory and loaded from there into the user's choice of browser. > > > > An example of such a work is “MuscleBook”, which “has no server and > > works completely offline” <URL:https://github.com/cfilipov/MuscleBook.net > > >. > > > > > To package such a program for Debian – into a hypothetical Debian > > > binary package ‘ipsum’ – I expect that installing that package will > > > give a command-line executable program, which launches and runs. > > > > So, I would expect after installing the hypothetical ‘musclebook’ Debian > > package, that a command such as ‘/usr/bin/musclebook’ is installed. > > > > Then, running ‘/usr/bin/musclebook’ at the command line invokes a new > > browser tab (or a new browser window is started) visiting the MuscleBook > > ‘index.html’. > > > > I understand how to install the files (to ‘/usr/share/musclebook/’, for > > example). What comes next is to work correctly with the Debian web > > browser convention, and have a command-line program load the file > > ‘/usr/share/musclebook/index.html’ in the currently-running browser. > > > > How would a Debian package do that nicely with our conventions? > > > > xdg-open ? Not sure, but I think sensible-browser is better: As I understand it XDG covers only graphical desktop environments, whereas sensible-* tools cover console environments as well. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#872899: node-tap: autopkgtests fail with nodejs 6
Quoting Graham Inggs (2017-08-22 11:35:11) > Source: node-tap > Version: 8.0.0-4 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu artful autopkgtest > > Hi Maintainer > > Since the upload of nodejs 6, node-tap's autopkgtests have been failing > [1] with the following error: > > # failed 3 of 47 tests > # skip: 7 > # time=113059.894ms > autopkgtest [11:52:27]: test command1: ---] > autopkgtest [11:52:27]: test command1: - - - - - - - - - - results - - > - - - - - - - - > command1 FAIL non-zero exit status 1 > > The tests have been flaky in the past, but now they seem to be failing > consistently. Perhaps solved in a newer upstream release: Upstream is at version 10.7.2. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#872894: Bug#872894: node-policyfile: autopkgtests fail with nodejs 6
Quoting Graham Inggs (2017-08-22 11:18:25)
> Since the upload of nodejs 6, node-policyfile's autopkgtests have been
> failing [1] with the following error:
>
> autopkgtest [09:36:46]: summary
> require FAIL stderr: (node:773) DeprecationWarning:
> process.EventEmitter is deprecated. Use require('events') instead.
This bug seems fixed upstream in their 0.0.6 release:
https://github.com/3rd-Eden/FlashPolicyFileServer/issues/9
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: 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#872903: node-policyfile: wrong homepage
Package: node-policyfile Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 node-policyfile lists as homepage https://github.com/ - that is clearly wrong. May correct URL is https://github.com/3rd-Eden/FlashPolicyFileServer - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlmb/EEACgkQLHwxRsGg ASGUfhAAnOs8rkMWqJFuTHNOH9rN0nhDj9LHYgcf8B0v12KejgCSaCJXfcdeb2sA xcjBsqdXT40KQzNGoS9+nE3p+hoR3WQnC6ijRUdFVzXZDHAlfVGEL7HQaBtUMn6+ f4e8CYHp6Aq0rQMQkCXIBe3TfLn/Hzyg703BWYCGV10viHbXIVbDJzMzf8rlrzpz hCa3J4D6dPXu2/c0DLmKbFj3d4odjJxhYfGZGXHtiLceJLQ6KtU3K40Du29a+GW9 gQdF45R/H3ywFyLxv8BlEBh6OMgVbeQtZazZwkTaDH37Muh/GI/w8VMJodASk5tq qiu+pe2H6hqmau//zV6m5cwtSh7edRVzdZEcKBZKd9JKsGmx/4OtEpnaDRPscC4v CMtKDpM4vT+SG2ZfqB9T4Go2mPbI7XGycw4ZjEqI7Xf66oaMy8eulXcJHiJ/KHY+ oEAsrJa3HAH89/KCSIq3jtDYGHfPzlJdcFpPN36FQ25cNjb4Kts1L2vGIPNeOemu 6TzTH4KrMzetpw6lN8BP7ozjeh5zyAVbXWm0aimUQIX1nS2hSTOg9EPw9Nny91EH o8Bugb6iZ3K4M3pT2vb2Q+VGiaPHwOgWaRzcRGxDjQzsQHKNhI4/kWxh3OoweaTq O+imbl7UOI1VyLWsi4nyMGhhkTYkwUGmKtfE/Nz5vu3E2DjtOq8= =kO8e -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#872901: node-node-redis: unused and unmaintained upstream
Package: node-node-redis Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 node-node-redis has seen no upstream activity fo 4 years. According to https://github.com/tim-smart/node-redis/issues/4 another similar project node-redis is more active. This package has no reverse dependencies. Perhaps sensible to simply drop this package? - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlmb+wIACgkQLHwxRsGg ASFvOA//VAXwaiH/X7HXl0cYBfQMoiJK8fja3jsUJ6H21XzpqGv0YGGHIZEneqjB u2Y4RFTeZwmQ3CuQq2+QoEx4d/Rl76YsI+ikSxW40oZC2Tj+qRbiSB5+txqMH5if YWIW/zNCpTvlN3ISH7cru1JvdNq4tXEQoChqb9fPde6DwknSy/ZArHG0PkoUyUFF RdkpF39hgk4ZDwQXG8SRnkmH+RcJGFWjp6Rmwg7Qw0aHZM7sL30uuoD5Gqgo3EMn O1W4bHrKwuT4yiXai5dCXDuXHMFVXYn/rAybQ/MHP1PvPDJOgbu9ck/C4flZWkO+ QTQ8OQKjiCfq0TtiWwN8saMz/sj8TUnZsApJiqnTA73V1MlQXgv/iRr5AogehCAF lfAjyX07CDYntTn4VZdk2XoY7RbODsB7A0utMBpFrwGWIiThMk7+hUw00pdixRi7 wDmpl0AcMTcqkl6qZjtvCbtGwQufjMLosw8SwolZ5qX3JFBlRxNeHsxZLF9UBbHi TgqoqmTujnhU51BoaDWAGUYAWq4wScod76GFoCnwIwEWb6sl2vhTejMU3oWCDvjC cXqIKnd/JYl1JrMrdVHxNVGvRTVfyTjiAMON6OaFM8QHOWdaeA3tUCCgwsFKfZsJ 1j19nIX4TV/jIjQQ3R27kC5NzIrj/7UxWYqD6AWtYXmypXW+arQ= =2+ra -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] parallel installation
Quoting Ross Gammon (2017-08-18 19:54:50) > On 08/18/2017 06:09 PM, Jonas Smedegaard wrote: > > Quoting Ross Gammon (2017-08-18 16:47:10) > >> On 08/18/2017 04:50 AM, Hubert Chathi wrote: > >>> On Wed, 16 Aug 2017 09:27:49 +0200, Ross Gammon > >>> <javascr...@the-gammons.net> said: > >>> > >>>> For node-* stuff however, upstream handle this by bundling a > >>>> particular version of a module in node_modules. If it is "really > >>>> difficult" to patch a node module/app to use the Debian version > >>>> of a library (because the versions have changed too much), then > >>>> shouldn't we bundle the node_module and install it as upstream do > >>>> it (avoiding all the relative path issues)? It could be followed > >>>> up with a bug (severity wishlist/normal?) to remove the bundled > >>>> module once Debian and upstream are more aligned. > >>> Embedding copies of libraries should be highly discouraged. For > >>> one thing, it is agaist policy[1], but it also it makes security > >>> support much harder, you may end up with multiple buggy versions > >>> of a library on your system, and have a bunch of duplication. It > >>> may make initial packaging easier, but it usually makes > >>> maintenance harder. > >>> > >>> [1] > >>> https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles > >> The title of this section of policy is actually "Convenience copies > >> of code". It is definitely not a convenience to heavily patch a > >> package just to use a "way out of date" dependency, when it is out > >> of date because many other packages still require that old > >> dependency. > > It is an _upstream_ antipattern, and is indeed a convenience for > > them. > > > > > >> I agree that it should be discouraged though, except in rare cases. > >> It is just a normal transition (like in C/C++) after all. > > Not sure if you agree with policy or try argue against it. > > > > > >> Whether it is bundled, or several versions of the same upstream are > >> packaged separately, you still have the issue of code duplication, > > No, several versions of a library is not convenience code copies. > > > > > >> and the possibility that a security update might be required in > >> several places at the same time. > > It is certainly _possible_ for a security bug to exist in multiple > > upstream releases of a code project, but when tracked on its own it > > is easier to hunt down such bugs, and when each version exist only > > at one place in Debian then each version needs only be fixed once > > for a security bug to get squashed. > > > > > >> Of course, bundled copies are harder to find. But we can manage > >> that in the team (via a transition bug, and/or a list on the wiki?) > >> while we push all the unwilling upstreams to align on the same > >> version (and nodejs upstreams are REALLY unwilling on this - > >> believe me). I still think it is better to manage multiple copies > >> in the same way that upstream do. It will give a lot less friction > >> upstream. > > It is not adequate to agree in this team about bundling code: As an > > example, the security team tracks security bugs and will also need > > to agree on such deviation from Debian Policy. > > > > Personally I do *not* find bundling easier manageable than > > separately tracking each true upstream project. You are welcome to > > explore argue for that, but you will need to convince not only this > > team but Debian in general. > > > > > > - Jonas > > > From the policy: "Debian packages should not make use of these > convenience copies unless the included package is explicitly intended > to be used in this way.". > > "Should" does not equal "must", it means something closer to "maybe". > This gave me some trouble in my Danish language classes :-) And also from policy: "Non-conformance with guidelines denoted by should (or recommended) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution.". So yes, it does not equal "must" (and I believe I didn't claim it did), but it does not equal "maybe" either (arguably you didn't claim it did - but your choice of words had a real risk of being perceived that way). > I believe upstream &quo
Re: [Pkg-javascript-devel] parallel installation
Quoting Ross Gammon (2017-08-18 16:47:10) > On 08/18/2017 04:50 AM, Hubert Chathi wrote: > > [meant to reply to the list, so sending again] > > > > On Wed, 16 Aug 2017 09:27:49 +0200, Ross Gammon > > <javascr...@the-gammons.net> said: > > > >> For node-* stuff however, upstream handle this by bundling a > >> particular version of a module in node_modules. If it is "really > >> difficult" to patch a node module/app to use the Debian version of a > >> library (because the versions have changed too much), then shouldn't > >> we bundle the node_module and install it as upstream do it (avoiding > >> all the relative path issues)? It could be followed up with a bug > >> (severity wishlist/normal?) to remove the bundled module once Debian > >> and upstream are more aligned. > > Embedding copies of libraries should be highly discouraged. For one > > thing, it is agaist policy[1], but it also it makes security support > > much harder, you may end up with multiple buggy versions of a library on > > your system, and have a bunch of duplication. It may make initial > > packaging easier, but it usually makes maintenance harder. > > > > [1] https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles > > The title of this section of policy is actually "Convenience copies of > code". It is definitely not a convenience to heavily patch a package > just to use a "way out of date" dependency, when it is out of date > because many other packages still require that old dependency. It is an _upstream_ antipattern, and is indeed a convenience for them. > I agree that it should be discouraged though, except in rare cases. It > is just a normal transition (like in C/C++) after all. Not sure if you agree with policy or try argue against it. > Whether it is bundled, or several versions of the same upstream are > packaged separately, you still have the issue of code duplication, No, several versions of a library is not convenience code copies. > and the possibility that a security update might be required in > several places at the same time. It is certainly _possible_ for a security bug to exist in multiple upstream releases of a code project, but when tracked on its own it is easier to hunt down such bugs, and when each version exist only at one place in Debian then each version needs only be fixed once for a security bug to get squashed. > Of course, bundled copies are harder to find. But we can manage that > in the team (via a transition bug, and/or a list on the wiki?) while > we push all the unwilling upstreams to align on the same version (and > nodejs upstreams are REALLY unwilling on this - believe me). I still > think it is better to manage multiple copies in the same way that > upstream do. It will give a lot less friction upstream. It is not adequate to agree in this team about bundling code: As an example, the security team tracks security bugs and will also need to agree on such deviation from Debian Policy. Personally I do *not* find bundling easier manageable than separately tracking each true upstream project. You are welcome to explore argue for that, but you will need to convince not only this team but Debian in general. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] parallel installation
Quoting Paul Gevers (2017-08-15 21:20:49) > On 14-08-17 20:38, Hubert Chathi wrote: > > At the BoF at DebConf, we were talking about parallel installation > > of different versions of JS libraries. In order to do parallel > > installation, we'd need differently named packages for different > > versions, and it seems like the obvious way to do that is to have > > packages called something like libjs-fooVER and node-fooVER, where > > VER some sort of the API version, similar to the way that C/C++ > > library packages are named after the library SONAME. If upstream > > follows semver properly, then VER would be the major version number. > > This sounds like a reasonable approach, I agree above sounds sensible. > but what I am missing is a recommendation on what to do to keep the > number of packages limited. I think it is not such a great idea to > replace one problem (not the right version) with another one (too many > packages to support). > > One approach could be for example the following. Try to have only two > versions per release, but really limit the number to a maximum of 3. I see no need for a team policy specifically for parallel versions of same project: Some libraries may have 4 well-maintained concurrent releases, whereas others may have *zero* well-maintained releases. We need to ensure that our packages are properly *maintained*. Period. If an upstream project releases foo1 and foo2 and foo3, and other packages depend on all three, then that is fine if all three are properly maintained - both upstream and in Debian. If an upstream project releases foo1 and only that one which other packages depend on, then that is bad if that that one is poorly maintained - either upstream and in Debian. I believe we cannot make a simple rule like "only 2 parallel releases", but I believe we can easier identify potential problems if we have a policy on "at least two team members must care specifically", as is practiced in the Multimedia team. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#872473: Bug#872473: node-xmpp outdated
Quoting Thorsten Alteholz (2017-08-17 19:58:24) > The Homepage:[1] leads to an almost empty page. > The github repository URL[2] in debian/copyright is redirected to a > different project[3], where the README says: >"xmpp.js is a rewrite of node-xmpp" > Further, at least for me it was not possible to connect with the example > send_message.js to a jabberd2 with legacy ssl. > > Maybe it is time to remove this package and switch to xmpp.js? Yes. Please kill it. Thanks for the investigation. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] coffeescript & node-coffeeify
Hi Ross! Quoting Ross Gammon (2017-07-20 20:19:00) > I looked at moving [node-coffeeify] to unstable yesterday, but > realised that it needs the version of coffeescript that is also > sitting in experimental. > > Is there anything holding up the latest coffeescript from moving to > unstable (other than time)? It is not urgent for anything as far as I > know - just a gentle prompt. I have now prepared packaging of most recent upstream 1.x.x release of Coffeescript - which should not break existing reverse dependencies in Debian, assuming the semantic versioning is properly handled. ...but it depends on Nodejs 6, which is inly in experimental so far :-/ > PS: I can see there are a few reverse dependencies now. Let me know if > I can help check any of those. I did not look yet into packaging the 2.x.x release of Coffeescript. If that requires new dependencies, then yes, it would be great if you (or others reading this) could help package those. I will then upload Coffeescript 2.x.x into experimental for testing compatibility with reverse dependencies in Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#862918: libjs-bignumber: New version available upstream: 4.0.2
Quoting Ben Finney (2017-07-11 14:01:14) > Control: retitle -1 libjs-bignumber: New version available upstream: 4.0.2 > > On 20-May-2017, Jonas Smedegaard wrote: >> Quoting Pirate Praveen (2017-05-20 07:57:32) >>> Most likely this was packaged as a dependency of another package and >>> that package no longer needs it. >> >> Debian packages should be _maintained_, not only packaged. All >> packages, not only topmost ones in dependency trees! > > I agree with that. But I also agree with Praveen's point you omitted: > > > On 20-May-2017, Pirate Praveen wrote: >> node-bignumber is a dependency on node-mysql. Seems newer version of >> node-mysql just work fine with the current node-bignumber. If we have >> to update, we should make sure it does not break node-mysql. s/but/and/ I agree with that other point too. > Both of these – incorporate new upstream versions, don't break > dependent packages – are important facets of maintaining a Debian > package. > > Sometimes these two important directions conflict. What should be done > if the new upstream version breaks dependent packages without offering > an upgrade path? If _only_ the older version version is relevant then (obviously) we should only provide that version as a Debian package. If both older version and newer version is relevant (either directly for some of our users or as reverse depencency for other packages) then we should maintain both. "Maintain" includes dealing with upstream no longer maintaining the code we carry. "Maintain" includes checking if newer upstream releases cause trouble for reverse dependencies: Not upgrading to newer upstream releases because the code possibly maybe perhaps breaks a reverse dependency but not inspecting closer is lack of maintenance. This bugreport is an explicit request to package a newer version, so an indication that there is some (at least one) of our users would value that newer version being available as a Debian package. This in itself do not mean that we must upgrade, but is an indication of relevancy. I would find it perfectly fine to close this bugreport with e.g. a "sorry, but the newer version breaks the only reverse dpendency in Debian for that code project - please file a separate ITP or RFP bugreport to track eventual concurrent packaging of a newer version as a separate Debian package." After investigating and if then getting to that conclusion. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#867298: Bug#867298: npm2deb: please bump debhelper and Standards-Version
Quoting Johannes Schauer (2017-07-05 21:16:38) > Quoting Jonas Smedegaard (2017-07-05 21:04:44) > > Quoting Johannes Schauer (2017-07-05 18:26:40) > > > Maybe I misunderstand but this bug report is not about "changing" > > > or "bumping" anything. > > > > > > Since npm2deb creates the *initial* Debian packaging, the > > > situation where we start with a lower Standards-Version and then > > > have to verify changes before we can "bump" the Standards-Version > > > doesn't arise. > > > > Right, this is not about single package bumping as I confusingly > > wrote, but instead about automated processing where it is even > > _more_ important to verify that the claimed Standards-Version is > > accurately applied, and even _more_ important to consider if newest > > shiny denhelper really is needed! > > Lets not conflate the two issues. I assume that it's uncontroversial > that the newest Standards-Version should be emitted because it doesn't > make sense to pick any old policy version and then require the > maintainer to bump the version bit by bit, right? If npm2deb maintainers has only verified that the tool comply with some older version of Debian Policy, then indeed the burden is on each maintainer using the tool to verify that the generated package comply with a different (newer) release of Debian Policy. I am not against this being addressed. My point is just that addressing it involves actually checking that newer release of Debian Policy and ensuring that the tool complies with it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#867298: Bug#867298: npm2deb: please bump debhelper and Standards-Version
Quoting Johannes Schauer (2017-07-05 18:26:40) > Quoting Jonas Smedegaard (2017-07-05 17:46:19) > > Quoting Johannes Schauer (2017-07-05 17:15:46) > > > Standards-Version 3.9.8 is outdated. npm2deb should generate version > > > 4.0.0 instead. > > Just to avoid misunderstanding: Standards-Version should *only* be > > changed as a *result* of verifying that said the package comply with > > said version of Debian Policy. > > > > > > > The current recommended compat level for debhelper is 10. npm2deb > > > should use that one instead of compat level 9. > > Please bump debhelper compatibility level only when really needed, > > to help ease backportability (to _any_ environment, not only > > backport.debian.org). > > Maybe I misunderstand but this bug report is not about "changing" or > "bumping" anything. > > Since npm2deb creates the *initial* Debian packaging, the situation > where we start with a lower Standards-Version and then have to verify > changes before we can "bump" the Standards-Version doesn't arise. Right, this is not about single package bumping as I confusingly wrote, but instead about automated processing where it is even _more_ important to verify that the claimed Standards-Version is accurately applied, and even _more_ important to consider if newest shiny denhelper really is needed! > Furthermore, I'd argue that any tool which auto-generates Debian > packaging data should use the current and/or recommended packaging > practices. According to the debhelper man page, compatibility level 10 > is the "recommended mode of operation". I am aware that the developers of debhelper promote newest major version - that does not change my plea about being more conservative: Use the debhelper compatibility level supported in oldstable (currently 9), unless some feature requiring a newer compatibility level is needed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#867298: Bug#867298: npm2deb: please bump debhelper and Standards-Version
Quoting Johannes Schauer (2017-07-05 17:15:46) > Standards-Version 3.9.8 is outdated. npm2deb should generate version > 4.0.0 instead. Just to avoid misunderstanding: Standards-Version should *only* be changed as a *result* of verifying that said the package comply with said version of Debian Policy. > The current recommended compat level for debhelper is 10. npm2deb > should use that one instead of compat level 9. Please bump debhelper compatibility level only when really needed, to help ease backportability (to _any_ environment, not only backport.debian.org). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#857986: Bug#857986: npm: This pakcage is 3 years old? (consider removal)
Quoting Pirate Praveen (2017-05-22 16:10:32) > On തിങ്കള് 22 മെയ് 2017 06:41 വൈകു, Jonas Smedegaard wrote: >> ...for the _initial_ packaging work. >> >> We are package *maintainers*. > > If you have not realized, we are discussing about maintaining an > existing package. I think you have also not realized the meaning of > team maintained packages. The person who did the initial package need > not be the maintainer of the packager for ever. When there is enough > interest in the package, it will remain maintained else it gets > removed. Exactly: Packages poorly _maintained_ should be removed. E.g. npm! My point in previous post was that focusing only on the workload for _initial_ packaging masks the actual real workload, which is being discussed here! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#857986: Bug#857986: npm: This pakcage is 3 years old? (consider removal)
Quoting Pirate Praveen (2017-05-22 13:27:35) > On വെള്ളി 19 മെയ് 2017 03:45 വൈകു, Jérémy Lal wrote: >> There are complications to distributing npm: it depends on a LOT of >> modules, which means it requires a lot of debian-maintainer time to >> package, and update. > > https://wiki.debian.org/Javascript/Nodejs/Tasks/npm ie, roughly about > 78 new modules to package. If one person were to work full time, I > think about 10-15 days time. ...for the _initial_ packaging work. We are package *maintainers*. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#863056: node-gulp-coffee: lacks dependency on coffeescript
Package: node-gulp-coffee Version: 2.3.4-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - From the package descript it seems node-gulp-coffee is a wrapper for coffeescript, yet it does not depend on coffeescript. Is there any use cases without involving coffeescript? - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlkgwgwACgkQLHwxRsGg ASE2/g//RNarOABKUTvwcmbI1BcDbE2glmLIabqYUGB4BpeHN03C5qHoNLaeYuNt UysKo1qE7RyAmAICxaWxxe4SWldUm8zQcA3J/GLL82rKQxsviwT5khLyY4PteTYn M2yhDrCKz7eAGD2+kMXxW9QoJgS99YiBMPNPh81ivHCri5IfEQR6FDAzos2xaSnT MdEuD9+JIAoHEJBC55NH/jnfbVPHNSCELLLSu2v7UTot5sCyPld+ma6vTTDUsfhD mu+8A64RCtftRV4QnRC9/rB1Q8uveyq6fjAb0+xiUpm8+2NCyoxn1XICZq65NuJQ i+zKT85NaRHmikmlZ0Zq/DiS0zY5wOnidRZb8w6ErrRnlv/9bhnsF6HTzP/F3x+S 3RlNs1xQoPesUZGmz50r1gNQxNveAhctMavqYPOxF8fyGaOYPPlSqN9Daqck5dZA b+kDl4dqK9De6iJS7LJDdynHZjE19MclKCzr5bOEl4NGiky+jOeItffCpRr8lZT5 BVbfFYWtZ9D8RiiTBRsyl9rzYVisvD6TmQE7LilT5CdeN+hIpz5nhHzfM5V8QGvj Oig4b/jbb6/xcOXBtoxYzTkz8xd4Y1LnPjJ5cK1aLwd2K3Jm151vuxoKrRBBjdKk zQZ91h9LyFQhIu4ad65m8OxXvjmLpSEyYxxCq/xF1v1dlvXf23o= =qeHP -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#862918: Bug#862918: Bug#862918: New version available upstream: 4.0.2
Quoting Pirate Praveen (2017-05-20 07:57:32) > On വ്യാഴം 18 മെയ് 2017 11:34 വൈകു, Jeffrey Cliff wrote: > > Package: libjs-bignumber > > Severity: normal > > Version: 1.3.0+dfsg-1 > > > > Looks like this package hasn't been updated to upstream in quite awihle > > - 3 major versions have been released since ~2013 where 1.3.1 seems to > > date from. > > > > Most likely this was packaged as a dependency of another package and > that package no longer needs it. Debian packages should be _maintained_, not only packaged. All packages, not only topmost ones in dependency trees! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] My status in Debian
Hi Ross, Quoting Ross Gammon (2017-04-22 12:38:31) > I know I am not a guru like most of you in the team, and that and my > busy life means I am a little slow sometimes. I also spread myself > around Debian a bit (Multimedia, GIS & Python teams), and I also work > on Ubuntu Studio. > > Anyway, one of my other sponsors has stated a few times when I have > asked for DM rights for something, that maybe it was time to step up > to DD status. > > I am in no hurry (probably would aim to take the plunge towards the > middle of the year). And I wouldn't do it until there was wider > support for that. So any words of encouragement, or any suggestions of > things that you would like to see from me before you would endorse me > are welcome (here or in private). Do it! Was that adequate encouragement? :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Fwd: Revive NodeJS on armel (forwardport jessie src-package)
Quoting Sven Giermann (2017-03-17 22:32:54)
> 2017-03-17 11:22 GMT+01:00 Jonas Smedegaard <jo...@jones.dk>:
>
>> How about fresh install of _Debian_ wheezy (not Emdebian wheezy)?
>>
>
> That's my main problem:
> I am unable to install wheezy or jessie, passing all tests supplied
> with the source package!
My point is: How about _not_ rebuild (backport or forwardport) Nodejs
package at all, but instead rebase system ("side-grade" - or rather
reinstall) from unmaintained Emdebian to LTS-team-maintained Debian.
> I was trying to stress that on my initial post, only writing the
> initial intent for better understanding.
I understand that your initial post was about forward-porting nodejs -
i.e. rebuilding an older nodejs package on a newer Debian.
I did not address your question, but side-stepped it by questioning the
_premise_ for your question - that it is "time to change to newer
distribution" - and consequently explore a _different_ and likely far
less complex path not involving package recompilation.
Perfectly fine if what you want to do is recompile Nodejs. You need not
defend your premise, I only questioned it in case your limited scope was
unintentional.
[details on rebuilding Nodejs snipped - left for others to discuss]
>> Depending on your needs (is brand recognition a need for you?), I
>> recommend you to consider the OSHW boards from Olimex.
>>
>
> I'm fine with everything that does not cost to much and is easy to
> purchase.
> Is anyone able to pass all nodejs build tests on that platform?
Yes: LIME2 is an armhf device, and all tests enabled in the Debian
packaging of Nodejs passes for armhf, if that is what you mean. Status
for archs succeeding build (including testsuite) is here:
https://buildd.debian.org/status/package.php?p=nodejs
I believe the full _upstream_ testsuite does not succeed on _any_ Debian
arch. But Jéremy knows more intimately about that.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: 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] Revive NodeJS on armel (forwardport jessie src-package)
Quoting Sven Giermann (2017-03-17 10:21:00) > Jonas, > > thanks for your quick reply and the interest in my "problem". :-) > > 2017-03-17 9:47 GMT+01:00 Jonas Smedegaard <jo...@jones.dk>: > > > Could you please elaborate on the "time to change to newer > > distribution" part? > > > > If reason for the change is improved security support, then it seems > > you are somewhat defeating that by running (exposed to the network, > > I guess) code which no longer receives security updates. > > > > Yes, I'm well aware of that. But until now, it's only exposed to my > LAN. The reason for looking at newer distributions is the need for a > clean reinstallation after trying different packages on my production > system, I don't need any more. I'd like to renew my installation from > scratch, which (of course) could still be done with emDebian wheezy, > but I'm not sure how long the mirrors will still be active. Yes, I > might archive a pure base installation - but I'd feel more comfortable > with a supported distribution, keeping only NodeJS in an unsupported > state. How about fresh install of _Debian_ wheezy (not Emdebian wheezy)? That will receive limited support - not by Debian itself but from the "LTS team" - until mid 2018: https://www.debian.org/releases/wheezy/ - giving you more than a year to explore the range of armhf boards to replace your setup. Even if nodejs is not covered by the limited support by LTS team, you could include that package from the unsupported archive of wheezy. > Apart from that, I fear that even wheezy's backport of v0.10.29 does > not pass all tests, so I started to focus on the current stable > distribution (jessie). But as this fails to build 'test-simple', I > wanted to get some support from others who know, what they are > doing... > > Further, there are many more components like OWFS and EBUSD running on > that system - which I'd like to keep more current. Would it be an option for you to backport those parts (as opposed to forward-port Nodejs which I fear is quite more complex)? > Last but not least, the most obvious solution would be to retire my > armel device and get a standard Raspberry Pi or similiar - but I get > comparable test failures on stable (jessie) running armhf, too. > So I thought, it's time to shed some light on this... Raspberry Pi is arguably _popular_ but certainly not a standard. Depending on your needs (is brand recognition a need for you?), I recommend you to consider the OSHW boards from Olimex. > > NB! Please, if you haven't yet, subscribe to the list or mention > > explicitly in each of your posts if not and you want to be cc'ed on > > replies: Normal for Debian lists (which I didn't follow in this > > post) is to only reply to list. > > > > You're right - my fault. I first posted to the group without > subscribing, cancelled the request and posted again after subscribing! You misunderstand: It is *not* wrong to post without subscribing. Your previous post was *not* rejected, only postponed for manual screening to avoid spam (and, it seems, withdrawn by yourself before anyone got around to do that screening). My point above was independent from yourt held-back post: Just a warning that you might miss _responses_ from others due to our posting style. Regards, - Jonas P.S. I am listmaster for this list but only noticed _after_ my initial response that you had attempted to post and had subscribed to the list). -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Revive NodeJS on armel (forwardport jessie src-package)
Hi Sven, Quoting Sven Giermann (2017-03-17 09:25:14) > I have a small armel board (armv5tel), currently running emDebian Grip > 7.1 (wheezy) for Home Automation. Because it's time to change to a > newer distribution, I was facing 'stretch' - but... I need NodeJS! > > As everybody may know, the required v8 dropped support for armel some > years ago, you may read bug #818552 [1] for some background. Could you please elaborate on the "time to change to newer distribution" part? If reason for the change is improved security support, then it seems you are somewhat defeating that by running (exposed to the network, I guess) code which no longer receives security updates. If reason for the change is new features, then it might be far easier to identify which features you really want and look into possibilities of backporing only those to your older-but-working system. Feel free to ignore my comments that are sure sidestepping your question - I will leave it to others better qualified to try adddress those. NB! Please, if you haven't yet, subscribe to the list or mention explicitly in each of your posts if not and you want to be cc'ed on replies: Normal for Debian lists (which I didn't follow in this post) is to only reply to list. I wish you continued joy tinkering with tiny devices, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#851318: Bug#851318: uglifyjs: FTBFS on slow machines (failing tests)
Quoting Santiago Vila (2017-01-13 23:34:23) > I tried to build this package in stretch with "dpkg-buildpackage -A" > but it failed: [...] > [92m [0m[32m 66 passing[0m[90m (34s)[0m > [31m 1 failing[0m > > [0m 1) bin/uglifyjs should produce a functional build when using --self: > [0m[31m Error: timeout of 5000ms exceeded[0m[90m > at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19) > at Timer.listOnTimeout (timers.js:92:15) > [0m > > > debian/rules:52: recipe for target 'debian/stamp-build' failed > make: *** [debian/stamp-build] Error 1 > dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 > > > This is just how the build ends, not necessarily the relevant part. > > I've put several build logs here: > > https://people.debian.org/~sanvila/build-logs/uglifyjs/ > > If this is really a bug in one of the build-depends, please use > reassign and affects, so that this is still visible in the page for > this package. > > I can reproduce this in a lot of different computers, all being > "slow", but there is not a policy anywhere saying that autobuilders > must be fast, so I'm not treating this one as a FTBFS-randomly bug. I agree these failures are not random: Tests should not assume fast environment. Seems the proper fix is to patch test/mocha/cli.js to not have a timeout (or as workaround an insanely large timeout). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] ITP: node-aproba -- A rediculously light-weight argument validator
Hi Akash, Quoting Akash Sarda (2017-01-29 15:50:21) > Description : A rediculously light-weight argument validator > > . > Node.js is an event-based server-side JavaScript engine. Seems you meant to write "ridiculously" (with an "i"). Without further elaboration, I understand that description to mean that the only feature worth mentioning for this package is a validator so minimal that it is stupid. Please let us not ship purely stupid packages with Debian! Therefore, please elaborate in long description what this module does, and consider avoiding the word "rediculously" altogether from short description. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#850660: Bug#850660: nodejs-dev: npm conflicts transitively with libssl-dev since nodejs-dev 4.7.2~dfsg-1
Quoting Sebastiaan Couwenberg (2017-01-29 14:56:41) > On 01/29/2017 02:31 PM, Jonas Smedegaard wrote: >> Quoting ano...@users.sourceforge.net (2017-01-29 14:12:59) >>> I've been unable to upgrade nodejs and nodejs-dev thanks to this >>> issue: I need npm for some things, but also php7.0-dev (which >>> depends on libssl-dev) for something else. >> >> Please share what it is that - transitively or not but _concurrently_ >> - needs both libssl-dev. > > A system with (build) dependencies for multiple packages installed. Thanks for clarifying that the issue is *not* impossibility of building a package, but annoyance of wanting a single unified development environment (which is nice but not promised by Debian nor this package). I will leave it to others to deal further with this bugreport. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#850660: nodejs-dev: npm conflicts transitively with libssl-dev since nodejs-dev 4.7.2~dfsg-1
Quoting ano...@users.sourceforge.net (2017-01-29 14:12:59) > I've been unable to upgrade nodejs and nodejs-dev thanks to this issue: > I need npm for some things, but also php7.0-dev (which depends on > libssl-dev) for something else. Please share what it is that - transitively or not but _concurrently_ - needs both libssl-dev. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] pre-spring cleaning, please advise
Quoting Ben Finney (2017-01-28 03:07:01) > Jérémy Lal <kapo...@melix.org> writes: > > > - or having a reverse (build-)dependency, or what's the point ? > > I am very much in favour of this: node libraries should be in Debian > to provide a library that is needed for some actual program of benefit > to Debian users. Agreed. > But my eagerness to remove useless packages makes me worry that some > useful ones could be swept up also. > > One use case I don't see addressed: How will we ensure that a library > is not needed for some other package not yet uploaded to Debian? Removal from testing involves filing a bugreport to ftpmaster. I guess it makes sense if at all uncertain to first file bugreport against the package and cc this list - of not-to-high severity - suggesting the intent (removal from stretch or removal from Debian completely) some time (2 weeks?) before reasigning to ftpmaster. Discussing only here is not adequate: Being part of this team and subscribing to this mailinglist is voluntary. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#852338: Bug#852338: node-expat FTBFS on mipsel/mips64el: Errored » callback not fired
Hi Adrian, Quoting Adrian Bunk (2017-01-23 18:12:44) > ✗ Errored » callback not fired > in stop and resume > in node-expat > in test/index.js > ✗ Errored » callback not fired > in Stream interface read file > in node-expat > in test/index.js > (node) util.puts is deprecated. Use console.log instead. > ✗ Errored » 28 honored ∙ 1 errored ∙ 4 dropped The difference from succeeding builds to above failing one did not involve any changes to build routines, which I take as indication that the cause is higly likely the testsuite itself being unreliable (too sensible to slow hardware, perhaps). I have therefore temporarily adapted the build routines to not fail if testsuite fails, and lowered this bugreport to important. Thanks for reporting! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#852188: jssip: please package newer upstream source
Source: jssip Severity: wishlist Currently packaged version 0.6.34 is 18 months old: Upstram is at version 3.0.1 by now. Please package newer upstream release. - Jonas -- 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#850719: rollup: please consider mention why package is in contrib
Package: rollup Version: 0.38.0-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I notice that rollup is not targeted main but contrib, yet the package seemingly does not depend on or recommend any non-free packages. If this package really need to be in contrib, then please consider mention in long description why, so that potential users are better aided in deciding whether sensible to use it or not. Or, if there is no need for avoiding main, then please correct that hint in debian/control - it looks like a nice tool that I would like to use (also for use cases restricted to Debian main). - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYc7X0AAoJECx8MUbBoAEhjUgP/1faJGFLyjy/dRAQUmGdQ0Sp 7PIeqmZCmQcSSM1ZePXpjc+6/fiTnnFPyjrWONYgpiZhKmOzzp5PPcIBwKMAd/FA zhquFRqweV3jvJn4SmnuSPaspqz6qBxjWAWQ+MnTD/ITw7LHR+EZLI97vmgQzkoS z3bqckizpG/4vb3SuMPsFs9oe4s4plOA5wtS/9cKHKaYME7EtqGqyTKOUOmF0vCL t9NRH6VDnUNOQr7dw9ICURLa2mx/uyo1rS+6vsHzVrGjF21N89UDZQNy9msgNLcz vA/Vx1uj9EgzKkKfqbb+lPYo+5dbHiKj9XvkgJLebV5w9fd7jS8CC2K7EmTV4zcv hvUNRgg0BhJ8WgrEt7+Pkvhy6ToTonEL8BNQA1U7jOg0gK8mybPaUluO0/DZAM1Q JWH2e8274tZRnv+37hezmg0VCfOvUfF8xPW5TeEisztLfVjgfeF+1YfRCVyBfRrz Jh/FPKtSYlVPhfaIIPDTSLV+nuGKxAbLjlvZyInbv0iYfHggdDsdpvVhvXkUQa/L YPhmwuub+ftfOTuqOgqts8b5bBeESARrjzkvAk0sJUH5aowYIAtlo0xIPP+Qu3DK mHjs9yBdpBWb6RvgzNTzhFvRvm5XvEbWG4Y8aQB2jSk74tuUkxwBagUoMvu0frdC 1bORvtlp1tuzps77Hyqd =mZYb -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#850419: Bug#850419: Bug#850419: Local installation seems needed
Quoting Pirate Praveen (2017-01-07 01:02:53) > On വെള്ളി 06 ജനുവരി 2017 11:10 വൈകു, Bastien ROUCARIES wrote: > > On Fri, Jan 6, 2017 at 6:39 PM, Bastien ROUCARIES > > <roucaries.bast...@gmail.com> wrote: > >> On Fri, Jan 6, 2017 at 5:41 PM, Jonas Smedegaard <jo...@jones.dk> wrote: > >>> How about patching the error message, as an intermediary step? > >> > >> How about adding an option --global to make grunt global > > > > And even better add a environment variable GRUNT_FLAGS to pass flag to grunt > > All of these are good options, we just need someone to write the code. > I'm not well versed in javascript to write it myself. Are you able to locate the error message string, and replace it with another string? That, I believe, is all my suggestion requires. No, sorry, I will not dive in and do it myself - I prioritize higher to get more of the ~400 packages under my wings in shape for Stretch. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#850419: Bug#850419: Local installation seems needed
Quoting Pirate Praveen (2017-01-06 17:12:29) > Control: severity -1 important > > On വെള്ളി 06 ജനുവരി 2017 04:07 വൈകു, Bastien ROUCARIES wrote: > > Using grunt for node-sprintf-js I get > > > > Fatal error: Unable to find local grunt. > > > > If you're seeing this message, grunt hasn't been installed locally to > > your project. For more information about installing and configuring grunt, > > please see the Getting Started guide: > > > > http://gruntjs.com/getting-started > > > > Thus it unusable > > > > This is the default behavior of grunt and the upstream is unwilling to > change this behaviour. To use it for building packages in debian, you > have to patch Gruntfile.js. > > Patches welcome to make grunt look for global tasks by default. You can > see packages like node-fuzzaldrin-plus for the patch. > > https://anonscm.debian.org/cgit/pkg-javascript/node-fuzzaldrin-plus.git/tree/debian/patches/use-global-tasks.patch How about patching the error message, as an intermediary step? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] lots of requests to join pkg-javascript
Quoting Ximin Luo (2017-01-06 11:27:00) > Pirate Praveen: >> On വ്യാഴം 05 ജനുവരി 2017 10:20 വൈകു, Ximin Luo wrote: >>> Let's please talk about the specifics of this situation rather than >>> appealing to vague notions of being welcoming. >> >> This is completely arbitrary restriction. I was thinking we evaluate >> people based on what they have done, rather than when and where they >> have done it. I don't agree with this notion. I agree with Praveen. > Being a maintainer is about more than doing one small thing. True, but that's how it usually begins! This team is not restricted to people _already_ being maintainers. >> [..] I do not see this as sustainable and I will not approve any more >> requests in this team. if we, as a team are unable to follow the >> processes in line with the debian philosophy and spirit, I will >> remove myself as an admin from this team. >> >> I will not import any of these repos to alioth. Someone who relish >> authority and elitism has to do the extra work. I wish you wouldn't give in like that, but understand your reasoning (and appreciate that you didn't take even worse action!). > Get your head out of your own ass, and stop acting like you're a > victim here. Go wash your mouth, and step back from your high horse: You are *not* the boss around here (noone is), and you have no right to dictate newly invented rules nor point fingers at peer team members choosing to disagree with them! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] lots of requests to join pkg-javascript
Quoting Julien Puydt (2017-01-05 18:41:22) > On 05/01/2017 18:24, Jonas Smedegaard wrote: > > Quoting Ximin Luo (2017-01-05 17:50:00) > >> I propose some reasonable checks, to ensure that we get people who are > >> interested. I disagree that this attitude is flawed. > > > > Thanks. Ximin. > > > > What do others think? > > Until now the discussion seems to have been centered on the Debian > JavaScript Team : should it accept them? Isn't it a security problem to > grant them access? Won't they leave the team out in the cold after > pushing their packages? > > But those are actual people, not just names : are all applicants aware > they are expected to maintain those packages? Are they really interested > in doing so? Do they have any long-term use for an account on alioth? > > I'm for granting them access if they have something to contribute and > they want to join, but I'm againsts forcing them to join to contribute. Thanks! I don't think anyone has suggested or implied forcing anyone to do anything (please help point out if I missed some detail on that!). On the matter of treating newcomers as real people: Approved or not, anyone are free to join this mailinglist ans speak up (e.g. to answer my early question question whether intent is releasing package or maintain, which it is still hanging unanswered!). Anyone else having opinions on the matter? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] lots of requests to join pkg-javascript
Quoting Ximin Luo (2017-01-05 17:50:00) > I propose some reasonable checks, to ensure that we get people who are > interested. I disagree that this attitude is flawed. Thanks. Ximin. What do others think? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] lots of requests to join pkg-javascript
Quoting Ximin Luo (2017-01-05 16:26:00) > Jonas Smedegaard: > > Quoting Ximin Luo (2017-01-05 13:51:00) > >> > >> [..] > >> > >> The security aspect is just one factor, not the main factor. > > > > Ok, you now tell me that security is not the main factor. > > > > I clearly read your previous email as if security was the main factor > > for rejecting these requests. For clarity of discussion I shall > > *ignore* the security factor. > > > > > >> But to give more detail, (a) just because we have "little" security, > >> doesn't mean we have to make it quantitatively worse, which we will do > >> if we add anyone that asks - it adds surface area. And (b) the > >> standards of time and continual maintenance that I described > >> elsewhere, also indicates that a person is careful about their general > >> computing practices, which also helps to not-reduce security - > >> compared to giving access to a random person. > > > > Do I understand you correctly that in your opinion the main factor is > > devotion to continued mainentance? > > > > I agree it's the main factor, but for me this is also linked to security. > Having lots of inactive people with that level of access increases risk with > no benefit in return. It's better to have fewer active people. (Of course > lots of active people are even better.) I welcome suggestions for how we might identify and maybe even kick inactive users. I won't spend time proposing or defending such procedures myself, as I find no need for them (we use this team only to exchange emails and exchange git repos - each of us is responsible to validate each email and each git repo!!!). I (loudly!) oppose treating not-yet-members as inactive: Improving security by minimizing activity is a luxury we cannot afford! > > If so, then we agree on what is "main factor" - but still we > > disagree on how to then deal with it: > > > > It seems Praveen find it reasonable to approve "because they are > > ready to upload their packages", and it seems you find that exact > > situation reason for rejecting. I find it neither reject nor > > approve reason. > > > > I welcome into this team any and all persons who feel they are ready > > to *maintain* official Debian packages. I find it wrong to impose > > restrictions on that, but I want to emphasize _maintain_ - this team > > is *not* the Javascript *contribution* team (there are other methods > > to contribute to Debian in other ways than continuous mainenance). > > > > This is why I suggested having them apply individually later. I disagree that requiring individual membership requests helps. Some are inspired to join when alone and seeking friends, other are inspired to join when with friends also joining, or when meeting and working concentrated for days with a role model - as I guess might be the case for (some or all of) these applicants. > They can see if they're comfortable with doing this semi-regularly. > Everything is more fun at a group event but this is not the same as > robust long-term maintenance of packages. I sure hope you are telling me how *you* find it fun to collaborate. If you are imposing on me and others in this team the reasons we should find it fun to be here, you are effectively *discouraging* anyone with different personality than yourself. Please embrace variety! > Another issue that I noticed is some of the requests were very vague. > (Other requests were suitably specific.) I hope these are fixed the > next time around. Since most of these javascript packages are very > small, it would also be good to mention more numbers of packages in > these requests. Since when did we validate membership based on how they formulated their requests to join? Were you yourself treated with scrutiny when you joined, then I appologize on behalf of the team, and kindly ask you to not repeat that flawed attitude towards newcomers. or alternatively - if this team generally appraise such attitude, I will respect that by leaving the team, as I personally appreciate the *lack* of hierarchy in Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] lots of requests to join pkg-javascript
Quoting Paolo Greppi (2017-01-05 15:40:16) > On 05/01/2017 14:00, Pirate Praveen wrote: > > On വ്യാഴം 05 ജനുവരി 2017 06:09 വൈകു, Ximin Luo wrote: > >> This has nothing to do with tools, as Jonas mentioned it is about a > >> continual time dedication to a FOSS project. Please try to understand this. > > Yes, it has a lot to do with our tools. If we were using a git hosting > > tool like gitlab or pagure, we could have reviewed pull requests before > > we grant access to a new contributor. > > > > You can't demand such dedication from a new contributor. Did you sign > > such a commitment before you got access to pkg-javascript team and debian? > > > > What did you mean when you said they can use github.com? Isn't that > > evidence of our lack of tools to bring new people to debian? Why should > > I tell anyone to use a proprietary service to contribute to debian? This > > is something we got to fix. > > When I read this, I became curious about who creates and contributes to repos > in /git/pkg-javascript. Here is what I found out thanks to my paolog-guest > shell access to git.d.o. > > There are 876 subdirs in /git/pkg-javascript, and they were created by 30 > guest accounts and 37 non-guest accounts. A recursive search on all contained > files & subdirs yields a grand total of 33 guest accounts and 46 non-guest > (apparently not many people push to repositories someone else had created). > > For those git repos we are using a setup that the git docs [1] advise for "a > small outfit", but 79 seems more than "few developers" ... For larger teams > they advise gitosis or gitolite; only the latter seems to be an active > project and is packaged as gitolite3. > > My comments: > > - the tools we have are in line with rest of the debian tools (WOT, BTS ...): > CLI, raw and based on trust > > - granting shell access to guests is consistent with that culture > > - but 10 new guest accounts added to the pkg-javascript team in one > shot is a lot (+30%); also mass requests to join the team sound like > spamming (but that's clearly not the case here !) > > - when I was a student at the uni a long time ago I remember we were > willing to go a long way to please the professors **before** the exam > ;-) > > - if gitolite were installed and configured on moszumanska (git.d.o.), it > would probably be possible to set up access control on select repos for > external "contributors"; "contributor" here is meant in a sense similar to > "debian contributor" idea [2]. > > In conclusion, Debian Contributor is a suitable status for a student > who wants to give it a try during a seminar. If they pass the exam and > **afterwards** out of their free will submit a request to join > pkg-javascript, then the path from contributor to DD is open to them ! Yes, statistics may show how many in this team currently collaborate how much. And yes, Alioth provide us tools to separate our team in multiple classes of members. Do we want to maintain our current level of (lack of) collaboration? Do we want multiple classes of users? I want this team to be equal peers - one class with equal access rights. I want this team to be for maintainers helping each other as time and skills permit. If we should ever reject anyone, then only those who have demonstrated *not* collaborating or *not* maintaining - we should never refuse people based on fear that they will not do so in the future. That's why I ask (but do not demand proof) if these concrete newcomers are able and interested in not only releasing packages but also in maintaining them. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] lots of requests to join pkg-javascript
Quoting Pirate Praveen (2017-01-05 14:06:32) > On വ്യാഴം 05 ജനുവരി 2017 06:21 വൈകു, Ximin Luo wrote: > > We don't have hard rules, but we all have our ideas about what is right or > > wrong. For you, it is a question of "are they aware". For me, I explained > > it in my other email, and it roughly overlaps with "are they aware". > > I have accepted their request because I have spent time with them. By > removing people that I have accepted you showed contempt for my > judgment. What authority do you have to remove people from the project > just because they are new? > > Is this how this team want to continue? If I have acted wrongly, then > please remove my admin access as well. But this kind of action is not > sustainable as a team. Please stay, Praveen! Please do not kick out people, Ximin! Please, everyone else (and newcomers in particular): Please feel welcome in the javascript maintainers team when you feel able and interested in *maintaining* official debian javascript-related packages. Let's discuss here. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] lots of requests to join pkg-javascript
Quoting Ximin Luo (2017-01-05 13:51:00) > Jonas Smedegaard: >> Quoting Ximin Luo (2017-01-05 12:53:00) >>> Pirate Praveen: >>>> On വ്യാഴം 05 ജനുവരി 2017 04:22 വൈകു, Jérémy Lal wrote: >>>>> This is great, but is this serious ? >>>>> Anyone knows what's happening ? [...] >>>> I'm taking a packaging workshop at College of Engineering Pune [1]. >>>> >>>> This is 4th day of the workshop and many have completed their packages >>>> and are ready for upload. [...] >>> Hi, please don't add these people. >>> >>> People in the alioth group have read-write access to all >>> pkg-javascript git repos as well as shell access on that machine. >>> >>> I don't think it's right to give this many people, who show up at an >>> event, this level of access without any other requirement. It is too >>> dangerous. [...] >> We do not in this team have any rules for membership that one must >> first prove her worth by packaging outside of Debian, not that they >> must use their spare time doing so! >> >> I am concerned if people requesting to join are fully aware what it is >> they join, which is why I asked about that. But I see nothing wrong >> with approving people we don't know well. > > > > We must recognize that we have little security fencing the assets of > > this team, and treat them accordingly (double-check what you pull, sign > > changes you make, etc.). Making it harder to join this team does *not* > > help secure our assets! > > > > We don't have hard rules, but we all have our ideas about what is > right or wrong. For you, it is a question of "are they aware". For me, > I explained it in my other email, and it roughly overlaps with "are > they aware". > > The security aspect is just one factor, not the main factor. Ok, you now tell me that security is not the main factor. I clearly read your previous email as if security was the main factor for rejecting these requests. For clarity of discussion I shall *ignore* the security factor. > But to give more detail, (a) just because we have "little" security, > doesn't mean we have to make it quantitatively worse, which we will do > if we add anyone that asks - it adds surface area. And (b) the > standards of time and continual maintenance that I described > elsewhere, also indicates that a person is careful about their general > computing practices, which also helps to not-reduce security - > compared to giving access to a random person. Do I understand you correctly that in your opinion the main factor is devotion to continued mainentance? If so, then we agree on what is "main factor" - but still we disagree on how to then deal with it: It seems Praveen find it reasonable to approve "because they are ready to upload their packages", and it seems you find that exact situation reason for rejecting. I find it neither reject nor approve reason. I welcome into this team any and all persons who feel they are ready to *maintain* official Debian packages. I find it wrong to impose restrictions on that, but I want to emphasize _maintain_ - this team is *not* the Javascript *contribution* team (there are other methods to contribute to Debian in other ways than continuous mainenance). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] RFS: node-loose-envify 1.3.0
Excerpts from Pirate Praveen's message of December 12, 2016 11:54 am: On ശനി 10 ഡിസംബര് 2016 07:43 വൈകു, Jonas Smedegaard wrote: I generally use ~ because upstream may re-release _same_ version but with DFSG-violating pieces stripped. Arguably that is dificult to do at github but that is besides the point. It is not difficult in github, you just have to remove a tag, push a new tag. But I don't think retroactively changing a release is a good idea or a popular thing (do you know of any project that has done this?). Our job is to distribute code from upstream. When I use ~ then I allow upstream to use either approeach if they decide to adopt our repackaging: Treat as a new version or as repackaging of same version. When I use + then I cannot support upstream that choose to repackage and label it as being same version. I have opinions on what upstream approach is the best practice to use, but I do not want to cripple my packaging to not support other practices. It is not very useful to add extra steps (fix npm2deb or manually fix every depending package) for this unlikely scenario. If our tools do not support ~ then our tools are broken. Example: If you want official Debian packages to also support backports.debian.org then you will want to generally use ~ (and lintian warns if you don't in some cases - e.g. when tracking C symbols). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpBye8PpBpRr.pgp Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] RFS: node-loose-envify 1.3.0
Excerpts from Ross Gammon's message of December 10, 2016 10:14 am: On 12/10/2016 07:26 AM, Paolo Greppi wrote: The most popular suffix separator for dfsg is + (694 times), last comes ~dfsg (79 times) and finally -dfsg (15 times). ? ~ sorts before [a-z], + sorts after [a-z] I have used 1.2.3-1~exp1 sometimes, because then I can use 1.2.3-1 for the next upload to unstable once I know that it worked in experimental. If you exclude something from the upstream tarball because it is not allowed in Debian, then to stop repacking the tarball you need a new fixed version (without the offending file in the tarball) to be released upstream. Then 1.2.3+dfsg-1 makes a lot of sense, because if upstream fix it, the next version will always be higher than 1.2.3 (e.g 1.2.4). The only advantage to using ~ that I can think of, is if we change the rules and the offending file was now "free", you could just drop the ~dfsg. Unless others can think of another use case? I generally use ~ because upstream may re-release _same_ version but with DFSG-violating pieces stripped. Arguably that is dificult to do at github but that is besides the point. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpIdvrKMjXvB.pgp Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] new uglifyjs package ready for release (but failing for me)
Excerpts from Pirate Praveen's message of December 9, 2016 7:39 pm: On വെള്ളി 09 ഡിസംബര് 2016 07:45 വൈകു, Pirate Praveen wrote: I had uploaded 2.7.4 on Dec 1 and it is now in testing. Sorry about the confusion. No problem. I thought you missed my last upload. I have uploaded 2.7.5 Great. Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpqTI0Q7jyRm.pgp Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] new uglifyjs package ready for release (but failing for me)
Excerpts from Jérémy Lal's message of December 9, 2016 2:37 pm: 2016-12-09 12:48 GMT+01:00 Jonas Smedegaard <d...@jones.dk>: I have prepared a new upstream release of uglifyjs - but it still fails for me, as was the case also for last package (related to enabling testsuite). Please someone do the release. And that someone please share here your buildlog, to help me triangulate how my build environment may differ from yours, causing my build failures. Built and autopkgtest work perfectly here, in a clean sbuild sid chroot. Thanks. Could you please release it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] new uglifyjs package ready for release (but failing for me)
I have prepared a new upstream release of uglifyjs - but it still fails for me, as was the case also for last package (related to enabling testsuite). Please someone do the release. And that someone please share here your buildlog, to help me triangulate how my build environment may differ from yours, causing my build failures. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#836722: Bug#836722: Bug#836722: Bug#836722: needs yargs as a dependency
Quoting Pirate Praveen (2016-11-29 07:55:30) > On ചൊവ്വ 29 നവംബര് 2016 11:38 രാവിലെ, Jonas Smedegaard wrote: > > How? Please elaborate! > > > > Checking now with freshly updated unstable+incoming archives and it > > still fails to satisfy dependencies. > > I should have mentioned node-cross-spawn-async 2.2.5-2 (I had drafted > such a mail, but gnome-shell broke on my laptop, so missed that detail > when typed from mobile) > > It just took some time for processing after I uploaded > https://tracker.debian.org/news/819919 Thanks for the details. Now (after adding build-dependency on mocha) build fails with these: --- Sourcemaps tests ․․․ ․ 62 passing (44s) 2 failing 1) bin/uglifyjs should produce a functional build when using --self: Error: timeout of 5000ms exceeded at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19) at Timer.listOnTimeout (timers.js:92:15) 2) spidermonkey export/import sanity test should produce a functional build when using --self with spidermonkey: Error: timeout of 2ms exceeded at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19) at Timer.listOnTimeout (timers.js:92:15) My laptop slows to a crawl just before that failure, so I suspect it is eating up all memory, and I am not in the mood for disabling timeout as it seems mocha can do. Any ideas? Did you succeed a build, Praveen? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#836722: Bug#836722: Bug#836722: needs yargs as a dependency
[re-adding bugreport]] Quoting Pirate Praveen (2016-11-29 06:56:23) > On 2016, നവംബർ 29 10:05:58 AM IST, Jonas Smedegaard <d...@jones.dk> wrote: >>Cannot build the new uglifyjs until bug#846076 is resolved. > > This is now fixed. How? Please elaborate! Checking now with freshly updated unstable+incoming archives and it still fails to satisfy dependencies. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#836722: Bug#836722: Bug#836722: needs yargs as a dependency
Quoting Jonas Smedegaard (2016-11-29 05:26:39) > Seems to me that a simple chmod command is the right thing to use. I > do that now, and try release the package - but you are quite welcome > to suggest other approaches, or adapt the package yourself. Cannot build the new uglifyjs until bug#846076 is resolved. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#794890: Bug#794890: Bug#794890: npm: new upstream version
Quoting Michael Prokop (2016-11-23 14:18:49) > Disclaimer: I'm not blaming nor pointing to anyone, but I feel like > that this is yet again the team pattern and I'd really like to see > whether we have any way out of this... Thanks for stating above. > ... I'm afraid the situation of node-* packages in Debian is worse > than I expected. node-request's upstream release of version 2.26.1 > dates back to August 2013 and nowadays upstream is at version 2.79. > There's #844072 against node-request (where someone is asking for a > newer version of node-request in Debian), but it was filed just this > month (November 2016) and between 2013 and 2016 there was not a single > package upload for node-request in Debian. Seems you imply that node-request is badly maintained. Another interpretation of above facts is that node-request was very well written and its dependencies in Debian until recently was satisfied fine by the older version. > Asking around what other Debian contributors and users usually do when > they've to deal with npm + nodejs: either "npm install -g npm"(sic!) > and then use npm to install the actual node packages or directly head > towards upstream (like https://deb.nodesource.com/setup_4.x). Npm is an *alternative* to using Debian packaged nodejs code. Users of Debian cannot tell anything about how same or similar tasks could be solved using Debian, because they evidently stopped trying. > Now one reason why we have node-* packages in Debian is that they > are dependencies of further packages. To have some numbers: I see > 601 packages named "node-*" in sid/amd64 as of today, and when > looking at their reverse dependencies I see only those 24 binary > packages with node-* packages in their depends/recommends/suggests: [] > [JFTR: I didn't consider and look into build-depends for my numbers > and didn't verify my list with UDD or similar yet. If my numbers are > wrong please correct me.] Seems you counted only _binary_ packages - missing e.g. libjs-jquery which is a dependency of quite a few packages. > I might be wrong (please correct me), but my impression is that people > are uploading node-* packages mainly to satisfy a (build-)dependency > they have in a package and then don't really care about those packages > any longer. That may be true for some packages, but please fix your counting method before further discussion, to avoid discouraging people doing good work here, > Back to the npm situation: I was reporting > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794890#34 because > Debian's npm can't be really used reliably nowadays (the > "@module/names" not supported at all). Looking through the bugreports > of the npm package I'd call it unmaintained, I suspect you are right that npm specifically is in bad shape in Debian - but my (unsubstantiated) impression is that the cause is not that Nodejs packages in general are badly maintained, but instead because of the very aim of npm being not to fit Debian but to bypass it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#836722: Bug#836722: Bug#836722: needs yargs as a dependency
Quoting Pirate Praveen (2016-11-23 08:37:39) > On Tuesday 22 November 2016 10:53 PM, Jonas Smedegaard wrote: >> Ah, I understand you now: You present breakage when using code not in >> Debian. Quite confusing - please *always* mention explicitly in >> bugports when using non-Debian packages! > > Sorry, that was mostly meant a self note (I should have explicitly > mentioned it). > > I ran uscan, imported the new upstream release, built the package and > got the error when running it. Makes sense (now that I what sense to make of it) :-) >> I only asked whether or not it was related - I did not imply it was >> not. >> >> I was genuinely confused by your terse writing style. >> >> Another point of confusion was that a different topic was used in the >> email than in original bugreport topic. I was unaware (until digging >> into archive, when in above latest post you still didn't elaborate >> much) that was a wishlist bug, so assumed that your presenting code >> failing was to be treated seriously. >> >> >> With the best of intentions, > > Sorry about doubting your intentions, but that came as a result of so > much comments on -devel about packaging so many tiny node modules. > Since you already commented before to start with packaging yargs I > thought it would be enough. I can understand how might have seen the clues as being "right around the corner". Keepup the good work, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#836722: Bug#836722: needs yargs as a dependency
Quoting Pirate Praveen (2016-11-22 17:54:32) > On Tuesday 22 November 2016 10:19 PM, Jonas Smedegaard wrote: > >> I got this when running the updated uglifyjs package (before seeing your > >> previous comment about yargs). > > > > What version is "the updated uglifyjs package"? > > latest upstream release which needs yargs. Ah, I understand you now: You present breakage when using code not in Debian. Quite confusing - please *always* mention explicitly in bugports when using non-Debian packages! >>> We are getting close to packaging yargs >>> https://wiki.debian.org/Javascript/Nodejs/Tasks/yargs >> >> Great. But is that related to this bugreport? > > Did you read the previous comments? Newer version of uglifyjs needs > yargs. How is this not related? I only asked whether or not it was related - I did not imply it was not. I was genuinely confused by your terse writing style. Another point of confusion was that a different topic was used in the email than in original bugreport topic. I was unaware (until digging into archive, when in above latest post you still didn't elaborate much) that was a wishlist bug, so assumed that your presenting code failing was to be treated seriously. With the best of intentions, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#836722: Bug#836722: needs yargs as a dependency
Quoting Pirate Praveen (2016-11-22 16:50:42) > On Mon, 05 Sep 2016 12:03:22 +0200 Jonas Smedegaard <d...@jones.dk> wrote: > > Quoting Pirate Praveen (2016-09-05 09:22:06) > > > nodejs bin/uglifyjs --help > > > module.js:339 > > > throw err; > > > ^ > > > > > > Error: Cannot find module 'yargs' > > > > Which version of uglifyjs? > > I got this when running the updated uglifyjs package (before seeing your > previous comment about yargs). What version is "the updated uglifyjs package"? > We are getting close to packaging yargs > https://wiki.debian.org/Javascript/Nodejs/Tasks/yargs Great. But is that related to this bugreport? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#844072: node-request: Please upload the latest version of node-request
Quoting Ross Gammon (2016-11-12 10:26:55) > I am working on finalising the new kosmtik package, and it depends on > node- request (>= 2.64.0). Currently only 2.26.1 is in Debian, and > upstream have released 2.78.1. > > Would it be possible to have a new version? I can see 5 reverse dependencies, > but I haven't checked them: > npm > node-ytdl-core > node-gyp > node-pre-gyp > node-millstone > node-jsdom > > I would be happy help with the update if you prefer. You are quite welcome to help in any way you can. You are also welcome to repackage, if you are uncomfortable with its current CDBS packaging style. If you do that, then just beware that you will effectively take over maintenance, as I am not comfortable with short-form dh packaging style. But arguably that would be no big loss anyway :-/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#844075: Bug#844075: leaflet: Please provide the latest Leaflet package including a node module
Quoting Jérémy Lal (2016-11-12 10:51:08) > leaflet reverse dependencies need extra careful checks, because i > believe there are been many changes between 1.0 and 0.7. Right. Luckily only few packages depend on leaflet, but indeed they need to be checked thoroughly for incompatibilities. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#844075: leaflet: Please provide the latest Leaflet package including a node module
Hi Ross, Quoting Ross Gammon (2016-11-12 10:45:14) > I am trying to finalise the packaging of the new kosmtik package, but > it requires a newer version of Leaflet (>= 1.0.0-beta.2) including the > node module. Debian currently has version 0.7.7+20160312-1, and 1.0.1 > has been released upstream. > > There are a few reverse dependencies that would need to be checked: > libjs-leaflet-markercluster > qgis-common > libjs-wax > routino-www > qgis-common > gis-osm > flightgear-phi > > Let me know if I can help with pulling together the new version. Would be great if you could look into those dependencies. I believe I have some half-baked attemtps at updating the leaflet package itself which I would like to dust off and check if still relevent. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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] Nodejs-D3 package
Hi Alexis, [tracking URLs stripped from quoted text] Quoting Alexis Rodriguez (2016-11-08 04:42:42) > I'm Alexis and I saw the bug report > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801765. > I would like to help to package and maintain Nodejs-D3 - > https://github.com/d3/d3 > for debian. I'm not a official Debian Developer or maintainer but I > have knowledge in debian packaging. Are someone else interested on > help me to resolve all dependencies for Nodejs-D3 ? Great that you wanna help! If you haven't already, then please a) subscribe to this mailinglist and (create an Alioth account and) request membership of our Alioth team. (I cc'ed you in this response, but the normal mailinglist posting style in Debian is to not cc sender unless explicitly requested, so don't rely on that!) You ask if others want to join your effort, but please note that D3 is already packaged for Debian: Bugreport #801765 is about _extending_ the existing source package to produce an additional binary package targeted nodejs, in addition to the current binary package for browser use. Therefore a good starting point is to look at the existing source packag: If maintained by others than this team then get in touch with then and ask how more concretely they might need your help in solving the bug (or go ahead and create a patch and add that to the bugreport, and _then_ ask them if they wanna apply it themselves. If maintained by this team then look who is listed as uploaders, and who in fact has uploaded the most recent changes to the package - and try get in touch with those explicitly to figure out if they are perhaps working on this already. Hope that helps. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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#840170: Bug#840170: some modules has package.yaml instead of package.json
Quoting Pirate Praveen (2016-10-31 10:39:58) > On Monday 31 October 2016 03:07 PM, Jonas Smedegaard wrote: > >> reducing severity to important, this does not have to block the release > >> as it happens only in a few packages and which can easily be fixed. > > > > The tag is "severity", not "complexity": If the bug cause failure to > > build packages the it is of high severity, no matter how hard or easy it > > will be to fix. > > > > If release happened before this bug was fixed, then it _is_ a blocker! > > > > Fix is to add package.yaml to debian/install. This bug does not make any > current packages to fail. It only affects packages that are newly > created and debian/install is not corrected. Ah - makes sense, then. I simply misunderstood your previous comment. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#840170: some modules has package.yaml instead of package.json
Quoting Pirate Praveen (2016-10-31 06:46:56) > Control: severity -1 important > > On Sun, 9 Oct 2016 11:32:47 +0530 Pirate Praveen <prav...@debian.org> wrote: > > severity: grave > > justification: breaks package build > > reducing severity to important, this does not have to block the release > as it happens only in a few packages and which can easily be fixed. The tag is "severity", not "complexity": If the bug cause failure to build packages the it is of high severity, no matter how hard or easy it will be to fix. If release happened before this bug was fixed, then it _is_ a blocker! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#842058: Bug#842058: uglifyjs: diff for NMU version 2.4.15-6.1
Hi Jochen (cc the bugreport), [please follow up via the public bugreport rather than discretely] Quoting Jochen Sprickerhof (2016-10-26 10:51:09) > * Jonas Smedegaard <jo...@jones.dk> [2016-10-25 19:27]: > > If you have uploaded with delay, feel free to re-upload without > > delay (the package is - or should be - listed in LowThresholdNMU at > > our wiki). > > Did so, thanks for the quick reply. Yes, I noticed. Thanks again! Also, if you are interested in helping maintain the package generally, then feel free to join the javascript team and add yourself in the "Uploader:" field (yes, no matter if technically you do anything but exactly upload). > Can you push the changes to the git repo? (Sorry for asking, I'm still > new to this). Yes, don't worry: I will include the patch when I get around to it later (if you don't do it first - see above). :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#842058: Bug#842058: uglifyjs: diff for NMU version 2.4.15-6.1
Quoting Jochen Sprickerhof (2016-10-25 18:16:02) > I've prepared an NMU for uglifyjs (versioned as 2.4.15-6.1). The diff > is attached to this message. Thanks, also for the NMU itself. If you have uploaded with delay, feel free to re-upload without delay (the package is - or should be - listed in LowThresholdNMU at our wiki). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#841981: nodejs should recommend ca-certificates
Quoting Jérémy Lal (2016-10-25 01:49:01) > 2016-10-25 1:43 GMT+02:00 Daniel Lo Nigro <li...@dan.cx>: > > > Apart from that, is there a good reason to use Recommend instead of Depend > >> ? > > I'm not sure. wget and libcurl3-gnutls both "Recommend" rather than > > "Depend" on ca-certificates. I think it's because wget still mostly > > works without it, it's just TLS/SSL connections that fail. Node.js > > behaves the same way, all of Node.js works without ca-certificates > > except for TLS connections. > > > > > I'm leaning toward Depend, because upstream bundles certificates (and > the nodejs debian package patches upstream to use ca-certificates > instead), users expect the usual certificates independently of how > they installed nodejs. Some use-cases of nodejs does not involve network access, and therefore not TLS either. Example build environment. Bootstrapping a chroot with ca-certificates takes more time and diskspace than without it. The correct package relation to use if there are corner cases without need is Recommends:. - Jonsa -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] /usr/bin/nodejs vs /usr/bin/node
Hi Daniel, Quoting Jérémy Lal (2016-10-21 09:05:04) > 2016-10-21 7:24 GMT+02:00 Paul Gevers <elb...@debian.org>: > > On 21-10-16 06:55, Daniel Lo Nigro wrote: > > > Given the amount of complexity stemming from Debian renaming this > > > binary and the fact that it breaks parts of the Node.js ecosystem, > > > is there any chance it will be renamed back to "node" in the > > > future, or for /usr/bin/node to be symlinked to /usr/bin/node > > > (perhaps using the update-alternatives system to allow the user to > > > choose whether they want to symlink nodejs or ax25-node, in case > > > they have both installed)? > > > > In Debian, we have the package nodejs-legacy which provides the > > symlink you request. Please read the description. Apart from text > > describing fact that no official Debian package may depend on it, it > > also contains a link to the technical committee ruling on how this > > came about. As the ax25-node package still exist, I see no chance at > > all that the current situation will change. > > > > As ax25-node and nodejs don't provide the same functionality, using > > the update-alternaives system is not appropriate. > if you're distributing yarn in the main debian archive, i believe the > right way to work around this is to "Suggest" nodejs-legacy in > debian/control. I disagree that above is the "right way" - here are the options you have as I see them: a) Continue to also support "nodejs" runtime * You may suggest (but not recommend or depend on) nodejs-legacy. * Must be usable (at least for a subset of cases) with "nodejs". b) Support only "node" runtime * You should depend on or recommend nodejs-legacy * Cannot be part of official Debian (but can be in contrib) c) Change ruling through the tech-ctte or a general solution vote * Will be a tiresome and long process * Will only become effective for next-next stable (i.e. in ~2019) * May further tear apart our communities rather than unite As I see it, the "right way from the POV of Debian is a), while from the POV of the Node.js community it is c). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] jquery-goodies policy and grunt
Quoting Paul Gevers (2016-10-07 15:33:39) > First off, you voice my opinion, and fortunately you don't mention > anything new (to me). The reason why I asked is because what I observe > in packages maintained by this team (which is new to me). This team is very loose - which means some in the team package in a style others do not agree with. > On 07-10-16 15:21, Jonas Smedegaard wrote: >> Quoting Paul Gevers (2016-10-07 14:09:43) >>> A relate question: JavaScripts are often "combined" with Grunt. What >>> is the current status/stance of including those in Debian. > > You didn't really answer this question. As far as I am aware, but > maybe I am wrong, there were issues with getting Grunt into Debian. Or > is that issue already solved. Sorry if I was unclear. In my *personal* opinion, concatenated source is not upstream preferred form and therefore not the ideal for us to redistribute as source and therefore not something that I personally would treat as such. I believe we as *team* do not have different rules than Debian in general regarding what is permitted and what is not in source packages. No, grunt was not in Debian last I checked. What I would do is try mimic with other tools what grunt does. I would so such mimicing during *build* from true non-concatened non-minified sources included in source package, due to my personal opinion described above. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] jquery-goodies policy and grunt
Hi Paul, Quoting Paul Gevers (2016-10-07 14:09:43) > I am about to add some JavaScript binary packages to Debian, but I was > really wondering what the current ideas are with respect to source > packages. There are a lot of jquery plugins packaged in the > jquery-goodies package, but also several (a lot?) of plugins are > packaged separately. What is the current consensus: should new plugins > be packages via the jquery-goodies package or stand-alone or does it > depend? Are there reasons to choose one or the other? You should track each upstream project. Easiest way to do that is to package each (real!) upstream as a separate Debian source package. You might alternatively track indirectly either via an intermediate pseudo-upstream or via bundling multiple upstream into a single Debian source package - but I doubt that will work reliably, and continue to do so over time. And I doubt it works well for current bundle packages! > A relate question: JavaScripts are often "combined" with Grunt. What > is the current status/stance of including those in Debian. I am > normally of the opinion that everything should be build from source, > but I can also be somewhat pragmatic if required. JavaScript that is > combined is still very readable and changeable and I have the idea > that there is a lot of JavaScript in Debian that isn't "build from > source". You must include source. Easiest way to do that is to only include source - i.e. the form preferred by (real!) upstream as basis for their development. You might alternatively ensure in other ways that source is included, e.g. by build-depending on other packages shipping the source and implementing build rules checking that processing (minifying, concatenation, whatever) of both real source and your included files produce identical result. But I am highly sceptical that it will be simpler, or that you can come up with an approach that ftpmasters, release managers, and Debian in general will agree complies with DFSG if/when they actually look closely at what you implement (but obviously you might succeed at first with getting it into Debian if they don't). Hope that helps. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Request to Join Project Debian JavaScript Maintainers from Paul Gevers (elbrus)
Quoting Paul Gevers (2016-09-18 18:14:34) > On 09/18/16 17:50, Jonas Smedegaard wrote: >> Does this imply you've also subscribed to our list now, or would you >> still like to be cc'ed for conversations involving you there? > > I just did that, so from now on you can drop the CC to me. Excellent! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] roadmap of jquery (and helpers)
Quoting Jonas Smedegaard (2016-09-18 17:48:44) > Quoting Paul Gevers (2016-09-18 09:40:30) >> On 09/17/16 10:51, Jonas Smedegaard wrote: >>> Quoting Paul Gevers (2016-09-16 20:01:27) >>>> How are other JavaScript chains handling the lack of automatic API >>>> tracking? [...] > I am unaware of any systematic checks being done to javascript > packages like the symbols files we have for C/C++ libraries. > > Would be awesome to improve on that! The "scope analyzer" part of > UglifyJS might be a start: http://lisperator.net/uglifyjs/scope A better starting point seems tobe Esprima: http://esprima.org/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Request to Join Project Debian JavaScript Maintainers from Paul Gevers (elbrus)
[sent again - properly spelling Paul's address this time] Quoting nore...@alioth.debian.org (2016-09-18 06:59:41) > My interest is to improve the jquery situation and to add several > JavaScript files that use jquery. Either via jquery-goodies or via new > packages. Welcome aboard, Paul! Does this imply you've also subscribed to our list now, or would you still like to be cc'ed for conversations involving you there? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] roadmap of jquery (and helpers)
Quoting Paul Gevers (2016-09-18 09:40:30) > On 09/17/16 10:51, Jonas Smedegaard wrote: >> Quoting Paul Gevers (2016-09-16 20:01:27) >>> How are other JavaScript chains handling the lack of automatic API >>> tracking? >> >> At least 16 packages unacceptably violates Debian Policy, according >> to >> https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co > > This was not what I meant. What I meant is how JavaScript is handling > the lack of shlibs/symbols processing as we do during package building > for libraries and depending packages. I would love to know how I can > learn what version of $javascript-package I actually need for my > package to work properly. Oh - sorry for not reading properly what you indeed explicitly wrote! I am unaware of any systematic checks being done to javascript packages like the symbols files we have for C/C++ libraries. Would be awesome to improve on that! The "scope analyzer" part of UglifyJS might be a start: http://lisperator.net/uglifyjs/scope I don't know javascript well enough to program something myself, though. >>> Are there tools in the team to check for breakage? One of the stupid >>> but powerful things that I do for the cacti package (a web-app) is >>> to just recursively crawl all web-pages, I guess it must be possible >>> to also check JavaScript execution. >> >> In theory we have several tools to emulate javascript-enabled >> browsing, > > Could you please hint which ones you have in mind? Backbone used to use PhantomJS in its upstream testsuite. The testsuite as a whole required parts not packaged for Debian but I had lifted out the one line executing PhantomJS. But then PhantomJS had problems close to a freeze and I avoided PhantomJS (see bug#768754). Recently when upgrading Backbone, I had a look at that PhantomJS issue again, but failed for me to use xvfb (workaround noted in bug#817277). There are some alternatives to PhantomJS, and there are verious frameworks making use of either PhantomJS or some of its alternatives. http://stackoverflow.com/questions/14964108/alternative-to-phantomjs-for-testing mentions some alternatives, one of them being "jsdom" seemingly what we have in Debian as node-jsdom, but I gave up on trying to figure out how to use it. Backbone recently switched upstreeam to the helper tool https://github.com/karma-runner/karma - which at its website mentions a range of related helper tools, some of which might (directly or indirectly) support either PhantomJS or some alternatives. Another approach might be to sidestep the whole Nodejs environment for testing. Seems there are automated web browsing testing tools for java, python and perl - where "Selenium" pops up frequently as a protocol(?) commonly used... I am a perl guy mostly. If you are a python guy you might have more or different options available... >> I guess locally - *not* using Debian infrastructure - one might use >> npm > > Why not using Debian infrastructure, because one needs to download > stuff that isn't in the package? I was thinking of running these tests > as autopkgtest? Correct: Many tools used in upstream testsuites are not packaged in Debian yet. I don't know the rules for autopkgtest - if pulling in alien code then I guess that is an option - but IMO would be a severe bug in the rules for autopkgtest (but arguably that's besides the point of this discussion). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Request to Join Project Debian JavaScript Maintainers from Paul Gevers (elbrus)
Quoting nore...@alioth.debian.org (2016-09-18 06:59:41) > My interest is to improve the jquery situation and to add several > JavaScript files that use jquery. Either via jquery-goodies or via new > packages. Welcome aboard, Paul! Does this imply you've also subscribed to our list now, or would you still like to be cc'ed for conversations involving you there? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] roadmap of jquery (and helpers)
Quoting Paul Gevers (2016-09-16 20:01:27) > On 09/14/16 21:46, Jonas Smedegaard wrote: > > The Javascript team is only loosely coordinated: Not all of us nurse > > all of the packages in the team. > > So how many are there approximately? We are potentially 82, according to https://alioth.debian.org/projects/pkg-javascript/ How many of us have actively contributed in recent time I don't know. Probably a sensible feature to add to UDD dashboard (see bug#838067). > And how many are involved in the jquery stuff? Officially 3, according to Uploaders field as listed at https://tracker.debian.org/pkg/jquery Effectively only 1 has committed to master branch recently, according to https://anonscm.debian.org/cgit/pkg-javascript/jquery.git/log/ Numbers more broadly for "jquery stuff" is more tedious to resolve, I suspect. It involves resolving the contributors to somewhere between 24 and 1500 packages, according to quick looks at https://udd.debian.org/dmd/?pkg-javascript-devel%40lists.alioth.debian.org and the output of "build-rdeps libjs-jquery". > I am considering joining the team, but I don't want to be the only one > to care for jquery and its related packages (no offense intended > Antonio). I understand your concern, but which are the alternatives as you see it? Personally I find only these alternatives sensible: a) patch package to work with javascript libs available in Debian b) hack package to avoid javascript unadaptable/unsuitable in Debian c) convince existing maintainers of javascript libs to improve d) get involved and do the improvements yourself I.e. I don't find it sensible to maintain javascript libraries outside of this team, and don't find it sensible to embed code copies of javascript in other packages. I am curious which alternatives you see, and arguments supporting them. > > As I recall, maintenance of jquery in particular has lagged behind a > > lot in the past. So any and all help would be much appreciated. > So a statement on the current strategy would be nice, such that I can > evaluate if it makes sense to join the team. Anyone (potential/official/effective/whatever) involved with jquery stuff please speak up! > What I care for is that a modern version is available (maybe for the > time being next to an older API? Sounds sensible to me - but my voice count less than those caring about jquery in particular. > How are other JavaScript chains handling the lack of automatic API > tracking? At least 16 packages unacceptably violates Debian Policy, according to https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co > Are there tools in the team to check for breakage? One of the stupid > but powerful things that I do for the cacti package (a web-app) is to > just recursively crawl all web-pages, I guess it must be possible to > also check JavaScript execution. In theory we have several tools to emulate javascript-enabled browsing, but I have not yet been able to figure out how to use any of them. Anyone having positive experience with automated brower testing, please speak up! I guess locally - *not* using Debian infrastructure - one might use npm to pull down and run some of the more involved various upstream testing tools. Not that I would do so myself, just mentioning as an option... Ideally we should package the more popular of those tools, obviously, but dependency chains are often long, and deviates from your question. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#837929: npm: Should suggest nodejs-legacy
[drop old archived bug from cc] Quoting Matijs van Zuijlen (2016-09-16 10:39:05) > On 16/09/16 10:24, Jérémy Lal wrote: > > 2016-09-16 10:22 GMT+02:00 Jonas Smedegaard <d...@jones.dk > > <mailto:d...@jones.dk>>: > > Quoting Matijs van Zuijlen (2016-09-16 09:57:52) > > > I read through bug 614907, and I think the very best solution > > > would be for npm to ensure the correct node executable is > > > referenced in each package's executable. I don't know how feasible > > > that would be. > > > > Arguably the "very best" would be to drop npm from Debian ;-) > > > > More to the point, however: Do npm work at all without > > nodejs-legacy? If not, then npm itself should be moved to contrib! > > > > Actually i believe most modules just work without nodejs-legacy, and > > npm itself has some uses without installing it either. > > Yes, it seems it's mainly the modules that provide an executable > script that need nodejs-legacy (In my case, coffeelint). Agreed. I mentioned it only for completeness. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#837929: npm: Should suggest nodejs-legacy
Quoting Matijs van Zuijlen (2016-09-16 09:57:52) > I read through bug 614907, and I think the very best solution would be > for npm to ensure the correct node executable is referenced in each > package's executable. I don't know how feasible that would be. Arguably the "very best" would be to drop npm from Debian ;-) More to the point, however: Do npm work at all without nodejs-legacy? If not, then npm itself should be moved to contrib! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#837929: npm: Should suggest nodejs-legacy
Quoting Jérémy Lal (2016-09-15 17:21:30) > 2016-09-15 17:12 GMT+02:00 Matijs van Zuijlen <mat...@matijs.net>: > > > Package: npm > > Version: 1.4.21+ds-2 > > Severity: wishlist > > > > Executables installed with npm need the /usr/bin/node executable, which > > is provided in the nodejs-legacy package. This information is currently > > only in the README.Debian file. I think it would be really helpful to > > add nodejs-legacy to the npm package's Suggests:, or even Recommends:. > > > > > Well, re-reading > https://lists.debian.org/debian-devel-announce/2012/07/msg2.html > paragraph 2 says > > > No package in the archive may depend on or recommend > > the nodejs-legacy package, which is provided solely for upstream > compatibility. > > Taken literally, it doesn't forbid Suggest. Does it ? I agree we are not forbidden from suggesting: Seems to me the choice of words by the Technical Committee was deliberate, as that matches how packages outside of Debian (i.e. non-free stuff) is allowed to be suggested only. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] roadmap of jquery (and helpers)
Hi Paul, Quoting Paul Gevers (2016-09-14 20:53:40) > [I am aware that this has probably been discussed before, but I fail > to find the right discussion in the archive. Please point me to it if > you know where it is.] > > I am currently preparing for a new major upstream version of my > package cacti (which I hope will be able to meet the stretch freeze). > Upstream has already for a long time been using jquery, and I have > been able to use the Debian package as my dependency. The next major > version "needs to avoid jQueryUI 1.2 as it's currently a hot stinking > mess."¹ > > AFAIUI due to the nature of how the javascript eco-system works, it is > not trivial to "follow" newer versions. Could you please let me know > what the roadmap² of the javascript maintainer team is for the jquery > package and to jquery related packages. I see there is a 3.0 version > in experimental, but it is unclear to the outside world (and to me) > when that will migrate to unstable. Should I instead prepare for a > convenience copy of jquery (and related scripts), which I would really > hate to do? I strongly recommend against embedding jquery into the cacti package: You will then effectively take responsibility for maintaining the code (albeit only for compatibility with that one package, but with full coverage of eventual security flaws), and it would be far better if you instead joined the effort of maintaining the proper packaging. The Javascript team is only loosely coordinated: Not all of us nurse all of the packages in the team. Personally I dislike jquery so am not involved in that. As I recall, maintenance of jquery in particular has lagged behind a lot in the past. So any and all help would be much appreciated. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#837467: libjs-handlebars, libjs-handlebars.runtime: should track its canonical source
Package: libjs-handlebars,libjs-handlebars.runtime Version: 2:0.21.0-5 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Binary packages libjs-handlebars and libjs-handlebars.runtime are built from source package ruby-handlebars-assets which is the source only of the Ruby wrapper for Handlebars, not Handebars project itself. Instead, these packages should be built from the canonical source at https://github.com/wycats/handlebars.js/ . - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJX1bSCAAoJECx8MUbBoAEh9+YP/2fth9UQfP9TAoRYSz4/+E/a /FqAch7DeYU0nb9vi0o6rwHvbOt+hKha26o0B+v+GVpuUgJDaEwhjWiibJRMQo04 LweSSQ8AAy/qlMxO/Py7uiEwZmTS6xTDterrzbc6UiRFaHnOCnI47kdV+4JZ5No1 IomMuduB9lpmIZRved1JRLRM9t5gUVHMLW9ItSj82ba7uiUyn8B6gqHOb0ZOUsKK rV7otCpBIGxG1YkRuV7EyHZlCc9Zq9rA9EJB76h5J7u9bIGawrMkPl/YdjzIG460 DP4cMIoaP+gTg5a8i3rR5BSlTENhcQwaTw2vs+yVpbjPsESgX2gv7bGN9zVlZ/oS F0od5E12TV/gbyuTeT4G8v4btf+KtJlt2EpX91+UFH3FH1iZ88oL85PABy5zfCfH /EFWLHGC85C0udwqJHcJsX+PSBmKUWREEZLclcpIKhbe2LgPCDeBLQS+GER0qIfL Bg1GeFEsK5scDHi4zUnqN8szmWK3yII0wOMMnnfDkusY7x5o0+YChKqfC+ZOGhZE MvMyunHUKEdsNcjmba9b2HGCavgwyfsV4dvMqSP7C4iQVH5NSEzfhfpTTIy2zzc7 HA7Tkd8YmiK4v/3VED3ldoNj6cezD22mdBZHysrdQxFOWNzi4rTIYytyHeXEY8md tpH+ChEHRHIIwayCzuoI =akQF -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] Request to Join Project Debian JavaScript Maintainers from ChangZhuo Chen (czchen)
Quoting nore...@alioth.debian.org (2016-09-05 16:46:14) > I want to join JavaScript team to comaintain chartkick.js (#836765). Welcome aboard! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#836722: Bug#836722: needs yargs as a dependency
Hi Praveen, Quoting Pirate Praveen (2016-09-05 09:22:06) > nodejs bin/uglifyjs --help > module.js:339 > throw err; > ^ > > Error: Cannot find module 'yargs' Which version of uglifyjs? NB! Make sure to always mention explicitly in bugreports if your system is not plain Debian - i.e. if you use backports.debian.org packages or packages from other non-default sources, or if you use code not integrated with APT at all - e.g. with NPM, RubyGems, CPAN etc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#836722: Bug#836722: update libjs-uglify to latest upstream release
Hi Praveen, Quoting Pirate Praveen (2016-09-05 08:16:11) > I'd like to update ruby-uglifier to 3.0.2 version (for updating > diaspora to 0.6). It ships with 2.7.3 of uglify.js. It would be better > to have the matching version in debian. Would indeed be great to have newer releases of Uglifyjs. Newer uglifyjs depend on, yargs, which is not yet in Debian. There are possibly more missing dependencies, I have not yet investigated that, but yargs is a start... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#805282: Bug#805282: Bug#805282: Please package version >= 3.9.3
Hi Valentin, Quoting Valentin (2015-11-16 12:42:57) > I will update the package this week-end so you could work on > OpenStack. What is status on updating recent version of node-lodash? I can help maintain this package. Would you be ok with that? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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#836205: node-debug: CVE-2015-8315: Vulnerable to ReDoS attacks
Package: node-debug Version: 2.1.0+dfsg Severity: important Tags: security upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 node-debug contain convenience code copy of ms, which is vulnerable to so-called ReDoS (regular expression denial of service) attacks: https://nodesecurity.io/advisories/46 According to above advisory, upgrading to ms 0.7.1 or greater solves the issue. node-debug addressed this as last commit before releasing 2.2.0: https://github.com/visionmedia/debug/commit/0f4fd585befe8ce9287f4407cbcd95c63a6f1cfd I found this issue through a commit message to node-stringprep: https://github.com/astro/node-stringprep/commit/e9d5b40ab3c6a03546309ba84b08b159b5d0db59 I wonder if perhaps the security team might have spotted this far earlier, if the ms code had been properly packaged as a first-class node-ms package rather than hidden as embedded convenience code copy. - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXxusPAAoJECx8MUbBoAEhqQQQAKcrT5xHurYY+lFrI01rLeiQ FY037YgZEUAzyTKEIYRCR46Xw3XEuTv6y670RQsYY7C7/jO2gPzHUACthyaCdak8 SNrSEQYFh52fy9hiSZBtetyrqLh4JN/sPA+/+yGFouFHj+CSILqT7LCPbDfxO0jn 58pN8PTmBeZFaJ0yg8wm1oct/8KlS1loiXoRSLErTBDNJ9fMzooOve1ukMsOYpC2 9gDb0zDogsGf23hvMVfoOJ2jAskCKroVUU9V8/BwiOTJquU9SY/fCtX8+jZXrYVY vnRuMboZPV/ZHDN3ofO1ZzVS9Kt86Ccvi5+XcwtrEDNBqNCRDaDakaPQ8BH2bF+6 VJIU94haukEgQedO8tvGBgdsE775Nls70UBmwsUKdbrkRBAqsOrlTqpK7HFbEZYF mYLgVuoPvyl65A8UXypboYJnNYARbCQfXcOve5QAGYUSVqvOudpXUnZWQJ6yY8Rp vBQB5JgZNJsxNQugbr3yau+/C34/UHSjwDQ2Rlw2EdpXn1bXP7D4EEPtL9RvgVkx tlKWKPuGrzDygN97PykrYFiQQk7KSPJlTX2Mjf2uHOJNgIrWKq5EGXtFyqLr7zWo Qd0ovpQ5nPdSdkDpcSZNRyYcqj+xL1KX7N/E5vuVCyvpPA5kck6//XgO4Mx5OozF pSveE98RXTlWwycgyAtW =4l4T -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
