[Pkg-javascript-devel] GitLab (salsa)

2018-03-04 Thread Sebastiaan Couwenberg
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

2018-02-25 Thread Sebastiaan Couwenberg
On Fri, 13 Oct 2017 02:21:28 +0300 Adrian Bunk  wrote:
> 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

2018-02-09 Thread Sebastiaan Couwenberg
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 ?

2017-12-25 Thread Sebastiaan Couwenberg
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

2017-10-29 Thread Sebastiaan Couwenberg
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

2017-03-19 Thread Sebastiaan Couwenberg
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

2017-01-29 Thread Sebastiaan Couwenberg
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'

2016-10-19 Thread Sebastiaan Couwenberg
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

2016-10-10 Thread Sebastiaan Couwenberg
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

2016-10-09 Thread Sebastiaan Couwenberg
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

2016-10-06 Thread Sebastiaan Couwenberg
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

2016-09-21 Thread Sebastiaan Couwenberg
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

2016-09-16 Thread Sebastiaan Couwenberg
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

2016-07-15 Thread Sebastiaan Couwenberg
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

2016-04-08 Thread Sebastiaan Couwenberg
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

2016-04-08 Thread Sebastiaan Couwenberg
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

2016-04-08 Thread Sebastiaan Couwenberg
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

2016-04-08 Thread Sebastiaan Couwenberg
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

2016-04-08 Thread Sebastiaan Couwenberg
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)

2016-03-13 Thread Sebastiaan Couwenberg
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

2016-02-02 Thread Sebastiaan Couwenberg
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?

2015-11-06 Thread Sebastiaan Couwenberg
-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

2015-07-14 Thread Sebastiaan Couwenberg
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

2015-07-12 Thread Sebastiaan Couwenberg
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

2015-07-12 Thread Sebastiaan Couwenberg
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

2015-07-12 Thread Sebastiaan Couwenberg
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

2015-06-14 Thread Sebastiaan Couwenberg
-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

2015-04-08 Thread Sebastiaan Couwenberg
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

2015-04-04 Thread Sebastiaan Couwenberg
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

2015-04-04 Thread Sebastiaan Couwenberg
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

2015-03-19 Thread Sebastiaan Couwenberg
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

2015-03-17 Thread Sebastiaan Couwenberg
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

2015-03-15 Thread Sebastiaan Couwenberg
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

2015-03-14 Thread Sebastiaan Couwenberg
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

2015-03-11 Thread Sebastiaan Couwenberg
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

2015-03-09 Thread Sebastiaan Couwenberg
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

2015-03-01 Thread Sebastiaan Couwenberg
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