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

Peter Robinson pbrobinson at gmail.com
Tue Feb 17 12:07:29 UTC 2015


On Tue, Feb 17, 2015 at 8:56 AM, Jakub Jelinek <jakub at 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


More information about the devel mailing list