Here's a candidate patch. Sbuild works in stages, and each stage gets its own object. Each object in turn has a set of properties, such as a 'Log Stream' to log to. Here we were trying to use a Resolver's Log Stream before one was created. In such a case the attached patch attempts to use the Session's Log Stream and then the Host's Log Stream. Those are parent objects that are initialized earlier, and their Log Streams should be set up.
My perl-fu is sufficient, but I don't have an intimate knowledge of sbuild. This patch works, but I don't know enough to claim this is the "right" way to do this.
>From 526631ee947e374e8bda498e570906a7b729dfcf Mon Sep 17 00:00:00 2001 From: Dima Kogan <d...@secretsauce.net> Date: Tue, 7 Oct 2014 00:37:26 -0700 Subject: [PATCH] Sbuild::Base::log() now tries harder to find a valid 'Log Stream' This is a candidate fix for http://bugs.debian.org/763635 It was possible for ResolverBase to call log() before it had a LogStream to log to. Even in that case, the objects that created the ResolverBase may have a LogStream, and I now try their LogStreams before giving up. --- lib/Sbuild/Base.pm | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/Sbuild/Base.pm b/lib/Sbuild/Base.pm index 25a4607..a5f2ec8 100644 --- a/lib/Sbuild/Base.pm +++ b/lib/Sbuild/Base.pm @@ -85,7 +85,14 @@ sub set_conf { sub log { my $self = shift; - my $logfile = $self->get('Log Stream'); + # Use my own LogStream if there is one. If not, try my Session's LogStream. + # If that doesn't work either, look at my host's LogStream. If THAT doesn't + # work, give up + my $logfile = + $self->get('Log Stream') // + ($self->get('Session') && $self->get('Session')->get('Log Stream')) // + ($self->get('Host') && $self->get('Host') ->get('Log Stream')); + if (defined($logfile)) { print $logfile @_; } else { -- 2.0.0
