make_common_builder: fix source-to-BUILD relative directory

make_common_builder(): pass branch name as list

master.cfg: add gitsigur builder

Together with a "make_common_builder()" proc to contain potential
cross-project boilerplate.

debugedit_gitpoller: Add missing comma after main_and_users_try_branches

debugedit_gitpoller: pull main_and_users_try_branches

Now that we have a debugedit_try_scheduler we also need to pull the
users try branches.

Add debugedit try builders

elfutils_try_fedora_x86_64_builder: Also build rpm

Containerfile-fedora-latest: Add sysprof-capture-devel

Needed for elfutils eu-stacktrace builds.

Containerfile-fedora-latest: add cargo

Needed by the gccrs builders.

See e.g. https://builder.sourceware.org/buildbot/#/builders/37/builds/2060.

fedrawhide builder: stop building gcc

It takes too long on this little VM, and we have better/faster ones
(albeit not exact match for fedora-rawhide).

master.cfg: add "*.trs" files to bunsen data from gcc testruns

libbacktrace uses automake style tests

gcc_nightly_full_scheduler: every four hours

The new fullest builder can take more than three hours. Doing a build
every four hours still gives us 6 fullest builds a day (assuming there
is at least one commit every 4 hours).

debian_ppc64_worker: set ncpus and maxcpus to 2

We are seeing out of memory issues with 4 cpus and the VM only has 2.

gcc-fullest-builder: add multilib build & testing

Look on my works, ye Mighty, and despair!

      r"RUNTESTFLAGS=--target_board=unix\\\{,-m32\\\}"

Add binutils_factory_ld_check and use it for i386, arm64 and s390x

Use a separate (non-failing) binutils_step_check_ld_warn step in
binutils_factory_ld_check so the i386, arm64 and s390x (try) builders
should normally succeed (apart from the known ld failures).

binutils_step_check_ld_warn: Add || true

A builder which has a "warning" step will stay in Warning state. A
builder that never succeeds just accumulates all ChangeSets (and
Responsible Users). When the state changes (to a true Failure) that
means all those ChangeSets (and Responsible Users) are marked and
notified.

Fix adding || true to make_gdb_check_full_step

commit 662687024e7bae64f53d63d498faf51349a8777e
"make_gdb_check_full_step: add || true to end of command line"
Added the " || true" with command = ...
This should have been command += of course.

make_gdb_check_full_step: add || true to end of command line

There are always some failing tests, so for now pretend the make check
does succeed. We do this by turning the command from an array into a
string to be interpreted by a shell.

Update valgrind (try) builders

Remove the opensuse x86_64 builders. They don't add much extra.
Add an ibm-power10 and a fedora-arm64 try builder.
Don't run the auxchecks. They are unreliable.
Add || true to make regtest becuase the regtests aren't zero fail.
Add valgrind_regtest_step and bunsen upload for dist_factory.
Add collapseRequests=True to all builders.

gcc_full_build_factory_gen: Add || true to make check -k step

With all languages enabled make check seems to always fail if one of
the (non-default) language/runtime testsuites show failurs. This puts
the build in a Warning state. We don't care about some tests failing,
so add || true to the end of the make check -k command.

Remove gdb_cleanup_gdbservers_step

This step was only necessary because the gdbserver could keep running
detached from gdb. https://sourceware.org/bugzilla/show_bug.cgi?id=29796
resolved by gdb commit a733b2c90: imply --once if connecting via stdio

Killing all gdbservers might accidentially kill other gdbservers
running in a separate testrun.

gcc_nightly_full_scheduler: Change back to every three hours

The scheduler triggered once an hour as a test. Things seem to work
fine, so switch back to once every three hours (a build with all
languages and extra checking takes < 2 hours on x3d1, x3d2 and < 3
hours on bb3).

gcc_nightly_full_scheduler: Explicitly add branch="master"

Also trigger every hour, just for testing.

gcc_fullest_debian_amd64_builder --enable-languages=all

Now that the Debian stable container contains rustc and cargo 1.72.0
we can enalbe all GCC language frontends.

gcc_nightly_full_scheduler: Add change_filter for gcc master branch

Install recent rustc in Debian stable

Debian stable container is used for building all GCC frontends, except
for rust (gccrs) because Debian's rustc is too old for the few
dependencies the frontend has.

Installing a more recent rustc allows the building of the
frontend (until it can self-host).

Include the sha256 checksums for both archives and check that we are
downloading the expected binaries.

Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
Signed-off-by: Mark Wielaard <mark@klomp.org>

Do a gcc-fullest-debian-amd64 every 3 hours

Also decrease the timeout a bit in gcc_full_build_factory_gen now that
we got faster builds on both riscv and x86_64. And don't
flunkOnFailure for the gcc full build make check.

Add x3d1 and x3d2 vm container workers

These are "big" workers (Ryzen 9 machine).
Make bbo2 a "normal" worker.

Add elfutils-try-{debian,fedora}-coverage builders

Scheduled with the elfutils-try scheduler.
Add lcov to Containerfile-fedora-latest.

Add extensive checking (asserts) for 'fullest' GCC build

For non-release builds, GCC defaults to --enable-checking=yes.
For release builds, it defaults to --enable-checking=release.

The builder added in 92fa2b67f3875b5dc4ddca2cec1bba377a82e6a2 took less
time to complete than we expected, so let's try --enable-checking=yes,extra,rtl
which in my experience finds issues others missed.

gcc: add an all-FE builder (minus Rust)

Add a single build with all FEs except Rust (*) to catch bootstrap
issues exposed by less common FEs, e.g. PR116349.

(*) No Rust for now because Debian's rustc is too old, see
https://github.com/Rust-GCC/gccrs/issues/3116.

Simplify glibc builders use one scheduler and one factory

Run all tests on all builders. Drop release branch builds for
now. They often fail builds with modern toolchains. And results are
confusing. Should use different builders for different (release)
branches in the future.

Move arm64 gcc builder to fedora, add arm64 gcc-full builder on debian

The osuosl debian arm builder is bigger (has 16 cores) and should be
able to do a full gcc build. The osuosl fedora arm builder is a little
smaller (8 cores). Only allow one build on the fedora arm builder, but
allow each build to use all 8 cores in that case.

gcc_full_build_factory_gen: Add STAGE1_CFLAGS=-O2 to bootstrap make step

Using -O2 for STAGE1_CFLAGS can speed up bootstrap (the default is -O0).

Suggested-by: Sam James <sam@gentoo.org>

gcc_full_fedora_riscv_builder drop patch_gcc_makefile_step

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166

patch_gcc_makefile_step: Don't apply workaround to generic match files

generic-match files will produce maybe-uninitialized warning/errors
when build with -O1 -fno-tree-dominator-opts.

run patch_gcc_makefile_step in the gcc src workdir

gcc-riscv: Adjust configure and workaround compile time issue

Increate timeout for gcc full build to 12 hours for risc-v

Use 96 partitions. And increase the timeout for make check to 6 hours.

Increate timeout for gcc full build to 4 hours for risc-v

Increate timeout for gcc full build to 2.5 hours for risc-v

Add milkv-pioneer worker and riscv full gcc builder

Add a new worker "milkv-pioneer", a risc-v box with a SG2042,
64 core C920, RVV 0.7.1.

Make gcc_full_build_factory_gen take an array of extra configure
arguments. Adjust gentoo-sparc-big to pass the single string as array.

Add gcc-full-fedora-riscv worker using --disable-multilib
--enable-checking=release --with-matchpd-partitions=64
--with-insnemit-partitions=64. And add it to the gcc_scheduler.

Add RISC-V International and SOPHGO to Thanks.

binutils builders: add collapseBuilds=True to three laggards

Buildrequests piled up for those three builders that lacked collapseBuilds=True.
Now they are all like their peers.

valgrind buildbots: try "make regtest", include bunsen uploads

There's more data in them testsuite hills!

dyninst: split scheduler

It appears that not one build has been attempted by the buildbots
for git changes dribbling into dyninstfans.git.  I speculate
this is because of the re* means of identifying the subject
branches, so splitting the scheduler into two to try.

glibc: add debian-armhf builder

libc-alpha community requested more 32 bit testing.

Disable debian testing container builds

Like fedora rawhide, debian testing currently doesn't have a
buildbot-worker package that can be installed. Disable all debian
testing builders for now.

stap-prep INST path tweak, redux

stap privileged builders: tweak stap-prep to $prefix/bin location

For privileged stap builders, run a "stap-prep" operation first.

This could become part of the "stap-test*".sh bits.

Disable fedora rawhide container builds

Fedora rawhide currently is uninstallable because the python migration
is incomplete. Disable all fedora rawhide builders for now.

Add gdb_cleanup_gdbservers_step also to gdb_factory_full_native

Add a gdb_cleanup_gdbservers_step to all gdb factories

Sometimes gdbservers keep running after a make check-gdb step.
kill them at the end of the run.

make_gdb_check_full_step use maxcpus

Don't include gdb.{sum,log} in gdb check full runs

They are huge and take up time and resources to transmit and
store. They will be uploaded to bunsen. Where they are easier to
analyze.

Only run full native build for gdb-debian-arm64-full builder

The full runs take a lot of time (even when run parallel) on arm64
because various tests fail by timing out.

make_gdb_check_full_step: properly add FORCE_PARALLEL=1 to the command

Add gdb-debian-{amd64,arm64}-full workers

These do a full make check native/gdbserver/gdbserver-extended.
Just amd64 and arm64 on the big machines.

They don't have a gdb tag, but a gdb-full tag, which means they only
upload results to bunsen, but don't have an email notifier.

Fix binutils/gdb snapshot builds after src-release sanity check update

We need to make a "fake" commit with the snapshot version change so
the src-release sanity check doesn't trigger for uncommitted changes.

gdb_create_output_step: Use gdb-*tar.xz instead of .gz

Add sha512.sums and use xz for snapshots

Add make-sha which is called from the publish-snapshots script. The
publish-snapshots and make-sha scripts run on the snapshots server.

Also adjust the bfd/configure --version output for binutils
snapshots. This output is used for the directory and tar file name.

Use xz instead of gzip for the binutils, gdb and glibc snapshot
output.

Add gdb-snapshots builder

binutils: Always build and check libctf

Remove the special case binutils_factory_libctf just always build and
check libctf. Rename the binutils_factory_gas_binutils to
binutils_factory_minimal and include libctf and libsframe building and
checking.

binutils snapshot steps should run in the git step workdir

Add binutils-snapshots builder

Wrap the four separate pass .bunsen.source.* steps into one

Each step separately can take up to 30 seconds to execute. But they can
be executed as one shell command. Saving up to 1.5 minute per build.

Add debugedit clang builder

Same as a regular debugedit-x86_64-fedora builder, but configured with
env CC=clang.

Introduce vm_most_workers group and move some container builders to it

vm_most_workers is vm_workers minus the bbo1-1 and bbo1-2 workers,
which run somewhat low on diskspace. Move gcc-autoregen and
libabigail[-try]-opensuse[tw|leap]-x86_64 to vm_most_workers.

Containerfile-fedora-latest add texlive-threeparttable

The threeparttable package is used by the DWARF latexdoc spec now.

autoregen.py: Remove special cases for libgm2

gcc commit 67e66c973ce3 ("modula2: Regenerate libgm2 Makefile.ins using
correct include order") made it so libgm2 autotool files (including in
the directories under it) can now be simply be regenerated with
autoreconf -f.

autoregen.py: Use autoreconf by default

Since the list of directories compatible with autoreconf is large,
make it the default, and introduce a list of directories to
reconfigure 'manually'.

stap: exclude testsuite/.systemtap-root from bunsen upload

The testsuite leaves a heap of .log files under
testsuite/.systemtap-root/cache, which are then picked up by bunsen.
They shouldn't be.

Add full roster of fedora/rhel/centos-stream stap workers and builders

The full set of buildbots will take a bit more time to bring up,
but I'm sending them in one patch now for simplicity's sake.

Worker ibmpower9-cel was setup as a test. Not needed anymore.

gdb-alma-x86_64 is no longer broken, add gdb-try-alma-x86_64 back

Add stap-fedrawhide-x86_64 to buildbot.config.sample

With all workers in the buildbot.config.sample file one can do a quick
local check.

 $ cp buildbot.config.sample ~/buildbot.config
 $ buildbot checkconfig builder

See README under = Local hacking

buildbot.config.sample: Replace centos-x86_64 worker with alma-x86_64

Forgot to rename when upgrading the working from centos7 to alma8.

Add new worker "stap-fedrawhide-x86_64" and associated builder/scheduler.

autoregen.py: Add introduction comment

To give more context to users, with the plan of moving this file to
contrib/ in binutils-gdb and gcc repositories.

autoregen.py: libcpp can use autoreconf

After libcpp's aclocal.m4 and configure were fixed in GCC, we can now
use autoreconf for it too.

autoregen.py: improve comment

Make it clearer that we use regenerate_manually() by default.

autoregen.py: Move subdirs common to binutils-gdb and gcc...

... at the beginning of AUTORECONF_DIRS.

Just for the sake of clarity.

autoregen.py: enable autoreconf for gcc, libdecnumber, libiberty, libobjc

Calling just 'autoreconf' works well for these subdirs despite the
absence of Makefile.am: there's no real need to provide -I xxxx flags
when calling aclocal, the generated files are the same.

It does make a difference for gcc and libobjc however: some warnings
are printed by autoreconf, because additional .m4 files are parsed in
a different order by plain 'aclocal' and 'aclocal -I xxx'.

We can accept that for the buildbot, for the sake of simplicity of
this helper, but that may confuse users.

gcc-mingw don't enable rust

gccrs now requires cargo to build

autoregen.py: Add binutils directories to AUTORECONF_DIRS

These directories are correctly regenerated using autoreconf, so use
it as it is simpler.

autoregen.py: Add support for autogen

GCC's toplevel Makefile.in is generated with
autogen Makefile.def
(which uses Makefile.tpl too)

Containerfile-autotools: Add autogen

autoregen.py: Use autoreconf in most GCC directories

Add most of GCC's subdirectories to AUTORECONF_DIRS, since 'autoreconf
-f' works for them.

A few subdirs still need to be regenerated "manually", because they do
not have Makefile.am which autoreconf uses to determine which aclocal
flags to use.

Most use our default aclocal -I../config, but a few need special
flags, which I copied from the corresponding Makefile.in:
* fixincludes: -I.. -I../config
* gcc, libiberty, libobjc: -I../config -I..
* libgm2: -I../config -I.. although Makefile.in says otherwise. Using
  what Makefile.in defines results in generating aclocal.m4 with a
  different contents than what it is in the repo. The repo is
  presumably wrong, but use this until this is fixed.

Note that we do not regenerate
libvtv/testsuite/other-tests/Makefile.in, because
libvtv/testsuite/other-tests/ has no configure.ac.

Running this script over GCC's repository generates quite a few
warnings, which are the same as before this patch. Namely, these
subdirs seem to have incorrect autotools files (at least partially):
* libgfortran
* libgomp
* libsanitizer

This patch does not support regenerating gcc/m2/gm2-libs/config-host
and gcc/m2/gm2-libs/gm2-libs-host.h.in because I didn't manage to
regenerate them with the exact same content. FTR I tried:
autoconf -f config-host.in > config-host
autoheader config-host.in
as described in gcc/m2/Make-maintainer.in

Similarly, we skip libcpp because the files we regenerate have small
differences with the current versions.

Tested by removing all aclocal.m4 files, Makefile.in files derived
from Makefile.am, configure files derived from configure.ac and
checking they are correctly regenerated (that is, 'git status' does
not report deleted nor modified files).

autoregen.py: Flush all print commands

For consistency and easier debug of traces

autoregen.py: Move comment...

... just before the line where it makes sense

auroregen.py: Check AC_CONFIG_MACRO_DIR instead of AC_CONFIG_MACRO_DIRS

Some configure.ac files still use AC_CONFIG_MACRO_DIR rather than
AC_CONFIG_MACRO_DIRS, so we would skip them without this patch.

Add collapseRequests=True to gccrust-fedora-arm64

We only have one fedora-arm64 builder.

Add gdb-ubuntu-riscv builder

gdb builds fine and all test variants, unix, native-gdbserver and
native-extended-gdbserver pass.

Add g++-multilib to Containerfile-debian-{stable,testing}

For building valgrind g++ -m32 tests.

autoregen.py: use autoreconf in some directories

The builder currently mis-generates the config files for the gdb and
gnulib directories.  It passes `-I ../config` to aclocal, causing the
include path order to be different to what it would be without that -I
argument, causing the generated aclocal.m4 to be different (same entries
but different order).

For the gdb, gdbserver, gdbsupport and gnulib directories, the config
files are usually re-generated without any -I argument.  In fact, for
gnulib, it is baked in gnulib/update-gnulib.sh that aclocal should be
called without -I arguments:

    aclocal &&
    autoconf &&
    autoheader &&
    automake

Moreover, they can be re-generated using autoreconf, removing the need
to guess which speicific tools need to be invoked.  autoreconf takes a
bit more time to run than the individual tools, but it's worth it for
the simplicity.

So, add a list of directories for which it is known that they can be
re-generated using a simple autoreconf without special flags.  For these
directories, call `autoreconf -f`.

autoregen.py: pass environment through subprocess.run's env parameter

Arsen pointed out that a better way to pass the environment to the
subprocess (one that is not vulnerable to space splitting, for instance)
is to use subprocess.run's env parameter.

 - Define a new EXTRA_ENV dict with the environment variables we want to
   add to the current process' environment, when running subprocesses
 - Copy the current process' environment into ENV
 - Augment ENV with EXTRA_ENV
 - Use EXTRA_ENV when logging the environment variables

autoregen.py: do not pass sys.stdout/sys.stderr to subprocess.run

Arsen pointed out that this is unnecessary.  If we don't pass an
stdout/stderr, the subprocess will use the same file descriptors as the
parent, which is what we want.

auroregen.py: print environment only once at the beginning

Reduce the duplication in the output a bit by printing the environment
variables passed to all commands only once at the beginning.

Note that the previous code ended up putting {ENV} twice in the command,
which is harmless but unnecessary.

autoregen.py: be more verbose

- Print the version of all the tools used.
 - Print more clearly when entering or skipping a directory.

autoregen.py: let subprocesses print to stdout/stderr

Use `subprocess.run` with `stdout=sys.stdout` and `stderr=sys.stderr`,
such that subprocesses print to the job's stdout and stderr directly.

This is not expected to cause any change, as the current commands don't
output anything.  But if they do, I think it's useful to have that
output in the buildbot's logs.