It would be great if lintian could include the relevant file name and line number in each line of output. That way, users could easily jump to the issue at hand by using their editor’s “compilation mode” (Emacs), quickfix (Vim) or similar feature.
Hi Michael, Lintian does do this in many cases; do you have any specific examples where it doesn't right now? Regards,
% lintian dunst_1.2.0-1_amd64.changes I: dunst source: testsuite-autopkgtest-missing P: dunst source: debian-watch-may-check-gpg-signature I: dunst: dbus-session-service-wrong-name org.freedesktop.Notifications.service usr/share/dbus-1/services/org.knopwob.dunst.service I: dunst: spelling-error-in-manpage usr/share/man/man1/dunst.1.gz verticaly vertically W: dunst: manpage-has-errors-from-man usr/share/man/man1/dunst.1.gz 476: warning [p 5, 8.7i, div `an-div', 0.2i]: can't break line What I’d like is to output to look like this (possibly only after specifying a flag in case it causes breakage): % lintian dunst_1.2.0-1_amd64.changes debian/watch:1: P: dunst source: debian-watch-may-check-gpg-signature I: dunst: dbus-session-service-wrong-name org.freedesktop.Notifications.service usr/share/dbus-1/services/org.knopwob.dunst.service I: dunst: spelling-error-in-manpage usr/share/man/man1/dunst.1.gz verticaly vertically […] I realize that for some of the messages, like the manpage-related ones, we don’t have the mapping between binary artifact and source file (maybe debhelper could be extended to store it). But many other warnings that I run into can be tied to a specific source file.
Hi Michael,
^^^^
Ah, I see. I like this.
Well, we currently just "text encode" the line number where we happen to
know it and include it as a suffix, eg. "(line 23)".
To support the above I believe it would need a more substantial reworking
of the `tag` command in Lintian more generally to consume the metadata in
a more structured way AIUI.
Regards,
Hi Jelmer, Would more reporting detail, as outlined in this bug, be useful to lintian-brush or to D-Janitor? Kind regards Felix Lechner
Hi Felix, Not directly, I think the lintian-info field in the lintian output is more useful for the janitor. That said, I think it would be great to have this feature in lintian - easily being able to jump to the relevant line in an editor would be very useful. Jelmer
Hi Jelmer et al., (FYI there's a wishlist bug somewhere requesting machine-readable output in a format such as JSON/Yaml/etc. where the fields are consistent and named reliably) Regards,
Hi Chris, From my perspective it is a different, although perhaps more helpful item. Machine readable output is coming soon. I need it for something too. Mentioning source files and line numbers, on the other hand, requires a retooling in most checks. I may provide the infrastructure, but getting that information consistently right is challenging, especially in checks looking at installation (deb) packages. Kind regards, Felix Lechner
Hi Felix, Don't worry, I think we are talking about exactly the same thing. I have a (very old) branch that starts to do this but I'm sure you will get around to this before me though. If it helps, my plan was that we call "tag" with many more arguments which all end up in said metadata, but each tag had a "to_string" method (or similar) that would render it into the existing flat, plaintext string... both for the benefit of retaining command-line conciseness but also for the benefit of existing overrides and to roll this out over many many releases. (As you imply, context is important to disambiguate points to filename and — optionally — line number combinations in a source or binary package.) Regards,
Hi Chris, Please let me pick your brain. My current solution is to instantiate tags as they are issued, but they are a bit cumbersome to use. Did you have a more concise approach? Kind regards Felix Lechner
Felix, I cannot recall I had a more concise approach beyond a bunch of dirty "tag_with_filename"-like helpers/wrappers. Just to be clear, this was very much a proof-of-concept. Regards,