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. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130813191008.ga...@angband.pl
