Status on Lintian 2.5.0~rc3
-----BEGIN PGP SIGNED MESSAGE-----
I thought I would bring a little update on the progress on Lintian
2.5.0~rc3. I have CC'ed Steve Langasek and Vincent Fourmond because I
last I heard from you, you were working on patches for bugs I am
considering for the 2.5.0~rc3 release (and I was not sure if you were
Since my last update [LU], I have fixed #618587 (armhf support), #621667
(Add S-V 3.9.2), #621658 (add/use --dump-logs in tests),
#621681 (disable pkgbinarymangler during tests) and #621667 (add
spelling mistakes/corrections). I also fixed the uninitialized variable
errors mentioned in #621006.
On my TODO list I still have the merge of infra-513663 into master
(scheduled for Tuesday), inclusion of more java checks (#600829, waiting
for tests) and some multi-arch related checks (bug/patch no yet, waiting
for vorlon). I may also include #620120 (confusion about dash
essentialness) in 2.5.0~rc3.
Finally I am getting a bit fed up with #620289 (false positives with .gz
files), because it sometimes leaves lintian unbuildable. I am
considering to implement a work around for this issue, but this may be
deferred to a later release.
Suggested Release Schedule
I would like to release 2.5.0~rc3 shortly after getting the Multi-arch
patches from vorlon for two reasons. As I understand it, his changes
will assist us in catching common mistakes and multi-arch changes are
most likely "coming soon" (tm). The second reason is to make Lintian
S-V 3.9.2 aware.
I hope to make the release between Wednesday the 13th and Friday the
15th. I expect it to be Thursday or Friday, but I willing to stall it
till Tuesday the 19th if vorlon is running late.
If this is not to your liking, by all means feel free to suggest a
different release date/schedule.
The Java Checks
As mentioned I am hoping Vincent will augment his patch with some tests.
These tests will most likely require a JDK and possibly some javahelper
in our Build-Depends.
The checks and collections are so far all written entirely in perl
(using unzip as extra dependency). That being said, it is not
unreasonable to think we might soon see collections implemented in Java.
This brings us back to the Lintian BoF at DebConf10[BoF], where we
debated how to do this. I hope we can look at this in a release in the
(not too distant) future.
I also have a concern that some of these checks may cause a lot of
false-positives, particularly the codeless-jar tag (See [JavaQATools]).
But we can debate that in #600829.
File and gzip files
I am also considering to work around #620289. The issue is that file
sometimes incorrectly reports .gz files as something else (#522441).
I believe we can use file to come with an initial suggestion (as we do
now), but manually recheck all files ending with .gz, which file does
not report as "gzip compressed data". If the files appear to contain
the magic gzip header, then we could extend the original file output
with "probably gzip compressed data" (etc).
Personally I hope this will greatly improve our false-positive rating
with nearly no cost to our false-negative rating as well as increase the
rebuild-ability of Lintian (it failed for me 5 times yesterday because
file decided gz files where not gzip compressed >.>)
 Originally a patch sent to Ubuntu to help them debug FTBFS on their
 tool used on Ubuntu's buildds causing the FTBFS mentioned in 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----