Re: [Pkg-javascript-devel] Comments regarding node-node-localstorage_1.3.0-2_amd64.changes

[Daniel Kahn Gillmor]

On Thu 2018-02-22 10:38:42 +, Chris Lamb wrote:
> Might be worth using "Laurence (Larry) Maccherone" - this alternative/nickname
> can be somewhat Western-centric.

Thanks for the pointer.  the author identifies themselves once as
Lawrence (not "Laurence") S. Maccherone, Jr in README.md, despite
identifying as Larry in README.md, package.json, and all the git
commits.  But the "Lawrence" business is on the Copyright line
specifically, so i've just made this change to debian/copyright:

https://salsa.debian.org/js-team/node-node-localstorage/commit/e1e3b33a6d44e2190e0879440cb0c6644020428d

I will probably not roll a new debian release just for that change, but
it should be included in any future release.

 --dkg

-- 
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#734101: libjs-jquery-mobile: New Release

[Daniel Kahn Gillmor]

On Fri 2014-01-03 14:04:26 -0600, in https://bugs.debian.org/734101 Charlie 
Smotherman wrote:
> Package: libjs-jquery-mobile
> Version: 1.2.0+dfsg-2
> Severity: wishlist

What's going on with libjs-jquery-mobile?  It would be really good for
debian to ship an up-to-date version of libjs-jquery-mobile, or at least
as up-to-date as libjs-jquery at any rate.

is there a reason that libjs-jquery-mobile is in worse shape than the
other libjs-jquery-* packages?

  --dkg


-- 
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] npm2deb, OpenPGP.js, and dependency management [was: Re: Looking for help Re: Bug#787774]

[Daniel Kahn Gillmor]

On Thu 2018-02-01 21:41:48 +0530, Pirate Praveen wrote:
> You can request access to the team.

done, if anyone can grant it i'd appreciate it.  my account is "dkg".

> I have replied to your ITP about grunt. Yes, many of this can be
> ignored. You will need to replace browserify with webpack.

i appreciate your help here.  When i get time to follow up in more
detail, i might also try asking on #debian-js.

once i get access to the salsa js-team group, i'll upload what i've
managed to figure out so that there's a common point of reference before
uploading.

--dkg


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] Looking for help Re: Bug#787774: RFP: libjs-openpgp -- OpenPGP JavaScript Implementation (OpenPGP.js)

[Daniel Kahn Gillmor]

Over on https://bugs.debian.org/787774, On Fri 2015-06-05 00:43:14 +0200, W. 
Martin Borgert wrote:
> Package: wnpp
> Severity: wishlist
>
> Package name: libjs-openpgp
> Version : v0.10.1
> Upstream Author : OpenPGP Development Team 
> URL : http://openpgpjs.org/
> License : LGPL3+
> Programming Lang: JavaScript
> Description : OpenPGP JavaScript Implementation

OpenPGP.js is in even better shape today when this bug was filed, but it
hasn't been included in debian yet.  This is an e-mail asking about the
best next steps to get it into Debian.

(btw, URL should be https://openpgpjs.org/ these days)

I need OpenPGP.js in debian in order for me to upload the upcoming
enigmail 2.0 release, because enigmail 2.0 includes OpenPGP.js, and
upstream only has the minified versions available, which clearly isn't
DFSG-free.

I'm not very skilled with the node/grunt toolchain in debian, or with
the current debian javascript packaging policy but i'd be happy to learn
if someone wants to give me pointers.

the upstream documentation looks like it can prepare everything for
publication with:

npm install
npm test

but that itself looks likely to use network access which is something we
can't depend on during the debian build.

Should i try to follow the npm2deb guidance here:

   https://wiki.debian.org/Javascript/Nodejs/Npm2Deb

or is there a better approach?

Also, is libjs-openpgp still the best-practice name for the debian
package for OpenPGP.js?  I'd be happy to take over this RFP if i can get
guidance from wiser javascript people about this.

   --dkg


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] #743404 RFP: eslint -- tool for static analysis of ECMAScript (JavaScript™) code

[Daniel Kahn Gillmor]

Hi debian javascript maintainers--

in https://bugs.debian.org/743404, Ben Finney  
wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: eslint
>   Version : 0.4.5
>   Upstream Author : Nicholas C. Zakas 
> * URL : http://eslint.org/
> * License : Expat (MIT)
>   Programming Lang: ECMAScript
>   Description : tool for static analysis of ECMAScript (JavaScript™) code
>
> ESLint is a tool for identifying and reporting on patterns found in
> ECMAScript (JavaScript™) code. It performs static code analysis to find
> common and likely mistakes.
> .
> In many ways, it is similar to JSLint and JSHint with a few exceptions:
> .
> * ESLint uses Esprima for JavaScript parsing.
> * ESLint uses an AST to evaluate patterns in code.
> * ESLint is completely pluggable, every single rule is a plugin and you
>   can add more at runtime.
>
> One reason this package is attractive for ECMAScript developers is because
> it is a DFSG-free licensed linter; the two most popular linters, JSLint and
> JSHint, both have non-free licenses that prevent their inclusion in Debian.


Is anyone in the javascript team up for packaging this?  It appears to
available in npm, fwiw.

Enigmail is now using eslint upstream as part of the test suite (they've
switched to it from jshint to avoid the crappy jshint license), and i'd
love to be able to run the full test suite from within debian during
enigmail package builds.

 --dkg

___
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] [Launchpad Feedback #50206] RE: Launchpad: Claim existing team

[Daniel Kahn Gillmor]

Hi Valentin--

On Fri 2015-01-23 16:40:46 -0500, valentin OVD wrote:

 It's me who have claimed the team for prevent this to happen.

Thanks for clarifying, i have indeed seen you posting on the mailing
list since March 2014.

 Administrators of Pkg-javascript please reclaimed the launchpad team.

I don't understand who you are addressing, or what you think they should
do.  Can you clarify?

Regards,

 --dkg

___
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] Launchpad: Claim existing team

[Daniel Kahn Gillmor]

On Fri 2015-01-23 15:17:19 -0500, Launchpad wrote:

 vovd (vovd) tried to claim the Launchpad
 team named Debian Javascript Maintainers (pkg-javascript-devel-lists) (which 
 is
 associated with pkg-javascript-devel@lists.alioth.debian.org).

 To finish claiming that team, making vovd (vovd)
 its owner, just follow the link below.

 https://launchpad.net/token/s82RbqGNq9Zn29808FhD

This is a troubling situation.  Launchpad sends this token, but the
owner is a publicly-archived mailing list.

All an attacker needs to do is submit a request to claim the team, then
read the archive to find the token and claim the team.

Should launchpad have a warning against assigning group ownership to a
public mailing list?

fwiw, i've been on the Debian Javascript Maintainers mailing list for
over a year and i've never heard of anyone named vovd.

 --dkg

___
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] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)

[Daniel Kahn Gillmor]

On 05/05/2014 06:16 AM, Emilien Klein wrote:

 It's not about being more strict.
 It's about explicitly mentioning a requirement that is not clear to a
 number of our co-packagers.

FWIW, if the exclusions in debian/copyright (those mentioned on the
wiki) interact properly with uscan, and if the uscan-based repackaging
is deterministic (e.g. run it twice on the upstream tarball and get the
same repacked tarball, byte-for-byte), and if all of our packages have
valid debian/watch files, so that the normal package update is uscan,
then i can live with this policy.

I personally don't think it seems necessary, but if it encourages people
to use standard tools, and to ensure that those tools are in good
working order, and to document our relationships with upstream, then it
could be a good thing overall.

--dkg

PS i haven't tested all of the conditions i mentioned above, i'm just
hypothesizing and haven't had time to investigate further.  sorry for my
laziness!



signature.asc
Description: OpenPGP 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] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)

[Daniel Kahn Gillmor]

On 05/04/2014 05:31 PM, Emilien Klein wrote:
 No other comments from the team on Jérémy's proposal?

If the upstream tarball has both the original and minified javascript, I
don't think we need to actively re-pack the upstream tarball to get rid
of the minified javascript, any more than we need to actively re-pack
upstream source that includes .png icon sources alongside their .svg source.

We should not shipping the upstream-minified files in our .debs  -- we
should re-minify the canonical source and ship the output of that step,
if we need to ship minified files.

--dkg



signature.asc
Description: OpenPGP 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#722490: Bug#722490: src:pegjs: please relax debhelper compatibility level to ease backporting

[Daniel Kahn Gillmor]

On 09/11/2013 11:52 AM, Jonas Smedegaard wrote:

 pegjs source package seems to do no extraordinary packaging tricks, yet
 uses debhelper compatibility level 9, making backporting to stable or
 oldstable harder, as it then involves also backporting debhelper (or
 relying on other backporting of that).

debhelper 9 is already in debian stable (wheezy).  It is also in
squeeze-backports (which we can treat as part of oldstable), and is
trivially easy to install for anyone building a backport.

At this point, debhelper 9 seems like a reasonable level to aim for.  I
don't think changing the packaging to accomodate people who develop on
pure squeeze is a good idea.

Regards,

--dkg



signature.asc
Description: OpenPGP 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] Debian font URLs [was: Re: Debian javascript URLs]

[Daniel Kahn Gillmor]

i'm hijacking this corner of a javascript discussion over to the debian
fonts team because i think they should be aware of it as well.

pkg-fonts folks, this is a continuation of a javascript discussion about
coordinating default data URL locations between fedora and debian
default HTTPd configurations; see the initial discussion starting at:

 
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-August/005888.html

 id:CAD3FbMW1ZceHPp5mtzeGjC4iJCAgD+o+0v3Wid=cg22vohz...@mail.gmail.com

The text below is interesting and worth considering.  I've changed the
subject line and am encouraging followup to pkg-fonts-devel -- but
please keep ktdreyer and tchollingsworth in the CC (until they ask to be
spared) since i think they are not subscribed.

On 08/15/2013 03:50 PM, T.C. Hollingsworth wrote:
 So first I think I should explain what the deal is with the assets
 thing.  As part of the new guidelines, we really want to take into
 account shared non-JS stuff like CSS frameworks, icon libraries, web
 fonts, whathaveyou.
 
 So the idea is to have one all-encompassing web assets directory, with
 various subdirectories for different kinds of stuff.  We intend to
 symlink /usr/share/fonts into this directory so web developers have a
 huge collection of free fonts available immediately at their fingertips,
 and so we don't have to repackage anything to make them available on the
 web.
 
 The httpd-exported directory kind of got kicked around and ended up
 being /_sysassets in the current incarnation of the proposal, but I'm
 not very happy with it.  I like how the sys prefix sets the directory
 apart enough so that it's not going to conflict with directories already
 being used on web servers out in the wild, but without adding a whole
 lot of extra length and reinforcing that the contents are provided by us
 awesome distro packagers.  The underscore doesn't really make much of a
 difference IMHO.
 
 I also think JS is important enough for it's own directory on top of the
 assets directory, and this would allow us to collaborate with you even
 if you're not interested in the rest of our assets approach.
 
 So, what I'd really like to do is:
 /sysjs  - system-provided shared JavaScript libraries
 - /usr/share/javascript on the filesystem
 - same HTTPd and filesystem-side on both Debian and Fedora
 /sysassets  - system-provided shared static assets
 - /usr/share/web-assets on the filesystem
 - up to you whether you want to implement
 
 This is highly unlikely to conflict with anything that's going on in the
 real world. Not to mention that /sysjs is half the length of
 /javascript.  (Who wants to type a bunch of crap into their script
 tags? ;-)
 
 I really think Debian and Fedora both would benefit from some synergy
 here.  If we diverge too much any chance of upstream support here is
 completely lost.  :-(


Setting aside that their initial query was about javascript resources,
does this seem like something we can or should encourage for font
packages?  It would be really nice to coordinate with fedora on this to
make it standard and stable.  Webfonts are a cool technology, and if we
could make it easy to provide them without encouraging off-origin
requests (often to surveillance-minded and potentially-compromised
third-parties), that would be a positive contribution to the state of
the network.

debian and fedora together seem like a good team to get the ball rolling
on making this somewhat standardized.

--dkg



signature.asc
Description: OpenPGP 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] Debian javascript URLs

[Daniel Kahn Gillmor]

sorry to be late to the discussion!

I quite like the idea that we can make it easy for web site
administrators who use debian (and fedora!) to avoid the evil CDNs for
their standard javascript.

On 08/15/2013 08:40 PM, T.C. Hollingsworth wrote:
 There's nothing wrong with it, I just think we should have something
 shorter and less likely to result in an uproar.  I'm happy with making
 it work, so you can just share /usr/share/doc as /doc and everything
 can work fine.  That makes a lot of sense to me.

fwiw, we recently *stopped* sharing /usr/share/doc as /doc due to
CVE-2012-0216:

 http://www.debian.org/security/2012/dsa-2452

So if we do this, we need to take some pains to be sure that this sort
of approach doesn't re-introduce the problems resolved there.  Do you
have any suggestions of how we could comprehensively avoid those problems?

 It doesn't make any sense to me to hardcode a filesystem path into
 applications written in dynamic languages that you'll never be able to
 just open with Firefox anyway.  There's a reason there's a separate
 namespace for content served over HTTP.

Jonas' argument to just use the filesystem hierarchy for select
directories is tempting (and feels logically the most satisfying), but i
suspect the complaints (about URL length and panic about exporting /usr)
that the fedora folks are trying to address or head off will be real
enough, even if they're not logical.

It occurs to me that if a single top-level directory (e.g. /.websys) in
the URL namespace was mapped to a safe directory in the filesytem,
then people who wanted the feature Jonas is asking for can simply create
a /.websys symlink in their local filesystem to get the same benefits
without requiring web sites to have huge URLs in their script tags.

breaking that into two separate top-level directories seems more likely
to raise objections to me -- just do it once and be done with it.

  /.websys/js

is still as short as

  /javascript

and permits /.websys/fonts, /.websys/css, etc to reside under the same link.

About the example name used above: i made up .websys for a couple
reasons, neither of which are particularly important, just trying them
on for size (if you have a link to the discussion that concluded with
_sysassets, i'd be happy to read the other issues and options fedora has
already considered):

 * leading dot makes the file hidden so most normal views of / won't
see an extra entry in case someone decides to add the symlink to the
root filesystem.

 * including web in the name gives people who find the name in the
filesystem a hint about what it's for, just like sys gives people who
find the name in a URL a hint about where it comes from

fwiw, i agree that waiting for a new revision of the FHS is implausible.
 If debian and fedora can agree on something while legitimately thinking
through and trying to address any potential objections, we shouldn't let
the FHS's stagnancy stop us.

Thanks for raising this issue, i really do think it would be good to see
fedora and debian collaborate on this.

Regards,

--dkg



signature.asc
Description: OpenPGP 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#495178: Bug#495178: Bug#495178: (no subject)

[Daniel Kahn Gillmor]

On 07/30/2013 03:36 PM, Jonas Smedegaard wrote:
 Quoting Thomas Bechtold (2013-07-30 19:47:10)
 forgot to describe the attached debdiff. The patch adds a 
 Build-Depends to yui-compressor and generates jquery.min.js. That's 
 it.
 
 I recommend against using a different and inferior compressor than the 
 one well tested upstream: uglify.

I think you're suggesting that this package should use the uglify
javascript minifier, rather than the yui minifier.

Do you mean node-uglify or ruby-uglifier or something else?

Does the debian javascript packaging team want to settle on a best
practices minifier and document it someplace?

--dkg



signature.asc
Description: OpenPGP 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] backporting jquery-timepicker

[Daniel Kahn Gillmor]

hi folks--

i'm planning on backporting jquery-timepicker 1.2 (which is in jessie)
to wheezy-backports.  Please let me know if you have any concerns!  I'm
the maintainer (under the aegis of the pkg-javascript team, cc'ed here)
for this package in the regular archive as well.

Regards,

--dkg


pgpFAQd97spTr.pgp
Description: PGP signature
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#715325: Bug#715325: npm: leaves lots of stuff in /tmp

[Daniel Kahn Gillmor]

On 07/10/2013 12:11 PM, Jérémy Lal wrote:
 The security issue is fixed there :
 https://github.com/isaacs/npm/commit/f4d31693
 
 this will eventually come to npm debian package.

Thanks for the followup on this, jérémy!

I confess i'm kind of amazed that node doesn't have any primitive like
mkstemp(3), or if it does, that npm isn't using such a primitive.

Has a CVE been requested or assigned for this yet?  I'd be happy to make
the request if you think that would be useful.

regards,

--dkg



signature.asc
Description: OpenPGP 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#715325: [oss-security] npm uses predictable temporary filenames when unpacking tarballs

[Daniel Kahn Gillmor]

On 07/10/2013 04:02 PM, Daniel Kahn Gillmor wrote:
 hi oss-sec folks--
 
 i recently learned that npm, the node.js language-specific package
 manager, created predictable temporary directory names in a
 world-writable filesystem (/tmp) by default when unpacking archives.
 
 It looks like this might leave open a classic symlink race such that one
 user could control the location where another user unpacked packages
 coming from an npm installation.
 
 if the superuser was the one running npm, this might have led to a
 non-privileged user who wins the race getting a privilege escalation as
 well, depending on the contents of the fetched package.
 
 The issue appears to have been fixed upstream today, here:
 
   https://github.com/isaacs/npm/commit/f4d31693
 
 I first learned about the problem during a related a bug report
 http://bugs.debian.org/715325 (cc'ed here)

sorry, i should also have mentioned that the upstream bug report is:

https://github.com/isaacs/npm/issues/3635

--dkg



signature.asc
Description: OpenPGP 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#715325: Bug#715325: Bug#715325: npm: leaves lots of stuff in /tmp

[Daniel Kahn Gillmor]

On 07/08/2013 03:33 AM, Jérémy Lal wrote:
 On 08/07/2013 05:08, Shawn Landden wrote:

 I installed a few packages yesterday, and today realized npm was wasting 50M
 of my ram with copies of what it downloaded still in /tmp/npm-# folders


I haven't tried to reproduce this yet, but it sounds to me like you
might be saying that the names of the /tmp/npm-# folders might be
predictably named (e.g. named after the process id).  Is this the case?
 If so, has anyone considered the possibility of an attack via
predictable paths in a world-writable directory?

 it should clean this up, put it in /var/cache, and/or have a command to 
 clean up
 
 Issue reproduced.
 As a quick workaround, you can create ~/tmp and npm will use that instead.
 Otherwise i believe those leftovers are a bug.

it's buggy if it doesn't clean up, regardless of which tmp directory it
uses.  and npm should probably be respecting $TMPDIR directly following
the standard unix conventions, rather than just assuming that the
magically-named ~/tmp is preferable to /tmp.

--dkg



signature.asc
Description: OpenPGP 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#715325: Bug#715325: Bug#715325: npm: leaves lots of stuff in /tmp

[Daniel Kahn Gillmor]

On 07/08/2013 07:55 AM, Jérémy Lal wrote:

 I am curious about how `npm install mymodule` could be a target for an 
 attacker,
 especially considering the temp directory is used only once (at (un)tar 
 times).

if the tmpdir is predictably-named (e.g. it is /tmp/npm-$PID), then an
attacker could watch the process table for a process named npm, and as
soon as it appears (say, as pid 13577, create a symlink at
/tmp/npm-13577 that points to, say, the home directory of the user npm,
which might have the effect of clobbering any similarly-named files.

This is a crude attack, but depending on the contents of the tarball it
could be pretty unfortunate (e.g. if the tarball contains a file named
secring.gpg, and the attacker points the symlink to the victim's
~/.gnupg ?).

 Agreed, the workaround i proposed is completely wrong,
 please read what `man npm-config` says about TMPDIR instead.

http://sources.debian.net/src/npm/1.2.18~dfsg-3/doc/cli/config.md#L756
suggests that it is supposed to use TMPDIR, which is good :)

--dkg



signature.asc
Description: OpenPGP 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] packaging libjs-jquery*

[Daniel Kahn Gillmor]

Hi M.Tornow--

On 05/31/2013 04:16 AM, tor...@riseup.net wrote:
 I try to learn packaging for
 Debian in a group which wants to package diaspora for debian. 

great, thanks!

 I downloaded apt-get source
 libjs-jquery-fancybook to get a template, but to my surprise it gave
 me jquery-goodies-8. And no good template to work with. 

this is because jquery-goodies-8 is a source package that bundles the
packaging for several jquery addons -- i agree that it's not a good
example for someone who wants to package a single new addon.

If you're looking for a single package that you might use as an example,
i offer my own jquery-timepicker package, at:

 git://anonscm.debian.org/git/pkg-javascript/jquery-timepicker.git

I've only recently started packaging javascript for debian myself (i
have done other debian packaging for a while now), so hopefully other
members of the team will chime in if this doesn't make sense as a model.

Sorry i don't have time to review your package further right now.

Regards,

--dkg



signature.asc
Description: OpenPGP 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] documentation about distributing minified versions of files

[Daniel Kahn Gillmor]

On 05/08/2013 07:29 AM, Jérémy Lal wrote:
 There are two different needs :
 
 1) packaged webapp that depends on libjs-* package
 
 2) user project that depends on libjs-* package.
 
 
 For 1) your suggestion would work, but it wouldn't for 2).

Why not?  I don't see what problems it causes for that scenario.

 Something that would work for 2) is user Makefile that helps
 setup symlinks or copies of the packaged files. Symlinks if the user
 wants to be able to upgrade the files along with packages upgrades,
 copies if he doesn't. In both cases it's up to a user script to
 install minified/unminified version, possibly renaming the files and so
 on.

this sounds like we would be encouraging a maintenance nightmare.  what
if the user adds a new script or a new symlink manually to the same
directory, and then re-runs the makefile hook to bring the external
dependencies up to date or to switch from minified to non-minified?
for people who deploy their code from (signed) tags in a VCS, do they
have to have a new tag at each deployment that re-runs this hook to
adjust the links, thereby diverging from their VCS checkout?

 But if the user has to install libjs-jquery or libjs-jquery-minified
 each time, it is a painful process.

why is this painful?  During development, you install libjs-jquery
alongside whatever other development tools, libraries, frameworks your
user project depends on.  your user project links to the
/usr/share/javascript/jquery directory, whose contents are provided by
libjs-jquery.

In deployment, the sysadmins install libjs-jquery-minified on the live
server instead.  this installs minified files in
/usr/share/javascript/jquery .  the user project does not change at all.

Regards,

--dkg



signature.asc
Description: OpenPGP 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] documentation about distributing minified versions of files

[Daniel Kahn Gillmor]

On 05/06/2013 02:21 PM, Jérémy Lal wrote:
 Daniel you ask me to explain some things i thought was common practice.
 Below i try to give explanations ; please help me fix, refine, or reject
 them.

thanks, i think it's useful to establish documentation of common
practice, along with the rationales for it, so we can evaluate whether
the practice actually supports the rationales.

 An essential difference between C and Javascript is that C is compiled,
 and Javascript is interpreted.
 Before minifying was so easy, nobody minified Javascript files, and
 it is perfectly fine to use unminified Javascript files in production.

sure, i understand the nature of the toolchains; but clearly it's not
100% perfectly fine to use unminified js in production, or we wouldn't
have tools that generate minified js :)  That is, minifying js provides
certain performance gains that users can't expect from non-minified js.

 The obvious advantage of keeping unminified files by default is keeping
 this advantage of being able to debug a Javascript program right away,
 since all modern web browsers ship full-featured debuggers.

i like the idea of being able to debug a webapp using the browser's
debugger; however, i'm not sure how we expect a webapp maintainer to
switch between the minified and non-minified versions of the javascript.

 * should name the minified files like foo.min.js

it sounds to me like this proposal asks the webapp maintainer/developer
to change all their code to explicitly source $foo.min.js when it is in
production, and then change it back to sourcing $foo.js when they are
debugging.

Is this a realistic workflow to expect of web developers?  It seems more
plausible to me that webdevs will write the code to use $foo.js (for
easier debugging) and never use the minified versions.

Given that it will be system administrators and not webdevs who want it
to use the minified versions, maybe another approach would be to have
two different packages that conflict with each other.  for example:

 libjs-jquery
 libjs-jquery-minified (Provides: libjs-jquery)

then the source code for webapps could remain static, and the sysadmin
could switch between minified and verbose forms via apt/dpkg.

I'm happy to hear suggestions for other approaches, i'm just trying to
think more widely if we're in the process of establishing best-practices.

 For the keep it easily debuggable reason. It brings absolutely no
 real advantage to have minified versions for nodejs modules.

Just to be clear, is this because node loads the interpreted code once,
does so at minimal expense, and then operates from it in memory as it
handles each subsequent request?  (sorry, i don't know the node process
architecture very well) Or is it because node is loading the files from
disk instead of over the network and we just assume that there is
minimal cost for loading from disk as compared to loading over the network?

--dkg



signature.asc
Description: OpenPGP 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] libjs-jquery-timepicker (http://bugs.debian.org/693884)

[Daniel Kahn Gillmor]

hi debian javascript folks--

I'm about to try to take on #693884 to package Trent Richardson's jQuery
UI timepicker addon.

i've just subscribed to the javascript maintainers team, and i'm afraid
i don't have the time to help out with other js packages, but i would be
happy to include this new package under the pkg-javascript team umbrella
if y'all are interested.  I've just applied for team membership via the
alioth interface.

I'm hoping to place the new packaging into a git repository on alioth
(in addition to my personal git repos) so that anyone who wants to fix
my bugs can do so easily :P

Any suggestions or guidance or best practices for this jquery plugin
would be very much appreciated.

Happy Hacking,

  --dkg


pgpRkbIeF2qTz.pgp
Description: PGP signature
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Request to Join Project Debian JavaScript Maintainers from Daniel Kahn Gillmor (dkg)

[Daniel Kahn Gillmor]

On 03/26/2013 02:18 PM, Marcelo Jorge Vieira wrote:

 On Tue, 2013-03-26 at 17:19 +, [dkg] wrote:

 [...] have just subscribed to pkg-javascript-devel@lists.alioth.debian.org

 Have you subscribed to our mailinglist already? 
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

i think that's the same thing, yes :)

I'm going to set up the shared libjs-jquery-timepicker repo on alioth
shortly.

I've read https://wiki.debian.org/Javascript and
https://wiki.debian.org/Javascript/Policy . I welcome any other guidance
y'all have to offer.

Thanks for the welcome, i look forward to working with everyone!

--dkg



signature.asc
Description: OpenPGP 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