On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault <samuel.thiba...@gnu.org>
wrote:
> Yes, sure, anything will do.
>
> I essentially mean that "we" shouldn't be me.
>
> For a start, just testing that the whole thing just builds in the
> various situations would be a *VAST* improvement, considering the amount
> of time I spend on just that.
>
> Then there was recently some work on building simple userland tests,
> that can be easily tested as well.
>
> Essentially, any regression that people usually find ("doesn't build",
> "doesn't boot", etc.) is worth testing. That can also be simply running
> the glibc testsuite in the resulting build.
>
> Samuel
>
I have a simple CI setup in my cross-hurd github repository, see
https://github.com/flavioc/cross-hurd/actions/runs/7080757561
It uses 4 different build configurations and it runs on my home server on a
daily basis. I have sent quite a few patches throughout the last year or so
because things would fail to build from time to time.
I run the same build harness whenever I have a new patch plus some manual
testing (e.g., running qemu to see that things are not broken).
The issue is that I am building with my own scripts, so things are not
configured like Debian GNU/Hurd or even using the same patches, but it's a
good starting point - I think it's fine that we have multiple ways to build
the Hurd.
Regarding my MiG patch generating warnings on glibc: I was looking into how
I was building glibc and indeed I am passing --disable-werror. I had set
this up many years ago so that explains what happened and sorry about that
:) I need to go back to it, remove --disable-werror and generate the
appropriate casts.
>
> Almudena Garcia, le dim. 03 déc. 2023 01:20:58 +0000, a ecrit:
> > As a little suggestion, using my very little knowledge about it, we can
> set a mirror in a GitLab server, which incorporates this functionality
> natively. We can deploy a GitLab local server if we don't want to depends
> of gitlab.com, and set a couple of tests in it.
> >
> > As this way, we can use a testing branch in the GitLab server to merge
> the changes and execute the tests automatically from it before applying it
> over Savannah's upstream.
> >
> > Maybe even we can configure any task to push the changes in Savannah if
> they pass the tests.
> >
> > Obviously, the first what we need is to discover what tests are
> necessary to execute to be sure that all the changes works properly.
> >
> > What do you think?
> >
> > El domingo 3 de diciembre de 2023, Samuel Thibault escribió:
> > > Can some people eventually set up some CI somehow somewhere?
> > >
> > > (AFAIK savannah doesn't support such a thing, so it wouldn't go there,
> > > so anybody can feel free to set it up wherever it sees easiest).
> > >
> > > If people wonder why I don't make releases that often, the reason is
> > > very simple: each time I try to do one, I end up spending *hours* in
> > > fixing various build failures and runtime failures, because things are
> > > not tested properly. And I'm not saying that *people* are not testing
> > > properly, because there are so many various cases that can break (32,
> > > 64, 32-on-64, acpi, non-acpi, smp, non-smp, Xen, etc.). So we do need
> > > automated testing, otherwise that just burns my time.
> > >
> > > Samuel
>
>
