public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Provide Solaris 11 buildbots
Date: Thu, 20 Sep 2018 12:35:00 -0000	[thread overview]
Message-ID: <yddfty48hz9.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <874lelw9r3.fsf@redhat.com> (Sergio Durigan Junior's message of	"Wed, 19 Sep 2018 15:46:40 -0400")

Hi Sergio,

> On Wednesday, September 19 2018, Rainer Orth wrote:
>
>> If the proposed Solaris 11 buildbots
>>
>> 	https://sourceware.org/ml/gdb/2018-09/msg00004.html
>
> Thanks for the offer, and for the patch!
>
> IMO, "the more the merrier".  So yeah, Solaris 11 buildslaves are
> absolutely welcome.

great.  It will save me the trouble of detecting post-factum when some
patch broke the Solaris build ;-)

>> * The buildslaves are configured to be compile-only at the moment: at
>>   -j4, a build takes ca. 15 minutes, while make check takes 1h 15 due to
>>   many timeouts (mostly in gdb.threads).  Until those are resolved, it's
>>   probably useless to run the tests.
>
> Right.  Until I implement a way to enable only a subset of tests from
> our testsuite, I agree that it's not a good idea to have builds taking
> that long to finish.

While I could perhaps increase the degree of parallelism, even full -j16
or -j48 builds on my regular build systems take about 5 minutes to
compile, but about half an hour to test, which is still way too long
compared to e.g. a Linux/x86_64 build/test cycle.

I suspect that those timeouts are due to a handful of root causes; once
those are fixed, it should be possible to enable the tests, too.

>> * I couldn't find proper documentation for at least two fields:
>>
>> ** arch in config.json (slaves), seems to be unused AFAICT
>>
>> ** tags in config.json (builders)
>
> Sorry about that.
>
> The "arch" field is indeed unused.  The initial plan was to use it to
> offer some filtering capabilities in the web interface, but that's been
> replaced by "tags".
>
> The "tags" filter is just a collection of tags that are used to
> categorize the builders.  If you go to
> <https://gdb-build.sergiodj.net/waterfall>, at the top of the page
> you'll see a "Tags:" header, with a bunch of tags.  You can use them to
> selectively display just the builders associated with a certain tag.
> For example, if you want to list the x86_64 builders, you'd go to
> <https://gdb-build.sergiodj.net/waterfall?tag=x86_64>.

Ah, I see.  Probably something to add to the wiki ;-)

> There are two "special" tags: "MAIL" and "TEST".  When a builder is
> marked as "MAIL", the BuildBot master will send e-mail notifications
> about it to gdb-testers/gdb-patches.  If it's marked as "TEST", then all
> e-mail notifications are supressed.  I just mark a builder as "TEST" if
> it proves to unstable (i.e., when GDB fails to compile on it because of
> some problem with the builder itself).  I think it makes sense to mark
> your builders as "MAIL", since they're relatively stable, from what you
> said.

That's the intent: the hosts (global zones in Solaris lingo) are among
my main (or only in case of the sparc box) development machines, so I'll
keep them up and running for that reason alone ;-)

The global zones are running current Solaris 11.5 Beta builds, and thus
will be upgraded/rebooted biweekly.  The kernel zones which host the
build slaves are on Solaris 11.4, with the intent of upgrading to the
latest SRU (support repository upgrade; collection of patches tested
together) once a month.  Apart from those planned downtimes (reboots in
the order of minutes), the systems have been rock solid.

> I'll have to contact you in private in order to give the password
> necessary for connection to the BuildBot master.  I'll also apply your
> patch now and enable the builders, so all it's left for you is to start
> them on your side.

That's has happened now, and both are registered with the master, though
they haven't run any builds yet.  I'll wait a bit until this has
completed successfully, then turn the buildslave start into a service so
they are automatically restarted on failure and rerun at boot.

Thanks for your help.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  reply	other threads:[~2018-09-20 12:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 11:23 Rainer Orth
2018-09-19 19:46 ` Sergio Durigan Junior
2018-09-20 12:35   ` Rainer Orth [this message]
2018-09-20 14:10     ` Sergio Durigan Junior
2018-09-20 14:40       ` Sergio Durigan Junior
2018-09-20 14:44         ` Rainer Orth
2018-09-20 14:50           ` Sergio Durigan Junior
2018-09-20 17:55             ` Rainer Orth
2018-09-24 14:43               ` Rainer Orth
2018-09-24 15:25                 ` Sergio Durigan Junior
2018-09-26 13:16                   ` Sergio Durigan Junior
2018-09-26 13:33                     ` Rainer Orth
2018-09-26 14:05                       ` Sergio Durigan Junior
2018-10-05  8:48                         ` Rainer Orth
2018-10-05 15:36                           ` Sergio Durigan Junior
2018-09-21  8:51       ` Rainer Orth
2018-09-21 15:31         ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yddfty48hz9.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).