Bug#617450: sbuild: Please include lintian status in the bottom summary
Cyril Brulebois
Version: 0.61.0-1
Severity: normal
Hi,
it'd be nice if we could have a “lintian: ACK/NACK”-like line in the
bottom summary. ACK/NACK could mention the highest level, like:
- Errors
- Warnings
- OK / All green / Good to go / whatever.
Having the actual issues listed right after that would make sense to me.
That would match debuild's behaviour (running lintian after the build;
but you could run it where it is done currently, and only save the
output for later), and would make lintian's output (if there's an issue)
more visible.
Thanks for considering.
KiBi.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
> it'd be nice if we could have a “lintian: ACK/NACK”-like line in the
> bottom summary. ACK/NACK could mention the highest level, like:
> - Errors
> - Warnings
> - OK / All green / Good to go / whatever.
>
> Having the actual issues listed right after that would make sense to me.
> That would match debuild's behaviour (running lintian after the build;
> but you could run it where it is done currently, and only save the
> output for later), and would make lintian's output (if there's an issue)
> more visible.
Done. Note that it currently looks like this:
Lintian: policy violation
due to using the pre-existing reasons:
if ($?) {
my $why = "unknown reason";
$why = "runtime error" if ($status == 2);
$why = "policy violation" if ($status == 1);
$why = "received signal " . $? & 127 if ($? & 127);
$self->log_error("Lintian run failed ($why)\n");
$self->set('Lintian Reason', $why);
We can, of course, alter this to make the summary values more simple/
informative for automated processing. Due to being based solely
upon the exit status, this can not pick up if non-fatal warnings
were issued--we would need to parse the lintian output for that.
We should probably shorten the text values to e.g.
0: successful
1: policy-violation
2: fatal-signal
*: unknown-error
(i.e. remove whitespace). We could alternatively do something
even simpler e.g. pass/fail/error. Let me know which you prefer;
I think I would prefer pass/fail/error for simplicity--the detail
will always be in the main log (adding the actual lintian issues
to the summary is probably impractical--it's there in RFC-822
format so buildd can consume it at a later date).
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Roger Leigh
I've currently simplified it to allow:
- pass (lintian returned 0)
- fail (lintian returned 1)
- error (any other failure e.g. abort from signal or runtime error)
Could you let me know if this is OK?
Note I've also done the same for piuparts, though it's currently
limited to only pass or fail.
Thanks,
Cyril Brulebois
Roger Leigh <rle...@codelibre.net> (29/05/2011):
> Could you let me know if this is OK?
sorry but I gave up on sbuild.
Mraw,
KiBi.