Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: overseers@sourceware.org
Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org,
	binutils@sourceware.org, gdb@sourceware.org
Subject: Re: Sourceware - Building Together, Fri 11, 15:00 UTC
Date: Fri, 11 Sep 2026 22:16:00 +0200	[thread overview]
Message-ID: <20260911201600.GO23490@gnu.wildebeest.org> (raw)
In-Reply-To: <8bf28f40d7dad5169cdd0b222f38ec903a718d90.camel@klomp.org>

Hi,

On Thu, Sep 10, 2026 at 01:58:41PM +0200, Mark Wielaard wrote:
> Discussion topics about various CI builder buildbots/patchwork/etc:

For those that couldn't attend. Some notes on the topics discussed.

- The sware-gg-bot in #overseers that grants unlimited https access
  has been moved to #sourceware-goodguys. The 429 error page has been
  updated if you still happen to see those.

    Joining the <code>#overseers-goodguys</code> channel directly from
    your host, without a "cloak", should automatically but temporarily
    remediate.

- Claudio fixed the syncing of the gcc-wwwdocs repo (the bot was not
  allowed to push to the gcc- wwwdocs repo)
  Also forge-stage has been updated to the latest forgejo release.

> - Rainer would like to extend the Solaris (amd64 and sparcv9)
>   buildbot workers to gdb
>   https://inbox.sourceware.org/ydd4iglf9yj.fsf@CeBiTec.Uni-Bielefeld.DE

This would reuse the workers already setup for binutils.
And the tricky 32bit-only case if off the table.
Also disabling sim and no targets=all. Only PATH differs.

make check-gdb is clean on solaris? It really only matters for the
reporting, if we have a clear/clean "green" list we can immediately
sent out warning emails Most other builders use a curated list of
tests to run that are known to not fail.  See
https://sourceware.org/cgit/builder/tree/builder/master.cfg#n3752

We'll integrate it with the full make check-gdb list, but disable fail
email reporting for now. Then we'll review the results and see whether
or not to configure the mail reporter.

- A buildbot related question for gcc folks.  A vendor of build
services (incredibuild) has offered free buildbot/build services to
the sourceware fleet, and has an interest in supporting the gcc
project specifically.  They'd welcome suggestions as to architecture,
configuration, target sorts of triplets we should configure for them.
(We would not be running any of their software on sourceware or
nearby; they'd be running build/tests on their own hw/sw as a
community donor).  Please let fche and/or buildbot@sourceware.org know
of any suggestions or concerns.

Richard suggested looking into glibc's scripts/build-many-glibcs.py

> - DJ would like to run the patchwork CI/CD curator in a Sourceware VM
>   https://sourceware.org/glibc/wiki/CICDDesign
>   https://gitlab.com/djdelorie/glibc-cicd
>   This is also a good opportunity to discuss putting patchwork as a
>   whole in its own isolated VM. And to see if we can use some of the
>   builder servers/VM to use the curator to do CI builds.
>   https://sourceware.org/sourceware-wiki/servers-and-services-2026/

Agreed on https://patchwork.sourceware.org/cicd/curator.cgi as
canonical URL. This must be stable because runners will connect to it.
It can be a simple single-url proxy from an apache server to a hidden
internal curator instance. The curator is one python script that runs
four or so processes and talks to mariadb.  It can run anywhere.

mjw would like to take this oppertunity to create a new patchwork VM
and stuff everything in there. We already reserved space for it 4
vcores, 12GB mem, 30GB disk (double checked that is enough).

But some pushback to that and some discussion about whether to run in
containers instead and the maintenance cost of each option. In the end
decided it really is three separate tasks. That shouldn't be handled
in one big bang. So for now we'll simply would be to have it isolated
as separate user on vm01 (possibly in its own container). After that
works we can see about additional steps and/or a separate VM.

For the trybots (buildbots) it is suggesting that they run on
"corporate branded" hardware as advertisement for other companies to
donate more hardware (or run their own). There is a collection of
those here https://builder.sourceware.org/#thanks:~:text=Thanks

> - Should we look into bugspray? A public-inbox bugzilla integrator:
>   https://git.kernel.org/pub/scm/utils/bugspray

Yes, but time ran out.

> - An update on funding https://sourceware.org/financials.html

Numbers for Augustus, $400+ private donations that month, still have
to see how much of that is recurring. The first Supply Chain Defender
corporate sponsor Open Source Security, Inc. $5000 has been fully
processed. Others still in progress, vacations, purchase orders, other
processes take a lot of time.

> - Builders/CI talk at Cauldron with tips and tricks for having all
>   our automated processes (buildbots, try-bots, pre/post-commit-CI/CD,
>   snapshots, forgejo runners, patchwork's curator, etc.) working smoothly,
>   even in the face of the AI scraperbot attacks, and how to add your own.
> https://conf.gnu-tools-cauldron.org/prg26/talk/review/YZDVBNFDPSSZERNAYRYDCS8XWF3BURZC
>   The FSF (GNU Toolchain projects fiscal sponsor) and SFC
>   (Sourceware fiscal sponsor) will also attend to answer any
>   questions on how we are running the community infrastructure
>   together with our other partners.

All the above give some good input into what might be interesting to
talk about.

      parent reply	other threads:[~2026-09-11 20:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 11:58 Mark Wielaard
2026-09-10 21:45 ` Zack Weinberg via Gdb
2026-09-11 13:09   ` Mark Wielaard
2026-09-11 20:16 ` Mark Wielaard [this message]

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=20260911201600.GO23490@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=libc-alpha@sourceware.org \
    --cc=overseers@sourceware.org \
    /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