[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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




Le 6 janvier 2016 16:55:19 GMT+01:00, Ximin Luo <infinity0@debian.org> 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é.


Reply to: