Michael Banck wrote:
On Mon, May 11, 2009 at 03:17:33PM +0200, Giacomo A. Catenazzi wrote:So I would like to have a short log (e.g. what I put in stdout/stderr, with "./configure --quiet"), so that people will have no excuses for not be carefukll, but also to have access to configure.log (or/and other build time log), on build failure.OK, so I am not sure what this has to do with the thread. Are you proposing a completely different way of how autoconf packages should get configured in debian/rules? What does ./configure --quiet have to do with compiler warnings or deprecated features? Does it print out relevant parts of config.log on failure? If not, what is the point of "configure.log", having the same information then than one has now in general?Is it to much to ask?You can ask anything, the question is whether it gets picked up. If what you ask for required changes in most source packages, it is likely that it will not get picked up. What I do think might make sense is changing dh7 and/or CDBS to print out config.log if configure fails; that might help debug problems on the autobuilders more quickly.
Ok, I was not so clear. I was replying to: >> Goswin von Brederlow wrote:
Debuild already creates a build log. I think it would be nice to include that file in the changes file and have DAK forward it to buildd.debian.org for archival.
Thus: my request was more about our infrastructure then the building tools. In my experience, the ./configure script are usually too verbose (whose created with autoconf in particulary). Maintainer tends not to parse carefully the output of such script, e.g. ask my sponsorees ;-) , missing important parts. So, if we centrally save the logs, I would like to allow maintainer to run configure with --quiet, but also to save extra informations for late processing. It is not only build failures, but the log (on file, which is much more verbose then normal output) contains also other useful informations: e.g. the compiler and other tool versions, etc. E.g. if we saw a bug (secutity or also miscompilation) in one package in the toolchain, we can found what package need to be recompiled (and in what architecture). I think such logs are more useful to archive, than the simple stdout/stderr. BTW I just discovered dh_buildinfo, which unfortunately has no manpage. ciao cate