[ANNOUNCEMENT] GDB BuildBot

[ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

Hi all,

It took a bit more time than I was planning, but finally I am back to
announce our BuildBot.  I really expect that it will help us improve our
codebase and catch regressions/failures sooner (in fact, it already
helped me to catch at least 2 regressions).

The initial idea was to deploy our BuildBot master directly on
sourceware, but unfortunately this was not possible.  So, after trying
to find other places, I decided to use my own personal server.  However,
my main goal is to turn this project into something official for the GDB
project, and I do hope that using my own server does not give a false
sense of "this is Sergio's pet-project".

Having said that, the current address for our BuildBot is:

  <http://gdb-build.sergiodj.net/>

You will see many pages there, each one displaying the builds in a
particular way.  The one that I find most useful is the Waterfall view:

  <http://gdb-build.sergiodj.net/waterfall>

You can already see the 8 build configurations (a.k.a. "builders") that
I created to test Fedora in a variety of ways; it is obviously possible
to create as many builders as we want, and I intend to expand this list
very soon (I'm trying to obtain access to a PPC64 Fedora machine).

Each build is composed by a number of steps.  There are preparation
steps (i.e., cleaning up the build directory, updating the git
repository), compilation steps (i.e., configure && make && make check,
each one with customizable parameters), a step to compare the test
results (kindly contributed by Tom Tromey), and another two steps to
save the test results in a nice way (details later).

The comparison of the test results is done by using a baseline, which is
the best testsuite run done so far (think of it as the best gdb.sum we
had so far).  For each testsuite run, we get its results and compare
against this baseline; if something that was PASSing turns to FAIL, it
is reported as a regression.  If a test that was FAILing turns to PASS,
it is added in the baseline.  If no regressions are found, then nothing
is done; otherwise, an e-mail is sent to <gdb-testers@sourceware.org>
with a report of what failed.  Therefore, if you are not subscribed to
this list, I strongly recommend you to do so!

Still on the comparison topic, another thing worth mentioning is the
presence of non-deterministic testcases in our testsuite.  To deal with
this, a special file called "xfail" can be created for each builder,
which will contain lines to be ignored in the gdb.sum file (i.e., test
failures to be ignored).  For now, this file needs to be updated by
hand, but I am already thinking about a way to semi-automatize the
process.  If you want me to update the xfail file for a certain builder,
please send me an e-mail (and feel free to include the GDB mailing list
in the Cc).

After struggling *a lot* trying to find a nice way to store the
testsuite results, I came up with a solution using git as a DB-like
backend.  You can see the test results here:

  <http://gdb-build.sergiodj.net/cgit>

You will notice that, for each builder, there is a git repository.
Inside it, I store the gdb.{sum,log} files.  When a new commit has been
tested by BuildBot, it stored the files in the repository, and commits
the result.  Additionally, it also creates a tag whose name is composed
by a timestamp and the git SHA1 that has been tested from the GDB
repository.  For example, suppose that I pushed a new patch to the GDB
repository, and its SHA1 is 0a1b2c3d.  Then, after BuildBot has tested
my commit on the builder Fedora-x86_64, it will store the resulting
gdb.{sum.log} files on the repository named Fedora-x86_64, commit them,
and create a tag named 20150114-182610-0a1b2c3d.

The cgit interface's main purpose, for now, is just to allow everybody
to have access to the full testsuite logs that were generated when
certain commit was tested.  It is also not possible (yet) to clone the
repositories containing the logs; maybe I will enable it in the future.

The configuration files for our BuildBot are currently located at:

  <http://git.sergiodj.net/?p=gdb-buildbot.git;a=summary>

I intend to submit them soon upstream, and put them under the contrib/
directory.  The BuildBot also offers an IRC bot that can stay in the
channel and send messages if some regression is found, but I haven't
enabled this because it can be a little verbose for some people.
However, if the majority wants, I can easily enable it.

I am maintaining a wiki page describing the details of our BuildBot
here:

  <https://sourceware.org/gdb/wiki/BuildBot>

And I am looking for new buildslaves to add to our setup!  If you are
interested, take a look at the wiki page above and do not hesitate to
contact me.  I personally believe that the following setups would help a
lot:

  - ARM
  - PPC
  - Some Windows/MinGW machine

I am also open for suggestions/improvements, of course.  I still think
our configuration needs a lot of polishing, and I already have some
ideas that I would like to implement (testing other branches, enabling
the "Try mode", which will allow people to send their patches to be
tested, etc.), but IMNSHO it is good to be used "in production" already.
I hope it helps!

Before I forget: special thanks to Tom Tromey (for starting to work on a
previous GDB BuildBot in 2011), and Jan Kratochvil for valuable feedback
during the configuration of the current BuildBot.

Cheers,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Joel Brobecker]

Hi Sergio,

> It took a bit more time than I was planning, but finally I am back to
> announce our BuildBot.  I really expect that it will help us improve our
> codebase and catch regressions/failures sooner (in fact, it already
> helped me to catch at least 2 regressions).
> 
> The initial idea was to deploy our BuildBot master directly on
> sourceware, but unfortunately this was not possible.  So, after trying
> to find other places, I decided to use my own personal server.  However,
> my main goal is to turn this project into something official for the GDB
> project, and I do hope that using my own server does not give a false
> sense of "this is Sergio's pet-project".
> 
> Having said that, the current address for our BuildBot is:
> 
>   <http://gdb-build.sergiodj.net/>

I started taking a look, and this looks very very nice.
The interface already looks quite sleek and polished!

We've all already seen that the bot help us a couple of times
associate regressions with specific commits, so I know it's going
to be really useful, and I look forward to more reports (actually,
not really, but that wouldn't be the bot's fault ;-)).

Perhaps you might want to present it and give a demo at the next
GNU Cauldron :-)...

-- 
Joel

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 15 2015, Joel Brobecker wrote:

> Hi Sergio,

Hey Joel,

>> It took a bit more time than I was planning, but finally I am back to
>> announce our BuildBot.  I really expect that it will help us improve our
>> codebase and catch regressions/failures sooner (in fact, it already
>> helped me to catch at least 2 regressions).
>> 
>> The initial idea was to deploy our BuildBot master directly on
>> sourceware, but unfortunately this was not possible.  So, after trying
>> to find other places, I decided to use my own personal server.  However,
>> my main goal is to turn this project into something official for the GDB
>> project, and I do hope that using my own server does not give a false
>> sense of "this is Sergio's pet-project".
>> 
>> Having said that, the current address for our BuildBot is:
>> 
>>   <http://gdb-build.sergiodj.net/>
>
> I started taking a look, and this looks very very nice.
> The interface already looks quite sleek and polished!

Thank you :-).

> We've all already seen that the bot help us a couple of times
> associate regressions with specific commits, so I know it's going
> to be really useful, and I look forward to more reports (actually,
> not really, but that wouldn't be the bot's fault ;-)).

Great!  I am seeing some fuzzy test results there now, so it will take
some time until everything is set up perfectly.  But, baby steps!

> Perhaps you might want to present it and give a demo at the next
> GNU Cauldron :-)...

It would be neat :-).  I just have to be able to attend the conference
:-P.

Cheers,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Wednesday, January 14 2015, I wrote:

> Hi all,
>
> It took a bit more time than I was planning, but finally I am back to
> announce our BuildBot.  I really expect that it will help us improve our
> codebase and catch regressions/failures sooner (in fact, it already
> helped me to catch at least 2 regressions).

Hey guys,

It's been a week since our BuildBot is running, and I would like to
say/ask a few things.

First, thanks to Mark Wielaard for setting up a Debian Wheezy x86_64
machine as one of our buildslaves!  And also, thanks for Tulio Magno and
for IBM/UNICAMP for providing a PPC64LE VM where I could set up another
buildslave for us.  So now, GDB is being tested on:

- Fedora 21 x86_64
- Debian Wheezy x86_64
- Fedora 21 ppc64le

Not bad for a first week :-).  I also plan to set up a buildslave for us
on an AIX machine from the GCC Farm (thanks to David Edelsohn for the
reminder).

Now, the questions.

1) I am still tweaking the notifications that are sent to the
gdb-testers mailing list.  Do you have any ideas/suggestions for
improvement?

2) Are you guys actually seeing the notifications that are sent to the
gdb-testers?  :-).  I know the amount of e-mails can get annoying, and
that's why I'm trying to reduce them by tracking the XFAIL's, but I'd
like to know if this is being used.

3) Eli requested, and I created a new "make TAGS" pass that is performed
on every build.  It is failing every time now (because of the some
issues found by Eli and posted to the gdb-patches).  I could make
BuildBot generate an e-mail for every failure, but this would massively
increase the number of e-mails sent to the gdb-testers.  So, for now, I
am only sending an e-mail *if* some regression has been found.  Is it OK
for you?  Would you like me to make BuildBot send an e-mail every time
"make TAGS" fail?

Other than that, I think we our BuildBot is looking good, and we will
soon be able to filter the noise and catch only the real regressions.
Meanwhile, if you want to help, you can:

- Help me filter the XFAIL tests

- Contribute with a buildslave!

- Improve the current configuration, which can be found (temporarily) at
  <http://git.sergiodj.net/?p=gdb-buildbot.git;a=summary>.

Cheers,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 21 Jan 2015 17:53:36 -0500
> 
> 3) Eli requested, and I created a new "make TAGS" pass that is performed
> on every build.  It is failing every time now (because of the some
> issues found by Eli and posted to the gdb-patches).

Did my recent commit fix this at least for some targets?

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 22 2015, Eli Zaretskii wrote:

>> From: Sergio Durigan Junior <sergiodj@redhat.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>
>> Date: Wed, 21 Jan 2015 17:53:36 -0500
>> 
>> 3) Eli requested, and I created a new "make TAGS" pass that is performed
>> on every build.  It is failing every time now (because of the some
>> issues found by Eli and posted to the gdb-patches).
>
> Did my recent commit fix this at least for some targets?

No, all builders are still failing.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: gdb@sourceware.org
> Date: Thu, 22 Jan 2015 13:37:41 -0500
> 
> On Thursday, January 22 2015, Eli Zaretskii wrote:
> 
> >> From: Sergio Durigan Junior <sergiodj@redhat.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>
> >> Date: Wed, 21 Jan 2015 17:53:36 -0500
> >> 
> >> 3) Eli requested, and I created a new "make TAGS" pass that is performed
> >> on every build.  It is failing every time now (because of the some
> >> issues found by Eli and posted to the gdb-patches).
> >
> > Did my recent commit fix this at least for some targets?
> 
> No, all builders are still failing.

Because of libdecnumber?

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 22 2015, Eli Zaretskii wrote:

>> From: Sergio Durigan Junior <sergiodj@redhat.com>
>> Cc: gdb@sourceware.org
>> Date: Thu, 22 Jan 2015 13:37:41 -0500
>> 
>> On Thursday, January 22 2015, Eli Zaretskii wrote:
>> 
>> >> From: Sergio Durigan Junior <sergiodj@redhat.com>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>
>> >> Date: Wed, 21 Jan 2015 17:53:36 -0500
>> >> 
>> >> 3) Eli requested, and I created a new "make TAGS" pass that is performed
>> >> on every build.  It is failing every time now (because of the some
>> >> issues found by Eli and posted to the gdb-patches).
>> >
>> > Did my recent commit fix this at least for some targets?
>> 
>> No, all builders are still failing.
>
> Because of libdecnumber?

<http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>

Yes.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: gdb@sourceware.org
> Date: Thu, 22 Jan 2015 13:54:55 -0500
> 
> >> > Did my recent commit fix this at least for some targets?
> >> 
> >> No, all builders are still failing.
> >
> > Because of libdecnumber?
> 
> <http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>
> 
> Yes.

Thanks, I tried to fix that in this commit:

commit 53bef1c10759f1fd7faf675459871b2f4cc12e53
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Thu Jan 22 21:07:31 2015 +0200

    Another part of fixing "make TAGS".
    
    libdecnumber/
    2015-01-22  Eli Zaretskii  <eliz@gnu.org>
    
    	* Makefile.in (TAGS): New target, to avoid failures in "make TAGS".

diff --git a/libdecnumber/ChangeLog b/libdecnumber/ChangeLog
index 65d20fc..ec6ea1a 100644
--- a/libdecnumber/ChangeLog
+++ b/libdecnumber/ChangeLog
@@ -1,3 +1,7 @@
+2015-01-22  Eli Zaretskii  <eliz@gnu.org>
+
+	* Makefile.in (TAGS): New target, to avoid failures in "make TAGS".
+
 2014-01-23  Marek Polacek  <polacek@redhat.com>
 
 	PR c/59871
diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
index b6f3842..8dbada9 100644
--- a/libdecnumber/Makefile.in
+++ b/libdecnumber/Makefile.in
@@ -167,6 +167,8 @@ maintainer-clean: distclean
 	@echo "it deletes files that may require special tools to rebuild."
 	-rm -f $(srcdir)/configure $(srcdir)/aclocal.m4
 
+TAGS:
+
 check:
 installcheck:
 dvi:

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: gdb@sourceware.org
> Date: Thu, 22 Jan 2015 13:54:55 -0500
> 
> >> > Did my recent commit fix this at least for some targets?
> >> 
> >> No, all builders are still failing.
> >
> > Because of libdecnumber?
> 
> <http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>
> 
> Yes.

Thanks, I tried to fix that in this commit:

commit 53bef1c10759f1fd7faf675459871b2f4cc12e53
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Thu Jan 22 21:07:31 2015 +0200

    Another part of fixing "make TAGS".
    
    libdecnumber/
    2015-01-22  Eli Zaretskii  <eliz@gnu.org>
    
    	* Makefile.in (TAGS): New target, to avoid failures in "make TAGS".

diff --git a/libdecnumber/ChangeLog b/libdecnumber/ChangeLog
index 65d20fc..ec6ea1a 100644
--- a/libdecnumber/ChangeLog
+++ b/libdecnumber/ChangeLog
@@ -1,3 +1,7 @@
+2015-01-22  Eli Zaretskii  <eliz@gnu.org>
+
+	* Makefile.in (TAGS): New target, to avoid failures in "make TAGS".
+
 2014-01-23  Marek Polacek  <polacek@redhat.com>
 
 	PR c/59871
diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
index b6f3842..8dbada9 100644
--- a/libdecnumber/Makefile.in
+++ b/libdecnumber/Makefile.in
@@ -167,6 +167,8 @@ maintainer-clean: distclean
 	@echo "it deletes files that may require special tools to rebuild."
 	-rm -f $(srcdir)/configure $(srcdir)/aclocal.m4
 
+TAGS:
+
 check:
 installcheck:
 dvi:

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 22 2015, Eli Zaretskii wrote:

>> From: Sergio Durigan Junior <sergiodj@redhat.com>
>> Cc: gdb@sourceware.org
>> Date: Thu, 22 Jan 2015 13:54:55 -0500
>> 
>> >> > Did my recent commit fix this at least for some targets?
>> >> 
>> >> No, all builders are still failing.
>> >
>> > Because of libdecnumber?
>> 
>> <http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>
>> 
>> Yes.
>
> Thanks, I tried to fix that in this commit:

It fixed libdecnumber, but now I see:

  <http://gdb-build.sergiodj.net/builders/Fedora-x86_64-cc-with-index/builds/53/steps/make%20tags/logs/stdio>

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: gdb@sourceware.org
> Date: Thu, 22 Jan 2015 14:55:08 -0500
> 
> > Thanks, I tried to fix that in this commit:
> 
> It fixed libdecnumber, but now I see:
> 
>   <http://gdb-build.sergiodj.net/builders/Fedora-x86_64-cc-with-index/builds/53/steps/make%20tags/logs/stdio>

It's a bug in libiberty/Makefile.in:

  TAGS: $(CFILES)
	  etags `for i in $(CFILES); do echo $(srcdir)/$$i ; done`

and CFILES is just a list of files, without $(srcdir)/.  So this can
only work when building inside the source tree.

I will see what I can do with this.

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> Date: Thu, 22 Jan 2015 22:32:43 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb@sourceware.org
> 
> >   <http://gdb-build.sergiodj.net/builders/Fedora-x86_64-cc-with-index/builds/53/steps/make%20tags/logs/stdio>
> 
> It's a bug in libiberty/Makefile.in:
> 
>   TAGS: $(CFILES)
> 	  etags `for i in $(CFILES); do echo $(srcdir)/$$i ; done`
> 
> and CFILES is just a list of files, without $(srcdir)/.  So this can
> only work when building inside the source tree.

On second thought, TAGS files _should_ be in the source tree, because
that's where they will be used.

So how about running "make TAGS" in the source tree?  Can this be
done in the BuildBot?

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> Date: Thu, 22 Jan 2015 22:39:38 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb@sourceware.org
> 
> >   TAGS: $(CFILES)
> > 	  etags `for i in $(CFILES); do echo $(srcdir)/$$i ; done`
> > 
> > and CFILES is just a list of files, without $(srcdir)/.  So this can
> > only work when building inside the source tree.
> 
> On second thought, TAGS files _should_ be in the source tree, because
> that's where they will be used.
> 
> So how about running "make TAGS" in the source tree?  Can this be
> done in the BuildBot?

And btw, why doesn't VPATH work in this case?

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 22 2015, Eli Zaretskii wrote:

> On second thought, TAGS files _should_ be in the source tree, because
> that's where they will be used.
>
> So how about running "make TAGS" in the source tree?  Can this be
> done in the BuildBot?

Yeah, it can be done.  I will adjust the scripts.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 22 2015, Eli Zaretskii wrote:

>> On second thought, TAGS files _should_ be in the source tree, because
>> that's where they will be used.
>> 
>> So how about running "make TAGS" in the source tree?  Can this be
>> done in the BuildBot?

On a second thought (from my side), I would have to run configure from
the srcdir before "make TAGS"...  While I can do that, I'm trying to
avoid having too many unecessary steps in the build.

If the "make TAGS" step proves to be too difficult to implement in the
regular build process, I will create a special builder just for it.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Doug Evans]

On Thu, Jan 22, 2015 at 1:46 PM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> If the "make TAGS" step proves to be too difficult to implement in the
> regular build process, I will create a special builder just for it.

Yeah, I definitely wouldn't want this to detract from the builds.

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Thursday, January 22 2015, Doug Evans wrote:

> On Thu, Jan 22, 2015 at 1:46 PM, Sergio Durigan Junior
> <sergiodj@redhat.com> wrote:
>> If the "make TAGS" step proves to be too difficult to implement in the
>> regular build process, I will create a special builder just for it.
>
> Yeah, I definitely wouldn't want this to detract from the builds.

I disabled this step temporarily until we figure out what to do.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: gdb@sourceware.org
> Date: Thu, 22 Jan 2015 16:46:48 -0500
> 
> On Thursday, January 22 2015, Eli Zaretskii wrote:
> 
> >> On second thought, TAGS files _should_ be in the source tree, because
> >> that's where they will be used.
> >> 
> >> So how about running "make TAGS" in the source tree?  Can this be
> >> done in the BuildBot?
> 
> On a second thought (from my side), I would have to run configure from
> the srcdir before "make TAGS"...  While I can do that, I'm trying to
> avoid having too many unecessary steps in the build.
> 
> If the "make TAGS" step proves to be too difficult to implement in the
> regular build process, I will create a special builder just for it.

I don't think we need to go that far.  Simply adding "cd $(srcdir) &&"
to the TAGS rules that don't already do that should be good enough.

Alternatively, you could do just "make -C gdb TAGS".  After all, we
don't necessarily need to fix the entire repository, only the parts
that are under our responsibility.  Perhaps this is the best
alternative, on balance.

WDYT?

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb <gdb@sourceware.org>
> Date: Thu, 22 Jan 2015 17:34:46 -0500
> 
> I disabled this step temporarily until we figure out what to do.

I think "make -C gdb TAGS" will allow you to re-enable it.  At least
this will focus us on the problems in our own back-yard.

Thanks.

Re: [ANNOUNCEMENT] GDB BuildBot

[Pedro Alves]

On 01/23/2015 09:06 AM, Eli Zaretskii wrote:
>> From: Sergio Durigan Junior <sergiodj@redhat.com>

>> If the "make TAGS" step proves to be too difficult to implement in the
>> regular build process, I will create a special builder just for it.
> 
> I don't think we need to go that far.  Simply adding "cd $(srcdir) &&"
> to the TAGS rules that don't already do that should be good enough.

Yes, we should do that.  It's what we do to other similar rules
that  generate files in the source dir, like e.g.,

$(srcdir)/aclocal.m4: @MAINTAINER_MODE_TRUE@ $(aclocal_m4_deps)
	cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)

> Alternatively, you could do just "make -C gdb TAGS".

Agreed, though I'd say "in addition", rather than "alternatively".  It's
still good to make it easy to generate TAGS without having to reconfigure.

> After all, we
> don't necessarily need to fix the entire repository, only the parts
> that are under our responsibility.  Perhaps this is the best
> alternative, on balance.

Thanks,
Pedro Alves

Re: [ANNOUNCEMENT] GDB BuildBot

[Pedro Alves]

On 01/22/2015 07:09 PM, Eli Zaretskii wrote:
>> From: Sergio Durigan Junior <sergiodj@redhat.com>
>> Cc: gdb@sourceware.org
>> Date: Thu, 22 Jan 2015 13:54:55 -0500
>>
>>>>> Did my recent commit fix this at least for some targets?
>>>>
>>>> No, all builders are still failing.
>>>
>>> Because of libdecnumber?
>>
>> <http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>
>>
>> Yes.
> 
> Thanks, I tried to fix that in this commit:

Was this sent to gcc?  The master copy of libdecnumber is gcc.
It's best to put the commit there too, so that the next
merge from upstream doesn't lose it.

Thanks,
Pedro Alves

> commit 53bef1c10759f1fd7faf675459871b2f4cc12e53
> Author: Eli Zaretskii <eliz@gnu.org>
> Date:   Thu Jan 22 21:07:31 2015 +0200
> 
>     Another part of fixing "make TAGS".
>     
>     libdecnumber/
>     2015-01-22  Eli Zaretskii  <eliz@gnu.org>
>     
>     	* Makefile.in (TAGS): New target, to avoid failures in "make TAGS".
> 
> diff --git a/libdecnumber/ChangeLog b/libdecnumber/ChangeLog
> index 65d20fc..ec6ea1a 100644
> --- a/libdecnumber/ChangeLog
> +++ b/libdecnumber/ChangeLog
> @@ -1,3 +1,7 @@
> +2015-01-22  Eli Zaretskii  <eliz@gnu.org>
> +
> +	* Makefile.in (TAGS): New target, to avoid failures in "make TAGS".
> +
>  2014-01-23  Marek Polacek  <polacek@redhat.com>
>  
>  	PR c/59871
> diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
> index b6f3842..8dbada9 100644
> --- a/libdecnumber/Makefile.in
> +++ b/libdecnumber/Makefile.in
> @@ -167,6 +167,8 @@ maintainer-clean: distclean
>  	@echo "it deletes files that may require special tools to rebuild."
>  	-rm -f $(srcdir)/configure $(srcdir)/aclocal.m4
>  
> +TAGS:
> +
>  check:
>  installcheck:
>  dvi:
> 

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> Date: Fri, 23 Jan 2015 10:14:31 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gdb@sourceware.org
> 
> >> <http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>
> >>
> >> Yes.
> > 
> > Thanks, I tried to fix that in this commit:
> 
> Was this sent to gcc?  The master copy of libdecnumber is gcc.

Sorry, I didn't know that.  I sent the patch there just now.

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> Date: Fri, 23 Jan 2015 09:56:25 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gdb@sourceware.org
> 
> > I don't think we need to go that far.  Simply adding "cd $(srcdir) &&"
> > to the TAGS rules that don't already do that should be good enough.
> 
> Yes, we should do that.  It's what we do to other similar rules
> that  generate files in the source dir, like e.g.,
> 
> $(srcdir)/aclocal.m4: @MAINTAINER_MODE_TRUE@ $(aclocal_m4_deps)
> 	cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)

I'll look into the libiberty problem when I have time.  I don't
understand why VPATH didn't do its job in that case.

Re: [ANNOUNCEMENT] GDB BuildBot

[Pedro Alves]

On 01/23/2015 10:41 AM, Eli Zaretskii wrote:
>> Date: Fri, 23 Jan 2015 10:14:31 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: gdb@sourceware.org
>>
>>>> <http://gdb-build.sergiodj.net/builders/Fedora-i686/builds/46/steps/make%20tags/logs/stdio>
>>>>
>>>> Yes.
>>>
>>> Thanks, I tried to fix that in this commit:
>>
>> Was this sent to gcc?  The master copy of libdecnumber is gcc.
> 
> Sorry, I didn't know that.  I sent the patch there just now.

Thanks!  FYI, the information on who owns each top
level dir is found in the top level MAINTAINERS file.

Thanks,
Pedro Alves

Re: [ANNOUNCEMENT] GDB BuildBot

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> And btw, why doesn't VPATH work in this case?

There is no VPATH in libiberty/Makefile.in.

http://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=37254c9;hp=51f72ab2bcdc0fc9977b4d9b570bdc8e17abcfa5

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [ANNOUNCEMENT] GDB BuildBot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: sergiodj@redhat.com,  gdb@sourceware.org
> Date: Fri, 23 Jan 2015 15:25:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And btw, why doesn't VPATH work in this case?
> 
> There is no VPATH in libiberty/Makefile.in.

Thanks, that explains why it doesn't work ;-)

I thought out-of-tree builds were supposed to be supported by VPATH,
but it looks like the commit to which you pointed replaced that with
explicit $(srcdir).

Re: [ANNOUNCEMENT] GDB BuildBot

[Mark Wielaard]

On Wed, 2015-01-21 at 17:53 -0500, Sergio Durigan Junior wrote:
> First, thanks to Mark Wielaard for setting up a Debian Wheezy x86_64
> machine as one of our buildslaves!

BTW. I saw more spurious failures on this setup than on the other
buildbot slaves. After lots of digging it turns out that all released
versions of dejagnu have a bug that causes spurious fails in some cases
on SMP machines...

The patch to fix that was posted back in 2005, and was picked up by
fedora in 2006. Which explains why I could reproduce it on my Fedora or
RHEL setups. But at least Debian based distros don't have this patch
yet, since it is not in the latest 1.5.1 dejagnu release yet.

It is in upstream dejagnu git now:
https://lists.gnu.org/archive/html/dejagnu/2011-03/msg00019.html

Full writeup is in the Debian bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776362

If you are running a buildbot slave (or just make gdb-check) and run a
machine with multiple cores you might want to check that you have the
above patch applied to prevent some spurious FAILs.

Cheers,

Mark

Re: [ANNOUNCEMENT] GDB BuildBot

[Sergio Durigan Junior]

On Tuesday, January 27 2015, Mark Wielaard wrote:

> On Wed, 2015-01-21 at 17:53 -0500, Sergio Durigan Junior wrote:
>> First, thanks to Mark Wielaard for setting up a Debian Wheezy x86_64
>> machine as one of our buildslaves!
>
> BTW. I saw more spurious failures on this setup than on the other
> buildbot slaves. After lots of digging it turns out that all released
> versions of dejagnu have a bug that causes spurious fails in some cases
> on SMP machines...
>
> The patch to fix that was posted back in 2005, and was picked up by
> fedora in 2006. Which explains why I could reproduce it on my Fedora or
> RHEL setups. But at least Debian based distros don't have this patch
> yet, since it is not in the latest 1.5.1 dejagnu release yet.
>
> It is in upstream dejagnu git now:
> https://lists.gnu.org/archive/html/dejagnu/2011-03/msg00019.html
>
> Full writeup is in the Debian bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776362
>
> If you are running a buildbot slave (or just make gdb-check) and run a
> machine with multiple cores you might want to check that you have the
> above patch applied to prevent some spurious FAILs.

Wow :-).  Thanks for the investigation, Mark.  It is probably worth
putting this info in the wiki:
<http://sourceware.org/gdb/wiki/BuildBot>.  I will put it there later
(if you don't beat me to it).

Cheers,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/