Re: [Pkg-javascript-devel] Packages ready to review

2018-05-07 Thread Xavier
Updated list of packages to review:

 - node-mongodb
   - node-mongodb-core
   - node-require-optional
   - bson.js
 - node-nodedbi
 - node-file-cache-simple
   - node-fs-jetpack
 - node-inireader
 - node-q
 - node-syslog-client

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Packages ready to review

2018-05-09 Thread Xavier
Le 08/05/2018 à 10:55, Pirate Praveen a écrit :
> On തി, മേയ് 7, 2018 at 8:10 വൈകു, Xavier <x.guim...@free.fr> wrote:
>> Updated list of packages to review: - node-mongodb - node-mongodb-core
>> - node-require-optional
> 
> Try to enable tests.
> See https://wiki.debian.org/Javascript/Nodejs/Npm2Deb#Run_tests_if_available

Done for node-require-optional.
Test are enabled for all except node-mongodb* because a lot of
test-dependencies are missing in Debian

>> - bson.js
> 
> bson.js: I suggest you keep node-bson as source package name, remove
> nodejs depndency from node-bson binary package, remove libjs-bson binary
> package and just provide libjs-bson.

Done

> Also rebuild browser_build/bson.js using the provided webpack
> configuration. See
> https://wiki.debian.org/Javascript/Nodejs#Using_build_tools_like_grunt

OK, but this need to package babel-polyfill and used only to provide
browser lib (which is no more provided since renaming). I've so skipped
this step

> - node-nodedbi - node-file-cache-simple - node-fs-jetpack -
>> node-inireader - node-q - node-syslog-client Regards, Xavier

I packaged also node-modern-syslog

Regards,
Xavier


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] New packages to review

2018-04-30 Thread Xavier
Hi all,

I've packaged these libs:
- fs-jetpack.js,
- file-cache-simple.js,
- inireader.js,
- node-bufferlist,
- node-fastcgi-stream,
- node-fastcgi
- node-nodedbi.

@kapouer: could you review them ?

Best regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Packages ready to review

2018-05-01 Thread Xavier
Hi all,

these packages are ready for review (with dependencies):
 - node-fastcgi
   - node-fastcgi-stream
   - node-bufferlist
 - node-mongodb
   - node-mongodb-core
   - node-require-optional
   - bson.js
 - node-nodedbi
 - file-cache-simple.js
   - fs-jetpack.js
 - inireader.js
 - node-q

Best regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Packages ready to review

2018-05-02 Thread Xavier
Le 02/05/2018 à 08:07, Xavier a écrit :
> Le 02/05/2018 à 07:18, Pirate Praveen a écrit :
>>
>>
>> On ബു, മേയ് 2, 2018 at 10:44 രാവിലെ, Xavier <x.guim...@free.fr> wrote:
>>> Hi all, these packages are ready for review (with dependencies): -
>>> node-fastcgi - node-fastcgi-stream - node-bufferlist - node-mongodb -
>>> node-mongodb-core - node-require-optional - bson.js - node-nodedbi -
>>> file-cache-simple.js - fs-jetpack.js
>>
>> This seems to be a node module, so it is better to keep node- as
>> the source package name (the default by npm2deb).
> 
> Hello,
> 
> thanks, I'm going change fs-jetpack.js to node-fs-jetpack and
> file-cache-simple.js to node-file-cache-simple

Done for node-fs-jetpack, node-file-cache-simple and node-inireader.
List is now:
 - node-fastcgi
   - node-fastcgi-stream
   - node-bufferlist
 - node-mongodb
   - node-mongodb-core
   - node-require-optional
   - bson.js
 - node-nodedbi
 - node-file-cache-simple
   - node-fs-jetpack
 - node-inireader
 - node-q

Thanks!

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Packages ready to review

2018-05-02 Thread Xavier
Le 02/05/2018 à 13:22, Pirate Praveen a écrit :
> On ബുധന്‍ 02 മേയ് 2018 02:21 വൈകു, Xavier wrote:
>> Done for node-fs-jetpack, node-file-cache-simple and node-inireader.
>> List is now:
>>  - node-fastcgi
>>- node-fastcgi-stream
>>- node-bufferlist
> 
> Uploaded. Next time you can use compat 11 and also remove unnecessary
> dh-buildinfo build dependency (not required for debhelper >= 10).

Done for:
 - node-mongodb
   - node-mongodb-core
   - node-require-optional
   - bson.js
 - node-nodedbi
 - node-file-cache-simple
   - node-fs-jetpack
 - node-inireader
 - node-q

> Also check the LICENSE* file and update debian/copyright. See my changes
> in node-fastcgi.

Seems good for these packages.

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-05 Thread Xavier
Le 05/09/2018 à 22:45, Thorsten Alteholz a écrit :
> Hi everybody,
> 
> as you already know, there is a big number of node packages waiting in
> NEW. Does Debian really need all those packages?
> 
> node packages are rather small and often consist only of a few lines of
> code. From my point of view it is very unlikely that such packages will
> change over time, so their code will remain constant forever. More
> likely upstreams will add new features and pay no attention to backward
> compatible APIs.
> 
> In the node ecosystem everything is fine. Their developers use carets or
> tildes as dependency operators and just depened on the version of the
> API they really need.
> 
> In Debian such packages basically create two problems. They bloat the
> packages file, which prolongs the process of installing or updating
> packages. Further Debian only allows packages with one, the latest,
> version in the archive. So uploading packages with the newer API would
> make packages unusable, that still depend on the older API. Usually this
> is not recognized and suddenly packages in the archive won't work
> anymore. One could introduce versions within package names, but this
> would just multiply the number of node packages.
> 
> To answer my question from above: no, nobody needs these small packages.
> 
> But of course Debian wants to have packages with a certain
> functionality. Stuff like grunt, d3, babel and npm totally make sense to
> have.
> 
> So in order to reduce the number of node packages that appear in NEW and
> the archive one might lessen the Debian embedding policy.
> What do you think about embedding ...
>  - small modules that are not going to be changed and contain less than
>    50 lines of code (this limit is totally arbitrary)
>  - put together packages that belong together; I am not sure here, but
>    wouldn't it be fine to have just one package node-d3 or node-babel
>    that contains all corresponding modules (though their different versions
>    might create problems in keeping track of them)?
> In order to not lose track of the installed software, providing
> something like debian/modules.embedded might be nice to have?
> 
> As you know your tools best, can you please create a proposal of how you
> would like to handle maintenance in such a new situation?
> 
> Maybe we can already start by removing node-is-generator-fn,
> node-is-npm, node-is-unc-path and node-isstream and create a wiki page
> to keep track of all node modules that are candidates of being embedded?
> 
> Though I admit it might be a bit demotivating, we would like to REJECT
> all node packages currently in NEW and start as soon as possible with
> the new policy.
> 
>   Thorsten, on behalf of the ftpmasters

Hello,

you're right even if it may conflict a little with
https://wiki.debian.org/EmbeddedCodeCopies

We could also have a different policy for:
 - dependency of a end-user software
 - development libraries not yet used by any end-user software in main

In the first case, could follow normal process, and your proposition
could be applied for the second

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-05 Thread Xavier
Le 05/09/2018 à 22:58, Xavier a écrit :
> Le 05/09/2018 à 22:45, Thorsten Alteholz a écrit :
>> Hi everybody,
>>
>> as you already know, there is a big number of node packages waiting in
>> NEW. Does Debian really need all those packages?
>>
>> node packages are rather small and often consist only of a few lines of
>> code. From my point of view it is very unlikely that such packages will
>> change over time, so their code will remain constant forever. More
>> likely upstreams will add new features and pay no attention to backward
>> compatible APIs.
>>
>> In the node ecosystem everything is fine. Their developers use carets or
>> tildes as dependency operators and just depened on the version of the
>> API they really need.
>>
>> In Debian such packages basically create two problems. They bloat the
>> packages file, which prolongs the process of installing or updating
>> packages. Further Debian only allows packages with one, the latest,
>> version in the archive. So uploading packages with the newer API would
>> make packages unusable, that still depend on the older API. Usually this
>> is not recognized and suddenly packages in the archive won't work
>> anymore. One could introduce versions within package names, but this
>> would just multiply the number of node packages.
>>
>> To answer my question from above: no, nobody needs these small packages.
>>
>> But of course Debian wants to have packages with a certain
>> functionality. Stuff like grunt, d3, babel and npm totally make sense to
>> have.
>>
>> So in order to reduce the number of node packages that appear in NEW and
>> the archive one might lessen the Debian embedding policy.
>> What do you think about embedding ...
>>  - small modules that are not going to be changed and contain less than
>>    50 lines of code (this limit is totally arbitrary)
>>  - put together packages that belong together; I am not sure here, but
>>    wouldn't it be fine to have just one package node-d3 or node-babel
>>    that contains all corresponding modules (though their different versions
>>    might create problems in keeping track of them)?
>> In order to not lose track of the installed software, providing
>> something like debian/modules.embedded might be nice to have?
>>
>> As you know your tools best, can you please create a proposal of how you
>> would like to handle maintenance in such a new situation?
>>
>> Maybe we can already start by removing node-is-generator-fn,
>> node-is-npm, node-is-unc-path and node-isstream and create a wiki page
>> to keep track of all node modules that are candidates of being embedded?
>>
>> Though I admit it might be a bit demotivating, we would like to REJECT
>> all node packages currently in NEW and start as soon as possible with
>> the new policy.
>>
>>   Thorsten, on behalf of the ftpmasters
> 
> Hello,
> 
> you're right even if it may conflict a little with
> https://wiki.debian.org/EmbeddedCodeCopies
> 
> We could also have a different policy for:
>  - dependency of a end-user software
>  - development libraries not yet used by any end-user software in main
> 
> In the first case, could follow normal process, and your proposition
> could be applied for the second
> 
> Cheers,
> Xavier

- More secured for first case (no copy and more easy to follow CVE)
- Libraries in the 2nd case: perhaps insert in ITP issue the use level
  (NPM weekly downloads for example) and/or any other justification
  (important framework like vue.js,...)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-07 Thread Xavier
Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit :
> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz  wrote:
>>
>> Hi Bastien,
>>
>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote:
>>>>   - put together packages that belong together; I am not sure here, but
>>>> wouldn't it be fine to have just one package node-d3 or node-babel
>>>> that contains all corresponding modules (though their different 
>>>> versions
>>>> might create problems in keeping track of them)?
>>>
>>> I strongly oppose to keep different version.#
>>
>> I don't meant to have different versions of one package here, but
>> bundling several packages with different versions, so that it might not be
>> clear what version the resulting package might get.
> 
> I agree with this maybe we could get something like:
> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version
> ?
> 
> Bastien

Hello,

I've written a little draft:
https://wiki.debian.org/Javascript/GroupedSourcePackageProxy

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-08 Thread Xavier
Le 07/09/2018 à 16:36, Xavier a écrit :
> Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit :
>> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz  wrote:
>>>
>>> Hi Bastien,
>>>
>>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote:
>>>>>   - put together packages that belong together; I am not sure here, but
>>>>> wouldn't it be fine to have just one package node-d3 or node-babel
>>>>> that contains all corresponding modules (though their different 
>>>>> versions
>>>>> might create problems in keeping track of them)?
>>>>
>>>> I strongly oppose to keep different version.#
>>>
>>> I don't meant to have different versions of one package here, but
>>> bundling several packages with different versions, so that it might not be
>>> clear what version the resulting package might get.
>>
>> I agree with this maybe we could get something like:
>> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version
>> ?
>>
>> Bastien
> 
> Hello,
> 
> I've written a little draft:
> https://wiki.debian.org/Javascript/GroupedSourcePackageProxy

I've updated draft to build a stateless proxy: DB was a bad idea since
it can be modified at each request.
I started to build groupedsources.cgi. The function to build grouped
upstream sources works. Now I'm going to write the download part. When
ready, you will be able to test with node-tap, simply by changing
debian/watch.

If this proposition is acceptable, I'll propose a policy patch to
authorize JS grouped sources and a JS policy patch for details.

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node packages in NEW

2018-09-06 Thread Xavier
Le 06/09/2018 à 08:05, Pirate Praveen a écrit :
> On 06/09/18 10:15 AM, Pirate Praveen wrote:
>> I suggest we categorize the packages in NEW and process accordingly. I can 
>> help with categorizing it.
>>
>> I propose the following,
>>
>> 1. Simple modules that could be embedded - REJECT.
>> 2. Modules that includes a build step, for example that needs babel, webpack 
>> etc. (Modules that will produce a source is missing lintian error). I think 
>> those packages would be better in their own package as it will make 
>> embedding more complicated to maintain - ACCEPT
>> 3. A module that is a dependency or build dependency of more than 3 packages 
>> (arbitrary, could be 5 as well) - ACCEPT
>>
> 
> I have started this categorization here,
> 
> https://wiki.debian.org/Javascript/Nodejs/NEW

(reposted with my debian address)

Hello,

Thanks, I've updated this wiki page with my proposed packages:
 - 8 to reject/embed
 - 3 to keep
 - 2 to discuss

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-06 Thread Xavier
Le 05/09/2018 à 23:14, Bastien ROUCARIES a écrit :
> On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES
>  wrote:
>>
>> On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz  
>> wrote:
>>>
>>> Hi everybody,
>>>
>>> as you already know, there is a big number of node packages waiting in
>>> NEW. Does Debian really need all those packages?
>>>
>>> node packages are rather small and often consist only of a few lines of
>>> code. From my point of view it is very unlikely that such packages will
>>> change over time, so their code will remain constant forever. More likely
>>> upstreams will add new features and pay no attention to backward
>>> compatible APIs.
>>>
>>> In the node ecosystem everything is fine. Their developers use carets or
>>> tildes as dependency operators and just depened on the version of the API
>>> they really need.
>>>
>>> In Debian such packages basically create two problems. They bloat the
>>> packages file, which prolongs the process of installing or updating
>>> packages. Further Debian only allows packages with one, the latest,
>>> version in the archive. So uploading packages with the newer API would
>>> make packages unusable, that still depend on the older API. Usually this
>>> is not recognized and suddenly packages in the archive won't work anymore.
>>> One could introduce versions within package names, but this would just
>>> multiply the number of node packages.
>>>
>>> To answer my question from above: no, nobody needs these small packages.
>>>
>>> But of course Debian wants to have packages with a certain functionality.
>>> Stuff like grunt, d3, babel and npm totally make sense to have.
>>
>> They are at least what are waiting to be packaging:
>> - browserify
>> - a few package that are needed to regenerate web fonts.
>>>
>>> So in order to reduce the number of node packages that appear in NEW and
>>> the archive one might lessen the Debian embedding policy.
>>> What do you think about embedding ...
>>>   - small modules that are not going to be changed and contain less than
>>> 50 lines of code (this limit is totally arbitrary)
>>>   - put together packages that belong together; I am not sure here, but
>>> wouldn't it be fine to have just one package node-d3 or node-babel
>>> that contains all corresponding modules (though their different versions
>>> might create problems in keeping track of them)?
>>
>> I strongly oppose to keep different version.
>>> In order to not lose track of the installed software, providing something
>>> like debian/modules.embedded might be nice to have?
>>
>> i have proposed to do something with uscan in order to simplify the
>> work but I need help on it. The goal is to do something like
>> ,node-bind that embed node-has.
>>
>> The main problem is really updating and getting newer version automatically.
>>
>> With versioned provides we could even keep the best of the world (see
>> node-has or node-tap).
>>
>> Debhelper support will be nice but it is second order problem compared to 
>> uscan.
> 
> see #899073 for bugs

Hello,

instead of modifying uscan, we could perhaps build a "proxy" like
https://qa.debian.org/cgi-bin/fakeupstream.cgi which could populate
`node_modules/` directory. Example of such debian/watch:

version=3
opts="dversionmangle=s/\+embed\d*$//,repacksuffix=+embed" \
 
https://qa.debian.org/cgi-bin/embednpmjs.cgi?upstream=npmjs/package=npmjs/dependency1,npmjs/dependency2
 \
 .*=package-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))

This CGI could add node_modules/dependency1 and node_modules/dependency2
in upstream archive.
Note that something may be found to verify gpg signatures if any.

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-09 Thread Xavier
Le 09/09/2018 à 23:36, Bastien ROUCARIES a écrit :
> On Sat, Sep 8, 2018 at 6:17 PM Xavier  wrote:
>>
>> Le 07/09/2018 à 16:36, Xavier a écrit :
>>> Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit :
>>>> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz  
>>>> wrote:
>>>>>
>>>>> Hi Bastien,
>>>>>
>>>>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote:
>>>>>>>   - put together packages that belong together; I am not sure here, but
>>>>>>> wouldn't it be fine to have just one package node-d3 or node-babel
>>>>>>> that contains all corresponding modules (though their different 
>>>>>>> versions
>>>>>>> might create problems in keeping track of them)?
>>>>>>
>>>>>> I strongly oppose to keep different version.#
>>>>>
>>>>> I don't meant to have different versions of one package here, but
>>>>> bundling several packages with different versions, so that it might not be
>>>>> clear what version the resulting package might get.
>>>>
>>>> I agree with this maybe we could get something like:
>>>> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version
>>>> ?
>>>>
>>>> Bastien
>>>
>>> Hello,
>>>
>>> I've written a little draft:
>>> https://wiki.debian.org/Javascript/GroupedSourcePackageProxy
>>
>> I've updated draft to build a stateless proxy: DB was a bad idea since
>> it can be modified at each request.
>> I started to build groupedsources.cgi. The function to build grouped
>> upstream sources works. Now I'm going to write the download part. When
>> ready, you will be able to test with node-tap, simply by changing
>> debian/watch.
> 
> No I will not use as is. Actually node-tap use upstream tar ball
> renamed as per dpkg spec [1].
> 
> You solution use a repack...
> 
> 
> uscan support multiple tar (in V4) but only with one version. Your
> redirector could help by fixing the version problem.

OK, my redirector is ready. It provides all component with the same
version. Example of debian/watch:

# Main
https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or
\
  .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
# Component own-or
opts=component=own-or \
https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or=own-or;
\
  .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
...

Downloads are redirected to npmjs and not built by groupedsources.cgi

> A minor point about version, it should be + instead of ~. Embded
> version are after normal version. I think the best will be to use +~
> to separate embed version. It is unlikey someone will use +~ and it is
> a perfectly legal string.
> 
> so I will recommend as version
> mainversion+dsembded+~version1+~version2+~version3

OK, to simplify version, the second part is a cumulative version (sum of
digits of each component). Example: 1.2.3+~6.2.4
There is a "over" parameter in CGI to increase first digit (in case it
was decreased due to the removal of 1 component)

>> If this proposition is acceptable, I'll propose a policy patch to
>> authorize JS grouped sources and a JS policy patch for details.
> 
> [1] 
> https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/
> 
> 
>>
>> Cheers,
>> Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-10 Thread Xavier
Le 10/09/2018 à 07:59, Bastien ROUCARIES a écrit :
> On Mon, Sep 10, 2018 at 7:33 AM Xavier  wrote:
>>
>> Le 09/09/2018 à 23:36, Bastien ROUCARIES a écrit :
>>> On Sat, Sep 8, 2018 at 6:17 PM Xavier  wrote:
>>>>
>>>> Le 07/09/2018 à 16:36, Xavier a écrit :
>>>>> Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit :
>>>>>> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz  
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Bastien,
>>>>>>>
>>>>>>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote:
>>>>>>>>>   - put together packages that belong together; I am not sure here, 
>>>>>>>>> but
>>>>>>>>> wouldn't it be fine to have just one package node-d3 or node-babel
>>>>>>>>> that contains all corresponding modules (though their different 
>>>>>>>>> versions
>>>>>>>>> might create problems in keeping track of them)?
>>>>>>>>
>>>>>>>> I strongly oppose to keep different version.#
>>>>>>>
>>>>>>> I don't meant to have different versions of one package here, but
>>>>>>> bundling several packages with different versions, so that it might not 
>>>>>>> be
>>>>>>> clear what version the resulting package might get.
>>>>>>
>>>>>> I agree with this maybe we could get something like:
>>>>>> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version
>>>>>> ?
>>>>>>
>>>>>> Bastien
>>>>>
>>>>> Hello,
>>>>>
>>>>> I've written a little draft:
>>>>> https://wiki.debian.org/Javascript/GroupedSourcePackageProxy
>>>>
>>>> I've updated draft to build a stateless proxy: DB was a bad idea since
>>>> it can be modified at each request.
>>>> I started to build groupedsources.cgi. The function to build grouped
>>>> upstream sources works. Now I'm going to write the download part. When
>>>> ready, you will be able to test with node-tap, simply by changing
>>>> debian/watch.
>>>
>>> No I will not use as is. Actually node-tap use upstream tar ball
>>> renamed as per dpkg spec [1].
>>>
>>> You solution use a repack...
>>>
>>>
>>> uscan support multiple tar (in V4) but only with one version. Your
>>> redirector could help by fixing the version problem.
>>
>> OK, my redirector is ready. It provides all component with the same
>> version. Example of debian/watch:
>>
>> # Main
>> https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or
>> \
>>   .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
>> # Component own-or
>> opts=component=own-or \
>> https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or=own-or;
>> \
>>   .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
>> ...
>>
>> Downloads are redirected to npmjs and not built by groupedsources.cgi
>>
>>> A minor point about version, it should be + instead of ~. Embded
>>> version are after normal version. I think the best will be to use +~
>>> to separate embed version. It is unlikey someone will use +~ and it is
>>> a perfectly legal string.
>>>
>>> so I will recommend as version
>>> mainversion+dsembded+~version1+~version2+~version3
>>
>> OK, to simplify version, the second part is a cumulative version (sum of
>> digits of each component). Example: 1.2.3+~6.2.4
>> There is a "over" parameter in CGI to increase first digit (in case it
>> was decreased due to the removal of 1 component)
> I prefer the previous version of version string. Sorry no sum please. Be 
> stupid.
> 
>>>> If this proposition is acceptable, I'll propose a policy patch to
>>>> authorize JS grouped sources and a JS policy patch for details.
>>>
>>> [1] 
>>> https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/

OK, it works now. I've rebuild node-mongodb including its 2 dependencies
not yet available. If you want to test:
 * install groupedsources.cgi in your local /usr/lib/cgi-bin:
 https://salsa.debian.org/yadd/qa/blob/master/cgi-bin/groupedsources.cgi
 * clone https://salsa.debian.org/js-team/node-mongodb
 * `git checkout groupedsources`

This works:
 * `uscan -dd` installs the 3 sources
 * sbuild or `gbp buildpackage` installs the 3 node modules

Note:
 * since mongodb build doesn't need dependencies, they are not installed
   in node_modules directory during build. A simple mkdir+ln-s would be
   enough if this was needed
 * debian/copyright not yet updated (=> lintian warnings)
 * a suffix may be required here

Any advice or contribution are welcome!

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node packages in NEW

2018-09-10 Thread Xavier
Le 10/09/2018 à 17:09, Xavier a écrit :
> Le 10/09/2018 à 07:59, Bastien ROUCARIES a écrit :
>> On Mon, Sep 10, 2018 at 7:33 AM Xavier  wrote:
>>>
>>> Le 09/09/2018 à 23:36, Bastien ROUCARIES a écrit :
>>>> On Sat, Sep 8, 2018 at 6:17 PM Xavier  wrote:
>>>>>
>>>>> Le 07/09/2018 à 16:36, Xavier a écrit :
>>>>>> Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit :
>>>>>>> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz  
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Bastien,
>>>>>>>>
>>>>>>>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote:
>>>>>>>>>>   - put together packages that belong together; I am not sure here, 
>>>>>>>>>> but
>>>>>>>>>> wouldn't it be fine to have just one package node-d3 or 
>>>>>>>>>> node-babel
>>>>>>>>>> that contains all corresponding modules (though their different 
>>>>>>>>>> versions
>>>>>>>>>> might create problems in keeping track of them)?
>>>>>>>>>
>>>>>>>>> I strongly oppose to keep different version.#
>>>>>>>>
>>>>>>>> I don't meant to have different versions of one package here, but
>>>>>>>> bundling several packages with different versions, so that it might 
>>>>>>>> not be
>>>>>>>> clear what version the resulting package might get.
>>>>>>>
>>>>>>> I agree with this maybe we could get something like:
>>>>>>> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version
>>>>>>> ?
>>>>>>>
>>>>>>> Bastien
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I've written a little draft:
>>>>>> https://wiki.debian.org/Javascript/GroupedSourcePackageProxy
>>>>>
>>>>> I've updated draft to build a stateless proxy: DB was a bad idea since
>>>>> it can be modified at each request.
>>>>> I started to build groupedsources.cgi. The function to build grouped
>>>>> upstream sources works. Now I'm going to write the download part. When
>>>>> ready, you will be able to test with node-tap, simply by changing
>>>>> debian/watch.
>>>>
>>>> No I will not use as is. Actually node-tap use upstream tar ball
>>>> renamed as per dpkg spec [1].
>>>>
>>>> You solution use a repack...
>>>>
>>>>
>>>> uscan support multiple tar (in V4) but only with one version. Your
>>>> redirector could help by fixing the version problem.
>>>
>>> OK, my redirector is ready. It provides all component with the same
>>> version. Example of debian/watch:
>>>
>>> # Main
>>> https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or
>>> \
>>>   .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
>>> # Component own-or
>>> opts=component=own-or \
>>> https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or=own-or;
>>> \
>>>   .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
>>> ...
>>>
>>> Downloads are redirected to npmjs and not built by groupedsources.cgi
>>>
>>>> A minor point about version, it should be + instead of ~. Embded
>>>> version are after normal version. I think the best will be to use +~
>>>> to separate embed version. It is unlikey someone will use +~ and it is
>>>> a perfectly legal string.
>>>>
>>>> so I will recommend as version
>>>> mainversion+dsembded+~version1+~version2+~version3
>>>
>>> OK, to simplify version, the second part is a cumulative version (sum of
>>> digits of each component). Example: 1.2.3+~6.2.4
>>> There is a "over" parameter in CGI to increase first digit (in case it
>>> was decreased due to the removal of 1 component)
>> I prefer the previous version of version string. Sorry no sum please. Be 
>> stupid.
>>
>>>>> If this proposition is acceptable, I'll propose a policy patch to
>>>>> authorize JS grouped sources and a JS policy patch for details.
>>>>
>&

[Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-10 Thread Xavier
Dear fellow maintainers,

QA team accepted my changes, so now fakeupstream.cgi is able to handle
npmjs multiple sources. I've written a draft here:
https://wiki.debian.org/Javascript/GroupSourcesTutorial

Please review it.

Many thanks!
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-mongodb embedded modules

2018-09-11 Thread Xavier
Le 10/09/2018 à 23:34, Xavier a écrit :
> Dear fellow maintainers,
> 
> QA team accepted my changes, so now fakeupstream.cgi is able to handle
> npmjs multiple sources. I've written a draft here:
> https://wiki.debian.org/Javascript/GroupSourcesTutorial
> 
> Please review it.
> 
> Many thanks!
> Xavier

node-mongodb has been updated on Salsa: now all is in branch "master"
(branch groupedsources merged and deleted). Source contains now 3
embedded node modules (same author: MongoDB team):
 - require_optional
 - bson
 - mongodb-core

You can now test using either `sbuild` or `gbp buildpackage` or any
build tool. Following my tests, they all work but if someone could
validate this, I'll be very happy ;-)

autopkgtests are also updated.

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Packaging of node-lemonldap-ng-handler

2018-04-23 Thread Xavier
Hello,

I'm member of pkg-perl group
(https://udd.debian.org/dmd/?x.guimard%40free.fr#versions,
xguimard-guest on Salsa). I'd like to package node-lemonldap-ng-handler
which is a Node.js module that can be used in a lemonldap-ng system
(WebSSO written in Perl).
Some dependencies are needed (aes-js file-cache-simple inireader js-md5
node-dbi node-fastcgi).

Would you like to accept me in pkg-javascript team to do this or do you
prefer creating RFPs ?

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Packaging of node-lemonldap-ng-handler

2018-04-24 Thread Xavier
Hello,

I'm member of pkg-perl group
(https://udd.debian.org/dmd/?x.guimard%40free.fr#versions,
xguimard-guest on Salsa). I'd like to package node-lemonldap-ng-handler
which is a Node.js module that can be used in a lemonldap-ng system
(WebSSO written in Perl).
Some dependencies are needed (aes-js file-cache-simple inireader js-md5
node-dbi node-fastcgi).

Would you like to accept me in pkg-javascript team to do this or do you
prefer creating RFPs ?

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Packaging of node-lemonldap-ng-handler

2018-04-24 Thread Xavier
Done, thanks !

Le 24/04/2018 à 10:13, Jérémy Lal a écrit :
> Sure, you just have to "request access" from there:
> https://salsa.debian.org/js-team
> 
> Cheers,
> Jérémy
> 
> 
> 
> 2018-04-23 18:54 GMT+02:00 Xavier <xavier.guim...@polytechnique.org
> <mailto:xavier.guim...@polytechnique.org>>:
> 
> Hello,
> 
> I'm member of pkg-perl group
> (https://udd.debian.org/dmd/?x.guimard%40free.fr#versions
> <https://udd.debian.org/dmd/?x.guimard%40free.fr#versions>,
> xguimard-guest on Salsa). I'd like to package node-lemonldap-ng-handler
> which is a Node.js module that can be used in a lemonldap-ng system
> (WebSSO written in Perl).
> Some dependencies are needed (aes-js file-cache-simple inireader js-md5
> node-dbi node-fastcgi).
> 
> Would you like to accept me in pkg-javascript team to do this or do you
> prefer creating RFPs ?
> 
> Regards,
> Xavier
> 
> -- 
> Pkg-javascript-devel mailing list
> Pkg-javascript-devel@alioth-lists.debian.net
> <mailto:Pkg-javascript-devel@alioth-lists.debian.net>
> 
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
> 
> <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel>
> 
> 
> 
> 

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] acorn status

2018-10-22 Thread Xavier
Le 22/10/2018 à 13:52, Bastien ROUCARIES a écrit :
> Hi,
> 
> I have grouped some small package for acorn, see salsa
> 
> But i could not progress due to dynamic-import failling test
> 
> Do you have idea ?
> 
> Bastien

There is a bug with gbp. This works:
 - launch uscan
 - use gbp import-orig ../main-package.orig.tar.gz

gbp --uscan fails

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-10-22 Thread Xavier
Le 22/10/2018 à 12:52, Bastien ROUCARIES a écrit :
> On Mon, Oct 22, 2018 at 12:34 PM Xavier  wrote:
>>
>> Le 22/10/2018 à 11:23, Bastien ROUCARIES a écrit :
>>> I really need it for next ckeditor (40 small packages) and acorn.
>>>
>>> For uscan  I do not think the alpha sort is worthwhile. Let version be
>>> in watch file order.
>>
>> Do you speak on fakeuptream-like behavior ? If yes, I think a
>> 1.0.0+~23.4.65 version (sum) will be more efficient for 40 packages. It
>> guaranties that upstream updates will be detected
> 
> Sum is not bijective so your are not stateless. I plan to cut in 10
> packages each ckeditor.
> 
> BTW see that I have just pushed on salsa for acorn. We really need it.
> 
> Bastien

I checked a look at acorn. How uscan will build current version and
upstream version to be able to detect any change in any npmjs package ?

>>
>>> Bastien
>>> On Sat, Oct 20, 2018 at 5:18 PM Xavier  wrote:
>>>>
>>>> Le 20/10/2018 à 16:47, Bastien ROUCARIES a écrit :
>>>>> On Thu, Sep 27, 2018 at 3:29 PM Bastien ROUCARIES
>>>>>  wrote:
>>>>>>
>>>>>> On Mon, Sep 24, 2018 at 10:03 AM Xavier  wrote:
>>>>>>>
>>>>>>> Le 13/09/2018 à 11:16, Xavier a écrit :
>>>>>>>> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>>>>>>>>
>>>>>>>>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>>>>>>>>> Hi Xavier,
>>>>>>>>>>
>>>>>>>>>> The example in Provides section should be written
>>>>>>>>>> Provides: node-ta, node-tb
>>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> I think there should not be Provides as it implies sharing, which will
>>>>>>>>> negate the reason why we are embedding in the first place.
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial to
>>>>>>>> write a ~policy to choose to embed or not and to export or not. Please
>>>>>>>> review it
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Xavier
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I rewrote uscan and my work has been accepted by devscripts team (no
>>>>>>> behavior change for now but OO rewrite will help a lot). If you agree, I
>>>>>>> can add the same embedding system in uscan than I've done for
>>>>>>> fakeupstream.cgi
>>>>>>
>>>>>> Yes it will really help.
>>>>>
>>>>> Any news of uscan ?
>>>>
>>>> Hello,
>>>>
>>>> I rewrote uscan and fix some bugs. I can embed fakeupstream behavior in
>>>> uscan but it needs a consensus, here at least.
>>>>
>>>> --
>>>> Pkg-javascript-devel mailing list
>>>> Pkg-javascript-devel@alioth-lists.debian.net
>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>>>

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-10-22 Thread Xavier
Le 22/10/2018 à 11:23, Bastien ROUCARIES a écrit :
> I really need it for next ckeditor (40 small packages) and acorn.
> 
> For uscan  I do not think the alpha sort is worthwhile. Let version be
> in watch file order.

Do you speak on fakeuptream-like behavior ? If yes, I think a
1.0.0+~23.4.65 version (sum) will be more efficient for 40 packages. It
guaranties that upstream updates will be detected

> Bastien
> On Sat, Oct 20, 2018 at 5:18 PM Xavier  wrote:
>>
>> Le 20/10/2018 à 16:47, Bastien ROUCARIES a écrit :
>>> On Thu, Sep 27, 2018 at 3:29 PM Bastien ROUCARIES
>>>  wrote:
>>>>
>>>> On Mon, Sep 24, 2018 at 10:03 AM Xavier  wrote:
>>>>>
>>>>> Le 13/09/2018 à 11:16, Xavier a écrit :
>>>>>> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>>>>>>
>>>>>>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>>>>>>> Hi Xavier,
>>>>>>>>
>>>>>>>> The example in Provides section should be written
>>>>>>>> Provides: node-ta, node-tb
>>>>>>>> ?
>>>>>>>
>>>>>>> I think there should not be Provides as it implies sharing, which will
>>>>>>> negate the reason why we are embedding in the first place.
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial to
>>>>>> write a ~policy to choose to embed or not and to export or not. Please
>>>>>> review it
>>>>>>
>>>>>> Cheers,
>>>>>> Xavier
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I rewrote uscan and my work has been accepted by devscripts team (no
>>>>> behavior change for now but OO rewrite will help a lot). If you agree, I
>>>>> can add the same embedding system in uscan than I've done for
>>>>> fakeupstream.cgi
>>>>
>>>> Yes it will really help.
>>>
>>> Any news of uscan ?
>>
>> Hello,
>>
>> I rewrote uscan and fix some bugs. I can embed fakeupstream behavior in
>> uscan but it needs a consensus, here at least.
>>
>> --
>> Pkg-javascript-devel mailing list
>> Pkg-javascript-devel@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
> 

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] acorn status

2018-10-22 Thread Xavier
Le 22/10/2018 à 15:23, Bastien ROUCARIES a écrit :
> On Mon, Oct 22, 2018 at 1:55 PM Xavier  wrote:
>>
>> Le 22/10/2018 à 13:52, Bastien ROUCARIES a écrit :
>>> Hi,
>>>
>>> I have grouped some small package for acorn, see salsa
>>>
>>> But i could not progress due to dynamic-import failling test
>>>
>>> Do you have idea ?
>>>
>>> Bastien
>>
>> There is a bug with gbp. This works:
>>  - launch uscan
>>  - use gbp import-orig ../main-package.orig.tar.gz
>>
>> gbp --uscan fails
> 
> I use git dpm. It is eassier for patch

I fixed your debian/watch: there was 2 "debian". There is still a bug
somewhere...

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] acorn status

2018-10-22 Thread Xavier
Le 22/10/2018 à 21:21, Bastien ROUCARIES a écrit :
> Ok, thanks.

Last bug fixed, you missed a filenamemangle.

Now uscan downloads the 3 components + main package

> The main bug is why test fail
> On Mon, Oct 22, 2018 at 9:08 PM Xavier  wrote:
>>
>> Le 22/10/2018 à 15:23, Bastien ROUCARIES a écrit :
>>> On Mon, Oct 22, 2018 at 1:55 PM Xavier  wrote:
>>>>
>>>> Le 22/10/2018 à 13:52, Bastien ROUCARIES a écrit :
>>>>> Hi,
>>>>>
>>>>> I have grouped some small package for acorn, see salsa
>>>>>
>>>>> But i could not progress due to dynamic-import failling test
>>>>>
>>>>> Do you have idea ?
>>>>>
>>>>> Bastien
>>>>
>>>> There is a bug with gbp. This works:
>>>>  - launch uscan
>>>>  - use gbp import-orig ../main-package.orig.tar.gz
>>>>
>>>> gbp --uscan fails
>>>
>>> I use git dpm. It is eassier for patch
>>
>> I fixed your debian/watch: there was 2 "debian". There is still a bug
>> somewhere...

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-10-20 Thread Xavier
Le 20/10/2018 à 16:47, Bastien ROUCARIES a écrit :
> On Thu, Sep 27, 2018 at 3:29 PM Bastien ROUCARIES
>  wrote:
>>
>> On Mon, Sep 24, 2018 at 10:03 AM Xavier  wrote:
>>>
>>> Le 13/09/2018 à 11:16, Xavier a écrit :
>>>> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>>>>
>>>>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>>>>> Hi Xavier,
>>>>>>
>>>>>> The example in Provides section should be written
>>>>>> Provides: node-ta, node-tb
>>>>>> ?
>>>>>
>>>>> I think there should not be Provides as it implies sharing, which will
>>>>> negate the reason why we are embedding in the first place.
>>>>
>>>> Hello,
>>>>
>>>> I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial to
>>>> write a ~policy to choose to embed or not and to export or not. Please
>>>> review it
>>>>
>>>> Cheers,
>>>> Xavier
>>>
>>> Hi all,
>>>
>>> I rewrote uscan and my work has been accepted by devscripts team (no
>>> behavior change for now but OO rewrite will help a lot). If you agree, I
>>> can add the same embedding system in uscan than I've done for
>>> fakeupstream.cgi
>>
>> Yes it will really help.
> 
> Any news of uscan ?

Hello,

I rewrote uscan and fix some bugs. I can embed fakeupstream behavior in
uscan but it needs a consensus, here at least.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-10-20 Thread Xavier
Le 20/10/2018 à 16:47, Bastien ROUCARIES a écrit :
> On Thu, Sep 27, 2018 at 3:29 PM Bastien ROUCARIES
>  wrote:
>>
>> On Mon, Sep 24, 2018 at 10:03 AM Xavier  wrote:
>>>
>>> Le 13/09/2018 à 11:16, Xavier a écrit :
>>>> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>>>>
>>>>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>>>>> Hi Xavier,
>>>>>>
>>>>>> The example in Provides section should be written
>>>>>> Provides: node-ta, node-tb
>>>>>> ?
>>>>>
>>>>> I think there should not be Provides as it implies sharing, which will
>>>>> negate the reason why we are embedding in the first place.
>>>>
>>>> Hello,
>>>>
>>>> I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial to
>>>> write a ~policy to choose to embed or not and to export or not. Please
>>>> review it
>>>>
>>>> Cheers,
>>>> Xavier
>>>
>>> Hi all,
>>>
>>> I rewrote uscan and my work has been accepted by devscripts team (no
>>> behavior change for now but OO rewrite will help a lot). If you agree, I
>>> can add the same embedding system in uscan than I've done for
>>> fakeupstream.cgi
>>
>> Yes it will really help.
> 
> Any news of uscan ?

Hello,

I rewrote uscan and fix some bugs. I can embed fakeupstream behavior in
uscan but it needs a consensus, here at least.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFC: javascript bundle of small packages

2018-10-30 Thread Xavier
Le 30/10/2018 à 10:51, Bastien ROUCARIES a écrit :
> Hi,
> 
> I have just pushed a new version of acorn and associated small package
> to salsa (https://salsa.debian.org/js-team/acorn)
> 
> It group small package using dpkg module and for now fakeupstream redirector.
> 
> We plan to modify uscan (yadd?) in order to get this feature upstream.
> 
> We also plan to improve debhelper in order to get the version parsing
> of control automatic, and to ease build.
> 
> But we believe it is a first step in the good direction.
> 
> Dear ftpmaster could you review before I upload to experimental,
> particularly breaks/replace line.
> 
> Package that bundle a few package will be called node-debbundle-foo. I
> plan to update policy
> 
> Bastien

Cc: devscri...@packages.debian.org

It's now ~easy to modify uscan to do this. We must fix some policy points:
 - a grouped package version is the join of component versions separate
   by "+~"

If this way suits you, debian/watch file will look like this:

version=4

# Main component
http://website /regexp/ group
# optional pgp check
opts=pgpmode=previous,.. \
 http://website /regexpSig/

# 2nd component
opts=component=node-foo \
 http://website2 /regexp/ group
# optional pgp check
opts=pgpmode=previous,.. \
 http://website /regexpSig/

# and so on

"group" replaces "debian"+"same". uscan calculates new version looking
at all "group" lines

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFC: javascript bundle of small packages

2018-10-30 Thread Xavier
Le 30/10/2018 à 11:14, Xavier a écrit :
> Le 30/10/2018 à 10:51, Bastien ROUCARIES a écrit :
>> Hi,
>>
>> I have just pushed a new version of acorn and associated small package
>> to salsa (https://salsa.debian.org/js-team/acorn)
>>
>> It group small package using dpkg module and for now fakeupstream redirector.
>>
>> We plan to modify uscan (yadd?) in order to get this feature upstream.
>>
>> We also plan to improve debhelper in order to get the version parsing
>> of control automatic, and to ease build.
>>
>> But we believe it is a first step in the good direction.
>>
>> Dear ftpmaster could you review before I upload to experimental,
>> particularly breaks/replace line.
>>
>> Package that bundle a few package will be called node-debbundle-foo. I
>> plan to update policy
>>
>> Bastien
> 
> Cc: devscri...@packages.debian.org
> 
> It's now ~easy to modify uscan to do this. We must fix some policy points:
>  - a grouped package version is the join of component versions separate
>by "+~"
> 
> If this way suits you, debian/watch file will look like this:
> 
> version=4
> 
> # Main component
> http://website /regexp/ group
> # optional pgp check
> opts=pgpmode=previous,.. \
>  http://website /regexpSig/
> 
> # 2nd component
> opts=component=node-foo \
>  http://website2 /regexp/ group
> # optional pgp check
> opts=pgpmode=previous,.. \
>  http://website /regexpSig/
> 
> # and so on
> 
> "group" replaces "debian"+"same". uscan calculates new version looking
> at all "group" lines

I wrote this feature (doc to do). Works fine:

 * Modified uscan:
   https://salsa.debian.org/yadd/devscripts/commits/uscan-899073
 * Test with node-mongodb:
   https://salsa.debian.org/js-team/node-mongodb/tree/test-uscan

node-mongodb debian/watch:
version=4

opts="searchmode=plain,pgpmode=none" \
 https://registry.npmjs.org/mongodb
https://registry.npmjs.org/mongodb/-/mongodb-(\d[\d\.]*)@ARCHIVE_EXT@ group

opts="searchmode=plain,pgpmode=none,component=bson" \
 https://registry.npmjs.org/bson
https://registry.npmjs.org/bson/-/bson-(\d[\d\.]*)@ARCHIVE_EXT@ group

opts="searchmode=plain,pgpmode=none,component=mongodb-core" \
 https://registry.npmjs.org/mongodb-core
https://registry.npmjs.org/mongodb-core/-/mongodb-core-(\d[\d\.]*)@ARCHIVE_EXT@
group

opts="searchmode=plain,pgpmode=none,component=requireoptional" \
 https://registry.npmjs.org/require_optional
https://registry.npmjs.org/require_optional/-/require_optional-(\d[\d\.]*)@ARCHIVE_EXT@
group

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-24 Thread Xavier
Le 13/09/2018 à 11:16, Xavier a écrit :
> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>
>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>> Hi Xavier,
>>>
>>> The example in Provides section should be written
>>> Provides: node-ta, node-tb
>>> ?
>>
>> I think there should not be Provides as it implies sharing, which will
>> negate the reason why we are embedding in the first place.
> 
> Hello,
> 
> I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial to
> write a ~policy to choose to embed or not and to export or not. Please
> review it
> 
> Cheers,
> Xavier

Hi all,

I rewrote uscan and my work has been accepted by devscripts team (no
behavior change for now but OO rewrite will help a lot). If you agree, I
can add the same embedding system in uscan than I've done for
fakeupstream.cgi

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Update policy for Buster

2018-12-30 Thread Xavier
Hi all,

while buster freeze comes,
https://udd.debian.org/dmd/?pkg-javascript-devel%40lists.alioth.debian.org
shows that:
 - more than 60 RC bugs have to be fixed
 - the majority of our packages are outdated or obsolete

I think we should - at least until buster freeze - have a "salvage" policy.
Some ways:
 - declare JS team as "Low Threshold Nmu" [1]
 - organize some online hacking parties to release "team uploads"
   regardless uploader name

Cheers,
Xavier

[1] https://wiki.debian.org/LowThresholdNmu

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#917750: node-redis: FTBFS: tests failed

2018-12-30 Thread Xavier
Hello,

node-redis seems also out-of-date. Would you accept co-maintenance on
this package ?

Cheers,
Xavier

Le 29/12/2018 à 23:40, Lucas Nussbaum a écrit :
> Source: node-redis
> Version: 0.12.1-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: buster sid
> Usertags: ftbfs-20181229 ftbfs-buster
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
>> make[1]: Entering directory '/<>'
>> NODE_DISABLE_COLORS=1 nodejs test.js
>> [redis-server] 31493:C 29 Dec 2018 13:29:06.704 # oO0OoO0OoO0Oo Redis is 
>> starting oO0OoO0OoO0Oo
>> 31493:C 29 Dec 2018 13:29:06.704 # Redis version=5.0.3, bits=64, 
>> commit=, modified=0, pid=31493, just started
>> 31493:C 29 Dec 2018 13:29:06.704 # Configuration loaded
>> 31493:M 29 Dec 2018 13:29:06.705 * Running mode=standalone, port=6379.
>> 31493:M 29 Dec 2018 13:29:06.705 # WARNING: The TCP backlog setting of 511 
>> cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower 
>> value of 128.
>> 31493:M 29 Dec 2018 13:29:06.705 # Server initialized
>> 31493:M 29 Dec 2018 13:29:06.705 # WARNING overcommit_memory is set to 0! 
>> Background save may fail under low memory condition. To fix this issue add 
>> 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the 
>> command 'sysctl vm.overcommit_memory=1' for this to take effect.
>> 31493:M 29 Dec 2018 13:29:06.705 # WARNING you have Transparent Huge Pages 
>> (THP) support enabled in your kernel. This will create latency and memory 
>> usage issues with Redis. To fix this issue run the command 'echo never > 
>> /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your 
>> /etc/rc.local in order to retain the setting after a reboot. Redis must be 
>> restarted after THP is disabled.
>> 31493:M 29 Dec 2018 13:29:06.705 * Ready to accept connections
>> 31493:M 29 Dec 2018 13:29:06.705 * The server is now ready to accept 
>> connections at /tmp/redis.sock
>>
>> Connected to 127.0.0.1:6379, Redis server version 5.0.3
>>
>> Using reply parser javascript
>> - ipv4:(node:31487) [DEP0026] DeprecationWarning: util.print is deprecated. 
>> Use console.log instead.
>> Connected to 127.0.0.1:6379, Redis server version 5.0.3
>>
>> Using reply parser javascript
>> - ipv6:Connected to ::1:6379, Redis server version 5.0.3
>>
>> Using reply parser javascript
>> - unix_socket:Connected to /tmp/redis.sock, Redis server version 5.0.3
>>
>> Using reply parser javascript
>> - flushdb: 1 ms
>> - incr: 0 ms
>> - multi_1: 2 ms
>> - multi_2: 0 ms
>> - multi_3: 1 ms
>> - multi_4: 0 ms
>> - multi_5: 1 ms
>> - multi_6: 0 ms
>> - multi_7: 1 ms
>> - multi_exception_1: 1 ms
>> - multi_8: 1 ms
>> - fwd_errors_1:incoming
>>  151 ms
>> - eval_1: 5 ms
>> - script_load: 0 ms
>> - client_list:id=3 addr=127.0.0.1:56828 fd=9 name= age=0 idle=0 flags=N 
>> db=15 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 
>> events=r cmd=exec
>> id=4 addr=127.0.0.1:56830 fd=10 name= age=0 idle=0 flags=N db=15 sub=0 
>> psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=select
>> id=5 addr=127.0.0.1:56832 fd=11 name= age=0 idle=0 flags=P db=15 sub=1 
>> psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=subscribe
>> id=6 addr=127.0.0.1:56834 fd=12 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 
>> multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client
>>
>> id=3 addr=127.0.0.1:56828 fd=9 name= age=0 idle=0 flags=x db=15 sub=0 psub=0 
>> multi=1 qbuf=14 qbuf-free=32754 obl=4 oll=0 omem=0 events=r cmd=exec
>> id=4 addr=127.0.0.1:56830 fd=10 name= age=0 idle=0 flags=N db=15 sub=0 
>> psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=select
>> id=5 addr=127.0.0.1:56832 fd=11 name= age=0 idle=0 flags=P db=15 sub=1 
>> psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=subscribe
>> id=6 addr=127.0.0.1:56834 fd=12 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 
>> multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
>>
>> id=3 addr=127.0.0.1:56828 fd=9 name= age=0 idle=0 flags=x db=15 sub=0 psub=0 
>> multi=1 qbuf=55 qbuf-free=32713 obl=18 oll=0 omem=0 events=r cmd=exec
>> id=4 addr=127.0.0.1:56830 fd=10 name= age=0 idle=0 flags=N db=15 sub=0 
>> psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=select
>> id=5 addr=127.0.0.1:56832 fd=11 name= age=0 idle=0 flags=P db=15 sub=1 
>> psub=0 multi=-1 qb

Re: [Pkg-javascript-devel] RFS: node-markdown-it-html5-embed

2019-01-16 Thread Xavier
Le 16/01/2019 à 12:28, Utkarsh Gupta a écrit :
> ...
> Done. Little question, are you sure this module is useful ? It provides
> a plugin for markdown-it which isn't available in unstable.
> That's the reason why I added a minimal test and not the real one
> (mocha).
> 
> 
> Thank you so much! :D
> I updated and pushed the rest of the changes you suggested.
> Could you please review the same?
> 
> The module was included by Praveen (prav...@debian.org
> <mailto:prav...@debian.org>), so I am sure he must have something in mind.
> I just fixed the error due to which the package was rejected.
> 
> So if it is fine by you, could you review the changes and upload the same?
> 
> 
> Best,
> Utkarsh

I fixed this package. However, it hasn't been pushed to new and I don't
think it is useful to push it since node-markdown-it doesn't exist for
now (even if ruby-team pushed a libjs-markdown-it package [source:
ruby-rails-assets-markdown-it] but without node files).

Cheers,
Xavier

@Utkarsh: take a look at my changes

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#918627: node-cacache FTBFS with nodejs 10.15.0

2019-01-16 Thread Xavier
Update to 11.3.2 fixes partially failing build. Last problem is in
node-readable-stream

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#918670: node-duplexer3: incompatible with Node >=10 stream

2019-01-18 Thread Xavier
Control: reopen -1
Control: severity -1 important
Control: tags -1 - ftbfs
Control: retitle -1 node-duplexer3: incompatible with Node >=10 stream

Even using `npm install` files, the failing test shows that duplexer3
isn't compatible with Node.js stream.

Tagged as "important" instead of "serious" because:
 - workaround exists in test since 0.1.4-3 (increased in 0.1.4-4) and so
   both debci and autopkgtest are OK
 - bug exists only if application tries to write in a closed stream

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: RainLoop Webmail and dependencies

2019-01-19 Thread Xavier
Le 19/01/2019 à 13:51, Xavier a écrit :
> Le 19/01/2019 à 13:34, Xavier a écrit :
>> Le 19/01/2019 à 11:34, Daniel Ring a écrit :
>>> Hello Debian JS Maintainers,
>>>
>>> I've updated Rainloop and all of its dependencies to the latest versions
>>> that don't require new packages. All of them should be ready for
>>> uploading, but let me know if you spot any issues.
>>>
>>> Please take a look and sponsor uploads when you have the time. The only
>>> constraint is that rainloop should be uploaded last, as it bundles the
>>> currently-installed versions of some of its dependencies during build.
>>>
>>> The full list of packages:
>>> - libjs-jquery-backstretch
>>
>> TODO added in debian/changelog
>>
>>> - node-autolinker
> 
> Take a look at my changes, remove also dist/Autolinker.min.js here and
> generate it
> 
>>> - node-babel-loader
>>> - node-babel-plugin-transform-decorators-legacy
>>> - node-js-cookie
>>> - node-knockout
>>> - node-knockout-sortable
>>> - node-knockout-transformations
>>> - node-lightgallery
>>> - node-normalize.css
>>> - node-opentip
>>> - node-pikaday
>>> - node-raw-loader
>>> - node-style-loader
>>> - rainloop
>>>
>>> The current state of these packages can be viewed on my QA page [1];
>>> some of the packages were updated to declare "Multi-Arch: foreign" but
>>> don't have a new upstream version, so please check the version in the
>>> VCS column.
>>>
>>> [1]: https://qa.debian.org/developer.php?email=dr...@wolfishly.me
>>>
>>> Sincerely,
>>> Daniel Ring

Please update all your debian/copyright files: lintian reports:
insecure-copyright-format-uri
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

You can use "cme check dpkg-copyright" or directly "cme fix dpkg-copyright"

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: RainLoop Webmail and dependencies

2019-01-19 Thread Xavier
Le 19/01/2019 à 14:18, Xavier a écrit :
> Le 19/01/2019 à 13:51, Xavier a écrit :
>> Le 19/01/2019 à 13:34, Xavier a écrit :
>>> Le 19/01/2019 à 11:34, Daniel Ring a écrit :
>>>> Hello Debian JS Maintainers,
>>>>
>>>> I've updated Rainloop and all of its dependencies to the latest versions
>>>> that don't require new packages. All of them should be ready for
>>>> uploading, but let me know if you spot any issues.
>>>>
>>>> Please take a look and sponsor uploads when you have the time. The only
>>>> constraint is that rainloop should be uploaded last, as it bundles the
>>>> currently-installed versions of some of its dependencies during build.
>>>>
>>>> The full list of packages:
>>>> - libjs-jquery-backstretch
>>>
>>> TODO added in debian/changelog
>>>
>>>> - node-autolinker
>>
>> Take a look at my changes, remove also dist/Autolinker.min.js here and
>> generate it
>>
>>>> - node-babel-loader
>>>> - node-babel-plugin-transform-decorators-legacy
>>>> - node-js-cookie
>>>> - node-knockout
>>>> - node-knockout-sortable
>>>> - node-knockout-transformations
>>>> - node-lightgallery
>>>> - node-normalize.css
>>>> - node-opentip
>>>> - node-pikaday
>>>> - node-raw-loader
>>>> - node-style-loader
>>>> - rainloop
>>>>
>>>> The current state of these packages can be viewed on my QA page [1];
>>>> some of the packages were updated to declare "Multi-Arch: foreign" but
>>>> don't have a new upstream version, so please check the version in the
>>>> VCS column.
>>>>
>>>> [1]: https://qa.debian.org/developer.php?email=dr...@wolfishly.me
>>>>
>>>> Sincerely,
>>>> Daniel Ring
> 
> Please update all your debian/copyright files: lintian reports:
> insecure-copyright-format-uri
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> You can use "cme check dpkg-copyright" or directly "cme fix dpkg-copyright"

I pushed node-js-cookie, take a look at my changes and do the same for
other packages. Tools to use:
 - cme
 - duck

Thanks for your work !

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#751605: node-amdefine: Embedded copy of "RequireJS text"

2019-01-15 Thread Xavier
Control: severity -1 minor

Decrease severity since tests are not launched for now (missing
dependencies).

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-markdown-it-html5-embed

2019-01-15 Thread Xavier
Le 15/01/2019 à 22:06, Utkarsh Gupta a écrit :
> 
> 
> On Wed, Jan 16, 2019 at 2:34 AM Utkarsh Gupta
> mailto:guptautkarsh2...@gmail.com>> wrote:
> 
> Hi,
> 
> The package node-markdown-it-html5-embed_1.0.0+ds-1_amd64.changes
> was rejected because of the issues in the license block.
> And the rejection mail can be found here:
> 
> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030605.htm
> 
>  
> Correction:
> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030605.html
> 
> 
> However, I updated the same and the changes would be visible at the
> salsa repo which may be found at
> https://salsa.debian.org/js-team/node-markdown-it-html5-embed/
> 
> Requesting you to please upload the same.
> 
> 
> Best,
> Utkarsh

Hello,

TODO added in debian/changelog

Thanks !

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-markdown-it-html5-embed

2019-01-15 Thread Xavier
Le 15/01/2019 à 23:57, Utkarsh Gupta a écrit :
> On Wed, Jan 16, 2019 at 3:37 AM Xavier  <mailto:x.guim...@free.fr>> wrote:
> 
> Le 15/01/2019 à 22:06, Utkarsh Gupta a écrit :
> >
> >
> > On Wed, Jan 16, 2019 at 2:34 AM Utkarsh Gupta
> > mailto:guptautkarsh2...@gmail.com>
> <mailto:guptautkarsh2...@gmail.com
> <mailto:guptautkarsh2...@gmail.com>>> wrote:
> >
> >     Hi,
> >
> >     The package node-markdown-it-html5-embed_1.0.0+ds-1_amd64.changes
> >     was rejected because of the issues in the license block.
> >     And the rejection mail can be found here:
> >   
>  
> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030605.htm
> >
> >  
> > Correction:
> >
> 
> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030605.html
> >
> >     However, I updated the same and the changes would be visible
> at the
> >     salsa repo which may be found at
> >     https://salsa.debian.org/js-team/node-markdown-it-html5-embed/
> >
> >     Requesting you to please upload the same.
> >
> >     Best,
> >     Utkarsh
> 
> Hello,
> 
> TODO added in debian/changelog
> 
> 
> Ah, thank you so much!
> However, I am facing a little difficulty in adding a test in debian/rules.
> I am able to set the other things right, except that.
> When I add a minimal test, the build fails and on removal, it builds
> successfully.
> Could you please help me a little here, too?
> 
> Thanks !

Done. Little question, are you sure this module is useful ? It provides
a plugin for markdown-it which isn't available in unstable.
That's the reason why I added a minimal test and not the real one (mocha).

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-lemonldap-ng-handler_0.3.0-1_amd64.changes REJECTED

2019-01-21 Thread Xavier
Hello,

yes reject it for now, I'll packaged it after buster release.

Cheers,
Xavier

Le 21/01/2019 à 17:00, Thorsten Alteholz a écrit :
> 
> Hi Xavier,
> 
> some dependencies of this module are mentioned on the list of to be embedded 
> modules.
> 
>  Thorsten
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#895316: Fixed ?

2019-01-22 Thread Xavier
Control: severity -1 important

According to debci reports, this FTBFS seems fixed. I'm going to upload
a new version since license is wrong (upstream has changed to ISC, not
reported in debian/changelog)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#897156: node-cache-base: FTBFS and Debci failure with node-is-extendable 1.0.1-1

2019-01-22 Thread Xavier
An update of node-union-value fixes the problem. Let's do it

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#918404: node-temporary FTBFS with nodejs 10.15.0

2019-01-23 Thread Xavier
node-temporary seems orphaned upstream, looking at apt-cache depends, it
seems that no package needs it, so I think it can be safely removed from
testing.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Fwd: [vesln/temporary] Tests fail (#28)

2019-01-23 Thread Xavier
node-temporary in memoriam...

Anyway, keeping this package in buster seems not a security problem:
very simple wrapper around node.fs()

 Message transféré 
Subject :   Re: [vesln/temporary] Tests fail (#28)
Date :  Wed, 23 Jan 2019 08:57:32 -0800
From :  Will 
To :vesln/temporary 

If you create this as a pull request, we can merge it in on GitHub,
however only @vesln  , who has disappeared for
some years, is able to update the published package on NPM. As such,
it's probably best to think of this official repository as deprecated.

https://github.com/vesln/temporary/issues/28#issuecomment-456881403



-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Proposed fix

2019-01-23 Thread Xavier
Hi all,

to fix missing popper.js, I propose to embed it for now in
twitter-bootstrap4 (done in salsa repo but not pushed). After buster
release, we could split it in a separate package.

Please review this.

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#920188: Proposed fix

2019-01-23 Thread Xavier
Le 23/01/2019 à 21:55, Xavier a écrit :
> Hi all,
> 
> to fix missing popper.js, I propose to embed it for now in
> twitter-bootstrap4 (done in salsa repo but not pushed). After buster
> release, we could split it in a separate package.
> 
> Please review this.

Reverted.


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-markdown-it-html5-embed

2019-01-16 Thread Xavier
Le 16/01/2019 à 06:54, Xavier a écrit :
> Le 15/01/2019 à 23:57, Utkarsh Gupta a écrit :
>> On Wed, Jan 16, 2019 at 3:37 AM Xavier > <mailto:x.guim...@free.fr>> wrote:
>>
>> Le 15/01/2019 à 22:06, Utkarsh Gupta a écrit :
>> >
>> >
>> > On Wed, Jan 16, 2019 at 2:34 AM Utkarsh Gupta
>> > mailto:guptautkarsh2...@gmail.com>
>> <mailto:guptautkarsh2...@gmail.com
>> <mailto:guptautkarsh2...@gmail.com>>> wrote:
>> >
>> >     Hi,
>> >
>> >     The package node-markdown-it-html5-embed_1.0.0+ds-1_amd64.changes
>> >     was rejected because of the issues in the license block.
>> >     And the rejection mail can be found here:
>> >   
>>  
>> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030605.htm
>> >
>> >  
>> > Correction:
>> >
>> 
>> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-January/030605.html
>> >
>> >     However, I updated the same and the changes would be visible
>> at the
>> >     salsa repo which may be found at
>> >     https://salsa.debian.org/js-team/node-markdown-it-html5-embed/
>> >
>> >     Requesting you to please upload the same.
>> >
>> >     Best,
>> >     Utkarsh
>>
>> Hello,
>>
>> TODO added in debian/changelog
>>
>>
>> Ah, thank you so much!
>> However, I am facing a little difficulty in adding a test in debian/rules.
>> I am able to set the other things right, except that.
>> When I add a minimal test, the build fails and on removal, it builds
>> successfully.
>> Could you please help me a little here, too?
>>
>> Thanks !
> 
> Done. Little question, are you sure this module is useful ? It provides
> a plugin for markdown-it which isn't available in unstable.
> That's the reason why I added a minimal test and not the real one (mocha).

I can modify this package to include markdown-it and rebuild it using
components.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: RainLoop Webmail and dependencies

2019-01-22 Thread Xavier
Hello,

wait new unstable index, bug is fixed

Le 22/01/2019 à 16:14, Christoph Berg a écrit :
> Re: Daniel Ring 2019-01-19 <71c60884-6b98-e568-02c3-abddcf200...@wolfishly.me>
>> I've updated Rainloop and all of its dependencies to the latest versions
>> that don't require new packages. All of them should be ready for uploading,
>> but let me know if you spot any issues.
> 
> In git, there's UNRELEASED changes in some packages. I'm manually
> selecting older revisions which seem to be what you had in mind.
> 
>> The full list of packages:
>> - libjs-jquery-backstretch
> 
> I tried building a211b082d0bacaa7ddaa8e9bc2c252d83445bc69, but the
> B-Ds are not installable:
> 
> Unpacking node-get-value (3.0.1+~3.0.1-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-F6WG6i/026-node-get-value_3.0.1+~3.0.1-1_all.deb 
> (--unpack):
>  trying to overwrite '/usr/lib/nodejs/isobject/index.js', which is also in 
> package node-isobject 3.0.1-1
> 
> Filed as #920190.
> 
>> - node-autolinker
> 
> 5ac11ebcc3f9d68de20181cd72f5f101a2cc8726 uploaded
> 
>> - node-babel-loader
> 
> Uploaded.
> 
>> - node-babel-plugin-transform-decorators-legacy
> 
> Uploaded.
> 
>> - node-js-cookie
> 
> Bad B-D as above.
> 
>> - node-knockout
> 
> Uploaded.
> 
>> - node-knockout-sortable
> 
> Uploaded.
> 
>> - node-knockout-transformations
> 
> Uploaded.
> 
>> - node-lightgallery
> 
> Uploaded.
> 
>> - node-normalize.css
> 
> Uploaded.
> 
>> - node-opentip
> 
> Uploaded.
> 
>> - node-pikaday
> 
> Uploaded.
> 
>> - node-raw-loader
> 
> Uploaded.
> 
>> - node-style-loader
> 
> Uploaded.
> 
>> - rainloop
> 
> TBD.
> 
> Christoph
> 

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#918404: Bug#918404: node-temporary FTBFS with nodejs 10.15.0

2019-01-23 Thread Xavier
Le 23/01/2019 à 09:33, Xavier a écrit :
> node-temporary seems orphaned upstream, looking at apt-cache depends, it
> seems that no package needs it, so I think it can be safely removed from
> testing.

However I fixed this package.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Plan for bootstrap 4

2018-12-01 Thread Xavier
Le 21/09/2018 à 10:16, Pirate Praveen a écrit :
> Hi David,
> 
> I need bootstrap 4 for gitlab (though only its node counterpart). I'm
> thinking of creating a new source package node-bootstrap (if required
> create libjs-bootstrap4 binary). What is your plan with bootstrap 4?
> 
> Thanks
> Praveen

Hi all,

did someone package it ?

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Plan for bootstrap 4

2018-12-01 Thread Xavier
Le 01/12/2018 à 12:14, Jonas Smedegaard a écrit :
> Quoting Xavier (2018-12-01 09:24:54)
>> Le 21/09/2018 à 10:16, Pirate Praveen a écrit :
>>> I need bootstrap 4 for gitlab (though only its node counterpart). 
>>> I'm thinking of creating a new source package node-bootstrap (if 
>>> required create libjs-bootstrap4 binary). What is your plan with 
>>> bootstrap 4?
> [...]
>> did someone package it ?
> 
> Please use the Debian bugtracker for such packaging coordination: 
> https://www.debian.org/devel/wnpp/#l1
> 
> Concretely, https://www.debian.org/devel/wnpp/prospective lists 
> bootstrap4 as an RFP, so answer to your question is "No".
> 
>  - Jonas

Thanks,

~90 packages depends on libjs-bootstrap while ~168 packages embeds a
copy of bootstrap.js.

RFP still exists: https://bugs.debian.org/842828 (I forgot to Cc, done now)

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 15:24, Jérémy Lal a écrit :
> 
> 
> Le mar. 27 nov. 2018 à 15:22, Xavier  <mailto:y...@debian.org>> a écrit :
> 
> Le 27/11/2018 à 15:03, Jonas Smedegaard a écrit :
> > Quoting Xavier (2018-11-27 14:00:42)
> >> Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
> >>> Hi Xavier and Paolo,
> >>>
> >>> Please allow me to highlight this security-related detail:
> >>>
> >>> Quoting Xavier (2018-11-26 16:29:32)
> >>>> Embedding components without following them may be a lack of
> security.
> >>>> I think we should have a policy for embedding:
> >>>>  - components without major risks   => not used in version
> >>>>  - components that must be followed => declared as "group" in
> >>>>    debian/watch
> >>>>  - components that must be followed and used in many other packages
> >>>>    => packaged separately
> >>>
> >>> Quoting Paolo Greppi (2018-11-27 10:52:37)
> >>>> With yesterday's news about the event-stream node module being
> pwned:
> >>>> https://github.com/dominictarr/event-stream/issues/116
> >>>> the importance of these matters should be clear to anyone.
> >>>> Probably there is no component "without major risks", and even
> if it
> >>>> existed, it would be unfair to lay upon the busy maintainer the
> task
> >>>> of deciding if it is risky or not.
> >>>
> >>> Thanks to _both_ of you (and others in the thread) for all your
> work
> >>> tackling these issues.
> >>>
> >>> My point here is *not* to point fingers, but to emphasize an
> important
> >>> aspect of our task as (re)distributors of code: Ensure code
> integrity
> >>> towards our users.
> >>>
> >>>
> >>>  - Jonas
> >>
> >> Thanks, so I propose this policy update - please review this:
> >>  - components used only during build => not used in version
> >>    (except if they inject some code)
> >>  - if upstream version isn't locked on dependencies (see Jérémy
> remark)
> >>    [or if upstream isn't serious?]:
> >>    * very little component => not used in version
> >>    * components that must be followed and maybe used in many other
> >>      packages              => packaged separately
> >>    * other components      => declared as "group" in debian/watch
> >
> > Sorry, I don't understand: Why not track code used during build?
> >
> > Seems you propose to systematically ignore potential upstream
> bugfixes.
> >
> >
> >  - Jonas
> 
> I was thinking to modules used to generate documentation, to test,... So
> even if there is a security issue in them, risk doesn't exist in
> published binary
> 
> 
> If there's something able to inject code in documentation (especially in
> html) it's a big issue...

Not directly but it can affect building machine in the worst case (a
corrupted upstream doc which uses a buffer overflow?)

I think that a Debian policy update should be proposed to fix possible
misuse of components

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 15:48, Bastien ROUCARIES a écrit :
> On Tue, Nov 27, 2018 at 3:45 PM Xavier  wrote:
>>
>> Le 27/11/2018 à 15:33, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2018-11-27 15:22:10)
>>>> Le 27/11/2018 à 15:03, Jonas Smedegaard a écrit :
>>>>> Quoting Xavier (2018-11-27 14:00:42)
>>>>>> Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
>>>>>>> Hi Xavier and Paolo,
>>>>>>>
>>>>>>> Please allow me to highlight this security-related detail:
>>>>>>>
>>>>>>> Quoting Xavier (2018-11-26 16:29:32)
>>>>>>>> Embedding components without following them may be a lack of security.
>>>>>>>> I think we should have a policy for embedding:
>>>>>>>>  - components without major risks   => not used in version
>>>>>>>>  - components that must be followed => declared as "group" in
>>>>>>>>debian/watch
>>>>>>>>  - components that must be followed and used in many other packages
>>>>>>>>=> packaged separately
>>>>>>>
>>>>>>> Quoting Paolo Greppi (2018-11-27 10:52:37)
>>>>>>>> With yesterday's news about the event-stream node module being pwned:
>>>>>>>> https://github.com/dominictarr/event-stream/issues/116
>>>>>>>> the importance of these matters should be clear to anyone.
>>>>>>>> Probably there is no component "without major risks", and even if it
>>>>>>>> existed, it would be unfair to lay upon the busy maintainer the task
>>>>>>>> of deciding if it is risky or not.
>>>>>>>
>>>>>>> Thanks to _both_ of you (and others in the thread) for all your work
>>>>>>> tackling these issues.
>>>>>>>
>>>>>>> My point here is *not* to point fingers, but to emphasize an important
>>>>>>> aspect of our task as (re)distributors of code: Ensure code integrity
>>>>>>> towards our users.
>>>>>>>
>>>>>>>
>>>>>>>  - Jonas
>>>>>>
>>>>>> Thanks, so I propose this policy update - please review this:
>>>>>>  - components used only during build => not used in version
>>>>>>(except if they inject some code)
>>>>>>  - if upstream version isn't locked on dependencies (see Jérémy remark)
>>>>>>[or if upstream isn't serious?]:
>>>>>>* very little component => not used in version
>>>>>>* components that must be followed and maybe used in many other
>>>>>>  packages  => packaged separately
>>>>>>* other components  => declared as "group" in debian/watch
>>>>>
>>>>> Sorry, I don't understand: Why not track code used during build?
>>>>>
>>>>> Seems you propose to systematically ignore potential upstream bugfixes.
>>>>>
>>>>>
>>>>>  - Jonas
>>>>
>>>> I was thinking to modules used to generate documentation, to test,... So
>>>> even if there is a security issue in them, risk doesn't exist in
>>>> published binary
>>>
>>> I think it is dangerous to try judge systematically and automated with
>>> no qualitative input what has security implications and what does not!
>>>
>>>  - Jonas
>>
>> You're right but this has some other cons (version string length,...).
>> Today, components are allowed without any version following. So this
>> point should also be inserted in Debian policy, shouldn't it ?
> 
> Components were created for packaging multiple tar of same project.
> See cernlib package and cry for instance

I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial
Please review it:
 - format : english to review (this is not my mother language)
 - content: I tried to wrote the 2 policies

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] script to generate debian/watch for embedding nodejs modules

2018-11-26 Thread Xavier
Le 26/11/2018 à 15:55, Paolo Greppi a écrit :
> I am thinking of using this approach:
> https://wiki.debian.org/Javascript/GroupSourcesTutorial
> to embed the modules required for yarkpkg.
> 
> I have created a Python script to automatically generate required the 
> debian/watch file:
> https://salsa.debian.org/paolog-guest/create-bundled-watch
> (to use it, modify the data dictionary as required and invoke it)
> 
> Running uscan on the generated yarnpkg debian/watch file, it spits out a 
> bunch of tar errors but also successfully downloads these files:
> 
> babel-plugin-transform-inline-imports-commonjsyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> dnscacheyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> normalize-urlyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> tar-fsyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> v8-compile-cacheyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> yarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> 
> It further creates these soft links:
> 
> node-yarnpkg_0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.orig-babel-plugin-transform-inline-imports-commonjs.tar.gz
>  -> 
> babel-plugin-transform-inline-imports-commonjsyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> node-yarnpkg_0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.orig-dnscache.tar.gz 
> -> 
> dnscacheyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> node-yarnpkg_0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.orig-normalize-url.tar.gz
>  -> 
> normalize-urlyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> node-yarnpkg_0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.orig-tar-fs.tar.gz -> 
> tar-fsyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> node-yarnpkg_0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.orig.tar.gz -> 
> yarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> node-yarnpkg_0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.orig-v8-compile-cache.tar.gz
>  -> 
> v8-compile-cacheyarnpkg_babel-plugin-transform-inline-imports-commonjs_dnscache_normalize-url_tar-fs_v8-compile-cache-0.15.1+~1.2.0+~1.0.1+~4.0.0+~1.16.3+~2.0.2.tar.gz
> 
> The file names are crazy ! is this the way the Debian JavaScript Maintainers 
> team wants to go ?
> If you are brave, generate the debian/watch for npm and try running uscan on 
> it ...

Hi all,

new uscan provides a way to avoid part of this (fakeupstream.cgi was
used to workaround old-uscan). See below.

Embedding components without following them may be a lack of security. I
think we should have a policy for embedding:
 - components without major risks   => not used in version
 - components that must be followed => declared as "group" in
   debian/watch
 - components that must be followed and used in many other packages
   => packaged separately

Example with node-mongodb (accepted by ftpmaster), 3 "group" components.
It is easy to add non followed component (replace "group" by "ignore"):

# debian/watch:
opts="searchmode=plain,pgpmode=none" \
 https://registry.npmjs.org/mongodb
https://registry.npmjs.org/mongodb/-/mongodb-(\d[\d\.]*)@ARCHIVE_EXT@ group

opts="searchmode=plain,pgpmode=none,component=bson" \
 https://registry.npmjs.org/bson
https://registry.npmjs.org/bson/-/bson-(\d[\d\.]*)@ARCHIVE_EXT@ group

opts="searchmode=plain,pgpmode=none,component=mongodb-core" \
 https://registry.npmjs.org/mongodb-core
https://registry.npmjs.org/mongodb-core/-/mongodb-core-(\d[\d\.]*)@ARCHIVE_EXT@
group

opts="searchmode=plain,pgpmode=none,component=requireoptional" \
 https://registry.npmjs.org/require_optional
https://registry.npmjs.org/require_optional/-/require_optional-(\d[\d\.]*)@ARCHIVE_EXT@
group

# uscan result:
bson-4.0.0.tgz
mongodb-3.1.10.tgz
mongodb-core-3.1.9.tgz
node-mongodb/
node-mongodb_3.1.10+~4.0.0+~3.1.9+~1.0.1.orig-bson.tar.gz
 -> bson-4.0.0.tgz
node-mongodb_3.1.10+~4.0.0+~3.1.9+~1.0.1.orig-mongodb-core.tar.gz
 -> mongodb-core-3.1.9.tgz

Re: [Pkg-javascript-devel] script to generate debian/watch for embedding nodejs modules

2018-11-26 Thread Xavier
Le 26/11/2018 à 16:29, Xavier a écrit :
> Le 26/11/2018 à 15:55, Paolo Greppi a écrit :
>> I am thinking of using this approach:
>> https://wiki.debian.org/Javascript/GroupSourcesTutorial
>> to embed the modules required for yarkpkg.
>>
>> I have created a Python script to automatically generate required the 
>> debian/watch file:
>> https://salsa.debian.org/paolog-guest/create-bundled-watch
>> (to use it, modify the data dictionary as required and invoke it)
>>
>> Running uscan on the generated yarnpkg debian/watch file, it spits out a 
>> bunch of tar errors but also successfully downloads these files:
>>
>> ..
>>
>> The file names are crazy ! is this the way the Debian JavaScript Maintainers 
>> team wants to go ?
>> If you are brave, generate the debian/watch for npm and try running uscan on 
>> it ...
> 
> Hi all,
> 
> new uscan provides a way to avoid part of this (fakeupstream.cgi was
> used to workaround old-uscan). See below.
> 
> Embedding components without following them may be a lack of security. I
> think we should have a policy for embedding:
>  - components without major risks   => not used in version
>  - components that must be followed => declared as "group" in
>debian/watch
>  - components that must be followed and used in many other packages
>=> packaged separately
> 
> Example with node-mongodb (accepted by ftpmaster), 3 "group" components.
> It is easy to add non followed component (replace "group" by "ignore"):
> 
> # debian/watch:
> opts="searchmode=plain,pgpmode=none" \
>  https://registry.npmjs.org/mongodb
> https://registry.npmjs.org/mongodb/-/mongodb-(\d[\d\.]*)@ARCHIVE_EXT@ group
> 
> opts="searchmode=plain,pgpmode=none,component=bson" \
>  https://registry.npmjs.org/bson
> https://registry.npmjs.org/bson/-/bson-(\d[\d\.]*)@ARCHIVE_EXT@ group
> 
> opts="searchmode=plain,pgpmode=none,component=mongodb-core" \
>  https://registry.npmjs.org/mongodb-core
> https://registry.npmjs.org/mongodb-core/-/mongodb-core-(\d[\d\.]*)@ARCHIVE_EXT@
> group
> 
> opts="searchmode=plain,pgpmode=none,component=requireoptional" \
>  https://registry.npmjs.org/require_optional
> https://registry.npmjs.org/require_optional/-/require_optional-(\d[\d\.]*)@ARCHIVE_EXT@
> group
> 
> # uscan result:
> bson-4.0.0.tgz
> mongodb-3.1.10.tgz
> mongodb-core-3.1.9.tgz
> node-mongodb/
> node-mongodb_3.1.10+~4.0.0+~3.1.9+~1.0.1.orig-bson.tar.gz
>  -> bson-4.0.0.tgz
> node-mongodb_3.1.10+~4.0.0+~3.1.9+~1.0.1.orig-mongodb-core.tar.gz
>  -> mongodb-core-3.1.9.tgz
> node-mongodb_3.1.10+~4.0.0+~3.1.9+~1.0.1.orig-requireoptional.tar.gz
>  -> require_optional-1.0.1.tgz
> node-mongodb_3.1.10+~4.0.0+~3.1.9+~1.0.1.orig.tar.gz
>  -> mongodb-3.1.10.tgz
> require_optional-1.0.1.tgz
> 
> 
> In this case, require_optional may be declared as "ignore". This gives:
> 
> bson-4.0.0.tgz
> mongodb-3.1.10.tgz
> mongodb-core-3.1.9.tgz
> node-mongodb/
> node-mongodb_3.1.10+~4.0.0+~3.1.9.orig-bson.tar.gz
>  -> bson-4.0.0.tgz
> node-mongodb_3.1.10+~4.0.0+~3.1.9.orig-mongodb-core.tar.gz
>  -> mongodb-core-3.1.9.tgz
> node-mongodb_3.1.10+~4.0.0+~3.1.9.orig-requireoptional.tar.gz
>  -> require_optional-1.0.1.tgz
> node-mongodb_3.1.10+~4.0.0+~3.1.9.orig.tar.gz
>  -> mongodb-3.1.10.tgz
> require_optional-1.0.1.tgz
> 
> 
> Looks acceptable IMO

Policy update:
 - components used only during build => not used in version
   (except if they inject some code)
 - components without major risks=> not used in version
 - components that must be followed  => declared as "group" in
   debian/watch
 - components that must be followed and used in many other packages
   => packaged separately

Note: I wrote this to help js-team and decrease time to wait in NEW
queue. If you feel that "crazy", please simply delete
https://wiki.debian.org/Javascript/GroupSourcesTutorial and the links to
this page.

I you don't want to do it by yourself, I can remove the page for you.
Just ask me to do it.

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] script to generate debian/watch for embedding nodejs modules

2018-11-26 Thread Xavier
Xavier wrote:
>> ...
>> Looks acceptable IMO
> 
> Policy update:
>  - components used only during build => not used in version
>(except if they inject some code)
>  - components without major risks=> not used in version
>  - components that must be followed  => declared as "group" in
>debian/watch
>  - components that must be followed and used in many other packages
>=> packaged separately
> 
> Note: I wrote this to help js-team and decrease time to wait in NEW
> queue. If you feel that "crazy", please simply delete
> https://wiki.debian.org/Javascript/GroupSourcesTutorial and the links to
> this page.
> 
> I you don't want to do it by yourself, I can remove the page for you.
> Just ask me to do it.
> 
> Cheers,
> Xavier
> 

Warning added on top of
https://wiki.debian.org/Javascript/GroupSourcesTutorial

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
> Hi Xavier and Paolo,
> 
> Please allow me to highlight this security-related detail:
> 
> Quoting Xavier (2018-11-26 16:29:32)
>> Embedding components without following them may be a lack of security. 
>> I think we should have a policy for embedding:
>>  - components without major risks   => not used in version
>>  - components that must be followed => declared as "group" in
>>debian/watch
>>  - components that must be followed and used in many other packages
>>=> packaged separately
> 
> Quoting Paolo Greppi (2018-11-27 10:52:37)
>> With yesterday's news about the event-stream node module being pwned: 
>> https://github.com/dominictarr/event-stream/issues/116
>> the importance of these matters should be clear to anyone.
>> Probably there is no component "without major risks", and even if it 
>> existed, it would be unfair to lay upon the busy maintainer the task 
>> of deciding if it is risky or not.
> 
> Thanks to _both_ of you (and others in the thread) for all your work 
> tackling these issues.
> 
> My point here is *not* to point fingers, but to emphasize an important 
> aspect of our task as (re)distributors of code: Ensure code integrity 
> towards our users.
> 
> 
>  - Jonas

Thanks, so I propose this policy update - please review this:
 - components used only during build => not used in version
   (except if they inject some code)
 - if upstream version isn't locked on dependencies (see Jérémy remark)
   [or if upstream isn't serious?]:
   * very little component => not used in version
   * components that must be followed and maybe used in many other
 packages  => packaged separately
   * other components  => declared as "group" in debian/watch

Sharing policy (components published via debian/control "Provides:") -
please review this:
 - components used only during build => no
 - components locked in an too oldest version => no [needs to patch code
   to replace "require('x')" by "require('main_mod/x/index.js')" and to
   install this component in /usr.../main_mod/x]. Maybe a better way?
 - components installed in main node_modules => published


Example with node-mongodb:
 - mongodb-core => group + published
 - bson => group + not published (locked to 1.1.0 while upstream
  published a 4.0.0, NB: same author so
  less security risk)
 - require_optional => not grouped + not published (simple package that
avoid failure on
"require" to an
optional module:
try/catch)

Maybe a "debian/README.source" might be required for the DD to explain
his choices (lintian error if missing).

I think also that dak should redirect an upload to NEW queue when a new
component is added, at least in version (like every time a new binary
package is added)

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 13:47, Xavier a écrit :
> Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
>> Hi Xavier and Paolo,
>>
>> Please allow me to highlight this security-related detail:
>>
>> Quoting Xavier (2018-11-26 16:29:32)
>>> Embedding components without following them may be a lack of security. 
>>> I think we should have a policy for embedding:
>>>  - components without major risks   => not used in version
>>>  - components that must be followed => declared as "group" in
>>>debian/watch
>>>  - components that must be followed and used in many other packages
>>>=> packaged separately
>>
>> Quoting Paolo Greppi (2018-11-27 10:52:37)
>>> With yesterday's news about the event-stream node module being pwned: 
>>> https://github.com/dominictarr/event-stream/issues/116
>>> the importance of these matters should be clear to anyone.
>>> Probably there is no component "without major risks", and even if it 
>>> existed, it would be unfair to lay upon the busy maintainer the task 
>>> of deciding if it is risky or not.
>>
>> Thanks to _both_ of you (and others in the thread) for all your work 
>> tackling these issues.
>>
>> My point here is *not* to point fingers, but to emphasize an important 
>> aspect of our task as (re)distributors of code: Ensure code integrity 
>> towards our users.
>>
>>
>>  - Jonas
> 
> Thanks, so I propose this policy update - please review this:
>  - components used only during build => not used in version
>(except if they inject some code)
>  - if upstream version isn't locked on dependencies (see Jérémy remark)
>[or if upstream isn't serious?]:
>* very little component => not used in version
>* components that must be followed and maybe used in many other
>  packages  => packaged separately
>* other components  => declared as "group" in debian/watch
> 
> Sharing policy (components published via debian/control "Provides:") -
> please review this:
>  - components used only during build => no
>  - components locked in an too oldest version => no [needs to patch code
>to replace "require('x')" by "require('main_mod/x/index.js')" and to
>install this component in /usr.../main_mod/x]. Maybe a better way?
>  - components installed in main node_modules => published
> 
> 
> Example with node-mongodb:
>  - mongodb-core => group + published
>  - bson => group + not published (locked to 1.1.0 while upstream
>   published a 4.0.0, NB: same author so
>   less security risk)
>  - require_optional => not grouped + not published (simple package that
> avoid failure on
> "require" to an
>     optional module:
> try/catch)
> 
> Maybe a "debian/README.source" might be required for the DD to explain
> his choices (lintian error if missing).
> 
> I think also that dak should redirect an upload to NEW queue when a new
> component is added, at least in version (like every time a new binary
> package is added)
> 
> Regards,
> Xavier

Another problem to keep in mind, imagine node-mongodb published
"require_optional" or "bson" in /usr/lib/nodejs or
,/usr/lib/node_modules. Then every module who wants to use
require_optional will depends on node-mongodb driver! We must evaluate
this point before publishing a component and so lock
/usr/lib/nodejs/ directory, to decide if there is not too many
unwanted package installed.

(NB: I will upload a new version of node-mongodb, consistent with the
policy when it will be stable)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
> Hi Xavier and Paolo,
> 
> Please allow me to highlight this security-related detail:
> 
> Quoting Xavier (2018-11-26 16:29:32)
>> Embedding components without following them may be a lack of security. 
>> I think we should have a policy for embedding:
>>  - components without major risks   => not used in version
>>  - components that must be followed => declared as "group" in
>>debian/watch
>>  - components that must be followed and used in many other packages
>>=> packaged separately
> 
> Quoting Paolo Greppi (2018-11-27 10:52:37)
>> With yesterday's news about the event-stream node module being pwned: 
>> https://github.com/dominictarr/event-stream/issues/116
>> the importance of these matters should be clear to anyone.
>> Probably there is no component "without major risks", and even if it 
>> existed, it would be unfair to lay upon the busy maintainer the task 
>> of deciding if it is risky or not.
> 
> Thanks to _both_ of you (and others in the thread) for all your work 
> tackling these issues.
> 
> My point here is *not* to point fingers, but to emphasize an important 
> aspect of our task as (re)distributors of code: Ensure code integrity 
> towards our users.
> 
> 
>  - Jonas

Thanks, so I propose this policy update - please review this:
 - components used only during build => not used in version
   (except if they inject some code)
 - if upstream version isn't locked on dependencies (see Jérémy remark)
   [or if upstream isn't serious?]:
   * very little component => not used in version
   * components that must be followed and maybe used in many other
 packages  => packaged separately
   * other components  => declared as "group" in debian/watch

Sharing policy (components published via debian/control "Provides:") -
please review this:
 - components used only during build => no
 - components locked in an too oldest version => no [needs to patch code
   to replace "require('x')" by "require('main_mod/x/index.js')" and to
   install this component in /usr.../main_mod/x]. Maybe a better way?
 - components installed in main node_modules => published


Example with node-mongodb:
 - mongodb-core => group + published
 - bson => group + not published (locked to 1.1.0 while upstream
  published a 4.0.0, NB: same author so
  less security risk)
 - require_optional => not grouped + not published (simple package that
avoid failure on
"require" to an
optional module:
try/catch)

Maybe a "debian/README.source" might be required for the DD to explain
his choices (lintian error if missing).

I think also that dak should redirect an upload to NEW queue when a new
component is added, at least in version (like every time a new binary
package is added)

Regards,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 13:47, Xavier a écrit :
> Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
>> Hi Xavier and Paolo,
>>
>> Please allow me to highlight this security-related detail:
>>
>> Quoting Xavier (2018-11-26 16:29:32)
>>> Embedding components without following them may be a lack of security. 
>>> I think we should have a policy for embedding:
>>>  - components without major risks   => not used in version
>>>  - components that must be followed => declared as "group" in
>>>debian/watch
>>>  - components that must be followed and used in many other packages
>>>=> packaged separately
>>
>> Quoting Paolo Greppi (2018-11-27 10:52:37)
>>> With yesterday's news about the event-stream node module being pwned: 
>>> https://github.com/dominictarr/event-stream/issues/116
>>> the importance of these matters should be clear to anyone.
>>> Probably there is no component "without major risks", and even if it 
>>> existed, it would be unfair to lay upon the busy maintainer the task 
>>> of deciding if it is risky or not.
>>
>> Thanks to _both_ of you (and others in the thread) for all your work 
>> tackling these issues.
>>
>> My point here is *not* to point fingers, but to emphasize an important 
>> aspect of our task as (re)distributors of code: Ensure code integrity 
>> towards our users.
>>
>>
>>  - Jonas
> 
> Thanks, so I propose this policy update - please review this:
>  - components used only during build => not used in version
>(except if they inject some code)
>  - if upstream version isn't locked on dependencies (see Jérémy remark)
>[or if upstream isn't serious?]:
>* very little component => not used in version
>* components that must be followed and maybe used in many other
>  packages  => packaged separately
>* other components  => declared as "group" in debian/watch
> 
> Sharing policy (components published via debian/control "Provides:") -
> please review this:
>  - components used only during build => no
>  - components locked in an too oldest version => no [needs to patch code
>to replace "require('x')" by "require('main_mod/x/index.js')" and to
>install this component in /usr.../main_mod/x]. Maybe a better way?
>  - components installed in main node_modules => published
> 
> 
> Example with node-mongodb:
>  - mongodb-core => group + published
>  - bson => group + not published (locked to 1.1.0 while upstream
>   published a 4.0.0, NB: same author so
>   less security risk)
>  - require_optional => not grouped + not published (simple package that
> avoid failure on
> "require" to an
>     optional module:
> try/catch)
> 
> Maybe a "debian/README.source" might be required for the DD to explain
> his choices (lintian error if missing).
> 
> I think also that dak should redirect an upload to NEW queue when a new
> component is added, at least in version (like every time a new binary
> package is added)
> 
> Regards,
> Xavier

Another problem to keep in mind, imagine node-mongodb published
"require_optional" or "bson" in /usr/lib/nodejs or
,/usr/lib/node_modules. Then every module who wants to use
require_optional will depends on node-mongodb driver! We must evaluate
this point before publishing a component and so lock
/usr/lib/nodejs/ directory, to decide if there is not too many
unwanted package installed.

(NB: I will upload a new version of node-mongodb, consistent with the
policy when it will be stable)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 15:03, Jonas Smedegaard a écrit :
> Quoting Xavier (2018-11-27 14:00:42)
>> Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
>>> Hi Xavier and Paolo,
>>>
>>> Please allow me to highlight this security-related detail:
>>>
>>> Quoting Xavier (2018-11-26 16:29:32)
>>>> Embedding components without following them may be a lack of security. 
>>>> I think we should have a policy for embedding:
>>>>  - components without major risks   => not used in version
>>>>  - components that must be followed => declared as "group" in
>>>>debian/watch
>>>>  - components that must be followed and used in many other packages
>>>>=> packaged separately
>>>
>>> Quoting Paolo Greppi (2018-11-27 10:52:37)
>>>> With yesterday's news about the event-stream node module being pwned: 
>>>> https://github.com/dominictarr/event-stream/issues/116
>>>> the importance of these matters should be clear to anyone.
>>>> Probably there is no component "without major risks", and even if it 
>>>> existed, it would be unfair to lay upon the busy maintainer the task 
>>>> of deciding if it is risky or not.
>>>
>>> Thanks to _both_ of you (and others in the thread) for all your work 
>>> tackling these issues.
>>>
>>> My point here is *not* to point fingers, but to emphasize an important 
>>> aspect of our task as (re)distributors of code: Ensure code integrity 
>>> towards our users.
>>>
>>>
>>>  - Jonas
>>
>> Thanks, so I propose this policy update - please review this:
>>  - components used only during build => not used in version
>>(except if they inject some code)
>>  - if upstream version isn't locked on dependencies (see Jérémy remark)
>>[or if upstream isn't serious?]:
>>* very little component => not used in version
>>* components that must be followed and maybe used in many other
>>  packages  => packaged separately
>>* other components  => declared as "group" in debian/watch
> 
> Sorry, I don't understand: Why not track code used during build?
> 
> Seems you propose to systematically ignore potential upstream bugfixes.
> 
> 
>  - Jonas

I was thinking to modules used to generate documentation, to test,... So
even if there is a security issue in them, risk doesn't exist in
published binary

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] components without major risks

2018-11-27 Thread Xavier
Le 27/11/2018 à 15:22, Xavier a écrit :
> Le 27/11/2018 à 15:03, Jonas Smedegaard a écrit :
>> Quoting Xavier (2018-11-27 14:00:42)
>>> Le 27/11/2018 à 11:55, Jonas Smedegaard a écrit :
>>>> Hi Xavier and Paolo,
>>>>
>>>> Please allow me to highlight this security-related detail:
>>>>
>>>> Quoting Xavier (2018-11-26 16:29:32)
>>>>> Embedding components without following them may be a lack of security. 
>>>>> I think we should have a policy for embedding:
>>>>>  - components without major risks   => not used in version
>>>>>  - components that must be followed => declared as "group" in
>>>>>debian/watch
>>>>>  - components that must be followed and used in many other packages
>>>>>=> packaged separately
>>>>
>>>> Quoting Paolo Greppi (2018-11-27 10:52:37)
>>>>> With yesterday's news about the event-stream node module being pwned: 
>>>>> https://github.com/dominictarr/event-stream/issues/116
>>>>> the importance of these matters should be clear to anyone.
>>>>> Probably there is no component "without major risks", and even if it 
>>>>> existed, it would be unfair to lay upon the busy maintainer the task 
>>>>> of deciding if it is risky or not.
>>>>
>>>> Thanks to _both_ of you (and others in the thread) for all your work 
>>>> tackling these issues.
>>>>
>>>> My point here is *not* to point fingers, but to emphasize an important 
>>>> aspect of our task as (re)distributors of code: Ensure code integrity 
>>>> towards our users.
>>>>
>>>>
>>>>  - Jonas
>>>
>>> Thanks, so I propose this policy update - please review this:
>>>  - components used only during build => not used in version
>>>(except if they inject some code)
>>>  - if upstream version isn't locked on dependencies (see Jérémy remark)
>>>[or if upstream isn't serious?]:
>>>* very little component => not used in version
>>>* components that must be followed and maybe used in many other
>>>  packages  => packaged separately
>>>* other components  => declared as "group" in debian/watch
>>
>> Sorry, I don't understand: Why not track code used during build?
>>
>> Seems you propose to systematically ignore potential upstream bugfixes.
>>
>>
>>  - Jonas
> 
> I was thinking to modules used to generate documentation, to test,... So
> even if there is a security issue in them, risk doesn't exist in
> published binary

This can avoid having a too long version string. We talked about version
summarization earlier, but it had many cons

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] script to generate debian/watch for embedding nodejs modules

2018-11-26 Thread Xavier
Le 26/11/2018 à 19:40, Jérémy Lal a écrit :
> 
> 
> Le lun. 26 nov. 2018 à 17:29, Xavier  <mailto:y...@debian.org>> a écrit :
> 
> Xavier wrote:
> >> ...
> >> Looks acceptable IMO
> >
> > Policy update:
> >  - components used only during build => not used in version
> >    (except if they inject some code)
> >  - components without major risks    => not used in version
> >  - components that must be followed  => declared as "group" in
> >    debian/watch
> >  - components that must be followed and used in many other packages
> >    => packaged separately
> >
> > Note: I wrote this to help js-team and decrease time to wait in NEW
> > queue. If you feel that "crazy", please simply delete
> > https://wiki.debian.org/Javascript/GroupSourcesTutorial and the
> links to
> > this page.
> >
> > I you don't want to do it by yourself, I can remove the page for you.
> > Just ask me to do it.
> 
> 
> This is certainly not crazy, and while i'm not myself completely
> convinced it's the right approach,
> (mostly because i did not took the time to review and practice), it's
> the closest thing we have
> to a usable solution.
> 
> Please don't stop there, it would be such a waste.
> 
> About the bundled packages and the weird version encoding all the
> bundled versions:
> most upstreams that are serious about their packaging now use a
> package-lock file,
> effectively locking down a released version to the needed versions of
> dependencies.
> When it's the case, it means that any change in versions of dependencies
> will be reflected
> by a new parent package version. In that case, it's useless to encode
> dependencies versions
> in the parent debian package version ?
> 
> Jérémy

You're right, in that case, components must be tagged as "ignore" or
best a version number ("0.0.1" for example) directly in debian/watch.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-duplexer2 and 3 - possible to keep only one ?

2019-01-08 Thread Xavier
Le 08/01/2019 à 23:23, Jérémy Lal a écrit :
> Hi,
> 
> is there a reason to keep both 
> node-duplexer2
> node-duplexer3
> packages ?
> It seems it's feasible to keep only one, unless we miss a deeper issue ?
> 
> Jérémy

Only 1 difference: node-duplexer2 uses `readable-stream` while
node-duplexer3 uses `stream` but there is a debian patch in
node-duplexer2 that replace `readable-stream` by `stream`, so Debian
package are identical (and so have the same RC bug...).

Full diff is attached.

Reverse-dependencies:
 * node-duplexer2 :
   |
   +-> node-multipipe
   |  |
   |  +-> node-gulp-util
   |  |
   |  +-> gulp & Co
   |
   +-> node-static-module
   |  |
   |  +-> node-brfs
   |
   +-> node-stream-combiner2
  |
  +-> node-module-deps

 * node-duplexer3 :
   |
   +-> node-got
   |
   +-> node-package-json
   |
   +-> node-latest-version
   |
   +-> npm
diff -aburN -x .git node-duplexer2/debian/changelog node-duplexer3/debian/changelog
--- node-duplexer2/debian/changelog	2019-01-08 23:06:17.285546692 +0100
+++ node-duplexer3/debian/changelog	2019-01-08 23:06:23.373438036 +0100
@@ -1,5 +1,13 @@
-node-duplexer2 (0.1.4-1) unstable; urgency=low
+node-duplexer3 (0.1.4-2) unstable; urgency=medium
 
-  * Initial release (Closes: #845727)
+  * Team upload
+  * Reupload to unstable
+
+ -- Pirate Praveen   Mon, 11 Dec 2017 19:03:15 +0530
+
+node-duplexer3 (0.1.4-1) experimental; urgency=low
+
+  * Initial release (Closes: #852778)
+
+ -- Tushar Agey   Fri, 27 Jan 2017 07:16:24 +
 
- -- Pirate Praveen   Sat, 26 Nov 2016 15:41:03 +0530
diff -aburN -x .git node-duplexer2/debian/control node-duplexer3/debian/control
--- node-duplexer2/debian/control	2019-01-08 23:06:17.285546692 +0100
+++ node-duplexer3/debian/control	2019-01-08 23:06:23.373438036 +0100
@@ -1,23 +1,28 @@
-Source: node-duplexer2
-Section: web
+Source: node-duplexer3
+Section: javascript
 Priority: optional
 Maintainer: Debian Javascript Maintainers 
-Uploaders: Pirate Praveen 
+Uploaders: Tushar Agey 
 Build-Depends:
  debhelper (>= 9)
  , dh-buildinfo
  , nodejs
+ , node-tap
  , mocha
-Standards-Version: 3.9.8
-Homepage: https://github.com/deoxxa/duplexer2#readme
-Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-duplexer2.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-duplexer2.git
+Standards-Version: 4.1.2
+Homepage: https://github.com/floatdrop/duplexer3
+Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-duplexer3.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-duplexer3.git
 
-Package: node-duplexer2
+Package: node-duplexer3
 Architecture: all
 Depends:
  ${misc:Depends}
  , nodejs
 Description: Like duplexer but using streams3
+ This is a reimplementation of duplexer using the Streams3 API
+ which is standard in Node as of v4. Everything largely works the same
+ Duplexer takes a writable stream and a readable stream and makes them
+ appear as a readable writable stream.
  .
  Node.js is an event-based server-side JavaScript engine.
diff -aburN -x .git node-duplexer2/debian/copyright node-duplexer3/debian/copyright
--- node-duplexer2/debian/copyright	2019-01-08 23:06:17.285546692 +0100
+++ node-duplexer3/debian/copyright	2019-01-08 23:06:23.373438036 +0100
@@ -1,14 +1,14 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: duplexer2
-Upstream-Contact: https://github.com/deoxxa/duplexer2/issues
-Source: https://github.com/deoxxa/duplexer2#readme
+Upstream-Name: duplexer3
+Upstream-Contact: https://github.com/floatdrop/duplexer3/issues
+Source: https://github.com/floatdrop/duplexer3
 
 Files: *
-Copyright: 2016 Conrad Pankoff  (http://www.fknsrs.biz/)
+Copyright: 2017 Conrad Pankoff  (http://www.fknsrs.biz/)
 License: BSD-3-Clause
 
 Files: debian/*
-Copyright: 2016 Pirate Praveen 
+Copyright: 2017 Tushar Agey 
 License: BSD-3-Clause
 
 License: BSD-3-clause
diff -aburN -x .git node-duplexer2/debian/install node-duplexer3/debian/install
--- node-duplexer2/debian/install	2019-01-08 23:06:17.285546692 +0100
+++ node-duplexer3/debian/install	2019-01-08 23:06:23.373438036 +0100
@@ -1,2 +1,2 @@
-index.js usr/lib/nodejs/duplexer2/
-package.json usr/lib/nodejs/duplexer2/
+package.json usr/lib/nodejs/duplexer3/
+index.js usr/lib/nodejs/duplexer3/
diff -aburN -x .git node-duplexer2/debian/patches/replace-readable-stream.patch node-duplexer3/debian/patches/replace-readable-stream.patch
--- node-duplexer2/debian/patches/replace-readable-stream.patch	2019-01-08 23:06:17.285546692 +0100
+++ node-duplexer3/debian/patches/replace-readable-stream.patch	1970-01-01 01:00:00.0 +0100
@@ -1,30 +0,0 @@
 a/index.js
-+++ b/index.js
-@@ -1,6 +1,6 @@
- "use strict";
- 
--var stream = require("readable-stream");
-+var stream = require("stream");
- 
- function DuplexWrapper(options, writable, readable) {
-   if (typeof readable === "undefined") {
 a/test/tests.js
-+++ b/test/tests.js
-@@ -1,7 

[Pkg-javascript-devel] Bug#902508: node-send: FTBFS in buster/sid (TypeError: mime.lookup is not a function)

2019-01-10 Thread Xavier
Problem found: node-send depends on node-mime 1.6 while unstable has
node-mime 2.3.1-1 (with breaking changes)

Probably same issue for #902507

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#902509: node-serve-static: FTBFS in buster/sid (TypeError: mime.lookup is not a function)

2019-01-10 Thread Xavier
Control: reassign -1 node-send

Build error is in node-send (index.js line 693)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Time for a RC bug ?

2019-01-10 Thread Xavier
Hello,

npm now seems unusable with node-10:

  npm WARN npm npm does not support Node.js v10.15.0
  npm WARN npm You should probably upgrade to a newer version of node as
  we
  npm WARN npm can't make any promises that npm will work with this
  version.
  npm WARN npm Supported releases of Node.js are the latest release of
  4, 6, 7, 8, 9.
  npm WARN npm You can find the latest version at https://nodejs.org/
  npm ERR! Class constructor LRUCache cannot be invoked without 'new'

I think a RC bug is needed somewhere (npm or one dependency)

@kapouer: also for node-lru-cache, please accept my [MR]: build fail on
low performance machine (another too short timeout)

Cheers,
Xavier

MR: https://salsa.debian.org/js-team/node-lru-cache/merge_requests/1

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#918935: node-browserify-lite FTBFS: Error: Cannot find module '../tools/exit'

2019-01-10 Thread Xavier
Le 10/01/2019 à 19:41, Xavier a écrit :
>> ...
>> That does actually look like a bug in the new uglifyfs.
>>
>> cu
>> Adrian
> 
> I tried to reproduce but have different errors related to debian/examples* :

debian/control should require node-pend (>= 1.2.0)


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Bug#918935: node-browserify-lite FTBFS: Error: Cannot find module '../tools/exit'

2019-01-10 Thread Xavier
Le 10/01/2019 à 19:34, Adrian Bunk a écrit :
> Control: reassign -1 uglifyjs 3.4.9-2
> Control: retitle -1 uglifyjs: Error: Cannot find module '../tools/exit'
> Control: affects -1 src:node-browserify-lite
> 
> On Thu, Jan 10, 2019 at 08:04:46PM +0200, Adrian Bunk wrote:
>> Source: node-browserify-lite
>> Version: 0.5.0-3
>> Severity: serious
>> Tags: ftbfs
>>
>> https://buildd.debian.org/status/fetch.php?pkg=node-browserify-lite=all=0.5.0-3=1547086740=0
>>
>> ...
>>debian/rules override_dh_auto_build
>> make[1]: Entering directory '/<>'
>> NODE_PATH=. /<>/cli.js debian/examples.d/main.js --outfile 
>> debian/examples.d/bundle.js
>> cd debian/examples.d/ && uglifyjs bundle.js -m --verbose --source-map  
>> bundle.compress.js.map -o bundle.compress.js
>> internal/modules/cjs/loader.js:583
>> throw err;
>> ^
>>
>> Error: Cannot find module '../tools/exit'
>> at Function.Module._resolveFilename 
>> (internal/modules/cjs/loader.js:581:15)
>> at Function.Module._load (internal/modules/cjs/loader.js:507:25)
>> at Module.require (internal/modules/cjs/loader.js:637:17)
>> at require (internal/modules/cjs/helpers.js:22:18)
>> at Object. (/usr/lib/nodejs/uglify-js/bin/uglifyjs:6:1)
>> at Module._compile (internal/modules/cjs/loader.js:689:30)
>> at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
>> at Module.load (internal/modules/cjs/loader.js:599:32)
>> at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
>> at Function.Module._load (internal/modules/cjs/loader.js:530:3)
>> make[1]: *** [debian/rules:26: debian/examples.d/bundle.compress.js] Error 1
> 
> That does actually look like a bug in the new uglifyfs.
> 
> cu
> Adrian

I tried to reproduce but have different errors related to debian/examples* :

NODE_PATH=. /<>/cli.js debian/examples.d/main.js
--standalone 'example' --outfile debian/examples.d/standalone.js
cd debian/examples.d/ && uglifyjs bundle.js -m --verbose --source-map
bundle.compress.js.map -o bundle.compress.js
cd debian/examples.d/ && uglifyjs bundle.js --verbose --source-map
bundle.min.js.map -o bundle.min.js
cd debian/examples.d/ && uglifyjs standalone.js --verbose --source-map
standalone.min.js.map -o standalone.min.js
cd debian/examples.d/ && uglifyjs standalone.js -m --verbose
--source-map  standalone.compress.js.map -o standalone.compress.js
Supported options:Supported options:Supported options:

  content null
  filenamenull
  includeSources  false
  rootnull
  url null
  content null
  filenamenull
  includeSources  false
  rootnull
  url null

  content null
  filenamenull
  includeSources  false
  rootnull
  url nullERROR: `bundle.compress.js.map` is not a supported
option
at DefaultsError.get (eval at 
(/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :71:23)
at fatal (/usr/lib/nodejs/uglify-js/bin/uglifyjs:291:53)
at run (/usr/lib/nodejs/uglify-js/bin/uglifyjs:235:9)
at Object. (/usr/lib/nodejs/uglify-js/bin/uglifyjs:160:5)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
ERROR: `standalone.min.js.map` is not a supported option
at DefaultsError.get (eval at 
(/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :71:23)
at fatal (/usr/lib/nodejs/uglify-js/bin/uglifyjs:291:53)
at run (/usr/lib/nodejs/uglify-js/bin/uglifyjs:235:9)
at Object. (/usr/lib/nodejs/uglify-js/bin/uglifyjs:160:5)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
make[1]: *** [debian/rules:26: debian/examples.d/bundle.compress.js] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: *** [debian/rules:23: debian/examples.d/standalone.min.js] Error 1

ERROR: `bundle.min.js.map` is not a supported option
at DefaultsError.get (eval at 
(/usr/lib/nodejs/uglify-js/tools/node.js:20:1), :71:23)
at fatal (/usr/lib/nodejs/uglify-js/bin/uglifyjs:291:53)
at run (/usr/lib/nodejs/uglify-js/bin/uglifyjs:235:9)
at Object. (/usr/lib/nodejs/uglify-js/bin/uglifyjs:160:5)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad 

Re: [Pkg-javascript-devel] libjs-cryptojs: Please upgrade to 3.1.9

2018-12-28 Thread Xavier
Hello,

do you want that we take maintenance of this package under JS-Team umbrella

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] mocha timeout

2019-01-11 Thread Xavier
Le 11/01/2019 à 10:19, Jérémy Lal a écrit :
> 
> 
> Le ven. 11 janv. 2019 à 09:26, Xavier  <mailto:y...@debian.org>> a écrit :
> 
> Hi all,
> 
> for some packages, default mocha timeout (2000 ms) is too short for
> autopkgtest. I patched some package to increase it but I think we could
> increase this timeout directly in mocha source to avoid these failures.
> 
> 
> It's somewhat "wrong" because it changes what usual users expect of mocha.
> Is there any way to make mocha detect it is running in autopkgtest ?

Not only, buildd fails sometime for the same reason


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] mocha timeout

2019-01-11 Thread Xavier
Le 11/01/2019 à 10:22, Xavier a écrit :
> Le 11/01/2019 à 10:19, Jérémy Lal a écrit :
>>
>>
>> Le ven. 11 janv. 2019 à 09:26, Xavier > <mailto:y...@debian.org>> a écrit :
>>
>> Hi all,
>>
>> for some packages, default mocha timeout (2000 ms) is too short for
>> autopkgtest. I patched some package to increase it but I think we could
>> increase this timeout directly in mocha source to avoid these failures.
>>
>>
>> It's somewhat "wrong" because it changes what usual users expect of mocha.
>> Is there any way to make mocha detect it is running in autopkgtest ?
> 
> Not only, buildd fails sometime for the same reason

I can reproduce failure in node-mocha here using a simple sbuild

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] mocha timeout

2019-01-11 Thread Xavier
Same for mocha itself !

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/node-mocha_4.1.0+ds3-1.rbuild.log.gz

Le 11/01/2019 à 09:26, Xavier a écrit :
> Hi all,
> 
> for some packages, default mocha timeout (2000 ms) is too short for
> autopkgtest. I patched some package to increase it but I think we could
> increase this timeout directly in mocha source to avoid these failures.
> 
> Cheers,
> Xavier
> 

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] mocha timeout

2019-01-11 Thread Xavier
Hi all,

for some packages, default mocha timeout (2000 ms) is too short for
autopkgtest. I patched some package to increase it but I think we could
increase this timeout directly in mocha source to avoid these failures.

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-livescript FTBFS with nodejs 10.15.0

2019-01-10 Thread Xavier
Control: tags -1 + moreinfo

Hello,

I'm unable to reproduce this bug and
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-livescript.html
seems clean at least since 2019-01-07

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-duplexer2 and 3 - possible to keep only one ?

2019-01-09 Thread Xavier
Le 09/01/2019 à 08:02, Pirate Praveen a écrit :
> 
> 
> On Wed, Jan 9, 2019 at 11:51 AM, Xavier  wrote:
>> Le 08/01/2019 à 23:23, Jérémy Lal a écrit :
>>
>> Hi, is there a reason to keep both  node-duplexer2 node-duplexer3
>> packages ? It seems it's feasible to keep only one, unless we miss
>> a deeper issue ? Jérémy 
>>
>> Only 1 difference: node-duplexer2 uses `readable-stream` while
>> node-duplexer3 uses `stream` but there is a debian patch in
>> node-duplexer2 that replace `readable-stream` by `stream`, so Debian
>> package are identical (and so have the same RC bug...). Full diff is
>> attached. Reverse-dependencies: * node-duplexer2 : | +->
>> node-multipipe | | | +-> node-gulp-util | | | +-> gulp & Co | +->
>> node-static-module | | | +-> node-brfs | +-> node-stream-combiner2 |
>> +-> node-module-deps * node-duplexer3 : | +-> node-got | +->
>> node-package-json | +-> node-latest-version | +-> npm
> 
> I think we can drop node-duplexer2 and add Provieds: node-duplexer2 to
> node-duplexer3. This will also require adding a symlink to duplexer3
> from duplexer2 in /usr/lib/nodejs.

I'm going to do it

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Request to join Javascript team

2019-01-14 Thread Xavier
Le 14/01/2019 à 10:09, Utkarsh Gupta a écrit :
> Hey,
> 
> I am already a part of ruby and go team, and would like to join the
> Javascript team, as well. 
> 
> My QA profile could be found on
> https://qa.debian.org/developer.php?login=guptautkarsh2...@gmail.com
> 
> I've requested to join the salsa team[2].
> 
> Requesting you to please grant me the access so I can start updating the
> packages at the earliest. 
> 
> [2]: https://salsa.debian.org/js-team/

Hello,

welcome to this group! Please read:
 - our policy [1] & [2]
 - embedding policy [3]

To ask for review, you can add an issue to [4] with tag RFS or RFC.
Don't hesitate to ask for help if necessary on this list.

Cheers,
Xavier

[1] https://wiki.debian.org/Javascript/Policy
[2] https://wiki.debian.org/Javascript/Nodejs
[3] https://wiki.debian.org/Javascript/GroupSourcesTutorial
[4] https://salsa.debian.org/js-team/current_itps/boards

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Draft to embed more than one Node module in a Debian package

2018-09-13 Thread Xavier
Ref:

Hi all,

Ftpmasters want to reduce node packages in NEW queue [1]. Extract:

  "node packages are rather small and often consist only of a few lines
  of code. From my point of view it is very unlikely that such packages
  will change over time, so their code will remain constant forever.
  More likely upstreams will add new features and pay no attention to
  backward compatible APIs.

  In the node ecosystem everything is fine. Their developers use carets
  or tildes as dependency operators and just depened on the version of
  the API they really need.

  In Debian such packages basically create two problems. They bloat the
  packages file, which prolongs the process of installing or updating
  packages. Further Debian only allows packages with one, the latest,
  version in the archive. So uploading packages with the newer API would
  make packages unusable, that still depend on the older API. Usually
  this is not recognized and suddenly packages in the archive won't work
  anymore.
  One could introduce versions within package names, but this would just
  multiply the number of node packages."
  ...

After a long discussion in JS team, I built a Wiki draft [2] and I would
like to have an opinion of Security Team before continuing in this way.

Cheers,
Xavier

[1]
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-September/027849.html
[2] https://wiki.debian.org/Javascript/GroupSourcesTutorial





signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-13 Thread Xavier
Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
> 
> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>> Hi Xavier,
>>
>> The example in Provides section should be written
>> Provides: node-ta, node-tb
>> ?
> 
> I think there should not be Provides as it implies sharing, which will
> negate the reason why we are embedding in the first place.

Hello,

I updated https://wiki.debian.org/Javascript/GroupSourcesTutorial to
write a ~policy to choose to embed or not and to export or not. Please
review it

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-mongodb-core_3.1.0-1_amd64.changes REJECTED

2018-09-16 Thread Xavier
Le 16/09/2018 à 23:00, Thorsten Alteholz a écrit :
> 
> appears in REJECT-section of https://wiki.debian.org/Javascript/Nodejs/NEW

Hello,

thanks for our work, does this means that our embedding draft seems
acceptable for ftpmasters ?

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Draft to embed more than one Node module in a Debian package

2018-09-18 Thread Xavier
Le 14/09/2018 à 14:09, Yves-Alexis Perez a écrit :
> On Thu, 2018-09-13 at 11:59 +0200, Xavier wrote:
>> After a long discussion in JS team, I built a Wiki draft [2] and I would
>> like to have an opinion of Security Team before continuing in this way.
> 
> Hi Xavier,
> 
> could you elaborate on the precise impact for security updates? If I
> understand correctly, what you want is to ship multiple upstream sources in
> one Debian source package? Meaning a security issue in any one of the embedded
> source would mean shipping a DSA for the whole?
> 
> Regards,

Hi Yves-Alexis,

this is the goal of the little "policy": providing all packages using
"Provides:" will avoid having the same module embedded in more than one
package. So DSA will apply for only one package. If embedded module is
used only during tests, it can be omitted.


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Draft to embed more than one Node module in a Debian package

2018-09-18 Thread Xavier
Le 18/09/2018 à 21:08, Moritz Mühlenhoff a écrit :
> On Thu, Sep 13, 2018 at 11:59:20AM +0200, Xavier wrote:
>> Ref:
>>
>> Hi all,
>>
>> Ftpmasters want to reduce node packages in NEW queue [1]. Extract:
>>
>>   ...
>>
>> After a long discussion in JS team, I built a Wiki draft [2] and I would
>> like to have an opinion of Security Team before continuing in this way.
> 
> I see the general direction, but I think this won't fully solve the actual
> problems we're seeing with applications using nodejs modules.
> 
> We need to look at this from the view of the web applications to be packaged,
> not from the view of individual packages.
> 
> Dealing with the bundles on the packages level is only part of the problem,
> though. This can only be made manageable with additional policy/archive
> changes, basically what I outlined at
> https://lists.debian.org/debian-devel/2018/02/msg00354.html before.
> 
> So I'd encourage you to extend/generalise this (the same problem is also
> applicable to Ruby packages to some extent) so that it's ready for the
> buster release.
> 
> Cheers,
> Moritz

Hello Moritz,

thanks for this feedback. The JS policy could filter/accept packages if
they match one rule:
 - web app and its main dependencies (other embedded)
 - "driver": LDAP/SQL connectors,... especially if they are linked to a
   C library
 - main JS frameworks (bootstrap, vue.js, jQuery,...)

JS-Team / Ftpmasters: any advice on this ?

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-12 Thread Xavier
Le 12/09/2018 à 11:48, Bastien ROUCARIES a écrit :
> On Tue, Sep 11, 2018 at 7:16 PM Jérémy Lal  wrote:
>>
>> Hi Xavier,
>>
>> The example in Provides section should be written
>> Provides: node-ta, node-tb
>> ?
> 
> Provides MUST be versionned in order to get smooth upgrade if we split.

Updated, thanks

> Bastien
>>
>>
>> 2018-09-10 23:34 GMT+02:00 Xavier :
>>>
>>> Dear fellow maintainers,
>>>
>>> QA team accepted my changes, so now fakeupstream.cgi is able to handle
>>> npmjs multiple sources. I've written a draft here:
>>> https://wiki.debian.org/Javascript/GroupSourcesTutorial
>>>
>>> Please review it.
>>>
>>> Many thanks!
>>> Xavier
>>>
>>> --
>>> Pkg-javascript-devel mailing list
>>> Pkg-javascript-devel@alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>>
>>
>> --
>> Pkg-javascript-devel mailing list
>> Pkg-javascript-devel@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-11 Thread Xavier
Le 11/09/2018 à 19:15, Jérémy Lal a écrit :
> Hi Xavier,
> 
> The example in Provides section should be written
> Provides: node-ta, node-tb
> ?

Hi Jérémy,

updated, thanks !

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-11 Thread Xavier
Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
> 
> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>> Hi Xavier,
>>
>> The example in Provides section should be written
>> Provides: node-ta, node-tb
>> ?
> 
> I think there should not be Provides as it implies sharing, which will
> negate the reason why we are embedding in the first place.

Hello,

it depends: node-mongodb is provided in 4 packages from the same author,
same copyright,... Packages are maintained ~simultaneously by upstream
but components are dependencies of some other modules (specially
node-bson). I think in this case, it make sense to group sources: more
easy to maintain, reduce NEW queue,...

Thanks for this feedback.

Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-11 Thread Xavier
Le 11/09/2018 à 21:01, Xavier a écrit :
> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>
>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>> Hi Xavier,
>>>
>>> The example in Provides section should be written
>>> Provides: node-ta, node-tb
>>> ?
>>
>> I think there should not be Provides as it implies sharing, which will
>> negate the reason why we are embedding in the first place.
> 
> Hello,
> 
> it depends: node-mongodb is provided in 4 packages from the same author,
> same copyright,... Packages are maintained ~simultaneously by upstream
> but components are dependencies of some other modules (specially
> node-bson). I think in this case, it make sense to group sources: more
> easy to maintain, reduce NEW queue,...

Also it avoid multiples copy, this will be useful for Security Team

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] GroupSourcesTutorial page to review

2018-09-11 Thread Xavier
Le 11/09/2018 à 21:06, Xavier a écrit :
> Le 11/09/2018 à 21:01, Xavier a écrit :
>> Le 11/09/2018 à 19:48, Pirate Praveen a écrit :
>>>
>>> On 9/11/18 10:45 PM, Jérémy Lal wrote:
>>>> Hi Xavier,
>>>>
>>>> The example in Provides section should be written
>>>> Provides: node-ta, node-tb
>>>> ?
>>>
>>> I think there should not be Provides as it implies sharing, which will
>>> negate the reason why we are embedding in the first place.
>>
>> Hello,
>>
>> it depends: node-mongodb is provided in 4 packages from the same author,
>> same copyright,... Packages are maintained ~simultaneously by upstream
>> but components are dependencies of some other modules (specially
>> node-bson). I think in this case, it make sense to group sources: more
>> easy to maintain, reduce NEW queue,...
> 
> Also it avoid multiples copy, this will be useful for Security Team

I've just updated wiki to insert ~policy elements

NB: I'm not English native, don't hesitate to fix my mistakes ;-)



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-yarnpkg

2019-01-26 Thread Xavier
Le 26/01/2019 à 08:50, Paolo Greppi a écrit :
> Il 25/01/19 09:18, Paolo Greppi ha scritto:
>> Il 25/01/19 09:06, Xavier ha scritto:
>>> Le 25/01/2019 à 09:04, Xavier a écrit :
>>>
>>> Install also docs in the right place:
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/decode-uri-component/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/decode-uri-component/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/decode-uri-component/readme.md
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/hash-for-dep/README.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/is-gzip/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/is-gzip/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/is-gzip/readme.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/normalize-url/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/normalize-url/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/normalize-url/readme.md
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/CHANGELOG.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/LICENSE.md
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/LICENSE.md
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/npm-logical-tree/README.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/peek-stream/LICENSE
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/peek-stream/LICENSE
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/peek-stream/README.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/query-string/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/query-string/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/query-string/readme.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/strict-uri-encode/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/strict-uri-encode/license
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/strict-uri-encode/readme.md
>>> I: yarnpkg: extra-license-file
>>> usr/lib/nodejs/yarn/node_modules/tar-fs/LICENSE
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/tar-fs/LICENSE
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/tar-fs/README.md
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/v8-compile-cache/CHANGELOG.md
>>> I: yarnpkg: package-contains-documentation-outside-usr-share-doc
>>> usr/lib/nodejs/yarn/node_modules/v8-compile-cache/README.md
>>>
>>>
>>
>> Will do this afternoon,
>>
>> Paolo
> 
> Done ! RFS
> 
> Paolo

Pushed thanks!

I repaired also pristine-tar branch after repacking sources with valid
timestamps.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Testsuite proposal

2019-01-24 Thread Xavier
Le 25/01/2019 à 04:07, Pirate Praveen a écrit :
> 
> 
> On 2019, ജനുവരി 24 7:46:32 PM IST, Xavier  wrote:
>> Hi all,
>>
>> I try to write a package that could be called by autodep8 to have a
>> "Testsuite: pkg-js" instead of writing debian/tests/* files
>>
>> Skeleton is pushed in node-combined-stream branch "pkg-js"
>>
>> What maintainer has to do:
>> * in debian/control, insert "Testsuite: pkg-js"
>> * in debian/rules, insert a "include /path/to/test.mk", no need to
>>   write override_dh_auto_test
>> * write upstream test in debian/tests/pkg-js/test (will be launched by
>>   sh)
>> * if some other files than "test*" and installed files are needed,
>>   write a "debian/tests/pkg-js/files" with all needed files
>> * that's all, other debian/tests files will be written on-the-fly by
>>   autodep8 during autopkgtest
>>
>> How it will run:
>> - dh_auto_test will launch debian/tests/pkg-js/test if exists, else
>>   just a "require('.')"
>> - autopkgtest will launch 2 tests:
>>   - a `node -e "require('name')`
>>  - the test defined in debian/tests/pkg-js/test in a temporary dir (it
>> links installed files)
>>
>> You can test it in node-combined-stream branch "pkg-js"
>> (pkg-js-autopkgtest files are included in it)
>>
>> If this proposal is accepted, I will package pkg-js-autopkgtest project
>> and then propose a MR to autodep8.
>>
>> Cheers,
>> Xavier
>>
> 
> Thanks for working on it. I'll try to test it soon.

Thanks, see also node-sqlite3

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#925517: Bug#925517: Non-NSA/Microsoft upstream repo, new version

2019-03-26 Thread Xavier
Le 26/03/2019 à 17:53, Jeffrey Cliff a écrit :
> I don't use NSA/Microsoft github so I'll assume you mean to update the
> readme in the repo I control, which I have added a note to.  Is there
> anything in specific you are interested in my adding?
> 
> On Tue, 26 Mar 2019 at 07:17, Xavier  <mailto:y...@debian.org>> wrote:
> 
> Le 26/03/2019 à 08:07, Jeffrey Cliff a écrit :
> > Package: node-progress
> > Version: 1.1.8-1
> > Severity: normal
> >
> > As NSA/Microsoft has taken over Github, it is long since time to
> move to
> > a non-Microsoft source for projects like node-progress.  I have made a
> > non-microsoft repo at salsa
> > at https://salsa.debian.org/themusicgod1-guest/progress/ for use as a
> > future 'upstream' for this package.
> >
> > Also of note: the version of progress at the above repo is 2.0.0,
> which
> > is a newer version.  A diff can be made available if it is required. 
> >
> > Jeff Cliff
> 
> Hello,
> 
> could you also update
> https://github.com/visionmedia/node-progress#readme ?

There are some troubles here:
 * For now, you are not mentioned as node-progress contributor neither
   author
(https://github.com/visionmedia/node-progress/blob/master/package.json).
 * Github/npmjs version is 2.0.3 while yours is 2.0.0.
 * Following https://www.npmjs.com/package/progress, repo is
   https://github.com/visionmedia/node-progress.
 * There is de debian/ dir in your repo, why ?

So if you're upstream author, I suggest you to publish a 2.0.4 in
npmjs.com with new repo in your package.json, then we could safely
change debian/watch.

Debian package of node-progress is hosted on
https://salsa.debian.org/js-team/node-progress

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#925517: Bug#925517: Non-NSA/Microsoft upstream repo, new version

2019-03-26 Thread Xavier
Le 26/03/2019 à 19:04, Jeffrey Cliff a écrit :
> 2.0.0 was the version when Microsoft captured Github.  That's the newest
> one I have, but thankfully that's as new as is needed by the version of
> eslint in RFP.
> 
> I prefer to do my contributions anonymously.  I am not the author.
> 
>> Following https://www.npmjs.com/package/progress, repo is
> https://github.com/visionmedia/node-progress.
> 
> Indeed, it does go to NSA/Microsoft's walled garden.
> 
>> There is de debian/ dir in your repo, why ?
> 
> I can remove that

>> So if you're upstream author, I suggest you to publish a 2.0.4 in
>> npmjs.com with new repo in your package.json, then we could safely
>> change debian/watch.

I won't update anything unless you publish a new version accepted by
npmjs.com: it will prove that you've some rights on node-progress.

Debian can't accept an hostile takeover. If you're not upstream, you can
publish your fork under another name.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#925517: Bug#925517: Non-NSA/Microsoft upstream repo, new version

2019-03-26 Thread Xavier
Le 26/03/2019 à 20:17, Jeffrey Cliff a écrit :
> As maintainer, that's up to you, but I do not accept any project hosted
> in the NSA/Microsoft walled garden as the legitimate upstream of
> anything and I will continue to host 'progress', in particular,
> somewhere, until a 2.0.0+ version is available in some other upstream place.

So I recommend you to no more use Debian since many packages come from
GitHub. Anyway, publishing a fork of a software without changing its
name isn't a good thing and may be invalid. Please host this somewhere else.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Giuseppe Pereira Interesting to join js-team

2019-03-26 Thread Xavier
Le 21/03/2019 à 01:28, Giuseppe M. Pereira a écrit :
> Dear js-team,
> 
> My name is Giuseppe Pereira and I'm NodeJS Software Architect in Brazil.
> I'm contacting you to apply for join on js-team and collaborate to
> Debian community.
> 
> 
> How may I proceed?

Hello,

join us on https://salsa.debian.org/js-team and read our docs:
 * https://wiki.debian.org/Javascript
 * https://wiki.debian.org/Javascript/Tutorial

Cheers,
Xavier

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-yamljs updated

2019-03-30 Thread Xavier
Hello,

I updated node-yamljs, please check my changes to see if all is OK and
ready to push.

Following our policy, source package should be renamed yamljs.js
(provides node-yamljs and libjs-yamljs).

Cheers,
Xavier

https://salsa.debian.org/js-team/node-yamljs

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-yamljs updated

2019-03-30 Thread Xavier
Le 30/03/2019 à 12:39, Xavier a écrit :
> Hello,
> 
> I updated node-yamljs, please check my changes to see if all is OK and
> ready to push.
> 
> Following our policy, source package should be renamed yamljs.js
> (provides node-yamljs and libjs-yamljs).
> 
> Cheers,
> Xavier
> 
> https://salsa.debian.org/js-team/node-yamljs

Renamed to https://salsa.debian.org/js-team/yamljs.js

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Request for review: src:node-ansi-up

2019-04-01 Thread Xavier
Le 01/04/2019 à 12:09, Dmitry Bogatov a écrit :
> 
> Hello!
> 
> Could someone please review js-team/node-ansi-up package?

Hello,

take a look at my changes:

> Following is done:
> 
>  * upstream tarball is repacked to exclude examples with missing
>sources and pre-built js file (source file is typescript, I believe)

upstream branch was not up-to-date (and tag was missing). Done

>  * lintian is happy

Now yes ;-) [except one lintian bug: dversionmazngle=auto is not yet
recognize, I'm going to fill a MR for that]

debian/watch and debian/copyright needed an update

>  * upstream tests pass

Modified to use pkg-js-tools and so enable upstream test in autopkgtest

>  * debian/tests/require is successful

Removed and replaced by pkg-js-tools/pkg-js-autopkgtest

It looks good now for me

Cheers,
Xavier

> What is not done:
> 
>  * I do not know, how to verify that browser version works.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#926616: Bug#926616: CVE-2018-3750: Prototype Pollution

2019-04-08 Thread Xavier
Control: tags -1 + security

Le 08/04/2019 à 00:22, Jeff Cliff a écrit :
> Package: node-deep-extend
> Version: 0.4.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> As per the ubuntu bug report: 
> 
> from https://snyk.io/vuln/npm:deep-extend:20180409 :
> 
> deep-extend "all the listed modules can be tricked into modifying the 
> prototype of "Object" 
> when the attacker control part of the structure passed to these function."
> 
> This is verifiably true on at least buster, given the PoC listed in the above 
> URL, but
> since it's the same deep-extend in sid, it's probably the same there.
> 
> The following commit apparently fixes this: (though I haven't verified that)
> 
> https://github.com/unclechu/node-deep-extend/commit/433ee51ed606f4e1867ece57b6ff5a47bebb492f

Hello,

this issue is referenced here in
https://security-tracker.debian.org/tracker/CVE-2018-3750 and marked as
"unimportant"

The commit that fix this is:
https://github.com/unclechu/node-deep-extend/commit/9423fae877e2ab6b4aecc4db79a0ed63039d4703

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#926616: Fwd: Bug#926650 closed by Ivo De Decker (unblock node-deep-extend)

2019-04-08 Thread Xavier
node-deep-extend 0.4.1-2 is unblocked


 Message transféré 
Sujet : Bug#926650 closed by Ivo De Decker 
(unblock node-deep-extend)
Date : Mon, 08 Apr 2019 14:36:04 +
De : Debian Bug Tracking System 
Répondre à : 926...@bugs.debian.org
Pour : Xavier Guimard 

This is an automatic notification regarding your Bug report
which was filed against the release.debian.org package:

#926650: unblock: node-deep-extend/0.4.1-2

It has been closed by Ivo De Decker .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Ivo De Decker
 by
replying to this email.


-- 
926650: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926650
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

--- Begin Message ---
Unblocked node-deep-extend.
--- End Message ---
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-deep-extend

Hi all,

node-deep-extend is vulnerable to CVE-2018-3750 [1]. This vulnerability
has been tagged as unimportant, however patch is simple and package is
outdated (VCS fields, bad section, bad copyright years) and upstream tests
were not enabled. I fixed this in version 0.4.1-2. Here is the full changes:

  * Add patch to prevent Object prototype pollution
(Closes: #926616, CVE-2018-3750)
  * Enable upstream tests using pkg-js-tools
  * Fix VCS fields
  * Fix debian/copyright years
  * Add upstream/metadata
  * Change section to javascript

node-deep-extend has no build reverse dependencies.

Reverse dependencies:
  node-rc
node-registry-url & node-registry-auth-token
  node-package-json
node-latest-version
  npm
  npm2deb
node-pre-gyp
  node-sqlite3
node-mbtiles
node-tilejson
node-millstone
  node-zipfile
node-millstone
  node-mapnik
node-tilelive-bridge
node-tilelive-vector
node-tilelive-mapnik
  node-opencv

Since patch seems to have no consequences on normal node-deep-extend
usage, I think it is low risky to unblock node-deep-extend.
Patch comes from
https://github.com/unclechu/node-deep-extend/commit/9423fae877e2ab6b4aecc4db79a0ed63039d4703
(I just taked the useful part of it).

Cheers,
Xavier

[1]: https://security-tracker.debian.org/tracker/CVE-2018-3750

unblock node-deep-extend/0.4.1-2

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 5b0e688..e4e0c2e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,18 @@
+node-deep-extend (0.4.1-2) unstable; urgency=medium
+
+  * Team upload
+  * Add patch to prevent Object prototype pollution
+(Closes: #926616, CVE-2018-3750)
+  * Enable upstream tests using pkg-js-tools
+  * Fix VCS fields
+  * Fix debian/copyright years
+  * Add upstream/metadata
+  * Change section to javascript
+
+ -- Xavier Guimard   Mon, 08 Apr 2019 14:52:06 +0200
+
 node-deep-extend (0.4.1-1) unstable; urgency=medium
 
-  * Initial release 
+  * Initial release
 
  -- Thorsten Alteholz   Mon, 22 Feb 2016 18:16:21 +0100
-
diff --git a/debian/control b/debian/control
index 72892ea..4db1cb8 100644
--- a/debian/control
+++ b/debian/control
@@ -1,22 +1,24 @@
 Source: node-deep-extend
-Section: web
-Priority: optional
 Maintainer: Debian Javascript Maintainers 

 Uploaders: Thorsten Alteholz 
-Build-Depends:
- debhelper (>= 9)
- , dh-buildinfo
- , nodejs
-Standards-Version: 3.9.7
+Section: javascript
+Testsuite: autopkgtest-pkg-nodejs
+Priority: optional
+Build-Depends: debhelper (>= 9),
+   dh-buildinfo,
+   mocha,
+   nodejs,
+   node-should,
+   pkg-js-tools
+Standards-Version: 4.3.0
+Vcs-Browser: https://salsa.debian.org/js-team/node-deep-extend
+Vcs-Git: https://salsa.debian.org/js-team/node-deep-extend.git
 Homepage: https://github.com/unclechu/node-deep-extend
-Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-deep-extend.git
-Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=pkg-javascript/node-deep-extend.git
 
 Package: node-deep-extend
 Architecture: all
-Depends:
- ${misc:Depends}
- , nodejs
+Depends: ${misc:Depends},
+ nodejs
 Description: Recursive object extending
  This module does a recursive object extending.
  .
diff --git a/debian/copyright b/debian/copyright
index 28c1d90..a1f8541 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -

Re: [Pkg-javascript-devel] RC bugs

2019-02-18 Thread Xavier
Le 19/02/2019 à 07:40, Pirate Praveen a écrit :
> 
> On Tue, Feb 19, 2019 at 2:50 AM, Xavier  wrote:
>> Le 18/02/2019 à 21:20, Xavier a écrit :
>>>  Le 18/02/2019 à 20:46, Bastien ROUCARIES a écrit :
>>>>
>>>>  Le lun. 18 févr. 2019 à 19:17, Xavier >>>  <mailto:x.guim...@free.fr>> a écrit :
>>>>
>>>>  Le 18/02/2019 à 17:46, Pirate Praveen a écrit :
>>>>  >
>>>>  >
>>>>  > On Thu, Feb 14, 2019 at 10:50 PM, Xavier >>>  <mailto:y...@debian.org>> wrote:
>>>>  >>  - node-mocha: #921798: FTBFS (Module not found: Error:
>>>> Recursion in
>>>>  >>    resolving)
>>>>  >
>>>>  > I tried to use rollup instead of webpack (in rollup branch),
>>>> it builds
>>>>  > fine, but will not work in a browser (should be enough for
>>>> node).
>>>>  If we
>>>>  > cannot fix thr rc bug, I suggest we drop the browser support for
>>>>  now and
>>>>  > only target node.
>>>>
>>>>  I fully agree. If no one finds this bad, I'll upload node-mocha
>>>> this
>>>>  evening.
>>>>
>>>>  I find this bad. Why webpack break ? Do we have an idea ?
>>>>
>>>>  Bastien
>>>
>>>  No idea after a long search. I pushed a temporary version without
>>>  libjs-mocha for now to close RC bug. If we find the problem, we could
>>>  restore libjs-mocha.
>>
>> Works with a more recent version of webpack
> 
> Updating webpack is not an option for buster, need babel 7 and which
> need gulp 4.

Yes of course, but it explains that pb is a webpack issue, not a
webpack.conf one

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

  1   2   3   4   5   >