Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
Dmitrijs Ledkovs wrote: We have build log analyzers running for the build logs. Checking heuristically for problems you know about does not help find the class of problems you don't know about yet. How about a new DEB_BUILD_OPTION=silent which opts into silent build log? Does that sound reasonable. I don't see how it could seem reasonable if you've read my message and followed my reasoning. -- see shy jo signature.asc Description: Digital signature
Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
Am 13.08.2013 21:10, schrieb Adam Borowski: 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. If you want to go this road, then it would be per use-case, not per tool. When looking at a QA maintained package, or looking at an unfixed RC issue in a package I do not maintain, I want to have as much information as possible. Filtering this information on my own is an easy task, however trying to figure out how to make a build to print all information usually takes a bit longer. So probably the package maintainer likes the terse build logs too, but he is usually the one who can make them terse without any effort. However people occasionally looking at a package are much better served with a complete build log. Working all the time with dpkg-buildpackage, so even there the default should be the one which is the most useful for the majority of use cases. Matthias -- 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/520c9fab.5060...@debian.org
Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
Adam Borowski kilobyte at angband.pl writes: Non-spammy builds are better for builds done by a human. No. They’re better for builds done by the developers of the upstream software on their own systems where they know what they’re doing. And even then, it’s a big maybe. Every other human is a packager or porter (in a broad sense… if I install Linux From Scratch then compile something I want to use on it, I’m one), and those *require* verbose output, e.g. to verify that the buildsystem didn’t eat $CFLAGS. I can live with an optional 'silent' build option, but I personally think everyone – especially(!) the package maintainers – should have no need to use it. bye, //mirabilos -- 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/loom.20130814t173844-...@post.gmane.org
Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
[why oh why are you breaking threading?] On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote: We have build log analyzers running for the build logs. And the important compiler warnings (errors) fail the build. If we make this opt-in, we will fail to achieve this goal. As when one is debugging a failed build (e.g. the failure in the last hour of webkit/qt/libreoffice compile on armhf porter box, or by hand ./debian/rules build) that's when one would start caring wishing to have the verbose output would have been set, but it would be too late. I don't see how. Either dpkg-buildpackage -nc or re-running debian/rules build with the option set would give you what you want. Cheers, Julien signature.asc Description: Digital signature
Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
On 13 August 2013 19:59, Julien Cristau jcris...@debian.org wrote: [why oh why are you breaking threading?] On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote: We have build log analyzers running for the build logs. And the important compiler warnings (errors) fail the build. If we make this opt-in, we will fail to achieve this goal. As when one is debugging a failed build (e.g. the failure in the last hour of webkit/qt/libreoffice compile on armhf porter box, or by hand ./debian/rules build) that's when one would start caring wishing to have the verbose output would have been set, but it would be too late. I don't see how. Either dpkg-buildpackage -nc or re-running debian/rules build with the option set would give you what you want. For well behaved build-systems that would only show flags for the yet to compile object, where the bug might be in the flags/libs used for the already compiled objects. (i don't have an example here, something like mixing with/without -fPIC but we get warnings which objects are at fault anyway) For less behaved build-systems this may cause a reconfigure and restart the whole build. Which is suboptimal. In the past there have been random bugs / build failures which are not reproducible on re-runs (but I've yet to see one which depended on build-flags, unless one gets different flags =/ on reruns which wouldn't know about) 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. Regards, Dmitrijs. -- 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/CANBHLUi1+Q8PVTJF2TvhGKBLQh-y=elhrzpuv-7ntjlypch...@mail.gmail.com
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. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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
