Stéphane Glondu 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 UNSUBSCRIBE, e
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
(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-build
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 diff
Hi,
On Tue, 13 Aug 2013, Russ Allbery wrote:
> debuild, pbuilder, and related packages currently use
> ../__.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 already
> happeni
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-bu
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 r
Adam Borowski 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
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 tha
Hi!
On Tue, 2013-08-13 at 15:16:49 -0700, Russ Allbery wrote:
> Joey Hess 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 and upload
Joey Hess 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` outputs
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 stder
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 reaso
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, automate
On 13 August 2013 19:59, Julien Cristau 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 t
[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 on
On 13 August 2013 14:36, Joey Hess 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 both adva
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 17 June 2013 23:58, Dmitrijs Ledkovs wrote:
> tags 680686 patch
> thanks
>
> On 14 June 2013 12:35, Matthias Klose wrote:
>>
>> - Fix debhelper not passing --disable-silent-rules by default.
>>#680686
>>I think cdbs already does this.
>
> Patch attached for autoconf dh build system. c
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 co
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
[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 [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
> binaries, whic
Hi
I agree we need good build logs.
On 14-06-13 14:14, Jakub Wilk wrote:
> * Matthias Klose , 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
>
> I a
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? TTB
Matthias Klose 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. However, since fix
On 2013-06-14, Jakub Wilk 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 detection.
But
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)
>>
[.
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
+++ 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 d
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 diagnose things, and even for successful
builds it's valuabl
32 matches
Mail list logo
