On Tue, Feb 17, 2015 at 8:56 AM, Jakub Jelinek <jakub(a)redhat.com> 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.
We were actually speaking with the mock guys about this in Brno last
week. From a koji PoV it just stores the files that mock spits out
which at the moment is just the build logs plus any *rpm files so it
shouldn't be too hard to extend mock to enable the output of extra
debug files.
Peter