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.)

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

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

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

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.

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

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

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

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