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
builds.
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: