In #551463 and #680686, people requested that debhelper should automatically
pass --disable-silent-rules to Automake build systems for the jessie
"verbose build logs" release goal.

Joey was reluctant to enable this by default (to avoid package maintainers
getting sufficiently verbose logs when developing that warnings are not
readily visible), but did merge a patch to do so when DH_VERBOSE is set
(#751207), with the suggestion that the buildds should enable it.

sbuild is a more or less non-interactive build even when not on a buildd,
and produces copious output regardless of debhelper settings, so I think
it would be reasonable for it to set DH_VERBOSE by default.

Regards,
    S

I think DH_VERBOSE does more than just pass
--disable-silent-rules.  You can also get the behaviour you want
with setting V=1.


Kurt

Yes, it still also does what it used to do, which is to make debhelper
echo each command it's going to run before it runs it. That's in the
same general category of "be more verbose, so that people trying to fix
a FTBFS they can't reproduce can see what the buildd is doing differently").

Yes, but I have to do either that or --disable-silent-rules as an extra
line in debian/rules in every Autotools package I touch, which is
somewhat at odds with "the Right Thing should be the default"; and
whenever a maintainer doesn't do that, it makes life harder for
build-log-checking, NMUers, and so on.

On that basis, several people have independently suggested that
debhelper should --disable-silent-rules by default. Joey was not willing
to do so by default, to avoid hiding warnings among a lot of noise in
developers' test builds, but said he wouldn't object to making
DH_VERBOSE have that extra side-effect.

I think it's a reasonable position to say that the right default for a
buildd, and the right default for a developer build, are different.
buildds are not accessible by random developers, so the build log is the
only information available to a developer wondering why their build
failed there - which is why it contains package versions, a summary of
toolchain versions, apt output, and all the other nice things that are
in the sbuild log.

I personally use a local sbuild to build my own packages for upload
(although I also do preliminary test builds outside sbuild if I expect
it to take several iterations) and I think a local sbuild is, on
balance, more like a buildd than it is like a test-build: you leave it
running noninteractively, and look at the log afterwards. That's most of
why this is a feature request on sbuild, not the buildd network.

(The other part is that if sbuild sets DH_VERBOSE, all architectures'
buildds will pick up that version eventually, whereas if it's per-buildd
configuration, AIUI I would have to ask the buildd maintainers for 13
architectures, plus an unknown number of unofficial ports, to set it up
individually :-)

For context please see #551463, #680686.

    S