[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

On Tue, Aug 13, 2013 at 08:30:16PM +0200, Dmitrijs Ledkovs wrote:
> In controlled environments, one doesn't get to re-run a build, as the
> instances are stripped-down and destroyed on build failure E.g. all
> the jenkins instances running debian package builds, PPAs,
> auto-package-tests, automated cross-builders. One would have to modify
> each and every deployment of those...
> Somehow we lived fine with verbose build-logs, until automake silent
> rules and a few other build-systems started to become more silent. I
> can understand the appeal of silent builds for upstream developers,
> but it makes zero sense for a distribution or package maintainers or
> our downstream.

Non-spammy builds are better for builds done by a human.
Spammy builds work around the inability to restart on a failure in automated

Trying to spot an irregularity can be really hard visually if you have half
a page of switches per every file.  With a terse build like:
  CC foo
  CC bar
  CC baz
  CC quux
  LD blah
any messages stand out.  And if a failure does happen, it's a matter of,
typically, make V=y.

Too bad you don't have this option on a buildd.

So I guess it would be best to put the threshold at automated vs
human-supervised builds.  What about setting the flag per-tool rather than
per-deployment?  For example, pbuilder would default to verbose (as you
can't restart builds) while dpkg-buildpackage in the absence of inherited
settings would default to terse.

This way we'd be spared the spam during development.


Reply to: