Bug#628515: recommending verbose build logs
Hi! On Sun, 2014-02-09 at 15:35:02 -0400, Joey Hess wrote: I raise similar concerns in #680686. There is also discussion there of making dpkg-buildpackage produce a smart display for interactive builds (fleeting display of verbose messages with warnings separated out and highlighted) while logging the full verbose build. The dpkg maintainers have not indicated if they are willing to add that to dpkg-buildpackage. https://lists.debian.org/debian-devel/2013/08/msg00281.html Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
On Wed, Jan 29, 2014 at 08:38:07AM -0800, Jonathan Nieder wrote: Hi, Matthias Klose wrote: This issue is now again silent for eight months. Is there anything missing, or any other reason why the issue doesn't see any progress? I believe there is a consensus that packages should produce verbose build logs by default and can optionally produce terse logs with DEB_BUILD_OPTIONS=terse and this is just waiting on someone to propose wording in policy to that effect. A patch against git://git.debian.org/dbnpolicy/policy.git is best, but rough proposed wording (in section x, add: ...) is also fine. A wiki page documenting how verbose build logs can be produced with the common build systems would be helpful. This would also help defining what 'verbose' means. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Johnathan raises important concerns in http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=628515 These have never been addressed by any proponents of verbose build logs AFAIK. I raise similar concerns in #680686. There is also discussion there of making dpkg-buildpackage produce a smart display for interactive builds (fleeting display of verbose messages with warnings separated out and highlighted) while logging the full verbose build. The dpkg maintainers have not indicated if they are willing to add that to dpkg-buildpackage. Also, there seems to be no consensus about what verbose means. Many build systems have multiple levels of verbosity. The closest this proposal comes to guidance about what level of verbosity is desired is to say we want compiler and linker command lines. (Personally, I do *not* want this output to my screen every build. '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-o' 'dist/build/git-annex/git-annex' 'dist/build/git-annex/git-annex-tmp/Test.o' 'dist/build/git-annex/git-annex-tmp/CmdLine.o' 'dist/build/git-annex/git-annex-tmp/CmdLine/GitAnnex.o' 'dist/build/git-annex/git-annex-tmp/CmdLine/GitAnnexShell.o' 'dist/build/git-annex/git-annex-tmp/Main.o' 'dist/build/git-annex/git-annex-tmp/Config.o' 'dist/build/git-annex/git-annex-tmp/Common.o' 'dist/build/git-annex/git-annex-tmp/Utility/SafeCommand.o' 'dist/build/git-annex/git-annex-tmp/Annex.o' 'dist/build/git-annex/git-annex-tmp/Annex/UUID.o' 'dist/build/git-annex/git-annex-tmp/Backend.o' 'dist/build/git-annex/git-annex-tmp/Git.o' 'dist/build/git-annex/git-annex-tmp/Git/CurrentRepo.o' 'dist/build/git-annex/git-annex-tmp/Git/Filename.o' 'dist/build/git-annex/git-annex-tmp/Types.o' 'dist/build/git-annex/git-annex-tmp/Git/Types.o' 'dist/build/git-annex/git-annex-tmp/Locations.o' 'dist/build/git-annex/git-annex-tmp/Types/KeySource.o' 'dist/build/git-annex/git-annex-tmp/Types/Backend.o' 'dist/build/git-annex/git-annex-tmp/Types/TrustLevel.o' 'dist/build/git-annex/git-annex-tmp/Logs.o' 'dist/build/git-annex/git-annex-tmp/Logs/UUIDBased.o' 'dist/build/git-annex/git-annex-tmp/Logs/Trust.o' 'dist/build/git-annex/git-annex-tmp/Remote.o' 'dist/build/git-annex/git-annex-tmp/Logs/Remote.o' 'dist/build/git-annex/git-annex-tmp/Logs/Unused.o' 'dist/build/git-annex/git-annex-tmp/Logs/Transfer.o' 'dist/build/git-annex/git-annex-tmp/Logs/Presence.o' 'dist/build/git-annex/git-annex-tmp/Types/Key.o' 'dist/build/git-annex/git-annex-tmp/Messages.o' 'dist/build/git-annex/git-annex-tmp/Types/Messages.o' 'dist/build/git-annex/git-annex-tmp/Config/Cost.o' 'dist/build/git-annex/git-annex-tmp/Crypto.o' 'dist/build/git-annex/git-annex-tmp/Annex/Init.o' 'dist/build/git-annex/git-annex-tmp/Annex/CatFile.o' 'dist/build/git-annex/git-annex-tmp/Utility/Path.o' 'dist/build/git-annex/git-annex-tmp/Utility/FileMode.o' 'dist/build/git-annex/git-annex-tmp/Build/SysConfig.o' 'dist/build/git-annex/git-annex-tmp/Utility/Format.o' 'dist/build/git-annex/git-annex-tmp/Utility/Verifiable.o' 'dist/build/git-annex/git-annex-tmp/Utility/Process.o' 'dist/build/git-annex/git-annex-tmp/Utility/Misc.o' 'dist/build/git-annex/git-annex-tmp/Utility/InodeCache.o' 'dist/build/git-annex/git-annex-tmp/Utility/Env.o' 'dist/build/git-annex/git-annex-tmp/Utility/Matcher.o' 'dist/build/git-annex/git-annex-tmp/Utility/Exception.o' 'dist/build/git-annex/git-annex-tmp/Utility/Hash.o' 'dist/build/git-annex/git-annex-tmp/Utility/Scheduled.o' 'dist/build/git-annex/git-annex-tmp/Utility/HumanTime.o' 'dist/build/git-annex/git-annex-tmp/Utility/ThreadScheduler.o' 'dist/build/git-annex/git-annex-tmp/Remote/Helper/Encryptable.o' 'dist/build/git-annex/git-annex-tmp/Types/Crypto.o' 'dist/build/git-annex/git-annex-tmp/Utility/Gpg.o' 'dist/build/git-annex/git-annex-tmp/Utility/PartialPrelude.o' 'dist/build/git-annex/git-annex-tmp/Utility/Directory.o' 'dist/build/git-annex/git-annex-tmp/Utility/Monad.o' 'dist/build/git-annex/git-annex-tmp/Utility/Data.o' 'dist/build/git-annex/git-annex-tmp/Utility/Applicative.o' 'dist/build/git-annex/git-annex-tmp/Utility/FileSystemEncoding.o' 'dist/build/git-annex/git-annex-tmp/Utility/PosixFiles.o' 'dist/build/git-annex/git-annex-tmp/Utility/Tmp.o' 'dist/build/git-annex/git-annex-tmp/Utility/UserInfo.o' 'dist/build/git-annex/git-annex-tmp/Common/Annex.o' 'dist/build/git-annex/git-annex-tmp/Types/Remote.o' 'dist/build/git-annex/git-annex-tmp/Utility/Base64.o' 'dist/build/git-annex/git-annex-tmp/Utility/Metered.o' 'dist/build/git-annex/git-annex-tmp/Git/Config.o' 'dist/build/git-annex/git-annex-tmp/Annex/Direct.o' 'dist/build/git-annex/git-annex-tmp/Annex/Direct/Fixup.o' 'dist/build/git-annex/git-annex-tmp/Git/CatFile.o' 'dist/build/git-annex/git-annex-tmp/Git/CheckAttr.o' 'dist/build/git-annex/git-annex-tmp/Git/CheckIgnore.o' 'dist/build/git-annex/git-annex-tmp/Git/SharedRepository.o' 'dist/build/git-annex/git-annex-tmp/Git/Queue.o'
Bug#628515: recommending verbose build logs
On Sun, Feb 09, 2014 at 03:35:02PM -0400, Joey Hess wrote: Johnathan raises important concerns in http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=628515 These have never been addressed by any proponents of verbose build logs AFAIK. The issue is that it is dangerous to upload packages built with a different DEB_BUILD_OPTIONS than the one on the buildd. So it is safer to keep the baseline at 'no options', otherwise all tools used to build package (sbuild, pbuilder, etc.) need to be updated when the default DEB_BUILD_OPTIONS change. I raise similar concerns in #680686. There is also discussion there of making dpkg-buildpackage produce a smart display for interactive builds (fleeting display of verbose messages with warnings separated out and highlighted) while logging the full verbose build. The dpkg maintainers have not indicated if they are willing to add that to dpkg-buildpackage. Also, there seems to be no consensus about what verbose means. Many build systems have multiple levels of verbosity. The closest this proposal comes to guidance about what level of verbosity is desired is to say we want compiler and linker command lines. All the more reasons to have a wiki page that document the logging behaviour of the common build systems. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Bill Allombert wrote: The issue is that it is dangerous to upload packages built with a different DEB_BUILD_OPTIONS than the one on the buildd. Much less dangerous than it is to upload packages built with a different dpkg-buildpackage -j -- see shy jo signature.asc Description: Digital signature
Bug#628515: recommending verbose build logs
Hi, Matthias Klose wrote: This issue is now again silent for eight months. Is there anything missing, or any other reason why the issue doesn't see any progress? I believe there is a consensus that packages should produce verbose build logs by default and can optionally produce terse logs with DEB_BUILD_OPTIONS=terse and this is just waiting on someone to propose wording in policy to that effect. A patch against git://git.debian.org/dbnpolicy/policy.git is best, but rough proposed wording (in section x, add: ...) is also fine. Thanks for poking. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
let me follow-up on this before jessie opens, and hopefully we can come to an agreement how to get this done for jessie. Since 2011, some tools are now looking at build logs (or should), and verbose build logs are required to make more use of these tools: - the build log checker: https://buildd.debian.org/~brlink/ now identifies 995 packages with compiler-flags-hidden, so that seem to be ~15% of all source packages building architecture dependent packages which cannot be analysed by the build log checker. - hardening is a release goal for wheezy. The current approach to analyse the binaries for hardened compiler flags gives many false positives for extension modules for interpreted languages. So a build log check could be used to eliminate these false positives. So we have a release goal, but incomplete tools to diagnose if we meet this goal. Afaics, hardening-wrapper can not: - see if a binary was built with -O0, and stop complaining about fortify (#694618), - can not diagnose objects not referencing any of the fortify functions provided by glibc. A build log check based on verbose build logs would help here. I suppose we want the autobuilders to generate verbose log, but I am not sure if we want the autobuilders to use a non-empty DEB_BUILD_OPTIONS (and whether we can). Most autobuilders already set DEB_BUILD_OPTIONS=parallel=n, so this can be done, and is already in use. Using the `terse' or `silent' keyword sounds fine. However maybe make it clear how DEB_BUILD_OPTIONS=verbose,terse would work (suggesting here that verbose should overwrite terse). Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Russ Allbery wrote: What should we do about cases where the upstream build system makes it difficult to override the verbosity? In other words, is this a place where we should push Debian package maintainers to actually fix the upstream build system to make build logs verbose even if upstream doesn't support that as an option? I'm thinking, for example, of some of djb's public domain software, where the compiler invocation is stored in a shell script Good question. IMHO yes, we should encourage packagers to help upstream provide an option that makes the logs indicate how the compiler was invoked, to make reproducing and debugging problems easier. In the kind of build system you're talking about, something like [ -z $V ] || set -x at the top of the compiler invocation script could do the trick. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Raphael Hertzog wrote: For reference dpkg supports DEB_BUILD_OPTIONS=maintainer-build [...] I also think that it would be more convenient to have the buildd set the verbose mode and others to have the silent rules by default but I don't think this is going to take traction. We have quite a few bugreports from users doing rebuilds and it's best to get verbose build logs in those cases. That's why I suggest to aim directly for the opposite: verbose by default and silent with a switch that maintainers can add. Makes sense to me, fwiw. Thanks for explaining. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
On Sun, Nov 27, 2011 at 04:39:33AM -0600, Jonathan Nieder wrote: Jakub Wilk wrote: * Jonathan Nieder jrnie...@gmail.com, 2011-11-26, 18:37: [...] I do not suspect there is a consensus for this. Why do you think there is not? I was guessing, it seems incorrectly, based on the lack of seconds or other discussion on this policy proposal. Some maintainers enjoy reading abbreviated build logs, where error messages and warnings stand out. Sure, that's why DEB_BUILD_OPTIONS=noverbose was proposed. I personally think that DEB_BUILD_OPTIONS=verbose would be better UI, because the cases where abbreviated build logs are most useful are during interactive builds (especially interactive builds by novices who are not accustomed to looking at logs and do not realize they have a choice about their format but may miss a warning). In non-interactive builds, it is easy to set an environment variable. I suppose we want the autobuilders to generate verbose log, but I am not sure if we want the autobuilders to use a non-empty DEB_BUILD_OPTIONS (and whether we can). It is unfortunately possible than a typo in debian/rules only trigger if DEB_BUILD_OPTIONS is set to some value. Most packages will only provide verbose log, so it is rather terse logs that are optionnal. So maybe the option should be DEB_BUILD_OPTIONS=terse. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
* Charles Plessy ple...@debian.org, 2011-11-28, 16:11: it seems to me that the best way to materialise a consensus for a release goal is to actually get it listed in http://release.debian.org/wheezy/goals.txt and have the work started. Matthias has already proposed it as RG, and he was redirected here: http://lists.debian.org/debian-release/2011/03/msg00023.html This will protect the Policy from documenting options that are not implemented. In line with this, http://wiki.debian.org/PolicyChangesProcess mentions “the proposed solution be known to work”. Well, I believe the fundamental part of the proposal (making build logs verbose by default) is mostly already implemented, i.e. majority of packages do produce verbose build logs. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: Most packages will only provide verbose log, so it is rather terse logs that are optionnal. So maybe the option should be DEB_BUILD_OPTIONS=terse. I agree with this. Most packages are already doing the right thing, and I think terse logs should be the non-default option. What should we do about cases where the upstream build system makes it difficult to override the verbosity? In other words, is this a place where we should push Debian package maintainers to actually fix the upstream build system to make build logs verbose even if upstream doesn't support that as an option? I'm thinking, for example, of some of djb's public domain software, where the compiler invocation is stored in a shell script and therefore doesn't appear usefully in the build output. Or should Policy just be saying that packagers should enable the verbose option by default if there is one? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Bill Allombert bill.allomb...@math.u-bordeaux1.fr (28/11/2011): I suppose we want the autobuilders to generate verbose log, but I am not sure if we want the autobuilders to use a non-empty DEB_BUILD_OPTIONS (and whether we can). It is unfortunately possible than a typo in debian/rules only trigger if DEB_BUILD_OPTIONS is set to some value. Most packages will only provide verbose log, so it is rather terse logs that are optionnal. So maybe the option should be DEB_BUILD_OPTIONS=terse. (While I'm open to other names,) I agree with the reasoning and the proposed name. Mraw, KiBi. signature.asc Description: Digital signature
Bug#628515: recommending verbose build logs
On Mon, Nov 28, 2011 at 11:37:41AM -0800, Russ Allbery wrote: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: Most packages will only provide verbose log, so it is rather terse logs that are optionnal. So maybe the option should be DEB_BUILD_OPTIONS=terse. I agree with this. Most packages are already doing the right thing, and I think terse logs should be the non-default option. What should we do about cases where the upstream build system makes it difficult to override the verbosity? In other words, is this a place where we should push Debian package maintainers to actually fix the upstream build system to make build logs verbose even if upstream doesn't support that as an option? I'm thinking, for example, of some of djb's public domain software, where the compiler invocation is stored in a shell script and therefore doesn't appear usefully in the build output. Or should Policy just be saying that packagers should enable the verbose option by default if there is one? We should start by providing instruction on how to turn on verbose log on the most common build systems and deal with exceptions later. Is there some wiki page already ? Build systems can be sneaky. For example upgrading automake to 1.11 will activate terse log by default without notice, so the developpers are in the painful situation to have to disable a feature they never wanted to activate in the first place. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: For example upgrading automake to 1.11 will activate terse log by default without notice, so the developpers are in the painful situation to have to disable a feature they never wanted to activate in the first place. I'm fairly certain this is not the case. That was the original proposal, and perhaps the original implementation, but there was a lot of pushback on the Automake development list, and looking at the documentation for Automake 1.11, it is not currently the default. To enable less verbose build rules, both the developer and the user of the package have to take a number of steps. The developer needs to do either of the following: * Add the `silent-rules' option as argument to `AM_INIT_AUTOMAKE'. * Call the `AM_SILENT_RULES' macro from within the `configure.ac' file. It is not possible to instead specify `silent-rules' in a `Makefile.am' file. If the developer has done either of the above, then the user of the package may influence the verbosity at `configure' run time as well as at `make' run time: * Passing `--enable-silent-rules' to `configure' will cause build rules to be less verbose; the option `--disable-silent-rules' is the default and will cause normal verbose output. * At `make' run time, the default chosen at `configure' time may be overridden: `make V=1' will produce verbose output, `make V=0' less verbose output. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
* Jonathan Nieder jrnie...@gmail.com, 2011-11-26, 18:37: Matthias Klose wrote: It's always interesting to look at build logs, or to receive bug reports of the form CC compiler error message or CCLD linker error message without knowing how the compiler or the linker were called. Maybe it is convenient for a package maintainer watching the build scrolling by (some of these are even colorized), but lacking this kind of information in the first place seems to be the wrong thing. Fully agreed. So please let us deprecate this anti-feature and recommend verbose build logs by default and only turn them off by request (e.g. with DEB_BUILD_OPTIONS=noverbose). As much as I agree with your goal (being able to easily understand and diagnose miscompilations and build failures) I do not suspect there is a consensus for this. Why do you think there is not? Some maintainers enjoy reading abbreviated build logs, where error messages and warnings stand out. Sure, that's why DEB_BUILD_OPTIONS=noverbose was proposed. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Jakub Wilk wrote: * Jonathan Nieder jrnie...@gmail.com, 2011-11-26, 18:37: [...] I do not suspect there is a consensus for this. Why do you think there is not? I was guessing, it seems incorrectly, based on the lack of seconds or other discussion on this policy proposal. Some maintainers enjoy reading abbreviated build logs, where error messages and warnings stand out. Sure, that's why DEB_BUILD_OPTIONS=noverbose was proposed. I personally think that DEB_BUILD_OPTIONS=verbose would be better UI, because the cases where abbreviated build logs are most useful are during interactive builds (especially interactive builds by novices who are not accustomed to looking at logs and do not realize they have a choice about their format but may miss a warning). In non-interactive builds, it is easy to set an environment variable. However: - My personal thoughts here don't matter. I am not a DD. - Any spelling of DEB_BUILD_OPTIONS=verbose or DEB_BUILD_OPTIONS=quiet would be perfectly fine with me. It sounds like we are ready for an improved wording? Thanks for your help, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Hi Charles, Charles Plessy wrote: I think that the best way to see which of verbose or noverbose is to be chosen would be to go through the soft release goal or release recommendation that Matthias advocated. Once the mayonnaise thickens (once the recommendation is followed), then it will have its place in the Policy. If there is enough consensus for a release goal, why not document that consensus in Policy? I don't get it. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Le Mon, Nov 28, 2011 at 12:06:05AM -0600, Jonathan Nieder a écrit : I think that the best way to see which of verbose or noverbose is to be chosen would be to go through the soft release goal or release recommendation that Matthias advocated. Once the mayonnaise thickens (once the recommendation is followed), then it will have its place in the Policy. If there is enough consensus for a release goal, why not document that consensus in Policy? I don't get it. Hi Jonathan it seems to me that the best way to materialise a consensus for a release goal is to actually get it listed in http://release.debian.org/wheezy/goals.txt and have the work started. This will protect the Policy from documenting options that are not implemented. In line with this, http://wiki.debian.org/PolicyChangesProcess mentions “the proposed solution be known to work”. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Charles Plessy wrote: it seems to me that the best way to materialise a consensus for a release goal is to actually get it listed in http://release.debian.org/wheezy/goals.txt and have the work started. This will protect the Policy from documenting options that are not implemented. In line with this, http://wiki.debian.org/PolicyChangesProcess mentions “the proposed solution be known to work”. Ok, I guess I still don't understand. Suppose http://release.debian.org/wheezy/goals.txt says that packages should support some DEB_BUILD_OPTIONS flag, maintainer can decide what name it is, to enable or suppress the full command line for the compiler and linker. Would that be progress? On the other hand, if you are saying that packagers should not wait for any official pronouncement to implement whatever DEB_BUILD_OPTIONS=verbose/quiet option they please, then I would agree with you. xz-utils has supported DEB_BUILD_OPTIONS=quiet for a while now. However, I thought Matthias was looking for something more consistent between packages, like making sure that logs are verbose when DEB_BUILD_OPTIONS is unset (or making sure that logs are verbose when DEB_BUILD_OPTIONS=verbose, whatever. Either way.) Hoping that clarifies a little, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Hi, On Mon, 28 Nov 2011, Jonathan Nieder wrote: On the other hand, if you are saying that packagers should not wait for any official pronouncement to implement whatever DEB_BUILD_OPTIONS=verbose/quiet option they please, then I would agree with you. xz-utils has supported DEB_BUILD_OPTIONS=quiet for a while now. However, I thought Matthias was looking for something more consistent between packages, like making sure that logs are verbose when DEB_BUILD_OPTIONS is unset (or making sure that logs are verbose when DEB_BUILD_OPTIONS=verbose, whatever. Either way.) For reference dpkg supports DEB_BUILD_OPTIONS=maintainer-build that enables the silent rules and I have an alias dpkgbuild that avoids me to have to type this every time. Maybe a discussion on -devel would be helpful to try to standardize on a name. I also think that it would be more convenient to have the buildd set the verbose mode and others to have the silent rules by default but I don't think this is going to take traction. We have quite a few bugreports from users doing rebuilds and it's best to get verbose build logs in those cases. That's why I suggest to aim directly for the opposite: verbose by default and silent with a switch that maintainers can add. Ideally though debuild would get support for this option and could be taught to set it via some ~/.devscripts setting. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Hi Matthias, Matthias Klose wrote: It's always interesting to look at build logs, or to receive bug reports of the form CC compiler error message or CCLD linker error message without knowing how the compiler or the linker were called. Maybe it is convenient for a package maintainer watching the build scrolling by (some of these are even colorized), but lacking this kind of information in the first place seems to be the wrong thing. So please let us deprecate this anti-feature and recommend verbose build logs by default and only turn them off by request (e.g. with DEB_BUILD_OPTIONS=noverbose). As much as I agree with your goal (being able to easily understand and diagnose miscompilations and build failures) I do not suspect there is a consensus for this. Some maintainers enjoy reading abbreviated build logs, where error messages and warnings stand out. So how can we make progress anyway? I would propose introducing something very similar to what you mentioned above, but just flipping the default. People who want verbose build logs could use DEB_BUILD_OPTIONS=verbose Then I think there would be a strong case for making that the default on autobuilders, but that's a separate question, anyway. Strawman patch below. What do you think? diff --git i/policy.sgml w/policy.sgml index 31226328..34a195f1 100644 --- i/policy.sgml +++ w/policy.sgml @@ -2224,6 +2224,17 @@ stripped from the binary during installation, so that debugging information may be included in the package. /item + tagverbose/tag + item + This tag means that compiler and linker commands used to + build the package should not be abbreviated in the + log.footnote + Packages built with ttcmake/tt, autotools, or + the Linux kernel build system can implement this by + passing the parameters ttV=1/tt and + ttVERBOSE=1/tt as arguments to ttmake/tt. + /footnote + /item tagparallel=n/tag item This tag means that the package should be built using up -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Package: debian-policy Version: 3.9.2.0 Severity: normal [https://lists.debian.org/debian-release/2011/03/msg00016.html] It was suggested to move this to debian-policy. It's always interesting to look at build logs, or to receive bug reports of the form CC compiler error message or CCLD linker error message without knowing how the compiler or the linker were called. Maybe it is convenient for a package maintainer watching the build scrolling by (some of these are even colorized), but lacking this kind of information in the first place seems to be the wrong thing. So please let us deprecate this anti-feature and recommend verbose build logs by default and only turn them off by request (e.g. with DEB_BUILD_OPTIONS=noverbose). The only reason (I know) for needing quiet builds logs should be handled depending on the buildd (e.g. if sending/emailing a large log is unreliable). The majority of quiet build logs comes from cmake based systems and (newer) automake based systems, so maybe this could be handled by cdbs and debhelper for the majority of packages. Other proposals how to include the important information would be welcome. I would like to see a finalized proposal as a soft release goal, or a release recommendation. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
On Sun, May 29, 2011 at 07:59:42PM +0200, Matthias Klose wrote: Package: debian-policy Version: 3.9.2.0 Severity: normal [https://lists.debian.org/debian-release/2011/03/msg00016.html] It was suggested to move this to debian-policy. It's always interesting to look at build logs, or to receive bug reports of the form CC compiler error message or CCLD linker error message without knowing how the compiler or the linker were called. Maybe it is convenient for a package maintainer watching the build scrolling by (some of these are even colorized), but lacking this kind of information in the first place seems to be the wrong thing. So please let us deprecate this anti-feature and recommend verbose build logs by default and only turn them off by request (e.g. with DEB_BUILD_OPTIONS=noverbose). The only reason (I know) for needing quiet builds logs should be handled depending on the buildd (e.g. if sending/emailing a large log is unreliable). The majority of quiet build logs comes from cmake based systems and (newer) automake based systems, so maybe this could be handled by cdbs and debhelper for the majority of packages. Other proposals how to include the important information would be welcome. To start with, do you know how to desactivate that feature in cmake and automake (and the linux kernel)? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
On 05/29/2011 08:11 PM, Bill Allombert wrote: To start with, do you know how to desactivate that feature in cmake and automake (and the linux kernel)? - cmake: VERBOSE=1 (?) - automake: V=1 - linux kernel: V=1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628515: recommending verbose build logs
Bill Allombert bill.allomb...@math.u-bordeaux1.fr (29/05/2011): To start with, do you know how to desactivate that feature in cmake and automake (and the linux kernel)? For automake. When running make: V=1 to enable verbosity again if silent rules were enabled. At configure time: --disable-silent-rules does what the name suggests. All details, see silent-rules on: http://www.gnu.org/s/hello/manual/automake/Options.html Mraw, KiBi. signature.asc Description: Digital signature
Bug#628515: recommending verbose build logs
Some notes for completeness. Matthias Klose wrote: - cmake: VERBOSE=1 (?) Yes, or cmake -DCMAKE_VERBOSE_MAKEFILE=1 at configure time. - automake: V=1 As KiBi mentioned, --disable-silent-rules at configure time works, too. - linux kernel: V=1 The KBUILD_VERBOSE environment variable determines the default behavior. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
