[buildd-tools-devel] Bug#617450: Bug#617450: Bug#617450: sbuild: Please include lintian status in the bottom summary

[Roger Leigh]

On Sun, May 29, 2011 at 01:54:45PM +0100, Roger Leigh wrote:
> On Wed, Mar 09, 2011 at 02:05:54AM +0100, Cyril Brulebois wrote:
> > 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).

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,
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110529/829ff106/attachment.pgp>