Status on Lintian 2.5.0~rc3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi
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
subscribed).
Status/summery
==============
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[1]),
#621681 (disable pkgbinarymangler during tests[2]) 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 >.>)
~Niels
[LU] http://lists.debian.org/debian-lint-maint/2011/04/msg00048.html
[1] Originally a patch sent to Ubuntu to help them debug FTBFS on their
buildd servers.
[2] tool used on Ubuntu's buildds causing the FTBFS mentioned in [1]
[BoF] http://lists.debian.org/debian-lint-maint/2010/08/msg00012.html
[JavaQATools] http://wiki.debian.org/Java/QATools#Under_way
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNoFK/AAoJEAVLu599gGRC9FAP/R+2wz3WGalXRgI7zIhqZpn0
yMd5Y/oAHBgeu7Jt1E/2xpi0CQ5oKF9XOlYY/uHVBeub12AznHqiE3AyLAXcNREL
c+mry4LcKGS4pc+t6q0Qa+evErY2a1RqDU6djBMmd3/2mF/Ov1cbBbWvtqykGi69
4Z88MVOPLF23xUys2Ur/2mJcpJxXfqpxRqqryzAI8GmgDRs4dMdyFBKo5JKVHIS9
9i9kjNLuj8lJpNqf4amnsnhu65iTAROJRXo8+RE5vbW3IzI4rQkNoOP+5yb2PDcF
u6CvG+1G4k70jJDBGkBtJe0ezFkWqxdrdsB7zYtM4u2aCZ5arGGLYl6+tfo73IWX
xOCjO4wQopQc6Ugw2ktngqJcQ8Wy35UYsXKGHtrq5EGmnrKfXGgkk6yptJK1MZod
a3B+f2IW4h97FqvGxUDkBdMNCzECbMZS6debTHAAIfCCgzpQgFJCMw34MqLB+pKW
IaoQpA5hHtnZpKcdSqQoTZm2cJcHf6Eb4iFPRpjdT4dvKhbTt7vnYLWVLiyMhrDa
pudreE3jJIrEZL1rgw/eTeVv/WmjKaJz10dM3Jc8eMhlChU97yQVKD4DFMJtaciT
bQKeQzCA6ESisY2cc+Mh4X72vtNnpolRla6Rl5KBbjGUGicasvPz7NPD2PiQf88C
4QseWxaMSOZU0er8nnHt
=7Fu7
-----END PGP SIGNATURE-----
Reply to: