Re: Suggested buildd log check

[Matthias Klose <doko@debian.org>]

On 11/26/2011 01:14 AM, Jonathan Nieder wrote:
> Hi,
> 
> You wrote[1]:
> 
>> If you have ideas for warnings/diagnostics visibile in buildd logs
>> that are worth having listed in a view like that, please let me
>> know.
> 
> I'm not sure how your infrastructure copes with something like this,
> but I would find it useful to have gcc 4.6's machine-parsable warnings
> in such a list.  They look like this:
> 
>  ../../src/gcc/graphite.c:59:29: warning: non-local variable 'cloog_pointers__' with anonymous type is questionable in C++ [-Wc++-compat]
> 
> I guess a regex like "\[-W[-+=a-z0-9]*\]" would do, plus
> "\[-pedantic\]" and "\[-fpermissive\]"..
> 
> I suppose these could all be lumped as one diagnostic type, except
> that when new gcc releases introduce new warnings (like the recent
> -Wunused-but-set-variable and -Wunused-but-set-parameter), they could
> get a different tag.  What do you think?
> 
> Thanks very much for this work,
> Jonathan
> 
> [1] https://buildd.debian.org/~brlink/

The first issue with this kind of approach is that not all build logs are
verbose by default.  So a first step would be to decide if you have a verbose
build log, or some quiet mess, and submit bug reports for the latter (there is a
lintian report for this, although the lintian maintainers think this is not the
right place).

It would be good not to limit this to warnings only. Another use case is the
check if build flags are really passed to the upstream build system; this seems
to be a requisite to the hardening release goal, because you generally can't see
for every object in the resulting binary if it was built with or without
hardening defaults.

So, a more general approach might be more useful in terms for the wheezy release.

  Matthias