Re: Oh dear. I regret to inform you that commit b1308d2c3749cc454f00b70768ee33724d919527 might be unfortunate

["H.J. Lu" <hjl.tools@gmail.com>]

On Thu, Sep 7, 2017 at 11:57 AM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> On Thursday, September 07 2017, H. J. Lu wrote:
>
>> On Thu, Sep 7, 2017 at 10:56 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>> I think this wasn't my commits, as it seems to be broken as of 63c99141deff
>>> ("remove QStartupWithShell entry from NEWS::Changes in GDB 7.11").  Also, I
>>> haven't touched anything in aarch64 GDB land
>>>
>>>   https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-native-gdbserver-m64/builds/2745
>>>
>>> I can't find any other mention of this on "gdb-patches", though I'm not a GDB
>>> maintainer (we don't have a RISC-V GDB port yet) so I had to poke around the
>>> archives and therefor may be missing something.  According to here
>>>
>>>   https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-native-gdbserver-m64?numbuilds=400
>>>
>>> This has been broken since 34d16ea2a144 ("gdb.base/commands.exp: Test
>>> loop_break and loop_continue in nested loops"), but that failure isn't relevant
>>> to this one as it's a test failure not a build failure.
>>>
>>>   https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-native-gdbserver-m64/builds/2671
>>>
>>> I poked around and there was at least one compilation failure in
>>> between the one I just got emailed about and the test failure above, caused by
>>> 7022349d5c86 ("Stop assuming no-debug-info functions return int").
>>>
>>>   https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-native-gdbserver-m64/builds/2673/steps/compile%20gdb/logs/stdio
>>>
>>> Given that there's two different failures in three commits and I'm pretty sure
>>> I didn't cause this bug, I don't want to dig through the rest of the history to
>>> figure out what's going on.  This has been broken for a while, is everyone else
>>> just ignoring these messages?
>>>
>>
>> This bot is next to useless.  I just ignore it.
>
> Funny, I have another opinion of what is really useless.
>
>> This bot shouldn't spam people when the new commit doesn't change
>> the old error.
>
> The bot is not spamming anyone, it had a bug in the way it used to
> determine whether the breakage email should be sent.  The bug has been
> fixed now.
>
> These breakage e-mails have caught many issues over time, so I still
> think they're very useful.  Of course, if the GDB community decides, I
> can take the bot down at any time.  If this happens, I suposse you must
> have a really better solution for CI.
>
> Anyway, it's a work-in-progress and has a few drawbacks and limitations,
> but overall I think people are reasonably satisfied with it.
>

Does it build for a target for any new commits which are unrelated to the
target?  For example,  when I make some changes to bfd/elfxx-x86.h,
will it triggers a gdb build for Sparc?

-- 
H.J.