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
stem is called from the Debian packaging.
>
> This is a useful goal. However, since fixing many different source
> packages is a lot of work I recently explored some alternative
> approaches. For example, with systemtap we can simply log all execve()
> invocations complete with timing in
(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
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
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
&
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
evel of cruft we wade through
> (often up to our eyeballs) when building packages, and allow
> concentrating on what's important. At the same time, it allows adding as
> verbose output as we like and getting that saved in the build logs for
> when a detailed analysis is needed.
I
g that in the dsc and uploading
> > local build logs..)
>
> 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
to including that in the dsc and uploading
> local build logs..)
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 it runs to stderr and so those
> continue to pollute the build display.)
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 uploading
local build logs.
s important. At the same time, it allows adding as
verbose output as we like and getting that saved in the build logs for
when a detailed analysis is needed.
--
see shy jo
#!/usr/bin/perl
$|=1;
my $width=$ENV{COLUMNS} || 80;
while (<>) {
chomp;
print substr($_
uto-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 silen
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
[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
>
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 p
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
t;> CC ...
> >> CCLD ... (sometimes even colorized)
> >>
> [...]
> > I'll second this. Like Doko, I've spent way too much time recently(ish)
> > staring at build-logs. The short-form build logs are often useless for
> > working out why something
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 gener
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-c
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 b
eful goal. However, since fixing many different source
packages is a lot of work I recently explored some alternative
approaches. For example, with systemtap we can simply log all execve()
invocations complete with timing information and end up with fully
structured build logs.
Here's example ou
d a better detection.
But beside that, I agree with wanting verbose build logs.
/Sune
--
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/slrnkrm2nj.j8.nos...@sshway.ssh.pusling.com
CLD ... (sometimes even colorized)
>>
[...]
> I'll second this. Like Doko, I've spent way too much time recently(ish)
> staring at build-logs. The short-form build logs are often useless for
> working out why something isn't working, or comparing successful
> native builds
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.
>
> Verbose build logs allow to analyse package builds
w how the upstream build system is called.
>#680687
>As an alternative buildds could run with DEB_BUILD_OPTIONS=verbose
>
> - Change Debian policy to recommend or require verbose build logs.
> #628515
I'll second this. Like Doko, I've spent way too much time recentl
it's valuable to have the complete build log, including the parts how the
upstream build system is called from the Debian packaging.
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
On Wed, 16 Feb 2011 09:53:24 +0100, Mike Hommey wrote:
> > I looks rather easy to strip the HTML, e.g. with the one-line patch
> > below. I leave it to you if you want to submit it against devscripts
> > :)
> That's unfortunately not enough, as some characters (at the very least
> quotes and <,>)
On Tue, Feb 15, 2011 at 05:45:56PM +0100, gregor herrmann wrote:
> On Tue, 15 Feb 2011 09:09:05 +0900, Charles Plessy wrote:
>
> > > getbuildlog(1) from devscripts downloads (almost, if you ignore a
> > > small header/footer) text-versions of build logs.
> > it is
Le Tue, Feb 15, 2011 at 05:45:56PM +0100, gregor herrmann a écrit :
> On Tue, 15 Feb 2011 09:09:05 +0900, Charles Plessy wrote:
>
> > > getbuildlog(1) from devscripts downloads (almost, if you ignore a
> > > small header/footer) text-versions of build logs.
> >
On Tue, 15 Feb 2011 09:09:05 +0900, Charles Plessy wrote:
> > getbuildlog(1) from devscripts downloads (almost, if you ignore a
> > small header/footer) text-versions of build logs.
> it is exactly that header and footer that I was reffering to when I wrote
> “withouth HTML pr
On Thu, Nov 12, 2009 at 01:51:41PM -0200, Gustavo Noronha Silva wrote:
> On Wed, 2009-11-11 at 09:58 +0100, Mike Hommey wrote:
> > I actually never experienced problems that were not due to my DSL
> > connection, which means they can happen at any time. In which case I'd
> > dcut the last file and
On Wed, 2009-11-11 at 09:58 +0100, Mike Hommey wrote:
> I actually never experienced problems that were not due to my DSL
> connection, which means they can happen at any time. In which case I'd
> dcut the last file and continue the upload. But when that happens in the
> middle of a file that takes
Le Wed, Nov 11, 2009 at 03:20:38PM +0100, Luk Claes a écrit :
>
> I think it's very wrong to ask core teams to lower the standards of
> possible package uploads while noone invests time to create a building
> machine that would make source-only uploads possible, even with the
> current rules in pl
Charles Plessy (11/11/2009):
> my gut feeling (but maybe I start to sound like a broken disk) is
> that most “FTBFS” and RC bugs that stay unfixed are more the
> signature of abandonned packages than sloppy maintainers.
Abandoned packages may start to FTBFS due to changes in their
build-dependenc
Charles Plessy wrote:
> Le Wed, Nov 11, 2009 at 10:45:57AM +0100, Stefano Zacchiroli a écrit :
>> Personally, I think that the extreme trade-off of making source upload
>> the default (which seems to be what you are arguing for) would be too
>> risky in term of degraded package quality. Look for th
Le Wed, Nov 11, 2009 at 10:45:57AM +0100, Stefano Zacchiroli a écrit :
>
> Personally, I think that the extreme trade-off of making source upload
> the default (which seems to be what you are arguing for) would be too
> risky in term of degraded package quality. Look for the "FTBFS" string
> in th
On 2009-11-11 09:42:25 +0100, Michal Čihař wrote:
> Sandro Tosi napsal(a):
> > As a personal note, as one of those unlucky people with a very slow
> > network connection: if binary packages built by maintainer have to be
> > discarded, than *please* allow a way to actually not upload them.
> >
>
On 2009-11-11, Stefano Zacchiroli wrote:
> Personally, I think that the extreme trade-off of making source upload
> the default (which seems to be what you are arguing for) would be too
> risky in term of degraded package quality. Look for the "FTBFS" string
> in the current RC bug list, do you th
On Tue, Nov 10, 2009 at 10:17:05PM -0600, Adam Majer wrote:
> It is *one* way of making sure the archive is consistent. But the idea
> behind source-only is to remove the necessity of uploading giant
> binaries if they are to be tossed anyway. For example, OpenOffice
> revisions, or Linux kernel re
On Wed, Nov 11, 2009 at 4:58 PM, Mike Hommey wrote:
> I actually never experienced problems that were not due to my DSL
> connection, which means they can happen at any time. In which case I'd
> dcut the last file and continue the upload. But when that happens in the
> middle of a file that takes
On 2009-11-11, Mike Hommey wrote:
>> Yes, you're missing at least the lintian checks that happen on ftp-master.
> You mean, the ones that should be running on buildd generated packages
> anyway ?
Sadly there is no easy way to let buildd cope with packages vanishing on
ftp-master and not being acc
On Wed, Nov 11, 2009 at 09:54:38AM +0100, Luk Claes wrote:
> Sandro Tosi wrote:
> > On Wed, Nov 11, 2009 at 09:42, Michal Čihař wrote:
> >> Hi
> >>
> >> Dne Wed, 11 Nov 2009 09:39:38 +0100
> >> Sandro Tosi napsal(a):
> >>
> >>> As a personal note, as one of those unlucky people with a very slow
>
On Wed, Nov 11, 2009 at 09:52:12AM +0100, Luk Claes wrote:
> You don't have to start over if the upload did not fail in the middle of
> a file, but failed right after a file. It may seem unlikely, but I've
> had these failures way more often than failures in the middle of a file.
>
> So if it did
Sandro Tosi wrote:
> On Wed, Nov 11, 2009 at 09:42, Michal Čihař wrote:
>> Hi
>>
>> Dne Wed, 11 Nov 2009 09:39:38 +0100
>> Sandro Tosi napsal(a):
>>
>>> As a personal note, as one of those unlucky people with a very slow
>>> network connection: if binary packages built by maintainer have to be
>>
On Wed, Nov 11, 2009 at 09:48:13AM +0100, Luk Claes wrote:
> Michal Čihař wrote:
> > Hi
> >
> > Dne Wed, 11 Nov 2009 09:39:38 +0100
> > Sandro Tosi napsal(a):
> >
> >> As a personal note, as one of those unlucky people with a very slow
> >> network connection: if binary packages built by maintai
Mike Hommey wrote:
> On Wed, Nov 11, 2009 at 09:39:38AM +0100, Sandro Tosi wrote:
>> On Wed, Nov 11, 2009 at 08:30, Adam Majer wrote:
>>> On Mon, Oct 26, 2009 at 02:58:19PM -0500, Manoj Srivastava wrote:
On Mon, Oct 26 2009, Adam Majer wrote:
> Or here's a radical idea - allow source only
On Wed, Nov 11, 2009 at 09:42, Michal Čihař wrote:
> Hi
>
> Dne Wed, 11 Nov 2009 09:39:38 +0100
> Sandro Tosi napsal(a):
>
>> As a personal note, as one of those unlucky people with a very slow
>> network connection: if binary packages built by maintainer have to be
>> discarded, than *please* al
Michal Čihař wrote:
> Hi
>
> Dne Wed, 11 Nov 2009 09:39:38 +0100
> Sandro Tosi napsal(a):
>
>> As a personal note, as one of those unlucky people with a very slow
>> network connection: if binary packages built by maintainer have to be
>> discarded, than *please* allow a way to actually not uplo
On Wed, Nov 11, 2009 at 09:39:38AM +0100, Sandro Tosi wrote:
> On Wed, Nov 11, 2009 at 08:30, Adam Majer wrote:
> > On Mon, Oct 26, 2009 at 02:58:19PM -0500, Manoj Srivastava wrote:
> >> On Mon, Oct 26 2009, Adam Majer wrote:
> >> > Or here's a radical idea - allow source only uploads of packages.
Hi
Dne Wed, 11 Nov 2009 09:39:38 +0100
Sandro Tosi napsal(a):
> As a personal note, as one of those unlucky people with a very slow
> network connection: if binary packages built by maintainer have to be
> discarded, than *please* allow a way to actually not upload them.
>
> I'm in favor of let
On Wed, Nov 11, 2009 at 08:30, Adam Majer wrote:
> On Mon, Oct 26, 2009 at 02:58:19PM -0500, Manoj Srivastava wrote:
>> On Mon, Oct 26 2009, Adam Majer wrote:
>> > Or here's a radical idea - allow source only uploads of packages.
>>
>> And thus allow people to upload without ever building
On Mon, Oct 26, 2009 at 02:58:19PM -0500, Manoj Srivastava wrote:
> On Mon, Oct 26 2009, Adam Majer wrote:
> > Or here's a radical idea - allow source only uploads of packages.
>
> And thus allow people to upload without ever building locally.
I would expect people to build packages local
On Tue, Nov 10, 2009 at 11:27:39PM +0100, Bernd Zeimetz wrote:
> Adam Majer wrote:
> > People are lazy and like myself don't want to sync pbuilder and
> > related stuff every time I want to upload something. Since my box is
> > rarely up to date, this can result in dependencies lagging
> > somewhat
On Wed, Oct 28, 2009 at 07:12:15AM +0100, Stefano Zacchiroli wrote:
> On Mon, Oct 26, 2009 at 02:29:47PM -0500, Adam Majer wrote:
> > Or here's a radical idea - allow source only uploads of packages.
>
> He, radical, but not new :) It has been discussed to death various
> times. The most likely (a
Adam Majer wrote:
> People are lazy and like myself don't want to sync pbuilder and
> related stuff every time I want to upload something. Since my box is
> rarely up to date, this can result in dependencies lagging
> somewhat compared to official buildd. I generally don't check for any
> build-dep
On Wed, 2009-10-28 at 10:14 +0100, Petter Reinholdtsen wrote:
> [Luca Niccoli]
> > I think Petter meant "upload packages which don't build successfully
> > even on a single architecture".[1]
>
> That is exactly what I meant, yes. :) If the source do not compile on
> any architecture, I believe it
[Luca Niccoli]
> I think Petter meant "upload packages which don't build successfully
> even on a single architecture".[1]
That is exactly what I meant, yes. :) If the source do not compile on
any architecture, I believe it the maintainer must have failed to done
the minimum checks that should be
On Mon, Oct 26, 2009 at 02:29:47PM -0500, Adam Majer wrote:
> Or here's a radical idea - allow source only uploads of packages.
He, radical, but not new :) It has been discussed to death various
times. The most likely (and IMO better) alternative to that is uploading
binaries but trowing them away
2009/10/27 Ben Hutchings :
> On Tue, Oct 27, 2009 at 12:15:39PM +0100, Petter Reinholdtsen wrote:
>
>> I believe a better approach is to collect stats on who upload packages
>> which fail to build on all architectures, and add a process to
[...]
> Well you can kick out the kernel team then, becaus
On Tue, Oct 27, 2009 at 12:15:39PM +0100, Petter Reinholdtsen wrote:
>
> [Charles Plessy]
> > Why don’t we remove the key of the developers uploading “crap
> > packages” from the Debian keyring?
>
> I believe a better approach is to collect stats on who upload packages
> which fail to build on al
[Charles Plessy]
> Why don’t we remove the key of the developers uploading “crap
> packages” from the Debian keyring?
I believe a better approach is to collect stats on who upload packages
which fail to build on all architectures, and add a process to
review/requalify a Debian Developer if this h
Le Mon, Oct 26, 2009 at 11:07:19PM +, Roger Leigh a écrit :
>
> While most developers are conscientious enough to make sure their
> packages build, one does see enough crap packages that IMO this
> (minimal) bar should probably be kept.
Hi all,
Why don’t we remove the key of the developers u
On Mon, Oct 26, 2009 at 02:29:47PM -0500, Adam Majer wrote:
> People are lazy and like myself don't want to sync pbuilder and
> related stuff every time I want to upload something. Since my box is
> rarely up to date, this can result in dependencies lagging
> somewhat compared to official buildd. I
On 2009-10-26, Adam Majer wrote:
> People are lazy and like myself don't want to sync pbuilder and
> related stuff every time I want to upload something. Since my box is
heard of cron?
/Sune
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
On Mon, Oct 26 2009, Adam Majer wrote:
> On Wed, Oct 21, 2009 at 01:27:05PM +0200, Samuel Thibault wrote:
>> I confirm that usually not having the i386 or amd64 log is often a
>> problem.
>>
>> One idea that was floating around was to have buildd always recompile
>> the package, even on archs the
On Wed, Oct 21, 2009 at 01:27:05PM +0200, Samuel Thibault wrote:
> I confirm that usually not having the i386 or amd64 log is often a
> problem.
>
> One idea that was floating around was to have buildd always recompile
> the package, even on archs the uploader has provided a binary version
> for,
Wesley W. Terpstra, le Wed 21 Oct 2009 13:02:37 +0200, a écrit :
> What do other people think? Should this be possible? Should this be required?
I confirm that usually not having the i386 or amd64 log is often a
problem.
One idea that was floating around was to have buildd always recompile
the pa
I've long thought that would be a good idea. However, IIRC the plan is
to drop the .debs built by developers and build each upload on the
buildds. That will mean that the build logs are available for all
architectures. In the meantime, or if this doesn't go ahead after all,
it would
Wesley W. Terpstra wrote:
> However, I find there's one piece of data that
> is sadly missing: the log from my local build!
why is the buildlog of the maintainers local build of interest to anyone
when it was announced that ftp-master is planning to throw away the
uploaded binaries from the mainta
I find the buildd logs on https://buildd.debian.org/ to be extremely
useful. They are nicely organized and it's easy to look back in time
and see previous build problems and/or get a quick overview of the
current build status. However, I find there's one piece of data that
is sadly missing: the log
Hello,
This idea might have been raised earlier but here goes anyway...
How about allowing the addition of build logs to the upload? Something
like _.log.gz to accompany _.deb when
the latter is uploaded.
This log would be merely put (by the incoming system) into
buildd.debian.org along with
77 matches
Mail list logo
