[Pkg-javascript-devel] Bug#857993: Please don't remove npm from Stretch
Hi, I very much don't agree with the set of arguments in the #857986 bug report. Npm can be used for a large amount of things, of which may not include downloading and installing the very latest version of a Javascript module. Therefore, the package is still useable for a wide set of functionalities within the scope of Debian and the set of package we have (for example, for rebuilding). Also, removing such a non-leaf package at this point of the release is a way too late. IMO, a bug should have been opened a long time ago asking for an upgrade of the package. Last, at this point in time, I believe we should discuss the issue with the release team. They may agree, for example, that we upgrade the package to a newer version (this is unlikely, but it is up to them to tell). They may don't agree that we "fix" so many source package to remove the build-dependency. Anyway, the solution should be discuss with them. Therefore, I'm CC-ing the release team. In any case, once Stretch is released, we must make sure such an important package gets better maintenance, and follow upstream closely. Cheers, Thomas Goirand (zigo) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Fwd: How to handle JavaScript npm + gulp web GUI packaging?
Hi, I'm resending this message, hopefully, it will reach the list this time. I would like to package a web app which contains Javascript stuff, which are using npm + gulp (to disclose everything: I am packaging fuel-web). Currently, the way to build the JavaScript is to do: cd nailgun npm install ./node_modules/.bin/gulp build --static-dir=compressed_static mkdir -p $(CURDIR)/debian/fuel-web-static/usr/share/nailgun cp -r compressed_static \ $(CURDIR)/debian/fuel-web-static/usr/share/nailgun/static cd .. Of course, doing the above in Debian isn't possible, because: 1/ I want to use system nodejs-* and libjs-* packages, not bundle any of these stuff inside my app. 2/ npm does network access to fetch dependencies, which isn't possible at build time So, for the moment, I have written a fuel-web-bundle-js source package containing the non-free pre-built blobs (which typically could be uploaded to non-free), and the fuel-web source package that generates the fuel-web-static that depends on it. I'd like to fix this in a better way so that Fuel can be fully uploaded to Debian main. How to make this all in a Debian policy compliant way? Cheers, Thomas Goirand (zigo) P.S: I'm not afraid of packaging all individual libjs-* and nodejs-* (build-) dependencies, even if there's a big number of them. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] How to handle JavaScript npm + gulp web GUI packaging?
Hi, I would like to package a web app which contains Javascript stuff, which are using npm + gulp (to disclose everything: I am packaging fuel-web). Currently, the way to build the JavaScript is to do: cd nailgun npm install ./node_modules/.bin/gulp build --static-dir=compressed_static mkdir -p $(CURDIR)/debian/fuel-web-static/usr/share/nailgun cp -r compressed_static \ $(CURDIR)/debian/fuel-web-static/usr/share/nailgun/static cd .. Of course, doing the above in Debian isn't possible, because: 1/ I want to use system nodejs-* and libjs-* packages, not bundle any of these stuff inside my app. 2/ npm does network access to fetch dependencies, which isn't possible at build time So, for the moment, I have written a fuel-web-bundle-js source package containing the non-free pre-built blobs (which typically could be uploaded to non-free), and the fuel-web source package that generates the fuel-web-static that depends on it. I'd like to fix this in a better way so that Fuel can be fully uploaded to Debian main. How to make this all in a Debian policy compliant way? Cheers, Thomas Goirand (zigo) P.S: I'm not afraid of packaging all individual libjs-* and nodejs-* (build-) dependencies, even if there's a big number of them. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] How to handle JavaScript npm + gulp web GUI packaging?
On 02/12/2016 05:23 PM, Jonas Smedegaard wrote: > Quoting Thomas Goirand (2016-02-12 08:27:12) >> I would like to package a web app which contains Javascript stuff, >> which are using npm + gulp (to disclose everything: I am packaging >> fuel-web). > > [details on dirty upstream build routines snipped] > >> I'd like to fix this in a better way so that Fuel can be fully >> uploaded to Debian main. How to make this all in a Debian policy >> compliant way? > > I suggest as first step to avoid cross-posting: I see no need for > involving all Debian developers in this - Javascript Maintainers > suffice. :-) I really thought it was of general interest, though I'm ok following-up only there (though see below...). >> P.S: I'm not afraid of packaging all individual libjs-* and nodejs-* >> (build-) dependencies, even if there's a big number of them. > > Awesome! Really really great! Please re-post only to javascript list, > and let's continue the discussion (only) there. It looks like my messages are going for moderation, for some reason. Could you white list my address? Cheers, Thomas Goirand (zigo) ___ 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#805289: Please upgrade to 2.4.0
On 11/16/2015 03:57 PM, Jonas Smedegaard wrote: > Hi Thomas, > > Quoting Thomas Goirand (2015-11-16 14:24:09) >> Severity: important > > Normal severity is "wishlist" for requests of newer upstream release. > > If you believe this needs special treatment, then please provide > arguments why that common rule should be side-stepped. No worries for the severity, I don't wish to spend time discussing that and any severity is fine as long as someone (maybe me) does the work. >> I need version 2.4.0 of libjs-less for OpenStack Fuel. Please package >> it. Please let me know if it is ok that I do the work in Experimental >> first, then you can review the package and upload to Sid. > > Recent Less.js has dependencies not yet packaged for Debian. Could you list these, and I do the work? Please help me to help! :) > You are quite welcome helping by packaging those. > > You are also quite welcome to help co-maintain less.js packaging, if you > are ok with its current style of packaging (CDBS and git-buildpackage), > as documented in README.source. In that case yes, targeting > experimental first is good. Well, CDBS has been in my list of things to learn for a long time, so I don't mind having a try. I do like the fact it's Make based, rather than Perl (which I have a hard time reading). BTW, do you think I should switch my other JavaScript packages to CDBS? I've been using dh so far... Cheers, Thomas Goirand (zigo) ___ 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#805289: Please upgrade to 2.4.0
Source: less.js Version: 1.6.3~dfsg-2 Severity: important Hi, I need version 2.4.0 of libjs-less for OpenStack Fuel. Please package it. Please let me know if it is ok that I do the work in Experimental first, then you can review the package and upload to Sid. Cheers, Thomas Goirand (zigo) ___ 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#797698: I'm also affected: update to latest upstream release
Hi, I'd like to also tell that I need a higher version of libjs-backbone. I need at least vesrion 1.2.1, which is needed by OpenStack Fuel. Can I do the work, and upload a new version to Experimental? Cheers, Thomas Goirand (zigo) ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#805282: Please package version >= 3.9.3
Package: libjs-lodash Version: 2.4.1+dfsg-3 Severity: important Hi, I'm trying to package OpenStack fuel, and it needs lodash 3.9.3. Please package it, at least in Experimental. Since I'm in the PKG Javascript team, I'll do the work to upload in there. If you don't want me to do that, let me know. Cheers, Thomas Goirand (zigo) ___ 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#802111: smash: FTBFS: TypeError: sandbox must be an object
On 10/29/2015 04:34 PM, Jérémy Lal wrote: > > > 2015-10-29 16:24 GMT+01:00 Thomas Goirand <mailto:z...@debian.org>>: > > Hi, > > I'm worried that this bug is left undressed. It affects *a lot* of > packages, including: > - nodejs > - openstack-dashboard > > And also, upstream seems to not care about it, as per the github issue > set in the forwarded-to-url. > > Laszlo, will you work on this? > > > Hi, > how does it affect "nodejs" ? > > Jérémy Well, not nodejs itself directly. Though a lot of javascript libraries are build-depending on node-smash, like for example libjs-angularjs. This breaks the dependency chain of many things, not only nodejs packages: - libjs-angular-gettext - libjs-angularjs-smart-table - libjs-lrdragndrop - libjs-magic-search - libjs-twitter-bootstrap-wizard - rickshaw: buggy deps smash, flagged for removal in 29.9 days Then lots of things are in AUTORM status because of this: - python-mpld3 - some owncloud stuff - things related to d3 - prometheus - ... and affecting OpenStack dashboard and friends: - horizon - murano-dashboard - python-xstatic-angular-cookies - python-xstatic-angular-gettext - python-xstatic-angular-lrdragndrop - python-xstatic-angular-mock - python-xstatic-angular - python-xstatic-d3 - python-xstatic-magic-search - python-xstatic-rickshaw - python-xstatic-smart-table - tuskar-ui I didn't have my facts completely strait, though the point is: node-smash removal from testing would impact lots of packages, so it'd be nice to have a way to solve the issue ASAP. And I'm worried that upstream wrote in the Github issue that nothing will be done. :( Thomas Goirand (zigo) ___ 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#802111: smash: FTBFS: TypeError: sandbox must be an object
Hi, I'm worried that this bug is left undressed. It affects *a lot* of packages, including: - nodejs - openstack-dashboard And also, upstream seems to not care about it, as per the github issue set in the forwarded-to-url. Laszlo, will you work on this? Cheers, Thomas Goirand (zigo) ___ 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: libjs-jquery: New upstream release
This starts to become a very old bug, and it needs to be addressed. We can't keep this ancient version. At the same time, #680282 also needs to be addressed. Any news on this? Shall I bring this topic to debian-devel@? Cheers, Thomas Goirand (zigo) ___ 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] libjs-require-css_0.1.0-1_amd64.changes REJECTED
On 12/04/2014 12:00 AM, Thorsten Alteholz wrote: > > Hi Thomas, > > I am afraid this package needs a reject. > > The license of > example/www/jquery.js > example/www/text.js > is missing in your debian/copyright. > > Maybe you can also take care of some lintian warnings: > W: libjs-require-css: macos-ds-store-file-in-package > usr/share/doc/libjs-require-css/examples/example/www/.DS_Store.gz > W: libjs-require-css: embedded-javascript-library > usr/share/doc/libjs-require-css/examples/example/www/jquery.js please use > libjs-jquery > W: libjs-require-css: symlink-is-self-recursive > usr/share/doc/libjs-require-css/examples/example/www/require-css ../.. > W: libjs-require-css: executable-not-elf-or-script > usr/share/doc/libjs-require-css/examples/example/www/text.js > W: libjs-require-css: executable-not-elf-or-script > usr/share/doc/libjs-require-css/examples/example/www/style/style.css > W: libjs-require-css: executable-not-elf-or-script > usr/share/doc/libjs-require-css/examples/example/www/components/component.css > W: libjs-require-css: executable-not-elf-or-script > usr/share/doc/libjs-require-css/examples/example/www/app.js > W: libjs-require-css: executable-not-elf-or-script > usr/share/doc/libjs-require-css/examples/example/www/components/component.js > > Thanks! > Thorsten All fixed and re-uploaded! Thomas ___ 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
On 12/02/2014 07:16 AM, Brian May wrote: > On 2 December 2014 at 09:46, Thomas Goirand <mailto:z...@debian.org>> wrote: > > if [ "$1" = "configure" ] ; then > > /usr/share/openstack-dashboard/manage.py compress --force > > fi > if [ "$1" = "triggered" ] ; then > /usr/share/openstack-dashboard/manage.py compress --force > fi > > Is it *that* simple? I'm surprised by the "interest" thing just being > hinted with a directory. Does this mean that if anything changes in that > directory, then there's a trigger, and the openstack-dashboard compress > stuff will happen? > > > There might be times when compress is run twice. e.g. when > upgrading openstack-dashboard and /usr/share/javascript/jsencrypt at the > same time. > > However I cannot think of anyway to fix this in a way that doesn't > create other problems. So this might actually be the best solution. > > (e.g. you could explicitly raise the trigger inside the configure event, > however that will trigger all applications that have an interest > in /usr/share/javascript/jsencrypt which is probably not desirable) Great, thanks a lot everyone, it works well, and it was indeed super easy to implement. I just uploaded horizon 2014.2-2 to Experimental with the triggers stuff. Cheers, Thomas Goirand (zigo) ___ 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
On 12/01/2014 04:26 PM, Thorsten Glaser wrote: > On Sat, 29 Nov 2014, Thomas Goirand wrote: > >> 2/ in debian/openstack-dashboard.postinst, implement something like: >> >> if [ "$1" = "triggered" ] ; then >> /usr/share/openstack-dashboard/manage.py compress --force >> fi >> >> Is it *that* simple? > > No, triggers unfortunately are not that simple: if you install/upgrade > openstack-dashboard together with some of the packages it wants a > trigger on, $1="triggered" will sometimes not happen, only "configure". > > Have a look at these: > > • > https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=evolvis-platfrm/evolvisforge.git;a=blob;f=mw-plugin/debian/triggers;h=723d1c077e3cf10350952cf9ded297b85cfde812;hb=HEAD > • > https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=evolvis-platfrm/evolvisforge.git;a=blob;f=mw-plugin/debian/postinst;h=fa480512bf5b32bcfe5412544159a158e6cfab08;hb=HEAD > > The thing to call when triggered is the upgrade_mediawikis shell > function, it’s called from the “triggered” case, but also from > the regular “configure” case. This is suboptimal, but apparently > needed. > > bye, > //mirabilos Hi Thorsten, First, thanks a lot for your help here. It's really appreciated. I hope I'll get it this time... I did get the point I needed to do it on my postinst too, and I am doing it already. So let me rephrase, just to make sure I got it: So if I understand well (by reading your example package), the only thing I have to do (for horizon) is: 1/ Create a debian/openstack-dashboard.triggers that would contain a list of "interest /usr/share/javascript/", for example: interest /usr/share/javascript/jsencrypt then I'd get triggered in my postinst, and then I should do: 2/ in debian/openstack-dashboard.postinst, implement something like: if [ "$1" = "configure" ] ; then /usr/share/openstack-dashboard/manage.py compress --force fi if [ "$1" = "triggered" ] ; then /usr/share/openstack-dashboard/manage.py compress --force fi Is it *that* simple? I'm surprised by the "interest" thing just being hinted with a directory. Does this mean that if anything changes in that directory, then there's a trigger, and the openstack-dashboard compress stuff will happen? Cheers, Thomas Goirand (zigo) ___ 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
On 11/29/2014 06:10 PM, Jérémy Lal wrote: > Le vendredi 28 novembre 2014 à 20:46 +0100, Jonas Smedegaard a écrit : >> 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? > > I suggest bundling javascript, stylesheets, images, assets in general > should be done using a custom, per-package, makefile (or makefile > target). Something in postinst ? > You can't standardize upon absence of standard. > > Jérémy. That's what I'm doing already, it's just that I *also* need to do it when a javascript package is upgraded. Cheers, Thomas ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Comments regarding libjs-cocktail_0.5.7-1_amd64.changes
On 11/30/2014 08:57 PM, Thorsten Alteholz wrote: > ... oh, come on, this time it is external/* > > Thorsten Hi Thorsten, Thanks for your patience with me. I've fixed all the copyright holder for the 3 packages with issues (eg: libjs-cocktail, libjs-backbone.stickit and libjs-backbone-deep-model). Except ruby-raemon, for which I'm still waiting for upstream response (he already fixed it, but didn't add a git tag in github), I believe that I have almost done all dependencies for OpenStack Fuel. So it's taking shape! :) Thanks again for your reviews, Cheers, Thomas Goirand (zigo) ___ 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
On 11/28/2014 08:20 PM, Thorsten Glaser wrote: > 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. Hi! Thanks for the pointer. I just had a look, let me make sure I understand how it works now. So if I understand well (by reading your example package), the only thing I have to do (for horizon) is: 1/ Create a debian/openstack-dashboard.triggers that would contain a list of "interest /usr/share/javascript/", for example: interest /usr/share/javascript/jsencrypt then I'd get triggered in my postinst, and then I should do: 2/ in debian/openstack-dashboard.postinst, implement something like: if [ "$1" = "triggered" ] ; then /usr/share/openstack-dashboard/manage.py compress --force fi Is it *that* simple? Cheers, Thomas Goirand (zigo) ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Javascript trigger design
Hi, Web application have evolved into monsters that needs lots of javascript. It's very common that these javascript applications are collecting all the .js library they use, concatenate them into a single file, and compress the result using all sorts of tools (node uglify is one of the implementation, but that's not the only one). As much as possible, as good Debian citizens, we do package each and every javascript library into a separate package. But then, if there's an update of that JS library, the Web application package has to somehow know about it, and redo the concatenate & compress job. Otherwise, the web app would continue to use the old version. I have this issue with the OpenStack dashboard (ie: Horizon), but also with a second web app which I'm currently packaging (OpenStack Fuel, which is a deployment software for OpenStack). Though this could of course be generalize to any JS app. 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 used triggers, and I thought it was a good idea to ask my DD friends and this list about it. Should there be one trigger per web app? How would this work? Thoughts anyone? Jonas maybe, who did lots of JS packaging? Cheers, Thomas Goirand (zigo) ___ 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#761681: should.js build-depends on node-mocha which isn't in Debian
Package: node-should Version: 4.0.4+dfsg-1 Severity: serious Hi, As per the title of this bug, node-mocha should be packaged, or should.js should not build-depend on it. Cheers, Thomas Goirand (zigo) ___ 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#761674: npm should allow the use of node-ansi from backports
Package: npm Version: 1.4.21+ds-2 Severity: normal Hi, Please downgrade the required version of node-ansi to be: >= 0.3.0-2~ and not just: >= 0.3.0-2 so that one can do/use a backported version of node-ansi. Thanks. Thomas Goirand (zigo) ___ 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#761672: node-utilities build-depends on itself
Package: node-utilities Version: 0.0.31-1 Severity: serious The test-suite of node-utilities uses node-jake, which itself uses node-utilities. So, effectively, node-utilities is build-depending on itself, which should never happen, and which by the way isn't even declared in the debian/control file in an explicit way. To effectively rebuild node-utilities on a system where node-jake isn't available (yet), one has to manually disable the unit test or do some kind of hacks. Please fix the dependency loop. Also, please respect the DEB_BUILD_OPTIONS. You should add something like this: override_dh_auto_test: ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) endif Cheers, Thomas Goirand (zigo) ___ 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: impossible to bootstrap build of node-jake and node-utilities: (build-)dependency loop
Package: node-jake Version: 0.7.9-1 Severity: serious Hi, 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. Cheers, Thomas Goirand (zigo) ___ 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] libjs-twitter-bootstrap-wizard_1.0.0+dfsg1-1_amd64.changes REJECTED
On 09/11/2014 12:00 AM, Thorsten Alteholz wrote: > > Hi Thomas, > > unfortunately I have to reject your package. > > Please add the Apache license of bootstrap/* to your debian/copyright. > > Thanks! > Thorsten > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. Well spotted. Fixed accordingly and reuploaded. Cheers, Thomas Goirand (zigo) ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] What JS compressor should I use?
Hi, To make sure we're using DFSG stuff, I'm compressing the JS scripts myself, instead of using pre-minified JS from upstream. Nothing fancy, I'm sure that's best practice everyone uses here. However, which compressor should I use? I need my packages to build in Wheezy, which is why I currently use yui-compressor (which is available there as well). Though there may be other (better) alternatives which I didn't spot. I perfectly know that the resulting JS file (after compressing with yui-compressor) isn't the best possible result. Note that using Node isn't one of the options I'm considering, because it's simply too big (though yui-compressor seems to depend on on java, which isn't great either). Anything in wheezy-backport would be acceptable too. Advice welcome! Thomas Goirand (zigo) ___ 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] Naming convention for jquery pluggins
Hi, I am currently working on packaging a few JS packages which are plugins for jquery. I've noticed that none of the JS plugins include a dot, however, the plugins I am packaging do have a dot in the name. So, should I use: libjs-jquery.quicksearch (to follow upstream naming) Or should I use: libjs-jquery-quicksearch (to follow a Debian standard) Please voice your opinion. I'm not even sure there's a standard here... Cheers, Thomas Goirand (zigo) ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Comments regarding libjs-jquery-hotkeys_0~20130707+git2d51e3a9+dfsg-1_amd64.changes
On 07/07/2013 05:14 PM, Ansgar Burchardt wrote: > Hi, > > debian/copyright contains > > This program is free software; you can redistribute it and/or modify it under > the terms of the GNU General Public License as published by the Free Software > Foundation; either version 2 of the License, or (at your option) any later > version. > > but the upstream source says "Dual licensed under the MIT or GPL Version 2 > licenses". Please remove the "or later" part in d/copyright in your next > upload. > > Ansgar Hi, Well spotted. As I don't think I will upload a new version soon, I have fixed it now and uploaded a Debian release -2. Thanks for this fast approval. Cheers, Thomas ___ 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] libextjs
Hi, I have heard twice that someone wants to take over maintainership of libextjs. Dapal asked me on IRC, but I'm not sure about his email (if he's not reading this list, can someone forward to his email address, which I don't know?). If so, please go ahead! I am the maintainer of too many packages already, I would have like to update libextjs to it's latest version 3, but I had not time for it. I'd welcome anyone to do this work. I'd like also to be kept in the Uploaders: field. The only thing that I ask is that libextjs 3 stays in Debian. Best would be to have both the latest v3 and v4 in Debian, as they aren't compatible. I maintain the extplorer package in Debian, and upstream author told me he wont ever be compatible with extjs 4. Cheers, Thomas ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Packaging version 3.4.0 of libjs-extjs
On 07/25/2012 01:06 AM, Beresford, Tom wrote: > Hi, > > Have attached a tar of git patches > > This is also a first for me so apologies if it's not correct > > Thanks > > Tom Hi Tom, Here's a few comments. 1/ Sending patches You don't need to send me the *full* git history, but only since the last change. This would be done with: git format-patch where the hash is the last commit I made when doing "git log". More details here: http://dtcsupport.gplhost.com/Git/Create-Patch-Files 2/ Your work Your patch 0007 is missing the debian/libjs-extjs.examples file, so I didn't apply it. Your patch 0006 should also contain edition of debian/changelog to document the change in debian/rules (this, I commited it). Your patch 0008 for the format 1.0 copyright file is just wrong, so I did the work by myself. 3/ Packaging in team libjs-extjs is in fact maintained inside the pkg-javascript group, I forgot about this. So what you need to do is to request to join the pkg-javascript group on Alioth. I would also suggest you to register to the pkg-javascript-devel@lists.alioth.debian.org list as well (not mandatory though), which I am Cc-ing here. 4/ New version The git now contains a debian-experimental and a upstream experimental branches. Please use these, and git-buildpackage to produce the new binary. Note that you will need the new .orig.tar.gz which I have prepared here: http://archive.gplhost.com/pub/libjs-extjs_3.4.0+dfsg0.orig.tar.gz Thanks for your interest and will to contribute to Debian, Cheers, Thomas ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
