Re: [Pkg-javascript-devel] Debian javascript URLs
Quoting Daniel Kahn Gillmor (2013-08-22 05:23:17) 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. Please let's discuss those two issues separately. URL length -- I did not propose to use /usr/share/javascript (that was only an example) but to use whatever is the actual path on each system. The length of the URL depends on the actual path - and if we (coordinated or as single distro) choose to not care about FHS then it could indeed be quite short. panic about exporting /usr -- I did not mean to imply re-exporting /usr (but can see how that was not at all clear from what I wrote - sorry!). What I meant was to export only the parts we actually need to share, just as we do today. I would want the root path to still be configurable, just as it is today, to allow sysadmins to e.g. optionally install a package that re-uglifies javascript (either due to some preference in quality of uglifier, or add some salt to to work against the host being easily identified as a certain release of Debian through fingerprinting). Trying to not look like generic Debian is a *different* interest of some of our users, which clashes with the interest of Debian hosts being able to form a CDN (which requires all participating hosts to serve same files, and therefore being able to match by patterns). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] nodejs won't be backward-compatible with c++ modules
Quoting Jérémy Lal (2013-09-01 17:57:17) On 01/09/2013 12:46, Jonas Smedegaard wrote: Quoting Jérémy Lal (2013-08-31 10:01:11) It is upstream's goal to improve on this, meanwhile it means the next stable release of nodejs will have to Break all c++ modules (at their current versions). Is there a way to ease transition that right now ? Add nodejs 0.11 in Depends ? If what breaks is abi but not api, then I believe the best is to release with no Breaks, and then request binNMUs for all affected reverse dependencies. no no it is really API breaking, both forward and backward. When nodejs is 1.0 these matters are supposed to be solved. Oh, ok. In that case it seems sensible to me to add Breaks in nodejs package against all reverse dependencies, up to and including the exact current version. E.g. Breaks: node-pg (= 0.7.1-1). That covers current version but not eventual binNMUs. I believe it is wrong to use an explicit version that does not really exist yet - so even if adding a trailing + would technically work I believe that is wrong. (as a sidenote, I _do_ find it ok to add training ~ for versioned dependencies, to include eventual backports of same version). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#722488: src:pegjs: should ship separate binary package libjs-peg
Package: src:pegjs Severity: normal Homepage advertises PEG.js being usable from a web-browser, which the build-dependency on uglifyjs also hints about. Packaging only provides creates a package for use with Nodejs, however. Minified code should be shipped in separate libjs-peg package that recommends javascript-common and (at most) suggests node-peg, for use in browsers. - Jonas ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] [Pkg-owncloud-maintainers] Bug#718915: owncloud: Share with input does not generate a users list
Being a bit clueless about how to even debug this situation, I’m hereby bugging the libjs-jquery-ui maintainers for help. owncloud works fine with its own libjs-jquery-ui copy (version 1.10.0) and with the libjs-jquery-ui package from wheezy (version 1.8.ooops.21+dfsg-2), but not with the version from sid (1.10.1+dfsg-1). Do you have any idea about what is going wrong here? Do you have any advice for debugging or fixing the situation? The embedded working owncloud copy is available online if needed: https://github.com/owncloud/core/raw/stable5/core/js/jquery-ui-1.10.0.custom.js Since the URL includes custom, perhaps it makes sense to simply ask upstream what they customized in the jQuery that they shipped. ...or look for clues in commit messages for their VCS, if available. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] (no subject)
Hi Firdaus, Quoting Muhammad Firdaus (2013-09-29 16:00:21) Hello, l am new Debian Maintaner now, l am packaging libjs-leaflet-awesome-markers, it's Leaflet plugin to make cool Font Awesome/Twitter Bootstrap Icon :) Welcome aboard! Looking forward to work with you! @others: Firdaus and I have been in touch for a couple years and I am very excited that he now decides to start do Debian packaging. I will help him with libjs-leaflet-awesome-markers - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Hello
Quoting Mike Gabriel (2013-10-01 14:30:32) On So 29 Sep 2013 16:50:32 CEST, Jonas Smedegaard wrote: @Mike: Are you still working on Etherpad Lite? Which libraries are still missing for that? Yes, I still have that on my radar. Per Andersson is also packaging dependencies. The list is long. My next target packages will be node-ws, node-socket.io, node-socket.io-client node-ueberdb Check the package.json [1] file of etherpad-lite to get further insight on the dependencies. Easier for collaboration than referring to a dependency list is probably to file RFPs for the dependencies you need but do not intend to necessarily work on yourself, and (convert to) ITPs for those you plan to do next. That goes for myself too (uglifyjs, coffeescript, buddycloud etc.), obviously. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#725362: Bug#725362: node-bones: present but uninstallable on architectures lacking nodejs
Quoting Colin Watson (2013-10-04 17:34:19) node-bones is present but uninstallable on a number of Debian architectures that lack nodejs. There is no point shipping it on these architectures, and it introduces noise for anything trying to do dependency consistency checks. While it would be possible to fix this by explicitly limiting node-bones' architecture list, this would require keeping that in sync with nodejs over time; so it's better to add an artificial build-dependency on nodejs to ensure that the package will harmlessly enter a dependency-wait state when it isn't available. You'll probably need to get an ftpmaster to manually remove the old binaries after uploading this. * Artificially build-depend on nodejs, to ensure that this package only builds on architectures where nodejs is available. Are you sure the package is really shipped on archs that do not include the interpreter that the _binary_ package depends on, even though _source_ package does not? As also commented in the related bug#725363, I believe it is filtered off by the transition rule for testing, and therefore only is noisy in unstable. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#725794: RFP: libjs-jsgantt -- gantt chart component built in Javascript, CSS and AJAX
Package: wnpp Severity: wishlist * Package name: libjs-jsgantt Version : 1.2 Upstream Author : Shlomy Gantz shlomyga...@hotmail.com * URL : http://jsgantt.com/ * License : BSD-3-clause Programming Lang: Javascript Description : Javascript/CSS/AJAX based Gantt chart component jsGantt is a fully featured gantt chart component built entirely in Javascript, CSS and AJAX. No images required. . Features include: * Tasks Collapsible Task Groups Dependencies * Task Completion * Task Color * Milestones * Resources * Dynamic Loading of Tasks * Dynamic change of format (day/week/month) * Load Gantt from XML file libjs-gantt should solve bug#724287 (convenience code copies). ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] backport nodejs to wheezy
Quoting Daniel Pocock (2013-10-11 10:22:48) On 11/10/13 10:20, Jérémy Lal wrote: On 11/10/2013 09:47, Daniel Pocock wrote: I'm just wondering if anybody else thinks a wheezy-backports version of nodejs is feasible? I've run it on wheezy and built my own packages (pegjs, jssip) on wheezy and all seems OK Do you backport libv8 too ? Just looking at the system where I did this, I notice it is not pure wheezy It has a version of libv8 depending on libc = 2.14 - I simply pulled the packages selectively from testing some months ago Has anybody tried a build of libv8 in a pure wheezy system? I suspect you mean libv8-3.14 - libv8 is same version in stable, testing and unstable. I have not (yet) backported libv8-3.14 to stable, but I have backported nodejs-0.6.19~dfsg1 to stable, and backported uglifyjs, pegjs and jssip to stable infected by that nodejs backport: deb http://debian.jones.dk/ wheezy javascript - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] nodejs for wheezy-backports: FTBFS due to failing tests
Quoting Mike Gabriel (2013-10-25 09:11:59) Hi Jeremy, On Do 24 Okt 2013 20:32:33 CEST, Jérémy Lal wrote: On 24/10/2013 20:17, Mike Gabriel wrote: when I try to build nodejs from testing (0.10.20~dfsg1-1) for wheezy-backports, I get failures during the test runs [1]. This error, however, does not occur always. Today, one of the builds succeeded. All other builds failed so far. That test isn't used to fail... but is probably failing because of your particular setup: maybe a missing loopback interface, or IPv6-only, or restrictive firewall. Did you build it in a chroot ? I disabled my local firewall setup, that did the trick. For building packages I use sbuild/schroot. Thanks for pointing at my firewall setup! That worries me: Does that mean Nodejs testsuite rely on network access? That sounds wrong to me! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] nodejs for wheezy-backports: FTBFS due to failing tests
Quoting Mike Gabriel (2013-10-25 13:05:48) On Fr 25 Okt 2013 11:14:48 CEST, Jonas Smedegaard wrote: Quoting Mike Gabriel (2013-10-25 09:11:59) On Do 24 Okt 2013 20:32:33 CEST, Jérémy Lal wrote: On 24/10/2013 20:17, Mike Gabriel wrote: when I try to build nodejs from testing (0.10.20~dfsg1-1) for wheezy-backports, I get failures during the test runs [1]. This error, however, does not occur always. Today, one of the builds succeeded. All other builds failed so far. That test isn't used to fail... but is probably failing because of your particular setup: maybe a missing loopback interface, or IPv6-only, or restrictive firewall. Did you build it in a chroot ? I disabled my local firewall setup, that did the trick. For building packages I use sbuild/schroot. Thanks for pointing at my firewall setup! That worries me: Does that mean Nodejs testsuite rely on network access? That sounds wrong to me! The testsuite does some localhost testing. I don't think that access to 0.0.0.0 is needed. Only a loop device is requires AFAICouldT. However, I did not investigate any further. As Debian's buildd chroot's are offline when building, I guess we would have realized earlier, if the package requires network access... (then buildd builds would have failed IMHO). Thanks for confirming sanity :-) I did hope for the situation you describe, but better double-check than blindly assume all is well :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#727730: ITP: libjs-img.srcset -- fast JavaScript polyfill for img srcset
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk * Package name: libjs-img.srcset Version : 2.0.0 Upstream Author : David Knight * URL : https://github.com/weblinc/img-srcset * License : Expat Programming Lang: Javascript Description : fast JavaScript polyfill for img srcset img.srcset is a lightweight, no nonsense, all browser supporting, fast polyfill for img srcset, allowing for lighter yet backwards-compatible responsive web design. . The srcset attribute is an HTML extension for adaptive (a.k.a. responsive) images. More info at http://www.w3.org/TR/html-srcset/. . A polyfill is (in the context of HTML5) Javascript code implementation of a functionality often available in modern web browsers, allowing web designers to use simpler standards-compliant and declarative code, burdening only older/simpler browsers with these fallback snippets. libjs-img.srcset is a dependency of libjs-slidy (ITP bug#673634). ___ 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#728727: libjs-wax: obsolete - replaced by mapbox.js
Package: libjs-wax Version: 5.0.1+ds2-1 Severity: normal Homepage now contains the following: We’d highly recommend you use a current version of MapBox.js rather than Wax for all future projects, and consider porting your code! So it would probably be good to package MapBox.js and fase this one out. - Jonas ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-less for wheezy backports?
Hi Alexander,
Quoting Alexander E. Patrakov (2013-11-27 07:50:48)
I have noticed that you have backported nodejs and node-uglify to
Wheezy, and that you have put the following comment into node-less
debian/rules:
# Ease backporting (node-uglify is tough to backport)
# TODO: drop fallback-dependency after Wheezy
...which I interpret as an intention to backport node-less to Wheezy.
However, to date, there is no such backport. Why?
I wrote that comment. It is related to backporting in general, not
backports.debian.org specifically, and was written back when I still
expected Nodejs to be included in Wheezy (before the frustrating CTTE
committee ruling). Also, I forgot to take oldstable into account.
Comment is now adjusted in our git to this:
TODO: drop fallback-dependency when node-uglify is in oldstable
The existing source package from Jessie produces the binary packages
just fine under Wheezy + nodejs + node-uglify, except for the --help
issue (due to require('../lib/less/lessc_helper')) which is not
specific to Wheezy (and #693944 has a working patch).
Correct - obviously a missing build-dependency for a backport can be
solved by also backporting the build-dependency.
The fallback build-dependency mentioned in that comment is for
supporting stricter backporting rules than those governing
backports.debian.org.
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] membership please :)
Hi Dmitry, Quoting Dmitry Smirnov (2013-12-29 03:14:38) I'd like to join pkg-javascript team please (did my ~month-old Alioth request came through?). My Alioth login is onlyjob. Welcome to our team! :-D No, your request was hanging there unprocessed - sorry about that (most of us in the team - now including yourself - are admins, so it is odd that noone acted on it for so long). At the moment I'm motivated to work on d3 and jsdom (but not limited to). Sounds great! Please subscribe to this list if are aren't already. And read (the little we have yet of) documentation at https://wiki.debian.org/Javascript and referenced pages. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] about granting scm commit access to the alioth project
Greetings, fellow Javascript hackers, Quoting Jonas Smedegaard (2014-01-02 16:29:30) Quoting Jérémy Lal (2014-01-02 13:01:12) I wonder if there is a minimum official requirement for granting SCM commit access to newcomers. At most there is common practice and of that there is several: Alioth is provided by Debian and has the requirement that its use should be related to Debian, but apart from that we decide on our own how we want to work internally in our team. I like to avoid taking or giving orders from others, and since we use Alioth only as central hub for distributed resources (git and mailinglists) I see no need for hierarchy and routinely appoint super cow powers to any newcomer to our team. If others insist that we should have hierarchy and distrust newcomers until they somehow prove themselves worthy of higher power, then I will demote myself to the lowest power (and consider leaving the group). Noone commented on this part. Last call: If noone argues to the contrary, I will promote all team members to admin status one week from now. Speaking of which: I have till now mostly used collab-maint instead of our own git area to ease contributions from other Debian members. Alioth now (since some time) allows any team to grant write access to all official Debian members, similar to the access rights of collab-maint. Do anyone in this team disagree with enabling that additional right to our git, or is it ok that I enable it (and start move packages from collab-maint to our own git)? I have now granted all DDs write access to our team git repository. I will start move packages there that I have previously maintained at collab-maint, and suggest others to do the same. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] about granting scm commit access to the alioth project
Quoting Jérémy Lal (2014-01-29 18:23:16) Le lundi 27 janvier 2014 à 20:44 +0100, Jonas Smedegaard a écrit : Quoting Jonas Smedegaard (2014-01-02 16:29:30) I like to avoid taking or giving orders from others, and since we use Alioth only as central hub for distributed resources (git and mailinglists) I see no need for hierarchy and routinely appoint super cow powers to any newcomer to our team. If others insist that we should have hierarchy and distrust newcomers until they somehow prove themselves worthy of higher power, then I will demote myself to the lowest power (and consider leaving the group). Noone commented on this part. Last call: If noone argues to the contrary, I will promote all team members to admin status one week from now. Agreed, but before you do: what's the worst thing an abusing member with admin status can do to the project ? Worst I can imagine is erase/replace central git clones. OThers with a wilder imagination than mine? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#736551: Bug#736551: Please include jquery-hashchange
Quoting Jerome Charaoui (2014-02-01 18:26:34) Dear Maintainers, I am part of the Javascript team, but not involved in maintaining jQuery plugins specifically. If you're unavailable to integrate this patch and others queued in BTS, and publish an update of jquery-goodies to the archive, I would be happy to upload version 9-1 myself and have it reviewed by a sponsor. Did you consider the option of joining the Javascript team, to help maintain it long-term instead of only this single upload? Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] about granting scm commit access to the alioth project
Quoting Jonas Smedegaard (2014-01-27 20:44:47) Quoting Jonas Smedegaard (2014-01-02 16:29:30) Quoting Jérémy Lal (2014-01-02 13:01:12) I wonder if there is a minimum official requirement for granting SCM commit access to newcomers. At most there is common practice and of that there is several: Alioth is provided by Debian and has the requirement that its use should be related to Debian, but apart from that we decide on our own how we want to work internally in our team. I like to avoid taking or giving orders from others, and since we use Alioth only as central hub for distributed resources (git and mailinglists) I see no need for hierarchy and routinely appoint super cow powers to any newcomer to our team. If others insist that we should have hierarchy and distrust newcomers until they somehow prove themselves worthy of higher power, then I will demote myself to the lowest power (and consider leaving the group). Noone commented on this part. Last call: If noone argues to the contrary, I will promote all team members to admin status one week from now. Done: We now have equal powers within this team! I also dropped roles now no longer used in our team. Any of us can re-add them later if needed: we have equal powers. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request to Join Project Debian JavaScript Maintainers from François-Régis Vuillemin (frv-guest)
Hi François-Régis (cc js team list), Quoting nore...@alioth.debian.org (2014-03-06 17:18:48) François-Régis Vuillemin wrote (via Alioth register interface): Dear admins, Im beginning to package js libs embeded by fusionforge [1]. I could put my package on collab-maint but pkg-javascript seems better place. So please allow me to join the project. Thank you. [1] https://wiki.debian.org/DebianFrance/NewContributorGame#Javascript_libraries_for_FusionForge Welcome to the team! If you haven't already, please subscribe to our mailinglist and read our Policy (but please don't just obey it but suggest changes if you spot any odd details in it!). Both should be linked from here: https://wiki.debian.org/Javascript Looking forward to collaborate with you, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request to Join Project Debian JavaScript Maintainers from François-Régis Vuillemin (frv-guest)
Quoting François-Régis (2014-03-06 22:59:20) I've two packages I'll submit soon to your review and before my first question : 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. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JavaScript policy?
Quoting François-Régis (2014-03-25 01:07:20) Le 22/03/2014 12:37, David Prévot a écrit : Le 22/03/2014 05:33, Emilien Klein a écrit : On 03/21/2014 11:22 PM, François-Régis wrote: Le 21/03/2014 07:45, Emilien Klein a écrit : We may have something like : * Origin tarball should not include any minify code. Maybe there is a missing “sourceless” here: it’s perfectly fine for a source package to embed a convenient binary/prebuilt copy, as long as it is not used in the binary package, but instead rebuild it from source and ships the rebuilt version. In order not to make minified JavaScript any different, the first point should read: * Origin tarball should not include any sourceless minified code. I find that a sensible change to our Policy. But that does *not* mean that a non-minified Javascript file and a minified one in same tarball can blindly be assumed to be code-identical: You would still need to actually prove that somehow - e.g. by (re-)minifying both! This is exactly not what Marcelo said in [0] and its reference to [1] shows that he removes minifies files from origin tarball althought they have source files. [0] http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007176.html [1] http://anonscm.debian.org/gitweb/?p=pkg-javascript/flot.git;a=blob;f=debian/rules;h=83670cf0ec4aaec4817d6f2eb68d0756d85ac553;hb=HEAD I don't understand what point you are trying to make: Even with above change to our Policy, it is still very valid to continue to repackage tarballs stripping suspect code instead of the more tedious task of proving that they are indeed acceptable for us to redistribute. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JavaScript policy?
Quoting François-Régis (2014-03-26 23:50:08) Le 26/03/2014 23:45, Jonas Smedegaard a écrit : Quoting Emilien Klein (2014-03-26 22:10:31) The current policy is made using the assumption that minified == compiled. Arguably minification is not compilation, but neither is it the preferred form of modification. 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 program must include source code, and must allow distribution in source code as well as compiled form. Which is not arguable to remove minified versions of files which have sources in orig tarball. True - just make *sure* minified file match source file. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JavaScript policy?
Quoting Emilien Klein (2014-03-27 13:30:23) 2014-03-27 0:13 GMT+01:00 Ben Finney ben+deb...@benfinney.id.au: 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. 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 do you know for certain that they are related like that? We've got an implicit statement from upstream that the minified file comes from the source file: - same base name - distributed together - updated in the VCS for each release We could ask for an explicit statement from upstream that they are minifying the source file, although I wouldn't suggest doing this. Issue is not licensing, so indications or statements from upstream are irrelevant. Issue is certainty of computation. For us (if we use the code) and for our users (when we offer them the code through redistribution either in binary packages or in source tarball). To take another example: .jpg images. - those are not the source of the image (would be e.g. a Gimp project file) - they are obfuscated binary content (no human can read the content of a jpg file and tell you what it represents) - there is no copyright information embedded in the file itself - a .jpg is not the preferred form of the work for modifying that work (quality issues) - and even worse: Yet we redistribute those binary sourceless files in the binary package based (if the maintainer did his due diligence) on the upstream developer indicating these files are licensed under a DFSG-approved license. Two wrongs don't make a right ;-) Preferrably we should include sources also for JPEG files (e.g. SVG files) but that is not always possible (e.g. when source is not digital) or not sensible (e.g. when source is gigantic). 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. JPEG code is less important to keep strict source for than Javascript, because consequences of flaws or malware in JPEG are only visual (consequences beyond that is bugs in _interpreters_ of JPEG code). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#743152: Bug#743152: doesn't ship the version required for tilemill
Quoting Antoine Beaupré (2014-03-31 01:21:56) It turns out that tilemill depends explicitely on version 1.3.27, while Debian ships the 2.0 release, which is actually *older* that the 1.3 series: https://github.com/developmentseed/bones/releases I have seen this strangeness before, in fact in tilemill itself: https://github.com/mapbox/tilemill/issues/2258 So I am not sure how to deal with this. Maybe a removal from unstable and a new upload of 1.3 would avoid an epoch change... Nope - you would need to remove it from *all* users' systems too. This is exactly the situation you want to use an epoch. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Socket.io and node-ws, node-options module
Quoting Leo Iannacone (2014-04-23 18:47:01) node-options was included in node-ws as patch by Jérémy, so we do not need to package it. Seems a good idea to me to then add a Provides: node-options to node-ws and mention it in long description, to help locate it. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Call for review: should.js packages
Quoting Emilien Klein (2014-04-24 17:27:48) 2014-04-23 23:11 GMT+02:00 Jérémy Lal kapo...@melix.org: Le mercredi 23 avril 2014 à 23:02 +0200, Emilien Klein a écrit : - d/watch: have you thought about using Debian's Github redir service [0]? [0] http://githubredir.debian.net/ why use this, when native watch file do the job just fine ? That's a good question. I have been made aware of this redirector by Jonas when packaging jquery-lazyload [0]. That was 2 years ago. Github changed since to need no redirection. I now recommend to rely on Github structure directly. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
[replying via list - I see no need for discretion here] Hi Leo, Quoting Leo Iannacone (2014-04-29 10:31:35) I have seen you worked on node-express debian package last year. I'm going to update it to 4.1, are you still interested in maintain that package or I can pop your contact from Uploaders ? I see that you have not only updated, but virtually rewritten the packaging from CDBS to short-form dh sequencer. It is not polite to do such massive restructuring without prior coordination with those already directly involved in a package. I would prefer that you revert that. If you insist on keeping that change, then please do remove me as uploader for that package. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
Quoting Leo Iannacone (2014-04-29 11:56:46) On 29 April 2014 11:40, Jonas Smedegaard d...@jones.dk wrote: I would prefer that you revert that. If you insist on keeping that change, then please do remove me as uploader for that package. It depends. If you're still interest in this package then I will revert it. Sorry if that was not obvious: The reason I prefer that you revert is indeed because I am still interested in helping maintain that package. What other reason could it be? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
Quoting Leo Iannacone (2014-04-29 14:58:03) On 29 April 2014 12:20, Jonas Smedegaard d...@jones.dk wrote: Sorry if that was not obvious: The reason I prefer that you revert is indeed because I am still interested in helping maintain that package. Great!. I reverted package to cdbs. Since I do not really know it, can you please take a look at debian/rules ensuring everything is correct? Certainly! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Socket.io and node-ws, node-options module
Quoting Leo Iannacone (2014-04-29 23:26:30) About the packages' name. Would you use 'node-socket.io' or 'node-socketio' ?? node-socket.io - I see no need for mangling the dot. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
Quoting Jérémy Lal (2014-04-29 16:03:04) Le mardi 29 avril 2014 à 15:31 +0200, Jonas Smedegaard a écrit : I reverted package to cdbs. Since I do not really know it, can you please take a look at debian/rules ensuring everything is correct? Certainly! I have taken a look now - a thorough one. Hope you agree with the changes I made. Don't hesitate to ask if in doubt about any of it. In case you're missing the time, i can review and upload later today. I suspect you couldn't (or shouldn't) upload yet: At least node-parseurl is missing (I haven't checked further). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#745687: Bug#745687: new upstream version (2.x series)
Hi Ramakrishnan, Quoting Ramakrishnan Muthukrishnan (2014-04-24 04:00:58) I noticed that uglify has two series of releases and two upstream repositories maintained, one for 1.x versions and another for 2.x and Debian packages 1.x version. libjs-d3 upstream needs uglify version 2.4.0 but the debian package for libjs-d3 depends on 1.x series packaged on Debian. It will be great if the 2.x version of uglify is packaged and made available in the unstable. Thanks for filing this as a bugreport. Work is underway to package UglifyJS2 in the master-experimental branch of git://git.debian.org/git/pkg-javascript/uglifyjs.git . Status of packaging is that these libraries needs packaging first: node-source-map node-uglify-to-browserify Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
Quoting Jérémy Lal (2014-04-30 01:43:03)
Le mercredi 30 avril 2014 à 00:46 +0200, Jonas Smedegaard a écrit :
Hope you agree with the changes I made. Don't hesitate to ask if in
doubt about any of it.
Damn copyrighted ICC profile in the png file !
I didn't build the package before, is this something caught by
copyright-check ? lintian ?
copyright-check wasn't enabled until now. It didn't reveal the actual
problem, only hinted about binary data needing further investigation.
Related to this: DPKG does not like binary data in debian dir, so to
avoid binary noise ending in the copyright_hints file, those files need
to be excluded from copyright-check. Previously I did just that -
relying on then checking manually those exluded files at each source
change. Recently I have begun to instead extending copyright check: See
the packages ruby-compass and ghostscript for the details.
The routine is dead slow currently. Suggestions for optimizations is
appreciated. When polished a bit I may include it in CDBS.
About package.json:
My idea was to include package.json as part of the module, because
* it is common practice to `require('./package.json').version` inside a
module, among other things
* eventually, being able to propose a npm-integration debian
package, much like rubygems-integration, would require access to
package.json files.
* looking for package.json is hard-wired into nodejs, it's really not
only about npm.
Granted, if you disagree that won't prevent node-express from running.
If you agree then it's only natural to keep the same relative tree as
the one expected by package.json
Ok - sounds reasonable that we consistently include package.json, then.
Will you update our wiki page about that?
(...unless anyone else objects, of course)
(that's why the lib/ dir was installed in the particular case of
express, instead of the files within). It saves a patch...
I don't follow: How is install paths related to package.json inclusion?
In case you're missing the time, i can review and upload later today.
I suspect you couldn't (or shouldn't) upload yet: At least node-parseurl
is missing (I haven't checked further).
Yes, it's waiting in NEW.
Great.
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
Quoting Leo Iannacone (2014-04-30 10:20:28) On 30 April 2014 02:39, Jérémy Lal kapo...@melix.org wrote: Interesting. Really, which tools do you use to inspect files covered by some copyright in a software? Depends on the needs - concretely I currently use exiftool and otfinfo. For more details please debcheckout ruby-compass (as I suggested), and let me guide you as needed in inspecting. Package is not big. If /usr/lib/nodejs/express/package.json exists, nodejs uses it to find the entry point of the module. Here more info about: http://nodejs.org/api/modules.html#modules_folders_as_modules Thanks for that! Really cool! I am still puzzled, however, on the concrete need for node-express to preserve its source structure to avoid patching package.json, as I see no name/main declarations in that specific package.json file. Regards, - Jonas P.S. I highly appreciate your practice of stripping irrelevant parts from your response, but suggest to consider including slightly more context than you did above - I find that my response is somewhat non-sensical due to the underlying parts missing. -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Debian node-express
Quoting Jérémy Lal (2014-04-30 11:59:08) Le mercredi 30 avril 2014 à 11:45 +0200, Jonas Smedegaard a écrit : Quoting Leo Iannacone (2014-04-30 10:20:28) On 30 April 2014 02:39, Jérémy Lal kapo...@melix.org wrote: If /usr/lib/nodejs/express/package.json exists, nodejs uses it to find the entry point of the module. Here more info about: http://nodejs.org/api/modules.html#modules_folders_as_modules Thanks for that! Really cool! I am still puzzled, however, on the concrete need for node-express to preserve its source structure to avoid patching package.json, as I see no name/main declarations in that specific package.json file. In that specific case, it is indeed unneeded. My personal preference is to not change it, and apparently yours is to change it - no problem with that, isn't it ? We can agree to disagree, yes, if that's what you mean. I just wanted to make sure I wasn't missing some valuable point that afected also this specific case. Seems that's not the case :-) Thanks to both of you for educating me about the general case! Having insight on that is obviously more important when being more aggressive in tidying while packaging, as I tend to do. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Mocha in Debian
Quoting Leo Iannacone (2014-04-30 23:26:44)
On 30 April 2014 23:11, Jérémy Lal kapo...@melix.org wrote:
It's not all right to remove other files without good reasons.
Here, you can have a doubt about the license of the other css file, but
there is no doubt the js file is correctly licensed, so no reason to
prune it.
But ... does it make sense leave snip of code that does not work?
I mean, if you `apt-get source' the package you will see run
bechmark/index.js. You may want to exec it.. and then??
It fails.. because try to open large.css, excluded from source.
$ grep css benchmark/index.js
var small = fs.readFileSync('benchmark/small.css', 'utf8');
var large = fs.readFileSync('benchmark/large.css', 'utf8')
Is it not better in this case remove the whole directory?
The better approach is not to remove more code, but to complement the
minimal code stripping with a patch that makes the remaining code work
again.
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#745687: Bug#745687: new upstream version (2.x series)
Quoting Jérémy Lal (2014-04-30 21:09:41) Le mercredi 30 avril 2014 à 14:34 +0200, Jonas Smedegaard a écrit : Quoting Jérémy Lal (2014-04-30 12:53:22) Le mercredi 30 avril 2014 à 12:35 +0200, Leo Iannacone a écrit : On 30 April 2014 02:10, Jonas Smedegaard d...@jones.dk wrote: Status of packaging is that these libraries needs packaging first: node-source-map node-uglify-to-browserify About node-uglify-to-browserify: You do not really need to package it, since it's only related to uglify2.x (it has no reverse-dependency) I think you can bundle it as a patch along with uglify v2.x. I am no fan of hiding upstream projects by maintaining as bundles in Debian. If in fact it makes best sense for node-uglify-to-browserify to be part of UglifyJS2 project, it makes more sense for me to have upstream merge those projects. Or did I perhaps misunderstand your suggestion? You understand correctly. I'm less strict about bundling... i'm using that workaround rarely, though. Anyway it doesn't matter here since in fact, uglify-to-browserify is A transform to make UglifyJS work in browserify. I propose we postpone packaging of this module and list it in Suggests for now. Agreed. About node-source-map: It build-depends on dryice (=0.4.8). You can find a pre-release package in pkg-javascript/node-dryice.git repository. Once it done/uploaded to unstable, we will be able to build source-map. I can help about that, Great! but could you find out about the dependency loop: dryice depends on uglify-js I suspect that such dependency would be only needed only for browser use, not for use in a Nodejs environment (which includes build environment for UglifyJS2). If that's true, I suggest to simply add hinting as documented here: https://wiki.debian.org/BuildProfileSpec I don't understand how that helps. In fact we have a simple uglify - sourcemap+dryice - uglify dependency loop. Sorry - I was thinking *build*-dependency loop. You are right, such hinting is of no help here. We could patch a little dryice so that it doesn't Depends uglify-js but only Recommends or Suggests it. Do i remember well ? would that be enough ? Sounds good. Seems the code already warns + returns uncompressed data if uglification fails, so possibly it is as simple as hacking the requires check. ...but I'd feel much safer leaving that in your hands :-D Related to the point above, it's interesting to note that dryice is a good example of what we could ask upstream to merge back into source-map. I'll leave that to you too. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-express is now *broken*
Quoting Jérémy Lal (2014-05-01 09:36:52) Le jeudi 01 mai 2014 à 08:02 +0200, Jonas Smedegaard a écrit : Quoting Jérémy Lal (2014-04-30 01:43:03) Le mercredi 30 avril 2014 à 00:46 +0200, Jonas Smedegaard a écrit : Quoting Jérémy Lal (2014-04-29 16:03:04) In case you're missing the time, i can review and upload later today. I suspect you couldn't (or shouldn't) upload yet: At least node-parseurl is missing (I haven't checked further). Yes, it's waiting in NEW. That was apparently only node-parseurl which I explicitly mentioned. node-express is now broken in sid, as it depends on non-existing node-serve-static! It's also sitting in NEW. Oh. Good. I don't get how node-parseurl got accepted sooner. ...and I don't get how I forgot to check NEW queue before whining :-/ - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#745687: Bug#745687: Bug#745687: Bug#745687: new upstream version (2.x series)
Quoting Jérémy Lal (2014-05-01 21:57:48) About node-source-map: It build-depends on dryice (=0.4.8). You can find a pre-release package in pkg-javascript/node-dryice.git repository. Once it done/uploaded to unstable, we will be able to build source-map. We could patch a little dryice so that it doesn't Depends uglify-js but only Recommends or Suggests it. Do i remember well ? would that be enough ? Sounds good. My mistake, dryice is tied to uglify too much - it uses uglify's Abstract Syntax Tree to walk the code and find 'require(module)'. I cannot make that optional without cutting dryice legs. On the other hand, uglifyjs2 only needs source-map for the cases where one uses --source-map, something that is not used by source-map (pardon the tautology). I'll push this evening a patch on the master-experimental branch of uglifyjs, just tell me if that's not right. That's perfect :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] npm2deb in debian
Quoting Jérémy Lal (2014-05-03 16:55:35) Le samedi 03 mai 2014 à 15:55 +0200, Leo Iannacone a écrit : Hello there, I'm looking for a sponsor for npm2deb: http://anonscm.debian.org/gitweb/?p=pkg-javascript/npm2deb.git some python developer around? Note that i'm all right with reviewing and uploading it, but it'd be very nice if a debian-python developer had a look at the python packaging part. Jérémy. (Please keep discussion into pkg-javascript-devel or cc to it) If acceptable to use CDBS, I can review and help maintain the packaging. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)
Quoting Emilien Klein (2014-05-05 10:09:19) 2014-05-05 0:32 GMT+02:00 Daniel Kahn Gillmor d...@fifthhorseman.net: 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. The current policy is to repackage the upstream tarball if it contains a minified file, and regenerate the minified files as part of the build process. This has been debated in March (please see the first message on this email thread for details). Although my original position is the same as what you outline, the outcome of the discussion is that the current policy will not be changed. I am thus currently pushing to get the policy formalized, by explicitly referencing it on our policy page. What exactly do you mean by formalized? I believe Jérémy suggested improving the Debian-wide documentation for best practices - Developers Reference. Daniel is talking about Debian Policy. Seems you are talking about a policy for this team. I see no need for this team to have a policy more strict than Debian generally regarding tarball repackaging. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)
Quoting Emilien Klein (2014-05-05 12:16:25) 2014-05-05 11:07 GMT+02:00 Jonas Smedegaard d...@jones.dk: [skipping parts on who said what: lacks consensus] I see no need for this team to have a policy more strict than Debian generally regarding tarball repackaging. 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. Sorry, but I can only read it as you contradicting yourself above... Which requirements if not ones restricting beyond Debian in general? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)
Quoting Emilien Klein (2014-05-05 20:57:39) 2014-05-05 18:59 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting Emilien Klein (2014-05-05 12:16:25) 2014-05-05 11:07 GMT+02:00 Jonas Smedegaard d...@jones.dk: [skipping parts on who said what: lacks consensus] I see no need for this team to have a policy more strict than Debian generally regarding tarball repackaging. 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. Sorry, but I can only read it as you contradicting yourself above... The policy of removing upstream-provided minified files comes from the interpretation of DFSG §2. So stating this policy on our policy page is not being stricter than Debian in general, just being clear on the workflow that packages maintained by the team must follow. As recent discussions (not so much here but) at debian-devel@d.o. have shown, there is more than one interpretation of DFSG §2. So stating in a policy for this team how team members must interpret Debian Policy is indeed more strict than Debian generally. I dearly appreciate your efforts trying to get this clarified, but believe Policy should be defined in Debian generally, not here specifically. I prefer that for this team we do not dictate, only recommend best practices. Or do we really want to have this debate started again for each new package asking the team to be reviewed? I believe we need not have same debate for each new package, if we document what we (or most of us) find to be best practices. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)
Quoting Emilien Klein (2014-05-05 23:35:34) 2014-05-05 21:31 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting Emilien Klein (2014-05-05 20:57:39) Or do we really want to have this debate started again for each new package asking the team to be reviewed? I believe we need not have same debate for each new package, if we document what we (or most of us) find to be best practices. What is your suggestion for documenting that? Somewhere below https://wiki.debian.org/Javascript. If calling the page Policy implies strict rules, then I would prefer not writing it there but instead at e.g. Guidelines or BestPractices. What do others think? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#747246: libv8-3.14: Add support for hurd-i386
Hi Svante, Thanks for working on the Hurd! Quoting Svante Signell (2014-05-06 21:44:54) On Tue, 2014-05-06 at 20:29 +0200, Jérémy Lal wrote: * can you submit the patches to upstream ? I can do that if you want, do they have a BTS or development list? Like all Debian packages, that information is in debian/copyright: Upstream-Contact: the V8 Project Authors v8-...@googlegroups.com - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] JS policy: repackaging upstream tarball when minified js files are present (was: Call for review: should.js packages)
Quoting Emilien Klein (2014-05-07 09:08:11) 2014-05-06 7:58 GMT+02:00 Jérémy Lal kapo...@melix.org: Le mardi 06 mai 2014 à 02:57 +0200, Jonas Smedegaard a écrit : Quoting Emilien Klein (2014-05-05 23:35:34) 2014-05-05 21:31 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting Emilien Klein (2014-05-05 20:57:39) Or do we really want to have this debate started again for each new package asking the team to be reviewed? I believe we need not have same debate for each new package, if we document what we (or most of us) find to be best practices. What is your suggestion for documenting that? Somewhere below https://wiki.debian.org/Javascript. If calling the page Policy implies strict rules, then I would prefer not writing it there but instead at e.g. Guidelines or BestPractices. I guess I understand my confusion now: In the debate last 2 months, there were some pretty strong arguments advanced why keeping the minified files was breaking the social contract (and thus RC-worthy) I looks like now that it is not necessarily as black and white. That has not changed: Some (including me) pretty strongly believe that keeping the minified files (not breaks not the social contract but) is in violation of Debian Policy and thus worthy of release-candidate bugs. It is up to those choosing not to follow guidelines to defend their reasoning that that is not the case. Just as before. Let's thus keep this as a recommendation/guideline/best practice for our team, and see how/if the debate comes to a resolution at the level of the entire project. Please note that I only claim guidelines can *help* avoid discussion - by either a) clearly documenting what is safe to do if you don't want trouble, or b) summarizing the essentials of one half of the debate - ideally cutting future threads in half. Imagine threads where half the posts are shrunk to stuff like How is your $foo compliant with Debian Policy §§x.y? Point $bar in our guideline addresses that.. Who can put Jérémy's text at the location Jonas mentions? Anyone understanding how wiki works and able to get a wiki.debian.org user account. :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] About node-expect.js (ITP)
Quoting Leo Iannacone (2014-05-08 15:44:45) I have prepared node-expect.js[0]. But I have some doubt about .. This module is not only for node.js module, but can be used also as simple javascript in a browser (tested and it works). So... should we provide also a libjs-expect.js package ? If yes.. in this package should I make a link to node-module-file or copy the file in usr/share/javascript ? Right now I have only node-expect.js and I did this in debian files: debian/control: Package: node-expect.js Provides: libjs-expect.js debian/links: usr/lib/nodejs/expect.js/index.js usr/share/javascript/expect.js Is it the wrong way to provide both javascript and node module at same time? libjs-* (but not node-*) code should be minified. libjs-* (but not node-*) packages should recommend javascript-common. node-* (but not libjs-*) packages should depend on nodejs. ...so even if code is identical, it seems better to me to ship as separate packages. (I seem to recall that I've made that same Provides: hack, but don't recall which package it was - I should fix it there too). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Naming node packages with binaries
Quoting Leo Iannacone (2014-05-08 19:38:57) AFAIK.. when a binary is present in a package, the package should have the be named as the binary. If code project is _mainly_ that binary, then yes. But for project known and Shit with binary the_shit, I'd name the package shit. But.. this is not so clear for node modules. For instance, for mocha, according with javascript policy, I should ship a package called `node-mocha' rather than one simply called `mocha'. This seems to be in contrast with perl policy (I think with python too). Should we follow this cli_based_name policy and rename those packages having binaries ? Sure - node-* name is for node _modules_, not anything-related-to-node. David Prevot suggests in chan: taffit maybe a Provides: node-$stuff could help in the dependency chain if needed Yes, if code project is mainly a binary but also a Nodejs module. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Updating wrong debian watch files
Quoting Leo Iannacone (2014-05-14 09:18:09) in DMD[0] we have 53 packages with a broken watch file. I wrote a script[1] able to fix most of them. Nice work! Please beware that not all JavaScript packages are maintained in this team. The devscripts package has tools to get in touch with authors of packages - e.g. the dd-list script (but possibly other tools as well). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Updating wrong debian watch files
Quoting Leo Iannacone (2014-05-14 13:12:31) On 14 May 2014 09:28, Jonas Smedegaard d...@jones.dk wrote: Quoting Leo Iannacone (2014-05-14 09:18:09) in DMD[0] we have 53 packages with a broken watch file. I wrote a script[1] able to fix most of them. Nice work! Please beware that not all JavaScript packages are maintained in this team. The devscripts package has tools to get in touch with authors of packages - e.g. the dd-list script (but possibly other tools as well). Do you mean: be sure to have reached all maintainers In other words: use dd-list and forward your email to co-maintainers? Almost. More accurately I mean that it looks like you intended to share some information with the package maintainers of a bunch of packages - if that's the case then please consider using a tool like dd-list to better reach those developers (i.e. don't assume they follow this list). Your use of quotes in your follow-up email seems to indicate that you are referring to some documentation somewhere, perhaps one on best practice when doing a mas bug-filing. I do not imply that you are necessarily doing a mass bug-filing so do not dictate you to use a specific procedure - I simply want to make you aware of tools that might be helpful for you in whatever it is you are trying to do here. :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#752823: Bug#752823: buddycloud-server: not installable in sid
Quoting Ralf Treinen (2014-06-26 21:36:05) Hi, buddycloud-server is not installable in sid on any architecture, for different reasons (see below). This is the case at least since 2014-04-05. Right. Thanks for reporting this. I am aware of it, however - I do intend to try get it back in working condition, hopefully before the freeze. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] What's the best section for JS packages?
Quoting Leo Iannacone (2014-06-27 10:25:17) all of my packages (most of them are node modules) have Section: web in debian/control. Do you think is not a happy choice? is `misc' better? and what about JavaScript packages? If the main use is related to web, then that's indeed a good choice. It might make sense to request new section for javascript and/or Nodejs libraries (but not for applications implemented in those scripting languages) at some point - try compare number of packages with those of other sections to get a feeling when that might be relevant to propose (I guess that should then be raised on debian-devel list. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] whether or not to sometimes remove questionably useful binaries from node modules
Quoting Jérémy Lal (2014-07-01 16:35:59) Andrew, modifications you make to the upstream files are supposed to be done in one of two ways (and directly removing files from the gbp repository is not a way): - repackage upstream tarball to exclude files for DFSG reasons The simplest way to do that is through [0] and uscan. The fact a upstream tarball was repackaged is advertised in the version of the debian package, like 3.0.1+dfsg-1 ...and if doing above, you also must mention in debian/copyright which files were stripped. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] About mime-types module
Quoting Leo Iannacone (2014-07-02 10:13:05) I would like to package mime-types for Debian. https://github.com/expressjs/mime-types Now.. during build, upstream makes HTTP requests to get mime information externally and stores that in local files (already present in git repository) - see build.js file in the repository. As far as I remember, making internet connections during package-build is not allowed (am I wrong?.. is it only for Ubuntu?). Correct: Build must be deterministic (possible to replay), which excludes network access. On the other hand, as far as I understood, I should not include those files already downloaded and parsed by build.js and stored in lib/* directory... Right - you lack source for files files. So, what can I do in this case? Allow internet connections during build or use pre-downloaded files ? Would it perhaps be possible to put together a script that creates same data from the data shipped in mime-support package? Then that script could either be used once at build time, or better be used at install time (stored below /usr/lib and symlinked from there if needed) and at will whenever the admin wants to update the database to reflect changes in master files. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] What's the best section for JS packages?
Quoting Leo Iannacone (2014-07-02 10:05:36) On 27 June 2014 15:50, Jonas Smedegaard d...@jones.dk wrote: Quoting Leo Iannacone (2014-06-27 10:25:17) all of my packages (most of them are node modules) have Section: web in debian/control. Do you think is not a happy choice? is `misc' better? and what about JavaScript packages? If the main use is related to web, then that's indeed a good choice. It might make sense to request new section for javascript and/or Nodejs libraries (but not for applications implemented in those scripting languages) at some point - try compare number of packages with those of other sections to get a feeling when that might be relevant to propose (I guess that should then be raised on debian-devel list. I think this is the best time to ask for a new section. We have already many node modules packaged (211) and the number is increasing day by day. It makes no sense to me waiting more time... Fine with me, I just won't lead it myself (simply because I have plenty on my hands elsewhere). Just made a search in my mail archive (for apt section introspection) - and seems it need no larger discussion, just a plain bugreport: See lists.debian.org/87iplw8px9@lennier.ganneff.de and the 3 bugreports closed by that mail. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] 500k javascript needs 175MB git source?!?
Hi, I just saw libjs-mediaelement has entered unstable which I need for a project, so I went to make a backport of it and did a debcheckout - and got a surprise: jonas@bastian:~/src/TMP/libjs-mediaelement$ debcheckout libjs-mediaelement declared git repository at git://anonscm.debian.org/pkg-javascript/mediaelement.git git clone git://anonscm.debian.org/pkg-javascript/mediaelement.git libjs-mediaelement ... Cloning into 'libjs-mediaelement'... remote: Counting objects: 9595, done. remote: Compressing objects: 100% (4086/4086), done. remote: Total 9595 (delta 5488), reused 9594 (delta 5488) Receiving objects: 100% (9595/9595), 175.26 MiB | 923.00 KiB/s, done. Resolving deltas: 100% (5488/5488), done. Checking connectivity... done. 175MB? Seriously? It looks like upstream is using the git not only for source but also as distribution medium for binary code in the build dir. I strongly recommend to try redo the Debian git - either without tracking upstream or with their git mangled to strip the build dir throughout the whole history of the git (see git help filter-branch). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760297: Bug#760297: libjs-mediaelement: completely useless without the flash/silverlight parts
Quoting David Prévot (2014-09-02 21:50:54) Control: severity -1 wishlist You honestly consider lack of those parts merely a wish, no bug at all? Control: rename -1 Please, (build and) ship Flash and Silverlight parts Le 02/09/2014 12:29, Jonas Smedegaard a écrit : The very purpose of MediaElement.js is to act as a polyfill for browsers that does not support html5 audio and video tags, and it does so by use of either flash or silverlight code. As (not enough) documented in the package description and (better) in the upstream homepage, the purpose is to offer an unified interface in order to offer the same experience whatever the browser. The Flash or Silverlight shim are only used if needed to help legacy browsers not HTML5-compatible to mimic those expectations. The middle-term goal is of course to offer the the Flash and Silverlight shims, but the upstream build process was not really open and properly documented at the time the package was uploaded to Debian. Let's see - here are the bullet points from the front page: * HTML5 audio and video players in pure HTML and CSS. * Custom Flash and Silverlight players that mimic the HTML5 MediaElement API for older browsers * Accessibility standards including WebVTT Of those, the first point is not Javascript at all, the second is not working at all, so your argument must be related to the third somehow. Please elaborate!! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760297: Bug#760297: libjs-mediaelement: completely useless without the flash/silverlight parts
severity 760297 grave thanks Quoting Jonas Smedegaard (2014-09-03 13:37:23) Quoting David Prévot (2014-09-02 21:50:54) Le 02/09/2014 12:29, Jonas Smedegaard a écrit : The very purpose of MediaElement.js is to act as a polyfill for browsers that does not support html5 audio and video tags, and it does so by use of either flash or silverlight code. As (not enough) documented in the package description and (better) in the upstream homepage, the purpose is to offer an unified interface in order to offer the same experience whatever the browser. The Flash or Silverlight shim are only used if needed to help legacy browsers not HTML5-compatible to mimic those expectations. The middle-term goal is of course to offer the the Flash and Silverlight shims, but the upstream build process was not really open and properly documented at the time the package was uploaded to Debian. Let's see - here are the bullet points from the front page: * HTML5 audio and video players in pure HTML and CSS. * Custom Flash and Silverlight players that mimic the HTML5 MediaElement API for older browsers * Accessibility standards including WebVTT Of those, the first point is not Javascript at all, the second is not working at all, so your argument must be related to the third somehow. Please elaborate!! Let's not complicate matters by allowing this package to enter testing, until we agree that it is suitable for general use. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Processed: severity of 760297 is wishlist
Quoting Debian Bug Tracking System (2014-09-04 23:24:05) Processing commands for cont...@bugs.debian.org: # Please, stop overriding the maintainer’s call without reason. severity 760297 wishlist Bug #760297 [libjs-mediaelement] Please, (build and) ship Flash and Silverlight parts Severity set to 'wishlist' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. I ask a question - you just silently play severity ping-pong here. That pisses me off. What do others in the team think of this bug? If this is the quality of packaging in this team, I seriously consider no longer wasting my time here. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760297: Is MediaElement.js fit for testing?
Quoting David Prévot (2014-09-05 03:57:02) On Fri, Sep 05, 2014 at 01:21:52AM +0200, Jonas Smedegaard wrote: Quoting Debian Bug Tracking System (2014-09-04 23:24:05) # Please, stop overriding the maintainer’s call without reason. I ask a question I already pointed at explanations before, ...and I pointed out how that reference did not answer the question. I just want you to stop playing, and advise you to get in touch with the release team if you want them to enforce an RC-bug here. Yes, that's an option if we cannot work as a team. Or one of us can leave the team. Now, to the facts: - MediaElement is currently embedded in at least two packages (wordpress and owncloud). As such, preventing the current package to enter testing is pointless (it’s already there), and harmful (code duplication, security tracking, etc.) Removing (all or some of) MediaElement from wordpress and owncloud packages do not render those packages mostly useless by their users. Whether that is also true for the js-mediaelement package depends on answer to my question. - All functionalities of the package are not yet enabled, and that is documented in the package description. As proven (at least via owncloud: I’ve not investigated how/if the media playing works in wordpress), the current package allows to play video and audio in a browser, which make it all but useless. Please elaborate on that proof: Is the opposite true - i.e. if MediaElement is completely missing do owncloud then no longer allow playing video and audio in a [modern] browser? - Since the initial packaging that has been approved by ftpmasters, upstream documented a way to rebuild the Flash parts. They use Flex SDK to do so (the present bug as been documented as blocked by the relevant RFP one day after you opened it). Ftpmaster approval relates to legality, and therefore irrelevant for this discussion on qualitative assesment of the package. Great that there is hope that MediaElement some day can make sense to package. Use an alternative build system to the one used upstream, (e.g., as3compile from swftools). I already tried [building with swftools], but back then, the package wasn’t yet accepted in the archive, which made the effort less attractive. Hence the question if the approach you considered attractive produces relevant result for our users: Do we currently ship the main functionality of MediaElement or a smaller/different subset than that? Can you please elaborate on that question. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Processed: severity of 760297 is wishlist
severity 760297 grave thanks Quoting Jérémy Lal (2014-09-05 01:37:37) Le vendredi 05 septembre 2014 à 01:21 +0200, Jonas Smedegaard a écrit : [David wrote - via cont...@bugs.debian.org:] # Please, stop overriding the maintainer’s call without reason. I fully agree. Maintainer of this package is the Javascript team Reason for grave severity is to keep this package from entering testing, because it is considered unsuitable in its current form (sorry if that was somehow unclear from my previous posts). What do others in the team think of this bug? I agree mediaelementjs cannot go into testing like this - at least not without a better reason than it's too hard to properly package half of it. If that's really the case - the plugins cannot be recreated from source without a crazy deal of work - package them in non-free and put mediaelementjs in contrib. Thanks for your input, Jérémy. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760297: Processed: retitle 760297 to Please, (build and) ship Flash and Silverlight parts
retitle 760297 libjs-mediaelement: should (build and) ship Flash or Silverlight parts thanks Point of this bug is a) that the package is useless without those parts (hence should instead of please) and need only one of the fallbacks for proper media element implementations (hence or instead of and). Also, titles should generally be prefixed with their package name. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760297: Bug#760297: The BTS is not a ping-pong table (or it is?)
Quoting David Prévot (2014-09-05 15:05:50) Control: severity -1 important On Fri, Sep 05, 2014 at 11:49:12AM +0200, Jonas Smedegaard wrote: severity 760297 grave Really, again? I would certainly prefer dialogue. Sadly you apparently treat my question (at bottom of https://bugs.debian.org/760297#21) as flamebait. [David wrote - via cont...@bugs.debian.org:] # Please, stop overriding the maintainer’s call without reason. I fully agree. Maintainer of this package is the Javascript team That’s fixed now, thanks again to your valuable input. https://anonscm.debian.org/cgit/pkg-owncloud/mediaelement.git/commit/?id=d1f88116baff56bb4ae1c5ed54529b6905bcef8d Sad that you choose that over teamwork. Make an official Debian package release which includes above git commit, and I shall stop consider myself co-maintainer of the package. I still look forward to your answer to https://bugs.debian.org/760297#21 - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] please push all node-postgres gbp branches
Hi Jérémy, [I dare reply via our public list - hope you don't mind] Quoting Jérémy Lal (2014-09-06 08:07:46) i just noticed that there was something missing to the gbp repo. Right - thanks for spotting that. I've pushed in now, and will finalize that (old!) release now. Besides that, will you have time to update it ? It's at 3.4.2 now. Newest node-postgres seems to need these modules missing in Debian: buffer-writer: 1.0.0, pgpass: 0.0.3, packet-reader: 0.2.0, pg-connection-string: 0.1.1, pg-types: 1.4.0 Help is much appreciated getting those packaged! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] please push all node-postgres gbp branches
Quoting Leo Iannacone (2014-09-07 10:21:24) On 6 September 2014 14:30, Jonas Smedegaard d...@jones.dk wrote: Quoting Jérémy Lal (2014-09-06 14:16:21) Le samedi 06 septembre 2014 à 12:59 +0200, Jonas Smedegaard a écrit : Newest node-postgres seems to need these modules missing in Debian: buffer-writer: 1.0.0, pgpass: 0.0.3, packet-reader: 0.2.0, pg-connection-string: 0.1.1, pg-types: 1.4.0 Help is much appreciated getting those packaged! I'm pretty sure i could team up with Leo (if he's available) to get the packages done in the day... but there's an ongoing discussion about bundling modules, so i wonder if it is a good occasion to start one. What do you think ? I am no fan of bundling! I appreciate the concern for keeping resources tight, but have seen no actual measurements as to the damage caused by tracking upstream projects individually - and I see a real damage to bundling in that it weakens tracking our upstreams (are bundled jQuery plugins up-to-date? How to check that - as a developer and as a user?). Perl team has recently gone _away_ from bundling modules. ...but I still remember when I adviced you to not taking serious the complaints about the node name - we lost ~3 years on that account :-( So I guess my advice is to _not_ listen directly to what I think, but only take it as inspiration - try distinguish between noise and substantial parts from those frowning upon tiny packages. I agree that a package containing essentially a single line of code is insane. What do anyone in the team think? Are we messing up with those small modules? If it works, then it works! If you can manage to track upstream changes and keep the bundle-packages sensibly up-to-date and their contents is reasonably easy to locate for our users, then I guess it is a success. And... should we have a max-lines-of-code number under of that the module should go in a multi-module package ? I am sceptical to such quantitative measure. But then again, I am sceptical to the whole approach so should probably step back and let those exploring the approach discuss here :-) My point was not that recent activities on bundling tiny Node packages has failed, but that a) I most likely won't participate in that and b) I recommend to beware if really needed (do the critical voices in Debian indicate real trouble e.g. with Policy or just a loud minority opinion). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-tap available - run tests !
Quoting Jérémy Lal (2014-10-20 16:33:56) from a local search through package.json files, it seems there are at least twenty node modules that could run tap tests now. Mind that runforcover is not packaged, so code coverage won't work. Could you please provide some (reference to) examples on how to do that? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-tap available - run tests !
Quoting Jérémy Lal (2014-10-20 17:21:37) Le lundi 20 octobre 2014 à 17:09 +0200, Jonas Smedegaard a écrit : Quoting Jérémy Lal (2014-10-20 16:33:56) from a local search through package.json files, it seems there are at least twenty node modules that could run tap tests now. Mind that runforcover is not packaged, so code coverage won't work. Could you please provide some (reference to) examples on how to do that? no idea about how to run code coverage option ! it's an experimental feature, as advertised in node-tap README file. ...but you probably asked how to run tap tests: in debian/rules test target: tap test/*.js should be enough. Thanks! Yes, that's what I meant to ask about :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] interest in reverse dependencies of dropped buddycloud?
Hi, Buddycloud is now dropped (upstream has abandonded it and moved to a Java-based reimplementation), which leaves behind some Nodejs packages with no reverse dependencies: * node-ain2 * node-jsconfig * node-pg (src:node-postgres) * node-underscore.logger (src:underscore.logger) Do you find any of above packages relevant to keep, then please adopt and drop me as uploader. After Oct. 26th (i.e. when window for updates reaching Jessie is lost) I will request ftpmaster to drop those of above still listing me as uploader! The packages below are no longer have reverse dependencies, but those I want to keep maintaining (even if they might not make it into Jessie): * node-node-xmpp (src:node-xmpp) * node-node-stringprep (src:node-stringprep) * node-node-expat (src:node-expat) * node-ltx (src:ltx) Help getting those into shape is quite appreciated (just don't change packaging style away from its current use of CDBS). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#768363: adjust font-awesome dependency version
Quoting Daniel Pocock (2014-11-06 20:43:48) The font-awesome package has a ~ symbol in the dfsg version. Therefore, depending on the constraint (= 4.2.0) doesn't match the version 4.2.0~dfsg-1 Relax the dependency to depend on (= 4.1.0~dfsg) Dependency should be 4.2.0~dfsg (i.e. 2 instead of 1). Perhaps simply a typo... Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#768363: adjust font-awesome dependency version
Quoting Daniel Pocock (2014-11-06 21:24:45) On 06/11/14 21:22, Jonas Smedegaard wrote: Quoting Daniel Pocock (2014-11-06 20:43:48) The font-awesome package has a ~ symbol in the dfsg version. Therefore, depending on the constraint (= 4.2.0) doesn't match the version 4.2.0~dfsg-1 Relax the dependency to depend on (= 4.1.0~dfsg) Dependency should be 4.2.0~dfsg (i.e. 2 instead of 1). Perhaps simply a typo... Not quite, 4.1.0~dfsg appears to be sufficient for this and it is in backports. Fair enough - I just reacted based on your own words above doesn't match the version 4.2.0~dfsg-1, which does not explain why it is ok to relax even further. In case you want release team to process this for Jessie, it might make sense to elaborate a bit why relaxing even further is ok - as there is nothing particular mentioned in changelog of fonts-font-awesome¹. - Jonas ¹ not font-awesome - again I guess it's just a typo here in the bugreport but mentioning to be on the safe side. -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#761670: Bug#761670: impossible to bootstrap build of node-jake and node-utilities: (build-)dependency loop
severity 761670 important thanks Quoting Thomas Goirand (2014-09-15 18:20:43) Trying to do a bunch of backports, I came across this issue. node-utilities build-depends: node-jake node-jake depends: node-utilities So, it's impossible to build node-utilities, because it needs node-jake, which cannot be installed, because it depends on node-utilities, which isn't build. This cycle has to be broken, otherwise it makes it very hard for porters to bootstrap the rebuild of node-utilities node-jake. I agree this is a bug and it needs correcting. I disagree, however, that it is so important that it is better to not ship Jessie with this bug than to ship Jessie with this unfixed. Hence lowering severity. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#768777: unblock: node-jake/0.7.9-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please unblock package node-jake Severity of bug#761670 was set too high, lowered only after the freeze. No debdiff, as no changes was needed, only an adjustment of severity. unblock node-jake/0.7.9-1 Thanks for considering, - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUXyr9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWh3UIALZ6/JiA8WM4CFV4Kq01vcHf qeAGu6MgvbeesZ2SHgvry7ea6199QyweMzoPcDI8dCA/dbicFfl1XekFgQ0TJjZT 9Z5zq65qpDUUGZt5SEY5lysfNsW9Vnm+s5JeHFYmIAw5/eGWcEvP7u64k7eItv2W WMgTNzhMy9/Is/v0xm7cMQxqaAgbjp8727i/aplQC87JM3VguNJrhAGVreHUPM2/ A+uKMjz6GC5DmGajS/r9YE5NzuHuOBGSXeXz32bqqLFIpt9DQrUT++OJj+sm8K/z Knv7xTG9JnNCFekxbShvWPeUIap5+FsUMblE2Qgt21ImOIP+hT1Z6VDTc7flwFE= =DMWB -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Javascript trigger design
Quoting Thorsten Glaser (2014-11-28 13:20:36) On Fri, 28 Nov 2014, Thomas Goirand wrote: It's been a long time I've been thinking about it, and I believe that the only way to do this, would be to use triggers. Though I have never Look at libjs-protoaculous which combines prototype and scriptaculous into one (possibly minified) js file. In (our inhouse version of) FusionForge, we just depend on it, and it contains all the trigger and dependency magic needed for that. Just looking at the package name that seems not an ideal aproach: Should we then make packages for each combination of libraries to be merged together, or am I missing a more clever logic? Or do you perhaps point at that package not suggesting duplicating it but instead cherry-picking triggers for a system-wide structure? On Fri, 28 Nov 2014, Ben Finney wrote: My understanding is that the Debian JavaScript team is converging on a standard for compiling JavaScript (using uglify, I think) as a routine That’s not good. Various upstreams recommend/require various minifier tools and say they have had issues with other tools, e.g. due to the minifiers differing in what they require from the source code to work without failure. I agree that too strong standardization is not good - and I disagree with the interpretation that the Javascript team is moving towards such standardization. That said, I do believe Uglifyjs is the best compressor we have, and recomend to treat it as a default similar to newest GCC for C - i.e. use Uglifyjs unless all of... * code is complex, and * upstream tests only only against an alternate compressor which is available in Debian, and * no testsuite with decent coverage and usable for us on build daemons - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Node-webkit
Hi Zlatan, Quoting Zlatan (Debianer) Todoric (2014-12-05 18:53:55) just posted message to debian-devel to find out that we don't have node-webkit in our archive (my question there was about packaging nw packages into Debian). So if there was any discussion why we don't have yet node-webkit in our archive or what is the progress on it, I would be very happy to get some links about it. Also, if there are pros/cons that you want to share for node-webkit apps, I would be pleased that you write them down here in response. I am unaware of anything specifically blocking node-webkit from being packaged for Debian, other than someone doing the tasks of both initial packaging and ongoin maintenance of the packaging. Next step is, I believe, to file either an ITP bugreport (if you intend to package and maintain yourself) or an RFP bugreport (if you want others to encourage others to do it. More info on how to file such bugreports is at https://www.debian.org/devel/wnpp/#l1. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760385: Fix for CVE-2014-5256
Quoting Michael Gilbert (2014-12-20 03:11:10) control: severity -1 important There is no security support for libv8 in jessie, so security issues aren't RC. Lack of support do not change severity. Seems more appropriate to then tag as *-ignore instead. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760385: lowering severity of bugs not tracked by release team
Quoting Michael Gilbert (2014-12-20 11:06:47) On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote: On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote: control: severity -1 important There is no security support for libv8 in jessie, so security issues aren't RC. Could you please add some links to explain that? I was about to fix this issue in an NMU after double-checking the fix. Severity doesn't say anything about whether or not a bugs can be fixed, so you can still do that. Anyway it was decided recently on the security team ml. I find it sensible for the security team to give up on maintaining some packages - and I find it great to try communicate that to our users by use of the debian-security-support package. Just now I learned from above bugreport that the security team also actively *lower* bugreports to avoid them being treated as release candidate, for packages not maintained by the security team. That I find a horrible approach: Severity of a bug is independent on whether it will be fixed or not. The more proper tag to use is *-ignore, IMO. Please let us not hide problems! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#760385: lowering severity of bugs not tracked by release team
[sent again, cc correct list address this time] Quoting Michael Gilbert (2014-12-20 11:06:47) On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote: On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote: control: severity -1 important There is no security support for libv8 in jessie, so security issues aren't RC. Could you please add some links to explain that? I was about to fix this issue in an NMU after double-checking the fix. Severity doesn't say anything about whether or not a bugs can be fixed, so you can still do that. Anyway it was decided recently on the security team ml. I find it sensible for the security team to give up on maintaining some packages - and I find it great to try communicate that to our users by use of the debian-security-support package. Just now I learned from above bugreport that the security team also actively *lower* bugreports to avoid them being treated as release candidate, for packages not maintained by the security team. That I find a horrible approach: Severity of a bug is independent on whether it will be fixed or not. The more proper tag to use is *-ignore, IMO. Please let us not hide problems! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Launchpad: Claim existing team
Quoting Marcelo Jorge Vieira (2015-01-26 14:41:04) On Fri, 2015-01-23 at 22:40 +0100, valentin OVD wrote: It's me who have claimed the team for prevent this to happen. Administrators of Pkg-javascript please reclaimed the launchpad team. pkg-javascript-devel is already in the Lauchpad since 2008 [0] and pkg-javascript-devel-lists since 2011. [0] https://launchpad.net/~pkg-javascript-devel [1] https://launchpad.net/~pkg-javascript-devel-lists Anyone know if I can merge it? Your questions seems specific to Ubuntu/Canonical to me. This is a Debian mailinglist. Ubuntu developers and/or Canonical employes might be listening here, but I guess you have far better chances getting in touch with them at their own lists/forums/whatever. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] npm2deb database
Quoting Sebastiaan Couwenberg (2015-03-14 13:38:20) On 03/14/2015 11:23 AM, Leo Iannacone wrote: please, consider to add your contributions to the DB of npm2deb (if needed): https://wiki.debian.org/Javascript/Nodejs/Database Interesting page, but not very informative. And also not linked from the Nodejs page, making it not very easily discoverable. I have no interest in npm2deb. Those relying on that wiki page please elaborate what maintenance is needed, and let us discuss if sensible to generally expect from us all to do that, and how (perhaps better to use e.g. debian/upstream/* YAML data for that). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Communication issues? (Was: node-tar_1.0.3-1_amd64.changes ACCEPTED into unstable)
Hi David (and others, Quoting David Prévot (2015-03-14 15:33:15) Le 14/03/2015 08:38, Sebastiaan Couwenberg a écrit : I'm happy that I'm finally getting some feedback even though its triggered by a fuckup of mine, at least there is some dialog going. I’ve been subscribed to this list for almost two years now, and unfortunately, it seems like there is not much positive feedback or help one can expect from here. Not sure how we (or more realistically you, since I’m pretty tired of the mud-throwing style of discussion here) may improve the current status, be more welcoming and helpful to each other, but believe there is room for improvement. I appreciate this list - it is far better than not having it: I have found it helpful for coordination of packaging efforts. I agree that our style and amount of dialogue can be improved, and welcome efforts towards that. Maybe a face to face meeting would help starting back on the right foot? The upcoming DebConf (and DebCamp) may be a good opportunity, so please, do register [1] and propose a team sprint [2] or at least an event [3] if you believe this can help. I will attend the upcoming Debconf + Debcamp, and would be happy to meet face to face then (but not all of Debcamp - I am involved quite a few places). I will also try make a better job of responding here on the list - reason I have often kept silent is to not bother with my arguably odd cdbs packaging style (I assume most here use short-form dh and - like myself - dislike embracing multiple styles). @David: Will you initiate a sprint for us at Debcamp? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Issues with coffeescript 1.9.1
Quoting Arto Jantunen (2015-03-10 12:32:09) Some developers here were requesting an update to coffeescript 1.9.1, I went looking for a packaged version and found out that it has already been merged in your team's git repo. I tried building this, but it doesn't quite work as is. Attached below are two patches that allow the package to build successfully. Ah, wonderful! When the build failed I suspected I needed to fix something in node-underscore, and from your patches I can see that I simply made the silly error of including the wrong package. Nice! Sadly even with these applied the package doesn't work, failing with the following traceback: /usr/bin/coffee module.js:340 throw err; ^ Error: Cannot find module '../../bin/coffee' [...] Apparently something goes wrong with the search path when looking for the modules, but my understanding of the node module system is somewhat limited. I'd greatly appreciate any help with solving this. That should be easy to catch (and thanks for saving me a roundtrip!). Issue is that Nodejs modules are assumed to be installed in the home directory - system-wide path is a Debian speciality. So any time a module walks the file system to get to other modules, we need to patch it to walk differently. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Issues with coffeescript 1.9.1
Quoting Arto Jantunen (2015-03-11 08:07:18) Jonas Smedegaard d...@jones.dk writes: Quoting Arto Jantunen (2015-03-10 12:32:09) Some developers here were requesting an update to coffeescript 1.9.1, I went looking for a packaged version and found out that it has already been merged in your team's git repo. I tried building this, but it doesn't quite work as is. Attached below are two patches that allow the package to build successfully. Ah, wonderful! When the build failed I suspected I needed to fix something in node-underscore, and from your patches I can see that I simply made the silly error of including the wrong package. Nice! Yeah, the build was looking for a node module and not just the javascript library, even though these are almost the same thing.. Yup, I (should) know. Which is why I call my error silly. :-) Apparently something goes wrong with the search path when looking for the modules, but my understanding of the node module system is somewhat limited. I'd greatly appreciate any help with solving this. That should be easy to catch (and thanks for saving me a roundtrip!). Issue is that Nodejs modules are assumed to be installed in the home directory - system-wide path is a Debian speciality. So any time a module walks the file system to get to other modules, we need to patch it to walk differently. I see you commited the fix already, and the resulting package seems to work fine. Thanks a lot for your quick and efficient response. Good to know. Thanks for the feedback :-) You are quite welcome to join the team and help maintain this and all other packages that I am directly involved in (and likely other packages too, but ask first - this team is only loosely coordinated): https://wiki.debian.org/Javascript - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#784439: uglifyjs version failing
Quoting Jérémy Lal (2015-05-06 14:08:09) 2015-05-06 13:31 GMT+02:00 Pau Garcia i Quiles pgqui...@elpauer.org: The package.json file does exist: [...] /usr/lib/nodejs/uglify-js/package.json that's why it's usually simpler and safer to install original hierarchy with - package.json - lib/* in /usr/lib/nodejs/uglify-js, instead of changing it and not installing package.json. You are barking up the wrong tree, Jérémy: package.js *is* installed at the *correct* location. Please read what Pau Garcia wrote. Problem is upstream script expecting to be installed in ~/bin/ and assuming its library is in ~/lib/ I will extend 2001 to also cover hardcoded path to parse.js. Thanks for your bugreport, Pau Garcia, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#784439: Bug#784439: uglifyjs version failing
Quoting Jérémy Lal (2015-05-18 19:33:34) 2015-05-18 19:19 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting Jérémy Lal (2015-05-06 14:08:09) 2015-05-06 13:31 GMT+02:00 Pau Garcia i Quiles pgqui...@elpauer.org: The package.json file does exist: [...] /usr/lib/nodejs/uglify-js/package.json that's why it's usually simpler and safer to install original hierarchy with - package.json - lib/* in /usr/lib/nodejs/uglify-js, instead of changing it and not installing package.json. You are barking up the wrong tree, Jérémy: package.js *is* installed at the *correct* location. Please read what Pau Garcia wrote. Problem is upstream script expecting to be installed in ~/bin/ and assuming its library is in ~/lib/ I will extend 2001 to also cover hardcoded path to parse.js. What i was saying was that files were expected to be installed in /usr/lib/nodejs/uglify-js/package.json /usr/lib/nodejs/uglify-js/lib/* which is fine for me but i saw you prefer installing them up one dir + patch. Please actually look at the uglifyjs source package - or just read closely the original bugreport - before you comment further. I think you will then agree that your remarks are totally irrelevant here. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#784439: Bug#784439: Bug#784439: uglifyjs version failing
Quoting Jérémy Lal (2015-05-19 02:15:29) 2015-05-19 1:34 GMT+02:00 Jonas Smedegaard d...@jones.dk: Please actually look at the uglifyjs source package - or just read closely the original bugreport - before you comment further. I think you will then agree that your remarks are totally irrelevant here. Well, i actually did that. So if you've setup the files with the same tree as in source, that is /usr/lib/nodejs/uglify-js/bin/uglifyjs /usr/lib/nodejs/uglify-js/lib/*.js /usr/lib/nodejs/uglify-js/package.json and a symlink /usr/lib/nodejs/uglify-js/bin/uglifyjs - /usr/bin/uglifyjs there wouldn't be a need for the patches. As i said, i'm not questionning the dislike for keeping the original tree, i'm just saying that it avoids adding more patches. Ohh, now I get it. Thanks for spelling it out to me: I even considered if you perhaps meant to install _everything_ including the script below /usr/lib/nodejs but dismissed that as unrealistic. So Nodejs lookup path is not only /usr/lib/nodejs/$lib.js and /usr/lib/$lib/index.js but also /usr/lib/nodejs/$lib/lib/index - or does it take /usr/lib/nodejs/$lib/package.json into account (I notice there's a mention of main in there - which is actually incorrect now with my patching)? Or does stuffing everything below /usr/lib/nodejs/$lib/ only solve internal lib paths, and I should still patch main lib to be .../index.js? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#785698: RM: node-in2 -- ROM; no longer used anywhere in Debian
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As subject says, please drop node-ain2 from unstable, as it is no longer used anywhere in Debian. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVWwZBAAoJECx8MUbBoAEhB/0P/iQBR3KCbkH1ovS2y/dCDYp1 1b54JL/oeOlaN5INWYs/+8BWaKY1jOI/1mZIzYdGO5ueT5dWT1i+fvLFqzspFMKh 4cV9/FCU7aA40y0/o+5xxRs/HzFj4sNWgbo2VP4lzJmyKtvLyx3sjcw6ZRP8P3n1 3hGP6JbSmWvP3nx6cn+MJnmn8P/VhO1f6zWm+Xk5VcjF3MFdE+lIVhN31jdCZ4Yu wvGN18pULSoadDeSf0BKWuAoywHOYIjoJReLiWefjvtVCc5Z8gNCPKonp13uh5eO YDVWYPm1CWyQ0M3Qq7rznZu9NFTHnnM2fbpXRgxKaWlPcgFmgSBEso+TWfdbNUgU m+N28sXleMgqyzXNCj6O2HCxo38A7pE8N8pMTZDRtwhBrSLB/mAxODaXB5Pyd0lE s7hJ33lImm3paQaMEdB3YnUXUmMZm/26iIBkR+1yY/EaJxREmQjACsUAjH9tfUD8 jES+8XgVr7/jqP3WC8YYksn9WbNbwF+U/L97GxNLvqLpIvtTcLARckUUlLxPouMu tREMYsrae66mqvJ3vVE0AoF4Vc5HShjjitkuzf367NOVkb6SIBbeAwGBjk8/M3Em XWZUpFHNqMpP5jscMQJy/gFpcla+89yw5/Qe9a8OX3BMNAlP4x3BFaJCVwmiJQhx IUi0l5IJ9nik5MvCcoPR =ZkY1 -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#785699: RM: node-jsconfig -- ROM; no longer used anywhere in Debian
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As subject says, please drop node-jsconfig from unstable, as it is no longer used anywhere in Debian. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVWwasAAoJECx8MUbBoAEhjBAP/38e1K84ml+XxytHW1kk30m7 GCcgeeczr69DBlRhaT+YNQNpt/y9JVkYxSm5/H0hGTuF5RJK5wMgl8MctzwhoCzt P2yHBTkSJWuSW1hvOB5pPv4Dtk7+cqu1sT6q/bdRY/9hnmYyGfByPMyqrwahrLWZ Mv8PdS2UNxVd0Q6MxBHA7BclWqQdcJDCh5UTbfhgO9eoJgCgLHralZeBzjDaIqSG OLIU0fa99fP4k6toxoEDLkvBVidNlbZPm4l4lyiICrshvsDTyQTAccBBezY1mDFR tqLu/4EjYFAgOoF79BZvF1KXPpwdxGsB9ICd5IfBs1qvJ/p5ajKObizf8um355CB VM6nrKN7NYeGZwJJILubUyyRYs2hsTAFRvXDsmoP8TY1AjgR79nmIf2qxt0oNw5r uM/MocQT95lWcEjbEYHK0xuBKtCaJ5ZgbUBPAT28PeCKW85sDCak0X9YgT2W2X8N +hfDPX/6pgBRZuGLxswNxtzeHoftsaOwyvJpPnmjlpS9TBGB33fE8m3rLSBmsEVi eKPk7/+AbYe7H2EzEwXd6b9+Ta9C0M0r3nOoXXYpSBNu+C6RWnS082MMGpgzvkMy syFiGCAkO1Xbs23jcj/v3hOkpGSe1SUiCBXFgI/rkDLHe3gVSLCqwWCmRCnmr9a1 q9tA4jDj7bDnQw3S0gDT =fZRo -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] libv8 tracking soname with abi-compliance-checker, another try
Hi Jérémy, Quoting Jérémy Lal (2015-05-17 19:56:06) it seems dh_acc or direct call of abi-compliance-checker could play the role of checking when the ABI breaks. However, this doesn't fit well with a soname based on upstream version: it could happen that version 3.50.1 is compatible with version 3.49.12, and 3.50.2 breaking compatibility with 3.50.1. So i'd like to move to an integer based soname that is incremented each time there is a detected abi break by a.c.c. I can do this as soon as the next v8 upload. Sounds good to me! I am not an expert in soname handling, though. I think the common thinking is that we should not as distro invent SONAME but leave that yo upstream, because ideally it should be identical across distros. But concretely for v8 I guess that is highly unlikely to happen - and we should deal with it when it does. You might wanna consult d-devel@l.d.o - as you know my judgement have been horribly wrong in the past :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Small Node.js packages in NEW
Hi Thorsten, I do recall a discussion about this recently, but no conclusion then. Please point to the conclusion you seem to imply that we reached in our recent descussion about this issue, so that we can avoid unneeded repetition this time around. Quoting Thorsten Alteholz (2015-04-04 15:12:14) Isn't git able to handle several upstreams in one repository? Tracking upstream projects is the main issue with bundling, I believe. Git is unable to help with tracking multiple upstreams, unless I am missing something. Please do elaborate if you have ideas :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request to Join Project Debian JavaScript Maintainers from Jean-Michel Vourgère (nirgal)
Hi Jean-Michel, Quoting nore...@alioth.debian.org (2015-05-19 17:15:29) I finally got DD status on Sunday \o/ Please grant access to my new account nirgal. You can drop permissions from nirgal-guest. Congratulations! You are admin (also with your old account), so can approve yourself :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#785791: nan.h:82:47: fatal error: nan_new.h: No such file or directory
Package: node-nan Version: 1.8.4-2 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems the newer node-nan needs another header file included: In file included from ../node-stringprep.cc:1:0: ../../../../usr/lib/nodejs/nan/nan.h:82:47: fatal error: nan_new.h: No such file or directory #include nan_new.h // NOLINT(build/include) ^ compilation terminated. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVXEkmAAoJECx8MUbBoAEhIGUQAKS1GkwsQdhC7iznHq5J+g1E d2fcLAf6XayfUsELQdJ+zGw4wxf36brBMDlx5uLTluDkuBQSGu79rf+Zc20KmG/2 qR5wz6bnlD6L+QW0KfM76ohuxxLH5AHr88TKWgX8K6LQbig7SMjOv1ZkFggGc2yN ZxXe5uSj36rnyBxW31D63qL1fXscXNqvb7+JPNykbiM7Nzv40BJBThuJ8W0SkMH7 iEWQmfzseb7SZ80yexH5d4wcU/O9VjG7kggwPyHYtU7S6nYCTiBUIZfKavlnUYxH sUaNQ7g0WmFgJJx4fmb4CLrysFE34Sfw7kGmon6+HNbBAZdRgDpcMbnybDQMWCZM oyIHtAnNyvG2LbnMJ7jZxbQy9Ql6yRbKv++whqbzlKEwyiCwt7WknTZ/SfW/bGur eXJMK5R02fOwHuzg+iM4P+p/egNI8jN6MN7Y0DrZFpZnwb0h6CBgii+T8/t/2RD9 2O0tB++7RV2NAeNUQ1pPkUtndGdTg8xxbzg63FRXTgsBKHQ5nijZN9rQM94m/c9I 4haCoaCs1bRgy2UdTiGjeGhEO/V/M8Bwz3dzT5wqf4C6Sge/vuYvulfBFyq/OOda cdBt9hyOXf/a1utgkwKDW+eFCaBXTFKPd01/e6wqjWKw2vQy6aNBiCE6EKlxmwjB fvDYcOf+fhoi1CPpjwYc =JVKF -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#785748: nodejs should provide virtual package nodejs-abi-11
Package: nodejs Version: 0.10.38~dfsg-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Architecture-dependent modules is tied to a module ABI, and fails to load with a Module version mismatch. Expected 11, got 1 or similar error. Current ABI can be resolved with this command: nodejs -e 'console.log(process.versions.modules)' Please have nodejs declare a virtual package, e.g. nodejs-abi-$abi, for arch-dependent modules to depend on. That way runtime failures can be detected as package dependency failure and a binNMU requested. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVW5P7AAoJECx8MUbBoAEhTHYQAIzz4qVe4yemBj2Au0SofNe1 xB8HishLQjrN28z5BQYA2h8m2GeVJ2A19o00ntIo3ToZfIx2CoWe70yvgKmsA3+Y cqim7ZwaX2/vLILVXGTcix07/jwB3ZQGtz7Nt1S+qncDfRqHJE2AsoJnnlHyu+eS W4FbT5KFqbkrIeI1/w/XUCmV1YQSim6IXn9Fb3wG6R/9D342klYYvn0Z0VO7oHw0 +g3t+ADQ0sFN/kYyg5oroqc5nC5V8wfOZ1qhJQzGiuRE1RqwUrPRTzqQsKymz8AJ kR6+yrXDh5sbLm+i74Id6D0WUs0nfpWsDrPTTds/LDdjw1t2HsHfTHfnX0fn5fja B4G+UsiRKcNEDPv8SkoLS2ZXXImtsUycr04wAWUDA54847CmiBftc7TyzkoH+oYS Ck3Z3d/CEsAUALH0DIjntoi/2uXoTxbQ02iW7mAB0u9AsXvCDD1TxpXayVP8OCx6 XTmrQ1MhOPTzAZ32W0j3Svsp00UT0ZtbcqPKMtbql+gnF4BfvV72tAnw1vba0bVX ChV+hTB5sVi/7d+uIAyh9boX0ooyzLHgtFNuRfgQKWn3jztiysfTQ3+yzkNP9k7i 9kVI3Ei+h5Hp9zl2QTKc99ud1W9+bv3NWLTQxO+HHtfKx2eeCY91S+omNbZBZzP/ 9Je1cutNFFhfhyh1c1NO =TaPE -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request to Join Project Debian JavaScript Maintainers from Julien Puydt (jpuydt-guest)
Hi Julien, [sent again - to proper mailinglist (not multimedia team list)] Quoting nore...@alioth.debian.org (2015-05-29 17:06:37) Hi, I'm already part of the debian-science team where I have a few packages and of the debian-python-modules team where I'm still waiting for someone to sponsor a few packages. The new ipython version needs jsdoc to rebuild its documentation, which in turn needs a few nodejs packages. I'd like to package some of those. Welcome aboard! Help is always appreciated :-D If you haven't already, then please subscribe to our mailinglist and check our wiki notes on how we collaborate - and don't hesitate to ask if something is unclear: Question are never silly but a help too! https://wiki.debian.org/Javascript - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Updating Mocha
Quoting Leo Iannacone (2015-05-30 18:00:42) I just figured out that to update node-mocha we need node-diff upgrade. Jonas, any plan to do that? Done! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Contacting maintainers of libjs-* packages for advice
Hi Antonio, Quoting Antonio Olmo Titos (2015-07-07 03:22:57) Hello, pkg-javascript-devel@lists.alioth.debian.org My name is Antonio, and I am a member of the systems team at the W3C. (I apologise in advance if this is not the right channel for my comments! If so, I would appreciate advice on how to contact the relevant people.) At the World Wide Web Consortium we are starting to collect in a central location a copy of the JS libraries we use most often -- many published specs and other documents use jQuery, MathJax etc, and to avoid redundancy we are putting together a very simple, internal repository (think our very own micro-CDN). While doing so, we are faced with a few problems (how to handle different versions or strands of each library, how to get security announcements from developers and deploy their updates promptly, etc). Leveraging libjs-* Debian packages is a possibility, although we still have to study if it fits our needs. In any case, we suspect the maintainers of libjs-* are dealing with the same issues, so I would like to talk with some of you to maybe answer these question. E-mail, IRC or some kind of VoIP would work for me. Thank you in advance, and keep on the good work. Yes, you reched the correct place! I would be happy to discuss collaboration/comparison with you - and I am sure others would as well. Also, please do not treat our current structures as written in stone: If you find that they are too limiting for your use, please do share your concerns with us, and it might be that we decide to extend to suite your needs :-) We can continue discussing here on this mailinglist if you are comfortable with that. If you prefer personal discussion and then summarize findings in public afterwards, then I am fine with e-mail, irc and SIP, and also Jabber - but I am lousy at writing summaries, so would appreciate if then you took care of that part ;-) Right now and a week onwards I am in Peru with limited bandwidth, so e-mail is most convenient. Else we generally hang out on OFTC.net in the #debian-js where I am jonas, and my Jabber and SIP id is jo...@jones.dk (i.e. not same as my email address). Looking forward to discussing with you, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#730014: Bug#730014: Bug#730014: new jquery needed
Quoting Mike Gabriel (2015-07-29 01:33:43) On Di 28 Jul 2015 20:45:45 CEST, Matt Taggart wrote: I also need jquery updated in order to fix #792451. Lots of upstream maintainers seem to embed copies of jquery, if we don't provide a recent packaged version this is going to turn into a security nightmare... by coincidence, I have today started looking at jquery-ui (and jquery-ui-themes) which needs to be updated in Debian in order to get the e-Learning portal ILIAS into Debian. I also vote for getting jquery updated in Debian, maybe to experimental first, so people can test compatibility(?!?). I am happy to continue working on jquery-ui, maybe someone else wants to pick up jquery itself? Obviously, the previous maintainer has not work on jquery(-ui) in Debian since 2013 or so, right? Yes, previous maintainer evidently is too busy elsewhere currently, but there's no dispute (that I am aware) so voting doesn't help. Instead, someone needs to step up and join the maintenance of jquery. Since you are interested in the quite related jquery-ui, perhaps you could also help with jquery? (I have little interest in jquery-based code myself) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request to Join Project Debian JavaScript Maintainers from Nigel Kukard (nkukard-guest)
Hi Nigel, Quoting nore...@alioth.debian.org (2015-08-11 08:29:57) Nigel Kukard (nkukard-guest) has requested to join your project. You can approve this request here: https://alioth.debian.org/project/admin/users.php?group_id=100128 Comments by the user: I was talked into joining the team at Debcamp. :-) I am very well versed with a couple of the JS libraries such as jquery, jquery-ui, flot, twitter-bootstrap. It is a better use of my time instead of freezing versions and including them in my software to do something more constructive and assist with maintaining the packages for them. Welcome aboard! If you haven't already, please read https://wiki.debian.org/Javascript/Policy and join our mailinglist http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#719367: Bug#719367: node-raptor on mipsel
Quoting Arturo Borrero Gonzalez (2015-07-15 13:33:49) after a month of no movements upstream, I feel we are hitting a dead project upstream. My intention is to give up in this issue :-( Thanks for trying, and sorry for not responding earlier... - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#802876: ITP: node-jison -- an API for creating parsers in JavaScript
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard <d...@jones.dk> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: node-jison Version : 0.3.10 Upstream Author : Zachary Carter <z...@carter.name> * URL : http://zaach.github.io/jison/ * License : Expat Programming Lang: JavaScript Description : an API for creating parsers in JavaScript Jison generates bottom-up parsers in JavaScript. Its API is similar to Bison's, hence the name. It supports many of Bison's major features, plus some of its own. If you are new to parser generators such as Bison, and Context-free Grammars in general, a good introduction is found in the Bison manual. If you already know Bison, Jison should be easy to pickup. . Briefly, Jison takes a JSON encoded grammar or Bison style grammar and outputs a JavaScript file capable of parsing the language described by that grammar. You can then use the generated script to parse inputs and accept, reject, or perform actions based on the input. Package is needed to generate coffeescript from its true source (currently it builds itself from pre-built code). Package will be maintained in the Javascript Maintainers Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWK4GNAAoJECx8MUbBoAEhx0IP/jD+Ng7nsOxDnDhhxNSiuRSe kXYo10k0a09wbpm0ZcbO7l4TSGemHFZTn8NPy9RXXLYMq56GnBO2HcWS5yYDcndk 4qr+QTKKqT58Bl1cYQQyvKMB0/WWUbFvD4OBrmmCR+Fi9K3boS9Fi6SRPUhCIWbU S3zUXshGXdHMCCVgyJbevYnrsEXago0mJaw1oEI8ZZERvVn5bacWDqTJiiJQkp8M MsyEa0YOn68XlFL/KpmjRWyGGhI/1PrN2IMj2oCgJzY4128Ry7BJc6gMJfN9OAAN UbNTgNC5abFsFyqx76zlfL3K4nB2U5y8/xNl6rjlyOPO2u8Sq9y2jYsCB6nCdY9K kOm4gr6DnAxeFXkwUBHB+mnaOSKL+F+8xbLm7caP8/e9H3g+AEibC8T+3+EwWlgF AaXt96j2IdZSMczbeIG25e00X1JYyX51N5vcSG4TfGAL5o+KDJUbgW0CZHBoLc2M CZA4GBnPkxOl/lQu45Q1gZ8glFnRtG9gZ78y6HfqGprog8gGoVDrdiElI6FnA5SK dIxIujwbcxIC+iAsj+0BL3UA0itmoLTCoFmEvTGMa5hx1G/xB9ekoEv7qAlTJdPy kXDBpnyaQCNBtDEn60ljTRhp+T2bAbADEWZtvapWFKhLhXs5ebbvVad8m7fUHsxb asElOU3w+TUvbW2bcymX =pZUj -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
