Launchpad itself

Merge lp://staging/~mbp/launchpad/884092-buildd-versions into lp://staging/launchpad

884092-buildd-versions
Merge into devel

Proposed by Martin Pool on 2011-11-01

Status:

Merged

Approved by:

Martin Pool on 2011-11-01

Approved revision:

no longer in the source branch.

Merged at revision:

14226

Proposed branch:

lp://staging/~mbp/launchpad/884092-buildd-versions

Merge into:

lp://staging/launchpad

Diff against target:

34 lines (+10/-3)

1 file modified

lib/canonical/buildd/buildrecipe (+10/-3)

To merge this branch:

bzr merge lp://staging/~mbp/launchpad/884092-buildd-versions

High

Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Jelmer Vernooij (community)	code	2011-11-01	Approve on 2011-11-01
Review via email: mp+80870@code.staging.launchpad.net

Commit message

[r=jelmer][bug=884092] buildrecipe shows the bzr and bzr-builder versions

Description of the change

Per bug 884092 this tries to make it easier to understand recipe build problems by logging the versions of bzr and plugins used.

Revision history for this message

Martin Pool (mbp) wrote on 2011-11-01:

I haven't tested this locally yet...

Revision history for this message

Martin Pool (mbp) wrote on 2011-11-01:

It looks a lot like this script will only ever run under Xen, and I don't see any scripts that set it up or any documentation that describes how to set up the right kind of Xen guest. Maybe someone can advise me how to test this either locally or on a staging instance.

Revision history for this message

Jelmer Vernooij (jelmer) wrote on 2011-11-01:

Thanks, this looks good.

My guess is that this should probably be tested on one of the test buildds, like we have done with the new bzr and bzr-builder.

Any particular reason for the change to use -u ? There already seem to be some explicit flush calls, and it doesn't seem like real time output is all that important. OTOH, it shouldn't really be harmful either.

review: Approve (code)

Revision history for this message

Martin Pool (mbp) wrote on 2011-11-01:

On 1 November 2011 22:02, Jelmer Vernooij <email address hidden> wrote:
> Review: Approve code
>
> Thanks, this looks good.
>
> My guess is that this should probably be tested on one of the test buildds, like we have done with the new bzr and bzr-builder.

OK.

> Any particular reason for the change to use -u ? There already seem to be some explicit flush calls, and it doesn't seem like real time output is all that important. OTOH, it shouldn't really be harmful either.

We want output written by this program to be in sync with output
written by programs it calls; if it's buffered internally the message
we're running a command may not be printed until well after the
command is finished.

Also, we'd like to see up-to-date log output in the web, and to have
the most output captured if it does crash.

Just making stdout unbuffered seemed cleaner than scattering flush
calls around.