Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread Emilien Klein
2014-03-28 0:28 GMT+01:00 Ben Finney :
> Emilien Klein  writes:
>
>> Let's take the example of jquery-lazyload [0].
>>
>> Both these files are provided in the upstream tarball:
>> - jquery.lazyload.js
>> - jquery.lazyload.min.js
>>
>> With the second one being the minified form of the first one.
>
> How will you guarantee that ‘jquery.lazyload.js’ is the corresponding
> source for the file ‘jquery.lazyload.min.js’? How will you guarantee
> that holds true every time a new version is released upstream?

As we can't make sure we're minimizing the file exactly the same way
upstream does, would comparing doubly-minified files work (I need to
try, but no suitable computer had hand just now):

Provided by upstream:
- File A: unminified .js
- File B: Upstream-provided .min.js

Debian minifies file A:
File C: Debian-minified file A

Debian minifies files B and C with the same options (e.g. drop
copyright notice) to get at the same minified content:
File D: Debian-minified file C
File E: Debian-minified file B

Validation check:
If File D and File E are equal, then we can assure file B was minified
from file A by upstream.

I'll try this out for lazyload and report back.

Should the check fail, the package does not build (and then we
repackage). Recheck by next package to see if repackageing is still
necessary.

I feel there is more value in shipping the upstream tarball (if we can
assure the minified file comes from the supplied source), as
repackaging is an extra step that could theoretically go wrong.

+Emilien

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

Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread Ben Finney
Ben Finney  writes:

> There is a method for [ensuring that every Debian release of the
> source package ships no files without corresponding source]:
>
> Don't distribute the minified file from upstream; instead, distribute
> only the source form of the work, and compile a minified file during
> the build of the binary package.
>
> What other method do you propose for keeping our promise in the Social
> Contract? Does it meet that promise with as much certainty as the method
> I propose above?

Emilien Klein  writes:

> 2014-03-28 0:28 GMT+01:00 Ben Finney :
> > Emilien Klein  writes:
> >
> >> Let's take the example of jquery-lazyload [0].
> >>
> >> Both these files are provided in the upstream tarball:
> >> - jquery.lazyload.js
> >> - jquery.lazyload.min.js
> >>
> >> With the second one being the minified form of the first one.
> >
> > How will you guarantee that ‘jquery.lazyload.js’ is the corresponding
> > source for the file ‘jquery.lazyload.min.js’? How will you guarantee
> > that holds true every time a new version is released upstream?
>
> As we can't make sure we're minimizing the file exactly the same way
> upstream does, would comparing doubly-minified files work (I need to
> try, but no suitable computer had hand just now): […]
>
> Validation check:
> If File D and File E are equal, then we can assure file B was minified
> from file A by upstream.
>
> I'll try this out for lazyload and report back.
>
> Should the check fail, the package does not build (and then we
> repackage). Recheck by next package to see if repackageing is still
> necessary.

This is significantly more complex and more prone to false positives,
than simply dropping the non-source files from the source package, as I
propose.

> I feel there is more value in shipping the upstream tarball (if we can
> assure the minified file comes from the supplied source), as
> repackaging is an extra step that could theoretically go wrong.

I think you're engaging in wishful thinking. The process you propose has
more steps to go wrong, and more points of potential error, than simply
dropping the non-source files from the source package.

-- 
 \ “If nature has made any one thing less susceptible than all |
  `\others of exclusive property, it is the action of the thinking |
_o__)  power called an idea” —Thomas Jefferson |
Ben Finney


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

Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread Emilien Klein
2014-03-29 9:17 GMT+01:00 Ben Finney :
> This is significantly more complex and more prone to false positives,
> than simply dropping the non-source files from the source package, as I
> propose.

I'm not saying it's even working. I am suggesting a potential solution
to getting the response to "is the upstream-provided minified file
coming from the same source?".

I don't agree that it would be more complex: 2 calls to uglifyjs, and
one to diff.
Compare that to the 18 lines (and I'm not including the other 10 `rm`
lines in there) that are needed for repackaging (example from flotjs
[0]), including calls to awk and sed ;)

[0] 
http://anonscm.debian.org/gitweb/?p=pkg-javascript/flot.git;a=blob;f=debian/rules;h=83670cf0ec4aaec4817d6f2eb68d0756d85ac553;hb=HEAD

>> I feel there is more value in shipping the upstream tarball (if we can
>> assure the minified file comes from the supplied source), as
>> repackaging is an extra step that could theoretically go wrong.
>
> I think you're engaging in wishful thinking. The process you propose has
> more steps to go wrong, and more points of potential error, than simply
> dropping the non-source files from the source package.

Well, my original suggestion is indeed much more simple than the
verification of upstream validity and the current policy to repackage:
leave the minified files in, as released by upstream under a license
that allows explicitly allows its redistribution.

As I've tried to explain before, I don't see what in DFSG §2 prevents
the inclusion of the minified file:

From https://www.debian.org/social_contract.en.html
Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form.

I argue that a tarball that contains the source for the program, along
with a minified file next to it is fulfilling "The program must
include source code".
As explained before as well, the minified file is provided by upstream
as a convenience to it's users, it's implicitly coming from the source
of the program.

DFSG §2 does not say something along the lines "The program must
*only* include the source code, excluding any files included by
upstream for the convenience of the user"

I feel we are stuck. In the intent to bring this discussion to a
close, would you strongly disagree if I ask the question on the -devel
mailing list?
I feel it would be beneficial (regardless of the way in which the
discussion goes there) to include developers that might have a broader
view of the landscape, maybe a bit less down into the specifics of js
packaging as we are. We can then record the final decision on our
policy page and close out this time-consuming discussion.

Have a great Saturday!
   +Emilien

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

Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread Emilien Klein
2014-03-29 9:57 GMT+01:00 Emilien Klein :
> I feel we are stuck. In the intent to bring this discussion to a
> close, would you strongly disagree if I ask the question on the -devel
> mailing list?

Let me rephrase that:
I will send a draft of the email on our js mailing list, presenting
both sides on this question.
All will have a say to make this better, and then I'll send it to -devel.

I'll likely have some time this afternoon.
   +Emilien


> I feel it would be beneficial (regardless of the way in which the
> discussion goes there) to include developers that might have a broader
> view of the landscape, maybe a bit less down into the specifics of js
> packaging as we are. We can then record the final decision on our
> policy page and close out this time-consuming discussion.
>
> Have a great Saturday!
>+Emilien

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


Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread Jonas Smedegaard
Quoting Emilien Klein (2014-03-29 09:57:20)
> 2014-03-29 9:17 GMT+01:00 Ben Finney :
>>> I feel there is more value in shipping the upstream tarball (if we 
>>> can assure the minified file comes from the supplied source), as 
>>> repackaging is an extra step that could theoretically go wrong.
>>
>> I think you're engaging in wishful thinking. The process you propose 
>> has more steps to go wrong, and more points of potential error, than 
>> simply dropping the non-source files from the source package.
>
> Well, my original suggestion is indeed much more simple than the 
> verification of upstream validity and the current policy to repackage: 
> leave the minified files in, as released by upstream under a license 
> that allows explicitly allows its redistribution.

...and blindly assume that source and minified file corresponds.


> As I've tried to explain before, I don't see what in DFSG §2 prevents 
> the inclusion of the minified file:

Correct - it does not prevent that.  We never said it prevents that.  
What it does is require source for any and all files we distribute.


> I argue that a tarball that contains the source for the program, along 
> with a minified file next to it is fulfilling "The program must 
> include source code".

That is quite possible, but not certain.


> DFSG §2 does not say something along the lines "The program must 
> *only* include the source code, excluding any files included by 
> upstream for the convenience of the user"

I fully agree.

I do not agree in blindly trusting upstream, however.


> I feel we are stuck. In the intent to bring this discussion to a 
> close, would you strongly disagree if I ask the question on the -devel 
> mailing list?
> I feel it would be beneficial (regardless of the way in which the 
> discussion goes there) to include developers that might have a broader 
> view of the landscape, maybe a bit less down into the specifics of js 
> packaging as we are. We can then record the final decision on our 
> policy page and close out this time-consuming discussion.

I recommend you to try address the questions raised by Ben.  Feel free 
to escalate to d-devel, but don't expect to have better luck there.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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

Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread Marcelo Jorge Vieira
Hello,

On Sat, 2014-03-29 at 10:33 +0100, Emilien Klein wrote:
> 2014-03-29 9:57 GMT+01:00 Emilien Klein :
> > I feel we are stuck. In the intent to bring this discussion to a
> > close, would you strongly disagree if I ask the question on the -devel
> > mailing list?
> 
> Let me rephrase that:
> I will send a draft of the email on our js mailing list, presenting
> both sides on this question.
> All will have a say to make this better, and then I'll send it to -devel.

Just to remember, two year ago this topic was discussed in the
debian-devel list.

https://lists.debian.org/debian-devel/2012/08/threads.html#00365


Cheers,

-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com


signature.asc
Description: This is a digitally signed message part
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] JavaScript policy?

2014-03-29 Thread François-Régis
Hi Marcello, Hi Emilien

Le 29/03/2014 22:33, Marcelo Jorge Vieira a écrit :
> On Sat, 2014-03-29 at 10:33 +0100, Emilien Klein wrote:
>> 2014-03-29 9:57 GMT+01:00 Emilien Klein :
>>> I feel we are stuck. In the intent to bring this discussion to a
>>> close, would you strongly disagree if I ask the question on the -devel
>>> mailing list?
>>
>> Let me rephrase that:
>> I will send a draft of the email on our js mailing list, presenting
>> both sides on this question.
>> All will have a say to make this better, and then I'll send it to -devel.
> 
> Just to remember, two year ago this topic was discussed in the
> debian-devel list.
> 
> https://lists.debian.org/debian-devel/2012/08/threads.html#00365

Thank you Marcello for this very interesting thread. By the way it's not
addressing exactly the question of *this* thread. It originally talks
about sources tarball providing minified files and no sources (and where
evently sources could exists elsewhere in debian).

As initiator of the thread, I may recall that the question we ask is
"Should we remove from source tarball minified versions of source files
existing in tarball". And of course nobody imagines to use those
minified files in binary package.

In the current thread, David clearly says we can keep them [1] and Ben
[2] suggests that it's better to remove the minified files from orig
tarball. And in an other thread [3], Marcello said we have to remove them.

[1]
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007214.html
[2]
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007242.html
[3]
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007176.html

-

I've detail read the thread from Marcello which is mainly beside the
subject we are talking about and without quoting too much, what I've
understood is that providing both source and minified version makes a
consensus. I may have a wrong undestanding of the discussion so if
anybody else could have look and gives return...

Beside, the question of the trust we can have on the fact that the
minified file is safe, which Emilien propose to verify, is only adressed
to people using source package outside debian, and from this POV, we may
perhaps make some checks as these are kinds of executable files. But we
just feel happy when we have xcf, scg or what else source for jpeg, png,
tiff or whatever format and we are still unable to prove that they are
"compile" from sources.

Hope that this until "-" will help to the clearify the question.

Cheers,


-- 
François-Régis



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