[Pkg-javascript-devel] GitLab (salsa)
Marcelo Jorge Vieira wrote: > Alioth was deprecated and our repositories will *not* be automatically > migrated to the new instance (Gitlab). I've created the js-team group > there and everybody is welcome. > > https://salsa.debian.org/groups/js-team Please give my account Master permissions so I can create the node-mapnik repository, or create the repository for me. Kind Regards, Bas -- 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#872547: Already fixed in experimental
On Fri, 13 Oct 2017 02:21:28 +0300 Adrian Bunkwrote: > mapnik-reference builds in experimental: Moving that to unstable will break node-carto at runtime. Updating node-carto to a new upstream release is blocked by missing (build) dependencies. We should probably remove both packages and their reverse dependencies (node-mapnik & node-tilelive-{bridge,vector,mapnik}). Kind Regards, Bas -- 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#889962: node-mapnik FTBFS with mapnik-vector-tile 1.6.0+dfsg-1
Control: tags -1 upstream Control: forwarded -1 https://github.com/mapnik/node-mapnik/issues/843 Upsteam is working on 3.6.3 which will support mapnik-vector-tile 1.6.0. Since node-mapnik is not in testing anyway breaking it with mvt is not an issue for the time being. Kind Regards, Bas -- 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] can i upload nodejs 8 LTS in unstable ?
On 12/25/2017 08:00 PM, Mattia Rizzolo wrote: > Please do move nodejs 8 to unstable! Doesn't that trigger a transition, and hence the need to coordinate with the Release Team? https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#880072: Bug#880072: node-mapnik doesn't appear to be linking correctly, making it unusable
On 10/29/2017 11:03 AM, Adam Conrad wrote: > On both Debian and Ubuntu, executing the simple autopkgtest command for > node-mapnik (nodejs -e "require('mapnik');") leads to an error resolving > symbols: This is a known issue. And not one I'm willing to spend time on, since there are no known users of the node-mapnik package. The Mapnik ecosystem is quite fragile, with an upstream who relies on mason builds (often from development branches), making packaging quite a chore. I think the node-mapnik package and its node-tilelive-* rdeps should be removed from Debian (and by extension Ubuntu), and we should give up on ever packaging kosmtik (#805308). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#734101: update on RC bug#734101: libjs-jquery-mobile not working
On 03/19/2017 07:30 PM, Paul Gevers wrote: > libwireshark-data depends on libjs-openlayers. And libjs-openlayers-doc, > build from the same source, depends on libjs-jquery-mobile. Also horde > depends on libjs-jquery-mobile. > > [...] > > However, other solutions may lay in the direction of > removing/downgrading dependencies of libjs-openlayers on > libjs-jquery-mobile (how much is it needed for a documentation > package?), removing the horde dependency (apparently the Horde usage is > broken already since 2014, see bug 749799 in CC) and similar dependency > tree resolutions. I'll try to make time to look into this, but don't > mind if other people beat me to it. OpenLayers 2.x is dead upstream, they have switched to Node.js since 3.x. Packaging that turned out to be worth the effort, the dependency chain is too large and (tiny) Node.js packages still trigger too many discussions in Debian. The OpenLayers.js provided by libjs-openlayers is still used by several packages, so I'd like to keep it around for a while longer. Based on the popcon for openlayers dropping the -doc package is not likely to adversely affect users. If that makes life for others easier, I'm happy to stop building that binary package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#850660: Bug#850660: nodejs-dev: npm conflicts transitively with libssl-dev since nodejs-dev 4.7.2~dfsg-1
On 01/29/2017 02:31 PM, Jonas Smedegaard wrote: > Quoting ano...@users.sourceforge.net (2017-01-29 14:12:59) >> I've been unable to upgrade nodejs and nodejs-dev thanks to this issue: >> I need npm for some things, but also php7.0-dev (which depends on >> libssl-dev) for something else. > > Please share what it is that - transitively or not but _concurrently_ - > needs both libssl-dev. A system with (build) dependencies for multiple packages installed. My unstable system is also affect by this issue, it has php7.0-dev installed as part of the php-geos build dependencies. Those packages need to be removed to allow the upgrade of nodejs & nodejs-dev. Because of the unholy mess that is the OpenSSL 1.1.0 transition and the complications it brings for the upcoming freeze, Julien Cristau has suggested to "go back to shipping libssl-dev as 1.0.2 for stretch, and rebuild the world" [0]. I hope that this happens so that we get rid of issues like this one caused by libssl-dev and libssl1.0-dev conflicting. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061#1427 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#841274: node-define-property: FTBFS: Error: Cannot find module 'wrappy'
On Wed, 19 Oct 2016 20:06:54 +0200 (CEST) Santiago Vila wrote: > If anybody reading this could tell me how we arrived at having so many > one-day-old unbuildable packages in unstable, I'm still curious about it. Because node-once was updated to a new upstream release which now requires node-wrappy but didn't add this to its dependencies. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#838440: Bug#838440: Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries
On 10/09/2016 11:02 PM, Sebastiaan Couwenberg wrote: > On 10/09/2016 10:25 PM, Jérémy Lal wrote: >> Now the same is going to happen with "powerpc" arch: libv8 is actually not >> compatible with all processors supported by debian (ppc64xx are ok, though). >> >> Sebastiaan, i feel bad asking for your help again, but since you already >> filled all the RM bugs once, i suppose you're in the best position to do it >> again >> for powerpc. > > Sure, the list of immediately affected packages is limited. There has been some progress getting the RM bugs processed. Several of for armel are still outstanding, which may be due to the dependency problems reported by dak for reverse dependencies. I thought that arch:all reverse dependencies didn't need to be removed too, but I may be mistaken in that although dak has the option --no-arch-all-rdeps for apparently that reason. I'll follow up on the outstanding bugreports to mention that only arch:all rdeps are reported by dak in the dependency problems. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#838440: Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries
On 10/09/2016 10:25 PM, Jérémy Lal wrote: > Now the same is going to happen with "powerpc" arch: libv8 is actually not > compatible with all processors supported by debian (ppc64xx are ok, though). > > Sebastiaan, i feel bad asking for your help again, but since you already > filled all the RM bugs once, i suppose you're in the best position to do it > again > for powerpc. Sure, the list of immediately affected packages is limited. Is there a bugreport or other reference for the powerpc issue I can include for more information in the RM bugs? Currently nodejs still built successfully on powerpc, so filing the RM bugs is a bit premature. The affected packages were retrieved from UDD as follows: udd=>SELECT DISTINCT source udd-> FROM packages udd-> WHERE distribution = 'debian' udd-> AND release = 'sid' udd-> AND architecture = 'powerpc' udd-> AND source != 'nodejs' udd-> AND (dependsLIKE '%nodejs%' OR udd(>recommends LIKE '%nodejs%') udd-> ORDER BY source udd-> ; source - almond codelite node-bones node-expat node-groove node-iconv node-leveldown node-mapnik node-sqlite3 node-srs node-stringprep node-topcube node-websocket node-ws node-xmlhttprequest node-zmq (16 rows) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#838440: Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries
On 10/06/2016 12:21 PM, Jérémy Lal wrote: > 2016-09-21 11:53 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: > >> On 09/21/2016 11:34 AM, Jérémy Lal wrote: >>> 2016-09-21 10:24 GMT+02:00 Emilio Pozuelo Monfort <po...@debian.org>: >>>> I see you dropped support for armel in #818552 and requested the removal >>>> of the outdated armel binaries. That's fine. However, nodejs doesn't >>>> migrate to testing because the lack of armel binaries breaks a number >>>> of packages that depend on nodejs on armel: >>>> >>>> trying: nodejs >>>> skipped: nodejs (15, 0, 81) >>>> got: 68+546: a-3:i-18:a-0:a-11:a-0:m-0:m-0:p-35:p-0:s-1:m-546 >>>> * armel: node-almond, node-groove, node-iconv, node-leveldown, >>>> node-node-expat, node-sqlite3, node-topcube, node-websocket, node-ws, >>>> node-xmlhttprequest, qtwebchannel5-examples >>>> >>>> Those need to get their armel binaries removed as well. >>>> >>> >>> Thank you for your help, at some point i believed the request for removal >>> implied removal of dependencies as well. >>> Should i make another removal request ? Would you like to do it ? I'm >>> super-busy right now. >> >> I've filed the RM bugs for the affected packages, some more may be >> required for their reverse dependencies. > > Thank you. Can we close this bug now ? No, ftp-master has not removed all the rdeps yet, so there are still RM bugs blocking this issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#838440: Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries
On 09/21/2016 11:34 AM, Jérémy Lal wrote: > 2016-09-21 10:24 GMT+02:00 Emilio Pozuelo Monfort: >> I see you dropped support for armel in #818552 and requested the removal >> of the outdated armel binaries. That's fine. However, nodejs doesn't >> migrate to testing because the lack of armel binaries breaks a number >> of packages that depend on nodejs on armel: >> >> trying: nodejs >> skipped: nodejs (15, 0, 81) >> got: 68+546: a-3:i-18:a-0:a-11:a-0:m-0:m-0:p-35:p-0:s-1:m-546 >> * armel: node-almond, node-groove, node-iconv, node-leveldown, >> node-node-expat, node-sqlite3, node-topcube, node-websocket, node-ws, >> node-xmlhttprequest, qtwebchannel5-examples >> >> Those need to get their armel binaries removed as well. >> > > Thank you for your help, at some point i believed the request for removal > implied removal of dependencies as well. > Should i make another removal request ? Would you like to do it ? I'm > super-busy right now. I've filed the RM bugs for the affected packages, some more may be required for their reverse dependencies. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Bug#837929: Bug#837929: npm: Should suggest nodejs-legacy
On 09/16/2016 09:57 AM, Matijs van Zuijlen wrote: > I read through bug 614907, and I think the very best solution would be > for npm to ensure the correct node executable is referenced in each > package's executable. I don't know how feasible that would be. That's unfeasible in my opinion. The best you can get expect is for npm to suggest nodejs-legacy to help remind you that you need that package for /usr/bin/node. All Node.js users on Debian should already be familiar which that situation and install nodejs-legacy when they need it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Current best practices for packaging small modules for Node.js
On 07/15/2016 01:34 PM, Mathias Behrle wrote: > Before proceeding further I would like to get an ACK from the side of > pkg-javascript-devel (that this is the way to go) as well as from ftpmasters, > if > such a package will be allowed to enter the archive. In the discussion about small packages ftp-master acknowledged that we don't have the tools to handle bundled packages, so would accept small node packages for lack of a better alternative, see: https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-August/011067.html Packaging the small node modules for in your dependency chain should not be blocked because of the small size argument. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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#791725: Bug#791725: node-mapnik: FTBFS against mapnik 3.0.0
On 04/08/2016 02:20 PM, Jérémy Lal wrote: > 2016-04-08 14:04 GMT+02:00 Sebastiaan Couwenberg: >> The test target fails because it requires node-pre-gyp, as do the >> bin/mapnik-*.js executables. We'll need to patch those to not require >> node-pre-gyp too. >> >> Do you have any suggestions for that? > > Yes, i have: i'm packaging node-pre-gyp and rc modules, it seems pkg-tar > could stay a recommandation. > It will be way simpler than spending the time patching node-mapnik. Thanks! I've patched the mapnik-*.js executables to not require node-pre-gyp, that just leaves lib/mapnik.js which uses it to find mapnik_settings.js. Since its path differs between the build environment and after installation, I'm not sure if we can make it support both without node-pre-gyp. I think I'll leave the node-mapnik packaging as it is for now, add have another look when node-pre-gyp is available or if it becomes clear we can work around it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#791725: Bug#791725: node-mapnik: FTBFS against mapnik 3.0.0
On 04/08/2016 01:54 PM, Jérémy Lal wrote: > 2016-04-08 12:49 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: > >> On 04/08/2016 12:34 PM, Jérémy Lal wrote: >>> 2016-04-08 12:24 GMT+02:00 Sebastiaan Couwenberg: >>>> Currenly `node-gyp configure` fails with: >>>> >>>> gyp: Undefined variable module_path in binding.gyp while trying to load >>>> binding.gyp >>>> >>>> If it's possible to fix that by using the system provided dependencies, >>>> it may be feasible to get node-mapnik working again. >>>> >>>> >>> The generic way of getting rid of these: >>> >>> node-gyp configure --module_name=`nodejs -e >>> "console.log(require('./package.json').binary.module_name)"` >>> --module_path=`nodejs -e >>> "console.log(require('./package.json').binary.module_path)"` >>> >>> >>> Updating node-mapnik is looking good; but I have trouble with >>> >>> In file included from /usr/include/vector_tile_merc_tile.hpp:5:0, >>> from ../src/mapnik_vector_tile.hpp:11, >>> from ../src/node_mapnik.cpp:5: >>> /usr/include/vector_tile_tile.hpp:208:32: fatal error: >>> vector_tile_tile.ipp: Aucun fichier ou dossier de ce type >>> >>> does it ring a bell ? >> >> Yes, the .ipp file is included in the mapnik-vector-tile source, but not >> installed in the binary package. >> >> I'll update mapnik-vector-tile to install the .ipp files too. > > I've just tested with those files installed by hand and it works all right. Yes, I've got similar results after some more changes to the node-mapnik packaging. The test target fails because it requires node-pre-gyp, as do the bin/mapnik-*.js executables. We'll need to patch those to not require node-pre-gyp too. Do you have any suggestions for that? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#791725: Bug#791725: node-mapnik: FTBFS against mapnik 3.0.0
On 04/08/2016 12:34 PM, Jérémy Lal wrote: > 2016-04-08 12:24 GMT+02:00 Sebastiaan Couwenberg: >> Currenly `node-gyp configure` fails with: >> >> gyp: Undefined variable module_path in binding.gyp while trying to load >> binding.gyp >> >> If it's possible to fix that by using the system provided dependencies, >> it may be feasible to get node-mapnik working again. >> >> > The generic way of getting rid of these: > > node-gyp configure --module_name=`nodejs -e > "console.log(require('./package.json').binary.module_name)"` > --module_path=`nodejs -e > "console.log(require('./package.json').binary.module_path)"` > > > Updating node-mapnik is looking good; but I have trouble with > > In file included from /usr/include/vector_tile_merc_tile.hpp:5:0, > from ../src/mapnik_vector_tile.hpp:11, > from ../src/node_mapnik.cpp:5: > /usr/include/vector_tile_tile.hpp:208:32: fatal error: > vector_tile_tile.ipp: Aucun fichier ou dossier de ce type > > does it ring a bell ? Yes, the .ipp file is included in the mapnik-vector-tile source, but not installed in the binary package. I'll update mapnik-vector-tile to install the .ipp files too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#791725: Bug#791725: node-mapnik: FTBFS against mapnik 3.0.0
On 04/08/2016 12:09 PM, Jérémy Lal wrote: > 2016-04-08 11:32 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: > >> On Wed, 8 Jul 2015 09:31:46 +0200 Jérémy Lal wrote: >>> 2015-07-07 23:43 GMT+02:00 Emilio Pozuelo Monfort <po...@debian.org>: >>>> Your package fails to build against mapnik 3.0.0: >>> >>> Thanks, it's going to be like this until gcc5 and latest boost libs are >>> available (which should be this summer). >> >> More recent node-mapnik versions are required for their Mapnik 3.x >> support, but these require the unpackaged node-pre-gyp to build. >> >> Perhaps it's better to remove node-mapnik and its reverse dependencies >> from the archive since they haven't seen any activity in over two years. >> > > Let me see if updating it goes smoothly. If not then i'll request the > removal. Thanks, that's much appreciated. I've pushed my initial changes for node-mapnik 3.5.8 to Alioth. > FYI node-pre-gyp is a useless module in debian because it is made to > download binaries from remote sources instead of properly compiling. Currenly `node-gyp configure` fails with: gyp: Undefined variable module_path in binding.gyp while trying to load binding.gyp If it's possible to fix that by using the system provided dependencies, it may be feasible to get node-mapnik working again. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#791725: Bug#791725: node-mapnik: FTBFS against mapnik 3.0.0
On Wed, 8 Jul 2015 09:31:46 +0200 Jérémy Lal wrote: > 2015-07-07 23:43 GMT+02:00 Emilio Pozuelo Monfort: > > Your package fails to build against mapnik 3.0.0: > > Thanks, it's going to be like this until gcc5 and latest boost libs are > available (which should be this summer). More recent node-mapnik versions are required for their Mapnik 3.x support, but these require the unpackaged node-pre-gyp to build. Perhaps it's better to remove node-mapnik and its reverse dependencies from the archive since they haven't seen any activity in over two years. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Bug#742347: Bug#742347: overview of the tilemill situation and alternatives (mapbox, kosmtik)
On 13-03-16 18:18, Jérémy Lal wrote: > 2016-03-13 16:40 GMT+01:00 Antoine Beaupré: > >> >> 9. Oh, and finally one could mention another Mapbox project, >> [Carto][], a commandline CSS tools that implements some sort of >> standard CSS language that all those tools end up using to talk to >> Mapnik, more or less. There are no RFPs for that. >> >> [Carto]: https://github.com/mapbox/carto > > > carto is in debian - it needs to be updated, though (node-carto) mapnik-reference needs to be packaged for the new carto version, and semver may need to be upgraded: Dependencies: NPM Debian carto (0.15.3)node-carto (0.9.5-2) ├─ mapnik-reference (~8.5.0) None │ └─ semver (^5.1.0) node-semver (2.1.0-2) ├─ optimist (~0.6.0) node-optimist (0.6.1-1) └─ underscore (~1.6.0)underscore (1.7.0~dfsg-1) Build dependencies: NPM Debian coveralls (~2.10.1) None istanbul (~0.2.14)None jshint (0.2.x)None mocha (1.12.x)node-mocha (1.20.1-1) sax (0.1.x) sax.js (0.5.5-1) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#813239: [acorn] Some sources are not included in your package
On Sat, 30 Jan 2016 20:03:38 +0100 Bastien ROUCARIÈS wrote: > In order to solve this problem, you could: > 1. add the source files to "debian/missing-sources" directory. > 2. repack the origin tarball and add the missing source files to it. Option 3. Remove acorn from the archive because adoption is not going to happen any time soon. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#742347: Fwd: Re: Bug#742347: Bug#742347: tilemill vs mapbox studio?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06-11-15 16:16, Ross Gammon wrote: > Also not sure if Bas is still reading Javascript list (so cc'd). I am, so need to CC. Kind Regards, Bas - -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWPMaeAAoJEGdQ8QrojUrxfX8P/0KzMJ+/5Km0ElKoDE89sJOn RdTGsxqhJDwHAdL2c7qZgW21ijpgbYAm5AzpgIt2x5sfXusc+DDMkTBiqHjYu783 T+5+GU5ePq1wru6z1RGgMIkGkLoAyzERJxGoApE5q4ZXxJ9QEiiW/jCSsWTqQDuD dbU9xvm24eesRMjznGMrzzGoij+FjDD2WQfXG8pMJWVplgY5S95FV5quNLmcEuQw dkKBMcg7xubpGQb+pKVaq8qQ7SqtdNhdJ12wMxDqJeMW9dL5ctSHhtXZBYTY17iO W7lxiU7kweCikI7y0P0IIVaL/0WRmbvPbNaSDvi05zXq52vdtakY5CilGpT1sEQ4 lqmMo/12KDRuT/5zaFfk2rmbbMI2JBTZ8RTwszTYFHE0Rk8qGTNUwyD0HXBFTxQz eskvKTY+QZOuzEEHYBa7N+NDNRx+8xrfHSj8Ah0GmuH7iabzLhOIBUd+aQaPq4QF FKop9hD7X0VMh6GZ8vH3DCZpDG+XAo6TMcN2kRI3cqohlk+mYmip1y4YbTcpDpit Fhjg8htfMcVIwYF2Kd+94IkrbdWP7qmDbMRa9kAGBkNAuUO01+8SKDBHHrCPAsf9 B3HqUgSuoAbrLqjxyff/yDv1IV2JITV8lE5pu+MWvSPejeM/D+VZDeH1gQmZVZue pbQPQmwI8WmiivDPjcHa =jE74 -END PGP SIGNATURE- ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-absolute-path_0.0.0-1_amd64.changes REJECTED
Hi Thorsten, Thanks for the further rejections. On 07/13/2015 10:30 PM, Thorsten Alteholz wrote: On Sun, 12 Jul 2015, Sebastiaan Couwenberg wrote: Thanks for finally rejecting packages too small to meet the criteria. What about node-nextback? I didn't want to spoil your weekend, so I started with only two packages. Don't worry about that, I have plenty of other (non-Node.js) packages to keep my occupied. It's probably better to reject all remaining Node.js packages I've uploaded, as I'm giving up on the OpenLayers 3 packaging. Ok, sorry. No problem. Can you also reject the remaining node-* packages I've got left in NEW? node-junk node-mkpath node-buffers node-binary node-touch Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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-absolute-path_0.0.0-1_amd64.changes REJECTED
Hi Thorsten, Thanks for finally rejecting packages too small to meet the criteria. On 07/12/2015 01:00 AM, Thorsten Alteholz wrote: this has the same problem as node-isarray ... What about node-nextback? It is required for node-gaze along with node-absolute-path to fix #784350. Since we don't have an acceptable solution for bundling these small Node.js packages, I won't be able to complete the OpenLayers 3 packaging. It's probably better to reject all remaining Node.js packages I've uploaded, as I'm giving up on the OpenLayers 3 packaging. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Small binary packages
On 07/13/2015 02:40 AM, Ben Finney wrote: Ben Finney ben+deb...@benfinney.id.au writes: What are the proposals to package small libraries of JavaScript code? Looking through the archive, I get the impression that one approach which could work is to collect multiple separate works by some related theme, and distribute some smaller number of larger, aggregate binary packages. Examples include the packages ‘emacs-goodies-el’ and ‘devscripts’: these pacakges don't go to special effort to integrate the code, they just bundle them together for ease of packaging and maintenance. Would that be feasible for small JavaScript libraries? Surely many of them can be grouped together by some common theme, and maintained as aggregate Debian packages. This is the most obvious approach. It was also discussed in the 'Small Node.js packages in NEW' thread: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-April/010242.html http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-June/010692.html One significant downside to bundling small Node.js packages is that an RC bug on one of the included modules threatens removal of all unrelated reverse dependencies too. There is also missing infrastructure to keep track of multiple upstreams in a single package. Some wrapper around uscan with multiple watch files and/or some server side helper will be needed for this. While it's something I could work on, I don't have the time nor motivation for it. Have a look at the 'OpenLayers 3' thread for all the Node.js packages that need someone else to take care of them: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-July/010798.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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] OpenLayers 3
Hi all, I'm giving up on the OpenLayers 3 packaging, because packaging Node.js projects is too painful. There is no acceptable solution to the small Node.js module bundling problem among others. The small Node.js modules need to be bundled in other packages because FTP-master won't accept separate packages when their binary size (excluding /usr/share/doc and other meta information) is less than 5kB. For more information about the FTP master stance, see the 'Small Node.js packages in NEW' thread on pkg-javascript-devel: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-April/010242.html http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-June/010692.html I've made some progress packaging the OpenLayers 3 dependency chain, see: https://wiki.debian.org/Javascript/Nodejs/Tasks/openlayers But I won't be able to complete it. I will be orphaning the Node.js packages I'm the only uploader of in the Javascript team. I'm tempted to even ask for removal from the archive, if no-one from the Javascript team wants to take over these packages. The packages in question: acorn node-gaze (still requires nextback absolute-path, see #784350) node-globule node-minimist (node-optimist dependency, has no other Uploaders) node-q node-tmp I will remove myself from Uploaders of the following packages: node-optimist node-tar I've asked FTP master to REJECT the Node.js packages I've uploaded that are still in NEW, these are: node-after (also required by Julien Puydt see #789912) node-ansi-regex node-ansi-styles node-arraybuffer.slice node-balanced-match node-base64-arraybuffer node-binary node-blob node-brace-expansion node-buffers node-concat-map node-core-util-is node-decompress-zip node-escape-string-regexp node-fs-extra node-get-stdin node-jsonfile node-junk node-mkpath node-nextback node-request-progress node-string-decoder node-supports-color node-touch node-throttleit Ross Gammon packaged the following Node.js module, still in NEW too: node-cli-table node-coffeeify node-convert-source-map node-cross-spawn I'm not sure if he want to give up on Node.js packaging too, but it's very likely since there packages are part of the OpenLayers 3 dependency chain too. I'll also give up on the following ITP/RFPs and close them: closure-util mout node-absolute-path node-bluebird node-chalk node-component-emitter node-engine.io node-engine.io-client node-engine.io-parser node-foreachasync node-get-down node-handlebars node-has-ansi node-has-binary node-has-binary-data node-isarray node-nomnom node-socket.io-adapter node-socket.io-client node-socket.io-parser node-strip-ansi node-utf8 node-walk openlayers3 I'll leave the git repositories for all these packages on Alioth after removing myself from the Uploaders field. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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#788717: Bug#788717: acorn: please make the build reproducible
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: tags -1 pending Hi Reiner, Thanks for reporting this issue, it was already fixed in git for some time but because the package was still in NEW until recently I hadn't uploaded a new revision yet. The fixed package will be uploaded shortly. Kind Regards, Bas - -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVfY1CAAoJEGdQ8QrojUrxYz8P/ixnLI1JoEeFdrvBwCk/Ag2b f/Jvm1JdbhcIhvWESe37UZYLIm6/8rIYwdST050hAVJcwMXbVYcUfRpSMOF9VNP0 bi10dtGU7EcsZqRCTyJDK9GBxms/Dy9ASBDJ55LuFqsDc9H/RQNHr/0LvO0mCxun y4/D5BlgwkVPz6ENwKM724lH+9hguG5eCsTH1fWo/NOay3lc/u8YUQM61kpDMmJh KaY9X3Jyk0i2hBXnEjrQxamm/kqMrd3qpS/7RP5ZwYEsc1ZVSxDMK4rAo/qK1fO8 kIzCwN1R1he6jJ0lvbvG4uceV08vOYXQITSXQdpsOBNX3YNxr5B8In2J6YHbHV09 Qa0lpJAKT1pE1srrEtnSSbpvifJXIP12DmwvVM+WWZGHSTwRGosbgvhEzuaH+VMT JF1GHYKgERxllgtNyuuFw52QX1ZkSkkB05T+xujj7p5Hlo3z3nnxYUVvsvFqFM8K FHvpVIxkTFbBl/O9Q57fdrJAOeaqmEviIlB6W0iVapMb/RfWx3LSWege+6AF7/Jr jWmUAbqoCLmsZw+n+8U10bCNSD0ZeO2O057+T1o7HiLoZIE+NOEhiunwcLmZP77P JtzOtxX+LmvquCaZRRKlmIbzJHVOeEh8y89bEwUL/w3SZT3LI+IvAeLRflYgYR9Y WkNC0nUibCbDq2ZCbuOs =8K5j -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] Small Node.js packages in NEW
Hi Thorsten, I'm reluctantly looking into this issue further, but I need to know what requirements an Node.js module must meet to be eligible for its own source package. What are your requirements for this? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Small Node.js packages in NEW
Hi Thorsten, Thanks for your work on the NEW queue. On 2015-04-03 Thorsten Alteholz wrote on his blog [1]: Recently the NEW queue grew due to lots of uploads of new KDE software and several smaller node-packages. The KDE-stuff will be processed one after another, but the node-stuff seems to be rather strange. After the last discussion I was told that all those small packages can be accumulated into bigger chunks. I hope this discussion doesn’t need to be repeated again … Since I'm responsible for quite a number of these Node.js packages, I'm afraid further discussion is required. I suspect the last discussion was about the node-chalk package and its dependencies. After the initial packager abandoned the effort Jérémy did some work to bundle the dependencies, but did not follow through to an actual upload. I picked up the chalk related packages because they're part of the OpenLayers 3 dependency chain [2], but decided against bundling the dependencies because it complicates the packaging too much. While the chalk dependencies are at this time only required for chalk, they have many more dependents [3-7] in the Node.js ecosystem. When we package some of those dependents they should in my opinion depend only on the (small) module package instead of the chalk because they need one of its dependencies. Instead of bundling the dependencies in the dependent package, we could also introduce a nodejs-modules package to bundle various small modules. This look a little cleaner to me dependency-wise, but it still has the same drawbacks of pulling in more than required and the one-to-many relationship between the source package and its various upstreams complicates the packaging too much. Do you have a better solution to the small Node.js packages problem? I think that the way the Node.js module ecosystem is structured warrants an exception to the avoid small packages guideline. Kind Regards, Bas [1] http://blog.alteholz.eu/2015/04/my-debian-activities-in-march-2015/ [2] https://wiki.debian.org/Javascript/Nodejs/Tasks/openlayers [3] https://www.npmjs.com/package/ansi-styles [4] https://www.npmjs.com/package/escape-string-regexp [5] https://www.npmjs.com/package/has-ansi [6] https://www.npmjs.com/package/strip-ansi [7] https://www.npmjs.com/package/supports-color -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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, Thanks for the feedback. On 04/04/2015 03:12 PM, Thorsten Alteholz wrote: Debian is running on lots of different types of computers ranging from high end number crunchers to low end Raspberry PIs or embedded devices. While installing/updating a package all of them have to download the complete package information and parse it over and over again. This is not a problem for high end computers with good network connectivity, but low end computers might have a problem. As we have seen in the past there are memory constraints or the whole process just consumes too much time. I admit that there is lots of room for improvement in Debians package handling, but at the moment we just have what we have. Parsing the apt metadata on low-powered hardware is a legitimate concern. I have experienced this myself with running Debian on embedded hardware for a firewall system. Looking at the popcon statistic of nodejs, the numbers are growing but compared with the numbers of dpkg, they are still rather low. So I would say the overhead of those nodejs users that need to install a few kB of superfluous code is not as bad as the resource consumption of all other users. The disk usage of nodejs module bundle packages is also least of my concerns. My primary concern is the increased maintenance burden caused by the one-to-many relationship between the source package and its various upstreams. I'm not enthusiastic about trying to solve this problem with a nodejs-modules package that bundles various small modules. But it seems the only way to address the metadata concern. I don't have a better solution for small packages, but as long as there is no improvement in package handling, I think there should be no exception. I would still prefer the bundling of several small packages into bigger chunks. Isn't git able to handle several upstreams in one repository? Per module upstream branches may have their place in the eventual solution. I'm thinking about per module watch files and an extensive get-orig-source script to handle them, these separate tarball can then be imported to their module specific upstream branch with git-import-orig. We'll also need a wrapper around uscan that can better report the update status of the various upstreams. AFAIK it's not possible to replace the watch file with an executable script like the install files for example do allow. Because I can't envision a good solution to the bundling problem, I strongly prefer not to. Bundling separate upstreams in a single source package is also very uncommon for other language packages. Should Node.js really be treated differently? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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] chalk packaging
Hi Andrew Jérémy, I've found your packaging for node-chalk and most of its dependencies and their related ITPs (#753410, #753254, #753275, #753321, #753269). What was the reason to no longer intent to package these? Are the dependencies really that strict to requiring bundling the dependencies? I want to get these packages into the archive because node-chalk is required for node-nomnom, which in turn is required for closure-util openlayers. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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-tar_1.0.3-1_amd64.changes ACCEPTED into unstable
On 03/15/2015 10:29 PM, Jérémy Lal wrote: i'd rather not fix the situation right now with an epoch, and instead please upload your merged version instead, and let it hang in unstable until global warming (as opposed to deep freeze). If you want to have a usable node-tar 1.0.3, you can update node-fstream in experimental (i trust you for not fu...g up a second time :). Feel free to convince me otherwise on IRC and let's use this channel for sharing the conclusion. As discussed on IRC, I've uploaded a fixed revision of node-tar to unstable: https://tracker.debian.org/news/675116 It also drops the version dependency on node-fstream (= 1.0.2) which is unavailable in unstable. This resolves the piuparts issue. node-fstream 1.0.4 is now available in experimental: https://tracker.debian.org/news/675184 I've also updated node-fstream-ignore to 1.0.2, but since it bumps the minimum required node-minimatch to = 2.0.1 and we only have 1.0.0 in Debian minimatch needs to be updated first. node-minimatch 2.0.0 adds a dependency on brace-expansion = 1.0.0, branch-expansion and its dependencies are not yet packaged in Debian. Expect ITPs for the brace-expansion packages soon, once those pass NEW I'll uploaded node-minimatch 2.0.x node-fstream-ignore 1.0.x to experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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-tar_1.0.3-1_amd64.changes ACCEPTED into unstable
Hi Jérémy, On 03/14/2015 01:38 PM, Sebastiaan Couwenberg wrote: On Sat, Mar 14, 2015 at 2:29 AM, Jérémy Lal kapo...@melix.org wrote: Did you just hijack node-tar that was already in the archive ? Apparently I fucked that up. I didn't look well enough to see that it was already packaged. I'm sorry about that, and I will revert my upload by restoring the previous version with an epoch unless there is no objection to the 1.0.3 version, then I will merge Jérémys packaging changes back. How do you want to proceed Jérémy? The 1.0.3-1 version of node-tar is not installable due to the unavailability of node-fstream (= 1.0.2). This in turns makes npm node-gyp uninstallable. Instead of sticking to the 1.0.3 upstream version, it's probably better to revert back to the 0.1.18 upstream version by uploading the previous package revision as 1:0.1.18-1 to supersede the newer upstream version. Please let me know whether you are apposed to this or not. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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-tar_1.0.3-1_amd64.changes ACCEPTED into unstable
On 03/14/2015 11:23 AM, Leo Iannacone wrote: On Sat, Mar 14, 2015 at 2:29 AM, Jérémy Lal kapo...@melix.org wrote: Did you just hijack node-tar that was already in the archive ? Apparently I fucked that up. I didn't look well enough to see that it was already packaged. I'm sorry about that, and I will revert my upload by restoring the previous version with an epoch unless there is no objection to the 1.0.3 version, then I will merge Jérémys packaging changes back. How do you want to proceed Jérémy? Please contact pkg-javascript and try to coordinate your uploads with this team. Check its wiki, read what npm2deb says about the modules you're packaging. My ITPs and RFPs for the openlayers project all go to the javascript list too. I'm also using the wiki to track the progress: https://wiki.debian.org/Javascript/Nodejs/Tasks/openlayers For such a loosely coordinated team, that seems the best I can do. For instance, the team was avoiding node-readable-stream for some reason. It would have been nicer to discuss and get some advices before blindly uploading. The avoidance of readable stream was not documented, and there was an RFP documenting the need for a package even though the package it was originally needed for didn't require it anymore. 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. Please give more advice for the packages in the openlayers dependency chain. Moreover, 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. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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] Package team ownership
On 03/11/2015 08:43 AM, valentin OVD wrote: We have already updated node-lodash on the git and we will published the package when the Jessie freeze is over. You can already find the updated package on Alioth on the git of the pkg-javascript-team :) Why not upload the package to experimental in the mean time? I've been uploading new upstream release to experimental since the freeze started. It works quite well, and doesn't force unstable users to build the packages themselves. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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 node-q_1.1.2-1_amd64.changes
Hi Thorsten, On 03/09/2015 07:44 PM, Thorsten Alteholz wrote: I marked your package for accept, but you might want to add Pivotal Labs as copyright holder for jasmine. Thanks for pointing out this omission and reviewing a bunch of the node modules I've uploaded. I've updated the copyright and uploaded the new revision. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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] OpenLayers 3
On 12/28/2014 10:24 PM, Sebastiaan Couwenberg wrote: Johan and I have started to package OpenLayers 3 after the need for a package arose for OSGeo Live. OpenLayers 3 is quite different from OpenLayers 2, the switch to Node.js being the most prominent. The OpenLayers 3 build.py script uses npm to install its dependencies, not all of which are available in Debian yet. [...] The npm2deb package exists, which may be helpful to get some of these missing dependencies packaged. There has been some progress on the OpenLayer 3 packaging front. Progress is being tracked in the BTS with RFS ITP bugs and their inter-dependencies. Progress is also tracked in the Wiki using openlayers task: https://wiki.debian.org/Javascript/Nodejs/Tasks/openlayers npm2deb has proven itself to be very useful in bootstrapping basic packaging for Node.js modules. Not all build dependencies for Node.js modules exist, but because shipping the plain JavaScript source is often sufficient this is not a big problem. Help with packaging more of the OpenLayer 3 dependency tree is very much appreciated! Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel