Access to failed builds [Was: gcc5 ICE xserver build on ARM]

Marek Polacek polacek at
Tue Feb 17 09:08:00 UTC 2015

On Tue, Feb 17, 2015 at 09:56:20AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 17, 2015 at 08:45:09AM +0000, Andrew Haley wrote:
> > On 17/02/15 07:21, David Airlie wrote:
> > 
> > > Well I can't provide any info, I don't have an ARM box here, and it
> > > happens in the buildroot which I don't think I can access to get the
> > > files out from.
> > 
> > I've been bitten by this several times.  We need to find a better way
> > to handle issues like this: when a build goes wrong a GCC developer
> > needs to be able to see what went wrong, and that means direct access
> > to the box so that they can reproduce the problem.
> > 
> > So what might we do to solve this?  Is there some way that we can
> > "freeze" the contents of a buildroot to allow a dev to get in there
> > and poke around?
> In most cases when the bug is reproduceable and a single preprocessed
> source is enough (e.g. not LTO build etc.), the gcc driver dumps all the
> required info into /tmp/.
> That is the -freport-bug
> Preprocessed source stored into /tmp/ccXXXXXX.out file, please attach this to your bugreport.
> message.
> So, if mock + koji copied those over (best xz or bzip2 compressed) alongside with
> build.log / root.log etc. in case the build failed, that would be very much
> appreciated.

Indeed, reproducing the failures only to get a /tmp/ccXXXXXX.out file
is not exactly fun.

In a related vein, I think ABRT should bundle the /tmp/ccXXXXXX.out
files to its reports as well.  From time to time we get reports as
<>, but such a bug
report is largely useless without preprocessed source + command-line

Sorry if I'm driving this off-topic.


More information about the devel mailing list