Re: CI
Hello, Flávio Cruz, le lun. 29 janv. 2024 23:03:43 -0500, a ecrit: > On Sun, Jan 14, 2024 at 7:13 PM Samuel Thibault <[1]samuel.thiba...@gnu.org> > wrote: > > Flávio Cruz, le mar. 05 déc. 2023 01:27:30 -0500, a ecrit: > > I have sent quite a few patches throughout the last year or so > > because things would fail to build from time to time. > > I'd say failures should be notified on [4]commit-h...@gnu.org, so you're > not the only one to fix issues. > > > I will try to do that. Thanks :) > I think it would be nice to run tests similar to the > gnumach qemu based tests so that we don't simply test compilation but also > that > the resulting images can boot and shutdown. Indeed! > FYI: it is now possible to build a working x86_64 image using [5]https:// > github.com/flavioc/cross-hurd if people want to hack on x86_64 as I added > support for rumpdisk recently. Cool :D Samuel
Re: CI
Hi
On Sun, Jan 14, 2024 at 7:13 PM Samuel Thibault
wrote:
> Hello,
>
> Flávio Cruz, le mar. 05 déc. 2023 01:27:30 -0500, a ecrit:
> > On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault <[1]
> 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.
> >
> > I have a simple CI setup in my cross-hurd github repository, see
> [2]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.
>
> Nice :)
>
> > I have sent quite a few patches throughout the last year or so
> > because things would fail to build from time to time.
>
> I'd say failures should be notified on commit-h...@gnu.org, so you're
> not the only one to fix issues.
>
I will try to do that. I think it would be nice to run tests similar to the
gnumach qemu based tests so that we don't simply test compilation but also
that the resulting images can boot and shutdown.
FYI: it is now possible to build a working x86_64 image using
https://github.com/flavioc/cross-hurd if people want to hack on x86_64 as I
added support for rumpdisk recently.
>
> > 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,
>
> That's not necessarily a problem. The debian-only patches are supposed
> to be minimal, and having diversity in tests is usually a good thing.
>
> Samuel
>
Re: CI
Samuel Thibault writes:
> Hello,
>
> Flávio Cruz, le mar. 05 déc. 2023 01:27:30 -0500, a ecrit:
>> On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault <[1]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.
>>
>> I have a simple CI setup in my cross-hurd github repository, see [2]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.
>
> Nice :)
>
>> I have sent quite a few patches throughout the last year or so
>> because things would fail to build from time to time.
>
> I'd say failures should be notified on commit-h...@gnu.org, so you're
> not the only one to fix issues.
>
>> 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,
>
> That's not necessarily a problem. The debian-only patches are supposed
> to be minimal, and having diversity in tests is usually a good thing.
>
> Samuel
>
I've got two Dell Optiplexs just sitting around doing pretty much
nothing. I forget the version number at the moment, but do we want a
Hurd CI running the Hurd? Or do we want the CI running GNU/Linux?
I would like to put one or two of those machines to good use. I suppose
that I would need the adapter for the keyboard and mouse. Or just buy
a really old keyboard/mouse.
Joshua
--
Joshua Branson
Sent from the Hurd
Re: CI
Hello,
Flávio Cruz, le mar. 05 déc. 2023 01:27:30 -0500, a ecrit:
> On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault <[1]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.
>
> I have a simple CI setup in my cross-hurd github repository, see [2]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.
Nice :)
> I have sent quite a few patches throughout the last year or so
> because things would fail to build from time to time.
I'd say failures should be notified on commit-h...@gnu.org, so you're
not the only one to fix issues.
> 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,
That's not necessarily a problem. The debian-only patches are supposed
to be minimal, and having diversity in tests is usually a good thing.
Samuel
Re: CI
On Sat, Dec 2, 2023 at 8:30 PM Samuel Thibault
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 +, 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
>
>
Re: CI
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
Almudena Garcia, le dim. 03 déc. 2023 01:20:58 +, 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
Re: CI
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 > > -- Enviado desde mi dispositivo Sailfish
