glibc CI (Re: forge vs gitolite)

[Mark Wielaard]

Hi Gabriel,

On Tue, Feb 10, 2026 at 01:50:31AM +0100, Gabriel Ravier wrote:
> I think the issue here is more that there appears to be a disconnect
> as to what exactly is SaaSS (or at least an "acceptable" thing for
> the glibc project to do) in the context of stuff like running tests
> automatically. Let's say that today, there is one s390x machine
> running tests (or arc, csky, or1k, sh or some other esoteric
> architecture - the specifics aren't super important), and that the
> project "relies" on this to make sure random commits don't break on
> s390x. Would this be SaaSS ? Would whether such is SaaSS rely on the
> precise manner in which the tests are used ? e.g.:
> - Is it SaaSS if we consider that the machine is required for s390x
> support, and if it is retracted with no replacement, s390x support
> will be officially dropped ?
> - Is it SaaSS if we consider that the machine is a non-required
> courtesy - if it is available, we make sure as often as possible to
> not break s390x, but if it isn't/is retracted in the future, we
> simply decide that some other interested s390x user can provide
> their machine if they want better support/to make sure random
> commits don't break s390x, and if no one provides one just support
> s390x somewhat less well ?
> - Is it SaaSS if the machine is of a more common architecture that
> we could "test ourselves" ? How common would it have to be ? Does
> e.g. any architecture with QEMU support qualify ? (even if running
> the tests would take much longer there, almost impractically so)
> - Is it SaaSS depending on *who asked* the machines to run the tests
> (e.g. because the glibc project kindly asked the owner of the
> machine to do so, or because the owner of the machine simply decided
> to do so), and if so, does it matter at all how the tests are used
> after someone "independently" (or not) ran the tests ?

Nice questions. To make it a little more concrete, let me describe how
the current glibc CI tests are done for s390x and x86_64 through
builder.sourceware.org.

s390x
Builds:
https://builder.sourceware.org/buildbot/#builders/glibc-fedora-s390x
Results:
https://builder.sourceware.org/testruns/?has_keyvalue_op=glob&has_keyvalue_k=testrun.gitdescribe&has_keyvalue_v=buildbot/glibc-fedora-s390x/%2A
Git file that describes what gets run:
https://sourceware.org/cgit/builder/tree/builder/master.cfg#n4452
glibc buildbot maintainers:
https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_BuildBot
But anybody can submit a patch to the builder project which then get
reviewed and integrated:
https://sourceware.org/mailman/listinfo/buildbot
Marist University hosts the server and lets us (through our Fedora
affiliate) install any software we need to run (on our VM) and
individual hackers can get access if they want to interactively debug
some issue. It has mock installed so you can install your own versions.

x86_64
Builds:
https://builder.sourceware.org/buildbot/#builders/glibc-fedora-x86_64
Results:
https://builder.sourceware.org/testruns/?has_keyvalue_op=glob&has_keyvalue_k=testrun.gitdescribe&has_keyvalue_v=buildbot/glibc-fedora-x86_64/%2A
The same git file describes what to run.
But in the x86_64 case also the Container file is in the builder repo:
https://sourceware.org/cgit/builder/tree/builder/containers
These containers are run in VMs on two servers from OSUOSL that they
own but we paid for some disks and control all installation of
software (both the bare metal OS and the VMs).
You can also use these container files to run the exact same set of
tests locally:
https://sourceware.org/cgit/builder/tree/README_containers

Cheers,

Mark