[Pkg-javascript-devel] Bug#892425: node-package-preamble: please make the output reproducible
On 09-Mar-2018, Chris Lamb wrote: > Upstream. I've filed it here: > https://github.com/mbostock/preamble/pull/4 I see that now, thank you. > > Does this change apply more generally to many JavaScript packages? > Not that I am aware of. It would only apply to a limit subset of > packages where […] Great, thank you for indulging my curiosity. -- \ “During the Middle Ages, probably one of the biggest mistakes | `\ was not putting on your armor because you were ‘just going down | _o__)to the corner.’” —Jack Handey | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#892425: node-package-preamble: please make the output reproducible
Chris Lamb <la...@debian.org> writes:
> diff --git a/bin/preamble b/bin/preamble
> index a563140..be96d96 100755
> --- a/bin/preamble
> +++ b/bin/preamble
> @@ -3,12 +3,17 @@
> var os = require("os"),
> fs = require("fs");
>
> +var now = new Date();
> +if (process.env.SOURCE_DATE_EPOCH) {
> + now = new Date((process.env.SOURCE_DATE_EPOCH * 1000) +
> (now.getTimezoneOffset() * 6));
> +}
> +
> fs.readFile("package.json", "utf8", function(error, text) {
>if (error) throw error;
>var json = JSON.parse(text);
>process.stdout.write("// " + (json.homepage || json.name)
>+ " Version " + json.version + "."
> - + " Copyright " + (new Date).getFullYear()
> + + " Copyright " + now.getFullYear()
>+ " " + json.author.name + (/\.$/.test(json.author.name) ? "" : ".")
>+ os.EOL);
> });
Is this change generally useful to recipients of the upstream code base?
Or is it specific to OS distributions?
Does this constitute an improvement to the upstream code base? Or should
remain a persistent patch in the Debian package?
Does this change apply more generally to many JavaScript packages?
--
\ “I prayed for twenty years but received no answer until I |
`\ prayed with my legs.” —Frederick Douglass, escaped slave |
_o__) |
Ben Finney <bign...@debian.org>
--
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
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. -- \ “Are you pondering what I'm pondering?” “I think so, Brain, but | `\why would anyone want a depressed tongue?” —_Pinky and The | _o__) Brain_ | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#892227: node-backbone: dependencies fail to resolve when jQuery not installed
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.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages node-backbone depends on:
ii libjs-backbone 1.3.3~dfsg-3
ii node-underscore 1.8.3~dfsg-1
ii nodejs 8.9.3~dfsg-12
node-backbone recommends no packages.
Versions of packages node-backbone suggests:
ii libjs-jquery-lazyload 1.7.2-1
-- no debconf information
--
\ “When we talk to God, we're praying. When God talks to us, |
`\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 |
_o__) |
Ben Finney <bign...@debian.org>
signature.asc
Description: PGP signature
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] ES6 ‘import’ of Debian-installed module
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? The ‘node-backbone’ package “Suggests: libjs-jquery-lazyload”, so will typically not bring in that package. Because the Backbone package can't be imported without jQuery, is the bug then that ‘node-backbone’ should actually declare a dependency on jQuery? -- \ “Books and opinions, no matter from whom they came, if they are | `\ in opposition to human rights, are nothing but dead letters.” | _o__) —Ernestine Rose | Ben Finney -- 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
Pirate Praveen <prav...@onenetbeyond.org> writes:
> On ചൊവ്വ 06 മാർച്ച് 2018 08:29 രാവിലെ, Ben Finney wrote:
> > So, either the defaults as installed by Debian are not sufficient
> > for Webpack to resolve the path of an installed NodeJS library; or I
> > have misunderstood what you say.
>
> I had linked to an exact line of the sample configuration which you
> seem to have missed.
>
> resolve: {
> modules: ['/usr/lib/nodejs', '.'],
> },
> resolveLoader: {
> modules: ['/usr/lib/nodejs'],
> },
Thank you. I add that to the Webpack configuration, which makes it look
like:
=
$ 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'],
},
};
=
With that configuration, Webpack finds Backbone, but then fails to find
jQuery (as needed by the Debian-installed Backbone package).
=
$ webpack --config webpack.config.js
Hash: a9597112585b9ca5fb40
Version: webpack 3.5.6
Time: 248ms
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
=
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?
> webpack, like other node tools (grunt, gulp) does not recognize global
> modules. So we need to provide this path manually. But we could make
> this path default with a patch in debian like we did for grunt and
> gulp, patches welcome.
I don't understand the problem well enough to patch it. This is by way
of diagnosis so far; but yes, I would assume that the Debian-installed
packages should be found by the Debian-installed Webpack module
resolver.
--
\ Fry: “Take that, poor people!” Leela: “But Fry, you’re not |
`\ rich.” Fry: “No, but I will be someday, and then people like |
_o__) me better watch out!” —Futurama |
Ben Finney
--
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
Pirate Praveen <prav...@onenetbeyond.org> writes:
> I think it is still better to require/import just 'backbone'
Okay:
=
$ cat ./source/foo.js
"use strict";
import 'backbone';
=
> and let nodejs and webpack handle the path resolution.
I believe this configuration just relies on Webpack and NodeJS to figure
out the path resolution:
=
$ 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',
},
};
=
Webpack simply fails to find ‘backbone’:
=
$ dpkg --list node-backbone | grep '^i'
ii node-backbone 1.3.3~dfsg-3 all some Backbone for JavaScript
applications - Node module
$ webpack --config webpack.config.js
Hash: ff84e9ffdf4f296d9c1d
Version: webpack 3.5.6
Time: 48ms
Asset Size Chunks Chunk Names
app.js 2.65 kB 0 [emitted] main
[0] ./source/foo.js 34 bytes {0} [built]
ERROR in ./source/foo.js
Module not found: Error: Can't resolve 'backbone' in '[…]/source'
@ ./source/foo.js 3:0-18
=
So, either the defaults as installed by Debian are not sufficient for
Webpack to resolve the path of an installed NodeJS library; or I have
misunderstood what you say.
--
\“… no testimony can be admitted which is contrary to reason; |
`\ reason is founded on the evidence of our senses.” —Percy Bysshe |
_o__)Shelley, _The Necessity of Atheism_, 1811 |
Ben Finney
--
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
Pirate Praveen <prav...@onenetbeyond.org> writes: > On March 4, 2018 2:56:53 PM GMT+05:30, Ben Finney <bign...@debian.org> wrote: > >I have the ‘libjs-backbone’ package installed, and want to use it in > >some JavaScript code via an ES6 ‘import’ statement. > > As far as I understand, you have to write code targeting nodejs […] Thanks for the reply. My understanding, from <URL:https://webpack.js.org/concepts/modules/> the Webpack documentation about modules, is that it claims to support the ‘require’ modules (so-called “AMD modules”). The ‘libjs-backbone’ package installs Backbone code that uses AMD-style ‘require’ dependencies. So, when I write code that uses ‘import’ to bring in Backbone, and the Backbone code uses ‘require’ for its dependencies, that seems compatible with Webpack if I understand the Webpack documentation. Or am I missing something there? -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney -- 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] Should Debian be shipping node-promise?
Pirate Praveen <prav...@onenetbeyond.org> writes: > On വെള്ളി 09 ഫെബ്രുവരി 2018 01:07 വൈകു, Chris Lamb wrote: > > FYI upstream don't seem to think we should be building node-promise > > from source: > > Almost all nodejs developers want everyone to use only npm provided > packages. It is futile to argue with them (I have such discussions > often). Thank you for persisting in these discussions with upstream developers. I think it's worthwhile continuing to explain our reasons to them, even when some people prove to be unreceptive. The public record of discussions on this subject, with our reasons plainly and politely expressed, are then available to observers of the projects, and will show that “no-one else should build from source” has plenty of reasonable argument against. For that reason, it is IMO worth arguing – politely and reasonably – to attempt to convince each project. > We should be prepared to maintain patches ourselves. That's also true :-/ -- \ “For your convenience we recommend courteous, efficient | `\self-service.” —supermarket, Hong Kong | _o__) | Ben Finney -- 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] How to use Debian Buster for developing with Webpack
Pirate Praveen <prav...@onenetbeyond.org> writes: > On 2018, ജനുവരി 21 10:53:01 AM IST, Ben Finney <bign...@debian.org> wrote: > >What do I need from Debian Buster, in order to feed a bunch of > >JavaScript modules to Webpack? > > You just need webpack if your code is already es5. Which package(s) in Debian Buster? There is no ‘webpack’ package there. -- \“If you go parachuting, and your parachute doesn't open, and | `\you friends are all watching you fall, I think a funny gag | _o__) would be to pretend you were swimming.” —Jack Handey | Ben Finney -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] How to use Debian Buster for developing with Webpack
Howdy all, I am thoroughly confused by the current state of Webpack in Buster. What Debian Buster packages should I be installing, to get Webpack working on a code base? There are a number of packages in Buster that have ‘webpack’ in the name, but none of them seem to be Webpack itself. Is there such a thing? For setting up a web development environment, the internet is awash in instructions akin to “just run this command that will download stuff from arbitrary places for you to run”. Of course, I want to do it with Debian packages instead. So those instructions are only confusing to me, because they almost never spell out exactly what packages are in the dependency chain. What do I need from Debian Buster, in order to feed a bunch of JavaScript modules to Webpack? -- \ “Some people have a problem, and they think “I know, I'll use | `\ Perl!”. Now they have some number of problems but they're not | _o__) sure whether it's a string or an integer.” —Benno Rice, 2011 | Ben Finney -- 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#884913: node-gulp-babel: fails immediately because of undeclared dependency “babel-core”
Package: node-gulp-babel Version: 7.0.0-2 Severity: serious Justification: Policy 3.5 Attempting to run a Gulp build that uses ‘gulp-babel’ fails immediately: = module.js:327 throw err; ^ Error: Cannot find module 'babel-core' at Function.Module._resolveFilename (module.js:325:15) at Function.Module._load (module.js:276:25) at Module.require (module.js:353:17) at require (internal/module.js:12:17) at Object. (/usr/lib/nodejs/gulp-babel/index.js:7:15) at Module._compile (module.js:409:26) at Object.Module._extensions..js (module.js:416:10) at Module.load (module.js:343:32) at Function.Module._load (module.js:300:12) at Module.require (module.js:353:17) = The dependency ‘babel-core’ needs to be packaged in Debian, and then this package can declare a Depends relationship on that one. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages node-gulp-babel depends on: ii node-gulp-util 3.0.7-1 ii node-replace-ext 1.0.0-1 ii node-through22.0.3-1 ii node-vinyl-sourcemaps-apply 0.2.1-1 ii nodejs 4.8.4~dfsg-1 node-gulp-babel recommends no packages. node-gulp-babel suggests no packages. -- no debconf information -- \ “Some forms of reality are so horrible we refuse to face them, | `\ unless we are trapped into it by comedy. To label any subject | _o__)unsuitable for comedy is to admit defeat.” —Peter Sellers | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Bug#884901: RM: libjs-jquery-dotdotdot -- RoM; Upstream changed to non-free license
Howdy Sergio, Sergio Durigan Junior <sergi...@sergiodj.net> writes: > I had packaged this software because it is a dependency for pagure, > another package that I am working on. In the interest of removing > non-free dependencies from a Free Software project, I have also filed > a bug against upstream pagure asking the project to stop using the > "dotdotdot" library: > > https://pagure.io/pagure/issue/2844 > > Thank you in advance. While reading your account of the problem, I was struck by a number of actions that need to be done in response to the things you discovered. Each time, I read further in your message and saw you tell us you had already done them :-) Your message to the Pagure project was very helpful. Thank you for this analysis, and especially for taking care to do the necessary weeding to keep our software freedom. -- \ “Time flies like an arrow. Fruit flies like a banana.” —Groucho | `\ Marx | _o__) | Ben Finney -- 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] Grunt plugins not found by Grunt
Pirate Praveen <prav...@onenetbeyond.org> writes: > On 2017, ഡിസംബർ 1 4:08:53 PM IST, Ben Finney <bign...@debian.org> wrote: > >Ross Gammon <javascr...@the-gammons.net> writes: > > > >> This tripped me up too when packaging something that needed the > >> system-wide installed Tasks. > > > >So the Debian packages install the plug-ins, in such a way that it > >doesn't work by default with Debian-packaged ‘grunt’? > > No, grunt upstream does not support loading tasks from a global path > and plugin packages cannot fix this. Its against nodejs culture of > forcing local dependencies. That makes me very sad. I hope that sanity can be restored to NodeJS, but with such a fundamental breakage I don't see it any time soon. > This will have to be a feature we add to debian's grunt. It already > has some basic support and has scope for improvement. Thank you for explaining. -- \ “I'm beginning to think that life is just one long Yoko Ono | `\ album; no rhyme or reason, just a lot of incoherent shrieks and | _o__) then it's over.” —Ian Wolff | Ben Finney -- 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] Grunt plugins not found by Grunt
Ross Gammon <javascr...@the-gammons.net> writes: > This tripped me up too when packaging something that needed the > system-wide installed Tasks. So the Debian packages install the plug-ins, in such a way that it doesn't work by default with Debian-packaged ‘grunt’? That seems like a bug in packaging those Debian package. Which package – ‘grunt’ or the plug-in packages – should I report a Debian BTS bug for? -- \ “Creativity can be a social contribution, but only in so far as | `\ society is free to use the results.” —Richard M. Stallman | _o__) | Ben Finney -- 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#880705: libjs-extjs-doc: Section should be “doc”
Package: libjs-extjs-doc Version: 3.4.0+dfsg1-1 Severity: minor Dear Maintainer, The section “javascript” is for packages that install implementations of JavaScript or libraries. The package ‘libjs-extjs-doc’ installs primarily documentation, not executable programs or libraries. It should not be in the “javascript” section. Please set the field “Section: doc” on this package. Then, since the package is already in Debian with a different section, you need to submit a request to override the existing section <URL:https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file>. Mark that new bug report as blocked by this one, to indicate the reliance between them. -- \“If we ruin the Earth, there is no place else to go. This is | `\not a disposable world, and we are not yet able to re-engineer | _o__) other planets.” —Carl Sagan, _Cosmos_, 1980 | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Javascript policy and npm2deb
Pirate Praveen <prav...@onenetbeyond.org> writes: > In a recent bug report, I came across this disparity, > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877213#36 > > npm2deb creates source packages with node- prefix. I think the policy > should be updated to reflect this. What change to the policy do you suggest? -- \ “Skepticism is the highest duty and blind faith the one | `\ unpardonable sin.” —Thomas Henry Huxley, _Essays on | _o__) Controversial Questions_, 1889 | Ben Finney -- 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
Jérémy Lal <kapo...@melix.org> writes: > 2017-09-03 7:24 GMT+02:00 Ben Finney <bign...@debian.org>: > > > Yes, I am looking for a general way to turn an HTML-page app into a > > stand-alone desktop app. That does mean no location bar, no tabs, no > > history navigation, etc.; just rendering the one HTML page with its > > JavaScript and other resources. > > i'd rely on epiphany-browser for that kind of job. […] > > Anyway, to get started, you can open epiphany-browser (a.k.a. "Web"), > go to local file url, and from sandwich menu choose "install site as > application". You'll find the .desktop file in > ~/.local/share/applications. epiphany also has probably a command-line > switch to enable XHR from file:// url. That is very close to what I want, thank you. Now I need a way to go from the bundle of files that Epiphany creates, to something I can turn into a Debian package for general installation. -- \ “Simplicity and elegance are unpopular because they require | `\ hard work and discipline to achieve and education to be | _o__)appreciated.” —Edsger W. Dijkstra | Ben Finney -- 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
Paul Gevers <elb...@debian.org> writes: > Edbrowse is shifting to use duktape, maybe that is what you are > looking for? Thanks for the response. I see that Duktape <URL:http://duktape.org/> is “an embeddable Javascript engine”. I don't see how addresses the requirement: to open an HTML file in a window, running a single-page browser window as a desktop app. -- \ “[F]reedom of speech does not entail freedom to have your ideas | `\accepted by governments and incorporated into law and policy.” | _o__) —Russell Blackford, 2010-03-06 | Ben Finney -- 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
Jérémy Lal <kapo...@melix.org> writes: > - some browsers can run an application in "kiosk mode" - it runs the > app independently of any other already opened web page, usually > without omnibar and/or without menus. > > However i don't know if it's possible to benefit from xdg-open and > these browser specific cli options. That's a good point to raise. Yes, I am looking for a general way to turn an HTML-page app into a stand-alone desktop app. That does mean no location bar, no tabs, no history navigation, etc.; just rendering the one HTML page with its JavaScript and other resources. I think Mozilla's XULRunner would have done this, but it is reportedly obsolete upstream for years now. What is in Debian now that I should use instead? -- \ “Anyone who puts a small gloss on [a] fundamental technology, | `\ calls it proprietary, and then tries to keep others from | _o__) building on it, is a thief.” —Tim O'Reilly, 2000-01-25 | Ben Finney -- 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
Antonio Terceiro <terce...@debian.org> writes: > 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. Thank you for your efforts maintaining jQuery in Debian. Especially thank you for clearly noting that you are no longer maintainer for the package. -- \ “There is something wonderful in seeing a wrong-headed majority | `\ assailed by truth.” —John Kenneth Galbraith, 1989-07-28 | _o__) | Ben Finney -- 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
Jonas Smedegaard <jo...@jones.dk> writes: > Quoting Jérémy Lal (2017-08-23 09:27:54) > > 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. In the case of essentially graphical programs like the ones I'm thinking of (e.g. “MuscleBook”), a pixel-based graphical browser would be required. That means ‘xdg-open’ is better for this purpose. So I would make a package that “Depends: xdg-utils”, and install a simple ‘/usr/bin/musclebook’ shell script: #! /bin/sh exec xdg-open /usr/share/musclebook/index.html Would that be fragile in some way? Is there something I am overlooking? -- \ “It's my belief we developed language because of our deep inner | `\ need to complain.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney -- 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
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? -- \“But it is permissible to make a judgment after you have | `\examined the evidence. In some circles it is even encouraged.” | _o__)—Carl Sagan, _The Burden of Skepticism_, 1987 | Ben Finney -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] JavaScript in-browser program, packaged in Debian
Howdy all, 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. 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. Is that a reasonable expectation? Is there an existing convention for Debian JavaScript packages that are intended to install end-user local programs, that happen to be written in JavaScript for a browser? If this doesn't yet exist, how would we do this in Debian today? -- \ “You are welcome to visit the cemetery where famous Russian and | `\Soviet composers, artists, and writers are buried daily except | _o__) Thursday.” —Russian orthodox monastery, Moscow | Ben Finney -- 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#740893: Should we install bundled third-party ‘hotkeys’ library
(duplicating because I forgot to include the bug report address) Ryan Attard <frontrunner4...@gmail.com> writes: > I've been struggling with this bug, but I'm a little confused by this > bug report and the response from the maintainers. Thank you for asking to clarify. I agree that this bug report discussion can be difficult to follow. > The source package has these JS files under in coverage/htmlfiles > (with what I'm assuming is the compatible/tested version), why aren't > they shipped in the debian package? Because they aren't used. Why aren't they used? Because it is a violation of Debian policy to install third-party bundled libraries; instead, the libraries should each have their own first-class Debian made from the source for that library. You might want to read <URL:https://bugs.debian.org/848188> describing why the library dependency is removed from the ‘python-coverage’ package. > It makes no sense to me as a user to have a critical portion of > functionality broken by default I agree, and this is discussed in the bug tracker for Coverage.py <URL:https://bitbucket.org/ned/coveragepy/issues/474/>. > (because it doesn't hard-dep on libjs-jquery-hotkeys/related JS libs, > and you can't get line-by-line reports without it), and also to depend > on a library that is also incompatible and known incompatible. I don't quite understand what you're saying there. There are incompatible libraries both claiming the “hotkeys” name, but that's already known here. > Can't you just drop the libjs* recommends and install the stuff in the > source package onto the target system? Definitely not; bundling a third-party library, especially when that is just a slightly modified version of an existing packaged library, is a violation of policy and makes security updates needlessly difficult. -- \ “Two paradoxes are better than one; they may even suggest a | `\ solution.” —Edward Teller | _o__) | Ben Finney signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Bug#740893: Patch for python-coverage bug #740893
Ryan Attard <frontrunner4...@gmail.com> writes: > I've been struggling with this bug, but I'm a little confused by this > bug report and the response from the maintainers. Thank you for asking to clarify. I agree that this bug report discussion can be difficult to follow. > The source package has these JS files under in coverage/htmlfiles > (with what I'm assuming is the compatible/tested version), why aren't > they shipped in the debian package? Because they aren't used. Why aren't they used? Because it is a violation of Debian policy to install third-party bundled libraries; instead, the libraries should each have their own first-class Debian made from the source for that library. You might want to read <URL:https://bugs.debian.org/848188> describing why the library dependency is removed from the ‘python-coverage’ package. > It makes no sense to me as a user to have a critical portion of > functionality broken by default I agree, and this is discussed in the bug tracker for Coverage.py <URL:https://bitbucket.org/ned/coveragepy/issues/474/>. > (because it doesn't hard-dep on libjs-jquery-hotkeys/related JS libs, > and you can't get line-by-line reports without it), and also to depend > on a library that is also incompatible and known incompatible. I don't quite understand what you're saying there. There are incompatible libraries both claiming the “hotkeys” name, but that's already known here. > Can't you just drop the libjs* recommends and install the stuff in the > source package onto the target system? Definitely not; bundling a third-party library, especially when that is just a slightly modified version of an existing packaged library, is a violation of policy and makes security updates needlessly difficult. -- \ “Two paradoxes are better than one; they may even suggest a | `\ solution.” —Edward Teller | _o__) | Ben Finney -- 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
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. 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? -- \ “Only good questions deserve good answers.” —Oscar Wilde, _De | `\ Profundis_, 1897 | _o__) | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#740893: libjs-jquery-hotkeys: Incompatible ABI change
Control: unblock 848188 by 740893 Control: summary 848188 0 Until the ‘libjs-jquery-hotkeys’ package resolves bug#740893, the ‘python-coverage’ packages should not use that library. I will patch the ‘python-coverage’ source so it omits any use of that library. On 06-Apr-2017, Philipp Hahn wrote: > <https://github.com/tzuryby/jquery.hotkeys/commit/321e02b98be973d1ea09eb97ceb921411ffb3415> > introduced an incompatible ABI change how events are registered: Thanks again for the analysis, I hope this package can be fixed for its dependents. -- \ “The trouble with the rat race is that even if you win, you're | `\ still a rat.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Bug#863255: Please rename/provide libjs-jquery-atwho
On 24-May-2017, Pirate Praveen wrote: > Also consider providing node-at.js as I may need it for new version > of gitlab (9.x) which depends on all node modules and uses webpack > directly (instead of depending on libjs packages). This library seems only useful in an interactive browser session. It seems quite misleading to declare that it provides a library for non-interactive Node. What would justify that declaration? -- \“I got food poisoning today. I don't know when I'll use it.” | `\—Steven Wright | _o__) | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#740893: Patch for python-coverage bug #740893
On 23-May-2017, Eevel Weezel wrote: > I'm attaching a patch. This will remove the bundled version of the js > libraries, allowing python-coverage to use the system libraries. Thank you for the patch. Is that needed, though? The package already omits those files from the HTML report, via an existing patch <URL:https://sources.debian.net/src/python-coverage/4.2%2Bdfsg.1-2/debian/patches/01.omit-resource-files-from-distutils-setup.patch/>. Also, I think this bug report is asking that the system libraries should be different. > Heather (Could you change your “From” field on your outgoing messages, so they have your name? Thanks!) -- \ “Philosophy is questions that may never be answered. Religion | `\ is answers that may never be questioned.” —anonymous | _o__) | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#740893: libjs-jquery-hotkeys: Incompatible ABI change
On 06-Apr-2017, Philipp Hahn wrote: > today I spent some time on investigating this issue Thank you! > <https://github.com/tzuryby/jquery.hotkeys/commit/321e02b98be973d1ea09eb97ceb921411ffb3415> > introduced an incompatible ABI change how events are registered: So the <URL:https://github.com/jeresig/jquery.hotkeys> and the <URL:https://github.com/tzuryby/jquery.hotkeys> repositories have diverged, incompatibly. I didn't know that :-/ > So "coverage_html.js" uses the 'jeresig' API to pass the hotkey via > "data", while the 'tzuryby' API "jquery.hotkeys.js" expects is via > 'namespace'. That's good investigation, thank you for that. > libjs-jquery-hotkeys currently is used by 3 packages in Debian: > - libghc-gitit-data > - prometheus > - python-pytest-cov I count 6 binary packages: = $ apt-cache rdepends libjs-jquery-hotkeys libjs-jquery-hotkeys Reverse Depends: libghc-gitit-data python3-pytest-cov python-pytest-cov python3-coverage python-coverage prometheus = The source packages are: * gitit * python-coverage * python-pytest-cov * prometheus Why are we getting different sets of packages that use ‘libjs-jquery-hotkeys’? > Doing some source code `grep -n -r "[.]bind([\"']key"`: When I use the pattern ‘[.]bind\(["']key’ for each of those source packages with <URL:https://codesearch.debian.net/>, I get a different set. These queries show matches: <URL:https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Agitit> <URL:https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Apython-coverage> <URL:https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Aprometheus> This does not: <URL:https://codesearch.debian.net/search?q=[.]bind\%28[%22%27]key+package%3Apython-pytest-cov> Does that mean ‘python-pytest-cov’ is not using the ‘jeresig’ API? Is there a better regex pattern to use to determine what API is used? > So all of them use the "jeresig" API, but 'libjs-jquery-hotkeys' > packages the "tzuryby" API. We get differing results, so I'd like to better understand before choosing how to resolve this. -- \ “How many people here have telekenetic powers? Raise my hand.” | `\ —Emo Philips | _o__) | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#854675: npm2deb: template for ITP should strongly encourage writing a proper package description
On 09-Feb-2017, Praveen Arimbrathodiyil wrote:
> Add one more paragraph and sent a pull request upstream. Once
> they review and merge, I will upload a new version.
On 09-Feb-2017, Praveen Arimbrathodiyil wrote:
> Can you try to update control file template too as suggested by
> Shanavas?
Okay, I have made some more extensive changes:
* Distinguish the upstream description versus the Debian package
description, in both the ‘debian/control’ template and the ITP
template.
* Add paragraphs to the ITP template suggesting explanations that are
commonly needed.
These are attached to this message as patches.
--
\ “I like to go to art museums and name the untitled paintings. |
`\‘Boy With Pail’. ‘Kitten On Fire’.” —Steven Wright |
_o__) |
Ben Finney <bign...@debian.org>
From 03cd5adac01c51077cff3edacad1fc9f4ee562c3 Mon Sep 17 00:00:00 2001
From: Ben Finney <bign...@debian.org>
Date: Fri, 10 Feb 2017 04:37:45 +1100
Subject: [PATCH 1/2] Distinguish upstream description from Debian package
description.
---
npm2deb/__init__.py | 13 +++--
npm2deb/templates.py | 27 ++-
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index 0ac807bb..1aa9ad28 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -29,7 +29,7 @@ class Npm2Deb(object):
self.json = None
self.args = args
self.homepage = None
-self.description = None
+self.upstream_description = None
self.upstream_author = None
self.upstream_license = None
self.upstream_version = None
@@ -295,8 +295,8 @@ and may not include tests.\n""")
% self.debian_name
args['Package'] = self.debian_name
args['Depends'] = self._get_Depends()
-args['Description'] = self.description
-args['Description_Long'] = 'FIX_ME long description'
+args['Description'] = 'FIX_ME write the Debian package description'
+args['upstream_description'] = self.upstream_description
template = utils.get_template('control')
utils.create_debian_file('control', template % args)
@@ -451,7 +451,8 @@ and may not include tests.\n""")
args['debian_name'] = self.debian_name
args['upstream_author'] = self.upstream_author
args['homepage'] = self.homepage
-args['description'] = self.description
+args['description'] = 'FIX_ME write the Debian package description'
+args['upstream_description'] = self.upstream_description
args['version'] = self.upstream_version
args['license'] = self.upstream_license
content = utils.get_template('wnpp')
@@ -485,9 +486,9 @@ and may not include tests.\n""")
def _get_json_description(self):
if 'description' in self.json:
-self.description = self.json['description']
+self.upstream_description = self.json['description']
else:
-self.description = 'FIX_ME description'
+self.upstream_description = 'FIX_ME no upstream package description'
def _get_json_author(self):
if self.upstream_author:
diff --git a/npm2deb/templates.py b/npm2deb/templates.py
index 9bda4ee3..f88861e6 100644
--- a/npm2deb/templates.py
+++ b/npm2deb/templates.py
@@ -6,6 +6,20 @@ CHANGELOG = """%(debian_name)s (%(version)s-1) UNRELEASED; urgency=low
"""
+description_template = """
+ Write the short and long descriptions for the Debian package as
+ explained in the Developer's Reference, §6.2.1 – §6.2.3.
+ .
+ You can start with the short upstream package description,
+ “%(upstream_description)s”.
+ .
+ Be aware that most upstream package descriptions are not written to
+ conform with Debian package guidelines. You need to explain the role
+ of this package for a Debian audience.
+ .
+ Node.js is an event-based server-side JavaScript engine.
+"""
+
CONTROL = """Source: %(Source)s
Section: web
Priority: optional
@@ -26,10 +40,7 @@ Depends:
${misc:Depends}
, %(Depends)s
Description: %(Description)s
- %(Description_Long)s
- .
- Node.js is an event-based server-side JavaScript engine.
-"""
+""" + description_template
RULES = """#!/usr/bin/make -f
# -*- makefile -*-
@@ -80,11 +91,9 @@ X-Debbugs-CC: debian-de...@lists.debian.org
Programming Lang: JavaScript
Description : %(description)s
- FIX_ME bug long description
- .
- Node.js is an event-based server-side JavaScript engine.
-
-"""
+ FIX_ME: This ITP report is not ready for submission, until you are
+ confident this package description is ready for Debian.
+ .""" + description_template
LICENSES = {}
--
[Pkg-javascript-devel] Bug#854675: npm2deb: template for ITP should strongly encourage writing a proper package description
Package: npm2deb Version: 0.2.6-1 Severity: normal Tags: patch The ‘npm2deb’ tool can automatically generate an ITP report. One field that it automatically generates is the package description. This unfortunately makes it very easy to submit *bad* ITP reports, with package descriptions that are quite unsuitable for Debian ITPs. Please make the ITP template produce a document that strongly encourages the maintainer to manually edit the description, to meet Developer's Reference guidelines in §6.2.1 – §6.2.3. Attached is my suggested patch for this. -- \ “For man, as for flower and beast and bird, the supreme triumph | `\ is to be most vividly, most perfectly alive” —D.H. Lawrence | _o__) | Ben Finney <bign...@debian.org> diff --git i/npm2deb/templates.py w/npm2deb/templates.py index 9bda4ee3..a3a06f7a 100644 --- i/npm2deb/templates.py +++ w/npm2deb/templates.py @@ -78,9 +78,18 @@ X-Debbugs-CC: debian-de...@lists.debian.org * URL : %(homepage)s * License : %(license)s Programming Lang: JavaScript - Description : %(description)s + Description : FIX_ME write the Debian package description - FIX_ME bug long description + FIX_ME: Write the description for the Debian package according to the + Developer's Reference, §6.2.1 – §6.2.3. + . + This ITP report should not be submitted until you are confident the + package description is ready for Debian. + . + You can start with the upstream package description, + “%(description)s”. + Be aware that many upstream package descriptions do not meet + Debian package guidelines. . Node.js is an event-based server-side JavaScript engine. signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] What tool is automating ITP reports?
shana...@disroot.org writes: > npm2deb automates packaging of npm modules and ITP composition using > information from npm registry. Thank you. Do you know if there is some social group that is encouraging sending ITP reports, without editing them to describe the package properly? Is there a group that is being encouraged to “just use the output of ‘npm2deb’ and send that”? -- \ “Friendship is born at that moment when one person says to | `\another, ‘What! You too? I thought I was the only one!’” —C.S. | _o__)Lewis | Ben Finney -- 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] What tool is automating ITP reports?
Howdy all, Many recent ITP reports for Node.js packages have had terrible descriptions. They seem to be just copied from the NPM package description with no regard for the conventions of a Debian package description. ITPs should not be submitted automatically, they should be composed as an individual's communication to the whole Debian Project. With bad reports, the reputation of the submitter is tarnished, and the ability of the Debian community to understand what people's intentions are is harmed. Is there some tool that people have been recommending that automates the ITP composition and sending process? What is it, and how can we correct it? -- \ “Money is always to be found when men are to be sent to the | `\ frontiers to be destroyed: when the object is to preserve them, | _o__) it is no longer so.” —Voltaire, _Dictionnaire Philosophique_ | Ben Finney -- 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] Bug#854246: ITP: node-buffer-xor -- A simple module for bitwise-xor on buffers
Ravishankar Purne <ravismai...@gmail.com> writes: > Description : A simple module for bitwise-xor on buffers This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, you are communicating to the Debian Project. Please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. Ravishankar, please don't file any more ITPs unless you know the work well enough to write a Debian package description for it. If you can't write your own description of the work to explain it, you probably are not ready to begin packaging it. -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney <bign...@debian.org> -- 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] Bug#854275: ITP: node-path-platform -- Provide access to win32 and posix path operations; sourced directly from upstream Node.js
Ravishankar Purne <ravismai...@gmail.com> writes: > Description : Provide access to win32 and posix path operations; > sourced directly from upstream Node.js This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, you are communicating to the Debian Project. Please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. Ravishankar, please don't file any more ITPs unless you know the work well enough to write a Debian package description for it. If you can't write your own description of the work to explain it, you probably are not ready to begin packaging it. -- \ “A free society is one where it is safe to be unpopular.” | `\—Adlai Ewing Stevenson | _o__) | Ben Finney <bign...@debian.org> -- 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] Bug#854267: ITP: node-os-browserify -- The [os](https://nodejs.org/api/os.html) module from node.js, but for browsers.
Ravishankar Purne <ravismai...@gmail.com> writes: > Description : The [os](https://nodejs.org/api/os.html) module from > node.js, but for browsers. This is not a suitable noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, you are communicating to the Debian Project. Please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. Ravishankar, please don't file any more ITPs unless you know the work well enough to write a Debian package description for it. If you can't write your own description of the work to explain it, you probably are not ready to begin packaging it. -- \“Like the creators of sitcoms or junk food or package tours, | `\ Java's designers were consciously designing a product for | _o__) people not as smart as them.” —Paul Graham | Ben Finney <bign...@debian.org> -- 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] Bug#854265: ITP: node-array-filter -- Array#filter for older browsers.
Ravishankar Purne <ravismai...@gmail.com> writes: > Description : Array#filter for older browsers. Iterates over the > elements in an array, returning an array with only the elements for which > the callback returns truthy. This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, you are communicating to the Debian Project. Please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. Ravishankar, please don't file any more ITPs unless you know the work well enough to write a Debian package description for it. If you can't write your own description of the work to explain it, you probably are not ready to begin packaging it. -- \ “When I turned two I was really anxious, because I'd doubled my | `\ age in a year. I thought, if this keeps up, by the time I'm six | _o__) I'll be ninety.” —Steven Wright | Ben Finney <bign...@debian.org> -- 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] Bug#854121: ITP: node-p-limit -- Run multiple promise-returning & async functions with limited concurrency
nikhil gawande <nikhilgawand...@gmail.com> writes: > Description : Run multiple promise-returning & async functions with > limited concurrency > . This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, you are communicating to the Debian project. Please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. -- \“The industrial system is profoundly dependent on commercial | `\ television and could not exist in its present form without it.” | _o__)—John Kenneth Galbraith, _The New Industrial State_, 1967 | Ben Finney <bign...@debian.org> -- 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] Bug#854119: sub...@bugs.debian.org
Aarti Kashyap <kaarti...@gmail.com> writes: > Description : Write a package.json file This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, you are communicating to the Debian project. Please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney <bign...@debian.org> -- 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] Bug#854067: ITP : node-prepend-http -- Prepend `http://` to humanized URLs like todomvc.com and localhost
Shirish Togarla <shirishtogarla...@gmail.com> writes: > Description : Prepend `http://` to humanized URLs like todomvc.com > and localhost This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney <bign...@debian.org> -- 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] Bug#854018: ITP : node-is-npm -- Check if your code is running as an npm script
Shirish Togarla <shirishtogarla...@gmail.com> writes: > Description : Check if your code is running as an npm script This is not written as a noun phrase describing the package. Also, there is no longer description to give enough information to the reader. When writing the ITP, please take the time to write a proper package description. See the Debian Developer's Reference, §6.2.1 – 6.2.3. Please note that it is often a mistake to copy the text from the upstream work. Write the description of the Debian package to meet Debian's guidelines. -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney <bign...@debian.org> -- 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
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. 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? -- \ “The aim of science is not to open the door to infinite wisdom, | `\but to set some limit on infinite error.” —Bertolt Brecht, | _o__)_Leben des Galilei_, 1938 | Ben Finney -- 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#849896: libjs-yui3: please add dependency “Suggests: libjs-yui3-doc”
Source: yui3 Version: 3.5.1-1 Severity: minor Dear Maintainer, Working with the ‘yui3’ packages requires understanding how it works and what it does. Please set a “Suggests: libjs-yui3-doc” dependency to the binary package ‘libjs-yui3-common’, or other binary packages for which it is appropriate. This will present the suggestion to administrators choosing which packages to install. -- \ “Give a man a fish, and you'll feed him for a day; give him a | `\religion, and he'll starve to death while praying for a fish.” | _o__) —Anonymous | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#847643: node-uglify: help output does not usefully describe the command
Package: node-uglify Version: 2.7.4-1 Severity: normal The ‘uglifyjs --help’ output is not helpful for learning to use the command: $ uglifyjs --help [object Object] Conventionally that should produce a usage message that tells the reader what the command does, and all the ways to invoke the program, with descriptions of all possible arbuments and options. $ uglifyjs --help Usage: uglifyjs --foo --bar COLOR --baz INFILE OUTFILE Obfuscate the infile to the outfile with a snargle snorgle. INFILE The input file to obfuscate. OUTFILE The obfuscated output. Options: --foo Obfuscate upside down. --bar COLOR Turn the output to COLOR. (default: green) --baz Hum gently while working. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages node-uglify depends on: ii node-async 0.8.0-1 ii node-yargs 6.4.0-2 ii nodejs 4.6.1~dfsg-1 Versions of packages node-uglify recommends: ii node-source-map 0.5.6+dfsg-1 Versions of packages node-uglify suggests: pn node-uglify-to-browserify -- no debconf information -- \ “It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__)will play itself.” —Johann Sebastian Bach | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#847642: node-uglify: manual page ‘uglifyjs?=(1)=?UTF-8?Q?’ lacks important information for all document sections
Package: node-uglify Version: 2.7.4-1 Severity: normal The command ‘uglifyjs’ has a manual page ‘uglifyjs(1)’ that does not helpfully describe the command: NAME uglify-js - manual page for uglify-js 2.7.5 DESCRIPTION [object Object] The manual page should have the sections described ‘man-pages(7)’ § “Sections within a manual page”, with the content as described in that document. -- \ “Following fashion and the status quo is easy. Thinking about | `\your users' lives and creating something practical is much | _o__)harder.” —Ryan Singer, 2008-07-09 | Ben Finney <bign...@debian.org> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] jquery 3.x uploaded to unstable
Antonio Terceiro <terce...@debian.org> writes: > To those who care about jquery: I have just uploaded jquery 3.1.1-1 to > unstable. Thank you to everyone who worked to bring this important update to Debian! -- \ “Guaranteed to work throughout its useful life.” —packaging for | `\ clockwork toy, Hong Kong | _o__) | Ben Finney -- 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] Clean room implementation of JavaScript compiler
Ben Finney <ben+deb...@benfinney.id.au> writes: > Perhaps not a complete re-implementation of Grunt. But there is a > clear desire for a JavaScript compiler: a program that takes several > input JavaScript files, and compiles them to a single generated file. > > Can we come up with a specification of that job, sufficient to package > in Debian for use where upstream packages use Grunt to “browserify” > libraries? Here is a dialogue exploring the “why use Grunt?” issue <URL:https://stackoverflow.com/questions/29190910/what-is-grunt-for>. The respondent gives enthusiastic advocacy, which may or may not be warranted; either way, it should be helpful to know what its advocates believe it should be used for. There are many JavaScript source distributions that are presently difficult to package because of their reliance on Grunt features, and Grunt is not in Debian. What features do we need in a tool, available in the Debian archives, that would allow much easier packaging of those JavaScript distributions? -- \ “On the internet you simply can't outsource parenting.” —Eliza | `\ Cussen, _Top 10 Internet Filter Lies_, The Punch, 2010-03-25 | _o__) | Ben Finney -- 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#832237: Bug#832237: libjs-mousetrap: Section should not be “ruby”
On 25-Jul-2016, Alexandre Viau wrote: > I wonder where the issue is from? I can confirm that the section > shows as ruby by running apt-get show. I don't know an ‘apt-get show’ command, that gives an error. Both ‘aptitude show’ and ‘apt show’ report that the section is “ruby”. > Perhaps a bit more history is needed to understand the issue. > libjs-mousetrap was originally shipped by another source package > (ruby-mousetrap-rails), which I had hijacked inadvertently. Yes, you will need to request an override in the archive. See the first message in this bug report. -- \ “Holy rising hemlines, Batman!” —Robin | `\ | _o__) | Ben Finney <b...@benfinney.id.au> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Clean room implementation of JavaScript compiler (was: Bug#830978: Browserified javascript and DFSG 2)
On 19-Jul-2016, Don Armstrong wrote: > And now that enough people have read [the bug discussing whether > compiled JavaScript is source], we probably could have > re-implemented grunt by now and solved the libjs-handlebars problem. Perhaps not a complete re-implementation of Grunt. But there is a clear desire for a JavaScript compiler: a program that takes several input JavaScript files, and compiles them to a single generated file. Can we come up with a specification of that job, sufficient to package in Debian for use where upstream packages use Grunt to “browserify” libraries? Ideally it should not be based on Grunt source, so that it's clear to implement just this tool without entanglement of existing programs not yet in Debian. -- \“Institutions will try to preserve the problem to which they | `\ are the solution.” —Clay Shirky, 2012 | _o__) | Ben Finney <b...@benfinney.id.au> signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#817092: libjs-handlebars: source package distributes files whose source is not in Debian
Control: reassign -1 src:libjs-handlebars Control: retitle -1 libjs-handlebars: source package contains files whose source is not in Debian On 10-Jul-2016, Pirate Praveen wrote: > This is not a minified file, only browserified. Since neither of those terms is particularly meaningful for the bug report, and the difference is not relevant to the actual issue, I'm retitling to accurately state what the bug is. The source package distributes files whose source form is not in Debian. Those files may not be in Debian without the source form of the work also being in a Debian source package; and all the build tools and scripts to generate the compiled form also needs to be in Debian. > When node-grunt is available in the archive, we can consider > browserifying. That sounds good. Until then, the non-source files need to be removed from the source package. -- \“Kill myself? Killing myself is the last thing I'd ever do.” | `\—Homer, _The Simpsons_ | _o__) | Ben Finney <b...@benfinney.id.au> signature.asc Description: PGP signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Small binary packages
Ben Finney ben+deb...@benfinney.id.au writes: What are the proposals to package small libraries of JavaScript code? Looking through the archive, I get the impression that one approach which could work is to collect multiple separate works by some related theme, and distribute some smaller number of larger, aggregate binary packages. Examples include the packages ‘emacs-goodies-el’ and ‘devscripts’: these pacakges don't go to special effort to integrate the code, they just bundle them together for ease of packaging and maintenance. Would that be feasible for small JavaScript libraries? Surely many of them can be grouped together by some common theme, and maintained as aggregate Debian packages. -- \“Intellectual property is to the 21st century what the slave | `\ trade was to the 16th.” —David Mertz | _o__) | Ben Finney ___ 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] Small binary packages (was: node-absolute-path_0.0.0-1_amd64.changes REJECTED)
Sebastiaan Couwenberg sebas...@debian.org writes: Since we don't have an acceptable solution for bundling these small Node.js packages, I won't be able to complete the OpenLayers 3 packaging. Thanks for expressing that. I'm sorry to learn that policy is a barrier to your packaging work. What are the proposals to package small libraries of JavaScript code? Have the FTP masters published suggested approaches that won't fall afoul of the “no small binary package” criterion? -- \“I always had a repulsive need to be something more than | `\ human.” —David Bowie | _o__) | Ben Finney ___ 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#787051: libjs-rickshaw: Documentation references nonexistent files
Package: libjs-rickshaw Version: 1.5.1.dfsg-1 Severity: normal Dear Maintainer, The documentation file ‘examples/index.html’ references a series of images, only some of which exist. The HTML references images files, but not all of them exist: $ (cd /usr/share/doc/libjs-rickshaw/examples/ \ grep 'img\' index.html \ | sed -e 's;^.*src=\([^]\+\).*$;\1;' \ | sort | xargs ls -1 ) ls: cannot access screenshots/fixed.png: No such file or directory ls: cannot access screenshots/formatter.png: No such file or directory ls: cannot access screenshots/hover.png: No such file or directory ls: cannot access screenshots/multi.png: No such file or directory ls: cannot access screenshots/x_axis.png: No such file or directory screenshots/ajax.png screenshots/colors.png screenshots/extensions.png screenshots/lines.png screenshots/logscale.png screenshots/scaled.png screenshots/scatterplot.png screenshots/start.png screenshots/status.png screenshots/stops.png screenshots/y_axis.png This results in errors rendering the page. There may be other missing image files referenced from other pages in the docs, but I have not checked. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (200, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libjs-rickshaw depends on: ii libjs-d3 3.5.3-1 Versions of packages libjs-rickshaw recommends: ii javascript-common 11 libjs-rickshaw suggests no packages. -- no debconf information -- \ “I was sad because I had no shoes, until I met a man who had no | `\ feet. So I said, ‘Got any shoes you're not using?’” —Steven | _o__) Wright | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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#773072: libjs-autonumeric: Please install upstream documentation
package libjs-autonumeric retitle 773072 libjs-autonumeric: Please install upstream documentation severity 773072 wishlist thanks On 13-Dec-2014, Adam Majer wrote: Please, include the documentation in the javascript package - it's on the upstream website as readme.md. It would be nice if you provided those examples on their website too. In which case, the severity of this bug report is “wishlist”. I'm changing the severity accordingly. PS. I've set priority as important on purpose. Without documentation, this library is difficult to use - you have to read the source code to know what it is trying to do. The usability of the package is not affected by the absence of the documentation *on Debian*, since it can just as easily be used by getting the documentation from elsewhere. The severity levels have definitions in Debian. For “important”, the package needs to be significantly impacted for its usability as is. This clearly does not cover “lacks documentation”. This report is valid, but it is “wishlist” severity. If other javascript packages lack basic documentation, please add it to them too! Please report “wishlist”-severity bugs against each of those packages separately. They do not affect this bug report, which applies only to a single package. -- \ “A thing moderately good is not so good as it ought to be. | `\Moderation in temper is always a virtue; but moderation in | _o__) principle is always a vice.” —Thomas Paine | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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 trigger design
Thomas Goirand z...@debian.org writes: Web application have evolved into monsters that needs lots of javascript. It's very common that these javascript applications are collecting all the .js library they use, concatenate them into a single file, and compress the result using all sorts of tools (node uglify is one of the implementation, but that's not the only one). My understanding is that the Debian JavaScript team is converging on a standard for compiling JavaScript (using uglify, I think) as a routine part of JS library package installation. How far along is such a rmalisation of convention? Is there a document yet discussing our consensus on JS compilation? As much as possible, as good Debian citizens, we do package each and every javascript library into a separate package. But then, if there's an update of that JS library, the Web application package has to somehow know about it, and redo the concatenate compress job. Otherwise, the web app would continue to use the old version. An alternative is that we standardise on *not* concatenating all the libraries together, but compile them so they're separate and modular. Would that be acceptable? -- \ “We suffer primarily not from our vices or our weaknesses, but | `\from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 | _o__) | Ben Finney ___ 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#755547: libjs-extjs: Please add dependency “Suggests: libjs-extjs-doc”
Source: libjs-extjs Severity: minor Developing with ExtJS requires understanding how it works and what it does. Please set a “Suggests: libjs-extjs-doc” dependency, so that administrators choosing to install ‘libjs-extjs’ will receive the suggestion. -- \ “Faith, n. Belief without evidence in what is told by one who | `\ speaks without knowledge, of things without parallel.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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#747032: RFS: libjs-zxcvbn/1.0+dfsg.1-1
Package: sponsorship-requests Severity: wishlist Control: tags 726171 + pending Control: block 726171 by -1 I am looking for a sponsor for my package ‘libjs-zxcvbn’: Package name: libjs-zxcvbn Version : 1.0+dfsg.1-1 Upstream Author : Dan Wheeler d...@dropbox.com URL : https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/ License : Expat Section : web It builds these binary packages: libjs-zxcvbn - realistic password strength estimation — JavaScript library You can get the package with ‘dget’: $ dget -x http://mentors.debian.net/debian/pool/main/l/libjs-zxcvbn/libjs-zxcvbn_1.0+dfsg.1-1.dsc More information about ‘zxcvbn’ can be obtained from URL:https://mentors.debian.net/package/libjs-zxcvbn and in the ITP bug report URL:http://bugs.debian.org/726171. -- \“Spam will be a thing of the past in two years' time.” —Bill | `\ Gates, 2004-01-24 | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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 policy?
François-Régis f...@miradou.com writes: As initiator of the thread, I may recall that the question we ask is Should we remove from source tarball minified versions of source files existing in tarball. An outcome of the thread is to show that the original question is ill-posed, because it hides some important assumptions. Those assumptions are now evident, and important questions come from them: * How do we know – and demonstrate to anyone who asks – the truth of the assertion that the source is actually the corresponding source of the exact non-source file? My answer to this is: Currently, we don't know that at all. We take upstream's word for it, though upstream frequently has no incentive to guarantee that to us and can easily make mistakes in ensuring it. * How do we maximise the certainty that what we ship in the source package has no files without corresponding source? My answer to this is: 100% certainty can be achieved by automatically omitting the non-source files from the Debian source package. * How do we maximise the certainty that what we ship in *every future version* of the source package has no files without corresponding source? My answer to this is: Again, 100% certainty can be achieved by automatically omitting the non-source files every time from every Debian release of the source package. * The Debian Social Contract obliges us to provide corresponding source for every file in Debian. Should we rate the promise so unimportant that we risk shipping a file without corresponding source? My answer to this is: No, we should do what we can to meet that obligation, and guarantee it to our recipients in a manner that they can independently verify. Whatever your answers to these questions are, I hope you can understand that they are necessary to provide context to the question you would like answered. -- \ “Let others praise ancient times; I am glad I was born in | `\ these.” —Ovid (43 BCE–18 CE) | _o__) | Ben Finney ___ 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?
François-Régis f...@miradou.com writes: Hi Ben, Le 31/03/2014 00:03, Ben Finney a écrit : * How do we know – and demonstrate to anyone who asks – the truth of the assertion that the source is actually the corresponding source of the exact non-source file? Before asking how do we know, we should ask do we need to know (and this in fact the question of the thread). You're asserting that there is some set of works received from upstream where: * (for example) ‘foo.js’ and ‘foo.min.js’ are distributed together; and * the Debian maintainer claims ‘foo.js’ in the source package is the corresponding source for ‘foo.min.js’ in the source package, thereby satisfying the Social Contract requirement to provide the source for every work in Debian. Yes? (If you're not claiming there is such a set of works, then I don't see the point of discussing what to do about them. So I'll continue on the assumption that you claim there really *are* some such works to which the discussion applies.) In order for the Debian package maintainer to claim that file ‘foo.js’ is the corresponding source for the non-source file ‘foo.min.js’, we should require that the claim is true about those specific files. That seems to make it clear that the question quoted above – “how do we know?” – is prior to the question you're posing – “based on that knowledge, what should we do?”. Or are you saying that it's acceptable for a Debian package maintainer to make a claim about the freedoms of the source package's recipient, without a sound reason for claiming it? My answer to this is: Currently, we don't know that at all. We take upstream's word for it, though upstream frequently has no incentive to guarantee that to us and can easily make mistakes in ensuring it. You're right so we take care to which is pristine upstream and which is provided in binary package. And people using debian source packages outside debian should take care of it, but can check that upsream tarball is the same as debian tarball. That's an entirely separate question: whether what Debian provides is the same file as provided by upstream. That question is not at issue. What is at issue is whether *what upstream provides* is actually corresponding source for a non-source file. Whether, for example, the file ‘foo.js’ is the corresponding source for ‘foo.min.js’. The fact that upstream provided both of them is no help in determining the answer to that question. So the provenance of a file, while important for other questions, is of no help in answering the question at issue here. The question here is to accept minified versions of files that have sources in orig tarball, Before that question even makes sense, a necessary prior question is: *Is it true* the sources for those minified files are actually in the orig tarball, and *how* does any recipient verifiably know that? I just try to have responses to the question I've adressed Should we remove from source tarball minified versions of source files existing in tarball. The response may depends on context but please deatails which kind of contest. I hope this makes it clearer. -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney ___ 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?
Ben Finney ben+deb...@benfinney.id.au writes: There is a method for [ensuring that every Debian release of the source package ships no files without corresponding source]: Don't distribute the minified file from upstream; instead, distribute only the source form of the work, and compile a minified file during the build of the binary package. What other method do you propose for keeping our promise in the Social Contract? Does it meet that promise with as much certainty as the method I propose above? Emilien Klein emilien+deb...@klein.st writes: 2014-03-28 0:28 GMT+01:00 Ben Finney ben+deb...@benfinney.id.au: Emilien Klein emilien+deb...@klein.st writes: Let's take the example of jquery-lazyload [0]. Both these files are provided in the upstream tarball: - jquery.lazyload.js - jquery.lazyload.min.js With the second one being the minified form of the first one. How will you guarantee that ‘jquery.lazyload.js’ is the corresponding source for the file ‘jquery.lazyload.min.js’? How will you guarantee that holds true every time a new version is released upstream? As we can't make sure we're minimizing the file exactly the same way upstream does, would comparing doubly-minified files work (I need to try, but no suitable computer had hand just now): […] Validation check: If File D and File E are equal, then we can assure file B was minified from file A by upstream. I'll try this out for lazyload and report back. Should the check fail, the package does not build (and then we repackage). Recheck by next package to see if repackageing is still necessary. This is significantly more complex and more prone to false positives, than simply dropping the non-source files from the source package, as I propose. I feel there is more value in shipping the upstream tarball (if we can assure the minified file comes from the supplied source), as repackaging is an extra step that could theoretically go wrong. I think you're engaging in wishful thinking. The process you propose has more steps to go wrong, and more points of potential error, than simply dropping the non-source files from the source package. -- \ “If nature has made any one thing less susceptible than all | `\others of exclusive property, it is the action of the thinking | _o__) power called an idea” —Thomas Jefferson | Ben Finney ___ 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?
Emilien Klein emilien+deb...@klein.st writes: Let's take the example of jquery-lazyload [0]. Both these files are provided in the upstream tarball: - jquery.lazyload.js - jquery.lazyload.min.js With the second one being the minified form of the first one. How will you guarantee that ‘jquery.lazyload.js’ is the corresponding source for the file ‘jquery.lazyload.min.js’? How will you guarantee that holds true every time a new version is released upstream? There is a method for doing so: Don't distribute the minified file from upstream; instead, distribute only the source form of the work, and compile a minified file during the build of the binary package. What other method do you propose for keeping our promise in the Social Contract? Does it meet that promise with as much certainty as the method I propose above? We've got an implicit statement from upstream that the minified file comes from the source file: This implicit statement can be false; if not by malice, then by simple omission or other mistake. So it is less reliable than removing the non-source form of the work from our source package. To take another example: .jpg images. - those are not the source of the image (would be e.g. a Gimp project file) In many cases, JPEG *is* the preferred form for modifying a work. For example: when no other form exists. If (as we do for .jpg) we accept non-source files based on their licensing information, and even use them as such in the binary package, I don't see how worse it would be to leave a minified file (which has it's explicit copyright notice embedded!) in the orig tarball, and rebuild it on our side to absolutely rule out any evil action or omission of update on upstream's side. Where a JPEG image is not the source form of a work – that is, where we have good reason to believe the JPEG image has a source form which the upstream maintainer could provide but does not – we should indeed ask that they provide the source form of the work. But where the upstream has no form of the work more suitable for modification than the JPEG image, then that *is* the source form of the work and it belongs in the Debian source package. I would argue that having minified files in the upstream tarball is no reason for repackaging. Those files are released under the same license as the source As has been pointed out, the issue being discussed is not the license terms of the work. The non-source form should not be part of the source package because we risk violating our Social Contract, and we can easily be much more sure of that contract by removing the non-source form of the work from the source package we distribute. -- \“If it ain't bust don't fix it is a very sound principle and | `\ remains so despite the fact that I have slavishly ignored it | _o__) all my life.” —Douglas Adams | Ben Finney ___ 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?
Emilien Klein emilien+deb...@klein.st writes: The current policy is made using the assumption that minified == compiled. For my information: Has this ever clearly and definitively been established? I'm not understanding your question. What assumption are you describing? Equating “minified” with “compiled” is not, AFAICT, an assumption; it is describing different aspects of the same process. I agree that we shouldn't be redistributing *compiled* software that we can't guarantee hasn't been fiddled with. Would you agree that we should not be shipping non-source forms of works that we can't guarantee have not been fiddled with? One of the guarantees to Debian recipients is that they have full freedom to change the behaviour of the software; that entails having the corresponding source form of the work. so, whether you call the process of generating an executable work “compiling” does not matter. What matters is that a non-source form of the work is generated and we distribute it; the Social Contract requires us to ensure that the resulting non-source form corresponds to the source form of the same work. Minified files is a practice in the JavaScript developer community to provider smaller files (mainly for performance reasons), but they remain JavaScript scripts, only harder for a human to read. In other words, they are not the source form of the work. To help make this situation clearer, can somebody point us to (1) the exact part of the DFSG or policy that we're using to base our exclude minified files from orig tarball policy and (2) where discussions have been led with folks outside of our team (e.g. -devel) about the undistributable character of minified files in upstream tarballs? DFSG §2: The work must be accompanied by its source code. A minified file is not the source form of the work, so we must provide, in the source package, the source form of the exact same work. -- \ “As we enjoy great advantages from the inventions of others, we | `\ should be glad to serve others by any invention of ours; and | _o__) this we should do freely and generously.” —Benjamin Franklin | Ben Finney ___ 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?
Emilien Klein emilien+deb...@klein.st writes: Hi Ben, 2014-03-26 22:30 GMT+01:00 Ben Finney ben+deb...@benfinney.id.au: Emilien Klein emilien+deb...@klein.st writes: The current policy is made using the assumption that minified == compiled. For my information: Has this ever clearly and definitively been established? I'm not understanding your question. What assumption are you describing? I am mentioning the fact that our policy mandates to repackage upstream tarballs if they contain minified files, based on the assumption that a minified file is a compiled resource (I almost wrote compiled binary, which is what I think of when thinking of compilation, but that is obviously not true as a minified JavaScript file is not a binary file) What makes you think the policy is “based on the assumption that a minified file is a compiled resource”? My understanding is that the policy is based on the fact that a minified file is a non-source form of the work, and the source package should contain only the source form of the work. Equating “minified” with “compiled” is not, AFAICT, an assumption; it is describing different aspects of the same process. That is exactly what I want to see confirmed. Is everybody (not just our smallish team of JS packagers) agreeing on the fact that a minified file is a compiled file? I don't see how disagreeing on that terminology would change the policy, since AFAICT the policy is not based on the definition of “compiled”. Would you agree that we should not be shipping non-source forms of works that we can't guarantee have not been fiddled with? Regarding the sentence that you cite below (regarding DFSG §2), I think there is no issue in redistributing an upstream tarball that contains the minified file from it's own source code. If the tarball only contained the minified file, I would obviously object. But if the tarball contains the source .js and the minified .min.js, I'm not sure we are in breach of DFSG §2 as the source is provided. The issue raised by that is, of course, how can we know that the non-source form of the work corresponds to the source form we are distributing? One way to be sure is to discard the non-source form we receive, and built it from the source. Then we don't need to assume anything about the non-source form we received; we can know that the result of the build corresponds to the source form of the work. Since we re-minify as part of our build process (should also be specified in our policy), the binary packages contain the source and the by-us-ensured-valid minified file. The .orig tarball then remains the same as provided by upstream. If we're distributing a non-source file in the source package, we run the risk of that file not corresponding to any source that we distribute. How do you propose we remove that risk? The risk is reduced to zero by discarding the non-source file we receive, and building it from the source. I believe most upstreams are in good faith, providing the minified files as a service to their users that can just extract that file and use it on their servers. Regardless of good faith, people can make mistakes or omissions. Why bother with a file that could quite easily violate our social contract, when we can just discard the non-source file from the source package and thereby avoid that risk? Have we ever seen a case where an upstream shipped an evil minified file in their release tarball? Why assume malice, when a simple mistake has the same result? This is, after all, a mistake easily made: upstreams routinely include the non-source form of a JavaScript work as a bundled third-party library, and have little motivation to bother checking that the source form corresponds with what they're shipping to us. -- \ “[Entrenched media corporations will] maintain the status quo, | `\ or die trying. Either is better than actually WORKING for a | _o__) living.” —ringsnake.livejournal.com, 2007-11-12 | Ben Finney ___ 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?
Jonas Smedegaard d...@jones.dk writes: DFSG #2: The program must include source code, and must allow distribution in source code as well as compiled form. I believe the term source code is in Debian generally interpreted as preferred form of modification. (That should be “preferred form of the work for modifying it”. I don't know what “form of modification” would be.) You may disagree with that interpretation, but that's where you should then argue your case - not at definition of minification or compilation. Indeed. Any transformation – minification, obfuscation, compilation, encryption, etc. – which makes a form of the work which is not the preferred form of the work for modifying that work, thereby makes a non-source form of the work. So the distinction being discussed is source versus non-source form of the work. -- \ “If you do not trust the source do not use this program.” | `\—Microsoft Vista security dialogue | _o__) | Ben Finney ___ 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?
David Prévot da...@tilapin.org writes: Hi François-Régis, I may be wrong but perhaps providing minified files in source tarball (which are considered as binary files) is DFSG compliant providing we have the sources, but debian policy is to exclude them from sources. Can you please be specific about what (point of) “debian policy” are you referring to? I think the policy referred to there is not Debian Policy, but the policy of the FTP-master team. The Developers’ Reference, on the contrary, advises to keep useless but DFSG-compliant files: Note that the section you quote is explicitly limited to unused *build infrastructure*, i.e. files that comprise tools needed for changing and building from the source package. That does not match compiled (minified) JavaScript files, which are clearly not part of the build infrastructure – they are the *end product* of a build, and hence not part of the source. -- \ “We can't depend for the long run on distinguishing one | `\ bitstream from another in order to figure out which rules | _o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 | Ben Finney ___ 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#740893: libjs-jquery-hotkeys regression (was: python-coverage regression)
On 21-Mar-2014, Thomi Richards wrote: I hope you don't mind my pinging you like this. No problem, you're doing so in my capacity as a Debian package maintainer, so this address is fine for that. I've discovered a regression in python-coverage packages in Ubuntu Trusty, and narrowed the problem down to a the jquery.hotkeys package in Debian. I filed a bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740893 Right, I think that bug report is correct. I'm replying onto that bug report to keep the discussion where it (IMO) belongs for now. ...and was hoping I could bring this to your attention, with the hopes of getting it fixed in time for the Trusty release. Isn't the problem best fixed by reverting the ‘libjs-jquery-hotkeys’ package to the working “0.8” version? The newer version breaks dependent packages, so the right place to apply pressure it seems to me is by rejecting that newer code from Debian until it works again. I'm not sure what the best solution is. I've identified the last revision of that package that worked well with coverage.py. One option is to revert the debian package, but presumably those changes were made for a reason, and I'd hate to break other projects. Another option is to use the vendorised libraries in upstart coverage.py. Sure. It's easy for me to identify the location for a solution in a package which I'm not really involved with, so my position is not the only one to consider. Please let me know if I can do anything to help out. Have you got any feedback from the Debian package maintainer of ‘libjs-jquery-hotkeys’ to find out whether rolling back to version “0.8” is feasible? Have you worked with that package maintainer to report the bug upstream (it is the package maintainer's responsibility)? Has the upstream developer -- \ “Too many pieces of music finish too long after the end.” —Igor | `\ Stravinskey | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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] Policy on installation of source and compiled (minified) versions of a library (was: Request to Join Project Debian JavaScript Maintainers from François-Régis Vuillemin (frv-gue
Jonas Smedegaard d...@jones.dk writes: Quoting François-Régis (2014-03-06 22:59:20) what is the preferred way : - install a minify version an keep the orginal in source package - install both minify and original source - just install original source Install both. Some users may serve the minified version as-is, while some other users may want to join multiple files where better minification may be gained from joining source files instead of pre-minified files. Other languages – e.g. Python, Ruby, Emacs's elisp, etc. – have a policy on what packages should install and where they should install them. The establishment of such a policy has enabled conventions for packaging tools (e.g. ‘dh_python’) to perform the compilation and renaming in a standard manner for all packages using the tool. What is the Debian ECMAScript (JavaScript) policy on: * Whether to install source and/or compiled (minified) versions? * What compiler (minifier) to use by default? * Where to put the source and compiled versions during install? * How to name the installed files so that library names and versions can predictably be located? etc. If such questions aren't yet answered in a Debian-wide policy, what are the current consensus on these? What prospect is there to have the discussions needed to reach a consensus for policy? -- \ “When a well-packaged web of lies has been sold to the masses | `\over generations, the truth will seem utterly preposterous and | _o__)its speaker a raving lunatic.” —Dresden James | Ben Finney ___ 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#736779: [src:nodejs] Sourceless file
retitle 736779 [src:nodejs] Minimised ECMAScript in upstream source thanks On 26-Jan-2014, bastien ROUCARIES wrote: I could not find the source of: doc/sh_javascript.min.js On 26-Jan-2014, Jérémy Lal wrote: Meanwhile, do applying the patch replacing minified by unminified source is enough ? Patching the source will remove the file only from resulting binary packages. To address this bug, non-source files must be removed also from the source package. This can be solved by one of: * Convince upstream to routinely ship a tarball of only the *actual* source (i.e. the preferred form of the work for making modifications to it), and ensure that tarball has everything needed to build the binary package. * Re-pack to remove the non-source files from the pristine upstream tarball URL:https://wiki.debian.org/BenFinney/software/repack. Such a program would need to be maintained on an ongoing basis as upstream's source releases continue to change. A likely way to do this is to start by re-packing (in order to address this Debian bug), and continue to work with upstream to persuade them to omit the non-source files from their source release procedure, thereby solving the problem permanently in this package. -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__)—Bill Maher, 2003 | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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#726481: coffeescript: please add dependency “Suggests: coffeescript-doc”
Package: coffeescript Version: 1.4.0-1 Severity: minor Howdy, Programming in Coffeescript requires understanding how it works and what it does. Please set a “Suggests: coffeescript-doc” dependency, so that administrators choosing to install ‘coffeescript’ will receive the suggestion. -- \ “Immorality: The morality of those who are having a better | `\ time.” —Henry L. Mencken | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital 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] First-class examples of Debian packaging for ECMAScript libraries
Howdy all, I am beginning the journey of learning how to package ECMAScript code for Debian. What are good examples of existing Debian packages, which the community would consider exemplify good practice and convention? Ideally I'm looking to package browser-based libraries with Debhelper. -- \ “Why should I care about posterity? What's posterity ever done | `\for me?” —Groucho Marx | _o__) | Ben Finney ___ 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] MIT +no-false-attribs
Jérémy Lal kapo...@melix.org writes: On 06/03/2012 19:20, Isaac Schlueter wrote: In other words, if the terms of this license keep npm out of Debian Stable, or any particular distro, then that means it's working. The fact that npm is not in the distro is worse for the distro than it is for npm. That's certainly not going to help in any discussions to work with Debian. Maybe we would be best respecting the copyright holder's clearly stated wishes to keep this work out of Debian. -- \“Don't worry about people stealing your ideas. If your ideas | `\ are any good, you'll have to ram them down people's throats.” | _o__)—Howard Aiken | Ben Finney ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
