Le 14/06/2013 15:19, Timo Juhani Lindfors a écrit :
This doesn't really help when trying to diagnose things, and even for
successful
builds it's valuable to have the complete build log, including the parts how
the
upstream build system is called from the Debian packaging.
This is a
Stéphane Glondu glo...@debian.org writes:
http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build
How do you do that exactly?
Can't remember the exact details but you can get the script with
git clone http://lindi.iki.fi/lindi/git/structured-buildlogs.git/
-Timo
--
To
(Resending; first copy failed due to MIME non-8-bit-cleanliness damage.)
Joey Hess writes (Re: jessie release goal: verbose build logs):
I've attached a simple proof of concept you can try it out with building
your own packages. For example:
dpkg-buildpackage | ssh
On Wed, 14 Aug 2013, Guillem Jover wrote:
Definitely, and planned (#476221) to be fixed pretty soon. But the
problem is that this can not be enabled by default (only through an
option initially, until the upper layers rely on a dpkg-buildpackage
with such option and use it) because the
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
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
Hi,
On Tue, 13 Aug 2013, Russ Allbery wrote:
debuild, pbuilder, and related packages currently use
../package_version_arch.build for this output. Maybe the
lower-level build architecture should take over maintaining that log file
instead and those tools should be modified to assume that's
Hi!
On Tue, 2013-08-13 at 15:16:49 -0700, Russ Allbery wrote:
Joey Hess jo...@debian.org writes:
Also it could save the whole log to someplace when minimizing the
console output, to refer back to. Perhaps ../$package_$version.buildlog
(which gets a step closer to including that in the dsc
Hi!
On Tue, 2013-08-13 at 22:08:34 +0200, Joey Hess wrote:
At DebConf, Enrico came up with this idea: When the package is building
with the display going to the console, something could intercept the
stdout and convert \n to \r. Let stderr through untouched. The result
would be a build that
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
On 17 June 2013 23:58, Dmitrijs Ledkovs x...@debian.org wrote:
tags 680686 patch
thanks
On 14 June 2013 12:35, Matthias Klose d...@debian.org wrote:
- Fix debhelper not passing --disable-silent-rules by default.
#680686
I think cdbs already does this.
Patch attached for autoconf
Dmitrijs Ledkovs wrote:
Is there any reason this hasn't been applied yet?
Can I NMU this, as debhelper is marked as LowNMU package.
Not for reasons such as allowing patches like this.
Making all builds verbose by default has both advantages and
disadvantages.
The disadvantages include making
On 13 August 2013 14:36, Joey Hess jo...@debian.org wrote:
Dmitrijs Ledkovs wrote:
Is there any reason this hasn't been applied yet?
Can I NMU this, as debhelper is marked as LowNMU package.
Not for reasons such as allowing patches like this.
Ok.
Making all builds verbose by default has
[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
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
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
Joey Hess wrote:
Making all builds verbose by default has both advantages and
disadvantages.
The disadvantages include making builds possibly so noisy that when one
runs them during daily work, once ignores all output. Including
important compiler warnings.
(This is the same reason why
Joey Hess wrote:
(The implementation needs to be improved; it should read both stdout and
stderr and multiplex them properly. And it should check if stdout is not
to a TTY, and if so avoid munging the build log output. The only other
problem is that `make` outputs the lines it runs to stderr
Joey Hess jo...@debian.org writes:
Joey Hess wrote:
(The implementation needs to be improved; it should read both stdout
and stderr and multiplex them properly. And it should check if stdout
is not to a TTY, and if so avoid munging the build log output. The only
other problem is that `make`
This is now documented at
http://wiki.debian.org/ReleaseGoals/VerboseBuildLogs
--
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/51d6afef.8060...@debian.org
On 14/06/2013 13:49, Wookey wrote:
+++ Matthias Klose [2013-06-14 13:35 +0200]:
Much more often than I do like it, I see bug reports for the toolchain just
pointing to a build log. Then looking at the build log, you often just see
CC ...
CCLD ... (sometimes even colorized)
[...]
On Fri, 14 Jun 2013 14:14:39 +0200, Jakub Wilk wrote:
- File and track issues for packages not enabling verbose builds.
https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html
I attached a dd-list for the lazy. But note that false positives
are possible, especially when
On Fri, Jun 14, 2013 at 14:14:39 +0200, Jakub Wilk wrote:
Debian X Strike Force debia...@lists.debian.org
[long list]
Working on fixing these (adding --disable-silent-rules) as I update
them. Will take a while though...
Cheers,
Julien
signature.asc
Description: Digital signature
+++ Matthias Klose [2013-06-14 13:35 +0200]:
Much more often than I do like it, I see bug reports for the toolchain just
pointing to a build log. Then looking at the build log, you often just see
CC ...
CCLD ... (sometimes even colorized)
This doesn't really help when trying to
Hi,
On 14/06/13 13:35, Matthias Klose wrote:
Much more often than I do like it, I see bug reports for the toolchain just
pointing to a build log. Then looking at the build log, you often just see
CC ...
CCLD ... (sometimes even colorized)
This doesn't really help when trying to
On 14/06/2013 13:49, Wookey wrote:
+++ Matthias Klose [2013-06-14 13:35 +0200]:
Much more often than I do like it, I see bug reports for the toolchain just
pointing to a build log. Then looking at the build log, you often just see
CC ...
CCLD ... (sometimes even colorized)
[...]
I'll
On 2013-06-14, Jakub Wilk jw...@debian.org wrote:
I attached a dd-list for the lazy. But note that false positives are
possible, especially when building in parallel.
I've just sample-checked 4 packages I'm involved in and 100% of those
four I checked was false positives.
We need a better
Matthias Klose d...@debian.org writes:
This doesn't really help when trying to diagnose things, and even for
successful
builds it's valuable to have the complete build log, including the parts how
the
upstream build system is called from the Debian packaging.
This is a useful goal.
Hi,
I completely agree on the goal and disable silent rules where I notice them,
but:
On Fri, Jun 14, 2013 at 01:35:34PM +0200, Matthias Klose wrote:
- Change Debian policy to recommend or require verbose build logs.
#628515
Change buildds.
Do we have autosiging now for all buildds?
Hi
I agree we need good build logs.
On 14-06-13 14:14, Jakub Wilk wrote:
* Matthias Klose d...@debian.org, 2013-06-14, 13:35:
So I'm proposing for jessie:
- File and track issues for packages not enabling verbose builds.
https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html
* Matthias Klose d...@debian.org [130614 13:36]:
Verbose build logs allow to analyse package builds and give hints to more
issues
regarding the build, especially for the hardening flags. The lintian
hardening
checks are incomplete, because they rely on the inspection of the generated
31 matches
Mail list logo
