Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Paul Wise]

On Wed, 2016-01-06 at 16:55 +0100, Ximin Luo wrote:

> Do you have a more solid lead that we can chase down?

Jonathan Ulrich Horn 

Jonathan started by packaging getobject: #809983/#810107


> I don't see why you think this as a DFSG issue?

The source is missing, only the generated otr.js is present.
Also, even if the source were present the source isn't buildable using
only software in Debian main.

>  This is an embedding issue, and there have been exceptions made
> before for this.

I'd rather this file didn't have to get any bigger:

https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co
https://wiki.debian.org/EmbeddedCodeCopies

> Well, it is still emitting this warning for that file (1 long line
> out of 2600 short lines [1]) currently. If any pending versions of
> lintian in git would not do this, then please add a pending tag and
> close this bug of course.

Personally I'm glad this lintian warning is a bit over-zealous, since
it points out missing source code quite often and if the line length
check was removed then it wouldn't have pointed out the source is
missing in your case, when it should actually do that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Ximin Luo]

On 06/01/16 14:02, Ximin Luo wrote:
> On Tue, 05 Jan 2016 20:12:12 +0800 Paul Wise  wrote:
>> On Tue, 05 Jan 2016 11:20:45 + u wrote:
>>
>>> cryptocat source: source-is-missing chrome/content/data/js/lib/otr.js
>>
>> This is an embedded code copy and should be packaged separately:

Also, in terms of lintian and this bug report, *it is still a bug in lintian*. 
It would still give a false positive even if otr.js is packaged correctly. This 
is also triggered by some other JS stuff I have been packaging.

I would suggest that lintian be amended, so that if the file is >20-50 lines, 
and there are only 1-2 of these "long lines", then no error/warning is emitted.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Ximin Luo]

On Tue, 05 Jan 2016 20:12:12 +0800 Paul Wise  wrote:
> On Tue, 05 Jan 2016 11:20:45 + u wrote:
> 
> > cryptocat source: source-is-missing chrome/content/data/js/lib/otr.js
> 
> This is an embedded code copy and should be packaged separately:
> 
> https://github.com/arlolra/otr
> https://wiki.debian.org/EmbeddedCodeCopies
> 
> It is also generated from other files:
> 
> Â  This file is concatenated for the browser.
> 
> The build process is defined here:
> 
> https://github.com/arlolra/otr/blob/master/gruntfile.js
> 
> This requires grunt, which isn't yet in Debian.
> 

Grunt is going to take a while to package, due to the wider JS ecosystem being 
generally stupid, over-bloated and self-important far beyond its worth.

https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt

(For example, I very much doubt someone is going to maintain a debian package 
for a JS npm package whose only purpose and ability is to check if 
number-is-nan. Also, lol @ the meow -> indent-string -> repeating -> meow 
cyclic dependency.)

Could we just make an exception at this time for this OTR.js embedded copy? We 
can add very loud notices to debian/TODO and debian/rules saying that this 
should be fixed whenever otr.js is packaged properly, hopefully once we 
convince upstream to move away from Grunt.

X

[1] Seriously, WHO THE FUCK WRITES THIS SHIT???

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Paul Wise]

On Wed, 2016-01-06 at 14:02 +0100, Ximin Luo wrote:

> Grunt is going to take a while to package, due to the wider JS
> ecosystem being generally stupid, over-bloated and self-important far
> beyond its worth.

I spoke to someone on IRC who was working on it the other day, it
sounded like they were close, just packaging another 1KB JS file.

> (For example, I very much doubt someone is going to maintain a debian
> package for a JS npm package whose only purpose and ability is to
> check if number-is-nan. Also, lol @ the meow -> indent-string ->
> repeating -> meow cyclic dependency.)

Uh, #797455

> Could we just make an exception at this time for this OTR.js embedded
> copy? We can add very loud notices to debian/TODO and debian/rules
> saying that this should be fixed whenever otr.js is packaged
> properly, hopefully once we convince upstream to move away from
> Grunt.

I don't think the DFSG has exceptions :)

> [1] Seriously, WHO THE FUCK WRITES THIS SHIT???

It is a different world from a different age, completely disconnected
with the world of Linux distros. Unfortunately those people are the new
Open Source ecosystem and abhor the distros and how we do things.

> Also, in terms of lintian and this bug report, *it is still a bug in
> lintian*. It would still give a false positive even if otr.js is
> packaged correctly. This is also triggered by some other JS stuff I
> have been packaging.

Agreed, but it is a bit much to expect lintian to be false-positive free.

> I would suggest that lintian be amended, so that if the file is >20-
> 50 lines, and there are only 1-2 of these "long lines", then no
> error/warning is emitted.

IIRC it already has been toned down.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Ximin Luo]

On 06/01/16 15:26, Paul Wise wrote:
> On Wed, 2016-01-06 at 14:02 +0100, Ximin Luo wrote:
> 
>> Grunt is going to take a while to package, due to the wider JS
>> ecosystem being generally stupid, over-bloated and self-important far
>> beyond its worth.
> 
> I spoke to someone on IRC who was working on it the other day, it
> sounded like they were close, just packaging another 1KB JS file.
> 

Do you have a more solid lead that we can chase down?

>> (For example, I very much doubt someone is going to maintain a debian
>> package for a JS npm package whose only purpose and ability is to
>> check if number-is-nan. Also, lol @ the meow -> indent-string ->
>> repeating -> meow cyclic dependency.)
> 
> Uh, #797455
> 

"maintain" is more than filing an ITP and uploading the initial package, it 
means making sure that other things continually work well with it across 
multiple versions, and when it is finally obsolete to see it get removed 
cleanly. Cost is important too. I would take good bets that the person 
intending to do this upload will go AWOL and drop the whole deal in 1-2 years, 
because the cost of maintaining npm bullshit is simply not worth the benefits.

>> Could we just make an exception at this time for this OTR.js embedded
>> copy? We can add very loud notices to debian/TODO and debian/rules
>> saying that this should be fixed whenever otr.js is packaged
>> properly, hopefully once we convince upstream to move away from
>> Grunt.
> 
> I don't think the DFSG has exceptions :)
> 

I don't see why you think this as a DFSG issue? This is an embedding issue, and 
there have been exceptions made before for this. If we can package Grunt soon, 
then ok we can wait, but my previous experience working with JS packages makes 
me strongly want to avoid this road.

>> [1] Seriously, WHO THE FUCK WRITES THIS SHIT???
> 
> It is a different world from a different age, completely disconnected
> with the world of Linux distros. Unfortunately those people are the new
> Open Source ecosystem and abhor the distros and how we do things.
> 

I wouldn't say they're the "new ecosystem" just yet, and "new" does not imply 
"better". In particular, that ecosystem does not understand the concept of 
long-term maintenance cost. Not discouraging packages whose metadata is larger 
in size than the data, not supporting forked version trees to backport 
bugfixes, etc, wastes massive amounts of time and effort in the end, which may 
be a good deal for the developers getting paid to waste this effort, but is not 
good for users and developers that want to see the overall FOSS ecosystem 
progress technologically.

>> Also, in terms of lintian and this bug report, *it is still a bug in
>> lintian*. It would still give a false positive even if otr.js is
>> packaged correctly. This is also triggered by some other JS stuff I
>> have been packaging.
> 
> Agreed, but it is a bit much to expect lintian to be false-positive free.
> 

Of course not for all warnings; but the warning for this specifically tells 
people to file bugs against lintian:

https://lintian.debian.org/tags/source-is-missing.html

>> I would suggest that lintian be amended, so that if the file is >20-
>> 50 lines, and there are only 1-2 of these "long lines", then no
>> error/warning is emitted.
> 
> IIRC it already has been toned down.
> 

Well, it is still emitting this warning for that file (1 long line out of 2600 
short lines [1]) currently. If any pending versions of lintian in git would not 
do this, then please add a pending tag and close this bug of course.

X

[1] 
https://anonscm.debian.org/cgit/pkg-mozext/cryptocat.git/tree/chrome/content/data/js/lib/otr.js

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Bastien Roucaries]

Le 6 janvier 2016 16:55:19 GMT+01:00, Ximin Luo  a écrit :
>On 06/01/16 15:26, Paul Wise wrote:
>> On Wed, 2016-01-06 at 14:02 +0100, Ximin Luo wrote:
>> 
>>> Grunt is going to take a while to package, due to the wider JS
>>> ecosystem being generally stupid, over-bloated and self-important
>far
>>> beyond its worth.
>> 
>> I spoke to someone on IRC who was working on it the other day, it
>> sounded like they were close, just packaging another 1KB JS file.
>> 
>
>Do you have a more solid lead that we can chase down?
>
>>> (For example, I very much doubt someone is going to maintain a
>debian
>>> package for a JS npm package whose only purpose and ability is to
>>> check if number-is-nan. Also, lol @ the meow -> indent-string ->
>>> repeating -> meow cyclic dependency.)
>> 
>> Uh, #797455
>> 
>
>"maintain" is more than filing an ITP and uploading the initial
>package, it means making sure that other things continually work well
>with it across multiple versions, and when it is finally obsolete to
>see it get removed cleanly. Cost is important too. I would take good
>bets that the person intending to do this upload will go AWOL and drop
>the whole deal in 1-2 years, because the cost of maintaining npm
>bullshit is simply not worth the benefits.
>
>>> Could we just make an exception at this time for this OTR.js
>embedded
>>> copy? We can add very loud notices to debian/TODO and debian/rules
>>> saying that this should be fixed whenever otr.js is packaged
>>> properly, hopefully once we convince upstream to move away from
>>> Grunt.
>> 
>> I don't think the DFSG has exceptions :)
>> 
>
>I don't see why you think this as a DFSG issue? This is an embedding
>issue, and there have been exceptions made before for this. If we can
>package Grunt soon, then ok we can wait, but my previous experience
>working with JS packages makes me strongly want to avoid this road.
>
>>> [1] Seriously, WHO THE FUCK WRITES THIS SHIT???
>> 
>> It is a different world from a different age, completely disconnected
>> with the world of Linux distros. Unfortunately those people are the
>new
>> Open Source ecosystem and abhor the distros and how we do things.
>> 
>
>I wouldn't say they're the "new ecosystem" just yet, and "new" does not
>imply "better". In particular, that ecosystem does not understand the
>concept of long-term maintenance cost. Not discouraging packages whose
>metadata is larger in size than the data, not supporting forked version
>trees to backport bugfixes, etc, wastes massive amounts of time and
>effort in the end, which may be a good deal for the developers getting
>paid to waste this effort, but is not good for users and developers
>that want to see the overall FOSS ecosystem progress technologically.
>
>>> Also, in terms of lintian and this bug report, *it is still a bug in
>>> lintian*. It would still give a false positive even if otr.js is
>>> packaged correctly. This is also triggered by some other JS stuff I
>>> have been packaging.
>> 
>> Agreed, but it is a bit much to expect lintian to be false-positive
>free.
>> 
>
>Of course not for all warnings; but the warning for this specifically
>tells people to file bugs against lintian:
>
>https://lintian.debian.org/tags/source-is-missing.html
>
>>> I would suggest that lintian be amended, so that if the file is >20-
>>> 50 lines, and there are only 1-2 of these "long lines", then no
>>> error/warning is emitted.
>> 
>> IIRC it already has been toned down.
>> 
>
>Well, it is still emitting this warning for that file (1 long line out
>of 2600 short lines [1]) currently. If any pending versions of lintian
>in git would not do this, then please add a pending tag and close this
>bug of course.
>
>X
>
>[1]
>https://anonscm.debian.org/cgit/pkg-mozext/cryptocat.git/tree/chrome/content/data/js/lib/otr.js



Does this line is one of the prime compromises but thé nsa?
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[u]

Package: lintian
Version: 2.5.38.1
Severity: normal

In the packaging for the Cryptocat extension, there is a false positive.

The file is source code but contains a very long line that is a
cryptographic
constant
cryptocat source: source-is-missing chrome/content/data/js/lib/otr.js

https://anonscm.debian.org/cgit/pkg-mozext/cryptocat.git/

Cheers!


-- System Information:
Debian Release: stretch/sid
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#810000: lintian: False positive source-is-missing for cryptocat/otr.js

[Paul Wise]

On Tue, 05 Jan 2016 11:20:45 + u wrote:

> cryptocat source: source-is-missing chrome/content/data/js/lib/otr.js

This is an embedded code copy and should be packaged separately:

https://github.com/arlolra/otr
https://wiki.debian.org/EmbeddedCodeCopies

It is also generated from other files:

  This file is concatenated for the browser.

The build process is defined here:

https://github.com/arlolra/otr/blob/master/gruntfile.js

This requires grunt, which isn't yet in Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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