Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Vincent Bernat  writes:

> [ Unknown signature status ]
>  ❦ 18 octobre 2016 23:01 +0200, Florian Weimer  :
>
 I think it's clear that the TC believes that this package is not DFSG
 free.
 I think it's clear that the TC believes perl would be better if the
 situation was improved.
 I thought it was clear we believed perl had a DFSG issue, although IRC
 discussion today makes that less clear.
 I don't think the value of having the TC formally say any of those
 specific things is very high.
...
>>>
>>> Please describe the relevant differences between browserified javascript 
>>> and perl that make the TC believe that the former has a DFSG issue but 
>>> the latter probably has not, in a way that I can deduct what the TC 
>>> would believe regarding the similiar problem related to SQLite.
>>
>> Configure in Perl is a build tool, and appears amenable to manual
>> patching.
>>
>> Browserified Javascript is hardly human-editable, and it is shipped as
>> part of built packages.
>
> I don't think this is the debate. The debate is around pre-minified
> versions. Those versions are also human-editable and amenable to manual
> patching.

I dispute that there was anything like a useful debate, because all
attempts to discover what "browserified" is supposed to mean have been
ignored.  Despite that, this is still the term that continues to be used
to pose the question.

There may have been the appearance of a debate in the TC, but from my
point of view that was mostly pondering what conceivable meaning
"browserified" could have that might lead to one thinking that posing
these questions made any sense whatsoever.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Vincent Bernat]

 ❦ 18 octobre 2016 23:01 +0200, Florian Weimer  :

>>> I think it's clear that the TC believes that this package is not DFSG
>>> free.
>>> I think it's clear that the TC believes perl would be better if the
>>> situation was improved.
>>> I thought it was clear we believed perl had a DFSG issue, although IRC
>>> discussion today makes that less clear.
>>> I don't think the value of having the TC formally say any of those
>>> specific things is very high.
>>>...
>>
>> Please describe the relevant differences between browserified javascript 
>> and perl that make the TC believe that the former has a DFSG issue but 
>> the latter probably has not, in a way that I can deduct what the TC 
>> would believe regarding the similiar problem related to SQLite.
>
> Configure in Perl is a build tool, and appears amenable to manual
> patching.
>
> Browserified Javascript is hardly human-editable, and it is shipped as
> part of built packages.

I don't think this is the debate. The debate is around pre-minified
versions. Those versions are also human-editable and amenable to manual
patching.
-- 
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Florian Weimer]

* Adrian Bunk:

> On Wed, Oct 05, 2016 at 10:00:53AM -0400, Sam Hartman wrote:
>>...
>> I think it's clear that the TC believes that this package is not DFSG
>> free.
>> I think it's clear that the TC believes perl would be better if the
>> situation was improved.
>> I thought it was clear we believed perl had a DFSG issue, although IRC
>> discussion today makes that less clear.
>> I don't think the value of having the TC formally say any of those
>> specific things is very high.
>>...
>
> Please describe the relevant differences between browserified javascript 
> and perl that make the TC believe that the former has a DFSG issue but 
> the latter probably has not, in a way that I can deduct what the TC 
> would believe regarding the similiar problem related to SQLite.

Configure in Perl is a build tool, and appears amenable to manual
patching.

Browserified Javascript is hardly human-editable, and it is shipped as
part of built packages.  These scripts need regular maintenance, and
patching what is in Debian directly is too cumbersome.  I can't quite
understand why there is any debate that shipping these artifacts
without sources which are built at build time is in any way desirable.
If we don't build from source, how we are supposed to fix bugs?

(Pre-compiled C files from Vala sources have the same issue, I think.
Ocaml's bootstrapping from pre-compiled bytecode is slightly
different.)

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

"Joseph R. Justice"  writes:

> To all: Should Mr's Raboud's request for interpretation be expanded to
> include clarification on whether, and if so when and how, the TC can
> require some other delegate to take a particular action or actions,

This mail seems to be prompted by a series of seriously flawed assumptions:

  That one can force volunteers to do anything.

  That anyone on the TC would be foolish enough to try and tell any
  volunteer that they must do something that they are unwilling to do.

  That if we had more powers, and for some bizarre reason were willing
  to use them, that there is any chance of obtaining a 2/3 majority in
  favour of forcing source-less, buildtool-less packages into 'main'.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] "Joseph R. Justice" 

> For the record for this bug / discussion:
> 
> I note Didier 'OdyX' Raboud 's mail to the Debian Secretary, CC'd to
> the TC list and the FTP Master list, requesting a general
> interpretation of the TC's ability (if any) to override the decisions
> made by various Debian delegate teams and individuals.  A copy of the
> mail can be found at
> https://lists.debian.org/debian-ctte/2016/10/msg00060.html .  If the
> request had been made as a bug filed to the bug tracking system,
> perhaps to a "secretary" meta-package, I'd have suggested this bug be
> blocked by that bug.

As noted in OdyX' mail, we think it's quite unlikely that we'd like to
override the ftpmasters in this case, so 839570 isn't blocked on that
response (at least not until we go «yes, we want to override, can we?»).

> I realize that the idea of the TC overriding a delegate's decision
> *can* be interpreted to include this sort of thing, too.  However, I
> do not know if it is sufficiently obvious that such an interpretation
> should be made (the obvious counter-question is "How can the TC
> override a decision which has not yet been made, or which has not yet
> been requested to be made, or which perhaps is not a request-able
> decision in the first place (e.g. that there is no procedure in place
> to request that such a decision be made)?").

We (as in Debian, not the CTTE in particular) don't need a formal
procedure for everything we do.  There's always the «send an email to
the team asking them to do something» default.  If you haven't even
asked the team to do something, asking the CTTE to overrule them would
be completely inappropriate.

I'd rather not spend needless energy on seeing just how much heavy
artillery we can bring to bear on various parts of the project.
Overriding developers is a very heavy-handed action (which is why it
requires a 3:1 majority) and even more so on core infrastructure teams
such as ftpmaster or the release team.  It's much more likely that we
can get the end result we're after by mediation or offering advice,
without anywhere near the same level of casualities.

The reason we asked for clarification from the secretary on this is so
we can reduce the amount of noise.  Not to conduct war games where we
see how we can make the most people upset with the shortest resolution.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

For the record for this bug / discussion:

I note Didier 'OdyX' Raboud 's mail to the Debian Secretary, CC'd to the TC
list and the FTP Master list, requesting a general interpretation of the
TC's ability (if any) to override the decisions made by various Debian
delegate teams and individuals.  A copy of the mail can be found at
https://lists.debian.org/debian-ctte/2016/10/msg00060.html .  If the
request had been made as a bug filed to the bug tracking system, perhaps to
a "secretary" meta-package, I'd have suggested this bug be blocked by that
bug.

(As an aside, perhaps there should be a wishlist bug to create such a
meta-package, for use in similar situations in the future?)

While the request for interpretation was clearly prompted by the discussion
in this bug (indeed, the request explicitly says as much!), it is phrased
to be very general in nature, which I personally think is a good idea.

I look forward to any discussion on that request for interpretation.  (I
suspect I'll have to subscribe to the secretary mailing list, if there is
one such, to make sure I see all of it.)



To all: Should Mr's Raboud's request for interpretation be expanded to
include clarification on whether, and if so when and how, the TC can
require some other delegate to take a particular action or actions, even if
the delegate has not made a decision (or perhaps even been asked to make a
decision) on the action?  (This, presumably if and only if the TC is
capable of overriding a delegate's decision in the first place; if the TC
cannot override a delegate's decision, it does not make sense then that
they could require a delegate to decide to take an action!)

The particular specific case here would be as to whether the TC can require
the release masters to add stretch-ignore tags either to bugs for
individual packages affected by the "browserified Javascript" issue
(whatever it is determined that "browserified Javascript" is ultimately
defined to mean; in particular, I am *not* claiming at this time that the
definition of browserified Javascript does include or should include
packages affected by the includes generated lexer/parser code / jison (?)
issue) and/or for all bugs which fall under this issue (e.g. bugs which are
determined to block a meta-bug "resolution of browserified Javascript"
issue and/or which are determined to be blocked by a "ITP: grunt" or "IT
Create and Package: sufficiently capable replacement for grunt" bug.

I realize that the idea of the TC overriding a delegate's decision *can* be
interpreted to include this sort of thing, too.  However, I do not know if
it is sufficiently obvious that such an interpretation should be made (the
obvious counter-question is "How can the TC override a decision which has
not yet been made, or which has not yet been requested to be made, or which
perhaps is not a request-able decision in the first place (e.g. that there
is no procedure in place to request that such a decision be made)?").

I am tempted to write the secretary to request just such an expanded
consideration of Mr. Raboud's request.  However, before I do so, I think it
is prudent to seek the counsel of older and wiser heads as to whether or
not this is a good idea or if it will instead just confuse things and muddy
the waters.

So...  What, if anything, do all'y'all think?



Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Bdale Garbee]

Adrian Bunk  writes:

> Only DFSG-free packages that depend on non-free software are allowed 
> in contrib.

At Debconf in Heidelberg, this definition was tweaked somewhat by
inspiration of the sitting DPL in light of the ZFS discussion to include
software which itself is free, but the use of which is unlikely to be
possible without creating an unredistributable result in combination
with other DFSG-free but license incompatible packages.  So it's not
strictly necessary for there to be a dependence on non-free software to
push something to contrib.

Bdale


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Adrian Bunk  writes:

> On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote:
>>  ❦  5 octobre 2016 22:49 CEST, Philip Hands  :
>> 
>> > If you fancy explaining what you think browserified means w.r.t. the
>> > Jison stuff, go ahead of course.  That might at least help to focus the
>> > discussion a bit.  Just don't feel obliged to because I said so.
>> 
>> The libjs-handlebars issue has little to share with browserified
>> JS. Browserified JS is usually just concatenated JS. Here, there is an
>> equivalent of flex/bison involved. That's quite unusual and is more a
>> build process. If the TC rules over this issue, it should drop the
>> "browserified" part. Otherwise, a negative answer would also apply to
>> more basic packages.
>>...
>
> Why is Grunt such a blocker here?
>
> If I understand it correctly, Grunt is a powerful build system that can 
> do a gazillion different things and has many dependencies.
>
> For the basic browserified JS case, could a much simpler tool like
> node-browserify-lite produce the same output?

Sadly, it seems that's not as simple as one would hope -- see:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814871

and the referenced:

  https://gitlab.com/gitlab-org/gitlab-ce/issues/14450

which seem to illustrate the tangled mess we're talking about.

BTW I must applaud Praveen's tenacity, as exhibited in these bug logs,
while getting this stuff packaged, and I do understand that it must be
really frustrating to have been swimming upstream against this for so
long only for the result to still be deemed unfit for main.

That said, I think they really are unfit for 'main' at present. :-/

(in no small part because of the fragility that is highlighted by that
upstream bug log -- if we are not able to lock down the versions of all
the packages and tools in question, by packaging them, how is this sort
of thing ever going to be brought to a point of sanity?)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Vincent Bernat]

 ❦  6 octobre 2016 20:47 CEST, Adrian Bunk  :

>> > If you fancy explaining what you think browserified means w.r.t. the
>> > Jison stuff, go ahead of course.  That might at least help to focus the
>> > discussion a bit.  Just don't feel obliged to because I said so.
>> 
>> The libjs-handlebars issue has little to share with browserified
>> JS. Browserified JS is usually just concatenated JS. Here, there is an
>> equivalent of flex/bison involved. That's quite unusual and is more a
>> build process. If the TC rules over this issue, it should drop the
>> "browserified" part. Otherwise, a negative answer would also apply to
>> more basic packages.
>>...
>
> Why is Grunt such a blocker here?

I didn't mention Grunt because in this case, it is not really a
problem. Whatever Grunt got packaged or not doesn't change the situation
for libjs-handlebars. What this package needs is jison. Once jison is
here, this package becomes buildable from tools in main and can enter in
main (since there is a tolerance for pre-generated files).

> If I understand it correctly, Grunt is a powerful build system that can 
> do a gazillion different things and has many dependencies.

Yes.

> For the basic browserified JS case, could a much simpler tool like
> node-browserify-lite produce the same output?

I can't say.
-- 
AWAKE! FEAR! FIRE! FOES! AWAKE!
FEAR! FIRE! FOES!
AWAKE! AWAKE!
-- J. R. R. Tolkien


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote:
>  ❦  5 octobre 2016 22:49 CEST, Philip Hands  :
> 
> > If you fancy explaining what you think browserified means w.r.t. the
> > Jison stuff, go ahead of course.  That might at least help to focus the
> > discussion a bit.  Just don't feel obliged to because I said so.
> 
> The libjs-handlebars issue has little to share with browserified
> JS. Browserified JS is usually just concatenated JS. Here, there is an
> equivalent of flex/bison involved. That's quite unusual and is more a
> build process. If the TC rules over this issue, it should drop the
> "browserified" part. Otherwise, a negative answer would also apply to
> more basic packages.
>...

Why is Grunt such a blocker here?

If I understand it correctly, Grunt is a powerful build system that can 
do a gazillion different things and has many dependencies.

For the basic browserified JS case, could a much simpler tool like
node-browserify-lite produce the same output?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 07:48:28PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk 
> 
> > On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
> > >...
> > > I think it'd be preferable for the software to be in contrib (AFAIK
> > > there's nothing here which is non-free?)
> > >...
> > 
> > When a package is not DFSG-free it is non-free.
> > 
> > Only DFSG-free packages that depend on non-free software are allowed 
> > in contrib.
> 
> from policy 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.
> 
> […]
> 
> 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
> 
> That sound like a pretty good match for those Javascript packages that
> require grunt to build.


Where you placed the dots policy says:

 Every package in _contrib_ must comply with the DFSG.


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] Adrian Bunk 

> On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
> >...
> > I think it'd be preferable for the software to be in contrib (AFAIK
> > there's nothing here which is non-free?)
> >...
> 
> When a package is not DFSG-free it is non-free.
> 
> Only DFSG-free packages that depend on non-free software are allowed 
> in contrib.

from policy 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.

[…]

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

That sound like a pretty good match for those Javascript packages that
require grunt to build.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
>...
> I think it'd be preferable for the software to be in contrib (AFAIK
> there's nothing here which is non-free?)
>...

When a package is not DFSG-free it is non-free.

Only DFSG-free packages that depend on non-free software are allowed 
in contrib.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] "Joseph R. Justice" 

> I'll be honest, I assumed from what I've read that a decision had
> already been made by the FTP team against Mr. Praveen. I figured that
> it must have been, or else why would he be raising this bug with the
> TC now?

It's not clear that it has, which is one of the reasons why there are so
many questions asked.

> He's just hoping to avoid the stigma of having to be in contrib
> / non-free for the release of Debian Stretch, by seeking a variance
> that this issue is RC-buggy *for now* so that the various pieces of
> software can be in main, while he works on achieving that possible,
> preferable outcome during the preparation of Stretch+1 which will
> permanently resolve the issue of whether this issue is RB-buggy.)

I think it'd be preferable for the software to be in contrib (AFAIK
there's nothing here which is non-free?) until those pretty important
defects are worked out.  If that is a black mark on the software, it
might just as easily be seen as motivation for something to be fixed as
some sort of stigma.  I also disagree with implying that software in
contrib or non-free carries stigma with it.  It just means that it needs
software outside of Debian to build or function, or has a license that
is not DFSG free.

Trying to use the timing of this as some sort of leverage to get an
exception because it's too hard to get grunt packaged in time fills me
with little sympathy.  The initial bug was filed back in March (817092),
and did not receive a reply until July.  I'd also question that grunt is
so hard to package it takes more than six months to even get it into the
archive at all.

[...]

> I'm not a web developer. I have absolutely no idea how important these
> applications are in actual practice. They may have little use in the
> Real World. They may have tons of use. It may have strong adverse
> effects on users or potential users of Debian if these applications
> are not in Debian main; it may have little or no effect at all. In the
> worst possible case, potential users (be they individuals, or end user
> companies, or people selling software and services making use of
> Debian stable) maybe decide to use another distribution because they
> can't get what they want out of Debian stable main.

On the other hand, if we ship software we can't support and which has
freeness related problems, we might alienate existing or new users.
It's not at all clear that our users are served better by having this
software included.

[...]

> What advice, if any, does the TC have to offer Mr. Praveen as to how
> can he best achieve this goal, and what assistance if any can the TC
> offer him in terms of achieving it?

Frankly, I don't think it's very realistic to see all of this properly
resolved (including having toolchains uploaded, etc) before stretch
freezes, so my answer to your question would be 無, or at best just get
those packages into contrib and start on it immediately.  There's always
a next release.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] Joseph R. Justice

> Is there any information yet on what formal policy (if any) will be
> used by the release managers for allowing bugs to be tagged
> stretch-ignore? *Was* there any formal policy ever set in place for
> the prior (the current stable) release of Debian, e.g. Jessie, or
> prior to that Wheezy? Was it / will it be entirely ad-hoc and at the
> discretion of the release team?

I believe it's at the discretion of the release team, but they would be
in a better position to answer that question properly.  I believe they
have exceptions for classes of bugs as well as individual cases in the
past (but I do not have the references at hand to back that up, so I
could be wrong).

> If the TC as a body does not feel it can, or does not feel it should,
> override the release team in terms of granting stretch-ignore tags for
> certain bugs or classes of bugs (and, I am not saying the TC *should*
> feel it can or should do this, mind you!), still the TC as a body can,
> if a developer so requests and if the TC as a body agrees it should do
> so, offer an advisory opinion concerning particular bugs / bug classes
> to the release team and/or offer a show of support to the affected
> developer, in terms of saying "we believe stretch-ignore tags should
> be applied to the following bugs / classes of bugs, because ..."
> Correct?

Yes, the TC is free to offer advice on any matter.

> Question of bug process, I guess ... For purpose of stretch-ignore
> tags (should they be granted, of course!), would it make sense to
> create a meta-bug, say "Browserified Javascript in Stretch", make all
> the individual package bugs somehow depend on or refer to this meta
> bug, and then apply a stretch-ignore tag to the meta-bug and allow it
> to propagate somehow to all the individual bugs? Or would it be better
> to just apply the stretch-ignore tag to each separate individual
> package bug? I'm thinking as to what will be most effective in making
> sure nothing gets missed, overlooked, forgotten about, either
> pre-Stretch or post-Stretch.

I would leave the desired process to the release team. I believe it'd be
tagging the individual bugs with stretch-ignore, since that's what's
looked at by tooling.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 02:23:37PM +0200, Didier 'OdyX' Raboud wrote:
>...
> All of the above are imperfections (yes, bugs) in how src:firefox handles its 
> internal sqlite3.c code copy. In an ideal world:
> 
> * src:sqlite3 would provide sqlite3.c in a binary package (sqlite3-static ?)
> * src:firefox would build-depend against that package, and get rebuilt on 
> sqlite3 security uploads
> * firefox would use Built-Using pointing at the correct version of src:sqlite3

The reality in unstable is already even better than your ideal world:

Firefox does already use the shared SQLite library in unstable.
For unstable you could just remove the file from the sources
(and for most other affected packages that would just fix it).

The main problem is that the security team has given up patching 
Firefox years ago, and just ships the latest ESR.

SQLite in stable and oldstable is too old for recent Firefox,
and therefore the amalgamation is used in security updates.

>...
> As a conclusion, my point is we aren't talking about the same thing:
> 
> * On the src:sqlite3 (in src:firefox) side, we have a giant C file, merely a 
> concatenation of source files in Debian, using a script available in Debian, 
> all of which is free software.
> 
> * On the bug that triggered this discussion (#817092 in libjs-handlebars), we 
> have the "browserified" handlebars-v1.3.0.js [2] which a "transformation" of 
> source files not in Debian, using tools not in Debian. 

No non-amalgamation sources for the exact SQLite version used by Firefox 
in jessie are in jessie.

At that point the two cases have strong similarities.[1]

> As was pointed by Phil in [3], although the result is JavaScript code, the 
> transformation is more than "just" concatenation. The original source files 
> are 
> not available in Debian, and the tools aren't either.

As has already been pointed out, there are several issues mixed in the 
"browserified javascript" discussion.

This is a package with several issues, not a generic example.


Does the TC want to be constructive or not?

The TC seeme to have doubts whether or not the constitution allows the 
TC to override decisions by the FTP team on DFSG issues.
According to the constitution, the secretary has the power
of interpreting the constitution.

Has the TC already asked the secretary?
If not, why not?

If it would turn out that there is nothing short of a GR to override a 
decision of the FTP team on DFSG issues, I would expect the TC to state 
explicitely to Pirate Praveen that his only option is a GR.


In any case, and clearly within what the TC could do, it would be 
constructive if the TC could become active itself with gathering
a good understanding of the whole problem.

No matter whether this gets resolved by FTP team, TC or GR, the biggest 
obstacle currently is that noone has a proper understanding of the whole
problem.


> Cheers,
> OdyX

cu
Adrian

[1] there could be significant differences somewhere, but my current
impression is that the SQLite amalgamation might actually be more
problematic than the basic browserified javascript case

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 11:48:36AM +0200, Philip Hands wrote:
>...
> The security team are going to have to track down every instance of that
> code and fix it.  If the bug is something to do with an interaction
> between the code and the tools used to "browserifiy" the code, that may be
> non-trivial.

For the DFSG it is perfectly fine if a package ships a private 
(potentially modified) copy of the code and only works with this 
specific copy.

And providing 3 years of security support for a huge amount
of JS packages sounds challenging in any case.

I would strongly distinguish between the "what is source code according 
to the DFSG" and "what can the security team support" questions.

The former is a general question that is relevant here,
the latter is a release-specific issue that should be
discussed separately.

>...
> Of course, for that to happen we'd have to start accepting tiny
> javascript packages, which is currently not happening (which also seems
> to be a blocker to grunt being packaged BTW).

https://sources.debian.net/src/node-number-is-nan/1.0.0-1/index.js/

I cannot imagine a package more tiny than this one that was accepted 
last month.

> Cheers, Phil.
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Didier 'OdyX' Raboud]

Le jeudi, 6 octobre 2016, 14.38:21 h CEST Adrian Bunk a écrit :
> I am not sure whether this has been filed as a bug in any affected 
> package, but src:sqlite3 is not affected.
> 
> The problem is the amalgamation in other packages, for example:
> https://sources.debian.net/src/firefox/49.0-4/db/sqlite3/src/sqlite3.c

This is of course problematic, especially because this source file is copied 
multiple times accross the archive. It should really be under the Security 
Team's radar through
https://wiki.debian.org/EmbeddedCodeCopies
(it apparently isn't)

That said, there _is_ code to reproduce this amalgamation (roughly, a 
concatenation) in Debian main already, see [0] for example.

mksqlite3.tcl as well as all the source files it will bundle in sqlite3.c are 
DFSG-free source, and are available in Debian. Sure, sqlite3.c as embedded in 
firefox 49.0-4 is in version 3.13.0 and that version of src:sqlite3 isn't in 
any Debian suite anymore (we have snapshot.d.o though [1])

All of the above are imperfections (yes, bugs) in how src:firefox handles its 
internal sqlite3.c code copy. In an ideal world:

* src:sqlite3 would provide sqlite3.c in a binary package (sqlite3-static ?)
* src:firefox would build-depend against that package, and get rebuilt on 
sqlite3 security uploads
* firefox would use Built-Using pointing at the correct version of src:sqlite3

Note that the latter mechanism could be used immediately to get dak to 
guarantee the availability of the correct version of src:sqlite3 in mirror's 
pool.

As a conclusion, my point is we aren't talking about the same thing:

* On the src:sqlite3 (in src:firefox) side, we have a giant C file, merely a 
concatenation of source files in Debian, using a script available in Debian, 
all of which is free software.
* On the bug that triggered this discussion (#817092 in libjs-handlebars), we 
have the "browserified" handlebars-v1.3.0.js [2] which a "transformation" of 
source files not in Debian, using tools not in Debian. 

As was pointed by Phil in [3], although the result is JavaScript code, the 
transformation is more than "just" concatenation. The original source files are 
not available in Debian, and the tools aren't either.

-- 
Cheers,
OdyX

[0] http://sources.debian.net/src/sqlite3/3.14.2-1/tool/mksqlite3c.tcl
[1] http://snapshot.debian.org/package/sqlite3/3.13.0-1/
[2] 
https://sources.debian.net/src/libjs-handlebars/1.3.0-1/handlebars-v1.3.0.js/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90

signature.asc
Description: This is a digitally signed message part.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 10:43:00AM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2 
> (reopening)"):
> > Perl's Configure or SQLite are other examples of code with similar 
> > issues currently in Debian, and it would be helpful if the TC would 
> > start by gathering an overview of the different cases and how they
> > are similar or different.
> 
> You've mentioned sqlite3 several times in this thread, but I couldn't
> find a corresponding bug report against src:sqlite3.  Did I miss one ?

I am not sure whether this has been filed as a bug in any affected 
package, but src:sqlite3 is not affected.

The problem is the amalgamation in other packages, for example:
https://sources.debian.net/src/firefox/49.0-4/db/sqlite3/src/sqlite3.c

Upstream documentation:
http://sqlite.org/howtocompile.html
"The use of the amalgamation is recommended for all applications."
"Recall that the SQLite amalgamation contains a lot of C-code that is 
 generated by auxiliary programs and scripts."

> Ian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 01:13:16AM -0400, Joseph R. Justice wrote:
> For the record, I wish the message I am now responding to, and other
> subsequent responses and discussion, were being sent to the bug mail
> address *in addition to* all the other addresses they're being sent to.
>...

For the record, that was my fault and a problem in my mail setup.

> Joseph

Sorry for that
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

"Joseph R. Justice"  writes:

>> Here are some factors to consider:
>>
>> 1)  It's not clear to several TC members that the FTP team has decided
>> on this question.  It seems fairly clear how they would decide if they
>> did decide, but from a process standpoint, it's important to have a
>> formal dialogue with them before they are overruled.
>
> I'll be honest, I assumed from what I've read that a decision had already
> been made by the FTP team against Mr. Praveen.  I figured that it must have
> been, or else why would he be raising this bug with the TC now?

Well, quite.

Joseph, thanks for you efforts here, I think some light has been shed
( although as a dyslexic, shorter/fewer mails would be helpful ;-)
  That being the case I'm just going to reply to one mail and cover
  some of the points that you raised across several).

I'm just writing as an individual here BTW, but I'll obviously carry
these views into any discussion that the TC might have about this.

The repeatedly presented request is for a ruling on the question of
'browserified javascript' in general.  There are two serious problems
with that straight away.

Firstly, none of the people being asked to make to that general
decision are used to making general statements on such matters, and
many/most of them think that doing so is a bad idea.

Secondly, 'browserified' is poorly defined, and repeated attempts to
clarify its meaning seem to have been ignored.

Pretty much any response that any of us might be hoped to make to such
requests are things we're unwilling to say because we reject both the
assumption that a general statement is a good idea, and don't want to
make statements that are then open to wild reinterpretation because of
the fluffy terminology.

So we end up asking what look like picky, annoying questions about small
details in order to try and get something concrete to talk about.

Meanwhile Praveen is only interested in fixing the whole problem at once,
and pushes harder to get a general response.  This is not working.

Speaking purely for myself, no matter how trivial the transformation
being done to the source, I see no compelling reason for an exception.

My reason being more to do with the practical consequences of allowing
such an exception, than the subtle issue of what might constitute source.

Assuming for the sake of argument that the request for a special
exception were granted, then:

Let's imagine that there's one-line npm library that has an (as
yet undiscovered) flaw that allows some sort of serious remote attack.

Also, that library is popular enough to be included in numerous
"browserified" libraries, which because of the exception get packaged,
and then included in a release, and are depended upon by the likes of
gitlab and other such packages.

Wait a couple of years, and then discover the bug.

In the mean time, some of the browserified libraries have become
unpopular, and no longer have upstreams and because of developments in
grunt can now only be built with an obsolete version of grunt.  Some have
refactored and can now only be built with the latest version of grunt.
Some have moved on and no longer use the faulty code at all, so have no
interest in helping fix old versions.

The security team are going to have to track down every instance of that
code and fix it.  If the bug is something to do with an interaction
between the code and the tools used to "browserifiy" the code, that may be
non-trivial.

We have no real control over which versions of those tools were used,
and various upstreams are likely to say "just upgrade" or thay may
present us with vastly different versions of the browserified code,
especially if they've switched to different tools in the mean time.

None of this seems compatible with our normal security processes.

In a perfect world the person doing the security fix would go to the
buggy code in its own library, and then upload a new version, provoking
all the other packages to be rebuilt.  Job done.

Of course, for that to happen we'd have to start accepting tiny
javascript packages, which is currently not happening (which also seems
to be a blocker to grunt being packaged BTW).

In conclusion, Praveen's asking a question that I see no real prospect of
getting an answer in its current form.

In fact, I'm yet to imagine a way of framing this question that would
result in any of the packages being acceptable in 'main' and I don't see
any problem with them being moved to a combination of contrib and
non-free -- I think that is actually the correct outcome, because it
gives the correct impression about the level of security support they
should expect for those packages.  It also doesn't encourage people to
use packages that might well be removed in a subsequent release.

How good would it be, for instance, if in the lifetime of Squeeze,
Alioth were migrated to gitlab, only for it to be removed from Squeeze+1
when grunt proves to be unpackageable?  Temporoary 

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Ian Jackson]

Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2 
(reopening)"):
> Perl's Configure or SQLite are other examples of code with similar 
> issues currently in Debian, and it would be helpful if the TC would 
> start by gathering an overview of the different cases and how they
> are similar or different.

You've mentioned sqlite3 several times in this thread, but I couldn't
find a corresponding bug report against src:sqlite3.  Did I miss one ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   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.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Wed, Oct 5, 2016 at 12:04 AM, Pirate Praveen  wrote:

A quick update, I have asked ftp masters to make a ruling on the issue.
> #839801.
>

Forgot to mention in my other response to this message...

Should this bug (839570) depend on the FTPmaster ruling request bug
(839801), or vice versa, so as to indicate that the TC is waiting on any
response from the FTP team before making a decision?  (Since, after all,
the FTP team might make a decision which satisfies Mr. Praveen, making
what's been asked of the TC moot.)

If this should be done, I encourage someone with the right to do this to do
so.  I certainly do not feel I have the right myself, and even if I did I
am unfamiliar enough with the bug tracking software to feel I should
attempt to do this.

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Thu, Oct 6, 2016 at 12:55 AM, Tollef Fog Heen  wrote:

> ]] "Joseph R. Justice"
>


> > Could the TC offer guidance, or issue a statement, on if (and if so
> > when) it should ever be permissible to allow a waiver from RC-bug
> > status for software whose source code is available but determined to
> > be insufficiently free for the DFSG while active efforts are underway
> > to get the source code into a state determined to be fully compliant
> > with the DFSG?
>
> This is very clearly release team territory and they have an RC bug
> policy already: https://release.debian.org/stretch/rc_policy.txt If this
> isn't clear enough or sufficient enough, that policy should be improved.
> The TC should not go out and overrule the release team's RC bug policy
> unless we have a really good reason (and it's still not completely clear
> that we can overrule them as a team either, but that entire discussion
> is unneeded unless we want/need to override them).
>

Read it.  Thank you.

Clearly (to me) what Mr. Praveen is asking for is stretch-ignore tags by a
release manager for software which has the browserified Javascript issue.
This software might and/or might not include software with the generated
lexer/parser code issue and/or other as yet unknown issues, depending on
what exactly browserification is defined to mean, which I will agree for
now has not yet been done.  E.g. it is not clear, there is not a hard and
firm definition, of what it means to browserify Javascript, such that one
can say "this software is merely browserified" or "that software is
browserified *and* *also* ..."

Is there any information yet on what formal policy (if any) will be used by
the release managers for allowing bugs to be tagged stretch-ignore?  *Was*
there any formal policy ever set in place for the prior (the current
stable) release of Debian, e.g. Jessie, or prior to that Wheezy?  Was it /
will it be entirely ad-hoc and at the discretion of the release team?

If the TC as a body does not feel it can, or does not feel it should,
override the release team in terms of granting stretch-ignore tags for
certain bugs or classes of bugs (and, I am not saying the TC *should* feel
it can or should do this, mind you!), still the TC as a body can, if a
developer so requests and if the TC as a body agrees it should do so, offer
an advisory opinion concerning particular bugs / bug classes to the release
team and/or offer a show of support to the affected developer, in terms of
saying "we believe stretch-ignore tags should be applied to the following
bugs / classes of bugs, because ..."  Correct?

Question of bug process, I guess ...  For purpose of stretch-ignore tags
(should they be granted, of course!), would it make sense to create a
meta-bug, say "Browserified Javascript in Stretch", make all the individual
package bugs somehow depend on or refer to this meta bug, and then apply a
stretch-ignore tag to the meta-bug and allow it to propagate somehow to all
the individual bugs?  Or would it be better to just apply the
stretch-ignore tag to each separate individual package bug?  I'm thinking
as to what will be most effective in making sure nothing gets missed,
overlooked, forgotten about, either pre-Stretch or post-Stretch.

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Wed, Oct 5, 2016 at 12:04 AM, Pa irate Praveen 
wrote:

> On 2016, ഒക്‌ടോബർ 4 7:49:28 PM IST, Sam Hartman 
> wrote:
>


> >You're asking questions that don't make sense from a p.process
> >standpoint, doing things that have a very low probability of making
> >anyone happy,
>
> A quick update, I have asked ftp masters to make a ruling on the issue.
> #839801.
>

I saw that.  I look forward to any response they (or others) care to make
concerning that bug.

FWIW, I for one was under the impression (in part based on what you
originally wrote when you opened this bug, and looking at the bugs you
referenced in that message) that there had already been a decision by them
to declare browserified Javascript as failing to be DFSG-free on the
grounds of failing source code availability (because grunt is not currently
available in the Debian main archive).  If this was not the case, then I'll
agree with others it's important you get an explicit ruling from them one
way or another, so that if the ruling goes against you you can go to the TC
and say "This is what was decided, and this is why I disagree", and you
actually *have* something to point to in terms of what was decided!

Based on what Mr. Hartman has written, I would encourage you to explain for
everyone involved just exactly what you mean by "browserified Javascript",
what sort of processes and transformations are included by that term and
what are not.  Try to be as specific and precise as possible, not just
handwavy.  I've seen some stuff that makes it sound like it's merely
concatenation of files, but then I've seen other stuff that makes it sound
like it's *not* just that.  So I'm confused.  Remember, the people on the
TC are generally technically adept, but they're *not* specialists in
Javascript as you apparently are!  You need to teach them some stuff, so
they can make an educated and informed decision.

I would also suggest you explain exactly how the issue raised in bugs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830986 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830987 (the bugs related
to the generated lexer/parser code issue) relate to the concept of
browserified Javascript in general?  Is part of what's described in these
bugs routinely considered to be part of what it means to browserify
Javascript, so that if browserified Javascript is (temporarily) declared to
not be RC-buggy for Stretch, that means this stuff is not RC-buggy for
Stretch?  Or, is what's described by these bugs entirely separate and apart
from the process of browserification, such that even if browserification is
not RC-buggy for the moment, software with these bugs is still RC-buggy and
needs to have the bug resolved or else have the software go to the non-free
archive?





> I feel these responses make TC more like a bureaucracy, where focus is
> given on process and having people to go around asking many people.
>

>From what I understand of Mr. Hartman, he is particularly interested in
process.

But, for your purposes, that is not a *bad* thing!  He's not necessarily
interested in simply denying your request (tho, he *is* interested in
making sure your request is seen by him only after the people who should
see and decide on your request first have had a chance to do so).

That doesn't mean he'll necessarily agree with your position.  But, I think
it's important to him that you get a fair hearing and be treated as fairly
as possible.

It's important however for *you*, if you are to get what you want (which as
far as I can tell is a temporary variance for the duration of Stretch for
browserified Javascript files from being considered RC-buggy while you work
to package grunt for Stretch+1), to explain *why* this variance should be
granted.  And what you're going to do to permanently resolved this issue
for Stretch+1, so it doesn't come up again as a problem.  You have to
convince the TC to take your side; it's not enough for you to say "Well,
you should do what I want because ... Just because."

I'm sorry if you feel like this is a bureaucracy.  For what it's worth, I
think people are just trying to make sure they're doing what's right or
what's best, not just what's convenient or expedient at the moment.



Hope this is of some use, interest.  Thanks for your time.



Joseph

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

For the record, I wish the message I am now responding to, and other
subsequent responses and discussion, were being sent to the bug mail
address *in addition to* all the other addresses they're being sent to.  I
am choosing to send my response here to the bug mail address, at least in
part so there is a record there that not all the discussion related to this
bug is available at the bug itself, but instead is only found in the
debian-ctte list archives.



On Tue, Oct 4, 2016 at 11:31 AM, Adrian Bunk  wrote:

> On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>


> > Here are some factors to consider:
>

[...]


> In other words, the best way forward for getting any decision would be
> an RC bug against perl claiming that the Configure script is not DFSG-free.
>

For the record, having read Mr. Hartman's draft analysis at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#217 , and some
other things related to the perl Configure script source code availability
issue, I admit that I would be ... "amused", for a suitable definition of
the word amused, if this issue were brought up.  (*cough*).




> If anyone thinks that this hardball approach would not be necessary,
> please describe to Pirate Praveen a better way for getting an explicit
> decision in time for stretch.
>

Get a variance from RC-buggyness for browserified Javascript for Stretch,
and package grunt and/or alternative for Stretch+1.  That's what he's asked
for, anyway.

Admittedly, if grunt et al fails to be successfully packaged for Stretch+1,
and/or if packaging grunt et al proves to be insufficient for the
browserified Javascript source code availability issue, then the RC-bug
issue reappears for Stretch+1, with an even more tangled thicket around it
 But, that's the risk one takes.



Hope this is of some use, interest.  Thanks for your time.  Be well.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] "Joseph R. Justice" 

> Could the TC offer guidance, or issue a statement, on if (and if so
> when) it should ever be permissible to allow a waiver from RC-bug
> status for software whose source code is available but determined to
> be insufficiently free for the DFSG while active efforts are underway
> to get the source code into a state determined to be fully compliant
> with the DFSG?

This is very clearly release team territory and they have an RC bug
policy already: https://release.debian.org/stretch/rc_policy.txt If this
isn't clear enough or sufficient enough, that policy should be improved.
The TC should not go out and overrule the release team's RC bug policy
unless we have a really good reason (and it's still not completely clear
that we can overrule them as a team either, but that entire discussion
is unneeded unless we want/need to override them).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 10:30 AM, Sam Hartman  wrote:

First off, I would like to, sincerely and truly, thank you for responding
to my message.  I'd been wondering if maybe they were going into a black
hole of some sort.  You give me some reassurance that they are not, or at
least not entirely.



Thanks for your detailed message.  I don't agree with all of it, but I
> find it a lot easier to interact with than some of the requests we've
> gotten related to this issue.
>

No problem, thanks back, and fair enough that you don't agree with all of
it.

FWIW, in some ways, it might be easier for me dealing with this than it is,
say, Mr. Praveen.  He is (inevitably!) emotionally invested in this issue,
since it's something important to him, something he's working on.  It's not
something I'm particularly invested in; if anything, this is something I'm
doing "pour le sport".  He is intimately familiar with this stuff; I am
not, so stuff that's obvious to him isn't obvious to me.  And, no
disrespect intended to him (or anyone), but I think I write mor gud (or at
least more verbosely!) than he does.

Just think of me as a roaming mercenary volunteer hired gun lawyer /
advocate / mouthpiece, here to right wrongs, keel keel keel the bad guys,
and sneak off into a haystack in the back barn with the comely schoolmarm
before I ride off into the sunset on my faithful steed, Horse.  (We're
still trying to figure out which of us is smarter.  My vote is on the guy
with four legs, myself.)




> Here are some factors to consider:
>
> 1)  It's not clear to several TC members that the FTP team has decided
> on this question.  It seems fairly clear how they would decide if they
> did decide, but from a process standpoint, it's important to have a
> formal dialogue with them before they are overruled.
>

I'll be honest, I assumed from what I've read that a decision had already
been made by the FTP team against Mr. Praveen.  I figured that it must have
been, or else why would he be raising this bug with the TC now?

I do note however that Mr. Praveen has subsequent to your message stated
that he has filed a formal request with the FTP team concerning
browserified Javascript in general (although IMO he hasn't clearly stated
that in his message opening the bug, tho I do believe that's what he means).

To make life easier for anyone reading the bug log, the full link to the
bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839801 .

I've looked at it as I write this response; there's been no response to
that bug yet (tho I hardly would expect one, it hasn't even been a day
since the bug was filed, after all, and this is a non-trivial decision
being asked for).




> 2) It's not clear constitutionally that the TC can overrule the ftp
> team's decision regarding whether something is DFSG-free.  Even if we
> could, it's not clear that is a technical decision in our scope.
> So, asking the TC to overrule such a decision is asking for the hardest
> political choice possible in such a situation--a really hard sell within
> the project and the TC.
>

Mmmm.  I respect that.

FWIW, I don't think Mr. Praveen necessarily wants a ruling that
browserified Javascript meets the full definition as-interpreted of "source
code available".  (Or, rather, I think *he* thinks browserified Javascript
by itself is "good enough as-is", but he's willing to concede that
something better is possible and preferable.  He's said as much.  He's just
hoping to avoid the stigma of having to be in contrib / non-free for the
release of Debian Stretch, by seeking a variance that this issue is
RC-buggy *for now* so that the various pieces of software can be in main,
while he works on achieving that possible, preferable outcome during the
preparation of Stretch+1 which will permanently resolve the issue of
whether this issue is RB-buggy.)



Mmmm...  With respect to politics...  I fully agree that this is / will be,
at least in part and possibly in large part, a political decision.  Mr.
Praveen has already started that ball in motion, by suggesting that this
issue will cause many (presumably) important pieces of web-based software
to have to be moved to contrib and the libraries they depend on be moved to
non-free, at least until and if grunt (or a sufficiently capable
replacement) can be added to the main archive.  I'm aware that, for many
people, *not* being in main is like saying "You're not *really* part of
Debian Linux".

I'm not a web developer.  I have absolutely no idea how important these
applications are in actual practice.  They may have little use in the Real
World.  They may have tons of use.  It may have strong adverse effects on
users or potential users of Debian if these applications are not in Debian
main; it may have little or no effect at all.  In the worst possible case,
potential users (be they individuals, or end user companies, or people
selling software and services making use of Debian stable) maybe decide to
use 

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 9:18 AM, Sam Hartman  wrote:

> > "Didier" == Didier 'OdyX' Raboud  writes:
>

I do think there are things we could do in this space.
> We could set policy consistent with the DFSG on what the definition of
> source code in Debian is.
>

Could the TC offer guidance, or issue a statement, on if (and if so when)
it should ever be permissible to allow a waiver from RC-bug status for
software whose source code is available but determined to be insufficiently
free for the DFSG while active efforts are underway to get the source code
into a state determined to be fully compliant with the DFSG?

That's what Mr. Praveen is actually asking for, after all.  (IMO, of
course.)  He wants the software he is interested in in the Debian main
archive at the time Debian Stretch is released (because, politically and
... I can't think of the right word, but in terms of advertising
capabilities, it's undesirable for the software to have to be relegated to
the contrib and non-free archives, those don't count for many as being part
of "Debian").  But, in practical terms, while the source code for the
software may effectively be available within Debian now, it does not meet
the full and pristine interpretation of the DFSG in terms of what it means
to have source code available.  So, while he works on that (by packaging
grunt), he's seeking a waiver from RC-bug status for this issue for the
in-preparation release.

Mmmm.  I believe I saw ...  Found it.

https://lists.debian.org/debian-devel/2016/07/msg00253.html .

Quoting from that message (first paragraph from Mr. Praveen, remainder by
Philip Hands ):

=
> And why is the people who are so strict about packaging the build tool
> not stepping up to package it? FRP for node-grunt was filed in 21 May
> 2012 and it is still not complete. So removing these packages until
> grunt is packaged makes debian better?

They should be in contrib.

Allowing them in main removes any incentive to do the work to fix this
problem, which I'd imagine is the reason it's not been done.

When this was last raised, I looked into it and concluded that grunt is
a tangled mess.

[...]

Simply letting them [ed: packages ultimately depending on the presence of
grunt] into main removes that pressure [ed: to deal with the tangled mess
of grunt either directly or else indirectly by finessing / replacing it,
and/or by getting upstreams to alter their use of grunt, etc], it also
means that
we're deceiving our users, since they expect buildable source for all
packages in main.
=

That's a political decision, too.  (I'm not claiming or implying it's a
wrong decision, mind you!  I'm simply noting it as an observation, I was
impressed by it the first time I read it.)



Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 7:37 AM, Didier 'OdyX' Raboud 
wrote:

Would the following ballot be a better fit ?
> ==
> C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
> FD: Further Discussion
> ==
>

I'd like to state again that, if you (the TC as a body) choose not to vote
in favor of Mr. Praveen's request, I believe he would be more satisfied if
you chose to express an active preference against his position and in favor
of the (presumable) FTP Team's position, rather than merely decline to make
a ruling and close the bug.  I believe, given his original message opening
the bug, that he would find the latter action by you all highly
unsatisfactory.  (Not that I claim he would be satisfied by an active
ruling against him, mind you!)

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

[I realize there have been several messages subsequent to this, but I'm
working down the list in order of presentation by the GMail web interface.]

On Tue, Oct 4, 2016 at 4:13 AM, Didier 'OdyX' Raboud 
wrote:

> Le dimanche, 2 octobre 2016, 14.29:49 h CEST Pirate Praveen a écrit :
>


> > package: tech-ctte
> >
> > Following up on #830978. I would like this to be reopened and request
> > CTTE make a formal vote.
>
> The discussion that lead to closing #830978 happened on IRC [0] , see the
> full
> log from line 172 [1] , and Sam put a clear rationale in the mail closing
> the
> bug [2]. I'll quote on specific part of it:
> > With regard to the particular issue of Browserified javascript,
> > particularly in the libjs-handlebars package, the best way forward is
> > for the submitter to discuss the question with the FTP team.  Such a
> > discussion would be less confusing if it took place after #830986 is
> > resolved.
>
> (#830986 isn't resolved)
>

FWIW, it's not clear to me at least that ""browserified" Javascript"
necessarily includes the issue pointed out in 830986, e.g. the generated
lexer/parser code.  (I'm not saying it *doesn't* include the 830986 issue,
mind you!  I'm just not saying either that it *does* include it.  Reviewing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 , I see some
comments that, to me at least, imply that browserification does not
necessarily imply the 830986 issue in in play for any given instance of
browserified code.)

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 , Mr. Praveen
lists bugs which ultimately refer to several other Javascript library
packages beyond that of libjs-handlebars.  I suppose it's possible that all
of them include generated lexer/parser code, but if there are some that do
not then apparently "browserification" does not necessarily involve use of
external lexer/parser generators (tho certainly it's possible that
browserification, in the form Mr. Praveen means it, might include always
having the capability to invoke a lexer/parser as part of the process of
browserifying Javascript libraries).  In any event, for any browserified
libraries which do *not* include code generated by a lexer/parser, the bug
at 830986 should not apply to them.

Further, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#35 ,
Mr. Praveen says "the browserified javascript can be modified by anyone who
understand javascript without difficulty and can satisfy dfsg requirement
for source" where the browserified javascript refers to "libjs-handlebars,
libjs-fuzzaldrin-plus and other browserified javascript".  Given what I
understand about the sort of code typically generated by lexer/parsers,
e.g. that it typically can *not* be modified, in generated form, by
"anyone" "without difficulty", I have to think that either (a) Mr. Praveen
does not mean libraries of this sort (e.g. containing generated
lexer/parser code) when he is speaking of browserification in general, or
else (b) he is mistaken in his claim about how easy to modify such
libraries.

So...  If there can be / are browserified libraries which do not suffer
from an issue of containing generated lexer/parser code, then it may make
sense to consider whether such libraries are suitable for inclusion in the
"main" archive separately from the issue of any such libraries which *do*
suffer from an issue of containing generated lexer/parser code.  (For the
record, I myself do not know if there are any such libraries, nor am I
claiming that there are any such.  I'm just raising the possibility as a
"What if?" sort of thing.)




> Now, moving forwards… We decided to close the bug without a formal vote,
> because it was clear for all the present TC members that we were in
> agreement.
> We have also agreed (amongst us) to avoid the use of unnecessary
> bureaucracy
> when possible; hence our delegation to close the bug to Sam. Now, the
> offer to
> "repoen the bug and ask for a formal vote"  [3] stood to enable anyone to
> ask
> for the bug closure to respect our formal procedures (saying "please don't
> close the bug because you think you're in agreement, but run a formal
> vote").
>
> For what I'm concerned, the situation hasn't evolved, and the conclusion
> that
> Sam outlined still stands (FTP Team is responsible for DFSG, and has
> decided,
> Release Team has decided DFSG is RC and has deferred DFSG-compliance
> determination to FTP Team).
>

I'll go into this point in more detail in other responses, I expect, but
I'll at least say for now that I think it is possible to find that there
are differing levels or degrees of DFSG non-compliance, in terms of their
severity of non-compliance or the amount of harm that can be done by
distributing them despite the fact that they are not fully compliant with
*all* the terms of the DSFG and their current interpretation by Debian, and
that therefore it is possible that it might be reasonable in some
circumstances to decide that a 

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Philip Hands  writes:

> Praveen, please respond to #830986

Actually, I withdraw that request -- I doubt replying there is going to
be a productive use of your time, and is probably not going to improve
your chances of getting what you want either.

If you fancy explaining what you think browserified means w.r.t. the
Jison stuff, go ahead of course.  That might at least help to focus the
discussion a bit.  Just don't feel obliged to because I said so.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Wed, Oct 05, 2016 at 08:21:40PM +0200, Philip Hands wrote:
> Adrian Bunk  writes:
> 
> > Why are TC members complaining that they do not even properly understand 
> > what "browserified" means, instead of using the power to give advice to 
> > structure the discussion?
> 
> Probably because without a response to #830986, "browserified" either
> means including Jison output into things, or it cannot possibly cover
> what's being done to libjs-handlebars, either of which makes the recent
> bugs against tech-ctte and ftp-master just a little astonishing.
> 
> Praveen, please respond to #830986

Yesterday Sam stated that the TC would first require a ruling from the
FTP team for being able to overrule it. The result is #839801.

This is exactly why I am saying the TC should structure the discussion.

> Without such a response, I wasn't even sure if the re-opening of the bug
> was instead an attempt to get some sort of permission to let the likes
> of gitlab into main, by temporarily ignoring the non-free
> dependencies. (I'm not suggesting that as a way forward BTW, but it
> seemed at least as plausible as what was actually being asked)

I would assume good faith.

My impression is that there are several problems mixed with only the 
most obvious one inititially discussed, and that the best way forward 
would be if a TC member would look at the packages in question as well 
as what terminology is used in the JS world.

You really need someone who will also look for issues like #830986 
to actually get first-hand knowledge.

It would also be good if that person could get an understanding which 
of these problems would be fixed when Grunt is packaged.

And then also looks at cases like Perl or SQLite.

Any TC member should be able to do that in 1-2 days, and then
there would be a proper description of the problem that could
serve as basis for an actual discussion of the problem.

> Cheers, Phil.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Adrian Bunk  writes:

> Why are TC members complaining that they do not even properly understand 
> what "browserified" means, instead of using the power to give advice to 
> structure the discussion?

Probably because without a response to #830986, "browserified" either
means including Jison output into things, or it cannot possibly cover
what's being done to libjs-handlebars, either of which makes the recent
bugs against tech-ctte and ftp-master just a little astonishing.

Praveen, please respond to #830986

Without such a response, I wasn't even sure if the re-opening of the bug
was instead an attempt to get some sort of permission to let the likes
of gitlab into main, by temporarily ignoring the non-free
dependencies. (I'm not suggesting that as a way forward BTW, but it
seemed at least as plausible as what was actually being asked)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[gregor herrmann]

On Wed, 05 Oct 2016 19:10:35 +0300, Adrian Bunk wrote:

> The TC is clearly not too busy, just too lazy.

I find your recent mails quite aggressive which makes them unpleasant
to read for me. Please try to change your tone a bit.

Cheers,
gregor
 

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Pink Floyd: The Great Gig In The Sky


signature.asc
Description: Digital Signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

> "Don" == Don Armstrong  writes:

Don> I don't believe there is anyone on the TC who is arguing that
Don> perl doesn't (or at least didn't) have a DFSG issue.[1]

Don> We merely believe the TC does not have the power to make a
Don> decision for the ftpmasters without being delegated that
Don> decision. We can help try to clarify the issue for the
Don> ftpmasters and the project, but the bully pulpit (up to and
Don> including §6.1.5) is the only special power we think we have in
Don> this area.

For what it's worth I think our power in this area extends beyond 6.1.5
in some cases.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Wed, Oct 05, 2016 at 10:06:57AM -0500, Don Armstrong wrote:
> On Wed, 05 Oct 2016, Adrian Bunk wrote:
> > Please describe the relevant differences between browserified
> > javascript and perl that make the TC believe that the former has a
> > DFSG issue but the latter probably has not, in a way that I can deduct
> > what the TC would believe regarding the similiar problem related to
> > SQLite.
> 
> I don't believe there is anyone on the TC who is arguing that perl
> doesn't (or at least didn't) have a DFSG issue.[1]
> 
> We merely believe the TC does not have the power to make a decision for
> the ftpmasters without being delegated that decision. We can help try to
> clarify the issue for the ftpmasters and the project, but the bully
> pulpit (up to and including §6.1.5) is the only special power we think
> we have in this area.
>...

What I am dismayed about is how the TC seems to try to find excuses to 
avoid making any decision or being in any other way helpful.

Just yesterday the chairman (!) of the TC was stating "but it's not at 
all clear that the constitution enables the TC to override Delegates or 
decisions made by delegates":
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#40

For comparison, here is a vote by the very same person last year where 
he does override a decision made by a delegate, with the TC even making
a decision on a question it wasn't asked:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#1042

You did also vote the same:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#1037


Looking at [1], the TC made two decisions in 2015.
Each of them took over a year.

No decisions in 2016 so far.

The TC is clearly not too busy, just too lazy.


I do agree with Ian that even though I doubt that Pirate Praveen will
get the decision he hopes for, he is entitled to a proper resolution
of the issue.

Why are TC members complaining that they do not even properly understand 
what "browserified" means, instead of using the power to give advice to 
structure the discussion?

I do not see anything controversial about the TC generating an overview 
of the relevant issues related to javascript as well as similar 
non-javascript cases.

You have 8 of the most experienced Debian developers in the TC, no other 
TC work at hand, and any one of you should be able to help resolving 
this conflict by doing this.

How a final decision would look like, and who would make that, would be 
the next step. In any case you have to first understand the problem 
properly. And I would not even exclude the possibility that there might 
be solutions that were not visible before understanding the problem.


cu
Adrian

[1] https://www.debian.org/devel/tech-ctte

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Don Armstrong]

On Wed, 05 Oct 2016, Adrian Bunk wrote:
> Please describe the relevant differences between browserified
> javascript and perl that make the TC believe that the former has a
> DFSG issue but the latter probably has not, in a way that I can deduct
> what the TC would believe regarding the similiar problem related to
> SQLite.

I don't believe there is anyone on the TC who is arguing that perl
doesn't (or at least didn't) have a DFSG issue.[1]

We merely believe the TC does not have the power to make a decision for
the ftpmasters without being delegated that decision. We can help try to
clarify the issue for the ftpmasters and the project, but the bully
pulpit (up to and including §6.1.5) is the only special power we think
we have in this area.

1: I just looked into this yesterday, and was amazed at how complicated
the Configure regeneration process was. It even seems to depend on being
run by a specific user.
-- 
Don Armstrong  https://www.donarmstrong.com

Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities.
 -- W. Churchill

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Wed, Oct 05, 2016 at 10:00:53AM -0400, Sam Hartman wrote:
>...
> I think it's clear that the TC believes that this package is not DFSG
> free.
> I think it's clear that the TC believes perl would be better if the
> situation was improved.
> I thought it was clear we believed perl had a DFSG issue, although IRC
> discussion today makes that less clear.
> I don't think the value of having the TC formally say any of those
> specific things is very high.
>...

Please describe the relevant differences between browserified javascript 
and perl that make the TC believe that the former has a DFSG issue but 
the latter probably has not, in a way that I can deduct what the TC 
would believe regarding the similiar problem related to SQLite.

> --Sam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

> "Sam" == Sam Hartman  writes:

Sam> Obviously, there's a level at which I agree with you.  When
Sam> this came around last time, I wanted us to issue advice.

This was something I intended to send to Ian privately, not to the bug.
Apologies for the spam and for emphasis that probably doesn't help the
public discussion.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Wed, Oct 05, 2016 at 12:59:36PM +0100, Ian Jackson wrote:
>...
> I think the TC has many reasonable options.
> 
>  * You could say that you think you aren't authorised, by the
>constitution, to overrule a decision on DFSG-ness, and invite the
>petitioners to consider a GR.

In any case the TC is entitled to offer advice in the form of 
structuring the discussion and advising/helping in getting a decision.

A large part of the problem seems to be a lack of understanding what
terms like "browserified" or "minified" actually mean, and what
other related problems might exist with javascript.

Perl's Configure or SQLite are other examples of code with similar 
issues currently in Debian, and it would be helpful if the TC would 
start by gathering an overview of the different cases and how they
are similar or different.

>...
>  * With respect to Perl's Configure, one possible answer that has not
>been considered is to declare that you agree that there is a
>software freedom problem, but to distinguish the proper action with
>respect to Configure on the basis of several possible factors.  For
>example, one might argue that an exception should be made in the
>same way as we have collectively previously made exceptions for
>certain freedom problems; or that while the Perl situation is a
>problem, people agree that it should be fixed, and that it does not
>justify introducing new problems; or whatever.
>...

Not installing firmware by default is causing an enormous amount of 
trouble for users of Debian, if Debian wants to make an exception
anywhere then look no further.

For Perl's Configure I do not see so far why this would be a problem in 
any case.

The most extreme requirement I could imagine would be to strip the 
Configure from the source tarball and ship a metaconfig checkout
from the commit used for this release of Perl.

And even implementing this most extreme requirement wouldn't look
like a huge problem to me.

> Ian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

Obviously, there's a level at which I agree with you.
When this came around last time, I wanted us to issue advice.

The advice I wanted to issue isn't the advice you wished we issued, but
it would have at least been advice.

However, I was the only one on the TC who wanted to touch the issue.
It was quite clear from the IRC meeting that  I didn't have the support.
I think the TC did reach a consensus not to touch the general question
and give advice there.


I think it's clear that the TC believes that this package is not DFSG
free.
I think it's clear that the TC believes perl would be better if the
situation was improved.
I thought it was clear we believed perl had a DFSG issue, although IRC
discussion today makes that less clear.
I don't think the value of having the TC formally say any of those
specific things is very high.

I don't think having a formal vote to confirm the TC consensus to say
nothing does much
good.
I do think such an outcome would accurately represent the current
thinking of the TC as a body.
I haven't seen anyone who has reviewed the log claim otherwise.


I also don't think asking for a formal vote in a situation where there
is a clear consensus is the right way to ask someone to change their
mind.
I think the TC is making the wrong call here.
So do you.



I guess I don't mind that you're bringing that up again.  I'll be
delighted if it changes peoples' minds.

I don't entirely know what I'm saying.  Perhaps just expressing
disappointment in this overall process.

--Sam

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#839570: Browserified javascript and DFSG 2 
(reopening)"):
> Would the following ballot be a better fit ?
> ==
> C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
> FD: Further Discussion
> ==

I think this would be an extremely unsatisfactory outcome.

Once again, we have a situation of ongoing disagreement.  It runs on
and on.  The people involved are trying to properly escalate the
situation.  If the TC produces this unrationalised dismissal, the
dispute will continue to rumble on.

It must also be very frustrating for the petitioners that the
decisionmaking process is deflecting their arguments, and not engaging
properly even to state disagreement.  The point about Perl's Configure
is very well made.

Personally I actually disagree with the petitioners as to the right
action to take, but I think they are entitled to a proper resolution
of their complaint.

I think the TC has many reasonable options.

 * You could say that you think you aren't authorised, by the
   constitution, to overrule a decision on DFSG-ness, and invite the
   petitioners to consider a GR.

 * You could say whether or not you actually agree with the
   petitioners about the DFSG-freenees of the browswerified JS.  If
   your decision is that the JS is non-free then you should explicitly
   express some opinion about the situation with Perl's Configure.

 * If you agree with the petitioners and think you are
   constitutionally authorised, you could resolve to overrule.  I
   doubt anyone would gainsay the TC, other than by GR.  If you agree
   with the petitioners and don't think you are constitutionally
   authorised, you could issue advice.

 * With respect to Perl's Configure, one possible answer that has not
   been considered is to declare that you agree that there is a
   software freedom problem, but to distinguish the proper action with
   respect to Configure on the basis of several possible factors.  For
   example, one might argue that an exception should be made in the
   same way as we have collectively previously made exceptions for
   certain freedom problems; or that while the Perl situation is a
   problem, people agree that it should be fixed, and that it does not
   justify introducing new problems; or whatever.

 * If you feel that the issue isn't ripe because ftpmaster haven't
   formally made a decision, then TC members should explicitly invite
   ftpmaster to provide a decision (and there should be a deadline
   set).  I agree with the complaint that this point, as taken so far
   by members of the TC, is overly bureaucratic.

If the TC can't get consensus on any particular form of words, then
the right answer is not to try to gain consensus on dismissing the
petitioner with no explanation.

Instead, if there is not consensus on the various questions raised by
the petitioner, the TC should vote on various suitable options.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   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.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Pirate Praveen]

On 2016, ഒക്‌ടോബർ 4 7:49:28 PM IST, Sam Hartman  wrote:
>You're asking questions that don't make sense from a p.process
>standpoint, doing things that have a very low probability of making
>anyone happy, 

A quick update, I have asked ftp masters to make a ruling on the issue. #839801.

I feel these responses make TC more like a bureaucracy, where focus is given on 
process and having people to go around asking many people.

I have to go now, will try to reply in detail later.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Tue, Oct 04, 2016 at 05:54:55PM -0400, Sam Hartman wrote:
>> > "Adrian" == Adrian Bunk  writes:
>> 
Adrian> In other words, the best way forward for getting any
Adrian> decision would be an RC bug against perl claiming that the
Adrian> Configure script is not DFSG-free.
>> 
>> This RC bug was filed, and I think everyone involved including
>> the Perl maintainers agreed it was RC.
>> 
>> I'd be really surprised if the TC or FTP team disagreed about our
>> need to be able to regenerate the perl configure script using
>> tools only in Debian.

Adrian> RC bug #762638 was resolved with
Adrian> 
https://sources.debian.net/src/perl/5.24.1~rc3-3/debian/README.source/#L128

Sigh.
I'm entirely unsatisfied by that conclusion and disagree with the Perl
maintainer's decision.

I think that if the metaconfig.git sources for the version of perl in
Debian were also in Debian,
then the README.source discussion would be sufficient.

Adrian> Are you saying Pirate Praveen could also use this solution
Adrian> for browserified javascript in main?

No.
The circumstances are different in nontrivial details and I think the Perl
maintainer is wrong.

--Sam

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Tue, Oct 04, 2016 at 05:54:55PM -0400, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk  writes:
> 
> Adrian> In other words, the best way forward for getting any
> Adrian> decision would be an RC bug against perl claiming that the
> Adrian> Configure script is not DFSG-free.
> 
> This RC bug was filed, and I think everyone involved including the Perl
> maintainers agreed it was RC.
> 
> I'd be really surprised if the TC or FTP team disagreed about our need
> to be able to regenerate the perl configure script using tools only in
> Debian.

RC bug #762638 was resolved with
  https://sources.debian.net/src/perl/5.24.1~rc3-3/debian/README.source/#L128

Are you saying Pirate Praveen could also use this solution for 
browserified javascript in main?

Or are you saying that you will reopen #762638?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> In other words, the best way forward for getting any
Adrian> decision would be an RC bug against perl claiming that the
Adrian> Configure script is not DFSG-free.

This RC bug was filed, and I think everyone involved including the Perl
maintainers agreed it was RC.


I'd be really surprised if the TC or FTP team disagreed about our need
to be able to regenerate the perl configure script using tools only in
Debian.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>...
> Here are some factors to consider:
> 
> 1)  It's not clear to several TC members that the FTP team has decided
> on this question.  It seems fairly clear how they would decide if they
> did decide, but from a process standpoint, it's important to have a
> formal dialogue with them before they are overruled.
> 
> 2) It's not clear constitutionally that the TC can overrule the ftp
> team's decision regarding whether something is DFSG-free.  Even if we
> could, it's not clear that is a technical decision in our scope.
> So, asking the TC to overrule such a decision is asking for the hardest
> political choice possible in such a situation--a really hard sell within
> the project and the TC.
> 
> 3) We'd need a rationale for overruling someone.  That might not be a
> strict requirement, but if we're going to say that "browserified
> javascript" is DFSG-free, what exactly are we saying?  There was a
> discussion of what is source code, with a number of different
> considerations brought up.  Something that was responsive to that part
> of the discussion would be a lot more likely to move things forward than
> simply an assertion.  I don't even have a clear enough understanding of
> what browserified means to have any understanding of what a ruling based
> on those terms would mean.  Put another way, the TC is more comfortable
> acting when it's building a coherent policy that fits together.  To gain
> traction, a ruling almost certainly needs to fit into some intellectual
> framework about what source means.  It's quite unlikely that we'd decide
> something was source simply because it would be inconvenient for us and
> our users if it were not source.
> User convenience is something we're likely to consider, but "source is
> what we need source to be so things work well for users," is going to be
> a really improbable sell.

In other words, the best way forward for getting any decision would be 
an RC bug against perl claiming that the Configure script is not DFSG-free.

If anyone disputes that perl is not DFSG-free due to the Configure 
script, "Is the perl Configure script DFSG-free?" would be a clear 
question that could be escalated to FTP/TC/GR.

This is also a case where it would be easier for you to get a clear 
understanding.

The relevant part of #762638 is:
  Clearly perl isn't going to be kicked out of Debian because of this,
  but a less important package might well be.

That is exactly the problem here - browserified javascript is
not important enough, so FTP team and TC are getting away with
not making a decision.

Pirate Praveen is simply doing the wrong thing by pursuing a path
where everyone is just trying to avoid making a an explicit decision,
sustaining an implicit decision against him.

perl is important enough that noone would get away with not making a 
decision, and the only realistic way forward for browserified javascript 
would be to force a decision whether or not the perl Configure script is 
DFSG-free.

After forcing a decision on perl, there will be decisions that would 
also settle the main questions regarding browserified javascript.

If anyone thinks that this hardball approach would not be necessary, 
please describe to Pirate Praveen a better way for getting an explicit 
decision in time for stretch.

If you want to build a coherent policy for that, that policy would of 
course equally apply to other similar cases like the perl Configure
or SQLite, so there is nothing bad about starting the process with
the perl Configure.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

Dear joseph:

This message will be hurried: I'm on a train and approaching my stop.


Thanks for your detailed message.  I don't agree with all of it, but I
find it a lot easier to interact with than some of the requests we've
gotten related to this issue.

Here are some factors to consider:

1)  It's not clear to several TC members that the FTP team has decided
on this question.  It seems fairly clear how they would decide if they
did decide, but from a process standpoint, it's important to have a
formal dialogue with them before they are overruled.

2) It's not clear constitutionally that the TC can overrule the ftp
team's decision regarding whether something is DFSG-free.  Even if we
could, it's not clear that is a technical decision in our scope.
So, asking the TC to overrule such a decision is asking for the hardest
political choice possible in such a situation--a really hard sell within
the project and the TC.

3) We'd need a rationale for overruling someone.  That might not be a
strict requirement, but if we're going to say that "browserified
javascript" is DFSG-free, what exactly are we saying?  There was a
discussion of what is source code, with a number of different
considerations brought up.  Something that was responsive to that part
of the discussion would be a lot more likely to move things forward than
simply an assertion.  I don't even have a clear enough understanding of
what browserified means to have any understanding of what a ruling based
on those terms would mean.  Put another way, the TC is more comfortable
acting when it's building a coherent policy that fits together.  To gain
traction, a ruling almost certainly needs to fit into some intellectual
framework about what source means.  It's quite unlikely that we'd decide
something was source simply because it would be inconvenient for us and
our users if it were not source.
User convenience is something we're likely to consider, but "source is
what we need source to be so things work well for users," is going to be
a really improbable sell.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

Dear Pirate:

I hear that you're fairly frustrated by the response you're getting from
the TC.

Speaking as someone who has read extensively the earlier bug log, I
think that your cause would be advanced by getting an additional primary
advocate who has a better understanding of what the TC can do, what the
TC is likely to do, and who can more articulately ask for things to
advance your position.
If Joseph were more involved in Debian, I'd suggest him as a
possibility.

You're asking questions that don't make sense from a p.process
standpoint, doing things that have a very low probability of making
anyone happy, and not responding to advice people have given you on how
to move forward.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Didier 'OdyX' Raboud]

Le mardi, 4 octobre 2016, 07.12:24 h CEST Sam Hartman a écrit :
> I'd be willing to vote on the ballot you propose.
> I disagree with your rationale for why this bug is not for the TC to
> decide.

Good. Can you outline shortly why ?

> But I agree that this bug is not for the TC to decide at this time.

Are you saying it might be for the TC to decide at a hypothetical later point 
in time when FTP Team has issued a concrete decision? Or through mediation?

> So, if that's all we're voting on, and I don't need to agree with your
> rationale to vote C, I'm fine with your ballot.

Would the following ballot be a better fit ?
==
C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
FD: Further Discussion
==

I'd like to understand where our disagreement lies though.
-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Sam Hartman]

I'd be willing to vote on the ballot you propose.
I disagree with your rationale for why this bug is not for the TC to
decide.
But I agree that this bug is not for the TC to decide at this time.
So, if that's all we're voting on, and I don't need to agree with your
rationale to vote C, I'm fine with your ballot.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Didier 'OdyX' Raboud]

Le dimanche, 2 octobre 2016, 14.29:49 h CEST Pirate Praveen a écrit :
> package: tech-ctte
> 
> Following up on #830978. I would like this to be reopened and request
> CTTE make a formal vote.

The discussion that lead to closing #830978 happened on IRC [0] , see the full 
log from line 172 [1] , and Sam put a clear rationale in the mail closing the 
bug [2]. I'll quote on specific part of it:
> With regard to the particular issue of Browserified javascript,
> particularly in the libjs-handlebars package, the best way forward is
> for the submitter to discuss the question with the FTP team.  Such a
> discussion would be less confusing if it took place after #830986 is
> resolved.

(#830986 isn't resolved)

Now, moving forwards… We decided to close the bug without a formal vote, 
because it was clear for all the present TC members that we were in agreement. 
We have also agreed (amongst us) to avoid the use of unnecessary bureaucracy 
when possible; hence our delegation to close the bug to Sam. Now, the offer to 
"repoen the bug and ask for a formal vote"  [3] stood to enable anyone to ask 
for the bug closure to respect our formal procedures (saying "please don't 
close the bug because you think you're in agreement, but run a formal vote").

For what I'm concerned, the situation hasn't evolved, and the conclusion that 
Sam outlined still stands (FTP Team is responsible for DFSG, and has decided, 
Release Team has decided DFSG is RC and has deferred DFSG-compliance 
determination to FTP Team).

I'm therefore putting the following ballot up for discussion within the TC:

==
C: Close 830978 as not being something for the TC to decide
FD: Further Discussion
==

To make things maybe clearer: we have said through the initial bug closure 
(and would be reaffirming this) that deciding about DFSG compliance is not for 
the TC to decide (we're refusing to rule about something clearly in the FTP 
Team's jurisdiction; that is).

You seem to be asking us to decide on DFSG compliance (in place of the FTP 
Team); but it's not at all clear that the constitution enables the TC to 
override Delegates or decisions made by delegates (see §6.1). We have 
recommended you (through Sam's message when closing the bug) to discuss this 
question with the FTP Team:

> With regard to the particular issue of Browserified javascript (…) the best
> way forward is for the submitter to discuss the question with the FTP team. 

Has this happened? What was the outcome?

(For completeness, if you had discussed with FTP Team, reached a point of 
disagreement, noticed that the TC would continue to decline to rule in place 
of the FTP Team, your next recourses would be to go through a GR (§4.1.3) to 
override the FTP Team's decision on interpreting DFSG for the specific cases 
you have in mind; or through amending the DFSG itself (through §4.1.5). )

-- 
Cheers,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-07-28-18.00.html
[1] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-07-28-18.00.log.html#l-172
[2] https://bugs.debian.org/830978#212 
[3] Which you didn't; you opened a new bug, anyway, let's not nitpick on 
details.

signature.asc
Description: This is a digitally signed message part.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Pirate Praveen]

On 2016, ഒക്‌ടോബർ 4 4:16:48 AM IST, Philip Hands  wrote:
>I think you need to try a little harder than that -- it is still
>unclear
>to me what you are even attempting to ask for.  Unless that changes I
>would think that the right response to this is to simply close the bug.

First, the issue is already discussed and understood in an earlier bug 
(referenced it in my first message). When that bug was closed, TC members 
suggested any member could reopen the bug if a formal vote was desired.

Second, this issue is already demoralising, and responses like this are not 
helpful. Isn't it reasonable to expect someone commenting on a bug to read the 
comments posted already?

>
>As a bare minimum, try specifying what outcome you are hoping for, with
>respect to which package.
>

libjs-handlebars, libjs-fuzzaldrin-plus and other browserified javascript 
should be allowed in main (the browserified javascript can be modified by 
anyone who understand javascript without difficulty and can satisfy dfsg 
requirement for source). This would result in diaspora, gitlab, pagure, 
prometheus (and likely other afftected packages) to be shipped in main instead 
of contrib.

But it would be better to ship the source code used by upstream (consider it as 
severity important and not serious), so we should try to package grunt for 
stretch+1 and browserify during build. 

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Mon, Oct 3, 2016 at 6:46 PM, Philip Hands  wrote:

> Pirate Praveen  writes:
> > On 2016, ഒക്‌ടോബർ 3 8:22:20 AM IST, "Joseph R. Justice" <
> jayare...@gmail.com> wrote:
>


> >>If I have misunderstood in any way Mr. Praveen's position, or if I have
> >>misrepresented in any fashion whatsoever what it is he is trying to
> >>express, then I sincerely apologize for my error.
> >>
> >>Otherwise...  I hope this is of some use, interest, in resolving this
> >>issue.  If it is, then I'm glad I could help.  Thanks for your time in
> >>reading this.  Be well, and thanks for all of y'all's efforts in
> >>creating
> >>Debian!
> >
> > Thank you Joseph, that is a good summary of the situation.
>
> I think you need to try a little harder than that -- it is still unclear
> to me what you are even attempting to ask for.  Unless that changes I
> would think that the right response to this is to simply close the bug.
>
> As a bare minimum, try specifying what outcome you are hoping for, with
> respect to which package.
>

Errr.  Mr. Hands.  Did you perhaps not see Message #15 in this bug log,
which is what Mr's Praveen's message (which you quote) is itself referring
to?  (For the record, I myself wrote Message #15.)

If you did not see this message, you can find it at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#15 .

If you did indeed see this message, did you perhaps not see the points
labeled (8a), (8b1), and (8b2) in that message, near the bottom of it?
Those points, I believe, clearly signified two alternative outcomes, namely
either (8a) or else [the combination of (8b1) and (8b2) as a set], which I
was suggesting Mr. Praveen was requesting the TC decide between.



Given that Mr. Praveen responded to Message #15 by saying "that is a good
summary of the situation", I believe I can safely say that I have, in fact,
reasonably well expressed what it is he is achieving to desire as an
outcome from this bug.  E.g. he is attempting to achieve either the outcome
described in point (8a), or failing that the outcome described in the set
of points (8b1) and (8b2).  (For what it's worth, I think it's fair to say
that Mr. Praveen has a preference as to which outcome he's like to achieve,
namely that described in (8a).  However, I believe he'd settle for the
outcome described by (8b1) and (8b2) if he cannot achieve (8a).)



As I said in Message #15, "I don't have a horse in this race".  I don't
have a preference as to which of these outcomes comes to pass; it is
irrelevant to me.  I am a disinterested bystander.

I *am*, however, a little offended that you would write, in your response
to Mr. Praveen's response to my Message #15, "it is still unclear to me
what you are even attempting to ask for".  I went to some effort to express
what I believed to be Mr. Praveen's intentions and desires in as explicit
and detailed a fashion as I could achieve.  Given Mr. Praveen's response to
my message, I believe I have in fact reasonably well correctly expressed
and explained what it is he was attempting to express in his original
message opening this bug.  I believe my Message #15 fairly and accurately
represents his position, and what he wants the TC to do.

Therefore, sir, I ask you -- what if anything is unclear to you about the
outcomes expressed in points (8a), or else (8b1) and (8b2), in Message
#15?  I would be happy to try to explain them in a different fashion, or to
attempt to clarify them, if I knew what it was specifically that was
unclear to you.

If you are asking what effect the outcomes expressed in (8a) or else (8b1)
and (8b2) would have on specific packages, well, honestly, I think that
should be self-evident given what I wrote in Message #15 to anyone who read
the entire message carefully and comprehended what was written there.
However, if you need, I will be pleased to explain what I believe the
effect of each of these distinct outcomes, (8a) or else (8b1) and (8b2),
would be on the packages referred to in Message #15 (which is simply the
list provided by Mr. Praveen himself in his original message and the bugs
referred to in his original message).

If there is any further assistance I can provide regarding this matter,
I'll be happy to provide that as well as best as I can.  Just let me know.



Thanks for your time in reading this.  Hope you find it of some use,
interest.  Again, thanks as an end-user and an outside observer for your
(actually, all of y'all's) efforts in creating, maintaining, enhancing, and
promoting Debian.  Be well.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Philip Hands]

Pirate Praveen  writes:

> On 2016, ഒക്‌ടോബർ 3 8:22:20 AM IST, "Joseph R. Justice"  
> wrote:
>>If I have misunderstood in any way Mr. Praveen's position, or if I have
>>misrepresented in any fashion whatsoever what it is he is trying to
>>express, then I sincerely apologize for my error.
>>
>>Otherwise...  I hope this is of some use, interest, in resolving this
>>issue.  If it is, then I'm glad I could help.  Thanks for your time in
>>reading this.  Be well, and thanks for all of y'all's efforts in
>>creating
>>Debian!
>
> Thank you Joseph, that is a good summary of the situation.

I think you need to try a little harder than that -- it is still unclear
to me what you are even attempting to ask for.  Unless that changes I
would think that the right response to this is to simply close the bug.

As a bare minimum, try specifying what outcome you are hoping for, with
respect to which package.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Pirate Praveen]

On 2016, ഒക്‌ടോബർ 3 8:22:20 AM IST, "Joseph R. Justice"  
wrote:
>If I have misunderstood in any way Mr. Praveen's position, or if I have
>misrepresented in any fashion whatsoever what it is he is trying to
>express, then I sincerely apologize for my error.
>
>Otherwise...  I hope this is of some use, interest, in resolving this
>issue.  If it is, then I'm glad I could help.  Thanks for your time in
>reading this.  Be well, and thanks for all of y'all's efforts in
>creating
>Debian!

Thank you Joseph, that is a good summary of the situation.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

[FWIW: I am not a Debian Developer.  I am not a Debian Maintainer.  I am
not someone who (currently) uses Debian (tho I subscribe to some of the
mailing lists), nor uses the software being discussed or referred to within
this bug.  I don't have a horse in this race.  I do, however, have Male
Answer Syndrome, and I'm not afraid to use it!]


On Sun, Oct 2, 2016 at 2:50 PM, Tollef Fog Heen  wrote:

> ]] Pirate Praveen
>
> > Following up on #830978. I would like this to be reopened and request
> > CTTE make a formal vote.
>
> What is the exact question you're trying to get us to answer?  Are you
> asking us for advice, are you asking us to overrule a developer or
> something else?'
>

Having reread the bug log for 830978 and I think most if not all of what's
referenced there (tho not any broader discussions in d-devel), I *believe*
what Mr. Praveen (my apologies if I'm referring to hir incorrectly) is
trying to get at is the following:

(1) The current position of the FTP team is that software proposed to be
distributed by Debian which:
(1a) has source code written in Javascript,
(1b) where the Javascript source code as distributed by Debian for the
software would be "browserified",
(1c) where the Javascript source code as released by the original author of
the software is *not* "browserified",
(1d) where there is no tool or set of tools currently packaged within the
Debian "main" archive which is capable of taking the Javascript source code
described by (1c) and transforming it into the form described by (1b),
(1e) is not suitable for distribution by Debian within the main archive,
because such software does not meet the requirements of the DFSG in terms
of source code availability.  However,
(1f) such software might be suitable for distribution in the "non-free"
archive if there is no reason prohibiting it from being distributed in
non-free.

One such software affected by this is a library package Mr. Praveen was
involved in packaging, libjs-handlebars.  (Its source is
ruby-handlebars-assets, and that source is currently in non-free.)
 Diaspora, which I believe Mr. Praveen was involved in packaging, depends
on libjs-handlebars.

There is apparently the software application "grunt" which is capable of
resolving the point in (1d) in a satisfactory fashion.  (E.g. if grunt
existed in main, (1d) and therefore (1) as a whole would be moot.)
 However, this application is not currently in the Debian main archive, and
presumably there is no hope of getting it into shape to be added to the
main archive in time for the release of Debian "Stretch".

There is also apparently no hope of creating some other software capable of
doing what grunt would do to resolve the point in (1d) in satisfactory
fashion in time for the release of Debian Stretch.

(2) There is other software currently in Debian (presumably in the main
archive), or proposed to be in Debian, which would be affected by the
reasoning in (1).

Bug 814871 refers to libjs-fuzzaldrin-plus, which is depended upon by
gitlab.  Apparently gitlab needs libjs-fuzzaldrin-plus to be in
browserified form and that form cannot yet be created within / by Debian.

Bug 829046 refers to unspecified Javascript libraries which depend on
"grunt" (which itself is not currently in Debian), which are bundled by and
therefore depended upon by pagure (which has an ITP); presumably the
dependency on grunt means that these unspecified Javascript libraries are
used in a browserified form.

Bug 835661 refers again to libjs-handlebars, this time being depended upon
by prometheus.

All these library packages would, per (1), have to be distributed in the
non-free archive.  Presumably at least some of these libraries are
currently being distributed in the main archive.

(3) The current position of the FTP team is that software proposed to be
distributed by Debian which
(3a) depends on software which is not available in the Debian main archive
(3b) cannot itself be distributed in the Debian main archive.  However,
(3c) such software might be suitable for distribution in the "contrib"
archive if the only reason it cannot be distributed in the main archive is
because it depends on software not found in the main archive.

(4) The software depending on the items affected by (1) and (2), e.g.
Diaspora, GitLab, Pagure, and Prometheus, will therefore have to be
distributed in the contrib archive, and moved from the main archive to
contrib if it is currently already in main.

Mr. Praveen further hypothesizes that there will be a number of other
important pieces of software, either already in main or that people would
like to distribute in main, which will have to be moved to contrib and/or
distributed in contrib because they are affected by the same issue: they
depend on other software written in Javascript which is affected by the
issues raised in (1) and (2) and which therefore can only be distributed in
non-free (assuming it is otherwise distributable in the first place).

(5) Mr. 

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] Pirate Praveen 

> Following up on #830978. I would like this to be reopened and request
> CTTE make a formal vote.

What is the exact question you're trying to get us to answer?  Are you
asking us for advice, are you asking us to overrule a developer or
something else?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Pirate Praveen]

package: tech-ctte

Following up on #830978. I would like this to be reopened and request
CTTE make a formal vote.

Because, every major web based software will have to be moved to contrib
because its likely at least one of the javascript dependencies are in
browserified form.

1. Diaspora is already moved to contrib because of libjs-handlebars
2. GitLab will need to be moved to contrib #814871
3. Pagure will have to be in contrib #829046
4. Prometheus will need to be moved to contrib #835661

There will be more if we look at all packages depending on javascript
libraries or embedding them.

It is not realistic to expect Grunt will be packaged for stretch or
reimplement the same functionality for all browserified packages.

This will encourage more people to depend on non-free/contrib and I
don't think debian community wants to move in that direction. If that is
really what the community wants, I want it formally declared

I suggest including browserified js in stretch and make an effort to
package grunt for stretch+1.







signature.asc
Description: OpenPGP digital signature