Re: [mass bug] New license problem/sourceless fil/privacy problems detected by lintian
Hi Bastien,
2014/1/15 Bastien ROUCARIES <roucaries.bastien@gmail.com>:
> Hi,
>
> I have just implemented a few new check in lintian:
> detecting non free file based on md5sum[1]. These file are non free.
> I have filled a few bugs and I plan to fill more on it, when I get more reports.
> Please send bug to lintian to add more file to detect. We could also
> detect non distributable file if needed.
>
> Another tags of interest are detection of flash object [2][3]
> I have filled bug when I could not find the source. I plan to fill more
>
> Moreover lintian detect minified javascript (based on extension).[4]
> I am slowly manually checking if source is present and fill bug when
> appropriate.
> I plan to detect more minified javascript based on contents analysis
> (line too long some comments) in newer lintian version.
>
> I have also created tags for .jar and .py(c|o) object but I will not
> open bug and manually check (I am not an expert in these kind of
> stuff). Please java team and python get a glimpse at these tags [5][6]
>
> Last but not least I have splitted the privacy-breach tags. Lintian
> gives now some piece of advice depending of the problem.
>
> Feel free to open bugs against lintian in case of false positive or
> other problems [7]
>
> Thank you
>
> [1] http://lintian.debian.org/tags/license-problem-md5sum-non-free-file.html
> [2] http://lintian.debian.org/tags/source-contains-prebuilt-flash-object.html
> [3] http://lintian.debian.org/tags/source-contains-prebuilt-flash-project.html
> [4] http://lintian.debian.org/tags/source-contains-prebuilt-javascript-object.html
> [5] http://lintian.debian.org/tags/source-contains-prebuilt-java-object.html
> [6] http://lintian.debian.org/tags/source-contains-prebuilt-python-object.html
> [7] Please read first about privacy-breach-logo
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735321#10
Thank you for implementing the lintian checks and notifying maintainers
through bug reports.
I'm about to fix the one created against xbmc because I already planned
removing some other embedded but unused libraries anyway, but I would
like to suggest using the important severity as a start for such bugs.
Later the severity could be upgraded if there is no action on the maintainer's
side.
The rationale behind this proposal is that considering xbmc, source creates
a new 24MB source package and ~30MB of binary packages per architecture.
I expect more similar checks to be implemented and more bugs to be
opened against many packages.
Opening the bugs as important, thus not RC ones would allow maintainers
to collect more fixes to fewer package updates not having to worry about
automated removal of their packages from testing.
I agree that the detected issues are RC, and I also agree with the current
autoremoval procedure but IMO having more time to fix these issues
would allow using the project's resources and maintainters' time better.
Cheers,
Balint
Reply to: