[Pkg-javascript-devel] node-handlebars is marked for autoremoval from testing

[Debian testing autoremoval watch]

node-handlebars 3:4.0.10-5 is marked for autoremoval from testing on 2018-03-21

It (build-)depends on packages with these RC bugs:
874420: node-babel-cli: /usr/bin/babel is already provided by openbabel
877220: node-babel: B-D npm not available in testing


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

[Pkg-javascript-devel] node-webpack_3.5.6-2_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 03 Mar 2018 01:17:02 +0530
Source: node-webpack
Binary: webpack
Architecture: source
Version: 3.5.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Pirate Praveen 
Description:
 webpack- Packs CommonJs/AMD modules for the browser
Changes:
 node-webpack (3.5.6-2) unstable; urgency=medium
 .
   * Fix package name in autopkgtest
   * Exclude test/Compiler.test.js to avoid hangs
   * Enable upstream tests as autopkgtests
   * Bump standards version to 4.1.3 and debhelper compat to 11
Checksums-Sha1:
 003ad037a52661ca69b66eaa4031dd3ad01fb9a0 2697 node-webpack_3.5.6-2.dsc
 a00707b3e3f5bdf876cf5fcb473c6988ab359662 3048 
node-webpack_3.5.6-2.debian.tar.xz
 eb63acb821b63db2324df8bd9863438a15251407 14480 
node-webpack_3.5.6-2_source.buildinfo
Checksums-Sha256:
 3c75a27a8c1e6a36ef17df415f2046b5f0c1a93188eceb7337a421346a4a60ce 2697 
node-webpack_3.5.6-2.dsc
 63ce706a97f786f936e768c39f811c8bdb701b4fe067040bdce348a05cb2ec7a 3048 
node-webpack_3.5.6-2.debian.tar.xz
 fd013eabadf923ab6bd3971e02d51da121476ac2b312ac678a34849e9c57e2da 14480 
node-webpack_3.5.6-2_source.buildinfo
Files:
 09e4cbbec9364b96b63924517101ad82 2697 javascript optional 
node-webpack_3.5.6-2.dsc
 3e1f6f0c32c2b329b6eea2aa89a75b7b 3048 javascript optional 
node-webpack_3.5.6-2.debian.tar.xz
 fd7f4f6f990bfcb07b5d82bc6c86b85d 14480 javascript optional 
node-webpack_3.5.6-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEKnl0ri/BUtd4Z9pKzh+cZ0USwioFAlqZrBkACgkQzh+cZ0US
wiqLug/8DTGcrS4fRhL73x3Y4QdQ1pIhuv42r46jTljwJPnXsclfSOKHbwWC3FF8
VKxdkwGqXfq+tacI55NDEQInA/r3bcIXaGE42kLFDqDhkGGOiqg+IlKmeFlGrKcU
XDXjmH0Tgcb2lzFy4iHBR+v9dPwz6FOeaOwD3+jBa7e7boMqgP9JKnuMBW23uUwy
zCh5bOHUHR/2Yftnyp6611v5BEKSPoRppzUmJop1Io064ooURrhDU/XwxGb4SxhP
yVxfLbOED/yLuujC8QEzcPZ0HV9Id3j2GYQkHT01R7P6vvq0gzP4IB2l7pNEseoB
A0/sImXoMtM+2rA1XISIjY8jZuxjtkRd0fgMcoxR5u/+hsThcXjzJLhSQGCauGh9
UiwISF8xP7TPz328oggCTBurTHhx3TWsVrrYaeqfeiS1ObUSWmdNUhZIeIlqIE+5
sPLFBz2ibvLefdow8Y3IReD0OKs3MhN4zqPWSm4iWsCgHVLZbEjcTI/5OOJViaNN
X69o6E4JVYWXZPOX3meu8GMGBSiSTg6+PTL+X6Q/N/HfuOES85W1B3JZpkrPSPtC
YoGlQuJiiXbxCkvBaK1bI6wBwssKBiwCECi5LZ8Q6GkjRIaFqqz7HaAhbMOQY3oz
fswAipWNnVYqa5MCmCC4v8kV4j0XHP70/OdpisAxjYLYQSzTkhQ=
=SZRJ
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

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

[Pkg-javascript-devel] Processing of node-webpack_3.5.6-2_source.changes

[Debian FTP Masters]

node-webpack_3.5.6-2_source.changes uploaded successfully to localhost
along with the files:
  node-webpack_3.5.6-2.dsc
  node-webpack_3.5.6-2.debian.tar.xz
  node-webpack_3.5.6-2_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

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

[Pkg-javascript-devel] Processed: Re: Bug#887586: node-chokidar: build hangs with mocha 4.0.1-3

[Debian Bug Tracking System]

Processing control commands:

> affects -1 -src:node-webpack
Bug #887586 [mocha] mocha 4.0.1-3 causes build hangs in various build-rdeps
Removed indication that 887586 affects src:node-webpack

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

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

[Pkg-javascript-devel] Bug#887586: node-chokidar: build hangs with mocha 4.0.1-3

[Pirate Praveen]

Control: affects -1 -src:node-webpack

On Sun, 4 Feb 2018 17:32:36 +0200 Adrian Bunk  wrote:>
This is actually an issue that seems to affect more build-rdeps of mocha
> (build logs are in the reproducible builds of the affected packages).

test/Compiler.test.js was hanging in case of webpack, it has been
skipped for now (many other tests are also skipped, so it will need a
deeper look anyway to get full test coverage). Also since it was working
with mocha 3, it can't be a webpack issue.



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

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Sean Whitton]

Hello,

On Fri, Mar 02 2018, Pirate Praveen wrote:

> I think the policy is good and request debian policy team to endorse
> it.

The way forward is to add the JavaScript policy to the debian-policy
package.  It would not be wise to add a single requirement to our
document, with the rest of the JavaScript policy maintained elsewhere.

Note that this does require that the JavaScript policy is no longer
"work in progress" (quoting the wiki page you reference).  The reason
for this is that the process for making changes will become much longer
than editing a wiki page (requiring seconds etc.), so we would want to
ensure the policy is more complete than it is now.

If you want to go ahead and do this, please file a bug against
debian-policy, with a patch that adds the JavaScript policy to our repo.
(There wouldn't be much point in filing such a bug without a patch.)

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Jonas Smedegaard]

Quoting Pirate Praveen (2018-03-02 15:26:40)
> Javascript maintainers team have evolved a policy for javascript 
> packages and it is available at 
> https://wiki.debian.org/Javascript/Policy
> 
> Its last point says,
> 5. should generate a node-foo binary package if the script is usable
> also for Nodejs

I generally read team policies with an implicit "...as long as it 
doesn't conflict with the general Debian Policy".

Specifically, I read the "should" in above quote as "in most cases, but 
not a "must".

We have in the Javascript team an old practice of avoiding duplicate 
code: When code is same for Browsers and Nodejs, we ship the code in the 
libjs-* package and have that package "Provides: " the nodejs package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Pirate Praveen]

On വെള്ളി 02 മാർച്ച് 2018 04:38 വൈകു, Ian Jackson wrote:
> This is the first I'd heard of this being a policy question.  How
> about you discuss the team policy and the reasons behind it on
> d-policy CC the javascript list.  If you wish to retain the policy,
> but ftpmaster disagree with it, you can escalate the policy question
> to the TC.
> 
> The TC are empowered to "Decide on any matter of technical policy".
> If the TC endorse your policy then I don't doubt that ftpmaster will
> stop rejecting packages for complying with it.
> 
> Ian.
> 

Thanks for the suggestion, I have started a thread in d-policy.



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

[Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

[As suggested by Ian Jackson on -devel] [0]

Hi,

Javascript maintainers team have evolved a policy for javascript
packages and it is available at https://wiki.debian.org/Javascript/Policy

Its last point says,
5. should generate a node-foo binary package if the script is usable
also for Nodejs

But ftp masters rejected the last upload [1] which added node-three
binary package to three.js source package. There was also a similar
demand earlier about handlebars package [2] but was accepted by another
ftp master. I think the policy is good and request debian policy team to
endorse it.

The advantages of creating different binary packages (hope others in the
team can add any points I missed):

1. Node.js has standard locations for discovering installed packages
which is different from browser targeted javascript libraries.

Node.js expects pure js modules to be installed at /usr/lib/nodejs but
javascript libraries are installed at /usr/share/javascript

2. Dependency on nodejs is required only during build or when other
Node.js modules depend on it. a browser targeted library does not need
to depend on nodejs package.

If you take example of node-handlebars source package, libjs-handlebars
is targeted at browsers and does not need to declare a dependency on
nodejs. But handlebars package need nodejs to run. If there is only a
single binary package, nodejs will get installed unnecessarily.

[0] https://lists.debian.org/debian-devel/2018/03/msg00063.html
[1]
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2018-February/025121.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837467#22



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

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Pirate Praveen]

On വെള്ളി 02 മാർച്ച് 2018 02:00 വൈകു, Joerg Jaspert wrote:
> But if you continously "run into the same wall", then it does not do any
> good to assume its that one person hating you and that, if you happen to
> get to another team member, they will like you. It's the wrong mindset.

This is based on my past experience with multiple packages where same
criteria was interpreted differently by different ftp masters (At least
3 cases I can quote 1. node-babel-preset-env was rejected but
node-rollup was accepted, both can't be bootstrapped without a binary
upload first. 2. I was asked to make a single handlebars package, by
waldi, but it was accepted by Chris 3. There was long discussion on
node-babel but it was easily resolved when another ftp master was involved).

> Also, possibly we should adjust our communications here, at least get
> others to respond/jump in (earlier). Not sure we need it so much formal
> as Ian wrote down, but get someone else in early shouldn't hurt.
>
Thanks.



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

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Ian Jackson]

Pirate Praveen writes ("Re: [Pkg-javascript-devel] 
three.js_80+dfsg2-2_amd64.changes REJECTED"):
> So in this specific case, I will add these files to libjs-three. I think
> ftp masters don't want to distinguish between browser environment and
> node environment, but just have one package. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837467#22 for a
> previous instance of this demand. I think arbitrarily reducing the
> number of binary packages is more important than following JavaScript
> team policy https://wiki.debian.org/Javascript/Policy which says "should
> generate a node-foo binary package if the script is usable also for Nodejs".
> 
> I also propose we abandon the current Javascript team policy because it
> is not supposed to be followed. Just have one binary package for every
> source package irrespective of it is useful for node or browser.

This is the first I'd heard of this being a policy question.  How
about you discuss the team policy and the reasons behind it on
d-policy CC the javascript list.  If you wish to retain the policy,
but ftpmaster disagree with it, you can escalate the policy question
to the TC.

The TC are empowered to "Decide on any matter of technical policy".
If the TC endorse your policy then I don't doubt that ftpmaster will
stop rejecting packages for complying with it.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

[Pkg-javascript-devel] Bug#891899: node-rollup: please make the build reproducible

[Chris Lamb]

forwarded 891899 https://github.com/rollup/rollup/pull/2024
thanks

I've forwarded this upstream here:

  https://github.com/rollup/rollup/pull/2024


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

[Pkg-javascript-devel] Processed: Re: node-rollup: please make the build reproducible

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 891899 https://github.com/rollup/rollup/pull/2024
Bug #891899 [src:node-rollup] node-rollup: please make the build reproducible
Set Bug forwarded-to-address to 'https://github.com/rollup/rollup/pull/2024'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
891899: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891899
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Pkg-javascript-devel] Bug#891899: node-rollup: please make the build reproducible

[Chris Lamb]

Source: node-rollup
Version: 0.50.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that node-rollup could not be built reproducibly as it encodes
the current build time via "new Date()".

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0001-reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0001-reproducible-build.patch  2018-03-02 
09:41:49.392154726 +
@@ -0,0 +1,19 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-03-02
+
+--- node-rollup-0.50.0.orig/rollup.config.js
 node-rollup-0.50.0/rollup.config.js
+@@ -14,9 +14,11 @@ const commitHash = (function() {
+   }
+ })();
+ 
++const now = new Date(process.env.SOURCE_DATE_EPOCH ? 
(process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime());
++
+ const banner = readFileSync('src/banner.js', 'utf-8')
+   .replace('${version}', pkg.version)
+-  .replace('${time}', new Date())
++  .replace('${time}', now.toUTCString())
+   .replace('${commitHash}', commitHash);
+ 
+ export default [
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2018-03-02 09:20:55.357126507 +
@@ -0,0 +1 @@
+0001-reproducible-build.patch
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] node-has_1.0.1-1_amd64.changes REJECTED

[Joerg Jaspert]

On 14959 March 1977, Pirate Praveen wrote:
 8 node modules (all of them dependencies of gitlab) depend on this
 module (colormin, cssnano, eslint-import-resolver-webpack,
 eslint-plugin-import, postcss-merge-idents, postcss-minify-selectors,
 postcss-reduce-transforms, postcss-zindex). Do you think duplicating
 this code 8 times or maintaining 8 patches are better approach than this?
>> For one line code: yes.  You can never change this one line anyway.
> I'd like to ask other ftp masters if they agree with this assessment.
> How do we know for sure we will never have to change this line? Even if
> I agree this need not be changed, is having duplicated work 8 times
> still better compromise?

Duplicate of one line? Yes.

Leaving out the insanity of ways that node goes with its design of
idiotically small modules for things, lets consider what it means in
Debian terms:

A one line, no matter if its 20 or 1000 characters long, needs a
package. Upstream with license, readme, maybe tests, in Debian then with
all the stuff in debian/, most files larger than the actual code.
Then you end up with the .deb. Now that and the source get onto mirrors.
And into all packages files, blowing them up. And needing to be
processed in all the various locations all over.

So we have 114 bytes of code and 50 to a hundred times that size of
metadata, on every mirror. And one more stanza in the packages file to
parse for every tool, yet more data and time at totally unrelated
places.

Thats why we ended up long ago to deny small packages. Yes, most of node
is small, so we really dislike it, but if its at least a bit more than a
line, we grudgingly accepted it. (Also, actually most of node is unfit
for packaging, neither is the nodejs system made to be packaged, nor is
Debian made to handle this stuff).


I think reject faq needs to make it more clear on size, currently its
included in "Package split". I'm unsure what a good value is for minimum
size. It can't be one value. But 114bytes of source? I'm with
Bastian/Chris here.

-- 
bye, Joerg

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

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Joerg Jaspert]

On 14963 March 1977, Pirate Praveen wrote:

>> I wonder why you think "a single ftpmaster". We are a team. We closely
>> coordinate what we do and how we do it. When one of us rejects, the team
>> rejects - it just happens to be a random one of us doing it. Others do
>> not need to get involved and review everything. Or we wouldn't ever be
>> able to get anything done if each of us always has to weight in on any
>> single issue.
> Thanks for the clarification. I was thinking about it more like how the
> courts work in India (possibly in other countries too). When a single
> judge decides on a case, there is always an option to appeal to larger
> bench (more number of judges).

Right.

> The team as a whole has to weigh in only when the decision of a single
> team member is challenged and such a review is requested.

> I don't think it is healthy to not have an option of reviewing
> individual members decisions.
>
> That leaves me only GR as a possible escalation route. I will think
> about it.

And no, I didnt say one can not ever challenge a reject, although one
can put that meaning in my words, sorry for that. Quite the contrary,
despite other rumours, we are all just humans, and humans make mistakes.
And we are open to be told about such and do admit them, and yes, that
does happen.

But if you continously "run into the same wall", then it does not do any
good to assume its that one person hating you and that, if you happen to
get to another team member, they will like you. It's the wrong mindset.

Also, possibly we should adjust our communications here, at least get
others to respond/jump in (earlier). Not sure we need it so much formal
as Ian wrote down, but get someone else in early shouldn't hurt.

-- 
bye, Joerg

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